要件定義

要件定義とは

要件定義は、システム開発の初期に「何を作るのか」「それによって何を実現したいのか」を明確にする工程だ。利用者やビジネス側の要望を整理し、実現すべき機能・満たすべき条件を文書としてまとめる。設計や実装に先立つ最上流の活動であり、ここでの認識のずれが、後工程で大きな手戻りやプロジェクトの失敗につながる。

2 種類の要件

種類	内容
機能要件	システムが何をするか (検索、登録、通知など)
非機能要件	どう動くべきか (性能、可用性、セキュリティ)

機能要件は意識されやすいが、「同時に何人が使えるか」「障害時にどう振る舞うか」といった非機能要件の見落としが、後の重大な問題になりやすい。

なぜ難しいのか

要件定義の難所は、依頼する側自身が「本当に必要なもの」を言語化できていないことにある。要望をそのまま受け取ると、表面的なニーズに応えても本質的な課題を解決できない。「なぜそれが欲しいのか」を掘り下げ、隠れた前提や真の目的を引き出す対話が求められる。技術力以上に、傾聴と整理の力が問われる工程だ。

失敗を避ける勘所

要件は最初から完璧に固めきれるものではなく、開発を進める中で理解が深まる。すべてを事前に文書化しようとして時間を浪費するより、重要な要件を優先して合意し、変化を前提に見直せる進め方が現実的なことも多い。一方で、関係者間の認識合わせを怠ると「作ったが使われない」システムが生まれる。曖昧なまま進めず、誰が読んでも同じ解釈になる具体性を持たせることが、手戻りを防ぐ鍵になる。

検証可能な書き方に落とす

要件工学の国際規格 ISO/IEC/IEEE 29148:2018 (2011 年版の改訂) は、個々の要件が満たすべき性質として一意に解釈できること・検証可能であることを挙げている。裏を返せば「レスポンスが速いこと」「使いやすいこと」のような書き方は、完成後に満たしたかどうかを誰も判定できないため要件として機能しない。「一覧表示は同時 100 ユーザーの負荷下で 95 パーセンタイル 1 秒以内」のように、測る対象・条件・しきい値の 3 点を書けば、そのまま受け入れテストの判定条件になる。

合意形成でも同じ原理が働く。文書に署名をもらうことが合意ではなく、「この条件を満たせば完成と認める」という判定基準を関係者が共有できた状態が合意だ。判定基準に落とせない要望が残っているなら、それは合意ではなく先送りされた争点であり、受け入れ試験や検収の場で必ず表面化する。