要件定義フェーズは準委任契約にすべき理由｜プロジェクト成功率を上げる契約設計

要件定義フェーズは準委任契約にすべき理由

「要件定義込みで請負契約」が失敗の入り口です

「要件定義も含めて、全部まとめて請負でお願いしますよ」

中小工務店や設計事務所がシステム開発を外注するとき、こう言ってしまうケースが非常に多いです。

• 「何を作るか決まっていないのに、見積もりと納期だけ先に決まった」
• 「要件定義のつもりが、いつの間にか開発が始まっていた」
• 「途中で"やっぱりこうしたい"と言ったら"契約外です"と返された」
• 「最終的に、誰が何を決めたのかわからないまま納品された」
• 「完成したシステムが、現場の業務フローとまるで噛み合わない」

建設業界にいれば、請負契約は日常的な契約形態です。図面を描いて、その通りに建てる。完成物を納品して、検収する。この流れに慣れているからこそ、システム開発も同じ感覚で「丸ごと請負」にしてしまうのです。

しかし、建物とシステムには決定的な違いがあります。建物は設計図が完成してから施工に入りますが、システム開発では**「何を作るか」を決めること自体が、最も難しい工程**なのです。

この記事では、要件定義フェーズを準委任契約に分離すべき理由と、それによってプロジェクト成功率がどう変わるのかを、実務の視点から解説します。

なぜ「丸ごと請負」だと失敗するのか——建設と IT の決定的な違い

この悩み、痛いほどわかります。

工務店や設計事務所の経営者にとって、「まとめて請負で発注する」のは合理的な判断に見えます。実際、建設工事ではそれが当たり前だからです。

設計図面を渡して、施工業者に請負で発注する。完成したら検収して引き渡し。この流れで何十年もやってきたのですから、システム開発も同じように考えるのは自然なことです。

しかし、建設とシステム開発には見落としがちな構造的な違いがあります。

つまり、建設工事の「設計→施工」という流れは、設計図の確度が高いから成り立つのです。

一方でシステム開発は、「何を作るか」を決める段階（＝要件定義）で不確実性が最も高い。ここを請負契約に含めてしまうと、まだ何も決まっていないのに「完成責任」を負わせるという矛盾が生まれます。

開発会社側も、不確実なまま請負で受けるとリスクが大きいため、見積もりにバッファを大きく乗せるか、スコープを狭く限定して防衛するしかありません。どちらにしても、発注側にとって良い結果にはなりません。

「丸ごと請負」が悪いのではなく、「要件が固まっていない段階を請負に含める」のが問題なのです。

要件定義を「準委任契約」に分離すれば、プロジェクトは変わる

結論から言います。要件定義フェーズだけを準委任契約で分離する——これだけで、プロジェクトの成功率は大きく変わります。

要件定義を準委任契約に分離する

そもそも「準委任契約」とは？

建設業界に馴染みのある方のために、シンプルに整理します。

• 請負契約：完成物の納品義務がある。成果物に対して報酬を支払う
• 準委任契約：業務の遂行義務がある。作業（プロセス）に対して報酬を支払う

建設で例えるなら、請負契約は「この建物を建ててください」、**準委任契約は「設計の相談に乗ってください」**に近いイメージです。

要件定義は、まさに**「何を作るか一緒に考える」フェーズ**。完成物が事前に定義できないのですから、プロセスに対して報酬を支払う準委任契約のほうが、実態に合っているのです。

なぜ要件定義だけ分離するのか？

要件定義と開発をひとつの契約にまとめると、以下の問題が起きます。

問題1：要件変更ができなくなる

請負契約では「仕様」が契約の基準になります。しかし要件定義中は、その仕様自体を模索している段階です。「仕様を決める作業」に「仕様通りの完成」を求めるのは、論理的に矛盾しています。

問題2：開発会社が防衛的になる

不確実な要件を請負で受けた開発会社は、リスクヘッジとして要件を狭く固定しようとします。結果、現場で本当に必要な機能が「契約外」として切り落とされます。

問題3：費用の透明性が失われる

要件定義にいくらかかったのか、開発にいくらかかったのかが見えなくなります。「追加費用300万円」と言われても、それが妥当なのか判断できない状態に陥ります。

契約を分離するとどうなるか

こうすることで、要件定義フェーズでは自由に議論・変更ができ、要件が固まった段階で精度の高い見積もりに基づいて請負契約を結べます。

建設に置き換えれば、基本設計は設計事務所にコンサルティング的に依頼し、実施設計と施工は請負で発注する——この感覚に近いはずです。

準委任契約で要件定義を進める具体的なポイント

「準委任にすればいいのはわかった。でも具体的にどう進めればいいのか？」

ここからは、中小工務店・設計事務所がシステム導入する際の実務的なポイントを解説します。

準委任契約の進め方

ポイント1：契約書に「成果物」ではなく「遂行すべき業務」を明記する

準委任契約では、何を納品するかではなく、何をやるかを定義します。

具体的には、以下のような業務内容を契約書に記載します。

• 現状業務フローのヒアリングと可視化
• システム化対象範囲の特定と優先順位付け
• 機能要件・非機能要件の整理
• 画面遷移図・ワイヤーフレームの作成
• 概算見積もりの提示（開発フェーズ用）

