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

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

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

戻る

各種データ分析の例
- マーケティング
- 施策の傾向
- 宇露戦争
- コロワク系
- お金の話

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

目次 †

概要 †

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

詳細 †

施策の分類と実績の分析

分類 †

Wiki系 †

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

予算が付かなくても継続される定常業務化すると良い。

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

テンプレ系 †

特徴
- 潜在的な需要は多いが、施策としてオーソライズされ難い。
- 技術習得、QCD向上、信頼性向上などに貢献できる。

課題と対策

課題
- 予算が付かなくても継続される定常業務化すると良い。
- 人目に付く所にどうやって置くかが課題になる。
- トレンド非依存のベネフィットを創出する事が難しい（要本気度

対策
（OSS化

資産・開示の問題をクリアできる。
コミュニティでやり、GitHubに置く。

パッケージ系 †

特徴
- ≒ フレームワーク、ライブラリ系の意味。
- 基本的な部分は、テンプレ系と同じ。
- また、テンプレ系と比べ、開発の難易度が高い。
  - 生産性の上がる仕様を立案が属人的
  - 自ずと、失敗事例が増えるので新規参入が減る。

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

UIサブシステム系 †

変化のスピードが早い。

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

新UIサブシステムは汎用的ではない。
汎用的と見せかけて実は特定のドメインに特化している。

鉄板UIサブシステムが引き続き鉄板のまま。
Window Forms、MPA（Web Forms/JSF、MVC）

...と言う事で、流石に新規参入は減った感。

DBMSアプリの開発生産性向上と言うPG系施策の限界。
- テンプレやパッケージに行けないモノについては特に。
- RDBMSアプリへの新規投資が減ったのも関係あるかも。

インフラ系 †

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

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

プラットフォーム系

特徴
- 汎用的かつ入用だが、全体的に予算化が困難
- 組織内インフラ的な乗りにならないので良い施策

小分類

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

スマホ系
スマホを ≒ Windows、Linuxと同じプラットフォームと認識して取り組む。

（クラウド・）サービス系

特徴
- プラクラは予算化され易いが、大規模で、パブクラ（メガクラ）に押される。
- なんというか、プラクラ名目で予算化して、パブクラ利用リテラシを高めてるんじゃ？

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

PaaS ～ CaaS
・案件での採用数は増加している。
・CaaSはK8sなどオンプレ回帰系クラウド・ソリューション
・組織外か組織内か？が難しい状況（ペイするか否か）

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

プロセス系 †

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

方法論系

旧方法論
やることがないので予算が付かない
- POA
- DOA
- OOP（OOD

新方法論
先行研究は予算が付く（ただし、圧倒的に成功しない）
- OOA、SOA、DDD
- TDD、CI、DevOps?
- アジャイル、スタートアップ

方法論系の規格化は、独自研究結果ではなく、標準化されたモノになる。
- 標準：PMBOK、BABOK、スクラム等。
- デファクト・スタンダード：組織外コンテンツ、親会社コンテンツ

明確な標準が出てこないモノは独自研究扱いになり例外無く失敗する。
- OOA、SOA、DDD
- , etc.

最新技術系 †

UIサブシステム系
例えば、SPA系など

インフラ系 → プラットフォーム系
最近（と言ってもココ20年）、増えてきている。

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

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

Buzz系 †

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

※ 担ぐ系：自社製品ではなくオープン系製品を使用したソリューション

実績 †

Wiki系 †

特徴
- 個人的なモノが多い。脳内では１人１個ある。自分のためのWiki。
- 体系的にまとめる（１件１葉ならStack Overflowで良い）。
- ネットコンテンツと比べ手厚い社内コンテンツは良し悪し。

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

テンプレ系 †

特徴
弊部会でOSS化した例

データ

導入実績数は増加傾向
導入件数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は、情シ系が担当した方が良い気がする。
（ただ、組織内にデータ分析のアクティビティが増えないとダメ）

プロセス系 †

規格系

PMBOK
脆弱性診断
- アプリ・インフラ脆弱性診断：○
- OSS脆弱性ライセンス診断：○

