要件定義

システム開発はなぜ失敗するのか。この問いに対する最も本質的な答えの一つが、要件定義の不備にある。開発の後工程で仕様変更が生じるほど、手戻りコストは指数関数的に増大する。

後工程になるほど修正コストは増大し、Boehm（1981）の研究では、大規模プロジェクトにおいて保守フェーズでの修正コストは要件定義フェーズの最大100倍に達するとも言われている。上流工程における合意形成の精度が、プロジェクト全体の品質とコストを左右する。

情報システム、Webサービス、業務アプリケーションなど、ITを活用したあらゆる開発において、要件定義はプロジェクトの成否を決定づける最重要工程として位置づけられている。

コンサルティング領域においても、とりわけIT戦略・業務改革（BPR：Business Process Re-engineering）支援の文脈で、要件定義への関与は不可欠なスキルセットとなっている。

要件定義とは

要件定義（Requirements Definition）は、開発プロジェクトの最上流工程に位置し、「何を作るか」を確定させる作業である。

要件定義は大きく以下の2種類の要件から構成される。

• 機能要件（Functional Requirements）：システムが提供すべき具体的な機能・動作を定義したもの。例として「在庫数が一定値を下回ると自動発注メールを送信する」「ユーザーごとに閲覧権限を設定できる」などが挙げられる。
• 非機能要件（Non-Functional Requirements）：システムの品質特性を定義したもの。性能（レスポンスタイム）、可用性（稼働率）、セキュリティ、拡張性、運用・保守性などが含まれる。

要件定義の直前工程として「要求定義」が存在する。要求定義とは、発注者がビジネス上の目的・課題・ニーズを整理する工程であり、「なぜシステムが必要か（Why）」を明確にする。

要件定義はその後段に位置し、「何をどのように実現するか（What）」を技術的・業務的観点から具体化する工程である。この2つを混同しないことが、上流工程の論点設計において重要となる。

なお、要件定義の完成度は後続の設計・製造・テスト・保守フェーズに連鎖的に影響する。

IPAの調査では、システム開発プロジェクトの失敗要因の上位に「要件の曖昧さ・不確定さ」が継続的に挙がっており、上流工程の品質管理が業界全体の課題となっている。

システム開発における要件定義の位置づけ（プロセス構造図）

具体例／ミニケース：基幹システム刷新プロジェクト

製造業A社が老朽化した在庫管理システムの刷新を検討していたケースを例に取る。

発注者であるA社の情報システム部門が当初提示した要求は「現行システムを新しくしてほしい」という抽象的なものであった。

コンサルタントが要求定義のヒアリングを実施したところ、真の課題は「リアルタイムでの在庫可視化ができず、欠品による機会損失が年間数億円に達している」ことだと明確になった。

この課題認識を起点に、機能要件として「全拠点のリアルタイム在庫参照機能」「在庫アラート・自動発注機能」を、非機能要件として「99.9%の稼働率」「レスポンスタイム3秒以内」「外部物流システムとのAPI（Application Programming Interface：異なるソフトウェア間でデータをやり取りする仕組み）連携」を定義した。

この事例が示すように、要件定義の核心は「発注者の言葉を技術仕様に翻訳する」作業にある。抽象的な要求を機能・非機能の双方から構造化し、発注者・開発者双方が合意できる形式に落とし込むことが求められる。

要件定義・要求定義・RFPの違い

RFP（Request for Proposal：提案依頼書）とは、発注者がベンダー企業に対してシステム開発の提案を求める際に作成する文書であり、要件定義を基に作成される。

要件定義書とRFPはしばしば混同されるが、前者は内部の合意形成文書、後者は対外的な調達文書という点で性格が異なる。

ウォーターフォール開発とアジャイル開発における要件定義の違い

要件定義のアプローチは、採用する開発手法によって大きく異なる。

• ウォーターフォール開発（Waterfall Development）：要件定義→設計→製造→テストを順次実施する線形型のプロセスモデルである。

  要件定義フェーズで全要件を網羅的に確定することが前提となるため、上流での精度が特に重視される。大規模な基幹システム開発や官公庁向けシステムに多く採用される。仕様変更への対応コストが高く、要件確定の精度が品質を左右する。

• アジャイル開発（Agile Development）：スプリント（Sprint）と呼ばれる短期間の開発サイクル（通常1〜4週間）を反復するイテレーション型の開発手法である。

  要件は固定せず、開発と並行して継続的に精緻化していく。スタートアップや顧客向けWebサービスなど、仕様変更が頻発する開発環境に適している。要件定義は各スプリント開始時にバックログ（開発項目リスト）を整理する形で継続的に行われる。

コンサルティング業務での位置づけ

論点設計（イシュー出し）

