請負契約でシステム開発を成功させるための要件定義書の作り方

請負契約でシステム開発を成功させるための要件定義書の作り方

「要件定義書の曖昧さが、請負契約のトラブルの9割を生む」——その実態を直視します

「ベンダーと請負契約を結び、要件定義書も作成した。ところが開発が進むにつれて、『その機能は要件に明記されていない』『画面のイメージが違う』といった認識齟齬が続出し、追加費用と納期遅延が発生した」「検収段階で『これで完成』と主張されたが、こちらの想定と違って受け取れない」——IT発注に不慣れな会社でよく起きる事態です。

• 要件定義書が機能名の羅列だけで、業務シナリオが書かれていない
• 画面仕様が文章のみでモック・ワイヤーフレームがない
• 非機能要件（性能・セキュリティ・可用性）がほぼ抜けている
• 検収基準が「問題なく動くこと」など曖昧表現
• スコープ外の記載がなく、範囲の線引きがない

これらはどれも、発注側が要件定義書の役割と構造を理解していないことから生じる失敗パターンです。

請負契約は、「契約書に書かれた成果物を完成させる義務」をベンダーに課す契約形態です。つまり、契約書の別紙として添付される要件定義書こそが成果物の定義そのものになります。要件定義書が曖昧なら、成果物の定義が曖昧となり、検収基準も曖昧となり、最終的に紛争に発展します。

「要件定義書はベンダーが作るもの」——その誤解が受け身の失敗を生みます

IT発注に不慣れな中小企業や建築・設計事務所の担当者は、「要件定義書は専門家のベンダーが作るもの」と考えがちです。これは半分正解で、半分間違いです。

「ベンダーから出てきた要件定義書に押印した。後から読むと業務用語の解釈が自社の感覚と違っていた」

「要件定義書にヒアリング内容が反映されていると思い込んでいたが、実は重要な業務フローが抜けていた」

「画面の項目数や見た目は**『打ち合わせで伝えたはず』**と思ったが、文書には書かれておらず、結局追加費用で対応することに」

ベンダーが作成する要件定義書は、あくまでベンダー側の解釈・理解で書かれています。発注側の業務や意図を100%反映することは構造的に不可能です。したがって、発注側が自社の業務観点で要件定義書をレビューし、必要な修正・追記を入れる責務があります。

この「レビューする責任」を果たすためには、要件定義書の構造と必須項目を発注側が理解している必要があります。

また、請負契約の前段階として、「要件定義フェーズは別途の準委任契約」にするのが近年の主流です。要件定義段階では成果物が確定していないため、完成責任を負わせる請負契約は構造的に合いません。要件定義を先に確定させ、確定した要件定義書をもとに開発フェーズは請負契約とするのが安全な進め方です。

請負契約で成功する要件定義書の作り方を、実務目線で整理します

本記事では、以下の流れで解説します。

• 要件定義書の役割と構造
• 必ず盛り込むべき7つの必須項目
• 曖昧さを排除する書き方のコツ
• 検収基準の定量化方法
• 請負契約に添付する際の実務的な注意点

要件定義書の品質を上げるだけで、プロジェクトのトラブルは劇的に減ります。一緒に見ていきましょう。

要件定義書の全体構造

要件定義書に必ず盛り込むべき、7つの必須項目

1. プロジェクト背景と業務目的

要件定義書の最初のセクションには、なぜこのシステムを作るのかを明記します。

• 現状の業務課題（数値で表現、例：「月次の請求処理に40時間かかっている」）
• システム化によって達成したい状態（例：「月次処理を8時間以内に完了」）
• ターゲットユーザーと利用頻度
• 期待する効果指標（KPI）

この部分が弱いと、ベンダーが技術的な最適解ばかりを追求し、業務的な価値とずれた成果物が出てきます。

2. 業務フローとユースケース

次に、誰が・いつ・どんな状況で・何を行うかを時系列で記述します。

• 主要な業務シナリオ（3〜10パターン）
• 各シナリオのアクター（操作者の役割）
• トリガー（シナリオが始まるきっかけ）
• 期待される結果
• 例外パターン（エラー時・異常時の挙動）

ユースケース図や業務フロー図を必ず添付します。文章だけでは解釈の幅が生まれ、後のトラブル源になります。

3. 機能要件（何ができるシステムか）

機能要件は、ユースケースから導出される形で記述します。

• 機能名・機能ID
• 入力・処理・出力の3点セット
• 機能の実行条件
• エラー時の挙動
• 関連機能との連携

機能要件を書く際の鉄則は、「曖昧な動詞を使わない」ことです。「適切に処理する」「柔軟に対応する」「ユーザーフレンドリーに表示する」などの表現は、解釈が分かれる元凶です。定量的な基準に置き換えます。

4. 非機能要件（どんな性質のシステムか）

請負契約で最も抜けがちで、最も紛争を生む領域です。必ず明文化します。

非機能要件は、数値化しにくい項目でもなんらかの定量基準を設けることが重要です。抽象的な表現で放置すると、「これで要件を満たしている」「いや満たしていない」の不毛な議論が発生します。

5. 画面仕様（UI・UX）

画面仕様は、文章のみで書かないのが鉄則です。

• ワイヤーフレーム（画面ごとのレイアウト図）
• 画面遷移図（画面間の動き）
• 画面項目の一覧表（項目名・データ型・必須/任意・文字数）
• 操作フロー（ボタン押下時の挙動）

Figma・Miro・draw.io などの簡易ツールで、A4で1枚ずつまとめるだけでも、認識齟齬が激減します。

