システム開発などの現場で必須となる要件定義。当たり前のように使っている言葉ではあるものの、要件定義書の記載事項や具体的な要件定義の進め方についてあらためて問われると、返答に困ってしまうという人も多いのではないでしょうか。
今回は、要件定義の概要や要件定義書に記載すべき項目、要件定義を進める際の基本的な流れについて解説します。要件定義を適切に行うために必要なスキルにも触れていますので、ぜひ参考にしてください。
目次
要件定義とは？
はじめに、要件定義に関する基本的な知識を整理しておきましょう。「要件」と「要求」の違いや、要件定義と仕様書の違いを押さえておくことが大切です。
要件定義の位置づけ
要件定義とは、開発者の視点で発注者の要求をまとめ、解決するための具体的な方法を決めることを指します。何をどうシステム化するのか、ドキュメント形式で可視化することが要件定義のゴールと捉えてください。
さまざまな開発プロジェクトは、要件定義にもとづいて進行します。要件定義はすべての開発工程の起点となるため、肝心な要件定義が曖昧だとプロジェクトが迷走する原因にもなりかねません。はじめに要件定義をきちんと固められるかどうかによって、プロジェクトの成否が決定づけられるといっても過言ではないのです。
要件と要求の違い
要件と似た言葉に「要求」があります。発注者からヒアリングした「〜したい」「〜ができるようにして欲しい」といった願望が要求にあたると捉えてください。要求はあくまでも最終到達地点のため、そこに至るまでの道筋を考えなくてはなりません。この道筋を明確にした上で、要求を具現化するための解決策として示したものが「要件」に相当します。
よって、発注者から聞き取った要求を羅列するだけでは要件にはなり得ません。要求を技術的に実現するにはどうすればよいのか、具体的なプログラムやエラー動作などを想定した上で要件定義を固めておく必要があります。
要件定義書と仕様書の違い
要件をまとめた「要件定義書」と混同されやすいドキュメントとして「仕様書」が挙げられます。仕様書とは、要件定義書を元にシステムの詳細な仕様を記述したドキュメントのことです。
よって、要件定義書と仕様書は作成するタイミングが異なります。要件定義書はシステム開発を始める前に作成される一方で、仕様書はシステム開発中に開発者やテスター向けに作成されるのです。仕様書の土台となるのは要件定義書のため、要件定義の段階でシステムに求められている条件や性能、制約条件などを明確にしておかなければなりません。
要件定義は誰が担当する？
要件定義書は、発注者の要求をヒアリングした上で開発者が作成するのが一般的です。発注者によっては、自社が実現したいシステムの条件や解決したい課題を文書にまとめて提示するケースがありますが、これは要求定義書と呼ばれます。開発者は、発注者の要求を元に要件定義書を作成していきます。
したがって、発注者の要求に沿った要件定義を行うには、詳細にわたるヒアリングが欠かせません。要件定義書が完成したら、発注者とすり合わせを行って認識のずれや抜け漏れがないか確認し、開発がスタートしてから手戻りが発生するのを防ぐことが大切です。
要件定義書に記載すべき項目
要件定義書に記載すべき項目として、漏らしてはならない4つの要素について解説します。要件定義書を作成する際には、次の4要素が含まれていることを確認しながら進めることが大切です。
業務要件
業務要件とは、現状の業務フローがどのように流れているかを分析し、問題を抽出した上で何を解決・実現すべきかを決めることを指します。開発するシステムありきで考えるのではなく、まずは現状を整理し、正しく把握しておくことが大切です。
業務要件の把握が不十分なまま開発に着手すると、発注者が本来求めているシステムとは程遠いものになってしまう恐れがあります。発注者が本質的に求めているものは何か、じっくりと見極めておきましょう。
システム要件
システム要件とは、業務要件をどのようにシステムに落とし込むかを決めることを指します。発注者の要求によっては、技術によって解決できること・できないことが出てくる場合もあるでしょう。システムが解決できる課題を見極め、開発の方向性を定めることがシステム要件を作成する主な目的です。
業務要件によっては、システム化が最善の解決策とは限らないケースもあるでしょう。したがって、業務要件とシステム要件は必ずしもイコールにはならない点に注意が必要です。
機能要件
機能要件とは、システム要件に沿って具体的にどのような機能を実装するのかを決めることを指します。必要とされる機能を漏れなく反映させ、最低限実現すべき要件を明らかにしておくことが大切です。
確定した機能要件を元に基本設計が作られていくため、必須の機能に漏れがないか発注者に十分確認を取っておく必要があります。開発が進んでから機能に不足があったことが判明すると、プロジェクト全体の大幅な遅延につながりかねないため注意してください。
非機能要件
非機能要件とは、機能以外の面で発注者がシステムに求める要件のことです。セキュリティやデザイン面などが該当します。開発者にとっては必須とは思えない要求であっても、発注者にとっては成果物に求める重要な要件の1つとなっているケースは少なくありません。発注者の満足度を高めるには、非機能要件を含めて綿密にヒアリングを実施しておくことが重要です。
ただし、非機能要件は「こだわり始めればきりがない」要素ともいえます。開発予算やスケジュールも考慮しながら、実現可能な要件を絞り込んでおきましょう。
要件定義の進め方
要件定義の基本的な進め方を確認しておきましょう。開発するシステムの規模や分野によらず、基本的な流れは以下の通りです。
1. 要求をヒアリングする
はじめに発注者の要求を入念にヒアリングします。一般的には営業部門が担当しますが、必要に応じて開発部門も同行し、発注者が抱えている課題や問題点を探っていきましょう。
ただし、発注者の要求をきめ細かく聞き取ることは要求を丸のみするのとは異なります。要求の本質を見極め、解決可能な課題へと落とし込むのが開発部門の役割です。要求の背景や現状の業務フローを掘り下げてヒアリングし、状況を正しく把握しておく必要があるでしょう。
2. 要求を細分化する
次にヒアリングした要求を細分化し、解決すべき課題の優先順位をつけていきます。すべての要求を100％実現できるとは限らないことから、発注者にとって最も本質的な課題解決につながる要素を洗い出していくことが大切です。
要求を要件定義へと反映させる際には、必須要件と希望要件を分けておく必要があります。希望要件と捉えていたものが実は発注者にとって必須要件だった、といった行き違いが生じることのないよう、発注者とすり合わせながら優先順位づけを進めましょう。
3. 要件定義書にまとめる
細分化した要求のうち、優先順位の高い要素を要件定義書に落とし込んでいきます。まずはシステムの全体像を明らかにした上で、詳細を詰めていくのがポイントです。主な項目として、次のものを挙げておくとよいでしょう。
・システム概要・構想：どのようなシステムを開発するのか大枠の構想を記載する
・要求と必須要件：発注者側の要求と開発者側が整理した必須要件を対応させる
・開発目的：システムを導入する目的や得られる効果について記載する
注意点として、要件定義書は開発者だけでなく発注者も閲覧することを想定して作成する必要があります。技術的な専門用語はできるだけ使わず、非開発部門の担当者にも要点が伝わるように記載することが大切です。システムの詳細な仕様を記述する「仕様書」とは異なる点を理解した上で作成を進めましょう。
要件定義を適切に行うために必要なスキル
要件定義を適切に行うには、どのようなスキルが求められるのでしょうか。とくに重要度の高い4つのスキルについて解説します。
要求を引き出すヒアリングスキル
要件定義のベースとなるのは、発注者から聞き取った要求です。発注者の意図を把握し、要求の本質をくみ取る能力が求められます。発注者が挙げた課題を丸のみするのではなく、課題の背景にある状況や従来の業務フローが抱えている問題点を深掘りしていくことが大切です。
発注者は要求を実現するための技術的な難易度を把握していないケースも多いため、実現可能なシステムかどうかを適切に判断する能力も求められます。先入観を排して発注者の要求に耳を傾ける能力と、開発担当者として現実的な落としどころを探る能力のバランス感覚が求められるでしょう。
システムの全体像を把握するスキル
システムの全体像を把握し、成果物をイメージする能力も求められます。技術的に実現できること・できないことを適切に判断するには、実際に開発に携わってきた経験が欠かせません。必要な開発期間や予算、技術的な難易度を見極めるための知見は必須といえるでしょう。
要求された機能を1つずつ積み上げて全体像を完成させていくのではなく、まず全体像を把握してから詳細な機能要件を詰めていくことが大切です。完成形を先にイメージする能力は、要件定義を進める上で重要な能力の1つといえます。
成果物から逆算して工程を組むスキル
開発の難易度や必要なリソースを見積もり、適切な工数を概算してスケジュールを組む能力も求められます。システムはプログラムの集合体のため、求められる機能を実装するにはどのようなプログラムが必要になるのか把握しておかなくてはなりません。無理のない工程を組むためにも、ゴールから逆算する能力は必須といえるでしょう。
実際の開発実務においては、先に希望納期や予算が決まっているケースも少なくありません。納期・予算に見合った現実的なスケジュールを組むためにも、実現可能な成果物を見通せることは重要な能力といえます。
要件をドキュメントに反映させるスキル
担当者の頭の中で要件ができあがっていたとしても、システムの構想や具体的な成果物を適切に伝えられなければプロジェクトは成立しません。伝えるべき事項を要件定義書に抜け漏れなく記載し、わかりやすく見やすいドキュメントにまとめるスキルも求められます。
要件定義書はシステムを開発する時点だけでなく、将来的に改修や改良が必要になった際にも参照される可能性のある資料です。必要事項を機械的に埋めていくのではなく、読みやすさやわかりやすさに配慮して記載する必要があるでしょう。
まとめ
要件定義は発注者の要求を具現化するために作成されるドキュメントであり、基本設計や詳細設計の土台となる重要な資料でもあります。要件定義書が果たす役割を正しく理解した上で、必須要件と希望要件が理路整然と記載されたドキュメントの作成を目指しましょう。
今回紹介したポイントを参考に、ぜひ要件定義を適切に進めてください。要件定義書を抜け漏れなく作成しておくことでプロジェクトの基盤が固まり、狙い通りの成果物を納品することにも寄与するはずです。
こちらもオススメ：
プロジェクト管理とは？目的や項目、管理手法について徹底解説！ | Backlogブログ
プロジェクト管理の基本や主な項目を紹介。CCPMやWBSなどのプロジェクト管理の代表的な手法やプロジェクト管理全体の流れを解説。これからプロ…
backlog.com