タスク管理はソフトスキルとして非常に重要ですが、未だにろくに整備されていません。
※プロジェクトのタスク管理ではなく、自分で自分のタスクを管理するという 個人タスク管理 の話です。
おそらく管理という言葉が良くないのでしょう。別の言葉で捉え直した方が良いと考えました。私達はエンジニアなのでエンジニアリングとして捉えるのはどうでしょうか。つまりタスク工学です。
そもそも、なぜタスク管理が重要なのかというと、自律的に働くために必要なスキル だからです。
自律的に働けない者は悲惨です。物理的に集合して、場の雰囲気やメンバーからの声掛けによって駆動する 反応駆動（Reaction Driven） しか取れません。これが合う人や、このスタイルでこそ結果を出せる人もいますが、通常はそうではない。Online Meeting Sucks でも述べたとおり、エンジニアリングの本懐は孤独に集中することにあります。そうしてつくったものを、ミーティングなりコラボレーションなりで揉めば良い。もちろんたまには雑談でもリトリートでもして交流すればいい。それでも、最も重要なのは孤独な集中なのです。
さて、孤独に集中するにはタスク管理（個人タスク管理）が必要です。自分を律さないといけないからです。また仕事なのでコミュニケーションの機会はあります。集中モードとコミュニケーションモードを切り替えねばならず、これも自分を律することに含まれます。
プログラミングを行うための道具であるエディタやターミナルのスキルが必要なように、エンジニアリングを行うエンジニアという「人間」を律する「タスク管理」というスキルが必要 なのです。
本題に入りましょう。タスク工学（Task Engineering） とは、タスクという概念を上手く扱うためのエンジニアリングです。
明確な理論や体系はまだありませんが、私は以前オンライン書籍として整理したことがあります。
必要な概念はおおよそ出揃っていると思います。
以降では、上述のオンライン書籍の内容をベースに、タスク工学の構成要素をピックアップします。おおよそどのような概念が要求されるかを感じ取ってください。そして、自分ならどうやって実現するか、特にエンジニアとして上手く取り入れるかを考えてみてください。
本記事のフォーカスは個人タスク管理ですが、この目線での分類は 3 つあると思っており、私は 3P として整理しました。
| 名前 | 対象 | 主な性質 |
|---|---|---|
| Project | プロジェクト（チーム） | 割り当て、調整、全体俯瞰と個別詳細 |
| Partner | パートナー（夫婦、親子） | タスクの共有とメッセージのやり取り |
| Personal | パーソナル（個人） | 人それぞれ |
それぞれジャンルが全く異なります。特にプロジェクトタスク管理と個人タスク管理は分けねばなりません。
タスクと聞いて皆さんが思い浮かべるのはプロジェクトの方だと思いますが、タスク工学の主戦場は個人です。プロジェクトの方は、プロジェクトマネジメントや開発手法などでカバーしているので放っておいてもいいです。それよりも、各個人が自分に合ったタスクの扱い方を模索するとの観点が圧倒的に不足しているので、タスク工学として強化するべきと考えています。
個人タスク管理はアスリートのような営みになります。結局のところ、タスクを可視化して、それを見ながら優先順位を判断して、一つずつ潰していくものだからです。可視化や優先順位付けも大事ですが、それ以上に *「書いてあるタスクをちゃんとこなす」パワーが最も重要です。
プログラムは書かれたコードのとおりに動作しますが、人間はそうもいきません。それでもそうしないといけないのです。これは身体的にも精神的にもキツイことであり、私は アスリート とたとえます。実際、普段から習慣に頼って健康的な肉体と健全な精神を維持することが不可欠です。
一方で、もう一つのタイプがあります。頭の中が普段から慌ただしくて、じっとしていられない性分の人がわかりやすいと思います。この人達はアスリートにはなれません（したがって個人タスク管理がそもそも向いてません）が、頭の処理能力は高いのでパフォーマンスは高い。これを私は アプライア（Applier） と呼んでいます。応用が得意です。
まとめましょう。
長くなりましたが、この節で一番言いたい事を言います。個人タスク管理においては、
つまり アスリートなのに環境の力に頼ったり、逆にアプライアなのに自分でつくろうとしたりといったミスマッチはやめましょう。
タスク管理の戦略とは、どんなやり方や考え方で望むかという方針のことです。これは「何を拠り所にするか」で分けることができます。
主な戦略を挙げます:
次にタスク管理のスタンスとは、タスクをどう処理するかという対応パターンを指します。メンタルモデルと言っても良いかもしれません。戦略は「どう扱うか」という管理の話でしたが、スタンスは「どうこなすか」という処理の話です。
主なスタンスを挙げます:
いかがでしたか。皆さんも上記のいずれかの戦略とスタンスを取っているはずです。もちろん場合によって複数を使い分けるのも普通です。特に目新しいことは言っていませんが、こうして言語化して捉えることに意味があります。エンジニアリングも言語化と設計から始まりますよね。
私はタスクのようでタスクでないものを オルタスク（Altask） と呼んでいます。オルタスクはタスクではないので、タスクとは違った扱い方をしないといけません。
オルタスクとして以下があります。
わかりやすいのがイベントで、イベントはおそらくカレンダーを使うでしょう。イベントをタスクリストで管理しようとする人はいないはずです。このようなオルタスクは、イベントの他にも色々あるのです。
Ans: いいえ、気のせいではありません。
むしろ重要です。
タスク工学として向き合うのはタスクだけではありません。タスクとだけ向き合っていてもタスクはこなせないからです。たとえばタスクを発生させる原因（オルタスク）や、タスクを遂行する自分自身の性質やメンテナンスにも気を配らねばなりません。
タスク工学では、このような周辺領域もカバーします。ですので、見かけ上はタスクと直接関係がないことも扱っているように見えます。
タスクを全部頭の中に入れて、忘れることなく、怠けることもなく、もちろん迷うこともなくすべてを消化することなど不可能です。現実的には 必要なときに思い出す しかありません。リマインダーはすでにご存知でしょうが、この「思い出せる仕組み」は非常に重要です。
動線とリマインドがあります。
動線(Waypoint) とは、普段私達が頻繁に通る場所を指します。PC のデスクトップがアイコンが散らかっていて日々あれこれ触っているなら、そこはその人個人の動線です。プロジェクトとして毎日必ずよく見る Slack チャンネルがあるのなら、そこも動線です。ダッシュボードやデイリーノートをつくっていたり、最近だと ChatGPT Projects のような「AI も居座っているワークスペース」も見かけます。
動線があると、そこにタスクを置いておくことでそのうち目に入るので思い出せます。これを トラップ・リマインド と呼びます。罠を仕掛けておいて、あとで引っかける（自らひっかかる）というニュアンスです。
次に リマインド とは、「未来のあるタイミング」に「事前に仕込んでいた用件」を思い出させる仕組みを指します。
一番単純なのが目覚まし時計で、これは指定時間に、音を使って（起きるという用件を間接的に）知らせます。私達が普段使っているのはカレンダーによるもので、n 分前にアラームやポップアップが届いているかと思います。
また、物理的に集まって仕事をすると良くも悪くも場の雰囲気がわかり、次何をすればいいかが自然と（もしくは無理やり）知らされますが、これもリマインドの一種であり、私は雰囲気リマインド（Atmosphere Remind）と呼んでいます。
さて、リマインドですが、これは単純な話で リマインドについて知っていれば知っているほど、より決めの細かいリマインダーを仕掛けやすくなります。逆に考えてみてください。もしあなたが目覚まし時計しか使えないとしたら、どうでしょう。相当不便でしょうし、おそらく形骸化します。そして様々な打ち合わせや「あとでやるべこと」を忘れてしまうのです……。
割り込み はエンジニアの敵である――この主張に異論は無いと思います。必要悪と諦めている人も多いと思いますが、違います。割り込みは減らせますし、何ならなくせます。そのためには「割り込みとはそもそも何なのか」「どういうメカニズムで発生するのか」「回避するために、どんな代替の仕組みをつくらねばならないか」といったことを考えねばなりません。
もう一つ、割り込みと区別したい概念があって、脱線 です。割り込みは他者から強制的にもたらされますが、脱線は自分自身によって注意が逸れるものです。スマホに通知が来たからちょっと覗こう、といったことですね。
タスク工学では、この割り込みと脱線もしっかりと扱います。たとえば以下は私が開発した SWAP マトリックスであり、4 パターンに分けて対処できるようにしています。
| Strong (強い後回し) | Weak (弱い後回し) | |
|---|---|---|
| (Active) 割り込み | パターン1 | パターン2 |
| (Passive) 脱線 | パターン3 | パターン4 |
※ちなみに 後回し とは、タスクAをやっている最中にタスクBが来たときに、どちらか片方を後回しにしなければならないということです。Bを後回しにした場合、自分が強いので「強い後回し」と言います。Aを後回しにした場合、Bに負けたということなので「弱い後回し」と言います。
文芸的タスク管理（Literate Task Management） とは、文芸的に行うタスク管理を指します。LTM と略します。
日本で開発され始めている概念であり、文芸的プログラミングから着想を得ています。従来のタスク管理は、タスクという情報をチケットのように機械的に扱っていました。
LTM では、まず日記や思考や調査まで文章として書き記します。その上で、必要に応じてタスクの情報も記述します。タスクを抽出したい場合は、文章から上手く抽出します。つまり文章ファーストだと言えます。
なぜそんなことをするかというと、文脈を意識できる からです。文脈を意識せず、思考停止して目の前のタスクを処理し続けるのは愚かなことです。通常は相応の文脈があり、正解も無くて、文脈に応じた最適な戦略を考えねばならないはずです。LTM を使うと、文脈を意識しやすいのです。また、副次的なメリットとして、生成 AI に食わせて分析がしやすい点も挙げられます。
エンジニアにはまだ馴染みづらい考え方かもしれませんが、すでに Obdisian などを使って、ローカルで自分なりのテキストステーションをつくっている人もいるでしょう。
個人タスク管理は、自律的に働くための必須スキルです。その割には整備されていません。管理という言葉が悪いのでしょう……というわけで、タスク工学という新しい言葉を提唱しました。
私はナレッジ・アーキテクトであり、ソフトスキル・エンジニアでもあります。近年の大仕事として、すでにタスク管理の基礎概念を整理しています（冒頭のオンライン書籍）。本記事では、書籍の内容をベースに、タスク工学の登場人物をかんたんに紹介してみました。
いかがでしたか。たかが個人タスクと言えど、そうかんたんではないことがおわかりいただけたかと思います。まだまだ発展途上であり、皆さんの試行と議論も必要としています。ぜひタスク工学の世界に、足を踏み入れてみてください！