プロダクト価値を最大化するスクラムチームの組織づくりに迫る。Four Keys向上を目指すダイキン工業の取り組み
世界170ヵ国以上で事業を展開するグローバル空調総合メーカー、ダイキン工業株式会社。その中でもR&Dの最前線であるテクノロジーイノベーションセンター（TIC）において、エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用いただいています。
今回は、TIC内の空調データを活用したソリューションに取り組むチームで開発兼スクラムマスターを務める、笹原さんと平松さんにインタビュー。開発生産性の計測に取り組んだ背景や、「Findy Team+」の活用方法などについてお話をうかがいました。
目次
2つのスクラムチームで、社内向けのプロダクトを開発
――まず最初に、お二人のご経歴や現在の役割を教えてください。
笹原：ダイキン工業に新卒で入社し、現在5年目となります。役割は開発者兼スクラムマスターです。
平松：笹原と同期で、入社5年目になります。現在は、開発者兼スクラムマスターを担っております。
――所属しているチームの規模や体制について教えていただけますか？
笹原：私たちは、空調データを活用したEneFocus αというプロダクトの開発を行っています。開発は2つのスクラムチームで行っており、両チームそれぞれプロダクトオーナーが1人、スクラムマスターが1人、開発が4人という、6人チーム体制です。これに加えて、両チームを見るアジャイルコーチが1人います。
平松：各スクラムチーム間では課題や良かった取り組みを共有し合っています。
――スクラムチームを立ち上げられたのは、どういった背景があったのでしょうか？
平松：チーム内で課題の改善が中々進まなかったという背景があります。属人化により、担当者がいなくなったら誰もわからなくなる機能がいくつもある、といった状況をチームとして改善していきたいと考え、スクラムを始めました。
――チームの特徴を教えていただけますか？
笹原：チーム全員がプロダクト価値に本気で向き合っているという特徴があります。プロダクトオーナーだけでなく、開発者もプロダクト価値を高めることに対して強い意識を持っており、実際に、ステークホルダーと開発者が頻繁に会話したり、開発者からプロダクトの今後に関する意見が出たりすることも多くあります。
――チームでそういった意識を持つために、どのような工夫をされたのでしょうか？
平松：ステークホルダーと密に関わるようにする、スプリントゴールをプロダクト価値を意識・検査しやすいような文言に変えるなど、各チームで開発者がプロダクト価値にコミットしやすくなるような仕組みを整えていきました。 また、それらの施策を毎週のスクラムマスターどうしの相談会で共有し、別のチームの効果的な取り組みを即座に取り入れていきました。
――両チームが開発しているプロダクトや、それによって実現しようとしていることを教えてください。
平松：弊社には、空調機の運用方法について改善提案・運用するEneFocus αというサービスがあり、そのサービスを手助けするためのプロダクトを作っています。プロダクトを通じて、EneFocus αの契約数を増やしていくことを目的としています。
――社内向けのプロダクトで、社内の方々がエンドユーザーということでしょうか。
平松：はい、そうです。
「Findy Team+」の導入で、より具体的な議論＆改善へ
――「Findy Team+」を導入いただいた背景や、開発生産性の計測に取り組む前にあった課題について教えてください。
笹原：私たちのチームでは「Findy Team+」を導入する前からスクラムを始めており、ふりかえりを非常に大切にしてきました。しかし、ふりかえりで開発プロセスについて議論する際、どうしても感覚ベースでの話になってしまい、実際の改善につなげるのが難しいという状況がありました。
例えば、プルリクエストのレビュー依頼を出してから、しばらくレビューされなかった気がするとか。このチームって、どれくらいの速度でリリースできているんだろうとか。課題や疑問に感じたことが実際に起こっていることなのかわからない、といった話が何度か出てきていたのです。
そのため、定量的なメトリクスを可視化することで、確実なボトルネックを見つけやすくしたいという思いがあり、事実ベースで議論することにより、より具体的な改善につなげられることを期待して、「Findy Team+」を導入しました。
――開発生産性の計測を通じて、どういったゴールを設定されていますか？
笹原：結局、事業部門にいかに価値を出せたか、ということが真のゴールだと考えており、それはスクラムのプロダクトゴールとして設定しています。その価値を出すための大切な要素の1つに、ソフトウェアをいかに迅速かつ確実にデリバリーできるか、という点があると思います。開発生産性の計測は、実装した機能をいかに迅速かつ確実にデリバリーできているかを確認するために行っており、開発生産性の観点でのゴールはそこだと考えております。
――「Findy Team+」の導入後、現場の皆さんの理解はすぐに得られましたか？
平松：すぐには得られませんでした。単に「Four Keysの値を上げていこう」と提案するだけでは、なぜそれを上げなければならないかが伝わりません。他社での事例を伝えても、「自分たちのチーム状況とは違うのに、それを真似したところで本当に意味があるのか？」など、スムーズに理解を得られない部分も多くありました。
――そういったところは、どのようなアプローチで解決していきましたか？
平松：Four Keysの値を見てというよりは、実際の開発プロセスで起きていることをベースに改善していきました。
例えば、メインブランチのマージが大きくなってしまい、それが理由で修正に大量の時間がかかってしまうことが何度かありました。これはデプロイ頻度を上げて、変更差分を小さくすることによって解決でき、チームとしてメリットを実体験として感じることができました。
このようにチームの課題を解決した結果としてFour Keysの値が上がっていく、という流れに持っていけたことが良かったと思います。
特に注目するのは、デプロイ頻度と変更のリードタイム
――現在、「Findy Team+」をどういった形で活用いただいていますか？
笹原：毎週のチームのふりかえりで、「Findy Team+」を使って指標を確認しています。具体的には、まずFour Keysの確認をして、現状の共有をします。Four Keysのなかでも、特にデプロイ頻度と変更のリードタイムに注目して、それぞれの増減の原因を見るようにしています。
デプロイ頻度に関してはプルリクエストの数、変更のリードタイムに関してはサイクルタイムを参照し、さらにそこから詳細なプルリクエストまで追っていくようにしています。Four Keysの目標としては「Elite」ランクで、デプロイ頻度が2件、変更のリードタイムが24時間以内を目指しています。
――プルリクエストの作成数にも、具体的な目標を設定されていますか？
笹原：設定しています。最初はFour Keysの目標だけを設定していたのですが、開発メンバーにとってはイメージが湧きづらかったようでした。デプロイ頻度2件と言われても、実際に1日1人当たりどれくらいのプルリクエストを作ったらいいのかわからないという声が、ふりかえりであがっていました。
そこで、目標のデプロイ頻度と現状のプルリクエストの粒度から逆算して、現在は1日1人あたり3プルリクエスト作成するという目標を立てています。
――デプロイ頻度とリードタイム以外に、例えば変更障害率や平均修復時間などにも目標を設定されていますか？
笹原：もちろん安定性に関する指標にも目標を設定しております。ただし、変更障害率と平均修復時間に関してはすでに目標を達成できているので、現在は達成できていないスピードに関する指標に注目しています。
平松：変更障害率と平均修復時間は現在「Elite」の状態ではあるのですが、スピードを上げることによって下がらないかは見ています。速度と安定性は、どちらかを上げてどちらかが下がってしまうと意味がないので、意識するようにしています。
――そのほかにも、Four Keysを向上するために注目している観点はありますか？
平松：私のチームでは、デプロイ頻度が低いことが課題になっています。今の開発方法では、プルリクエスト数を増やすだけではデプロイ頻度は向上しないと考え、1日でデプロイできる単位をより細かく分けていくことに意識して取り組んでいます。
これまでは機能としてまとまった単位でデプロイしていたのですが、さらに分割してデプロイできないかをチームで話し合うようにしました。
例えば、クラスが複数あった場合に、それらが全て完成しないとデプロイできないのか、といったことを突き詰めていくイメージです。
デプロイ頻度は、「Findy Team+」導入時から2倍以上に
――「Findy Team+」の活用を通じて、改善された結果について教えてください。
笹原：プルリクエストの作成数が上がりました。その一方で、スクラムにおけるベロシティは変わっていないので、プルリクエストをより細分化できていると思います。それがFour Keysの値や、レビュー精度の向上にもつながっています。
――実際に「Findy Team+」上で、直近半年の1人当たりのプルリクエスト作成数（棒グラフ）を見てみると、導入時は1人当たり約1件だったのが、最近では1.8件～1.9件と継続的に向上できていることがわかります。
――続いてデプロイ頻度を見ると、導入時は1日当たり0.6件ほどでしたが、直近では2件を超え、3倍以上のデプロイ頻度が実現できています。ここまでにお話いただいた以外にも、デプロイ頻度が上がった理由として考えられる要素はありますか？
平松：開発チームでデプロイ権限を持てるようにユーザーと交渉したことが大きな要因だったと思います。以前までは、2週間に1回のスプリントレビュー後に機能をまとめてデプロイするルールとなっており、それ以上はデプロイ頻度が上がらないという状況でした。
――ユーザーとの交渉はスムーズに進みましたか？
平松：このルールだと何が良くないのかを明確に説明できたので、特に苦戦はしませんでした。
2週間かけて作った機能すべてがデプロイされ、そこで初めてバグに気づいた場合、手戻りは大きく、修正には大量の時間がかかってしまいます。しかし、より早い段階でデプロイできれば、その時点でのフィードバックを得ることができ、進路変更を早期に行えます。その結果、全体のリードタイムが大きく短縮されるということを伝えました。
今後のトライは、可視化する文化を社内で広げていくこと
――開発生産性向上のための取り組みのなかで、難しかったことはありましたか？
平松：デプロイ頻度が上がらない要因に中々気づけなかった点です。開発者個人の能力に目が向きがちになってしまい、開発プロセスやデプロイ方法といった本質的な問題にフォーカスできるようになるまでに時間がかかりました。
――どういったきっかけで、開発プロセスやデプロイ方法に目線を合わせられたのでしょうか？
平松：スクラムマスターとして、開発者の頑張りを間近で見ていた一方で、チームのデプロイ頻度が0.6件である事実を目の当たりにした時に、個人の能力の問題ではないと推測しました。 その後、チームでふりかえりをしたことで、根本的な開発プロセスやデプロイ方法に目を向けることができました。
――今後さらにトライしていきたいと考えていることがあれば教えてください。
笹原：現状、FindyTeam+を利用する前提となる文化が社内に浸透していません。まずは「実装した機能を迅速かつ確実にデリバリーできているかを計測して可視化する」というDevOpsの文化そのものを、社内で広めていくことにトライしていきたいです。
――そのために今必要だと感じることや、ハードルになっていることはありますか？
笹原：内製化しているチームが少ないという構造的なハードルと、DevOpsやアジャイルの考え方が根付いていないというマインドセットのハードルがあります。前者に関しては、すぐに変えることは難しいので、現在は後者のマインドセットの転換に取り組んでおります。具体的には、社内コミュニティを立ち上げ、毎週1時間、チーム開発で得た知見や文化を共有・議論するイベントを開催しております。
――最後に、御社のアピールポイントがありましたらお願いします。
平松：開発チームができたのは3年ほど前なのですが、ソフトウェア開発をしたことがないメンバーの集まりで、試行錯誤しながらスクラム体制をつくってきました。自分たちで考えたり調べたりして、今の体制をつくり上げてきたという自負があります。
笹原：自由度がとても高く、自律性を感じられる環境です。マイクロマネジメントされるようなことはなく、意思決定がチームに委ねられており、働きやすい環境が整っています。
平松：ダイキンはデジタル分野に関わる重要テーマを推進する人材を募集しております。技術の力で組織を変えたいエンジニアやマネージャーの方には、ぜひ応募の検討をしてほしいと思っております。
――笹原さん、平松さん、ありがとうございました！
※ダイキン工業の採用ページでは技術の力で組織を変えたいエンジニアを募集しています。 https://www.daikin.co.jp/recruit
※「Findy Team+」のサービス詳細は、以下よりご覧いただけます。 https://findy-team.io/service_introduction
