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

Slide 1

Slide 1 text

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

Slide 12

Slide 12 text

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研修設計ドキュメント作成サービスメニュー構築

Slide 13

Slide 13 text

13 「こっそり変わるよね」 FYxx 8月 FYxx 9月 FYxx 10月 FYxx 11月 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ツールでケイパビリティをグラフ化する

Slide 14

Slide 14 text

14 「こっそり変わるよね」 FYxx 8月 FYxx 9月 FYxx 10月 FYxx 11月 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ツールでケイパビリティをグラフ化するお分かりいただけただろうか…

Slide 15

Slide 15 text

15 「こっそり変わるよね」 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研修設計ドキュメント作成サービスメニュー構築スローでもう一度見てみよう……

Slide 16

Slide 16 text

16 「こっそり変わるよね」 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研修設計ドキュメント作成サービスメニュー構築

Slide 17

Slide 17 text

17 「こっそり変わるよね」 FYxx 8月 FYxx 9月 FYxx 10月 FYxx 11月 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ツールでケイパビリティをグラフ化する

Slide 123

Slide 123 text

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)

Slide 124

Slide 124 text

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)

Slide 125

Slide 125 text

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)

Slide 126

Slide 126 text

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)

Slide 131

Slide 131 text

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.

Slide 132

Slide 132 text

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.

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text