このページの問いは、この章で見てきた5つの考え方が、どうつながっているか、です。最後にもう一度、全体を1枚の地図としてまとめ直し、次の章へとつなげます。ページごとに個別に見てきた道具立てを、あらためて1つの流れとして見直すと、それぞれの位置づけがより明確になるはずです。
出発点は、人間の「マルチタスク」も、コンピュータの処理と同じく、実際には仕事の間を高速に切り替えているだけだ、という見方でした。違うのは切り替えの値段です。コンピュータの切り替えはほぼ無料に近いのに対し、人間の切り替えは、頭の中の情報を丸ごと入れ替える重い作業になります。
この見方が持つ意味は、単なる比喩にとどまりません。忙しく働いているのに仕事が進まないという感覚を、意志や能力の問題として片づけずに、切り替えの設計という、扱いようのある問題として捉え直せることに意味があります。設計の問題であれば、原因を特定し、対策を立て、少しずつ改善していくことができます。精神論に頼らずに済むという点も、この見方の実用的な利点です。
もう一つ付け加えるなら、この見方は個人の働き方だけでなく、チームや組織の設計にも応用できます。誰か1人だけが頻繁に呼び止められている状況、会議の議題が細かく行き来する進行、承認待ちで作業が止まっている部下。これらはいずれも、個人の性格や能力の問題ではなく、チームとしての切り替えの受け方が設計されていない状態として説明できます。この章の内容を、自分だけでなく、周囲の働き方を見直す視点としても、あわせて使ってみてください。
そこから、5つの道具を見てきました。ひとつ目は、プロセスとスレッドという区別です。目的も相手も締切も別の独立した案件をプロセス、同じ案件内の複数の作業の流れをスレッドと呼び分けました。プロセスをまたぐ切り替えは重く、スレッド間の切り替えは軽いという違いが、その後のすべての話の土台になっています。
この区別を持っておくだけで、日々のタスク一覧の見え方が変わります。ただ並んだタスクの羅列ではなく、どのタスクがどの案件に属し、どの移動が重く、どの移動が軽いかが見えてくるようになります。これは、日々の忙しさの中身を分解して眺めるための、いわば最初の解像度にあたります。
この解像度がなければ、以降で扱う道具はどれも、うまく地に足のつかないまま宙に浮いてしまいます。何が切り替わっているのかが分からなければ、切り替えのコストを測ることも、通知の制御を設計することも、時間割を組むこともできません。プロセスとスレッドの区別が、この章全体の出発点に位置づけられているのは、このためです。逆に言えば、この区別さえ最初にできていれば、残りの4つの道具は、あとからいつでも1つずつ取り入れていくことができます。
ふたつ目に見てきたのは、コンテキストスイッチのコストです。切り替え自体は仕事を1つも進めないのに、確実に時間と集中力を消費します。この余分な支払いは記録に残らないため、忙しく働いた実感と、実際に終わった仕事の量がずれる原因になります。切り替えの重さは、案件が変わったかどうかだけでなく、直前の作業がどれだけ複雑だったかによっても変わる、という点も見てきました。込み入った検討の途中の割り込みほど、高くつくのでした。
みっつ目に見てきたのは、割り込みとマスキングです。通知のすべてに即座に反応する必要はなく、意図的に受け付けない時間帯をつくってよい、という考え方でした。ただし、待たされた依頼はキューに積まれて消えずに残ること、そして本当に緊急なものだけは別経路で必ず届くようにしておくことが条件でした。この条件をどちらか一方でも欠いたマスキングは、ただの放置になってしまいます。
よっつ目といつつ目に見てきたのは、シングルタスク設計とバッチ処理です。前者はある時間をひとつの案件に専念させて切り替えコストの発生自体を防ぐ設計、後者は似た小さな仕事をまとめて処理し、1件あたりの速さより全体の処理量を優先する設計でした。どちらも、切り替えは高くつくという前提に立ったうえでの、具体的な対処法です。1日の時間帯を、重い仕事のためのシングルタスク、軽く似た仕事のためのバッチ処理、そして緊急対応のための即応の余白という3層で組み立てる、という考え方も、あわせて見てきました。
この5つの道具は、いずれも「切り替えは無料ではない」という1つの事実から出発している、という点に、あらためて注目してください。プロセスとスレッドの区別も、割り込みの制御も、時間割の設計も、突き詰めれば、切り替えという見えないコストにどう向き合うかという、1つの問いへの答え方の違いにすぎません。個別の道具として1つずつ覚えるよりも、この1つの問いから枝分かれした答えとして理解しておくほうが、あとから思い出しやすく、応用も利きます。
これら5つをつなげると、次のような姿になります。まず、抱えている仕事を独立した案件(プロセス)とその中の作業(スレッド)に分けて把握する。次に、その切り替えには見えないコストがあることを前提として置く。そのうえで、通知の受け方に意図的な制御(マスキング)をかけ、緊急なものだけが確実に届く経路を残す。そして最後に、専念できる時間(シングルタスク)と、まとめて片づける時間(バッチ処理)を、あらかじめ設計しておく。
この順番には理由があります。案件の区別ができていなければ、そもそも何が切り替わっているのかを認識できません。切り替えのコストを知らなければ、通知を制御する必要性そのものに気づけません。通知を制御できなければ、まとまった時間を確保することができません。1つ目の道具が2つ目の土台になり、2つ目が3つ目の土台になる、というふうに積み上がっていく構造になっているのだと理解してください。どれか1つだけを取り入れても一定の効果はありますが、土台から順に積み上げていくほうが、無理なく全体に効いてきます。
5つの道具が組み合わさった1日を、最後にもう一度たどってみます。朝、あなたは抱えている案件を紙に書き出し、週次報告と問い合わせ対応が別のプロセスであることを確認します(1つ目)。次に、報告書の90分には切り替えコストがかからないよう、朝一番の時間帯を確保します(2つ目の理解を踏まえた対策)。チームには「10時から11時半は集中タイムです」と伝え、通知をオフにします(3つ目)。11時半、たまった依頼をまとめて仕分け、優先度の高いものから返信します(4つ目のシングルタスクと5つ目のバッチ処理の組み合わせ)。夕方、部下から「今日は集中できましたか」と聞かれ、あなたは「思ったより進みました」と答えます。5つの道具は別々に使うものではなく、1日の中で自然につながっているのです。
ここまでは、いわば「切り替えをどう減らすか」という話でした。しかし、切り替えを減らしても、複数の案件が同時に手元にある状況そのものはなくなりません。減らした上でなお残る複数の仕事を、どんな順番でこなすべきか、という問いが残ります。締切が近いものを優先するのか、時間のかからないものから片づけるのか、それとも来た順に処理するのか。
この問いは、実はこの章の中で扱ったシングルタスク設計やバッチ処理の中身を決めるときにも、すでに顔を出していました。90分のシングルタスクの時間に、複数の案件の候補がある中から、どれを選ぶべきか。バッチ処理の対象となる複数の小さな依頼の中で、どれから手をつけるべきか。この章では、切り替えの回数そのものを減らす方法に焦点を当ててきましたが、残った仕事をどの順番でこなすかについては、あえて詳しく踏み込みませんでした。それこそが、次章のテーマです。
次章では、この「どれからやるか」という問いを、コンピュータの「スケジューリング」という考え方を借りて扱います。来た順に処理する方式、優先度で決める方式、時間のかからない仕事を先に片づける方式、順番に少しずつ進める方式など、複数の作業に順番をつける方法にはいくつもの型があり、それぞれに向き不向きがあります。あわせて、後回しにされ続けるタスクを救う仕組みや、締切の接近によって順番を強制的に入れ替える仕組みも扱います。
これらの型は、いずれも「限られた処理能力を、複数の待っている仕事にどう配分するか」という、この章と同じ根っこの問題から生まれています。順番の決め方ひとつで、全体の待ち時間や、個々の仕事の締切の守りやすさが大きく変わってくることも、次章であわせて見ていきます。この章で扱ったのは主に「切り替えのコストをどう抑えるか」でしたが、次章で扱うのは「残った仕事をどの順番でこなすか」です。この2つは別々の問題でありながら、どちらも同じ制約、つまり一度に処理できる仕事の量には限りがある、という制約から出発している点でつながっています。この制約そのものは、この先どの章に読み進んでも、形を変えながら繰り返し出てくることになります。
この章の内容は、次章以降の土台になります。プロセスとスレッドの区別、切り替えコストの認識、割り込みの制御という視点は、スケジューリングだけでなく、この先扱う待ち時間の設計やキャッシュの考え方にも繰り返し登場します。案件を区別し、切り替えの値段を意識し、通知を制御し、時間を設計する。この4つの姿勢を持つだけでも、日々の仕事の進み方はかなり変わって見えるはずです。
ここまで読んできて、5つすべてを一度に取り入れようとする必要はありません。まずは、案件を書き出して区別すること、あるいは1時間だけ通知を切ってみることのどちらか1つから始めれば十分です。1つの道具がうまく回り始めれば、他の道具の必要性も自然と見えてきます。切り替えという1つの視点さえ持てば、あとの4つはその応用として、無理なくつながっていくはずです。焦って一度に全部を変えようとするよりも、1つずつ効果を確かめながら進めるほうが、結果として無理なく長く続けられます。
最後にもう一度、この章の出発点を振り返っておきます。一日中働いていたのに、報告書が白紙のままだったとしても、それはあなたの能力の問題ではありません。切り替えに設計がなかった、というだけのことです。設計は、今日からでも少しずつ変えられます。抱えている案件の数そのものを減らせなくても、切り替えの受け方を変えるだけで、夕方に残っている仕事の量は着実に変わってくるはずです。
本書はCSの単元を仕事の言葉に翻訳するという方法を取っています。この章はその最初の実践でした。次章以降も、コンピュータの中で磨かれてきた考え方を、同じように仕事の場面に置き換えながら見ていきます。1つの章を読み終えるごとに、あなたが自分の働き方を見る解像度は、少しずつ確実に上がっていくはずです。1つの章ごとに少しずつ視点を積み重ねていくこと、それこそが、本書全体を通じて目指しているものです。
持ち帰り
- 人間の切り替えは高くつくという前提に立ち、案件の区別・切り替えコストの自覚・通知の制御を組み合わせる
- マスキングは通知を消すことではなく、緊急でないものを後回しにし、緊急なものだけを確実に通す仕組みである
- シングルタスクとバッチ処理は、それぞれ切り替えの発生を防ぐ設計と、まとめて片づける設計である
やってみる
この章の5つの考え方のうち、明日ひとつだけ試すとしたら何を選ぶか決めて、実際にカレンダーやメモに書き込んでみてください。書き込んだ内容は、次章を読み終えたあとにもう一度見返してみると、スケジューリングの考え方と組み合わせたときの変化にも気づきやすくなります。