はじめに：消火ホースの前に立つ人
月曜の朝、あなたは見事な計画を立てます。「今日は決済モジュールのリファクタリングを終わらせよう」。コーヒーを淹れて席に着きます。
9時12分、Slack。「@あなた 昨日デプロイした件で通知が飛んでいないようです」。9時34分、別チームからDM。「急ぎなんですがこのデータを抽出してもらえますか」。10時、突然入った会議。11時、顧客問い合わせによる緊急デバッグ。昼食も抜いて対応していると、いつのまにか午後5時。肝心のリファクタリングは一行も触れていません。
こんな日が一度なら事故ですが、毎日なら、それがあなたの職務です。多くのエンジニア、特に運用を兼ねたり、プラットフォーム/SRE/サポート的な仕事をする人は、**計画された仕事より降り注いでくる仕事(adhoc work)**のほうが多い環境で生きています。まるで消火ホース(firehose)から水を飲もうとするようなものです。
この記事はそのホースを塞ぐ方法ではありません。ホースは塞がりません。代わりに、**降り注ぐ水流の中でも溺れず、本当に重要な仕事までやり遂げるシステム**を作る方法です。
1. まず現実を認めよ
最もよくある誤りは「本来は計画通りになるはずなのに、今日だけ運が悪かった」と考えることです。一か月毎日そうだったなら、それは例外ではなくパターンです。割り込みはバグではなく仕様です。
この認識がなぜ重要か。現実を否定すると間違った計画を立てるからです。割り込みが一日2〜3時間を奪う環境で「今日8時間の集中作業」を計画すれば、毎日失敗し毎日自責します。
[誤ったメンタルモデル]
一日8時間 = すべて計画された仕事に使える時間
[現実に合うメンタルモデル]
一日8時間 = 割り込みバッファ3時間 + 計画された仕事4時間 + 雑務1時間
→ 計画された仕事は最初から4時間基準で組む
現実を認めれば二つが可能になります。第一に、達成可能な計画を立てます。第二に、割り込みそのものを「管理すべき業務」と見てシステムを設計し始めます。
2. トリアージ — すべての火が同じ火ではない
救急室では患者が来た順ではなく重篤な順に治療します。これがトリアージ(triage)です。降り注ぐ仕事も同じく分類すべきです。入ってきた順に処理するのは最悪の戦略です。
簡単な分類基準を頭に置きます。
[即時分類4段階]
P0 今止めて対応 : サービス障害、金/セキュリティ直結、データ消失リスク
P1 今日中に : 顧客が止まっている、締切間近、他人をブロック
P2 今週中に : 重要だが時間に余裕あり
P3 いつか / やらない : あれば良いが急がない
三つの鍵となる質問で素早く仕分けます。
1. **これは今、誰かを止めているか?**(ブロッキング)
2. **今やらないと後でコストが大きくなるか?**(時間敏感度)
3. **自分にしかできない仕事か?**(委任可能性)
三つすべてに「いいえ」なら、その仕事はほぼ常に後回しにできます。ところが私たちは「ついさっき入ってきた」という理由だけで、それをP0のように扱いがちです。最新性バイアスを警戒すべきです。
3. インテークを一元化せよ
割り込みが四方から、あらゆるチャネルで入ってくると、トリアージすら不可能になります。DMで、メンションで、廊下で、会議の終わりに「ああ、あと一つだけ」。だから最初のシステムは**入ってくる経路を一つにまとめること(intake funneling)**です。
[散らばったインテーク] [まとめたインテーク]
Slack DM ───┐ すべての依頼
メンション ─┤ → #team-requests チャネル
廊下の会話 ─┼──→ カオス vs または依頼フォーム/チケット一つに
メール ─────┤ → 一か所でトリアージ
会議の終わり┘ → 追跡可能
実践方法は環境ごとに異なります。
- 依頼専用チャネルやフォームを作り、「急ぎはここに投稿してください」と案内します。
- DMで来る依頼は丁寧に公開チャネルへ誘導します。「ここに投稿いただければ、チームで一緒に見て優先順位を決められます」
- 口頭の依頼は「Slackに一行残してもらえますか。でないと忘れてしまうので」とお願いします。
こうすれば三つが得られます。依頼が記録に残り、一か所で比較・トリアージでき、何より**依頼の量自体が可視化**されます。「今週23件入った」というデータができれば、増員やプロセス改善を説得する根拠になります。
4. バッチ処理と集中時間の確保
割り込みの本当のコストはその仕事自体ではなく、**コンテキストスイッチ(context switching)**です。深い集中に入るのに15〜20分かかるのに、5分の割り込み一つがその20分を丸ごと吹き飛ばします。
対策は二つです。
4.1 バッチ処理 — 割り込みをまとめて一度に
小さな依頼を来るたびに即処理せず、まとめて決まった時間に一気に処理します。
[悪いパターン] [バッチパターン]
依頼1 → 即処理 → 復帰(20分) 依頼1 ─┐
依頼2 → 即処理 → 復帰(20分) 依頼2 ─┼→ ためる
依頼3 → 即処理 → 復帰(20分) 依頼3 ─┘
= 集中60分の損失 11時・15時の二回にまとめて処理
= 集中損失を最小化
「即答が親切」という通念を疑うべきです。ほとんどの依頼は一〜二時間以内に答えれば十分です。
4.2 集中時間をカレンダーに釘付けにせよ
空いている時間は割り込みで埋まります。だから集中時間は**明示的に予約**せねばなりません。
[一日の設計例]
09:00-09:30 インテークのトリアージ(昨夜・朝にたまった依頼を分類)
09:30-12:00 集中ブロック(カレンダーに「集中」表示、通知オフ)
12:00-13:00 昼食
13:00-13:30 割り込みバッチ処理1
13:30-16:00 集中ブロック2
16:00-16:30 割り込みバッチ処理2 + 明日の準備
もちろんP0が起きれば集中ブロックも崩れます。それは当然です。重要なのは「デフォルト」を集中に置き、割り込みをその例外にすることです。逆になってはいけません。
5. 緊急の罠
降り注ぐ仕事の中で最も危険なのは**すべてが緊急に見える錯覚**です。依頼する人はほぼ常に「急ぎ」と言います。そう言えば早く処理されるからです。皆が急ぎと言えば、本当に急ぎなものが埋もれます。
「緊急さは伝染する。一人が急ぎと言えば
次の人も急ぎと言う。結局皆が急ぎになり、
何一つ本当には急ぎでなくなる。」
罠から抜ける方法は、緊急さを事実として受け入れず**検証する**ことです。
- 「いつまでに必要ですか?」— 漠然とした「ASAP」に具体的な期限を尋ねます。「今日6時まで」と「今月中」では天と地ほど違います。
- 「これが得られないと何が起きますか?」— 本当に影響があるか確認します。
- 「今やっているXを止めてこれを先にやるのが正しいですか?」— トレードオフを相手に見せます。
最後の質問が特に強力です。ほとんどの人はあなたが何をしているか知りません。「あなたの依頼のために決済バグ修正を止める必要があります」と伝えれば、相当数は「ああ、ではゆっくりで大丈夫」に変わります。
6. 期待値を管理せよ
降り注ぐ仕事を扱う肝は速く働くことではなく、**期待値を正直に管理すること**です。人が怒るのは仕事が遅れるからではなく、いつ終わるか分からないまま待つからです。
[期待値管理の応答テンプレート]
受領 + 分類 + 時点:
「確認しました。今P0障害対応中なので、これは今日午後に見て
明日午前までに返します。より急ぎなら教えてください」
断り(やわらかく) + 代替:
「今週はX締切のため難しそうです。
来週月曜に着手するか、Yさんがより早く手伝えるかもしれません」
ここで重要な二つの原則：
1. **沈黙するな。** 「対応中」の一言がないと、相手は無視されたと感じます。今できなくても「受け取った、いつ見る」という合図はすぐに出します。
2. **過度に約束するな。** 「すぐやります」と言って守れないと信頼が削れます。むしろ余裕を持って約束し早く終えるほうがよいです(under-promise, over-deliver)。
7. 繰り返す仕事は自動化するか文書化せよ
降り注ぐ依頼をよく見ると、相当数が**同じ種類の繰り返し**です。「このデータを抽出して」「この権限をくれ」「これどうやるんだっけ」。同じ依頼を毎回手で処理すれば、永遠にホースの下敷きになります。
ここにインパクトのレバレッジがあります。割り込みを処理することから、割り込みを**減らすこと**へ一段上がるのです。
[繰り返し依頼への対応のはしご]
ステップ1: 毎回手で処理 (最も非効率)
ステップ2: セルフサービス文書で案内 (「ここのガイドを見てください」)
ステップ3: セルフサービスツール/スクリプト化 (依頼者が直接処理)
ステップ4: 根本原因の除去 (そもそも依頼が起きないように)
例えば「権限をくれ」が週に五回来るなら、セルフサービス権限申請フォーム一つで五回を0にできます。文書化も同じです。同じ質問に三度目の回答をしているなら、その回答を文書にして次からはリンクだけ送ります。
このとき重要な習慣：**問題を解決しながら同時に文書を残すこと。**後で別途まとめようとすると永遠にやりません。割り込みを処理するその瞬間に、5分余分にかけて次の人(あるいは未来の自分)のための記録を残します。
8. バーンアウトを防ぐ方法
降り注ぐ仕事は単なる非効率の問題ではなく、**消耗の問題**でもあります。常にオンでいなければならず、いつも誰かの緊急に反応せねばならない感覚は人を蝕みます。心理学者クリスティーナ・マスラック(Christina Maslach)はバーンアウトの核心要因として、過負荷とともに**コントロール感の喪失**を挙げました。割り込み主導の業務が危険なのは、まさにこのコントロール感を奪うからです。
対策はコントロール感を少しずつ取り戻すことです。
- **オン/オフの境界を作る。** 常にオンでいる必要はありません。昼休み、集中ブロック、退勤後は通知を切ります。本当のP0は別の経路(電話、オンコール)で来ます。
- **オンコールを循環させる。** 割り込み対応を一人が専任すればその人が燃え尽きます。チームで「今日の当番」を回せば、残りは集中でき、負担が分散します。
- **小さな勝利を記録する。** 割り込みだけ処理した日は「何もできなかった」感覚になります。しかし実際は23件の依頼を解決したのです。処理した仕事を記録に残せば、自己効力感と評価の根拠を同時に得られます。
- **データで助けを求める。** インテークデータ(週あたり依頼数、所要時間)がたまれば、「今の構造では持続不可能だ」を感情ではなく数字で言えます。
9. 個人の技術を超えて — 組織レベルの交渉
ここまでの方法は、ほとんどが個人で一人でできるものです。しかし降り注ぐ仕事の根本原因が構造にあるなら、個人の英雄的努力だけでは限界が来ます。ある時点では上へ、そして横へ交渉せねばなりません。
このとき最も強力な武器は、3章でためた**インテークデータ**です。感情ではなく数字で語れるからです。
[データなしの訴え]
「忙しすぎます。割り込みが多くて仕事になりません」
→ 主観的な不平に聞こえる。皆忙しい。
[データありの交渉]
「過去4週間で週平均71件の臨時依頼が入り、
対応に一人あたり週14時間がかかりました。その結果、計画されたロードマップ作業が
毎週半分しか進みませんでした。三つの案を提案します」
→ 意思決定可能な提案に聞こえる。
交渉で提示できる選択肢：
- **増員/オンコール追加:** 依頼量が一人で吸収できる水準を超えたことを示します。
- **セルフサービスへの投資:** 繰り返し依頼をなくすツールを作る時間を公式に確保します。「今2週間投資すれば、以後毎週10時間を節約します」
- **期待値の公式化:** 依頼に対するSLAをチームレベルで合意します。「P2依頼は3日以内に応答」のように。
- **優先順位の調整:** 「この割り込みを受け続けるなら、ロードマップのXを後回しにする必要がある」を明示的にテーブルに載せます。
肝心なのは、割り込み負荷を**個人の忍耐力の問題ではなく、チームの資源配分の問題として**再定義することです。そうしてこそ持続可能な解決策が生まれます。一人で速く飲むことは解決策ではなく、バーンアウトの先延ばしにすぎません。
10. 事例：ホースをシステムに変えたプラットフォームチーム
ある会社の3人のプラットフォームチームは、社内開発者のあらゆる依頼に悩まされていました。デプロイ権限、環境設定、トラブルシューティングの依頼がDMで一日数十件入り、チームは常に疲弊し、肝心のプラットフォーム改善は一歩も進みませんでした。
彼らは4週間かけてシステムを変えました。
1. **インテーク統合**：すべての依頼を専用チャネル一つにまとめました。最初の週のデータが衝撃でした。週87件、うち60%がたった三種類の繰り返し依頼。
2. **トリアージ導入**：入ってきた順ではなくP0〜P3で分類しました。
3. **繰り返し除去**：最も多かった三種類をセルフサービス文書とスクリプトにしました。4週目に週あたり依頼が87件から31件に減りました。
4. **集中時間の確保**：減った割り込みのおかげで毎朝をプラットフォーム改善に使えるようになりました。
三か月後、そのチームは同じ人数でより多くの仕事をこなし、残業は減りました。ホースを塞いだのではなく、ホースの前に蛇口とコップを置いたのです。
11. 実践チェックリスト
降り注ぐ仕事に流されていると感じるとき：
- [ ] 割り込みを例外ではなく仕様として受け入れ、計画にバッファを入れたか。
- [ ] 入ってきた順ではなくP0〜P3でトリアージしているか。
- [ ] 依頼インテークが一か所にまとまり、記録に残るか。
- [ ] 小さな依頼をバッチでまとめて処理しているか。
- [ ] 集中時間をカレンダーに明示的に予約したか。
- [ ] 「急ぎ」という言葉を検証しているか。(期限・影響・トレードオフの質問)
- [ ] 受領の合図と予想時点をすぐに出しているか。(沈黙禁止)
- [ ] 繰り返し依頼を文書/自動化/根本除去で減らしているか。
- [ ] オン/オフの境界、オンコール循環でバーンアウトを管理しているか。
- [ ] 処理した仕事とインテークデータを記録しているか。
12. 二つのモードを意識的に行き来する
降り注ぐ仕事をうまく扱う人を間近で見ると、彼らは一つのモードに閉じこもっていません。二つのモードを意識的に行き来します。
[反応モード vs 創作モード]
反応(reactive)モード : 割り込みに応答。素早い判断、軽い文脈。
Slackを点けて、短い作業を処理。
創作(creative)モード : 深い集中。大きな文脈を頭に載せ本質を作る。
通知を切って、一つに没入。
問題はこの二つのモードがうまく混ざらないことです。創作モードに入ろうとするその瞬間、割り込み一つが反応モードへ引きずり下ろせば、再び入るのに大きなコストがかかります。逆に反応モードであるべき時間に深い作業を抱えていると、詰まった同僚が待ってもどかしがります。
肝心なのは**モードを混ぜず、ブロックで分けること**です。午前は創作、午後の一部は反応 — このように時間帯でモードを割り当てます。そして自分が今どのモードかを自覚します。「今、自分は反応モードか創作モードか?この時間に合う仕事をしているか?」という短い問い一つが一日の質感を変えます。
この自覚がないと、私たちは一日中中途半端なグレーゾーンにとどまります。集中しようとして通知に反応し、反応しようとして集中に未練を残し、どちらもまともにできない状態。降り注ぐ仕事の中で最もよくある消耗の形が、まさにこのグレーゾーンです。モードを鮮明に分けるだけでも、同じ量の仕事がはるかに疲れにくくなります。
おわりに
降り注ぐ仕事を扱う人は、しばしば見えない英雄です。彼らが黙々と火を消してくれるおかげで、他の人は計画通りに働けます。しかし英雄的にもっと多くの水を飲むことは答えではありません。それでは結局溺れるか燃え尽きます。
本当の答えはシステムです。トリアージで優先順位を仕分け、インテークをまとめて可視化し、バッチで集中を守り、繰り返しを自動化で消し、境界で自分を守ること。こうすればホースは依然として降り注ぎますが、あなたはその中で泳げます。そしてさらに、その水流を少しずつ手なずけていけます。
水をより速く飲もうとしないでください。水路を治める人になってください。
参考資料
- Cal Newport, *Deep Work* (集中とコンテキストスイッチのコスト)
- Christina Maslach & Michael Leiter, *The Truth About Burnout* (バーンアウトとコントロール感)
- Google SRE Book, sre.google — 割り込みとオンコールの管理、「Dealing with Interrupts」
- Will Larson, lethain.com — 運用負荷とシステム的アプローチ
- Atlassian — インシデント/依頼トリアージのガイド (atlassian.com)
- Greg McKeown, *Essentialism* (選択と断り)
현재 단락 (1/142)
月曜の朝、あなたは見事な計画を立てます。「今日は決済モジュールのリファクタリングを終わらせよう」。コーヒーを淹れて席に着きます。