執筆：Swooo編集部／監修：諸藤 哲耀（株式会社アイビス Swooo）
要件定義の成否を分けるのは、要件定義書の書式ではなく、「誰が・いつ・何を決めるか」という進め方の設計です。システム開発の手戻りの多くは要件定義に起因すると言われ続けていますが、その原因は書き方の知識不足よりも、決める体制と段取りがないまま工程が走り出してしまうことにあります。
この記事では、発注者の立場から、要件定義を始める前の準備、5ステップの進め方、各ステップでの発注者とベンダーの役割分担、よくある失敗の回避策、そしてAI駆動開発で進め方がどう変わりつつあるかを整理します。用語の解説や要件定義書の書式・記載項目の詳細は要件定義の基礎知識（要件定義とは・要件定義書の書き方）で扱っているため、本記事はプロセスの運用に絞ります。
要件定義の「進め方」とは：この記事で扱う範囲
要件定義は、発注先のベンダーが決まった後、設計・開発に入る前に行う最初の共同作業です。発注側の「こうしたい」という要求を、ヒアリングと精査を通じて「何を作るか」の合意へ落とし込みます。時系列でいえば、社内企画→RFP（提案依頼書）によるベンダー選定→要件定義→設計・開発・テスト、という流れの中に位置します。
「進め方」という言葉には2つの意味が混ざりがちです。1つは、要求をどんな種類に分類し、どんな文書に落とすかという成果物の作り方。もう1つは、誰がいつ集まり、何を材料に、どの順で決めていくかという運用です。前者は要件定義の基礎知識に譲り、本記事は後者、つまり工程としての運びを扱います。前提として押さえたいのは、要件定義は発注者が「参加する」工程ではなく、発注者が「決める」工程だということです。この認識が、以降のすべてのステップの土台になります。
要件定義を始める前に発注者が準備しておくこと
IPAが2019年に公開した「ユーザのための要件定義ガイド 第2版」は、要件定義を成功に導く128の勘どころを整理した資料ですが、全体を貫くのは「要件定義をベンダー任せにせず、業務部門のユーザーが主体的に関与する」という思想です。主体的に関与するための具体的な準備が、次の棚卸しです。
- 業務の実物：現行の業務の流れ、実際に使っている帳票・Excel・現行システムの画面。口頭の説明より実物のほうが、桁違いに正確に伝わります
- 運用ルールと例外：マニュアルにない現場ルール、月末だけ発生する処理、特定の取引先だけの特別対応。例外こそが設計の難所であり、後から発覚すると手戻りになります
- 困りごとの棚卸し：何に、どのくらいの頻度で、誰が困っているか。優先順位づけの材料になります
- 関係者マップ：システムの影響を受ける部門と、その部門の意見を代表できる人の一覧。工程の後半で「聞いていない部門」が現れるのが典型的な破綻パターンです
- 決める人の任命：意見が割れたときに決められる責任者を、工程が始まる前に決めておきます
- 現場の時間の確保：ヒアリングやレビューには現場担当者の時間が必要です。通常業務との兼ね合いを、上長が業務として確保します
要件定義の進め方5ステップ：発注者とベンダーの役割分担
要件定義の運びを5つのステップに分け、それぞれで発注者がやること・ベンダーがやることを対比します。役割の線引きはプロジェクトによって多少動きますが、「業務と判断は発注者、構造化と実現手段はベンダー」という軸は共通です。
ステップ1：体制づくりとキックオフ
最初に決めるのは要件そのものではなく、決め方です。会議体（誰が・どの頻度で集まるか）、決定事項の記録方法、保留事項の管理方法、工程の完了条件を、双方で合意します。ここを飛ばすと、以降のすべての決定が「言った・言わない」のリスクを抱えます。
| 発注者がやること | ベンダーがやること |
|---|---|
| 参加メンバーと決裁ルートを確定する 現場担当者の稼働を業務として確保する 社内資料（業務フロー・帳票・現行画面）を提供する | 工程全体のスケジュールと会議体を設計する 成果物の一覧と完了条件を提示する 決定・保留・宿題の管理方法を提示する |
ステップ2：ヒアリングと現状分析
ベンダーが業務を理解する段階です。発注者の仕事は「上手に説明すること」よりも、「実物を見せること」と「例外を隠さないこと」です。きれいに整理された建前の業務フローだけを渡すと、例外処理が後から噴出します。
| 発注者がやること | ベンダーがやること |
|---|---|
| 実物（帳票・画面・データ）を見せる 例外業務・現場ルールも含めて話す ヒアリング記録を確認し、事実誤認をその場で正す | 仮説を持って質問を設計する 聞いた内容を文書化し、早いうちに確認へ出す 現状の課題を構造として整理する |
ステップ3：要求の整理と優先順位づけ
集めた要求をすべて叶えることはできません。このステップの主役は優先順位です。MoSCoW法（Must／Should／Could／Won’t＝必須・重要・あれば良い・今回やらない）のような枠組みで仕分けし、とくに「今回やらないこと」を明文化します。
| 発注者がやること | ベンダーがやること |
|---|---|
| 要求の背景（なぜ必要か）を説明する 部門間の優先順位の衝突を調整する 「今回やらないこと」の判断を下す | 要求を構造化し、粒度を揃える 優先度案と、実現手段・費用への影響を提示する 技術的な依存関係（Aを外すとBもできない等）を示す |
ステップ4：要件の確定と文書化
優先順位のついた要求を、要件定義書として文書に固定する段階です。執筆はベンダーの仕事ですが、レビューは発注者の仕事です。レビューの観点は文章の巧拙ではなく、「これで自分の部門の業務が回るか」。成果物の書式や記載項目の詳細は要件定義の基礎知識を参照してください。
| 発注者がやること | ベンダーがやること |
|---|---|
| 業務の実態と合っているかの観点でレビューする 不明な用語・記述を放置せず質問する 保留事項の決着期限を確認する | 要件定義書を執筆する 決定事項と保留事項を明確に区別して書く 専門的な内容を発注者が検証できる表現に翻訳する |
ステップ5：合意形成と開発への引き継ぎ
最後に、決裁者を含めた承認の場を設けます。担当者間では合意できていたのに決裁者が初見で差し戻す、という事故を防ぐため、決裁者には途中経過の段階から要点を共有しておきます。承認後は「ここから先の変更には影響が伴う」ことを社内に周知し、変更管理のルールとともに開発工程へ引き継ぎます。
| 発注者がやること | ベンダーがやること |
|---|---|
| 決裁者を含めた承認を取り付ける 確定した要件と変更ルールを関係部門へ周知する | 承認用に要点を要約した資料を用意する 変更管理ルール（受付・影響評価・合意の手順）を提示する 要件を設計・開発計画に落とし込む |
要件定義でよくある失敗と回避策
失敗1：「決めたつもり」で決まっていない
会議で話し合ったことと、決まったことは別物です。「あの件はあの場で決まったはず」という認識のずれは、数ヶ月後に設計の手戻りとして返ってきます。回避策は単純で、会議のたびに決定事項・保留事項・宿題を文書にし、その場で読み合わせてから解散することです。議事録を後日回覧する方式は、読まれないまま確定扱いになる点で危険です。
失敗2：後出しの要求でスコープが膨らむ
工程が進んで理解が深まるほど、「そういえばこれも」という要求は自然に湧いてきます。問題は要求が出ること自体ではなく、受け皿がないことです。ステップ3で作った優先順位と「今回やらないことリスト」が受け皿になります。新しい要求はいったんリストに載せ、優先順位の枠組みの中で判断すれば、その場の声の大きさでスコープが膨らむことを防げます。
失敗3：部門間の要求衝突が終盤に噴出する
営業部門と管理部門で求めるものが正反対だった、という衝突は、終盤に発覚するほど高くつきます。NTTデータ経営研究所が2023年に公開したシステム調達に関するレポートも、調達成功の核として部門横断の合意形成を挙げています。前述のIPAガイドが言う業務部門の主体的関与も同じ論点で、回避策は関係部門を最初のステップから会議体に組み込むことに尽きます。「後で説明すればいい」という部門の扱いが、後の火種になります。
要件定義書に何を書くか（詳しい書式は別記事で）
要件定義の成果物は、要件定義書を中心に、業務フロー図・画面一覧・機能一覧などで構成されます。ただし成果物の網羅性より大切なのは、書かれた内容を発注者が読んで検証できることです。発注者が読めない文書は、どれだけ厚くても合意の道具になりません。
要件定義書の記載項目や要件の分類の詳しい解説は要件定義の基礎知識（要件定義とは・要件定義書の書き方）にまとめています。本記事の5ステップとあわせて読むと、運びと成果物の両面から工程の全体像がつかめます。
AI駆動開発時代に要件定義はどう変わるか
生成AIを開発工程に組み込むAI駆動開発の広がりは、要件定義の進め方そのものを変えつつあります。変化の中心は、「文書で合意してから作る」から「動くものを見ながら決める」への移行です。プロトタイプの作成コストが下がったため、ヒアリングで聞いた要求を画面の形にして翌週の会議で見せる、という運びが現実的になりました。文章の解釈のずれは、動く画面の前では一瞬で表面化します。Swoooの受託開発でも、AI駆動開発とノーコード開発を組み合わせ、最短2週間でMVP（検証用の最小プロダクト）を納品した実績があります。
もう1つの変化は、要件定義の重心が「整理」から「決断」へ移ることです。議事録の整理、要求の構造化、文書ドラフトの作成といった作業は、AIの補助で速くなります。速くならないのは、どの業務を変えるか、何を今回やらないか、部門間の対立をどう裁くかという判断です。整理の工数が下がった分、工程の価値は発注者の決断の質と速度に集中していきます。あわせて、発注側の事前準備の価値も上がります。材料（実物・例外・困りごと）が揃っているほどAIによる整理と試作が効くため、準備の差がそのまま工程全体の速度差になります。
なお、こうした進め方ができるかどうかはベンダーの体制次第です。発注先を選ぶ段階で、生成AIの使いどころと検証体制を確認する項目をRFPに入れておくと、要件定義の進め方まで含めて比較できます。詳しくはRFP（提案依頼書）の書き方のAI駆動開発の章で解説しています。
要件定義の費用の目安
要件定義の費用は、開発全体の見積もりに含まれる場合と、要件定義だけを独立した契約（準委任契約が一般的）で先行させる場合があります。不確実性が高い案件ほど、要件定義を切り出して先行させるほうが、発注側・受託側の双方にとって見積もりの無理がなくなります。金額の相場はプロジェクトの規模と進め方で変わるため、システム開発の費用相場と見積もりの読み方で規模別に整理しています。
よくある質問・まとめ
Q. RFPと要件定義はどう違うのですか？
RFP（提案依頼書）は発注先を選ぶために発注側が作る文書、要件定義は発注先が決まった後にベンダーと共同で「何を作るか」を確定する工程です。時系列ではRFPが先で、RFPに書いた要求が要件定義の入力になります。作り方はRFPの書き方（テンプレートつき）で解説しています。
Q. 要件定義の期間はどのくらいかかりますか？
小規模なら数週間、業務システムの刷新など規模が大きければ数ヶ月が目安です。期間を左右する最大の変数はベンダーの作業速度ではなく、発注側の意思決定の速度です。会議で決めきれず持ち帰りが続くと、その分だけ工程は延びます。決裁ルートの整備と現場の時間確保という事前準備が、結果的に最も効く短縮策です。
Q. 要件定義はベンダーに任せきりにできますか？
できません。ベンダーが肩代わりできるのは整理と文書化であって、「自社の業務がどうあるべきか」の判断は発注者にしかできないためです。IPAの要件定義ガイド（2019年）が業務部門の主体的関与を繰り返し求めているのも同じ理由です。任せきりの結果として出来上がるのは、文書としては整っているのに業務に合わないシステムです。
Q. 要件定義の途中で要求が変わったらどうすればいいですか？
変わること自体は正常です。重要なのは、変更を受け付ける手順（受付→影響の評価→優先順位の中での判断→合意）をキックオフ時点で決めておくことです。手順があれば変更は管理できますが、手順がないまま個別対応を重ねると、スコープと期間が気づかないうちに膨らみます。
最後に、本記事の要点を整理します。
- 要件定義は発注者が「参加する」工程ではなく「決める」工程。決める体制と段取りの設計が成否を分ける
- 始める前に、業務の実物・例外ルール・困りごとの棚卸しと、決める人の任命・現場の時間確保を済ませる（IPA「ユーザのための要件定義ガイド 第2版」の言う業務部門の主体的関与）
- 進め方は、体制づくり→ヒアリングと現状分析→要求の整理と優先順位づけ→要件の確定と文書化→合意形成の5ステップ。業務と判断は発注者、構造化と実現手段はベンダーという役割分担
- 失敗の型は「決めたつもり」「後出しスコープ」「部門間衝突の終盤噴出」。決定事項の即時文書化、今回やらないことリスト、関係部門の初期からの参加で防ぐ
- AI駆動開発により、動くものを見ながら決める進め方が現実的になり、工程の重心は整理から決断へ移りつつある
本メディアを運営するSwooo（東証グロース上場・株式会社アイビス、証券コード9343）は、Claude Codeなどを使ったAI駆動開発とノーコード開発による受託開発で、累計50件以上の開発を支援してきました。要件定義では動くプロトタイプを早期に提示する進め方を取り入れており、最短2週間でのMVP納品実績があります。「要求がまだ固まっていない」という段階からのご相談に対応します。
あわせて読む：RFP（提案依頼書）の書き方：テンプレートとベンダー選定の流れ／要件定義の基礎知識（要件定義とは・要件定義書の書き方）／システム開発の費用相場と見積もりの読み方
