大手空調メーカーでプロダクト価値にうるさい開発チームができるまで

大手空調メーカーで プロダクト価値にうるさい 開発チームができるまで ダイキン工業株式会社 テクノロジーイノベーションセンター 笹原 啓佑 平松 尚人

自己紹介 笹原 啓佑（Keisuke Sasahara） 平松 尚人（Naoto Hiramatsu） • ダイキン工業株式会社 • ダイキン工業株式会社 ‣ 開発（3年） ‣ 開発（3年） ‣ 開発 & スクラムマスター（1年半） ‣ 開発 & スクラムマスター（1年半） • 実家にエアコンがない • 自宅のエアコンは三菱 2

プロダクト紹介 ：空調運用改善のサブスクリプションサービス 3

開発体制 • サービス部門が顧客かつ最大のステークホルダー • プロダクトオーナーは開発部門所属 開発部門 提案支援 ツール開発 サービス部門 省エネ提案 スクラムチーム 4

チーム体制 • アジャイル内製化チーム ‣ ２つのスクラムチームによる開発 PO SM 開発 アジャイルコーチ PO SM 開発 5

チームの空気 それは何のために行うんでしたっけ？ • 基本ワイワイ • 言いたいことが言える • 良い意味でうるさい ‣ 技術 ‣ プロダクト価値 何を作るかじゃなくてどんな価値を 出せるかじゃないですかね？ 実装面から考えるとこっちの 方がいいと思います ユーザーからしたら その方が使いやすいと思います 6

プロダクト価値にうるさい 開発チームはいかにして生まれたのか 7

初期のチーム状態 ✅ スキルアップ志向 ✅ コーディングは楽しい ❌ プロダクトへの興味はない いつでも転職できるように スキルを磨いておこう 一人で黙々とコード書くのは楽しい ソフトウェア開発できるなら プロダクトはなんでもいい ❌ 仲は良いが一体感は薄い チームというより個人開発者集団 8

初期の働き方 • スクラムは未実施 • 属人的な開発 ‣ 開発者ごとにシステムの担当機能が存在 ‣ 作業計画が個人依存で隠蔽されている • デスマーチ ‣ キャパシティを無視した無理のある計画 開発プロセスで問題が頻発 9

開発プロセスの改善 あの機能でバグ出ているけど 今日担当者有休なんだよな • 属人性解消 ‣ 担当者依存をなくしたい あのタスクって進捗どう なっているんだろう ‣ 作業計画を透明化したい 改善する余裕がない・・・ • デスマーチ解消 ‣ 余裕を持ちたい スクラム開始 10

スクラム導入後の働き方 • 全てのタスクを全員が取れる • タスクの進捗を可視化 ➡ 全員で検査できるようになった • ベロシティーに基づいた無理のない計画 ➡ 自己研鑽やカイゼンの時間がとれるように スクラムによって開発プロセスが改善 11

スクラム導入後のチーム状態 ✅ 一体感が生まれてきた ✅ スキルアップ志向 ✅ チーム開発は楽しい チームとして成長できてきている 最近は人に教えたりペアプロしたり するのも楽しい スクラム導入上手くいってる！ ❌ プロダクトへの興味は薄い 個人開発者集団からチームへ 12

スクラム研修受講 スクラムの目的は プロダクト価値を最大化すること 開発プロセスをよくするためだと思っていた... 現状プロダクトへの興味が薄いメンバーが多い けどどうしよう... プロセスを改善できてベロシティが高いから 完璧にうまくいっていると思っていた... 13

当時のスクラム プロダクトバックログリファインメント ステークホルダーの要望・優先度が そのままバックログに反映 スプリントプランニング スプリントゴール「(機能)を実装する」 デイリースクラム タスクの進捗確認だけが目的 スプリントレビュー ステークホルダーが不参加 スプリントレトロスペクティブ 主な議題は 「なぜタスクが終わらなかったか」 プロダクト価値を高める活動なし 14

プロダクト価値を高める意識を 持つために何をしたのか

