IPA要件定義ガイドの要点とは？第2版128の勘どころを発注者の実務で読む

IPAの「ユーザのための要件定義ガイド 第2版」は、要件定義で起きがちな問題と、その解決の勘どころを128件ペアにして並べた498ページの資料です。読者として想定しているのは、システムを使う側の企業です。本記事では、第2版の版と入手方法の現状、BR・SR・RM・DDという4カテゴリの読み方を整理します。そのうえで、ガイドの記述を根拠に発注者が担う範囲、要求の合意形成、失敗パターン、完了判断の材料を整理し、実務の手順として示す構成です。最後に、ガイドを社内標準にしてよい条件と、外部の支援に切り替える判断基準を示します。

まとめ：IPA要件定義ガイドは発注者が主体で回すための問題と勘どころの対応表

ガイドの主張は一文に収まります。要件定義は、システムを使って業務の成果を出す業務部門が主体で進めるものだ、という立場です。第2版は初版の内容を一新し、ビジネス要求定義と要件定義マネジメントの2領域を厚くしました。

書籍版は2024年1月10日に販売を終えています。一方でPDF版はIPAのサイトから無償で入手でき、2026年10月時点でもダウンロードできる状態でした。

全ページを通読する必要はありません。発注者がまず読むべきなのは、第2章の問題一覧と第6章の要件定義マネジメントです。契約形態・要求の絞り込み・完了判断という、発注者側でしか決められない論点がここに集まっています。

ガイドどおりの体制が社内で組めない場合、つまり業務部門のオーナーを立てられない、または進行管理を担う人がいない場合は、その部分だけ外部の支援を入れるのが現実的な選択です。

IPAユーザのための要件定義ガイド第2版の版と公開時点・入手方法の現状

同じ名前で検索しても、IPAの別資料が混ざって表示されます。まず、どの文書を指すのかを版と時点で確定させます。

2019年9月公開・498ページの第2版で初版から強化された2領域

IPAのユーザのための要件定義ガイド 第2版の概要ページによると、第2版の公開は2019年9月12日です。副題は「要件定義を成功に導く128の勘どころ」。改訂で重点を置いたのは、業務の要求を把握・分析する「ビジネス要件定義」と、要件定義の立上げから終結までを管理する「要件定義マネジメント」の2つでした。

本文の「はじめに」によれば、初版の読者から寄せられた要望は、業務上の要求を分析する手法、プロジェクトマネジメント上の問題への対処、実施事例の3点です。第2版はこれらに応える形で加筆しており、本文には東京海上日動火災保険のアプリケーションオーナー制度など26件の事例が収録されています。

書籍は2024年1月に販売終了・PDF版と正誤表は無償で入手できる状態

IPAの書籍ページに載っている書誌情報は、2019年12月20日発行、B5変形判498ページ、定価2,500円（税込）です。更新履歴は、2020年3月13日の正誤表公開、2021年12月13日の2刷公開、2024年1月10日の販売終了と続きます。

現在入手できるのは、同ページに置かれた要件定義ガイド第2版のPDF（12.5MB）と正誤表PDFです。2026年10月21日時点で、どちらも取得できることを確認しました。同ページには、事業が終了しているため問い合わせには対応できない旨も記載されています。内容の質問先は無いものとして扱ってください。

アーカイブ扱いとなった上流工程強化シリーズと関連ガイドの位置づけ

ガイドはIPAサイトの「アーカイブ」配下に移されており、システム構築の上流工程強化の資料一覧に非機能要求グレードやシステム再構築のガイドと並んでいます。新しい版が出る予定は示されていません。

関連資料との分担は、扱う要求と合意形成の対象による区分です。性能や可用性など非機能の要求水準を決める作業は、IPAの非機能要求グレードの6大項目とグレード表の使い方で解説している別資料が受け持ちます。要件定義ガイドはその手前にある「何を作るかを誰がどう決めるか」を扱い、付録では画面や帳票の合意に特化した「機能要件の合意形成ガイド」へ案内しています。

ガイドの全体像をBR・SR・RM・DDの4カテゴリで掴む読み方の順番

128の勘どころは、問題が起きる局面ごとに4つの大カテゴリへ分けて整理されています。カテゴリの役割を先に押さえておくと、必要な章だけ引けるようになります。

ビジネス要求定義とシステム化要求定義・マネジメント・文書記述の分担

本文の図2.4「要件定義問題カテゴリマップ」をもとに、各カテゴリの対象と章をまとめました。

