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

https://speakerdeck.com/visional_engineering_and_design/devopsdays-tokyo-2024
のクローンです。

Transcript

1. SPI原点回帰論: 事業課題とFour Keysの結節点を見出す 実践的ソフトウェアプロセス改善 DevOpsDays Tokyo: Day1, 2024/4/16 Visionalグループ 株式会社ビズリーチ リクルーティングプロダクト本部 PMO室 SODA推進グループ 高橋裕之 内藤靖子
2. 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. 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. 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） 趣味 コストコ、ねこ、ラジオ体操、昼寝 経歴
5. 会社概要 株式会社ビズリーチ / BizReach, Inc. 創業 ：2009年4月 代表者 ：株式会社ビズリーチ 代表取締役ボス 酒井 哲也 グループ従業員数：2,149名（2023年7月末時点） 拠点 ：東京、大阪、名古屋、福岡、静岡、広島 資本金 ：1億3,000万円 事業内容：HR Techのプラットフォーム・SaaS事業
6. 6 株式会社ビズリーチ ビジョン 自分の可能性を信じ、 自分の意志ではたらき方を選択することができたら、 覚悟をもった主体的な「はたらく」を実現できる。 生産性も向上し、企業にも活力が生まれる。 そのために、自分らしく「はたらく」をあたりまえにする 「キャリアインフラ」になりたい。 一人ひとりが活き活きとはたらくことができる社会のために。 「キャリアインフラ」になる
7. 時代の変化により、市場の構造が複雑化し、 価値観も多様化している。 キャリア形成において重要なのは、 自分の未来に自信を持てる「はたらく」を選択し、 挑戦し続ける企業と繋がり、新たな活力を生み出すこと。 私たちは世の中にたくさんの「選択肢と可能性」を提供し、 「はたらく」を変革していく。 7 株式会社ビズリーチ ミッション キャリアに、選択肢と可能性を
8. 株式会社ビズリーチ サービス一覧 即戦力人材と企業をつなぐ 転職サイト OB/OG訪問 ネットワークサービス 人財活用システム 採用管理システム 勤怠管理システム 経費精算システム
9. 9 あれは、2年前のある夏の日だった
10. ボス、ロードマップに戸惑う 2年前のある夏 10
11. 11 ボス、ロードマップに戸惑う 開発ロードマップ、 こっそり変わるときあるよね…… ボス
12. 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研修設計 ドキュメント 作成 サービスメニュー構築
13. 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ツールでケイパビリティ をグラフ化する
14. 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ツールでケイパビリティ をグラフ化する お分かりいただけただろうか…
15. 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研修設計 ドキュメント 作成 サービスメニュー構築 スローでもう一度見てみよう……
16. 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研修設計 ドキュメント 作成 サービスメニュー構築
17. 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ツールでケイパビリティ をグラフ化する
18. 18 ボス、ロードマップに戸惑う …… ボス
19. 19 ボス、ロードマップに戸惑う …… ボス 問題 1. 現象のエビデンスがない （なんで変わったの？） 2. お客様への約束を守れてない （信頼・売上への影響懸念） 3. 「今期中はムリです」と変更を断られる （戦略への影響懸念） 4. リスケしたのでオンスケです （ん？） etc.
20. 20 ボス、ロードマップに戸惑う 開発生産性って測れないの？ やっぱり知りたいなぁ 開発チームの遅れた理由を 「信じる」しかないんだよねぇ…… ボス
21. 21 ボス、ロードマップに戸惑う （あっ…これ上手く対応しないとヤバイやつ！） わかりました！考えます！ 開発生産性って測れないの？ やっぱり知りたいなぁ 開発チームの遅れた理由を 「信じる」しかないんだよねぇ…… ボス
22. 22 ボス、ロードマップに戸惑う ロードマップがこっそり変わるのは 生産性が低いからだ 自組織の生産性が分からないから計画がブレる or ズレた根拠がない（エビデンスが欲しい） ボスの仮説 開発生産性って測れないの？ やっぱり知りたいなぁ 開発チームの遅れた理由を 「信じる」しかないんだよねぇ……
23. 23 ボス、ロードマップに戸惑う ロードマップがこっそり変わるのは 生産性が低いからだ 自組織の生産性が分からないから計画がブレる or ズレた根拠がない（エビデンスが欲しい） ロードマップが「おおざっぱな WBS」みたいになっている 作業ばかり挙げてゴール・成果 物に着目できていない 工場みたいに 生産性がわかればソフトウェア も予測可能と思われている （物的生産性） リリースさえすれば 売れると信じている （そうかもしれないし、 そうでないかもしれない） そもそもロードマップを 適当に作った （どうせ変わるしマインド）
24. 24 ボス、ロードマップに戸惑う ロードマップがこっそり変わるのは 生産性が低いからだ 自組織の生産性が分からないから計画がブレる or ズレた根拠がない（エビデンスが欲しい） ロードマップが「おおざっぱな WBS」みたいになっている 作業ばかり挙げてゴール・成果 物に着目できていない 工場みたいに 生産性がわかればソフトウェア も予測可能と思われている （物的生産性） リリースさえすれば 売れると信じている （そうかもしれないし、 そうでないかもしれない） そもそもロードマップを 適当に作った （どうせ変わるしマインド） ロードマップがこっそり変わる要因は たくさんありそうだ
25. リリース1 リリース2 リリース3 ②リリース計画 ③イテレーション 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 （参考）PMBOKガイド第7版の図2-17 を加工して作成
26. 26 ソフトウェア開発の“生産性”指標の難しさ 「書いたコードの量」が生産性とは言い難い • 1000行から成るコードより、10行のコードで解決するほうが望ましいこともある • 誰も理解出来ない1行のコードより、理解も保守もしやすい数行のコードのほうが望ましいこともある 「ベロシティ(速度)」が生産性とは言い難い • ベロシティはキャパシティを予測する(計画する)ためのツールであって生産性とは違う • ベロシティは、あくまでもチーム内の相対的な尺度（過去の自分たちとの比較）。即ち、チーム同士の比較に意味はない 「リソース効率(利用率)」を上げれば生産性が上がるとは限らない • リソース効率向上ばかり目指すと「人が足りない」問題がいつまでも続く • 大事なのは作業に集中する「フロー効率」の向上 • さらに大事なのは、必ず発生する予想外の仕事や計画変更、エンジニア自身の実験・勉強・鍛錬の時間を捻出するための「Slack（ゆとり）」 計測によってチーム同士が競争・対立するような状況を防がなければならない • 開発 vs QA 、開発 vs 運用 といった対立を煽りかねない 計測値を人事評価に使わせない • 評価者への甘い囁き！（評価が明確になりそうな雰囲気がある） • 評価KPIにしたとたん、数値を良く見せるための計測Hackがはじまる（最悪の場合、偽装も）
27. 27 ボス、ロードマップに戸惑う ロードマップがこっそり変わるのは 生産性が低いからだ 自組織の生産性が分からないから計画がブレる or ズレた根拠がない（エビデンスが欲しい） ボスの仮説 開発生産性って測れないの？ やっぱり知りたいなぁ 開発チームの遅れた理由を 「信じる」しかないんだよねぇ……
28. 28 ボス、ロードマップに戸惑う ロードマップがこっそり変わるのは 生産性が低いからだ 自組織の生産性が分からないから計画がブレる or ズレた根拠がない（エビデンスが欲しい） ボスの仮説 開発生産性って測れないの？ やっぱり知りたいなぁ 開発チームの遅れた理由を 「信じる」しかないんだよねぇ…… 測るのは良いが、 測ったあとのことや 測るときのチームの負荷を考えて 意味のない計測をしないようにする 必要がある
29. 29 計測を始めるにあたって注意したこと プロジェクトを 時間通り、予算通りに 終わらせることよりも もっと重要なのは、 世界を変えるような、あるいは企業 やビジネスのあり方を変えるような ソフトウェアを作るという「変革」 （参照）Tom DeMarco. (2009). IEEE Software誌7月8月合併号"Software Engineering: An Idea Whose Time Has Come and Gone?".
30. 30 計測を始めるにあたって注意したこと プロジェクトを 時間通り、予算通りに 終わらせることよりも もっと重要なのは、 世界を変えるような、あるいは企業 やビジネスのあり方を変えるような ソフトウェアを作るという「変革」 （参照）Tom DeMarco. (2009). IEEE Software誌7月8月合併号"Software Engineering: An Idea Whose Time Has Come and Gone?". 「アウトプット」より「アウトカム」
31. 31 計測を始めるにあたって注意したこと • 組織がアウトカムではなくアウトプットで成功を計測しようとして、行き詰まっている状況＊ • 実際に生み出された価値ではなく、機能の開発とリリースに集中してしまっている状態＊ ビルドトラップ 誰もプロダ クトを使わ ない 足りない機 能を作る 顧客に足り ない機能を 聞く プロダクトの死のサイクル(デイビッド・ブランド) https://twitter.com/davidjbland/status/467096015318036480 * Perri, M. (2018). プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける (吉羽 龍太郎, Trans.). O'Reilly Japan, Inc​​.
32. 32 計測を始めるにあたって注意したこと • 組織がアウトカムではなくアウトプットで成功を計測しようとして、行き詰まっている状況＊ • 実際に生み出された価値ではなく、機能の開発とリリースに集中してしまっている状態＊ ビルドトラップ 誰もプロダ クトを使わ ない 足りない機 能を作る 顧客に足り ない機能を 聞く プロダクトの死のサイクル(デイビッド・ブランド) https://twitter.com/davidjbland/status/467096015318036480 * Perri, M. (2018). プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける (吉羽 龍太郎, Trans.). O'Reilly Japan, Inc​​. 「アウトプット」より「アウトカム」
33. 33 Software Outcome Delivery Architecture(SODA): prototype SODA構想ってのを考えました！ ぜひ、進めさせてください！ ボス
34. 34 Software Outcome Delivery Architecture(SODA): prototype • “相互に関連した責任感のあるチーム ”を組織に「実装」するうえで必要なマネジ メント関連のナレッジ・スキル体系・フレームワークなどを集め組織への実装イ メージを「設計」しメタ的なアーキテクチャを作成した。 • これを Software Outcome Delivery Architecture (SODA) と名付けた。
35. 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
36. Software Outcome Delivery Architecture(SODA): prototype
37. Software Outcome Delivery Architecture(SODA): prototype 信頼されるロードマップを作るには
38. Software Outcome Delivery Architecture(SODA): prototype 継続的に成果を出し続けるには
39. 39 Software Outcome Delivery Architecture(SODA): prototype ぜひ進めて！ 経営層も計測結果を読む スキルが必要だね！ プロダクト組織を「計測」して 改善の手がかりをつかむんだね 科学的でいいね！ SODA構想ってのを考えました！ ぜひ、進めさせてください！ ボス
40. 40 Software Outcome Delivery Architecture(SODA): prototype 自組織を視座高く点検するためのアーキテクチャ。 組織に足りない機能を実装したり、メンバーはもちろん マネジャー、経営層のアンラーニングにも役に立つ
41. Software Outcome Delivery Architecture(SODA): BizReach ver.
42. テーラリング Software Outcome Delivery Architecture(SODA): BizReach ver.
43. Software Outcome Delivery Architecture(SODA): BizReach ver.
44. Software Outcome Delivery Architecture(SODA): BizReach ver.
45. 45 SODA Project のデータソース
46. データソリューショングループ(DSG) リクルーティングプロダクト本部 SODA Project のデータソース BigQuery （データーポータル） HRMOSプロダクト本部 BigQuery ETL ダッシュボード
47. 47 指標構造｜プロダクト下 - ３つの指標領域 品質(Q)とスピード(D) 開発進捗 障害 開発チーム パフォーマンス 顧客満足度 営業指標 マーケティング指標 市場占有率 売上 利益 契約企業/HH数 登録ユーザー数 UHS 求人数 内定率 入社人数 レジュメ数 応募数 内定承諾率 障害数 障害レベル DORAメトリクス （FourKeysなど） オンプロダクト指標 スコープ(S) 時間(D) 予算(C) デリバリーの変更率 進捗率 スコープの達成率 マイルストーン達成率 人件費 固定費 開発ツール費 e-NPS パルスサーベイ DiSC （行動特性） 工数 勤務年数 プロダクト組織のコンディション 開発チーム組成 年齢 性別 等級 エンジニア個人ケイパビリティ コミット数 平均コミットサイズ PR作成数・マージ数 コード行数 平均PRクローズ時間 Issue ticket クローズ 数 品質(Q)とスピード プロダクト開発指標 アウトカム アウトカム指標は、３つの指標群（営業、マーケティング、 プロダクト開発）により可視化できると考えています。
48. 48 ((SODA))Evidence Viewer デモ リーチ
49. 計測の重要性：Opinion vs Fact（意見か事実か） Problem（問題） Solution（解決策） Fact（事実） Opinion（意見） 設計 デプロイ 仮説を実装する （改善活動） 仮説を動かす （改善活動） 結果を 検証する 仮説 改善アプローチ の仮説を立てる 計測 (参考) https://slide.meguro.ryuzee.com/slides/78 吉羽龍太郎さん「カイゼンの基本」の図を変更 仮説を立てるには、 計測データを検証す る必要がある。 SODA
50. 計測の重要性：Opinion vs Fact（意見か事実か） Problem（問題） Solution（解決策） Fact（事実） Opinion（意見） 設計 デプロイ 仮説を実装する （改善活動） 仮説を動かす （改善活動） 結果を 検証する 仮説 改善アプローチ の仮説を立てる 計測 (参考) https://slide.meguro.ryuzee.com/slides/78 吉羽龍太郎さん「カイゼンの基本」の図を変更 仮説を立てるには、 計測データを検証す る必要がある。 SODA 大抵の組織では この「改善アプローチの仮説」を 立てるスキルが不足している 仮説 改善アプローチ の仮説を立てる
51. SPIへの原点回帰 生産性よりチームの性能向上を目指す 51
52. 52 ずっとエンジニア不足 （引用）BizReach withHR 「IT人材不足の原因とは？ 現状や対策法、今後の見通しを解説」https://media.bizreach.biz/40991/ , 経済産業省「IT 人材需給に関する調査」を加工して作成
53. 53 ずっとエンジニア不足 （引用）BizReach withHR 「IT人材不足の原因とは？ 現状や対策法、今後の見通しを解説」https://media.bizreach.biz/40991/ , 経済産業省「IT 人材需給に関する調査」を加工して作成
54. 54 生産性とは （引用）経済産業省「IT 人材需給に関する調査」2019年3月, https://www.meti.go.jp/policy/it_policy/jinzai/houkokusyo.pdf
55. 55 生産性とは ｢生産性とは生産諸要素の有効利用の度合いである｣ ヨーロッパ生産性本部（1959年ローマ会議） （参考）BizReach withHR「労働生産性とは？【高める方法】計算式、種類、日本の現状」https://media.bizreach.biz/24663/
56. 56 生産性とは ｢生産性とは生産諸要素の有効利用の度合いである｣ （参考）BizReach withHR「労働生産性とは？【高める方法】計算式、種類、日本の現状」https://media.bizreach.biz/24663/ 原材料 機械設備 人
57. 57 生産性とは ｢生産性とは生産諸要素の有効利用の度合いである｣ （参考）BizReach withHR「労働生産性とは？【高める方法】計算式、種類、日本の現状」https://media.bizreach.biz/24663/ 原材料 機械設備 人 ←労働生産性
58. 58 生産性とは ｢生産性とは生産諸要素の有効利用の度合いである｣ （参考）BizReach withHR「労働生産性とは？【高める方法】計算式、種類、日本の現状」https://media.bizreach.biz/24663/ 人 ←労働生産性
59. 59 生産性とは ｢生産性とは生産諸要素の有効利用の度合いである｣ （参考）BizReach withHR「労働生産性とは？【高める方法】計算式、種類、日本の現状」https://media.bizreach.biz/24663/ 人 ←労働生産性 生産性＝産出(output) ÷ 投入(input) 物的労働生産性:量 付加価値労働生産性:質(利益) ＝生産量 ÷（労働者数 or 労働者数×労働時間） ＝付加価値額 ÷（労働者数 or 労働者数×労働時間）
60. 60 生産性とは ｢生産性とは生産諸要素の有効利用の度合いである｣ （参考）BizReach withHR「労働生産性とは？【高める方法】計算式、種類、日本の現状」https://media.bizreach.biz/24663/ 人 ←労働生産性 生産性＝産出(output) ÷ 投入(input) 物的労働生産性:量 付加価値労働生産性:質(利益) ＝生産量 ÷（労働者数 or 労働者数×労働時間） ＝付加価値額 ÷（労働者数 or 労働者数×労働時間） 開発生産性を語るうえで「測っても仕方がない」や「物的労働生 産性の計測はアジャイル開発では危険」といった論調も。
61. 61 生産性とは ｢生産性とは生産諸要素の有効利用の度合いである｣ （参考）BizReach withHR「労働生産性とは？【高める方法】計算式、種類、日本の現状」https://media.bizreach.biz/24663/ 人 ←労働生産性 生産性＝産出(output) ÷ 投入(input) 物的労働生産性:量 付加価値労働生産性:質(利益) ＝生産量 ÷（労働者数 or 労働者数×労働時間） ＝付加価値額 ÷（労働者数 or 労働者数×労働時間） 開発生産性を語るうえで「測っても仕方がない」や「物的労働生 産性の計測はアジャイル開発では危険」といった論調も。 生産性？ ちょっと何言ってるか分からない
62. 62 生産性：宇宙事業で例えてみる 物的労働生産性:量 付加価値労働生産性:質(利益) 【メタファー】 安定したロケットの打ち上げ 宇宙で成し遂げたいなら「推力」を手に入れる 【メタファー】 宇宙でのミッション、惑星探査 月面基地の建設、火星旅行
63. 63 生産性：宇宙事業で例えてみる 物的労働生産性:量 付加価値労働生産性:質(利益) 【メタファー】 安定したロケットの打ち上げ 宇宙で成し遂げたいなら「推力」を手に入れる 【メタファー】 宇宙でのミッション、惑星探査 月面基地の建設、火星旅行 ロケットを打ち上げれないと（量） ミッションは実現できない（質）
64. 64 生産性：宇宙事業で例えてみる 物的労働生産性:量 付加価値労働生産性:質(利益) 【メタファー】 安定したロケットの打ち上げ 宇宙で成し遂げたいなら「推力」を手に入れる 【メタファー】 宇宙でのミッション、惑星探査 月面基地の建設、火星旅行 重さ1tのロケットに必要な推力は 1t以上(約9.8kN)の推力が必要 （ちなみにH3ロケットの総重量は575t、 個体ロケットブースタの真空中推力は2300kN）
65. 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 は「推力」を計れる
66. 66 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 は「推力」を計れる 開発のパフォーマンス(性能)・レベル
67. 67 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 は「推力」を計れる 開発のパフォーマンス(性能)・レベル ©JAXA
68. 信頼・対価(売上) 68 生産性よりチームの性能向上を目指す 顧客 プロダクト・サービス提供 良かった！ 継続 事業会社 アウトカム向上
69. 信頼・対価(売上) 69 生産性よりチームの性能向上を目指す 顧客 プロダクト・サービス提供 良かった！ 継続 アウトカム向上 チームの性能を上げる！
70. 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. 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)
72. 72 DORA Metrics 変更リードタイム デプロイ頻度 デプロイ失敗からの 回復時間 変更失敗率 信頼性（可用性） Four Keys 27のケイパビリティ 統計的相関 （参考）Google Cloud. ” Explore DORA's research program”. Google Cloud. https://www.devops-research.com/research.html. (参照 2023-1-10) デモ リーチ
73. 73 DORA Metrics 変更リードタイム デプロイ頻度 デプロイ失敗からの 回復時間 変更失敗率 信頼性（可用性） Four Keys 27のケイパビリティ 統計的相関 （参考）Google Cloud. ” Explore DORA's research program”. Google Cloud. https://www.devops-research.com/research.html. (参照 2023-1-10) デモ リーチ 推力
74. 74 DORA Metrics 変更リードタイム デプロイ頻度 デプロイ失敗からの 回復時間 変更失敗率 信頼性（可用性） Four Keys 27のケイパビリティ 統計的相関 （参考）Google Cloud. ” Explore DORA's research program”. Google Cloud. https://www.devops-research.com/research.html. (参照 2023-1-10) デモ リーチ 推力 我々は、生産性より チームの性能向上を目指す SPI活動を実践してきました
75. Stream-aligned team Platform team Enabling team Complicated Subsystem team Collaboration Fundamental Team Types Team Interaction Modes XaaS Facilitating Undefined Team Type Supplementary Team Types SPIへの原点回帰 スケルトン, M., パイス, M., 原田 騎郎, 永瀬 美穂, & 吉羽 龍太郎. (2021). チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計. 日本能率協会マネジメントセンター.
76. Stream-aligned team Platform team Enabling team Complicated Subsystem team Fundamental Team Types SPIへの原点回帰 スケルトン, M., パイス, M., 原田 騎郎, 永瀬 美穂, & 吉羽 龍太郎. (2021). チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計. 日本能率協会マネジメントセンター. ビジネスドメインの特定の領域に密接に関連した作業の流れに沿って配置される。主な 目的は、エンドユーザーに価値を直接的に提供する製品やサービスに焦点を当てること である。比較的自己管理的であり、少ない依存関係で迅速に変更を行えるよう設計され ている。 高度な技術的専門知識を要する複雑なシステムやコンポーネントを開発する責任を担 う。作業には高度な数学、計算、またはその他の専門的技術が必要であり、その専門性 のために他のチームと区別される。 内部で使用される製品やサービスを開発し、これによって他のストリームアラインド チームがより迅速に価値を提供できるようにすることを目指す。基盤となるプラット フォームやツール、共通のサービスを提供し、これによって他のチームがその上に構築 することができるようにする。 Stream-aligned team が直面する技術的な「阻害要因」を克服することを目的とする。 新しい技術や方法論の導入を支援し、必要なスキルや能力がチーム内で開発されるよう 促す。 このチームは他のチームが自己完結できるようになるまでの一時的または短期的な支援 を提供することが多い。
77. Stream-aligned team Platform team Enabling team Complicated Subsystem team Fundamental Team Types SPIへの原点回帰 スケルトン, M., パイス, M., 原田 騎郎, 永瀬 美穂, & 吉羽 龍太郎. (2021). チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計. 日本能率協会マネジメントセンター. ビジネスドメインの特定の領域に密接に関連した作業の流れに沿って配置される。主な 目的は、エンドユーザーに価値を直接的に提供する製品やサービスに焦点を当てること である。比較的自己管理的であり、少ない依存関係で迅速に変更を行えるよう設計され ている。 高度な技術的専門知識を要する複雑なシステムやコンポーネントを開発する責任を担 う。作業には高度な数学、計算、またはその他の専門的技術が必要であり、その専門性 のために他のチームと区別される。 内部で使用される製品やサービスを開発し、これによって他のストリームアラインド チームがより迅速に価値を提供できるようにすることを目指す。基盤となるプラット フォームやツール、共通のサービスを提供し、これによって他のチームがその上に構築 することができるようにする。 Stream-aligned team が直面する技術的な「阻害要因」を克服することを目的とする。 新しい技術や方法論の導入を支援し、必要なスキルや能力がチーム内で開発されるよう 促す。 このチームは他のチームが自己完結できるようになるまでの一時的または短期的な支援 を提供することが多い。
78. Stream A Stream B Platform V Flow of change 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）という手法を用いて、 ソフトウェア開発の効率性、品質、パフォーマンスを向上させる技術や方法論の導入を支援する
79. PdM Enabling team QA Enabling team 79 SPIへの原点回帰 SPI Enabling team SODAイネーブルメントでスキル、ツール、プロセス、システムの使用を向上を促す
80. 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 は他のチームが自己完結できるようになるまでの 一時的または短期的な支援を提供する
81. ソフトウェアプロセス改善について SPI:Software Process Improvement 81
82. 82 ソフトウェア開発は建築に似ている？ 似ていない。大規模開発はときにビル建設並の予算と時 間がかかるが建築のように部材ひとつ、ネジひとつに きっちりとしたJIS規格があるわけではない。 エンジニアリング ≠ ソフトウェア・エンジニアリング。 ソフトウェア開発は建築に比べれば自由度が高すぎる。
83. 似ているようで似ていない。独創性は大事でありそれが イノベーションに繋がることはある。しかし、我々の ゴールは顧客の困ったことを解決し、お金を扱い、法律 を遵守するといったさまざまな制約に縛られている。 ソフトウェア開発は芸術と違い不確実性が高い。 83 ソフトウェア開発は芸術に似ている？
84. 似ている。終わらないWeb系開発は日々の食卓のよう。プロダクトに定期的に価値を 作り込む手段がソフトウェア開発。日々の食事に価値を与えるのが料理。 料理人はレシピなんか見ないし分量も測らないが美味しい料理を作れる。しかし、 再現性が必要になればレシピは大事。レシピどおり作っても失敗することはある。 家庭料理とファミレス、高級料理店とでは、コストもオペレーションは違う。 そして美味しくても流行らない店もある…… 84 ソフトウェア開発は料理に似ている？
85. 85 ソフトウェアプロセス改善(SPI)とは何か？ 料理 ソフトウェア開発 料理研究家 ソフトウェアプロセス改善 (SPI)専門家 研究・鍛錬 研究・鍛錬 似ている 料理の世界では「料理研究家」という人た ちがいる。 時代の変化と共に生活様式が変わっていく 中で、「料理研究家」はその時代にあった 料理を日々研究し、レシピを開発したり伝 承に励んでいる。 ソフトウェア開発の世界でも「プロ ス改 善コーチ・アジャイルコーチ」と言われる 人たちがいる。 テクノロジーの進化とビジネス変化のス ピードに合わせソフトウェアの開発も変 わっていく。ソフトウェアプロ ス改善(SPI) 専門家は様々な現場にあった最適なプロ スやチームへのアプローチを日々研究し、 フレームワークを研究したり実践に励んで いる。 似ている
86. 86 ソフトウェアプロセス改善(SPI)とは何か？ 料理 ソフトウェア開発 料理研究家 ソフトウェアプロセス改善 (SPI)専門家 研究・鍛錬 研究・鍛錬 実践・伝達 イネーブルメント 日本の食卓を変える 日本人のくらしを変える ケイパビリティ獲得を促し、 チームの性能向上を目指す 似ている 似ている
87. 87 ソフトウェアプロセス改善(SPI)とは何か？ 1. 優れたソフトウェアプロセスの要 素が、優れたやり方で定義できる こと 2. ソフトウェア開発への既存の組織 的アプローチが、これらの要素と 照らし合わせて診断できること 3. 改善のための有意な戦略を定義で きること 実践ソフトウェアエンジニアリング[第9版] Roger S Pressman・Bruce R.Maxim著 より引用
88. ソフトウェアプロセス改善(SPI)とは何か？ ボトムアップで失敗する例 ビジネスゴールを決めて取り組むと Mary E. Potter, &Neil S. Sakry. (2002). Making Process Improvement Work: A Concise Action Guide for Software Managers and Practitioners. US: Addison-Wesley Professional; 左の例では、ゴールを決めずにプロ ス中心のアプローチをとって失敗する例。 右の例では、ゴールに向かってゆく過程で問題が発生する部分について、 プロ ス改善のアプローチを適用する、プロ ス改善の成功例を示しています。
89. 89 ソフトウェアプロセス改善(SPI)とは何か？ IDEALモデル 変化への 刺激 変化背景 の確認 スポンサー シップ確立 活動体制 の構築 現状と 理想像の 記述 勧告の 策定 優先 順位の 設定 アプ ローチ の策定 行動の 計画 解決策の 作成 先行評価/ 試行の実施 解決策の 改良 解決策の 実施 分析と 検証 Initiating 開始 Diagnosing 診断 Establishing 確立 Acting 行動 Learning 学習 1 2 3 4 0 将来活動 を提案 IDEALモデル
90. 90 ソフトウェアプロセス改善(SPI)とは何か？ IDEALモデル 変化への 刺激 変化背景 の確認 スポンサー シップ確立 活動体制 の構築 現状と 理想像の 記述 勧告の 策定 優先 順位の 設定 アプ ローチ の策定 行動の 計画 解決策の 作成 先行評価/ 試行の実施 解決策の 改良 解決策の 実施 分析と 検証 Initiating 開始 Diagnosing 診断 Establishing 確立 Acting 行動 Learning 学習 1 2 3 4 0 将来活動 を提案 SODA構想 IDEALモデル
91. 91 ソフトウェアプロセス改善(SPI)とは何か？ 廻るSPI 診断フェーズ 確立フェーズ 行動フェーズ 学習フェーズ 1 2 3 4 開発チームの体力や 筋力のレベルを評価する • ((SODA)) Evidence Viewer で 開発パフォーマンス（Four Kyes）やアウトカム指標など を確認。ケイパビリティ・ データを対比させ改善が必要 な箇所を把握する。 開発チームの 筋トレ計画を立てる • 診断フェーズで得られた結果 に基づいて、プロセス改善活 動の優先順位と取り組み方を 策定し、具体的な改善計画を 作成する。改善計画はSPIが支 援。 実際に筋トレを 開始する • 確立フェーズで作成された改 善計画に従って解決策を作 り、その先行評価・試行・ パッケージ化・展開・長期支 援移行を実施する。 効果を評価し、必要に応じて 計画を調整する • 行動フェーズの結果を受け て、これまでの活動を分析し てその妥当性を確認し、次の サイクルの準備を行う。 • 診断フェーズに戻る
92. SPIはDevOps時代に合っているのか? 古い？新しい？ 92
93. 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. 94 プロセス改善アプローチ 目的に有効な“能力あるいは機能”を特定し続け、 それらを組織的に伸ばし改善を目指すモデル •CMMの成熟度モデル 成熟のステップを定義し、段階を追って高レベル の達成を目指すモデル •DORAのケイパビリティモデル テクノロジーやビジネスをめぐる状況が絶えず変化する時代では 「成熟度」よりも「ケイパビリティ」(できること) を増やすほうが良い http://app.fujiq-resorts.com/fujitozan/knowledge/page/equipment/?mode=pc https://learn.microsoft.com/en-us/azure/devops/boards/work- items/guidance/cmmi/guidance-background-to-cmmi?view=azure-devops
95. 95 プロセス改善アプローチ 目的に有効な“能力あるいは機能”を特定し続け、 それらを組織的に伸ばし改善を目指すモデル •CMMの成熟度モデル 成熟のステップを定義し、段階を追って高レベル の達成を目指すモデル •DORAのケイパビリティモデル テクノロジーやビジネスをめぐる状況が絶えず変化する時代では 「成熟度」よりも「ケイパビリティ」(できること) を増やすほうが良い http://app.fujiq-resorts.com/fujitozan/knowledge/page/equipment/?mode=pc 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 のレベ ル属性があります。
96. 96 DORA Metrics 変更リードタイム デプロイ頻度 デプロイ失敗からの 回復時間 変更失敗率 信頼性（可用性） Four Keys 27のケイパビリティ 統計的相関 （参考）Google Cloud. ” Explore DORA's research program”. Google Cloud. https://www.devops-research.com/research.html. (参照 2023-1-10) デモ リーチ 推力
97. 97 DORA Metrics 技術 プロセス 組織文化 バージョン管理 チームのツール選択のサ ポート チームの実験 システムをモニタリングして ビジネス上の意思決定に役立 てる 仕事の満足度 トランクベース開発 テストデータ管理 変更承認の効率化 障害の予兆通知 Westrumの組織類型 継続的インテ グレーション セキュリティの シフトレフト 顧客からの フィードバック 仕掛かり制限 学習文化 デプロイの自動化 データベースの チェンジマネジメント バリューストリーム での作業の可視性 ビジュアル管理 変革型リーダーシップ 継続的なテスト クラウド インフラストラクチャ 小さいバッチ 単位の作業 継続的デリバリー コードの保守性 疎結合なアーキテクチャ モニタリングとオブザービ リティ 現在27のケイパビリティが公開されている https://cloud.google.com/architecture/devops/capabilities?hl=ja
98. 98 DORA Metrics 技術 プロセス 組織文化 バージョン管理 チームのツール選択のサ ポート チームの実験 システムをモニタリングして ビジネス上の意思決定に役立 てる 仕事の満足度 トランクベース開発 テストデータ管理 変更承認の効率化 障害の予兆通知 Westrumの組織類型 継続的インテ グレーション セキュリティの シフトレフト 顧客からの フィードバック 仕掛かり制限 学習文化 デプロイの自動化 データベースの チェンジマネジメント バリューストリーム での作業の可視性 ビジュアル管理 変革型リーダーシップ 継続的なテスト クラウド インフラストラクチャ 小さいバッチ 単位の作業 継続的デリバリー コードの保守性 疎結合なアーキテクチャ モニタリングとオブザービ リティ 現在27のケイパビリティが公開されている https://cloud.google.com/architecture/devops/capabilities?hl=ja 「LeanとDevOpsの科学」には次のような一節がある。 “忘れないでほしいのは、「ハイパフォーマンス」とは購入した り、真似したりできるものではないという点である。自身のケイ パビリティを高めつつ、自チームや自組織の現状や目標にしっく りくる道を模索する必要がある。そしてこれには、絶え間ない努 力、投資、集中、時間を要する。” Forsgren, N., Humble, J., & Kim, G. (2018). LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する (武舎広幸 & 武舎るみ, Trans.). impress top gear. (Original work published 2018). p. 233.
99. 改善事例 99
100. Four Keys 測れませんっ!! 事例① 100
101. 101 【事例①】Four Keys 測れませんっ!! メトリクス DORAの定義 いざ測ろうとしたら…… 変更リードタイム コードがコミットされてから本番環境で 正常に実行されるまでの時間 1. 複数チームで同一リポジトリを使って いて、チーム毎にデータ収集できない 2. リポジトリが複数あって、それぞれに ブランチ戦略が異なる 3. ブランチ戦略が複雑で収集後のデータ 加工が大変…… デプロイ頻度 コードを本番環境にデプロイまたはエン ドユーザーにリリースした頻度 デプロイ失敗からの 回復時間 サービスインシデントまたは不具合が発 生したときにサービスの復元にどれくら いの時間がかかるか 1. 障害管理ツールを変更したら日付 フィールドしかなく、デプロイ失敗か らの回復時間を計測できない 2. 障害のエビデンスはあるが、計測可能 な状態になっていない（テキスト） 変更失敗率 本番環境に変更を加えた、またはユー ザーへのリリースを実施した結果サービ スが低下し、その後修正を行う必要が生 じた割合
102. 102 【事例①】Four Keys 測れませんっ!! • 予定のなかった計測を意識した運用はもちろんムリ • 計画されないものは実行されない • JiraにせよGitHubにせよ、そもそもルールがなければあっというまに無法地帯 • 繰り返される歴史。チームに運用をまかせると、あまり良い結果にはならない • 最低限のガイドラインは横断的に見ているEnabling teamが決めると良い • 計測はカトラリールール。プロジェクトの計画に「計測」を組み込む（前提もし くは制約） • 管理ツールを計測可能な形式に整える • 幸いなことに、これから開発が始まる場合は、 計測を意識した運用になってきている 計測はカトラリールール 外から順に！ https://www.foods-labo.net/page-special.php?special_id=2260
103. 地図のない旅 事例② 103
104. Case B： •レガシーで稼働していたシステムの移植を実 施すること。 •「作り変えなので同じ仕様で」と言われた。 •時間が経つにつれ、仕様を把握しているひと が居ないことに気づく •また、せっかく作り直すなら、今より良くし たほうが良いのではと思うものの、スケ ジュールの全体感が掴めず躊躇している。 Case A： •チームは共通コンポーネントの開発をしてい る。他チームから様々要望を受け、振り回さ れている。 •カンバンボードでタスク管理をしてるが、そ れ以外ではロードマップしかない。 •タスクの優先順位が判断できず、来たものか ら逐次こなしている……ので常に忙しい。 •これで良いのだろうか？ 104 【事例②】地図のない旅 ライトは当てたところしか見えない…… 双子は似ているけど同じではない…
105. リリース1 リリース2 リリース3 ②リリース計画 ③イテレーション 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 （参考）PMBOKガイド第7版の図2-17 を加工して作成 欲しいレベルの地図
106. リリース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 マネジャーの頭の中では イメージされてたりするのだが…… 欲しいレベルの地図
107. リリース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時間 メンバーには、 こんな感じで伝わってしまう
108. リリース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. 109 【事例②】地図のない旅 • 「同じ仕様」と言われても実はメンバーそれぞれの知っている範囲、理解は異 なっている • 「☓☓は◯◯だよね？！」「あれ、そうだった？」。どこにもドキュメントがなーい！現行シス テムを動作させて確認する・・・。 • ざっくり何ができるかはわかるが、詳細になるとみんな違うことを言う （引用）https://agilewarrior.wordpress.com/2010/11/06/the-agile-inception-deck/
110. 110 【事例②】ユーザーストーリーマッピング まず、立ち止まる 関係者間での対話を作り出す 最初は時間かかるが、 共通理解が生まれると前に進む （引用）https://agilewarrior.wordpress.com/2010/11/06/the-agile-inception-deck/
111. 111 【事例②】ユーザーストーリーマッピング • 以下の3つを同時に見える化する • 【ワークフロー】【プロダクトの設計】【リリース計画】 （引用）Jeff Patton著 川口 恭伸 監訳 長尾 高弘 訳 『ユーザーストーリーマッピング』
112. リリース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. 生産性のパラドックス 事例③ 113
114. 114 【事例③】生産性のパラドックス 機能を作ることばかりに集中してしまうことをビルドトラップと言いますが…… 顧客 コレ じゃない！ 機能A 機能B 機能C 機能D 事業会社
115. 115 【事例③】生産性のパラドックス Scrumを導入しチームはがんばっているのにパフォーマンスが低い 顧客 …… 事業会社 ほぼ無風
116. 116 【事例③】生産性のパラドックス • 情報技術の導入が進むにつれて、生産性が期待されるほど向上しない、あるいは 場合によっては低下する現象を指す。1980年代にこの語が広まり、特にオフィス の自動化やコンピュータ技術の急速な発展に伴う生産性の停滞が問題とされた。 • 経済学者のロバート・ソローは、「コンピュータの生産性効果は至る所で見られ るが、統計数字には現れない」と述べ、このパラドックスを端的に表現している。 • このパラドックスの原因は多岐にわたる。一つは、新技術の導入初期において、 従業員がその技術を習得し、効果的に活用するまでに時間が必要であるため、短 期間での生産性向上が見込めないことがある。また、技術導入に伴うコストが初 期の生産性向上を上回る場合もある。さらに、新技術のポテンシャルを最大限に 活用するための組織やプロセスの改革が伴わない場合、その効果が限定的になる ことも指摘されている。 • したがって、「Productivity Paradox」は、単に新技術を導入するだけでは不十分 であり、その技術を最大限に活用するための戦略的なアプローチが必要であるこ とを示唆している。 Productivity Paradox (Solow paradox)
117. 117 【事例③】生産性のパラドックス 開発生産性が期待よりも低いと、次のような疑念が囁かれはじめた スクラムだか ら遅い 会議が多すぎる 人員配置がう まくないのか なぁ？ 1on1が多すぎ では？ えらい人
118. 118 【事例③】生産性のパラドックス 開発生産性が期待よりも低いと、次のような疑念が囁かれはじめた スクラムだか ら遅い 会議が多すぎる 人員配置がう まくないのか なぁ？ 1on1が多すぎ では？ えらい人 これらは印象では？
119. 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. 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. 121 【事例③】エビデンスベースドマネジメント（EBM） 重要価値領域(KVA) 市場に出すまでの時間（反応性） (T2M: Time to Market) 新しい能力、サービス、製品を迅速 に提供する能力 イノベーションの能力（効果性） (A2I: Ability to Innovate) 顧客やユーザーのニーズにより良く 応えられるような新しい能力を提供 する能力 現在の価値 (CV: Current Value) 現在、顧客やユーザーに提供された 価値 未実現の価値 (UV: Unrealized Value) 顧客やユーザーの潜在的なニーズを すべて満たすことによって実現しう る価値
122. 122 【事例③】エビデンスベースドマネジメント（EBM） 重要価値領域(KVA) 市場に出すまでの時間（反応性） (T2M: Time to Market) 新しい能力、サービス、製品を迅速 に提供する能力 イノベーションの能力（効果性） (A2I: Ability to Innovate) 顧客やユーザーのニーズにより良く 応えられるような新しい能力を提供 する能力 現在の価値 (CV: Current Value) 現在、顧客やユーザーに提供された 価値 未実現の価値 (UV: Unrealized Value) 顧客やユーザーの潜在的なニーズを すべて満たすことによって実現しう る価値 市場価値 組織的な能力
123. 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. 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. 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. 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. 127 【事例③】時間の使い方に問題がありそう 同時に複数のタスクを進 めている 作業はしている！しかし どれも終わらない
128. 128 【事例③】時間の使い方に問題がありそう 同時に複数のタスクを進 めている 頻繁に会議がはいる 作業はしている！しかし どれも終わらない 頻繁に作業が中断する
129. 129 【事例③】時間の使い方に問題がありそう 同時に複数のタスクを進 めている 頻繁に会議がはいる Slackでの問合わせや調査 依頼が毎日何件もくる 作業はしている！しかし どれも終わらない 頻繁に作業が中断する 割り込み作業が発生する
130. 130 【事例③】時間の使い方に問題がありそう 同時に複数のタスクを進 めている 頻繁に会議がはいる Slackでの問合わせや調査 依頼が毎日何件もくる 作業はしている！しかし どれも終わらない 頻繁に作業が中断する 割り込み作業が発生する プロダクト開発に集中する時間がとれない 迅速なデリバリーが出来ない
131. 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. 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. 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. 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.
135. Four Keysでは見えないところ 事例④ 135
136. 136 【事例④】Four Keysでは見えないところ • 変更リードタイムの長いチームがあった • ケイパビリティ調査では「プロセス」カテゴリ全体的に低かった • エセ自己組織化に陥っていた https://speakerdeck.com/visional_engineering_and_design/number-rsgt2023
137. DevOps Four Keys 137 【事例④】Four Keysでは見えないところ リードタイム 変更リードタイム 変更失敗率 デプロイ失敗からの 回復時間 デプロイ頻度 信頼性 企画 計画 実装 テスト デプロイ 運用 設計 障害〜復旧 変更リードタイムを向上させるためには、 プロダクト開発全体の仕事の流れを理解する必要がある
138. 138 【事例④】現状を見えるようにする DanielPenfield, CC BY-SA 3.0 <https://creativecommons.org/licenses/by-sa/3.0>, via Wikimedia Commons
139. 139 【事例④】現状を見えるようにする • Value Stream Mapping • 製品が顧客に届くまでの「もの」と「仕事」の流れを可視化したもの • プロダクト開発関係者でお客様にプロダクトが届くまでのプロセスを明らかにし、 現状認識を揃える
140. 140 【事例④】ボトルネックを発見する 可視化の目的 1. 共通認識を形成する 2. ボトルネックを発見する 3. ボトルネックをカイゼンする 4. リードタイムを短縮する= フ ロー効率の向上 ボトルネック = 流れが悪くなるところ This is Lean: Resolving the Efficiency Paradox（ Niklas Modig (著), Par Ahlstrom (著), Rheologica Publishing, 2012）
141. 141 【事例④】ボトルネックを発見する 7つのムダ 1. つくり過ぎのムダ 2. 手待ちのムダ 3. 運搬のムダ 4. 加工のムダ 6. 動作のムダ 7. 不良をつくるムダ 5. 在庫のムダ 例 使わない機能をつくる 承認待ちで開発作業にはいれない 他チーム、他部門へ引き継ぎをする 不要な成果物を作成する 同時に複数のタスクに着手する 不要な作業をおこなう 不具合の修正をする トヨタ生産方式-脱規模の経営を目指して-（ 大野耐一 (著), ダイヤモンド社, 1978）
142. 142 【事例④】ボトルネックをカイゼンする 02:Combine 03:Rearrange 04:Simplify 01:Elimate やめる 結合 入れ替え 簡素化
143. 中間成果物を探せ！ 事例⑤ 143
144. リリース1 リリース2 リリース3 ②リリース計画 ③イテレーション 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 （参考）PMBOKガイド第7版の図2-17 を加工して作成 どうやって見積もるか？ 機能や過去の経験に基づいて見積もると 成果物のことを忘れがち。
145. 145 【事例⑤】中間成果物を探せ！ • ケイパビリティ調査の「ドキュメンテーション」の設問は低いチームが多い • 必要だと思ったときに必要なものを作っているため、決まった成果物が定義されていない • 前述のValue Stream Mapping を実施してみてきづいたこと • 中間成果物の話しが全然でてこない！ • アクティビティと細かいタスクばかりが目立つ • 代表的な成果物は「会議での話し合い」と「プロダクトバックログ」と「ソースコード」 • 中間成果物がないわけではない。意識していないだけ。 最初から「すべての」中間成果物を見極めるのは無理。 だからといって、現時点でわかる範囲の成果物見極めをあきらめてはだめ。 アジャイルな計画づくりでは、今わかる成果物の 目的確認や優先順位を整理することが大事 要因：見積もるべき中間成果物が見えていない
146. 146 【事例⑤】中間成果物を見出す • PRINCE2は成果物指向のプロジェクトマネジメント・アプローチ • 計画書から成果物の定義と分析を行い、すべての成果物を階層化し、成果物ブレークダウン・ス トラクチャ（PBS）を作成する （参考）:「成功のためのプロジェクトマネジメント・手法 PRINCE2」付録Dより
147. 147 【事例⑤】中間成果物を見出す • Process Flow Diagram（PFD） • 成果物連鎖のシュミレーションができ、不足している成果物やムダな成果物の発見ができる • PFDは清水吉男さんが発案したプロセス設計記法 • （参考） https://affordd.jp/koha_hp/process/PFDform3.pdf • 中間成果物を見いだせれば、見積もりのブレが低減する • 作業時間＝成果物の質量／単位時間あたりの生産性 成果物α 仕様化 プロセス 設計 プロセス テスト プロセス 成果物β 成果物γ 成果物δ 成果物ε in out in in out out in
148. まとめ 148
149. 149 まとめ • アジャイル開発が失敗するのは「推力＝チーム性能」が満たされる前に、あれや これや考えすぎてるときが多い • まずは、重力に負けない推力を手に入れよう！ • チーム性能が高ければ、ロードマップ（約束）を守れるチームになれる • 価値を作れるのは推力を手に入れてるから！ 生産性よりチームの性能向上を目指す
150. 150 まとめ • これ絶対忘れちゃだめ • 忘れるとFour Kyesを測ったあと迷子になりやすい • 「LeanとDevOpsの科学」は読むたびに新たな発見がある良書（つまり難解） • 付録A、B、Cを最初に読むのがオススメ Four Keys はケイパビリティと統計的相関がある Four Keys 27のケイパビリティ 統計的相関 推力
151. 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. 152 まとめ • SODAは、ITエンジニアに向けた、問題解決のための知識体系を提供するエピッ ク集です。クリエイティブ・コモンズだよ。 • これにより、プロダクト開発組織は人材育成の仕組みを整え、生産性を向上させ、学習文化を育 むことが容易になります。 • 偉い人のアンラーニングにも役に立つ SPI活動にはSODAを利用しよう。そーだ！そーだ！ テーラリング
153. 153 天国にいるお二人へ 多田洋祐さん、とりあえずベースラインは整いました。あのときGo!と言ってくたおかげです。 データをお見せできないのが悔やまれます。 西康晴さん、SODAが構想レベルだったときに褒めてくださったから、モチベーション高くここまで来れました。 実況をXに書き込んでくださいましたか？それ読んでクスッとしたいです。 これからも私たちはソフトウェア業界に貢献できるようがんばります。