コンサルティングの上流工程では、クライアントが提示する「システムをリプレースしたい」「DX（Digital Transformation：デジタル技術を活用した業務・ビジネスモデルの変革）を推進したい」という要求を出発点に、真の課題を構造化する。

要件定義支援の文脈では、「現行システムのどの機能が業務ボトルネックになっているか」「新システムで解決すべき優先課題は何か」という論点を設定し、ヒアリングや業務分析の設計に落とし込む。

現状分析（As-Is整理）

As-Is（アズイズ：現状の姿）の整理では、既存システムの機能マッピング・業務フロー（BPM：Business Process Management）・データフローの分析を行う。

コンサルタントはこの段階でクライアント部門の担当者へのインタビューを設計・実施し、業務課題・非効率点・システムの制約条件を可視化する。

この作業が不十分だと、要件定義において現行業務との整合性を欠いた仕様が生まれ、後工程での手戻りの原因となる。

施策設計（To-Be）

To-Be（トゥービー：あるべき姿）の設計では、要求定義で整理されたビジネス目的を達成するために、新システムの機能構成・データ構造・業務プロセスの変更案を設計する。

この段階でのコンサルタントの役割は、技術的な実現可能性とビジネス要件の橋渡しである。スコープ（開発対象範囲）の確定、フェーズ分割（MVP：Minimum Viable Productによる段階的展開など）、優先順位付けを通じて、実行可能な要件定義書のドラフトを作成する。

資料作成（スライド構造）

コンサルティングファームが作成する要件定義関連資料は、一般的に以下の構成をとる。

• エグゼクティブサマリー：プロジェクト背景・目的・要件定義の対象スコープを1〜2枚で整理
• 業務要件整理表：機能要件・非機能要件をMoSCoW法（Must have / Should have / Could have / Won't have）で優先度分類
• As-Is / To-Be業務フロー図：現状と将来の業務プロセス比較を可視化
• システム構成概念図：新システムのアーキテクチャ全体像
• 課題・リスク管理表：要件確定にあたっての論点・懸念点を一覧化

コンサル採用面接で問われる理由

コンサルティングファームの採用面接において、要件定義の知識が直接的に問われる場面は多くない。

しかし、この概念の背景にある「発注者の曖昧な要求を構造化し、合意形成に落とし込む」という思考プロセスは、ケース面接で問われる問題解決能力と本質的に重なる部分が大きい。

ケース面接では、「クライアントが抱える課題を整理し、解決策を論理的に構築する」プロセスが評価される。

要件定義のアプローチ（要求の背景にある真課題の特定、機能・非機能の軸での要素分解、優先順位付け、ステークホルダー間の合意形成）は、このプロセスと構造的に類似している。

ITコンサルタントや業務改革（BPR）コンサルタントを志望する場合、要件定義支援がプロジェクトの中核業務となることが多い。

概要と考え方の骨格をおさえておけば、「システム開発のどの工程で何が行われているか」について面接官と共通認識を持ちながら会話を進められる、十分な知識基盤となる。

FAQ

Q1. 要件定義とは何か？

要件定義とは、システム開発プロジェクトにおいて、発注者が求める機能・性能・制約条件を体系的に整理し、開発側との合意を形成するプロセスおよびその成果物を指す。

要件定義は「機能要件」と「非機能要件」の2種類から構成される。

機能要件はシステムが提供すべき具体的な動作・機能（例：在庫自動発注、ユーザー権限管理など）を定義したものであり、非機能要件は性能・可用性・セキュリティ・拡張性といったシステムの品質特性を規定するものである。

要件定義は開発工程の最上流に位置し、ここで確定した内容が後続の設計・製造・テストの全フェーズに連鎖的に影響を与える。

曖昧な要件定義はプロジェクトの手戻り・コスト超過・品質低下の主因となるため、コンサルティング支援の文脈でも特に重視される工程である。

Q2. 要件定義と要求定義はどう違うのか？

要求定義と要件定義は、同一プロジェクト内で順序関係にある別工程である。要求定義（Requirements Elicitation）は発注者がビジネス上の目的・課題・ニーズを整理する工程であり、「なぜこのシステムが必要か（Why）」を明確にする。

一方、要件定義は要求定義の結果を受け、「何をどのように実現するか（What）」を技術的・業務的観点から具体化する工程である。

平易に言えば、要求定義が「欲しいもの・解決したい課題」を言語化する作業であり、要件定義はそれを「実現可能な仕様」に変換する作業といえる。

コンサルタントが要件定義支援に関与する場合、この2工程を明確に区別した上でヒアリング設計を行うことが、スコープ管理と合意形成の精度を高める上で不可欠となる。

Q3. 要件定義はどのようなプロセスで進めるのか？

要件定義は一般的に以下のプロセスで進行する。まずステークホルダー（発注者・利用部門・IT部門等の利害関係者）を特定し、ヒアリングやワークショップを通じて業務課題・システム要求を収集する。

