要件定義の進め方と5W2H・要件定義書の書き方

要件定義がうまく進まないプロジェクトは、たいてい要求を集める前に目的を決めていないか、集めた要求を絞り込まないまま要件定義書を書き始めています。進め方の順番と、決めるべき項目の抜け漏れを確かめる型があれば、経験の浅い人が担当しても崩れにくい工程です。

要件定義の進め方を5つのステップに分け、5W2Hでの確かめ方、要件定義書と業務フローの書き方、失敗を防ぐ勘どころをまとめました。後半では、要件定義の経験がプロダクトマネージャー（PdM）の求人でどう求められているかを、Offers に掲載された求人の集計から確かめています。

要件定義はシステムで実現することを決めて関係者と合意する工程

要件定義は、システムやソフトウェアの開発で、利用者や業務部門の要求を整理し、システムが備える機能と品質を文書にまとめて関係者と合意する工程です。開発は要件定義、設計、実装、テストの順に進み、要件定義で決めた内容が後のすべての工程の前提です。

IPA（情報処理推進機構）は「ユーザのための要件定義ガイド 第2版」（2019年）の紹介ページで、システムの要件を定義する責任は、システムを使ってビジネスに貢献するユーザ側にあると言われていると書いています。IT ベンダやシステム部門に任せきりにせず、業務部門が主体的に関わる進め方への転換を促す内容です。

要求定義と要件定義の違い

要求は利用者や業務部門の「こうしてほしい」という希望で、要件は、その要求を文書にして仕様に落とし、関係者と合意したものです。IPA の要件定義ガイド第2版も、要求を文書化・仕様化してステークホルダと合意したものを「要件」と定義し、要件は次の工程へ渡すために第三者へ伝わる形にしておく必要があると書いています。

同じガイドは、規格（JIS X 0166）の注記で requirement が「要求」とも「要件」とも訳されることを挙げ、要求と要件に標準的な定義は無いとも断っています。実務では、要求を集めて整理する段階を要求定義、実現の方法と範囲まで決める段階を要件定義と呼び分けるのが一般的です。要求を並べただけの文書は、どう実現するかが書かれていないため設計の入力になりません。

要件定義は開発の工期の2割強を占める

IPA の「ユーザのための要件定義ガイド 第2版」は、日本情報システム・ユーザー協会（JUAS）の「ソフトウェアメトリックス調査2016」をもとに、要件定義からユーザー総合テストまでの工期のうち要件定義が占める割合を、76件の合計で22.5%と示しています（表2.1）。開発の規模や新規・改修の別で分けても20.1〜24.3%の範囲に収まり、規模が大きくなっても要件定義にかかる期間の比率はほとんど変わりません。

一方、投入した工数（人手の量）に占める要件定義の割合は、同じ調査をもとにした表2.2で78件の合計9.6%にとどまります。要件定義は期間の割に投入する人手が少なく、実装やテストと違って人を増やしても進み方が速くなるとは限らない工程だというのが、この2つの表についてのガイドの読み方です。

同じガイドは、同調査で479プロジェクトの担当者に工期遅延の理由を尋ねた結果から、遅延の理由の50%以上が要件定義の問題にあると読み取っています。要件定義を急いで未決の事項を残すと、設計・実装・テストの期間と負荷が膨らむというのがガイドの指摘です。そのため要件定義には本当に必要な人を割り当て、十分な期間を与えることを、ガイドは成功の条件に挙げています。

要件定義の進め方は5つのステップに分かれる

要件定義は、目的と現状の把握、要求の洗い出し、要求の分析と優先順位付け、要件への落とし込み、要件定義書による合意、の5つのステップで進めます。IPA の要件定義ガイド第2版による要件定義の区分は、ビジネス要求定義（獲得・分析・文書化）、システム化要求定義（仕様化・確認と評価）、要件定義マネジメント（立上げから終結まで）の3つです。5つのステップは、この区分を実務の順番に並べ直しました。

ステップ1と2では目的を決めてから要求を集める

要求を集める前に決めておくのは、システムを作る目的と、達成したときに何がどう変わるかを示す定量的な目標です。目的が無いまま要求を集めると、声の大きい部署の要望がそのまま機能の一覧になり、優先順位を付ける基準がなくなります。

