SPI原点回帰論：事業課題とFour Keysの結節点を見出す実践的ソフトウェアプロセス改善 / DevOpsDays Tokyo 2024

SPI原点回帰論: 事業課題とFour Keysの結節点を⾒出す実践的ソフトウェアプロセス改善 DevOpsDays Tokyo: Day1, 2024/4/16 Visionalグループ株式会社ビズリーチ
リクルーティングプロダクト本部 PMO室 SODA推進グループ⾼橋裕之内藤靖⼦

2 本コンテンツの⽬的本⽇お伝えしたいこと Learning Outcome エビデンスデータを元に改善する⽅法 • ビズリーチ版SODA構想の実装 • Four
Keysと統計的相関のある27のケイパビリティ • ケイパビリティ（パフォーマンス）向上を⽬指すSPI活動 1. ⾃⼰紹介 2. 会社概要 3. ボス、ロードマップに⼾惑う 4. SPIへの原点回帰 5. ソフトウェアプロセス改善について 6. SPIはDevOps時代に合っているのか？ 7. 改善事例 8. まとめアジェンダソフトウェアプロセス改善（SPI）の基本 • SPIとは • SPIに必要なスキル • SPIのアプローチ • SPI活動の事例紹介

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

4 ⾃⼰紹介 2000年、キヤノンソフトウェア株式会社(現・キヤノンITソリューションズ株式会社)に⼊社。プリンタドライバ開発に従事。2008年、ソニーデジタルネットワークアプリケーションズ株式会社に⼊社。コンシューマ向けハンディカム開発や携帯型⾳楽プレイヤー開発、ソフトウェアプロセス改善に携わる。2015年、ウイングアーク１ｓｔ株式会社に⼊社、2021年8⽉、株式会社ビズリーチに⼊社し、ソフトウェアプロセス改善に従事。SODA構想の推進に取り組んでいる。 Certified ScrumMaster® Advanced
Certified ScrumMaster® Certified Scrum Product Owner® Certified Agile Leadership Essentials® Certified Agile Leadership for Organizations® Mobius Outcome Delivery Certified Practitioner PRINCE2® Foundation Certificate in Project Management 内藤靖⼦（Yasuko NAITO）趣味コストコ、ねこ、ラジオ体操、昼寝経歴

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

6 株式会社ビズリーチビジョン⾃分の可能性を信じ、⾃分の意志ではたらき⽅を選択することができたら、覚悟をもった主体的な「はたらく」を実現できる。⽣産性も向上し、企業にも活⼒が⽣まれる。そのために、⾃分らしく「はたらく」をあたりまえにする「キャリアインフラ」になりたい。⼀⼈ひとりが活き活きとはたらくことができる社会のために。
「キャリアインフラ」になる

時代の変化により、市場の構造が複雑化し、価値観も多様化している。キャリア形成において重要なのは、⾃分の未来に⾃信を持てる「はたらく」を選択し、挑戦し続ける企業と繋がり、新たな活⼒を⽣み出すこと。私たちは世の中にたくさんの「選択肢と可能性」を提供し、「はたらく」を変⾰していく。 7 株式会社ビズリーチミッション
キャリアに、選択肢と可能性を

株式会社ビズリーチサービス⼀覧即戦力人材と企業をつなぐ転職サイト OB/OG訪問ネットワークサービス人財活用システム採用管理システム勤怠管理システム経費精算システム

9 あれは、2年前のある夏の⽇だった

ボス、ロードマップに⼾惑う 2年前のある夏 10

11 ボス、ロードマップに⼾惑う ։ൃϩʔυϚοϓɺ ͬͦ͜ΓมΘΔͱ͖͋ΔΑͶʜʜ ボス

12 「こっそり変わるよね」 FYxx 8⽉ FYxx 9⽉ FYxx 10⽉ FYxx 11⽉
FYxx 12⽉ FYxx 1⽉ 1Q 2Q エビデンスデータを経営の意思決定に利⽤できるよう可視化し提供するプロダクトのロードマップ、予定、進捗、進捗理由のデータを収集する 1プロダクト分、ワンパスのデータ表⽰の仕組みが出来ている⾼品質で、アウトカムが最⼤化されるプロダクトを顧客に届け続ける開発組織になる品質とプロダクト・マネジメント強化エンジニア・デザイナーが困ったときに⽀援する仕組み作り Evidence-Based Management に基づた「アウトカム」指標を使って仮説検証品質保証制度のグランドデザインの作成が完了する PdM研修 Four Keys 計測仕込みと改善提案（#RP1） Four Keys 計測仕込みと改善提案（#RP2） Four Keys 計測仕込みと改善提案（#RP3） Four Keys 計測仕込みと改善提案（#RP4）インナーブランディング計画テックブログテックブログテックブログ Playbook 1st 作成 Playbook 2nd 作成 Playbook 3rd 作成 BIツールでケイパビリティをグラフ化する PdM現状調査ケイパビリティ調査改善ケイパビリティ調査2 回⽬（HRMOS）企画・計画 BIツールのフィジビリティスタディを⾏い選定するペーパープロトタイプ開発チームとの連携を開始実績計画 PdM研修企画 Playbook 構築サイト選定 JIRA/Confluence申請・問い合わせフロー構築導⼊する品質施策の設計とロードマップの作成施策の導⼊を開始する⽤語、レベルの定義関係者との合意形成が完了データ収集施策の導⼊開始運⽤のモニタリングモニタリングデータの報告品質保証制度（品質基準）の設計⽬的の整理が完了「アウトカム」の指標を選定障害データの収集⽬的活⽤⽅法の整理が完了 Four Keys 計測説明（RP本部MGR向け） PdM研修設計ドキュメント作成サービスメニュー構築

FYxx 12⽉ FYxx 1⽉ 1Q 2Q エビデンスデータを経営の意思決定に利⽤できるよう可視化し提供するプロダクトのロードマップ、予定、進捗、進捗理由のデータを収集する⾼品質で、アウトカムが最⼤化されるプロダクトを顧客に届け続ける開発組織になる品質とプロダクト・マネジメント強化エンジニア・デザイナーが困ったときに⽀援する仕組み作り Evidence-Based Management に基づた「アウトカム」指標を使って仮説検証品質保証制度のグランドデザインの作成が完了する PdM研修 Four Keys 計測仕込みと改善提案（#RP1） Four Keys 計測仕込みと改善提案（#RP2） Four Keys 計測仕込みと改善提案（#RP3） Four Keys 計測仕込みと改善提案（#RP4）テックブログ Playbook 1st 作成 Playbook 2nd 作成 Playbook 3rd 作成 PdM現状調査ケイパビリティ調査改善ケイパビリティ調査2 回⽬（HRMOS）企画・計画 BIツールのフィジビリティスタディを⾏い選定するペーパープロトタイプ開発チームとの連携を開始実績計画 PdM研修企画 Playbook 構築サイト選定 JIRA/Confluence申請・問い合わせフロー構築導⼊する品質施策の設計とロードマップの作成⽤語、レベルの定義関係者との合意形成が完了データ収集施策の導⼊開始運⽤のモニタリングモニタリングデータの報告品質保証制度（品質基準）の設計⽬的の整理が完了「アウトカム」の指標を選定障害データの収集⽬的活⽤⽅法の整理が完了 Four Keys 計測説明（RP本部MGR向け） PdM研修設計ドキュメント作成サービスメニュー構築 BIツールでケイパビリティをグラフ化する

FYxx 12⽉ FYxx 1⽉ 1Q 2Q エビデンスデータを経営の意思決定に利⽤できるよう可視化し提供するプロダクトのロードマップ、予定、進捗、進捗理由のデータを収集する⾼品質で、アウトカムが最⼤化されるプロダクトを顧客に届け続ける開発組織になる品質とプロダクト・マネジメント強化エンジニア・デザイナーが困ったときに⽀援する仕組み作り Evidence-Based Management に基づた「アウトカム」指標を使って仮説検証品質保証制度のグランドデザインの作成が完了する PdM研修 Four Keys 計測仕込みと改善提案（#RP1） Four Keys 計測仕込みと改善提案（#RP2） Four Keys 計測仕込みと改善提案（#RP3） Four Keys 計測仕込みと改善提案（#RP4）テックブログ Playbook 1st 作成 Playbook 2nd 作成 Playbook 3rd 作成 PdM現状調査ケイパビリティ調査改善ケイパビリティ調査2 回⽬（HRMOS）企画・計画 BIツールのフィジビリティスタディを⾏い選定するペーパープロトタイプ開発チームとの連携を開始実績計画 PdM研修企画 Playbook 構築サイト選定 JIRA/Confluence申請・問い合わせフロー構築導⼊する品質施策の設計とロードマップの作成⽤語、レベルの定義関係者との合意形成が完了データ収集施策の導⼊開始運⽤のモニタリングモニタリングデータの報告品質保証制度（品質基準）の設計⽬的の整理が完了「アウトカム」の指標を選定障害データの収集⽬的活⽤⽅法の整理が完了 Four Keys 計測説明（RP本部MGR向け） PdM研修設計ドキュメント作成サービスメニュー構築 BIツールでケイパビリティをグラフ化する分 …

