要件定義の完全ガイド 要件定義書の記入例とテンプレート付き。議事録から作る範囲・完成条件・テストまで決める

要件定義の目的は、きれいな仕様書を作ることではありません。「作ったのに違う」「そこまで含むと思っていた」「完成したと言われたけれど業務では使えない」を、開発の後ではなく前に減らすことです。

私がこれまで相談を受けたり、途中から引き継いだりした案件では、欲しい機能は書かれていても、なぜ必要なのか、今回は何を作らないのか、どこまで動けば完成なのかが整理されていないケースを何度も見てきました。すると開発が進むほど、発注側と開発側の「当然」がずれていきます。

Beekleでは、打ち合わせで出た要望をそのまま仕様書へ写しません。まず、誰のどの仕事をどう変えたいのかを確認します。そのうえで、効果が大きいか、予算や期間の中で作れるか、現場で実際に使えるかを見て、今回作るもの・後回しにするもの・作らないものを決めます。さらに、どの状態で何をするとどうなれば完成なのかまで具体化し、その条件をそのままテストへつなげます。

このやり方をすると、不要な機能に予算を使いにくくなり、発注側と開発側で「完成」の意味をそろえやすくなります。途中で仕様が変わっても、どこを直し、何を再確認する必要があるか追いやすくなります。つまり、作る前の勘違いと、作った後の手戻りを減らすための要件定義です。

たとえば「経費精算を楽にしたい」という相談でも、領収書の入力を減らしたいのか、上司の承認を早くしたいのかで、必要な機能は変わります。まず困っている作業を特定し、その作業をどう変えるかを決めます。そのうえで、必要な機能、利用できる人、処理のルール、動作の確認方法を具体化します。

この記事では、経費精算を例に、議事録や文字起こしから要求を整理し、FMで評価して開発範囲を決め、開発担当者へ渡すまでの手順を説明します。後半では、実装後のテストと変更への対応も扱います。経費精算の業務・人物・金額は説明用の架空の例です。Beekleの引き継ぎ事例とは区別して紹介します。

進める順序は、議事録・文字起こし → 要求の整理 → FMによる評価と採否判断 → 必要に応じてMoSCoWでリリースの優先順位付け → 開発範囲の合意 → ユーザーストーリー単位で整理 → シナリオをGherkinで具体化、です。その後、運用条件も含めて要件を合意し、実装とテストへ進みます。

要件定義で決める主な項目は、次の5つです。

1. 議事録・文字起こしと実際の資料で、現在の業務を確認する

最初に、打ち合わせの議事録や録音の文字起こし、普段使っている申請書や表計算ファイル、既存システムの画面などを集めます。システムを作り直す案件なら、コード、問い合わせ履歴、障害の記録も確認します。

今回の例では、社員が紙で申請し、上司が承認した後、経理担当者が金額を管理表へ転記しています。申請書と管理表を見比べれば、どの情報を二度入力しているかが分かります。経理担当者には、転記だけでなく、照合や入力ミスの修正にかかる手間も聞きます。

「経費精算が大変」という発言だけで判断せず、誰が、どの作業に困っているかを確かめます。申請内容の不備が多い場合と、転記に時間がかかる場合では、見直す業務が違うからです。

ここを飛ばすと、「言われた機能は作ったのに、肝心の仕事は楽になっていない」という状態が起きます。要望を聞くことと、問題を理解することは別です。

新しいサービスで既存の業務や資料がない場合は、想定する利用者、利用場面、解決したい問題を会話やメモに残すところから始めます。議事録やAIとの対話記録も材料になりますが、思いついた案と決定事項は分けて扱います。

2. 欲しい機能だけでなく、必要な理由と目標を書く

「承認ボタンが欲しい」と言われたら、先に理由を確認します。承認待ちを短くしたいのか、誰が承認したかを記録したいのか。それによって、必要な仕組みが変わります。

今回の例では、経理担当者の転記作業と、その際の入力ミスを減らすことを目指します。こうした「実現したいこと」を、この記事では要求と呼びます。

要求：経費申請の転記作業と入力ミスを減らしたい
困っている人：経理担当者
現在の作業：承認済みの紙の申請書を見て、金額を管理表へ入力している
目指す状態：社員が入力した申請内容を、入力し直さずに一覧で確認できる
根拠となる資料：経費申請書、経理の管理表、打ち合わせの議事録・文字起こし