要求の洗い出しでは、欲しい機能を聞くだけでなく、「今の業務のどこで時間がかかっているか」「どの操作に不満があるか」を重ねて尋ね、利用者自身が言葉にしていない潜在的な要求まで引き出します。現行の業務フロー（As-Is）を利用者と一緒に描きながら聞くと、手作業で補っている工程や二重入力の箇所が見つかりやすくなるはずです。

ステップ3では要求を絞り込んで範囲を決める

集めた要求はすべてを実装するのではなく、矛盾や重複を整理したうえで、目的への貢献の大きさと実現のコストで優先順位を付けます。要求を全部盛り込んだシステムが、利用者の課題を解決するとは限りません。

どこまでをシステム化し、どこからを今回の対象外にするかという開発範囲（スコープ）も、この段階で文書に残す項目です。対象外にした要求も理由とともに一覧に残しておくと、後になって「頼んだはずの機能が無い」という食い違いが起きにくくなります。

ステップ4と5では要件に落として合意を文書で残す

優先順位を付けた要求は、業務要件・機能要件・非機能要件に分けて書き、要件定義書にまとめます。書き方の詳細は、後の「要件定義書は概要・業務要件・機能要件・非機能要件の4部で書く」の節が扱う内容です。

要件定義書は、発注側と開発側、業務部門と開発チームの双方がレビューし、承認を得て初めて要件として確定する文書です。合意の後に要件を変えるときに、誰が変更を決め、影響する範囲と費用・納期がどう変わるかを記録する変更管理の手順も、この段階で決めておきます。

5W2Hで要件定義の抜け漏れを確かめる

5W2Hは、Why（なぜ）・What（何を）・Where（どこまで）・When（いつまでに）・Who（誰が）・How（どうやって）・How much（いくらで）の7つの問いで、要件定義では、決めるべき項目が抜けていないかを確かめるチェックリストとして使えます。要件定義のために作られた型ではなく、計画や問題の整理に広く使われる問いの型です。それでも7つの問いは、それぞれ要件定義書のどこかの項目に対応します。

Why・What・Whereで目的と手段と範囲を決める

Why・What・Where の3つは、目的、手段、範囲の順に決める問いです。最初に Why で「なぜ作るのか」を決め、What で目的を達成する手段としての機能を決め、Where で今回の開発にどこまでを含めるかというスコープを決めます。

この順番を崩して What から入ると、目的に結びつかない機能が一覧に並びます。スコープを決めないまま進めた場合も、手当たり次第に機能を広げて、どれも中途半端なシステムになりがちです。

When・Howで納期と実現の方法を決める

When と How は、いつまでに、どの方法で実現するかを決める問いです。納期の決まり方には、発注側から完成時期の希望が示される場合と、必要な工程から日数を積み上げて決める場合の2通りがあり、どちらでも納期から逆算してマイルストーンを置きます。

How で決めておくのは、機能を実現する方式や、既存のシステムとの連携の方法です。実現の方法を要件定義の段階で確かめておけば、設計に入ってから「この方式では実現できない」と行き詰まる事態を減らせます。

Who・How muchで体制と費用を決める

Who と How much は、誰が担い、いくらで作るかを決める問いです。Who では、プロジェクトの役割と体制に加えて、要件を最終的に承認する人を決めます。承認者が曖昧なまま進めると、終盤に別の部署から要求が追加されても、受け入れるか断るかを誰も決められません。

How much は、ほかの6つの見通しが立った段階で見積もる費用です。開発費用だけでなく運用・保守の費用まで含めて見積もっておくと、稼働した後に予算が足りなくなる事態を防げます。

要件定義書は概要・業務要件・機能要件・非機能要件の4部で書く

要件定義書は、概要、業務要件、機能要件、非機能要件の4部を階層構造で書くのが基本です。書式は会社やプロジェクトによって異なりますが、この4部を押さえておけば、目的から機能、品質までを関係者全員が同じ順序で読めます。

要件定義書を作る目的は、完成するシステムの姿を発注側と開発側で共有し、作り始める前に合意しておくことです。書式が決まっていないからこそ、読む人が迷わない構成と書き方を選ぶことが、そのまま合意の取りやすさにつながります。

概要には背景と目的と定量目標を書く

概要に書くのは、システム開発に至った背景と、開発の目的と目標です。目的はシステムで何を実現したいか、目標はそれが達成されたと判断する指標で、「請求書の作成にかかる時間を月20時間減らす」のように数値で書くと、関係者のあいだで認識がずれにくくなります。

