7. 小さなバッチで作業する
定義
小さなバッチで作業する(Working in small batches) は、フィードバックループが重要なあらゆる規律の必須原則です。小さなバッチは、特定の改善が望む効果を生むか素早く仮説検証し、そうでなければ方向転換や仮定の再検討を可能にします。
リーン製品管理の一部であり、価値ストリームの可視性・チーム実験・顧客フィードバックの可視性とともに、ソフトウェアデリバリーパフォーマンスと組織パフォーマンスを予測します。
AI時代にこのケイパビリティはさらに重要になりました。DORA研究: 小さなバッチはAI導入が製品パフォーマンスに与えるポジティブな効果を増幅し、AIの組織摩擦への中立効果を正味のポジティブに変えます。
利点
- 変更へのフィードバック時間を短縮し、問題の切り分け・修正を容易にする。
- 効率と動機を高める。
- 埋没費用の誤謬(sunk-cost fallacy)を防ぐ。
- AI導入の安全網: AI導入はしばしばデリバリー不安定さの増加につながる。小さなバッチはこのリスクへの核心的対応で、AIの速度を混沌ではなく価値へ導く。
実装方法
新機能を計画するとき、独立して短時間で完了できる作業単位に分割します。各機能/バッチはアジャイルのINVEST原則に従うのが良いでしょう。
- Independent — 他のバッチと独立し、順序に関係なく作業・デプロイ・検証
- Negotiable — 反復可能でフィードバックに応じて再交渉
- Valuable — ステークホルダーにとって利用可能で価値を提供
- Estimable — 範囲を容易に見積もれる情報が存在
- Small — 数時間から2日程度で完了
- Testable — テスト・監視・検証が可能
理想的には、開発者は1日に少なくとも1回、複数の小さくリリース可能な変更をtrunkにチェックインすべきです。
AI時代の要点
AIは大きなコードブロックを素早く生成するのが得意ですが、大きな変更はレビュー・テスト・統合が困難です。小さなバッチを強制すると、開発者の焦点が生のコード生成から思慮深い分解と検証へ移ります。AIツールに大規模なPRを生成させる誘惑を避けてください。機械生成コードは行あたりの認知負荷が人間が書いたコードより高いことがあります。
有用な技法
- API/サービス層から開始し、UIではなくサービス/API層で開発する。
- ダークローンチ(dark launching): ユーザーに見せずに本番へ変更をデプロイ。
- フィーチャートグル(feature toggle): 構成設定に基づく条件分岐で動作をオン・オフ。
- 抽象化によるブランチ分け(branch by abstraction): 抽象化レイヤーを介して旧実装と新実装を切り替えながら、long-livedブランチを作らずに大規模な変更をtrunk上で段階的に開発・デプロイするパターン。
バッチは本番へデプロイされフィードバック検証が始まったときに完了します。
よくある落とし穴
- 十分に小さく分割しない。 機能の状態に関係なくコードをコミットし、個々の機能は数日を超えないようにする。1週間以上かかるバッチは大きすぎる。
- 小さく分けた後に再びまとめて下流へ送る。 これは欠陥・適合性へのフィードバックを遅延させる。
測定方法
- アプリケーション機能が頻繁なリリースを支えるよう分解されているか？（リリース可能な頻度、チームごとのばらつき、大きな機能による遅延の有無）
- 機能が開発者にとって1週間以内に完了できるよう細分化されているか？（完了比率、完了前のコミット・リリース可否）
- MVPが定義されチーム目標に設定されているか？
測定は組織プロセスの理解、無駄削減の目標設定、開発プロセスの複雑性削減にかかっています。
出典
本記事はDORAのWorking in small batchesを要約したものです。原文 © Google LLC、CC BY 4.0。