「質とスピード」を両立するためのKPIと少しの工夫で組織を改善
デブサミ2020で和田拓人氏が「質とスピード」という講演を行い、その中でリードタイム、デプロイ頻度、MTTR(平均修復時間)、変更失敗率という4つのキーメトリックスを紹介した。これは2018年に出版された『LeanとDevOpsの科学』という書籍に書かれており、この内容はDX Criteriaからも数多く参照されている。「ソフトウェア企業ではよく使われており、開発スタイルと市場占有率や収益性などの企業パフォーマンスとの関係性を科学的に証明する試みです」と高山氏。
より高速かつ安全に仮説検証できる組織がエリート組織となる。高速とは、開発に迷わない、待たない、無駄なコミュニケーションが発生しないこと。安全は、意識しなくてもセキュリティが保たれ、大きな障害に至らず心理的な安全が保たれることだ。これらが示されているこの書籍が「凄く良いものなので、入社前から社内に布教し、この本の通りにやりますとして始めました」と高山氏。
4つのキーメトリックスに関して、エリートとローパフォーマーの組織間にはデプロイ頻度で208倍、MTTRは1/2604など大きな差がある。リードタイムとデプロイ頻度は開発速度に、MTTRと変更失敗率は品質に関する指標だ。高速に開発できる組織は品質も高くトレードオフ関係にはない。
この4つを計測して組織を改善したいが、4つ全ての計測にはかなり手間がかかる。それぞれのキーメトリックスで計測の難易度も異なり、リードタイムやMTTRの計測はかなり難しい。一方デプロイ頻度は定義が明確で比較的ばらつきも少なく計測は容易だ。書籍から高速かつ安全に開発できるエリート組織は全ての指標が高いことが分かっており、「極論すれば、どれか1つだけを計測すれば十分ではと考え、デプロイ頻度をKPIとし、品質に関するエラー数やSLO(Service Level Objective)などの指標も観測して品質の低下傾向がなければ良しとすることにしました」と高山氏は説明する。
定点観測をすると1週間のデプロイ頻度が見え、またボトルネックが何かも分かる。たとえば、以前はデプロイのためにSSHで接続しコマンドを実行していた。それがボトルネックだと分かり「マージされたらbotが動き、Slackで確認などのやりとりをすれば自動的にデプロイするよう変更しました」と高山氏。このように一つ一つボトルネックを解消した結果、1回のデプロイ作業に30分から1時間かかっていたものが5分に短縮された。開発者1人当たりのデプロイ頻度も2倍から3倍に増え、権限の低い人でも安全にデプロイできるようになった。デプロイ頻度を上げたことで、結果として安全性が増したのだ。
「それぞれが改善の取り組みを実現すればきちんと称えるようにし、全員でデプロイを良くしていこうとの意識が芽生え、それが必然的に高速、安全にもなりチームの雰囲気が変わりました」(高山氏)
高速にできるだけでなく、安全も大事だ。高速だけに偏ると、もう片方がおろそかになりエラーを放置してでも開発しなければとのプレッシャーになりかねない。それでは本末転倒なので、アクセスとブレーキを踏み分けられることが重要だと言う。エラー数、レスポンスタイム、スマホアプリのCrash Free率、セキュリティリスクアセスメントの自動化、お問い合わせ起因のチケットの生存期間といった品質に関わる指標を定点観測し、これらが悪化傾向になければOKとした。品質が悪くなっていなければ、高速化により品質はおのずと向上するからだ。その上で、MTTRや変更失敗率の指数関数的な改善は、今後の課題としている。
このような取り組みを1年続けた結果、DX Criteriaの自己診断結果は劇的に改善している。全体的に改善傾向にあるが、特にデプロイに関するシステム部分の改善は大きくチームとしても良くなっている。この結果から「CTOとしての信頼を勝ち取れたかなと思っています」と高山氏は言う。
最後に、ソフトウェア開発組織運営のための「DX Criteria」「LeanとDevOpsの科学」という凄く良くできたテンプレートがあり、これをぜひ参考にして欲しい。これらを使えば、突然組織のCTOに抜擢されても大丈夫だと言う。そして多くの場合、デプロイ頻度をKPIにするのは効果的だと薦める。CTOとして最も重要な責任は、会社の未来を左右する大きな技術投資を間違えないこと。とはいえ短期トレンドの見極めは難しい。なので、いつでも変わらずに必要となる技術に投資する。それがより高速かつ安全に開発できるためのデプロイや品質のための技術であり、それらに投資すべきだと言うことが伝えられた。