FYxx 12⽉ FYxx 1⽉ 1Q 2Q エビデンスデータを経営の意思決定に利⽤できるよう可視化し提供するプロダクトのロードマップ、予定、進捗、進捗理由のデータを収集する 1プロダクト分、ワンパスのデータ表⽰の仕組みが出来ている⾼品質で、アウトカムが最⼤化されるプロダクトを顧客に届け続ける開発組織になる品質とプロダクト・マネジメント強化エンジニア・デザイナーが困ったときに⽀援する仕組み作り Evidence-Based Management に基づた「アウトカム」指標を使って仮説検証品質保証制度のグランドデザインの作成が完了する PdM研修 Four Keys 計測仕込みと改善提案（#RP1） Four Keys 計測仕込みと改善提案（#RP2） Four Keys 計測仕込みと改善提案（#RP3） Four Keys 計測仕込みと改善提案（#RP4）インナーブランディング計画テックブログテックブログテックブログ Playbook 1st 作成 Playbook 2nd 作成 Playbook 3rd 作成 BIツールでケイパビリティをグラフ化する PdM現状調査ケイパビリティ調査改善ケイパビリティ調査2 回⽬（HRMOS）企画・計画 BIツールのフィジビリティスタディを⾏い選定するペーパープロトタイプ開発チームとの連携を開始実績計画 PdM研修企画 Playbook 構築サイト選定 JIRA/Confluence申請・問い合わせフロー構築導⼊する品質施策の設計とロードマップの作成施策の導⼊を開始する⽤語、レベルの定義関係者との合意形成が完了データ収集施策の導⼊開始運⽤のモニタリングモニタリングデータの報告品質保証制度（品質基準）の設計⽬的の整理が完了「アウトカム」の指標を選定障害データの収集⽬的活⽤⽅法の整理が完了 Four Keys 計測説明（RP本部MGR向け） PdM研修設計ドキュメント作成サービスメニュー構築⼀度⾒ ……

FYxx 12⽉ FYxx 1⽉ 1Q 2Q エビデンスデータを経営の意思決定に利⽤できるよう可視化し提供するプロダクトのロードマップ、予定、進捗、進捗理由のデータを収集する 1プロダクト分、ワンパスのデータ表⽰の仕組みが出来ている⾼品質で、アウトカムが最⼤化されるプロダクトを顧客に届け続ける開発組織になる品質とプロダクト・マネジメント強化エンジニア・デザイナーが困ったときに⽀援する仕組み作り Evidence-Based Management に基づた「アウトカム」指標を使って仮説検証品質保証制度のグランドデザインの作成が完了する PdM研修 Four Keys 計測仕込みと改善提案（#RP1） Four Keys 計測仕込みと改善提案（#RP2） Four Keys 計測仕込みと改善提案（#RP3） Four Keys 計測仕込みと改善提案（#RP4）インナーブランディング計画テックブログテックブログテックブログ Playbook 1st 作成 Playbook 2nd 作成 Playbook 3rd 作成 BIツールでケイパビリティをグラフ化する PdM現状調査ケイパビリティ調査改善ケイパビリティ調査2 回⽬（HRMOS）企画・計画 BIツールのフィジビリティスタディを⾏い選定するペーパープロトタイプ開発チームとの連携を開始実績計画 PdM研修企画 Playbook 構築サイト選定 JIRA/Confluence申請・問い合わせフロー構築導⼊する品質施策の設計とロードマップの作成施策の導⼊を開始する⽤語、レベルの定義関係者との合意形成が完了データ収集施策の導⼊開始運⽤のモニタリングモニタリングデータの報告品質保証制度（品質基準）の設計⽬的の整理が完了「アウトカム」の指標を選定障害データの収集⽬的活⽤⽅法の整理が完了 Four Keys 計測説明（RP本部MGR向け） PdM研修設計ドキュメント作成サービスメニュー構築

FYxx 12⽉ FYxx 1⽉ 1Q 2Q エビデンスデータを経営の意思決定に利⽤できるよう可視化し提供するプロダクトのロードマップ、予定、進捗、進捗理由のデータを収集する⾼品質で、アウトカムが最⼤化されるプロダクトを顧客に届け続ける開発組織になる品質とプロダクト・マネジメント強化エンジニア・デザイナーが困ったときに⽀援する仕組み作り Evidence-Based Management に基づた「アウトカム」指標を使って仮説検証品質保証制度のグランドデザインの作成が完了する PdM研修 Four Keys 計測仕込みと改善提案（#RP1） Four Keys 計測仕込みと改善提案（#RP2） Four Keys 計測仕込みと改善提案（#RP3） Four Keys 計測仕込みと改善提案（#RP4）テックブログ Playbook 1st 作成 Playbook 2nd 作成 Playbook 3rd 作成 PdM現状調査ケイパビリティ調査改善ケイパビリティ調査2 回⽬（HRMOS）企画・計画 BIツールのフィジビリティスタディを⾏い選定するペーパープロトタイプ開発チームとの連携を開始実績計画 PdM研修企画 Playbook 構築サイト選定 JIRA/Confluence申請・問い合わせフロー構築導⼊する品質施策の設計とロードマップの作成⽤語、レベルの定義関係者との合意形成が完了データ収集施策の導⼊開始運⽤のモニタリングモニタリングデータの報告品質保証制度（品質基準）の設計⽬的の整理が完了「アウトカム」の指標を選定障害データの収集⽬的活⽤⽅法の整理が完了 Four Keys 計測説明（RP本部MGR向け） PdM研修設計ドキュメント作成サービスメニュー構築 BIツールでケイパビリティをグラフ化する

18 ボス、ロードマップに⼾惑う ʜʜ ボス

FYxx 12⽉ FYxx 1⽉ 1Q 2Q エビデンスデータを経営の意思決定に利⽤できるよう可視化し提供するプロダクトのロードマップ、予定、進捗、進捗理由のデータを収集する⾼品質で、アウトカムが最⼤化されるプロダクトを顧客に届け続ける開発組織になる品質とプロダクト・マネジメント強化エンジニア・デザイナーが困ったときに⽀援する仕組み作り Evidence-Based Management に基づた「アウトカム」指標を使って仮説検証品質保証制度のグランドデザインの作成が完了する PdM研修 Four Keys 計測仕込みと改善提案（#RP1） Four Keys 計測仕込みと改善提案（#RP2） Four Keys 計測仕込みと改善提案（#RP3） Four Keys 計測仕込みと改善提案（#RP4）テックブログ Playbook 1st 作成 Playbook 2nd 作成 Playbook 3rd 作成 PdM現状調査ケイパビリティ調査改善ケイパビリティ調査2 回⽬（HRMOS）企画・計画 BIツールのフィジビリティスタディを⾏い選定するペーパープロトタイプ開発チームとの連携を開始実績計画 PdM研修企画 Playbook 構築サイト選定 JIRA/Confluence申請・問い合わせフロー構築導⼊する品質施策の設計とロードマップの作成⽤語、レベルの定義関係者との合意形成が完了データ収集施策の導⼊開始運⽤のモニタリングモニタリングデータの報告品質保証制度（品質基準）の設計⽬的の整理が完了「アウトカム」の指標を選定障害データの収集⽬的活⽤⽅法の整理が完了 Four Keys 計測説明（RP本部MGR向け） PdM研修設計ドキュメント作成サービスメニュー構築 BIツールでケイパビリティをグラフ化する問題 1. 現象のエビデンスがない（なんで変わったの？） 2. お客様への約束を守れてない（信頼・売上への影響懸念） 3. 「今期中はムリです」と変更を断られる（戦略への影響懸念） 4. リスケしたのでオンスケです（ん？） etc.

20 ボス、ロードマップに⼾惑う ։ൃੜ࢈ੑͬͯଌΕͳ͍ͷʁ ΍ͬͺΓ஌Γ͍ͨͳ͊ ։ൃνʔϜͷ஗Εͨཧ༝Λ ʮ৴͡Δʯ͔͠ͳ͍ΜͩΑͶ͐ʜʜ ボス

21 ボス、ロードマップに⼾惑う ʢ͋ͬʜ͜Ε্ख͘ରԠ͠ͳ͍ͱϠόΠ΍ͭʂʣ Θ͔Γ·ͨ͠ʂߟ͑·͢ʂ ։ൃੜ࢈ੑͬͯଌΕͳ͍ͷʁ ΍ͬͺΓ஌Γ͍ͨͳ͊ ։ൃνʔϜͷ஗Εͨཧ༝Λ ʮ৴͡Δʯ͔͠ͳ͍ΜͩΑͶ͐ʜʜ ボス

22 ボス、ロードマップに⼾惑うロードマップがこっそり変わるのは⽣産性が低いからだ⾃組織の⽣産性が分からないから計画がブレる or ズレた根拠がない（エビデンスが欲しい） ϘεͷԾઆ ։ൃੜ࢈ੑͬͯଌΕͳ͍ͷʁ ΍ͬͺΓ஌Γ͍ͨͳ͊
։ൃνʔϜͷ஗Εͨཧ༝Λ ʮ৴͡Δʯ͔͠ͳ͍ΜͩΑͶ͐ʜʜ

23 ボス、ロードマップに⼾惑うロードマップがこっそり変わるのは⽣産性が低いからだ⾃組織の⽣産性が分からないから計画がブレる or ズレた根拠がない（エビデンスが欲しい）ロードマップが「おおざっぱな WBS」みたいになっている作業ばかり挙げてゴール・成果
物に着目できていない工場みたいに生産性がわかればソフトウェアも予測可能と思われている（物的生産性）リリースさえすれば売れると信じている（そうかもしれないし、そうでないかもしれない）そもそもロードマップを適当に作った（どうせ変わるしマインド）

