SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine(コードジン) DeveloperZine(デベロッパージン)- エンジニアの意思決定を支える技術情報メディア

ProductZine Day&オンラインセミナーは、プロダクト開発にフォーカスし、最新情報をお届けしているWebメディア「ProductZine(プロダクトジン)」が主催する読者向けイベントです。現場の最前線で活躍されているゲストの方をお招きし、日々のプロダクト開発のヒントとなるような内容を、講演とディスカッションを通してお伝えしていきます。

AI時代の「壁」を乗り越えろ。プロダクトマネージャーが直面するカオスと、現場を動かす「仕組み化」のリアル

ProductZine Day 2026

ProductZine Day 2026

「CEDEC2026」レポート

予定どおり作っているのに、なぜ良くならないのか──「アウトプット脳」と「ユーザー価値脳」に橋をかける3つの設計【CEDEC2026】

「CEDEC2026」レポート


1本目の橋:小さな実験は「アウトプット脳がギリギリ耐えられる」大きさで設計する

 1つ目は、小さな実験を前提にすることだ。仮説は当たるか外れるか分からない。ならば外れたときのダメージを小さくするしかなく、それは検証コストを小さくすることに尽きる。

 必要になる理由は、アウトプット脳と仮説検証の相性の悪さにある。アウトプット脳にとって成果は予定どおり進むことであり、不確実性はリスクだ。だから検証をやってはみるものの、結果を懸命に解釈して「成功だ、予定どおり進めるぞ」と言えるようにしたくなる。「どう考えても仮説が外れているのに、当たっていた、よし行くぞ、と無理やりこじつけていく」振る舞いは、実際に起きている。

 変化が大きくなるほど、この差は危険になる。予定の遵守という点ではアウトプット脳のほうが安全に見えるため、大きな変化をユーザー価値脳に任せたくなくなる。だがユーザー価値脳からすれば、予定どおりできあがったゴツいものがユーザーと市場の求めるものとまったく違っている、というリスクのほうが許容しがたい。

 「アウトプット脳の人たちがギリギリ耐えられるぐらいの小さな実験をしていく。これを外してもスケジュールへの影響は軽微だと言い張りながら進めていく、みたいな感じですね」

 小さな実験は、そもそも「これはユーザーにとって価値があるのか」を基準にしている。だから価値の話がしやすくなる。「社長、これからはユーザー価値脳です」というよりも、日々の営みの中で価値について話す体験をつくったほうが早い。

 肝は、作るものを変えないことにある。同じ機能をつくるとしても、「この機能を実装しましょう」で終わらせず「誰がどんな行動を変えるのか」を話す。「新しいステージを追加しましょう」ではなく、ステージは追加するとしても「前のステージの攻略者のアクティブ率が、この追加によって何%になる」と話す。氏が過去に携わったBtoB SaaSであれば、「ダッシュボード機能を追加しましょう」ではなく「金属加工業のユーザーが週3回以上ダッシュボードを見るようになる」となる。

 実験を始めるときの3点セットは次のとおりだ。

  1. 誰のどんな行動を変えたいのか(例:新規ユーザー、金属加工業の現場担当者)
  2. どの指標でその兆しを見るのか(例:ログイン率)
  3. うまくいったとき、いかなかったとき、それぞれ次に何をするのか
小さな実験の3点セット
小さな実験の3点セット

 3つ目を先に決めておくことが決定的に重要だと氏は強調する。決めておかないと、後からこじつけで「うまくいった」ことにできてしまうからだ。これがあることで、ただアウトプットを出すだけだった行為が小さな実験に変わる。

2本目の橋:会話の内容ではなく、順序を変える

 2つ目の設計は、会話の順序である。ここで氏が明確に否定したのは、内容を変えにいくアプローチだった。「ユーザー価値について語りましょう」といきなり言えば、「何を言っているんだお前」という反応が返ってくる。内容は変えなくてよい。変えるのは順序だ。

 アウトプット脳との会話は、往々にして「何をつくりましたか」「予定どおり終わりました」「コストはどうでしたか」となる。価値の話はどうしても付け足しになる。氏がいま最もうまくいっているという順序は、次の4段である。

  1. 誰の、どんな行動が変わったのか(例:新規画面のコンバージョンレートが上がった)
  2. その変化はどの証拠に出ているのか
  3. それは事業や体験にどう効くのか
  4. 次に何をするのか、何をやめるのか
