Skip to content

DNET_GoNoGoCaseDatabase

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

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

概要

テクノロジやエンジニアリング関連のベネフィット創出プロジェクト、プログラム、
（...ある意味、ソフトウェア生産技術、開発基盤開発プロジェクト）
の結果（過去情報）から、プロジェクト選定委員会
（プロジェクト選定委員会運営）で
活用可能な教訓をまとめる。

区分毎の事例

UIサブシステム関連

概要（UIサブシステム）

  • 過去事例を見てみると、
    セグメント、ターゲットにハマっているかが重要と言える。

  • また、昨今では、Webサービスなどで利用されることが≒トレンドに乗る条件と
    なっているため、IDEなどにロックインされていないことが重要になってきている。

事例（UIサブシステム）

  • VB6のフォームアプリケーション
    （その後の.NETのWindows Forms）

    • 非常に高い生産性で、エンプラで多用されている。
    • UIコントロールをD&D、ダブルクリック、コードの実装
      と非常に直感的な手順で、簡単に習得・実装できるのが当時ウケた。

  • Webアプリケーション（MPA → AJAX）

    • エンプラのWebアプリでは、コレがデファクト。

    • また、Webサービスのスタートアップなどでも
      コレの技術で開発されるケースは、まだまだ多い。

    • 方式

      • MVC
        柔軟な対応が可能なMVCが流行っている。

      • Web Forms（JSF）
        柔軟な対応が可能なMVCが流行ってはいるが、
        セグメント的にはハマる分野もまだまだ多い。

  • Webアプリケーション（SPA、(MV*) UIフレームワーク）

    • 「狭い帯域幅でもコンテンツにユーザがリーチできるように。」
      的な要件コンテキストで採用されるUI技術であると考える。

      • 故に、エンプラの生産性にリーチしないことがある。
      • しかし、ミドルウェアなどの管理画面には使用される。

    • スタートアップ後の成功したWebサービスなどで利用される。
      （如何にエンドユーザにリーチするか？的な要件のコンテキストで）

  • スマホ（ネイティブ）アプリ

    • 基本的にSPAと同じだが、
    • ネイティブなので、
      • 性能的に優れている。
      • ネイティブ・アクセス的に優れている。
      • スマホUX的に優れている。

参考（UIサブシステム）

データ・アクセス関連

概要（データ・アクセス）

  • 過去事例を見てみると、
    セグメント、ターゲットにハマっているかが重要と言える。

  • 色々なタイプのORMが出てきたが、結局は、要件に沿って使い分けている。

事例（データ・アクセス）

参考（データ・アクセス）

テスト技法ツール関連

概要（テスト技法ツール）

  • 過去事例を見てみると、
    セグメント、ターゲットにハマっているかが重要と言える。

  • テスト技法ツール関連は、プラクティスが重要なので、
    そのプラクティスが誕生したセグメント以外にはハマらない可能性がある。

事例（テスト技法ツール）

  • CI / CD

  • テスト自動化

    • TDD（テストコードを書く系）
    • UIオートメーション系

参考（テスト技法ツール）

プライベート・クラウド関連

概要（プライベート・クラウド）

  • SI事業者でアレコレ検討がされた。

  • ハイブリッド・クラウド・ポータルは上手く行かない。
    ハイブリッド・クラウドに投資できる企業が出現しないので。

  • 最終的に、メガ・クラウド謹製の垂直統合に落ち着く感じ。

    • Azure Stack
    • AWS Outposts

事例（プライベート・クラウド）

  • ハイブリッド・クラウド・ポータル的な。

    • ハイブリッド・クラウド・ポータル（組織内みたいな）
    • 一昔前、PrimeCloud Controllerという
      OSSがあった。

  • 担ぐ系

    • プラクラ

      • VMware vCenter Server
      • Microsoft System Center
      • Cloud Stackなど

    • PaaS

  • OSS系

参考（プライベート・クラウド）

アーキテクチャ関連

概要（アーキテクチャ）

  • 書籍レベルにまでなればいいが、組織内での取り組みは微妙。

  • デザインパターンなど空気的な存在になってようやく効果が出てくる。

  • マイナーな状態ではナカナカ効果が出てこない
    （テンプレートやIDEなどのサポートがない状態では難しい）。

事例（アーキテクチャ）

  • オブジェクト指向 分析/設計/プログラミング（OOA、OOD、OOP）
    OOD、OOP辺りは空気化してイイ感じになっている。OOAは普及しなかった感。

  • サービス指向（SOA）、マイクロサービス
    しかし、SOAやマイクロサービス系は、理論をこねくり回したわりに、
    Webメソッド実装できりゃーエエとかそのレベルになっている。

  • ドメイン駆動設計（DDD）→ クリーンアーキテクチャ
    DDDも≒クリーンアーキテクチャ位で落ち着くのが良いのかも知れない。

  • クラウド・アーキテクチャ

    • 主語がデカイのでは？オンプレをクラウドにもっていくなら変更は不要
    • ただし、要件次第で、以下のような対応が必要になるケースは多い。
      • クロスドメイン認証に対応
      • WebAPIやDBのリトライポリシー策定＆実装

