要件定義と要求定義の８の違いをシステム開発のプロが解説

あなたは今、新規事業のアイデアがありシステム開発をエンジニアに依頼しようと思っている。色々とシステム開発のフローを検索する中で「要求定義」と「要件定義」という二つの工程があることを知った。

しかし、この二つの違いはいまいちわかりづらい。エンジニアに依頼する前に自分自身がしなければならないことはなんなのかがわからず困っているのではないだろうか。

実際、要求定義と要件定義は全く違う。その最も大きな違いは目的と実施する担当者だ。

例えば、目的で言うとそれぞれ以下のようになる。
・要求定義の目的は実現したい理想をエンジニアに伝える
・要件定義の目的は実現したい理想を元に、現実の制約条件を踏まえて開発の方向性を決める

また、担当者はそれぞれ以下のようになる。
・要求定義の担当者は発注者
・要件定義の担当者は受注者（エンジニア）

他にも以下のような違いがある。
・目的の違い
・作業の担当者の違い
・作業の順番の違い
・成果物の違い
・必要になる情報の違い
・作業段階で注意することの違い
・作業中に関わる人の違い
・作業工程に要する期間の違い

この記事では、こういった違いを徹底的に解説する。両者の違いについて理解し要求定義をしてからエンジニアに相談するようになっていただき、最高のシステム開発を実現していただければ幸いである。

1 目的の違い

要求定義と要件定義の最も大きな違いはその目的だ。

以下の章で、その違いを説明する。

1-1 要求定義の目的は、開発者にシステムで実現したい理想の状態を伝えること

要求定義の目的は、発注者が、エンジニアにシステムで実現したい理想を伝えることだ。

発注者が事前に理想像をエンジニアへて伝えていないと、エンジニア側の事情（期間、資金、人材）が開発に強く反映されやすくなる。その結果、開発者の希望とは異なったシステムが開発されてしまう可能性があるのだ。

こういった問題を防ぐために、発注者は要求を明確に定義し、エンジニアが自分と理想イメージを事前に共有していく必要がある。

例えば、以前筆者が参加したプロジェクトでこんなことがあった。そのプロジェクトではプロジェクト発注先企業のウェブサービスの利用状況を確認できるアナリティクスツールを開発していた。

全体のタスク管理には外部のタスク管理ツールを使っていたが、一部のメンバーからアナリティクスツール上でも関連タスクを管理したいという話がでた。そして気を利かせたエンジニアが、要求が固まっていない段階で作業を始めてしまった。

その結果、タスク管理の場所が外部ツールとアナリティクスツール上の２つに分かれてしまい、タスクの管理が効率的にできない状態がしばらく続いてしまった。

これなども、現状を整理しどこでタスクを管理するべきかと言う理想を言語化していれば、アナリティクスツールへのタスク管理機能は開発が不要だったかもしれない。

1-2 要件定義の目的は、要求と実現可能性を考慮して開発の方向性を定めること

要件定義の目的は、発注者から提示された要求をもとに、以下の現実の制約を踏まえてシステムで実現する事の方向性を定めることだ。
・システムのリリース期日
・予算
・人員
・利用可能な技術

要求として提示されるものは理想の状態、つまり「松竹梅」で言うと松プランだ。しかし、開発期間・予算・人員・利用可能な技術は限られているのが現実だ。そのため、松プランである理想の状態を実現できるとは限らない。

例えば、以前筆者が参加したプロジェクトでこんなことがあった。とある診断ツールを開発していたが、その診断結果をPDF形式で出力したい、なおかつそのPDFのレイアウトをカスタマイズ可能にしたいという要求であった。

しかし、リリーススケジュールやその機能がどれくらい使われるのかわからないと言う事情を加味した結果、要件をPDFの出力機能だけに絞り、レイアウトは一つだけでカスタマイズはしないという方向に落とし込んだ。つまり、要件定義の段階で「レイアウトのカスタマイズ」という機能要求を一旦削ぎ落としたのだ。

2 作業の担当者の違い

作業の担当者は要求定義と要件定義で異なる。

以下の章で、その違いを説明する。

2-1 要求定義の担当者は、発注者

要求定義をするのは発注者だ。

この作業はビジネス目的を達成するためにシステムで実現したいことを定義する工程である。そのため、ビジネス目的を深く理解している人が担当する必要がある。

逆にビジネスに対する理解が甘いものが行うと、ビジネス的に妥協した要求定義になってしまう可能性が高い。

2-2 要件定義の担当者は、受注者（エンジニアサイド）

要件定義をするのはエンジニアだ。

この作業はシステムで実現する事を決める工程である。そのため、システムを理解している者が行う必要がある。

逆にシステムを理解していない者が要件定義を行うと、実現不可能な要件に落とし込まれる可能性がある。その結果、最悪の場合プロジェクトが大幅に遅延したり、リリース後に障害が多発して使えないシステムという評価を受けることになりかねない。