24 ボス、ロードマップに⼾惑うロードマップがこっそり変わるのは⽣産性が低いからだ⾃組織の⽣産性が分からないから計画がブレる or ズレた根拠がない（エビデンスが欲しい）ロードマップが「おおざっぱな WBS」みたいになっている作業ばかり挙げてゴール・成果
物に着目できていない工場みたいに生産性がわかればソフトウェアも予測可能と思われている（物的生産性）リリースさえすれば売れると信じている（そうかもしれないし、そうでないかもしれない）そもそもロードマップを適当に作った（どうせ変わるしマインド）ロードマップがこっそり変わる要因はたくさんありそうだ

リリース1 リリース2 リリース3 ②リリース計画 ③イテレーション 0 ③イテレーション 1 ③イテレーション 2
③イテレーション 3 ③イテレーション n ④イテレーション計画 ⑥フィーチャーA (⑤ユーザー・ストーリー2) ⑥フィーチャーB (⑤ユーザー・ストーリー3) ⑥フィーチャーC (⑤ユーザー・ストーリー4) ⑥フィーチャーD (⑤ユーザー・ストーリー5) ⑦タスクA ⑦タスクB ⑦タスクC ⑦タスクD 5時間 8時間 4時間 12時間 nプロダクト・ビジョンが①プロダクト・ロードマップを導く n①プロダクト・ロードマップが②リリース計画を導く n②リリース計画が③イテレーションを設定する n④イテレーション計画がフィーチャー開発のスケジュールを設定する n⑤ユーザー・ストーリーによって提供される優先順位の付いた⑥フィーチャー（ストーリーポイントで⾒積もられる) n⑤ユーザー・ストーリーを提供するために作成された⑦タスク(時間単位で⾒積もられる) ⑥フィーチャーA (⑤ユーザー・ストーリー1) プロダクト・ロードマップと計画の関連図 ①プロダクト・ロードマップ SP 5 SP 8 SP 3 SP 5 SP 8 （参考）PMBOKガイド第7版の図2-17 を加⼯して作成

26 ソフトウェア開発の“⽣産性”指標の難しさ「書いたコードの量」が⽣産性とは⾔い難い • 1000⾏から成るコードより、10⾏のコードで解決するほうが望ましいこともある • 誰も理解出来ない1⾏のコードより、理解も保守もしやすい数⾏のコードのほうが望ましいこともある「ベロシティ(速度)」が⽣産性とは⾔い難い • ベロシティはキャパシティを予測する(計画する)ためのツールであって⽣産性とは違う
• ベロシティは、あくまでもチーム内の相対的な尺度（過去の⾃分たちとの⽐較）。即ち、チーム同⼠の⽐較に意味はない「リソース効率(利⽤率)」を上げれば⽣産性が上がるとは限らない • リソース効率向上ばかり⽬指すと「⼈が⾜りない」問題がいつまでも続く • ⼤事なのは作業に集中する「フロー効率」の向上 • さらに⼤事なのは、必ず発⽣する予想外の仕事や計画変更、エンジニア⾃⾝の実験・勉強・鍛錬の時間を捻出するための「Slack（ゆとり）」計測によってチーム同⼠が競争・対⽴するような状況を防がなければならない • 開発 vs QA 、開発 vs 運⽤といった対⽴を煽りかねない計測値を⼈事評価に使わせない • 評価者への⽢い囁き！（評価が明確になりそうな雰囲気がある） • 評価KPIにしたとたん、数値を良く⾒せるための計測Hackがはじまる（最悪の場合、偽装も）

։ൃνʔϜͷ஗Εͨཧ༝Λ ʮ৴͡Δʯ͔͠ͳ͍ΜͩΑͶ͐ʜʜ

։ൃνʔϜͷ஗Εͨཧ༝Λ ʮ৴͡Δʯ͔͠ͳ͍ΜͩΑͶ͐ʜʜ 測るのは良いが、測ったあとのことや測るときのチームの負荷を考えて意味のない計測をしないようにする必要がある

29 計測を始めるにあたって注意したことプロジェクトを時間通り、予算通りに終わらせることよりももっと重要なのは、世界を変えるような、あるいは企業やビジネスのあり⽅を変えるようなソフトウェアを作るという「変⾰」（参照）Tom
DeMarco. (2009). IEEE Software誌7⽉8⽉合併号"Software Engineering: An Idea Whose Time Has Come and Gone?".

30 計測を始めるにあたって注意したことプロジェクトを時間通り、予算通りに終わらせることよりももっと重要なのは、世界を変えるような、あるいは企業やビジネスのあり⽅を変えるようなソフトウェアを作るという「変⾰」（参照）Tom
DeMarco. (2009). IEEE Software誌7⽉8⽉合併号"Software Engineering: An Idea Whose Time Has Come and Gone?". 「アウトプット」より「アウトカム」

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

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

33 Software Outcome Delivery Architecture(SODA): prototype 40%"ߏ૝ͬͯͷΛߟ͑·ͨ͠ʂ ͥͻɺਐΊ͍ͤͯͩ͘͞͞ʂ ボス

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

35 SODA Journey https://speakerdeck.com/takabow/devopsdays-tokyo2022-huakutokarashi- merugai-shan-apuroti-leantodevopsfalseke-xue-woshi-jian-site https://speakerdeck.com/visional_engineering_and_design/number- rsgt2023 https://speakerdeck.com/visional_engineering_and_design/developer- experience-day-2023 https://speakerdeck.com/visional_engineering_and_design/devopsdaystoky
o-2023 https://speakerdeck.com/visional_engineering_and_design/jasst24-tokyo 2022-4-21 DevOpsDaysTokyo 2022 2023-1-11 Regional Scrum Gathering Tokyo 2023 2023-4-18 DevOpsDaysTokyo 2023 2023-6-14 Developer eXperience Day 2023 2024-3-14 JaSST'24 Tokyo

Software Outcome Delivery Architecture(SODA): prototype

Software Outcome Delivery Architecture(SODA): prototype 信頼されるロードマップを作るには

Software Outcome Delivery Architecture(SODA): prototype 継続的に成果を出し続けるには

39 Software Outcome Delivery Architecture(SODA): prototype ͥͻਐΊͯʂ ܦӦ૚΋ܭଌ݁ՌΛಡΉ εΩϧ͕ඞཁͩͶʂ ϓϩμΫτ૊৫Λʮܭଌʯͯ͠
վળͷख͕͔ΓΛ͔ͭΉΜͩͶ ՊֶతͰ͍͍Ͷʂ 40%"ߏ૝ͬͯͷΛߟ͑·ͨ͠ʂ ͥͻɺਐΊ͍ͤͯͩ͘͞͞ʂ ボス

40 Software Outcome Delivery Architecture(SODA): prototype ⾃組織を視座⾼く点検するためのアーキテクチャ。組織に⾜りない機能を実装したり、メンバーはもちろんマネジャー、経営層のアンラーニングにも役に⽴つ

Software Outcome Delivery Architecture(SODA): BizReach ver.

テーラリング Software Outcome Delivery Architecture(SODA): BizReach ver.

Software Outcome Delivery Architecture(SODA): BizReach ver.

45 SODA Project のデータソース

σʔλιϦϡʔγϣϯάϧʔϓ %4( ϦΫϧʔςΟϯάϓϩμΫτຊ෦ SODA Project のデータソース #JH2VFSZ ʢσʔλʔϙʔλϧʣ )3.04ϓϩμΫτຊ෦
#JH2VFSZ &5- μογϡϘʔυ

47 指標構造｜プロダクト下 - ３つの指標領域 ඼࣭ 2 ͱεϐʔυ % 開発進捗障害
։ൃνʔϜ パフォーマンス顧客満足度営業指標マーケティング指標市場占有率 ച্ 利益契約企業/HH数登録ユーザー数 6)4 求人数内定率入社人数レジュメ数応募数内定承諾率 ো֐਺ ো֐Ϩϕϧ %03"ϝτϦΫε ʢFourKeysͳͲʣ オンプロダクト指標スコープ 4 時間 % 予算 $ デリバリーの変更率進捗率スコープの達成率マイルストーン達成率人件費固定費開発ツール費 e-NPS パルスサーベイ DiSC （行動特性） ޻਺ 勤務年数 ϓϩμΫτ૊৫ͷコンディション開発チーム組成年齢性別 ౳ڃ ΤϯδχΞݸਓέΠύϏϦςΟ ίϛοτ਺ ฏۉίϛοταΠζ 13࡞੒਺ɾϚʔδ ਺ ίʔυߦ਺ ฏۉ13Ϋϩʔζ࣌ ؒ *TTVFUJDLFUΫϩʔ ζ਺ ඼࣭ 2 ͱεϐʔυ プロダクト開発指標アウトカムアウトカム指標は、３つの指標群（営業、マーケティング、プロダクト開発）により可視化できると考えています。

48 ((SODA))Evidence Viewer σϞϦʔν

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

計測の重要性：Opinion vs Fact（意⾒か事実か） Problem（問題） Solution（解決策） Fact（事実） Opinion（意⾒）設計デプロイ仮説を実装する
（改善活動）仮説を動かす（改善活動）結果を検証する仮説改善アプローチの仮説を⽴てる計測 (参考) https://slide.meguro.ryuzee.com/slides/78 吉⽻⿓太郎さん「カイゼンの基本」の図を変更仮説を⽴てるには、計測データを検証する必要がある。 SODA ⼤抵の組織ではこの「改善アプローチの仮説」を⽴てるスキルが不⾜している仮説改善アプローチの仮説を⽴てる

