要件収集テンプレート：プロジェクトで使っている7つのコツ

要件収集テンプレートに存在する価値があるのは、難しい会話を早い段階で強いるときだけです。誰が署名するのか、誰が止められるのか、成功とはどういう状態か、システムはどれだけ速くなければならないのか。このガイドは、最初のステアリングコミッティを過ぎても使えるテンプレートを必要としている、プロジェクトマネージャー、ビジネスアナリスト、SAPリードに向けたものです。以下に、すべてのセクションに担当者を付けた、私が使っている全体構成、決して省かない5つのセクション、インタビュー、優先順位付け、変更に関する7つのコツを示します。構成を自分の文書にコピーし、設計が始まる前に埋めてください。

かつて、誰もきちんと要件を詰めなかったために、予算が6桁に達するプロジェクトが崩壊するのを見たことがあります。クライアントが期待していたものと、開発チームが作ったものが違っていました。誰もが責任を押しつけられる事態になり、そこで私が呼ばれました。

このパターンは珍しくありません。PMIが2014年にまとめた要件管理に関するPulse of the Professionレポートは、失敗したプロジェクトの47%が、要件管理の不備が原因で目標を達成できなかったと報告しています。私は、これが何十回も現実になるのを見てきました。

私自身も、大規模なシステム展開で、あやうく同じ状況に陥るところでした。関係者の意見はバラバラで、開発者は推測で作っていました。そこで私たちは立ち止まり、きちんとした要件テンプレートを作り、ビジネスが必要とするものを、期日どおり、予算内で納めました。

友人の会社は、誰も使わないカスタムCRMに35万ドルを費やしました。営業が必要としたものとマーケティングが求めたものは違い、開発者は全員が望んでいると自分たちが思ったものを作ったのです。

ある医療機関のクライアントは、医師たちが使うのを拒んだEMR（電子カルテ）の導入に、18か月を無駄にしました。日々のワークフローで何が必要か、誰も彼らに尋ねていなかったのです。プロジェクトは中止され、やり直しになりました。

発見の遅れは高くつきます。エラーコストの増大に関するNASAの調査によると、結合テストの段階で見つかった要件のエラーは、要件の段階で見つかったものに比べて、修正に21〜78倍のコストがかかりました。運用段階で見つかった場合、その倍率は29倍から1,500倍超に及びました。エンタープライズのプログラムでは、それはワークショップで済むか、数十万規模の変更要求になるかの違いです。

1. 要件修正にかかる基準コスト要件がまだ書かれている段階で見つかる
2. 結合・テストコストは21〜78倍システムが構築されテスト中の段階で見つかる
3. 運用コストは29倍から1,500倍超システムが本稼働した後で見つかる

出典: エラーコストの増大に関するNASAの調査

痛い思いをして学んだ結果、要件テンプレートが省いてはならないセクションは、次の5つです。

1. 署名欄付きのエグゼクティブサマリー

多忙な経営幹部は、30ページの要件定義書を読みません。以前、スポンサーが何に署名しているのかを理解しないままプロジェクトを承認し、結果を見て激怒したことがありました。1ページにまとめてください。ビジネスへの影響、スケジュール、リソース、期待する効果、そして同じページに署名欄を設けます。そうすれば承認者は、重要な詳細を見落としたとは言えなくなります。

2. 役割と影響力のマッピング

名前の一覧では足りません。必要なのはパワーマップです。誰がプロジェクトを潰しかねないか、誰に相談すべきか、誰には報告だけで足りるか。以前の職場で、開発に入って6か月が経った頃、法務部門が設計のやり直しを迫る要件を持ち込んできました。誰も法務を巻き込もうと考えていなかったのです。影響を受けるすべての部門について、その代表者と影響力をマッピングしてください。

3. 技術要件ではなく、ビジネス目標

どんな問題を解決しようとしているのか、そして成功をどう測るのか。ある製造業のクライアントは、仕様どおりに在庫管理ソフトウェアを導入しましたが、倉庫の作業は20%遅くなりました。テンプレートは、機能の一覧ではなく、現状のベースラインを添えて、ビジネス上の成功を関係者に定義させるものであるべきです。

4. 開発者が使える機能要件

