とにかく大事な要件定義 ~ビジネスを最速かつ最小コストで回すために~

こんにちは、井澤です。
最近行ったロサンゼルスとは全く関係のない記事を書きます。

前回「「作らない、作らせない」ことがプロダクトマネージャーの最大の価値なんじゃないかという話」という記事を書かせて頂きました。

作らない、作らせない

これをPdM(プロダクトマネージャー)としていかに大切にするか、という記事を書いたのですが、「じゃあ、いざ実際に作ることが決定したとき気をつけることは何でしょう？」という話がちらほらあったので、そちらを今度はまとめたいと思います。

ここを外すと後で後悔したり、作った意味がなかったり、ビジネス強制終了という最悪な事態になりかねないと考えています。自分も忘れがちな部分なので今回ちゃんとまとめておこうと思います。

そんな自分のためのメモ (毎度ご意見大歓迎)
※思い出し追記めっちゃしそう

井澤のPdM経歴についてはさきほど取り上げた前回の記事をご確認ください。

とにかく大事なのは要件定義

月並みかもしれませんがこの記事で言いたいのはこちらだけです。要件だけはちゃんと思考を通してからしっかり定義し、プロダクト作りをする必要があります。前回の記事でも、「企業ビジョンを達成するための戦略を経営目線で描き、戦術に落とし込み、最小で必須の要件を整理していくのがPdMとしての仕事」と触れました。この「要件」というのが実は曲者なんです。後から「あぁぁ、思考漏れてた！困ったなぁ…!!」なんてことはザラにあります。そんな「あぁぁ」ってならないように以下基本をまとめました。

ちなみにここで言う「要件」はビジネス要件・機能要件に近いものだと思ってください。PdMサイド、企画サイドが落としてはいけない部分です。一般的には「要求」と呼ばれてる部分がメインで、ビジネスとして動かすのにどうすれば良いか、の部分です。システム設計・非機能要件周りについてはエンジニアの方々がメインで考えてくれる部分かと思うので割愛します。

また、私は「プロダクト = 事業全体を動かすための仕組み」としてかなり広義の意味として捉えているとお話しましたが、以下は利用者がいる前提で記載しています。読み手の方には、状況に応じて読み替えていただければ幸いです。

①最小限の必須要件のみ定義せよ

前回の記事でも言っている一番大事なところです。まずは最小限の必須要件のみ定義しましょう。ここをいかにスリムにできたか次第で実現方法、実現するまでの時間が大きく変わっていきます。利用者は誰で、どれくらいいて、一番実現したい内容はなんでしょうか？そのプロダクトが提供する一番の価値はなんでしょう？検索機能がないとそれは実現されませんか？利用者にほんとにマイページは必要でしょうか？独自の支払い機能って本当に必須なんでしょうか？常に問い続け削れるところはガンガン削っていきましょう。そして最低限の労力で戦略・戦術を高速に実現しましょう。最低限の必須要件がうまく定義できれば、そもそもデザイナーやエンジニアなどの専門職の方の力を借りずとも実現できることは多々あります。そうなると彼ら彼女らでないと実現ができない難易度の高い部分にリソースを集中できる、というメリットも発生します。スリムにスピーディに、これがとにかく大切なことは間違いありません。

②目的に即した計測可能な目標・指標を定義せよ

どんな形であろうとプロダクトをわざわざ作るのであれば、ちゃんと目的に達成できているか計測しなければいけません。その時に目的に即した目標・指標を最初に定義しておくのはとても大切なことです。これを先にしておかないと、プロダクトづくりが終わったときに、計測しておきたかった数字が見れなかった、結果として目的を達成してるのか不明瞭になってしまった、となりかねません。また、「計測可能な」というのはかなり大事なところです。計測できない夢みたいな数字を定義しても仕方ないのはもちろんですが、計測するのが非常に大変なものを定義することも①最小限の必須要件のみ定義せよから外れていってしまいます。最低限見なければいけない目標・指標のみをしっかり整理しましょう。

③作った後にどのような運用が発生するか定義せよ

プロダクトを作って世に出した後の運用についても先にしっかりと考えておきましょう。実作業として、何を、どれくらいの頻度で、どのように運用されるのかを考えておかないと、せっかく出したのにうまくプロダクトを回せなかった、となりかねません。toCサービスであれば、プロダクトの質の監視はもちろん、カスタマーサポート的な動きもあるかもしれません。全てを想定することはできませんが、想定できる範囲で業務フローを練ったり、担当者を決めておくことで、スムーズなプロダクト運用が実現されます。また、現実的な運用を考えたときには、もしかしたら管理画面なども必須要件に入る可能性があります。先に思考を通して損はないでしょう。また、先に運用に頭を回すことで、逆に「あれ、これってわざわざプロダクトで作らなくても運用側で巻き取れるのでは」というプロダクトをスリムにする方向に要件定義が進むことがあります。

④法的・規約的な必須対応事項を定義せよ

