システム開発をフルスクラッチで成功させるために──“ステークホルダー合意”なくして次工程へ進んではならない理由
“誰も反対していない”は合意ではない──フルスクラッチ開発の落とし穴
2025-12-16

システム開発は、単に機能を実装する作業ではなく、企業の業務そのものを再構築するプロジェクトです。特にフルスクラッチ開発では、現場担当者、管理部門、経営層、外部パートナーなど、関わるステークホルダーが多岐にわたり、それぞれが異なる期待や課題を抱えています。この認識の違いを整理し、合意を形成しないまま次工程に進むことは、後から重大な手戻りや追加コストを招く原因となります。
本コラムでは、「ステークホルダーの合意を得ないまま次工程に入らない」という原理原則を基に、なぜこの工程が重要なのか、どのように進めるべきか、そしてフルスクラッチ開発で成功する企業が実践しているポイントを解説します。
>>フルスクラッチ(オーダーメイド)のシステム開発について詳細はこちら
目次
【要約】IT化の原理原則[4]ステークホルダー間の合意なくして次工程へ進んではならない
システム開発では、関係者(ステークホルダー)が増え続けており、部門や利用者層ごとに異なる期待や要件が存在します。これらの意見を整理し、共通理解を得ないまま次の工程に進むと、後になって重大な要件漏れや認識の齟齬が発覚し、手戻りや追加費用の発生につながります。プロジェクト責任者は、関係者の役割・業務・課題を正確に把握し、必要な調整を行うことで、合意形成を確実に進めることが求められます。また、システム開発会社任せにせず、発注側自身が主体的に合意状況を確認する姿勢も重要です。ステークホルダーが誰かを明確にし、意見を適切に集約することで、プロジェクト全体の質と成功率を大きく向上させることができます。
出典:独立行政法人情報処理推進機構
『超上流から攻める IT化の原理原則 17ヶ条』原理原則[1]
『実務に活かす IT化の原理原則 17ヶ条』原理原則[1]
「IT化の原理原則17ヶ条」が教える、IT導入を成功へ導くための基礎知識
IPAが公開する「IT化の原理原則17ヶ条」は、企業がIT導入やシステム開発を円滑に進めるための基本的な考え方を整理した指針です。ユーザー企業とシステム開発会社の視点の違い、要件定義の重要性、コミュニケーション不足が招く問題など、実務で起こりやすい課題を原理的に示している点が特長です。また、開発プロセスにおける責任や役割の明確化、投資判断の妥当性、品質確保への姿勢など、プロジェクト成功に必要な視点を包括的に提示しています。これらの原理原則を理解することで、組織が主体的にIT化を推進し、失敗しにくい体制を整えることができるようになります。
出典:独立行政法人情報処理推進機構
『超上流から攻める IT化の原理原則 17ヶ条』原理原則[1]
『実務に活かす IT化の原理原則 17ヶ条』原理原則[1]
ポイントをひとことで
このコラムが示す核心は、システム開発において「誰が何を決めるのか」が曖昧なまま進むことが、技術的課題以上にプロジェクトを不安定化させるという点です。ステークホルダーが多い現代の開発では、目的の不一致や前提のズレが手戻りや追加仕様を生み、結果として大きなコストと時間の浪費につながります。重要なのは、全員の意見を単に集めることではなく、どの立場が何を判断すべきかを明確化し、合意を構造として作ることです。フルスクラッチ開発ほど、この“共通認識の設計力”が成功の鍵を握ります。
ステークホルダーが増えるほど、合意形成は難易度が上がる
現代のシステム開発は、多くの部署・役割が関わる複雑なプロジェクトになっています。
特にフルスクラッチ開発では、以下のようなステークホルダーが登場します。
- 現場の業務担当者
- 部門責任者
- 経営層
- 情報システム部門
- 外部パートナー
- システム開発会社
それぞれの視点や期待は異なり、時に相反します。
ある部署は「効率化」を最優先にしたい一方で、別の部署は「統制強化」を求めるなど、目的に矛盾があることも珍しくありません。
このような状況で合意形成を怠ると、次の工程で大きくつまずく原因になります。
合意が曖昧なまま進むと起こる問題
ステークホルダーの合意が取れないまま要件定義や設計に進むと、次のようなリスクが顕在化します。
要件の抜け漏れが発覚する
現場担当者が必要な業務フローを把握していないまま決裁が進むと、後から「実はこの処理が必要だった」という重大な抜け漏れが発生します。
各部門の前提が違うままプロジェクトが動く
部門ごとに目的が違う場合、立てた計画が成立しなくなり、工程が崩れます。
追加仕様が大量に生まれる
合意不十分な要件ほど、後から修正や追加が入り、プロジェクトの負荷が増大します。
誰の判断が正しいか分からなくなる
責任の所在が曖昧になり、意思決定が遅延し、進捗が止まります。
これらの問題は、技術的な課題ではなく“プロジェクト設計の欠陥”が原因です。
【関連記事】
要件定義が失敗する原因は?6つの失敗事例から学ぶ対策を解説
なぜ“ステークホルダーの合意”がここまで重要なのか
ステークホルダー間で目的が一致していないと、要件定義や設計は正しく成立しません。
システム開発の本質は、企業の仕組みを形にすることです。
つまり、企業としての合意がない状態では「何を作るべきか」が定まりません。
合意形成は、単に承認をもらう作業ではなく、次のような役割を果たします。
- 共通の目的を明確にする
- 方向性を揃える
- 要件の優先度を整理する
- プロジェクトの責任範囲を明確にする
合意があることで初めて、要件は“企業としての意思”として扱えるようになります。
ステークホルダーの役割と責任を明確にすることが重要
合意形成が難しい原因のひとつに、「誰が何を決めるのか」が曖昧であることが挙げられます。
成功する企業は、次のように役割と責任を整理しています。
- 現場:業務要件の提示
- 部門責任者:業務の最終判断
- 情シス:全体最適の観点で調整
- 経営層:投資判断
- システム開発会社:システム実現性の評価
これらを整理しないと、意見が錯綜し、プロジェクトは迷走します。
事前調整を怠ると“合意できない状態”が続く
実務では、次のような理由で合意が進まないことがあります。
- 部門間で利害が異なる
- 現場が十分に参加していない
- 情報共有が不足している
- ユースケースが整理されていない
- 承認プロセスが不透明
これらをクリアにしない限り、合意には至りません。
フルスクラッチ開発において合意形成が特に重要な理由
フルスクラッチの特徴は「正解が企業ごとに異なること」です。
そのため、以下の理由で合意の重要性がさらに高まります。
仕様の自由度が高い
自由に設計できるため、ユーザー側の判断が非常に多く求められます。
業務プロセスへの依存度が大きい
業務理解が浅いと誤った仕様が作られます。
影響範囲が広い
ひとつの要件変更が複数の機能に波及します。
つまり、合意の質がシステムの質を決めるといっても過言ではありません。
“誰の意見を聞くべきか”を明確にすることで合意は進む
ステークホルダーが多いほど、優先的に意見を集めるべき人物と、参考として扱うべき人物が存在します。
合意形成がうまくいく企業は、
- 意思決定者
- 実務担当者
- 運用責任者
を明確に分離し、それぞれに必要な情報を渡しています。
これにより、“全員の承認が必要”という非効率な状態を避けられます。
システム開発会社に任せきりではプロジェクトは前に進まない
システム開発会社はシステムのプロであり、技術的実現性を判断できます。しかし、業務の最終判断や優先度の決定は、ユーザー企業にしかできません。
合意形成は「システム開発会社に任せる」領域ではなく、ユーザー企業が主体的に取り組むべき領域です。
まとめ
ステークホルダーの合意を得ないまま次工程へ進むことは、プロジェクト全体を不安定にする大きなリスクです。要件の抜け漏れ、認識ズレ、追加仕様の連発、責任の曖昧化といった問題は、合意形成が不十分な状態で発生します。フルスクラッチ開発は自由度が高い分、判断の連続であり、企業として“何を目指すのか”の合意が不可欠です。ステークホルダーの役割を整理し、企業としての意思を明確にしたうえで工程を進めることが、プロジェクト成功の最も堅実なアプローチとなります。
ステークホルダーの合意形成は、プロジェクトの安定性と成果を左右する最も重要な基盤です。フレシット株式会社は、このプロセスを単なる確認作業ではなく「企業全体の意思を構築する工程」と捉え、関係者の意見を丁寧に整理し、合意を得られる形へと変換する伴走型の支援を得意としています。業務理解を踏まえた要件整理、意思決定しやすい情報設計、そしてステークホルダー間の認識を揃えるファシリテーション力を強みとし、フルスクラッチ開発に必要な“合意の質”を高める仕組みづくりをサポートします。貴社独自の業務や課題を正しく捉え、関係者全員が納得できる形で進めたいとお考えでしたら、ぜひフレシット株式会社にご相談ください。プロジェクトを成功へ導くために、確かな技術と高い伴走力で支援いたします。
>>フルスクラッチ(オーダーメイド)のシステム開発について詳細はこちら
著者プロフィール
フレシット株式会社 代表取締役 増田順一
柔軟な発想でシステム開発を通して、お客さまのビジネスを大きく前進させていくパートナー。さまざまな業界・業種・企業規模のお客さまの業務システムからWEBサービスまで、多岐にわたるシステムの開発を手がける。一からのシステム開発だけでは無く、炎上案件や引継ぎ案件の経験も豊富。システム開発の最後の砦、殿(しんがり)。システム開発の敗戦処理のエキスパート。

公式Xアカウントはこちら