何かサービスを開発する時に、以下のような状態に陥ることがあります。
- 「要求」だとか「要件」が曖昧なまま開発に入ってしまう
- 形だけの要件定義書を作り、開発に入ると見返さない(形骸化してしまう)
このような状態になってしまうと、大体は大きな手戻りが発生したりプロジェクトに損失を与えてしまいます。
これを防ぐためにも、要件定義の役割と重要性を理解しておくことは大事です。
「タクシー配車アプリを開発する」というプロジェクトを例に出しながら考えてみます
要求・要件・仕様の違い
ざっくりとですが、プロジェクトを始める際には要求・要件・仕様の3つを考える必要があります。
要求とは
要求とは、**「ユーザーがサービスで実現したいこと」**です。
タクシー配車アプリでは「手軽に近くのタクシーを呼びたい」など。
ニーズとウォンツのような話だと、ニーズ(=目的)ということになります。
要件とは
要件とは、**「どのようなサービスを開発するか」**です。
例では「現在地から近いタクシーを探せる」「目的地の位置情報をマップで入力できる」など。
ニーズとウォンツでは、ウォンツ(=手段)ということになります。
仕様とは
仕様とは、**「サービスの制約や実現手段」**です。
例では「GPSで位置情報を取得、3km以内のタクシーを対象とする」「検索時のレスポンスは2秒以内」など。
要件定義の役割とは
要件定義とは、その名の通り上記で言う「要件」を定義するものです (要求や詳細な仕様を決めることも含めて要件定義と言う場合もあります)。
要件定義の役割とは、**「ビジネスサイドとエンジニアサイドの橋渡し」**になります。
よく次のようなことが起きます
「プロダクトオーナーが、開発中のサービスで〇〇をやりたいと言って、それを口頭で聞いたエンジニアが上手い具合に解釈して実装した」
これでは、後々に仕様変更で苦しむ未来が見えますね…
本来、プロダクトオーナー(ビジネスサイドの人間)のやるべきことは、サービスで実現したい事とビジネス上のKPIやKGIを設定し、そこに責任を持つことです。
つまり、要件が要求を満たしていることについて合意が取れれば、それより下の工程について関わる必要はありません。
そして、開発チーム(エンジニアサイドの人間)のやるべきことは、サービスに必要な要件を元に、詳細な仕様やアーキテクチャを決め、それの実装に責任を持つことです。
テストを書く時も、仕様及び要件さえ満たせていればいいので「ユーザーが実現したいことは…」などと悩む時間は必要ないはずです。
そもそもビジネスサイドとの合意が取れているので、要件さえ満たしていればリリース可能と言うことになります。
この**両者の認識を擦り合わせて、合意を取るための行為が「要件定義」**となります。
このようにレイヤーをしっかり区別することで、各ステークホルダの責務を明確にすることができます。
要件定義でしっかり要件を明文化しておくことで、テストを書いたりレビューをする際も要件定義書を参照することで悩む必要が無くなります。
チームメンバーの能力とリソースを最大限に生かして、生産性の高いハッピーな開発🍻を行うためにも要件定義はしっかりやりましょう！！
要件定義フレームワークの例でRDRAというものを紹介しています
「リレーションシップ駆動要件分析(RDRA)」