[CLONE] 開発者体験を見える化し「計器飛行」の実現を目指すSODA構想 〜事業の成長とプロダクト組織能力の相関関係を見いだすには〜 / Developer eXperience Day 2023

会社として正式にはこちらで公開しています。同じものです。
https://speakerdeck.com/visional_engineering_and_design/developer-experience-day-2023

Transcript

1. 開発者体験を⾒える化し
   「計器⾶⾏」の実現を⽬指すSODA構想
   〜事業の成⻑とプロダクト組織能⼒の相関関係を⾒いだすには〜
   Developer eXperience Day 2023: Day2, 2023/6/15
   Visionalグループ 株式会社ビズリーチ
   管理執⾏管掌プロセス改善部
   ⾼橋裕之
   

   View Slide

2. 2
   本コンテンツの⽬的
   本⽇お伝えしたいこと
   Learning Outcome
   エグゼクティブ、マネジャーの⽅へ
   • プロダクト開発チームの「内側」で起きやすい事象を認識しよう
   • ビジネス(事業)とプロダクト開発の相関関係を⾒出そう
   • DORA Metrics（Four Keysなど）以外にもいっぱい測ろう
   • ビジネスを成⻑させるために「計器⾶⾏」を実現しよう
   1. ⾃⼰紹介
   2. 株式会社ビズリーチ紹介
   3. 開発者体験とは
   4. 開発者体験の誤解
   5. 計測指標(メトリクス)の内側と外側
   6. エビデンスベースの計器⾶⾏
   7. SODA構想とは
   8. ビズリーチ版SODA
   アジェンダ
   プロダクト開発者・エンジニアの⽅へ
   • プロダクト開発チームの「外側」も意識しよう
   • 開発者体験はイメージよりエビデンスに価値を置こう
   

   View Slide

3. 3
   ビズリーチ・ジャーニー
   JJUG CCC 2022 Fall (2022/11/27)
   DevOpsDays Tokyo2022 (2022/4/21)
   本
   ⽇
   発
   表
   す
   る
   の
   は
   こ
   れ
   ら
   の
   続
   編
   で
   す
   Regional Scrum Gathering Tokyo 2023 (2023/1/11) DevOpsDays Tokyo2023 (2023/4/18)
   

   View Slide

4. 4
   ⾃⼰紹介
   数々の受託プロジェクトを経験し、フリーランスを経て、1996年に⽇⽴通信システム株式会社
   （現・⽇⽴情報通信エンジニアリング）に⼊社。同社で交換機やIP機器の開発に携わった。2002
   年にソニーデジタルネットワークアプリケーションズ株式会社に⼊社し、コンシューマ向けカメラ
   開発や全社プロセス改善に取り組んだ。2013年にウイングアーク１ｓｔ株式会社に⼊社。2018年
   から品質管理部部⻑、製品品質管理責任者、およびOSS管理責任者を兼任。2021年7⽉に株式会社
   ビズリーチに⼊社し、同年11⽉からプロセス改善部の部⻑を務めている。
   Certified ScrumMaster®
   Advanced Certified ScrumMaster®
   Certified Scrum Product Owner®
   Certified Scrum Professional® - ScrumMaster
   Certified Scrum Professional® - Product Owner
   Certified Agile Leadership I
   Mobius Outcome Delivery Certified Practitioner
   PRINCE2® Foundation Certificate in Project Management
   Management 3.0 licensed facilitator.
   ⾼橋 裕之（Hiroyuki TAKAHASHI）
   趣味
   ⼭、海、⼩説、漫画、映画、ランニング
   経歴
   

   View Slide

5. 株式会社ビズリーチ紹介
   5
   

   View Slide

6. 会社概要
   株式会社ビズリーチ / BizReach, Inc.
   創業 ：2009年4⽉
   代表者 ：株式会社ビズリーチ 代表取締役社⻑ 酒井 哲也
   グループ従業員数：1,821名（2022年7⽉末時点）
   拠点 ：東京、⼤阪、名古屋、福岡、静岡、広島
   資本⾦ ：1億3,000万円
   事業内容：HR Techのプラットフォーム・SaaS事業
   

   View Slide

7. 株式会社ビズリーチのサービス
   

   View Slide

8. 開発者体験とは
   Developer Experience (DevEx)
   8
   

   View Slide

9. 9
   開発者体験とは
   •昨⽇、エンジニアが選ぶ「開発者体験が良い」イメージのある企業
   「Developer eXperience AWARD 2023」ランキング上位30が発表されました。
   •選出企業様、おめでとうございます！！
   https://cto-a.org/news/2023/06/14/8859/
   

   View Slide

10. 10
    開発者体験とは
    •昨⽇、エンジニアが選ぶ「開発者体験が良い」イメージのある企業
    「Developer eXperience AWARD 2023」ランキング上位30が発表されました。
    •選出企業様、おめでとうございます！！
    https://cto-a.org/news/2023/06/14/8859/
    イメージってナニ？
    

    View Slide

11. 11
    イメージは⼤事だ。
    でも「開発者体験が良い」ってどんなこと？
    ツール?
    フルリモート?
    テックブログ？
    カルチャー? ⼤喜利？
    川柳？
    

    View Slide

12. 12
    開発者体験とは
    “開発者体験とは、開発者が⾼速な仮説検証を⾏うための企業における環境や習
    慣、⽂化のことを指します”
    ⽇本CTO協会
    “開発者体験は、開発者が⾃分の仕事についてどう感じ、どう考え、どう評価す
    るかを包含する。(中略) 例えば、中断、⾮現実的な納期、開発ツールのフリク
    ション（摩擦）はDevExに悪影響を及ぼし、明確なタスク、整理されたコー
    ド、負担のないリリースはDevExを向上させます。”
    Abi Noda, Margaret-Anne Storey, Nicole Forsgren, & Greiler, M. (2023).
    引⽤: DevEx: What Actually Drives Productivity: The developer-centric approach to measuring and improving productivity. ACM Queue, Vol.21, No.2, p.35-53.
    引⽤: https://dxd2023.cto-a.org/
    

    View Slide

13. 13
    なるほど。
    では「開発者体験が良い」は
    イメージではなく可視化できるのでは？
    

    View Slide

14. 14
    ウガンダのAirQoプロジェクト
    アフリカの都市部では⼤気汚染が深刻で
    毎年700万⼈もの⼈が亡くなっている。
    ウガンダの⾸都カンパラも例外ではなく
    ⼈々は⼤気汚染に苦しんでいる。
    が、そもそもカンパラの⼈たちは『空気
    がどれぐらい汚れているか』を知らな
    かった。
    マケレレ⼤学のバイノムギシャ⽒は安価
    な⼤気センサーを開発し、バイクタク
    シー（ボタボタ）や建物の屋上に⼤気セ
    ンサーを取り付け市内全域の⼤気汚染
    データを収集し、汚染の予測や⼤気質の
    改善に役⽴つようにした。
    https://about.google/intl/ja_AI/stories/clean-air-for-kampala/
    

    View Slide

15. 15
    ウガンダのAirQoプロジェクト
    アフリカの都市部では⼤気汚染が深刻で
    毎年700万⼈もの⼈が亡くなっている。
    ウガンダの⾸都カンパラも例外ではなく
    ⼈々は⼤気汚染に苦しんでいる。
    が、そもそもカンパラの⼈たちは『空気
    がどれぐらい汚れているか』を知らな
    かった。
    マケレレ⼤学のバイノムギシャ⽒は安価
    な⼤気センサーを開発し、バイクタク
    シー（ボタボタ）や建物の屋上に⼤気セ
    ンサーを取り付け市内全域の⼤気汚染
    データを収集し、汚染の予測や⼤気質の
    改善に役⽴つようにした。
    https://about.google/intl/ja_AI/stories/clean-air-for-kampala/
    まず「測る」ことが⼤事
    

    View Slide

16. 16
    開発者体験とは
    •"DevEx: What Actually Drives Productivity: The developer-
    centric approach to measuring and improving productivity"
    (DevEx: 何が実際に⽣産性を向上させるのか： ⽣産性を測定し改善
    するための開発者中⼼のアプローチ)
    • Association for Computing Machinery（ACM）が発⾏する雑誌 "acmqueue"
    2023年3⽉-4⽉号に載った論⽂
    •著者
    •Abi Noda:
    DX社創業者兼CEO。以前は2019年にGitHubに買収されたPull Panda
    を設⽴
    •Margaret-Anne Storey:
    ビクトリア⼤学コンピューターサイエンス教授。DX社チーフサイエ
    ンティスト
    •Nicole Forsgren:
    Microsoft ResearchのパートナーでDeveloper Velocity Labを率いる。
    "Accelerate: The Science of Lean Software and DevOps"（和名
    「LeanとDevOpsの科学」）の筆頭筆者
    •Michaela Greiler:
    DX社研究責任者。以前はチューリッヒ⼤学およびMicrosoft
    Researchの研究員
    https://mydigitalpublication.com/publication/?m=38068&i=791199&p=1&ver=html5
    

    View Slide

17. 17
    DevExの3コア・ダイヤモンド
    DevEx
    Flow State
    Feedback
    Loops
    Cognitive
    Load
    (参考) Noda, A., Storey, M. A., Forsgren, N., & Greiler, M. (2023). DevEx: What Actually Drives Productivity: The developer-centric approach to measuring and improving productivity. ACM Queue, Vol.21, No.2, p.35-53.
    フロー状態
    認知負荷
    フィードバックループ
    

    View Slide

