要件定義の進め方｜工程と成果物・詰まりの実録

要件定義の進め方は、ヒアリングで業務を聞き取り、要件を整理し、要件定義書にまとめ、レビューと承認で確定する、という4工程が標準です。ただ、この工程を教科書どおりにこなしても、要件の漏れは出ます。漏れが起きる場所は決まっていて、機能の中ではなく、機能と機能のあいだです。

引っ越しの荷造りで、部屋ごとに箱の数を数えた完璧なリストを作ったことがあります。当日、リストの箱はすべて予定どおりに埋まりました。詰まったのは、冷蔵庫の霜取りと洗濯機の水抜きです。どの部屋のリストにも載らない、部屋と部屋のあいだの作業だけが、手つかずで残っていました。

要件定義でも同じことが起きます。部屋ごとの箱リストにあたるのが画面一覧と機能一覧で、どの部屋にも属さない作業にあたるのが、業務の受け渡しです。数えやすいものだけが数えられ、あいだが抜けます。

この話に出てくるのは、空調・電気設備を手がける中堅の設備工事会社です。見積から施工、検収、請求までを扱う工事案件管理システムの要件定義を進めました。※複数の実経験をもとに再構成した架空のプロジェクトです。起きている力学は実際のものです。僕は15名ほどの会社を10年経営していて、発注側の要件定義を支援する立場で参加しました。この記事では、要件定義の進め方、つまり工程と成果物の話を扱います。

前置きはさておき、本題に入ります。

① 教科書どおりに、要件定義を進めてみる

「教科書どおりに、要件定義を進めてみる」を図解したスライド｜要件定義とは、システムで実現することを、開発が始まる前に確定させる工程です

「そのとおりに進めて、詰まる」を図解したスライド｜冒頭の設備工事会社の案件の話に入ります

要件定義の基本をすでにご存じの方は、② そのとおりに進めて、詰まるから読み進められます。

要件定義とは——開発全体のどこにあるか

要件定義とは、システムで実現することを、開発が始まる前に確定させる工程です。ウォーターフォール型の開発では最上流に置かれ、ここで決めた内容が設計、実装、テストのすべての土台になります。

最上流にある、ということが重要です。要件定義の誤りは下流に行くほど直すコストが増えます。設計段階の手戻りは図面の書き直しで済みますが、テスト段階で見つかった要件漏れは、実装からやり直しになります。

要求定義との違い

要求定義は、発注側が「こうしたい」を言葉にする工程です。要件定義は、その要求を、システムで実現する範囲と方法に落とし込む工程です。要求は願望を含んでよく、要件は実現の約束になります。

順番は要求定義が先です。要求が曖昧なまま要件定義に入ると、ベンダーの解釈で要件が決まり、納品後に「頼んだものと違う」が起きます。

基本設計との違い

要件定義が「何を作るか」を決めるのに対して、基本設計は「どう作るか」を決めます。画面のレイアウト、データベースの構造、外部システムとの接続方式は基本設計の領域です。

境界が曖昧になりやすいのは画面まわりです。要件定義では「見積を一覧で確認し、承認できること」まで、画面のどこにボタンを置くかは基本設計、と役割を分けます。

なぜ要件定義が必要か

要件定義を薄くすると、3つの形で返ってきます。予算の超過、スケジュールの遅延、そして納品後の「業務に合わない」です。作っている途中で要件が増えれば見積は膨らみ、期間は延び、間に合わせで削った部分が運用の詰まりになります。

逆に言うと、要件定義は発注金額と納期を守るための工程です。ここに時間を使うことは、遠回りに見えて、総額ではいちばん安くつきます。

責任の所在——要件定義は発注者の仕事

要件定義の主体は発注者です。ベンダーは業務を知らないので、業務の中身を決めることはできません。ベンダーが担うのは、聞き取った業務を実現可能な要件に翻訳する部分です。

「要件定義もまとめてお願いします」と丸投げすると、ベンダーは自分たちが作りやすい形で要件を書きます。悪意ではなく、それしか書けないからです。発注側の実務を知る担当者が、工程の中心に立つ必要があります。ベンダーをどう選ぶかはベンダー選定の落とし穴で別に書いています。

進め方の4ステップ

標準的な進め方は、次の4ステップです。

ステップ	やること	主な成果物
1. ヒアリング	現場の業務と課題を聞き取る	議事録、業務の一覧
2. 整理	要求を分類し、優先順位を付ける	要求一覧、業務フロー図
3. 文書化	要件定義書にまとめる	要件定義書、機能一覧
4. レビューと承認	関係者で確認し、確定させる	承認記録、変更管理のルール

各ステップは一方通行ではありません。文書化の途中で不明点が出たらヒアリングに戻ります。ただし承認後の変更は、後述する変更管理のプロセスに乗せます。

