システム開発をフルスクラッチで成功させるために──“合意と承認”を軸にプロジェクトを成立させる方法

システムを新しく作りたいと思ったとき、最も重要でありながら見落とされやすいのが「取り決めの明確化」です。誰が何を承認し、どこからどこまでを合意とするのか。このルールが曖昧なままプロジェクトが進むと、仕様変更の認識違い、追加コストの発生、想定外の責任問題など、トラブルが連鎖的に生まれてしまいます。特にフルスクラッチ開発では、機能も仕様もゼロから作られるため、合意と承認のプロセスがプロジェクト全体の品質を左右します。

本コラムでは、IT化の原理原則［2］の考え方を基に、「合意」「承認」がなぜ重要なのか、そしてそれをどう実務に落とし込むべきかを、システム開発の現場経験とビジネス観点の双方から解説します。

＞＞フルスクラッチ（オーダーメイド）のシステム開発について詳細はこちら

【要約】IT化の原理原則［2］取り決めは合意と承認によって成立する

すべての取り決めは、誰がどのように承認するかという手続きを明確にし、双方が合意した内容として確認されることで初めて有効に機能します。合意内容が曖昧なまま進むと、後から解釈の相違や責任の所在が不明確になり、プロジェクトの混乱につながりやすくなります。重要な決定事項は文書化し、承認の主体や方法を明確にすることで認識のずれを防ぎます。また、専門用語や業界用語に偏らず、相手が理解しやすい表現で説明することも、健全な合意形成に不可欠です。発注者・受注者双方が共通のルールに基づき、透明性の高い意思決定を行うことが求められます。

参考：独立行政法人情報処理推進機構
『超上流から攻める IT化の原理原則17ヶ条』原則原理［2］
『実務に活かす IT化の原理原則17ヶ条』原則原理［2］

「IT化の原理原則17ヶ条」が教える、IT導入を成功へ導くための基礎知識

IPAが公開する「IT化の原理原則17ヶ条」は、企業がIT導入やシステム開発を円滑に進めるための基本的な考え方を整理した指針です。ユーザー企業とシステム開発会社の視点の違い、要件定義の重要性、コミュニケーション不足が招く問題など、実務で起こりやすい課題を原理的に示している点が特長です。また、開発プロセスにおける責任や役割の明確化、投資判断の妥当性、品質確保への姿勢など、プロジェクト成功に必要な視点を包括的に提示しています。これらの原理原則を理解することで、組織が主体的にIT化を推進し、失敗しにくい体制を整えることができるようになります。

参考：独立行政法人情報処理推進機構
『超上流から攻める IT化の原理原則17ヶ条』
『実務に活かす IT化の原理原則17ヶ条』

取り決めが曖昧なプロジェクトは、なぜ迷走するのか

システム開発のトラブルは、技術よりも“意思疎通の曖昧さ”に起因するケースが多くあります。「その仕様、合意したつもりだった」「変更の前提だと思っていた」「承認した認識はなかった」といった言葉は、現場で頻繁に聞かれるものです。

特にフルスクラッチ開発では、仕様が確定していない段階や、業務整理がこれからというフェーズでもプロジェクトが動き始めます。そのような状況で取り決めが曖昧だと、ユーザー企業もシステム開発会社も互いに異なる前提で判断を下し、プロジェクトが複数の方向へ進んでしまいます。

これは技術では解決できません。プロジェクトを成立させるには、共通理解のための「仕組み」が必要です。

“合意と承認”がプロジェクトを安定させる理由

取り決めは、単なる手続きではありません。プロジェクトの土台そのものです。
明確にすべきポイントは次の3つです。

誰が承認権限を持つのか（承認主体）

• 現場責任者が承認するのか
• 部門長が必要なのか
• 経営層の意思決定が必要な範囲はどこか

これを曖昧にすると、意思決定のスピードが落ち、プロジェクトは停滞します。

どの段階で承認が必要なのか（承認プロセス）

• 要件定義
• 画面設計
• 機能設計
• 追加開発

承認のタイミングを明確にしないと、「戻るべき地点」が不明瞭になり、手戻りが膨らみます。

