こんにちは！株式会社雲海設計の技術部です。2026年6月現在、弊社の経営相談で急増しているのが「コンサルにグランドデザインを描いてもらったが、別の開発ベンダーに渡したら『この要件では作れない』と差し戻された」「上流と実装のベンダーが分かれていて責任の押し付け合いになっている」という情シス・経営企画層からのご相談です。IPAが2026年4月に公表した『DX動向2026』では、分離発注プロジェクトの54%が要件定義から実装フェーズへの引き継ぎで遅延または再見積もりが発生しており、コンサルと開発の分断が新たな経営課題として顕在化しています。
本記事では、コンサルティング システム開発というキーワードで検索する意思決定者向けに、コンサルと開発を一気通貫で提供する価値を、責任分界・費用構造・失敗回避の3軸で発注企業視点に整理します。技術詳細ではなく、「自社はコンサルと開発を分けるべきか、一気通貫で頼むべきか」の判断材料の提供がゴールです。
- コンサルティング システム開発は「戦略・要件・実装・運用を同一責任主体で提供する形態」であり、分離発注の引き継ぎロスを構造的に排除する
- 分離発注の失敗パターンの62%は「要件定義書の解釈差異」に起因 (IPA 2026年4月)
- 費用構造は(1)構想策定、(2)要件定義、(3)実装、(4)運用の4フェーズで総コストの内訳を可視化できる
- 一気通貫型のROIが最も出やすいのは「業務知見が必要かつスコープが流動的な基幹・業務システム」
- 選定の3軸は(1)上流の業界知見、(2)実装体制の内製比率、(3)運用引き渡し設計で意思決定可能
そもそもコンサルティング システム開発とは何か？
結論から言うと、コンサルティング システム開発とは「経営課題のヒアリングから業務要件定義、システム設計、開発、運用までを単一の責任主体が一気通貫で担う開発形態」を指します。従来主流だった「戦略コンサル → SIer → 運用ベンダー」という多段階分離発注に対する、統合型のアプローチです。
2025年から2026年にかけて顕在化した分断問題
2025年までは「上流はコンサル、実装はSIer」という役割分担が王道とされていました。しかし2026年に入り、生成AI・エージェント前提の業務設計が必要になり、上流と実装の境界が曖昧化。コンサルが描いた絵が実装段階で実現不能と判明する事例が急増しています。
Gartnerが2026年3月に公表したレポートでは、「2027年までにエンタープライズシステム開発の40%が、戦略から実装までを統合する単一ベンダーモデルへ移行する」と予測されています。背景には次の3点があります。
- AI前提の業務設計では、技術的実現可能性が要件定義段階で問われる
- アジャイル前提のため、要件凍結を前提とした分離発注が機能しない
- 運用フェーズの継続改善に上流知見が必要
「戦略と実装を分けることは、もはや贅沢ではなくリスクである。AI時代の業務設計は、設計と実装の対話的進化を前提にする」
— Gartner『Future of Enterprise IT Sourcing』2026年3月
関連して業務システムと基幹システムの違いを完全整理した記事でも、刷新判断における上流と実装の連動性を詳述しています。
分離発注と一気通貫型はどう違うのか？
結論として、最大の差分は「責任分界点が要件定義書か、業務成果か」です。分離発注では要件定義書が責任の境界線になりますが、一気通貫型では業務KPIや経営成果そのものが共通の責任対象になります。
2モデルの構造比較
| 観点 | 分離発注 (コンサル+SIer) | 一気通貫型 (コンサル開発統合) |
|---|---|---|
| 責任分界点 | 要件定義書 | 業務成果・KPI |
| 引き継ぎロス | 大 (再ヒアリング発生) | 小 (同一チーム継続) |
| 仕様変更耐性 | 低 (再見積もり頻発) | 高 (バックログ調整で吸収) |
| 初期コスト | 低めに見える | やや高め |
| 総コスト (運用含) | 結果的に1.3〜1.5倍に膨張しがち | 予算内に収まりやすい |
| 向くプロジェクト | 要件凍結可能な定型システム | 業務改革を伴うDX・新規事業 |
分離発注で起きる典型的な事故
IPAの2026年調査で報告された分離発注の失敗パターン上位は次の通りです。
- 要件定義書の解釈差異 (62%) — コンサルは抽象、SIerは具体を期待
- 非機能要件の抜け漏れ (48%) — 性能・運用・セキュリティが上流で詰まらない
- 業務知見の喪失 (41%) — 引き継ぎ後にヒアリングをやり直す
- 変更要望の宙吊り (37%) — どちらの責任か曖昧で塩漬け化
同様の構造的問題は受託開発とSESの違いを契約・指揮命令・成果責任で整理した記事でも触れています。契約形態の選択は、責任分界の前提条件として極めて重要です。
費用構造はどう読み解くべきか？
結論から言うと、コンサルティング システム開発の費用は「構想策定・要件定義・実装・運用」の4フェーズに分解して把握すべきです。総額だけを見ても判断はできません。
4フェーズの費用構造とレンジ
| フェーズ | 主な成果物 | 期間目安 | 費用比率 (総額に対し) |
|---|---|---|---|
| 構想策定 | 業務改革コンセプト、ROI試算 | 1〜2ヶ月 | 5〜10% |
| 要件定義 | 業務要件・機能要件・非機能要件 | 2〜4ヶ月 | 15〜20% |
| 実装 | 設計・開発・テスト・移行 | 6〜12ヶ月 | 50〜60% |
| 運用 | 保守・改善・教育 | 継続 | 年間で実装費の15〜25% |
分離発注で見落としがちな「隠れコスト」
初期見積もりに含まれず、後から発生する典型コストは以下です。
- 再ヒアリング工数: 実装ベンダーが業務を再学習するコスト (要件定義費の20〜40%相当)
- 仕様調整会議: コンサル・SIer・発注企業の三者会議が頻発
- 変更管理コスト: 要件変更時の再契約・追加見積もり
- 運用引き渡しロス: 開発知見が運用ベンダーに継承されない
これらを合算すると、分離発注は表面上の安さに反して総コストで1.3〜1.5倍になるケースが多く、特に業務改革型のプロジェクトでは差が顕著です。
一気通貫型を選ぶべきプロジェクトの3条件
結論として、一気通貫型が経済合理的になるのは次の3条件のいずれかを満たすケースです。
条件1: 業務改革を伴うDXプロジェクト
業務プロセス自体を再設計する場合、要件は実装と並行して進化します。要件凍結を前提とした分離発注は機能しません。
条件2: AI・エージェントを前提とした新システム
生成AIの業務組み込みは、技術的実現可能性とビジネス要件が密結合します。プロンプト設計・評価ハーネス・ガードレールの設計を、上流の業務要件と一体で詰める必要があります。詳細はハーネスエンジニアリングのガードレール設計記事を参照ください。
条件3: スコープが流動的な新規事業領域
市場の不確実性が高い新規事業では、要件の頻繁な見直しが前提となります。一気通貫型のアジャイル開発でないと、変更コストが累積していきます。
逆に、要件が完全に固まっている定型システム (会計・人事の置き換えなど)は分離発注の方が安く済むケースもあります。判断は次の4軸で行うと良いでしょう。
graph TD
A[プロジェクト特性] --> B{業務改革を伴う?}
B -->|Yes| C[一気通貫型推奨]
B -->|No| D{AI/エージェント活用?}
D -->|Yes| C
D -->|No| E{スコープ流動的?}
E -->|Yes| C
E -->|No| F[分離発注も選択肢]失敗回避のためのベンダー選定3軸
結論として、コンサルティング システム開発のベンダー選定は「上流の業界知見」「実装体制の内製比率」「運用引き渡し設計」の3軸で判断します。
軸1: 上流の業界知見
戦略コンサル出身者だけのファームは、業務の機微を理解しない傾向があります。該当業界での実装経験がある人材が要件定義に入っているかを確認すべきです。
軸2: 実装体制の内製比率
「コンサルです」と名乗りつつ実装を外注している場合、結局分離発注と同じ構造になります。自社エンジニアの比率が70%以上あるかを確認しましょう。
軸3: 運用引き渡し設計
開発完了後の運用設計を初期段階から組み込めるかは、長期コストを左右します。運用フェーズの体制図と教育計画を提案段階で出せるベンダーを選ぶべきです。
提案依頼書 (RFP) チェックリスト
| 確認項目 | NG例 | OK例 |
|---|---|---|
| 上流体制 | 戦略コンサルのみ | 業務SME + 技術アーキテクト |
| 実装体制 | 主要工程を外注 | 内製比率70%以上 |
| 契約形態 | 要件定義と実装で別契約 | マイルストーン分割の一括契約 |
| 変更管理 | 変更時は都度見積もり | 変更予算枠を初期計上 |
| 運用設計 | 納品後に別途検討 | 初期から運用体制図を提示 |
雲海設計の支援アプローチ
雲海設計では、業界知見を持つコンサルタントと自社内製エンジニアが同一チームで動く一気通貫モデルでご支援しています。構想策定から要件定義、設計・実装、運用までを単一責任で担い、責任分界の曖昧さによる手戻りを構造的に排除します。
特に2026年は、AI・エージェントを業務に組み込むDXプロジェクトの引き合いが急増しており、DXソリューションとITコンサルティングを組み合わせた提案を強化しています。Web・業務システムの実装はWeb開発・デザインサービスで内製対応します。
「コンサルと開発を分けるべきか迷っている」「既存ベンダーとの引き継ぎが上手くいかない」といったお悩みがあれば、お問い合わせフォームからお気軽にご相談ください。初回ヒアリングは無料で承っています。
よくある質問
Q. 一気通貫型は分離発注より本当に安いのですか？
A. 初期見積もりは一気通貫型の方が10〜20%高く見えることが多いですが、引き継ぎロスや変更管理コストを含めた総額では、業務改革型プロジェクトの場合分離発注が1.3〜1.5倍高くなる傾向があります (IPA 2026)。要件が完全凍結できる定型システムは分離発注も合理的です。
Q. コンサルファームと開発会社、どちらに頼むべきですか？
A. 業務改革やAI活用を含むプロジェクトであれば、「自社内製エンジニアを抱えるコンサル」または「上流コンサル機能を持つ開発会社」が望ましいです。戦略コンサルのみのファームや、実装専業SIerは、それぞれ反対側のフェーズで弱みが出ます。
Q. 既に分離発注で進めていますが、途中で一気通貫型に切り替えられますか？
A. 可能ですが、要件定義書の解釈差異を埋めるための「再ヒアリング期間 (通常1〜2ヶ月)」が必要です。運用フェーズ前であれば切り替えのROIは十分に出るケースが多いため、現状の遅延コストと比較して判断することをお勧めします。
Q. 要件定義だけコンサルに頼んで、実装は別社に出すのはダメですか？
A. 要件が完全に文書化可能で、業界知見が陳腐化しにくい領域 (会計・人事など) であれば成立します。一方、AI・新規事業・業務改革型のプロジェクトでは、要件と実装の対話的進化が前提となるため、分離はリスクが高くなります。
Q. ベンダー選定で最初に確認すべき1点は何ですか？
A. 「実装を自社内エンジニアでやるか、外注するか」です。コンサル肩書きでも実装を丸投げしている場合、結局分離発注と同じ構造になり、一気通貫型のメリットが消失します。提案書で内製比率と体制図を必ず確認してください。