【あうとかむべーすかいはつ】
アウトカムベース開発 とは？
最終更新:
💡 作った後に、利用者の何が変わったかを確かめる
機能を作った数だけでなく、利用者にどんな変化や価値が生まれたかを目標にする開発の考え方。アウトプットとの違いと、仮説・検証・見直しの進め方を解説します。
📌 このページのポイント
- アウトプットは作ったもの、アウトカムは利用者などに生じる成果
- 望む変化から、試す施策と確認する方法を考える
- 機能を作れば、望む成果が出るとは限らない
- 結果を確かめ、仮説・施策・目標を見直す
ひよこ アウトプットとアウトカムは、どう違うの？
ペンギン先生 例えば「商品検索を改善した」が作ったもの、つまりアウトプットだ。「利用者が欲しい商品を見つけやすくなった」は、目指す変化としてのアウトカムになる。図は架空の例だよ。
ひよこ 機能をたくさん作っても、成果とは限らない？
ペンギン先生 そうだね。機能を出したことと、利用者の役に立ったことは別だ。何が困りごとで、どんな状態に変えたいのかを考える。新機能だけでなく、既存の案内を直すなどの選択肢もある。
ひよこ 成果から考えるには、何から始めるの？
ペンギン先生 今の状態と望む変化を整理しよう。例えば、商品を見つけられない理由を調べる。「検索条件を分かりやすくすると探しやすくなる」という仮説を立て、どう確かめるかを決める。
ひよこ リリース後に数字が上がれば、成功？
ペンギン先生 それだけでは判断できない。季節や利用者の変化など、施策以外の影響もある。測る対象や期間をそろえ、利用者の声も含めて、望む変化が起きたか、別の不便が増えていないかを確認する。
ひよこ 目標に届かなかったら、開発は失敗？
ペンギン先生 仮説が合わなかったのか、測り方や目標に問題があるのかを見直す材料になる。結果から学び、次に試すことを変える。必要な機能を作ることや、品質を守ることを軽視する考え方ではないよ。
もっと詳しく知りたい人へ
売上だけを、開発チームの目標にすればよい？
売上は大切ですが、価格や販売活動などチームが直接変えられない要因にも左右されます。利用者の行動や体験のうち、チームが改善でき、事業の目標につながると考えられる変化を具体化します。利用者の価値と事業の結果を区別して考えます。
OKRやノーススターメトリクスを使うことが必須？
必須とはしません。目標を共有するための道具と、利用者への成果を検証する考え方は別です。EBMのように仮説と実験から学ぶ方法もあります。特定の名称の指標を導入するより、何を変えたいかと、どう確かめるかを明確にします。
まとめ：ざっくりこれだけ覚えればOK！
「アウトカムベース開発」って出てきたら「作った数だけでなく、利用者に生まれた変化や価値を確かめる開発」と思えばだいたいOK！
📖 おまけ：英語の意味
「Outcome-based development」 ＝ 成果を目標にする開発の考え方
💬 このページでは、成果物の完成だけでなく利用者への価値を確かめる考え方として扱います。単一の決まった開発手順の名称ではありません。参考資料のEBMは、目標・仮説・実験・フィードバックを扱う関連する枠組みです。