このページの問いは、切り替えのコストを知ったうえで、実際にどう時間を組み立てればよいか、です。ここまでの3つのページで、案件の区別、切り替えのコスト、割り込みの制御を見てきました。このページでは、それらを踏まえた2つの具体的な設計を扱います。ここまでの内容が「なぜ切り替えは高くつくのか」という理解だったとすれば、このページは「では実際に、時間割をどう組み立てればよいのか」という実践編にあたります。
1つ目は「シングルタスク設計」です。これは、ある時間帯を1つの案件(プロセス)だけに割り当て、その時間内は他の案件に切り替えないという決め方です。コンピュータでたとえるなら、ある処理が終わるまで、他のプログラムへの切り替えをできる限り発生させない運用に近いものです。前のページのマスキングと組み合わせることで実現します。通知を受け付けない時間をつくり、その時間はひとつの案件だけに使うのです。
これは、コンピュータの世界で使われる「一括処理」という考え方にも、かなり近いものです。ある種のプログラムは、あえて他の処理と時間を分け、まとまった時間を専有して一気に処理を終わらせる設計になっています。細切れに少しずつ進めるよりも、まとまった時間を確保して一気に片づけたほうが、切り替えの手間がかからず、結果として早く終わることがあるからです。人間の仕事でも同じ発想が成り立ちます。90分を細切れの30分×3回に分けるのと、まとまった90分を1回で確保するのとでは、同じ時間でも実際に進む量が違って見えるのは、この一括処理の考え方で説明がつきます。
シングルタスク設計の効果は、切り替えコストがそもそも発生しないことです。報告書を書く90分を確保できれば、その90分の間は「どこまで書いていたか」を思い出す作業が一度も発生しません。90分丸ごとが、実際の執筆に使われます。同じ90分を、他の案件との往復に細切れに使ってしまった場合と比べると、実質的に使える時間の差は決して小さくありません。
シングルタスク設計は、単に「1つのことをやる」という漠然とした心構えではなく、時間帯という具体的な単位で区切ることが重要です。頭の中で「今は報告書に集中しよう」と念じるだけでは、通知が鳴れば結局反応してしまいます。前のページで見たマスキングと組み合わせて、物理的に他の案件が入り込めない状態を作ることで、初めて実効性を持ちます。心構えではなく仕組みとして用意する、という点が、この設計の肝になります。
2つ目は「バッチ処理」です。これは、似た種類の小さな仕事を、発生するたびに個別に処理するのではなく、まとめて一度に処理するという考え方です。コンピュータの世界でも、印刷指示や集計処理などは、発生した順に1件ずつすぐに実行するのではなく、一定数がたまってからまとめて実行することがあります。1件ごとの応答は遅くなりますが、全体の処理量、つまりスループットは上がります。
シングルタスク設計とバッチ処理は、似ているようで狙いが異なります。シングルタスク設計は、1つの重い案件に、まとまった連続した時間を割り当てる設計です。一方バッチ処理は、複数の軽い案件を、時間的にまとめて連続処理する設計です。前者は「1つの案件にどれだけ長く連続して取り組めるか」に焦点があり、後者は「似た性質の複数の案件をどれだけまとめて処理できるか」に焦点があります。どちらも切り替えの回数そのものを減らすという共通の目的を持ちながら、対象とする仕事の粒度が違うのだと理解しておいてください。
これを仕事に置き換えると、経費精算の承認、短い問い合わせへの返信、日々発生する簡単な確認依頼などが、バッチ処理に向いています。届くたびに1件ずつ処理するのではなく、「経費精算は毎日16時にまとめて承認する」「短い確認メールは11時と17時にまとめて返す」と決めておくのです。1件あたりの返信は多少遅くなりますが、その都度の切り替えが発生しなくなるため、1日全体で見ると処理できる件数は増えていきます。
バッチ処理には、もうひとつ見落とされがちな利点があります。同じ種類の作業をまとめて行うと、1件ごとに毎回思い出していた「進め方の手順」を、まとめて処理する間はずっとそのままの形で保持していられることです。経費精算の承認作業では、確認すべき項目や、よくある差し戻しのパターンがあらかじめ決まっています。これを1件ずつ日中に散発的に処理すると、毎回この手順を頭に呼び出し直す必要がありますが、まとめて10件処理すれば、手順を1回思い出すだけで済みます。これは、前のページで見たスレッド間の切り替えが軽い理由と同じ構造です。同じ種類の作業は、同じ「進め方」というメモリ領域を共有しているのです。
具体的な場面を見てみます。1つ目は、週次報告を書く時間を朝の90分に固定し、その時間帯はチャットも電話対応も入れないと決める場面です。これはシングルタスク設計の典型です。2つ目は、部下からの承認依頼を、届いた順にその都度処理するのではなく、1日に2回、決まった時間にまとめて処理する場面です。これはバッチ処理です。3つ目は、会議調整のような似た性質の細かい連絡を1つの時間帯にまとめて片づけ、それ以外の時間は他の案件に専念する場面です。これは両方の考え方を組み合わせています。
4つ目は、社内で日常的に発生する資料のレビュー依頼です。複数の部下や同僚から資料のレビューを頼まれる立場にあるなら、依頼が来るたびにその都度目を通すのではなく、1日1回、決まった時間にまとめてレビューする運用にできます。レビューという作業は、視点の切り替えに独特の負担があります。1件ごとに評価の基準を頭に呼び出す必要があるため、まとめて連続して行うほうが、基準を保持したまま効率的に進められます。5つ目は、複数の部署をまたいで発生する、日程や情報の調整ごとです。複数の関係者に同じ内容を個別に説明して回るのではなく、いったん情報を整理し、まとめて1回の連絡や会議で伝えるほうが、説明する側の切り替えコストも、聞く側の理解の食い違いも減らせます。
バッチ処理を実際にやってみた場面を見てみます。あなたは経費精算の承認を、届くたびに処理するのをやめ、毎日16時にまとめて行うと決めました。16時になると、承認待ちが7件たまっています。1件目を開き、金額と領収書を確認し、承認ボタンを押します。2件目も同じ手順です。3件目で、領収書の日付がずれている案件を見つけ、本人にひとことメッセージを送ります。「日付が1日ずれているので確認をお願いします」。残りを承認し終えるまで、10分ほどで済みました。確認すべき項目を毎回思い出す手間が、まとめて処理したことで一度で済んだのです。
ここでの落とし穴は、何でもかんでもシングルタスク化やバッチ処理にしてしまうことです。前のページで見たとおり、本当に緊急なものまで「まとめて処理する時間」に押し込めてしまうと、対応が遅れて実害が出ます。バッチ処理に向いているのは、多少遅れても実害が少なく、かつ似た性質を持つ仕事に限られます。取引先からの重大な苦情や、安全に関わる連絡は、バッチ処理の対象から外し、割り込みとして即座に扱うべきものです。
見分け方のもうひとつの軸は、待たせることで相手の作業が止まってしまうかどうかです。たとえば、部下があなたの承認をずっと待って次の作業に進めない状態にあるなら、それは実質的に相手の仕事全体を止めていることになります。この場合、バッチ処理の間隔を長く取りすぎると、あなたの手元では効率化できても、組織全体で見ると待ち時間がかえって増えてしまいます。バッチ処理を導入するときは、自分の効率だけでなく、待たされる側の負担も一緒に考える必要があります。この視点は、待ち時間そのものの設計を扱う3章の内容にも、通じるものです。
もうひとつの落とし穴は、シングルタスクの時間を確保したつもりでも、その中で扱う案件を絞り込めていないことです。90分を確保しても、その中で報告書と問い合わせ対応を行き来していては、切り替えコストは変わらず発生します。シングルタスク設計は、時間を区切ることと、その時間の中身を1つの案件に絞り込むことの、両方があって初めて効果を持ちます。
さらに言えば、時間帯だけを区切って、案件そのものを事前に絞り込まずに終わってしまうケースは、実際の職場でよく見られます。「午前中は集中タイム」と決めても、その中身が具体的にどの案件かを決めていなければ、結局その場の気分や、目についた依頼から手をつけることになり、案件をまたぐ切り替えが起きてしまいます。シングルタスクの時間を確保するときは、時間帯だけでなく、「この90分は週次報告だけ」というように、扱う案件名まで具体的に決めておくことが欠かせません。
この2つの設計は、対象とする仕事の性質そのものが違うことにも、注意しておいてください。シングルタスク設計は、まとまった思考が必要で、途中で切ると立て直しに時間がかかる仕事に向いています。報告書の執筆や、込み入った提案の検討などがこれにあたります。バッチ処理は、1件あたりは短いが件数が多く、性質が似ている仕事に向いています。どちらの設計を使うかは、目の前の仕事が「重いが少数」か「軽いが多数」かで見分けるとよいでしょう。
実際の1日は、この2つを組み合わせて設計することになります。たとえば、朝の90分をシングルタスクで週次報告に充て、昼前の30分をバッチ処理で経費承認とメール返信に充て、午後は会議と会議の合間に残った時間を、緊急度の高い個別対応に使う、という組み方です。1日のすべての時間帯を、どちらか一方の型に無理に当てはめる必要はありません。重い仕事にはシングルタスクの時間を、軽く似た仕事にはバッチ処理の時間を、そして本当に緊急なものにはどちらの型にも属さない即応の余白を、あらかじめ残しておくという3層構造で考えると、無理なく1日の時間割を組み立てられます。この余白の部分こそが、前のページで見た「マスクできない経路」から届く連絡を、実際に受け止める先になります。
最後に、シングルタスク設計とバッチ処理のどちらも、最初から完璧に運用しようとしなくてよい、という点を付け加えておきます。まずは1日に1つの時間帯だけ試してみて、うまくいかなければ長さや対象を少しずつ調整していく、という小さな試行から始めるのが現実的です。周囲の反応を見ながら、無理のない範囲で少しずつ運用を育てていけばよいのです。最初から完璧な時間割を目指す必要はまったくありません。
持ち帰り
- シングルタスク設計は、ある時間帯をひとつの案件だけに専念させ、切り替えコストの発生自体を防ぐ
- バッチ処理は、似た小さな仕事をまとめて処理し、1件あたりの速さより全体の処理量を優先する
- 緊急性が高く実害の出るものは、バッチ処理やシングルタスクの対象から外し、即座に対応する
この章の最後のページでは、ここまで見てきたプロセスとスレッド、コンテキストスイッチのコスト、割り込みとマスキング、シングルタスク設計とバッチ処理という5つの道具立てを、あらためて1枚の地図として整理し、次章のスケジューリングにつなげます。
やってみる
明日、似た種類の小さな依頼(経費承認や簡単な確認メールなど)をひとつ選び、届くたびにその場で処理するのをやめて、決まった時間にまとめて処理してみてください。