要求ごとに、元の議事録や文字起こしの該当箇所を参照できるようにしておきます。AIで整理する場合も、発言から読み取れた要求と、AIが補った提案は分けます。次のFM評価では、要求の根拠と不足している情報を確認しながら判断します。

この記事では、「何を改善したいか」という実現したいことを要求、それをシステムで実装し、あとから確認できる条件まで具体化したものを要件と呼びます。たとえば「経理担当者の転記作業と入力ミスを減らしたい」という要求を、「上司が承認した申請は、申請者・金額・領収書を経理担当者の一覧から確認できる」といった要件へ具体化します。

「何を改善したいか」と「システムをどう動かすか」を分けておくと、新しい機能の要望が出たときに、元の問題を解決するために必要かどうかを判断できます。業務改善の効果も測るなら、導入前の転記件数や所要時間を記録し、導入後の目標も決めておきます。

この一段を入れておくと、「なんとなく欲しい機能」に予算を使うのではなく、元の問題を減らすために必要な機能へ予算を集中できます。

3. 「欲しい」だけでは作らない。効果・作りやすさ・現場運用で開発範囲を決める

要求を並べたら、すぐに「必須」「あると便利」と分類するのではなく、実現する価値があるか、技術的に実現できるか、現場で運用できるかを確認します。Beekleでは、そのためにFM（ファンクショナリティ・マトリクス）を使います。FMは「システムに求める機能」や機能要求を一覧にして開発範囲を判断する方法として使われますが、Beekleでは、まだユースケースや具体的な画面・操作へ分解されていない要求レベルでまず評価します。「承認ボタンを作る」といった解決策を先に固定せず、「承認待ちを減らしたい」「再入力をなくしたい」といった実現したいことの段階で、価値・実現性・現場運用を見て採否を決めるためです。採用した要求を、その後ユーザーストーリーやGherkinのシナリオへ具体化します。

価値が高くても、予算内で作れないならそのまま作らない。技術的に作れても、現場が使えないならそのまま作らない。FMの価値は、名前や表の形式ではなく、この判断を開発前にできることです。

3-1. FMの3軸で評価する

各軸はH（高）・M（中）・L（低）で評価し、理由を残します。技術的容易性のHは「実現しやすい」という意味です。「技術コスト」として表す場合は向きが逆になり、コストが低いほど技術的容易性は高くなります。

評価に必要な情報がなければ、無理にH・M・Lを付けず、未評価として確認担当者と期限を決めます。たとえば「会計ソフトの連携仕様をまだ調べていない」と「調べた結果、予算内では連携できない」は別の状態です。評価軸や基準を案件に合わせて追加・調整する場合も、関係者で先に共有します。

3-2. 評価を基に「作る・後回し・作らない」を決める

ここでは、Beekleで判断をそろえるために使っている例として、FMの判定を次のように整理します。白・グレー・黒は評価点ではなく、開発範囲の区分です。この判定ルール自体がFMに共通する唯一のルールというわけではありません。この記事の例では「どれか一つでもL」を先に確認するため、H・H・Lは白ではなく黒になります。

次は、経費精算の要求を評価した架空の例です。評価はこの例で置いた条件に基づくもので、同じ要求がどの会社でも同じ判定になるわけではありません。

たとえば会計ソフトへの連携は、効果だけを見れば重要です。しかし、この例では技術・予算の条件を満たせないため外しています。これが、単に「欲しい機能へ優先度を付ける」こととFMの違いです。要求自体は削除せず、条件が変わったときに見直せるよう、判断の根拠を残します。

業務に不可欠な要求が黒になった場合は、それを無視して開発を進めるのではなく、実現方法、対象範囲、予算や体制を見直します。FMの判定は、その時点の条件に基づく判断であり、今後も永久に作らないという意味ではありません。

ここで「作らない」を決められるほど、重要なところに予算と時間を集中できます。要件定義は機能を増やすためではなく、開発範囲を減らすためにも使います。

3-3. 必要に応じてMoSCoWで初回リリースの優先順位を決める