背景には、発注側がなぜこのシステムを必要としたのかという経緯を書きます。開発の途中で方向を見失ったときに立ち返る拠り所になり、後から加わったメンバーが判断の前提を知る手がかりにもなる項目です。

業務要件は現状と稼働後の業務フローで示す

業務要件は、目的を達成するために業務がどう変わるかを、現状の業務フロー（As-Is）とシステム稼働後の業務フロー（To-Be）の2枚で示す要件です。2枚を並べると、どの作業がシステムに置き換わり、どの作業が人の手に残るかが見え、システム化の範囲を決める根拠になります。

業務の流れは文章だけで書くと読み取りにくいため、業務フロー図に描きます。読みやすい業務フロー図にするための約束ごとは、次の3つです。

• 開始点と終了点を明確にし、流れを一方向にそろえる（線の交差を避け、分かれる箇所は分岐で表す）
• 使う図形を、開始と終了を表す端子、作業を表す処理、Yes と No で分かれる判断の3種類に絞る
• 担当者や部署ごとに列を分け、判断の分岐は色で区別する

業務フロー図は開発チームだけでなく、利用者との仕様の確認にも使う資料です。図形の種類を増やしすぎず、色やアイコンで直感的に読めるようにしておくと、確認の場で読み違いが起きにくくなります。

機能要件は利用者の操作とシステムの処理を書く

機能要件は、業務要件でシステム化すると決めた範囲で、利用者が何をどう操作し、そのときシステムがどんな情報を管理・処理するかを書く要件です。画面ごと、帳票ごと、外部システムとの連携ごとに一覧にすると、抜けや重複に気づきやすくなります。

開発側だけで機能を決めると、実際には使われない機能が増えがちです。実際に使う人の操作を確かめながら、目的に必要な機能に絞ることが、使いやすさと開発費用の両方を守ります。

非機能要件はIPAの非機能要求グレードで漏れを防ぐ

非機能要件は、性能・可用性・セキュリティのように、利用者の目に直接触れないシステムの品質を決める要件です。IPA が公開する「非機能要求グレード」は、非機能要求の項目を網羅的に並べ、それぞれの要求の水準を段階で示したツールで、ユーザと開発者の認識の行き違いを防ぐことを目的にしています。要件定義ガイド第2版の説明では、非機能要求グレードが扱う領域は、可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6つです。

非機能要件はどのシステムでも検討する項目が似ているため、こうした一覧を土台にして、重要な項目から水準を決めていくと抜けを防げます。たとえば運用時間なら、平日の日中だけ動けばよいのか、24時間止めずに動かすのかで、必要な構成と費用が大きく変わります。

読み手を選ばない書き方にして合意を取りやすくする

要件定義書は、開発の専門知識を持たない業務部門や経営層も読んで承認する文書です。専門用語は最小限にとどめ、使うときは用語集や注記で説明を添え、図や表で示せるものは図表にします。

見出しを階層で整理し、1つの要件を1か所にだけ書いて重複させないと、変更が出たときの直し漏れも防げます。発注側と開発側のどちらか一方しか読み解けない要件定義書は、合意の文書として役に立ちません。

要件定義の失敗を防ぐ4つの勘どころ

要件定義の失敗を防ぐには、決める人を最初に決める、要求と要件を分けて記録する、打ち合わせの結論を毎回文書で残す、十分な期間と適任の人を割り当てる、の4点を押さえます。いずれも IPA の要件定義ガイド第2版が扱う論点（オーナーの選定、要求と要件の区別、コミュニケーション、工期と工数の割り当て）と重なる内容です。

• 決める人を最初に決める。部署ごとの要求はぶつかることがあり、最終的に判断する人（オーナー）がいないと合意がまとまらないため、誰が承認するかを始める時点で関係者に示す
• 要求と要件を分けて記録する。「こうしてほしい」という要求と、実現すると合意した要件を同じ一覧に混ぜると何が約束なのかが曖昧になるため、採用しなかった要求も理由とともに残す
• 打ち合わせの結論を文書で残す。発注側の都合で打ち合わせの回数が限られても、毎回の結論と未決の事項を文書で共有し、完成イメージのずれを早めに見つける
• 期間と人を惜しまない。IPA のガイドは、要件定義では人数を増やしても進み方が速くなるとは限らないとし、本当に必要な人に十分な期間を与えることを成功の条件に挙げている

