彼らは「言われたもの」を“実装”する。私たちは「勝てる事業」を“設計”する。
なぜ、巨額の予算を投じた「システム刷新（技術）」は、「変革（DX）」に繋がらないのか。それは、クライアントの「戦略（事業）」や「顧客体験（デザイン）」から**バラバラな状態（分断）**になった「要件定義書（技術）」を、システム構築会社（SIer）が「忠実に」実装しているからです。本稿では、「SIer依存」が「戦略・体験・技術の分断」をいかに“加速”させるかを論証します。
執筆者： 日本オープンイノベーション協会（JOIA） / GREATS編集部
目次
1. はじめに：「システム実装」≠「事業実現」
- 1-1. DXの“不都合な真実”：なぜ「システム刷新」は「変革」にならないのか
- 1-2. 「システム構築会社（SIer）」という“実装部隊”
- 1-3. 本稿の論点：「技術」と「戦略」の“構造的分断”
2. 「SIer（実装部隊）」の“構造的限界”：「戦略」からの「分断」
- 2-1. 彼らの「目標」は「事業実現」ではなく、「人月」と「納品」である
- 2-2. 「要件定義書」という「分断」の“設計図”
- 2-3. なぜ「要件定義書」通りに作ると「使われないシステム」が生まれるのか
3. 客観的証拠：競合（NTT DATA）が示す「戦略」と「実行」のギャップ
- 3-1. リサーチ分析：「91%」が「古いシステムの壁」に阻まれているという現実
- 3-2. リサーチ分析：戦略（経営層）と現場（技術部門）の「深刻な不一致」
- 3-3. 「SIer依存」モデルの“必然的”な失敗
4. GREATSの処方箋：「実装」の「前」に「統合」を“設計”する
- 4-1. 私たちは「要件定義書」を受け取らない。「問い」を再定義する
- 4-2. 事例（メガバンク）：「古いシステム前提」で「事業実現」を設計する
- 4-3. 事例（電力会社）：「技術PoC」を「SaaS事業」に“再設計”する
5. 結論：GREATSは「実装部隊」ではなく、「統合」を担う「設計者（アーキテクト）」である
記事本文
1. はじめに：「システム実装」≠「事業実現」
1-1. DXの“不都合な真実”：なぜ「システム刷新」は「変革」にならないのか
前回の記事では、「戦略コンサルタント」の「戦略」が、いかに「実行」から分断され、「絵に描いた餅」に終わるかを論証しました。
では、その「実行」を担う巨大なプレイヤー、すなわち「システム構築会社（SIer）」はどうでしょうか。
日本のDXプロジェクトにおいて、最も巨額の予算が投じられるのは、多くの場合、大手システム構築会社です。彼らは「古いシステム（レガシー）刷新」や「DX基盤構築」を担う、「実装」のプロフェッショナルです。
しかし、彼らが「納品」した「新システム」は、果たして「変革（DX）」、すなわち「新しい事業価値（事業実現）」を生み出しているでしょうか。残念ながら、その多くは、「古いシステム」が「新しいシステム」に入れ替わっただけの、「コスト（刷新）」に終わっていないでしょうか。
なぜ、「システム実装」は、自動的に「事業実現」へと繋がらないのでしょうか。
1-2. 「システム構築会社（SIer）」という“実装部隊”
その理由は、システム構築会社というビジネスモデルの「構造」そのものにあります。
彼らは、クライアントの「戦略（事業）」を設計する「設計者（アーキテクト）」ではありません。彼らは、クライアントから提示された「要件」に基づき、システムを「構築」する**「実装部隊」**です。
彼らの「知恵」は、「戦略（ビジネス）」や「顧客体験（デザイン）」ではなく、「技術（テクノロジー）」の「実装力（マンパワー）」に最適化されているのです。
1-3. 本稿の論点：「技術」と「戦略」の“構造的分断”
本稿は、この「システム構築会社（実装部隊）」の「構造的な限界」に焦点を当てます。「システム実装」のプロである彼らは、その「専門性」ゆえに、
- 「経営戦略（ビジネス）」から**「分断」**され、
- 「顧客体験（デザイン）」から**「分断」**されている。
本稿では、「SIer依存」が分断をいかに“加速”させるか、そのメカニズム（＝要件定義書の罠）を解明します。
2. 「SIer（実装部隊）」の“構造的限界”：「戦略」からの「分断」
2-1. 彼らの「目標」は「事業実現」ではなく、「人月」と「納品」である
システム構築会社のビジネスモデルの根幹は、「人月」、すなわち「何人のエンジニアが、何ヶ月働いたか」で売上（フィー）が決定される「請負契約」です。
これは、彼らの「目標（KPI）」が、「クライアントの事業が『事業実現』されたか（＝成果）」ではなく、「『要件定義書』通りのシステムを『期日通り』に『納品』**できたか（＝作業完了）」であることを意味します。
彼らの「知恵」は、「成果（事業実現）」を最大化するためではなく、「作業（マンパワー）」を「効率的」に「管理」するために最適化されているのです。
2-2. 「要件定義書」という「分断」の“設計図”
この「請負（人月）」モデルにおいて、クライアントとシステム構築会社を繋ぐのが、「要件定義書」です。しかし、この「要件定義書」こそが、**「分断」の“設計図”**そのものです。
私たちがDX戦略に関する記事で論じた通り、クライアントの多くは、「戦略（事業）」を「技術」に「翻訳」する「設計力」を社内に持っていません。その分断されたクライアントが作成する「要件定義書」は、必然的に分断されています。
「戦略（ビジネス）」部門の「理想」と、「技術（テクノロジー）」部門の「制約」などが「統合」されていない「矛盾（分断）」を孕んだまま、「要件定義書」は作られます。
2-3. なぜ「要件定義書」通りに作ると「使われないシステム」が生まれるのか
「実装部隊」であるシステム構築会社は、この分断された「要件定義書」を「正」として受け取り、「忠実に（契約通りに）」システムを「実装」します。
その結果、何が起きるか。私たちが「高機能・低UX」に関する記事で論じた「悲劇」です。
- 「戦略」と「技術」の分断：「戦略（ビジネス）」の「あるべき論」と、「技術」の「現実（古いシステム）」が分断されたまま実装され、「絵に描いた餅」が生まれる。
- 「体験」と「技術」の分断：「顧客体験（デザイン）」の視点が欠如した「要件定義書」に基づき、「技術」の論理だけで実装され、「高機能だが使われない」システムが生まれる。
システム構築会社は「契約違反」を犯していません。彼らは「分断された設計図」通りに「実装」しただけです。「SIer依存」とは、分断を解決するどころか、自社の分断を「システム」として「固定化・加速」させてしまう、極めて危険なアプローチなのです。
3. 客観的証拠：競合（NTT DATA）が示す「戦略」と「実行」のギャップ
この「戦略」と「技術（実行）」の「分断」は、システム構築業界の巨人であるNTT DATA自身が「客観的データ」として提示しています。
3-1. リサーチ分析：「91%」が「古いシステムの壁」に阻まれているという現実
NTT DATAが行った調査は、「91%」の企業が、「**古いシステム（レガシー）**が、新しい技術（AIなど）の活用能力に重大な影響を与えている」と回答している事実を示しています。
これは、「技術（古いシステム）」が、新しい「戦略（AI活用）」の“足枷”となっている、典型的な「技術と戦略の分断」の“証拠”です。
3-2. リサーチ分析：戦略（経営層）と現場（技術部門）の「深刻な不一致」
さらに、NTT DATAの別の大規模調査は、「戦略（経営層）」と「実行（現場・技術）」の分断を明らかにしています。
- 戦略（CEO）は楽観的：CEOの67%がAIに「重大なコミットメント」を計画。
- 実行（技術部門）は懐疑的：一方で、技術責任者の45%が、AI導入に「ネガティブな感情」を抱いている。
- 分断の理由：技術責任者の54%が「内部のルールや仕組み（＝ガバナンス）が不明確」であると回答しているにもかかわらず、CEOで同様の懸念を持つのはわずか20%でした。
これは、NTT DATA自身のリサーチが、経営層（戦略）と現場（技術・組織）の間に「深刻なギャップ」と「不一致」が存在することを立証した、決定的な「証拠」です。
3-3. 「SIer依存」モデルの“必然的”な失敗
これらのデータは、「システム構築会社（実装部隊）」が直面する「構造的な限界」を示しています。
彼らは、「分断」されたクライアント（＝戦略と現場の「不一致」）から、「分断」された「要件定義書」を受け取り、「分断」された（＝古いシステムの壁を前提とした）「実装」を行わなければならない。このモデルでは、変革（DX）が失敗し、「事業実現」に至らないのは“必然”なのです。
4. GREATSの処方箋：「実装」の「前」に「統合」を“設計”する
4-1. 私たちは「要件定義書」を受け取らない。「問い」を再定義する
GREATSは、この「SIer依存」モデルとは対極にあります。私たちは「実装部隊」ではありません。「事業実現の設計者（アーキテクト）」です。
私たちは、クライアントから分断された「要件定義書」を「受け取らない」。私たちは、その「要件定義書」の「前提」となった「問い」そのものを「再定義」します。
「どのシステムを刷新（技術）しますか？」という「実装部隊の問い」ではなく、「あなたの会社の『経営戦略』と『顧客体験』を阻害している『技術的な“分断”』はどこですか？」という「設計者の問い」を立てるのです。
4-2. 事例（メガバンク）：「古いシステム前提」で「事業実現」を設計する
「メガバンク」の事例は、この「設計者」の仕事を象徴しています。
- 実装部隊の「解」：「古いシステム（技術）」を「刷新（実装）」するために「5カ年計画」を提案した（＝「分断」された「技術」の解）。
- GREATSの「解」：「古いシステムは“前提”として、どう“最速で”『パーソナライズ戦略（戦略）』を『事業実現』するか？」という問いに再定義しました。そして、「二つの仕組みの共存（組織設計）」と、「外部（FinTech）との連携（技術統合）」という「事業実現の設計図」を描いたのです。
私たちは「実装」したのではありません。「事業実現」の「設計（アーキテクチャ）」を「設計」したのです。
4-3. 事例（電力会社）：「技術PoC」を「SaaS事業」に“再設計”する
「大手電力会社」の事例も同様です。
- 実装部隊の「解」：「AI（技術）で何ができるか？」という「技術PoC（実証実験）」を回し続け、分断を加速させていました。
- GREATSの「解」：「AI（技術）」を「手段」とし、「SaaS事業（戦略）」という「第二の収益源」を「目的」として「再設計」しました。そして、「戦略（ビジネス）」と「体験（デザイン）」を「統合」した「事業実現の設計図」を描いたのです。
5. 結論：GREATSは「実装部隊」ではなく、「統合」を担う「設計者（アーキテクト）」である
「古いシステムの壁」は、「技術」の課題であると同時に、「戦略（事業）」と「組織（デザイン）」の分断の課題です。
**「システム構築会社（実装部隊）」**は、その「ビジネスモデル（請負・人月）」の「構造的な限界」により、「技術」のプロではあっても「戦略」と「体験」のプロではありません。
彼らに分断された「要件定義書」を渡すことは、分断そのものを「実装」し、固定化させる行為に他ならないのです。
**「GREATS（設計者）」**は、「実装」ではなく「設計」で勝負します。
私たちは、
- **「統合」された「手法（知恵）」**により、
- クライアントが「要件定義書」を書く“以前”の段階で、「戦略・体験・技術」を「統合」する「事業実現の設計図（アーキテクチャ）」を描きます。
あなたの会社に必要なのは、「要件定義書」通りに「実装」する「実装部隊」でしょうか？それとも、「事業実現」そのものを「設計」する「設計者」でしょうか？
GREATSは、後者のための「解」です。
コメント