「ユーザのための要件定義ガイド 要件定義を成功に導く 128 の勘どころ」をまとめてみた

システムの設計に関わり始めたので、独立行政法人情報処理推進機構（IPA）の無料PDF 「ユーザのための要件定義ガイド 要件定義を成功に導く 128の勘どころ（2019）」をとりあえず読んでみた。

すぐ使えるように自分用にまとめておく。

こんな内容と対象者の本です。

はじめに

「ステークホルダから要求（What）を漏れなく抽出し、内容を見極め、新たなビジネスやシステムを創造する要件として定義する」という、要件定義の取り組みの重要性がますます増加してくる。

顧客とのつながりによる協働を重視し、IoT やビッグデータ、AI などの比較的新しい技術を活用する「攻めの分野」では産業の垣根を越えて異なる分野の機器やシステムが連携し、目的に応じた「最適な組み合わせ」を導き出して新たなサービスを提供することが求められ、ベンダ企業とともに協力して、多様なデータを収集、蓄積、解析してサービス化するサイクルを廻すことが重要であるが、攻めの分野においては要求のすべてが開発段階で明らかになっていないことが多く、IT システムにはサービス開始してから徐々に明らかになっていく要求への対応が常に求められる。使ってみて初めて分かる本来の要求を要件として的確にシステム化し、迅速にサービスとして市場へ提供し続けることが課題になる。

基幹業務に必要なデータの転送・蓄積・処理を中心とする従来の「守りの分野」では開発完了後に長期間を経過し、システムを構築する際に使用したハード・ソフトや技術が時代遅れになっていった（レガシー化した）システムが増加している。守りの分野における課題であるレガシー化の解消には、開発完了後の長年の保守で蓄積された「業務仕様の理解不足」などによる再構築の難しさという問題がある。下流工程においてコスト超過や稼動延伸などが発生する大きなリスクになるにも関わらず、モダナイゼーション（システム再構築）の実施前にそれを予測することは難しい。いかに安全確実にレガシー化を解消するかはユーザ企業、ベンダ企業が協力して取り組むべき優先課題であり、上流工程においてリスクを明らかにして、対策をユーザ企業とベンダ企業が合意し、ユーザ企業の経営層を含めてリスクヘッジすることが重要になる。

経済産業省が2018 年に公開したデジタルトランスフォーメーションを推進するためのガイドライン （以下、本ガイドでは「DX 推進ガイドライン」と記す）では、DX を「企業がビジネス環境の激しい変化に対応し、データとデジタル技術を活用して、顧客や社会のニーズを基に、製品やサービス、ビジネスモデルを変革するとともに、業務そのものや、組織、プロセス、企業文化・風土を変革し、競争上の優位性を確立すること。」と定義している。

既存 IT システムについて、「DX を実行していくに当たっては、データを収集・蓄積・処理する IT システムが、環境変化、経営・事業の変化に対し、柔軟に、かつスピーディーに対応できることが必要である。」と述べる一方で、その現状について「老朽化・複雑化・ブラックボックス化した既存システムが、DX 推進のための足かせになってい
る。」と述べている。このような状態の既存システムを刷新し、DX にシフトしていくためには、自社の情報資産を正確に把握しなおし、最適な再構築手法を選択することが必要になる。

「ユーザのための要件定義ガイド」および「システム再構築を成功に導くユーザガイド」はDX の 2 つのポイントである「デジタル時代に対応した新たなビジネスモデルの構築」と「DX 実現を困難にしている既存 IT システムの再構築」に強く関連している

第一章 背景

ITシステムは効率化ステージから競争力強化ステージに変わろうとしている。

1. 置き換えステージ　紙や口頭でのやりとりをITへ
2. 効率化ステージ　社内事務を効率化
3. 競争力強化ステージ　売り上げ向上などの競争力強化に積極的活用

各企業がこれからも競争力維持・強化して生き残っていくためには、「デジタル時代に対応した新たなビジネス・モデルの構築と価値の創造」および「DX 実現を困難にしている既存 IT システムの再構築」を行う必要がある

479のプロジェクトを対象に工期遅延の理由を担当者にアンケート調査した結果、工期遅延
の理由の 50％以上が要件定義の問題にあることが分かった。また、同じ調査の中では、予算オーバーや品質不良においても要件定義の問題が原因の多くを占めることが指摘されている。

既存システムが巨大・複雑化しているために、すべての仕様を明確にすることが困難になってきている。また既存システムのドキュメントが陳腐化していたり、業務知識を持っている人が業務部門にすら居なくなってきている。

個別サイロ型システムを全体統合システムに変更するには、システムの刷新が必要であり、多くの費用と期間が必要となるため、全体最適化より各事業部の最適化が最優先され、合意形成が困難を極める。

システム部門は硬直したシステムを柔軟なシステムに刷新したくても、費用、期間も膨大で予算が通らず困っている。

「デジタル時代に対応した新たなビジネス・モデルの構築と価値の創
造」では
・お客様が本当に欲しい価値は何なのか
・お客様のエクスペリエンスとは何なのか
・ビジネスにどういう価値を作るのか
・ビジネス・モデルを変えるために、データをどのように活用すれば良いのか
・デジタル技術を用いて、どのように価値創出に貢献できるのか
などを考えることがベースにある。これは DX 以前の従来の要件定義そのものであり、要
件定義は普遍であることを示している。
「新たなビジネス・モデルの構築と価値の創造」においても要件定義が重要であることを
意味している。

既存システムの刷新に必要なプロセスの一部を以下に示す。
・既存システムの調査・分析
・情報資産の仕分（機能分割・刷新、機能追加、機能縮小・廃棄、現状維持（塩漬け）な
ど）
・再構築目的やビジネスリスクの明確化
・再構築手法の選択、再構築リスクの明確化
・現行業務知識不足への対応
・品質保証（業務継続性の担保、テスト）の検討
・再構築計画と見積り
このように、既存 IT システムの再構築においても上流工程が重要であることを意味している。

要件定義では、以下の 3 つのことを意識して行う必要がある。

１「経営や業務に貢献する要求を見極める　」

いざ要件定義を終えてみると当初の狙いが達成できていない要件定義になっているこ
とがある。上記民法改正にもあるように、契約の「目的」達成を期待できるシステムを作っ
たかどうかが問題になる。また、経営層や業務部門のすべての要求を実現できるわけではな
い。経営層や業務部門との合意形成や積極的な経営層、業務部門の参画などが要件定義には
求められる

２「要求を実現する新しい業務を作り上げる」

多くの場合、経営者の IT 投資の意図は、ビジネスプロセスのチェンジである。新しいビジネスプロセスを明確に定義し業務運用までつなげるのも要件定義の仕事である

３「要求仕様を「抜け」「漏れ」「あいまい」なくシステム開発につなげる」

システム開発の失敗の原因の多くが要件定義にある。その中で
も、要求仕様の決定や漏れが一番多い。要求仕様に抜け・漏れがあったり、あいまいであっ
たりしている。システム開発工程で発覚し手戻りを起こしている。手戻り負荷は、発覚が遅
ければ遅いほど指数的に大きくなると言われている。

非機能要求は、重要なビジネス要求、利用者要求として捉え、経営層や企画部門、利用部門などが上流工程から検討を進めないといけなくなっている。要件定義のパワーの 95％が機能検討にさかれ、非機能の検討は画面レスポンスぐらいという例もあり、非機能の検討が設計工程から検討され、予算やインフラが決まった中で後手に回り苦労するという悪循環になることもある。

上流工程で、非機能としての要求を明確にすることを目的に IPA は「非機能要求グレード」を公開している。非機能要求グレードはインフラを決めるための要求を中心として上流工程でまとめるべきことを列挙してくれている。非機能要求すべてをカバーしているわけではないが、上流工程で決めなさいという示唆は重要であり多く利用されている

要件定義の進め方に工夫が必要になる代表的な3つの場面を挙げる。

1. 再構築時の要件定義（現状の可視化や理解、変える変えないの判断などを工夫する必要）
2. 本当に役立つ要求が分からない（重要な要求の見極めやリリースしてから評価するなど、リーンスタートアップやアジャイル開発を前提とした要件定義の進め方が必要）
3. アイデア創出（デザイン思考や UXアプローチなどアイデア発想アプローチを取り入れた要件定義を実施するなどの工夫が必要）

第二章 要件定義の問題認識

システム開発の超上流フェーズを進めるにあたって気を付けるべき17のポイント

原理原則[1] ユーザとベンダの想いは相反する
原理原則[2] 取り決めは合意と承認によって成り立つ
原理原則[3] プロジェクトの成否を左右する要件確定の先送りは厳禁である
原理原則[4] ステークホルダ間の合意を得ないまま、次工程に入らない
原理原則[5] 多段階の見積りは双方のリスクを低減する
原理原則[6] システム化実現の費用はソフトウェア開発だけではない
原理原則[7] ライフサイクルコストを重視する
原理原則[8] システム化方針・狙いの周知徹底が成功の鍵となる
原理原則[9] 要件定義は発注者の責任である
原理原則[10] 要件定義書はバイブルであり、事あらばここへ立ち返るもの
原理原則[11] 優れた要件定義書とはシステム開発を精緻にあらわしたもの
原理原則[12] 表現されない要件はシステムとして実現されない
原理原則[13] 数値化されない要件は人によって基準が異なる
原理原則[14] 「今と同じ」という要件定義はあり得ない
原理原則[15] 要件定義は「使える」業務システムを定義すること
原理原則[16] 機能要求は膨張する。コスト、納期が抑制する
原理原則[17] 要件定義は説明責任を伴う

経営者が意識すべきこと

システム化検討の際に経営者に最も実施していただきたいのは、最上段から見た
判断である。
• 自社を取り巻く経営環境はどのように変化していくのか、
• それに先手を打って競争力をつけるためには自社の商品サービスをどのように
変えていけば良いのか、どこの誰に買ってもらうのか
・顧客、販売店、株主、銀行、協力会社、従業員などの期待は何で、どのように対
応すべきか
これらの項目を最も正しく理解し展望をもっているのが経営者である。

業務部門、情報システム部門から多額の投資を必要とするシステム化提案が提出
されてきた場合には、以下のような考慮ができるのが経営者である。
• 今すぐ実行すべき課題なのか、新しい技術が登場してきて別の方法で解決され
ることは予想できないか
• 自社がなすべき課題の中で、今回のシステム化提案は最優先すべき課題か
• 提案内容は現状の改善にこだわり過ぎていないか、予算をもっと大きく与えれ
ば、もっと素晴らしい方法が提案できるのではないか
• このシステム化を実施するとして、システム化前に解決しておくべき課題はな
いか
• できあがったシステムを使いこなすためには業務部門の運用レベルを向上させ
ておく必要がないか
• 期待する効果を出すためには、何をする必要があるのか
• 効果を出す責任者は誰で、このプロジェクトにどの程度参加しているのか

業務部門が意識すべきことは以下の通り

1. 経営や業務に貢献する
2. ビジネスプロセス改革、改善
3. 業務部門のリーダーシップ
4. 現行業務、システムの理解
5. 合意形成
6. 仕様変更が生じた場合を想定した予算確保

システム部門が意識すべきことは以下の通り

1. 既存システムの状況の明確化
2. ベンダ企業の選定
3. システム部門のパラダイムシフト
4. プロジェクトマネジメント

ベンダが意識すべきこと

1. ユーザ企業課題解決貢献
2. 見積もり
3. 要求仕様の凍結（要件定義のアウトプットである要求仕様の細部が決まらないとか、仕様が変化し続けるといった仕様未凍結の問題が起こらないようにするために、要件定義の完了時点で要求仕様が凍結できるようにする）

要件定義の問題は以下のように分類される

「現行業務やシステムが分からない」といった『現状把握の問題』
「真の問題・課題が抽出できていない」といった『問題課題抽出の問題』
「経営要求が不明確」「経営に貢献する要求にならない」といった『ゴール明確化の問題』
「要求間の整合性がとれていない」といった『要求の体系化の問題』
「要求に基づき新らたな業務としてうまく具体化できない」といった『要求の具体化の問題』
「要求が膨らみ、捨てる判断が難しい」といった『優先順位付けの問題』
「各ステークホルダに対し要求の合意形成が難しい」といった『要求の交渉の問題』
「成果物に抜け・漏れ・あいまいが存在する」といった『要求の仕様化の問題』
「要件定義の不具合を抽出しきれない」といった『要求の検証の問題』
「システム化仕様が経営や業務にどう貢献するか分からない」といった『妥当性確認の問題』
「要件定義前の構想や企画が不十分」「開始前に必要なステークホルダが洗い出されていない」といった『立ち上げ時の問題』
「要件定義で何をどこまで実施すれば良いのか分からない」といった『要件定義プロセス計画の問題』
「そもそも開発スコープがあいまいである」といった『スコープ定義の問題』
「要求件数では開発規模の膨らみが分からない」といった『見積りの問題』
「要件定義ドキュメントの品質の確保方法が分からない」といった『品質計画の問題』
「要件定義の体制が不十分である」といった『体制・チームビルディングの問題』
「要件定義の契約形態がバラバラである」といった『契約の問題』
「コミュニケーションが不十分である」といった『コミュニケーション計画の問題』
「リスクを把握できていない」といった『リスク認識の問題』
「要求調整・規模調整のコントロールができない」といった『要求・スコープコントロールの問題』
「要件定義の品質を監視できない」といった『品質の監視の問題』
「コミュニケーションがうまくいっているか分からない」といった『コミュニケーション監視の問題』
「課題やリスクが放置される」といった『リスクの監視の問題』
「ドキュメント間の整合性がいつの間にか失われる」といった『トレーサビリティ管理の問題』
「要件定義完了時期に未決定要求が残る」といった『要求評価の問題』
「要件定義の完了を判断できない」といった『完了判断の問題』
「要件定義ドキュメントのサンプルや書き方のコツが欲しい」といった『要件定義ドキュメント記載上の問題』

