マルチプロダクト運用における機能の重複に悩む方へ　開発の迷いを消した「やらないこと」の言語化 [2/2]

プロダクトの価値の言語化に挑むが、議論が進まない状況に

こうして無事に可視化を終えた我々は、（次に）やらないことの議論に入れたら良かったのですが、やらないことの議論は、実は初めからステップとして設計していたわけではなく、その前に実施したことがありました。

今振り返ると失敗とも言えるかもしれないんですけれども、言語化していく際の切り口については、1回方向転換がありました。もともと決めていたのではなく、初めは別の方法でまとめようとしていたので、ステップ1.5と位置付けて、そのあたりの話をしたいと思います。

初めは「私たちはユーザーにどんな価値を提供しているのか」という観点でまとめようとしておりました。（スライドを示して）こんな感じで、あるグループに対してプロダクトごとの価値を言語化する、価値のスタンスを言語化するみたいなところを目指しておりました。しかし、議論がなかなか進まない状況になりました。

というのも、まず価値を言語化しようとしても、正直無限に出てきてしまうということがありました。Yappliはノーコード製品なので、冒頭に説明したように、アプリの使い方とか目的が、本当にクライアントによって大きく異なるんですね。なので、1つの価値の機能が多岐にわたりすぎて、収拾がつかなかったっていうところがございます。

また、無限に出てきてしまうが故に、無理矢理まとめようとすると、「プッシュ通知の価値はエンドユーザーに何か届ける」みたいなかたちで、ちょっとふんわりしたものにとどまってしまうようなことになりました。

このままだとYappliとYappli CRMにおける差異が明確にできないとなり、やることにフォーカスしても収拾がつかないという結論に至りまして。思い切って議論の方向性を転換していくことをいたしました。

議論で自然とやらないべきこと・やるべきことみたいなところの話が少しずつあがっていったとこに着目して、その方向性で再構築できないかなと整理を進めることにしました。

「この機能でやるべきではないことは何か」という問いに切り替え

というところで、ステップ1.5の失敗を経て、やらないことを議論することに至りました。

そのステップ2ですが、「この機能でやるべきではないことは何か」という問いに切り替えたことで、議論が劇的に進んだかなと思っています。

ここがプロダクトの意義を問い直すことにつながって、「そもそもなんでこの機能を作ったんだっけ」という原点に立ち返ることができたところが1つあるかなと思います。価値ではなく、やらないことから考えることで、それぞれの本音に近づいたというか、シャープな意見が飛び交うようになったんじゃないかなと考えています。

そして「ここにあったら主機能との相性が悪いよね」とか「こっちをむしろやりたいよね」みたいなプロダクト開発チームの強い意思が言語化されてきて、将来が見えるように、想像できるようになってきました。

やらないことには意思がある

この議論を通じて自分は、やらないことには意思があるんじゃないかなと思っています。メンバーの中でぼんやりと蓄積されてた意思を「やらないこと」っていうフィルターを通じて、引き出すことができたのではないかと今思い返しております。

このようにやらないことの切り口でそれぞれの機能を言語化していき、それらをまとめてプロダクトのらしさを言語化することができました。結果、Yappliはアプリ内の体験にフォーカスして、顧客データの管理とか分析・セグメント管理みたいなところはYappli CRMにやってもらう。一方でYappli CRMのほうは、施策の実行や分析にフォーカスするので、アプリ内UIとか体験そのものの設計はYappliにやってもらおうと決めることができました。

プロダクト責務の指針を設定したことで得られた成果

というかたちで、失敗も含めてコンパス設計のプロセスについてお話しいたしました。ここからは、Yappli Value Compassがもたらした成果についてお伝えしていきます。

策定したやらないことリストは、すぐに具体的なユースケースの設計図として活用できました。例えば「会員の購入履歴を元にランク分けして出し分けしたい」という要件があった場合、Yappli CRMでセグメント生成して、Yappliで受け取ってUIに表示するというような明確な役割分担が設計できるようになりました。以前迷っていたユースケースについても、責務を分割して割り振ることができるようになりました。

設計した指針について現場に浸透させるべく、プロダクトマネージャー起点でエンジニア組織の開発部全体に説明会でYappli Value Compassのリード・内容を発信するっていうところを行いました。

その結果のアンケートですが、5段階の平均で「共感しますか」が4.2ポイント、「活用」が3.9っていうような評価になっていました。前者のほうが高めに出ているんですが、プロダクト間の役割分担を明確にすることの重要性についてはかなり共感の声が多く、「住み分けが明確になって良かった」とか、「役割が明確のほうが効率が良くていいね」っていうような声を聞くことができました。

活用できそうかっていう点が、少しポイントが下がりました。「設計時に相談できる体制が欲しい」といった意見があったので、そちらについてはチームメンバーで随時フォローしているところになってます。

また、実際に指針を使い始めた結果、大半のケースで迷いが消えて、やらないことを意識して「Value Compass」に即した解決策を考えられるようになったかなと思ってます。

残っている課題と今後の見通し

一方でまだ課題もありまして、特にマルチプロダクトとして連携する部分のユーザビリティとか、開発スピードを優先した結果、ルールを守らない、トレードオフの意思決定をすることも実は正直ちょっとあります。

ですが、指針がない中でむやみに意思決定をすることは避けられるようになったので、自分的には大きな進歩だったのではないかなと思っております。

今後はこの「Value Compass」をさらに洗練させて、中長期ロードマップに落とし込んでいきたいなと思っております。2025年にやったことをホットに話しているので、まだ着手中なところもあるんですが、これからも方針の見直しなどを含め、継続的に議論していきたいなと考えております。

本日のまとめになります。私たちはマルチプロダクト戦略において、開発の迷いを減らすため、Yappli Value Compassというプロダクト責務の指針を作成いたしました。

進め方の最大のポイントは、当初のやることを決めるというアプローチから、やらないことを通じて、プロダクトのらしさを言語化するというアプローチに方向を転換した点になります。

その結果、現場の迷いが消え、誰もが開発しやすくなるためのルールを整えることができました。

やらないことの議論にぜひチャレンジを

最後に、実はこの取り組み自体、「pmconf 2024」の公募セッションの発表を聞いたり、現地に参加させていただいたりして、自分もやってみたいなと思って着手したものになります。

自分はそれまで現場の機能デリバリーみたいなところにかなり注力してしまっていて、不確実性の高い議論はなかなかチャレンジできなかったっていうのがありました。

ですが、2024年の参加を通じて、世の中の多くの現場がこういった課題に真正面から取り組んでいるんだなというところに気づいて、現場から立ち上げて議論に挑戦したようなかたちになっています。

なので、もし本日の自分の登壇が、誰かの背中を押すものになったらすごくうれしいですし、自分の経験が参考になったら、ぜひやらないことの議論にチャレンジしていただけると、とてもうれしいなと思います。

では自分の発表は以上になります。ご清聴ありがとうございました。