2026.11.11

「アウトカムが大事」にピンとこなかった開発者が、作る前に指標を決めるようになるまで

はじめに

こんにちは、クリエーションラインでバックエンドエンジニアをしているくまごろーです。

「アウトカムが大事なのはわかる。でも、じゃあ開発のやり方を具体的にどう変えればいいの？」

私はずっと、そう思いながら日々の開発をしていました。正直に言うと、「アウトカムが大事」という話は聞き飽きていて、言われるたびに少しイラッとすることもありました。

そんな私のいるチームが、ここ数か月で少しずつアウトカム志向に変わってきました。気づけば、機能の話をする前に「誰のどんな行動を変えたいか」を考え、作る前に指標を決めるのが当たり前になっています。

この記事では、その過程を、推進した側ではなく変わった側の開発者の目線で振り返ります。疑問を抱えていた頃の開発の進め方、転機になった出来事、アウトカムと指標を決めて開発した実例、そして「目標未達」という結果からチームがどう動いたかまでを書きます。

前提：どんな案件で、どんなチームか

題材は、飲食フランチャイズ向けのキャンペーン素材管理システムの開発です。フランチャイズ本部が用意したメニュー写真やキャンペーン素材（POP、チラシ、SNS 用の画像など）を、全国の加盟店の店長がダウンロードして、地域のお客さまの来店や注文を促すために使います。

※ 案件の設定や、この記事に出てくるゴール、ペルソナ、機能などは、実際の内容をもとにした例です。

チームはスクラムで開発していて、PO、スクラムマスター、開発者数名という構成です。スクラムマスターは同じクリエーションラインの ikikko さんで、私は開発者の一人として、設計から実装、計測までを担当しています。

この記事でいう「アウトプット」と「アウトカム」は、EBM（Evidence-Based Management）の定義を参考にしています。

アウトプット：組織が作成し、提供したもの。例：プロダクトのリリース（機能を含む）、レポートなど
アウトカム：プロダクトの顧客やユーザーが体験する、望ましい成果。例：以前よりも速く目的地に行けるようになった

Before：アウトプット志向だった頃

アウトカムを意識する前のチームでは、開発はおおむね次のように進んでいました。

よさそうな機能（アウトプット）を考える
ユーザーストーリーをもとに仕様を深掘りする
実装して、リリースする

ユーザーへの価値提供を意識していなかったわけではありません。「どういう仕様なら使いやすいか」はチームでよく議論していましたし、スプリントレビューでは機能へのフィードバックももらえていました。

それでも、リリースした機能が実際にどれだけ価値を届けられているのかは、観測できていませんでした。今作っている機能が、遠い先にあるゴールとどうつながっているのかも感じられない。雲をつかむような感覚がずっとありました。

その結果、私は「機能はあればあるほどいい」と考えるようになっていました。機能を増やせば保守コストが増え、プロダクトが複雑になることはわかっていました。ただ、どのユーザーがどんな機能を求めているかを十分につかめていなかったので、機能の種類を増やすほど、どれかがユーザーのニーズに当たる可能性は高まるはずだと思っていたのです。

「アウトカムを意識しよう」と言われて、意識しようとはしました。でも、意識しようと思うだけでは、アウトカムを扱えるようにはなりませんでした。何を考え、何を決めればいいのかがわからなかったからです。

転機：チームで行った3つのこと

転機は、期限の決まっていた大きなリリースを終えたあとに訪れました。スクラムマスターの伴走のもとで、チームは次の3つに取り組みました。

1. プロダクトゴールを決めた

そのリリース後のキックオフで、PO にプロダクトビジョンを改めて共有してもらいました。「忙しい合間に仕方なく開いた店長も、良い素材に触れることで、自分の店に合わせた販促をしてみたくなる場所」にしたい、という内容です。

チームはこのビジョンをもとに、プロダクトゴールを2つ決めました。

店長が、探している素材に迷わずたどり着ける
店長が、本部のおすすめ素材に自然と出会える

振り返ると、これで「登るべき山の頂上」がはっきりしました。

2. ペルソナとペインを絞った

