13.3K Views
July 19, 25
スライド概要
Scrum Fest Osaka 2025 での発表資料です
レッドジャーニー(https://redjourney.jp/) 所属のアジャイルコーチ 元ギルドワークス 所属 様々な規模のSIerでのシステム開発を経て今に至り、約10年で45の組織、100のチームを支援している。 「ええと思うなら、やったらよろしいやん」を口癖に、社内のみならず社外のチームがより良くなるお手伝いなど日々活動中。 ・認定プロフェッショナルスクラムマスター(CSP-SM) ・認定プロダクトオーナー(CSPO) ブログ:サウスポーなエンジニアの独り言
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を中心にした プロダクトづくりのヒントに なれば幸いです