SPIへの原点回帰⽣産性よりチームの性能向上を⽬指す 51

52 ずっとエンジニア不⾜（引⽤）BizReach withHR 「IT⼈材不⾜の原因とは？現状や対策法、今後の⾒通しを解説」https://media.bizreach.biz/40991/ , 経済産業省「IT ⼈材需給に関する調査」を加⼯して作成

53 ずっとエンジニア不⾜（引⽤）BizReach withHR 「IT⼈材不⾜の原因とは？現状や対策法、今後の⾒通しを解説」https://media.bizreach.biz/40991/ , 経済産業省「IT ⼈材需給に関する調査」を加⼯して作成

54 ⽣産性とは（引⽤）経済産業省「IT ⼈材需給に関する調査」2019年3⽉, https://www.meti.go.jp/policy/it_policy/jinzai/houkokusyo.pdf

55 ⽣産性とは｢⽣産性とは⽣産諸要素の有効利⽤の度合いである｣ヨーロッパ⽣産性本部（1959年ローマ会議）（参考）BizReach withHR「労働⽣産性とは？【⾼める⽅法】計算式、種類、⽇本の現状」https://media.bizreach.biz/24663/

56 ⽣産性とは｢⽣産性とは⽣産諸要素の有効利⽤の度合いである｣（参考）BizReach withHR「労働⽣産性とは？【⾼める⽅法】計算式、種類、⽇本の現状」https://media.bizreach.biz/24663/ 原材料機械設備⼈

57 ⽣産性とは｢⽣産性とは⽣産諸要素の有効利⽤の度合いである｣（参考）BizReach withHR「労働⽣産性とは？【⾼める⽅法】計算式、種類、⽇本の現状」https://media.bizreach.biz/24663/ 原材料機械設備⼈ ←労働⽣産性

58 ⽣産性とは｢⽣産性とは⽣産諸要素の有効利⽤の度合いである｣（参考）BizReach withHR「労働⽣産性とは？【⾼める⽅法】計算式、種類、⽇本の現状」https://media.bizreach.biz/24663/ ⼈ ←労働⽣産性

59 ⽣産性とは｢⽣産性とは⽣産諸要素の有効利⽤の度合いである｣（参考）BizReach withHR「労働⽣産性とは？【⾼める⽅法】計算式、種類、⽇本の現状」https://media.bizreach.biz/24663/ ⼈ ←労働⽣産性⽣産性＝産出(output) ÷ 投⼊(input)
物的労働⽣産性:量付加価値労働⽣産性:質(利益) ＝⽣産量 ÷（労働者数 or 労働者数×労働時間）＝付加価値額 ÷（労働者数 or 労働者数×労働時間）

物的労働⽣産性:量付加価値労働⽣産性:質(利益) ＝⽣産量 ÷（労働者数 or 労働者数×労働時間）＝付加価値額 ÷（労働者数 or 労働者数×労働時間）開発⽣産性を語るうえで「測っても仕⽅がない」や「物的労働⽣産性の計測はアジャイル開発では危険」といった論調も。

物的労働⽣産性:量付加価値労働⽣産性:質(利益) ＝⽣産量 ÷（労働者数 or 労働者数×労働時間）＝付加価値額 ÷（労働者数 or 労働者数×労働時間）開発⽣産性を語るうえで「測っても仕⽅がない」や「物的労働⽣産性の計測はアジャイル開発では危険」といった論調も。⽣産性？ちょっと何⾔ってるか分からない

62 ⽣産性：宇宙事業で例えてみる物的労働⽣産性:量付加価値労働⽣産性:質(利益) 【メタファー】安定したロケットの打ち上げ宇宙で成し遂げたいなら「推⼒」を⼿に⼊れる【メタファー】宇宙でのミッション、惑星探査⽉⾯基地の建設、⽕星旅⾏

ロケットを打ち上げれないと（量）ミッションは実現できない（質）

重さ1tのロケットに必要な推⼒は 1t以上(約9.8kN)の推⼒が必要（ちなみにH3ロケットの総重量は575t、個体ロケットブースタの真空中推⼒は2300kN）

65 Elite High Medium Low 変更リードタイム 1⽇未満 1⽇以上1週間未満 1週間以上 1週間以上
デプロイ頻度 1⽇に複数回（5回/週以上）週に1回以上（1回/週以上、5回/週未満）⽉1回以上（1回/⽉以上、1回/週未満）⽉1回以上（1回/⽉以上、1回/週未満）デプロイ失敗からの回復時間 1時間未満 1⽇未満 1⽇〜1週間未満 1週間〜変更失敗率 5% (0〜7.5％未満) およそ10% （7.5%以上12.5%未満）およそ15% （12.5%以上17.5%未満）およそ20%〜（17.5%以上） The Accelerate State of DevOps Report 2023 より ※カッコ内は弊社の解釈 Four Keys は「推⼒」を計れる

デプロイ頻度 1⽇に複数回（5回/週以上）週に1回以上（1回/週以上、5回/週未満）⽉1回以上（1回/⽉以上、1回/週未満）⽉1回以上（1回/⽉以上、1回/週未満）デプロイ失敗からの回復時間 1時間未満 1⽇未満 1⽇〜1週間未満 1週間〜変更失敗率 5% (0〜7.5％未満) およそ10% （7.5%以上12.5%未満）およそ15% （12.5%以上17.5%未満）およそ20%〜（17.5%以上） The Accelerate State of DevOps Report 2023 より ※カッコ内は弊社の解釈 Four Keys は「推⼒」を計れる開発のパフォーマンス(性能)・レベル

デプロイ頻度 1⽇に複数回（5回/週以上）週に1回以上（1回/週以上、5回/週未満）⽉1回以上（1回/⽉以上、1回/週未満）⽉1回以上（1回/⽉以上、1回/週未満）デプロイ失敗からの回復時間 1時間未満 1⽇未満 1⽇〜1週間未満 1週間〜変更失敗率 5% (0〜7.5％未満) およそ10% （7.5%以上12.5%未満）およそ15% （12.5%以上17.5%未満）およそ20%〜（17.5%以上） The Accelerate State of DevOps Report 2023 より ※カッコ内は弊社の解釈 Four Keys は「推⼒」を計れる開発のパフォーマンス(性能)・レベル ©JAXA

信頼・対価(売上) 68 ⽣産性よりチームの性能向上を⽬指す顧客プロダクト・サービス提供継続事業会社アウトカム向上

信頼・対価(売上) 69 ⽣産性よりチームの性能向上を⽬指す顧客プロダクト・サービス提供継続アウトカム向上チームの性能を上げる！

70 ⽣産性よりチームの性能向上を⽬指す組織のソフトウェアデリバリのケイパビリティ（能⼒・機能）は、組織に競争上の優位性をもたらすソフトウェアのデリバリのパフォーマンス組織全体のパフォーマンス⾮営利部⾨のパフォーマンス
* Forsgren, N., Humble, J., & Kim, G. (2018). LeanͱDevOpsͷՊֶ [Accelerate: The Science of Lean Software and DevOps] (෢ࣷ޿޾ & ෢ࣷΔΈ, ༁). ΠϯϓϨε. (ग़൛೥2018೥11݄21೔). p.32, ਤ2.4.

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

Keys 27のケイパビリティ統計的相関（参考）Google Cloud. ” Explore DORA's research program”. Google Cloud. https://www.devops-research.com/research.html. (参照 2023-1-10) σϞϦʔν

Keys 27のケイパビリティ統計的相関（参考）Google Cloud. ” Explore DORA's research program”. Google Cloud. https://www.devops-research.com/research.html. (参照 2023-1-10) σϞϦʔν 推⼒

Keys 27のケイパビリティ統計的相関（参考）Google Cloud. ” Explore DORA's research program”. Google Cloud. https://www.devops-research.com/research.html. (参照 2023-1-10) σϞϦʔν 推⼒我々は、⽣産性よりチームの性能向上を⽬指す SPI活動を実践してきました

Stream-aligned team Platform team Enabling team Complicated Subsystem team Collaboration
Fundamental Team Types Team Interaction Modes XaaS Facilitating 6OEFGJOFE5FBN5ZQF Supplementary Team Types SPIへの原点回帰 , M., , M., , , & . (2021). . .

Stream-aligned team Platform team Enabling team Complicated Subsystem team Fundamental
Team Types SPIへの原点回帰 , M., , M., , , & . (2021). . . ビジネスドメインの特定の領域に密接に関連した作業の流れに沿って配置される。主な⽬的は、エンドユーザーに価値を直接的に提供する製品やサービスに焦点を当てることである。⽐較的⾃⼰管理的であり、少ない依存関係で迅速に変更を⾏えるよう設計されている。⾼度な技術的専⾨知識を要する複雑なシステムやコンポーネントを開発する責任を担う。作業には⾼度な数学、計算、またはその他の専⾨的技術が必要であり、その専⾨性のために他のチームと区別される。内部で使⽤される製品やサービスを開発し、これによって他のストリームアラインドチームがより迅速に価値を提供できるようにすることを⽬指す。基盤となるプラットフォームやツール、共通のサービスを提供し、これによって他のチームがその上に構築することができるようにする。 Stream-aligned team が直⾯する技術的な「阻害要因」を克服することを⽬的とする。新しい技術や⽅法論の導⼊を⽀援し、必要なスキルや能⼒がチーム内で開発されるよう促す。このチームは他のチームが⾃⼰完結できるようになるまでの⼀時的または短期的な⽀援を提供することが多い。