6. データ設計

システムが扱うデータの構造と関係を記述します。

• データ項目一覧（エンティティ・属性・データ型）
• エンティティ関連図（ER図）
• マスターデータの初期登録要件
• データ保存期間と削除ポリシー
• 外部システムとのデータ連携仕様

データ設計は技術者寄りの項目ですが、発注側でも業務用語の定義だけは明確にします。たとえば「顧客」と「取引先」が同義なのか異なるのか、といった業務定義は発注側にしか答えられません。

7. スコープ外の明記と検収基準

最後に、やらないことと完成の判断基準を明記します。

スコープ外の記載

• 対象にしない業務プロセス
• 連携しない外部システム
• 今回の開発で実装しない機能
• 将来的に検討する保留項目

スコープ外を明文化することで、「当然含まれると思った」「言った言わない」の水掛け論を回避できます。

検収基準

• 機能ごとのテスト項目数と合格基準
• バグの許容レベル（Critical/Major/Minorで分類）
• 検収期間と差し戻し条件
• 検収完了の判定者と判定方法

検収基準が曖昧だと、「ベンダーは完成と主張、発注側は不十分と主張」で平行線になります。数値化できる項目は数値化します。

要件定義書の作成ステップ

曖昧さを排除する、要件定義書の書き方3原則

原則1｜主語を明確にする

「システムは、売上データを集計する」という記述は、集計ロジック・集計タイミング・集計結果の表示方法が不明です。以下のように書き換えます。

• いつ：毎月1日 AM2:00に
• 何を：前月1日〜月末の売上データを
• どうする：部門別・商品カテゴリ別に合計する
• どこに出す：月次売上レポート画面に一覧表示する

この5W1Hが埋まっていれば、解釈の幅はほぼ消えます。

原則2｜定量表現を徹底する

以下の言葉は要件定義書から排除するのが理想です。

• 「適切な」「柔軟に」「ユーザーフレンドリーに」「直感的に」
• 「高速」「大量」「十分な」「必要に応じて」
• 「できる限り」「可能な範囲で」「基本的に」

必ず数値・条件・具体例に置き換えます。

• 「高速」→「処理時間3秒以内」
• 「大量データに対応」→「100万件のデータに対応」
• 「必要に応じて通知」→「エラー発生時にメール通知」

原則3｜反例と境界条件を書く

「○○の場合はどう動くか」という例外・境界条件を明記します。

• データが0件の場合の表示
• 最大許容量を超えた時の挙動
• 通信エラー時のリトライ・エラー表示
• 同時実行時の排他制御
• 不正な入力が来た場合のバリデーション

正常系だけで要件定義書を書くと、開発フェーズで例外対応の追加工数が大量発生します。最初から例外を含めることが、結果的に工数削減につながります。

こんな方にこの記事の内容が役立ちます

• 初めてシステム開発を請負契約で発注する建築・設計事務所や中小工務店の総務担当者
• 過去のIT発注で要件のずれによるトラブルを経験した中小企業の情シス責任者
• ベンダー提示の要件定義書にそのまま押印せず、自社観点でレビューしたい経営企画担当者
• 社内システムを刷新し、紛争なく納品まで辿り着きたい情報システム責任者
• 要件定義フェーズを別契約にする意味を発注側として理解しておきたい経営者

要件定義書は、請負契約の成否を決定づける最重要文書です。技術的な専門用語を完璧に理解する必要はありませんが、業務観点での網羅性・具体性・例外条件を確認する責任は、発注側にあります。

ここを疎かにすると、契約後のあらゆる場面で認識齟齬と紛争が発生し、結果としてコストも納期も膨らみます。逆に、要件定義書の段階で時間をかけた会社ほど、開発フェーズがスムーズに進む——これが、IT発注の長年の経験則です。

まとめ

精緻な要件定義書で成功するシステム開発

請負契約で成功する要件定義書の要点を整理します。

• 7つの必須項目：背景/業務フロー/機能要件/非機能要件/画面仕様/データ設計/スコープ外と検収基準
• 曖昧表現の排除：主語を明確に、定量表現を徹底、反例・境界条件を明記
• 発注側のレビュー責任：ベンダー作成の要件定義書を、業務観点で精査する
• 要件定義フェーズの分離：開発の請負契約前に、準委任で要件定義を確定させる
• 検収基準の定量化：機能ごとのテスト項目、バグ許容レベルの事前合意

要件定義書の品質は、プロジェクトの成否の7割以上を決めます。ここで手を抜いて急ぐと、その後の開発・テスト・検収・運用までの全工程に歪みが伝播します。逆に、ここに時間をかけた案件ほど、後工程がスムーズで、追加費用・納期遅延が発生しにくくなります。

建築・設計事務所や中小工務店など、IT発注に不慣れな会社向けの要件定義支援はアトリエ・バイナリ（atelier binary）で承っており、ベンダー提示の要件定義書レビュー、業務ヒアリング、非機能要件の整備、検収基準の定量化までを伴走しています。「ベンダーの提案書を読み解けない」「要件定義フェーズを独立発注すべきか判断がつかない」といった段階で早めに相談いただければ、紛争リスクを最小化しながら発注を進めることができます。

まずは、手元にベンダーから提示されている要件定義書があれば、本記事の「7つの必須項目」と「3原則」に照らしてチェックしてみてください。漏れや曖昧表現がいくつも見つかるはずです。その気づきが、請負契約のトラブルを避ける第一歩になります。