システム開発の現場で、最も「やりすぎ」と「足りない」のバランスが難しいのが、要件定義という工程です。
「教科書通りに全てのドキュメントを揃えようとして、現場が疲弊し、スケジュールが溶けていく……」 「逆に、顧客の言葉を鵜呑みにして走り出し、後工程で『こんなはずじゃなかった』と大炎上する……」
こうした悲劇を避けるためには、自分なりの経験則だけでなく、一度「標準的な型」を理解しておくことが近道です。今回は、業界の指針として広く知られるIPAのガイドラインをベースに、現場で数多くのプロジェクトに関わってきた経験から導き出した「実戦で本当に使える要件定義の全体像」を整理します。
指針としての「ユーザのための要件定義ガイド 第2版」
要件定義には、いわゆる「絶対的な正解」はありません。しかし、先人たちの失敗と成功の知恵が凝縮された「優れた地図」は存在します。それが、IPA（独立行政法人情報処理推進機構）が発行している以下のガイドラインです。
🔗 ユーザのための要件定義ガイド 第2版（IPA 独立行政法人情報処理推進機構）
このガイドは、2019年に大規模な改訂が行われ、現在も要件定義における「勘どころ」を学ぶためのバイブルとして扱われています。
守・破・離で考える「型」の重要性
このガイドをそのまま現場に持ち込んで「この通りにやってください」と顧客に迫るべきだとは思いません。全350ページを超える内容を請負の短い工期で完遂するのは、現実的ではないからです。
しかし、なぜこのガイドがこれほどまでに「発注者の責任」を強調し、「ビジネスの目的」を問うのか。その理由を知ることは、我々エンジニアにとって非常に強力な武器になります。
「型」を知っているからこそ、目の前の現場に合わせて正しく「崩す（アレンジする）」ことができる。この記事では、このガイドが示す理想を尊重しつつ、リソースの限られた現場でどう立ち回るかという視点で解説を進めていきます。
要件定義の「3つの層」と連鎖構造
要件定義と一口に言っても、その対象は多岐にわたります。これらを整理せずに場当たり的に議論を始めると、必ずどこかで矛盾が生じます。
実務においては、全体を「業務」「機能」「非機能」という3つの層（レイヤー）で捉えるのが最もスマートです。IPAのガイドでは、これらを「ビジネス要求」や「システム化要求」と分類していますが、現場のエンジニアとしては以下の3層構造として理解するのが良いでしょう。
| 層 | 問いかけ | 具体例 |
|---|---|---|
| 業務要件 | Why（なぜ作るか）／What（何をするか） | 経営課題、業務フロー、データ定義 |
| 機能要件 | How（システムに何をさせるか） | 画面・帳票、ロジック |
| 非機能要件 | How well（どの品質で実現するか） | 可用性・性能、セキュリティ |
業務要件は、すべての「起点」です。IPAガイドが「ビジネス要求」として強調しているのがこの部分です。ここが曖昧なまま「どんな画面を作るか」という話に進むのは、行き先を決めずに地図を書き始めるようなものです。
機能要件は、業務を支える「設計図」です。ここでのポイントは、機能は常に「業務要件を満たすための手段」であるべきだということです。「この機能が欲しい」という要望があったとき、それが「どの業務要件に基づいているか」を常にトレースできる状態にしておくことが、無駄な作り込みを防ぐ秘訣です。
非機能要件は、品質を支える「土台」です。IPAには「非機能要求グレード」という優れた指標もありますが、現場では「この業務が止まったらどれだけの損失が出るか」というビジネスのリアルから逆算して、過不足ない目標値を決めていきます。
なぜ「上から下へ」の連鎖が重要なのか
要件定義の失敗の多くは、この層を飛び越えて議論することで起こります。業務ルール（上層）が決まっていないのに、画面のボタンの配置（中層）を議論しても、後でルールが変われば全て作り直しになります。
「上の層で決まったことが、下の層の前提条件（インプット）になる」
この連鎖を意識するだけで、打ち合わせの迷走は劇的に減り、手戻りの少ない堅牢な要件定義が可能になります。
【実戦一覧表】成果物のインプットとアウトプット
要件定義とは、ある「材料（インプット）」を加工して、次工程への「バトン（成果物）」を作る作業です。IPAのガイドにある名称と、現場で実際に作成すべきドキュメントを、情報の流れに沿って整理しました。
| フェーズ | インプット （主な材料） | 主要なアウトプット （成果物） | 現場での呼び名と役割 |
|---|---|---|---|
| 共通 | RFP 構想資料 | システム全体構成図 | 要件定義10箇条・項目6に基づく粗いスコープ確定用の図。詳細な技術構成は非機能要件・基本設計で深掘りする。 |
| 業務要件 | ヒアリング 現行伝票 | ビジネスプロセス関連図 | 開発対象のスコープと、他部署・関連業務プロセスとの境界を明確にする鳥瞰図。 |
| 業務機能構成表 | 業務を機能分解し、システム化対象を洗い出す一覧。 | ||
| ビジネスプロセスフロー | 業務フロー。人間とシステムの役割分担を示す。 | ||
| 業務処理定義書 | 業務ルール集。計算ロジックや例外処理の定義。 | ||
| 機能要件 | 業務要件 現行DB | システム化業務一覧 | システム機能要件。業務機能構成表がシステム化対象として発展した一覧。 |
| 画面一覧／画面遷移図／画面レイアウト／画面・機能権限マトリクス | 画面要件。ユーザーとの認識合わせの主戦場。 | ||
| 帳票一覧／画面・帳票レイアウト | 帳票要件。 | ||
| バッチ処理一覧 | バッチ要件。 | ||
| 概念データモデル（ER図）／エンティティ定義書・データ項目定義書 | 情報・データ要件。データの構造と「器」の定義。 | ||
| 外部インタフェース一覧 | 外部インターフェース要件。 | ||
| 非機能要件 | セキュリティ規定 | 非機能要件書 | 性能、可用性、バックアップ方針など。 |
実務で優先すべき「新・三種の神器」
IPAのガイドには多くの成果物が定義されていますが、請負契約などの限られた工期の中では、優先順位の明確化が不可欠です。次工程（基本設計）への橋渡しとして特に重視すべきは以下の3点です。
- システム全体構成図 まずは1枚の図で全体を俯瞰します。要件定義段階では、外部連携やアクター、大まかなインフラ境界を示す「粗い版」で十分です。詳細なサーバー構成・ネットワーク構成は、後続の非機能要件や基本設計フェーズ（アーキテクチャ設計）で作り込みます。
- 画面要件一式（画面一覧・画面遷移図・画面レイアウト） 開発対象（スコープ）の最終確定図です。誰がどの画面を操作できるかという権限マトリクスも、このタイミングであわせて整理します。
- ER図（ERD） データの構造を正しく定義することは、設計の品質に直結します。単なる概念図に留めず、主要な項目やテーブル間のリレーションまで踏み込んだ「論理設計のたたき台」となる詳細度が求められます。
現場のリアル：役割分担と責任の境界線
IPAのガイドラインでは、「要件定義は発注者の責任である」という原則が示されています。しかし、実際の現場、特にプロジェクトの初期段階でこの原則をそのまま適用しようとすると、かえって合意形成を遅らせてしまうことがあります。
「代行」と「合意」のバランス
理想的には発注者が自ら業務ルールを言語化すべきですが、現実にはドキュメント作成の時間を十分に確保できないケースが少なくありません。
- たたき台の提示：顧客が資料を用意するのを待つのではなく、SE側がこれまでの知見や現行調査から「仮説としての仕様」を提示し、それに対してフィードバックをもらう形を取るのが、現実的な進め方です。
- 責任の所在を明確にする：資料作成をSEが代行したとしても、「そのルールで業務が回るか」の最終判断は発注者に仰ぐ。この線引きを、日々の打ち合わせの中で地道に積み重ねていくことが重要です。
IT語り部たたき台は、現行システムがあればその設計書から読み解けます。完全な新規開発の場合は、類似の既存サービスを実際に触ってみて、それをベースに仮説を組み立てます。
ER図の詳細度を巡る課題
ER図において、よく問題になるのが「詳細度」です。ベンダー側が「この工程では主要な箱（エンティティ）を並べるだけの概念レベルで良い」と考え、一方で発注者側が「具体的な項目（属性）が分からないと業務がイメージできない」と不満を持つ、という状況です。
実務上、概念図だけで終わってしまうと、次工程の基本設計でデータの不整合が見つかり、見積もりの前提が崩れるリスクがあります。主要な項目やテーブル間のリレーション（制約）まで踏み込んだER図を作成しておくことが、結果として双方の不利益を防ぐことにつながります。
IT語り部現行システムがあると、既存のテーブル構造に引きずられて、概要設計のはずが詳細設計レベルの粒度になってしまうことがあります。これでは既存の問題点をそのまま引き継ぐだけです。概要設計の段階では、あえて既存構造から距離を置き、整理し直す視点を持つことが重要です。
請負契約における「未決事項」の管理
要件定義の終盤には、次工程の見積もりを確定させる必要があります。しかし、どうしても決まりきらない項目が残るのが現実です。
- リスクの可視化：未決事項を単に「宿題」とするのではなく、それが設計工数にどう影響を及ぼす可能性があるかを、見積もりの前提条件として明記します。
- 段階的な合意：「現時点で確定している範囲」と「不確定な要素」を切り分けることで、不透明な状態のまま開発へ進むリスクを最小限に抑えます。
IT語り部未決事項を可視化しておかなければ、後になって「それも対応してくれると思っていた」という食い違いが起きます。また、後工程に入るタイミングなどで先方から「あの件はどうなったか」と聞かれたときに答えられなければ、そこで後工程が止まってしまいます。可視化は、忘れないためだけでなく、双方の認識を揃えておくためのものです。
まとめ：共通の「地図」を持って次工程へ
要件定義のゴールは、立派な書類の束を作ることではありません。IPAの『ユーザのための要件定義ガイド 第2版』が指し示すように、発注者と受注者が同じ未来を共有し、プロジェクトを成功に導くための「共通の地図」を完成させることにあります。
今回の内容を振り返ると、実務において押さえておくべき要点は以下の通りです。
- 3つの層を意識する：「業務（Why/What）」から「機能・非機能（How）」へと流れる連鎖を崩さないこと。
- 新・三種の神器を固める：「システム全体構成図（粗い版）」「画面要件一式（画面一覧・画面遷移図・画面レイアウト）」「ER図（ERD）」の3つを、次工程のインプットに耐えうる詳細度で仕上げること。
- 現実的な立ち回り：「発注者責任」という原則を理解した上で、SEが戦略的に「代行・支援」を行い、合意形成を加速させること。
要件定義が完了し、成果物が揃った時点で、ようやく基本設計以降の正確な見積もりが可能になります。未決事項が残っている場合は、それを「リスク」として共有し、互いに納得した上で次へ進むことが、長期的な信頼関係を築く鍵となります。
要件定義のもう一つの実務課題である「言った言わない」を防ぐ合意形成の技術については、こちらの記事「要件定義はなぜ失敗する？「言った言わない」を防ぐ現場の合意形成術」もあわせてご覧ください。