Stream A Stream B Platform V 'MPXPGDIBOHF SPI Enabling team
78 SPIへの原点回帰 Stream- aligned team SPI Enabling team Stream- aligned team SPI Enabling team Stream- aligned team SPI Enabling team XaaS Stream-aligned team が直⾯する技術的な「阻害要因」を克服することを⽬的とする。新しい技術や⽅法論の導⼊を⽀援し、必要なスキルや能⼒がチーム内で開発されるよう促す。このチームは他のチームが⾃⼰完結できるようになるまでの⼀時的または短期的な⽀援を提供する SPI Enabling team とはソフトウェアプロセス改善（SPI：Software Process Improvement）という⼿法を⽤いて、ソフトウェア開発の効率性、品質、パフォーマンスを向上させる技術や⽅法論の導⼊を⽀援する

PdM Enabling team QA Enabling team 79 SPIへの原点回帰 SPI Enabling
team SODAイネーブルメントでスキル、ツール、プロセス、システムの使⽤を向上を促す

80 SPIへの原点回帰 • 問題の形成⼒：⼤局的に現象を把握し仮説を組み⽴て対策を考える⼒ • 問題の解決⼒：最後までやりきる⼒（GRIT） • これらのスキルを⾝につけるには時間がかかりますが、多くの開発チームや改善担当者にはこれが不⾜しています。そのため、プロセス改善の専⾨家で構成されるSPI Enabling
team の構築は、このギャップを埋めるための重要な戦略になります。 SPIを成功させるには2つのメタスキルが必要 Stream- aligned team SPI Enabling team Stream- aligned team SPI Enabling team Stream- aligned team SPI Enabling team XaaS Enabling team は他のチームが⾃⼰完結できるようになるまでの⼀時的または短期的な⽀援を提供する

ソフトウェアプロセス改善について SPI:Software Process Improvement 81

82 ソフトウェア開発は建築に似ている？ ࣅ͍ͯͳ͍ɻେن໛։ൃ͸ͱ͖ʹϏϧݐઃฒͷ༧ࢉͱ࣌ ͕͔͔ؒΔ͕ݐஙͷΑ͏ʹ෦ࡐͻͱͭɺωδͻͱͭʹ ͖ͬͪΓͱͨ͠+*4ن͕֨͋ΔΘ͚Ͱ͸ͳ͍ɻ ΤϯδχΞϦϯά 㱠ιϑτ΢ΣΞɾΤϯδχΞϦϯάɻ ιϑτ΢ΣΞ։ൃ͸ݐஙʹൺ΂Ε͹ࣗ༝౓͕ߴ͗͢Δɻ

ࣅ͍ͯΔΑ͏Ͱࣅ͍ͯͳ͍ɻಠ૑ੑ͸େࣄͰ͋ΓͦΕ͕ Πϊϕʔγϣϯʹܨ͕Δ͜ͱ͸͋Δɻ͔͠͠ɺզʑͷ ΰʔϧ͸ސ٬ͷࠔͬͨ͜ͱΛղܾ͠ɺ͓ۚΛѻ͍ɺ๏཯ Λ९क͢Δͱ͍ͬͨ͞·͟·ͳ੍໿ʹറΒΕ͍ͯΔɻ ιϑτ΢ΣΞ։ൃ͸ܳज़ͱҧ͍ෆ࣮֬ੑ͕ߴ͍ɻ 83 ソフトウェア開発は芸術に似ている？

ࣅ͍ͯΔɻऴΘΒͳ͍8FCܥ։ൃ͸೔ʑͷ৯୎ͷΑ͏ɻϓϩμΫτʹఆظతʹՁ஋ Λ࡞ΓࠐΉखஈ͕ιϑτ΢ΣΞ։ൃɻ೔ʑͷ৯ࣄʹՁ஋Λ༩͑Δͷ͕ྉཧɻ ྉཧਓ͸ϨγϐͳΜ͔ݟͳ͍͠෼ྔ΋ଌΒͳ͍͕ඒຯ͍͠ྉཧΛ࡞ΕΔɻ͔͠͠ɺ ࠶ݱੑ͕ඞཁʹͳΕ͹Ϩγϐ͸େࣄɻϨγϐͲ͓Γ࡞ͬͯ΋ࣦഊ͢Δ͜ͱ͸͋Δɻ ՈఉྉཧͱϑΝϛϨεɺߴڃྉཧళͱͰ͸ɺίετ΋ΦϖϨʔγϣϯ͸ҧ͏ɻ ͦͯ͠ඒຯͯ͘͠΋ྲྀߦΒͳ͍ళ΋͋Δʜʜ 84 ソフトウェア開発は料理に似ている？

85 ソフトウェアプロセス改善(SPI)とは何か？料理ソフトウェア開発料理研究家ソフトウェアプロセス改善 (SPI)専⾨家 ݚڀɾ஁࿉ ݚڀɾ஁࿉ ࣅ͍ͯΔ
ྉཧͷੈքͰ͸ʮྉཧݚڀՈʯͱ͍͏ਓͨ ͕͍ͪΔɻ ࣌୅ͷมԽͱڞʹੜ׆༷͕ࣜมΘ͍ͬͯ͘ தͰɺʮྉཧݚڀՈʯ͸ͦͷ࣌୅ʹ͋ͬͨ ྉཧΛ೔ʑݚڀ͠ɺϨγϐΛ։ൃͨ͠Γ఻ ঝʹྭΜͰ͍Δɻ ιϑτ΢ΣΞ։ൃͷੈքͰ΋ʮϓϩηεվ ળίʔνɾΞδϟΠϧίʔνʯͱݴΘΕΔ ਓ͕͍ͨͪΔɻ ςΫϊϩδʔͷਐԽͱϏδωεมԽͷε ϐʔυʹ߹Θͤιϑτ΢ΣΞͷ։ൃ΋ม Θ͍ͬͯ͘ɻιϑτ΢ΣΞϓϩηεվળ 41* ઐ໳Ո͸༷ʑͳݱ৔ʹ͋ͬͨ࠷దͳϓ ϩηε΍νʔϜ΁ͷΞϓϩʔνΛ೔ʑݚڀ ͠ɺϑϨʔϜϫʔΫΛݚڀͨ͠Γ࣮ફʹྭ ΜͰ͍Δɻ ࣅ͍ͯΔ

86 ソフトウェアプロセス改善(SPI)とは何か？料理ソフトウェア開発料理研究家ソフトウェアプロセス改善 (SPI)専⾨家 ݚڀɾ஁࿉ ݚڀɾ஁࿉ ࣮ફɾ఻ୡ
Πωʔϒϧϝϯτ ⽇本の⾷卓を変える⽇本⼈のくらしを変えるケイパビリティ獲得を促し、チームの性能向上を⽬指す ࣅ͍ͯΔ ࣅ͍ͯΔ

87 ソフトウェアプロセス改善(SPI)とは何か？ 1. 優れたソフトウェアプロセスの要素が、優れたやり⽅で定義できること 2. ソフトウェア開発への既存の組織的アプローチが、これらの要素と照らし合わせて診断できること
3. 改善のための有意な戦略を定義できること ࣮ફιϑτ΢ΣΞΤϯδχΞϦϯά<ୈ൛>3PHFS41SFTTNBOɾ#SVDF3.BYJNஶ ΑΓҾ༻

