【IPAデータ】要件定義とは｜進め方と失敗要因・発注側の情シスがやること。業務担当者が関与した案件は要求仕様の明確さが約2倍（2017年分析）

システムの刷新や新しいツールの導入で、ベンダーから「まず要件を出してください」と言われたことはありませんか。発注側の情シスになると、こうした場面で手が止まってしまう方は多いですよね。

• 要件定義で何を決めればよいのか、全体像がつかめない
• 「要求」と「要件」の違いを、業務部門にうまく説明できない
• 業務部門が忙しく、要件定義の打ち合わせに参加してもらえない

結論から言うと、要件定義は、業務で実現したいことをシステムの機能と条件に落とし込み、発注側とベンダーで合意する工程です。IPAのデータを見ると、業務担当者が要求仕様づくりに関わったプロジェクトほど、要求仕様が明確だった傾向があります。

この記事では、要求と要件の違い、要件定義で決める項目、進め方の5つのステップを順に解説します。そのうえで、IPAのデータから分かることと分からないこと、発注側の情シスがやることを整理しました。

要件定義は発注側の要求をシステムの機能と条件に落とし込み、合意する工程

要件定義とは、業務で実現したいことを整理し、システムの機能と条件として決めて、発注側とベンダーで合意する工程です。システム化の企画（構想・計画）を終えた後、設計に入る前に行う工程です。IPAも、発注側の企業向けに「ユーザのための要件定義ガイド」を2017年に公開し、2019年に第2版を出しています。

要求は業務で実現したいこと、要件はシステムが備える機能と条件

要件定義を理解するには、「要求」と「要件」の違いを押さえることが大切です。要求は業務部門が実現したいことで、要件はそれをシステムでどう実現するかを決めたものです。

要求は、業務の言葉で出てくることがほとんどです。たとえば「月末の締め作業を早く終わらせたい」「入力の二重作業を減らしたい」といった形です。この段階では、システムに何をさせるかはまだ決まっていません。

要件は、要求を実現するためにシステムが備える機能や性能、制約をまとめたものです。「売上データを会計システムへ自動で連携する」のように、ベンダーが設計に使える形まで具体化します。

ただし、要求のすべてが要件になるわけではありません。予算や期間と照らし合わせて、今回実現するものを選びます。要件定義は、要求を選び取り、合意した要件として確定させる作業です。

要件定義の結果は設計の前提になり、IPAの白書では設計開始時点で要求仕様が明確だったプロジェクトは69.9%

要件定義で決めた内容は、基本設計の前提になります。発注側がシステムを受け入れるときの、テストの基準にもなります。要件があいまいなままだと、設計とテストの基準もあいまいになります。

参考になるのは、IPAが2004〜2015年に完了したプロジェクトを中心に集計したデータ（2016年発行の白書）です。基本設計を始める時点で要求仕様が「非常に明確」「かなり明確」と回答されたプロジェクトは69.9%でした。裏を返すと、約3割は要求仕様が十分に明確とは言えないまま設計に入っていました。

なお、この回答はデータを提供したIT企業（受注側）が記入したものです。発注側から見た評価とは異なる場合があります。また、この設問は開発を終えた後に、手戻りの有無なども振り返って総合的に評価する形式です。

出典: IPA「ユーザのための要件定義ガイド 第2版」／IPA/SEC「ソフトウェア開発データ白書2016-2017」／IPA「共通フレーム2013」第3部

要件定義で決める項目は機能要件と非機能要件の2つに分かれる

要件定義で決める項目は、大きく「機能要件」と「非機能要件」の2つに分かれます。機能要件はシステムに何をさせるか、非機能要件はどの水準で動かすかを決めるものです。

機能要件は、画面や帳票、データの処理、外部システムとの連携など、業務の流れに直接関わる内容です。非機能要件は、性能や可用性、セキュリティ、運用・保守、移行など、システムの品質や動かし方に関わる内容です。違いを表にまとめました。

区分	決める内容	例	決め漏れたときに起きやすいこと
機能要件	システムに何をさせるか	入力画面、帳票の出力、データの集計、他システムとの連携	必要な画面や処理が足りず、稼働後に追加開発が必要になる
非機能要件	どの水準で動かすか	応答時間、稼働時間帯、障害時の復旧方法、アクセス権限、バックアップ、データ移行	動きが遅い、止まったときに復旧できない、運用の手間が想定より大きい

非機能要件で注意したいのは、業務部門から要求として出てきにくい点です。業務部門は「何ができるか」には関心を持ちます。一方で、「どのくらいの速さで動くか」「止まったらどう戻すか」までは考えないことが多いですよね。

そのため、非機能要件は情シスが主体となって案を作る項目です。項目の洗い出しには、IPAが公開している「非機能要求グレード」が使えます。項目と水準の選択肢が体系的に整理されているため、決め漏れの確認に役立ちます。

参考: IPA「非機能要求グレード」

要件定義は現状把握から合意までの5つのステップで進める

要件定義は、現状の把握から始めて、発注側とベンダーの合意で終わる5つのステップで進めます。目的と範囲を先に決めないと、要求が広がり続け、優先順位を付ける基準も持てなくなるためです。

ステップ	やること	主な成果物	主に動く側
1. 現状業務と課題の把握	今の業務の流れと、困っていることを洗い出す	現行業務フロー、課題一覧	発注側
2. 目的と対象範囲の決定	システム化で何を達成するか、どの業務を対象にするかを決める	システム化の目的、対象範囲の定義	発注側
3. 要求の洗い出しと優先順位付け	業務部門から要求を集め、必須か任意かを分ける	要求一覧（優先度付き）	発注側
4. 要件への落とし込みと要件定義書の作成	要求を機能要件と非機能要件に具体化し、文書にまとめる	要件定義書	発注側とベンダー
5. レビューと合意	要件定義書を関係者で確認し、内容を確定させる	合意済みの要件定義書、保留事項の一覧	発注側とベンダー

ステップ1〜3は、業務の現状と目的を最もよく知る発注側が中心になります。ステップ4と5では、ベンダーと一緒に要件定義書をまとめ、発注側とベンダーの双方で内容を確定させます。発注側の具体的な準備は、後の章で解説します。

なお、社内体制の考え方は内製化の記事で解説しています。

IPAのデータでは、QCDすべての目標を達成したプロジェクトは67.1%にとどまる

要件定義の失敗要因としては、「要求があいまい」「非機能要件の漏れ」「関係者の合意不足」などがよく挙げられます。ただ、これらは経験則として語られることが多いため、この章では公的データで確認できる範囲を見ていきます。

使うのは、IPA/SECが2004〜2015年に完了したプロジェクトを中心に集計した累積データです。データは、開発を受注したIT企業から提供されたものです。

未達の多くはQCDのうち1つか2つで、すべて未達だったプロジェクトは2.2%

IPAが2004〜2015年に完了したプロジェクトを中心に集計したデータ（2016年発行の白書）を見ます。品質・コスト・工期（QCD）のすべてで目標を達成したと自己評価したプロジェクトは67.1%でした。達成した目標の数ごとの分布は次のとおりです。

目標を達成した数（品質・コスト・工期のうち）	割合
3つすべて達成	67.1%
2つ達成	23.4%
1つだけ達成	7.3%
いずれも未達	2.2%

出典: IPA/SEC「ソフトウェア開発データ白書2016-2017」をもとに作成（完了プロジェクトの自己評価、2004〜2015年完了が中心）

出典: 上の表と同じデータをもとに作成

この分布から読み取れるのは、全面的な失敗よりも、QCDのどれかで計画からずれるケースのほうが多いという点です。

ただし、この分布は未達の原因を示しておらず、要件定義が原因とは読めません。また、対象は完了したプロジェクトのみで、中止された案件は含まれていない可能性が高いと考えられます。

稼働後の不具合が少ないプロジェクトは、開発中に見つけた不具合の約85%（中央値）を基本設計〜製作の段階で見つけている

IPAは2017年に、白書と同じ累積データを分析した資料「設計レビュー・要件定義強化のススメ」を発行しています。この資料では、稼働後の不具合が少ない信頼性の高いグループ（稼働後の発生不具合密度が0.02件/KSLOC未満）は、上流工程での不具合摘出比率が中央値で約85%でした。信頼性の低いグループ（同0.02件/KSLOC以上）では、中央値で約66%です。対象は、新規開発で規模をコード行数で測定したプロジェクトです。不具合摘出比率は、基本設計から総合テスト（ベンダ確認）までに見つかった不具合のうち、設計レビューで見つけたものの割合を指します。

ここでいう上流工程は、基本設計から製作（プログラムの作成）までを指します。要件定義の工程は含まれていないため、要件定義で不具合を防げるとまでは言えません。なお同じ資料は、別の分析として、要求仕様が明確なプロジェクトや要件定義書の分量が多いプロジェクトほど、稼働後の不具合が少ない傾向も報告しています。これらも相関を示したものです。

この結果から読み取れるのは、設計のレビューなどで問題を早めに見つけたプロジェクトほど、稼働後の不具合が少ない傾向です。同じ資料は発注側の関与と要求仕様の明確さの関係も分析しており、次の章で紹介します。

失敗の何割が要件定義に起因するかを示す公的データは見当たらない

ここまでのIPAのデータには、失敗したプロジェクトの何割が要件定義に原因があったかという内訳はありません。そろっているのは、成否の分布、要求の明確さと関与度の関係、設計段階での不具合摘出の3つと、前の見出しで触れた要件定義の質・量と稼働後の不具合の関係（いずれも相関）です。

データは受注側のIT企業から提供された、2004〜2015年完了の案件が中心です。発注側（ユーザ企業）が要件定義にかけた工数や合意の取り方など、発注側の実務に関する統計は含まれていません。分析資料には要件定義の工数比率も出てきますが、受注側の工数のみで、ユーザ側の工数は含まれていないと注記されています。IPAの白書の後継版やDX白書など、より新しい調査に関連データがある可能性はあります。

