フレームワーク活用ガイドひとことで言うと#
チームが手動で行う定型的な運用作業（トイル）に上限時間（バジェット）を設定し、超過した分は自動化に投資するという判断基準を設けるフレームワーク。GoogleのSREプラクティスで提唱された「トイルは全体の50%以下に抑える」という原則を運用可能にする。
押さえておきたい用語#
- トイル（Toil）
- 手動・繰り返し・自動化可能・戦術的・長期的価値がないという特徴を持つ運用作業。サーバー再起動、手動デプロイ、定型的なデータ修正などが典型。
- トイルバジェット（Toil Budget）
- チームの稼働時間のうち、トイルに費やしてよい上限。Google SREでは50%が基準だが、チーム状況に応じて設定する。
- エンジニアリング時間（Engineering Time）
- トイル以外の時間、つまり自動化ツール開発、アーキテクチャ改善、新機能開発などの創造的な作業に使える時間。
- トイル削減ROI（Toil Reduction ROI）
- ある作業を自動化するためのコスト（開発工数）と、自動化によって削減される将来のトイル時間の比率。投資判断の基準になる。
- トイル計測（Toil Measurement）
- 各トイルに費やした時間を記録し、チーム全体のトイル率を定量的に把握する活動。計測なくして改善なし。
トイルバジェットの全体像#
こんな悩みに効く#
- エンジニアの時間の大半が運用作業で埋まり、改善や新機能に着手できない
- 「自動化したい」と言い続けているが、優先順位が決まらない
- 手作業がどれくらいの時間を占めているか、誰も正確に把握していない
- チームの人数は増えたのに、運用の負荷が下がらない
基本の使い方#
チーム全員に、手動で行った運用作業を記録してもらう。
- 作業名・所要時間・発生頻度を記録（スプレッドシートで十分）
- 「トイルかどうか」の判断基準: 手動・繰り返し・自動化可能・戦術的（長期的価値がない）
- 新機能開発やアーキテクチャ設計は「エンジニアリング時間」なのでトイルに含めない
- 2週間の合計をチーム全体の稼働時間で割り、トイル率を算出する
計測結果をもとに、トイルの上限を決める。
- Google SREの基準は50%。これを出発点にチーム状況で調整する
- 現状が65%なら、まず55%を目標にして段階的に下げる
- バジェットは四半期ごとに見直し、段階的に引き下げる
- マネージャーとチームで合意し、バジェット超過時は新しいトイルを受けない（自動化を先に行う）
バジェットを超過しているトイルを自動化候補にし、ROIで優先順位をつける。
- ROI計算: 月間トイル時間 × 12か月 ÷ 自動化に必要な開発時間
- ROIが高い（少ない投資で大きな時間削減ができる）ものから着手
- 完全自動化が難しければ、半自動化（手順の一部をスクリプト化）でもよい
- 自動化したらトイル計測に反映し、バジェット内に収まったか確認する
トイルバジェットは一度設定して終わりではない。
- 月次（少なくとも四半期）でトイル率を再計測する
- グラフ化してチームに共有し、改善の進捗を可視化する
- 新しいプロダクトやサービスが増えるとトイルも増えるため、継続的な監視が必要
- トイル率がバジェット以下に安定したら、バジェットをさらに引き下げる
具体例#
SREチーム6名のスタートアップ。メンバーから「改善に手が回らない」という不満が多く、エンジニアリングマネージャーがトイル計測を実施した。
2週間の計測結果:
| トイル | 週あたり時間 | 頻度 |
|---|---|---|
| 手動デプロイ | 8時間 | 日2回 |
| アラート対応（誤報含む） | 12時間 | 日10件 |
| 定期的なDB手動バックアップ確認 | 3時間 | 日1回 |
| ユーザーデータの手動修正依頼 | 5時間 | 週5件 |
| SSL証明書の手動更新 | 2時間 | 月2回 |
| 合計 | 30時間 | ― |
チーム全体の週間稼働は240時間（6名×40時間）。トイルは合計156時間/週で、トイル率は65%。
バジェット設定: 50%（120時間/週）を上限に設定。
ROI順に自動化:
- 手動デプロイ → CI/CDパイプライン構築（開発40時間、削減48時間/週）→ ROI 62.4
- アラート誤報 → アラートルールチューニング（開発16時間、削減36時間/週）→ ROI 117
- DBバックアップ確認 → 自動検証スクリプト（開発8時間、削減18時間/週）→ ROI 117
- SSL更新 → Let’s Encrypt + cert-manager（開発12時間、削減2時間/月）→ ROI 2
ROI順に着手し、3か月後のトイル率は65%→35%に。エンジニアリング時間が週84時間→156時間に増え、SLO設計やカオスエンジニアリングなどの改善プロジェクトに着手できるようになった。
データエンジニア3名のチーム。毎週月曜日にビジネスチーム向けの8本のレポートを手動で作成していた。SQLを実行→スプレッドシートに貼り付け→グラフ化→Slackに投稿、という手順を8本分繰り返す。
計測結果:
- 週次レポート作成: 12時間/週（3名で分担）
- アドホックなデータ抽出依頼: 8時間/週
- データパイプラインの手動リカバリー: 4時間/週
- 合計: 24時間/週（チーム稼働120時間の20%）
トイル率20%は許容範囲に見えたが、データエンジニアの本来業務（パイプライン構築、データモデリング）が圧迫されていた。バジェットを**10%**に設定。
自動化の実施:
- 週次レポート: dbtのジョブ→Lookerのスケジュール配信に移行（開発24時間、削減12時間/週）
- アドホック依頼: ビジネスチーム向けにRedashのセルフサービスダッシュボードを構築（開発40時間、削減6時間/週）
2か月後、トイル率は20%→7%に。削減された時間でリアルタイムデータパイプラインを構築し、レポートの鮮度が週次→日次に向上。ビジネスチームからの満足度も大幅に改善した。
バックエンドチーム8名。カスタマーサポートから「ユーザーのアカウント状態を調べてほしい」「特定のトランザクションログを確認してほしい」という依頼が週25件来ており、各件に平均20分かかっていた。
計測:
- CS技術調査対応: 約8.3時間/週
- これはバックエンドチーム稼働320時間/週の**2.6%**に過ぎないが、割り込みが入るたびにコンテキストスイッチが発生し、体感的な影響は数字以上に大きかった
エンジニアの実感を定量化するため、割り込みによる生産性低下を含めた「実効コスト」を計算。1回の割り込みにコンテキストスイッチ15分を加算すると、実質的なトイルは週約17時間（5.3%）に。
対応:
- 管理画面にCSチーム向けの「ユーザー調査ダッシュボード」を構築（開発60時間）
- アカウント状態、直近のアクティビティ、トランザクション履歴を検索可能に
- CSチームに操作トレーニングを実施（2時間×2回）
導入後、CS→エンジニアの依頼は週25件→4件に減少（残り4件は高度な調査が必要なケース）。エンジニアの割り込み時間は週17時間→3時間に削減。CSチームからも「自分で調べられるので対応速度が上がった」と好評。開発投資60時間に対し、年間の削減時間は約728時間でROIは12倍超。
やりがちな失敗パターン#
- トイルを計測しないままバジェットを設定する — 現状が見えていないのに上限だけ決めても、何を改善すべきか判断できない。最低2週間の計測データを基にする
- バジェット超過を放置する — 「忙しいから仕方ない」でバジェットを有名無実にすると、トイルは増え続ける。超過時は「新しい手動作業を受けない」ルールを徹底する
- 全てを完全自動化しようとする — 月1回・5分で終わる作業を自動化するのに40時間かける必要はない。ROIが低い作業はランブックのまま残す判断も重要
- 自動化した後に計測をやめる — 新サービスの追加や組織変更で新たなトイルが発生する。月次の再計測を仕組み化しないと、いつの間にかバジェットを超過する
まとめ#
トイルバジェットは、手作業の運用コストを「計測→上限設定→自動化投資→再計測」のサイクルで継続的に削減する仕組み。まず2週間のトイル計測でチームの現状を数字にし、50%以下のバジェットを設定する。超過分はROIで優先順位をつけて自動化に投資する。トイルを減らすことが目的ではなく、エンジニアリング時間を確保して価値ある仕事に使うことが目的。計測を続ける限り、トイル率は確実に下がっていく。