目次／制作・開発ディレクション／要件定義・仕様書作成

要件定義

項目番号 050 ／最終更新 2026-09-19

10秒でわかる！要点まとめ

「何をやるか」と同じくらい「何をやらないか」を決めるのが要件定義の肝
クライアントの「要望（Wants）」と、システムとしての「要件（Requirements）」は別物
「機能」だけでなく、スピードやセキュリティといった「非機能要件」の定義がプロの仕事

1. 概要：プロジェクトの「憲法」を制定する

要件定義とは、クライアントの曖昧な要望やビジネス上の課題を整理し、それを解決するためにシステムやWebサイトに求められる具体的な機能・性能・制約条件を明確化して、ドキュメント（要件定義書）にまとめる業務です。

「お問い合わせフォームが欲しい」という要望に対し、「項目は何か」「確認画面は必要か」「自動返信メールの文面は」「データはDBに保存するかメールのみか」といった詳細を詰め、開発チームが実装可能で、かつクライアントが合意できるレベルまで仕様を具体化します。これがプロジェクトにおける全ての判断基準（憲法）となります。

2. なぜ重要なのか：トラブルの火種を消し止める

システム開発の失敗原因の多くは、技術力不足ではなく「要件定義の曖昧さ」にあります。「普通これくらいできると思ってた」「そんな話は聞いていない」といった、プロジェクト後半で発生する「言った言わない」のトラブルは、すべてこの段階での詰めが甘かったことへの請求書です。

要件定義がしっかりしていれば、後から追加要望が出ても「それは要件定義に含まれていないので追加費用になります」と堂々と交渉できます。自社の利益を守り、エンジニアを守り、最終的にクライアントに約束通りのものを納品するために、最もエネルギーを注ぐべき工程です。

3. 実務のポイント：機能要件と「非機能要件」

実務では、目に見える機能だけでなく、見えない品質への言及が不可欠です。

機能要件：「何ができるか」の定義。ログイン、検索、決済など、ユーザーが触れる機能。ここはクライアントもイメージしやすいため、比較的スムーズに決まります。
非機能要件：「どうあるべきか」の定義。ここが腕の見せ所です。「何秒以内に表示するか（性能）」「何万アクセスに耐えられるか（拡張性）」「セキュリティレベルは（安全性）」「24時間365日稼働か（可用性）」など、後から変更が困難なインフラ周りの要件を漏れなく定義します。
除外事項（スコープ外）：「サポートが終了した旧ブラウザには対応しません」「データ移行は含みません」といった、「やらないこと」を明記することが、身を守る最大の防御になります。

4. スキルアップのヒント：IPAの「グレード」を参照する

要件定義の抜け漏れを防ぐには、IPA（情報処理推進機構）が公開している「非機能要件グレード」というガイドラインが非常に役立ちます。「可用性」「性能」「セキュリティ」などの項目が網羅されており、これをチェックリストとして使うだけで、プロレベルの定義が可能になります。

また、エンジニアとランチに行き、「今までで一番困った要件定義は何？」と聞いてみてください。「曖昧な仕様で作り直しになった」などの失敗談こそが、生きた教科書になります。