どのように承認を残すのか（承認証跡）

• 文章化
• 打ち合わせ記録
• 仕様書の版管理

言った言わないを防ぐには、承認証跡の残し方もルール化する必要があります。
これらはすべて、プロジェクトを安定させるための“必須条件”です。

曖昧さが引き起こすのは「仕様変更」ではなく“合意変更”

現場で頻発する問題のひとつに、「仕様変更を要求された」という誤解があります。しかし実際には、多くが“合意が成立していなかった”ことが根本原因です。

• 仕様の範囲を説明したつもり
• 以前の打ち合わせで話したつもり
• 担当者同士の認識だけで進めてしまった

これらはすべて「合意」ではありません。プロジェクトは“合意された内容”を前提に動くため、合意されていないものは追加対応として扱われます。

つまり、仕様変更の混乱は「技術の問題」ではなく「プロセスの問題」なのです。

承認ルールが整備されている企業ほど、プロジェクトが強い

成功する企業の共通点として、承認ルールが非常にクリアです。

• 誰が決めるのか
• 何をもって決定とするのか
• どこまで合意に含まれるのか
• どこからが追加の判断になるのか

これらが明確だと、意思決定のスピードが安定し、システム開発会社も適切な提案と計画が行えます。

さらに、承認ルールが明確だと“責任の所在”が曖昧になりません。責任の流動化はプロジェクトを不安定にしますが、ルールで明確に定義されていれば、迷いも誤解も減ります。

フルスクラッチ開発と「合意形成プロセス」の相性

白紙から構築するフルスクラッチ開発は、合意形成がそのまま品質に直結します。
理由は3つあります。

1.要件の曖昧さが影響範囲を大きく広げる

フルスクラッチは自由度が高い分、前提が一つ変わるだけで設計全体に影響します。

2.合意が取れていない部分ほど、手戻りが増える

ユーザー企業内で合意が取れていないまま外部に発注すると、後の承認プロセスで混乱しやすくなります。

3.承認ルールがプロジェクトの“スピード”を決める

フルスクラッチ開発は意思決定の回数が多く、承認の遅れがそのまま工期に影響します。
つまり、合意と承認のプロセスそのものが、フルスクラッチ開発では成功の鍵になるのです。

承認しやすい表現とは何か──専門用語より“理解できる言葉”を使う

システム開発会社が専門用語を多用しすぎると、ユーザー企業が承認しにくい状態が生まれます。「理解できないもの」は承認の対象になりにくいためです。

承認がスムーズに進む企業は、次の特徴があります。

• 技術用語をそのまま使わず、業務に置き換えて説明する
• 図解やプロトタイプで視覚的に確認する
• 判断に必要な情報だけを整理して提示する

承認しやすい表現とは、「相手が理解しやすい言語で説明すること」です。

まとめ

システム開発を安定して進めるためには、合意と承認のプロセスを明確にし、誰が何を決めるのかを透明化することが欠かせません。特にフルスクラッチ開発では、このプロセスの精度がプロジェクト全体の品質とスピードに直結します。合意が曖昧なまま進めば手戻りが増え、承認が曖昧であれば責任の所在が不明確になり、プロジェクトは迷走します。明確なルールと、相互理解を前提とした説明こそが、良いシステム開発を実現するための基盤となります。

フルスクラッチ開発では、合意と承認のプロセスが整っているかどうかが、最終的な品質と満足度を大きく左右します。当社フレシット株式会社は、このプロセスを単なる手続きではなく「共通認識を育てるための対話」と捉え、要件整理から設計、開発、運用保守まで一貫して伴走する体制を整えています。業務理解を深めたうえで、判断に必要な情報をわかりやすく可視化し、ユーザー企業が承認しやすい形で進めることを得意としています。貴社だけの最適なシステムをゼロから構築したいとお考えでしたら、ぜひフルスクラッチ開発を強みとするフレシット株式会社にご相談ください。丁寧な合意形成と高い技術力で、安心して進められるプロジェクトをご一緒に実現いたします。

＞＞フルスクラッチ（オーダーメイド）のシステム開発について詳細はこちら