18. 18
    DevExの3コア・ダイヤモンド
    DevEx
    Flow State
    Feedback
    Loops
    Cognitive
    Load
    1. Feedback Loops(フィードバックループ)：ソフトウェアの開発とテスト、
    コードレビュー、マニュアルテスト、実際のユーザーフィードバックなど、ソ
    フトウェア配信には多くのフィードバックループが関与しています。これらの
    ループはすべて短くなければならず、特にタスクがまだ活動中の間に完了する
    ことが理想的です。フィードバックループがタスクの⼀部として中断すると、
    それは次の作業を中断し、認知負荷を増加させます。
    2. Cognitive Load(認知負荷)：ソフトウェアを作成し維持する作業は⼤量の精神
    的処理を必要とします。開発者が多くのツールや技術を持っていると、タスク
    の⾃然な認知負荷が増加します。ソフトウェアのアーキテクチャも負荷を増加
    させることがあります。ツールチェーンの摩擦を減らす、ドキュメンテーショ
    ンを最新の状態に保つ、システムのアーキテクチャを改善する、プロセスの遅
    延を排除することで認知負荷を軽減できます。
    3. Flow State(フロー状態)：フロー状態は、エネルギーに満ちた集中した感覚を
    伴う完全な没頭感として説明されます。この状態は、作業の構造に対するコン
    トロール、明確な⽬標、魅⼒的な作業があるときに⾃然に発⽣します。フロー
    をもたらすためには、中断や遅延からの邪魔を防ぐことが必要です。
    (参考) Noda, A., Storey, M. A., Forsgren, N., & Greiler, M. (2023). DevEx: What Actually Drives Productivity: The developer-centric approach to measuring and improving productivity. ACM Queue, Vol.21, No.2, p.35-53.
    

    View Slide

19. 19
    DevExの3コア・ダイヤモンド
    DevEx
    Flow State
    Feedback
    Loops
    Cognitive
    Load
    Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons
    Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons
    フィードバックループ
    

    View Slide

20. 20
    DevExの3コア・ダイヤモンド
    (参考)ݪాӻࢠ, ڮຊӳಸ, & ਢ౻ஐ. (2016). ໼ҹΛ༻͍ͨň૊Έ߹Θ͞Εͨํ޲αΠϯʼnͷ
    Θ͔Γ΍͢͞ɿߏ଄ɼΞΠίϯɼՃྸͷޮՌ. ೔ຊೝ஌Պֶձୈ33ճେձ. P2-42. (ਤ1)
    DevEx
    Flow State
    Feedback
    Loops
    Cognitive
    Load
    Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons
    Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons
    認知負荷
    フィードバックループ
    

    View Slide

21. 21
    DevExの3コア・ダイヤモンド
    (参考)ݪాӻࢠ, ڮຊӳಸ, & ਢ౻ஐ. (2016). ໼ҹΛ༻͍ͨň૊Έ߹Θ͞Εͨํ޲αΠϯʼnͷ
    Θ͔Γ΍͢͞ɿߏ଄ɼΞΠίϯɼՃྸͷޮՌ. ೔ຊೝ஌Պֶձୈ33ճେձ. P2-42. (ਤ1)
    DevEx
    Flow State
    Feedback
    Loops
    Cognitive
    Load
    Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons
    Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons
    認知負荷
    フィードバックループ
    

    View Slide

22. 22
    DevExの3コア・ダイヤモンド
    (参考)ݪాӻࢠ, ڮຊӳಸ, & ਢ౻ஐ. (2016). ໼ҹΛ༻͍ͨň૊Έ߹Θ͞Εͨํ޲αΠϯʼnͷ
    Θ͔Γ΍͢͞ɿߏ଄ɼΞΠίϯɼՃྸͷޮՌ. ೔ຊೝ஌Պֶձୈ33ճେձ. P2-42. (ਤ1)
    DevEx
    Flow State
    Feedback
    Loops
    Cognitive
    Load
    Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons
    Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons
    認知負荷
    フィードバックループ
    

    View Slide

23. 23
    DevExの3コア・ダイヤモンド
    (参考)ݪాӻࢠ, ڮຊӳಸ, & ਢ౻ஐ. (2016). ໼ҹΛ༻͍ͨň૊Έ߹Θ͞Εͨํ޲αΠϯʼnͷ
    Θ͔Γ΍͢͞ɿߏ଄ɼΞΠίϯɼՃྸͷޮՌ. ೔ຊೝ஌Պֶձୈ33ճେձ. P2-42. (ਤ1)
    DevEx
    Flow State
    Feedback
    Loops
    Cognitive
    Load
    Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons
    Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons
    認知負荷
    フィードバックループ
    

    View Slide

24. 24
    DevExの3コア・ダイヤモンド
    (参考)ݪాӻࢠ, ڮຊӳಸ, & ਢ౻ஐ. (2016). ໼ҹΛ༻͍ͨň૊Έ߹Θ͞Εͨํ޲αΠϯʼnͷ
    Θ͔Γ΍͢͞ɿߏ଄ɼΞΠίϯɼՃྸͷޮՌ. ೔ຊೝ஌Պֶձୈ33ճେձ. P2-42. (ਤ1)
    DevEx
    Flow State
    Feedback
    Loops
    Cognitive
    Load
    Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons
    Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons
    認知負荷
    フィードバックループ
    

    View Slide

25. 25
    DevExの3コア・ダイヤモンド
    (参考)ݪాӻࢠ, ڮຊӳಸ, & ਢ౻ஐ. (2016). ໼ҹΛ༻͍ͨň૊Έ߹Θ͞Εͨํ޲αΠϯʼnͷ
    Θ͔Γ΍͢͞ɿߏ଄ɼΞΠίϯɼՃྸͷޮՌ. ೔ຊೝ஌Պֶձୈ33ճେձ. P2-42. (ਤ1)
    DevEx
    Flow State
    Feedback
    Loops
    Cognitive
    Load
    Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons
    Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons
    認知負荷
    フィードバックループ
    

    View Slide

26. 26
    DevExの3コア・ダイヤモンド
    (参考)ݪాӻࢠ, ڮຊӳಸ, & ਢ౻ஐ. (2016). ໼ҹΛ༻͍ͨň૊Έ߹Θ͞Εͨํ޲αΠϯʼnͷ
    Θ͔Γ΍͢͞ɿߏ଄ɼΞΠίϯɼՃྸͷޮՌ. ೔ຊೝ஌Պֶձୈ33ճେձ. P2-42. (ਤ1)
    DevEx
    Flow State
    Feedback
    Loops
    Cognitive
    Load
    Georgios Liakopoulos, CC BY-SA 2.0, via Wikimedia Commons
    Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons
    Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons
    フロー状態
    認知負荷
    フィードバックループ
    

    View Slide

27. 27
    DevEx Metrics
    Feedback Loops
    フィードバックループ
    Cognitive Load
    認知負荷
    Flow State
    フロー状態
    Perceptions
    認識（態度、感情、意⾒）
    Human attitudes and opinions
    • ⾃動テストのスピードと出⼒
    に対する満⾜度
    • ローカル変更の検証にかかる
    時間に対する満⾜度
    • 変更を本番に導⼊するまでの
    時間に対する満⾜度
    • コードベースの複雑さの認識
    • プロダクションシステムのデ
    バッグのしやすさ
    • ドキュメントの理解しやすさ
    • 集中⼒と中断を回避する能⼒
    の認識
    • タスクやプロジェクトの⽬標
    が明確であることの満⾜度
    • オンコールがもたらす混乱に
    ついての認識
    Workflows
    ワークフロー
    System and process behaviors
    • CIの結果⽣成にかかる時間
    • コードレビューのターンアラ
    ウンドタイム
    • デプロイメント・リードタイ
    ム（変更が本番環境にリリー
    スされるまでの時間）
    • 技術的な質問に対する回答を
    得るまでにかかる時間
    • 変更を適⽤するために必要な
    ⼿動⼿順
    • ドキュメントの改善頻度
    • ミーティングや割り込みがな
    い時間帯の数
    • 予定外のタスクやリクエスト
    の発⽣頻度
    • チームの対応を必要とするイ
    ンシデントの発⽣頻度
    KPIs
    North star metrics
    • ソフトウェア提供の容易さに関する総合的な認識
    • 従業員エンゲージメントまたは満⾜度
    • ⽣産性の認識
    (参考) Noda, A., Storey, M. A., Forsgren, N., & Greiler, M. (2023). DevEx: What Actually Drives Productivity: The developer-centric approach to measuring and improving productivity. ACM Queue, Vol.21, No.2, p.35-53.
    

    View Slide

28. 28
    DevExメトリクスの例
    Feedback Loops
    フィードバックループ
    Cognitive Load
    認知負荷
    Flow State
    フロー状態
    Perceptions
    知覚
    Human attitudes
    and opinions
    • ⾃動テストのスピードと出⼒に
    対する満⾜度
    • ローカル変更の検証にかかる時
    間に対する満⾜度
    • 変更を本番に導⼊するまでの時
    間に対する満⾜度
    • コードベースの複雑さの認識
    • プロダクションシステムのデ
    バッグのしやすさ
    • ドキュメントの理解しやすさ
    • 集中⼒と中断を回避する能⼒の
    認識
    • タスクやプロジェクトの⽬標が
    明確であることの満⾜度
    • オンコールがもたらす混乱につ
    いての認識
    Workflows
    ワークフロー
    System and
    process
    behaviors
    • CIの結果⽣成にかかる時間
    • コードレビューのターンアラウ
    ンドタイム
    • デプロイメント・リードタイム
    （変更が本番環境にリリースさ
    れるまでの時間）
    • 技術的な質問に対する回答を得
    るまでにかかる時間
    • 変更を適⽤するために必要な⼿
    動⼿順
    • ドキュメントの改善頻度
    • ミーティングや割り込みがない
    時間帯の数
    • 予定外のタスクやリクエストの
    発⽣頻度
    • チームの対応を必要とするイン
    シデントの発⽣頻度
    KPIs
    North star
    metrics
    • ソフトウェア提供の容易さに関する総合的な認識
    • 従業員エンゲージメントまたは満⾜度
    • ⽣産性の認識
    (参考) Noda, A., Storey, M. A., Forsgren, N., & Greiler, M. (2023). DevEx: What Actually Drives Productivity: The developer-centric approach to measuring and improving productivity. ACM Queue, Vol.21, No.2, p.35-53.
    「開発者体験」は測れる
    

    View Slide

29. 29
    やっぱり測れそうだね。
    昔から
    「計測できないものは制御できない」
    って⾔うもんね。
    

    View Slide

30. 30
    ソフトウェアエンジニアリングの歴史的「格⾔」
    「計測できないものは制御できない」
    “You canʼt control what you canʼt measure.”
    Tom DeMarco(1982)
    ”Controlling Software Projects: Management, Measurement, and Estimation” (Prentice Hall/Yourdon Press, 1982)
    

    View Slide

