書籍とPodcastで学ぶトランクベースの開発
最近「LeanとDevOpsの科学」や「texta.fm」などを通して、「トランクベースの開発」や「フロー効率・リソース効率」というものを知りました。とても面白い考え方なので、簡単にまとめてみようと思います。
リソース効率とフロー効率
texta.fmでt-wadaさんも話されていますが、リソース効率・フロー効率について知っておくと、トランクベースの開発について理解が捗ります。
リソース効率
「人月」や「稼働率」の考え方です。リソース効率が良いとは、「稼働率が100%」を指すというイメージです。開発者に遊びを発生させず、複数の施策(ブランチ)を同時並行で進めます。
フロー効率
「単位時間あたりのスループット」に注目する考え方です。フロー効率が良いとは、「リードタイムが短い」を指すというイメージです。開発者に多少の遊びが発生したとしても、1つのことをやりきって終わらせる、次に行くという形で進めます。
トランクベースの開発とはなにか
Gitのブランチ戦略の1つで、一言でいうと「短命なブランチで開発し頻繁にmainブランチにマージする」戦略です。以下のような特徴を持ちます。
- mainブランチから近いところで開発をする
- アクティブなブランチを少なくして、ペアプロやモブプロで開発をする
- 小さい単位で開発し、CICDからフィードバックを得る
デリバリのパフォーマンスが高いチームのアクティブなブランチはどの時点でも3つ未満で、こうしたチームのブランチがトランクにマージされるの時間は非常に短く（1日未満）、プログラムの追加や変更をストップする「コードフリーズ」や安定化期間はまったくなかった ー LeanとDevOpsの科学
LeanとDevOpsの科学では、トランクベースの開発とペアプロ・モブプロがセットであるとは書かれていませんでしたが、高頻度にマージしていくためにはペアプロなどのプラクティスで品質を担保する必要があると思います。
ペアプロ・モブプロの実践は「フロー効率」を上げる
トランクベースの開発は、少ない本数の短命なブランチをペアプログラミングやモブプログラミングによって実装していき、フロー効率を上げていきます。
ペアプロやモブプロの実践によって、レビューのボトルネックを解消しています。レビューのボトルネックとは、例えば以下のような問題です。
- 設計判断の間違いに実装後に気づくことで、大きな手戻りが発生する
- コードを書くことで価値を提供できるベテランが、レビューに追われてしまう
- 結果的に1つ1つのコードレビューが荒くなりコードの品質が落ちてしまう
GitHubの登場によって発生した上記のような問題を、トランクベースの開発ではペアプロやモブプロの実践によって解消しています。結果的にリードタイムが短くなり、デプロイ頻度が高くなり、ハイパフォーマンスな組織に向かっていくことができます。
最後に
ペアプロ・モブプロは銀の弾丸ではないのですが、開発組織のパフォーマンス向上のヒントになるかなと思います。