参考（アーキテクチャ）

プロセス関連

マネジメント・プロセス

エンジニアリング・プロセス

  • 特に下流の開発方法論については、大きな変化は見られない。
  • 2001～2010あたりで（生産技術の該当節を参照）
    大方、Fixした感がある。

要件定義と適応型ライフサイクル

  • 要件に係る上流に関しては、近年重要性を増している。
  • そういう動きが、2010以降の生産技術
    （生産技術の該当節を参照）で見られる。

マーケティング や 組織的プロジェクト・マネジメント（OPM）

マーケティング、
PMP：共通 - 組織的プロジェクト・マネジメント（OPM）

事業戦略と組織戦略 に関しては、近年重要性を増している。

サプライサイド・デマンドサイド

捻じれ（サプライ/デマンド）

SIは、本質的にデマンドサイドだが、
以下のケースで、サプライサイド気質が残るケースがある。

  • もともと

    • 販社
    • SES、下請け企業

  • 現時点で、
    SES、下請け事業を含む。

能率主義

捻じれが起きているケースで、
ニーズが効率向上ではなく能率向上に終始するケースがある。

移行メモ（正誤）: 元ページの「終止するケース」は「終始するケース」の
誤変換と判断し修正した。

自前主義

捻じれが起きているケースで、
自前主義からの脱却が遅れるケースがある。

プロフィット・ベネフィット

捻じれ（プロフィット/ベネフィット）

SIは、プロフィット偏重の傾向がある。

  • 社歴が長い程、プロフィット偏重の傾向がある。

  • ベネフィット系のプログラムは
    プロフィット系のミッションからは創出されない。

  • ただし、世の中は、ベネフィットの重要性が増してきて来ている。

売上至上主義

  • プロフィット偏重の一例
  • 売上は重要だが、原因と対策に注力されていない。

労働集約型産業

  • プロフィット偏重の一例
  • 時間の切り売りを行うのは、
    • プロフィット偏重、ベネフィット軽視。
    • 能力的にベネフィット創出が出来ない。

, etc.

必要に応じて追記していく。

教訓登録簿

基本的にトレンドは無視できない。

以下のような話で、結局、トレンドは無視できない。

  • トレンドに乗ってない技術は、disconになってサポートが切れる。
  • ハイプ・サイクル（シェアの該当節を参照）によりトレンドが
    浸透に代わるなどすると、クラウド、スマホなど、
    デマンドサイドのニーズとしても増えてくる。

トレンドだからと言って成長していない事業に投資してもダメ

  • 例えば、垂直統合型のソフトウェア産業が斜陽化しているとする。

  • そんな中で、クラウド（プラットフォーム）が出てきて、
    焦って、垂直統合型スキームのまま投資しても勝てる訳が無い。

トレンド無視のニッチ系は事業と深い関連が必要、だがソレは短期的な話。

  • トレンドに乗っていない、ニッチである場合、

    • トレンドを無視して良いケースもある。
    • ただし、事業と深い関連が必要になる。

  • これは、つまり、

    • トレンド ≒ 外部要因（環境要因）であるが、
    • ニッチ ≒ 内部要因（自社事業要因）である

と言うことになる。

  • また、
    • ニッチは、短期的には重要である。
    • トレンドは、長期的に重要性を増して行く。

と言う傾向がある。

ベネフィット系は現場（プロフィット）のニーズ駆動だと失敗する。

  • ベネフィット系は現場のニーズ聞いて愚直にやって成功した事例は一つも無い。
  • 理由は、現場のミッションがプロフィットなので、
    ベネフィットに関する考察が浅いため。

ライフサイクルは早くなってきている（同時に注力ポイントでもある）。

ライフサイクルの変化

SoRだけでなく、SoEでのIT利用が進み、

  • 一応、技術は（基礎部分というより、応用部分が）、進歩していると言える。
  • その結果として、ランタイム系のライフサイクルは短くなっている。
  • 代表的な例が、Javaや.NET Coreの
    長期商用サポート(LTS : Long Term Support)の提供。

移行メモ（正誤）: 元ページの「Long Time Support」は
「Long Term Support」の誤記と判断し修正した。

注力ポイントの変化

  • 早いライフサイクルの中で、廃れない技術を見極め、
    ピックアップすることの重要性が高まっている。

    • ただし、SPA系のフレームワークの栄枯盛衰をみると、
      予測不可能と思われるケースも多い。
    • 事業的に、急いでいなければ、慌てず待つ。と言う選択肢を
      選択する事も重要になる。

  • 同時に、

エンジニアリング・プロセスなどの、
変化の乏しい分野は、相対的に注力ポイントではない。

