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

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

• バックアップ一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• データ分析例 - 施策の傾向 へ行く。
  • 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系 †

• 特徴
  雑でも役立つ。初歩の初歩。

• 課題と対策

• 課題
  • 潜在的な需要は多いが、施策としてオーソライズされ難い。
  • どうやって人目に付く所に置くかが課題（Stack Overflow

• 対策
  • 予算が付かなくても継続される定常業務化すると良い。
  • 弊WikiやQiita等、組織外にリリースするのが良い。

テンプレ系 †

• 特徴 技術習得、QCD向上、信頼性向上などのベネフィットを創出。

• 課題と対策

• 課題
  • 潜在的な需要は多いが、施策としてオーソライズされ難い。
  • どうやって人目に付く所に置くかが課題（多様化で展開が困難
  • トレンド非依存のベネフィットを創出する事は結構難しい。

• 対策

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

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

パッケージ系 †

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

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

UIサブシステム系 †

• 変化のスピードが早い。

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

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

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

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

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

インフラ系 †

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

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

• プラットフォーム系
  

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

• 小分類

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

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

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

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

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

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

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

プロセス系 †

• 特徴

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

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

• 分類

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

• 方法論系

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

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

最新技術系 †

傾向が無いが故にプログラム・マネジメントが重要に。

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

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

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

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

Buzz系 †

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

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

実績 †

Wiki系 †

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

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

テンプレ系 †

• 特徴
  弊部会でOSS化した例

• データ

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

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

パッケージ系 †

• 特徴
  テンプレ系と同じ。

• データ

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

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

UIサブシステム系 †

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

• データ
  難しい割に、傍流・discon率が高い。

• 主流
  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、BABOK：◯
• 脆弱性診断
  • アプリ・インフラ脆弱性診断：◯
  • 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成分を含む。
  • UIサブシステム系
  • インフラ系
  • プロセス系
  • 最新技術系

傾向まとめ †

生産技術系の施策は、

• ポイント

• 技術の多様化によって、研究的な側面が増えてきた一方で、

• 振り返って、生産技術とはスマイルカーブ下部の研究と再認識する。

• 基幹的事業にならないと生産性向上の投資が予算化出来ない。

• 予算上の問題が出た場合、品質方面に遡及することによって活路を見いだせる可能性。
  （例えば、クラウドなら利用申請について、AIならAIの品質保証について。

• ただし、シェア、スコープ、ターゲット・セグメントが大き過ぎるものを対象にすると、
  内容を絞れず汎化させ過ぎてアーキテクチャ宇宙飛行士化する。

• 定常業務化

• ...がされるかどうか？が重要。

• ...されるには、

• キャズム・幻滅期超えが前提。

• そして、基幹的事業になること。

• ...されたとしても、
  

• それは実力ではないので評価はされない。

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

イノベーター、キャズム理論、ハイプ・サイクル †

研開と生技 †

最新技術の多くは潜在的技術革新後の研究開発から黎明期が始まり、
生き残ったものが、啓発期を経由し生産性の安定期に移行できる。

• 研開は啓発期以前のリスクが高い状態で着手
• 生技は啓発期以後のリスクが下がった状態で着手

Buzz系はマーケティング †

一方で、Buzz系はマーケティングから始まる印象。

• RPAやローコードは、プロダクトのマーケティング的な意味合いが強く、研究のフェーズが無いので、幻滅期辺りから突然登場する。
• ただし、ビッグデータが2012年の最大のバズワードだったことを考えると、研究開発 or マーケティングの境界は曖昧。
• プロダクトを使用するような場合は、自身で開発するというよりは、担ぐ系にシフトし、ベンダのサポートを活用する様になる。

トレンドと基幹事業 †

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

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

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

基幹的事業になるモノ。 †

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

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

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

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

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

テクノロジ系 †

テクノロジ系は、

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

• ロングランするモノは、
  • 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.067 sec.