要件定義は、システム開発プロジェクトの成否を決める最重要工程です。当社の支援現場でも、要件定義に十分な時間を取れたプロジェクトと、急いで設計に進んだプロジェクトでは、最終的な品質と予算超過のリスクがまるで違います。けれども、「要件定義とは具体的に何をするのか」「何が成果物なのか」が曖昧なまま、ベンダー任せにしてしまうケースが少なくありません。この記事では、要件定義の定義から、役割、進め方、必要な成果物、失敗パターンまでを実務目線で整理します。
要件定義とは何か
要件定義とは、システム開発プロジェクトの最初のフェーズで、「システムに何をさせるか」「何をさせないか」を明確にし、関係者の合意を取る活動を指します。業務上の課題と、システムで実現すべき機能を文書化し、設計以降の工程の土台を作ります。
要件定義の質が、プロジェクト全体の品質を決定づけます。要件が曖昧なまま設計や開発に進むと、後の工程で前提が崩れ、手戻りや追加開発のコストが膨らみます。
要件定義と要求定義の違い
似た言葉として「要求定義」があります。両者の関係を整理します。
| 概念 | 内容 | 主体 |
|---|---|---|
| 要求定義 | 業務上やりたいことを整理 | 発注側 |
| 要件定義 | システムが満たすべき条件を定義 | 発注側＋開発側 |
要求は「業務上の希望や課題」、要件は「システムが満たすべき条件」と整理できます。要求を整理し、それを実現するための要件を定義する、という流れになります。実務では両者が一体で進むことが多く、明確に分けないこともあります。
要件定義の重要性
要件定義がなぜ重要かを整理します。
プロジェクト全体の品質を決定づける
要件定義の段階で業務フローが整理され、解決すべき課題が明確で、関係者の合意が取れていれば、後の工程は計画通りに進みやすくなります。逆に要件定義が甘いと、設計のたびに前提が揺れ、製造の段階で手戻りが発生し、テストで仕様の解釈の違いが噴出します。
後工程の手戻りコストを抑える
ソフトウェア開発の手戻りコストは、後工程ほど指数関数的に大きくなることが知られています。要件定義での見落としが製造工程で発覚すると、その修正コストは要件定義段階の数十倍に達することもあります。
発注側と開発側の認識を揃える
要件定義は、発注側と開発側が同じ理解を共有するための活動でもあります。文書化された要件があることで、「言った・言わない」が防げます。
要件定義の進め方
実務での進め方を整理します。基本的にはシステム開発の工程の最初のフェーズに位置します。
ステップ1：プロジェクトのゴール定義
何のためにシステムを作るのか、解決すべき業務課題は何かを明確にします。「販売管理を効率化する」では曖昧すぎるため、「受注から発送までのリードタイムを3日から1日に短縮する」のように、達成すべき目標を数値で示します。
ステップ2：現状業務の可視化
フローチャートなどで現状の業務フローを可視化します。As-Is（現状）が見えていないと、To-Be（あるべき姿）も設計できません。
ステップ3：あるべき姿の設計
To-Beの業務フローと、システムで実現すべき機能を設計します。業務改善の機会としてあるべき姿を考えてください。
ステップ4：機能要件の整理
システムが提供する機能を一覧化します。画面、データ項目、業務処理、外部連携を明確にします。
ステップ5：非機能要件の整理
性能、可用性、セキュリティ、保守性など、機能以外に満たすべき条件を整理します。
ステップ6：関係者との合意
整理した要件を関係者でレビューし、合意を取ります。経営層、業務部門、情報システム部門、開発ベンダーが同じ理解を共有することが、後工程の品質を担保します。
ステップ7：要件定義書の作成
合意した内容を要件定義書として文書化します。これが後の設計、開発、テストの基準になります。
機能要件と非機能要件
要件は2つに大別されます。
機能要件
システムが「何をするか」を定義する要件です。具体例として、以下が含まれます。
- 利用者ができる操作（ログイン、登録、検索、編集など）
- システムが処理する業務ロジック
- 画面の構成と項目
- データの入出力
- 他システムとの連携
非機能要件
システムが「どう動くか」を定義する要件です。機能要件の影に隠れがちですが、運用品質を決定づけます。
| 観点 | 内容 |
|---|---|
| 性能 | 応答時間、処理件数、同時接続数 |
| 可用性 | 稼働率、障害時の復旧時間 |
| セキュリティ | 認証、暗号化、ログ管理 |
| 保守性 | 拡張のしやすさ、ドキュメント整備 |
| 運用性 | 監視、バックアップ、復旧手順 |
| 移行性 | 既存システムからの移行のしやすさ |
非機能要件は、業務担当者だけでは整理しきれない領域です。情報システム部門や開発ベンダーの協力を得ながら、必要な水準を定義してください。
要件定義の主な成果物
要件定義フェーズで作成する代表的な成果物を整理します。
- プロジェクトの目的と範囲の文書
- 業務フロー図（As-Is、To-Be）
- 機能一覧
- 画面遷移図、画面ラフ
- データ項目定義
- 外部システム連携の整理
- 非機能要件の整理
- 要件定義書（上記をまとめた文書）
これらが揃って初めて、基本設計（外部設計）のフェーズに進めます。
要件定義の期間と費用
要件定義に必要な期間と費用の目安を整理します。
| 規模 | 期間の目安 | 全体工程に占める割合 |
|---|---|---|
| 小規模 | 1〜2か月 | 20〜25% |
| 中規模 | 2〜4か月 | 20〜30% |
| 大規模 | 4か月以上 | 25〜30% |
要件定義に全体工程の20〜30%を割くのが、業界的な目安です。ここを短縮して後工程の手戻りで支払うコストは、要件定義に投資するコストの数倍になります。
要件定義でよくある失敗パターン
失敗パターンを整理します。
ひとつめは、要件定義を急ぐパターンです。「早く動くものを見たい」「予算を抑えたい」というプレッシャーで要件定義を簡略化すると、後工程で必ず手戻りが発生します。
ふたつめは、ベンダー任せにするパターンです。業務の細部は発注側にしか分かりません。それを丸投げすると、ベンダーは類似プロジェクトの経験から推測で要件を埋めることになり、「思っていたのと違う」が頻発します。
みっつめは、非機能要件を軽視するパターンです。機能だけ整理して非機能要件が曖昧だと、リリース後に性能やセキュリティの問題が顕在化します。
よっつめは、現場を巻き込まないパターンです。経営層や情シスだけで要件を決めると、現場の実態に合わない要件になります。
いつつめは、要件を文書化しないパターンです。「言った・言わない」を防ぐためにも、合意内容は必ず文書化してください。
H&Kの視点：要件定義は「業務改善とセット」で考える
要件定義は、単なるシステムの仕様書作成ではなく、業務をどう変えるかを設計する活動です。当社が支援する場面では、要件定義の前段に業務改善を位置づけ、業務フローを整理してから要件に落とすアプローチをおすすめしています。
業務フローを整理し、最適なシステムアーキテクチャを提案することは当社の得意領域です。ステークホルダーが複数組織にまたがる場合、ほぼ必ずデータ連携が発生するため、要件定義の段階でその設計を含めて議論することが、後の運用品質を左右します。
要件定義に時間とコストをかけることをためらわないでください。後の工程で支払うコストに比べれば、はるかに安い投資です。要件定義の質が、プロジェクト全体の投資対効果を決めます。