3 作業の順番の違い

作業の順番は以下の通りである。

3-1 要求定義は要件定義の前に行う

要求定義は要件定義の前に行うものだ。要求をもとに要件定義で実現可能性を加味して、システム開発の方向性を決める。

4 成果物の違い

要件定義と要求定義の成果物は大きく異なる。

以下の表は、それぞれの成果物を表している。

要求定義	要件定義
・システムで実現したい理想の状態を記したテキスト・システムの全体像・想定するユーザの行動シナリオ・プロジェクトの制約条件（期間、予算、人など）・要求一覧	・ラフなUI（画面遷移図）・必要な機能の一覧・簡易なデータモデル図

また、続く章でそれぞれ詳しく見ていく。

4-1　要求定義の成果物

要求定義の成果物として重要なのは以下の５つである。下に具体的な成果物の例とそれを作る目的などを示した。
・システムで実現したい理想の状態を記したテキスト
・システムの全体像
・想定するユーザの行動シナリオ
・プロジェクトの制約条件を記したテキスト
・要求一覧

4-2 要件定義の成果物

要件定義の成果物として重要なのは以下の3つである。下に具体的な成果物の例とそれを作る目的などを示した。
・簡易なUIと画面遷移図
・必要な機能一覧
・簡易なデータモデル図

5 必要になる情報の違い

要求定義と要件定義で、それぞれの工程のアウトプットの質を上げるために欠かせない情報も異なる。

5-1 要求定義で必要になる情報

要求定義でアウトプットを作るために必要になる情報は以下の通りだ。
・理想とする世界観
・システム開発で実現するビジネスのロードマップ
・ビジネスの財務状況や財務戦略

これらの情報は要求事項と開発の制約条件を把握するために必要だ。

「理想とする世界観」とは「誰の何を解決するのかという理想とする情報」のことだ。たとえば以下のようなテキストだ。これは、要求一覧やシステムの全体像を出すために必要になる。

「システム開発で実現するビジネスのロードマップ」とは「いつまでに何ができているべきか」が示されたタイムライン形式の資料のことだ。このタイムラインは向こう1年間を四半期ごとにざっくりと区切ったもので良い。これは要件定義で「何を作り、何を作らないか」、また「どう言う順番で作るか」を決める際に必要だ。

「ビジネスの財務状況や財務戦略」とは、いつどれくらいシステム開発にお金を使えるのかがわかる資料のことだ。通常はプロジェクトのP/Lを作る際にシステム開発にかける人件費として特定されているだろう。

これは開発にいつどれくらいの人数を使うことができるのか、つまりどのタイミングでどれくらいの開発力を確保できるのかを把握するのに必要だ。これがわかれば要件定義で「何を作り、何を作らないか」を決められる。

5-2 要件定義で必要になる情報

要件定義でアウトプットを作るために必要になる情報は以下の通りだ。
・システムで実現する理想の世界観
・想定するユーザの行動シナリオ
・プロジェクトの制約条件

要件定義では前述の通り、以下のアウトプットを作成する必要がある。
・簡易なUIと画面遷移図
・必要な機能一覧
・簡易なデータモデル図

ユーザの行動シナリオとシステムで実現したい理想の世界観は、要件定義のアウトプットの全てを作るのに欠かせない。

また、プロジェクトの制約条件は、利用可能な予算とプロジェクトの期待されるリリース日までに開発が可能な機能を絞り込んでいくのに欠かすことができない。

6 作業段階で注意することの違い

要求定義・要件定義では作業者が異なるので、作業上の注意点が変わってくる。この章では、そこの差異を説明する。

6-1 要求定義では要望の抜け漏れがないことに注意する

要求定義では、実現したいことの要望を漏れなく出し切る必要がある。

要望の漏れがあることで起きうる問題は以下の２つだ。
・システム開発完了後に実現したかったことが実現できていない
・開発中に追加で矛盾した要求が出てきてしまう。その結果、開発の手戻りの発生やスコープが広がりすぎてしまい、予定したスケジュールでシステムが完成しない

6-2 要件定義で注意すること

要件定義で注意することは主に以下の3つだ。
・要求にあいまないな点があれば、それを明確にする
・要求に抜け漏れがないかを確認する
・要求と制約事項を考慮して、実現可能なシステム開発の要件に落とし込む

要求に曖昧な点を残したくない理由は、曖昧な点を放置しておくと、プロジェクトの後半で手戻りや本来不要だったはずの追加対応コストが発生する原因になるからだ。

要求の抜け漏れを無くしたい理由は、システム開発で実現したかったものをしっかりと実現できることを担保するためだ。また前述の通り、要求の抜けがあると要求が追加されたタイミングで、本来であれば不要だったはずの追加の対応コストが発生する可能性があることも理由の一つだ。

要求と制約事項を考慮して実現可能なシステム開発の要件に落とし込む理由は二つある。