次に収集した要求を機能要件・非機能要件に分類・整理し、矛盾や重複を排除する。その後、要件の優先度付けを行う（MoSCoW法等を活用）。

優先度が確定したら要件定義書に取りまとめ、発注者・開発者双方のレビューと承認を得る。

最後に開発チームへの要件説明（ウォークスルー）を実施し、認識齟齬がないことを確認する。

ウォーターフォール開発では全要件を事前確定するが、アジャイル開発ではスプリントごとにこのプロセスを繰り返す点で運用が異なる。

Q4. コンサルティングファームは要件定義にどう関与するのか？

コンサルティングファームが要件定義に関与する場面は、主に大規模システム開発・基幹システム刷新・DX推進プロジェクトである。

コンサルタントの役割は、技術的な仕様策定よりも「ビジネス要件の構造化」と「ステークホルダー間の合意形成」にある。

具体的には、As-Is（現状）業務プロセスの分析・可視化、To-Be（あるべき姿）の設計、機能要件の優先順位付け（スコーピング）、RFP（提案依頼書）の作成支援、ベンダー評価・選定支援などを担う。

ITコンサルタント（例：大手総合系ファームやITコンサルティング専業ファーム）がプロジェクト全体をリードするケース、業務コンサルタントが要求定義フェーズのみ支援するケースなど、関与の深度はプロジェクト規模・クライアントの内製能力によって異なる。

要件定義の品質がその後の開発ROI（投資対効果）に直結するため、コンサルティングフィーの観点でも高付加価値工程として位置づけられる。

Q5. 要件定義でよくある失敗パターンは何か？

要件定義の失敗パターンは大きく5つに集約される。

第一は「要求の曖昧さ」で、「使いやすいシステムにしてほしい」など定量化されていない要求をそのまま仕様化するケースである。

第二は「ステークホルダーの巻き込み不足」で、現場部門や経営層の意見が反映されないまま要件が確定し、後から大幅な仕様変更が生じる。

第三は「非機能要件の軽視」で、機能要件の議論に注力するあまり、性能・セキュリティ・可用性の定義が後回しになる。

第四は「スコープクリープ（Scope Creep）」で、承認後に追加要求が継続的に発生し、当初スコープが際限なく拡大する現象である。

第五は「要件定義書の形骸化」で、作成後に利用されない、あるいは開発チームに正確に伝達されないケースである。

コンサルタントが要件定義支援を行う際は、これらのリスクを早期に検知・対処することが付加価値の源泉となる。

Q6. ウォーターフォールとアジャイルで要件定義はどう異なるか？

ウォーターフォール開発では、要件定義フェーズで全機能・非機能要件を網羅的に確定し、承認後は原則変更しないことを前提とする。

このため要件定義の精度と完全性が強く求められ、変更管理プロセスも厳格に運用される。

一方、アジャイル開発では要件を固定せず、プロダクトバックログ（開発項目の優先順位付きリスト）という形で継続的に管理する。

スプリントプランニング（各開発サイクルの計画会議）ごとに直近の要件を詳細化し、フィードバックを基に随時見直す。

コンサルタントが関与する大規模プロジェクトでは、基幹部分にウォーターフォール、周辺機能にアジャイルを組み合わせるハイブリッドアプローチも採用されている。

両手法の特性とトレードオフを理解した上で、プロジェクト特性に応じた手法選択を提言できることが、ITコンサルタントとしての実務力の一つとなる。

まとめ（実務整理）

要件定義は、システム開発プロジェクトにおいて「何を作るか」を確定させる最上流工程であり、機能要件と非機能要件の双方を網羅的に整理し、発注者と開発者の合意を形成するプロセスである。

上流工程の品質が後続全工程の品質とコストを規定するという原則は、コンサルティングの問題解決プロセスにおける「論点設計の重要性」とも重なる。

クライアントの曖昧な要求を構造化し、ステークホルダー間の認識を揃えるというアプローチは、コンサルティング業務の本質的な付加価値の一つといえる。

ITコンサルタント・業務改革コンサルタントを志向する場合、要件定義の基本構造（要求定義との関係、機能・非機能要件の区分、ウォーターフォールとアジャイルの違い）についての概要をおさえておけば、プロジェクト全体の流れを理解した上で実務に臨むための十分な知識基盤となる。

出典

• 独立行政法人情報処理推進機構（IPA）「ユーザのための要件定義ガイド 第2版｜要件定義・システム再構築」
  https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/youkenteigi20190912.html
• 独立行政法人情報処理推進機構（IPA）「要件定義・システム再構築 紹介ページ」
  https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/sys_upper.html
• 経済産業省「DXレポート〜ITシステム「2025年の崖」の克服とDXの本格的な展開〜」（PDF）
  https://www.meti.go.jp/policy/it_policy/dx/20180907_03.pdf