ビルドトラップを防ぐ7つの対処方法
ではこれらの兆候が現れたとき、どのようにして改善していけばよいのか。その対処方法として次の7つのポイントが紹介された。
（1）適切なプロダクトマネージャーを据える
プロダクトマネージャーは『Why（なぜ）』に責任を持つ役割だ。「なぜこれを作るのか、どうやって顧客に価値を届けるのか、ビジネス目標を達成する上でどう役に立つのかなどの問いに答えられなければなりません。しかも会社のビジョンや目標、ビジネス、マーケットを理解した上で、語れることが重要になります」と吉羽氏はプロダクトマネージャーのロールを説明。そのほか、ユーザーの理解や、技術者と会話できる程度の知識など、必要なスキルは多岐にわたる。
（2）適切なチーム構成にする
受託開発の現場では機能ごとに組織が分かれることが多いが、プロダクト開発では問題発見からデリバリーまでの一連の流れをスムーズにすることが重要になるため、組織を細かく分けるのは得策ではない。「クロスファンクショナルチームにして、チーム外の作業に依存することなしに届けられるようにすることが重要です」（吉羽氏）
（3）適切な戦略を組織に行き渡らせる
「多くの企業が戦略と計画をごちゃ混ぜにしている」と吉羽氏は指摘する。例えば「今期に○○を作る」ことは本来計画だが、戦略にしている組織も多いという。このように計画を戦略にしてしまうと、ビルドトラップとなり、いらない機能をたくさん作ることにもつながってしまう。戦略は組織のレイヤーに合わせて、ビジョン、戦略的意図、プロダクトイニシアティブ、オプションというようにブレークダウンして行き渡らせることが重要になるという。
「細かい計画はそれを担当するチームが知っていればよく、マネジメント層は知っていなくてもよいです。マネジメント層にとって重要なのは、企業のビジョンをいかに達成するかで、機能をどう届けるかではないからです」（吉羽氏）
では戦略をどうプロダクト開発に浸透させていけば良いのか。書籍『プロダクトマネジメント』では、それを「プロダクトのカタ」という言葉で表している。プロダクトのカタとは「方向性の理解」→「現状の分析」→「次の目標を設定」→「ステップの選択」→最初の「方向性の理解」に戻るサイクルを繰り返していくことである。「すぐに機能の話をするのではなく、ビジョンや戦略を踏まえて作るものを決めていくことが大事になります」（吉羽氏）
（4）ソリューションの前に問題を理解する
「人間はソリューションを考える方が得意。問題そのものを考えるよりも、こういう問題があったとするとどう解くかという思考になりがちです」と吉羽氏は指摘する。だが、適切な問題を解決しないと価値は出ない。思い込みでソリューションを作る前に、「本当に解決すべき問題は何なのかしっかり考えること」と吉羽氏は言う。「問題を解決するのに20日かけられるのなら、19日は問題の定義に使いたい」とアインシュタインも言っているように、問題を理解することは非常に重要なことなのである。
（5）ソリューションを探索する
プロダクト開発は「やってみないとわからないことが多いので、実験することが重要」と吉羽氏。実験は長期間、大きな投資で行うのではなく、この仮説が正しいかどうかを証明するために、なるべく素早く行うべきだという。もう一つ重要なことは、「実験で作ったものは捨てること」と吉羽氏は言う。実験で作ったものの多くは品質を満たしておらず、それを使うとかえって遠回りになることが多いからだ。
実験方法としてはコンシェルジュ（顧客に代わって手作業でやってみる）、オズの魔法使い（裏側に人がいる）、コンセプトテスト（コンセプトをデモしたり、ランティングページを用意したりする）などがあると示した。
また例として米国の大手オンライン靴店「Zappos.com」のケースを紹介。同社の創業者はサービスを立ち上げる際、オンラインで本当に靴が売れるのか疑問を持っていたという。それを確かめるためにWordPressを使ってWebサイトを作成し、注文が入れば自ら買いに行き、宅配業者に持ち込んで発送していたという。この実験により、このソリューションはうまくいくと考え、サービスを立ち上げた。Zapposだけではない。Dropboxも投資家から資金を集める際、実際にプロダクトを作るのではなく、プロダクトの動きがわかるコンセプト動画だけを作って見せたという。
（6）適切な指標を定めて活用する
リリース自体がゴールになっているケースの中でも最悪な例は、リリースした後、プロダクトの数字を何も見ないこと。数字を見るといってもユーザー数やPVでは意味がない。もちろん完成した機能の数やスクラムのストーリーポイントも同様に意味がない。「コンテキストがわかる数字を集めていくこと」が重要になるという。フレームワークはいろいろあるが、海賊指標（AARRR）やHEARTフレームワークなどを見ていくこと。
「もちろんプロダクトごとに見ると良い指標は異なるので、それはステークホルダーを含めたチームで話すこと。そして目指す方向を示すNorth Star Metric（ノーススターメトリック）を決めることです」（吉羽氏）
そして計測ツールを用意しておくことも忘れてはならない。「計測した結果、使われていない機能などがあれば、捨てていくことです」（吉羽氏）
（7）組織をプロダクト主導にする
「これが一番難しい」と吉羽氏は言う。組織をプロダクト主導にするためには、顧客中心を体現することが必要になる。「プロダクトの成功は実験と学習が基になる。実験が究極のリスクマネジメントなので、安全に学習できる環境を作ることです」と吉羽氏。古い予算制度から脱却することはもちろん、報酬やインセンティブ制度なども変えていく必要がある。
とはいえ、これを現場から変えていくのは難しいし、時間がかかる。まずは顧客中心を徹底していくことから始めるのが得策と言えるのかもしれない。
このようにビルドトラップを回避するためにできることはたくさんある。吉羽氏は最後に、「今日伝えた内容は書籍『プロダクトマネジメント』の中にも書いてあるので、興味がある人はぜひ読んでほしい」と参加者に呼びかけ、セッションを終了した。
ProductZine読者向けウェビナーのお知らせ（第7回：2021年2月24日開催）
毎月開催しているProductZineの読者向けウェビナーですが、2月開催分は本対談でお話しいただいたエムスリー山崎聡さんにご登壇いただきます。
テーマは「プロダクトマネージャー育成」と「チーム作り」。事前登録制で参加無料です。ぜひ併せてご参考ください！
- 詳細・参加申し込み⇒ https://codezine.jp/application/15/