橋を架ける会話
橋を架ける会話

 この順序の妙は、価値を語らないと次の話題に進めない縛りが生まれる点にある。しかも1から3の中で、アウトプットもスケジュールもコストも扱える。2の「どの証拠に出ているか」で「コストは変わっていません」と話すこともできる。アウトプット脳がしたい会話は全部網羅できるが、それがユーザー価値の土俵の上で行われている。

 順序を変えると、もう一つ効果が生まれる。氏は少し声を落としてこう言った。

 「あんまりこれ、アウトプット脳の人にバレたくないんですけど、順序が変わると予定の意味が変わっていきます

 アウトプット脳にとって、予定とは守るべき作業計画である。外れれば「失敗だ、誰が悪いんだ」となる。ところがこの順序で会話をしていると、予定は「得られるアウトカムの仮説」に変わる。この機能を追加したから継続率はきっと上がるはずだ、という形になるからだ。そうなれば、予定を外すことは学習機会になる。なぜ外れたのか、なぜそう思ったのか、次はどう確かめるのか、という会話が出てくる。

 会議体をいきなり変えるのは抵抗がある組織も多いだろう。そこで氏が「明日からぜひやってみてほしい」と提案したのが、会議の冒頭に「最近のユーザー」コーナーを増設することだ。今週、ユーザーの行動でどんなことがあったか。そこに短い一次情報を一つ添える。先週この機能をリリースしたからかもしれない。昨日インタビューしたらこんな使い方をしていると聞いたかもしれない。5分程度のショートコーナーでよい、というのが氏の提案である。

 ただし、次のスライドで残念なお知らせをしなければならない、と氏は続けた。

 順序を変えれば価値の話はできるようになるが、会社の仕組みとして、あるいは相手のマインドセットとして最終地点がアウトプットKPIのままであれば、結局引き戻される。「取り組みました」「いいね」と受けたあとに、「で、納期は守れているんだっけ」「今月何件リリースしたの」が来る。KPIが相変わらずそこにあるからだ。

3本目の橋:KPIを「通信簿」から「仮説の集合」に変える

 価値の話を「いい話だったね」で終わらせないために、3つ目の設計としてKPIの再設計が要る。氏の言葉では、KPIを「通信簿」から「仮説の集合」へ変えることだ。

 まず一度やってほしいこととして挙げられたのは、すべてのKPIに「これは何がどう良くなるという仮説で採用されているのか」を問うことである。例えばリリース件数は、仮説が読みにくい。件数が増えると何がうれしいのか。悪いケースでは「件数を増やせばいいのね」となり、品質を犠牲にしてでも件数を増やすエンジニアが現れる。それは周辺でよく聞く話だ、と氏は言う。

 ただし歯止めもかかっている。やりくりに支障を来してまでKPIを追加してはいけない。重要なのは因果関係を明らかにすることであり、つないでみて「この先には何もない」と分かったときに初めて追加を考えればよい。

 では、因果関係をどうつなぐのか。ここで提示されたのがKPIチェーンである。KPIを3つの層でつないでいく考え方だ。

3層のKPI(KPIチェーン)の例
問い
Leading指標(先行指標) どのユーザー行動がどう変わる? フレンド登録率がXポイント上昇した
Intermediate指標(中間指標) 行動の結果、何が改善する? 一緒に遊ぶプレイヤーが増え、30日継続率が向上した
Lagging指標(遅行指標) 最終的に、どの事業指標に効く? LTVが平均Y円向上する
3層のKPI(KPIチェーン)を作成する
3層のKPI(KPIチェーン)を作成する

 ここで氏は、セッション前半に使ったスライドを再び映した。経営層はユーザーに興味がないのか、という問いに答えたときの、あの因果の流れの図である。

 「覚えていますか。これ、今見るとちょっと見え方が変わってきませんか」

 開発チームが主に見ていたユーザーの行動や体験は先行指標であり、その先にある利用の定着や関係の変化は中間指標だ。そして経営が見ていた事業の継続可能性や売上・LTVは、遅行指標にあたる。同じ流れの別地点を見ていた、という前半の説明は、そのままKPIチェーンの説明だったのである。