31. 31
    ソフトウェアエンジニアリングの歴史的「格⾔」
    「計測できないものは制御できない」
    “You canʼt control what you canʼt measure.”
    Tom DeMarco(1982)
    ”Controlling Software Projects: Management, Measurement, and Estimation” (Prentice Hall/Yourdon Press, 1982)
    呪⾔
    

    View Slide

32. 32
    「測定できないものは制御できない｣は誤りだった？
    •2009年7⽉、Tom DeMarco がIEEE Software誌7⽉8⽉合
    併号に、衝撃的な記事を寄稿しました。タイトル
    は ”Software Engineering: An Idea Whose Time Has
    Come and Gone?（ソフトウェアエンジニアリング：その
    考えは、もう終わったことなのか？）”
    •この⽂章は当時、Tom DeMarco ⾃⾝が「測定できないも
    のは制御できない｣は誤りだったと認めた！ということで
    業界に衝撃が⾛りました。
    https://www.cs.uni.edu/~wallingf/teaching/172/resources/demarco-on-se.pdf
    「計測できないものは制御できない」
    “You canʼt control what you canʼt measure.”
    このセリフには本当の真実が含まれているのですが、私はこのセリ
    フを使うことに違和感を覚えるようになりました。 (中略)例えば、
    過去40年間、私たちはソフトウェアプロジェクトを時間通り、予算
    通りに終わらせることができないことで⾃らを苦しめてきました。
    (Tom DeMarco, 2009)
    

    View Slide

33. 33
    「測定できないものは制御できない｣は誤りだった？
    •2009年7⽉、Tom DeMarco がIEEE Software誌7⽉8⽉合
    併号に、衝撃的な記事を寄稿しました。タイトル
    は ”Software Engineering: An Idea Whose Time Has
    Come and Gone?（ソフトウェアエンジニアリング：その
    考えは、もう終わったことなのか？）”
    •この⽂章は当時、Tom DeMarco ⾃⾝が「測定できないも
    のは制御できない｣は誤りだったと認めた！ということで
    業界に衝撃が⾛りました。
    https://www.cs.uni.edu/~wallingf/teaching/172/resources/demarco-on-se.pdf
    「計測できないものは制御できない」
    “You canʼt control what you canʼt measure.”
    このセリフには本当の真実が含まれているのですが、私はこのセリ
    フを使うことに違和感を覚えるようになりました。 (中略)例えば、
    過去40年間、私たちはソフトウェアプロジェクトを時間通り、予算
    通りに終わらせることができないことで⾃らを苦しめてきました。
    (Tom DeMarco, 2009)
    例えば、過去40年間、私たちはソフトウェアプ
    ロジェクトを時間通り、予算通りに終わらせる
    ことができないことに⾃責の念を抱いてきまし
    た。しかし、先ほども申し上げたように、これ
    は決して⾄上命題ではありませんでした。
    もっと重要なのは、世界を変えるような、ある
    いは企業やビジネスのあり⽅を変えるようなソ
    フトウェアを作るという「変⾰」です。
    Tom DeMarco(2009)
    

    View Slide

34. 34
    例えば、過去40年間、私たちはソフトウェアプ
    ロジェクトを時間通り、予算通りに終わらせる
    ことができないことに⾃責の念を抱いてきまし
    た。しかし、先ほども申し上げたように、これ
    は決して⾄上命題ではありませんでした。
    もっと重要なのは、世界を変えるような、ある
    いは企業やビジネスのあり⽅を変えるようなソ
    フトウェアを作るという「変⾰」です。
    Tom DeMarco(2009)
    

    View Slide

35. 開発者体験の誤解
    35
    

    View Slide

36. 36
    開発者体験の誤解
    DevEx
    Flow State
    Feedback
    Loops
    Cognitive
    Load
    (参考) Noda, A., Storey, M. A., Forsgren, N., & Greiler, M. (2023). DevEx: What Actually Drives Productivity: The developer-centric approach to measuring and improving productivity. ACM Queue, Vol.21, No.2, p.35-53.
    フロー状態
    認知負荷
    フィードバックループ
    

    View Slide

37. 37
    開発者体験の誤解
    プロダクト開発チーム
    開発者
    DevEx
    Flow State
    Feedback
    Loops
    Cognitive
    Load
    one for all,
    all for one !!
    

    View Slide

38. 38
    開発者体験の誤解
    ねぇ、◯◯の機能って
    6⽉のリリースに乗
    るっていってたよね？
    ⼊ってなくない？
    あぁ、アレはボクたち
    開発チームのスプリン
    トプランニングで⼊ら
    なかったんだ
    ええっ！
    お客様、あの機能ずっーと
    待ってるんだぞ！
    6⽉には必ず！ってお伝え
    しちゃってるんだよ〜！
    他のPBIを優先させ
    たしね。アレは6⽉
    リリースからはド
    ロップさせてもらっ
    たよ
    

    View Slide

39. 39
    開発者体験の誤解
    そんなわけで、私た
    ちのチームは今回余
    裕があったので例の
    △ △ 対応画⾯の実装
    を終えたわ
    ちょいちょい、待てよ！
    俺たちバックエンドチー
    ムは聞いてないぞ！
    キミらだけ出来てどーす
    んだよ！
    スプリントプランニングどおり
    なんだから仕⽅ないじゃない、
    私たちのチームは⾃律性を⼤切
    にしてるのよ！
    

    View Slide

40. 40
    開発者体験の誤解
    one for all,
    all for one !!
    

    View Slide

41. 41
    開発者体験の誤解
    one for all,
    all for one !!
    内側しか⾒てないとこうなる
    

    View Slide

42. 42
    開発者体験の誤解
    アウトプットが恐ろしく速いプロダクト開発チーム
    PO SM
    開発者
    DevEx
    Flow State
    Feedback
    Loops
    Cognitive
    Load
    

    View Slide

43. 43
    開発者体験の誤解
    PO SM
    開発者
    DevEx
    Flow State
    Feedback
    Loops
    Cognitive
    Load
    顧客
    アウトプットが恐ろしく速いプロダクト開発チーム
    

    View Slide

44. 44
    開発者体験の誤解
    PO SM
    開発者
    DevEx
    Flow State
    Feedback
    Loops
    Cognitive
    Load
    顧客
    機能A
    アウトプットが恐ろしく速いプロダクト開発チーム
    

    View Slide

45. 45
    開発者体験の誤解
    PO SM
    開発者
    DevEx
    Flow State
    Feedback
    Loops
    Cognitive
    Load
    顧客
    機能A
    機能B
    アウトプットが恐ろしく速いプロダクト開発チーム
    

    View Slide

46. 46
    開発者体験の誤解
    PO SM
    開発者
    DevEx
    Flow State
    Feedback
    Loops
    Cognitive
    Load
    顧客
    機能A
    機能B
    機能C
    アウトプットが恐ろしく速いプロダクト開発チーム
    

    View Slide

47. 47
    開発者体験の誤解
    PO SM
    開発者
    DevEx
    Flow State
    Feedback
    Loops
    Cognitive
    Load
    顧客
    機能A
    機能B
    機能C
    機能D
    アウトプットが恐ろしく速いプロダクト開発チーム
    

    View Slide

48. 48
    開発者体験の誤解
    PO SM
    開発者
    DevEx
    Flow State
    Feedback
    Loops
    Cognitive
    Load
    顧客
    機能A
    機能B
    機能C
    機能D
    アウトプットが恐ろしく速いプロダクト開発チーム
    

    View Slide

49. 49
    ビルドトラップ
    •組織がアウトカムではなくアウトプットで成功を計測しようとして、⾏き詰まっている状況＊
    •実際に⽣み出された価値ではなく、機能の開発とリリースに集中してしまっている状態＊
    誰もプロダ
    クトを使わ
    ない
    ⾜りない機
    能を作る
    顧客に⾜り
    ない機能を
    聞く
    ϓϩμΫτͷࢮͷαΠΫϧ σΠϏουɾϒϥϯυ
    
    IUUQTUXJUUFSDPNEBWJEKCMBOETUBUVT
    * Perri, M. (2018). ϓϩμΫτϚωδϝϯτ ―ϏϧυτϥοϓΛආ͚ސ٬ʹՁ஋Λಧ͚Δ (٢Ӌ ཾଠ࿠, Trans.). O'Reilly Japan, Inc.
    

    View Slide

50. 50
    ビルドトラップ
    •ビルドトラップ：
    •組織がアウトカムではなくアウトプットで成功を計測しようとして、⾏き詰まっている状況＊
    •実際に⽣み出された価値ではなく、機能の開発とリリースに集中してしまっている状態＊
    誰もプロダ
    クトを使わ
    ない
    ⾜りない機
    能を作る
    顧客に⾜り
    ない機能を
    聞く
    ϓϩμΫτͷࢮͷαΠΫϧ σΠϏουɾϒϥϯυ
    
    IUUQTUXJUUFSDPNEBWJEKCMBOETUBUVT
    * Perri, M. (2018). ϓϩμΫτϚωδϝϯτ ―ϏϧυτϥοϓΛආ͚ސ٬ʹՁ஋Λಧ͚Δ (٢Ӌ ཾଠ࿠, Trans.). O'Reilly Japan, Inc.
    内側しか⾒てないとこうなる
    

    View Slide

51. 計測指標(メトリクス)の内側と外側
    ソフトウェアの⼒で世界を変えるようなプロダクトを⽣み出す
    51
    

    View Slide

52. 52
    計測指標(メトリクス)の内側と外側
    プロダクト開発チーム
    PO SM
    開発者
    DevEx
    Flow State
    Feedback
    Loops
    Cognitive
    Load
    

    View Slide

53. 53
    計測指標(メトリクス)の内側と外側
    プロダクト開発チーム
    PO SM
    開発者
    DevEx
    Flow State
    Feedback
    Loops
    Cognitive
    Load
    顧客
    

    View Slide

54. 54
    計測指標(メトリクス)の内側と外側
    プロダクト開発チーム
    PO SM
    開発者
    DevEx
    Flow State
    Feedback
    Loops
    Cognitive
    Load
    顧客
    プロダクト・サービス提供
    

    View Slide