FMを使って開発全体の採否を決め、その後のリリース計画をMoSCoWで整理します。FMで白にした要求について、初回リリースで必ず入れるものをMust、重要だが代替手段があるものをShould、余力があれば入れるものをCouldとして整理します。FMでグレーや黒にした要求も、「このリリースでは扱わない」とスコープを明示したい場合はWon'tとして併記できます。FMで白にした範囲を一度に提供できるなら、MoSCoWを使うためだけに工程を増やす必要はありません。

FMの白は「今回の開発全体で作る」、この表のMust・Should・Couldは「その中で初回リリースにどこまで含めるか」の判断です。FMでグレーや黒にした要求を、評価を見直さずにShouldやCouldへ入れ直してはいけません。Won'tとして併記する場合も、FM側の判定は変えません。グレーなら「条件が整えば再検討する」、黒なら「現在の条件では採用しない」という違いをFM側に残します。

優先度を付けたら、予算と期限を踏まえ、各リリースに含める範囲を発注側と開発側で合意します。通知を初回に含めない場合は、提供時期と、それまでの代替手段も決めます。今回の開発全体から外すなら、FMもグレーへ更新します。

この例では、管理表への転記はなくしますが、会計ソフトへの登録作業は残ります。「経費精算を自動化する」とだけ書かず、どの作業をなくし、どの作業は残すのかまで明記します。

評価方法はFM法の使い方、両者の役割分担はFM法とMoSCoWの使い分けで詳しく説明しています。

4. ユーザーストーリーでシナリオを束ね、完成した範囲を把握する

FMで採用し、今回のリリースに含めると合意した要求を、利用者の目的ごとに整理します。Beekleでは、採用した要求をユーザーストーリーとして目的単位に整理し、その下に具体的な動作条件をシナリオとして関連付けます。ここでユーザーストーリーを使うのは、開発が大きくなっても、利用者が何をできるところまで完成したかを把握できるようにするためです。

これで防ぎたいのは、「進捗80％です」と言われたのに、利用者がまだ何も完了できない状態です。作業量ではなく、実際に使える目的単位で進捗を見ます。

4-1. タスクの完了数だけでは、何が完成したか分からない

経費精算の開発でも、「申請画面を作る」「金額の入力チェックを作る」「申請を保存する処理を作る」「承認者の一覧へ表示する」と、作業は複数のタスクに分かれます。機能や担当者が増えるほど、タスクの数も増えていきます。

個々のタスクに完了の印が付いていても、それだけでは「社員が申請を提出できるようになったか」は分かりません。画面と保存処理ができていても、提出した申請が承認者の一覧に出なければ、申請を渡すところまでは完成していないからです。

タスクを一覧に並べるだけでは、どの機能のどの部分まで終わっていて、何が残っているかを、そのつど担当者に聞いて組み立て直す必要があります。シナリオも個別に並べるだけでは、それぞれがどの利用者の目的に対応するのか見えにくくなります。

4-2. 同じ目的のシナリオを、ユーザーストーリーにまとめる

ユーザーストーリーには、利用者の立場、したいこと、その目的を書きます。たとえば「社員として、領収書と金額を登録して経費申請を提出したい。紙の申請書を回さずに申請を済ませるため」と書きます。

この目的を実現するために、どのような場面でどう動けばよいかを具体的に書いたものがシナリオです。同じユーザーストーリーの下に、正常に処理できる場合、入力に不備がある場合、金額などの境界で判断が変わる場合をまとめます。

ユーザーストーリー：社員が経費申請を提出する
  シナリオ：必要な情報がそろっていれば、申請が承認待ちになる
  シナリオ：領収書がなければ、提出を受け付けず理由を表示する
  シナリオ：金額が上限と同じなら、提出を受け付ける
  シナリオ：金額が上限を超えていれば、提出を受け付けない

それぞれのシナリオに、実装タスクとテスト結果を関連付ける

この例の細かな業務ルールとGherkinでの書き方は、次の章で具体化します。後回しや不採用にした要求まで、同じ細かさでシナリオを作り込む必要はありません。

タスクでは「何の作業を終えたか」、シナリオでは「どの条件で期待どおりに動くか」、ユーザーストーリーでは「利用者のどの目的を実現できたか」を確認します。一つの実装タスクが複数のシナリオに関係する場合もあります。その場合は同じタスクを関連付け、シナリオごとに複製して別々に管理しないようにします。

こうしてまとめておけば、まずユーザーストーリー単位で完成した範囲を確認し、未完了のものだけシナリオとタスクをたどれます。「社員の申請は確認済みだが、上司の差し戻しは未完成」と説明でき、細かなタスクをすべて覚えていなくても、開発全体の残りを把握しやすくなります。ユーザーストーリーが増えた場合は、元の要求や業務ごとにまとめて一覧にします。

5. 「申請できる」を、誰が確認しても同じ結果になるところまで決める

「申請を提出できる」を、実装後に確認できる条件へ具体化します。自分の画面に保存されるだけでよいのか、上司の一覧に表示される必要があるのかまで決めます。ここまで決めることで、発注側の「できた」と開発側の「できた」をそろえます。

以下では、「領収書の登録は必須」「申請額の上限は5万円」「申請ごとに承認者を指定する」という架空の業務ルールを使います。実際の案件では、その会社のルールに合わせてください。

Beekleでは、動作の具体例をGherkinの「前提・もし・ならば」で記述します。「前提」は処理前の状態、「もし」は操作や出来事、「ならば」は期待する結果です。

# language: ja
機能: 経費申請の提出

  シナリオ: 社員が必要な情報をそろえて申請を提出する
    前提 社員の田中がログインしている
    かつ 田中の申請は下書きで、必要な項目と領収書が登録され、金額が12,000円である
    かつ この申請の承認者が上司の佐藤に設定されている
    もし 田中が申請を提出する
    ならば 申請の状態が「承認待ち」になる
    かつ 佐藤の承認待ち一覧にこの申請が表示される

この例では、田中の画面に保存できても、佐藤の一覧に表示されなければ条件を満たしていません。「申請できる」の意味を、確認できる結果まで具体化しています。

正常に処理できる場合だけでなく、入力不備や上限付近の金額も確認します。次の表は下書きから提出する場面を想定し、各行に記載した点以外の提出条件は満たしているものとします。

これで提出条件をすべて網羅したわけではありません。金額の下限、必須項目、承認者が未設定の場合なども、実際の業務ルールに応じて追加します。

承認の操作には、別の条件を書きます。たとえば「承認者として指定された佐藤は承認できる」「承認者ではない鈴木は承認できず、申請の状態も変わらない」です。誰が、どの申請に対して、何をできるかを明確にします。

また、「上限を超える申請を受け付けない」という業務ルールと、「金額欄の下にエラーを表示する」という画面上の動きは、区別して記録します。Gherkinの記法については、Cucumber公式リファレンスも参照できます。

6. 運用に必要な条件を確認し、要件について合意する

申請や承認の動作が決まっても、実際に使うための条件は残っています。発注側の業務担当者、システム管理者、開発担当者で、次のような項目も確認します。

処理速度や障害からの復旧などの条件は、非機能要件として整理します。「速く表示する」「安全に運用する」だけで済ませず、必要な水準と、その確認方法を決めます。

未決定の項目は、決定済みの仕様と分けて記録します。たとえば承認者の決め方が未定なら、「確認する人」「決める期限」「決まらないと進められない作業」を残します。開発担当者に、会社の業務ルールを推測で補わせないためです。

ここまで決めておくと、未決定の業務ルールを開発側が推測で補い、あとから前提が覆って手戻りになる状況を減らせます。

開発へ進む前に、少なくとも次の点を関係者で確認します。

• 今回の目的と、開発に含める機能・含めない機能が合意されている。
• 着手する機能について、通常時・エラー時の動作、権限、関連する運用条件が決まっている。
• 未決定事項の担当者と期限、開発への影響が分かる。
• 参照する仕様と、実装後に使う確認項目がそろっている。

要件定義で行うのは、「何を作り、どう確認するか」の合意です。実装後のテストでは、その条件を実際に満たしているかを確かめます。要件定義の完了と、システムの完成は別の判断です。未決定事項が残る場合も、着手できる範囲と、決定を待つ範囲を分けます。

7. 合意した仕様を開発担当者へ渡し、実装後にテストする

要件定義書を共有したら、各タスクがどのシナリオを実現する作業かを関連付けます。タスクからシナリオ、そのシナリオを束ねるユーザーストーリー、元の要求をたどれるようにします。仕様の本文はシナリオなどの参照先で管理し、タスクへコピーして別々に更新しないようにします。

