完璧な要件定義など幻想である。個ではなく、チームで作る要件定義


※ この記事は、株式会社じげん Advent Calender 2021の記事です。

これはなにか

エンジニア、ビジネスサイドの方に向けた、「良い要件定義の作り方」について書いた記事です。
長文がつらつらと書いてある本稿ですが、要するに言いたいことは、

● 完璧な要件定義など幻想であり、誰がどう作っても不完全である ● そのため、一番危険なのは、とびきり賢い人が出してきた要件定義で、 「あの人が作ったんだから大丈夫」と盲目的に考えること ● 完璧にはならないことを受け入れ、ベストを尽くす姿勢が大事 ●そもそも、アジャイル開発において、完璧な要件定義は求められていない ●良い要件定義には以下のスタンスが必要  ● UXから逆算する  ● 削ぎ落とす  ● 個ではなく、チームで作る  ● レビューを徹底する  ● 3つのシナリオを想定する

ということです。

※約1万字あり、また各章について深く掘り下げる項目は別記事を添付しています。そのため、モバイルで通読するにはすこし骨が折れるかもしれません。気になる章をピックアップしてお読みいただければと思います。

目次

1. はじめに
2. 要件定義とはなにか
 2.1. ソフトウェア開発ライフサイクルの全体像
 2.2. 要件定義の役割
 2.3. 要件定義が肝である
3. 完璧な要件定義など幻想である
4. なぜ要件定義は不完全なのか
 4.1. 要求は変化し続ける
 4.2. 時間軸を考慮する必要がある
 4.3. 一人の力には限界がある
5. 良い要件定義とは
 5.1. UXから逆算する
 5.2. 削ぎ落とす
 5.3. 個ではなく、チームで作る
 5.4. レビューを徹底する
 5.5. 3つのシナリオを想定する
6. おわりに

1. はじめに

株式会社じげんの廣瀬です。
企画マーケティングユニット ディレクターチームに所属しており、普段の業務では開発ディレクションをメインに、プロダクトのUX改善などを担当しています。

今年も気づけばもう終わり。ぼちぼち忘年会の予定が入っている方や、この1年の振り返りを行っている方も多いのではないでしょうか。

日々、ソフトウェア開発に携わっている方は今年も多くの要件定義を目にし、開発してきたことと思います。その中で以下のような経験はないでしょうか?

  • 要件定義を作成したものの、エンジニアに浴びるような質問を受け、Slackのラリーに疲弊した
  • 起案者から渡された要件定義に対してアイデアはあったものの、意見するか迷い、中途半端でモヤモヤするリリースをしてしまった

本稿はそんな皆様に向けた記事になります。

※本稿はアジャイル開発、内製化された開発チームを前提としていますが、それ以外の方にも共通する部分は多分にあるかと思います。

2. 要件定義とはなにか

2.1 ソフトウェア開発ライフサイクルの全体像

本題に入る前に、ソフトウェアを開発するプロセスの全体像についてです。
一般的に一つの施策をリリースするまでには、以下のように6つのプロセスを経る必要があります。そして、このプロセスのうち、最初に行うのが要件定義です。


※参考:【簡単解説】システム開発ライフサイクルとは?~6つのフェーズとモデル例~

ウォーターフォール開発と違い、アジャイル開発においては、開発したい機能ごとに細かい開発ライフサイクルを何度も繰り返します。


※参考:【簡単解説】システム開発ライフサイクルとは?~6つのフェーズとモデル例~

2.2 要件定義の役割

要件定義とは何でしょうか?企業や開発者により、回答は若干異なるかと思いますが、グーグルで検索してみると、以下のような回答が得られました。

必要な機能や要求をわかりやすくまとめていく作業のこと

※参考:要件定義とは?何をすべき?流れ・必要なスキルをわかりやすく解説!

これでもまだ少しわかりにくいですね。もう少し噛み砕いてみようと思います。
一つの施策をリリースする際は大きく分けて2種類の登場人物がいます。

  • 開発者(ソフトウェアを作る人、エンジニアなど)
  • 起案者(施策案を出す人、ビジネスサイドの人など)

開発者と起案者が同じ人であれば、頭の中にイメージしたものを実際にコーディングすればよいだけなので特に問題はありません。しかし、実際には開発者と起案者が異なるケースのほうが圧倒的に多く、この場合、開発者が作ったものと、起案者がイメージしていたものが違うということが往々にして起こります。

それを防ぐために作成するのが、要件定義です。

つまり、要件定義の役割とは、

  • なぜそれをやりたいのか(Why)、とそのために必要なこと(What)を明確にする
  • アウトプットされたものが正しく作られているかを確認できるようにする

です。

2.3 要件定義が肝である

要件定義について理解できたところで、その重要性について考えてみたいと思います。
開発ライフサイクルの6つのうち、最も重要なフェーズはどこでしょうか?一概にここ、と言える答えはないかと思いますが、私は要件定義が最も重要だと考えています。

それは、神は「順序」に宿るからです。

どんなに優れたコーディングがされ、どんなに優れたデザインをしたものでも、そもそもユーザーが求めていない機能であったり、今リリースするべき施策でないと価値は一切生まれません。

このような過ちを起さないために、今自分たちが置かれている状況と、そこに潜んでいる制約を理解した上で、真にユーザーが求めていることを決めるのが要件定義なのです。

ただし、本稿では具体的にどのように要件定義を作成すれば良いか、という各論を伝えたいわけではありません。具体的な要件定義の作成方法については、こちらの記事が参考になるかと思います。

本稿ではもう少し上流の、要件定義と向き合う姿勢についてお伝えします。

3. 完璧な要件定義など幻想である

ここからが本稿の本題です。起案者の方は、そもそも要件定義を作成する際に、手戻りのない完璧な要件定義を作ろうとしていないでしょうか?

残念ながら、それはほぼ不可能です。

アメリカの航空宇宙メーカー、SpaceX CEOのイーロン・マスク氏が、SpaceXのテキサス工場の中を歩き回りながら、ロケットの製造プロセスについて語っている動画があります。その中で、イーロン・マスク氏は要件定義について以下のように語っています。

まず要件定義ってのがあって「こういうデザインでこういうのを作ってくれ」って計画なんだけど、それらは必ずバカなんだ。本当に文字通りバカなんだ。誰が作ってもどうやってもまず要件定義ってのはバカなんだ。まずそうやって「バカなんだ」って定義しておかないといけない。

一番危険なのはとびきり賢い人が出してきた要件定義で「あの人が作ったんだから大丈夫でしょ」って考えてしっかり質問しないこと。これが一番危険なんだ。私も含めて誰が要件定義を作ってもバカなんだ。だからとにかくそのバカさ加減を少なくすること。所詮は要件定義ってバカだからゼロにはならないけど、とにかくこのステップ1でバカを少なくすること。