55. 55
    計測指標(メトリクス)の内側と外側
    プロダクト開発チーム
    PO SM
    開発者
    DevEx
    Flow State
    Feedback
    Loops
    Cognitive
    Load
    顧客
    プロダクト・サービス提供
    

    View Slide

56. 56
    計測指標(メトリクス)の内側と外側
    プロダクト開発チーム
    PO SM
    開発者
    DevEx
    Flow State
    Feedback
    Loops
    Cognitive
    Load
    顧客
    プロダクト・サービス提供 アウトカム向上
    

    View Slide

57. 信頼・対価(売上)
    57
    計測指標(メトリクス)の内側と外側
    プロダクト開発チーム
    PO SM
    開発者
    DevEx
    Flow State
    Feedback
    Loops
    Cognitive
    Load
    顧客
    プロダクト・サービス提供 アウトカム向上
    

    View Slide

58. 信頼・対価(売上)
    58
    計測指標(メトリクス)の内側と外側
    プロダクト開発チーム
    PO SM
    開発者
    DevEx
    Flow State
    Feedback
    Loops
    Cognitive
    Load
    顧客
    プロダクト・サービス提供
    継続
    アウトカム向上
    

    View Slide

59. 信頼・対価(売上)
    59
    計測指標(メトリクス)の内側と外側
    プロダクト開発チーム
    PO SM
    開発者
    DevEx
    Flow State
    Feedback
    Loops
    Cognitive
    Load
    顧客
    プロダクト・サービス提供
    継続
    アウトカム向上
    内側
    ⾃組織を測る
    メトリクス
    外側
    顧客を測る
    メトリクス
    

    View Slide

60. 60
    DORA Metrics
    •Four Keys とは DORA社(DevOps Research and Assessment, 現Google)が⻑年の
    の研究から導いた開発チームのパフォーマンス指標
    •アジャイルでもウォーターフォールでも計測可能
    リードタイム
    コードがコミットされてか
    ら本番環境で正常に実⾏さ
    れるまでの時間
    デプロイ頻度
    コードを本番環境にデプロ
    イまたはエンドユーザーに
    リリースした頻度
    平均サービス
    回復時間(MTRS)
    サービスインシデント
    または不具合が発⽣したと
    きにサービスの復元にどれ
    くらいの時間がかかるか
    変更失敗率
    本番環境に変更を加えた、
    またはユーザーへのリリー
    スを実施した結果サービス
    が低下し、その後修正を⾏
    う必要が⽣じた割合
    

    View Slide

61. DORA Metrics
    “⽣産性”に代わる開発チームのパフォーマンス計測を！
    ソフトウェア開発の“⽣産性”指標の難しさ
    「書いたコードの量」が
    ⽣産性とは限らない
    「ベロシティ(速度)」は
    ⽣産性とは限らない
    「リソース効率(利⽤率)」が
    ⽣産性とは限らない
    品質 スピード
    リードタイムが短くなると学
    習スピードが増し、品質が向
    上する
    品質が向上するとリードタイ
    ムは短くなり、頻繁なデプロ
    イが容易になる リードタイム
    デプロイ頻度
    平均サービス
    回復時間(MTRS)
    変更失敗率
    

    View Slide

62. 62
    DORA Metrics
    リードタイム
    デプロイ頻度
    平均サービス
    回復時間(MTRS)
    変更失敗率
    信頼性（可⽤性）
    Four Keys 27のケイパビリティ
    統計的相関
    （参考）Google Cloud. ” Explore DORA's research program”. Google Cloud. https://www.devops-research.com/research.html. (参照 2023-1-10)
    

    View Slide

63. 信頼・対価(売上)
    63
    Four Keys は内側か外側か？
    プロダクト開発チーム
    PO SM
    開発者
    DevEx
    Flow State
    Feedback
    Loops
    Cognitive
    Load
    顧客
    プロダクト・サービス提供
    継続
    アウトカム向上
    

    View Slide

64. 顧客
    プロダクト・サービス提供
    信頼・対価(売上)
    64
    Four Keys は内側か外側か？
    プロダクト開発チーム
    DevEx
    Flow State
    Feedback
    Loops
    Cognitive
    Load
    継続
    

    View Slide

65. 顧客
    プロダクト・サービス提供
    信頼・対価(売上)
    65
    Four Keys は内側か外側か？
    プロダクト開発チーム
    プロダクト開発チームの“現在の姿”=内側の指標
    DevEx
    Flow State
    Feedback
    Loops
    Cognitive
    Load
    

    View Slide

66. 顧客
    プロダクト・サービス提供
    信頼・対価(売上)
    66
    Four Keys は内側か外側か？
    プロダクト開発チーム
    DevEx
    Flow State
    Feedback
    Loops
    Cognitive
    Load
    プロダクトのアウトカムや品質の定量的計測を中⼼とした
    「市場価値」（アウトカム）も計測したい＝外側の指標
    

    View Slide

67. 顧客
    プロダクト・サービス提供
    信頼・対価(売上)
    67
    Four Keys は内側か外側か？
    プロダクト開発チーム
    DevEx
    Flow State
    Feedback
    Loops
    Cognitive
    Load
    プロダクトのアウトカムや品質の定量的計測を中⼼とした
    「市場価値」（アウトカム）も計測したい＝外側の指標
    もっと重要なのは、世界を変えるような、ある
    いは企業やビジネスのあり⽅を変えるようなソ
    フトウェアを作るという「変⾰」です。
    Tom DeMarco(2009)
    

    View Slide

68. 68
    エビデンスベースドマネジメント（EBM）
    •エビデンスベースドマネジメントは、Scrum.org、Professional Scrum Trainer の
    コミュニティ、Ken Schwaber、Christina Schwaberによって共同開発された。
    •価値を俊敏に、計測・管理・改善するためのフレームワーク
    (参考)Scrum.org ”Evidence-Based Management Guide” https://www.scrum.org/resources/evidence-based-management-guide (参照 2023-1-10)
    

    View Slide

69. 69
    エビデンスベースドマネジメント（EBM）
    市場に出すまでの時間（反応性）
    (T2M: Time to Market)
    新しい能⼒、サービス、製品を迅速
    に提供する能⼒
    イノベーションの能⼒（効果性）
    (A2I: Ability to Innovate)
    顧客やユーザーのニーズにより良く
    応えられるような新しい能⼒を提供
    する能⼒
    現在の価値
    (CV: Current Value)
    現在、顧客やユーザーに提供された
    価値
    未実現の価値
    (UV: Unrealized Value)
    顧客やユーザーの潜在的なニーズを
    すべて満たすことによって実現しう
    る価値
    重要価値領域(KVA)
    

    View Slide

70. 70
    エビデンスベースドマネジメント（EBM）
    市場に出すまでの時間（反応性）
    (T2M: Time to Market)
    新しい能⼒、サービス、製品を迅速
    に提供する能⼒
    イノベーションの能⼒（効果性）
    (A2I: Ability to Innovate)
    顧客やユーザーのニーズにより良く
    応えられるような新しい能⼒を提供
    する能⼒
    現在の価値
    (CV: Current Value)
    現在、顧客やユーザーに提供された
    価値
    未実現の価値
    (UV: Unrealized Value)
    顧客やユーザーの潜在的なニーズを
    すべて満たすことによって実現しう
    る価値
    重要価値領域(KVA)
    市場価値（外側）
    組織的な能⼒（内側）
    

    View Slide