第三章 要件定義の全体像

企画工程では、一般的に経営上のニーズ、課題を実現、解決するための新たな業務の全体
像と実現に向けたシステム構想を立案する。この工程では、システム化構想を具現化するた
めに、運用や効果等の実現性を考慮したシステム化計画、プロジェクト計画を具現化し、ス
テークホルダの合意を得る。

要件定義工程では、企画工程で立案したシステム化計画をインプットに、ステークホルダ
のニーズ、要望、課題を分析し、利用者や他のステークホルダが必要とするサービスを提供
するシステムに対する要求を定義し、ステークホルダと合意して、要件とする。

基本設計（外部設計）では、要件定義で合意した要件をシステムの技術的要件やソフトウ
ェアの構成要素の要件に詳細化する。

要件定義の問題カテゴリマップ

ビジネス要求定義、システム化要求定義の主要タスク例

要件定義の手順はプロジェクトの内容によって大きく変わるので、こうでなけれ ばならないというものはないが、ここでは基幹業務システムのスクラッチからの再構築プロジェクトの場合を参考までに示す。(なお、この例は4カ月で要件定義を行 う例を示している。)

1カ月目
最初の 1 カ月はビジネス戦略からのビジネス要求や現行業務の改善要求、ならびに現行システムからの改善要求などを集めて、その要求の要因や原因を調べたりす ることに主眼を置いている。また、新システム向けに採用する最新の技術や製品の採用可否を検討したりすることを行っている。

2カ月目-3カ月目前半
2 カ月目に入って、要求から要件への絞り込みを行って、To-Be のモデルや To-Beの業務フロー、To-Be の業務処理定義を主にユ―ザ主体に作成している。それと同時に、システム側では、新システムの機能要件や非機能要件を検討して、新技術や新製 品の技術検証を行っている。

3カ月目後半-4カ月目
3 カ月目半ばに入ってからは、これまでに検討された To-Be の業務フローや To-Be業務処理定義書、ならびに新システムの機能要件、非機能要件の検討結果をもとにし た新システムの機能一覧や新システム機能定義書の作成を実施している。また、デー タモデルや稼働環境の実現可能性の検証を行い、新システムの実現可能性を担保す るようにしている。他には運用要件や、データなどの移行に関する要件や課題を整理 し、また設計の標準化を徹底するように準備している。

その上で、開発・運用費用を概算で見積もり、投資効果を分析し、現新比較表をも とに、経営側への説明の準備を行っている。

この WBS（Work『作業』・Breakdown『分解』・Structure『構造化』）のすべての作業を実施しなればならないわけでもなく、実施するとして も概要レベルの内容にとどめても問題ない場合もあるので、表を参考にテーラリングして、自プロジェクトの WBS を作成されたい。

第四章 ビジネス要求定義（BR）における問題と解決の勘どころ

「BR.ビジネス要求定義」では、大きく3 つのサブプロセスに分けて作業を行う。

1. 「BR1.ビジネス要求の獲得」... 現状業務、システムの把握をした上で、それらの問題、ならびに解決すべき課題を抽出し、目指すべきゴールとその手段を抽出する。
2. 「BR2.ビジネス要求の分析」... 目指すべきゴールを実現するために必要な要求の体系化や実現手段の検討をする。また、体系化した要求、ならびに実現手段をもとに要求の優先順位付けを行い、対象とする要求の範囲、ならびに優先順位をステークホルダで合意する。
3. 「BR3.ビジネス要求の文書化」... 合意した範囲の要求についてその体系と内容、実現手段を文書化する。

要件定義の入り口として複数の人が業務を共通理解し、他の人に伝達していけるようにするためには、現行業務や現行システムを可視化し、把握することから始める必要がある。

第5章 システム化要求定義(SR)における問題と解決の勘どころ

「SR.システム化要求定義」では、大きく 2 つのサブプロセスに分けて作業を行う。まず、
「SR1.仕様化」において、「BR.ビジネス要求定義」で文書化した要求を機能面、非機能面の
両面で分析し、文書にまとめて仕様化する。続く「SR.2 確認・評価」では、作成した文書の
記述内容が構造的、意味的に正しいかどうかをレビューを通じて検証する。また、ビジネス
要求に照らし合わせて、ステークホルダが期待している初期の要求を満たしているかどう
かをステークホルダと確認する
「SR.システム化要求定義」における課題のカテゴリマップを図 5.1 に示す。

第6章 要件定義マネジメント(RM)における問題と解決の勘どころ

「RM.要件定義マネジメント」では、大きく 4 つのサブプロセスに分けて作業を行う。ま
ず、「RM1.立ち上げ」において、要件定義工程前に策定した構想・企画を確認の上、当該プ
ロジェクトを進める上でのステークホルダを特定する。そして、当該プロジェクトの成果に
対する責任の所在を明確にすべく、成果のオーナーを選定し、オーナーより要件定義工程を
開始する認可を得る。続いて、「RM2.計画立案」において、プロジェクトの目標達成に向け、
プロジェクトのスコープを定義し、プロジェクト計画を精緻化した上で、体制の構築、立ち
上げを行う。また、「RM3.監視・コントロール」において、プロジェクトの進捗やパフォー
マンスを監視し、計画の変更が必要な事柄を特定し、適切に変更を行う。最後に、「RM4.終
結」において、要件定義工程の成果を評価し、当該工程の完了を判断する。
「RM.要件定義マネジメント」における課題カテゴリマップを図 6.1 に示す。

第7章 要件定義の主要ドキュメント作成(DD)の勘どころ

「DD 文書記述」では、4 章、5 章で用いた成果物も含め、要件定義で作成する 36 の主要
な成果物をここに集約し、各ドキュメントの記載項目とサンプルドキュメント、作成時の留
意事項などを提示している。
成果物の課題領域を、「DD.1 ビジネスコンセプト」､「DD.2 ステークホルダ」､「DD.3 要
求分析」､「DD.4 データモデル」､「DD.5 ビジネスプロセスモデル」､「DD.6 相互作用モデ
ル」､「DD.7 コミュニケーション」､「DD.8 各種一覧」､「DD.9 インターフェース」､「DD.10
データ定義」､「DD.11 機能・データ整合性検証」､「DD.12 非機能要求」、「DD.13 運用、移
行、総合テスト」の 13 に分類し、それぞれの作成の勘どころを提示している。
「DD 文書記述」における課題カテゴリマップを図 7.1 に示す。

おわりに

本書は、システム構築の上流工程における重要プロセスである要件定義を適切に実施す
ることにより、それに続く開発プロジェクトの失敗を減らし、構築するシステムに対する品
質要求に応え、対象システムにより実現されるビジネスや新たなサービスに、より高い価値
をもたらすことをガイドすることを目的として作成した。本書では、この「適切に」という
言葉を、システム化の目的を達成するための要求を誤りなく選択し、そこから新たな価値を
創造するビジネス要求を過不足なく定義し、システム化要求定義に抜け漏れなく展開する、
そして、これらのプロセスを初期の計画どおりの QCD で実施できるようマネジメントする
こと、と定義してノウハウを記載した。
ノウハウは、要件定義の現場でよく発生する問題点を起点に、各問題が発生した際にどう
対処するか、発生させないためにどうするかなどにつき、問題と解決の勘どころを対応させ
る形式で記載した。発生する問題は、現場の有識者の経験から特に重要なものを選択してい
る。
ただし、要件定義において発生する問題は、このガイドに記載したものだけではない。む
しろ、まだ本書に記載されていない問題の方が多いと思われる。また、ガイドに示した勘ど
ころについても、本書とは異なるご意見をお持ちの方も少なくないと想像する。これについ
ては、みなさまの経験をもとに補完・訂正して、ご自身の作業環境でのより良い要件定義の
あり方として改善していただければ幸いである。また、本書に追記すべきノウハウをお持ち
の方も多いと思われる。本ガイドの今後の成長のために、そして今後の要件定義をより実り
のある活動にするために、ぜひお手持ちのノウハウをお寄せいただきたい。
IT の役割は"Support Business"から"Do Business"へと変化してきている、と言われ始
めてからもう何年も経過している。このような状況においてビジネスの変化に対応した情
報システムを構築・運用をするためには、今後、ますます要件定義の品質が重要になって
くる。システム構築の手法は IT の進歩と歩調を合わせて常に進化し続けており、要件定
義において作成する具体的な成果物の種類や記載内容も同様に変化し続けることが予想
されるが、本書に示したさまざまな事項は、要件定義の勘どころとして今後も普遍性を保
ち続けると考える。本ガイドがみなさまの要件定義の実施における道標として少しでも役
立つことを願う。