ここは特に最初から頭を寄せておきましょう。後から「法的にアウトでした」、など発覚したらビジネスが強制終了することがありますし、ケアが甘いせいで利用者と揉めることなどもあります。基本的なところでいくと利用規約、プライバシーポリシーについては最初から弁護士さんと協力しながら作るのがベストです。仮に適当に作ってしまった場合、後々利用規約を変更するのにも事前通知や、変更後の同意をどのように取ったとみなすか、など想定外の重めの対応が生まれてしまいます。最低限の範囲で構わないので、クリティカルな部分は丁寧に確認して対応しましょう。内容によってはプロダクト側での挙動に影響があるので、そういった意味でも要件としてしっかり定義しましょう。メール配信をするならば特定電子メール法、特典配布やキャンペーンがあれば景品表示法、CtoCのメッセージやりとりがあれば電気通信事業法など、各所に気にするべきところはたくさんあります。ちなみに、キャンペーンを開催するときなども、単純に期限を切り忘れたりすると、確実にどこかで利用者と揉める可能性があります。そういった細かい話でもちゃんと利用者に伝えなければいけない事項は確認し、しっかり伝え、同意をとっておく、という作業はプロダクト運営の観点からも大切なのです。また、外部サービスを使う際にも、自社の法的な対応が不十分で、利用を拒否されたり、利用中に先方の利用規約への対応が不十分なことで、利用提供を止められたりすることもあるので十分な注意が必要でしょう。

⑤利用者の体験・利用者への伝え方を定義せよ

実際にそのプロダクトを通して、「利用者は誰で、その人の何がどのようになるか」、「その利用者はどのように知り、どのような流れで実感するか」はストーリー立てて定義しておきましょう。「利用者は誰で、その人の何がどのようになるか」についてはプロダクトを作る目的そのものになってくるかと思いますが、「その利用者はどのように知り、どのような流れで実感するか」についてはマーケティング的な思考になってきます。この部分を考えておかないとせっかくプロダクトを作っても、誰にも届かなかったり、届いたとしても利用されない、といった悲しいことがおきます。特にプロダクトが目的達成をしているか検証するために初期の利用者をどのように集めるかは、ビジネスを進めていく上で外せない大切な要素です。広告を打つのか、地道に営業をするのか、SNSを活用するのか、イベントを開くのか、など選択肢はたくさんあります。そして、その選択肢によって準備する内容が変わってくるので、こちらも事前にしっかりと定義していきましょう。また、ストーリー立てて思考することで、狙ったターゲットに対するアプローチ方法が洗練されていきます。簡単に人を惹きつけることのできるAmazonギフト券ばらまきキャンペーンなどは、Amazonギフト券を目的としてしまった本質的ではない利用者(利用者とも呼べない)を集めてしまうので、安易に手をつけないよう注意しましょう。

⑥関係者との必要なコミュニケーションと役割分担を定義せよ

最後に、今まで触れてきた要件を達成したプロダクトづくりを円滑かつより質の高いものにするため、関係者とのコミュニケーションと役割分担に目を向けましょう。まずは一緒に作る仲間には目的や背景から丁寧にブレイクダウンしていった要件、そして役割を伝えましょう。どんなに頑張って要件を定義しても、様々な職責の関係者が内容を理解し、それぞれの視点で見ることで新しく気づくことがあります。また、目的から各々がしっかりと理解することで、それぞれの職責の範囲においてのさらなる要件定義、そこから発生する作業の抜け漏れを防ぐことに繋がります。そのためには、まず自身が自身の視点で要件を丁寧に定義しておくことが大切です。そして、安心と信頼の元、仕事をお願いするためには、仲間との同期は必要不可欠だと心がけましょう。また、直接的な作業は共にしなくても、内部・外部に影響しそうな関係者が少しでもいれば事前に告知しておくべきです。自身が見えない範囲にも影響範囲は必ず存在します。スムーズな進行のためにも、関係者との敬意を持ったコミュニケーションと役割分担は疎かにしてはいけません。実際のプロダクトづくりの部分だけではなく、リリースするときには誰がどのような手順で何の作業をし、その際に誰による何が発生するのか、リリース後には誰に何が起こるのか、関係者全員で早いうちに定義して共有し続けましょう。

まとめ

今回要件定義について外してはいけない内容について記述してきました。とにもかくにも最初にしっかりと定義し、関係者と共有して担当者と握るのが大切です。そして、要件をはっきり定義し、関係者に確認してからてからスケジュールは引きましょう。何がどう必要なのかわからないのにスケジュールを先に決めることなどできるわけがありません。もしスケジュールありきでどうしても作る必要があるなら、要件を変えたり、思い切って削りましょう（そもそもスケジュールありきなら、最初からそれ前提で要件を練る必要がありますが、目的ベースで考えると変な話かなとは思います）。

さもないと手戻りや追加作業、浮いてしまう作業等が必ず発生します。そして結果として、最低限の労力で戦略を高速に実現の考えに反し、無駄なコストを生んでしまうでしょう。ビジネスを続けていくのにも大きな悪影響を与えてしまいます。ちなみに大体そんなときは、誰かが犠牲になるパワープレイなどが生まれます。長期的に見ると組織形成の文脈でも最悪な一手と言えるでしょう。

とにかく大事なのは要件定義

これを自分自身も忘れず、疎かにせず、大切にしてプロダクトづくりをしていきたいと思います。

最後まで読んでいただきありがとうございました。

※補足として、、、
外注時などは特に気をつけましょう。大きなお金をかけて、全然目的から外れた成果物が納品されてしまうケースは結構あります。