BRで業務の言葉の要求を固め、SRでそれを機能要件・非機能要件の仕様に変えます。RMはこの2つを計画どおりに進めるための管理で、DDは途中で作る文書の書式集という関係です。

第2版で要件定義マネジメントが最も厚くなった理由と該当章の分量

第2章で委員から集めた問題を分類すると、27の問題群のうち半数を超える16群がマネジメント系でした。初版では対象外だった領域です。ガイドは「初版では対象外としたマネジメント系の問題が多く抽出されている」と書いています。

分量にもそれが出ています。第6章は本文の189ページから349ページまで続き、全体のおよそ3分の1を占めます。要件定義の失敗は、要求の書き方より、決め方と進め方で起きているというのがガイドの見立てです。

498ページを通読しない前提で発注者が先に開く章の実務上の優先順位

発注者が限られた時間で読む場合の順番を示します。

1. 第2章2.1「各ステークホルダが意識すべきこと」：経営層・業務部門・システム部門・ベンダの役割
2. 第6章6.2.8「調達計画と契約」：外部に委託する前に読む
3. 第6章6.3.1「要件量・スコープ」：要求が膨らみ始めたら読む
4. 第6章6.4「終結」：完了判断の直前に読む
5. 第7章：成果物の書式が必要になった時点で該当節だけ引く

第4章と第5章は、業務分析や仕様の書き方を担う実務担当者向けの内容です。決裁者が読むなら、上の1〜4で足ります。

発注者が担う範囲をガイドの記述から線引きする関係者の責任分担の整理

「ユーザのための」という書名どおり、ガイドは発注者側の責任を明確に書いています。どこまでが発注者の仕事なのかを、本文の記述から拾います。

業務部門をシステムオーナーに据える勘どころと投資回収を判断する責任

6.1.3「オーナーの選定」は、システムの仕様と投資対効果に最も責任を持つのはシステム部門ではなく業務部門だ、と言い切っています。要求を出した業務部門がシステムのオーナーであることを関係者に明示し、業務部門は自らの要求の投資対効果を自分で判断する。システム部門の責任は、要求された事項を約束した費用で過不足なく作ることに限られます。

ガイドが挙げる失敗の型は具体的です。「実務で多忙なのでシステム部門にお任せ」「利用頻度が低い業務にもシステム化要求が止まらない」「総合テストに業務部門が参加しない」。どれも、オーナーが不在のまま要件定義を始めた案件で起きます。

経営層・業務部門・システム部門・ベンダの4者に割り当てる役割

第2章2.1の記述を、発注側と受注側の役割として整理しました。

経営層について、ガイドは基幹業務システムの仕様を現行どおりで済ませるようなあいまいな要求を出さず、現行どおりとは何か、どうしたいのかを定義するよう求めています。システム部門には、ベンダ選定の基準を「有名だから」「一番安いから」にしないことも求めています。

要件定義は準委任が基本とする根拠と換算欠陥率0.62の実データ

6.2.8は、要件定義を外部に委託するときの契約は準委任が基本形だと書いています。根拠として載っているのが、日本情報システム・ユーザー協会の「ソフトウェアメトリックス調査2012」をもとにした表6.21です。

全工程を請負にした案件の欠陥率は、要件定義だけ委任にした案件の2倍を超えます。「すべてお任せ」の請負では要件定義へのユーザの参加が減り、総合テストで「これでは使えない」と変更が出る、というのがガイドの説明です。ガイドはさらに、未決事項の解決負荷が要件定義工数の10%を超えそうなら基本設計も準委任にする、といった取り決めを事前に合意しておく案も示しています。モデル契約書は2020年12月22日に情報システム・モデル取引・契約書（第二版）が公開されています。工程ごとの契約の切り替え方は要求定義と要件定義の責任範囲と契約の分界点で詳しく扱いました。

合意形成と要求の絞り込みでガイドが示す勘どころの実務への落とし方

ガイドは、要件量とスコープのコントロールを要件定義マネジメントの中で最も重い要素と位置づけています。合意を取りながら要求を減らす手順を、数値つきで見ていきます。

発散フェーズと収束フェーズを最初に区切る要求コントロールの手順

6.3.1は、要件定義の中に「要求を発散させるフェーズ」と「収束させるフェーズ」があると整理しています。最初から要求を絞ると、後から要求が出続けて要件定義が終わらない。逆に発散を放置すると、コストと工期を無視した要求の検討で手戻りが生まれます。