と言える。

競争のレイヤは上がっていく（スタックは積み上がっていく）。

ハード → ソフト

  • ハード

    • オンプレ
    • 仮想化
    • クラウド

  • ソフト

    • OS → ミドル → 上モノ
    • IaaS → PaaS → SaaS

インフラ → フロントエンド

  • インフラ →（仮想化/クラウド）→ アプリ
  • バックエンド →（PaaS/SaaS）→ フロントエンド

参考（競争のレイヤ）

データ分析例

施策の傾向

マーケティング

, etc.（教訓登録簿）

必要に応じて追記していく。

教訓のサマリ

サマリすると、大枠で以下のように言える。

中長期でゲームチェンジやパラダイムシフトは起きる。

概要（ゲームチェンジ）

以下のような変化の積み重なりで当然、起きうる。

事例（ゲームチェンジ）

  • ソフトはハードのオマケ → ハードはソフトのオマケ。
  • 垂直統合事業 → オープン・アーキテクチャ → 垂直統合事業
  • プロダクト → OSS
  • オンプレ → クラウド

参考（ゲームチェンジ）

天地人が揃う、時勢を読む必要がある。

概要（天地人）

  • 色々、時勢を読む必要がある。

    • 少子・高齢化社会 → 生産年齢人口の減少

    • 国際競争力の低下（新興国が伸びた）

    • 終身雇用の崩壊

      • メンバシップ雇用による新50代問題の発生。
      • メンバシップ雇用からジョブ型雇用へ。

  • 天地人

    • 孟子の「公孫丑章句上」の中の一節「天時不如地利。地利不如人和」に由来

      • 天：天の時＝タイミング
      • 地：地の利＝おかれた環境
      • 人：人の輪＝人心の一致

    • 意味としては、

      • 「天＜地＜人」だが、人心の一致には天・地も必要な訳で、
      • 戦に勝つことや物事を成功させるには（天地人の）３条件が必要。

事例（天地人）

...

参考（天地人）

認知バイアスに注意する。

認知バイアスのパターン

いずれも 認知バイアスのパターンの該当節を参照。

成功に関する認知バイアス

失敗に関する認知バイアス

リスク対応を誤らせる認知バイアス

ミクロ・マクロ

ミクロではセグメント＆ターゲットが重要

ミクロな技術のフィッティングでは、その技術が、
適切にセグメンテーションされたターゲットにフィットするかどうかという話。

マクロではゲームチェンジやパラダイムシフトを考慮

マクロな事業戦略と組織戦略では、

  • ゲームチェンジやパラダイムシフトに備えた対応が必要になる。
  • 変化が起き無い分野は斜陽の分野であり、注力ポイントではない。

戦略性が低いと、Buzzに乗った予算認可やカタストロフィ芸になる。

論理的ではない未来予測にありがちなパターン。

Buzzに乗った予算認可

  • 自分ではあまり考えていないが、Buzzってるので、予算認可され易い。
  • 予算認可されたはいいが、あまり考えていないので結果が出ず苦しむことも。

カタストロフィ芸

戦略立案のため、適切な、組織的プロジェクト・マネジメント（OPM）を行う。

PMP：共通 - 組織的プロジェクト・マネジメント（OPM）

ポートフォリオ・マネジメント

PMP：共通 - OPM - ポートフォリオ・マネジメントでは、
経営戦略、組織戦略などが対象になる。

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

ベネフィット創出の対象は、プログラム
（PMP：共通 - OPM - プログラム・マネジメント）になる。

プロジェクト・マネジメント

PMP

参考

マイクロソフト系技術情報 Wiki > VS系コンテンツ

UI系

Subsystem & Framework

  • Windows Form vs WPF
  • ASP.NET Web Forms vs ASP.NET MVC
  • 従来型のWebアプリ vs SPA（Single-page Application）
  • 様々なSPAフレームワーク
  • ネイティブ vs ハイブリッド

開発ツール

  • IDE vs RAD vs EUC vs Template & Package (開発支援ツールの種類)
  • ADO.NET vs ORM (Entity Framework, Dapper)
  • SVN vs Git vs TFS

その他（VS系コンテンツ）

  • ASP.NET Forms認証 vs ASP.NET Identity

OSSコンソーシアム > 開発基盤部会 Blog

生産技術界隈でBuzzったケド、ダメだった...

カタストロフィ的芸風について考える。

UIサブシステム関連（Blog）

データ・アクセス関連（Blog）

テスト技法ツール関連（Blog）

→ , etc.（CI/CDの該当節を参照）

プライベート・クラウド関連（Blog）

→ , etc.（PMP：PDU - コンピテンシーの該当節を参照）

アーキテクチャ関連（Blog）

ゲームチェンジやパラダイムシフト

時勢を読む

Tags: 移行, 生産技術, 事例, 教訓, プロジェクト選定, 開発基盤

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

NetDevInfraWiki

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

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally