中断駆動開発
筆者は、集中作業中に音楽を聴くことができないが、ヘッドフォンを装着して「作業中」の合図とすることで、中断を最小限に抑えていると述べている。
私は仕事中に音楽を聴くのが苦手です。多くの人がそうしているのは知っていますが、何か問題に集中する必要がある時はいつも、音楽を再生しているタブを探して一時停止しなければなりません。それでも私はヘッドフォンを着けています。何かを聴くためではなく、私のデスクに近づいてくる人に、自分が仕事中であることを知らせるためです。すべての人を遠ざけるわけではありませんが、もう少し長く集中し続けるための時間を稼いでくれます。
同僚との会話自体は気にしません。私が気にするのは、割り込みそのもの、特にタスクの最中に起こるものです。レガシーアプリケーションの問題をデバッグしていたり、ワークフローのメンタルモデルを構築していたり、例外を説明するコメントを読んでいたり、関数宣言を追っていたりすることがあります。まさに次の手がかりにたどり着こうとしているその時、声が聞こえるのです：「やあ！どうしたの？しばらく会ってなかったね。最近どうしてた？」
会話は決して長くはありません。しかし、それが終わった時、私の思考は消え去っています。さっきどこまでやっていたっけ？そうだ、関数宣言だ。でも、それはどこで呼び出されていたんだっけ？あのコメントが説明していた例外は何だったっけ？そもそもそのコメントをどこで見たんだっけ？前に進むためには、中断する前の精神状態を再構築するために、あらゆる手順をたどり直さなければなりません。
リモートワークは、ある程度までは役に立ちます。Slack経由の割り込みは、応答する準備ができるまでミュートできます。しかし、リモートワークも完全ではありません。依然として会議に参加することが求められます。リードとして、私は「すべてが火の車だ」という理由で頻繁に通話に引き込まれます。多くの場合、私の役目は火を消すことではなく、誰かの手を握って安心させることです。一時間後、自分が何をしていたかほとんど思い出せません。
割り込みのコストは、完全に割り込まれた側の人間が負います。自分の作業の位置を見失い、集中力を乱され、最終的には何事も時間通りに終わらせる能力を失います。しかし、割り込む側の人にとっては、しばしば好ましい経験です。チームを常にステータスアップデートに引き込むマネージャーは、生産的だと感じています。彼らは情報の輪の中にいて、存在感を示し、状況を掌握しています。デイリースタンドアップを設定し、すべてのスクラムセレモニーに出席し、開発者には進行中の作業を求めに応じてビジネス側にわかりやすい言葉で説明することを期待します。
一方、開発者は一日中通話に座り、安心させ、説明し、計画を立てることに時間を費やしていますが、実際には何も作り上げていません。彼らが抵抗すると、マネージャーは会議をキャンセルしません。代わりに、会議を30分から15分に短縮します。それは進歩のように感じます。しかし、問題は会議の長さではなかったのです。一日に三回の会議は、それがどれほど短かろうと、三回の割り込みを意味します。
仕事中に絶えず割り込まれることは、病院にいることを思い出させます。医師は安静を処方しますが、病院は実際に静養するには最悪の場所の一つです。子供たちが生まれる前、私の妻は約一ヶ月間入院しました。私は部屋の小さな一角に椅子と机を置き、彼女のそばでノートパソコンを使って仕事をしていました。20分ごとに、ドアが勢いよく開き、看護師が慌ただしく出入りし、ドアは彼女の後ろで大きく開けっ放しにされていました。
医師が安静を指示したことは関係ありませんでした。彼女の睡眠はそのたびに中断されたのです。
それが、実際の割り込み駆動開発の姿です。作業が実際に進むためには、中断されない集中した努力が必要です。正しいツール、正しいチーム、正しい意図があったとしても、何も生み出せないことがあります。作業環境そのものが、あなたの足を引っ張っているのです。
私のヘッドフォンは、会話したがっている人々を遠ざけてくれるかもしれません。しかし、私たちが本当に必要なのは、絶え間ない割り込みなしに仕事を成し遂げるための時間です。それはソフトウェア開発ライフサイクルの一部であるべきです。
原文を表示
I have a hard time listening to music while working. I know a lot of people do it, but whenever I need to focus on a problem, I have to hunt down the tab playing music and pause it. And yet I still wear my headphones. Not to listen to anything, but to signal to whoever is approaching my desk that I am working. It doesn't deter everyone, but it buys me the time I need to stay focused a little longer.
I don't mind having a conversation with coworkers. What I mind is the interruption itself, especially when I'm in the middle of a task. Sometimes I'm debugging an issue in a legacy application, building a mental model of the workflow, reading a comment that describes an exception, following a function declaration, right when I'm on the verge of the next clue, I hear a voice: "Hey! What's going on? I haven't seen you in a while. What have you been up to?"
The conversation is never long. But when it's over, my thoughts are gone. Where was I? Right, the function declaration. But where was it being called? What was that exception the comment described? Where did I even see that comment? I have to retrace every step just to rebuild the mental state I was in before I can move forward again.
Working remotely helps, to a point. Interruptions via Slack can be muted until I'm ready to respond. But remote work isn't immune. You're still expected to be in meetings. As a lead, I'm frequently pulled into calls because "everything is on fire." Often, my presence isn't to put out the fire, it's to hold someone's hand. An hour later, I can barely remember what I was working on.
The cost of interruption falls entirely on the person being interrupted. You lose your place, your focus, and eventually your ability to finish anything on time. For the person doing the interrupting, though, it's often a positive experience. The manager who constantly pulls the team into status updates feels productive. They're in the loop, they're present, they're on top of things. They schedule daily standups, attend every scrum ceremony, and expect developers to translate their work-in-progress into business-friendly language on demand.
Meanwhile, the developer is spending their day sitting in calls, reassuring, explaining, and planning, but never actually building anything. When they push back, the manager doesn't cancel the meetings. Instead, he trims them from 30 minutes to 15. It feels like progress. But the length of the meeting was never the problem. Three meetings a day means three interruptions, regardless of how short they are.
Being constantly interrupted at work reminds me of being in a hospital. Doctors prescribe rest, but hospitals are among the worst places to actually get any. Before our kids were born, my wife spent close to a month in the hospital. I had a small corner of the room, a chair and a desk, where I'd work on my laptop by her side. Every 20 minutes, the door would swing open, a nurse would bustle in and out, and the door would be left wide open behind her.
It didn't matter that the doctor had ordered rest. Her sleep was interrupted every single time.
That's what interruption-driven development looks like in practice. The work requires uninterrupted effort to actually happen. You can have the right tools, the right team, the right intentions, and still produce nothing. The work environment itself is working against you.
My headphones might keep those eager to converse at bay. But what we really need is time to get work done without the constant interruption. It should be part of the software development lifecycle.
関連記事
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み