狙いは、「実装が終わった」と「利用者が期待どおり使えることを確認できた」を区別し、後者まで確認して完成と判断できるようにすることです。作業が終わっただけでは完成扱いにしません。

実装タスク：経費申請を提出する処理を作る

関連するユーザーストーリー：社員が経費申請を提出する
元の要求：経理担当者の転記作業と入力ミスを減らす

参照するシナリオ：
・必要な情報がそろっている場合の提出
・領収書がない場合の提出拒否
・申請額が上限と同じ場合の提出
・申請額が上限を超える場合の提出拒否

各シナリオの前提と期待する結果は、リンク先の仕様を参照する。
実装後のテスト結果も、対応するシナリオへ記録する。
上司による承認・差し戻しは、別のユーザーストーリーに関連付ける。

CursorやClaude CodeなどでAIに実装を支援させる場合も、決定済みの仕様と確認条件を渡します。決まっていない業務ルールを、AIの推測で仕様に加えないようにします。

実装後は、開発前に決めた条件でテストします。対象の仕様、確認した環境、期待した結果と実際の結果、合否、確認した人と日時を記録します。画像・動画やテストログも、該当する確認項目に添付します。

個々の操作に加え、「社員が申請し、上司が承認し、経理担当者が申請内容を入力し直さずに確認できる」という一連の業務も確かめます。ボタンが動くことだけでなく、最初に実現したかった仕事の進め方になっているかを見るためです。

ユーザーストーリーごとに、確認済みと未完了を報告する

テスト結果は、ユーザーストーリーに属するシナリオごとに、確認済み・不合格・未確認を分けて記録します。「タスクは完了」と「期待どおりに動くことを確認できた」は同じではありません。次は、開発途中の状況をまとめた架空の例です。

この一覧なら、「申請の提出は完了。承認・差し戻しには残作業があり、経理の一覧は動作確認待ち」と説明できます。未完了のストーリーから、どのシナリオが未確認なのか、どのタスクを誰が担当しているのかを確認します。

ユーザーストーリーの完了は、関連タスクの消化数ではなく、今回合意した対象シナリオと、そのストーリーに適用する権限・性能などの完了条件を確認して判断します。シナリオの確認件数も、そのまま残り工数や開発全体の完成率を示すものではありません。本番に公開済みかどうかは、別に記録します。

8. 変更が出たら、影響する仕様・実装・テストを見直す

開発中に要件が変わったら、変更内容を議事録に残すだけでなく、現在の仕様にも反映します。たとえば申請額の上限を5万円から10万円に変えるなら、入力チェック、エラーメッセージ、テストデータへの影響を確認します。

ここをつながずに管理すると、仕様だけ新しくなり、実装やテストだけ古いまま残ります。変更そのものより、変更の伝え忘れの方が事故になります。

コードの修正が必要なのか、設定変更だけで対応できるのかも調べます。テストでは、旧上限の5万円を超え、10万円以下の申請が受け付けられることに加え、新しい上限の10万円と、その直前・直後の金額を確認します。

シナリオを変更した場合は、変更前のテスト結果だけで確認済みとはせず、影響する動作を再確認します。そのシナリオを束ねるユーザーストーリーの完了判定も見直します。

新しい要求が加わった場合や、技術・運用の条件が変わった場合は、FMの評価と採否も見直します。リリース計画に影響するなら、MoSCoWと各リリースの対象範囲を更新します。以前グレーや黒にした要求を採用する場合は、どの条件が変わったかも残します。

変更に追加費用や納期への影響がある場合は、対応を始める前に関係者で判断します。変更の理由、対応する範囲、判断した人を残し、仕様・開発作業・テストの記録を更新します。

Beekleでも、議事録や仕様をGoogle Driveに、作業をJiraやGitHub Issuesに分けて管理していた時期がありました。当時の運用では、変更のたびに関連する資料や作業を人が探す必要がありました。この負担を減らすため、要件と、それを実装する作業・確認するテストを関連付けて管理するようにしました。

事例：引き継ぎ案件で、要求と開発範囲を整理し直した

Beekleでは、前の開発会社で進まなくなったシステムを引き継いだことがあります。資料や実装済みの画面はありましたが、顧客の要望、実際に動く機能、未実装の機能を整理する必要がありました。

