製品を動かすのは機能ではなく翻訳だ: デザインと利害関係者調整の本当の仕事

Hatched by tttt

Apr 26, 2026

1 min read

5 views

84%

いちばん難しい仕事は、ものを作ることではない

優れたプロダクトマネージャーの仕事は、アイデアを出すことでも、仕様を書き切ることでも、会議を回すことでもありません。もっと厄介で、もっと価値がある仕事があります。それは、互いに違う言葉を話す人たちのあいだで、同じ現実を見えるようにすることです。

デザイナーは「ユーザーが何を求めているか」を見ようとし、財務はコストと収益の整合を見ようとし、法務はリスクを見ようとし、営業は市場での約束を見ようとし、経営は成長と優先順位を見ようとします。どれも正しい。しかし、正しさが並立したままでは、製品は前に進みません。必要なのは、正しさの衝突を解く翻訳です。

ここでいう翻訳とは、ただ情報を言い換えることではありません。各部門が本当に気にしている制約と目的を理解し、それらを一つの製品物語に編み直すことです。つまり、プロダクトマネジメントの中心には、実は「制作」よりも先に「統合」があるのです。

プロダクトを遅らせるのは、意思決定が少ないことではない。意味が揃っていないことだ。

デザインと利害関係者調整は、別の仕事ではなく同じ仕事の両面である

表面的には、デザイナーとの協働と外部ステークホルダーとの調整は別物に見えます。前者はユーザー体験、後者は組織運営。前者は創造、後者は政治。ところが実際には、この二つは同じ根っこを持っています。それは、抽象的な意図を、誰もが納得できる形に落とすことです。

デザインチームとの仕事では、プロダクトマネージャーは「何を作るか」だけでなく、「なぜそれがユーザーにとって意味があるのか」を共有しなければなりません。単に「見た目を良くする」話ではなく、ユーザーが何を求め、どの接点で迷い、どの感情で離脱するのかを一緒に解像度高く捉える必要があります。良いデザインとは装飾ではなく、ユーザーの行動を成立させる環境設計だからです。

一方で、財務、法務、営業、マーケティング、経営との調整では、同じ製品を別の視点から見直します。ここでは、美しさよりも、収益性、規制適合、販売可能性、戦略適合が問われます。重要なのは、これらを「邪魔な制約」と見なさないことです。むしろ、これらの制約は、アイデアを現実に耐えうる形へ鍛えるための設計条件です。

この視点で見ると、デザイナーとの会話と他部門との会話は本質的に同じです。どちらも、単なる要求伝達ではなく、制約の違う人々を同じ目的に向けて整列させる作業です。違うのは相手の専門性ではなく、見ている失敗の種類です。デザイナーは「使われない失敗」を恐れ、財務は「成立しない失敗」を恐れ、法務は「守れない失敗」を恐れます。プロダクトマネージャーは、その全部を同時に扱わなければなりません。

ここで重要なのは、優れたプロダクトマネージャーほど、実は個人貢献者としての能力を持っているという点です。調査し、仮説を立て、情報を構造化し、各専門家にとって意味のある形にして渡す。これができる人は、単に会議を取り仕切る人ではなく、組織の認知を整える人です。

ビジネスモデル、OKR、チーム憲章は、単なるフレームワークではない

外部ステークホルダーとの調整で登場するビジネスモデルキャンバス、OKR、アジャイルチーム憲章、製品パイプラインは、実務ではしばしば「便利なテンプレート」として扱われます。しかし本質はそこではありません。これらは、異なる人々が同じ問いに答えられるようにする共有言語です。

たとえばビジネスモデルキャンバスは、単に事業の部品を埋める表ではありません。価値提案、顧客セグメント、収益構造、コスト構造のあいだにどんな緊張があるかを可視化する装置です。デザインの議論が「どう使いやすくするか」に閉じるとき、このキャンバスは「その体験は持続可能か」という問いを持ち込みます。

OKRは、目標管理のためのチェックリストではありません。各チームが何に集中し、何を犠牲にするのかを明示する、優先順位の契約です。あるチームが「新しいアクティブユーザーを50,000人増やす」と掲げるとき、それは単なる数字ではなく、組織に対して「今期は何を勝ち筋と見なすか」を宣言しているのです。OKRが機能するのは、成果指標を通じて会話の焦点を揃えるからです。

アジャイルチーム憲章も同じです。これは単なる運営文書ではなく、チームが自分たちの役割をどう理解しているかを外部に伝える自己定義の文書です。何をするチームなのか、どこまで責任を持つのか、どのように意思決定するのか。これが明確でないと、デザインは手戻りし、他部門は期待値を誤り、優先順位は毎週変わってしまいます。

フレームワークの価値は、答えを与えることではない。会話の型を与えることだ。

だからこそ、これらのツールは単独で完結しません。むしろ、製品組織のさまざまな専門性を一枚の地図に重ねるために使います。デザインがユーザーの行動を可視化し、ビジネスモデルが経済性を可視化し、OKRが成果を可視化し、チーム憲章が責任範囲を可視化する。この四つが揃って初めて、組織は「何を作るか」ではなく「なぜそれを今やるのか」を本気で議論できます。

