開発生産性を３ヶ月で劇的に向上させた取り組み
こんにちは、amptalk 株式会社 CTO の鈴木です。
今月で amptalk は５期目を迎えました。GW 明けの８日に全社 kickoff を行い、各組織の前期振り返りと今期の共有方針を行いました。私も開発組織の生産性向上に関する取り組みを紹介したのですが、社内に留めておくのは勿体無い内容なためこちらの note で紹介します。
Four Keys について
私たちの開発組織では、開発生産性を測る指標の１つとして Four Keys を計測しています。Four Keys の詳しい説明は Google Cloud blog の記事がわかりやすいです。
デプロイの頻度 - 組織による正常な本番環境へのリリースの頻度
変更のリードタイム - commit から本番環境稼働までの所要時間
変更障害率 - デプロイが原因で本番環境で障害が発生する割合（%）
サービス復元時間 - 組織が本番環境での障害から回復するのにかかる時間
計測には Findy Team+ を活用しています。Four Keys を計測するツールは海外だと LinearB や cortex などがありますが、国内産だと Findy Team+ が一番有名かと思います。DORA チームが提供している OSS などを活用して自前で計測するのも１つの手段です。
もともと「変更障害率」や「サービス復元時間」といった安定性に関する指標は高水準を維持していましたが、「デプロイの頻度」や「変更のリードタイム」といった速度に関する指標については、Elite/High/Medium/Low で分類されるパフォーマンスレベルのうち High にとどまっていました。
顧客へ届けられる価値を最大化するため、開発組織の下半期 OKR として、これらの指標を Elite に押し上げることを掲げていました。
Objective:
Deliver high quality products to the market quickly.
Key Results:
~~
Ⅲ: Achieve ELITE on all four keys metrics.
As a product team, we will enhance the value we can offer. As an indicator of this, we will use the metrics called “Four Keys” for delivery performance, provided by DORA.
Particularly in terms of “deployment frequency” and “lead time”, we are currently at the “High” level, so we aim to achieve the “Elite” level.
成果
計測を始めた２月時点では以下の状態でした（*ブランチの運用方法を Findy Team+ に併せて変更する前に測定しているので、リードタイムは実際には 40.9h よりもさらに長いです）。
４月終了時点での結果は以下のとおりです。
デプロイ頻度は Elite レベル（2 件/day）に到達こそしていないものの、
デプロイ頻度：0.2 件/day 👉 1.4 件/day
変更のリードタイム：40.9 h（以上） 👉 20.2 h
と大きく改善しました🎉
これは週に１回だったリリースが１日に１回以上行われ、エンジニアが作成したコミットが１日以内に商用環境に反映されていることを意味します。
以下では、改善のために開発チームが取り組んだ内容を紹介したいと思います。
改善の取り組み
リリースパイプラインの自動化
もともとアプリケーションのリリースや DB マイグレーションは自動化されていたものの、AWS インフラのリリース（AWS CDK）やバックマージといった一部の工程では手作業が残されていました。
以前はほぼ週１回のリリースだったため、この工程はさして問題視されていませんでした。
しかし１回のリリースで 10 分程度の手作業だとしても、１日１回行うとなれば毎週１時間の損失になります。また単純な時間損失だけでなく、人的ミスによる障害リスク、作業への心理的ハードルがリリースのボトルネックになっていました。この手作業を徹底的に抹消すべくこれまで実施していたリリース作業を全て洗い出し、インフラの更新からリリースノートの作成まで、すべてがボタン１つで完了するような仕組みが出来上がりました。詳しいフローは以下の記事でも紹介しているので、ぜひご覧ください。
自動テストの高速化と安定化
手作業によるボトルネックが解消されリリースの頻度が向上してくると、今度は CI/CD パイプラインのテストフェーズの長さがボトルネックになってきました。amptalk ではテスト駆動開発を原則としており、PR が作成されるたびに数千件の自動テストが実行され、合格しなければマージ出来ません。これはプロダクトの品質の高さに貢献する一方で、テスト実行時間は少しずつ増加し、一時期は 20 分程度かかるようになってきました。リードタイムを抑えようとしている中で、20 分は開発者・レビュワー双方にとって非常に大きな足留めになります。
また一部 E2E テストではブラウザ・ツール起因の Flaky Tests が散見され、テストが失敗すると実行し直しになるなど、開発者の大きなストレスになっていました。
そこでテストの並列化やテストフレームワークの見直し（Cypress → Playwright）、変更セットからのテスト対象の絞り込みなど様々な取り組みが実施され、パイプラインが安定し 10 分以内に抑えられるようになりました。
チーム主体のリリース
リリースパイプラインが改善されていくと同時に、今度はリリースプロセスそれ自体の問題点が明らかになってきました。これまでは小さなチームだったこともあり、CTO の私がリリース承認者兼実行者という状態でした。しかし採用やプロダクト戦略など開発以外へリソースを割く比重が増えていく中で、リリースの頻度が増えると私自身がボトルネックになることが目に見えていため、チームへと権限委譲していきました。
現在では毎朝交代でリリース担当者がリリースを行い、それ以降も日中必要に応じてリリースできるという体制になっています。
チーム主体の定期リリースになることによって、エンジニアのマインドセットにも大きな影響がありました。
コードに変更を加えたあとの動作確認は欠かせませんが、PR を作成してからレビュー／マージ／デプロイを待っている間、エンジニアは時間をムダにしたくないので別の作業に移りたくなります。そうすると新しいタスクに集中している間に動作確認が遅れ、リリース前のブロッカーになるという事象が頻発していました。しかし毎朝、ある意味強制でリリースが行われるようになった結果、エンジニアは常に「自分のコードがすぐにリリースされる」ことを意識する必要が出てきます。すると
フィーチャーフラグで機能を隠しながらこまめにマージする（後述）
変更のインパクトを抑えるよう、Small PR を心がける
その結果レビュー負荷や、動作確認の粒度も小さくなり作業が楽になる
というように、よりリードタイムを短くする方向へと意識が醸成されていきました。以下はエンジニアとの会話ですが、このメンタルシフトをとても良く表しているので引用させてもらいます。
以前リリースするときは、開発レーンがあるという保護*があることを知っていたので、私自身も少し無頓着になっていましたが、もし本番環境に最初からシフトするなら、それは私にもっと注意深くなるように強制することになります。それはより良いメンタルシフトかもしれません。
* 開発環境での動作確認を完了していないタスクはかんばんの「開発レーン」にタスクが残留し、それがブロッカーになりリリース作業が遅れる。これがある種の保護機構として働く、という意味
フィーチャーフラグの活用促進
前項とも関連しますが、リリースの頻度が高まるにつれて承認プロセスがボトルネックになっていきました。この解決手段としてフィーチャーフラグの活用が進んできました。フィーチャーフラグの詳しい解説はさまざまな記事で行われているので省きますが、簡単には以下のようなものです。
Feature flags are a software development concept that allow you to enable or disable a feature without modifying the source code or requiring a redeploy.
フィーチャーフラグはソフトウェア開発のコンセプトのひとつで、ソースコードを変更したり、再デプロイを必要とすることなく、機能を有効にしたり、無効にしたりすることができる。
フィーチャーフラグには様々なメリットがありますが、今回の文脈で言うと「リリースプロセスと機能の承認プロセスを分離できる」という点です。フィーチャーフラグを用いない場合、新しい機能をリリースするためにはプロダクトオーナーの承認を待たなければいけません。結果リリース作業が遅れたり、大きな機能はマージがどんどん遅れてビッグバンリリースに繋がります。
しかしフィーチャーフラグを活用することで、開発チームは機能を公開することなくリリースを行うことが出来るようになり、承認プロセスを分離することができます。
もともと自前のフィーチャーフラグを開発・運用していたのですがやや使い勝手が悪く、開発に数週間〜数ヶ月単位でかかるような機能に対してのみ利用されていました。リリース頻度が高まるにつれて機能開発を始める際にはまずフィーチャーフラグの作成から始めるという習慣が出来上がり、利便性・安定性が重要になってきたため LaunchDarkly を導入しました。実験的な機能を特定の環境やグループにのみ公開したり、問題があればすぐに切り戻すといった柔軟なリリースも可能になり、さらなる高速な開発サイクルに貢献しています。
ボトルネックを特定する
以上で紹介したような取り組みによって、わずか数ヶ月で開発生産性が劇的に向上しました。しかしこれらの取り組みは初めから計画立てて行われていたわけではありません。まず初めに見えているボトルネックを解消することによって、そこに隠された次のボトルネックが見えるようになる。これをひたすら繰り返してきました。
手作業のボトルネックが改善されたおかげで自動テストのボトルネックが見つかり、それが改善されたおかげで承認フローのボトルネックが見つかり、、、
— Keita Suzuki (@leonis_sk) March 27, 2024
と、１つの大きな問題に隠されていたものがどんどん発見されて改善されていってる
素晴らしい
効果的な改善を継続的に繰り返すためにはボトルネックを特定することが大事です。例えば月１回のリリース判定会議を待たないとリリースが行えない、という組織でいきなり「CI/CD パイプラインを高速化するためにテストを並列化しよう」などと言っても、リードタイム短縮に効果が（ゼロとは言いませんが）出ないのは明らかです。他組織で行っているプラクティスを取り入れたからと言ってそれが改善に繋がるとは限らないので、自組織のボトルネックを正しく把握することが肝要です。
そしてボトルネックを特定するためには、計測をすることが大事です。Findy Team+ のようなツールを使えば Four Keys だけでなく PR のサイズやレビューまでの時間が見れたりしますし、GitHub Actions 等のパイプラインの実行時間を定期的に確認するのも良いと思います。こうした客観的な数値はしばしば、ボトルネック特定への洞察を与えてくれます。
開発生産性に課題を感じているが何から始めたら良いか…という方は、まず計測から始めてみてはいかがでしょうか。
継続的な改善が生まれる文化
ぜひ言及したい素晴らしいところは、こうした改善への継続的な取り組みがボトムアップで生まれている点です。今回紹介した取り組みはいずれも、チームで２週間に一度行っているレトロスペクティブで挙げられたアクションアイテムとして実施されてきました。
レトロスペクティブでは良かった点・悪かった点・不安などを思いつく限り書き出します。その後、投票で選ばれたみんなの関心のある出来事について話し合います。
議論の結果生まれたアクションアイテムをもとに有志が RFC を作成し、それをもとにみんなで分担して改善に取り組む、というサイクルが出来ており非常に頼もしいです。
最後に、amptalk の開発組織に少しでも興味を持っていただいた方は、ぜひご連絡ください！
採用ページ、もしくは私の X アカウントまでお気軽にお問い合わせください。
採用情報（日本語）
Recruitment Information (English)
この記事が気に入ったらサポートをしてみませんか？