71. 71
    EBMの重要価値指標（KVM）の例
    KVM Measuring
    従業員1⼈あたりの収益
    この⽐率（総収益 / 従業員数）は業界内の主要な競争
    指標である。業界によって⼤きく異なる。
    プロダクトコスト⽐率
    計測対象のプロダクトやシステムにかかる総費⽤およ
    びコスト。運⽤コストも含まれる。
    従業員満⾜度
    従業員のエンゲージメント、エネルギー、熱意を計測
    するのに役⽴つ感情分析の⼀種。
    顧客満⾜度 プロダクトに
    対する顧客のエンゲージメ
    ントと幸福度を計測す
    プロダクトに対する顧客のエンゲージメントと幸福度
    を計測するのに役⽴つ感情分析の⼀種。
    顧客使⽤指標
    機能別の利⽤状況を計測して、顧客がプロダクトをど
    の程度有益だと思っているかを推測する。また、機能
    にかける実際の使⽤時間が、期待と⼀致しているかを
    確認する。
    現在の価値（CV）
    未実現の価値（UV）
    KVM Measuring
    市場占有率
    プロダクトが市場を占める相対的な割合。顧客
    のニーズをよりよく満たした場合、そのプロダ
    クトが達成できるであろう潜在的な市場シェア。
    顧客（ユーザー）満⾜度ギャップ
    顧客またはユーザーが望む体験と実際の体験の
    格差。
    望ましい顧客体験または満⾜度 顧客が望んでいる体験を⽰す指標。
    KVM Measuring
    ビルドと統合の頻度
    単位時間あたりのビルド（統合されてテストされたもの）の回数。
    頻繁にあるいは継続的にリリースしているチームであれば、実際のリ
    リース回数を計測する。
    リリースの頻度
    単位時間あたり（継続的、⽇次、週次、⽉次、四半期ごとなど）のリ
    リース回数。これは、新規的で競争⼒のあるプロダクトにおいて、顧
    客を満⾜させるために必要な時間を評価するのに役⽴つ。
    リリースの安定期間
    開発者がリリースの準備ができたと⾔ったときから、プロダクトの問
    題を修正して、実際に顧客にリリースされるまでにかかった時間。こ
    れは、貧弱な開発プラクティス、その基盤となる設計やコードベース
    の影響を表すのに役⽴つ。
    平均修復時間
    エラーが発⾒されてから修正されるまでの平均時間。これは、組織が
    エラーを修正するときの効率性を明らかにする。
    顧客サイクルタイム
    リリース作業に着⼿してから実際にリリースするまでの時間。組織が
    顧客にリーチするための能⼒を計測するのに役⽴つ。
    リードタイム
    アイデアが提案されて仮説が形成されてから、顧客がそのアイデアを
    享受できるようになるまでの時間。顧客やプロダクトによって、この
    指標は⼤きく異なる。顧客満⾜度の要因でもある。
    変更のリードタイム
    コードがコミットされてから本番環境で正常に実⾏されるまでの時間。
    Four Keysのひとつ。
    デプロイ頻度
    組織がプロダクトの新規バージョンを顧客またはユーザーにデプロイ
    （またはリリース）する回数。Four Keysのひとつ。
    サービス復元時間
    サービスの停⽌が開始されてからサービスの可⽤性が完全に回復する
    までの時間。Four Keysのひとつ。
    学習時間
    アイデアや改善をスケッチして、構築して、ユーザーに提供して、そ
    の利⽤を学習するまでにかかる時間。
    障害物除去時間
    障害物が発⽣してから解決さるまでの平均時間。リードタイムや従業
    員満⾜度の要因でもある。
    ピボットまでの時間
    真のビジネスアジリティの指標で、組織がフィードバックや新しい情
    報を得てから、そのフィードバックに対応するまでの経過時間を表す。
    例えば、競合他社が新たな市場獲得のための機能を提供したことを
    知ってから、組織が顧客体験を計測できるほどに改善する新機能ある
    いはそれを超える機能を提供したりするまでの時間。
    市場に出すまでの時間（T2M）
    KVM Measuring
    イノベーション率
    新しいプロダクトの機能に費やした労⼒やコストを、すべてのプロダ
    クトに費やした労⼒やコストで割ったもの。新しいプロダクトの機能
    を提供する組織のキャパシティについてのインサイトが
    得られる。
    ⽋陥のトレンド
    前回の計測から⽋陥の変化を計測したもの。⽋陥とは、顧客、ユー
    ザー、組織にとってのプロダクトの価値を低下させるものである。⼀
    般的には、意図したとおりに動作しないことを指す。
    オンプロダクト指標
    チームがプロダクトと価値に費やす時間の割合。
    インストールされた
    バージョンの指標
    現在サポートしているプロダクトのバージョン数。これは、組織が古
    いバージョンのサポートや保守にかけている労⼒を表している。
    技術的負債
    プログラミングにおける概念であり、「クイック・アンド・ダー
    ティ」なソリューションをあとで修正することになったときに発⽣す
    る。追加の開発やテストの作業を表したもの。価値の提供に
    望ましくない影響を与え、回避可能な無駄とリスクの増加を⽣み出す。
    本番環境のインシデ
    ントの数
    インストールされたプロダクトの問題を修正するために開発チームが
    特定の期間中断された回数。本番環境でのインシデントの回数は、本
    番環境の安定性を⽰すのに役⽴つ。
    プロダクト（コー
    ド）のアクティブな
    ブランチ数
    プロダクトやサービスの異なるバージョン（または種類）の数。変更
    による潜在的な影響とそれに伴う作業の複雑さについてのインサイト
    が得られる。
    ブランチ間でコード
    をマージする時間
    プロダクトやサービスの異なるバーション間で変更を適⽤するために
    費やした時間。変更による潜在的な影響とそれに伴う作業の複雑さに
    ついてのインサイトが得られる。
    コンテキストスイッ
    チにかかる時間
    例えば、ミーティングや電話による中断された時間、タスクの切り替
    えに費やした時間、チームメンバーがチーム外の⼈を助けるために中
    断された時間がある。問題の規模を把握するのに役⽴
    つ。
    変更失敗率
    リリースされたプロダクトのうち、サービスが低下し、修正を⾏う必
    要が⽣じた割合（例: ホットフィックス、ロールバック、パッチ）。
    Four Keysのひとつ。
    イノベーションの能⼒（A2I）
    (参考) Scrum.org ⻑沢智治、⾓征典(翻訳)“Evidence-Based Management Guide” 2020-9 p.13-P.16 https://www.scrum.org/resources/evidence-based-management-guide (参照2023-1-10)
    

    View Slide

72. 72
    EBMの重要価値指標（KVM）の例
    KVM Measuring
    従業員1⼈あたりの収益
    この⽐率（総収益 / 従業員数）は業界内の主要な競争
    指標である。業界によって⼤きく異なる。
    プロダクトコスト⽐率
    計測対象のプロダクトやシステムにかかる総費⽤およ
    びコスト。運⽤コストも含まれる。
    従業員満⾜度
    従業員のエンゲージメント、エネルギー、熱意を計測
    するのに役⽴つ感情分析の⼀種。
    顧客満⾜度 プロダクトに
    対する顧客のエンゲージメ
    ントと幸福度を計測す
    プロダクトに対する顧客のエンゲージメントと幸福度
    を計測するのに役⽴つ感情分析の⼀種。
    顧客使⽤指標
    機能別の利⽤状況を計測して、顧客がプロダクトをど
    の程度有益だと思っているかを推測する。また、機能
    にかける実際の使⽤時間が、期待と⼀致しているかを
    確認する。
    現在の価値（CV）
    未実現の価値（UV）
    KVM Measuring
    市場占有率
    プロダクトが市場を占める相対的な割合。顧客
    のニーズをよりよく満たした場合、そのプロダ
    クトが達成できるであろう潜在的な市場シェア。
    顧客（ユーザー）満⾜度ギャップ
    顧客またはユーザーが望む体験と実際の体験の
    格差。
    望ましい顧客体験または満⾜度 顧客が望んでいる体験を⽰す指標。
    KVM Measuring
    ビルドと統合の頻度
    単位時間あたりのビルド（統合されてテストされたもの）の回数。
    頻繁にあるいは継続的にリリースしているチームであれば、実際のリ
    リース回数を計測する。
    リリースの頻度
    単位時間あたり（継続的、⽇次、週次、⽉次、四半期ごとなど）のリ
    リース回数。これは、新規的で競争⼒のあるプロダクトにおいて、顧
    客を満⾜させるために必要な時間を評価するのに役⽴つ。
    リリースの安定期間
    開発者がリリースの準備ができたと⾔ったときから、プロダクトの問
    題を修正して、実際に顧客にリリースされるまでにかかった時間。こ
    れは、貧弱な開発プラクティス、その基盤となる設計やコードベース
    の影響を表すのに役⽴つ。
    平均修復時間
    エラーが発⾒されてから修正されるまでの平均時間。これは、組織が
    エラーを修正するときの効率性を明らかにする。
    顧客サイクルタイム
    リリース作業に着⼿してから実際にリリースするまでの時間。組織が
    顧客にリーチするための能⼒を計測するのに役⽴つ。
    リードタイム
    アイデアが提案されて仮説が形成されてから、顧客がそのアイデアを
    享受できるようになるまでの時間。顧客やプロダクトによって、この
    指標は⼤きく異なる。顧客満⾜度の要因でもある。
    変更のリードタイム
    コードがコミットされてから本番環境で正常に実⾏されるまでの時間。
    Four Keysのひとつ。
    デプロイ頻度
    組織がプロダクトの新規バージョンを顧客またはユーザーにデプロイ
    （またはリリース）する回数。Four Keysのひとつ。
    サービス復元時間
    サービスの停⽌が開始されてからサービスの可⽤性が完全に回復する
    までの時間。Four Keysのひとつ。
    学習時間
    アイデアや改善をスケッチして、構築して、ユーザーに提供して、そ
    の利⽤を学習するまでにかかる時間。
    障害物除去時間
    障害物が発⽣してから解決さるまでの平均時間。リードタイムや従業
    員満⾜度の要因でもある。
    ピボットまでの時間
    真のビジネスアジリティの指標で、組織がフィードバックや新しい情
    報を得てから、そのフィードバックに対応するまでの経過時間を表す。
    例えば、競合他社が新たな市場獲得のための機能を提供したことを
    知ってから、組織が顧客体験を計測できるほどに改善する新機能ある
    いはそれを超える機能を提供したりするまでの時間。
    市場に出すまでの時間（T2M）
    KVM Measuring
    イノベーション率
    新しいプロダクトの機能に費やした労⼒やコストを、すべてのプロダ
    クトに費やした労⼒やコストで割ったもの。新しいプロダクトの機能
    を提供する組織のキャパシティについてのインサイトが
    得られる。
    ⽋陥のトレンド
    前回の計測から⽋陥の変化を計測したもの。⽋陥とは、顧客、ユー
    ザー、組織にとってのプロダクトの価値を低下させるものである。⼀
    般的には、意図したとおりに動作しないことを指す。
    オンプロダクト指標
    チームがプロダクトと価値に費やす時間の割合。
    インストールされた
    バージョンの指標
    現在サポートしているプロダクトのバージョン数。これは、組織が古
    いバージョンのサポートや保守にかけている労⼒を表している。
    技術的負債
    プログラミングにおける概念であり、「クイック・アンド・ダー
    ティ」なソリューションをあとで修正することになったときに発⽣す
    る。追加の開発やテストの作業を表したもの。価値の提供に
    望ましくない影響を与え、回避可能な無駄とリスクの増加を⽣み出す。
    本番環境のインシデ
    ントの数
    インストールされたプロダクトの問題を修正するために開発チームが
    特定の期間中断された回数。本番環境でのインシデントの回数は、本
    番環境の安定性を⽰すのに役⽴つ。
    プロダクト（コー
    ド）のアクティブな
    ブランチ数
    プロダクトやサービスの異なるバージョン（または種類）の数。変更
    による潜在的な影響とそれに伴う作業の複雑さについてのインサイト
    が得られる。
    ブランチ間でコード
    をマージする時間
    プロダクトやサービスの異なるバーション間で変更を適⽤するために
    費やした時間。変更による潜在的な影響とそれに伴う作業の複雑さに
    ついてのインサイトが得られる。
    コンテキストスイッ
    チにかかる時間
    例えば、ミーティングや電話による中断された時間、タスクの切り替
    えに費やした時間、チームメンバーがチーム外の⼈を助けるために中
    断された時間がある。問題の規模を把握するのに役⽴
    つ。
    変更失敗率
    リリースされたプロダクトのうち、サービスが低下し、修正を⾏う必
    要が⽣じた割合（例: ホットフィックス、ロールバック、パッチ）。
    Four Keysのひとつ。
    イノベーションの能⼒（A2I）
    (参考) Scrum.org ⻑沢智治、⾓征典(翻訳)“Evidence-Based Management Guide” 2020-9 p.13-P.16 https://www.scrum.org/resources/evidence-based-management-guide (参照2023-1-10)
    

    View Slide