同じ図が、KPIチェーンとして読み直される
同じ図が、KPIチェーンとして読み直される

 従って、多くの組織で起きている問題はこう言い換えられる。先行指標と遅行指標をつなぐ中間指標が、ちゃんとあるか。そして中間指標を含めて、先行から遅行までがつながっているか。ここが、経営層と話が通じるかどうかを決める。スライドの言葉を借りれば「このチェーンが描けない仮説は、経営の用語に翻訳できず、説明できず、優先順位が決められない」。

 とはいえ3層を一度に並べられても混乱する。指標は場面ごとに使い分けるものだと氏は補足した。

  • 日々の活動:主に先行指標。「本当に上がりそうか」「ユーザーは想定どおりの行動をしていて、それが数字に見えているか」
  • 週次・月次レビュー:先行+中間。「想定していた因果関係は成立していそうか」「その行動変化は次の成果につながりそうか」
  • 経営レビュー(月次〜四半期):中間+遅行。「この取り組みは続けるべきか」。それは「売上が上がっているか、または上がる兆しがあるか」でしか判断できない

 なお質疑応答では、プロダクトのハンドルは最終的にユーザー価値脳の人が握っているとよいという解釈で合っているか、という質問が寄せられた。氏の回答は「合っている」だった。良いものをつくれば済むわけではなく、ユーザーの状況を見ながら生存戦略を考えることがプロダクト責任者の大きな仕事になっているからだ。

価値志向は宗教ではなく、検証可能な実務である

 3つの設計を示したうえで、氏はもう一つのメッセージを置いた。価値志向は宗教ではなく、検証可能な実務であるべきだ、という一節である。

 価値志向であることは必要だが、価値志向でなければダメだという話ではない。価値を信じている人でも、アウトプット志向であるように振る舞わなければならない場面はいくらでもある。氏自身、1年間経営者の立場を経験したとき、「これはアウトプット脳的に見えることしか言っていないだろうな」と自覚していたという。それでも価値を信じていなかったわけではない。

 より悪いのは、「変えなければいけない」と思うことだ。「価値が大事」ということはよい。だが「価値が分かっていないやつはダメだ」と言い始める人が出てくると危うい。価値が攻撃の口実になるアンチパターンを数多く見てきたし、それは本当にうまくいかないという。

価値志向は宗教ではなく、検証可能な実務であるべき
価値志向は宗教ではなく、検証可能な実務であるべき

 では実務とは何か。仮説を書く。証拠を見る。外れた理由を学ぶ。次の判断を更新する。この4つである。

 「これをやっていたら、めちゃくちゃ忙しいものなんですよ。アウトプット脳の人の批判をしている暇なんてないぐらい忙しいんです」

あなたは分断を乗り越える橋の建設者である

 まとめとして氏は、3つの設計が積み上がる順序を整理した。土台は小さな実験である。それがしっかりすると価値について話すことが当たり前に近づき、会話の順序を変えることもKPIチェーンをつくることもやりやすくなる。3つが整うと実験が回しやすくなり、意思決定がしやすくなる。意思決定がうまくなれば、次にどの実験を選べば価値に近づくのかも選びやすくなる。

 最後のメッセージは、「あなたは分断を乗り越える橋の建設者である」だった。重要なのは、どちらが良いか悪いかではない。橋をつくること、そしてその橋を誰もが渡れるようにすることである。「俺は橋をつくったから偉いんだ」ではなく、「これはこういうふうに渡るんだよ」と伝えること。価値の話はこうする、KPIの因果関係はこうつなぐ、という作法を組織に埋め込んでいく。橋は、より良い意思決定をするためのものだ

あなたは分断を乗り越える橋の建設者である
あなたは分断を乗り越える橋の建設者である

 そのうえで氏は、明日から変えられる1つのことを挙げてセッションを締めた。

 「皆さん、もし明日一つだけ何か小さく変えることができるなら、『進捗どうですか』と聞きたくなったシーンで、『最近、誰の何が変わりましたか』と聞いてみてください」

 飯沼氏は、本セッションと同様のテーマをnoteのメンバーシップ限定マガジン「アウトプット脳からユーザー価値脳へ」で配信している(無料の試し読みあり)。また、アウトプット脳の人たちとうまくやっていくコツを扱った著書『Noを伝える技術――プロダクトマネージャーが教える「敵を作らずに断れるようになる」作法』(翔泳社)も刊行されている。

この記事は参考になりましたか?

連載通知を行うには会員登録(無料)が必要です。
既に会員の方はを行ってください。
この記事の著者

斉木 崇(編集部)(サイキ タカシ)

株式会社翔泳社 ProductZine編集長。1978年生まれ。早稲田大学大学院理工学研究科(建築学専門分野)を卒業後、IT入門書系の出版社を経て、2005年に翔泳社へ入社。ソフトウェア開発専門のオンラインメディア「CodeZine(コードジン)」の企画・運営を2005年6月の正式オープン以来担当し、2011年4月から2020年5月までCodeZine編集長を務めた。教育関係メディアの「EdTechZine(エドテックジン)」...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

CodeZine(コードジン)
https://codezine.jp/article/detail/29118 2026/07/30 11:56

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー