Outcomeの設計と計測のやり方

Scrum Fest Osaka 2025 Outcomeの設計と計測のやり方 中村 洋(@yohhatu)

自己紹介

中村 洋(Yoh Nakamura) ✔ レッドジャーニー ✔ アジャイルコーチ ✔ @yohhatu ✔ DevLOVE関西 ✔ 「ええと思うなら、やったらよろしいやん」

ともに越える

最近、言われること 「Outcomeオジサン」

Outcomeに関する こんなモヤモヤない？

Outcomeに関する こんなモヤモヤない？ ✔ 「誰の課題解決になるの？」 ✔ 「事業にどんな貢献があるの？」 ✔ 「作った機能は役に立った？」 これらがわからないとモヤモヤしませんか？

Outcome、むずかしい… ✔ Outcome、なんもわかっていなかった… (か、どうかすらわからない)

Scrum Fest Osaka 2025 現段階のyohhatuの思う Outcomeへの考えと 設計と計測のやり方 中村 洋(@yohhatu)

Outcomeの自分の理解

Outcomeの自分の理解

Outcomeの自分の理解 ✔ Activity：プログラミングなどの活動 ✔ Output：生み出された(中間)生成物 ✔ Outcome：生成物を通して得られた成果(変化) ✔ Impact：成果の対価として得られたもの

Outcomeの自分の理解 ✔ 生成物を通して得られた成果(変化) ✔ できなかったことができるようになっている か？もしくはなっていないか？ ✔ 効果がない、副作用があるのもOutcomeの一 種

Outcomeの自分の理解 ✔ 行動が変わるだけじゃなく「課題がどうなっ ているか？」が大事

Outcomeの設計と計測で 自分が今のところ考えていること

Outcomeの設計と計測で 自分が今のところ考えていること ✔ Outcomeだけで考えずにOutput、Impactを 含めて全体で考える

Outcomeの設計と計測で 自分が今のところ考えていること

Outcomeの設計と計測で 自分が今のところ考えていること ✔ Output、Outcome、Impactをそれぞれ計測 するが、それを人やチームの評価に使わない

Outcomeの設計と計測で 自分が今のところ考えていること ✔ Output、Outcome、Impactの計測は強い因 果があるわけではなく、わかりにくいものだと いう認識を持つ

Outcomeの設計と計測で 自分が今のところ考えていること ✔ Output、Outcome、Impactにみんなで関心 を持ち、対話を重ねる

Outcomeの設計と計測で 自分が今のところ考えていること

Outcomeの設計と計測で 自分が今のところ考えていること ✔ 単独で考えずに全体で考える ✔ 計測するが、評価に使わない ✔ わかりにくいものだという認識を持つ ✔ みんなで関心を持ち、対話を重ねる

Outcomeの設計と計測で 自分が今のところ考えていること どれも当たり前のこと

Outcomeの設計と計測で 自分が今のところ考えていること ✔ 当たり前だが、うまくやれるとは限らない ✔ 「難しい」は、やらない理由にはならない ✔ 組織、現場ごとに違うので、探し続ける

Outcomeをどのように 設計して、計測するか？

【再掲】Outcomeの設計と計測で 自分が今のところ考えていること ✔ 単独で考えずに全体で考える ✔ 計測するが、評価に使わない ✔ わかりにくいものだという認識を持つ ✔ みんなで関心を持ち、対話を重ねる

Outcomeをどのように 設計して、計測するか？ ✔ Outcomeだけで考えず、Output、Impactも 含めて考える ✔ それぞれに責務を持っている人たちで一緒に 取り組む ✔ 対話を通じて継続的に学んでいく

Outcomeをどのように 設計して、計測するか？

Outcomeをどのように 設計して、計測するか？ ✔ プロダクトのロードマップ ✔ プロダクトのバックログ ✔ プロダクトのデモ、レビュー

Outcomeをプロダクトの ロードマップに設定する

Outcomeをプロダクトの ロードマップに設定する ✔ もったいない例：ビジネス的な数字(Impact) と作るもの(Output)しかないロードマップ

Outcomeをプロダクトの ロードマップに設定する ✔ ビジネス的な数字(Impact)、課題解決(Outcome)、 作るもの(Output)があるロードマップ

Outcomeをプロダクトの ロードマップに設定する ✔ Output、Outcome、Impact、それぞれに責 務を負っている人たちみんなで設計する

Outcomeをプロダクトの ロードマップに設定する ✔ ビジネスとしてどうなりたいか？ ✔ そのために利用者がどんな体験ができるとい いか？ ✔ そのためにどんな機能、プロダクトになると いいか？

【再掲】Outcomeの設計と計測で 自分が今のところ考えていること ✔ Outcomeだけで考えずにOutput、Impactを 含めて全体で考える

Outcomeをプロダクトの バックログに設定する

Outcomeをプロダクトの バックログに設定する ✔ 誰の課題を解決するの？ ✔ 解決できているかをなにで計測する？ ✔ どうなっていたら解決できていると言える？

Outcomeをプロダクトの バックログに設定する ✔ 利用者が自分にあった商品をより早く手に入 れられる ✔ 検索する回数・探し始めてから購入までの時 間・次に買うまでの時間間隔 ✔ 検索する回数がN%減る・購入までの時間が N%短くなる…

Outcomeをプロダクトの バックログに設定する ✔ バックログのOutcomeをどう集めるの？

Outcomeをプロダクトの バックログに設定する ✔ バックログのOutcomeをどう集めるの？ ✔ ロードマップから集める(のも1つ)

Outcomeをプロダクトの バックログに設定する ✔ バックログを小さく分割した時、それぞれに Outcomeって設計するの？

Outcomeをプロダクトの バックログに設定する ✔ バックログを小さく分割した時、それぞれに Outcomeって設計するの？ ✔ 分割元のバックログのOutcomeをトレースで きるようにしておく(のも1つ)

【再掲】Outcomeの自分の理解 ✔ 行動が変わるだけじゃなく「課題がどうなっ ているか？」が大事

Outcomeをプロダクトの バックログに設定する ✔ 技術的なバックログのOutcomeはどう設計す るの？

Outcomeをプロダクトの バックログに設定する ✔ 技術的なバックログのOutcomeはどう設計す るの？ ✔ 開発者の課題が解決するならそれをOutcome としてみる

Outcomeをプロダクトの バックログに設定する ✔ Outcomeをプロダクトのバックログに設定す ることでロードマップに対する検査もしやすく なる

プロダクトのデモ、レビューで Outcomeを計測する

プロダクトのデモ、レビューで Outcomeを計測する ✔ デモで利用者に触ってもらってOutputからど んなOutcomeが生まれるのかを観察する

プロダクトのデモ、レビューで Outcomeを計測する ✔ 提供したOutputのOutcomeを確認する

プロダクトのデモ、レビューで Outcomeを計測する ✔ どれくらいの頻度でOutcomeの検査するの？

プロダクトのデモ、レビューで Outcomeを計測する ✔ どれくらいの頻度でOutcomeの検査するの？ ✔ Outcomeの計測に一定の時間が必要なことも ある。必ずしも一定じゃなくてもいい

プロダクトのデモ、レビューで Outcomeを計測する ✔ 直近のOutputの検査とごっちゃになりそう

プロダクトのデモ、レビューで Outcomeを計測する ✔ 直近のOutputの検査とごっちゃになりそう ✔ ごっちゃになるならOutcomeの検査をする別 の場を作る。参加する人が必ずしも一緒とは限 らない

まとめ

まとめ

まとめ ✔ Outcomeだけでなく全体で考える ✔ それぞれ計測するがチームの評価に使わない ✔ わかりにくいものだという認識を持つ ✔ みんなで関心を持ち、対話を重ねる

まとめ ✔ 当たり前だが、うまくやれるとは限らない ✔ 「難しい」は、やらない理由にはならない ✔ 組織、現場ごとに違うので、探し続ける

まとめ ✔ ロードマップにOutcomeを設定し、関係者で 対話する ✔ バックログにOutcomeを設定し、理解を深め る ✔ デモでOutcomeの結果を計測し、検査する

Outcomeを中心にした プロダクトづくりのヒントに なれば幸いです