なぜ僕らは「同時に全部」やろうとして、結局何も終わらないのか？
どうも、こんにちは！ヨーロッパの片隅で、今日もC#とWPFの画面設計と格闘しているITエンジニアです。海外でエンジニアとして働き始めて数年、ようやくこちらの生活にも慣れてきましたが、今でも毎日が新しい発見と（時々）炎上の連続です。
さて、いきなりですが、皆さんの「理想のエンジニア像」ってどんな感じですか？
バリバリと英語でミーティングをこなし、Slackの通知に即レスし、複数の開発タスクを同時並行で進め、QAからのバグ報告を瞬殺し、さらに新しい技術のキャッチアップも欠かさない……。
分かります。僕もそうでした。「海外で働く」って、そういう「スーパーマン」みたいな働き方だと思っていました。特にこっち（海外）のエンジニアは、自己主張も強いし、アウトプットのスピードも速い。彼らに追いつくためには、自分も「全部乗せ」でいかないとダメだ、と。
その結果、どうなったか。
ある日の午後、僕はまさに「それ」をやっていました。
午前中はロンドン（別拠点）との時差を考慮したミーティング。昼休みもそこそこに、インドのQAチームから飛んできた「クリティカル」なバグ報告の調査。その傍ら、マネージャーから「例の進捗どう？」というSlackがピコン。あ、やばい、C#のWPFで今まさに取り組んでいる、あの複雑なカスタムコントロールの非同期データバインディング処理がまだ終わってない……。
「まずい、全部が中途半端だ」
Slackに「今確認します！」と返信し、QAのバグを再現させようとデバッガを立ち上げ、その裏ではWPFのビルドが走り、頭の中では「あの非同期処理、スレッドセーフだっけ？」と自問自答する。
結果、その日、僕が成し遂げた「価値ある仕事」は、ゼロでした。
Slackの返信は「確認します」で止まり、バグの再現はできず（焦って手順を間違えた）、WPFのビルドは通ったものの、肝心のロジックは一行も進まなかった。
これ、笑い話じゃなくて、多くのエンジニアが（特に真面目で責任感が強い人ほど）陥りがちな「マルチタスクの罠」です。
僕たちはいつの間にか、「同時にたくさんのことを処理できる＝仕事ができる」と勘違いしてしまっている。でも、エンジニアリング、特に僕らがやっている設計や開発という仕事は、「レストランのウェイター」とは違います。あちこちのテーブルから同時に注文（タスク）を受けて、それを器用にさばくことが求められているわけじゃない。
僕らの仕事は、どちらかといえば「精密な手術」に近いです。
WPFのUIスレッドがなぜフリーズするのか、C#のメモリリークがどこで発生しているのか。そういった複雑な問題にメスを入れるには、全神経を一点に集中させる必要があります。その手術の途中で「ねえ、今日の夕飯なんにする？」と話しかけられたら、どう思いますか？ 「（医療）事故るわ！」って話ですよね。
僕らの脳みそで起こっているのも、まったく同じことです。
「コンテキスト・スイッチング」という言葉を聞いたことがあると思います。タスクAからタスクBに切り替えるとき、僕らの脳は「タスクAの作業データ」を一時的にメモリから退避させ、「タスクBの作業データ」をロードし直します。この切り替えには、思っている以上に莫大なコスト（時間と認知負荷）がかかっているんです。
ある研究では、一度中断した集中力が完全に戻るまでに15分から20分かかる、とも言われています。もし1日に5回、Slackやメールで「深い集中」を中断されたら？ それだけで1時間半以上を「再起動」のためだけに浪費している計算になります。
海外で働いていると、この「中断」がさらに厄介な形でやってきます。
時差です。
僕が集中してコーディングを始める頃、アメリカのチームが起きてSlackを飛ばしてくる。僕が退勤する直前に、アジアのチームからミーティングの招待が来る。常に誰かが「オンライン」で、常に「即レス」を求めてくる環境。
この環境で、かつての僕のように「全部に応えよう」とすると、確実にパンクします。そして、アウトプットの質は下がり、「あいつ、いつも忙しそうだけど、結局何やってるんだっけ？」という一番最悪な評価（サイレント・キラー）をもらうことになる。
だから、僕は数年前に決めました。
「マルチタスク、やめます」と。
このブログは、僕が海外のIT現場で生き残るために実践してきた「アンチ・マルチタスキング宣言（The Anti-Multitasking Manifesto）」です。
「一度に全部やろう」とするのをやめて、「一つに深く集中する」スキルを磨く。
これこそが、複雑な問題を解き明かし、質の高いアウトプットを出し続けるエンジニアにとって最強の「人生術」であり、海外で「こいつは信頼できる」と評価されるための最短ルートだと確信しています。
この連載ブログでは、
「承」で、なぜ僕らエンジニアにとって「ディープ・ワーク（深い集中）」が死活問題なのか。
「転」で、じゃあ具体的にどうやって「メーカーズ・タイム（集中時間）」を死守するのか。
そして「結」で、このスキルがあなたの海外キャリアでどう役立つのか。
僕の実体験（と失敗談）を交えながら、徹底的に解説していきます。
まず手始めに、あなたのデスクトップに開きっぱなしの「タブ」、いくつありますか？
……ふふふ、まずはそこから、ですよ。
なぜ「深い仕事（ディープ・ワーク）」こそが、エンジニアの最強の武器なのか？
「起」のパートでは、僕が海外の現場で「全部やろうとして全部失敗した」という、まあ、なんとも恥ずかしい失敗談を書きました。（読んでない人は先にそっちを読んでくれると嬉しいです！）
「マルチタスクやめます！」と宣言したのはいいけど、「いやいや、それができたら苦労しないよ」「海外で働いてて、そんな悠長なこと言ってられるの？」って声が聞こえてきそうです。
ええ、その通り。ぶっちゃけ、めちゃくちゃ「勇気」がいりました。
Slackの通知をオフにするのは、まるで「命綱」を外すような気分でしたからね。こっち（海外）のチームは、レスがちょっと遅いと「あいつ、寝てるのか？」くらいの勢いでメンション飛ばしてきますし。
でも、僕は気づいたんです。
僕らエンジニアが本当に価値を求められているのは、「素早いレスポンス」じゃない。
僕らが時給（あるいは高い年俸）をもらっている理由は、「他の誰にも（あるいはAIにも）簡単には解けない、複雑な問題を解決すること」。これに尽きます。
そして、その「複雑な問題」っていうのは、残念ながら「ながら作業」では絶対に解けないようにできているんです。
ここで「ディープ・ワーク」という言葉を出します。
知ってる人も多いと思いますが、カル・ニューポートさん（この人もエンジニア出身の教授！）が提唱した概念で、「認知能力を限界まで高める、注意散漫のない集中した状態で行う活動」のこと。
これ、僕らエンジニアの仕事にドンピシャで当てはまりませんか？
例えば、僕がやっているC#のWPFで、MVVM（Model-View-ViewModel）パターンを使って複雑な画面を作っているとします。
ユーザーがボタンAを押したら、バックグラウンドで非同期処理（async/await）が走り、データベースからデータを取得し、その結果を加工して、UIスレッド（Dispatcher）に戻して、画面上のグラフBとリストCを「同時に」「矛盾なく」更新する……。
これを実装するとき、僕らの頭の中はどうなっているか。
データの流れ、スレッド間の同期、CancellationTokenでの中断処理、INotifyPropertyChangedの発行タイミング、ViewとViewModelの責務分離……。これら「数十」の要素が複雑に絡み合った「巨大な設計図」を、頭の中にロードしなきゃいけない。
これはもう、脳みそが「フル稼働」どころか「オーバークロック」してる状態です。
この「頭の中に設計図をロードしきった状態」こそが、ディープ・ワークの入り口であり、エンジニアが最もパフォーマンスを発揮できる「ゾーン」なんです。
さあ、想像してください。
この「ゾーン」に入って、「よし、あの非同期処理のバグの原因、掴みかけてるぞ…！」という、まさにその瞬間。
ピコン♪（Slackの通知音）
「（マネージャー）今日の夕方、30分のミーティング追加してOK？」
……終わった。
僕の頭の中にロードしたばかりの「巨大な設計図」は、この「ピコン♪」の一撃で、ガラガラと音を立てて崩れ去ります。
たった5秒、Slackのウィンドウを開いて「OKです」と返信する。
その5秒で、僕の脳は「WPFの非同期処理モード」から「Outlookの空き時間確認モード」に強制的に切り替わってしまう。
そして、コードエディタに戻ってきた僕の頭は、もう「空っぽ」です。
「あれ？ さっきまで何を考えてたんだっけ？」
「このTask.Run、本当に必要だっけ？」
「ていうか、あのバグの再現手順なんだっけ？」
もう一度、あの「ゾーン」に入るために、また15分、いや、下手したら30分以上かけて、設計図を頭の中にロードし直すハメになる。
これが、「コンテキスト・スイッチングの本当の恐ろしさ」です。
僕らは「CPU」じゃないんですよ。
僕ら（人間）の脳は、悲しいかな「シングルコア・シングルスレッド」でしか動かない。
タスクを切り替えるたびに、莫大な「再起動コスト」が発生するんです。
「起」で話した、あの炎上しかけた日。
ロンドンとのミーティング、インドQAのバグ報告、マネージャーの進捗確認、そしてWPFの非同期処理。
僕は、この「再起動コスト」を1日のうちに何十回も支払っていたんです。そりゃ、何も終わるわけがない。
この「ディープ・ワーク」がなぜ重要か、もう一つ理由があります。
それは**「エラー（バグ）の削減」**です。
エンジニアリングは「積み木」です。
土台の設計（アーキテクチャ）がグラグラなまま、焦って機能（ブロック）を積み上げたらどうなりますか？
そうです。後で必ず、致命的なバグとして崩壊します。
Slackに即レスしながら書いたコード、ミーティングの「内職」で書いたコード。
そういう「浅い仕事（シャロー・ワーク）」で生み出されたコードは、大抵の場合、「負債」になります。
「まあ、いったんこれで動くから、FIXMEコメントでも残しとくか」
「ああ、時間がない、このtry-catch、雑だけどまあいいや」
この「まあいいや」が、半年後、地球の裏側にいる（かもしれない）同僚エンジニアを、あるいは最悪の場合、クライアントを地獄に突き落とすことになる。
逆に、ディープ・ワークで書き上げたコードは、美しい。
変数名は適切で、ロジックは簡潔、エッジケースも考慮されていて、テストコードも揃っている。
なぜなら、「ゾーン」に入っている時の僕らは、その問題の「全体像」を把握できているから。
海外（特に欧米）のシニアエンジニアたちは、この「集中」の価値を本当によく知っています。
彼らがヘッドホン（大抵ノイズキャンセリングのデカいやつ）をして、眉間にシワを寄せて画面を睨んでいる時は、「話しかけるな」のサインです。
それは彼らが「不機嫌」だからじゃない。「今、頭の中に『巨大な設計図』をロードしている最中だ。邪魔するな」という、プロフェッショナルとしての意思表示なんです。
僕らエンジニアが目指すべきは、「レスが速い人」でも「同時に色々やってる（ように見える）人」でもない。
**「深く潜って、デカい問題（バグ）を仕留めて、クリーンなコード（価値）を持って帰ってくる人」**であるべきなんです。
そのために、ディープ・ワークは「あったらいいな」スキルじゃなくて、「ないと死ぬ」必須スキル。
僕がマルチタスキングを捨てたのは、それが理由です。
……と、ここまで「ディープ・ワーク最高！」って話をしてきました。
でも、皆さんが本当に知りたいのは「理屈」じゃないですよね。
「分かった。重要性は分かった。じゃあ、どうやってその『ゾーン』に入る時間を確保するんだ？」
「Slackもメールもミーティングも、こっちの都合なんか待ってくれないぞ！」
ごもっとも。
僕も、この「理想」と「現実」のギャップに一番苦しみました。
「ディープ・ワークが大事」と分かっていても、現実の業務は「シャロー・ワーク（浅い仕事）」の洪水です。
次の「転」のパートでは、この「理想」を「現実」にするための、超・具体的なテクニックについてお話しします。
僕が実践している「タスク・バッチング（タスクのまとめ処理）」と、エンジニアの聖域「メーカーズ・タイム」を死守するための戦略です。
これができれば、あなたの生産性はマジで（マジで）爆上がりします。
お楽しみに。
エンジニアの聖域「メーカーズ・タイム」を死守せよ。そのための超・具体的戦術。
「承」で、僕らエンジニアの仕事は「精密な手術」や「巨大な設計図のロード」だって話をしましたよね。
じゃあ、その「手術室」や「設計室」を、どうやって守るのか。
答えは、**「エンジニアは『メーカー』である」**と自覚することから始まります。
プログラマーであり、偉大な投資家でもあるポール・グレアムが書いた「Maker’s Schedule, Manager’s Schedule (メーカーのスケジュール、マネージャーのスケジュール)」という有名なエッセイがあります。
- マネージャーのスケジュール：1日を30分や1時間の「コマ」で区切る。ミーティングからミーティングへ飛び回るのが仕事。スケジュール帳は「テトリス」みたいに埋まっている。
- メーカーのスケジュール：僕らエンジニアやデザイナー、作家のような「作る人」。彼らにとって、価値を生む単位は「最低でも半日（3〜4時間）」。この「まとまった時間」がないと、例の「巨大な設計図」を頭にロードすることすらできない。
海外で働いていると、この「2つのスケジュール感」が激しく衝突します。
マネージャーや他部署の人は、平気であなたのカレンダーに30分のミーティングを（それも、あなたが一番集中したい午前10時半とかに）ねじ込んできます。彼らに悪気はありません。それが彼らの「普通」だからです。
でも、考えてみてください。
「精密な手術」の予定が、午前10時から午後1時まで入っている外科医のところに、「すみませーん、10時半から30分、院内広報誌の打ち合わせでーす！」って入ってきたら？
「患者が死ぬわ！」って話ですよね。
僕らの「集中」は、それと同じくらい「繊細」で「価値がある」ものなんです。
この「メーカーズ・タイム（作る人の時間）」を、僕らは「意図的に」「戦略的に」死守しなくてはなりません。
じゃあ、具体的にどうするか。
僕は、大きく分けて2つの戦術を使い分けています。
それは**「防御（バッチング）」と「攻撃（ブロッキング）」**です。
戦術１【防御】：シャロー・ワークは「バッチ処理」で一網打尽
「シャロー・ワーク（浅い仕事）」とは、ディープ・ワークの対極にあるもの。
メールの返信、Slackの「確認しました」スタンプ、経費精算、簡単な進捗報告……。
これらは「必要」ではあるけれど、ぶっちゃけ「僕（エンジニア）じゃなくてもできる」仕事、あるいは「集中しなくてもできる」仕事です。
こいつらの何が厄介かって、**「ランダムに」「頻繁に」**発生して、僕らのディープ・ワークを中断させてくることです。
WPFのデバッガを一行ずつステップ実行して、メモリリークの原因を必死で追っている時に「ピコン♪（メール受信音）」が鳴ったら、もう集中力はブツ切れです。
だから、こいつら「シャロー・ワーク」は、まとめて「バッチ処理」するんです。
1. 「メール・Slack」バッチ処理
これが一番効きます。
まず、PCとスマホの「通知」を、今すぐ全部オフにしてください。
「え、海外のチームと仕事してるのに、即レスしないと不安…」
わかります。僕も最初は手が震えました。
でも、思い出してください。僕らの価値は「即レス」じゃない。
僕が実践しているのは「決まった時間にだけ、まとめてチェックする」というルールです。
- 僕の例： 11:30 と 16:00 の1日2回だけ。
- 午前中は、11:30まで絶対にメーラーもSlackも開かない。（どうせ時差で、朝イチは欧米からメールなんて来てない）
- 11:30になったら「よーいドン」で、そこまでのメールとSlackを「処理」する。
- 「処理」とは、「2分で終わるものはその場でやる」「それ以外はタスクリストに追加して、閉じる」「ただのFYIは読んだらアーカイブ」です。
- 午後は、16:00に同じことをやる。
- それ以外の時間は、Slackもメーラーも**「終了」**させておきます。ステータスも「集中モード」にしておく。
「じゃあ、緊急の連絡はどうするんだ！」
いい質問です。
本当に、今すぐ、僕の手を止めないと「会社が燃える」レベルの緊急事態って、1年に何回ありますか？
大抵の「緊急（と自称する）連絡」は、3時間待っても何も問題ありません。
そして、本当の本当の緊急事（例：本番サーバが落ちた）なら、彼らは「電話」をかけてきます。（海外はこれがハッキリしてます）
Slackでメンションが飛んでくる程度は、彼らにとっての「シャロー・ワーク」でしかありません。
この「通知オフ＆バッチ処理」をやるだけで、あなたの午前中（一番、頭が冴えている時間）は、完全に「あなただけのもの」になります。
2. 「管理タスク・雑務」バッチ処理
コードレビュー、ドキュメント作成、経費精算、週報……。
これらも「コンテキスト・スイッチ」の元凶です。
コーディングの合間に「あ、Aさんのコードレビューしなきゃ」と思い出す。これでまた集中が途切れる。
だから、これも「時間」を決めます。
- コードレビュー： 毎日15:00から30分間、まとめてやる。それまではPRの通知は（Slack連携を切り）見ない。
- ドキュメント・週報： 「金曜の午後」は「管理デー」と決めて、コーディングは一切やらない。その代わり、溜まった雑務を全部そこで片付ける。
こうやって「浅い仕事」を特定の「バケツ」に放り込んで、まとめて処理する。
これにより、それ以外の「聖域（メーカーズ・タイム）」がハッキリと浮かび上がってくるんです。
戦術２【攻撃】：カレンダーは「盾」であり「武器」である
「防御（バッチ処理）」がシャロー・ワークを「隔離」する戦術だとしたら、「攻撃（ブロッキング）」は、ディープ・ワークの時間を「確保」する戦術です。
海外（特に欧米）の企業で働いて一番驚いたのは、彼らは「カレンダーが全て」だということです。
カレンダーが「空いている」＝「この時間はあなたのものじゃない。会社の（＝誰でも使っていい）ものだ」
カレンダーが「埋まっている」＝「この時間は、彼のものだ。邪魔しちゃいけない」
このルールを逆手に取ります。
1. 「自分アポ」でカレンダーを埋め尽くせ
あなたのカレンダー、スカスカじゃないですか？
それ、マネージャーから見たら「お、Aくん、ヒマそうだな。ミーティング入れたろ」のサインです。
明日から、こうしてください。
自分の「ディープ・ワーク」の時間を、「予定」としてカレンダーに「ブロック（予約）」するんです。
- 例：
09:30 - 12:00: Deep Work (Project Phoenix: Async processing logic for WPF)14:00 - 16:00: Focus Time (Refactoring C# Data Access Layer)
これを、会社の共有カレンダーに「予定あり（Busy）」として入れてしまう。
（内容は、僕みたいに具体的に書いてもいいし、「Focus Time」とか「Development Work」みたいにボカしてもOK）
こうすると、どうなるか。
マネージャーがミーティングを設定しようとカレンダーを開いた時、あなたは「予定あり」になっています。
彼らは、その時間を「避けて」ミーティングを調整しようとします。
（もちろん、緊急なら「この時間、無理？」って聞いてきますが、その時は「今、クリティカルなバグを追ってる。30分後ろにずらせる？」と**「交渉」**すればいい）
たったこれだけで、あなたは「邪魔されない時間」を「公に」確保することができます。
これは「サボり」じゃありません。「成果を出すための、プロフェッショナルな時間管理」です。
2. 「ノー・ミーティング・デー」を交渉する
チームが成熟してきたら、これを提案するのもアリです。
「水曜の午前中は、全員がコーディングに集中する『ノー・ミーティング・タイム』にしようぜ」
僕の今のチームでは、暗黙の了解として「火曜と木曜の午前中」は、よほどのことがない限りミーティングを入れないルールになっています。
C#の複雑なジェネリクスと格闘するのも、WPFのXAMLで「なぜかズレる」レイアウトと戦うのも、全ては「まとまった時間」があってこそ。
ヘッドホン（もちろんノイズキャンセリング）は、その「聖域」を守るための「結界」です。
カレンダーのブロックは、その「結界」を可視化する「盾」なんです。
「シャロー・ワーク」をバッチ処理で隔離し、空いた時間（聖域）をカレンダーで死守する。
これが、僕が海外の「ミーティングだらけ」「チャットだらけ」の環境で、なんとか設計と開発という「メーカーの仕事」を続けるために身につけた、最強の「人生術」です。
さあ、理屈（承）と、戦術（転）は揃いました。
じゃあ、この「アンチ・マルチタスキング」な働き方を実践した結果、僕のエンジニア人生はどう変わったのか？
「即レス」を捨てた僕が、海外チームでどう評価されるようになったのか？
最後の「結」で、その「答え」をお話ししようと思います。
即レスを捨てた僕が、海外チームで本当に手に入れたもの。
さて、長い旅にお付き合いいただき、ありがとうございます。
「起」で、マルチタスクの罠にハマってもがいていた僕の（恥ずかしい）失敗を告白し、
「承」で、「エンジニアの価値はディープ・ワーク（深い仕事）にこそある！」と叫び、
「転」で、その「聖域（メーカーズ・タイム）」を死守するための超・具体的な戦術（バッチ処理とカレンダー防御）をお話ししました。
ここまで読んでくれたあなたが、一番聞きたいのはこれですよね。
「で、結局、それを実践してどうなったんだ？」
「本当に、海外のスピード感の中で『即レスしない』なんて働き方が通用するのか？」
今日は、その「答え」を包み隠さずお話しします。
この「アンチ・マルチタスキング宣言」を実践した僕が、何を得て、何を失った（と思った）のか。
まず、正直に白状します。
「通知をオフ」にして、Slackのステータスを「集中モード」に設定した最初の日。
僕は、めちゃくちゃ怖かった。
「今、マネージャーから『あれどうなった？』ってメンションが飛んでたらどうしよう」
「インドのQAチームが、僕のレス待ちでイライラしてたらどうしよう」
まるで、高層ビルの命綱を外したような気分でした。
午前9時半、僕は意を決して、メーラーもSlackも閉じました。
そして、例のカレンダーにブロックした「メーカーズ・タイム」の通り、あの忌まわしき「WPFの非同期データバインディングによるメモリリーク」の調査だけに、全神経を集中させました。
ヘッドホンで外界の音を遮断し、デバッガとC#のコードだけを睨みつける。
「ピコン♪」という通知音に、もう僕の「ゾーン」は邪魔されません。
……そして、11時半。
アラームが鳴り、僕は「バッチ処理」の時間だと気づきました。
恐る恐るSlackを開く。
そこには、マネージャーからのメンションが1件、QAからの質問が2件、溜まっていました。
でも、不思議なことに、誰も怒っていません。
「OK、A（僕）は今、集中モードだな。11時半になったら聞こう」
くらいのもんです。
それよりも、僕の手元には「成果」がありました。
2時間、完全に集中したおかげで、あの難解なメモリリークの原因を特定し、修正の目処が立っていたんです。
（ちなみに原因は、イベントハンドラの購読解除漏れっていう、WPFあるあるでした……恥ずかしい）
僕は、溜まっていたSlackにこう返しました。
「（マネージャーへ）進捗です。例のメモリリーク、原因特定しました。午後イチで修正プルリク出します」
「（QAへ）再現手順確認しました。これ、僕の修正で直るはず。修正版をデプロイしたら、また連絡します」
……これが、僕の「現実」でした。
僕が恐れていた「即レスしないことによる信用の失墜」なんてものは、どこにも存在しなかった。
むしろ、逆でした。
僕が「即レス」を捨てて手に入れたもの。
それは、「問題解決者」としての「本質的な信頼」です。
海外の（特に欧米の）エンジニアリングチームは、驚くほど「合理的」で「結果主義」です。
彼らが評価するのは、「レスが速いヤツ」ではありません。
彼らが本当にリスペクトし、信頼するのは、「デカい問題を、確実に解決してくれるヤツ」です。
僕がSlackで「確認します！」と即レスするだけの「お返事マシン」だった頃。
僕は、チームにとって「便利だけど、別にいなくても困らない人」だったかもしれない。
でも、僕がマルチタスキングをやめ、ディープ・ワークに舵を切った結果、どうなったか。
「A（僕）にあのC#のモジュールを任せれば、時間はかかるかもしれない（と彼らは思っている。実際はバッチ処理してるだけだが）。でも、必ず『クリーンなコード』と『確実な成果』を持って帰ってくる」
そういう「スペシャリスト」としての信頼（ブランド）が、少しずつ確立されていったんです。
思い出してください。僕のペルソナは「海外で働く、CシャープWPFで主に設計開発を行っているITエンジニア」です。
僕の価値は「設計」と「開発」にある。
「Slackの返信」や「ミーティングの調整」にあるんじゃない。
この「アンチ・マルチタスキング宣言」は、あなたの「本質的な価値」がどこにあるのかを、自分自身と、そしてチームメイトに再定義する「宣言」でもあるんです。
これから海外で働こうとしているあなたへ。
あなたは、言葉の壁、文化の壁、そして時差の壁という、ただでさえ高い認知負荷（コグニティブ・ロード）がかかる戦場に飛び込もうとしています。
そこで、日本にいた時と同じように「全部に対応しよう」「全部を同時にやろう」としたら？
100％、燃え尽きます。僕が保証します。
あなたの脳みそは、あなたのキャリアで最も貴重な「資産」です。
その「資産」を、Twitterの通知や、どうでもいいメールマガジンや、「今じゃなくていい」Slackのメンションで浪費してはいけない。
タイトルに戻りましょう。
「The Anti-Multitasking Manifesto: Focus on One Thing, Master All」
（アンチ・マルチタスキング宣言：一つを極めれば、すべてがうまく回りだす）
この「One Thing（一つ）」とは、今、あなたの目の前にある、最も重要な「ディープ・ワーク」のこと。
WPFのXAMLを組むことでも、C#のロジックを考えることでも、新しい技術のドキュメントを読むことでもいい。
それを「極める（Master）」ために、全リソースを集中投下する。
その結果、「All（すべて）」——つまり、あなたのプロジェクト、あなたの評価、あなたのキャリア、そしてあなたの心の平穏——が、自然と「うまく回りだす（Master All）」んです。
これが、僕が海外の現場で学んだ、最強の「人生術」です。
さあ、この記事を読んだら、ブラウザのタブを（この記事以外）全部閉じてみませんか？
そして、スマホを裏返して、あなたの「聖域（メーカーズ・タイム）」を取り戻しましょう。
あなたの「ディープ・ワーク」を、心から応援しています。
ではまた、次のプロジェクトで！
コメント