2021年に書いた下書きが出てきたので整理して供養します。今見るとチームが十分に大きいことを前提にしていますね（レビュアーを2人確保するとか）。

ぶっちゃけIndividual Contributor各位が快適に開発できれば何でもいいんですが、一応ビルドやリリース周りを長年囓ってきているため伝えられることもあるはずということで、新しくチームを持ったときには今のやり方の課題や改善方法、OSSプロジェクトや他社における事例など共有しています。だいたい毎回似たようなことを話している気がしてきたので、一旦ここにまとめてみます。

JavaあるいはTypeScriptのウェブアプリケーション開発プロジェクトを前提としています。チームリーダーに対して支援する立場で書いています。

大方針

チームの成果として何を評価するか

サービスや社内向けツール、プラットフォームを手掛けるチームの場合「そのユーザがどれだけの利益を得られたか」を基本的な指標にします。
- 何がユーザに求められているかは状況により、また実際に作ってみないとわからないことも多いため、ScrumやLean Software Developmentのような経験主義に基づくチーム運営を目指します。
- 「ユーザの利益を増やす」ためのアプローチとして「試行錯誤の回数を増やし効率を高める」ことを採用します。Continuous Deliveryを重視するのはこのためです。
コードの量や解決したチケットの数、ストーリーポイントなどは評価の対象ではありません。
- チケットの数を評価しないというのは「トラブル対応や不具合修正は評価しない」という意味ではなく、「早期に低コストに行える体制をつくる必要性がある」という意味です。
- その他にも「ユーザの利益を増やす」ことに直結しない手続きは極力低コスト化、あるいは省くことを目指します。

計画、朝会、振り返り

ある程度の規模のチームでは、タイムボックスを固定して定期的にイベントを作ることで、効率良く働くために改善する機会を見つけやすくなります。ここでは2週間スプリントを回していくことを念頭に話します。

スプリントのはじめに計画の機会をチームで設けてください。
- "sprint planning" と呼ばれるものです。やるべきことリスト（プロダクトバックログ）から扱うものを選び出し、細分化してタスク化します。
- 各タスクの「完了」の定義を明確にしてください。主に対象環境へのデプロイと動作確認になるはずです。
スプリントのおわりに振り返りの機会をチームで設けてください。
- "sprint retrospective" と呼ばれるものです。期待通りのパフォーマンスが出たのか、何がブロッカーになったのか、誰のどんな動きが良かったかなど、今後の改善に活かせる情報を共有し議論します。
- チームでデータや意見をひとつのテーブルに乗せて議論することが大事なので、しっかりめに時間を確保します。
毎日「昨日何をやったか」「どんな障害があったか」「今日は何をするのか」を共有する機会を設けてください。
- ミーティングの体制を取るならば、 “daily scrum” などと呼ばれるものになります。
- 準備をしてこないと意味がないのと、一人ひとりが発言すると時間がかかるので、チケットに最新の情報が上がるように・チケットを見れば次にすべきことがわかるようにします。

開発技術

branch運用

default branchからtopic branchを作成してPull Request（PR）を作成、ふたり以上のチームメンバーからLGTMをもらってからマージします。
- チームリーダーやテックリードだけレビューする体制はSPOFだし単純に負荷だけ見ても早々に崩壊するので、ベテランはもちろん新人も早いうちからレビュアーにします。
- レビュアー同士のコミュニケーションを通じて、暗黙知を形式知にする機会と捉えることもできます。
default branch以外のすべてのブランチは生存期間が短いほうが好ましい
- 3日以上長生きするtopic branchにいいヤツはいない、くらいの理解でだいたいあってる
- チケットが大きすぎるか、互換を保ったままマージする方法がないか、いずれにせよContinuous Deploymentをする条件が整ってない