プロダクト要件定義の議論スタイル
今年の4月にナレッジワークを創業しました。
創業以来ほぼ毎日、創業メンバー7人で議論をしながら、プロダクトづくりを進めてきました。
今日は僕たちがプロダクトの要件定義にあたって、どのようなスタイルで議論を進めているかをナレッジシェアさせて頂きます。
あくまで僕たちのスタイルにしか過ぎないのですが、もしも少しでも参考になる部分があれば幸いです。
●プロダクトの要件定義議論における役割
ナレッジワークのプロダクトづくりにおいては、プロダクトオーナーやプロダクトマネジャーだけでなく、UIデザイナーやフロントエンドエンジニア、バックエンドエンジニアみんなが機能や要件の議論に参加し、意思決定をしています。
その際に、それぞれが「マーケットの視点」「プロダクトデザインの視点」「テクノロジーの視点」の3つをもとに意見を出すことを意識しています。
「マーケットの視点」とは、端的に言うと「儲かるかどうか？」。
どんなに便利なものを作ったとしても、顧客がお金を払ってくれなければプロダクトとしては成立しません。
ビジネスチーム（と言ってもまだ僕しかいませんが）やそのリーダーである私は、マクロ・ミクロ両面からマーケットを理解し、ニーズ（顧客の願望や課題）とバリュー（顧客に提供する価値）を定義することが最も大切な仕事です。
「プロダクトデザインの視点」とは、端的に言うと「使えるかどうか？」。
どんなに受注できるものを作ったとしても、顧客が日々使ってくれなければプロダクトとしては継続していきません。
デザインチームやそのリーダーのPdm/UXデザイナーの徐福は、「マーケットの視点」で定義したニーズに応え、バリューを届けるために必要な顧客体験（UX）を定義し、要件に落とし込んでいくことが最も大切な仕事です。
「テクノロジーの視点」とは、端的に言うと、「作れるかどうか？」。
どんなに開発したいものがあったとしても、技術が実装できなければプロダクトとして開発することはできません。
エンジニアリングチームやそのリーダーCTO川中は、「プロダクトデザインの視点」で定義した要件をもとに、実際の開発を進めていくことが最も大切な仕事です。
ここまではよくある役割分担ですが、僕たちの開発の特徴は
A：「マーケットの視点」→「プロダクトデザインの視点」→「エンジニアリングの視点」という順番で川上から川下に流れていく開発
ではなく、
B：「マーケットの視点」⇄「プロダクトデザインの視点」⇄「エンジニアリングの視点」というように、フラットに議論をしていく開発
であるということです。
いずれの開発にもメリット・デメリットがあり、一概にどれがいいとは限りません。
私たちのようにBtoB向けのソフトウェアの場合は、エンジニア自身にユーザー体験がないので、Aでやった方が効果も効率も高いという場合も多々あります。
ただし、ナレッジワークのミッションは「ナレッジテクノロジーであらゆる人の可能性を解放する」であり、テクノロジーの活用は私たちにとって手段ではなく目的の一部ですので、プロダクトの要件定義には「どのような技術を活用していくべきか？」というエンジニアリング視点が欠かせません。
よってBを選択しています。
●プロダクト要件定義における議論方法
上記のような要件定義のアプローチを成功させるために大事なことの1つ目は「議論の方法を決めておくこと」だと考えています。
僕たちは開発優先順位などを議論する時にはDecisionAnalysis（DA）と呼ばれる手法を用いています。
※Decision Analiyis（DA）の詳細
https://www.monodukuri.com/gihou/article/396
「選択肢と選択基準でマトリクスを組み、選択肢を議論する前に選択肢に優先順位をつけた上で合致する選択肢を選択する」という手法を使うことで議論のクオリティやスピードを担保するようにしています。
2つ目は「それぞれが異なる視点を理解するように努めること」。
エンジニアリングチームもマーケットを理解し、ビジネスチームもテクノロジーを理解しなければ良い議論が成立しません。
この手法はそこがなければ、無用なチーム間での対立を生むことにもなり兼ねません。
僕もまだまだテクノロジーに対する理解が足りない場面が多々あるので、日々勉強しながら濃い議論がエンジニアとできるように努めています。
そして3つ目は「最後は誰が決めるかを決めておくこと」。
最終的に何を作っていくかの判断は51:49のギリギリのところで決めることになります。最後は誰が決めるかを明確にしておき、みんなが意思決定者の決断に従う、決断を正解にする、というスタンスが醸成されていなければ、議論に時間ばかりがかかってしまい、スタートアップにとって最大の競争優位性である「スピード」を失うことになります。
ナレッジワークの場合は、要件定義の大枠はプロダクトオーナーである麻野が、詳細はプロダクトマネジャーである徐福が意思決定者であるとなっています。
議論の際は、フロントエンドエンジニアもバックエンドエンジニアもUIデザイナーも参加し、喧々諤々の議論をしますが、意思決定されると実装に向けて最速で動かしていくというスタイルです。
①議論の方法を決めておくこと ②それぞれが異なる視点を理解するように努めること ③最後は誰が決めるかを決めておくこと の3つを意識することで、議論に参加するメンバーが多様であったとしてもスムーズにプロダクトの要件定義に関する議論が進んでいると感じます。
プロダクトマネジメントを専門にされている方からすれば当たり前だったりするのかもしれませんが、少しでも参考にさせて頂ければと思い、ナレッジシェアさせて頂きました。
現在、ナレッジワークのプロダクトチームはPO（私）、Pdm、UIデザイナー1名、フロントエンドエンジニア1名、バックエンドエンジニア2名という体制ですが、僕たちと一緒にこんなプロダクトづくりのプロセスに参加してくれる創業メンバーを若干名募集中です！特にソフトウェアエンジニアの方を探しています。
ご興味をお持ち頂けましたら、カジュアルな情報交換から始めさせて頂ければ幸いです。
よろしくお願いします！
この記事が気に入ったらサポートをしてみませんか？