そこで、発散の範囲を最初に合意しておきます。ガイドの例では、コスト制約が大きい案件なら検討単位ごとに最初の1時間のヒアリングだけを発散の場にし、工期制約が大きい案件なら要件定義の工期の最初の五分の一だけを発散フェーズにします。後半の絞り込みは業務部門任せにせず、システム部門やベンダが進行役を務めるのが勘どころです。

要求の規模を件数でなく実現コストで測る予算判断用の定量化尺度の選び方

「要求一覧から30件を対象外にしました」と伝えても、業務部門は納得しません。件数では、1件ごとの重さが見えないからです。6.2.3は、要求の規模を件数ではなく実現にかかるコストで表すよう勧めています。

尺度の候補として、表6.22はファンクションポイントなどを挙げています。ファンクションポイントは算出ルールが確立していて納得性が高い一方、計測できる要員の確保が必要です。全要求を同じ尺度で測ってから、割り当てられた予算に収まる要件量を示す。この順番で進めると、絞り込みの議論が「誰の要求を捨てるか」から「予算内でどれを先にやるか」に変わります。

仕様変更予算と投資判断用コンティンジェンシーの予算申請時の積み方の目安

第2章の表2.3は、ソフトウェアメトリックス調査2019の473件をもとにしています。仕様変更は79.3%の案件で発生し、変更費は総開発費の平均9.4%でした。予算に変更分を組み込んでいた案件でも、変更は90.7%で起きています。

ガイドは、2016年版の同調査で「仕様変更予算を10%程度持っておくと対応が円滑になる」と報告されたことも紹介しています。投資効果の分析を扱う6.3.7で勧めているのは、要件定義段階の見積りに最低でも20%から30%以上のコンティンジェンシーを見込むことです。予算申請では、前者を仕様変更への備え、後者を見積り誤差と要件拡大への備えとして分けて計上すると、どちらの予備を取り崩したのかを後から追えます。

ガイドが挙げる失敗パターンと要件定義の完了判断に使うチェック項目

要件定義の終わらせ方は、発注者が判断する場面です。ガイドは完了の判定と、未決事項を残したまま進む場合の扱いを分けて書いています。

「現行どおり」の要求と後付けの管理ルールが手戻りを生む典型パターン

ガイドの記述から、発注者側で起きやすい失敗を3つ挙げます。1つ目は、再構築で「現行どおり」と要求する型です。稼働中のシステムから仕様をすべて引き出せると考えて上流の作業を省き、下流でコスト超過になります。

2つ目は、管理ルールの後付けです。6.2.9によれば、要件定義はプロジェクト全体の工数の10〜15%程度で、参加メンバも少ないため、進捗・課題・変更の管理ルールを決めないまま始まりやすい。結果として、大量の残課題を抱えたまま要件定義が終わります。3つ目は、キーマンの時間が確保できない型で、事例11に1件分の経緯が載っています。

未決事項を先送りしてよい3条件と未決事項台帳で管理する8項目

6.4.2は、未決事項が残るなら期間を延ばしてでも解決するのが本来の姿だとしたうえで、やむを得ず先送りする場合の基準を例示しています。システムの効果やスコープに影響しないこと、業務フローが確定していること、解決期日が明らかなことの3つです。

先送りした事項は表6.28の形式で台帳に載せ、関係者と合意します。管理する項目は、未決事項のタイトル、詳細、対応状況、責任者、期限、未決による影響、決定までの見積工数、決定のための条件の8つです。ガイドは「未決状態の先送りだけは絶対に避けるべき」と書いており、台帳は期限を守らせるための道具として使います。

経営者を交えた要件定義の完了判断で揃える投資・回収・リスクの材料

完了判断の勘どころは4つあります。成果物の妥当性の確認、未決事項と対応計画の確認、判断材料の用意、そして経営者を交えた完了と後工程開始の判断です。材料は、開発費・維持運用費・人員投入計画といった投資、収益計画や直接換算しにくいメリットといった回収、予想されるリスクと対応策の3群に分けて揃えます。

投資額は開発費だけでなく、稼働後3年分または5年分の保守運用費を合計して比べるよう6.3.7が指定しています。開発を始めてしまうと、それ以降は中止の判断が難しくなるためです。投資回収の見込みに疑義が残るなら、解消するまで完了判断を延期すべきだとガイドは書いています。

IPA要件定義ガイドを自社で使う場面と外部支援に切り替える条件

ここからは、ガイドの記述と受託開発の現場の条件を突き合わせた判断です。ガイドは良い教科書ですが、そのまま全社標準にすると回らない組織もあります。

ガイドをそのまま社内標準にしてよい組織の体制条件と使わない開発の場面