次に、チーム全員でインパクトマッピングを行いました。プロダクトゴールを起点に、ゴールに関わるペルソナ、そのペルソナのジョブ、ペインとゲインを洗い出していきます。

たとえば、こんな組み合わせが見えてきました。

素材を作る本部の販促担当：せっかく作ったキャンペーン素材が、店舗で使われていない
担当エリアの店舗に販促を広げたいエリアマネージャー：どの素材を使えばいいのかわからない

開発者として大きかったのは、PO や一部の人だけでなく、チーム全員でこの作業をしたことです。「誰の、どんな課題を解決するのか」を自分の手で書き出したので、その後の開発で迷ったときに立ち返る場所ができました。登るべき山の頂上に加えて、どのルートを進むのかが見えてきた感覚です。

3. 計測基盤を導入した

最後に、ユーザーの動きや操作の状況を追えるようにするために、2つのツールを導入しました。

Amazon Quick：AWS の BI サービス。データベースにつないで簡単に分析できる。素材の閲覧やダウンロードが記録されている監査ログのテーブルを読み込ませて、利用状況の確認に使っている
PostHog：プロダクト分析ツール。ユーザーの行動をイベントとして追える。ページアクセスと、検索まわりの操作をイベントとして蓄積している

たとえば「検索機能が、セッションのうちどれくらいの割合で使われているか」や「画面上のお知らせをクリックしたあと、どこに移動しているか」が見えるようになりました。それまで感覚で語っていたユーザーの行動が、データで見えるようになったのです。山登りでいえば、自分たちの現在地がわかるようになりました。

開発の流れがこう変わった

この3つが土台になって、チームの開発の流れは次のように変わりました。

プロダクトゴールに近づくために、ユーザーにどんな行動変化（アウトカム）を起こすとよいかを考える
その行動変化を観測するのに、どんな指標が有効かを考える
行動変化を引き起こす機能（アウトプット）を考える
アウトプットを実装し、リリースする
期待したとおりに行動変化が起きたかを検証する

以前は1つ目のステップが「よさそうな機能を考える」でした。今は、アウトカムと観測する指標を先に決めて、そこから初めてアウトプットを考えるようになっています。

面白いのは、4つ目の「実装してリリースする」は以前とほとんど変わっていないことです。変わったのは、その前と後でした。

実例：「せっかく上げた素材が使われない」に向き合う

ここからは、この流れで実際に開発した例を一つ紹介します。

ゴールとペインを選ぶ

対象にしたのは、プロダクトゴールの「店長が、本部のおすすめ素材に自然と出会える」です。インパクトマッピングで出てきたペインのうち、次の2つがこのゴールにつながっていました。

素材を作る本部の販促担当：せっかく素材をアップロードしても、店長が気づかず、使ってもらえない
加盟店の店長：素材をシステムに上げてもらっても、フォルダ構造が複雑で、場所を知っている人しかたどり着けない

本部の複数の部署が、それぞれの判断でフォルダの深いところに素材を置いていきます。店長からすると、そもそも新しい素材が増えたことに気づけません。

① どんな行動変化（アウトカム）を起こすか考える

ペインを深掘りするために本部の販促担当に話を聞くと、素材にも優先度があり、特に使ってほしいものがあることがわかりました。

そこで、目指すアウトカムを次のように決めました。

本部が特に見てほしい素材を、大半の店長が見てくれる

② 行動変化を観測する指標を考える

次に、このアウトカムを何で測るかを考えました。「特に見てほしい素材」とは具体的に何かを詰めていき、時期を決めて公開される重要なキャンペーン素材に絞りました。

そこで、直近に公開される予定のキャンペーン素材を測定の対象に選び、次の指標を決めました。

対象期間中に、ログインしたユーザーの X% がその素材を閲覧する

ポイントは、機能の中身を決める前に、この指標を決めたことです。

③ 行動変化を引き起こす機能（アウトプット）を考える

ここでようやく機能の話に入ります。プロトタイプで、2つの案を用意しました。

案1：主な素材をまとめて、一覧で見せる
案2：新しく公開された素材を、ログイン後すぐ目に入る場所で知らせる

ユーザーにヒアリングした結果、案2を採用しました。