新方法論系

土台
- OOA：☓ ┐
- SOA：☓ ├ 使える公の研究結果も少ない。
- TDD：☓ ┘

延長上
- DDD：☓　OOA、SOAを更に捏ね繰り回し、予算化されるレベルにない。
- CI、DevOps?：☓　TDD延長を、ごった煮で予算化（実態が不明瞭

その他
- アジャイル：△ → ◯ PMBOK 7th（独自研究結果でなくなった。
- スタートアップ：△（書籍レベルを脱却していない印象がある（一般可が困難
- UI/UXデザイン：△（公の研究結果のみ。独自研究結果は少ない。

最新技術系 †

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

粒度が適切
都合が良過ぎて過渡期感ある。

粒度が適切でない。

粒度が小さ過ぎる
・Wikiやテンプレのレベル止まり
（テンプレ化・パッケージ化にリーチしなかった。
・予算化困難、ただし難易度は低い。

粒度が大き過ぎる
・ただし、網羅性や、プログラム・マネジメントが重要になる。
・予算化可能、ただし難易度は高い。

データ

粒度小さい
Wikiやテンプレのレベル。
- SPA：☓
- スマホ：☓

粒度大きい

クラウド：△（オンプレの延長上
・サービスA：○
・サービスB：○
・サービスC：○
・...

DX：△（組み合わせ、クロスセル可
・IoT：△
・ビッグデータ：○
・BI / AI：○

データサイエンス：◎（パラダイムシフト

Buzz系 †

傾向
- 施策化されたものは案外少ない
- その後、担ぐ系にシフトする。
- となると、やっぱり、マーケティング？

分類毎

テスト自動化系
CI、TDDなどと組み合わさってアジャイル＆DevOps?へ。
- GUIテスト自動化
- テスト自動生成

内製化系
→ 商材を担ぐ系
- RPA
- ローコード / ノーコード

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

傾向まとめ †

生産技術系の施策は、

定常業務化

...が出来るかどうか？が重要。

...するには、
- キャズム超えが前提。
- そして、基幹的事業になること。

...出来たとしても、
ルーチンワークを抱え続けると、
その後の結果が出なくなって続かない。

ポイント
- 基幹的事業にならないと生産性向上の投資が予算化出来ない。
- ただし、シェアが大き過ぎるものを対象にすると、
  内容を絞れず汎化させ過ぎてアーキテクチャ宇宙飛行士化する。

トレンドを追うモノ †

トレンドだけで終わるモノ。 †

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

ただし、トレンドを追うモノは結果が出ず続かない傾向がある。
- キャズム超えない。
- 基幹的事業にならない。

キャズム超えの後、基幹的事業になるモノ。 †

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

施策「開発」の定常業務化（ドキュメント、プロダクト、テンプレート
施策「実施」の定常業務化（フェーズゲート、チェック、検査

この理由は、
- キャズム超えの後、基幹的事業になる可能性が高い時点であるため。
- そして、基幹的事業にならないと生産性向上の投資が予算化出来ない。

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

いずれも、定常業務化される予定のモノはロングランする。

テクノロジ系 †

テクノロジ系は、

トレンドを追うモノが多く長続きしない。

ロングランするモノは、
- テンプレ、パッケージ、Wikiなどに持ち込む必要がある。
- この状態で、漸くトレンド非依存のベネフィットが創出されている状態になる。

プロセス系 †

プロセス系は、

実地に適用される規格系は問題無いが、
先進的な方法論はアーキテクチャ宇宙飛行士的な様相を呈する。
実際に運用される方法論は規格化されロングランする。

プロフィット系とノンプロフィット系 †

プロフィット系 †

プロフィットで運営出来るケースは、

研究開発施策で後に事業に引き渡す。
生産技術施策で予算化する必要はない。

ノンプロフィット系 †

ノンプロフィットでしか運営出来ないもの。

通常の事業で
- 溜まらないノウハウ
- 資産化されないノウハウ、プロダクト

参考 †