要件定義の経験はPdMの求人で多く求められる

Offers に掲載された正社員求人のうち、題名がプロダクトマネージャー・プロダクトオーナー系の求人（PdM・PO職）の45.7%が、求人本文で要件定義に触れていました（Offers（株式会社overflow）調べ・PdM・PO職の正社員求人 n=105・2026年10月集計）。エンジニア職の35.6%、デザイナー職の20.4%より高く、要件定義は PdM の求人が最もよく挙げる業務の1つです。

要件定義を担ってきた経験が PdM やプロダクト開発の求人でどう評価されるかは、Offers に経歴を登録して届くスカウトと、正社員求人の業務内容を並べて見ると確かめられます。

出所: Offers（株式会社overflow）調べ・正社員求人（n=3,317）・2026年10月集計。

PdMの求人は要件定義と並べてロードマップと優先順位を求める

PdM・PO職の求人本文で最も多く出る語はロードマップ（51.4%）で、要件定義（45.7%）、ステークホルダー・関係者（42.9%）、優先順位（38.1%）が続きます。PdM の求人が求めているのは、要件を正確に書く力に加えて、何を先に作るかを決め、関係者の合意をまとめる役割です。

出所: Offers（株式会社overflow）調べ・PdM・PO職の正社員求人（n=105）・2026年10月集計。

5W2Hに当てはめると、PdM の求人が重く見ているのは、Why（目的と目標）と Where（範囲と優先順位）を決める側の経験です。決まった要求を文書にまとめる役割として要件定義を担ってきた人と、何を作り何を作らないかを決めてきた人とでは、PdM の選考で語れる中身が変わります。

プロダクトオーナーとの役割の違いは「プロダクトオーナーとは」、要件を優先順位つきで管理する方法は「バックログとは」、納期と予算に責任を持つプロジェクトマネージャーとの違いは「ITのプロジェクトマネージャーとは」にまとめています。

要件定義という語だけでは提示年収は上がらない

エンジニア職の求人のうち、本文で要件定義に触れる求人の提示年収の上限の中央値は900万円で、触れない求人の975万円より低くなっていました。要件定義に触れる求人は、受託開発やシステムインテグレーション（SI）の語が本文に出る割合が38.8%と、触れない求人の26.1%より高くなっています。ただし自社サービス・自社プロダクト・自社開発の語が出る割合も22.8%と17.5%で同じ向きに高く、年収の差の理由はこの集計からは決められません。

出所: Offers（株式会社overflow）調べ・年収を記載したエンジニア職の正社員求人（n=2,240）・2026年10月集計。

一方、PdM・PO職の求人は上限の中央値が1,000万円で、上限が1,000万円以上の求人が72.8%を占めていました（Offers（株式会社overflow）調べ・年収を記載した PdM・PO職の正社員求人 n=103・2026年10月集計）。

年収を記載した正社員求人全体では、上限が1,000万円以上の求人は47.5%です（Offers（株式会社overflow）調べ・n=3,264・2026年10月集計）。要件定義の経験はそれだけで提示年収を押し上げるものではなく、プロダクトの方向と優先順位を決める役割まで広げたときに、年収帯の高い PdM の求人の条件と重なります。

職務経歴書には要件定義で何を決めたかを書く

PdM の求人に応募するときは、要件定義を「担当した」と書くだけでなく、何を決め、その結果どうなったかを書きます。求人本文で多く挙がる語に合わせると、書く材料は次の3つです。

• 目的と目標（どの課題に対して、どの数値を目標に置いたか）
• 範囲と優先順位（集めた要求のうち何を採用し、何を見送ったか、その判断の基準は何だったか）
• 合意形成（どの部署とどの部署の要求がぶつかり、どう合意に導いたか）

受託開発で要件定義を担ってきた人も、発注側の目的を聞き出してスコープを提案した経験は、PdM の「何を作るかを決める」仕事と地続きです。職務経歴書の全体の構成と書き方は「エンジニアの履歴書・職務経歴書｜52人調査と書き方」で扱っています。書き上げた経歴で届くスカウトの職種と年収帯は、Offers に登録すると確かめられます。