要件定義書の書き方｜エンジニアが迷わない標準構成と記述の鉄則

本連載について
この記事は、IT現場で最も炎上しやすいと言われる「要件定義」の進め方を、誰もが経験したことのある「家族旅行」に例えてわかりやすく解説する全7回のシリーズです。（※どの回からでも単独でお読みいただけます）

全7回にわたってお届けしてきた本シリーズも、いよいよ今回が最終回！ 最後は、開発を成功に導く決定打となる「要件定義書の書き方と記述の鉄則」についてお届けします。

「打ち合わせでは合意したはずなのに、出来上がったシステムがイメージと全く違う……」
「要件定義書が分厚すぎて、誰も中身を正しく理解できていない」

要件定義の最終段階で、こうした「伝達の齟齬（そご）」に悩まされていませんか？これまでの連載を通じて、目的地（企画）を決め、地図（全体像）を描き、プラン（業務・システム）を練り上げてきました。

最後の手仕事は、これらすべての合意事項を一冊の「要件定義書」にまとめることです。今回は、家族旅行の「旅のしおり」を例に、エンジニアが迷わないドキュメントの書き方を紐解いていきましょう。

要件定義書は、関係者全員の「旅のしおり」

要件定義書の役割は、単なる会議の議事録や記録ではありません。

旅行の当日、お父さんが空港へ向かっているのにお母さんが駅にいたら、旅行は台無しです。全員が「同じ情報」を見て、迷いなく同じ目的地へ動けるようにするためのガイドブック。それが要件定義書の本質です。

「何から書けばいいか迷う……」という場合は、以下の標準構成をテンプレートとして活用してください。第2回で解説した「4階層モデル」をベースに整理すると、情報の漏れがなくなります。

要件定義書が、書き手の思いを綴った「ポエム」になってはいけません。誰が読んでも一つの解釈しかできない「設計の根拠」である必要があります。

「〇〇ができるようにする」といった曖昧な書き方ではなく、「システムは、ユーザーが入力した情報をDBに保存する」のように、「誰（何）が」「何を」「どうする」の形式で記述します。

「使いやすい画面」ではなく、「すべての操作を3クリック以内で完了できる画面」と書きます。形容詞（使いやすい、速い、美しい）は人によって解釈が分かれるため、エンジニアが実装する際の基準になりません。

「ログインする」という正常な流れだけでなく、「パスワードを3回間違えたらアカウントをロックする」といった、うまくいかない時（例外・エラー時）の挙動こそが、エンジニアが最も知りたい重要な情報です。

全7回にわたってお伝えしてきた「旅の例えで学ぶ要件定義」も、いよいよフィナーレです。ここで、これまでの旅路を振り返ってみましょう。

要件定義書が完成した瞬間は、ゴールではなく「新しい旅の始まり」です。この一冊のしおりがあれば、開発チームという心強いパートナーとともに、自信を持って出発できるはずです。

要件定義書を書き終えたら、開発工程に進む前に以下の3点を必ずクリアしておきましょう。

[ ] 承認のプロセスを終える
ドキュメントをメールで送って終わりにするのではなく、関係者と「読み合わせ」の会議を行い、最終的な合意（サイン・承認）を得ているか。
[ ] 用語の定義を統一する
同じものを指しているのに人によって呼び方が違う言葉（例：顧客、ユーザー、担当者、クライアント）を整理し、用語集を作っているか。
[ ] 「やらないこと」を明記する
検討した結果、今回は実装しないと決めたこと（Won’t要件）をあえて明記し、開発中の「言った・言わない」や後出しの要望を防げているか。

次なる旅へ（あわせて読みたい）
要件定義という準備を終え、いよいよプロジェクトが出発します。出発した後のスケジュール管理やトラブル対応など、「プロジェクト管理」の極意を同じく旅行の例えで解説した全12回のシリーズもご用意しています！