Belong の開発生産性の取り組み
ttyfkyはじめに
Belong はエンジニアリングチーム立ち上げ当初より開発生産性を意識した取り組みを行ってきました。 最近は「開発生産性」という言葉を以前より耳にするようになりましたので、本記事では開発生産性のあり方について触れつつ、Belong における開発生産性向上のための取り組みを紹介します。
開発生産性について
Belong の開発生産性の取り組みは以下の図で表現できます。
この図は、開発生産性を支える要素をピラミッドで表現したものであり、下が基本的なもの、上へ向かって発展的なアプローチとして
開発生産性を向上させるための取り組みを表現しています。
Belong では下の基礎的なところから始まり、徐々に上へ向かって取り組んできました。
SRE の考え方として計測をしないことには効果を測ることができないという考え方がありますが、 まずは感覚ベースでも明らかに効果がある領域から取り組むことでアウトプットに対する影響を優先させることを選択し、 効果の可視化・分析は最近取り組み始めています。
Documentation
Belong ではチームメンバーや将来の自分を助けるためにドキュメンテーションを大切にしています。
システムがどういう形であるのか、なぜそのような形になっているのか、どのように使うのか、などを明確にすることで、
同じ課題のに対する取り組みや調査を何度も行わないようにし、開発者がより効率的に作業できるようにしています。
Platform Engineering
Belong ではプラットフォームエンジニアリングにも力を入れています。 詳しくは 「Belong のプラットフォームエンジニアリング」 に記載があります。
プラットフォーム エンジニアリングではセルフサービスのツールなどを提供し、開発者が効率的に作業できるようにすることを目的としています。 ゴールデンパスとして、わかりやすいものとしては GitHub Actions の共通化や Terraform Module、共通で使われるライブラリの提供などがあります。
例えば GitHub Actions では、Go の ビルド・テスト・リリースのパイプラインを共通化し、社内のプライベートリポジトリにある Action を利用したら
すぐに他のプロジェクトと同じように CI/CD パイプラインを構築できるようにしています。
ライブラリでは特にオブザーバビリティに関わる部分の共通化を初期の頃から行っています。
例えばロギングライブラリを共通化することで Google Cloud の
LogEntry の構造に合わせたログを即座に出力することを可能としたり、
Cloud Run にデプロイすると簡単に Cloud Trace に情報を送ることを可能にしています。
こういったサービスやプロジェクトを横断した共通の課題を解決し、それを再利用可能にすることで、既に解決された課題に対して再度取り組む必要性を減らし、 重要な課題により集中しやすい環境を提供するためにプラットフォームエンジニアリングを行っています。
AI
開発における AI 系のサービスは以前の記事 「AI サービスの利用」 で触れた、GPT-3.5 の発表以降 2023 年頃から取り入れ始めました。
GitHub Copilot を開発者は全員が利用可能にしてコードの補完やコメントの自動生成を行ったり、AI Reviewer を用いて Pull Request に対しての自動コメント付与を行っています。 また、社内で作成している Slack でのチャットボットであったり、Vertex AI 系のサービスを利用して RAG を取り入れつつ、社内の情報の効果的な利用にも取り組んでいます。
AI の利用により、共通の課題の解決やテストデータの細かい生成など難易度は高くない一方で時間がかかるような課題に取り組む必要性を減らし、 開発者がより重要な課題に集中できるようにしています。
Developer Metrics
開発者の生産性を計測し可視化するための取り組みも最近になって取り組む事が出来ています。 Four Keys 指標を意識しつつ、 変更のリードタイムやデプロイの頻度は GitHub や CircleCI のデータを利用し、変更障害率やサービス復元時間は社内の SDLC の仕組みで実施しやすいように Jira などを利用しつつ計測しています。
GitHub の指標は DORA の fourkeys repo を fork して社内独自で GitHub の情報を取得できる仕組みを導入し、
変更のリードタイム だけでなく、Pull Request におけるコメント数や承認数、コードの変更量など多面的な視点で開発者の生産性を計測可能にしました。
ここで得られる数字は操作可能なものなので、数字を作ることを目的にしないよう評価等では用いず、チーム・個人での傾向の発見や、
ロールモデルの動きを参考にするなど、より良い働き方をするためのインプットの一つとして利用しています。
git におけるアクティビティのデータが BigQuery に貯められる事により、SQL での多面的な計測結果の確認や分析が可能になりました。
一方で、CTO & SRE のサイドプロジェクト的に取り組む中で画面まで作り込むことができず、Looker Studio で可視化はしていますが、Findy Team+ などの
生産性可視化ツールも導入しつつ、生産性可視化のよりよい方法を模索しています。
おわりに
本記事では Belong の開発生産性の取り組みについて紹介しました。 Belong では私や SRE のメンバーが中心となり、開発者の生産性向上に取り組んでいますが、 各メンバーも個別のプロダクトの開発で生まれた汎用化可能なソリューションをゴールデンパスとして提供する事も重要な取り組みとしています。
このような取り組みが可能な環境で働くことに興味がありましたらお声がけ頂けたら嬉しく思います。