こんにちは、株式会社ビズリーチでプロセス改善活動をしている賀茂といいます。 少し前になりますが、2022年4月21日にDevOpsDays Tokyo 2022にて発表をしたので、発表内容の補足と発表後に会場の方からもらった質問について答えたいと思います。

発表内容について

今回は『ファクトから始める改善アプローチ 〜「LeanとDevOpsの科学」を実践して〜 』と題して「LeanとDevOpsの科学」という書籍の実践事例を発表してきました。

「LeanとDevOpsの科学」について

前提として今回の取り組みは「LeanとDevOpsの科学」という本を参考にしています。

「accelerateの紹介」

「LeanとDevOpsの科学」では開発組織のパフォーマンスを測る指標(Four keys)とFour keysを高めるための能力(ケイパビリティ)について言及しています。
私達SPI(ソフトウェアプロセス改善)グループはプロダクトチームと協力してFour keysとケイパビリティの計測を行っていて、 今回の取り組みは、計測を通して、効果的な改善をサポートし、「計測からわかったファクトを用いて改善を進める文化」を強化するのが狙いでした。

「fourkeys
「27のケイパビリティ」

ちなみに原書の「ACCELERATE」は文字通り「加速する」という意味合いがあり、計測は自分達の改善活動を加速させるためのものと捉えています。 後述しますが、プロダクトチーム向けに行った計測活動の説明会では、「計測は他組織と比較するのではなく、あくまで自チームの改善活動を加速させるためのもの」と説明していました。

計測について

計測方法の詳細は資料に記載しているので割愛しますが、計測仕様を決める際のポイントについては、時間の問題でお話できなかったので少し補足したいと思います。 計測仕様はチームと議論しながら決めたのですが、仕様を決める上で以下の2点が重要です。

順を追って説明します。
まず1点目についてですが、計測を円滑に実施する上で各指標に関する認識を関係者で揃えることが大事です。 例えばあるプロダクトチームでのリードタイムの議論時には、下図のように構成要素を可視化しました。

リードタイムに関する構成図

リードタイムという言葉自体、定義が曖昧になりやすく、どこからどこを指すのかわかりにくいのですが、このように可視化することで認識を合わせやすくなります。

2点目についてですが、可視化できたからといって、それらを全て計測するとは限りません。
リードタイムを例に出すと、Pull Request Lead Time(上図参照)はGitHub上のデータを収集することで計測できるものの、ステージング環境へのデプロイ以降のプロセスの計測は難しいのではないかという話になりました。 (厳密には計測できなくもないのですが、手間がかかるので、どこまで厳密に計測するか議論になりました。)
「どこまで厳密に測るべきか」は組織の状況などによって異なるので何がベストか一概に言えないのですが、 今回の事例でいうと各種環境へのデプロイ時間は大体一定なので、計測は行わず、Pull Request Lead Timeに一定のデプロイ時間をプラスした数値をリードタイムにしよう、という結論に至りました。

厳密さは重要ですが、こだわりすぎると計測疲れを起こし前に進まなくなる可能性もあるため、 あくまで計測の目的を確認しつつどこまで厳密に計測するのかは適宜議論しながら計測仕様を決めていくのが大事だと考えています。

会場で出た質問に対する回答

発表後にいくつかの質問をいただいたので、この場を借りて回答したいと思います。

最初にチームを巻き込む時どのように説明しましたか?

まずは説明会を開き、計測の概要、なぜ計測するのかについて説明する場を設けました。

計測に関する説明会

また、「計測結果は他組織と比較はしない」ということも伝えています。 チームの立場からすると他と比較されてしまい、できていない部分を指摘される(場合によっては責められる)可能性を感じてしまい、人によっては嫌だなと感じる方もいると思います。 (実際に会場で、「今回の活動をチームでやろうとしたら嫌がりそうだけど、拒否反応示す人はいなかったのですか?」と聞かれました。)
だからこそ、今回の計測では横で比較するのではなく、あくまで自分達の中で結果を見て改善を進めるための計測だと計測の本来の意義を伝えることで、安心して協力しあう土壌を作れるよう心がけました。

計測をした後、ボトルネックがどこか見つけにいくと思いますが、開発チーム以外にボトルネックがあった場合どのように見つけるつもりですか?

開発組織のボトルネックについてはケイパビリティ計測で判明する場合もありますが、ケイパビリティ自体開発組織に寄ったものが多いため、開発組織以外も巻き込む必要があります。 登壇時にもお話させていただきましたが、バリューストリームマッピングを実施し現状を可視化することが重要かなと考えています。この辺りは今後実施予定なので、機会があれば来年お話できたらなと思っています。

バリューストリームマッピングによる問題の可視化

おわりに

今回はDevOpsDays Tokyo 2022での発表について執筆させていただきました。 計測活動の取り組みはまだまだ道半ばなので、是非計測活動をしている方がいましたら知見を共有しあいたいので連絡いただけますと嬉しいです! また、一緒に開発組織のプロセス改善活動を推進していく仲間も募集しているので、気になる方は是非こちらからご連絡ください!

賀茂 慎一郎
賀茂 慎一郎

2020年にBizreachに入社。以後スクラム・アジャイルを専門にチーム支援に従事。現在はSPIグループの一員としてプロセス改善活動を実施している。