データ分析例 - 施策の傾向のバックアップ(No.7) - .NET 開発基盤部会 Wiki

[ トップ ] [ 新規 | 一覧 | 単語検索 | 最終更新 | ヘルプ ]

「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

戻る
- 各種データ分析の例
  - 施策の傾向
  - コロワク系
  - ウクロナチ戦争?

GO/NOGO判定用事例データベース

目次 †

概要 †

データから、施策の傾向を分析する。

詳細 †

全体的に予算が付き易い施策はトレンドを追うモノが多い。

ただし、トレンドを追うモノは結果が出ず続かない傾向がある。

予算の付き難いモノは、定常業務化してロングランする傾向がある。

テクノロジ系とプロセス系

テクノロジ系はトレンドを追うモノが多く長続きしないが、
前述した通り、定常業務化したものはロングランする。
（この条件に合致するモノは、トレンド非依存のベネフィットが創出されているため

プロセス系は、先進的なモノはアーキテクチャ宇宙飛行士的な様相を呈するが、
前述した通り、定常業務化される予定のモノはロングランする。
（この条件に合致するモノは、実際に運用されるプロセスであるため

分類 †

Wiki系 †

潜在的な需要は多いが、施策としてオーソライズされ難い。
予算が付かなくても継続される定常業務化すると良い。

人目に付く所にどうやって置くかが？課題になる。
弊WikiやQiita等、組織外にリリースするのが良い。

テンプレ系 †

潜在的な需要は多いが、施策としてオーソライズされ難い。

課題とOSS化

課題
- 予算が付かなくても継続される定常業務化すると良い。
- 人目に付く所にどうやって置くかが課題になる。

OSS化
資産・開示の問題をクリアできる。

コミュニティでやる。
GitHubに置く。

パッケージ系 †

フレームワーク、ライブラリ系

潜在的な需要は多いが、
施策としてオーソライズされ難い。

また、開発の難易度が高い
- 生産性の上がる仕様を立案が属人的
- 自ずと、失敗事例が増えるので新規参入が減る。

課題とOSS化
テンプレ系と同じ。

UIサブシステム系 †

歴史的に、コケる技術が多い（WPF、Silverlight、WinRT、jQuery系）。

変化のスピードが早い。
新技術は汎用的と見せかけて実はドメインに特化している。
鉄板技術が鉄板のまま（Window Forms、MPA（Web Forms/JSF、MVC））

インフラ系 †

情シ系
基本的に堅調だが、情シ業務

ネットワーク・サービス
ストレージ・サービス
OAソフトウェア（Office、O365等）

プラットフォーム系
汎用的かつ入用だが、全体的に予算化が困難。

スマホ系
- スマホを ≒ Windows、Linuxと同じプラットフォームと認識して取り組む。
- 組織内インフラ的な乗りにならないので例外的に良い施策。

Windows、Linux
- 潜在的な需要は多いが、施策としてオーソライズされ難い。
- 組織内インフラ的な乗りにならないので例外的に良い施策。

クラウド・サービス系
予算化はされ易いが、大規模で、パブクラ（メガクラ）に押される。

IaaS
- 仮想化系のプラクラ導入で行ける。
- セキュリティ的に必要なところがターゲット。

PaaS
- K8sなど、もしくは、オンプレ回帰系クラウド・ソリューション
- 組織外か組織内かが難しい状況（ペイするか否か）。

SaaS
- Redmine、GitLab、JIRAなど組織内サービス
- 今後は組織外サービスが浸透していく予想。

プロセス系 †

規格系
- 事務手続き、フェーズゲート、チェック、検査などは、上手く行くケースが多い。
- なんらかの方法論による付加価値追加については、上手く行かないケースが多い。

新プロセス系

先行研究は予算が付く
（ただし、圧倒的に成功しない）
- OOA
- SOA
- DDD
- アジャイル

ただし、規格化は、独自研究結果ではなく、標準化されたモノになる。
（故に、明確な標準が出てこないOOA、SOA、DDDは失敗する）
- 標準：PMBOK、BABOK、スクラム等。
- デファクト・スタンダード：組織外コンテンツ、親会社コンテンツ

最新技術系 †

SPA
コレは、≒ UIサブシステム系

プラットフォーム系
最近、増えてきている。

スマホ
- UIサブシステム系として取り組んでいる人も多い。
- 少数派がプラットフォーム系として取り組むが、コチラが正しい。

クラウド
プラットフォーム系参照

Buzz系 †

実績から、プロダクトのマーケティングに使われているケースが多いように思う。
結果として、特定プロダクトの担ぐ系にならざるをえない（施策というより事業）。

実績 †

Wiki系 †

個人的なモノが多い。
脳内では１人１個ある。
体系的にまとめる（１件１葉ならStack Overflowで良い）。

データ
- 組織内で公知のモノは２・３程度
- 弊部会は組織外で公知のものを運営（３つ

テンプレ系 †

弊部会で開発

データ

導入実績数は増加傾向
導入件数300件

類似施策数は減少傾向
- 組織内で公知のモノは１・２程度
- 弊部会は組織外で公知のものを運営（９リポジトリ

パッケージ系 †

テンプレ系と同じ。

データ

導入実績数は増加傾向
導入件数300件

類似施策数は減少傾向
- 組織内で公知のモノは１・２程度
- 弊部会は組織外で公知のものを運営（１リポジトリ、７パッケージ

UIサブシステム系 †

内容的にはWikiやテンプレのレベル。
- 主流 30%（主流は枯れる ≒ サポート不要）
- 傍流 40%（成果が減る
- discon 30%（ダメージ大

データ

主流
4 / 14件 ≒ 30%
- Window Forms
- MPA（Web Forms/JSF、MVC）

傍流
6 / 14件 ≒ 40%

WPF

SPA系
・Angular
・React
・Vue

クロスプラットフォーム系
・Electron
・Flutter

discon
4 / 14件 ≒ 30%
- WinRT
- jQuery
- Silverlight
- Cordova

インフラ系 †

パブクラ
内容的にはWikiやテンプレのレベル。

プラクラ
悪戦苦闘が観測されている。
- 施策A（情シ系 IaaS）：△
- 施策B（サービス開発系 PaaS）：☓
- 施策C（データサイエンス系 PaaS/SaaS）：☓

例えば、施策Cは、情シ系の方が良い気がする。
（ただ、組織内にデータ分析のアクティビティが増えないとダメ）

プロセス系 †

OOA：☓
SOA：☓
TDD：☓
DDD：☓（予算化されていない
アジャイル：△（独自研究結果は無し

最新技術系 †

粒度が適切なものは施策化し易い。

粒度が適切
ただ、教育体系が出来上がるまでの過渡期感はある。

粒度が適切でない。
- 粒度が小さ過ぎる（Wikiやテンプレのレベル。
- 粒度が大き過ぎる（分割すると小さい

データ

粒度小さい
Wikiやテンプレのレベル。
- SPA：☓
- スマホ：☓
- クラウド：△
  ・サービスA：○
  ・サービスB：○
  ・サービスC：○
  ・...

粒度大きい
- データサイエンス：◎
- DX：△
  ・IoT：○
  ・ビッグデータ：○
  ・BI / AI：○

Buzz系 †

テスト自動化 / RPA

ローコード / ノーコード

以下の施策中にもBuzz成分を含む。

参考 †