出典: IPA/SEC「ソフトウェア開発データ白書2016-2017」／IPA/SEC「設計レビュー・要件定義強化のススメ」

発注側の情シスがやることは、業務担当者を要件定義に参加させ、資料と合意の段取りを整えること

IPAが2017年に発行した分析資料に、業務担当者の関与度別のデータがあります。関与したプロジェクトは、関与不十分のプロジェクトに比べ、要求仕様が明確だった割合が約2倍でした。

このデータから考えると、情シスの役割は要件定義をベンダーに任せることではありません。業務部門と一緒に要求を作る段取りを組むことです。

業務担当者が関与したプロジェクトは要求仕様が明確だった割合が71.4%で、関与不十分の34.1%の約2倍

2017年発行の分析資料「設計レビュー・要件定義強化のススメ」は、2004〜2015年完了が中心のデータを分析しています。ここで紹介する数値は、そのうち新規開発で規模をコード行数で測定したプロジェクト（業種全体）に絞った分析です。業務担当者が要求仕様の作成に十分または概ね関与したプロジェクト（70件）では、要求仕様が明確だった割合が71.4%でした。関与が不十分または未関与のプロジェクト（41件）では34.1%で、37.3ポイントの差があります。

出典: IPA/SEC「ソフトウェア開発データが語るメッセージ『設計レビュー・要件定義強化のススメ』」（2017年）のデータをもとに作成

この差から読み取れるのは、業務担当者を要求づくりに参加させる段取りに時間をかける価値があるという点です。

なお、2016年発行の白書全体では、業務担当者が十分または概ね関与したと回答されたプロジェクトは76.9%でした。約4件に1件は、発注側の関与が不十分なまま進んでいたと読めます。

要件定義の一部を外部に委託する場合でも、業務担当者の関与は発注側にしかできません。委託範囲の考え方はアウトソーシングの記事で解説しています。

情シスは現行業務の資料と非機能要件の案を事前に用意し、要件定義書は項目ごとに合意を記録する

前の見出しのデータを踏まえると、情シスが担いたいのは、業務担当者が要件定義に参加しやすい材料と場を事前に整えることです。業務部門は白紙から要求を出すのが苦手なことが多いため、たたき台になる資料を用意します。

準備するもの	中身	誰から集めるか
現行業務フローと課題一覧	今の業務の流れと、困っていること・改善したいこと	業務部門
現行システムの構成と連携先	使っているシステム、データの流れ、外部連携の一覧	情シス
非機能要件の案	性能、稼働時間、セキュリティ、運用、移行などの水準案（非機能要求グレードを活用）	情シス
予算・期限・制約条件	使える予算、稼働したい時期、守るべき社内ルール	経営層・情シス
参加者と決定権者の名簿	業務部門から誰が参加し、誰が最終的に判断するか	業務部門・情シス

合意の取り方も事前に決めておきます。要件定義書のレビューには、その場で判断できる業務部門の決定権者に同席してもらいます。決まった事項と保留事項は分けて記録し、保留事項には判断する人と期限を書きます。

合意後に変更が出た場合は、同じ書式で記録を残しましょう。ベンダーとの進捗や品質の管理体制は、ベンダーコントロールの記事で解説しています。

出典: IPA/SEC「設計レビュー・要件定義強化のススメ」／IPA/SEC「ソフトウェア開発データ白書2016-2017」

まとめ: 要件定義は発注側が業務担当者と一緒に要求を固めるほど明確になりやすい

要件定義は、業務で実現したいこと（要求）を、システムの機能と条件（要件）に変えて合意する工程です。決める項目は機能要件と非機能要件に分かれ、現状把握から合意までの5つのステップで進めます。

IPAのデータが示しているのは、因果ではなく傾向です。それでも2017年発行の分析資料では、業務担当者の関与度によって、要求仕様が明確だった割合に約2倍の差がありました。

発注側の情シスにできることは、業務部門を巻き込む段取りを整えることです。要件定義に入る前に、次の点を確認してみてください。

出典: IPA/SEC「設計レビュー・要件定義強化のススメ」

情シスカレッジのご案内

要件定義のように、発注側の情シスが押さえるべき基礎知識は幅広くあります。とはいえ、日々の業務に追われながら体系的に学ぶ時間を取るのは大変ですよね。

情シスカレッジは、新人・ひとり情シスのためのマイクロラーニングLMSです。情シス業務に必要な知識を、短い動画で学べる形にまとめています。

5名から利用でき、請求書払いにも対応しています。初期設定にかかる時間は約10分です。

情シスカレッジの詳細を見る

※出典
– IPA/SEC「ソフトウェア開発データ白書2016-2017」
– IPA/SEC「ソフトウェア開発データが語るメッセージ『設計レビュー・要件定義強化のススメ』」
– IPA「ユーザのための要件定義ガイド 第2版」
– IPA「共通フレーム2013」第3部
– IPA「非機能要求グレード」