73. 73
    EBMの重要価値指標（KVM）の例
    KVM Measuring
    従業員1⼈あたりの収益
    この⽐率（総収益 / 従業員数）は業界内の主要な競争
    指標である。業界によって⼤きく異なる。
    プロダクトコスト⽐率
    計測対象のプロダクトやシステムにかかる総費⽤およ
    びコスト。運⽤コストも含まれる。
    従業員満⾜度
    従業員のエンゲージメント、エネルギー、熱意を計測
    するのに役⽴つ感情分析の⼀種。
    顧客満⾜度 プロダクトに
    対する顧客のエンゲージメ
    ントと幸福度を計測す
    プロダクトに対する顧客のエンゲージメントと幸福度
    を計測するのに役⽴つ感情分析の⼀種。
    顧客使⽤指標
    機能別の利⽤状況を計測して、顧客がプロダクトをど
    の程度有益だと思っているかを推測する。また、機能
    にかける実際の使⽤時間が、期待と⼀致しているかを
    確認する。
    現在の価値（CV）
    未実現の価値（UV）
    KVM Measuring
    市場占有率
    プロダクトが市場を占める相対的な割合。顧客
    のニーズをよりよく満たした場合、そのプロダ
    クトが達成できるであろう潜在的な市場シェア。
    顧客（ユーザー）満⾜度ギャップ
    顧客またはユーザーが望む体験と実際の体験の
    格差。
    望ましい顧客体験または満⾜度 顧客が望んでいる体験を⽰す指標。
    KVM Measuring
    ビルドと統合の頻度
    単位時間あたりのビルド（統合されてテストされたもの）の回数。
    頻繁にあるいは継続的にリリースしているチームであれば、実際のリ
    リース回数を計測する。
    リリースの頻度
    単位時間あたり（継続的、⽇次、週次、⽉次、四半期ごとなど）のリ
    リース回数。これは、新規的で競争⼒のあるプロダクトにおいて、顧
    客を満⾜させるために必要な時間を評価するのに役⽴つ。
    リリースの安定期間
    開発者がリリースの準備ができたと⾔ったときから、プロダクトの問
    題を修正して、実際に顧客にリリースされるまでにかかった時間。こ
    れは、貧弱な開発プラクティス、その基盤となる設計やコードベース
    の影響を表すのに役⽴つ。
    平均修復時間
    エラーが発⾒されてから修正されるまでの平均時間。これは、組織が
    エラーを修正するときの効率性を明らかにする。
    顧客サイクルタイム
    リリース作業に着⼿してから実際にリリースするまでの時間。組織が
    顧客にリーチするための能⼒を計測するのに役⽴つ。
    リードタイム
    アイデアが提案されて仮説が形成されてから、顧客がそのアイデアを
    享受できるようになるまでの時間。顧客やプロダクトによって、この
    指標は⼤きく異なる。顧客満⾜度の要因でもある。
    変更のリードタイム
    コードがコミットされてから本番環境で正常に実⾏されるまでの時間。
    Four Keysのひとつ。
    デプロイ頻度
    組織がプロダクトの新規バージョンを顧客またはユーザーにデプロイ
    （またはリリース）する回数。Four Keysのひとつ。
    サービス復元時間
    サービスの停⽌が開始されてからサービスの可⽤性が完全に回復する
    までの時間。Four Keysのひとつ。
    学習時間
    アイデアや改善をスケッチして、構築して、ユーザーに提供して、そ
    の利⽤を学習するまでにかかる時間。
    障害物除去時間
    障害物が発⽣してから解決さるまでの平均時間。リードタイムや従業
    員満⾜度の要因でもある。
    ピボットまでの時間
    真のビジネスアジリティの指標で、組織がフィードバックや新しい情
    報を得てから、そのフィードバックに対応するまでの経過時間を表す。
    例えば、競合他社が新たな市場獲得のための機能を提供したことを
    知ってから、組織が顧客体験を計測できるほどに改善する新機能ある
    いはそれを超える機能を提供したりするまでの時間。
    市場に出すまでの時間（T2M）
    KVM Measuring
    イノベーション率
    新しいプロダクトの機能に費やした労⼒やコストを、すべてのプロダ
    クトに費やした労⼒やコストで割ったもの。新しいプロダクトの機能
    を提供する組織のキャパシティについてのインサイトが
    得られる。
    ⽋陥のトレンド
    前回の計測から⽋陥の変化を計測したもの。⽋陥とは、顧客、ユー
    ザー、組織にとってのプロダクトの価値を低下させるものである。⼀
    般的には、意図したとおりに動作しないことを指す。
    オンプロダクト指標
    チームがプロダクトと価値に費やす時間の割合。
    インストールされた
    バージョンの指標
    現在サポートしているプロダクトのバージョン数。これは、組織が古
    いバージョンのサポートや保守にかけている労⼒を表している。
    技術的負債
    プログラミングにおける概念であり、「クイック・アンド・ダー
    ティ」なソリューションをあとで修正することになったときに発⽣す
    る。追加の開発やテストの作業を表したもの。価値の提供に
    望ましくない影響を与え、回避可能な無駄とリスクの増加を⽣み出す。
    本番環境のインシデ
    ントの数
    インストールされたプロダクトの問題を修正するために開発チームが
    特定の期間中断された回数。本番環境でのインシデントの回数は、本
    番環境の安定性を⽰すのに役⽴つ。
    プロダクト（コー
    ド）のアクティブな
    ブランチ数
    プロダクトやサービスの異なるバージョン（または種類）の数。変更
    による潜在的な影響とそれに伴う作業の複雑さについてのインサイト
    が得られる。
    ブランチ間でコード
    をマージする時間
    プロダクトやサービスの異なるバーション間で変更を適⽤するために
    費やした時間。変更による潜在的な影響とそれに伴う作業の複雑さに
    ついてのインサイトが得られる。
    コンテキストスイッ
    チにかかる時間
    例えば、ミーティングや電話による中断された時間、タスクの切り替
    えに費やした時間、チームメンバーがチーム外の⼈を助けるために中
    断された時間がある。問題の規模を把握するのに役⽴
    つ。
    変更失敗率
    リリースされたプロダクトのうち、サービスが低下し、修正を⾏う必
    要が⽣じた割合（例: ホットフィックス、ロールバック、パッチ）。
    Four Keysのひとつ。
    イノベーションの能⼒（A2I）
    (参考) Scrum.org ⻑沢智治、⾓征典(翻訳)“Evidence-Based Management Guide” 2020-9 p.13-P.16 https://www.scrum.org/resources/evidence-based-management-guide (参照2023-1-10)
    市
    場
    価
    値
    (
    外
    側
    )
    組織的な能力（内側）
    DevEx
    Flow State
    Feedback
    Loops
    Cognitive
    Load
    

    View Slide

74. エビデンスベースの計器⾶⾏
    74
    

    View Slide

75. 75
    IT企業の価値は⾔葉に宿る
    •Mission、Vision、Valueの⼤切さ
    ü Mission（⽬的）：
    ⾃分たちの会社は何のためにあるのか。
    ü Vision（夢）：
    どういう未来を築きたいと、⾃分たちは思っているか。
    ü Value（信念）：
    どういうバリューや信念（ビリーフ）を、⾃分たちは⼤事にしているか。
    “現代では世界のほぼすべての企業が「社是」とか、「経営理念」とか、
    「⾏動指針」とか、「企業理念」とか、その他、それに類したもの掲げてい
    る。⼩さいカードにその⾔葉を印刷して、全員に常に持ち歩かせている企業
    もある。そのねらいは、バリューを社内の隅々にまで浸透させることで、社
    員全員が⽇々、そのバリューに従って⾏動できるようにするためである。”
    ワイズカンパニー: 知識創造から知識実践への新しいモデル （野中 郁次郎 (著), ⽵内 弘⾼ (著), ⿊輪 篤嗣 (翻訳), 2020, p.034）
    

    View Slide

76. Mission
    

    View Slide