私が途中から相談を受けた案件では、こうした「要求・開発範囲・完成条件をつなぐ作業」が十分にできていないケースを繰り返し見てきました。機能一覧やタスクはあるのに、誰の何を解決するのか、どこまでできれば完成なのか、変更したときに何を見直すのかがつながっていない。そうすると、開発者が作業を進めても最後に認識差が表面化します。

そこで、この案件では三日余りをかけて資料とコードを照合し、要求と開発範囲を整理し直しました。利用者ごとの操作と期待する動作を決め、対応する開発作業に記載したうえで、実装を進めました。開発を急ぐために、最初にいったん開発を止めて整理した形です。

その後、約二週間の開発サイクルを一回終えた時点で、PM on Railsの管理進捗は約60％になりました。これは管理対象の作業のうち、完了を確認できた割合です。システム全体が60％完成したことや、本番運用の成功を示す数字ではありません。当時の途中経過であり、同じ期間・進捗を他の案件で保証するものでもありません。

資料と実装をどう照合したか、変更要求をどう扱ったかは、引き継ぎ案件の要件再整理と開発の事例で詳しく紹介しています。

Beekleでは、この状態を開発中も維持する

ここまでの進め方は、要件定義の最初だけ丁寧にやれば終わりではありません。開発中に変更が出れば、要求・仕様・作業・テストの関係も更新する必要があります。Beekleに開発を依頼いただく場合は、このつながりを開発側で維持し、発注側が細かな管理作業を全部背負わなくても確認できる状態を目指します。

PM on Railsは、そのためにBeekleが自社の開発で使うために作った、要件と開発作業の管理システムです。この記事で説明した手順、つまり議事録や文字起こしから要求を整理し、FMで採否を決め、採用した要求をユーザーストーリーとGherkinに具体化し、開発作業とテストへ関連付けるところまでを、この順序のまま一つの場所で管理します。

エンジニアにとっては、PM on Rails上で要求・シナリオ・作業を関連付けておくことで、仕様変更のたびに対応する作業を人手で探し直す負担を減らせます。要求を整理すると、決まっていない点は質問として発注側へ戻ります。作業は、どのシナリオを実現するものかが決まった状態で始まり、動作確認の結果はそのシナリオに残ります。要件が変わったときも、影響するシナリオ・作業・テストをたどれるので、変更前の記録で確認済みにしてしまう事故が起きにくくなります。開発全体の状態は、作業の消化数だけでは判断しません。ユーザーストーリーごとに「どこまで動作を確認できたか」も分けて見ます。

発注側にとっても、開発側がPM on Railsで管理していれば安心できる材料になります。打ち合わせで話したことがどの要求として記録され、FMでどう判定され、どのシナリオまで動作確認が終わったかが記録に残るからです。「言ったはずのことが入っていない」「作ったのに思っていたものと違う」を、実装後ではなく要求や仕様の段階で見つけられます。

AIによる情報整理や矛盾の確認は、判断の補助です。何を優先するか、未決定の業務ルールをどうするか、完成したものを受け入れるかは、関係者が決めます。

小さな案件なら、文書や表計算で要件と作業の対応を管理する方法もあります。要求や変更が増え、関連する仕様や作業を探す負担が大きくなってきた場合は、PM on Railsも管理方法の選択肢になります。現在はベータ版で、ウェイティングリストから登録できます。

要件定義で一番大事なのは、「何を書くか」ではなく「何を作るべきか、何を作らないか、何をもって完成とするか」を関係者で決めることです。最初に、誰のどの問題を解決するかを整理します。要求をFMで評価して作るものを選び、必要に応じてMoSCoWでリリースの優先順位を決めます。開発範囲を合意してから、必要な動作と運用条件、確認方法を具体化します。合意した内容を開発担当者へ渡し、実装後はその条件でテストします。結果をユーザーストーリー単位で確認し、利用者が何をできるところまで完成したかを把握します。変更が出たら、関連する仕様とテスト、完了判定も見直します。この順序を守ることで、不要な開発と手戻りを減らし、本当に改善したかった業務へ予算と時間を集中しやすくなります。

関連記事

• ユーザーストーリーの書き方と実例
• Gherkin入門：「前提・もし・ならば」で動作の条件を書く
• 要件定義書テンプレート（Markdown版）