Skip to content

DNET_DataAnalysisPolicy

Jump to bottom
nishi_74322014 edited this page Sep 11, 2026 · 1 revision

データ分析例 - 施策の傾向

概要

データから、生産技術系の施策の傾向等を分析する。

詳細

施策の分類と実績の分析

分類

Wiki系

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

  • 課題と対策

    • 課題

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

    • 対策

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

テンプレ系

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

  • 課題と対策

    • 課題

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

    • 対策

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

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

パッケージ系

  • 特徴
    ≒ フレームワーク、ライブラリ系の意味。

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

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

UIサブシステム系

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

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

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

    • 鉄板UIサブシステムが引き続き鉄板のまま。
      Windows 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
        ・アジャイル、スタートアップ

最新技術系

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

Buzz系

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

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

実績

Wiki系（実績）

  • 特徴

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

  • データ

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

テンプレ系（実績）

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

  • データ

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

    • 類似施策数は減少傾向

      • 組織内で公知のモノは１・２程度
      • 弊部会は組織外で公知のものを運営（９リポジトリ）

パッケージ系（実績）

  • 特徴
    テンプレ系（実績）と同じ。

  • データ

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

    • 類似施策数は減少傾向

      • 組織内で公知のモノは１・２程度
      • 弊部会は組織外で公知のものを運営（１リポジトリ、７パッケージ）

UIサブシステム系（実績）

  • サマリ
    内容的にはWikiやテンプレのレベル。

    • 主流 30%（主流は枯れる ≒ サポート不要）
    • 傍流 40%（傍流では成果が減る）
    • discon 30%（ダメージ大）

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

    • 主流
      4 / 14件 ≒ 30%

      • Windows 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系（実績）

傾向まとめ

実績から

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

製造系

  • ロング・ランの条件

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

  • プログラム系は（色んな意味で）難しくなっている。

    • 「テンプレ、パッケージ」、「UIサブシステム、ORM」などがあり、
    • サービス、パッケージ＆プロダクト（S、P＆P）との相性が悪い。

  • プログラム系からプラットフォーム系へシフト。

    • 情シ（ITサービス（スマホ、クラウド（XaaS（DX
    • IaCが強力だが、AdHocなのでテンプレート化が難しい。
    • サービス、パッケージ＆プロダクト（S、P＆P）との相性は悪くない

上流系

  • プロセス系

    • 規格化される方法論は実際の実地に適用され易く、ロング・ランする。

    • 先進的な方法論は実地に適用されないケースが多い。
      （アーキテクチャ宇宙飛行士的な様相を呈す。）

      • OOA、SOA、DDD
      • XML、K8s（Microservices）

    • 時勢としては、要件定義、新規事業の立ち上げ。

      • BABOK、PMBOK（7 th）
      • リーン・スタートアップ

  • マネジメント系
    技術マップとプログラム・マネジメントが重要に。

施策の特徴

ポイント

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

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

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

  • 基本は、Wiki、テンプレ、パッケージなどに持ち込み、
    トレンド非依存のベネフィットが創出されている状態にする。

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

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

定常業務化

定常業務（PMP：共通の該当節を参照）化

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

  • ...されるには、当該技術の、

    • キャズム・幻滅期（DXのポイントの該当節を参照）超えが前提で、

    • 基幹的事業の一部に組み込まれた後、

    • 施策プロジェクトの成果物を実地で運用

される必要がある。

  • 定常業務化の例
    • サポート（ドキュメント、wiki）の適用
    • プロダクト（テンプレート、パッケージ）の適用
    • ルール（フェーズゲート、チェック、検査）の適用

定型業務

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

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

DXのポイントの該当節を参照。

研開と生技

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

  • 研開は啓発期以前のリスクが高い状態で着手（黎明期 ～）
  • 生技は啓発期以後のリスクが下がった状態で着手（～ 生産性の安定期）

Buzz系はマーケティング

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

  • 例えば、RPAやローコードは、

    • 従来技術の寄せ集めで、研究のフェーズが無いので、幻滅期辺りから突然登場する。
    • そういう意味で、プロダクトのリマーケティング的な意味合いが強い様に思う。
    • ただし、ビッグデータが2012年の最大のバズワードだったことを考えると、
      研究開発 or マーケティングの境界は曖昧。

  • 担ぐ系はベンダのサポートを活用する
    （Eclipse、Visual Studio、Jupyter Notebookなどがセルフサポート）。

移行メモ（正誤）: 元ページの「Jupiter Notebook」は「Jupyter Notebook」の誤記と判断し修正した。

プログラム・マネジメント

プログラム・マネジメントを参照。

トレンドと基幹事業

キャズム・幻滅期（DXのポイントの該当節を参照）超えの後、
基幹的事業、定常業務化されるモノを選ぶ。

  • 研開と生技で着手時期が10年違うこともある。
  • リスクが高い程、予算化が容易で、
    リスクが低くなり生産性に言及する頃には予算が付き難くなっている。

移行メモ（正誤）: 元ページの「着手次期」は「着手時期」の誤変換と判断し修正した。

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

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

  • ただし、トレンドを追うモノは失敗の可能性も高い。

    • キャズム・幻滅期（DXのポイントの該当節を参照）超えない。
    • その後、基幹的事業にならない。
    • 施策のプロジェクトで失敗する。
    • 施策の成果物の運用で失敗する。

※ 予算は付き易いが失敗の可能性も高い。

基幹的事業になるモノ。

  • 逆説的に、予算の付き難いモノは、定常業務化してロングランする傾向がある。
  • この理由は、キャズム・幻滅期超えの後の、
    既に基幹的事業になる可能性が高い時点であるため。

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

同様に、基幹的事業、定常業務化されるモノを選ぶ。

テクノロジ系

テクノロジ系の実地へのアプローチは品質方面に寄せていくと良い。

プロセス系（アプローチ）

プロセス系の実地へのアプローチは標準・規格化が硬い。

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

事業で担ぐ製品についてはノンプロフィットでの生産性向上は不要。

プロフィット系

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

  • 研究開発の後に事業に引き渡す。
  • ベンダのサポートがあるのでノンプロフィットでサポートする必要はない。

ノンプロフィット系

ノンプロフィットでしか運営出来ないケース

  • 研究開発

  • 通常の事業で

    • 溜まらないノウハウ
    • 資産化されないプロダクト

参考

（元ページに記載なし）

Tags: 移行, データ分析, 生産技術, 施策, 開発基盤

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

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally