IPA情報処理推進機構が公開している「家づくりで理解する要求明確化の勘どころ」を読んだので、その内容を参考にしながらIPAが考える要件定義でやるべきことをまとめました。
こちらは、IPA情報処理推進機構がシステム開発における要件定義でやるべきことを、家づくりの例を用いて解説してくれているドキュメントです。
今後要件定義をする人のヒントになればと思います。
要件定義でやることまとめ
「家づくりで理解する要求明確化の勘どころ」では、要件定義でやることを次の15ステップにまとめています。
この後、私が実際に要件定義を経験していく中で感じたことを交えてつつ、１つずつ解説していきます。
- 初期要求（ニーズ）を明確にする
- どのようなシステムを作るかの前にどのような業務にするかを検討する
- 現行業務やシステムを把握し、To-Be の変化を明確にする
- ステークホルダを洗い出す
- ステークホルダ要求を明確にする
- 非機能要求など、その他の要求を明確にする
- 要求を目的展開する ～要求の妥当性を検証～
- 目的から手段を検討する ～要求の充分性を検証～
- 要求の価値／効果を判断し、要求を絞り込む
- 制約・前提条件を明確にする
- 制約条件や前提条件を考慮した現実案を検討する
- 要求の優先順位付けを行う
- To-Be 業務での変化と価値をまとめる
- ステークホルダと合意形成する
- 要件（仕様）として定義する
スポンサーリンク
初期要求（ニーズ）を明確にする
要件定義をはじめる際、まずは初期段階で存在する要求を素直に受け止めることが重要です。経営層には経営層なりの、業務部門には業務部門なりの、情報システム部門には情報システム部門なりの要求があるため、まずはその要求事項を拾い上げていくところからがスタートです。
私の経験上、こういった初期のニーズはRFPから収集することをお勧めします。私が重要だと思うポイントとしては、この段階では、各処から挙がってくる要求はまずは平等に扱っていくことです。意見の強い部門や経営層の声ばかりに耳を貸していると本当に重要な要求が埋もれてしまうので注意が必要です。
どのようなシステムを作るかの前にどのような業務にするかを検討する
要求を収集することができたら、続いて考えるべきことはシステムのことではなく、業務のことのことです。
家づくりを例にしていると、「新しい家でどのような生活を送りたいか」を聞き出すとのことです。合言葉は、「システムよりもまず業務」といってよいでしょう。
IPA情報処理推進機構の中では、次のように述べられており、システム開発において業務が占める重要性が強く示されています。
手作業の機械化は既に終わり、ビジネス改革が求められる中、最近は、経営や業務に直接貢献するITシステムが求められている。ビジネスプロセスの変わらないIT投資は認められない。
IPA情報処理推進機構 家づくりで理解する要求明確化の勘どころ
～システム構築を成功させる要件定義のポイント～
所謂、ここでいる「どのような業務にするか」を検討する部分が”業務要件定義”と言われる部分だといえます。システムをどうこうする前に、どんな業務を実現したいのか、ここが固まっていないままシステムの検討はできません。
スポンサーリンク
現行業務やシステムを把握し、To-Be の変化を明確にする
実現したい業務の姿を整理した後は、たしかにAsIsとToBeの違い、変化を明確にします。
私もシステム開発を通じて何度も「このシステムを導入して何がよくなるのかわからない」「今よりも悪くなる」といった厳しい声を頂いてきました。だからこそ、AsIsと比較したToBeの姿を明確にすることは重要です。
IPA情報処理推進機構では要件定義を実施する人の素養として次のように示しており、要件定義を実施する人に求められるビジネスセンスの重要性は増しているといえます。
システム構築でも、要件定義を捌く人は、何を作るかを聞き出す御用聞きではなく、お客様の課題を共に考える、ビジネスアナリストの資質が求められている
IPA情報処理推進機構 家づくりで理解する要求明確化の勘どころ
～システム構築を成功させる要件定義のポイント～
また、IPA情報処理推進機構では要件定義を次のように定義しているように、要件定義は今（AsIs）と未来（ToBe）との差が明確になっていないといけないと思います。
要件定義は、今と将来の「チェンジ」を創出することである。要求を精査してみると、意外と現状が変わらないことがよくある。何がどれくらいよくなるのか見極める必要がある。
IPA情報処理推進機構 家づくりで理解する要求明確化の勘どころ
～システム構築を成功させる要件定義のポイント～
ステークホルダを洗い出す
要件定義はシステム開発にお金を出す人だけではなく、取引先や一般消費者、利用者などあらゆる関係者がいます。こうした人たちの要求も収集し、整理する必要があると示されています。
そのために、まずはステークホルダを洗い出すことが重要になります。
家づくりの例でいえば、家を購入する夫婦だけではなく、夫婦の両親、将来授かる子どもなどもステークホルダとの例でIPAは例示してくれています。
IPA情報処理推進機構では、Step4でステークホルダを洗い出し、Step5でステークホルダの要求を明確にしています。しかし、私の経験上は、Step1「初期要求（ニーズ）を明確にする」の段階でステークホルダを洗い出し、最初からステークホルダの要求も込みで要求の明確化をする方が効率的といえます。
スポンサーリンク
ステークホルダ要求を明確にする
ステークホルダーを明確にした後は、ステークホルダーの要求も明確にしていくとのことです。
IPA情報処理推進機構でも次のように示されており、ステークホルダーの要求を明確にすることは難しいと思います。
要求を獲得する際、声の大きいステークホルダに流されたり、必要な要求がなかなか出てこないということが起こる。ステークホルダの特性や傾向を把握したうえで、要求の獲得を行う。
IPA情報処理推進機構 家づくりで理解する要求明確化の勘どころ
～システム構築を成功させる要件定義のポイント～
ステークホルダーをどう扱っていくかについては、PMBOKでも１つの知識領域として定義されており、その重要性が伺えます。ステークホルダーマネジメントについてはこちらも併せてご覧ください。
スポンサーリンク
非機能要求など、その他の要求を明確にする
家づくりでいえば、家そのものの要求だけではなく、「セキュリティ面」「治安」「地域社会」「地球環境」「災害対策」といった項目についても要求を明確にしなければいけません。これはシステム開発においては非機能要求と位置付けて解説してくれています。
私の経験上でも、非機能要求がシステムごとの差別化要素にもなってきており、昨今は機能要件よりも非機能要件の方がより重要性を増しているといっても過言ではありません。
非機能要求の検討については、IPA情報処理推進機構が公開している非機能要求グレードが非常に有効です。非機能要求グレードの使い方についてはこちらの記事でもまとめていますので併せてご覧ください。
スポンサーリンク
要求を目的展開する ～要求の妥当性を検証～
要求を洗い出すことができたら、続いてその要求の解像度を上げていく作業に入ります。つまり、真の目的を明確にすることが重要とのことです。
システム開発の要件定義では、最初に出てきた「要求（～したい）」は、「目的／ゴール（～をよくしたい）」と、「手段（～を実行したい）」の2 つが混在しておる場合が多い。それらを整理し、「目的／ゴール」を明確にするということが必要
IPA情報処理推進機構 家づくりで理解する要求明確化の勘どころ
～システム構築を成功させる要件定義のポイント～
このように言われているように、顧客、ユーザーが出す要求はたしかに非常にあいまいなものが多いです。そのため、要求を目的と手段に細分化して解像度を上げていく必要があります。
家づくりの例でいえば、「天井を高くしたい」という要求は手段であると紹介されていますが、その通りです。
私の経験も踏まえて、どのように要求から目的と手段を分解することができるか、この答えは「なぜを最低３回は繰り返すこと」だといえます。なぜ天井を高くしたいのか、なぜ天井が高いと解放感があるのか、なぜ解放感が必要なのか、このように考えることで、天井を高くしたい本当に目的が見えてきます。イメージにするとこのような感じです。
スポンサーリンク
目的から手段を検討する ～要求の充分性を検証～
真の目的が明確になったら、他の手段がないかを検討していくとのことです。
目的を果たすことできるのであれば、より効果的で合理性のある手段を取るべきとのことで、私もそう思います。IPA情報処理推進機構の言葉引用します。
効果的な手段を打つためには、「目的」を明確にすることが重要である。その目的達成起点で「手段」を再検討すると新しいアイディアが発見できることがある。
IPA情報処理推進機構 家づくりで理解する要求明確化の勘どころ
～システム構築を成功させる要件定義のポイント～
イメージにすると次のような関係となります。新たな手段を検討するところまでは実施できているプロジェクトも多いですが、その手段が真の目的を果たしているかどうかの検証までセットで実施することが重要です。
スポンサーリンク
要求の価値／効果を判断し、要求を絞り込む
要求に対して新たな手段を検討できました。しかし、なんでもかんでも実現できる訳ではありません。
そこで、ここから４つのStepに渡って要求事項の絞り込みを行っていくことがIPAの方では示されています。
ここからが要求を絞り込み、要件にしていくフェーズだということができます。むしろ、要件を絞り込み、要件量をコントロールするところこそ、要件定義力の腕の見せ所だと私は思っています。ここまでで要求を発散させましたが、ここからは要求事項を要件にし、収束させていきます。
イメージとしては次のようになります。
図 6.22 要件定義のフェーズを意識した要求コントロール例をもとに作成
要求と要件の違いについてはこちらをご覧ください。
記事の内容から抜粋すると、真の目的とそれを実現するための手段を明確にしたのちに、実際にプロジェクトとして実施する狭義の要件として絞り込みを行っていきます。
要求を絞り込む際のポイントについてIPA情報処理推進機構では次のように挙げていましたので紹介します。
要求を体系的に整理し可視化し説得力を持たせる
経営や業務への貢献度で判断する
貢献度が低いものは、思い切って削減する
IPA情報処理推進機構 家づくりで理解する要求明確化の勘どころ
～システム構築を成功させる要件定義のポイント～
スポンサーリンク
制約・前提条件を明確にする
経営、業務への効果の少ない要求を削ったとしても、プロジェクトには制約、前提条件があります。そこで、まずこのプロジェクトを取り巻く制約条件、前提条件を明確にます。
この制約条件や前提条件がプロジェクトの特性、特色でもあるため、この作業は必ず必要です。私の経験からも言えますが、この制約条件や前提条件を明確にする作業は要件定義の為に実施するだけではなく、プロジェクト計画を策定、もっと平たくいえば、どのようにプロジェクトを進めるかを考えるうえでのテーラリングの段階から必要となる重要な作業だと思います。
IPA情報処理推進機構では、制約と前提条件については次のように定義しています。
制約条件・・・プロジェクトで変更できない外から与えられた条件（予算、納期、契約事項など）
前提条件・・・プロジェクトで確証なく設定した条件（体制や関連システムなど）
IPA情報処理推進機構 家づくりで理解する要求明確化の勘どころ
～システム構築を成功させる要件定義のポイント～をもとに筆者にて記載
スポンサーリンク
制約条件や前提条件を考慮した現実案を検討する
洗い出した制約条件、前提条件をもとに現実的な要件に絞り込んでいきます。
実現可能性についても当然検討しておく必要があります。ただし、今回のIPA情報処理推進機構のStepでは前述の手段検討の段階で、実現可能性について検討済みだと言ってよいでしょう。
現実案を検討する中で前提事項が明確になったり、変更になったりすることもあります。したがって、どうしても絞り込みが難航する場合は、前提条件が本当に足かせとなっているのか、定期的に見直し、監視することも有効です。
要求の優先順位付けを行う
大概の場合、要求は膨れ上がり、結局絞り込みができないままになることが多いです。しかし、それではプロジェクトは成功できません。
最後には膨れ上がった要求は優先順位を付けて絞り込みを行います。
IPA情報処理推進機構の言葉を引用してみます。
システム開発の要件定義では、ほとんどのプロジェクトでは要件が膨らんで失敗の原因になっている。この段階で予算・期間が守れるように要求が絞り込まれることは、なかなか困難。できる限り要求を絞り込んではいるが、さらに優先順位をつけ、いざとなったら今回の対応から外すという合意形成をとっておくことも必要。優先順位は、効果やコストだけではなく、様々な観点から比較する。
IPA情報処理推進機構 家づくりで理解する要求明確化の勘どころ
～システム構築を成功させる要件定義のポイント～をもとに筆者にて文末の記載を一部修正
合言葉は、「勇気を持って切り捨てる」です。
この時、うまく取捨選択するためには、事前に優先順位を明らかにしておくことです。業務の効率化よりも経営への貢献度が高い方を優先する、A事業部の要求よりも業績が好調なB事業部の要求を優先するなど、予めルールを決めておくことでスムーズな要件コントロールが可能になります。
To-Be 業務での変化と価値をまとめる
最終的に、要求を要件として絞り込むことができたら、これらの最後にToBeの姿を描き直すことがIPAの方では示されています。
ただ、Step3現行業務やシステムを把握し、To-Be の変化を明確にするでもAsIsとToBeの姿を比較しています。そして、Step13To-Be 業務での変化と価値をまとめるでまとめ直します。そのため、ここで整理できれば、Step3は必ずしも必要ではないと私は考えています。
スポンサーリンク
ステークホルダと合意形成する
ToBeの姿を描くことができたら、その内容についてステークホルダと合意していくとのことです。
発注者だけではなく、ステークホルダーの合意も必要です。しかし、ステークホルダとの合意は簡単ではありません。とにかく時間を要します。IPA情報処理推進機構も次のように記されています。
必ずステークホルダと合意形成する。しかし、なかなか合意形成できないのが現実だ。要件定義が遅延する理由は合意形成を要するからである。ステークホルダとの合意形成を意識して要件定義プロセスを組む必要がある。
IPA情報処理推進機構 家づくりで理解する要求明確化の勘どころ
～システム構築を成功させる要件定義のポイント～
私の経験上、要件定義の半分は合意形成に充てるべきだと言えます。つまり、2週間かけて作成した要件定義書は合意されるまでに２週間かかるということです。一度の確認だけでは合意は得られず、２度３度とやり取りしていく過程で合意していきます。それだけ合意形成は難しいです。
合言葉は、「要件定義は合意形成の積み重ねである」です。まとめて合意を得ようとしてはいけません。こまめな合意形成こそ、要件コントロールには必須のプロセスです。
次の絵を頭の片隅に置いておくとよいと思います。
スポンサーリンク
要件（仕様）として定義する
最後に、要件としてまとまったものをもとに「契約」という言葉を使って要件を定義するとIPAでは締めくくっています。具体的には、次のようにIPA情報処理推進機構が要件定義書は「契約」そのものだと次のように言っています。
システム開発担当者に「これでシステムを作成してください」と文書（要件定義書）などの媒体を通じてお願いすること。お願いしますということは、開発者がベンダであろうがなかろうが、一種の契約。要件定義書は、契約書なんだと思うべき。
IPA情報処理推進機構 家づくりで理解する要求明確化の勘どころ
～システム構築を成功させる要件定義のポイント～をもとに筆者にて文末の記載を一部修正
昔、私も要件定義を担当していた時、先輩から「要件定義書に書いた１文は1行のコードの10倍の重みがあると思え」と言われたことがあります。それくらい、要件定義書の一文一文は重みがあり、重要だということがわかります。
スポンサーリンク
まとめ・参考文献
いかがでしょうか。要件定義でやるべき15のstepについてイメージできましたでしょうか？要件定義はシステム開発において重要な工程です。要件定義を捌ける人は非常に貴重な存在です。
IPA情報処理推進機構のドキュメントをもとに私の経験も交えてつつ、学んだことを整理しました。今回の内容が要件定義を担当する際の参考になれば嬉しいです。
今回元として、IPA情報処理推進機構のドキュメントについて最後に再度掲載しておきますので、ぜひ本ドキュメントをご覧になってみてください。
スポンサーリンク
システム構築の要件定義に役立つポイント集「家づくりで理解する要求明確化の勘どころ ～システム構築を成功させる要件定義のポイント～」
コメント