今回は、システム開発、特に上流工程で良く耳にする「要求」と「要件」について解説します。
皆さんは「要求」と「要件」について正しい理解をし、正しく説明ができますでしょうか？
数々の本で「要求」と「要件」の定義がされていますが、今回はそれらの内容を整理しながら、理解を深めていきたいと思います。
最後に参考文献をまとめていますが、これまでに私が読んだ本での定義を引用しながら、「要求」「要件」を整理します。加えて、実際の現場での使われ方や使われる時の注意点を交えて解説していきます。
特に、赤俊哉さん著書「要件定義のセオリー」は本記事を書くきっかけとなりましたので、ぜひお手にとっていただければと思います。
スポンサーリンク
この記事で分かること
〇要求と要件の違いがわかる
〇要求定義と要件定義が何か理解できる
〇要求と要件のレベルを理解できる
〇要件定義のやり方がわかる
では早速内容を確認していきましょう。
結論
まず最初に結論です。
要求とは、顧客のやりたいことです。
要件とは、要求事項を実現できるように検討した内容であり、実現することです。
そして、要求と要件にはそれぞれビジネスレベル、業務レベル、システムレベルの３つのレベルが存在します。
要求と要件の違いそして、これら３つのレベルの違いを理解して要件定義工程を実施することで、認識齟齬がなくなり、適切なプロジェクト遂行ができるようになります。
要求と要件の違い
各書籍による言葉の定義
まずはじめに各参考文献における言葉の定義を載せたいと思います。
赤俊哉著「要件定義のセオリー」における定義
「要件定義のセオリー」では次のように記されています。
「要求」＝本当に欲しいもの
「要件」＝本当に要るもの
だまし絵を描かないための– 要件定義のセオリー 赤 俊哉 (著)
特に情報システムに焦点を絞っていえば、以下のように述べられています。
「要求」とは、「ユーザが情報システムで実現したい事」を指します。
「要件」とは、「要求」を基に、「制約」を踏まえて、「情報システムに盛り込むべきもの」を指します。
だまし絵を描かないための– 要件定義のセオリー 赤 俊哉 (著)
室脇慶彦著「PMの哲学」における定義
続いて「PMの哲学」での定義を紹介します。
「要求」は、顧客の「したいこと」です。それに対して「要件」は顧客の「したいこと」に基づいて、実際に「できること」にしたものです。つまり、要求事項と制約事項の折り合いをつけて「要件定義」とします。
PMの哲学 室脇 慶彦 (著)
IPA情報処理推進機構「ユーザのための要件定義ガイド」における定義
次にIPA情報処理推進機構が出している「ユーザのための要件定義ガイド」においてどのようにまとめられているかご紹介します。少し長いですが、まずはそのまま引用します。
JIS X 0166 では、要求事項は「ニーズとそれに付随する制約・条件とを変換した又は表
現する文」と定義されている。（中略）
前述のJIS X 0166 において、要求事項(requirement)の注記に「requirement は、通常要
ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ 独立行政法人情報処理推進機構（IPA）
求又は要件と訳される」と記載されているとおり、要求と要件の標準的な定義は存在しない。
本ガイドでは、「要求」はJIS X 0166 における要求事項と同義としている。一方で、要求を
文書化、仕様化し、ステークホルダと合意したものを「要件」と定義する。要件は次工程の
入力となるため、第三者へ伝達可能（例えば、業務部門からIT 部門へ、IT 部門から開発を
担うベンダへ）な形に形式化されている必要がある。
JIS X 0166では定義が存在しないとしつつも、IPAとしては「要求」とは「制約や条件も含めたうえでのニーズ」と定義しています。
そして、「要件」とは「要求をステークホルダと合意したもの」としています。
要求・要件の言葉の定義
それぞれの参考文献の内容をまとめると次のようになります。
これらの内容を本記事として一言でまとめると次のようになります。
「要求」とは、「顧客がやりたいこと」
「要件」とは、「要求に制約を加味してできること・要ることを定義し、さらにステークホルダと合意したもの」となります。
いかがでしたでしょうか。
「要件」という言葉には少し”レベル”があると気づくと思います。すなわち、実際の現場では、要件定義を行い「要るもの」を定義したとしても様々な制約から「実施するもの」が選定されていきます。
つまり、顧客のやりたいことの中から、実現すると決めたことにさらに絞り込みされるイメージです。
そのため、これらの内容を総合して、次の図をイメージしてください。
広義の意味での要件とは「顧客のやりたいことへの実現案」となりますが、狭義の意味では「実際に実現すること」「プロジェクトのスコープ」という意味で使われます。
スポンサーリンク
残念ながら、これらの「要件」という言葉を使い分けるのに適した言葉はなかなか存在しないというのが現実です。
しかし、いずれにしても重要なことは、単に「要求」「要件」という言葉であっても解像度を高く持って使い分けることです。
要求と要件のレベル
要求と要件の整理がつきました。次に、要求と要件のそれぞれについてもう少し解像度を高めたいと思います。
それは、要求と要件にはレベル（階層）があるということです。
「要件定義のセオリー」と「ユーザのための要件定義ガイド」では「要求」を取り上げて次のように説明しています。
３種の要求の意味は以下の通りです。
・「ビジネス要求」＝トップダウンの要求
・「業務要求」＝業務レベルの要求
・「システム要求」＝システムレベルの要求
だまし絵を描かないための– 要件定義のセオリー 赤 俊哉 (著)
要求事項にはいくつかのレベルがあり、「利害関係者要求事項」、「システム要求事項」、「ソフトウェア要求事項」に分類される。
（中略）
本ガイドでは、利害関係者要求事項を「ビジネス要求」、システム要求仕様を「システム化要求定義」と定義している。
経営レベルの利害関係者要求仕様、ビジネス要求（業務レベルの利害関係者要求仕様）、システム化要求（システム要求仕様）の例として、部品メーカの在庫管理におけるそれぞれの具体的イメージを以下に示す。
ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ 独立行政法人情報処理推進機構（IPA）
両者で述べれてている内容は言葉の定義として差異があるため、それぞれで記されている図解を参考に私の解釈として描き直すと次のような階層構造になります。
ビジネス要求について、「要件定義のセオリー」では最上位層で定義しているが「ユーザのための要件定義ガイド」では中間層で定義しているため要記載
今後は「要求」「要件」という言葉を一面だけで捉えるのではなく、どのレベルの話をしているのかを意識するだけで要件定義の質が変わることは間違いありません。
スポンサーリンク
最後にそれぞれの階層が示す要求・要件のレベルの具体的な内容について、私のこれまでの開発経験とともに整理します。ぜひイメージを持っていただければと思います。
〇「ビジネスレベル」・・・経営層・ビジネス責任者、プロジェクトオーナーと合意
システム企画やビジネスモデルの変更、新組織設立、IT以外のビジネスプラン（例：新ビジネスへの拡大に伴う対応。新組織の立上げ）
サブシステム、モジュールの追加（例：ERPシステムにて新しいモジュールの導入(新規にPSモジュールを導入)）
マスタ系（リソース系）の変更（例：取引先マスタ,社員マスタの変更、商品マスタの階層変更）
〇「業務レベル」・・・ビジネス責任者・担当者、マネージャーと合意
業務フローの変更（例：新業務の追加、業務手順の変更）
業務プロセス（5W2Hで定義する業務要件定義書）の変更（例：業務定義、業務（例：請求方法）のやり方の変更）
データモデルの変更、トランザクション系（イベント系）の変更（例：新しいトランザクション、エンティティの追加、トランザクションの登録/削除のタイミング・条件変更、トランザクション登録時の対象属性の変更、処理分岐の追加、処理分岐追加のための業務処理区分の追加など）
〇「システムレベル」・・・マネージャー、業務担当と合意
UI,機能,非機能の変更、画面項目レベルでの追加変更（例：チェック処理の追加、画面項目の移動、単項目の追加）
スポンサーリンク
「要件」を決めるとは何か
要求定義と要件定義の違い
要求と要件にはレベルがあることを整理しました。
しかし、実際のシステム開発ではそれぞれのレベルどころか、要求と要件そのものがほとんど区別されていないのが現状です。
よくあるシステム開発の流れとして案件受注後に要件定義から開始することがあります。しかし、要件定義の中で実際には「要求定義」も行われている、行う必要があることを認識しましょう。
実際の現場では、案件受注前、引合段階で要求定義は粗方完了しているような感覚が持たれがちです。確かに、「やりたいこと」をある程度把握していなければ案件を受注することはできませんし、事前に見積を提出したり、予算を確保したりすることもできません。そのため、案件開始前に「やりたいこと」をある程度抑えていることも事実です。
しかし、その状態で要件定義を開始することは非常に危険です。しっかりと「何をやりたいのか」「ほかにやりたいことはないか」「やりたいことはどのレベルの要求か」を整理しておくことは非常に重要です。なぜなら、後から「そもそもやりたいことが違った」「やりたいことはシステムでは解決できず、業務を変えなければいけなかった」などと問題が多発するリスクがあるためです。
そのため、受注前にある程度「やりたいこと」が把握できていたとしても必ず「要求定義」から始めることを強く推奨します。
また、厳密な言葉の定義としては、顧客からは「要件」はヒアリングせず、「要求」をヒアリングします。顧客から「要件」は出てきません。なぜなら、「要件」は「要求」を基に出来ることをシステム担当が考えるものだからです。
したがって、顧客に対して「ご要件」はありますか、と「要件」を伺うのではなく、やりたいことはありますか、と「要求」を伺うのが正しい姿勢であり、言葉遣いです。
スポンサーリンク
要件定義の進め方
要求・要件はブレイクダウンして考える
ここからは実際に要件定義をどのように行うかを整理します。「要件定義のセオリー」で述べられている内容を引用しながら要件定義の正しい進め方、考え方を説明します。
前述したとおり、「要求」と「要件」にはレベルがあることを整理しました。
システム開発の目線でいえば、最終的には「システム要件」（広義の意味）を明確にするところを一旦のゴールとして目指します。その後、実際にプロジェクトで実施する対象となる「システム要件」（狭義の意味）を様々な制約条件（特にスケジュールやコスト）をもとに決定します。
そのため、まずは、「要求」をブレイクダウンするところから行います。具体的には、「ビジネス要求」を「業務要求」「システム要求」へブレイクダウンします。次に、「業務要求」を「システム要求」にブレイクダウンします。
ブレイクダウンできなかった「ビジネス要求」や「業務要求」、そしてブレイクダウンして浮かび上がった「システム要求」をそれぞれ対応する「要件」に変換していきます。
具体的には、「ビジネス要求」を実現するための「ビジネス要件」を考え、「業務要求」を実現するための「業務要件」を考え、「システム要求」を実現するための「システム要件」を考えます。
このように、「要求」を段階的にブレイクダウンし、それぞれの「要求」をどのレイヤーの「要件」として実現するか、解決させるかを検討します。
ブレイクダウンにおける注意点と具体例
ここで、「要件定義のセオリー」でも述べられている内容を引用しながら、段階的なブレイクダウンを行う際の注意点をお伝えします。
ここで気をつけなくてはならないのは、無理にブレイクダウンしないことです。無理して「ビジネス要求」を「システム要求」にブレイクダウンして整理するということは、本来システムで解決すべきでないビジネス課題に対して、強引にシステム化による解決を図ることを意味します。
だまし絵を描かないための– 要件定義のセオリー 赤 俊哉 (著)
無理にブレイクダウンをせず、適切なレベルに落とし込むことが要件定義は重要です。この整理を間違えると目的と手段を履き違え、要件を実現したとしても要求を満たしていない事態になります。
もう少し理解を進めるために「要件定義のセオリー」で記載されている具体例を挙げます。
・ビジネス要求：マルチチャンネルによる顧客接点の増加。それに伴う顧客及び売り上げ増加。必要となるリソースの配置（人・モノ・金）。
・業務要求：ユーザシナリオの確立。配置された少数精鋭のスタッフによる業務フローおよび業務プロセスの確立。
・システム要求：必要なデータ要件んとプロセス要件の確立。プロセス要件を満たす機能およびUIの構築。
だまし絵を描かないための– 要件定義のセオリー 赤 俊哉 (著)
それぞれのレベルをより具体的にイメージしていただければと思います。
顧客から要求を引き出す際のポイント
当然、要求事項はすべてが「ビジネス要求」といった上位レベルから必ずしも発生するものではありません。業務上、ある条件によって手続きを分けたいという「業務要求」や業務上の管理項目として画面項目を追加したい、もっと使いやすいっように項目の並びを変えたいといった「システム要求」レベルから始まることもあります。
要件定義を行う人や顧客折衝する人は、顧客から出てくる「やりたいこと」がそれぞれどのレイヤーの要求かを常に考えましょう。
最後に私が実際に担当した小規模改修を受注した際の顧客とのやりとりを例に要求・要件のレベルを考えることの重要性を記載します。
ある生産購買システムの保守を担当していたある日、ユーザから「発注区分によっては発注の承認フローはスキップにできないか」と「やりたいこと」の連絡を受けました。
これは所謂、「システム要求」に当たります。しかし、なぜシステムのそのようなことをさせたいのか、どのような業務をやりたいのか、システムレベルより上のレベルでのやりたいことを確認すると、実は、「一定条件を満たしている特約店からの受注に関する購買は、社内承認なく速やかに発注までつなげたい」という業務上の手続きに関する「業務要求」がありました。
そうであれば、発注区分によって承認フローの有無を判断するのではなく、取引先によって判断する仕組みにした方が理にかなっていることになります。実際、顧客にはこちらの内容を提案し、最終的に受注し、改修まで行いました。
よく「目的」を考える、「なぜ」を考えることは重要だと言います。今回の例もまさにその典型例です。「要求」「要件」のレベルを上げて考える（下げて考える）ことは、「目的」を考える、「なぜ」を考える際に非常に助けになるはずです。
ぜひ、実践してみてください。
スポンサーリンク
まとめ
いかがでしたでしょうか。
今回は、システム開発で良く耳にする「要求」と「要件」に徹底的に整理し、考えてきました。
要件定義工程はシステム開発の成否の８割を決めるとも言われる超重要な工程です。しかし、そのような工程であっても「要求」と「要件」が混合しているのが実情です。
実際のプロジェクトではもしかしたら厳密に分けることは難しい部分もたくさんあるかもしれません。しかし、今回の内容のように「要求」と「要件」の違いやどのように要件を考えていくべきかが頭の中で描かれているかでは要件定義の品質に大きく影響してくることは間違いありません。
ぜひ、今回の記事を何度も読んでいただき、理解を深めていただければと思います。
参考文献
・ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ IPA
・だまし絵を描かないための– 要件定義のセオリー 赤 俊哉 (著)
・PMの哲学 室脇 慶彦 (著)
コメント