一つ目は、要求はそもそも全てを実現できるわけではないからだ。

二つ目は、システムで実現するべきではない要求が含まれていることがあるからだ。実際、要求通りに開発してしまったがために、機能が多すぎて逆に使いづらいシステムになってしまう事例は多々発生している。

そのためエンジニアはシステム開発のプロとして、発注者の要求を全て受け入れてはいけない。ビジネス的に実現したいことを踏まえて何をシステムで作るべきかを発注者と一緒に議論しながらこの工程を進めていく必要がある。

7 作業中に関わる人の違い

7-1 要求定義では発注者だけの作業で完結する

要求定義で活動するのは発注者だけだ。

この工程で行うことは、すでに事業化することを承認された企画案をエンジニア向けの内容に書き直すことだ。そのため、エンジニアとの折衝などは不要だ。

7-2 要件定義では発注者とエンジニアが共同する

要件定義で活動するのは、エンジニアと発注者の二人だ。

この工程で行うことは、エンジニアが要求をもとに制約条件を踏まえて、システムの方向性を決めていく。この過程では、発注者と受注者であるエンジニアがシステムの方向性を議論しながら認識のすり合わせを行っていくことになる。

8 作業工程に要する期間の違い

8-1 要求定義では１週間程度が目安

要求定義にかかる期間の目安は、おおよそ１週間だ。

新規のシステム開発に当たっては企画書が作成されている可能性が高い。要求定義では、この企画書をエンジニア向けにわかりやすく伝える、この言い換えの作業だけになる。そのため、ここにかかる工数は１週間程度におさまる。

8-2 要件定義は１〜２ヶ月が目安

要件定義にかかる期間の目安は１〜２ヶ月だ。

この工程では、主に以下の二つの作業が発生する。
・エンジニアが要求事項を正確に把握する
・発注者とエンジニアが議論を通じて何度もシステムの方向性を修正・改善して磨いていく

一つ目に関しては、エンジニアがシステム開発の方向性を定め、良い提案をするためには、そもそも要求を正確に把握する必要がある。ここには一定程度の時間が必要になる。

二つ目に関しては、両者の間でやり取りの往復が何度も発生することになる。そして、その度にエンジニア側では成果物の修正をする必要がある。これにも相当の時間が必要だ。

9 システム開発は要件定義だけではなく要求定義が肝

システム開発においては、要件定義の前にしっかりと要求定義を行うことがとても重要だ。

要求定義の目的はビジネス的な理想を明確にすることである。要件定義の目的は理想を実現するために要求を削ぎ落としていくことである。いわば、発注者が理想を語り、エンジニアが実現可能な方針を作るために理想を現実へと引き寄せる綱引きをするようなものだ。

両者がプロとして主張し合い、落とし所を見つけることができれば良いプロダクトが出来上がる可能性が高まる。しかし、要求定義に甘さがあると以下のようなことが起きる。
・要求定義をしていないと、エンジニアが作りやすいものが出来上がってしまう
・要求漏れがあると、後続の作業が大幅に修正される可能性がある

9-1 要求定義をしていないと、エンジニアが作りやすいものが出来上がってしまう

要求定義をしていないと、エンジニアが作りやすいものができてしまう可能性が高い。

要件定義は実現可能なシステムの大枠を定義するのが目的である。そのため実現可能性が重視される。だから、要求がなければ実現可能性を重視して話が進んでいく。あえて難しい開発が必要になる提案をするインセンティブがないのだ。

例えば、タスク管理ツールを開発する場合を考えてみる。極端だが、タスクに親子関係を持たせたいという要求がなければ、要件としてタスクに親子関係を持たせることが定義される可能性は低い。なぜなら、親子関係を持たせるというのは一定の複雑さを伴うからだ。

9-2 要求漏れがあると、後続の作業が大幅に修正される可能性がある

要求に漏れがあると、後続の作業が大幅に修正される可能性がある。

要求に基づいて要件が定義され、その要件に基づいて開発が進んでいく。そのため、要求に漏れがあると、玉突き事故的に後続の作業にも影響を与え、大幅な工数遅延が発生する可能性が高い。

例えば、日記アプリを開発するとしよう。日記の記事は更新ができるという機能を想定する。この時に、更新履歴と各更新時点でのスナップショットを閲覧する機能が欲しいという要求が抜けていたら、要件定義や設計、開発全てをやり直す必要がある可能性がある。

まとめ

要件定義と要求定義の違いについて、様々な観点から見てきた。また、要求定義が重要である理由も最後に念押しでお伝えした。

ここまで読んでいただいた発注者の方には、システム開発で失敗しないために、要求定義をしっかりと行ってからエンジニアに相談することをお勧めする。もしそれが難しければ、ビジネス観点をしっかり持っていて、一緒にいいものを作りたいと思っているエンジニアに要求定義の段階から手伝ってもらうことを推奨したい。

要件定義と要求定義の８の違いをシステム開発のプロが解説