データ分析例 - 施策の傾向 のバックアップ(No.13)

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

• バックアップ一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• データ分析例 - 施策の傾向 へ行く。
  • 1 (2022-07-19 (火) 10:44:16)
  • 2 (2022-07-19 (火) 13:42:05)
  • 3 (2022-07-19 (火) 16:40:58)
  • 4 (2022-07-19 (火) 18:40:54)
  • 5 (2022-07-19 (火) 22:41:35)
  • 6 (2022-07-20 (水) 13:29:27)
  • 7 (2022-08-09 (火) 12:51:41)
  • 8 (2022-08-09 (火) 17:53:21)
  • 9 (2022-08-10 (水) 10:35:11)
  • 10 (2022-08-10 (水) 16:50:32)
  • 11 (2022-08-22 (月) 14:39:37)
  • 12 (2022-08-25 (木) 13:10:17)
  • 13 (2022-08-26 (金) 16:27:17)
  • 14 (2022-09-08 (木) 16:35:34)
  • 15 (2022-09-20 (火) 11:06:34)
  • 16 (2022-12-15 (木) 12:12:06)
  • 17 (2022-12-15 (木) 16:58:35)
  • 18 (2022-12-15 (木) 19:41:33)
  • 19 (2022-12-15 (木) 21:59:57)
  • 20 (2022-12-16 (金) 00:46:04)
  • 21 (2022-12-17 (土) 03:06:01)
  • 22 (2023-01-23 (月) 16:05:08)
  • 23 (2023-01-23 (月) 18:42:59)
  • 24 (2023-01-24 (火) 03:01:43)
  • 25 (2023-01-24 (火) 12:01:50)
  • 26 (2023-01-24 (火) 16:16:30)
  • 27 (2023-01-24 (火) 20:46:12)
  • 28 (2023-01-25 (水) 00:59:15)

---

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

• 戻る

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

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

目次 †

概要 †

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

詳細 †

施策の分類と実績の分析

分類 †

Wiki系 †

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

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

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

テンプレ系 †

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

• 課題と対策（OSS化

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

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

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

パッケージ系 †

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

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

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

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

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など組織内サービス
  • 今後は組織外サービスが浸透していく予想。

プロセス系 †

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

• プロセス系

• 旧プロセス
  やることがないので予算が付かない
  • POA
  • DOA

• 新プロセス
  先行研究は予算が付く（ただし、圧倒的に成功しない）
  • 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は、情シ系の方が良い気がする。
（ただ、組織内にデータ分析のアクティビティが増えないとダメ）

プロセス系 †

• 規格系

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

• 新プロセス系

• OOA：☓ ┐
• SOA：☓ ├ 使える公の研究結果も少ない。
• TDD：☓ ┘
• DDD：☓（そもそも予算化されるレベルにない
• アジャイル：△ → ◯ PMBOK 7th（独自研究結果は無し
• UI/UXデザイン：△（公の研究結果のみ。独自研究結果は少ない。
• スタートアップ：△（書籍レベルを脱却していない印象がある。

最新技術系 †

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

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

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

• データ

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

• 粒度大きい
  
  • データサイエンス：◎

• DX：△（大き過ぎ
  ・IoT：○
  ・ビッグデータ：○
  ・BI / AI：○

• クラウド：△（大き過ぎ
  ・サービスA：○
  ・サービスB：○
  ・サービスC：○
  ・...

Buzz系 †

• テスト自動化
  • GUIテスト自動化
  • テスト自動生成

• RPA、ローコード / ノーコード

• 以下の施策中にもBuzz成分を含む。
  • UIサブシステム系
  • インフラ系
  • プロセス系
  • 最新技術系

傾向まとめ †

生産技術系の施策は、

• 定常業務化

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

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

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

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

トレンドを追うモノ †

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

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

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

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

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

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

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

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

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

テクノロジ系 †

テクノロジ系は、

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

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

プロセス系 †

プロセス系は、

• 先進的なモノはアーキテクチャ宇宙飛行士的な様相を呈する。
• ロングランするモノは、実際に運用されるプロセスであるため。

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

プロフィット系 †

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

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

ノンプロフィット系 †

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

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

参考 †

     

Site admin: TechInfoOfMicrosoftTech

PukiWiki 1.4.7 Copyright © 2001-2006 PukiWiki Developers Team. License is GPL.
Based on "PukiWiki" 1.3 by yu-ji. Powered by PHP 5.3.3. HTML convert time: 0.058 sec.