この記事は株式会社ビットキー Advent Calendar 2024 6日目の記事です。
Product Managementチーム所属の古川（@kzfrkw）が担当します。
要約
書籍「TRANSFORMED」の内容から一部抜粋し、私個人や組織としてできていないな、耳が痛いなという部分をピックアップして、現状の振り返りや今後の改善への思いをまとめた記事です。
書籍「TRANSFORMED」とは
プロダクトマネジメントの世界においてバイブルとされる「INSPIRED」の著者であるマーティ・ケーガン氏による新作です。
以下、一部抜粋したAmazonの紹介文（ https://amzn.asia/d/cVYJ5VS ）です。
シリコンバレーが世界を席巻する理由は、「プロダクトモデル」で運営されていることにある。
顧客に愛され、ビジネスにも有効なテクノロジーパワードなソリューションを継続的に生み出す方法だ。
その方法がDXの本質である。起こすべき変化は以下の3つだ。
作り方を変える
問題解決の方法を変える
解くべき問題の決定方法を変える
これらを支えるのが、プロダクトマネジャーに代表される「プロダクトモデル・コンピテンシー」と、プロダクトチームの指針となる第一級原則群の「プロダクトモデル・コンセプト」である。
肩書の変更や人材の寄せ集め、アウトソーシングでは決してたどり着けない、トランスフォーメーションを成功させる要因が凝縮されている。
さらに、著者の長年にわたる企業支援の実績に基づき、トランスフォーメーションを進める上での重要なトピックや、想定される反対意見への対処法まで詳しく解説している。
具体的な会社の変革事例などを交えながら、プロダクトモデルという概念の紹介と、強いプロダクトを持った企業へと変革するために必要な要素や施策などを詳しく紹介している本です。
書籍の感想と本記事について
INSPIREDもそうですが、プロダクトマネジメントはかくあるべしという明確な方向性を示してくれる一方で、求めるレベルが高く、私個人や弊社ができていないことばかりで、読みながら終始打ちのめされていました。
この記事では特に私個人や組織としてできていないなと思ったことをピックアップし、現状を振り返り未来についての思考などを述べていきます。
1. 顧客との直接的かつ頻繁なインタラクション
実際のユーザーや顧客に直接アクセスできなければ、プロダクトチームはいかなる成功もほとんど望めない。
ユーザーや顧客は、未解決の問題に対するインスピレーションを与えてくれるだけでなく、提案したソリューションを迅速にテストする手段にもなる。
プロダクトマネージャーやデザイナーがユーザーや顧客に直接アクセスする必要がある理由は直感的にも明らかだろうが、エンジニアがユーザーに直接アクセスすることの重要性はあまり直感的ではないかもしれない。
しかし、エンジニアが自分達のプロダクトで苦労しているユーザーを見た時に「魔法」が起きるのだ。
まず、プロダクトマネージャーである私個人もつい最近まで直接お客様に会いに行く機会をほとんど作れていませんでした。
私自身、プロダクトマネージャーというロールで本格的に仕事をするようになったのがここ１年ほどでしたし、エンジニア出身という経歴も相まってプロダクトのデリバリーの方に注力しがちでした。
今の組織の基本的な仕事の進め方は、お客様の声をビジネス側のメンバーがヒアリングし、その内容を間接的に聞く形がほとんどであり、直接お客様と相対する機会がない状態でした。
プロダクトマネージャーという仕事を考えたときに、上司含めこの状況に課題を感じていたこともあり、直近は少しずつお客様と直接会話をする機会を増やしています。
とはいえ、書籍ではプロダクトのメンバーだけで会いに行けるような関係性の顧客を見つけ出し、デザイナーやエンジニアとともに直接的かつ頻繁にアクセスすることを推奨しており、その状態にはまだまだ遠いなという印象です。
組織としてより直接的に頻度高くお客様に会いに行ける動きを加速するため、比較的関係性の築けているお客様からアプローチをしていくなど、施策を打っていこうと思います。
2. 課題やアウトカムに焦点を当てたロードマップ
有効なトランスフォーメーション戦術がある、「アウトカムベースのロードマップ」だ。
世の中のほとんどのプロダクトロードマップはアウトプットのリストに過ぎない。
そのロードマップはとくべき問題のリストではなく、構築すべき機能のリストになってしまっているのだ。
そのロードマップの各項目を通して、各機能が解決したい問題は何か、成功の指標は何かを特定する。
プロダクトチームが潜在的なソリューションを探索する際に、ある程度の自由度が与えられることになる。
もう一つのメリットはステークホルダーが機能や期日の話題から離れ、解くべき問題やアウトカムについて話し合うようになることである。
この観点はテクニックという側面が強いと思いますが、我々も多分に漏れず、ありがちな機能ベースのロードマップを使ってきました。
プロダクトマネージャーが責任を持つべき指標はアウトプット（何の機能を作ったか）ではなくアウトカム（それによって顧客にどんな変化があったか）ですが、私個人はこれまでアウトカムに責任を持ちその達成に注力してきたとは言えない状況だと思っています。
そもそも何かの機能を開発するときにそれによってもたらされるアウトカムの定義すらないことが多くありました。
私個人のプロダクトマネージャーとしての成長や組織としてより課題解決にフォーカスしたプロダクト作りのためにも、書籍で述べられたアウトカムベースのロードマップは非常に効果的なのではと思っています。
すでにある機能のロードマップも、その先に何を解決したいのか、そこに思いを馳せるところからまずは始めていこうと思います。
3. プロトタイプを用いた価値検証
さまざまなアイデアを実際に作ってしまって何がうまくいくかを調べることも可能ではあるが、それでは非常に時間がかかってしまうし、たくさんの悪いアイデアを顧客に晒してしまうことになる。その代わりに、プロダクトチームはアイデアやアプローチを素早くテストするためのテクニックやツールをフル活用する。
多くの場合、プロダクトチームはプロトタイプを作成する。プロトタイプにはさまざまな形があるが、どれも非常に素早く低コストで作成できる。
お客様と会えていない話とも繋がってきますが、少なくとも私個人はこれまでプロトタイプのようなものを作ってお客様の反応からプロダクトの価値を検証するということをほとんど経験してきませんでした。
ビジネス側からお客様に開発予定の製品アイデアを紹介する場はこれまでもあったと思いますが、その場に私はいませんし、その紹介の仕方も基本的に動くものではなくせいぜいデザインのラフスケッチ程度のものだったと思います。
上記のような場に私も同席することで、お客様がどんな反応をするのか、ビジネス側から聞くだけでは得られない一次情報を感じ取ることができるはずです。
また、動くものが見せらればより多くのインサイトが得られることが期待されるので、書籍でも紹介されているプロトタイプ制作のテクニックなども積極的に利用していきたいです。
4. 少なくとも２週に１回以上のリリース
問題の解決に何週間も何ヶ月も待つことは、今やほとんどの企業にとって許されない。強いプロダクト企業には差し迫った顧客や市場ニーズに迅速かつ適切に対応する能力が必要だ。
そういったニーズに対応するために利用される基本原則は、小さく、頻繁な、独立したリリースのデプロイである。
まずこれは、各プロダクトチームが最低でも２週間に１回は新しいものをリリースするということだ。
ここは特別耳が痛かった箇所でした。。
我々のプロダクトの中にはリリースサイクルが１ヶ月のものもあり、背景として自動テストの不足により人力での品質担保に多くのリソースを割いていること、各機能同士が密に影響しあっており機能改修のたびに影響範囲が大きく調査も大変なことなど複数の要因があります。
このままでは顧客のニーズや市場の変化に追従していけなくなるリスクが非常に大きく、組織として解決していくべき重要課題だと認識しており、私もプロダクトマネージャーとしてこの課題にどう取り組んでいくかを考え続けていく必要があると思っています。
デグレを防ぎながら継続的に改修を行い、小さく頻繁にリリースできる体制を整えていくことは長く困難な道ではあると思います。しかし、今後のプロダクト成長・組織成長には欠かせない課題として、組織的に取り組んでいきます。
まとめ
今回ピックアップしたのはこの書籍から得られる学びの本の一部分です。具体的なテクニック含めたもっと多くの学びが得られる本ですので、強いプロダクト企業へ変革していきたいという思いのある方にとてもおすすめです。
私自身、読むだけで終わらせず実践していくという決意をここで表明して、本記事を締めたいと思います。
記事最後の例文
明日の7日目の株式会社ビットキー Advent Calendar 2024は、CSBチームの@_otakakot_が担当します。