77. 77
    Value
    มΘΓଓ͚ΔͨΊʹɺֶͼଓ͚Δ ͓٬༷ͷຊ࣭త՝୊ղܾ
    ͦͷߦಈͰɺϒϨΠΫεϧʔ ࣄۀͮ͘Γ͸ɺ஥ؒͮ͘Γ
    Ձ஋͋Δ͜ͱΛɺਖ਼͘͠΍Ζ͏
    Ұ౓͖Γͷਓੜɺ͔ͤͬ͘Կ͔ʹऔΓ૊ΉͳΒɺ
    ୭ʹͰ΋ڳΛுͬͯ఻͑ΒΕΔ࢓ࣄΛ͠Α͏ɻ
    ͓٬༷ɺגओɺࣾ಺֎ͷ஥ؒɺՈ଒ɺͦͯࣗ͠෼ɻ
    ؔΘΔ͢΂ͯͷਓ͕޾ͤʹͳΔࣄۀΛ૑Δɻ
    ͜ͷࢥ͍Λৗʹ๨Εͣɺ
    ͜Ε͔Β΋ಓͷਅΜதΛಊʑͱಥ͖ਐ΋͏ɻ
    มԽ͠ଓ͚Δ࣌୅ͰɺԿ͔Λม͍͑ͨͱࢥ͏ͷͳΒɺ
    ࣗ෼ࣗ਎͕Ұ൪มΘ͍ͬͯ͜͏ɻ
    ֶͼ͸มΘΔ͜ͱΛޙԡͯ͘͠͠ΕΔɻ
    มΘΓଓ͚Δ͜ͱ͸೉͘͠ɺ࣌ʹ͍͚ۤ͠ΕͲɺ
    ͋ͳͨͷࢹ໺ͱՄೳੑΛ޿͛ɺ
    ݁Ռͱͯ͠ਓੜͷ޾ͤ΁ͱͭͳ͕͍ͬͯ͘ɻ
    Ϣʔβʔͱ͍͏ݴ༿΋ؚΊɺ
    ҰਓҰਓ͕༗ػతͳ৺Λ࣋ͭʮ͓٬༷ʯͰ͋Δͱఆٛ͠ɺ
    ͓٬༷ͷମݧΛৗʹ૝૾͠ͳ͕Βɺ
    ຊ࣭తͳ՝୊ΛҾ͖ग़͠ɺൈຊతʹղܾ͠Α͏ɻ
    ͦΕ͕ͦ͜ظ଴Ҏ্ͷ੒Ռ΍඼࣭ɺ
    ͻ͍ͯ͸ࢲ͕ͨͪड͚औΔରՁͱͳΔͷ͔ͩΒɻ
    ୭͔ͷओମੑʹཔΔ͜ͱͳ͘ɺ
    ࣗΒ͕ࣄۀ΍αʔϏεͷΦʔφʔγοϓΛ࣋ͬͯ
    ߟ͑ɺൃݴ͠ɺߦಈ͍ͯ͜͠͏ɻ
    ͦ͏͢Ε͹ ɺ୹ظతͳ੒ՌͷͨΊʹ
    ௕ظతͳՁ஋Λ٘ਜ਼ʹ͢Δ͜ͱ΋ͳ͍ɻ
    ͍·ࣗ෼ʹͰ͖Δ͜ͱΛߟ͑ɺ࠷ॳͷҰาΛ౿Έग़͠ɺ
    ҰਓҰਓ͕ϒϨΠΫεϧʔ͍ͯ͜͠͏ɻ
    ࣄۀͮ͘Γʹ͓͍ͯɺ
    ҰਓͷྗͰ੒͠਱͛ΒΕΔ͜ͱʹ͸ݶք͕͋Δɻ
    ͔ͩΒͦ͜ɺࢤΛԕྀͳ͘ൃ৴͠ɺ஥ؒΛݟ͚ͭɺ
    ͲΜͲΜר͖ࠐΜͰ͍͘͜ͱʹΑͬͯɺ
    ૝૾΋Ͱ͖ͳ͍΄Ͳͷେ͖ͳਪਐྗΛੜΈग़ͦ͏ɻ
    ͦͯ͠ɺ࠷ߴͷ஥ؒͱྺ࢙Λ૑Ζ͏ɻ
    01 02 03
    04 05
    

    View Slide

78. 78
    Vision
    

    View Slide

79. View Slide

80. ⽇本の「キャリアインフラ」になる
    

    View Slide

81. 81
    ⽇本のキャリアインフラになる
    

    View Slide

82. 82
    ⽇本のキャリアインフラになる
    

    View Slide

83. 計測の重要性：Opinion vs Fact（意⾒か事実か）
    Problem（問題） Solution（解決策）
    Fact（事実） Opinion（意⾒）
    設計
    デプロイ
    仮説を実装
    する
    仮説を
    動かす
    結果を
    検証する
    仮説
    対策の仮説
    を⽴てる
    計測
    (参考) https://slide.meguro.ryuzee.com/slides/78 吉⽻⿓太郎さん「カイゼンの基本」の図を変更
    仮説を⽴てるには、
    計測データを検証す
    る必要がある。
    

    View Slide

84. 84
    指標構造｜全体のイメージ
    اۀ
    ࣄۀ
    αʔϏε
    ϓϩμΫτ
    ϓϩδΣΫτ
    ։ൃνʔϜ
    各ブロックが複数指標を保有し、
    さらに各ブロックの指標やアウトカムが下層から上層へ影響を及ぼすも
    のとして設計しています。
    

    View Slide

85. 85
    指標構造｜全体のイメージ
    اۀ
    ࣄۀ
    αʔϏε
    ϓϩμΫτ
    ϓϩδΣΫτ
    ։ൃνʔϜ
    プロダクト開発指標
    各ブロックが複数指標を保有し、
    さらに各ブロックの指標やアウトカムが下層から上層へ影響を及ぼすも
    のとして設計しています。
    将来的には企業ミッションや企業アウトカム指標との相関性を可視化し
    ますが、まずはプロダクト開発指標の可視化を⾏います。
    

    View Slide

86. 86
    指標構造｜プロダクト下 - ３つの指標領域
    アウトカム指標
    現在の品質、維持向上 開発進捗
    障害 開発パフォーマンス
    顧客満⾜度
    プロダクト開発指標
    営業指標 マーケティング指標
    市場占有率
    売上
    利益
    契約企業数 登録ユーザー数
    スカウト数
    求⼈数
    内定率
    ⼊社⼈数
    レジュメ数
    応募数
    内定承諾率
    計画リリース率
    緊急リリース率
    FourKeys
    オンプロダクト指標
    スコープ 時間 予算
    デリバリーの変更率
    進捗率
    スコープの達成率
    マイルストーン達成率
    ⼈件費
    固定費
    開発ツール費
    ケイパビリティ e-NPS パルスサーベイ DiSC
    （⾏動特性）
    勤怠 勤務年数
    開発チームの能⼒・コンディション
    開発チーム組成
    年齢 性別 職位
    アウトカム指標はプロダクト/プロジェクトにより変わります
    1〜複数存在します
    アウトカム指標は、３つの指標群（営業、マーケティング、プロダクト開発）により可視化できると考えています。
    ● 記載の指標、順序等は仮です
    ● 指標単体のみでなく、相関性をもたせた可視化も⾏います
    

    View Slide

87. 87
    指標構造｜プロダクト下 - ３つの指標領域
    アウトカム指標
    現在の品質、維持向上 開発進捗
    障害 開発パフォーマンス
    顧客満⾜度
    プロダクト開発指標
    営業指標 マーケティング指標
    市場占有率
    売上
    利益
    契約企業数 登録ユーザー数
    スカウト数
    求⼈数
    内定率
    ⼊社⼈数
    レジュメ数
    応募数
    内定承諾率
    計画リリース率
    緊急リリース率
    FourKeys
    オンプロダクト指標
    スコープ 時間 予算
    デリバリーの変更率
    進捗率
    スコープの達成率
    マイルストーン達成率
    ⼈件費
    固定費
    開発ツール費
    ケイパビリティ e-NPS パルスサーベイ DiSC
    （⾏動特性）
    勤怠 勤務年数
    開発チームの能⼒・コンディション
    開発チーム組成
    年齢 性別 職位
    アウトカム指標はプロダクト/プロジェクトにより変わります
    1〜複数存在します
    アウトカム指標は、３つの指標群（営業、マーケティング、プロダクト開発）により可視化できると考えています。
    ● 記載の指標、順序等は仮です
    ● 指標単体のみでなく、相関性をもたせた可視化も⾏います
    ブラックボックスになりがち
    

    View Slide

88. 88
    指標構造｜相関性の例
    アウトカム指標
    現在の品質、維持向上 開発進捗
    障害 開発パフォーマンス
    顧客満⾜度
    プロダクト開発指標
    営業指標 マーケティング指標
    市場占有率
    売上
    利益
    契約企業数 登録ユーザー数
    スカウト数
    求⼈数
    内定率
    ⼊社⼈数
    レジュメ数
    応募数
    内定承諾率
    計画リリース率
    緊急リリース率
    FourKeys
    オンプロダクト指標
    （⼯数）
    スコープ 時間 予算
    デリバリーの変更率
    進捗率
    スコープの達成率
    マイルストーン達成率
    ⼈件費
    固定費
    開発ツール費
    ケイパビリティ e-NPS パルスサーベイ DiSC
    （⾏動特性）
    勤怠 勤務年数
    開発チームの能⼒・コンディション
    開発チーム組成
    年齢 性別 職位
    アウトカム指標はプロダクト/プロジェクトにより変わります
    1〜複数存在します
    例えば、このような相関性が⾒られる可能性があります。
    ● 記載の指標、順序等は仮です
    ● 指標単体のみでなく、相関性をもたせた可視化も⾏います
    ブラックボックスになりがち
    

    View Slide

89. 89
    指標構造｜相関性の例
    アウトカム指標
    現在の品質、維持向上 開発進捗
    障害 開発パフォーマンス
    顧客満⾜度
    プロダクト開発指標
    営業指標 マーケティング指標
    市場占有率
    売上
    利益
    契約企業数 登録ユーザー数
    スカウト数
    求⼈数
    内定率
    ⼊社⼈数
    レジュメ数
    応募数
    内定承諾率
    計画リリース率
    緊急リリース率
    FourKeys
    オンプロダクト指標
    （⼯数）
    スコープ 時間 予算
    デリバリーの変更率
    進捗率
    スコープの達成率
    マイルストーン達成率
    ⼈件費
    固定費
    開発ツール費
    ケイパビリティ e-NPS パルスサーベイ DiSC
    （⾏動特性）
    勤怠 勤務年数
    開発チームの能⼒・コンディション
    開発チーム組成
    年齢 性別 職位
    アウトカム指標はプロダクト/プロジェクトにより変わります
    1〜複数存在します
    例えば、このような相関性が⾒られる可能性があります。
    ● 記載の指標、順序等は仮です
    ● 指標単体のみでなく、相関性をもたせた可視化も⾏います
    

    View Slide

90. 90
    指標構造｜相関性の例
    アウトカム指標
    現在の品質、維持向上 開発進捗
    障害 開発パフォーマンス
    顧客満⾜度
    プロダクト開発指標
    営業指標 マーケティング指標
    市場占有率
    売上
    利益
    契約企業数 登録ユーザー数
    スカウト数
    求⼈数
    内定率
    ⼊社⼈数
    レジュメ数
    応募数
    内定承諾率
    計画リリース率
    緊急リリース率
    FourKeys
    オンプロダクト指標
    （⼯数）
    スコープ 時間 予算
    デリバリーの変更率
    進捗率
    スコープの達成率
    マイルストーン達成率
    ⼈件費
    固定費
    開発ツール費
    ケイパビリティ e-NPS パルスサーベイ DiSC
    （⾏動特性）
    勤怠 勤務年数
    開発チームの能⼒・コンディション
    開発チーム組成
    年齢 性別 職位
    アウトカム指標はプロダクト/プロジェクトにより変わります
    1〜複数存在します
    例えば、このような相関性が⾒られる可能性があります。
    ● 記載の指標、順序等は仮です
    ● 指標単体のみでなく、相関性をもたせた可視化も⾏います
    プロダクト開発が⾒えていないと、
    対策が間違っている可能性がある……
    

    View Slide