ソフトウェアプロセス改善(SPI)とは何か？ ϘτϜΞοϓͰࣦഊ͢Δྫ ϏδωεΰʔϧΛܾΊͯऔΓ૊Ήͱ .BSZ&1PUUFS /FJM44BLSZ .BLJOH1SPDFTT*NQSPWFNFOU8PSL"$PODJTF"DUJPO(VJEFGPS4PGUXBSF.BOBHFSTBOE1SBDUJUJPOFST64"EEJTPO8FTMFZ1SPGFTTJPOBM ࠨͷྫͰ͸ɺΰʔϧΛܾΊͣʹϓϩηεத৺ͷΞϓϩʔνΛͱࣦͬͯഊ͢Δྫɻ ӈͷྫͰ͸ɺΰʔϧʹ޲͔ͬͯΏ͘աఔͰ໰୊͕ൃੜ͢Δ෦෼ʹ͍ͭͯɺ ϓϩηεվળͷΞϓϩʔνΛద༻͢Δɺϓϩηεվળͷ੒ޭྫΛ͍ࣔͯ͠·͢ɻ

89 ソフトウェアプロセス改善(SPI)とは何か？ IDEALモデル変化への刺激変化背景の確認スポンサーシップ確立活動体制
の構築現状と理想像の記述勧告の策定優先順位の設定アプローチの策定行動の計画解決策の作成先行評価/ 試行の実施解決策の改良解決策の実施分析と検証 Initiating 開始 Diagnosing 診断 Establishing 確立 Acting 行動 Learning 学習 1 2 3 4 0 将来活動を提案 IDEALモデル

90 ソフトウェアプロセス改善(SPI)とは何か？ IDEALモデル変化への刺激変化背景の確認スポンサーシップ確立活動体制
の構築現状と理想像の記述勧告の策定優先順位の設定アプローチの策定行動の計画解決策の作成先行評価/ 試行の実施解決策の改良解決策の実施分析と検証 Initiating 開始 Diagnosing 診断 Establishing 確立 Acting 行動 Learning 学習 1 2 3 4 0 将来活動を提案 SODA構想 IDEALモデル

91 ソフトウェアプロセス改善(SPI)とは何か？廻るSPI 診断フェーズ確⽴フェーズ⾏動フェーズ学習フェーズ 1 2 3
4 開発チームの体⼒や筋⼒のレベルを評価する • ((SODA)) Evidence Viewer で開発パフォーマンス（Four Kyes）やアウトカム指標などを確認。ケイパビリティ・データを対⽐させ改善が必要な箇所を把握する。開発チームの筋トレ計画を⽴てる • 診断フェーズで得られた結果に基づいて、プロセス改善活動の優先順位と取り組み⽅を策定し、具体的な改善計画を作成する。改善計画はSPIが⽀援。実際に筋トレを開始する • 確⽴フェーズで作成された改善計画に従って解決策を作り、その先⾏評価・試⾏・パッケージ化・展開・⻑期⽀援移⾏を実施する。効果を評価し、必要に応じて計画を調整する • ⾏動フェーズの結果を受けて、これまでの活動を分析してその妥当性を確認し、次のサイクルの準備を⾏う。 • 診断フェーズに戻る

SPIはDevOps時代に合っているのか? 古い？新しい？ 92

93 SPIはDevOps時代に合っているのか? • SPI活動の起源はSW-CMMの実装を⾏うための改善活動 • SPI活動を専⾨⾏うグループをEPG(Engineering Process Group)またはSEPG(Software Engineering Process
Group)と呼んだ • ⽇本では2002年4⽉に⽇本SPIコンソーシアムが発⾜ https://www.jaspic.org/ • 初めはSW-CMMの⽇本語訳ならびに研究、普及を⽬的としていた • 「Σ計画」の失敗を繰り返さないために設⽴されたとも⾔われている • 現在はソフトウェアプロセスの改善（SPI）およびSPIに伴うプロセス評価（SPA）に関する研究、技術移転、普及活動、国際交流などを⾏っている • SW-CMM • SW-CMMはCMMIに統合され、V1.3（2010）までは Carnegie Mellon⼤学の Software Engineering Institute (SEI)が管理していた。2012年以降は新たに⽴ち上げた研究所 CMMI Institute へ移管 • 2016年、CMMI Institute はISACAに買収される。2018年3⽉にV2.0をリリース • V1.3までは⽶国防省がスポンサーであったこともあり⼤抵のドキュメントは無料で⼊⼿できていたが、ISACA買収後はすべて有料となっている（⾮営利団体ではあるが独⽴採算制） CMMとかSEPGを知っていますか？

94 プロセス改善アプローチ⽬的に有効な“能⼒あるいは機能”を特定し続け、それらを組織的に伸ばし改善を⽬指すモデル •CMMの成熟度モデル成熟のステップを定義し、段階を追って⾼レベルの達成を⽬指すモデル •DORAのケイパビリティモデルテクノロジーやビジネスをめぐる状況が絶えず変化する時代では「成熟度」よりも「ケイパビリティ」(できること)
を増やすほうが良い IUUQBQQGVKJRSFTPSUTDPNGVKJUP[BOLOPXMFEHFQBHFFRVJQNFOU NPEFQD https://learn.microsoft.com/en-us/azure/devops/boards/work- items/guidance/cmmi/guidance-background-to-cmmi?view=azure-devops

95 プロセス改善アプローチ⽬的に有効な“能⼒あるいは機能”を特定し続け、それらを組織的に伸ばし改善を⽬指すモデル •CMMの成熟度モデル成熟のステップを定義し、段階を追って⾼レベルの達成を⽬指すモデル •DORAのケイパビリティモデルテクノロジーやビジネスをめぐる状況が絶えず変化する時代では「成熟度」よりも「ケイパビリティ」(できること)
を増やすほうが良い IUUQBQQGVKJRSFTPSUTDPNGVKJUP[BOLOPXMFEHFQBHFFRVJQNFOU NPEFQD https://learn.microsoft.com/en-us/azure/devops/boards/work- items/guidance/cmmi/guidance-background-to-cmmi?view=azure-devops 「LeanとDevOpsの科学［Accelerate］」では、暗にCMMIを否定しています。確かに、CMMIの数ヶ⽉単位で時間がかかるレベル判定作業に疲弊したり、レベルを維持できずプロセス改善が形骸化する組織をいくつも⾒てきました。⼀⽅で、DORAが提唱する27のケイパビリティモデルには既視感を覚えます。CMMIのケイパビリティモデルをDevOps向けにモダンにしたように⾒えなくもありません。また、成熟度ではありませんが、Four Keys には Elite、High、Middle、Low のレベル属性があります。

Keys 27のケイパビリティ統計的相関（参考）Google Cloud. ” Explore DORA's research program”. Google Cloud. https://www.devops-research.com/research.html. (参照 2023-1-10) σϞϦʔν 推⼒

97 DORA Metrics 技術プロセス組織⽂化バージョン管理チームのツール選択のサポートチームの実験
システムをモニタリングしてビジネス上の意思決定に役⽴てる仕事の満⾜度トランクベース開発テストデータ管理変更承認の効率化障害の予兆通知 Westrumの組織類型継続的インテグレーションセキュリティのシフトレフト顧客からのフィードバック仕掛かり制限学習⽂化デプロイの⾃動化データベースのチェンジマネジメントバリューストリームでの作業の可視性ビジュアル管理変⾰型リーダーシップ継続的なテストクラウドインフラストラクチャ⼩さいバッチ単位の作業継続的デリバリーコードの保守性疎結合なアーキテクチャモニタリングとオブザービリティ ݱࡏͷέΠύϏϦςΟ͕ެ։͞Ε͍ͯΔ IUUQTDMPVEHPPHMFDPNBSDIJUFDUVSFEFWPQTDBQBCJMJUJFT IMKB

98 DORA Metrics 技術プロセス組織⽂化バージョン管理チームのツール選択のサポートチームの実験
システムをモニタリングしてビジネス上の意思決定に役⽴てる仕事の満⾜度トランクベース開発テストデータ管理変更承認の効率化障害の予兆通知 Westrumの組織類型継続的インテグレーションセキュリティのシフトレフト顧客からのフィードバック仕掛かり制限学習⽂化デプロイの⾃動化データベースのチェンジマネジメントバリューストリームでの作業の可視性ビジュアル管理変⾰型リーダーシップ継続的なテストクラウドインフラストラクチャ⼩さいバッチ単位の作業継続的デリバリーコードの保守性疎結合なアーキテクチャモニタリングとオブザービリティ ݱࡏͷέΠύϏϦςΟ͕ެ։͞Ε͍ͯΔ IUUQTDMPVEHPPHMFDPNBSDIJUFDUVSFEFWPQTDBQBCJMJUJFT IMKB 「LeanとDevOpsの科学」には次のような⼀節がある。 “忘れないでほしいのは、「ハイパフォーマンス」とは購⼊したり、真似したりできるものではないという点である。⾃⾝のケイパビリティを⾼めつつ、⾃チームや⾃組織の現状や⽬標にしっくりくる道を模索する必要がある。そしてこれには、絶え間ない努⼒、投資、集中、時間を要する。” Forsgren, N., Humble, J., & Kim, G. (2018). LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活⽤が組織変⾰を加速する (武舎広幸 & 武舎るみ, Trans.). impress top gear. (Original work published 2018). p. 233.

改善事例 99

Four Keys 測れませんっ!! 事例① 100

101 【事例①】Four Keys 測れませんっ!! メトリクス DORAの定義いざ測ろうとしたら…… 変更リードタイムコードがコミットされてから本番環境で正常に実⾏されるまでの時間
1. 複数チームで同⼀リポジトリを使っていて、チーム毎にデータ収集できない 2. リポジトリが複数あって、それぞれにブランチ戦略が異なる 3. ブランチ戦略が複雑で収集後のデータ加⼯が⼤変…… デプロイ頻度コードを本番環境にデプロイまたはエンドユーザーにリリースした頻度デプロイ失敗からの回復時間サービスインシデントまたは不具合が発⽣したときにサービスの復元にどれくらいの時間がかかるか 1. 障害管理ツールを変更したら⽇付フィールドしかなく、デプロイ失敗からの回復時間を計測できない 2. 障害のエビデンスはあるが、計測可能な状態になっていない（テキスト）変更失敗率本番環境に変更を加えた、またはユーザーへのリリースを実施した結果サービスが低下し、その後修正を⾏う必要が⽣じた割合

102 【事例①】Four Keys 測れませんっ!! • 予定のなかった計測を意識した運⽤はもちろんムリ • 計画されないものは実⾏されない • JiraにせよGitHubにせよ、そもそもルールがなければあっというまに無法地帯
• 繰り返される歴史。チームに運⽤をまかせると、あまり良い結果にはならない • 最低限のガイドラインは横断的に⾒ているEnabling teamが決めると良い • 計測はカトラリールール。プロジェクトの計画に「計測」を組み込む（前提もしくは制約） • 管理ツールを計測可能な形式に整える • 幸いなことに、これから開発が始まる場合は、計測を意識した運⽤になってきている計測はカトラリールール外から順に！ https://www.foods-labo.net/page-special.php?special_id=2260

地図のない旅事例② 103

Case B： •レガシーで稼働していたシステムの移植を実施すること。 •「作り変えなので同じ仕様で」と⾔われた。 •時間が経つにつれ、仕様を把握しているひとが居ないことに気づく •また、せっかく作り直すなら、今より良くしたほうが良いのではと思うものの、スケジュールの全体感が掴めず躊躇している。
Case A： •チームは共通コンポーネントの開発をしている。他チームから様々要望を受け、振り回されている。 •カンバンボードでタスク管理をしてるが、それ以外ではロードマップしかない。 •タスクの優先順位が判断できず、来たものから逐次こなしている……ので常に忙しい。 •これで良いのだろうか？ 104 【事例②】地図のない旅ライトは当てたところしか⾒えない…… 双⼦は似ているけど同じではない…

③イテレーション 3 ③イテレーション n ④イテレーション計画 ⑥フィーチャーA (⑤ユーザー・ストーリー2) ⑥フィーチャーB (⑤ユーザー・ストーリー3) ⑥フィーチャーC (⑤ユーザー・ストーリー4) ⑥フィーチャーD (⑤ユーザー・ストーリー5) ⑦タスクA ⑦タスクB ⑦タスクC ⑦タスクD 5時間 8時間 4時間 12時間 nプロダクト・ビジョンが①プロダクト・ロードマップを導く n①プロダクト・ロードマップが②リリース計画を導く n②リリース計画が③イテレーションを設定する n④イテレーション計画がフィーチャー開発のスケジュールを設定する n⑤ユーザー・ストーリーによって提供される優先順位の付いた⑥フィーチャー（ストーリーポイントで⾒積もられる) n⑤ユーザー・ストーリーを提供するために作成された⑦タスク(時間単位で⾒積もられる) ⑥フィーチャーA (⑤ユーザー・ストーリー1) 【事例②】地図のない旅 ①プロダクト・ロードマップ SP 5 SP 8 SP 3 SP 5 SP 8 （参考）PMBOKガイド第7版の図2-17 を加⼯して作成欲しいレベルの地図

リリース1 5/31 リリース2 7/19 リリース3 9/15 ②リリース計画 ③イテレーション 0 ③イテレーション
1 ③イテレーション 2 ③イテレーション 3 ③イテレーション n ④イテレーション計画 ⑥フィーチャーA (⑤ユーザー・ストーリー2) ⑥フィーチャーB (⑤ユーザー・ストーリー3) ⑥フィーチャーC (⑤ユーザー・ストーリー4) ⑥フィーチャーD (⑤ユーザー・ストーリー5) ⑦タスクA ⑦タスクB ⑦タスクC ⑦タスクD 5時間 8時間 4時間 12時間 ⑥フィーチャーA (⑤ユーザー・ストーリー1) 【事例②】地図のない旅 ①プロダクト・ロードマップ SP 5 SP 8 SP 3 SP 5 SP 8 マネジャーの頭の中ではイメージされてたりするのだが…… 欲しいレベルの地図

リリース1 5/31 リリース2 7/19 リリース3 9/15 ⑦タスクA ⑦タスクB ⑦タスクC ⑦タスクD
5時間 8時間 4時間 12時間【事例②】地図のない旅 ①プロダクト・ロードマップ ⑦タスクE ⑦タスクF ⑦タスクG ⑦タスクH 2時間 10時間 4時間 12時間 ⑦タスクI ⑦タスクJ ⑦タスクK ⑦タスクL 10時間 8時間 20時間 12時間 ⑦タスクM ⑦タスクN ⑦タスクO ⑦タスクP 15時間 20時間 30時間 35時間メンバーには、こんな感じで伝わってしまう

リリース1 5/31 リリース2 7/19 リリース3 9/15 ⑦タスクA ⑦タスクB ⑦タスクC ⑦タスクD
5時間 8時間 4時間 12時間【事例②】地図のない旅 ①プロダクト・ロードマップ ⑦タスクE ⑦タスクF ⑦タスクG ⑦タスクH 2時間 10時間 4時間 12時間 ⑦タスクI ⑦タスクJ ⑦タスクK ⑦タスクL 10時間 8時間 20時間 12時間 ⑦タスクM ⑦タスクN ⑦タスクO ⑦タスクP 15時間 20時間 30時間 35時間メンバーには、こんな感じで伝わってしまうリリース日、なんでそこなんだろう…… 〇〇機能はスコープに含まれる？先が見えないなぁなんでこのタスク順番なんだっけ？誰がどのタスクやるんだ…やりきれるのか？

109 【事例②】地図のない旅 • 「同じ仕様」と⾔われても実はメンバーそれぞれの知っている範囲、理解は異なっている • 「☓☓は◯◯だよね？！」「あれ、そうだった？」。どこにもドキュメントがなーい！現⾏システムを動作させて確認する・・・。 • ざっくり何ができるかはわかるが、詳細になるとみんな違うことを⾔う
（引⽤）https://agilewarrior.wordpress.com/2010/11/06/the-agile-inception-deck/

110 【事例②】ユーザーストーリーマッピングまず、⽴ち⽌まる関係者間での対話を作り出す最初は時間かかるが、共通理解が⽣まれると前に進む（引⽤）https://agilewarrior.wordpress.com/2010/11/06/the-agile-inception-deck/

111 【事例②】ユーザーストーリーマッピング • 以下の3つを同時に⾒える化する • 【ワークフロー】【プロダクトの設計】【リリース計画】（引用）Jeff Patton著川口恭伸
監訳長尾高弘訳『ユーザーストーリーマッピング』

リリース1 5/31 リリース2 7/19 リリース3 9/15 ②リリース計画 ③イテレーション 0 ③イテレーション
1 ③イテレーション 2 ③イテレーション 3 ③イテレーション n ④イテレーション計画 ⑥フィーチャーA (⑤ユーザー・ストーリー2) ⑥フィーチャーB (⑤ユーザー・ストーリー3) ⑥フィーチャーC (⑤ユーザー・ストーリー4) ⑥フィーチャーD (⑤ユーザー・ストーリー5) ⑦タスクA ⑦タスクB ⑦タスクC ⑦タスクD 5時間 8時間 4時間 12時間 ⑥フィーチャーA (⑤ユーザー・ストーリー1) 【事例②】ユーザーストーリーマッピング ①プロダクト・ロードマップ SP 5 SP 8 SP 3 SP 5 SP 8 ゴールまでの進み⽅がわかった優先順位の⾼いものから完成させるぞー！リリース1で◯◯ ができるようになるね

⽣産性のパラドックス事例③ 113

114 【事例③】⽣産性のパラドックス機能を作ることばかりに集中してしまうことをビルドトラップと⾔いますが…… 顧客機能A 機能B 機能C 機能D 事業会社

115 【事例③】⽣産性のパラドックス Scrumを導⼊しチームはがんばっているのにパフォーマンスが低い顧客事業会社ほぼ無⾵

116 【事例③】⽣産性のパラドックス • 情報技術の導⼊が進むにつれて、⽣産性が期待されるほど向上しない、あるいは場合によっては低下する現象を指す。1980年代にこの語が広まり、特にオフィスの⾃動化やコンピュータ技術の急速な発展に伴う⽣産性の停滞が問題とされた。 • 経済学者のロバート・ソローは、「コンピュータの⽣産性効果は⾄る所で⾒られるが、統計数字には現れない」と述べ、このパラドックスを端的に表現している。 •
このパラドックスの原因は多岐にわたる。⼀つは、新技術の導⼊初期において、従業員がその技術を習得し、効果的に活⽤するまでに時間が必要であるため、短期間での⽣産性向上が⾒込めないことがある。また、技術導⼊に伴うコストが初期の⽣産性向上を上回る場合もある。さらに、新技術のポテンシャルを最⼤限に活⽤するための組織やプロセスの改⾰が伴わない場合、その効果が限定的になることも指摘されている。 • したがって、「Productivity Paradox」は、単に新技術を導⼊するだけでは不⼗分であり、その技術を最⼤限に活⽤するための戦略的なアプローチが必要であることを⽰唆している。 Productivity Paradox (Solow paradox)

117 【事例③】⽣産性のパラドックス開発⽣産性が期待よりも低いと、次のような疑念が囁かれはじめたスクラムだから遅い会議が多すぎる人員配置がうまくないのかなぁ？ 1on1が多すぎ
では？えらい⼈

118 【事例③】⽣産性のパラドックス開発⽣産性が期待よりも低いと、次のような疑念が囁かれはじめたスクラムだから遅い会議が多すぎる人員配置がうまくないのかなぁ？ 1on1が多すぎ
では？えらい⼈これらは印象では？

119 【事例③】⽣産性のパラドックス変更リードタイムデプロイ頻度デプロイ失敗からの回復時間変更失敗率信頼性（可⽤性） Four Keys
27のケイパビリティ統計的相関（参考）Google Cloud. ” Explore DORA's research program”. Google Cloud. https://www.devops-research.com/research.html. (参照 2023-1-10) しかし、 Four Keys はこの印象を打ち消すメトリクスではない

120 【事例③】エビデンスベースドマネジメント（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)

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

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

123 【事例③】 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)

