4/28(Sun)
要件定義は、プロジェクトやシステムの開発において、依頼者からの要望や要求を元に開発するべき機能や性能を明確にし、プロジェクトを成功に導くために重要な役割を担う作業です。
本稿では、要件定義の基本と進め方、進行上のポイントについてご紹介します。プロダクトやITシステム開発のプロジェクトに関わる方、要件定義の基礎を押さえてスムーズなプロジェクト進行をしたい方はぜひご覧ください。
＜ この記事で紹介する授業 ＞
先生プロフィール
赤 俊哉（せき としや）
ホームレス寸前から、下請けプログラマー、SEとしてIT業界の最下層に入る。 IT業界の闇を嫌というほど味わいながら、SIの立場で数々の悲惨なプロジェクト体験後、ユーザー企業のIT担当へ。 ユーザー部門にて業務の現場を体験後、デジタル責任者になる。経験の中で上流工程の重要性を認識し、データ中心でビジネス、ITを考えるように。
要件定義とは、システム開発で解決すべき課題を明らかにし、それら課題を解決するために必要な機能や性能、満たすべき条件を明確に定めるプロセスのことを指します。
要件定義はシステム開発の上流工程に位置しており、経営者や事業担当者などのビジネス側（依頼の発案者）の要望・要求を開発観点で整理することと、システムの開発者側に作るべきものの仕様や範囲、条件を正確に伝えるという役割を持ちます。
ここでは要件定義をする２つの目的と、要件と混同しやすい似た言葉との違いを詳しくご説明します。
要件定義には、システム開発を行うことで実現すべき姿を明らかにすること、システム開発を行う範囲（スコープ）を決めることの2つの目的があります。
「実現すべき姿を明らかにする」とは、言い換えると開発する対象物の仕様を確定することを指します。そして仕様を確定するためには「サイトの見やすさを改善したい」や「新しい機能を追加したい」などのビジネス観点の要望に加え、その背景にある事業上・業務上の課題を的確に把握することが必要です。また、開発にかけることが出来る金額や時間などの制約や前提を反映させることも重要です。
「システム開発を行う範囲（スコープ）を決める」とは、開発の対象となる機能や性能に何を含み、何を含まないのかを明確化することを指します。スコープが不明瞭なまま開発を進行すると、関係者間で認識の齟齬が生まれ、結果として成果物の品質低下や依頼者の満足度低下につながりやすくなってしまいます。
要件定義をする上でよく使われる言葉として、「要望」と「要求」があります。一見「要件」と類似している言葉ですが、それぞれ意味や使い方が異なります。混同しないように、違いについて押さえておきましょう。
システム開発における要望とは、依頼者がシステム開発を通じて実現したい希望やアイデアのことを指します。また、要望はその実現手法まで考慮されていない段階のものであり、そのため要望同士の整合性が取れていないことや、優先度が不明瞭であることもあります。
例えばWEBサービスを提供している会社がアプリ開発をする場合を例にすると、「ユーザーの囲い込みのためにサービスをアプリでも提供できるようにしたい」などが要望に当たります。
要求とは、依頼者からの要望を整理してまとめ、具体的に開発を通じて実現すべきことを明確化したものを指します。要望段階では、実現不可能なものや今回の開発の対象にならないものが含まれる可能性もありますが、要求はそれらを整理して、相互に矛盾のない形になっている必要があります。
先ほどの例で言うと、「ユーザーがアプリを使って会員登録、商品の閲覧、購入、注文履歴の確認ができるようにする」などが要求に当たります。
要件とは、システムが要求を実現するにはどのような機能や性能、条件を満たす必要があるのかを、成果物の観点から可視化したものです。そのため、要求よりも具体的な実現方法に落とし込まれたものであり、要求には明確に含まれていないものの、要求実現の上で必要なその他事項も含みます。
先ほどの例で言うと、要求を実現するために必要な画面（ログイン画面、商品一覧画面など）を具体的に定義したり、それぞれの挙動や関係性を明示したりすることは要件に該当します。
ここからは要件定義をする際の進め方と、その一連の流れについて詳しく解説していきます。要件定義は①要求の明確化、②システム要件の検討、③要件定義（要件定義書）の作成と合意形成、の大きく3つのステップで進行します。
要件定義のはじめのステップは、要求の明確化・業務要件定義です。このステップで要望を要求に変えることが求められます。
業務要件定義とはシステム化の対象となる業務のプロセスや求められる結果を洗い出し、現状課題や業務遂行に関わる人、必要な手順・作業を明らかにしていくことを指します。一般的には業務要件は要件定義作成の一連の流れの中でもはじめの方に決め、その後開発のスコープを定めていきます。
冒頭でご紹介したITエンジニアの赤 俊哉先生は、このフェーズで図を使ってビジネスの全体像・業務のあり方と流れ、関係性を整理することを推奨しています。整理の方法について更に詳しく知りたい方は、コースの第2回『要件定義を始める前に』の授業をご覧ください。
要求・業務要件を整理したら、それを実現するためにどのような仕様にするべきなのかの検討に移ります。ここでは要求を要件に変えるために、要求を詳細化し、どうシステムに落とし込むのかを検討・設計する事が必要です。
加えて、要件化する際は、プロジェクトにおける制約条件と前提条件を踏まえたものにすることも求められます。制約条件とは、業務の遂行に生じる制限や条件のことを指します。代表的な制約条件としては、人や物、時間、金、技術的難易度などがあります。また前提条件とは、業務を企画する段階で事前に想定される条件のことです。例えば、新しいシステムを既存システムと連携して使うことが予定されている場合、既存システムと連携できることは前提条件となります。
要求を実現するための仕様の検討が進んだら、最終的にそれを要件定義書などにまとめていきます。要件定義書の内容はケースバイケースですが、一般には依頼の目的やプロジェクトの概要、各種要件、予算やスケジュールなどを記載し、それを元に関係者と合意形成をしていきます。
ここでの合意形成は、関係者が目線を合わせ、プロジェクトをスムーズに進行しトラブルを防止する観点で重要な役割を果たします。そのため、ドキュメント化する際は、ビジネス側が理解でき、かつ開発側がそれを元に詳細のシステム設計フェーズに進める内容になっていることが大切です。
なお、赤 俊哉先生は『要件定義ですべきこと（後半）、後にすべきこと』の授業内で、重点的に確認するべき点として次の項目を挙げています。
続いてここからは、要件定義の構成要素について見ていきます。
前提として要件定義は、立場の異なる複数のステークホルダーが認識を合わせながらプロジェクトを進めるために必要なものです。そのため要件定義には①成果物の合意ができること、②要件定義をもとに設計フェーズに移行できること、③工数や作業規模が見積もれること、が役割として求められます。
一方で、これら目的のために要件定義がカバーするべき範囲は、プロジェクトによって千差万別です。開発手法や規模など様々な事情を考慮して決める必要があります。そのため、以降では一つの参考分類として、FURPS+（ファープスプラス）と呼ばれるモデルを用いて要件定義の構成要素について解説していきます。
【FURPS+】
FURPS+の中の「機能性」とはシステムの機能部分を指し、要件としては機能要件にあたります。機能要件とは、依頼者からの要求を実現するために開発を行う機能のことを言います。
機能要件は例えばショッピングアプリであればユーザーが購入するための機能など、システムが実現すべきことの中核を成す要件です。そのため要件定義の作成者は機能要件を正しく記載する必要があり、開発側には機能要件を必ず達成する事が求められます。
非機能要件とは、システムの機能以外の要件を指し、例えばシステムのセキュリティやパフォーマンスを安定して提供するために必要な事項などを記載します。
FURPS+の分類ではユーザビリティ、信頼性、性能、保守性、プロジェクト上の制約が該当します。それぞれの要素については以下で一つずつ解説していきます。
ユーザビリティ（usability）とは使いやすさ、操作性のことを指します。例えば画面の使い勝手や見た目に関する内容がここに分類され、利用者が思い通りの操作をするために必要な条件をユーザビリティ要件にまとめます。
また、近年はプロダクトの操作性や見やすさは製品の競争力となることも多く、依頼者側の要望に含まれることも多い内容です。そのような背景からも、ユーザビリティはプロジェクト全体にとって重要な要素であると言えるでしょう。
信頼性（reliability）は、システムの停止要件や復旧の容易さ、障害対策などの、システムを安心して使えるかどうかに関する事項を指します。
例えば信頼性要件には、アクセス集中などによるシステムへの過剰な負荷や災害などによってサービスがダウンしてしまった時に備え、復旧までにかかる時間の目標水準を定めたり、年間でどの程度の停止を許容するかを定めることが挙げられます。
いくら機能が良くても、度々システムトラブルで止まったり、一度ダウンしてしまった際に復旧まで時間がかかりすぎたりすればユーザーの信頼を損ねる可能性があるため、十分に定義しておく必要があるでしょう。
性能（performance）とはシステムの処理速度や精度のことを指しており、システムのスピードや効率、応答時間やバッチ処理時間などが含まれます。
例えば、自社サイトに新機能を搭載したとしても、負荷が上がり読み込みに時間がかかり過ぎる等するとかえってユーザーに不満を抱かせる可能性があります。
これらを防ぐためにも適切な性能水準を定めておく必要がありますが、一方で高い処理性能を求めすぎると高コストになりやすいため、実現する性能とコストのバランスを見て判断していくことになります。
保守性（supportability）は、プログラム保守やテストのしやすさ、システムの拡張性、互換性などのことです。
要件定義においてはシステムの完成後も必要な機能を提供し続けられるように、必要なメンテナンスや障害監視の仕組み、異常検知時の対応などについて定めます。そのため、将来的な利用者の増加や利用するソフトウェアのバージョンアップなど、定義タイミングで想定できる将来的な運用を見据えた上で設定していく必要があります。
プロジェクト上の制約（plus constraints）とは、上記4つの項目に当てはまらないその他制約のことで、具体的にはプロジェクトの予算や期間、法規制などのプロジェクトを完遂する上での制限のことを言います。
上でご紹介したコース授業の第4回目『要件定義ですべきこと（後半）、後にすべきこと』では、その他の例としてハードウェア設置場所等の物理的制約や、プログラミング言語の指定などもここに分類されることを紹介しています。
要件定義の範囲はプロジェクトによってさまざまであり、特にどのような開発手法を選択するかに大きく影響を受けます。
これまでの開発手法は、ウォーターフォール型と呼ばれる、要件定義から設計・実装までの流れを順を追って進める手法が一般的でした。一方、近年はアジャイル型と呼ばれる、開発工程を機能毎などに細かく区分して、それぞれで実装とテストを繰り返す手法が増えています。
前者の場合は最初にまとめて詳細まで要件定義することが必要でしたが、後者の場合は、開発を進めながらフィードバックを元に最適化していくため、はじめの段階では詳細まで要件を作り切らないという違いがあります。
これらの背景から、コース授業第3回目『要件定義ですべきこと(前半)』では、開発手法の違いを踏まえても最低限明らかにしておくべきものとして以下を紹介しています。
ここまで、要件定義の代表的な要素について解説してきました。続いて、スムーズな要件定義の実施のために押さえておきたいポイントを見ていきましょう。次の4点についてご紹介します。
要件定義を進行するには円滑なコミュニケーションが何よりも大切です。
要件定義を作成するには、ビジネス側からの要望とその背景の理解、開発側への連携、関係者全員との合意形成などの工程が必要です。そのため、要件定義作成者はさまざまな立場・役割を担う人と関わり、意思疎通できる必要があります。
特に要件定義をする際に関わる人の中には、システムや開発に馴染みのない人が要望を出したり、システム開発を外部の開発会社に依頼することも多かったりと、ビジネスと開発どちらかしか分からないという人も多いです。そのため、関係者間の立場や主張を理解しにくく、合意形成が難しくなることも多々あります。つまり、全ての立場の人が分かりやすく、応えやすいコミュニケーションを心がける必要があるでしょう。
要件定義を進める上では、常に「何を目的にしているのか」「そもそも何のためにこのシステムを作るのか」を念頭におくことも大切です。
要件定義は、さまざまな立場・役割を持つ人と連携して作成します。そのため特に要望を要求に整理していく段階においては、異なる意見の調整や事業観点での優先度の決定が必須になってきます。時には途中で追加の要望があったり、関係者間での合意が得られにくいケースも想定されますが、このような時は常に目的に立ち返ることをすると、軸のぶれないコミュニケーションが可能になります。
要件定義をするために考慮すべきことは、ここまでご紹介してきた通り非常に多岐にわたります。そして、整理した内容を立場の異なる関係者全員で認識を合わせるという難しさもあります。そのため、これらのハードルをクリアするためには言葉だけではなく図式化をうまく取り入れることもポイントです。
例えば、現状の業務フローやビジネスモデル、システムフローやデータモデルなどを図式化することによって、言葉だけで説明すると難しくなってしまう内容も視覚的に伝えることができ、共通認識を持ちやすくなります。
通常プロジェクトの成否は、かけたコストに対して見合ったリターンが得られるかで決まります。また、ビジネス側の要望は、「プロダクトのユーザー数を増やしたい」や「自動化によって業務効率化を図りたい」などの、経営上・事業上の課題に基づくものが多いです。そのため、開発を通じてこれらの課題にどれだけインパクトを与えらえれるのかを、かかるコストも踏まえた上で定量的に評価できるようにしておくのが大切です。
要件定義を行うには前提となるビジネス要求を理解・整理し、関係各所と調整を図るなど様々な力が求められます。ここからは要件定義に必要なスキルについて、次の3つをご紹介します。
ここまでお話ししてきたように、要件定義のプロセスにはさまざまな立場の人とのコミュニケーションが含まれます。その過程では情報を適切に受け取るだけでなく、利害が一致しない場合の調整力も求められるため、特にヒアリング力と調整・交渉力は重要だと言えるでしょう。
要件定義におけるヒアリング力とは、相手の言葉を正しく理解することに留まらず、開発依頼の背景にある課題を的確に把握するための力です。
ビジネス側の人はその業務におけるプロフェッショナルではあっても、常にプロダクトに対する明確な課題や、システムを通じての解決策を把握しているとは限りません。なかなか決定が進まないものについてはなぜ決まらないかを把握して解決策を考える、足りない情報を引き出すなど、積極的にコミュニケーションを取る必要があります。
要件定義における調整力・交渉力とは、要件定義作成に伴う関係者間の合意形成を促す力のことです。
要件定義では最終的に全ての関係者で認識を合わせ合意していく必要がありますが、関係者にはそれぞれの立場や役割があり、前提としている知識も異なるので、はじめから全ての人の利害が一致するとは限りません。また、技術的なハードルや予算やスケジュールなどの制約もあるので、それらを踏まえて内容を決定する必要があります。
そのため、要件定義を円滑に進めるにはバッティングする要望の取捨選択や、方針について意見が食い違う点について妥協点を見つける調整力、妥協案を納得してもらうための交渉力が求められるのです。
要件定義におけるドキュメント・図式化スキルとは、システムの仕様や条件を言葉や数字で明確に示したり、視覚的に物事を見やすくまとめたりする力を指します。
要件定義で作成する文書や図式は異なる立場の人が読むことになる他、システムの完成後に当時プロジェクトには関わっていなかった人が閲覧する可能性もあるものです。そのため技術者にしか伝わらないような言葉遣いは避け、文章の論理構成を意識し、数字や表も使用することで誰が見ても理解できるように分かりやすく表現する力が必要になるのです。
要件定義を作成する上で考慮しなくてはならないことの一つに、プロジェクトのスケジュールや予算があります。いつまでに開発をするのか、開発にいくら使えるのかによって開発に依頼できる内容は変わってきます。これらを踏まえて関係者と連携をとり、適切なすり合わせを行うためにも、要件定義作成者には実現可能性の高い計画を立てる力が求められます。
ここからは要件定義についてより詳しく学びたいと考える方に向けてSchooのおすすめ授業をご紹介します。要件定義について学ぶにあたり、現場でもご活躍されているプロの講師に教わりたいと考える方は、ぜひご覧ください。
＜ コース紹介 ＞
こちらの授業では、ITエンジニア/コンサルタントとして現場で活躍されている赤 俊哉先生より要件定義の一連の流れと、押さえておくべきポイントを詳しく教えていただきます。要件定義について学び始めたばかりの方や、要件定義の流れをもう一度確認したいと考える方にピッタリの授業です。また、一つあたりの授業の長さも30〜40分と短めなので、書籍やサイトで見て学ぶのは不安だけど、素早く体系的に学びたいと考える方におすすめです。
＜ コース紹介 ＞
この授業では、東京高等裁判所でIT専門委員を務めていたご経験もあるITコンサルタントの細川 義洋先生より、ITに関する裁判の例なども交えながら課題解決のための要件定義の作り方を教えていただきます。特にITベンダーに適切な要件を渡せていないといった悩みを抱えている方にぜひ見ていただきたい授業です。
先生プロフィール
細川 義洋（ほそかわ よしひろ）
日本電気ソフトウェア株式会社にて金融業向け情報システム及びネットワークシステムの開発・運用に従事した後、日本アイ・ビー・エム株式会社では、ITコンサルタントとしてシステム開発・運用の品質向上や企業のIT戦略立案の支援を行う他、東京地方裁判所、東京高等裁判所ではIT専門委員を務める。その後、政府にてCIO補佐官を務めるほか、各種システム開発やITガバナンス、ITプロセス品質の向上に携わっている。
＜ 授業紹介 ＞
IT領域やリーダシップについて多数著書を持つ白川 克先生に学ぶ本授業では、発注者がシステムベンダーに伝えるべき情報の言語化の方法を学びます。プロジェクトを持っており、開発側に依頼をすることになったものの、どう依頼すれば良いのか分からない方は是非ご覧ください。
先生プロフィール
白川 克（しらかわ まさる）
ケンブリッジ・テクノロジー・パートナーズのバイスプレジデント。 IT投資計画策定、人事、会計、全社戦略立案など、幅広い分野のプロジェクトに参加。プロジェクトと並行したリーダーの育成、ファシリテーションが武器。著書には「業務改革の教科書」「反常識の業務改革ドキュメント」「会社のITはエンジニアに任せるな！」「リーダーが育つ変革プロジェクトの教科書」「システムを作らせる技術」
本稿では、要件作成のやり方やポイント、必要なスキルなどを、第一線で活躍されているプロの先生の授業をもとにまとめてご説明してきました。要件作成をする力はIT・DX化の進む現代ではなくてはならないスキルです。
Schooでは要件定義について学ぶものだけでなく、IT領域の最新トレンドを押さえた実用的なスキルを学べる授業が8000本以上もあります。ぜひ活用してくださいね。