91. 91
    計器⾶⾏を実現する
    ボーイング787のグラスコックピット Brandrodungswanderfeldhackbau, Public domain, via Wikimedia Commons
    

    View Slide

92. 92
    パイロット/客室乗務員
    航空管制官/
    グランドクルー
    

    View Slide

93. 93
    プロダクト開発チーム
    経営チーム
    

    View Slide

94. ビズリーチが⽬指すプロダクト組織の「計器⾶⾏」
    ボーイング787のグラスコックピット
    Brandrodungswanderfeldhackbau, Public domain, via Wikimedia
    Commons
    

    View Slide

95. ビズリーチが⽬指すプロダクト組織の「計器⾶⾏」
    ボーイング787のグラスコックピット
    Brandrodungswanderfeldhackbau, Public domain, via Wikimedia
    Commons
    注）数値はダミーです
    

    View Slide

96. ビズリーチが⽬指すプロダクト組織の「計器⾶⾏」
    注）数値はダミーです
    

    View Slide

97. 97
    ビズリーチが⽬指すプロダクト組織の「計器⾶⾏」
    

    View Slide

98. 98
    ビズリーチが⽬指すプロダクト組織の「計器⾶⾏」
    Software Outcome Delivery Architecture
    SODA構想
    

    View Slide

99. SODA構想とは
    Software Outcome Delivery Architecture
    99
    

    View Slide

100. 100
     SODA構想とは
     プロダクト開発チーム
     プロダクトマネジメント
     プロダクト品質マネジメント
     プロセス改善マネジメント
     プロダクト組織マネジメント（事業経営）
     プロジェクト
     マネジメント
     プロダクト開発チームは、あらゆる側⾯の「マネジメント」に包まれている
     

     View Slide

101. 101
     SODA構想とは
     •“相互に関連した責任感のあるチーム ”を組織に「実装」するうえで必要なマネジ
     メント関連のナレッジ・スキル体系・フレームワークなどを集め組織への実装イ
     メージを「設計」しメタ的なアーキテクチャを作成した。
     •これを Software Outcome Delivery Architecture (SODA) と名付けました。
     

     View Slide

102. 102
     SODA構想とは
     ⾃組織を視座⾼く点検するためのアーキテクチャ。
     ⾜りない機能を実装したり、学習計画を⽴てることができる。
     

     View Slide

103. Software Outcome Delivery Architecture(SODA): prototype
     

     View Slide

104. Software Outcome Delivery Architecture(SODA): prototype
     

     View Slide

105. Software Outcome Delivery Architecture(SODA): prototype
     継続的に良質なアウトプットを出す仕組み
     

     View Slide

106. Software Outcome Delivery Architecture(SODA): prototype
     継続的に開発チームの
     QCDSをマネジメントする仕組み
     

     View Slide

107. Software Outcome Delivery Architecture(SODA): prototype
     

     View Slide

108. View Slide

109. 継続的に顧客アウトカムを
     達成する仕組み
     

     View Slide

110. View Slide

111. 継続的に適切な品質を
     達成する仕組み
     

     View Slide

112. View Slide

113. 継続的に改善を繰り返し
     Factデータで効果を検証で
     きる仕組み
     

     View Slide

114. View Slide

115. 継続的にビジネスと
     ベネフィットを達成させる仕組み
     

     View Slide

116. View Slide

117. 継続的にイノベーション
     を起こす仕組み
     

     View Slide

118. View Slide

119. プロダクトの世界観
     

     View Slide

120. View Slide

121. 122
     SODAのキーメソッド
     •Software Outcome Delivery Architecture (SODA) を組織にインストールするため
     のキーメソッドを以下のように定義している。
     •「仮説と実験」を繰り返しながら成⻑する組織を⽬指す。
     ((SODA)) Team Performance
     üすべてのプロダクトにFour Keysの計測を定着させ、改善サイクルを作る
     ((SODA)) Quality Value
     üプロダクトごとに有意な品質指標を⾒極めフィードバックプロセスを増やし、プロダ
     クト品質を向上させる
     ((SODA)) Outcome Delivery
     üプロダクトごとにアウトカム指標を⾒極め、計測する
     ((SODA)) Project Value
     üプロジェクトごとに有意なマネジメント指標を計測し段階や例外によるマネジメント
     を⾏えるようにする
     ((SODA)) Evidence Viewer
     üプロダクト開発チームのエビデンスデータを⾒える化する
     ((SODA)) Playbook
     üプロダクトに関するナレッジベースを作成しSECIモデルを作る
     

     View Slide

122. View Slide

123. Software Outcome Delivery Architecture(SODA): prototype
     

     View Slide

124. ビズリーチ版SODA
     125
     

     View Slide

125. 127
     SODAのキーメソッド
     •Software Outcome Delivery Architecture (SODA) を組織にインストールするため
     のキーメソッドを以下のように定義している。
     •「仮説と実験」を繰り返しながら成⻑する組織を⽬指す。
     ((SODA)) Team Performance
     üすべてのプロダクトにFour Keysの計測を定着させ、改善サイクルを作る
     ((SODA)) Quality Value
     üプロダクトごとに有意な品質指標を⾒極めフィードバックプロセスを増やし、プロダ
     クト品質を向上させる
     ((SODA)) Outcome Delivery
     üプロダクトごとにアウトカム指標を⾒極め、計測する
     ((SODA)) Project Value
     üプロジェクトごとに有意なマネジメント指標を計測し段階や例外によるマネジメント
     を⾏えるようにする
     ((SODA)) Evidence Viewer
     üプロダクト開発チームのエビデンスデータを⾒える化する
     ((SODA)) Playbook
     üプロダクトに関するナレッジベースを作成しSECIモデルを作る
     

     View Slide

126. 129
     SODAのキーメソッド
     •Software Outcome Delivery Architecture (SODA) を組織にインストールするため
     のキーメソッドを以下のように定義している。
     •「仮説と実験」を繰り返しながら成⻑する組織を⽬指す。
     ((SODA)) Team Performance
     üすべてのプロダクトにFour Keysの計測を定着させ、改善サイクルを作る
     ((SODA)) Quality Value
     üプロダクトごとに有意な品質指標を⾒極めフィードバックプロセスを増やし、プロダ
     クト品質を向上させる
     ((SODA)) Outcome Delivery
     üプロダクトごとにアウトカム指標を⾒極め、計測する
     ((SODA)) Project Value
     üプロジェクトごとに有意なマネジメント指標を計測し段階や例外によるマネジメント
     を⾏えるようにする
     ((SODA)) Evidence Viewer
     üプロダクト開発チームのエビデンスデータを⾒える化する
     ((SODA)) Playbook
     üプロダクトに関するナレッジベースを作成しSECIモデルを作る
     これらのメソッドを
     組織にインプリメントする
     

     View Slide

127. Software Outcome Delivery Architecture(SODA): prototype
     

     View Slide

128. テーラリング
     Software Outcome Delivery Architecture(SODA): BizReach ver.
     •SODA BizReachは、今後プロダクト組織の成熟度
     に合わせて仕組みを変えていく必要がありますが、
     現在は右図のような構成で考えています。
     深さ 広さ 構造 時間
     型
     • 上記のSODA Prototypeを元に、ビズリーチに合
     わせてテーラリングを⾏いました。
     • テーラリング後のSODA PrototypeをSODA
     BizReachと呼ぶことにします。
     

     View Slide

129. Software Outcome Delivery Architecture(SODA): BizReach ver.
     

     View Slide

130. Software Outcome Delivery Architecture(SODA): BizReach ver.
     

     View Slide

131. View Slide

132. View Slide

133. View Slide

134. すべてのプロダクト
     にFour Keysの計測
     を定着させ、改善サ
     イクルを作る
     

     View Slide

135. View Slide

136. プロダクトごとに有意な品質
     指標を⾒極めフィードバック
     プロセスを増やし、プロダク
     ト品質を向上させる
     

     View Slide

137. プロダクトごとに
     アウトカム指標を⾒極め、
     計測する
     

     View Slide

138. View Slide

139. プロジェクトごとに有意なマネ
     ジメント指標を計測し段階や例
     外によるマネジメントを⾏える
     ようにする
     

     View Slide

140. View Slide

141. プロダクトに関するナ
     レッジベースを作成し
     SECIモデルを作る
     

     View Slide

142. View Slide

143. プロダクト開発チーム
     のエビデンスデータを
     ⾒える化する
     

     View Slide

144. View Slide

145. View Slide

146. View Slide

147. Software Outcome Delivery Architecture(SODA): BizReach ver.
     

     View Slide

148. Software Outcome Delivery Architecture(SODA): BizReach ver.
     市場に出すまでの時間（反応性）
     (T2M: Time-to-Market)
     新しい能⼒、サービス、製品を迅速
     に提供する能⼒
     イノベーションの能⼒（効果性）
     (A2I: Ability to Innovate)
     顧客やユーザーのニーズにより良く
     応えられるような新しい能⼒を提供
     する能⼒
     現在の価値
     (CV: Current Value)
     現在、顧客やユーザーに提供された
     価値
     未実現の価値
     (UV: Unrealized Value)
     顧客やユーザーの潜在的なニーズを
     すべて満たすことによって実現しう
     る価値
     

     View Slide

149. 152
     SODAで強いチームづくりを！
     プロダクトの⼒で、お客さまにベネフィットを！
     

     View Slide

150. #MPH
     5XJUUFS
     IUUQTFOHJOFFSJOHWJTJPOBMJOD
     CMPH
     !7*4*0/"-@&/(
     7JTJPOBMάϧʔϓͰಇ͘ΤϯδχΞͷٕज़తͳऔΓ૊Έ΍ɺΠϕϯτɾొஃ৘ใͳͲΛ͓ಧ͚͠·͢ɻ
     153
     BlogとTwitterで発信中！
     

     View Slide