フジイユウジ (@fujii-yuji.mstdn.fujii-yuji.net.ap.brid.gy)

プロダクトマネージャーは「この世界をどう変えたいか」さえあればいい Tebiki で CTO をしています渋谷（@shibukk）です。自分は現在プロダクトマネージャーも兼務しているのですが、これまでのプロダクトマネジメントを振り返ると、たいてい同じパターンにハマっていました。まず四半期のはじめに、それっぽいロードマップを作るとします。ところが走り出してしばらくすると、想定とまったく違う状況や学びが次々に出てくる。軌道修正をしたほうがよいのに、「いったん約束したロードマップは守らないといけない」という考えに縛られる。その結果、「計画通りに進んだけれど、ユーザーの行動はあまり変わらなかった四半期」が生まれてしまう、そんな状況でした。これによって、一応は「計画通りです」と報告はできるようになります。しかし、顧客の利用状況を見ると何も変わっていない。プロダクトの数字だけに目を向けていれば自分をごまかせるが、現場の人と直接話すと否が応でも分かってしまうものです。こういう経験を本当に何度も何度も繰り返してきたのですが、その結果、ようやく分かってきたことがあります。それは、PRDを書くことでもなく、きれいなロードマップを引くことでもなく、チーム全員が信じてついてきてくれるような**「自分はこの世界をどう変えたいか」を創り、それを語り続ける。それこそがプロダクトマネージャーのやるべき仕事** だということです。この記事では、プロダクト開発においてなぜ行動変容が重要なのか、そしてそれを実現するためにエフェクチュエーション・ネガティブケイパビリティ・One-Way Door / Two-Way Door といった思考法をどう活かせばよいか、をこれまでの失敗をベースにまとめてみました。 #### 「行動変容」さえ決まっていれば、何度でもやり直せるプロダクトマネージャーの仕事を雑に分解すると、だいたい次の三つに分けられると思います。 1. どんな行動変容を起こしたいかを決める 2. その行動変容を起こせる仮説を考える 3. 仮説を検証しながら、打ち手をアップデートし続けるこのうち、2と3は何度でもやり直せます。むしろ短いサイクルで回し続けることが推奨されるものです。一方で、**1だけは、誰かがしっかりイメージしておく必要があります** 。ここが曖昧なままだと、どれだけ精密な計画を立てても、現場の行動はほとんど変わりません。では、この決めるべき「どんな行動変容を起こしたいか」とは何か。それは、**誰の・どんな行動を・どの方向に・どれくらい変えたいのか** を、現実のレベルで描いたものだと考えています。（これは市場に与える影響そのものになるので、大きければ大きいほどいいはず） Tebiki で言えば、例えばこんな感じです。 * 現場リーダーが毎回説明が違うOJTで育成するのをやめて、標準手順を定めて育成するようになる * 品質トラブルが起きたとき、誰のせいかではなくどの手順をどう変えるかが最初の会話になる * 新人にとって、仕事は先輩を見て盗むものではなく、いつでも見返せる教材から学ぶものと認識するようになるこういったユーザーの大きな行動変化を、プロダクトのゴールとして強くイメージすること。これこそがプロダクトマネージャーが手放してはいけないものです。起こしたい行動変容さえ決まっていれば、**極論そこに至る機能・優先順位・アサインは、何度変えてもいい** とさえ思っています。逆に、このイメージがないままロードマップだけ精密に引くと、個別のユースケースは満たしているが、全体としてはちぐはくしたプロダクトの出来上がりです。 #### セールスの要望を上から並べたロードマップ変えたい行動のイメージが弱いとき、ロードマップは簡単に別のものに変質してしまいます。よくあるパターンのひとつが、セールスの要望を上から並べたロードマップです。例えば四半期の計画を作るとき、まずセールスから「この商談で勝つにはこの機能が必要」「この大型案件はこの差分がないと厳しい」といった声が上がってきます。ひとつひとつはどれも筋がよく、金額も大きそうで、無視できない。そうした要望を拾っていくうちに、「××社向け」「××案件対応」といった項目が、いつの間にかロードマップの大半を占めていきます。ひとつひとつの要望はどれも正しく見えます。出来上がったときのビジネスインパクトもありそうだし、現場の困りごとも解決していそうに見える。でも、ふと全体を眺めると、こんな感覚になります。誰のどんな行動を変えようとしているのかをメンバーに説明できない。プロダクトのストーリーではなく、**案件の寄せ集め** にしか見えない。採用面談で「私たちがなぜ今この取り組みをしているのか」をうまく語れない。一番やっかいなのは、短期的には結果が出てしまうことです。いくつかの案件は本当に取れますし、セールスを通じて顧客の声を聞いて開発できているという安心感も生まれます。しかし、それはあくまでその場かぎりのクイックウィンでしかありません。プロダクトとしての長期的な価値は積み上がらず、市場を動かすような大きな成果には繋がらないのです。そしてさらに時間が経つと、別の大きなペインが噴出してきます。プロダクトが誰かの現場を変えるものというより、個別の要望集に近づいていく。開発チームが、自分たちの仕事をプロダクトづくりではなく、**ただのフィーチャーファクトリー** だと感じるようになる。変えたい行動がイメージできないので、何を捨てるかが決めづらくなり、じわじわと複雑さが増えていく。以前、まさにこの要望リストの消化を続けてしまったことがあります。「この機能があれば契約できる」「あの顧客要望は重要だ」といった声に応え続けることで、チームは常に忙しくデリバリーしていました。しかしあるとき、信頼していたエンジニアからこう言われました。 > 言われた機能は作りましたけど、これって結局、誰がどううれしくなってるんですか？私は言葉に詰まりました。個別の要望は満たしているはずなのに、チーム全体に漂うのは達成感ではなく、終わりのないタスク消化に対する疲弊感だけでした。まさに変えたい行動をイメージしないまま走ってしまっていたんです。これは今でも教訓になっていて、当時、自分の頭から抜け落ちていたのは、「この要望を聞くことで、自分が目指している行動変容に果たして近づいているのか？」という問いです。セールスの要望を聞くこと自体は、悪いことではありません。むしろ大事なインプットです。問題は**「ユーザーがどう変わるか」をイメージしないまま、そのままロードマップに積み上げてしまうこと** です。本来であれば、「この要望は、今目指しているゴールや世界観と同じ方向を向いているか？」「向いているなら、どのくらい汎用化すれば、より多くの現場で行動を変えられるか？」「向いていないなら、今回だけの対応にとどめるのか、それとも見送るのか？」といったことを、プロダクトマネージャーがフィルタリングする必要があります。そして、このフィルタリングの基準として必要なのが、先ほどの「行動変容」なんです。ここが曖昧なまま要望を積み上げると、ロードマップはあっという間に要望ランキングになってしまいます。逆に言えば、この**行動変容の「向き」さえ合っていれば、そこに至る手段はもっと柔軟でいい** はずなのです。 #### 行動変容の「向き」だけ決めるでは、行動変容のイメージを現実にするには、どう進めていけばいいのでしょうか。ここで効いてくるのが、エフェクチュエーションという考え方です。「こうなっていたい」という方向だけ決めておき、そこに至る具体的なルートは事前に固定せず、今ある手段から未来をつくっていく考え方です。よくある誤解は、行動変容まで完全に言語化できてからでないと動いてはいけないというものです。自分も以前は他者からの評価を気にするあまり、完璧なものを仕上げないといけないという思考に陥っていました。ですが、今は**「こういう方向に行動を変えたい」レベルまで決まっていれば、あとは今ある手札から始めていい** 、くらいでちょうどいいと感じています。 Tebiki でも、「現場リーダーの育成行動を変えたい」という方向性を持った状態で、ある顧客とは「動画撮影」から、別の顧客とは「紙マニュアルの置き換え」から、また別の顧客とは「評価シートの移行」から、といったように、手札（既存機能・顧客のステータス・導入部門）に応じて入り方を変えています。ここで大事なのは、**行動変容の「向き」は変えないが、そこに至る「ルート」はどんどん変えていい** と自分に言い聞かせることです。そうすると、ロードマップは未来を当てるための地図ではなく、手札と学びに応じて組み替える前提の仮説の集まりに変わっていきます。セールスの要望も、行動変容の「向き」に沿っているなら積極的に取り込み、そうでないなら「今回はやらない」「局所的な対応にとどめる」という判断がしやすくなります。 #### 「今は決めない」ことを決める行動変容のイメージは、最初からクリアに見えていることはほとんどありません。そんなときに必要になるのがネガティブケイパビリティ、ざっくり言うと「不確実性を受容する能力」です。プロダクトマネージャーにありがちな誤解として、誰も分からないことを、いち早く白黒結論づけるのが仕事というものがあります。もちろん、早く決めた方がいいこともたくさんあります。一方で、まだ決めない方がいいことも同じくらい多いです。たとえば、どの行動変容が一番インパクトが大きいのか、どのセグメントから攻めるのがよいのかといった問いは、会議室のホワイトボードや AI との会話だけではなかなか決まりません。現場に入り、ユーザーと話しながら、仮説をぶつけては打ち返してもらう中で、少しずつ輪郭が見えてくるものです。このとき必要なのは、「ここはまだ仮説レベルです」と正直に共有することと、**「今は決めない」とあえて判断すること** 、そして「白黒ついていない状態」をチームで受容することです。ロードマップを作る場面でも、全部をきっちり埋めるのではなく、ここは変えたい行動に直結するコアとなるので考え抜こうだとか、ここは学びに応じて変わる部分なので余白として残す、といった切り分けをしやすくなります。ネガティブケイパビリティがあれば、ロードマップはすべてが確定事項のスケジュール表ではなく、確定したいところとあえて曖昧にしておくところが共存したドキュメントになってくるはずです。 #### 不可逆な行動変容だけ慎重に決めるどの意思決定が「行動変容に対して取り返しがつかないか」を見極めるために使えるのが、One-Way Door / Two-Way Door です。これは一度決めても簡単に戻せる意思決定は Two-Way Door で、間違えるとコストが大きく、戻すのが難しいものは One-Way Door という考え方です。ここでのよくある勘違いは、影響範囲が大きい＝ One-Way Door と捉えてしまうことです。ですが、プロダクトマネージャーの仕事では、**目指す行動変容に対して、どれくらい不可逆か** という観点で見る方がしっくりきます。例えば、UI の配置や文言変更、小さな実験的機能の ON / OFF は、ユーザー数が多かったり利用頻度が高くても Two-Way Door にできます。反応を見て、ダメなら戻せばいいからです。一方で、料金体系の大きな変更や、ターゲットとする業界のシフト、プロダクトラインの分割・統合のようなものは、一度やると戻すこと自体がユーザーの行動を大きく揺らします。こういうものは、変えたい行動に対して不可逆な影響を与えがちなので、One-Way Door な意思決定として慎重に扱った方がいいです。この視点を持つと、**ほとんどの施策や仕様は Two-Way Door として軽く試せる** し、ごく少数の「変えたい行動に対して不可逆な選択」だけを One-Way Door として扱い、時間をかけて決めるというメリハリがつけやすくなります。そして、ここでも主語はあくまで「行動変容」です。「この意思決定を誤ったとき、狙いの変えたい行動からどれくらい遠ざかるか？」「この意思決定を通すことで、ユーザーの行動に対してどれくらい強いコミットになるか？」という問いを自分に投げると、One-Way Door と Two-Way Door の判定がクリアになるはずです。 #### 最後にもしこの記事を読み終わったあと、少しだけ時間があれば問いかけてみてください。 > このプロダクトで、誰のどんな行動を、どう変えたいのかを 10 秒で語れますか？ロードマップが多少ガタガタだったとしても、この問いにだけはきちんと答えられれば良く、この問いに答えられない限りは、どれだけ精密なロードマップを持っていても、それはあってもなくてもいいプロダクトです。 #### 私たちは仲間を募集しています！というわけでいつものやつを。この記事にある行動変容について、Tebiki はどう考えているか聞いてみたい方、ぜひカジュアル面談お願いします！ herp.careers https://techblog.tebiki.co.jp/2025/11/20/163215