**「要件定義書を納品する」のではなく、「要件を一緒に整理するプロセスを遂行する」**という建て付けです。

もちろん、プロセスの結果として要件定義書や画面設計書などのドキュメントは作成されます。しかし、契約の主眼は「成果物の完成」ではなく「業務の適切な遂行」にあるという点が重要です。

ポイント2：期間と工数の上限を設定する

準委任契約で最も不安になるのが、**「いつまで経っても終わらないのでは？」**という点です。

これを防ぐために、以下を契約に盛り込みます。

• 期間：要件定義フェーズは最長3ヶ月（中小規模なら1〜2ヶ月が目安）
• 工数上限：月あたりの稼働時間の上限を設定（例：月80時間まで）
• 中間報告：隔週でのレビュー会議を義務化
• 中途解約条項：合わないと感じたら、一定の予告期間で解約できる

**「期間と工数に上限がある準委任」であれば、青天井のリスクはありません。**むしろ、請負で丸ごと発注して後から追加費用が膨らむよりも、コストのコントロール性は高いのです。

ポイント3：要件定義の成果を「次の請負契約の仕様書」にする

準委任契約で作成した要件定義書を、そのまま開発フェーズの請負契約における「仕様書」として使います。

この流れを最初から設計しておくことで、以下のメリットが生まれます。

• 要件定義書の品質が上がる：「この文書が請負契約の基準になる」と意識するため、曖昧さが排除される
• 見積もりの精度が上がる：要件が明確になった状態で見積もるため、バッファが最小化される
• 開発会社の選択肢が広がる：要件定義書があれば、開発フェーズは別の会社に発注することも可能
• 発注者の交渉力が上がる：「この仕様でいくらか」を複数社に聞ける立場になれる

特に3番目と4番目は重要です。要件定義と開発を同じ会社に丸投げすると、途中で会社を変えることが極めて困難になります。これが、いわゆる**「ベンダーロックイン」**です。

準委任で要件定義を分離しておけば、開発フェーズで最適なパートナーを改めて選べるというオプションが手に入ります。

ポイント4：「善管注意義務」を理解しておく

準委任契約には**「善管注意義務」**という概念があります。これは、受託者がその専門家として当然払うべき注意を持って業務を遂行する義務です。

つまり、準委任契約だからといって**「適当にやっても問題ない」わけではありません**。要件定義を受託した会社は、ITの専門家として合理的なプロセスで業務を進める義務を負います。

逆に言えば、善管注意義務を果たしているかどうかが、成果の良し悪しを判断する基準になります。中間報告で進捗を確認し、適切なプロセスが踏まれているかをチェックすることが、発注側の重要な役割です。

こんな工務店・設計事務所は今すぐ契約設計を見直してください

以下に当てはまる方は、次のシステム導入で契約を分離することを強くお勧めします。

• 過去にシステム導入で「言った・言わない」のトラブルを経験した
• 「追加費用」の請求で予算を大幅に超過したことがある
• 納品されたシステムが現場で使われず、Excelに戻ってしまった
• 開発会社に言われるがまま、よくわからないまま契約を結んだ
• DXを推進したいが、どこから手をつければいいかわからない

特に、年間売上が1億〜30億円規模の中小工務店・設計事務所では、IT専任の担当者がいないケースがほとんどです。その状態で「丸ごと請負」の契約を結ぶのは、設計図なしで建物の施工を発注するようなものです。

契約形態を変えるだけで、プロジェクトの力学は大きく変わります。技術的な知識がなくても、「要件定義は準委任、開発は請負」という原則を知っているだけで、失敗のリスクを大幅に下げられるのです。

今すぐ次のプロジェクトの契約を見直してください。「前と同じ契約でいいか」を問い直すことが、プロジェクト成功への第一歩です。

まとめ

まとめ

この記事のポイントを整理します。

• 要件定義を請負契約に含めると、「何を作るか決まっていないのに完成責任を負わせる」という矛盾が生まれる
• 要件定義は準委任契約、開発は請負契約——この2段階の契約設計がプロジェクト成功の基本形
• 準委任契約では「成果物」ではなく「遂行すべき業務」を定義する
• 期間・工数の上限を設け、中間報告を義務化することでコストをコントロールできる
• 要件定義書を「次の請負契約の仕様書」に使う設計にすることで、ベンダーロックインを防げる

建設業界で長年培ってきた**「設計と施工を分ける」という知恵**は、実はシステム開発にもそのまま応用できます。違うのは契約形態の名前だけ——設計＝準委任、施工＝請負と読み替えれば、すでに持っている感覚で正しい判断ができるはずです。

「でも、自社だけで契約設計を見直すのは難しい」と感じた方もいるかもしれません。私たちアトリエ・バイナリでは、中小工務店・設計事務所のIT導入における契約設計から伴走するコンサルティングを行っています。要件定義フェーズの準委任契約の組み立て方から、開発会社の選定支援まで、「技術がわかる第三者」として一緒に考えるパートナーとして、お気軽にご相談ください。

まずは、次のシステム導入の契約形態を見直すことから始めてみてください。それだけで、プロジェクトの成功確率は確実に上がります。