計画されるより降り注いでくる仕事 — Adhoc業務を扱う方法

はじめに：消火ホースの前に立つ人
1. まず現実を認めよ
2. トリアージ — すべての火が同じ火ではない
3. インテークを一元化せよ
4. バッチ処理と集中時間の確保
- 4.1 バッチ処理 — 割り込みをまとめて一度に
- 4.2 集中時間をカレンダーに釘付けにせよ
5. 緊急の罠
6. 期待値を管理せよ
7. 繰り返す仕事は自動化するか文書化せよ
8. バーンアウトを防ぐ方法
9. 個人の技術を超えて — 組織レベルの交渉
10. 事例：ホースをシステムに変えたプラットフォームチーム
11. 実践チェックリスト
12. 二つのモードを意識的に行き来する
おわりに
参考資料

はじめに：消火ホースの前に立つ人

月曜の朝、あなたは見事な計画を立てます。「今日は決済モジュールのリファクタリングを終わらせよう」。コーヒーを淹れて席に着きます。

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 いつか / やらない : あれば良いが急がない

三つの鍵となる質問で素早く仕分けます。

これは今、誰かを止めているか?(ブロッキング)
今やらないと後でコストが大きくなるか?(時間敏感度)
自分にしかできない仕事か?(委任可能性)

三つすべてに「いいえ」なら、その仕事はほぼ常に後回しにできます。ところが私たちは「ついさっき入ってきた」という理由だけで、それを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さんがより早く手伝えるかもしれません」

ここで重要な二つの原則：

沈黙するな。 「対応中」の一言がないと、相手は無視されたと感じます。今できなくても「受け取った、いつ見る」という合図はすぐに出します。
過度に約束するな。 「すぐやります」と言って守れないと信頼が削れます。むしろ余裕を持って約束し早く終えるほうがよいです(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週間かけてシステムを変えました。

インテーク統合：すべての依頼を専用チャネル一つにまとめました。最初の週のデータが衝撃でした。週87件、うち60%がたった三種類の繰り返し依頼。
トリアージ導入：入ってきた順ではなくP0〜P3で分類しました。
繰り返し除去：最も多かった三種類をセルフサービス文書とスクリプトにしました。4週目に週あたり依頼が87件から31件に減りました。
集中時間の確保：減った割り込みのおかげで毎朝をプラットフォーム改善に使えるようになりました。

三か月後、そのチームは同じ人数でより多くの仕事をこなし、残業は減りました。ホースを塞いだのではなく、ホースの前に蛇口とコップを置いたのです。

11. 実践チェックリスト

降り注ぐ仕事に流されていると感じるとき：

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 (選択と断り)