このページの問いは、「ひとつの仕事」をどこからどこまでと数えるべきか、です。週次報告と問い合わせ対応は同じ1つの仕事でしょうか、それとも別の仕事でしょうか。この境界の引き方が、切り替えコストの正体を決めます。前のページでは、切り替えには値段があると述べました。しかし、何と何を切り替えたときに値段が発生するのかを決めるには、そもそも「ひとつの仕事」の輪郭をどう引くかを先に決めておく必要があります。
コンピュータの世界では、実行中の仕事のかたまりを「プロセス」と呼びます。プロセスは、それぞれ独立したメモリ領域(作業内容を置いておく場所)を持っています。ブラウザというプロセスと、資料作成ソフトというプロセスは、互いの作業内容を勝手に読み書きできません。完全に別の引き出しに入っていると考えてください。片方のプロセスが不具合を起こしても、引き出しが別である限り、もう片方のプロセスの中身がいきなり壊れることは基本的にありません。
一方「スレッド」は、同じプロセスの中にある、複数の実行の流れです。スレッドどうしは同じメモリ領域を共有します。たとえば資料作成ソフトが、文字入力を受け付けながら裏で自動保存も行っているなら、それぞれが別のスレッドとして動いていることがあります。どちらも同じ文書という、同じ引き出しの中身を見ています。文字入力用のスレッドと自動保存用のスレッドは、別々に動いていても、同じ文書データを参照しているからこそ、保存された内容が今まさに入力した文字とずれずに一致します。
この違いを仕事に翻訳すると、こうなります。プロセスに近いのは、目的も相手も締切も別々の、独立した案件です。週次報告の作成と、取引先からの問い合わせ対応は、別のプロセスです。それぞれに固有の背景、固有の関係者、固有の期限があり、互いのメモを勝手に流用することはできません。
もう少し補足します。コンピュータのプロセスは、たとえ同じ種類のアプリケーションを2つ開いていても、別々のプロセスとして扱われます。資料作成ソフトを2つのファイルで開いていれば、それぞれが独立したプロセスで、片方の文書を編集しても、もう片方には影響しません。仕事で言えば、同じ「報告書」という種類の案件でも、今月の報告書と先月の報告書は別のプロセスです。種類が同じだからといって、同じ引き出しに入っているとは限らない、という点が重要です。
スレッドに近いのは、同じ案件の中の複数の作業の流れです。週次報告という1つのプロセスの中に、本文を書く作業と、グラフを整える作業と、上長への確認依頼という、複数のスレッドが走っていると考えられます。これらは同じ目的、同じ締切、同じ背景情報を共有しています。
スレッドどうしが同じメモリ領域を共有するというのは、仕事で言えば、同じ資料・同じ前提・同じ関係者を土台にして動いている、ということです。本文を書く作業で決めた表現の方向性は、グラフを整える作業にもそのまま使えますし、上長への確認依頼の文面にも流用できます。これらの作業の間を行き来しても、毎回ゼロから前提を確認し直す必要がないため、切り替えの負担が軽く感じられるのです。
この区別は、コンピュータの設計者が偶然思いついたものではありません。プロセスごとにメモリ領域を分けておけば、あるプログラムに不具合が起きても、他のプログラムの作業内容を壊さずに済みます。一方でスレッドは、メモリを共有する代わりに、切り替えの手間を軽くできます。安全さを取るか、身軽さを取るかという設計上のトレードオフの上に、プロセスとスレッドという2つの単位が用意されているのです。仕事に置き換えても同じ発想が使えます。関係者や締切が異なる案件どうしは、あえて情報を分けて管理したほうが、混同による事故を防げます。逆に、同じ目的を共有する作業どうしは、情報を共有したまま並行して進めたほうが効率的です。
なぜこの区別が大事なのでしょうか。理由は、プロセス間の切り替えとスレッド間の切り替えでは、コストがまったく違うからです。週次報告の本文からグラフ整えに移るのは、同じ引き出しの中で手を動かす場所を変えるだけなので、比較的軽い切り替えです。背景を思い出す必要がほとんどありません。
ところが週次報告から問い合わせ対応に移るのは、引き出しをまるごと入れ替える作業です。相手が誰で、何を求めていて、社内のどこに確認すべきかを、ゼロから頭に呼び出す必要があります。対応が終わって報告書に戻るときも、同じだけの読み込みが逆方向に発生します。
プロセスとスレッドの区別は、見た目の作業内容だけでは判断できないことにも注意してください。たとえば「資料を直す」という同じ動作でも、それが週次報告というプロセスの一部を直しているのか、まったく別の企画書というプロセスを直しているのかで、意味がまったく違います。見た目の動作ではなく、その作業がどの目的・締切・関係者とつながっているかで、プロセスの境界を引く必要があります。
具体的な場面で考えてみましょう。1つ目は、週次報告の作成中に、まったく別の案件である問い合わせ対応が割り込む場面です。これはプロセスをまたぐ切り替えで、コストが高くつきます。2つ目は、報告書の中で、文章を書く作業から、数字を整える作業に移る場面です。これは同じプロセス内のスレッドの切り替えで、比較的軽く済みます。3つ目は、会議調整という1つの案件の中で、候補日の確認、参加者への連絡、会議室の予約という複数のスレッドを並行して進める場面です。これらは同じ目的を共有しているので、まとめて扱っても混乱しにくいのです。4つ目は、部下からの相談です。相談の内容が、あなたが今抱えている案件の一部であれば、それはスレッドの切り替えに近くなります。しかし、まったく別の案件についての相談であれば、実質的には新しいプロセスへの切り替えが発生していることになります。相談だから軽い、というわけではなく、相談の中身がどの案件に属するかで重さが変わるのです。
4つ目の場面を、もう少し具体的に描いてみます。部下が「先方への提案書の件で相談があります」と声をかけてきたとします。あなたが今取り組んでいるのが、たまたま同じ提案書の別項目だったなら、話は早く終わります。「その項目なら、価格表の3行目を見てください」と即答できるからです。しかし、あなたが取り組んでいたのが週次報告だった場合、事情は変わります。「その提案書、担当は誰でしたか」と聞き返すところから始まり、案件の背景を思い出すのに数分かかります。同じ「部下からの相談」でも、相談の中身がどの案件に属するかで、重さがまるで違うのです。
ここでの落とし穴は2つあります。ひとつは、すべての依頼をひとまとめの「作業」として扱い、プロセスの境界を意識しないことです。境界を意識しないと、実は重たいプロセスの切り替えを、軽いスレッドの切り替えのつもりでこなしてしまい、頭が消耗します。タスク一覧に「報告書」「問い合わせ」「引き継ぎ」と並べるだけでは、どれがどの案件に属するかが見えず、切り替えの重さを見誤ります。
多くのタスク管理ツールは、締切順や優先度順にタスクを並べる機能を持っていますが、案件ごとにグループ化して表示する機能は後回しにされがちです。締切順に並んだ一覧を上から順にこなしていくと、隣り合うタスクがまったく別の案件に属していることが多く、知らず知らずのうちに重いプロセス間の切り替えを何度も繰り返すことになります。タスクを並べる順番を決める前に、まずどの案件に属するタスクなのかをラベルづけしておくだけでも、並べ方の工夫がしやすくなります。
もうひとつの落とし穴は逆方向です。関連の薄い案件を「同じようなものだから」とまとめて扱い、それぞれの締切や関係者を混同してしまうことです。プロセスには、それぞれ固有のメモリ領域が必要です。別々の案件の情報を1つのメモに混ぜて書くと、あとで見返したときにどちらの締切か分からなくなります。たとえば、複数の取引先向けの提案書を1つのメモ帳に続けて書いていくと、後から見返したときにどの記述がどの取引先向けだったかが混ざり、確認の手間がかえって増えることがあります。この落とし穴は、一見すると「効率的にまとめている」ように見えるだけに、本人が気づきにくいという厄介さがあります。まとめて書くこと自体は悪くありませんが、まとめる前に、それぞれの案件の輪郭がどこにあるかを一度確認しておく必要があります。
プロセスとスレッドの区別は、引き継ぎの場面でも役立ちます。ある案件を別の担当者に引き継ぐとき、その案件が独立したプロセスとしてどれだけきちんと切り出されているかによって、引き継ぎのしやすさが変わります。案件の背景・関係者・現在の状態・次にやるべきことが、他の案件と混ざらずに1つのまとまりとして整理されていれば、引き継がれた側は新しいメモリ領域を読み込むだけで済みます。逆に、複数の案件の情報が本人の頭の中にしか存在せず、しかも互いに混ざっている状態だと、引き継ぎそのものが成立しません。これは11章で扱う「属人化」の問題ともつながっています。
もう一つ実務でよくあるのは、「大きな案件」の内部を、さらに独立したプロセスとして分割すべきかどうかという判断です。たとえば大きなプロジェクトの中に、性質の異なる複数の作業が含まれている場合、それらを1つのプロセスの中のスレッドとして扱うと、かえって境界があいまいになることがあります。締切や関係者が実質的に異なるほど大きな作業のかたまりであれば、いっそ別のプロセスとして切り出し、固有の期限と担当を与えたほうが、管理しやすくなる場合が多いのです。逆に、細かすぎる作業まですべて別プロセス扱いにすると、案件の数が増えすぎて、今度は案件どうしの切り替え自体が増えてしまいます。どこまで分けるかは、唯一の正解があるわけではなく、扱う仕事の性質に応じて決める判断です。迷ったときの目安は、締切と担当者のどちらか一方でも異なるなら、別プロセスとして切り出したほうが混乱が少ない、という点です。逆に、締切も担当者も完全に一致しているなら、無理に分けずに1つのプロセスの中のスレッドとして扱ってよいでしょう。この目安を持っておくだけで、案件を書き出す作業そのものの迷いが減ります。
実務での応用は、まず自分の抱えている仕事を「案件(プロセス)」の単位で書き出し、それぞれの中にある作業(スレッド)を書き出すことです。案件をまたぐ移動には心の準備がいる、同じ案件内の移動は身軽に動ける、という前提で1日の流れを組み立てると、切り替えの負担そのものが減ります。書き出す作業自体に時間はかかりませんが、一度書き出しておけば、その後の何日にもわたって、優先順位づけの判断材料として使い続けられます。次のページでは、この切り替えに実際どれだけのコストが乗っているのかを、さらに詳しく見ていきます。
持ち帰り
- プロセスは独立した案件、スレッドは同じ案件内の複数の作業の流れである
- プロセスをまたぐ切り替えは重く、スレッド間の切り替えは軽い
- タスクを並べるときは、どの案件(プロセス)に属するかをまず区別する
やってみる
今抱えているタスクを紙やメモに書き出し、同じ案件に属するものを線で囲んでみてください。案件の数と、案件をまたぐ移動の回数が見えてきます。囲み終えたら、案件をまたぐ移動が1日に何回起きているかも数えてみると、次のページで扱う切り替えコストの話がより具体的につながります。