※ この記事は、株式会社じげん 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種類の登場人物がいます。
- 開発者（ソフトウェアを作る人、エンジニアなど）
- 起案者（施策案を出す人、ビジネスサイドの人など）
開発者と起案者が同じ人であれば、頭の中にイメージしたものを実際にコーディングすればよいだけなので特に問題はありません。しかし、実際には開発者と起案者が異なるケースのほうが圧倒的に多く、この場合、開発者が作ったものと、起案者がイメージしていたものが違うということが往々にして起こります。
エンジニアにカレーパンを頼んでも要件定義が甘かったらこういうのが出てくる pic.twitter.com/p3Z59NQ2vk
— ヒホ（ヒロシバ）🗑️ (@hiho_karuta) August 5, 2019
それを防ぐために作成するのが、要件定義です。
つまり、要件定義の役割とは、
- なぜそれをやりたいのか(Why)、とそのために必要なこと(What)を明確にする
- アウトプットされたものが正しく作られているかを確認できるようにする
です。
2.3 要件定義が肝である
要件定義について理解できたところで、その重要性について考えてみたいと思います。
開発ライフサイクルの6つのうち、最も重要なフェーズはどこでしょうか？一概にここ、と言える答えはないかと思いますが、私は要件定義が最も重要だと考えています。
それは、神は「順序」に宿るからです。
どんなに優れたコーディングがされ、どんなに優れたデザインをしたものでも、そもそもユーザーが求めていない機能であったり、今リリースするべき施策でないと価値は一切生まれません。
このような過ちを起さないために、今自分たちが置かれている状況と、そこに潜んでいる制約を理解した上で、真にユーザーが求めていることを決めるのが要件定義なのです。
ただし、本稿では具体的にどのように要件定義を作成すれば良いか、という各論を伝えたいわけではありません。具体的な要件定義の作成方法については、こちらの記事が参考になるかと思います。
本稿ではもう少し上流の、要件定義と向き合う姿勢についてお伝えします。
3. 完璧な要件定義など幻想である
ここからが本稿の本題です。起案者の方は、そもそも要件定義を作成する際に、手戻りのない完璧な要件定義を作ろうとしていないでしょうか？
残念ながら、それはほぼ不可能です。
アメリカの航空宇宙メーカー、SpaceX CEOのイーロン・マスク氏が、SpaceXのテキサス工場の中を歩き回りながら、ロケットの製造プロセスについて語っている動画があります。その中で、イーロン・マスク氏は要件定義について以下のように語っています。
まず要件定義ってのがあって「こういうデザインでこういうのを作ってくれ」って計画なんだけど、それらは必ずバカなんだ。本当に文字通りバカなんだ。誰が作ってもどうやってもまず要件定義ってのはバカなんだ。まずそうやって「バカなんだ」って定義しておかないといけない。
一番危険なのはとびきり賢い人が出してきた要件定義で「あの人が作ったんだから大丈夫でしょ」って考えてしっかり質問しないこと。これが一番危険なんだ。私も含めて誰が要件定義を作ってもバカなんだ。だからとにかくそのバカさ加減を少なくすること。所詮は要件定義ってバカだからゼロにはならないけど、とにかくこのステップ１でバカを少なくすること。
※参考：イーロン・マスクのロケット製造５つのステップがサイコーだった
イーロン・マスク氏が要件定義について語る部分から動画が再生されるようになっているので、気になる方はぜひ見てみてください。日本語字幕もあります。
また、BtoB企業のためのweb制作会社、ベイジ代表の枌谷氏も自身のツイートで以下のように述べています。
要件定義書・仕様書・設計書・ワイヤーフレームの類は破綻なく網羅的で完璧であるべし、は幻想。ベストは尽くすべきだが決して完璧にはならない。その前提で妄信せず開発する。開発中の違和感はどんどんフィードバックしていい。理にかなってるなら路線変更していい。というのが当社考え。
— sogitani / baigie inc. (@sogitani_baigie) April 30, 2021
4. なぜ要件定義は不完全なのか
4.1 要求は変化し続ける
では、なぜ要件定義は誰がどう作っても不完全なのでしょうか？その理由は大きく分けて3つあるのではないかと考えます。
まずひとつ目は、要求は変化し続けるからです。
そもそも、「アジャイルは新しい価値を生み出すプロセスであり、要件は固まらないもの」という前提に立っています。
これは、従来は最初から作るものが明確なシステムが大半を占めていましたが、昨今は最初から要求に明確な答えがないことが多く、作るものの不確実性が高いからです。
また、ある時点において正しかった解も、時間の経過につれて顧客のニーズが変化し、正しい解ではなくなります。
アジャイルソフトウェア開発とその諸原則を公式に定義した文書であり、世界的に認められている、アジャイルソフトウェア開発宣言の中でも以下のことに価値を置くと示されています。
4.2 時間軸を考慮する必要がある
ウォーターフォール開発のように、要件定義がきちんと終わらない間は次の工程に進んではならない、というのは一見正しそうに思えます。一方で、要件の妥当性を担保するために工数をいくらでも超過して良いわけではありません。
要件定義に時間がかかりすぎてしまった場合、要求が陳腐化し、リリースできた頃には一切価値がなくなってしまいます。また、全体的なスケジュールの遅延は結果的にコストを膨れ上がらせます。
90点の要件定義を100点にするために工数をかけて、人件費と開発期間中の売上を毀損するくらいなら、要件定義後の手戻りを一定許容した上で、次の工程へと迅速に進めることのほうが全体でみると得策なのです。
4.3 一人の力には限界がある
正しい要件定義を行うためには、幅広いスキルが求められます。一つの施策をリリースするだけでも、そこには多くのステークホルダーが存在するからです。各ステークホルダーにとっての最適解を実現できる要件定義を行うことは容易ではありません。
エンジニアリングの知識はもちろんのこと、ステークホルダーが日々行う詳細なオペレーションにも精通している必要があります。しかし、現実的に、要件定義を行う起案者が一人で必要なスキルすべてを持ち合わせることはかなり難しいのではないかと思います。
小さい組織、事業規模であればそこまで難しいことではないかもしれませんが、組織、事業の規模が拡大するにつれ、この困難性は増していきます。それは関わるステークホルダーの数が増加し、オペレーションも複雑になっていくためです。ある程度成熟した事業において、要件定義を一人で完璧に行うのはほぼ不可能でしょう。
5. 良い要件定義とは
5.1 UXから逆算する
前章までで、完璧な要件定義は幻想であることと、その理由についてご説明しました。それでは、要件定義に価値はなく、作成する意味がないのでしょうか？私はそうではないと思います。イーロン・マスク氏も要件定義は必ずバカである、と言っていますが、価値がないとは言っていません。大事なことは、要件定義は必ずバカである。と定義した上で、ベストを尽くすということです。
それでは、良い要件定義を行う上で大事な条件とは何でしょうか？本稿ではそれを5つに集約し、ご紹介したいと思います。
まずひとつ目はUXから逆算することです。
要件定義の最終的な目的は良いプロダクトを作り、良いUXを提供することです。それによって売上を作り、事業をスケールさせていくことができます。そのためには、どんな要件定義であっても、ユーザー起点で最適なUXを目指す必要があります。
ユーザ目線でない自己陶酔型要件定義 pic.twitter.com/kCoRdOG1Fh
— 麹 (@oryzae1824) July 20, 2021
家を建てる時にいろんな会社に話聞きに行きましたが「どんな間取りがいいか」「何部屋いるか」と聞くところが多い中「家族みんなの趣味は何か」「家でどう過ごしたいか」と尋ねる会社が一社あって、出来上がった仮間取り図も理想通りだったのでそこにお願いした。要件定義ってそーゆー事だわいなー
— Mana (@chibimana) June 8, 2021
良いUXとはなんぞや、ということに関しては本稿では詳細を省きますが、詳しくはこちらがとても参考になるかと思います。
5.2 削ぎ落とす
次に、とにかく削ぎ落とすことです。
プロダクトづくりに関わる人のバイアスとして、「もしかしたら必要かもしれないから付けておこう」というものがあります。これが諸悪の根源となります。
要件定義の際には、このようなムダをとにかく削ることが重要です。
思っている以上に削るという行為は難しく、タフな意思決定であるかと思います。不確実性が高く、正解がないプロダクトづくりでは、各所から「あれも必要かも」「これも必要かも」という声が聞こえてきます。しかしその声に惑わされず、本質的に必要なもののみを抽出することが肝です。
削った結果、もし本当に必要なものだったことが分かれば後から追加すればよいのです。
5.3 個ではなく、チームで作る
要件定義には多くの要素が含まれますが、抽象化すると3つの大きな要素に分けられると思います。それは、以下の3つです。
- Why (なぜそれをやりたいのか)
- What (そのために必要なこと)
- How (どうやって実現するか)
この内、特に起案者側で磨く必要があるのがWhyとWhatです。
理由は、ここが固まっていないとHowを固めれず、不要な手戻りが発生してしまうためです。
反対に、ここをしっかりと考え抜き、固めておけばHowはエンジニアチームに託すことができます。そして、託されたエンジニアチームもWhyとWhatに納得感を持てれば、Howを安心して決められます。
ここで重要なのは全部一人でやろうとしないことです。Howまで責任を持って起案者がガチガチに作り込んでしまうと、エンジニアは提案の余地がないように感じてしまいます。
また、エンジニアの立場になってみると、起案者がイケてないHowを提案してきても、ガチガチに決めてきたものであれば別の提案をしにくいことが考えられます。
個ではなく、チームで要件定義する。このスタンスが重要なのではないかと思います。起案者の能力のMAXが要件のMAXになってしまっていてはもったいないです。そうではなく、チームで要件をMAXにする姿勢が起案者にもチーム全体にも求められます。
5.4 レビューを徹底する
良い要件を作るためには、多くの人にレビューをしてもらい、質問を受けることが必要です。
誰が作ったかどうかに関わらず、どんな要件定義も必ず他者の目を入れるようにすると良いと思います。この際に職種や立場などは関係ありません。
エンジニアであっても、要件定義のWhy, Whatに対して違和感を持つことがあれば、納得いくまで質問するようにしましょう。自分はHowだけに責任をもつのではなく、自分が書いたコードの価値を最大化するためにも、WhyとWhatにも盲目的にならずに踏み込むのが良いかと思います。
適切なレビューをもらうために重要なのは伝わるように書くことです。起案者は、自分が意図していることが他者に伝わらなければ、意味がありません。そのため、「これは伝わるか」という意識を常に持ちながら、要件定義を書くことが求められます。
そして、わかりやすいドキュメントを書くのにも王道はあります。個人的にはこちらがかなり網羅的にまとまっていて、参考になりました。
5.5 3つのシナリオを想定する
要件定義を行い、リリースする目的の一つに仮説検証があります。
短期的にその施策で数値が上がったか、下がったかは本質的な議論ではなく、どのような仮説検証の結果、何がわかったのかが重要です。
数値が上がったにせよ、下がったにせよ、適切に仮説検証を行うことができれば、必然的にネクストアクションが決まってきます。
そう考えたときに、良い要件定義の条件として、次の仮説検証への準備ができているかという視点が見えてきます。要件定義の段階で今行おうとしている仮説検証と、次に行うべき仮説検証を整理しておくことで、施策のスピードを最大化することができるからです。
例えば、フォームにこれまでなかったAという訴求を追加するABテスト施策の要件定義を行っているケースについて考えてみます。要件定義の段階でこの施策をリリースし、仮説検証を行った結果、どのようなシナリオが考えられるかを事前に想定しておくことが重要です。基本的には3つのシナリオを想定しておくと良いと思います。
-
Bestシナリオ
- 仮説がクリティカルヒットした場合
-
Goodシナリオ
- 仮説がある程度当たった場合
-
Badシナリオ
- 仮説がハズれた場合
Bestシナリオの場合のネクストアクションとしては、ABテストの結果を全適用することが考えられます。また、Goodシナリオの場合には、訴求自体はある程度インパクトがあることがわかったので、訴求の伝え方を工夫できるかもしれません。反対に、Badケースの場合には、訴求自体がヒットしないことがわかったので、別の訴求を試してみることができます。
このように施策をリリースする前に、要件定義段階で複数のシナリオを想定しておくことで、次なる準備を事前に進めることができ、次々に打ち手を出せます。PDCAのPに当たる要件定義の段階で、DCAについても事前に考えておくことが重要なのです。
6. おわりに
だいぶ長くなってしまいましたが、これまで私自身が要件定義を作成する中で感じたことと、社外で同じように要件定義に苦労している方たちのTipsをもとに執筆しました。本ドキュメントが少しでも皆さんのお役に立てば幸いです。それでは今年もあと少しですが、頑張っていきましょう！