TERASSのPdMチームで「Key Actions」を作った話｜再現可能な仕組み化への挑戦
はじめに
「PdMって、孤独じゃないですか？」
PdM同士で話していると、よく出てくる話題です。担当領域が違えば文脈も違う。判断の根拠は自分の中にある。誰かと一緒に動いているようで、実は一人で抱えていることが多い——そういう構造がPdMという仕事にはあります。
TERASSのPdMチームでも、この課題と向き合った時期がありました。その結果として生まれたのが、PdMチーム独自のKey Actions の策定です。孤立を防ぎ、チームとして成果を出すために、「自分たちはどう動くか」を言語化しました。
このKey Actionsが生まれた合宿の様子は、こちらのnoteにまとまっています。チームがどんな議論をしたのか、ぜひ読んでみてください。
今日は、そのKey Actionsの概要と、私が担当している「Outcome Driven」というActionについて、具体的にどう仕組みに落とし込もうとしているかをお伝えします。
TERASSのPdMに興味がある方、あるいはチームでのPdMのあり方を考えている方に、少しでも参考になれば嬉しいです。
TERASSのPdMチームでKey Actionsを作った理由
TERASSのPdMチームには現在、4つのKey Actionsが定められています。
Seek Insights on Facts 〜本質を探り、事実に基づいて動く〜
Outcome Driven 〜成果から逆算して動く〜
Be Brave 〜失敗を恐れるな、失敗で終わるな〜
Respect & Collaborate 〜互いを尊重し、共に挑む〜
なぜこれを作ったのか。出発点は、「PdMは孤独になりやすい」 という問題意識でした。
PdMという職種は、担当プロダクトや領域が異なると、それぞれが個別の文脈の中で動き続けることになります。PdMが成果を出すまでのプロセスにおいて、何をすれば正解なのか、その手段や判断の根拠が成果物として共有されにくい。TERASSのPdMチームも、以前はまさにそういう状態でした。各自が頑張っているのに、チームとしての繋がりが薄く、互いの動き方が見えない。
この「孤独な状態」は、組織にとっていくつかの深刻なリスクに繋がります。まず、情報の属人化。PdMが持つ文脈や判断基準が本人の中に閉じてしまい、チームの資産にならない。次に、PdMの離脱・離職リスク。孤独な環境は、特に裁量の大きいポジションほど消耗につながりやすい。
TERASSのPdMは、担当領域における意思決定の裁量が大きい。それは魅力でもあり、同時にリスクでもあります。裁量が大きければ大きいほど、チームとしての繋がりや共通の価値観がなければ、個人の負担になっていく。
だから私たちは、「チームとして価値を発揮するための共通の行動規範」 を作ることにしました。しかも、定義して終わりではなく、各メンバーがそれぞれのKey Actionsの担当者として、実行・改善・継続的な運用に責任を持つ形にしています。
私が担当する「Outcome Driven」とは何か
4つのKey Actionsのうち、私が担当しているのが 「Outcome Driven〜成果から逆算して動く〜」 です。
「プロダクトマネージャーとして、本当に成果を出せているのか？」——この問いは、PdMなら誰もが一度は向き合うものだと思います。そしてこの問いはOutcome Drivenの本質そのものです。
一言で言うと、「作ったもの（Output）ではなく、生まれた変化（Outcome）で成功を測る」 という考え方です。
OutputとOutcomeの違い
ここで少し整理させてください。PdMの仕事で陥りやすいワナが、OutputをOutcomeと混同してしまうことです。
Outcome（成果） ユーザーや事業に生まれた変化のこと。
例：問い合わせ件数が10%増えた
問い方：「何が変わったか？」
Output（作業結果） 実際に作ったもの・実施した施策のこと。
例：問い合わせフォームを設置した
問い方：「何を作ったか？」
フォームを設置した（Output）のに、問い合わせが増えていない（Outcomeなし）——これは失敗です。成功の定義が「リリースできたか」ではなく「何が変わったか」である必要があります。
「わかっている」と「できている」の間にある壁
Outcome Drivenの考え方自体は、多くのPdMが「そうだよね」と納得できるものだと思います。問題は、いざ実行しようとすると、思ったより難しいということです。
「成果を定義してから動く」と言っても、日々のスプリントの忙しさの中で、いつの間にか「とりあえず動く」になってしまう。KPIを設定しても、振り返りの場で「で、結局成果は出たの？」という問いに答えられない。これはTERASSに限らず、多くのプロダクト組織が直面する構造的な課題だと思います。
だから「型」を作ることにした
そこで私が担当として取り組んでいるのが、Outcome Drivenを「再現可能な仕組み」に落とし込むことです。個人の意識やスキルに依存するのではなく、どのプロダクトチームのメンバーでも同じように実行できる型を作る。
具体的には、施策立案に6つのステップを設けています。
Why（定義） — この施策で、何を変えたいのか？
Measure（指標） — 成果が出たことをどう測るか？
What（手段） — 成果を達成するための仮説を複数出す
Prioritize（優先度） — 成果インパクト × 実行コストで絞り込む
Do（実行） — 動きながら、常にStep 1を意識する
Check（評価） — 狙った成果は出たか？学びを次に活かす
このフローをNotionのSprintタスクDBやRetrospectiveのテンプレートに組み込み、「意識しなくても自然にOutcome Drivenになる」状態を目指しています。施策を起案する時点で「Outcome」「Measure」「Priority Score」の記入を必須にし、成果の定義が曖昧なままでは開発作業を進めない——そういう設計です。
振り返りも同様で、「リリースできたか」ではなく「狙った成果は出たか」を毎SprintのRetrospectiveで問う。この問いを習慣化できることで、チームの学びや改善速度は変わります。
TERASSのPdMチームが目指していること
このKey Actionsの取り組み、外から見るとよくある表面的な話に見えるかもしれません。でも、チームの中にいる実感として伝えたいのは、非常に現実的な話をしているということです。
「成果を出せているか？」という問いは、掲げるだけではなく、毎スプリントの振り返りで、毎施策のレビューで問い続ける。そしてそれを、全員がフラットに話せる文化がある。
私が担当するOutcome Drivenのみならず、他の3つのKey Actionsも同様に、各担当メンバーが「どう普及させるか」「どう改善するか」を継続的に考えています。チームで作ったKey Actionsを、チームで育てていく。そういう動き方をしています。
TERASSのPdMに興味を持った方へ
最後に、採用について少し触れさせていただきます。
TERASSのPdMチームは今、一緒に働く仲間を探しています。
「プロダクトで成果を出したい」「ちゃんとアウトカムを追いかけたい」「強いチームの中でPdMとして成長したい」——そう思っている方にとって、TERASSはとても良い環境だと思います。
不動産という、まだまだDXの余白が大きい領域で、データと向き合いながら本質的な成果を追いかけるPdMの仕事。決して簡単ではないですが、その分やりがいもあります。
ちょっとでも気になった方、ぜひカジュアルに話しましょう！