124 【事例③】 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)

125 【事例③】 EBMの重要価値指標（KVM）の例 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)

126 【事例③】 EBMの重要価値指標（KVM）の例 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)

127 【事例③】時間の使い⽅に問題がありそう同時に複数のタスクを進めている作業はしている！しかしどれも終わらない

128 【事例③】時間の使い⽅に問題がありそう同時に複数のタスクを進めている頻繁に会議がはいる作業はしている！しかしどれも終わらない頻繁に作業が中断する

129 【事例③】時間の使い⽅に問題がありそう同時に複数のタスクを進めている頻繁に会議がはいる Slackでの問合わせや調査依頼が毎⽇何件もくる作業はしている！しかしどれも終わらない頻繁に作業が中断する
割り込み作業が発⽣する

130 【事例③】時間の使い⽅に問題がありそう同時に複数のタスクを進めている頻繁に会議がはいる Slackでの問合わせや調査依頼が毎⽇何件もくる作業はしている！しかしどれも終わらない頻繁に作業が中断する
割り込み作業が発⽣するプロダクト開発に集中する時間がとれない迅速なデリバリーが出来ない

131 【事例③】 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.

132 【事例③】 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.

133 【事例③】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.

134 【事例③】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.

Four Keysでは⾒えないところ事例④ 135

