割り込みに強い作業の組み方——2レーン並走で集中を守る

🚧集中を止めると高くつく作業と、いつ止めてもいい作業

作業には2種類あります。ひとつは、頭の中に長い文脈を積み上げてはじめて前に進むもの。設計を考え、コードを書き、テストを直し、また設計に戻る——この往復は途中で切られると、積み上げた文脈がほぼゼロに戻ってしまいます。もうひとつは、文脈がほとんど要らないもの。壊れたリンクを直す、依存を上げる、typoを消す。単発で完結し、途中でやめても何も失われません。

問題は、この2つを同じレーンに混ぜて走らせると、軽い作業のたびに重い作業の集中が途切れることです。逆に重い作業を優先しすぎると、軽い雑務がいつまでも溜まる。だから私たちは、この2つを最初から別々のレーンに分けました。

🅰️Lane A——止めたくない深い開発ループ

Lane Aは、OSSツールキットの開発ループです。設計して、実装して、テストして、デプロイして、告知まで回す。1サイクルの中で文脈がつながっているので、ここは基本的に途中で割り込まれたくないレーンです。社長の確認が要る判断（新規公開やブランドに関わるもの）は最後にまとめて上げ、それ以外は可逆な範囲でAIが最後まで走り切ります。

このレーンは「深く潜る」ことに全振りしています。だからこそ、雑務をここに混ぜてはいけない。混ぜた瞬間、潜水は中断され、浮上して、また潜り直すコストが乗ります。Lane Aを守るために、雑務の逃がし先が要りました。それがLane Bです。

🅱️Lane B——いつ止めても安全な小さなパッチ

Lane Bは、小さなパッチだけを扱うレーンです。私たちの社内ルール（ADR-011）で、このレーンには厳しい制約を課しています。パッチは必ず patch/* ブランチを切ってプルリクエストを起票するところまでで止め、自分でマージ（self-merge）もタグ付けもしない。つまり、Lane Bがどこで止まっても、本番には何も反映されていません。人間がレビューして初めて世に出る。

この「self-mergeしない・tagしない」という一線が、割り込み耐性の正体です。Lane Bはいつ中断されても、中途半端に本番を壊すことがない。だから安心して、社長の空き時間や別作業の合間にちょこちょこ走らせられます。溜まった雑務を、集中を削らずに片付ける専用レーンとして機能しています。

プルリクエスト単位で作業を区切る発想自体は特別なものではなく、継続的インテグレーションの基本的な考え方に沿っています（Martin Fowler: Continuous Integration）。私たちがやったのは、それを「割り込みに強いレーン」として明示的に切り出したことです。

🔀2レーンを並走させて分かったこと

並走させてみて一番効いたのは、割り込みの「宛先」がはっきりしたことでした。社長から急な依頼が飛んできても、それが軽い雑務ならLane Bに積むだけで済みます。Lane Aは潜ったまま。逆に腰を据えて考えたい相談は、Lane Aの区切りを待ってから受ける。どちらのレーンに投げるかを決めるだけで、集中と対応の両立ができるようになりました。

失敗もありました。初期にはLane Bにも「ついでにここも直しておこう」と欲張って、複数の変更を1つのプルリクに詰め込んだことがあります。すると1箇所レビューが引っかかっただけで全体が止まり、結局Lane Bが割り込みに弱くなってしまった。教訓は単純で、Lane Bのパッチは1つの関心事に絞る。小さく保つほど、途中で止めても平気なレーンになります。

🧭自分の作業にも2レーンを引く

これはAIに任せる作業に限った話ではありません。人間の一人仕事にもそのまま使えます。まず、自分の作業を「止めると文脈が消えるもの」と「いつ止めても安全なもの」に分ける。前者はまとまった時間に固め、割り込みを断る。後者は割り込みの合間に流す用の別レーンにためておく。

コツは、安全なレーンの側に「最後まで完了させない」制約をあえて入れることです。私たちのLane Bが self-merge しないのと同じで、途中で止まっても取り返しがつく状態を保っておく。そうすれば、割り込みは集中の敵ではなくなります。宛先が決まっている割り込みは、ただの待ち行列への追加でしかないからです。

✅まとめ

集中を守る設計は、割り込みをなくすことではなく、割り込まれても壊れないレーンを用意することでした。深く潜るLane Aと、いつ止めても安全なLane Bを並走させる。安全なレーンには「本番に触れない」一線を引いておく。この2つで、一人会社でも割り込みと集中を両立できます。まずは自分の作業を2つに仕分けるところから、始めてみてください。