「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
データから、施策の傾向を分析する。
詳細 †
施策の分類と実績の分析
分類 †
Wiki系 †
- 潜在的な需要は多いが、施策としてオーソライズされ難い。
- 予算が付かなくても継続される定常業務化すると良い。
- 人目に付く所にどうやって置くかが？課題になる。
弊WikiやQiita等、組織外にリリースするのが良い。
テンプレ系 †
- 潜在的な需要は多いが、施策としてオーソライズされ難い。
- 課題
- 予算が付かなくても継続される定常業務化すると良い。
- 人目に付く所にどうやって置くかが課題になる。
- トレンド非依存のベネフィットを創出する事が難しい。
パッケージ系 †
フレームワーク、ライブラリ系
- 潜在的な需要は多いが、
施策としてオーソライズされ難い。
- また、開発の難易度が高い
- 生産性の上がる仕様を立案が属人的
- 自ずと、失敗事例が増えるので新規参入が減る。
UIサブシステム系 †
歴史的に、コケる技術が多い（WPF、Silverlight、WinRT、jQuery系）。
- 変化のスピードが早い。
- 新技術（新UIサブシステム）は汎用的と見せかけて実は特定のドメインに特化している。
- 鉄板技術が鉄板のまま（Window Forms、MPA（Web Forms/JSF、MVC））
...と言う事で、流石に新規参入は減った感。
インフラ系 †
- ネットワーク・サービス
- ストレージ・サービス
- OAソフトウェア（Office、O365等）
- プラットフォーム系
汎用的かつ入用だが、全体的に予算化が困難。
- スマホ系
- スマホを ≒ Windows、Linuxと同じプラットフォームと認識して取り組む。
- 組織内インフラ的な乗りにならないので例外的に良い施策。
- Windows、Linux
- 潜在的な需要は多いが、施策としてオーソライズされ難い。
- 組織内インフラ的な乗りにならないので例外的に良い施策。
- （クラウド・）サービス系
予算化はされ易いが、大規模で、パブクラ（メガクラ）に押される。
- IaaS
- 仮想化系のプラクラ導入で行ける。
- セキュリティ的に必要なところがターゲット。
- PaaS
- K8sなど、もしくは、オンプレ回帰系クラウド・ソリューション
- 組織外か組織内かが難しい状況（ペイするか否か）。
- SaaS
- Redmine、GitLab、JIRAなど組織内サービス
- 今後は組織外サービスが浸透していく予想。
プロセス系 †
- 規格系
- 事務手続き、フェーズゲート、チェック、検査などは、上手く行くケースが多い。
- なんらかの方法論による付加価値追加については、上手く行かないケースが多い。
- 先行研究は予算が付く
（ただし、圧倒的に成功しない）
- ただし、規格化は、独自研究結果ではなく、標準化されたモノになる。
（故に、明確な標準が出てこないOOA、SOA、DDDは失敗する）
- 標準：PMBOK、BABOK、スクラム等。
- デファクト・スタンダード：組織外コンテンツ、親会社コンテンツ
最新技術系 †
Buzz系 †
- 実績から、プロダクトのマーケティングに使われているケースが多いように思う。
- 結果として、特定プロダクトの担ぐ系にならざるをえない（施策というより事業）。
実績 †
Wiki系 †
- 個人的なモノが多い。
- 脳内では１人１個ある。
- 体系的にまとめる（１件１葉ならStack Overflowで良い）。
- データ
- 組織内で公知のモノは２・３程度
- 弊部会は組織外で公知のものを運営（３つ
テンプレ系 †
- 類似施策数は減少傾向
- 組織内で公知のモノは１・２程度
- 弊部会は組織外で公知のものを運営（９リポジトリ
パッケージ系 †
- 類似施策数は減少傾向
- 組織内で公知のモノは１・２程度
- 弊部会は組織外で公知のものを運営（１リポジトリ、７パッケージ
UIサブシステム系 †
- 内容的にはWikiやテンプレのレベル。
- 主流 30%（主流は枯れる ≒ サポート不要）
- 傍流 40%（成果が減る
- discon 30%（ダメージ大
- 主流
4 / 14件 ≒ 30%
- Window Forms
- MPA（Web Forms/JSF、MVC）
- SPA系
・Angular
・React
・Vue
- クロスプラットフォーム系
・Electron
・Flutter
- discon
4 / 14件 ≒ 30%
- WinRT
- jQuery
- Silverlight
- Cordova
インフラ系 †
- プラクラ
悪戦苦闘が観測されている。
- 施策A（情シ系 IaaS）：△
- 施策B（サービス開発系 PaaS）：☓
- 施策C（データサイエンス系 PaaS/SaaS）：☓
例えば、施策Cは、情シ系の方が良い気がする。
（ただ、組織内にデータ分析のアクティビティが増えないとダメ）
プロセス系 †
- 脆弱性診断
- アプリ・インフラ脆弱性診断：○
- OSS脆弱性ライセンス診断：○
- OOA：☓
- SOA：☓
- TDD：☓
- DDD：☓（予算化されていない
- アジャイル：△（独自研究結果は無し
最新技術系 †
- 粒度が適切
ただ、教育体系が出来上がるまでの過渡期感はある。
- 粒度が適切でない。
- 粒度が小さ過ぎる（Wikiやテンプレのレベル。
- 粒度が大き過ぎる（分割すると小さい
- DX：△（大き過ぎ
・IoT：○
・ビッグデータ：○
・BI / AI：○
- クラウド：△（大き過ぎ
・サービスA：○
・サービスB：○
・サービスC：○
・...
Buzz系 †
傾向まとめ †
生産技術系の施策は、
- 定常業務化
- ...が出来るかどうか？が重要。
- ...するには、
- キャズム超えが前提。
- そして、基幹的事業になること。
- ポイント
- 基幹的事業にならないと生産性向上の投資が予算化出来ない。
- ただし、シェアが大き過ぎると、アーキテクチャ宇宙飛行士化する。
トレンドを追うモノ †
トレンドだけで終わるモノ。 †
- 全体的に予算が付き易い施策はトレンドを追うモノが多い。
- ただし、トレンドを追うモノは結果が出ず続かない傾向がある。
キャズム超えの後、基幹的事業になるモノ。 †
- 逆説的に、
予算の付き難いモノは、定常業務化してロングランする傾向がある。
- 施策「開発」の定常業務化（ドキュメント、プロダクト、テンプレート
- 施策「実施」の定常業務化（フェーズゲート、チェック、検査
- この理由は、
- キャズム超えの後、基幹的事業になる可能性が高い時点であるため。
- そして、基幹的事業にならないと生産性向上の投資が予算化出来ない。
テクノロジ系とプロセス系 †
いずれも、定常業務化される予定のモノはロングランする。
テクノロジ系 †
テクノロジ系は、
- ロングランするモノは、
- テンプレ、パッケージ、Wikiなどに持ち込む必要がある。
- この状態で、漸くトレンド非依存のベネフィットが創出されている状態になる。
プロセス系 †
プロセス系は、
プロフィット系とノンプロフィット系 †
プロフィット系 †
プロフィットで出来るケースは、
- 研究開発施策で後に事業に引き渡す。
- 生産技術施策にする必要はない。
ノンプロフィット系 †
- 通常の事業で
- 溜まらないノウハウ
- 資産化されないノウハウ、プロダクト
参考 †
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