リリースするときには、「効果が見込めなければ消す」という前提をチームで共有していました。以前の私なら、機能を一つ増やすことにもっと慎重になっていたか、逆に「あって困るものではない」と深く考えずに足していたと思います。消す前提だったので、迷わず一度作ってみることができました。

④ 実装し、リリースする

ここは以前とほとんど変わりません。

⑤ 期待どおりに行動変化が起きたか検証する

リリースしてしばらく経ってから、指標を確認しました。

結果は、目標未達でした。行動の変化はあったものの、期待したほどではありませんでした。

それでも、チームは慌てませんでした。まず、「なぜ数値が上がらないのか」の仮説を立てました。

そもそもお知らせの存在に気づいていない
気づいてはいるが、使ったことがない
欲しい素材が、そもそもお知らせの中にない

次に、対象のユーザーを選んでヒアリングし、仮説を確かめました。その結果をもとに、次の一手を決めることができました。

振り返ると、迷わずに動けたのは、指標を先に決めていたからだと思います。「どこまで届けば成功か」が先に決まっていたので、届かなかったという事実をそのまま受け止め、「なぜ届かなかったのか」という問いに進めました。もし指標がなかったら、「リリースした、使っている人もいる、たぶん効果はあった」で終わっていたはずです。

目標未達は、失敗ではなく、次の一手を決める起点になりました。

開発者として何が変わったか

この流れで開発するようになって、開発者として感じている変化は4つあります。

作るか作らないかを判断しやすくなった

「アウトカムにつながるかどうか」で、作るかどうかをさっと判断できるようになりました。本実装に入るまでの工程は増えましたが、そのぶん作らなくていいものを作らずに済んでいます。「機能はあればあるほどいい」と考えていた頃とは真逆です。

議論が対立ではなく、すり合わせになった

要件定義や設計の場面で、論点がはっきりするようになりました。以前は、仕様の議論が「私はこっちのほうが使いやすいと思う」という好みのぶつけ合いになることがありました。今は指標が先に決まっているので、「その案は、この指標を動かすか」という同じ物差しで話せます。

作って終わりにならない

機能が期待どおりの成果を出しているかが一目でわかるので、リリース後にも手を入れやすくなりました。以前は、リリースしたら次の機能へ、という流れでした。

ゴールに向かって進んでいる実感が持てる

「プロダクトゴール → アウトカム → アウトプット」がすべてつながっていて、指標もはっきりしています。そのため、スプリント単位ではなく、ゴールに近づいているかどうかがわかるようになりました。

一言でまとめると、自分たちが前に進んでいるかどうかを、自分たちで判断できるようになった、ということです。

なぜ変われたのか

「アウトカムが大事」と説明されても動けなかった私が、なぜ変われたのか。振り返ると、2つのことがそろったからだと思います。

1つ目は、ゴールとの繋がりが見える構造があったことです。プロダクトゴールという中間ゴールがあり、計測によって現在地が見える。山登りでたとえると、頂上（プロダクトゴール）が見え、進むルート（ペルソナとペイン）が決まり、現在地（計測）がわかる状態です。この構造があって初めて、「次にどこを目指せばいいか」を自分たちで考えられるようになりました。

2つ目は、その構造を作る活動に、自分自身が参加したことです。インパクトマッピングで、誰のどんな課題を解決するのかを自分の手で書き出しました。誰かが作った構造を説明されるだけだったら、ここまで自分ごとにはならなかったと思います。

振り返ると、この2つのほかにも、変化を後押ししたことが3つありました。

言われ続けていたことが、あとから効いてきた 提案の段階から、プロジェクトのマネージャーやスクラムマスターは「ユーザーへの価値提供が大事」と繰り返し話してくれていました。当時はピンときていませんでしたが、それが今になって実を結んでいると感じます。
アウトカムに目を向けるには、準備も必要だった 期限のあるリリースに向けて走っていた頃は、その余裕はありませんでした。リリースを終え、AI によって実装にかかる時間も短くなって手があいたからこそ、アウトカムを考えたり計測の仕組みを整えたりする時間がとれたのだと思います。
開発者だけで切り替えられたわけではない PO がビジョンを語り、ユーザーへのヒアリングにも協力してくれたからこそ、この流れが回っています。