要望から要件へ——5段階のフェーズと成果物

ヒアリングで出てくる言葉は、まだ要件ではありません。要望（現場の困りごと）→要求（実現してほしいこと）→検討（実現手段の比較）→提案（ベンダーからの実現案）→要件（合意した実現内容）と、5段階を経て固まります。

フェーズごとに成果物を残すことが、後の合意形成を楽にします。要望の段階ではヒアリングメモ、要求の段階では要求一覧、検討と提案の段階では比較表と提案書、要件の段階で要件定義書です。どの段階の記述かが分かれば、「言った・言わない」の議論が減ります。

要件定義書に書く項目

要件定義書の標準的な項目は、次のとおりです。

項目	書く内容
背景・目的	なぜこのシステムを作るか
システム概要	全体像と対象範囲
業務要件	システム化する業務の流れ
機能要件	システムが備える機能の一覧
非機能要件	性能、セキュリティ、可用性、保守
技術要件	動作環境、連携する既存システム
予算・体制・スケジュール	費用、役割分担、期日

この中で分量が最も大きくなるのが機能要件、つまり機能一覧です。そして後で書くとおり、僕が詰まったのもこの表でした。

ヒアリングの方法——5W2Hで聞く

ヒアリングは、5W2H（いつ・どこで・誰が・何を・なぜ・どうやって・いくらで）で業務を聞き取るのが基本です。「どんな機能が欲しいですか」と聞くと、現場は今の画面の改善案を答えます。業務そのものを聞くほうが、要件の材料になります。

聞く相手は、決裁者と現場担当者の両方です。決裁者だけに聞くと理想の業務が、現場だけに聞くと今の手順の再現が要件になります。

業務フローの把握

聞き取った業務は、業務フロー図に起こします。誰が、どの順番で、何を使って進めるかを図にして、ヒアリング相手に確認してもらいます。図にすると、口頭では出てこなかった分岐や例外が見つかります。

このプロジェクトでも、見積→受注→施工→検収→請求の流れをスイムレーン図にしました。営業、工事部、事務のレーンに分け、書類とデータの流れを矢印でつなぎます。

必要なスキル

要件定義に必要なスキルは、業務知識、文書化の力、そして調整力です。技術の詳細はベンダー側が補えますが、業務のどこが要でどこが例外かは、発注側にしか分かりません。

社内にIT部門がない会社でも、要件定義はできます。必要なのはプログラミングの知識ではなく、自社の業務を順序立てて説明できることです。

使うツール

文書化には、表計算ソフトと作図ツールがあれば足ります。業務フロー図には draw.io などの無償ツール、要求一覧と機能一覧には表計算、議事録と要件定義書には文書作成ソフトです。

専用の要件管理ツールは、要件が数百件を超える規模や、変更履歴を厳密に追う必要がある案件で検討します。中堅企業の業務システムなら、まず表で始めて困りません。

変更管理のプロセス

承認後の要件変更は、必ず記録に乗せます。変更の内容、理由、影響範囲、費用と納期への影響を1件ずつ書き、発注側とベンダーの双方で合意してから反映します。

口頭の「ついでにこれも」が積もると、見積と実態が乖離し、検収のときに誰も全体を説明できなくなります。変更管理は面倒な手続きではなく、追加費用の交渉記録です。

ここまでが、教科書に書いてある進め方です。このプロジェクトでも、この工程はちゃんと機能しました。ヒアリングは進み、業務フロー図は現場の確認を通り、機能一覧は百行を超える厚みになり、要件定義書はレビューと承認を通過しました。

ただ、この工程を全部こなしても、抜けるものがありました。

② そのとおりに進めて、詰まる

「そのとおりに進めて、詰まる」を図解したスライド｜要件定義書のとおりにシステムは作られ、検収も通りました

冒頭の設備工事会社の案件の話に入ります。要件定義書のとおりにシステムは作られ、検収も通りました。百行を超えた機能一覧と、全部門のレビューを積み上げた後です。機能一覧にある機能はすべて動きます。仕様に違反している箇所はありません。

詰まりが出たのは、運用が始まって最初の月末です。請求処理の日、事務の担当者が施工報告の控えを1枚だけ持って、運用の立ち上がりを見に来ていた僕の席まで来ました。指摘は一言でした。「追加工事の分が、請求に載っていません」。控えの備考欄には、当日の追加作業が、職長の手書きで几帳面に記されていました。

流れはこうです。現場の職長は、施工が終わると施工報告を登録します。当日に追加作業が発生した場合、その内容は報告の備考欄に書かれます。事務は受注データをもとに請求書を起こします。備考欄は請求のデータに入りません。つまり、追加工事の情報は、施工報告と請求書のあいだで毎回消えていました。

機能一覧を見返すと、「施工報告の登録」の行はあります。「請求書の作成」の行もあります。どちらも要件どおりに動いています。追加工事の情報を報告から請求へ渡す、という行だけが、どこにもありませんでした。百行を超えた表が、あの日ほど頼りなく見えたことはありません。

③ どう気づいたか——案件を1件、最初から最後まで歩く

「どう気づいたか——案件を1件、最初から最後まで歩く」を図解したスライド｜最初は、備考欄の問題だと思っていました

最初は、備考欄の問題だと思っていました。備考を請求画面に表示すれば済む、という改修案も出ました。ただ、その前に確かめたいことがありました。消えているのは追加工事だけなのか、です。

やったことは単純で、実際の案件を1件選び、見積から請求まで、書類とデータの動きを伝票のように追いかけました。営業の見積が受注になり、工事部に渡り、施工報告になり、事務で請求書になる。工程のたびに、誰が何を見て、何を打ち直しているかを横で見せてもらいます。

収穫は、ここからでした。歩いてみると、消えていたのは追加工事だけではありませんでした。営業が口頭で受けた支払条件の変更は受注データに入らず、事務が毎回営業に電話で確認していました。検収予定日は工事部のホワイトボードにだけあり、請求のタイミングは事務の記憶で運用されていました。

どれも、機能の不具合ではありません。機能と機能のあいだ、部門から部門への受け渡しで、情報が落ちていました。そして、現場の怠慢でもありません。むしろ逆で、システムが受け取らない情報を、事務の電話と工事部のホワイトボードと誰かの記憶が、毎日手で運んでいました。人が接着剤になって、あいだを埋めてくれていたのです。機能一覧には、その接着剤を書く場所がそもそもありません。

④ 原因を1つに特定——数えやすいものだけが数えられていた

「原因を1つに特定——数えやすいものだけが数えられていた」を図解したスライド｜原因は1つです

原因は1つです。機能一覧という表の形が、数えやすいものだけを数えさせていました。①で引いたスイムレーン図も例外ではありません。矢印にしたのは正常に流れる書類とデータだけで、備考欄で運ばれる例外系の受け渡しは、矢印になっていませんでした。描きやすいものが描かれ、数えやすいものが数えられていたのです。

画面と機能は数えやすい。1行ずつ並べられて、見積の根拠になり、進捗の単位になります。だから要件定義書は機能で書かれます。一方、どの画面にも属さず、部門と部門のあいだで行われている仕事は数えにくい。僕はこの日から、これを「あいだ仕事」と呼んでいます。あいだ仕事は量が見えません。数えにくいものは表に行が立たず、行が立たないものは、誰の担当にもなりません。

ヒアリングが甘かった、という話にも見えます。実際、聞き漏らしはありました。ただ、聞き漏らしたのは人ではなく、聞かせた表の形のほうです。機能を聞く問いを立てれば、機能が返ってきます。受け渡しを聞く問いは、最初から立てていませんでした。

⑤ 直してみる——ヒアリングの問いを変え、機能一覧に3列足す

直したのは2箇所です。

1つ目は、ヒアリングの問いを変えました。「どんな機能が必要ですか」ではなく、「この業務は、どこから情報を受け取って、どこへ渡しますか。どこで止まりますか」を聞きます。機能を聞くのをやめて、業務の受け渡しと停止点——つまり、あいだ仕事を書き出す聞き方にしました。

2つ目は、機能一覧に3列を足しました。各機能の行に、受け渡し（どこから来て、どこへ渡すか）、停止点（誰の判断で止まるか）、そして、受け付けられない状態で人が来るケース（前工程の情報が欠けたまま届いたら、どう扱うか）です。

3列目が、いちばん効きました。追加工事の一件は、この列で言えば「備考にしか情報がない状態で請求処理に届くケース」です。埋めようとすると、答えが機能の追加ではなく運用のルールになる行も出てきます。それでよくて、システムで受けるか運用で受けるかを、要件の段階で決められることに意味があります。

確かめ方も1つ決めました。要件定義書のレビューの前に、実際の案件を1件、見積から請求まで机上で歩かせることです。3列が埋まらない行は、その場で誰かに聞けば埋まります。こうした要件の詰めから伴走する仕事は、僕の会社ではAIプロダクト開発として請けています。

⑥ このやり方には、名前があった

「このやり方には、名前があった」を図解したスライド｜案件を1件歩かせて、受け渡しと停止点を書き出す

案件を1件歩かせて、受け渡しと停止点を書き出す。素朴な工夫のつもりでしたが、調べると確立した手法がありました。

工程だけでなく、待ち時間と受け渡しを同じ1枚に描くやり方は、バリューストリームマッピング（VSM）と呼ばれています。製造業の現場改善から生まれた手法で、価値を生んでいる時間と、工程のあいだで止まっている時間を分けて見るための道具です。

さらに、受け渡しの質を測る指標にも、正式な名前がありました。%C/A（Percent Complete and Accurate）です。受け取った側が、差し戻しも問い合わせも追記もせずに、そのまま使えたものの割合を指します。僕が3列目で聞いていた「受け付けられない状態で人が来るケース」は、この指標の裏返しでした。

この指標がVSMに最初から用意されているということは、受け渡しの欠損が業務の主要な詰まりであることは、とうに知られていたということです。要件定義の文脈で使われることが少ないだけで、新しい理屈は、ひとつも要りませんでした。

⑦ 何が変わったか——そして、増えた代償

「何が変わったか——そして、増えた代償」を図解したスライド｜要件レビューの会話が変わりました

要件レビューの会話が変わりました。以前は「この機能は要るか、要らないか」を議論していました。いまは「この受け渡しは、システムで受けるか、運用で受けるか」が議題に加わります。機能の数は同じでも、決まっていることの範囲が違います。

追加工事の請求漏れは、施工報告の追加作業欄を構造化し、請求データに自動で載せる形で直りました。運用開始後の改修としては1件で済んでいます。

代償も書いておきます。まず、ヒアリングの時間が増えました。案件を1件歩かせるのに、関係者を集めて半日かかります。次に、要件定義書が厚くなりました。3列を足した機能一覧は横に長く、印刷して読む人には不評です。最後に、埋まらない行が残ります。発生頻度が低い受け渡しは、聞いても「そのときに考える」としか返ってきません。埋まらない行は空欄のまま残し、運用開始後に起きたら追記する、という割り切りが要ります。

⑧ 現場で使うなら、この3列

「現場で使うなら、この3列」を図解したスライド｜機能一覧に、次の3列を足してください

機能一覧に、次の3列を足してください。3列目の「受け付けられない状態で人が来るケース」は、前工程の情報が欠けたまま届いたら、どう扱うか、を書く列です。設備工事会社の記入例つきで置きます。

機能	受け渡し（どこから・どこへ）	停止点（誰の判断で止まるか）	受け付けられない状態で人が来るケース
見積の作成	営業のヒアリングメモから／受注登録へ	上長の承認で止まる	現場調査が未実施のまま見積依頼が来る
受注の登録	見積から／工事部の施工計画へ	止まらない（自動で渡す）	支払条件が口頭変更のまま届く
施工報告の登録	施工計画から／請求処理へ	職長の完了判断で止まる	追加作業が備考にしか書かれていない
請求書の作成	受注と施工報告から／会計システムへ	事務の確認で止まる	検収日が未入力のまま月末が来る

使い方は3手順です。

1. 機能一覧を書き終えたら、3列を足して各行を埋める

2. 埋まらない行は、実際の案件を1件、見積から請求まで机上で歩かせて埋める

3. 3列目の各ケースについて、システムで受けるか運用で受けるかを要件レビューで決める

2の「1件歩かせる」は、関係部門の担当者を1人ずつ集めて半日が目安です。既存システムの刷新で使う場合は、今のシステムの外で行われている手作業も同じ表に載せます。刷新案件の進め方の全体はシステムリプレイスの進め方に書きました。

⑨ この進め方が、これから効き続ける理由

「この進め方が、これから効き続ける理由」を図解したスライド｜AIで画面を作るコストは下がり続けています

AIで画面を作るコストは下がり続けています。プロトタイプが数日で組み上がる時代に、要件定義だけが従来のままです。

そして、画面が安くなるほど、この記事で書いた歪みは強まります。どんな要望も「画面を1枚足す」で処理できてしまうからです。画面が増えれば、画面と画面のあいだ、つまり受け渡しはさらに増えます。作る速度が上がるほど、数えられていない場所が広がります。

一方で、受け渡しの数は、作り方が変わっても変わりません。業務が営業から工事部へ、工事部から事務へ渡る回数は、仕事の側から決まっているからです。画面の数はツールで変わりますが、受け渡しの数は変わらない。だから、受け渡しを数える進め方は、開発の道具が何に変わっても効き続けます。

RFP（提案依頼書）を書く段階でも、この3列は流用できます。書き方そのものは本記事の範囲を超えるので、要件定義の成果物がそのままRFPの中核になる、とだけ書いておきます。

もう一段引いて言えば、業務システムが「現場に合わない」と言われるとき、合っていないのはたいてい機能ではなく、あいだ仕事の扱いです。だから、言い切ってしまいます。要件定義は、機能を数える工程ではなく、あいだ仕事を数える工程であるべきです。機能の行がどれだけ揃っていても、あいだの行が空白の要件定義書は、まだ半分しか書けていません。