優れたPMは、製品を管理するのではなく、認知の摩擦を減らす

多くの人は、プロダクトマネジメントを意思決定の職能だと考えます。もちろんそれは正しいのですが、十分ではありません。より本質的には、PMの仕事は認知の摩擦を減らすことです。認知の摩擦とは、チームや部門ごとに見ている世界が違いすぎて、同じ事実から違う結論が出てしまう状態を指します。

この摩擦は、しばしば「コミュニケーション不足」と呼ばれます。しかし、問題は単に話していないことではありません。もっと深いところで、各人が使っている評価軸が違うのです。デザイナーは流れの自然さを見る。営業は説明しやすさを見る。法務は予見可能なリスクを見る。財務は再現可能な単位経済を見る。経営は戦略的なレバレッジを見る。

PMは、これらの軸を消すことはできませんし、消すべきでもありません。必要なのは、それぞれの軸がどこで衝突し、どこで補完し合うかを見極めることです。たとえば新機能の導入が、ユーザー体験を良くし、営業トークを強め、収益も伸ばす一方で、法務レビューを増やし、実装コストを上げることがあります。そのときPMは、単純な賛否ではなく、どの摩擦なら支払う価値があるかを判断しなければなりません。

ここで役立つのが、私はこれを「三層変換」と呼びたい考え方です。

意味の変換: ユーザーの不満やビジネス要求を、製品の課題に言い換える。
制約の変換: 製品課題を、各部門が理解できる制約とリスクに分解する。
判断の変換: 制約を、優先順位と行動に落とし込む。

この三層が回り始めると、デザイナーへの依頼は「これをきれいにしてください」ではなく、「この離脱を減らしたい。理由はこれで、制約はこれです」に変わります。法務への相談は「あとでレビューお願いします」ではなく、「この体験上のこの部分が論点で、ここは譲れない、ここは調整可能です」に変わります。営業との会話も「売りやすいですか」ではなく、「誰に、どの価値で、どの条件なら売りやすいか」に変わります。

こうした変換ができると、組織は驚くほど速くなります。なぜなら、速さを妨げているのは作業量ではなく、解釈のズレだからです。

実例で考える: ひとつの機能が三つの言語でどう見えるか

たとえば、あるSaaSが新しいオンボーディング機能を作るとします。ユーザーにとっては、初回設定がわかりにくく、途中で離脱している。デザインの視点では、情報の順序、入力負荷、安心感の演出が論点になります。

財務の視点では、機能の開発コストと、改善によって増える転換率の関係が論点になります。法務の視点では、データ収集の同意や説明責任が論点になるかもしれません。営業の視点では、見込み客に見せたときの説得力が論点です。経営の視点では、それが今期の成長指標にどれだけ効くかが論点になります。

ここで失敗する組織は、各部門を順番に説得しようとします。しかし、優れたPMは順番ではなく構造で考えます。まず、ユーザーの失敗を定義する。次に、その失敗を減らす案を複数出す。さらに、その案を各部門の言葉に翻訳する。そして最後に、どの案が最も多くの制約を同時に満たすかを見る。

このとき、デザインは「見た目の改善」ではなく、「行動を成立させるための認知設計」になります。ステークホルダー調整は「承認取り」ではなく、「現実に耐える条件設定」になります。両者がつながると、製品は単に作られるのではなく、組織全体の理解に支えられて成立するようになります。

Key Takeaways

翻訳はPMの中核業務である。単に情報を伝えるのではなく、異なる部門の目的と制約を同じ文脈に乗せる。
デザイン協働とステークホルダー調整は分離できない。どちらも、抽象的な意図を具体的な行動に変える作業である。
フレームワークの価値は答えではなく会話の型にある。ビジネスモデルキャンバス、OKR、チーム憲章は、認識を揃えるための道具として使う。
速さを阻むのは作業量より意味のズレである。認知の摩擦を減らすと、意思決定と実行の速度は自然に上がる。
良いPMは制約を嫌わない。制約を、より強い製品に鍛える設計条件として扱う。

結論: 製品は機能の集合ではなく、合意のアーキテクチャである

私たちはつい、優れたプロダクトを「どんな機能があるか」で語ってしまいます。しかし本当に強いプロダクトは、機能の多さではなく、組織の合意がどれだけ精密に設計されているかで決まります。ユーザーにとっての価値、デザイナーにとっての意味、財務にとっての成立性、法務にとっての安全性、営業にとっての説明可能性。これらが一つの構造として噛み合ったとき、製品は初めて持続します。

だから、次に誰かとの調整が面倒に感じたら、それを「雑務」と呼ぶのではなく、製品づくりの中心にある仕事だと見直してみてください。調整とは、遅延の原因ではありません。製品が現実世界に着地するための最後の設計です。

最終的に、優れたプロダクトマネジメントとは、何かを決めること以上に、何が同じ問題なのかを人々に理解してもらうことです。機能を作るのではなく、意味を揃える。その瞬間に、チームは単なる協業体ではなく、ひとつの知性になります。