top of page

Chapter 3 要件定義  
「決まっていないこと」を決めない技術

chapter3

要件定義は、多くのITプロジェクトにおいて
最も誤解され、最も破壊力の高い工程です。

​

要件定義とは、

  • すべてを決める工程

  • 細部まで固める工程

だと思われがちですが、
それは 要件定義の失敗パターン です。

​

この章では、
**「要件定義をどう進めるべきか」**を
実務の視点で整理します。

3-0. 要件定義の前に必ず通る3つの関門

chapter3-0

要件定義は、
「作り方を決める工程」ではありません。

誰と、どこまで、どの責任で進めるかを確定させる工程です。

​

そのためには、
要件定義に入る前に、
必ず通過しなければならない3つの関門があります。

​

これを飛ばしたプロジェクトは、
ほぼ例外なく後工程で破綻します。

3-0-1. RFI｜知らないまま決めない

RFI（Request For Information）は、
**「情報収集の工程」**です。

 

ここでやるべきことは、
要件を決めることではありません。

RFIの本質的な目的

  • 市場にどんな選択肢があるのかを知る

  • 技術的に何が可能で、何が難しいかを把握する

  • 想像と現実のズレを認識する

つまり、
「知らない状態で決断しない」ための工程です。

RFIを飛ばすと起きること

  • 実現不可能な前提で要件を作る

  • 特定ベンダーの思惑に引きずられる

  • 「後で分かる」問題が山のように出る

これは、
要件定義の失敗ではありません。

RFIをやらなかった時点での敗北です。

RFIで決めてはいけないこと

  • 採用技術の確定

  • 実装方式の断定

  • 工数・金額の確定

RFIは、
可能性を知る工程であって、決断する場ではない
ということを忘れてはいけません。

3-0-2. RFP｜要求と責任を文章化する

RFP（Request For Proposal）は、
要件定義と最も混同されやすい工程です。

​

しかし役割は明確に違います。

RFPの役割

  • 何をやりたいのか

  • どこまでを求めているのか

  • 誰が何に責任を持つのか

これらを
第三者に伝わる文章として固定する工程です。

要件定義とRFPの違い

  • 要件定義：内部向け（判断と整理）

  • RFP：外部向け（要求と条件の提示）

 

RFPは、
**「ベンダーに考えさせるための資料」**であり、
「答えを書いてあげる資料」ではありません。

RFPに必ず含めるべき要素

  • プロジェクトの目的・背景

  • 成功条件と評価基準

  • 対象範囲と除外範囲

  • 制約条件（期限・予算・法的制限）

  • 役割分担・責任範囲

  • 契約前提・変更時の考え方

これが曖昧なRFPは、トラブルの予約券です。

3-0-3. ベンダー選定｜価格ではなく責任で選ぶ

ベンダー選定は、
見積比較の工程ではありません。

責任の分配を決める工程です。

​

価格で選ぶと何が起きるか

  • 安く見せるために前提条件が削られる

  • 責任範囲が曖昧なまま契約される

  • 問題が起きた瞬間に「契約外」と言われる

これは、
ベンダーが悪いのではありません。

選び方を間違えているだけです。

正しいベンダー選定の視点

  • 不確実性をどう扱うか

  • 変更が発生した時の考え方

  • 判断のエスカレーションルート

  • プロジェクトにどこまで関与する覚悟があるか

ここを見ずに
金額だけを見ると、
必ず後で高くつきます。

​

ベンダー選定で必ず確認すべきこと

  • 誰が最終責任者か

  • 人が変わった場合の引き継ぎ体制

  • 判断を止めないための関与レベル

  • 「できない」と言えるかどうか

安請け合いをするベンダーは、
良いベンダーではありません。

3-0 のまとめ

RFI・RFP・ベンダー選定は、
要件定義の前段ではありますが、
プロジェクトの運命をほぼ決める工程です。

 

ここを通らずに始めるプロジェクトは、

  • 誰も全体責任を取らず

  • 誰も正しい判断をせず

  • 最後に現場が潰れます

要件定義とは、
この3つの関門を通過した者だけが入れる領域です。

​

​

3-1. 要件定義の目的を最初に誤解しない

要件定義の目的は、
仕様書を完成させることではありません。

​

本当の目的は、次の3つです。

  • プロジェクトの判断基準を固定する

  • 誰が何を決めるかを明確にする

  • 未確定事項を「未確定」として共有する

 

つまり要件定義とは、
決断のための土台を作る工程です。

 

ここを誤解すると、
要件定義はただの「作業」になります。

3-2 「決めること」と「決めないこと」を最初に分離する

要件定義の最初にやるべきことは、
要件を詰めることではありません。

決めるべきことと、決めてはいけないことを分けることです。

​

決めるべきこととは、

  • プロジェクトの目的・成功条件

  • 対象業務と範囲

  • 利用者と利用シーン

  • 制約条件（期限・予算・法的制限）

  • 判断者と承認ルール

これらは、
現時点で事実として判断できることです。

 

一方で、
次のものは決めてはいけません。

  • 実装方法の詳細

  • 将来業務の細かい動き

  • 未検証の運用ルール

  • 特定の人のスキルに依存した前提

これらは、
まだ分からないことです。

3-3. 未確定事項を「未確定」として記録する

多くのプロジェクトでは、
未確定事項が次のように扱われます。

  • とりあえず決めたことにする

  • 書類上は確定にする

  • あとで変えればいいと思う

これが、後工程での炎上の原因です。

​

正しい進め方は、

  • 未確定事項は未確定として記録する

  • いつ・誰が・何をもって確定するかを決める

  • 変更時の影響範囲を明示する

 

要件定義書に
**「未確定事項リスト」**が存在しない場合、
その要件定義は不完全です。

3-4. 要件定義を「合意形成の場」にしない

要件定義は、
合意形成の場ではありません。

​

合意形成は、
すでに Chapter 2（企画・提案）で終わっているべきです。

 

要件定義で次のことが起きている場合、
危険信号です。

  • 方針の議論が始まる

  • ゴールの話に戻る

  • 責任者が決断を避ける

要件定義は、
決まった前提を具体化する工程であり、
前提を作り直す場ではありません。

3-5. 要件定義書は「契約書の補助資料」である

要件定義書は、
設計書ではありません。

また、
運用マニュアルでもありません。

​

契約書を実行可能にするための補助資料です。

​

そのため、要件定義書には次が必要です。

  • 契約範囲との対応関係

  • 変更が発生した場合の扱い

  • 契約外となるケースの明示

これがない要件定義書は、
後工程で必ず揉めます。

3-6. 要件定義を「守るための武器」にする

正しく作られた要件定義は、
現場を縛るものではありません。

​

現場を守るための武器です。

​

  • 無理な追加要求を断れる

  • 判断を上に戻せる

  • 感情論を排除できる

要件定義が弱いと、
現場はすべてを背負うことになります。

3-7. この章のまとめ

要件定義とは、

  • すべてを決める工程ではない

  • 曖昧さを排除する工程でもない

**「曖昧さを管理する工程」**です。

 

決められないことを、
決めたことにしない。

 

これが守られない限り、
プロジェクトは壊れ続けます。

​

要件定義が正しく行われたプロジェクトでは、
開発フェーズが驚くほど静かになります。

 

なぜなら、
判断すべきことが、すでに判断されているからです。

 

次章では、
この要件定義を前提に、
設計・開発フェーズをどう回すかを扱います。

▶ 前章：Chapter 2｜企画・提案 期待値を壊さないために最初に決めること

​​

▶ 次章：Chapter 4｜設計・開発  人ではなく、タスクでプロジェクトを回す

bottom of page