技術調達の意思決定のための体系的な方法論。戦略的整合性のスコアリングから TCO モデリング、共通化分析、ベンダーリスク評価まで — 意見ではなくデータを必要とする企業のための完全なプレイブック。
ある欧州の産業グループは、18 か月かけて 3 つの事業部にまたがるカスタム PLM 統合プラットフォームを構築した。コストは 420 万ユーロ。2 年後、商用ソリューションであれば 3 事業部すべてを合計 80 万ユーロで提供できたことが判明した — しかしその時点で、3 つの別々のチームが共通化のない非互換のシステムを構築していた。本当のコストは 420 万ユーロではなかった。統合をほぼ不可能にした 2 年間の乖離だった。
この話は珍しいものではない。欧州の産業グループ各社のエンジニアリングリーダーとの対話では、同じ失敗パターンが繰り返し現れる。根本原因はほぼ常に技術ではない。体系的な意思決定プロセスの欠如であり — そして決定的に、誰かが 1 行のコードを書く前、あるいはベンダー契約に署名する前の共通化評価の欠如である。
各事業体が独立して構築する。中央のガバナンスもなく、共通化評価もない。同じ問題が 5 回、5 倍のコストで解決される。事業部の CTO は自律性を守り、グループ IT にはポートフォリオレベルの意思決定を強制する権限がない。その結果、複数年の移行なしには統合できない非互換のシステムが生まれる。
チームは 1 年目の構築コストと 1 年目のライセンス料を比較する。実際の TCO には 5 年分の保守、人材維持、インフラ、研修、機会費用が含まれる。構築コストは前倒しで発生し、目に見える。保守コストは分散し、チーム予算に隠れ、複利的に積み上がる。内製の選択肢は 1 年目には安く見え、5 年目には高くつく。
「ずっとそうしてきたから」という理由でコモディティが内製される。「ベンダーのデモが素晴らしく見えたから」という理由でコア差別化要素が外注される。フレームワークがなければ政治が勝つ。部屋で最も声の大きい人物が内製か購入かを決める — そしてそれは通常、その意思決定から最も得をする人物であり、最も失うものがある人物ではない。
すべての内製/購入の意思決定は、これら 6 つの次元にわたって評価されるべきである。以下のデフォルトの重みは、複数の事業体を持つエンタープライズの産業グループに適している — 重みは具体的な状況に合わせて調整すること。スタートアップは Time to Value を 30% で重みづけするかもしれない。防衛請負業者はリスクと依存性を 35% で重みづけするかもしれない。
重みの合計は 100 でなければならない。セクション 3、4、5、6 では、最も重みの高い 4 つの次元を深掘りする。
これを構築することは競争優位を生み出すか?それはあなたの差別化の中核か、それともベンダーがより上手にこなすコモディティか?エンジニアリング人材の機会費用を含む。
5 年間のフルロードのコスト比較:開発、保守、インフラ、人材、研修、ベンダー料金、統合、移行、そして隠れたコスト。
1 つのソリューションが複数の事業部、事業体、製品ラインを提供できるか?再利用スコアリング、ゴールデンパスの可能性、事業体横断の標準化機会。
ベンダーロックインのリスク、IP の所有権、サプライチェーンの依存性、キーパーソンリスク(内製)、技術の陳腐化、規制上のエクスポージャー。
各選択肢はどれだけ早く本番価値を提供するか?構築のスケジュール vs ベンダーの展開、統合の複雑さ、組織の準備状況。
構築し保守する人材があるか?採用のスケジュール、研修への投資、定着リスク、内製 vs 購入の文化的適合性。
flowchart TD
A([Start: Technology Need]) --> B[Strategic Assessment]
B --> B1[Alignment with core competency?]
B --> B2[Competitive differentiation?]
B --> B3[Commonalization across entities?]
B1 & B2 & B3 --> C[Initial Classification]
C --> C1{Core to strategy?}
C1 -- Yes --> D[Build Track]
C1 -- No --> E[Buy Track]
D --> D1[Internal capability assessment]
D --> D2[TCO modeling: 5-year build cost]
D --> D3[IP & talent retention plan]
E --> E1[Vendor market scan]
E --> E2[TCO modeling: 5-year buy cost]
E --> E3[Integration & migration plan]
D1 & D2 & D3 --> F{Build TCO < 1.5x Buy TCO?}
E1 & E2 & E3 --> F
F -- Build wins --> G[Build Governance Gate]
F -- Buy wins --> H[Vendor Selection Process]
F -- Unclear --> I[PoC / Pilot Both]
I --> F
G --> J([Build Approved])
H --> K([Vendor Selected])
style A fill:#1a1a2e,stroke:#7c3aed,color:#e2e8f0
style B fill:#1e293b,stroke:#6366f1,color:#e2e8f0
style B1 fill:#1e293b,stroke:#475569,color:#e2e8f0
style B2 fill:#1e293b,stroke:#475569,color:#e2e8f0
style B3 fill:#1e293b,stroke:#475569,color:#e2e8f0
style C fill:#1e293b,stroke:#6366f1,color:#e2e8f0
style C1 fill:#1e1b4b,stroke:#8b5cf6,color:#e2e8f0
style D fill:#1e293b,stroke:#8b5cf6,color:#e2e8f0
style D1 fill:#1e293b,stroke:#475569,color:#e2e8f0
style D2 fill:#1e293b,stroke:#475569,color:#e2e8f0
style D3 fill:#1e293b,stroke:#475569,color:#e2e8f0
style E fill:#1e293b,stroke:#3b82f6,color:#e2e8f0
style E1 fill:#1e293b,stroke:#475569,color:#e2e8f0
style E2 fill:#1e293b,stroke:#475569,color:#e2e8f0
style E3 fill:#1e293b,stroke:#475569,color:#e2e8f0
style F fill:#1e1b4b,stroke:#8b5cf6,color:#e2e8f0
style G fill:#1e293b,stroke:#22c55e,color:#e2e8f0
style H fill:#1e293b,stroke:#3b82f6,color:#e2e8f0
style I fill:#1e293b,stroke:#f59e0b,color:#e2e8f0
style J fill:#0d1f12,stroke:#22c55e,color:#e2e8f0
style K fill:#0d1f12,stroke:#22c55e,color:#e2e8f0デフォルトの重み:30%
戦略的整合性は、分析全体の方向性を決めるため、最も重要な単一の次元である。競争差別化の中核となる能力は、ほぼ常に構築すべきである。コモディティの能力は、ほぼ常に購入すべきである。難しいのは正しく分類することだ。
| 分類 | 定義 | デフォルトの行動 | 例 |
|---|---|---|---|
| コア差別化要素 | 競争優位を生み出す。顧客はこの能力ゆえにあなたを選ぶ。 | 内製 | 独自アルゴリズム、独自の製造プロセス、コア IP |
| 戦略的イネーブラー | 戦略実行に必要だが、あなたの事業に固有ではない。 | 内製または提携 | データプラットフォーム、MLOps パイプライン、カスタム統合 |
| 運用上の必需 | 確実に機能しなければならない。異なるやり方をしても競争優位はない。 | 購入 | ERP、メール、人事システム、標準的な MES |
| コモディティのユーティリティ | 標準化され、置き換え可能。市場が成熟したソリューションを提供する。 | 購入(SaaS) | クラウドホスティング、オフィスツール、プロジェクト管理 |
コモディティのツールを構築するエンジニアは、あなたのコア製品を構築していないエンジニアである。エンジニアリング人材の機会費用は、内製/購入の意思決定で最も過小評価される要因だ。
デフォルトの重み:25%
5 年間の TCO モデルは、10 万ユーロを超える技術投資の最低限である。ほとんどのチームは 1 年目のコストしかモデル化せず、それは体系的に内製の選択肢(初期コストが低く、保守が複利的に高い)を購入の選択肢(初期ライセンスが高く、年間コストが予測可能)より優遇する。
1 年目の構築コストは通常、5 年間合計の 40〜50% である。残りの 50〜60% は保守、人材、インフラである。
1 年目の購入コスト(ライセンス + 導入)は通常、5 年間合計の 50〜70% である。継続コストは内製より予測しやすい。
隠れたコストは通常、内製と購入の両 TCO モデルに 15〜30% を加える。バイアスを避けるため両方に含めること。
例:3 事業体、合計 200 ユーザー向けの Manufacturing Execution System。
| コスト区分 | 内製(5 年) | 購入(5 年) |
|---|---|---|
| 初期開発 / 導入 | 120 万ユーロ | 35 万ユーロ |
| 年間ライセンス / ホスティング | 18 万ユーロ | 40 万ユーロ |
| 保守と更新(5 年) | 90 万ユーロ | 15 万ユーロ |
| チーム(専任 FTE、5 年) | 150 万ユーロ | 30 万ユーロ |
| 研修とオンボーディング | 12 万ユーロ | 20 万ユーロ |
| 統合と移行 | 20 万ユーロ | 25 万ユーロ |
| セキュリティとコンプライアンス | 10 万ユーロ | 8 万ユーロ |
| 5 年間合計 | €4,200K | €1,730K |
この例では、構築は 5 年間で購入の 2.4 倍のコストがかかる。内製の選択肢が安く見えるのは 1 年目だけである(120 万ユーロ 対 導入 + 初年度ライセンスを含む 120 万ユーロ)。乖離は保守とチームのコストが複利的に積み上がる 2 年目に始まる。
デフォルトの重み:15%
共通化は、内製/購入の意思決定で最も見過ごされる次元であり — 複数事業体の組織にとって最も ROI が高い次元である。1 つではなく 4 つの事業体を提供するソリューションは、コストを 75% 削減するだけではない。統合の負債を解消し、知識共有を可能にし、将来の展開を加速するゴールデンパスを生み出す。
各基準を 0〜10 でスコアリングする。合計スコアが 35 を超える場合、共通化の可能性が高いことを示し、共有ソリューションへの投資を正当化する。20 未満の場合、事業体固有のソリューションが適切であることを示唆する。
| 基準 | スコア 0-3(低) | スコア 4-6(中) | スコア 7-10(高) |
|---|---|---|---|
| 事業体横断の適用可能性 | 1 事業体がこれを必要とする | 2〜3 事業体が類似のニーズを持つ | 4 以上の事業体が同一のコア要件を持つ |
| インターフェースの標準化 | 事業体ごとに完全に異なる UX | 類似のワークフロー、異なるデータモデル | 同じワークフロー、同じデータモデル、わずかな構成差 |
| データモデルの互換性 | 非互換のスキーマ、共有タクソノミーなし | 部分的な重複、努力すればマッピング可能 | 共有マスターデータ、共通タクソノミー、互換性のあるスキーマ |
| デプロイパターンの再利用 | 事業体ごとに異なるインフラ | 同じクラウド、異なる構成 | 全事業体を提供する単一のデプロイ(マルチテナント) |
| 保守の統合 | 別々のチーム、共有コードなし | 一部の共有ライブラリ、別々のデプロイ | 1 つのチームが全事業体向けの共有プラットフォームを保守 |
10 万ユーロを超える内製/購入の意思決定の前に、このチェックリストを完成させること。これは事業体横断の可視性を強制し、最もコストのかかる失敗パターン、すなわち同じものを複数回構築することを防ぐ。
私たちが協働してきたすべての複数事業体の組織で、事業体のリーダーは自分たちの要件が「完全に独自」だと主張する。実際には、機能要件の 70〜85% は事業体間で同一である。認識される独自性は通常、根本的なアーキテクチャではなく、パラメータ化できるビジネスルールにある。テストはこうだ:その違いをコード変更ではなく構成ファイルで記述できるなら、それは本当に独自ではない。事業体が別個のシステムを必要とするという主張を受け入れる前に、このテストを実行すること。
デフォルトの重み:15%
内製も購入もリスクを伴う。目標はリスクを排除することではない — それを定量化し、TCO モデルに織り込むことだ。20 万ユーロのベンダーロックイン撤退コストは管理可能である。キーパーソンの離職による 200 万ユーロの社内プラットフォーム再構築は管理不能である。
manufacturing execution system を評価する産業 OEM について、4 つの調達オプションを比較する計算例。各オプションを次元ごとに 1〜10 でスコアリングし、次元の重みを掛け、加重合計を求める。
| 次元 | 重み | 内製カスタム開発 | 購入(SaaS)クラウドベンダー | 購入(オンプレミス)ライセンスソフトウェア | 提携共同開発 |
|---|---|---|---|---|---|
| 戦略的整合性 | 30% | 9/10(27.0) | 4/10(12.0) | 5/10(15.0) | 7/10(21.0) |
| 総所有コスト | 25% | 4/10(10.0) | 8/10(20.0) | 6/10(15.0) | 7/10(17.5) |
| 共通化の可能性 | 15% | 6/10(9.0) | 8/10(12.0) | 7/10(10.5) | 9/10(13.5) |
| リスクと依存性 | 15% | 8/10(12.0) | 4/10(6.0) | 6/10(9.0) | 5/10(7.5) |
| Time to Value | 10% | 3/10(3.0) | 9/10(9.0) | 6/10(6.0) | 7/10(7.0) |
| 組織的能力 | 5% | 5/10(2.5) | 9/10(4.5) | 7/10(3.5) | 8/10(4.0) |
| 加重合計 | 100% | 63.5 | 63.5勝者 | 59.0 | 70.5 |
この例では、産業 OEM の manufacturing execution system では購入(SaaS)が勝つ。内製は戦略的整合性で最高(9/10)だが、TCO、Time to Value、組織的能力で負ける。MES は運用インフラであり、競争差別化要素ではない —「内製」の戦略的整合性の高いスコアは、客観的評価ではなくエンジニアリングチームの選好を反映している。
同点決着ルール: 2 つの選択肢が互いに 5 点以内なら、6 週間の並行パイロットを実施する。内製 vs 購入では、これは両方の TCO モデルを実データで検証するため、ベンダー PoC を構築スプリントと並行して行うことを意味する。
重要なチェック: スコアを受け入れる前に、グループ CTO、事業体の CTO、CFO に独立して重みとスコアを割り当ててもらう。ステークホルダーが異なれば勝者も異なる — なぜそうなるかについての対話は、最終的な数値よりも価値がある。
完全な 6 次元スコアリングを実行する前に、迅速な方向性の回答が必要な場合は、この意思決定ツリーを使う。最も重要な分岐の質問を捉え、推奨アプローチへ導く。その後、完全なスコアリングマトリクスが初期の方向性を検証し、洗練すべきである。
flowchart TD
A{Is this core to competitive advantage?} -- Yes --> B{Do we have the talent to build & maintain?}
A -- No --> C{Does a mature vendor solution exist?}
B -- Yes --> D{Can we build faster than buy+customize?}
B -- No --> E[Partner or Acqui-hire]
C -- Yes --> F{Can it serve multiple entities?}
C -- No --> G[Build with commonalization mandate]
D -- Yes --> H[Build In-House]
D -- No --> I[Buy & Customize]
F -- Yes --> J[Buy & Standardize]
F -- No --> K{Is customization >40% of solution?}
K -- Yes --> G
K -- No --> J
style A fill:#1e1b4b,stroke:#8b5cf6,color:#e2e8f0
style B fill:#1e1b4b,stroke:#7c3aed,color:#e2e8f0
style C fill:#1e1b4b,stroke:#6366f1,color:#e2e8f0
style D fill:#1e1b4b,stroke:#7c3aed,color:#e2e8f0
style E fill:#1e293b,stroke:#f59e0b,color:#e2e8f0
style F fill:#1e1b4b,stroke:#6366f1,color:#e2e8f0
style G fill:#1e293b,stroke:#8b5cf6,color:#e2e8f0
style H fill:#0d1f12,stroke:#22c55e,color:#e2e8f0
style I fill:#1e293b,stroke:#3b82f6,color:#e2e8f0
style J fill:#1e293b,stroke:#3b82f6,color:#e2e8f0
style K fill:#1e1b4b,stroke:#6366f1,color:#e2e8f0これらは、うまくいかない技術調達の意思決定で私たちが見る再発パターンである。重大なアンチパターンは、ガバナンスの変更を要する組織的失敗である。高のアンチパターンは、フレームワークが防げる分析的失敗である。中のアンチパターンは、認識によって緩和できる認知バイアスである。
| # | アンチパターン | 深刻度 | 何が起こるか |
|---|---|---|---|
| 1 | Not-Invented-Here 症候群 | 重大 | 市場の代替案を評価せずに「自社の事業を最もよく知っている」という理由で構築すること。エンジニアリングチームは、それが自分たちのすることだという理由で、既定で構築に傾く。体系的な評価ゲートがなければ、内製の選択肢は分析ではなく惰性で勝つ。 |
| 2 | デモの罠 | 高 | ドメイン固有の PoC なしに、洗練されたベンダーデモに基づいて購入を選ぶこと。ベンダーは最良ケースの性能を見せるデモシナリオに多額を投資する。あなたの本番ワークロード、データ品質、統合要件は、デモが隠す問題を表面化させる。 |
| 3 | 事業部の封土 | 重大 | 各事業体がポートフォリオ横断の可視性なしに独立した内製/購入の意思決定を行う。中央の技術投資委員会がなければ、同じ問題が 5 回、5 倍のコストで解決される。意思決定がサイロ化していると、共通化の機会は見えない。 |
| 4 | TCO 健忘症 | 高 | 構築コスト(1 年目のみ)をベンダーライセンス(年間)と比較し — 5 年間合計を無視すること。構築コストは前倒しだが、保守、人材維持、インフラは年々複利で積み上がる。公正な比較には最低 5 年間のフルロードモデルが必要である。 |
| 5 | サンクコストの誤謬 | 高 | 「すでに 200 万ユーロ投資した」という理由で、将来は購入の方が安いのに構築を続けること。過去の支出は将来志向の意思決定とは無関係である。問いはこうだ:今日から 3 年後に機能するソリューションへ至る最も安い経路は何か? |
| 6 | ロックインのパニック | 中 | 構築コストが 5 倍高くても、ロックインの恐れからすべてのベンダーソリューションを避けること。ロックインのリスクは現実だが定量化できる。20 万ユーロの撤退コストは管理可能だが、それを避けるための 200 万ユーロの構築プレミアムは管理不能である。ロックインのリスクに値段をつけ、二者択一として扱わないこと。 |
| 7 | イノベーション劇場 | 中 | 標準ツールの方が速く提供できるのに、革新的に見せるためにカスタムソリューションを構築すること。リーダーシップは、退屈だが効果的なベンダー実装よりも、目に見えるエンジニアリングの労力を報いる。その結果、3 倍のコストがかかり 6 か月遅れて納品される過剰設計の社内ツールが生まれる。 |
| 8 | プラットフォーム楽観論 | 高 | 事業体横断の要件を検証せずに「みんなを提供するプラットフォームを構築する」こと。全事業部を同時に提供しようとする社内プラットフォームプロジェクトは 70% の確率で失敗する。2 事業体から始め、価値を証明し、それから拡大すること。 |
| 9 | スキルの蜃気楼 | 中 | 長期的な人材ニーズを評価せずに、現在のチームが構築し保守できると仮定すること。構築は 1 年のプロジェクトである。保守は 10 年のコミットメントである。v1 を構築できるチームでも、システムを保守・発展させる人材を維持できないことが多い。 |
| 10 | ガバナンスの空白 | 重大 | 正式な意思決定権がなく、共通化ゲートもなく、最も大声で叫ぶ者によって意思決定が下される。Technology Investment Board と定義された閾値がなければ、技術調達の意思決定は分析的ではなく政治的になる。これが他の 9 つのアンチパターンの根本原因である。 |
ガバナンスの変更を要する組織的失敗。より優れたスプレッドシートでは解決できない。
体系的なフレームワークが防ぐ分析的失敗。6 次元モデルがこれらを排除する。
認識によって緩和できる認知バイアス。研修と意思決定チェックリストが発生を減らす。
ガバナンスのないフレームワークは提案にすぎない。執行のないガバナンスは劇場だ。420 万ユーロの乖離パターンを回避する組織には、4 つのものが備わっている:Technology Investment Board、必須の共通化評価、支出閾値での意思決定ゲート、そして年次ポートフォリオレビュー。
| 投資規模 | 意思決定権限 | 必要な成果物 | レビュープロセス |
|---|---|---|---|
| < 10 万ユーロ | 事業部 CTO | 共通化チェックリスト(自己認証) | ポートフォリオトラッカーに記録 |
| 10 万 〜 50 万ユーロ | 事業部 CTO + グループアーキテクチャレビュー | 完全な共通化評価 + TCO モデル(3 年) | アーキテクチャ委員会の承認が必要 |
| 50 万 〜 100 万ユーロ | Technology Investment Board | 6 次元スコアリング + ベンダーショートリスト + PoC 計画 | 事業体横断の代表者による TIB 投票 |
| > 100 万ユーロ | Technology Investment Board + CFO | 完全なビジネスケース + 5 年 TCO + リスク評価 + 撤退計画 | 四半期の進捗ゲートを伴う取締役会レベルの承認 |
いかなる内製の意思決定も承認される前に、要求元の事業体は共通化評価を完成させ提出しなければならない。これは単一で最も効果的なガバナンス管理である。
年に 1 回、TIB はすべての主要な技術投資をレビューし、新たな統合機会を特定する。市場は変化し、事業体は進化し、新たな共通化の道筋が現れる。
6 か月のプロセス • 5 事業体を評価 • 4 つを単一プラットフォームに統合
5 つの事業体を持つ欧州の産業 OEM は、そのうち 4 つが同じ manufacturing execution のワークフローに対して独立して異なるソリューションを構築または購入していたことを発見した。総支出:グループ全体で 680 万ユーロ。必須の共通化評価を伴う体系的な内製/購入フレームワークを導入した後、4 事業体を提供する単一プラットフォームに統合し、年間 IT 支出を 120 万ユーロ削減し、統合保守を 12 FTE から 4 に削減した。
統合プラットフォームは 6 か月以内に 2 事業体で、12 か月以内に 4 事業体すべてで稼働した。5 番目の事業体は本当に独自のワークフロー(共通化評価で 18/50)を持ち、既存ソリューションに正しく残された。重要な洞察:フレームワークは標準化を強制しなかった — どこで標準化が正当化され、どこでされないかを明らかにした。
このプロジェクト中に設立された Technology Investment Board は、運用初年度に 3 件の追加の重複技術購入を防いだ。ガバナンスの変更だけによる初年度の総節約額:180 万ユーロ(統合による節約 + 防いだ重複)。
重要な教訓: 共通化評価が決定的要因だった。それがなければ、スコアリングマトリクスは各事業体に対して個別に異なる回答を生み出していただろう。事業体横断の視点は、意思決定を「1 つのために構築」から「全員のために購入」へと変えた — 根本的に異なり、根本的により良い成果である。
意思決定は始まりであって終わりではない。技術投資は能動的なモニタリングなしには劣化する。最良の成果を得るチームは、製品メトリクスに適用するのと同じ厳格さで、TCO の乖離、採用率、共通化スコアを追跡する。
| メトリクス | 目標 | 測定 | エスカレーションのトリガー |
|---|---|---|---|
| TCO の乖離 | 承認モデルの 15% 以内 | 四半期ごとの実績 vs 予測コスト比較 | 乖離が 2 四半期連続で 20% を超えたらレビュー |
| 採用率 | 12 か月以内に対象事業体の 80% 以上 | 事業体レベルのデプロイ追跡とアクティブユーザー数 | 6 か月後に採用が 50% 未満で停滞したらエスカレーション |
| 共通化スコア | 事業体間で共有コンポーネント 70% 以上 | 共有 vs 事業体固有のモジュール/構成の比率 | カスタマイズがコードベースの 40% を超えたらアーキテクチャレビュー |
| ベンダー SLA の遵守 | 稼働率 99.5% 以上、契約どおりの応答時間 | 自動モニタリングを伴う月次ベンダースコアカード | 四半期内に重大な SLA を 1 つでも逃したら正式なベンダーレビュー |
| 構築品質(構築した場合) | 四半期あたり P1 インシデント 5 件未満 | インシデント追跡、平均解決時間、デプロイ頻度 | インシデントが業界ベンチマークの 3 倍を超えたら内製の意思決定をレビュー |
| 年次ポートフォリオレビュー | 12 か月ごとに実施 | すべての主要な技術投資を現在の市場に対して再スコアリング | 新たな共通化機会が見つかったら統合レビューを開始 |
これらのシグナルは、当初の意思決定を見直す必要があるかもしれないことを示す。危機を待ってはならない — サンクコストの誤謬は、良い軌道修正の敵である。
モニタリングが当初の意思決定はもはや最適でないことを明らかにした場合、このプロトコルに従う。目標は責任を割り当てることではない — 将来志向のコストを最小化することだ。サンクコストは無関係である。