脳内コンテキストスイッチの最適化

CTOという、様々なAccountabilityが集約されがちなポジションを担っている関係上、今回の主題に上げているコンテキストスイッチにはずっと直面してきた。

まだこのコンテキストスイッチの課題を完全に解決できてはいないものの、現状の対策方法をメモし、あわよくばうまくやっている人からのFBを貰えるといいなぁと思い、記事化することにした。

コンテキストスイッチとは

もともとはCPUのマルチタスク/割り込み処理の話から作られた言葉。一つのCPUで複数の処理を実行する際、すでに処理されているプロセスを一時的に止めて別のタスクを実行することを指す。この「現在進めているタスクをとめ、他のタスクを行う」という現象はコンピュータだけではなく人間の世界でも発生するので転用されているのだと思う。

特に「タスクの切り替えの際にレジスタへの退避・復元にオーバーヘッドが発生する」という特徴が、人間の脳みそでも再現する特徴であり、とくにクリエイティビティが問われるエンジニアリングの世界においては致命的なオーバーヘッドになりがちなので、ことエンジニアリングの世界で多用されているのかなという風に思っている。

オーバーヘッドの要因１：集中力

人間は機械のように、与えられたタスクをほぼ同時間でこなせるようなレベルには達していない。集中力というものに起因し、タスクのスピード・質が大きく変わってくるためだ。特にフロー状態と呼ばれる脳の活性化状態に自分を持っていくと大きくパフォーマンスが上がるので、その状態にいかに持っていけるかがクリエイティビティを必要とする業務では必要で、フロー状態のオン・オフには非常に大きなコストを必要とする。

タスク移動の際、集中力は切れがちなため、タスク移動でも集中力が切れないようにするか、計画的に集中力のオン・オフを組み込むことによって、集中力の問題に退治することができる

タスク移動で集中力が切れないためには、コンテキストが親しいタスク同士の移動を意識するといい。例えばslackの応答などのメッセージのやり取りは比較的軽微なエネルギーの使用になるが、コーディング特に設計に関しては大量のエネルギーを要するため、メッセージのやり取りの時間とコーディングの時間を明確にわけるほうがいいかもしれない。また複数案件を同時並行しているのであれば、案件ごとのコンテキストの幅が大きいため、なるべく同じタイミングで同じ案件を処理するといった工夫となる。

計画的に集中力のオン・オフを組み込む方法として、ポモドーロテクニックというものがある。簡単に言うと25分集中し5分休むというサイクルを繰り返す方法。この25分間には同一のコンテキストタスクを組み込むことによって、5分区切り後に別のコンテキストのタスクを組み込んでも定期的な集中力の切断サイクルに載せられるため、集中力低下によるパフォーマンス低下には陥りづらい。注意点としては、ポモドーロテクニックには事前の計画と振り返りが組み込まれているものの、高頻度の割り込みタスクがあるような環境下ではこの25分区切りが足かせになることもあるので、このテクニックはある程度まとまったタスクを実行しなければならないときに有効かと思われる。

オーバーヘッドの要因２：記憶領域の使い方

本来の意味でのコンテキストスイッチでは、レジスタに一時的にその時の状態を止めておいて、復帰時にそれを復元しタスクを再開するようになっている。

人間のタスク（特に高度なタスクであればあるほど）その状態の記憶には非常に多くの情報が必要となってくる事が多いが、当然人間は忘れっぽいしそれほど一度に記憶できる量も多くないため、コンテキストスイッチのたびに人間の記憶領域だけに頼っていると、復元の際にタスクのやり直しなどが発生し多大なオーバーヘッドが発生してしまう。一方タスクごとにいちいちメモツールなどにメモをしていても、それそのものがタスクの効率を下げる要因にもなるためバランスが必要。

タスクをメモするという動作そのものにも記憶領域が必要になってくるので、いかにメモ化にコストを割かないかという工夫が必要になってくる。例えばslackでのやり取りを行っているのであれば、メッセージに対してリアクションをつけることによって自分の管理しているTODOアプリケーションに追加されるようにすればメモ化のコストはほとんどゼロになる。

また最近は文字起こしの精度も上がってきているので、雑に音声化しておいて、後で整形するという形でもメモ化のコストを下げられるかもしれない。

また、TODO化をした際が一番そのタスクに対しての重要性を理解しているタイミングなので、その場で既存タスクとの優先度付と期日設定を行うことによって、常に最適なタスクの順位に変更させられつつ、期日や重要性を脳内メモリに保存しなくて良くなる。

最後に

そもそもコンテキストスイッチが発生しない状況を作れればこんな事は考えなくてもいい。行動責任を追うタスクはもちろん説明責任を追うタスクに関しても積極的に移譲し、本来自分が負うべきタスクにフォーカスできたほうが少なくとも個人の生産性は上がるはずだし、もしかしたら全体の生産性も上がるかもしれない。個人的にはなかなか移譲が得意ではないので、ここに関してはいい方法を今後も模索していきたい。