専門用語は捨ててください。各要件は、具体的でテスト可能にします。「システムは顧客体験を向上させること」は役に立ちません。「ユーザーが3分以内に返品処理と返金を行えること」は要件です。やり遂げたかどうかを検証できないなら、書き直してください。

5. 非機能要件

性能、セキュリティ、コンプライアンス、可用性、拡張性。ほとんどの人が省略するセクションで、その結果、システムは負荷に耐えられなくなったり、セキュリティ監査に落ちたりします。ある小売業のプロジェクトで、ブラックフライデーまでは完璧に動いていたのに、負荷で崩壊したという話を聞きました。性能要件を誰も定めていなかったからです。応答時間、稼働率、ピーク時のユーザー負荷、コンプライアンス上の義務を、数値で書き出してください。

完全な構成は次のとおりです。上の5つのセクションはこの中に含まれ、署名後もテンプレートを生かし続けるログと並んでいます。

セクション	記載する内容	担当	承認者
1. エグゼクティブサマリー	課題、ビジネスへの影響、スケジュール、リソース、期待する効果。署名欄付きの1ページ	スポンサー（BAリードが起案）	スポンサーと財務
2. スコープとデプロイメントのベースライン	スコープの内外、制約。SAPの場合：Public Edition、Private Edition、またはオンプレミス	プログラムディレクター	ステアリングコミッティ
3. 役割と影響力のマップ	部門、代表者、影響力のレベル、相談か報告か	BAリード	スポンサー
4. ビジネス目標	各目標について、KPI、現状のベースライン、目標値	プロセスオーナー	スポンサー
5. 機能要件	ID（例：REQ-FUN-023）、説明、出所、優先度、受け入れ基準、Fit-to-Standardの判断	機能リード	プロセスオーナー
6. 非機能要件	性能、セキュリティ、コンプライアンス、可用性。SAPの場合は、各ギャップに対する拡張の方針	ソリューションアーキテクト	IT、セキュリティ、コンプライアンス
7. パーキングロット（保留リスト）	保留した依頼、依頼者、次回のレビュー日	BAリード	なし（昇格するまで）
8. 却下ログ	却下したもの、その理由、時期、決めた人	BAリード	スポンサー
9. 変更ログ	署名後のすべての変更と、時間とコストへの影響	PMO	変更委員会

1. 関係者インタビューでFive Whysを使う

「何が必要ですか？」と尋ねると、返ってくるのは希望リストです。代わりに、困りごとについて尋ねます。「パソコンを窓から投げ捨てたくなるのは、どんなときですか？」。そのうえで、なぜ、さらになぜと、5回繰り返します。本当の要件は、最初の依頼と違っていることがよくあります。

ある関係者は、複雑なレポート機能が必要だと言い張りました。実際のユースケースを一緒にたどってみると、必要なのはシンプルなダッシュボード3つだけでした。

2. 要件のパーキングロットを作る

関係者が求めるもののかなりの部分は、結局使われません。疑わしいものに固執されたとき、私は議論しません。パーキングロットに入れ、毎月リマインダーを送って、正式な要件に昇格させるかどうかを尋ねます。大半は、そのまま保留で終わります。

3. 何度も意見を変える関係者には「3回ルール」を使う

方針転換は、2回までなら何の問題もありません。3回目の変更では、変更の内容とその影響を説明するメールを、上司に送ってもらいます。そのメールを送りたい人はいません。変更はそこで止まります。

4. 資金配分の手法で、優先順位付けを迫る

各関係者に、すべての要件に配分できる仮想の100ドルを渡します。全部は手に入らないので、重要なところにお金を置きます。「重要」な要件が200件以上あった金融サービスのクライアントで、これをやりました。1時間で、本当の上位20件が決まりました。

5. すべての要件に番号を振る

REQ-FUN-023のような、一貫した形式を使います。「どの要件の話をしているのか」という混乱がなくなり、会議時間の無駄が消えます。出所、つまり誰がなぜ依頼したのかを記録しておけば、項目を削る必要が生じたときに、誰に連絡すればよいか分かります。

6. 要件を、関係者の言葉で読み返す

文書化した後、要件を関係者自身の言葉で読み返します。複雑なものは、開発が始まる前に、手早くプロトタイプやワイヤーフレームを作ります。誤解は、修正費用がまだ安いうちに表に出ます。

7. 却下したものを文書化する

5か月目に、却下された要件を誰かが蒸し返します。「4月に議論して、こういう理由で見送りました」と言えれば、その話はすぐに終わります。ログがなければ、同じ議論をもう一度することになります。

7つのコツは、どのプロジェクトでも使えます。SAPのプログラムでは、テンプレートにさらに3つ必要なものがあります。

デプロイメントモデルはベースラインに入れる

機能要件を集める前に、デプロイメントモデルを押さえてください。S/4HANA Cloud Public Edition（GROW with SAP、またはRISE経由）、Private Edition（通常はRISE経由）、またはオンプレミスです。これが、何が可能かを決めます。Public Editionではコアの改変が一切できないため、標準外のプロセスに依存する要件は、作り直すか却下しなければなりません。Private Editionとオンプレミスはより多くを許しますが、その代わりアップグレードの工数がかかります。

この決定より前に要件を集めると、決定が下りた時点で、その多くを書き直すことになります。

ギャップごとの拡張の判断

SAPのクリーンコアの考え方では、すべてのギャップについて、判断を記録する必要があります。コンフィグレーションで対応するか、リリース済みAPIを使って拡張するか（ABAP Cloudによるオンスタック、またはSAP BTP上のサイドバイサイド）、あるいは却下するかです。Public Editionでは、これは製品によって強制されます。Private Editionとオンプレミスでは、SAPの強い推奨にとどまり、許可したモディフィケーションはすべて、のちのアップグレード作業になります。この判断はテンプレートのセクション6、性能やセキュリティの隣に書き、承認の権限を1人のアーキテクトに与えてください。私のクリーンコアのガイドで、各レベルを説明しています。

AIは下書きを作り、判断するのは人

AIは、書類作業を手伝ってくれるようになりました。SAP Cloud ALMには要件生成機能があり、Fit-to-Standardワークショップの書き起こしから、テンプレートに沿って要件のドラフトを作成します。費用はAIユニットで支払います。Microsoft Copilotのような汎用アシスタントは、会議メモから要約や議事録のドラフトを作成します。

元の資料が整っていれば、AIによるドラフト作成ツールは、書類作業の時間を確実に減らします。ただし、インタビューは変えません。Five Whysを尋ねるのは、やはり人です。そして、部門長にエグゼクティブサマリーへ署名させるツールはありません。検証、優先順位付け、承認は、人の仕事のままです。

ソフトウェア開発。 技術的な制約、連携ポイント、ユーザーフロー（機能だけでなく、ユーザーが実際にたどる手順）、合否が明確な受け入れ基準を加えます。顧客ポータルのプロジェクトでこれを見落とし、機能が「正しく動いている」かどうかの議論に3か月を費やしました。

プロセス改善。 現状を、会議では誰も触れない面倒な回避策も含めてマッピングし、役割別の影響を評価し、確かな性能のベースラインを押さえます。ある製造業のクライアントは、ベースラインなしに倉庫のプロセスを刷新しました。6か月後、改善を証明することも、支出を正当化することもできませんでした。

ベンダー選定。 必須要件と、あれば望ましい要件を分け、評価基準に重みを付け、サポートと導入に対する期待を、細かすぎるくらい詳しく書き出します。ある企業が、ほぼ機能とデモの印象だけでベンダーを選ぶのを見ました。サポート要件を無視した結果、多額の追加コンサルティング費用なしには導入できないシステムを抱えることになりました。

小規模なプロジェクトなら、要件を承認の段階に沿って動かすTrello、レビュー用のコメント付きGoogleドキュメント、ワークショップでのプロセスマッピングに使うMiroです。

エンタープライズのプログラムなら、要件管理のアドオンを入れたJira、常に更新される文書のためのConfluence（AI機能は現在、AtlassianのRovoブランドの下にあります）、Azure DevOpsを使っているならModern Requirementsです。SAPのプログラムでは、SAP Cloud ALMが、要件、ユーザーストーリー、テストケースを1か所にまとめて保持し、SAP Activateのロードマップに結びつけます。

