バッチサイズ - yuuk1's Digital Garden

# バッチサイズ ## 定義バッチとは、開発工程を流れる作業成果物の単位である。ソフトウェアのバッチと言えばコードのことであり、その大きさは、継続的な開発に使う小さなものから、伝統的な開発手法で複数の開発者が数週間〜数か月かけて開発する大きなものまで幅がある。バッチサイズ(batch size)は、この作業成果物をどれだけまとめて後工程(統合・テスト・デプロイ)へ渡すかを表す設計変数であり、ソフトウェアは小さなバッチで設計・実装・デプロイすべきだというのが本概念の中心的主張である。ただし、バッチを小さくすることは直感に反するため、実際に行うのは難しいとされる。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 4 継続的デプロイ]] 冒頭) 小さなバッチには次の4つの利点があるとエリック・ライズは整理する。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 4 継続的デプロイ]] §4.1〜§4.4) 1. **フィードバックが早い**: 作業成果物を後工程に渡すのが早いほど、早くフィードバックを受け取れる。フィードバックが早ければ、まだ何の仕事をしていたか覚えているうちにミスに気付ける。(§4.1) 2. **問題を局所化する**: デプロイ時の変更が小さければ、バグの発見と修正の両方が速くなる。Flickr の例では、デプロイの変更が小さいためMTTD(平均診断時間)・MTTR(平均復旧時間)がともに短いと、ジョン・オルスポーの発言を引いて示される。(§4.2) 3. **リスクを減らす**: 2人が同じ場所に互換性のない変更を加えると統合の問題が起きる。設定変更もコード変更と同様に「デプロイ待ちの時限爆弾」を作りうる。リリースの回数を減らしても衝突の可能性は減らず、バッチが大きくなるだけである。(§4.3) 4. **オーバーヘッドを減らす**: ほとんどの組織はオーバーヘッドを減らすためにバッチサイズを大きくする(例: QAに1週間かかる企業が30〜60日に一度リリースする)が、この直感は誤りである。バッチサイズを小さくし頻繁にリリースする方が、承認手順の短縮・QA/オペレーションの余裕・継続的フィードバックループを通じて劇的に効率化できる。バッチサイズが大きくなる原因は隠されており、解明・解決に手間がかかるため、既存システムが「とりあえず」動いていると改善の試みは衰退しがちである。(§4.4) バッチサイズが大きい開発プロセスでは、時間と品質のトレードオフが避けられなくなる。フィードバックが遅いためミスから学べず、厳しい時間制約でコンフリクトを解消せざるを得ず、問題は次のリリースへ先送りされてスコープが増え、また時間が足りなくなるという悪循環に陥る。著者はこれを「カウボーイ派(とにかくやってしまう)」と「クオリティ派(ダブルチェックする)」の不毛な派閥争いの根本原因として位置づける。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 4 継続的デプロイ]] §4.5) ## 横断的知見 - **『ウェブオペレーション』4章と10章は、同じ「バッチサイズを小さくすべき」という結論に、理論(4章)と実務描写(10章)という異なる角度から独立に到達している**: 4章(Eric Ries)は、バッチを小さくする一般理論として「フィードバックの速さ・問題の局所化・リスクの低減・オーバーヘッドの削減」という4つの利点を抽象的に整理する。一方10章(Paul Hammond)は、大きな単位のコード変更(図10-1)と小さな単位のコード変更(図10-2)を対比し、「10,000行より10行の方がバグを見つけやすい」「一度に一箇所ずつデプロイすれば複数のコンポーネントが意図しない影響を受けない」と、Flickr の実務から具体的に論じ、これを支える3条件(ビルド・デプロイの自動化、ほぼ完璧なステージング環境、5分未満のデプロイ)を提示する。4章の「オーバーヘッドを減らす」利点は10章の「自動化」条件と、4章の「リスクを減らす」利点は10章の「小さな単位ほど原因特定が容易」という主張と、それぞれ対応している。同じ本の2つの章が、リーンスタートアップの理論家(4章)と現場の開発者(10章)という異なる立場から、同一の結論に収束したことになる。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 4 継続的デプロイ]] §4.1〜§4.4, [[@2011__OReillyJapan__ウェブオペレーション - Chapter 10 開発と運用の協力と連携]] §10.1) - **『アジャイルな見積りと計画づくり』のイテレーションの長さと、『ウェブオペレーション』のバッチサイズは、同じ「作業をどれだけの単位でまとめて後工程へ渡すか」という設計変数を、開発計画と本番デプロイという異なる工程で扱っている**: [[イテレーションの長さ]] concept は、開発イテレーションの長さを決める7つの要因(リリースまでの期間・不確実性・フィードバックの得やすさ・オーバーヘッド等)を扱うが、これは本概念がバッチサイズについて挙げる利点(フィードバックの速さ・オーバーヘッドの削減)とほぼ同じ軸に沿っている。さらに同concept は、『ウェブオペレーション』16章(Andrew Clay Shafer)が運用チームのタスク管理にはタイムボックス化されたイテレーションよりもカンバン(流れ・プルベース)が向くと述べていることを記録しており、「開発工程はイテレーション(時間で区切る)、デプロイ工程は継続的デプロイ(バッチサイズを最小化しほぼゼロにする)」という対応関係が浮かび上がる。4章が主張する「バッチサイズを小さくするほど良い」という極限は、カンバンが体現する「流れ・プルベース」の考え方と親和的であり、イテレーション(固定の時間区切り)よりもむしろカンバン側の思想に近い。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 4 継続的デプロイ]] §4.1〜§4.4, [[@2009__Mynavi__アジャイルな見積りと計画づくり - Chapter 15 イテレーションの長さを決める]] §1, [[@2011__OReillyJapan__ウェブオペレーション - Chapter 16 アジャイルインフラストラクチャ]] §16.2.1.14) - **Accelerate 第4章のトランクベースの開発に関する実証データは、本ページが4章・10章から理論的に整理してきた「小さなバッチの利点」を、独立した大規模調査による統計的な関連として裏づける**: 本ページ既出の知見は、『ウェブオペレーション』4章(理論)と10章(実務描写)が独立に「バッチサイズを小さくすべき」という結論に到達したことを記録してきたが、いずれも単一書籍内の理論・経験則にとどまる。Accelerate 第4章は、変更の単位を小さく保ち頻繁に統合するプラクティス(アクティブブランチ3つ未満、1日未満でのトランクへのマージ)が、業種・組織規模を問わない調査データにおいて、より高いソフトウェアデリバリのパフォーマンスと関連することを示す。ただし Accelerate 第4章はこの関連を支える因果メカニズムについて「より『寿命』の長いブランチを複数使うとリファクタリングとチーム間のコミュニケーションを阻害するのではないか」という仮説(聞き取り調査と著者らの経験に基づく)にとどめており、本ページが挙げる「バッチサイズをどこまで小さくすれば利点が頭打ちになるか」という未解決の問いには踏み込んでいない。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 4 技術的プラクティス―継続的デリバリの基本原則と効果]] §4.4.4, [[@2011__OReillyJapan__ウェブオペレーション - Chapter 4 継続的デプロイ]] §4.1〜§4.4) ## 未解決の問い - 4章はバッチサイズを小さくする利点を4つ整理するが、バッチサイズをどこまで小さくすれば利点が頭打ちになるか(最適なバッチサイズの下限)は論じていない。「小さければ小さいほど良い」という極限の妥当性は他ソースでの検証が必要。 - イテレーションの長さを決める7つの要因(不確実性・フィードバックの得やすさ等)のうち、デプロイのバッチサイズにも同様に適用できる要因はどれか。開発計画のイテレーションとデプロイのバッチサイズは独立に最適化すべきか、それとも連動させるべきかは、本ページの現ソース群では未整理。 - 10章が示す「頻繁デプロイを支える3条件」(自動化・ほぼ完璧なステージング環境・5分未満のデプロイ)のうち、4章のどの利点(フィードバック・局所化・リスク・オーバーヘッド)がどの条件と一対一に対応するかは、両章を突き合わせただけでは厳密には整理できていない。 ## 関連 - 概念: [[継続的デプロイ]](バッチサイズ最小化の実践形態) / [[イテレーションの長さ]](開発工程における同種の設計変数) / [[ソフトウェア変更管理]] / [[継続的デリバリ]](トランクベースの開発の実証データを提供) - ソース: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 4 継続的デプロイ]] / [[@2011__OReillyJapan__ウェブオペレーション - Chapter 10 開発と運用の協力と連携]] / [[@2018__Impress__LeanとDevOpsの科学 - Chapter 4 技術的プラクティス―継続的デリバリの基本原則と効果]] - 実体: [[Eric Ries]] / [[John Allspaw]] ## 出典 - エリック・ライズ, 「継続的デプロイ」, John Allspaw・Jesse Robbins 編, 角征典訳, 『ウェブオペレーション ―サイト運用管理の実践テクニック』, オライリー・ジャパン, 2011, 4章, §4.1〜§4.5. - Nicole Forsgren, Jez Humble, Gene Kim 著, 武舎広幸・武舎るみ訳, 『LeanとDevOpsの科学［Accelerate］』, インプレス, 2018, 第4章, §4.4.4.