136 【事例④】Four Keysでは⾒えないところ • 変更リードタイムの⻑いチームがあった • ケイパビリティ調査では「プロセス」カテゴリ全体的に低かった • エセ⾃⼰組織化に陥っていた https://speakerdeck.com/visional_engineering_and_design/number-rsgt2023

DevOps Four Keys 137 【事例④】Four Keysでは⾒えないところリードタイム変更リードタイム変更失敗率デプロイ失敗からの
回復時間デプロイ頻度信頼性企画計画実装テストデプロイ運⽤設計障害〜復旧変更リードタイムを向上させるためには、プロダクト開発全体の仕事の流れを理解する必要がある

138 【事例④】現状を⾒えるようにする DanielPenfield, CC BY-SA 3.0 <https://creativecommons.org/licenses/by-sa/3.0>, via Wikimedia Commons

139 【事例④】現状を⾒えるようにする • Value Stream Mapping • 製品が顧客に届くまでの「もの」と「仕事」の流れを可視化したもの • プロダクト開発関係者でお客様にプロダクトが届くまでのプロセスを明らかにし、
現状認識を揃える

140 【事例④】ボトルネックを発⾒する可視化の⽬的 1. 共通認識を形成する 2. ボトルネックを発⾒する 3. ボトルネックをカイゼンする 4.
リードタイムを短縮する= フロー効率の向上 ϘτϧωοΫ ྲྀΕ͕ѱ͘ͳΔͱ͜Ζ This is Lean: Resolving the Efficiency Paradoxʢ Niklas Modig (ஶ), Par Ahlstrom (ஶ), Rheologica Publishing, 2012ʣ

141 【事例④】ボトルネックを発⾒する 7つのムダ 1. つくり過ぎのムダ 2. ⼿待ちのムダ 3. 運搬のムダ 4.
加⼯のムダ 6. 動作のムダ 7. 不良をつくるムダ 5. 在庫のムダ例使わない機能をつくる承認待ちで開発作業にはいれない他チーム、他部⾨へ引き継ぎをする不要な成果物を作成する同時に複数のタスクに着⼿する不要な作業をおこなう不具合の修正をする τϤλੜ࢈ํࣜ-୤ن໛ͷܦӦΛ໨ࢦͯ͠-ʢ େ໺଱Ұ (ஶ), μΠϠϞϯυࣾ, 1978ʣ

142 【事例④】ボトルネックをカイゼンする 02:Combine 03:Rearrange 04:Simplify 01:Elimate ΍ΊΔ ݁߹ ೖΕସ͑ ؆ૉԽ

中間成果物を探せ！事例⑤ 143

③イテレーション 3 ③イテレーション n ④イテレーション計画 ⑥フィーチャーA (⑤ユーザー・ストーリー2) ⑥フィーチャーB (⑤ユーザー・ストーリー3) ⑥フィーチャーC (⑤ユーザー・ストーリー4) ⑥フィーチャーD (⑤ユーザー・ストーリー5) ⑦タスクA ⑦タスクB ⑦タスクC ⑦タスクD 5時間 8時間 4時間 12時間 nプロダクト・ビジョンが①プロダクト・ロードマップを導く n①プロダクト・ロードマップが②リリース計画を導く n②リリース計画が③イテレーションを設定する n④イテレーション計画がフィーチャー開発のスケジュールを設定する n⑤ユーザー・ストーリーによって提供される優先順位の付いた⑥フィーチャー（ストーリーポイントで⾒積もられる) n⑤ユーザー・ストーリーを提供するために作成された⑦タスク(時間単位で⾒積もられる) ⑥フィーチャーA (⑤ユーザー・ストーリー1) プロダクト・ロードマップと計画の関連図 ①プロダクト・ロードマップ SP 5 SP 8 SP 3 SP 5 SP 8 （参考）PMBOKガイド第7版の図2-17 を加⼯して作成どうやって⾒積もるか？機能や過去の経験に基づいて⾒積もると成果物のことを忘れがち。

145 【事例⑤】中間成果物を探せ！ • ケイパビリティ調査の「ドキュメンテーション」の設問は低いチームが多い • 必要だと思ったときに必要なものを作っているため、決まった成果物が定義されていない • 前述のValue Stream Mapping
を実施してみてきづいたこと • 中間成果物の話しが全然でてこない！ • アクティビティと細かいタスクばかりが⽬⽴つ • 代表的な成果物は「会議での話し合い」と「プロダクトバックログ」と「ソースコード」 • 中間成果物がないわけではない。意識していないだけ。最初から「すべての」中間成果物を⾒極めるのは無理。だからといって、現時点でわかる範囲の成果物⾒極めをあきらめてはだめ。アジャイルな計画づくりでは、今わかる成果物の⽬的確認や優先順位を整理することが⼤事要因：⾒積もるべき中間成果物が⾒えていない

146 【事例⑤】中間成果物を⾒出す • PRINCE2は成果物指向のプロジェクトマネジメント・アプローチ • 計画書から成果物の定義と分析を⾏い、すべての成果物を階層化し、成果物ブレークダウン・ストラクチャ（PBS）を作成する（参考）:「成功のためのプロジェクトマネジメント・⼿法 PRINCE2」付録Dより

147 【事例⑤】中間成果物を⾒出す • Process Flow Diagram（PFD） • 成果物連鎖のシュミレーションができ、不⾜している成果物やムダな成果物の発⾒ができる • PFDは清⽔吉男さんが発案したプロセス設計記法
• （参考） https://affordd.jp/koha_hp/process/PFDform3.pdf • 中間成果物を⾒いだせれば、⾒積もりのブレが低減する • 作業時間＝成果物の質量／単位時間あたりの⽣産性成果物α 仕様化プロセス設計プロセステストプロセス成果物β 成果物γ 成果物δ 成果物ε in out in in out out in

まとめ 148

149 まとめ • アジャイル開発が失敗するのは「推⼒＝チーム性能」が満たされる前に、あれやこれや考えすぎてるときが多い • まずは、重⼒に負けない推⼒を⼿に⼊れよう！ • チーム性能が⾼ければ、ロードマップ（約束）を守れるチームになれる •
価値を作れるのは推⼒を⼿に⼊れてるから！⽣産性よりチームの性能向上を⽬指す

150 まとめ • これ絶対忘れちゃだめ • 忘れるとFour Kyesを測ったあと迷⼦になりやすい • 「LeanとDevOpsの科学」は読むたびに新たな発⾒がある良書（つまり難解） •
付録A、B、Cを最初に読むのがオススメ Four Keys はケイパビリティと統計的相関がある Four Keys 27のケイパビリティ統計的相関推⼒

151 まとめ • SPI活動は、ちょっと特殊なスキルが必要 • ソフトウェアエンジニアリングが⼤事 • 問題の形成⼒も⼤事 • 問題の解決⼒はもっと⼤事
• 昔はSEPGって呼んでた概念（いや、今でもあるとこにはある） • 改善活動をファシリテーションしつつ、「⼿離れ」できるよう⾃律も促す難しい活動 • でも、それを繰り返すことで組織は成⻑する。 SPI Enabling team を⽴ち上げるべき Stream A SPI Enabling team Stream- aligned team SPI Enabling team Stream- aligned team SPI Enabling team Stream- aligned team SPI Enabling team XaaS Stream-aligned team が直⾯する技術的な「阻害要因」を克服することを⽬的とする。新しい技術や⽅法論の導⼊を⽀援し、必要なスキルや能⼒がチーム内で開発されるよう促す。このチームは他のチームが⾃⼰完結できるようになるまでの⼀時的または短期的な⽀援を提供する

152 まとめ • SODAは、ITエンジニアに向けた、問題解決のための知識体系を提供するエピック集です。クリエイティブ・コモンズだよ。 • これにより、プロダクト開発組織は⼈材育成の仕組みを整え、⽣産性を向上させ、学習⽂化を育むことが容易になります。 • 偉い⼈のアンラーニングにも役に⽴つ
SPI活動にはSODAを利⽤しよう。そーだ！そーだ！テーラリング

153 天国にいるお⼆⼈へ多⽥洋祐さん、とりあえずベースラインは整いました。あのときGo!と⾔ってくたおかげです。データをお⾒せできないのが悔やまれます。⻄康晴さん、SODAが構想レベルだったときに褒めてくださったから、モチベーション⾼くここまで来れました。実況をXに書き込んでくださいましたか？それ読んでクスッとしたいです。これからも私たちはソフトウェア業界に貢献できるようがんばります。

SPI原点回帰論：事業課題とFour Keysの結節点を見出す実践的ソフトウェアプロセス改善 / DevOpsDays Tokyo 2024

SPI原点回帰論：事業課題とFour Keysの結節点を見出す実践的ソフトウェアプロセス改善 / DevOpsDays Tokyo 2024

More Decks by Visional Engineering ＆ Design

Other Decks in Technology

Featured

Transcript