「Four Keysメトリクス」に基づく品質・生産性向上活動
リンクアンドモチベーションは組織人事コンサルティングのノウハウを活用した組織改善クラウドサービス「モチベーションクラウド」を主力商品に掲げ、2016年よりその提供を始めている。当初はその開発を外部パートナーへ依頼していたが、2018年より内製化を進め、さらに2020年にはSREチームを発足させてサービスの品質や開発生産性の向上活動に取り組むようになった。
この活動を展開するために同社が新たに取り入れたのが、「Four Keysメトリクス」と呼ばれる手法だ。これはGoogle CloudでDevOpsに関する研究・調査を行っている組織「DevOps Research and Assessment（DORA）」が提唱する手法で、ソフトウェア開発チームのパフォーマンスをその名の通り「4つの主要な指標」によって定量化・可視化するものだ。
具体的には、本番環境へのリリースの頻度を示す「デプロイ頻度」、First Commitから本番環境稼働までの所要時間を表す「リードタイム」、デプロイが原因で本番環境で障害が発生した割合を示す「変更障害率」、そして本番環境で発生した障害から回復するのに要した平均時間を示す「MTTR」の4つの指標を設けている。そしてこれらの指標の計測値を基に、組織のパフォーマンスを「Low」「Medium」「High」の3段階で評価する。
リンクアンドモチベーションは2022年末に晴れてHighレベルに到達したが、2018年に内製化をスタートさせた時点ではLowレベルでのスタート。その後さまざまな改善活動を展開してきたものの2021年の時点ではMediumレベルに留まっていた。当時抱えていた課題について、川津氏は次のように振り返る。
「当初はSREチームが自分たちだけでインフラやCI/CDの改善策を検討して、それを開発チームに展開していたので、どうしてもインフラ寄りの施策に偏りがちでした。そこからHighレベルを目指していくためには、どうしても開発やテストの改善も必要でした。しかし開発者は皆自分たちの仕事で忙しく、なかなか改善活動にまで手が回らないのが実情でした」
そこで同社では、SREと開発者が「協働」して品質・生産性改善に積極的に取り組んでいけるよう、次の3つの施策に力を入れてきた。
メトリクスを共有するためのダッシュボードを新たに構築
まず1つ目の施策として、開発生産性・メトリクスの基準を開発組織全体で統一した。一口に「開発生産性が高い・低い」と言っても、その基準が明確に定義されていないとそれぞれの主観に基づき評価・判断するしかなく、SREと開発者のように立場が異なる者同士では、正確なコミュニケーションがなかなか成立しない。この課題を解決するために導入したのが前出のFour Keysメトリクスであり、先ほど挙げた4つの指標を「共通言語」としてSREと開発者とが互いに正確なコミュニケーションを取れるようにした。
この施策を推進するために新たに構築したのが、これら4つの指標をSREと開発者とで共有するためのダッシュボードの仕組みだ。指標のデータを収集・可視化するための仕組みは以前からあったものの、手動でスプレッドシートを更新する運用となっており、データの量や正確性、タイムリー性に問題があったため、開発者に浸透しなかった。そこでこれをシステム化し、自動的にメトリクスを収集・集計・可視化する仕組みを新たに構築することにした。
具体的にはGitHubからリードタイムとデプロイ頻度に関するデータを、そしてスプレッドシートの帳票からMTTRと変更障害率のデータを自動的に収集し、既に社内で展開していたGoogle Workspaceのスプレッドシートアプリ上で集計した。その内容をGoogle Looker Studioを使って自動的にダッシュボード化し、ビジュアルな形式で誰もが一目で指標値をタイムリーに把握できる仕組みを新たに構築した。
これら一連の仕組みを実現するに当たっては、「全自動」「リアルタイム性」「変更容易性」という点にこだわった。
「メトリクスの集計作業自体が負担にならないよう全自動化すること、そして開発者が見たい時にいつでも正確な情報が参照できるリアルタイム性の実現を必須要件に挙げていました。また組織体制やプロセスが変わるとメトリクスの計測方法も変わるため、変更を容易にしておくことも重要でした。その点Google Looker Studioのようにノーコードでダッシュボードを開発できる仕組みは、私たちのニーズに合致していました」（川津氏）
SREと開発を横断する協働チームを新たに創設
2つ目の施策としては、改善活動を「皆の目標」とするようにした。開発チームにとってはサービスデリバリやインシデント対応が主たるミッションであるため、生産性の改善活動はどうしても後回しになりがちだ。そこでSREチームとの温度差を解消し、改善活動をSREと開発者双方にとって共通の目標とするために、SREチームと開発チームを横断するチームを新設した。
各開発チームから協力者を募り、SREチームのメンバーとともに改善活動のための明確なチーム・役割・責務を定義した。ここで最も重要視したのが、「改善をボランティア活動にしない」ことだった。
「ボランティアではなく、正式な仕事としてアサインすることで、開発者も日々の開発の仕事と並行して改善活動に堂々と関われるようになります」（川津氏）
また「Embedded SRE」と呼ばれる取り組みも新たに始めた。これはSREのメンバーが開発チームの中に直接入って、1カ月なり2カ月の間実際にチームの一員として働くことで、そのチームの中に潜む品質や生産性にまつわる潜在的な課題を掘り出すという取り組みだ。
同社のクラウドサービスで一時期変更障害率が高まったときがあり、なかなか原因がつかめずにいたが、このEmbedded SREの手法を取り入れてSREのメンバーが一定期間開発チームに入り込んで一緒に働いてみたところ、隠れた原因をあぶり出して無事対処できた。
メトリクスの数値を追うことが目的化してしまってはいけない
3つ目の施策としては、メトリクスの数値を向上させる意味と目的を広く共有するようにした。メトリクスを定義してその値を追うことは、改善活動を進める上で有効である半面、その運用が形骸化すると表面的な数値を上げること自体が目的化してしまい、そのメトリクスを設置した本来の目的が忘れられてしまいがちだ。
同社でもFour Keysメトリクスを導入した当初は、リードタイムの数値を上げることが目的化してしまった結果、「作業途中で中断した実装作業を、後に再開したときにPRをあらためて作り直して短いリードタイムを達成する」といったように、リードタイムの数値を上げることを完全に目的化とした運用がまかり通っていた。
そこで川津氏らは、同社でリードタイム短縮を目指す本来の目的を周知させるために、さまざまな場を借りて社内各所に説明して回った。
「弊社がリードタイム短縮を目指すのは、機能を限定したスモールリリースを繰り返すことで障害を減らし、かつリリースの複雑性を減らしたいからです。この目的に皆で立ち返れるよう、社内で何度も繰り返し説明しました」（川津氏）
ちなみに一般的には、このような品質向上活動は開発のスピードや効率と相反すると思われがちだが、例えば品質向上のために自動テストの仕組みを導入すれば結果として開発スピードも上がるように、むしろ「品質とスピードを表裏一体のものとしてとらえた方が良い」と川津氏は持論を述べる。
「Four Keysのような開発メトリクスを設けることで品質とスピードの関連性も見える化されますし、目標に対して今自分たちがどの地点にいるかを把握できることで改善活動全体を活性化できます。弊社でも『開発者が幸せを感じられる開発者体験』『高い開発者体験を提供できる組織』の実現に向けて、今後もメトリクスをベースにした改善活動を続けていきたいと考えています」（川津氏）