ステークホルダーとチームの関わり改善 開発者はコードを書くだけで、ステークホルダーとの関わりが少ない ステークホルダーとの関わりをプロダクトオーナーに任せている ステークホルダーの前でデモを動かしていない 開発者もステークホルダーと対面で 話す機会を作ろう Citation: amazon.com 16

対面でのスプリントレビューを実施 • ステークホルダーに直接システムを触ってもらう • 開発者が複数人同行 • 開発者がファシリテート 開発したものが実際に使われているのを 見るとモチベーションが上がる ステークホルダーの価値につながるものを作る意識が上がる 17

ゴールに対する認識の変化 • ある日のスプリントゴール 「消費電力を棒グラフで可視化する機能を実装する」 可視化の実装方法が固定化されている 固定化された実装方法のタスクが終わらないと、ゴール達成できない ゴール達成できないスプリントが続き、タスクを消化することだけを意識してしまう そもそもスプリントゴールが タスク化されているのは良くないのでは？ スプリントゴールとは本来どうあるべきなのかをチームが考え始める 18

価値を意識できるスプリントゴール • 何を作るかではなく、なぜ作るかがわかる • 誰にとってどんな価値があるかを検査できる • 実現方法を固定しない ‣ 開発者が価値を意識しながら実装に取り組める 「（機能）を実装する」 「（価値）のために（ユーザー）が〇〇できる」 19

優先度管理方法の変化 Before 優先順位 1. 〇〇の機能 2. △△機能 優先順位 1. 〇〇の機能 2. △△機能 3. □□の機能 の順で開発してください 3. □□の機能 の順で開発してください 〇〇の機能はあまり使われていない PO サービス部門 ステークホルダーの要望・優先度がそのままバックログに反映 20

優先度管理方法の変化 After 〇〇, △△, □□の要望 をもらいました。 それぞれの価値を説明 します。〇〇は... PO 優先順位 1. 〇〇の機能 2. △△機能 3. □□の機能 の順で開発してください サービス部門 △△の機能の方が~の観点で価値が高いので 優先度上げた方がいいと思います POが価値に基づいて要望の優先度を決定 21

ふりかえりによる検査と適応 改善アクション • 毎日15分 スプリント中間と最後に1時間 • KPT（Keep Problem Try）でふりかえり • 実行可能な改善アクションに繋げる • 毎週改善アクションを決定 • 毎日改善アクションの検査 ➡ 問題を拾い上げて、改善アクションに落とし込める環境 プロダクトやスクラムの改善もあがってくるようになった 22

スクラム相談会の実施 アジャイルコーチ • 毎週ほぼ欠かさず実施（これまで60回実施） Keep Problem Try スプリントゴールへの 認識が変わってきています 開発者とステークホルダー との接点を増やしています SM SM 各チームの良かったことや気づきを即座に取り入れた 23

現在のスクラムプロセス Before プロダクトバックログ ステークホルダーの要望・優先度が リファインメント そのままバックログに反映 スプリントプランニング 「(機能)を実装する」 デイリースクラム タスクの進捗確認だけが目的 スプリントレビュー ステークホルダーが不参加 スプリント レトロスペクティブ 主な議題は 「なぜタスクが終わらなかったか」 After POが価値に基づいて 要望の優先度を決定 「(価値)のために〇〇できる」 スプリントゴール達成に向けた 進捗共有と検査が目的 ステークホルダーと 対面でレビュー 上記を改善する議題 24

現在のチーム状態 それは何のために行うんでしたっけ？ • プロダクト価値にうるさい • 一体感がある • チーム開発は楽しい 何を作るかじゃなくてどんな価値を 出せるかじゃないですかね？ 実装面から考えるとこっちの 方がいいと思います ユーザーからしたら その方が使いやすいと思います チームが同じ方向へ前進している 25

なぜ2つのチームがここまで変われたか • ステークホルダーとの関わり増加 • POを助ける意識 • 毎日のふりかえり • 毎週のスクラム相談会 26