社内標準として採用してよいのは、次の2つを満たす組織です。業務部門の責任者を要件定義期間中にオーナーとして拘束できること。そして、システム部門に進行管理を専任で持てる担当がいることです。この2つが揃えば、第6章の管理ルールと第7章の書式をそのまま使って効果が出ます。

反対に、新規事業のWebサービスのように使ってみて要求が見えてくる開発では、ガイドを標準にしません。ガイドの「はじめに」も、攻めの分野に特化した内容は含まれていないと明記しています。この場合は、アジャイル開発の要件定義の進め方を基本にし、ガイドは完了判断や台帳の考え方だけを借りるのが妥当です。

ガイドどおりに回らない社内体制と要件定義の支援を外部に頼む判断基準

外部の支援に切り替えるべきなのは、オーナーは立てられたが進行管理を担える人が社内にいない場合です。ガイドは、要求の絞り込みはシステム部門やベンダが進行役を担うと良いとしていますが、システム部門が1〜2名の企業では業務部門との兼務で回らなくなります。

このとき外部に任せる範囲は、進行管理と文書化までに留めるのが原則です。要求の採否と完了判断は発注者に残すのが条件で、ここまで委ねると、ガイドが失敗例として挙げる「すべてお任せ」と同じ構図になります。一創の要件定義・RFP作成・PMO支援は、準委任を基本に開発の受注を前提とせず発注者の側に立ち、要件定義の伴走と、進捗・課題・変更要求を一つの台帳で追う管理を受け持ちます。

よくある質問

IPAの要件定義ガイドについて、検索で多い疑問に答えます。

IPAの要件定義ガイドは無料で読めますか？

PDF版は無料で読めます。IPAの書籍ページから「ユーザのための要件定義ガイド 第2版」のPDF（12.5MB）をダウンロードでき、2026年10月21日時点で取得できることを確認しました。紙の書籍は2024年1月10日に販売を終えており、新品は入手できません。正誤表も同じページにPDFで置かれています。IPAの事業は終了しているため、内容についての問い合わせ窓口はありません。

初版と第2版では何が違いますか？

第2版は2019年9月12日に公開され、初版の内容を一新しています。主な違いは、業務の要求を把握・分析する「ビジネス要件定義」と、立上げから終結までを扱う「要件定義マネジメント」の強化です。初版で対象外だったマネジメント系の問題が多く加わり、第6章だけで本文のおよそ3分の1を占めます。事例も大幅に増えています。これから読むなら第2版を選んでください。

非機能要求グレードとはどう使い分けますか？

両資料の違いは、対象とする要求と作業の範囲です。要件定義ガイドは、要件定義全体を誰がどう進めるかを扱う資料で、非機能要求は第7章7.12で非機能要件書の書き方として扱っています。性能・可用性・セキュリティなどの水準を項目ごとに決める作業に使うのは、IPAの非機能要求グレードです。要件定義ガイドで全体の進め方を決め、非機能の詳細は非機能要求グレードで詰める、という順番が実務に合います。

アジャイル開発でもIPAの要件定義ガイドは使えますか？

全体をそのまま使うのには向きません。ガイドは、使ってみて要求が明らかになる「攻めの分野」に特化した内容は含んでいないと明記しています。要件定義を一度で終える進め方が前提です。アジャイル開発でも、業務部門をオーナーに据える考え方、要求を実現コストで測る方法、未決事項の台帳管理は流用できます。スプリントごとの要求の扱いは別の進め方で設計してください。

ベンダ側の担当者が読む意味はありますか？

あります。ガイドは想定読者にITベンダを含めており、第2章2.1.4に「ベンダ企業が意識すべきこと」として、準委任契約を基本形にすること、見積りを都度見直すこと、要求仕様の凍結に向けてスコープと変更を統制することを挙げた記述です。発注者がこのガイドを読んで交渉に臨む場合、同じ前提を共有しておくと、契約形態や完了基準の話が早く進みます。

関連記事

• 要件定義とは？目的・進め方・成果物と失敗を防ぐポイントを解説：要件定義そのものの目的と進め方を押さえる親記事です
• 要件定義書の書き方：章立てサンプル・記載項目・レビュー観点を作業手順で解説：ガイド第7章の成果物を実際の文書にまとめるときに使えます
• 業務要件定義とは？8つの記載項目と業務要件定義書の作り方・機能要件との階層を解説：ガイドのビジネス要求定義にあたる工程を具体化しています
• RFPと要件定義の違いとは？要件の伝え方・記載項目と発注者の準備を解説：ベンダを選ぶ段階での要件の伝え方を扱っています