ツールの違いより、つながりのほうが重要です。要件をプロジェクト計画とテストケースに紐づけ、要件が変わったときには自動で通知を送ります。「それが変わったとは知らなかった」が、貧弱なツールよりも多くのプロジェクトを殺します。要件が承認された後、その状態を保つ方法はSAP導入でスコープクリープを避ける方法のガイドで、要件の承認がガバナンスのサイクルのどこに位置づくかはSAPのクオリティゲートで示しています。

署名後に誰も開かないテンプレートは、見せかけにすぎません。うまくいくテンプレートは、短く、セクションごとに担当者がいて、誰かが考えを変えるたびに更新されています。運営する価値のあるプログラムなら、それは毎週のことです。

要件収集の5つの段階とは何ですか？

1. 引き出し（エリシテーション）：インタビュー、ワークショップ、観察を通じた情報収集
2. 分析：要件の整理、優先順位付け、要件間の対立の解消
3. 文書化：仕様の作成（手法に応じてBRD、FRD、またはユーザーストーリー）
4. 検証：要件が実際のニーズを反映していて、テストできることの確認
5. 管理：プロジェクトの残りの期間、変更を追跡すること

各段階は、その前の段階の上に成り立っています。多くのチームがやるように引き出しを急ぐと、その後のすべての段階で問題が生まれます。

BRDとFRDの違いは何ですか？

ビジネス要件定義書（BRD）は、ビジネス上のニーズを扱います。背景、目標、関係者、制約、上位レベルの要件です。「ビジネスは何を必要としているのか」に答えます。

機能要件定義書（FRD）は、システムがどう動作するかを扱います。ユーザーストーリー、システムの動作、インターフェース、受け入れ基準です。「システムは何をしなければならないのか」に答えます。

私は必ず、FRDの前にBRDから始め、ビジネスの合意を取ります。FRDに直行するチームは、技術的には正しいのに、間違った問題を解くシステムを作ってしまうことがよくあります。

要件の3つの種類とは何ですか？

1. ビジネス要件：プロジェクトが存在する理由、その目標と成功の尺度
2. 機能要件：システムが何をしなければならないか
3. 非機能要件：それをどの程度うまくやらなければならないか（性能、セキュリティ、拡張性、コンプライアンス）

私が見てきたプロジェクトの失敗の大半は、非機能要件の欠落に行き着きます。システムは求められたことをこなし、そして実際の負荷の下で倒れるか、コンプライアンス監査に落ちます。

SAPのデプロイメントモデルは、要件収集をどう変えますか？

最初に押さえてください。S/4HANA Cloud Public Editionではコアの改変が一切できないため、標準外のプロセスに基づく要件は、作り直すか却下しなければなりません。Private Editionとオンプレミスはより柔軟ですが、改変するたびにアップグレードの工数が増えます。

この決定より前に機能要件を集めると、その多くをやり直すことになります。すべてのギャップについて、記録された拡張の判断（コンフィグレーション、リリース済みAPIによる拡張、または却下）を加えてください。

テスト可能な要件とは、どのようなものですか？

合否の条件が、明確で測定可能なものです。「システムは速いこと」はテストできません。「検索結果は、標準的な負荷で、クエリの95%について2秒以内に返ること」はテストできます。

私のテストはこうです。今すぐ、合否の基準が明確なテストケースを書けるか。書けないなら、要件を書き直します。テストできない要件は、私が見てきた中で、ほかの何よりも本稼働時の揉め事を多く生みます。

要件が絶えず変わるのを、どう防ぎますか？

1. 変更管理：署名後の変更は、誰かが承認する前に、時間、予算、リソースへの影響を文書化します。変更のコストを見える化してください。
2. パーキングロット：新しい依頼は、直接スコープに入れず、パーキングロットに入れます。毎月レビューします。緊急に見える依頼の大半は、待っているうちに消えます。
3. クオリティゲート：「要件が完了した」とは何を意味するかを定義し、それが満たされるまで設計に着手しません。

SAPのプログラムでは、拡張の判断が技術面のチェックを上乗せします。コアのモディフィケーションを必要とする依頼は、承認される前にアーキテクトの了承を得なければなりません。