Chapter 15
タスクソース

2024.09.09に更新
このチャプターの目次
 タスクソースの概要
 概要タスクソース（Task Source） とはタスクを生み出す何らかのもの――特に言語化されたものを指します。ソース（Source）とは源泉を意味し、まさにタスクの源泉というわけです。
序盤の章で解釈の公理について述べましたが、ある事柄がタスクであるかどうかは人次第です。その人がタスクだと解釈すればタスクですし、タスクではないと思うならタスクではありません。また同じ人であっても、状況次第でタスクだと解釈したりしなかったりするでしょう。
タスクソースもまさに解釈が絡んでいるもので、ソースからいつどんなタスクをつくるか（解釈するか）はその人次第です。引っ越ししたいという「やりたいこと」があるとして、ここからいつどんなタスクをつくるかは人次第ですよね。遠い願望くらいに考えてる人なら当面は何もつくらないでしょうが、極論近所トラブルやストーカー被害など喫緊の理由により今すぐやりたくなるかもしれません。いずれにせよ、「引っ越ししたい」なるソースがあるからといってタスクも絶対に存在するかというとそうではなく、あくまでタスク化しているのは私達自身の解釈にすぎません。
さて、この「引っ越ししたい」のような事柄をタスクとして扱っても上手くいきません。すでに述べたとおり、粒度が粗すぎて具体的に何をすればいいかがわからないからです。そもそもこんな雑な事柄を扱うだけで上手くいくなら、タスク管理など要りません。かといって、じゃあその場で事細かに具体的なタスクに分解するかというと、仕事でもなければ中々できないでしょうし、仕事でやったとしても上手くいくとは限りません（プロジェクトタスク管理は難しい）。そもそもすでに書いたように、同じ自分であっても状況次第で解釈は変わるのです。
ここでタスクソースの考え方を導入すると比較的やりやすくなります。具体的には、ソースはソースとしてリストアップなり掲示なりしておいて、これらから必要に応じて必要なタスクをその都度つくります。

 タスクソースの例タスクソースの例を示します。
目標事項
達成可否が存在する、道しるべとなるもの
例: 目的、目標、大タスクなど粒度の粗いタスク、プロジェクトなどのコンテナ

維持事項
恒久的に維持したいこと
例: 日課、習慣、一部のモットー

連想事項
何らかの事物を思い出す・思い起こすためのヒントとして使うもの
例: トリガーリスト、ブレストなど発想法で出力したもの全般、何らかの俯瞰全般

発想事項
ひらめきや思いつきを促すもの、インスピレーションのもととなるもの
例: 人によって著しく異なる

いずれも言語化されたものを想定していることに注意してください。なので具体的な人、場所、物タスク、画像や動画といったものはタスクソースではありません。これらリッチな事物もソースとみなして、タスクを生み出すことはできますが本章では扱いません。
以下、分かりづらい部分をもう少し解説します。
コンテナは目標事項とみなすこともできます。コンテナは通常、すでに存在するタスクや今後発生しうるタスクを束ねる単位であり、ソースからタスクを生み出すというよりも、既存のものを捕まえてくるイメージですが、実は前者として扱うこともできます。仕事においても、仮説や想像に基づいて先手を打っておく・先回りをしておくことは珍しくないと思いますが、これはいわばコンテナをソースとみなして、自分なりにタスクをつくっているわけです。
維持事項は、タスクソースとして最もわかりやすいかもしれません。たとえば「体重を 50kg 以内でキープする」との維持事項があった場合、そのために日々何をするかは別途タスク化するべきです。決意だけでは何も変わりませんし、もちろんタスク管理ツールに「50 kg 以内をキープする」など書いておいてもおそらく何もしません。普通は「毎日 2 km 走る」のような定期的なタスクをつくりつつ、脚を痛めたなら通院するでしょうし、シューズが敗れたなら買い替えるでしょうし、梅雨が近づいたら別のメニューに変えるなりレインウェアを購入するなりとスポットでもタスクを（適切なタイミングで実行できるよう上手く）入れて調整します。
連想事項と発想事項はわかりづらいですが、連想事項の方が身近です。アイデア出しとか発散とも言いますが、連想的に色んな記憶や知識を引っ張りたいことがよくあり、連想事項とはその際に目にいれるものです。たとえば「人生について考えたいときに見るといい 10 のリスト」なるものをつくっておけば、人生について考えたいときにそれを見ることで連想の助けになります。一から発想するよりははるかに楽なことです。またフィクションでも、主要人物の顔写真や相関関係を視覚化してそれを眺めているシーンがよくありますが、これも連想のヒントとして顔写真を使っている（そして並べることで俯瞰している）のです。
発想事項については、連想とは違って、ひらめきや思いつきといった「ゼロから急に何かが浮かぶ」感じを狙うものです。通常、発想はタスクソースの形で狙って出すことはできず、アイデアの 3B（入浴中、乗り物で移動中、寝るとき）ともいいますが、リラックスしてぼーっとしているときに降ってくることが多いです。これを意図的に狙うのが発想事項で、インスピレーションと呼ばれることもあります。発想事項とはインスピレーションを得るための言語化された何かです（※1）。何が発想事項であるかは人によって著しく異なり、詩などの美しい文章の人もいれば、格言やことわざなどの人もいるでしょうし、国語辞典の人もいるかもしれません。筆者の場合は「デジタルツールのヘルプ」や「個人的に気に入っていて、あまり難しいことを言わず、でもタスク管理など仕事術に関することを言う人の投稿」などが発想事項です。体感ですが、強張らず疲れてもなくてリラックスした頭でニュートラルに読めるかどうかが肝心という気がしています。ひらめいたものは、そのままだと見逃すのでタスク化します（その前段としてメモ化することも多い）。
※
1 インスピレーションというと芸術的な文脈を浮かべると思いますが、実際そのとおりで、言語的な情報よりも非言語的な情報、何なら体験の方がよくもたらされます。言語情報にとらわれる必要性はありません。ただ、本書ではタスクとは言語化されたものであるとの立場を取っているため、本章におけるタスクソースも（発想事項を含め）言語化されたもの、との定義にしています。


 タスクソースの運用
 目標事項と維持事項の運用メモのフローと同じような流れに沿います。タスクソースの定義 → 読み返し → タスク化、です。
まずタスクソースを定義するところは、いきなりですが一番大事な部分です。目標は達成するまで続きますし、維持事項に至ってはともすると一生続きます。長期的に続けても耐えられるほどの何かが必要で、何かとは納得感または信念です。アスリートタイプの人なら「とりあえず半年続けてみるかー」もできますが少数派でしょう。納得感も信念もない場合は、おそらく続かないため、最初から諦めた方がいいでしょう。またひとりでこれらが手に入らない場合は、誰かに従ったりどこかに行ったりしてとりあえず従ってみる、くらいに割り切った方がやりやすかったりします。ただし依存しすぎるとハメられたり抜け出せなくなったりするので一歩引いた姿勢も欲しいところです。次の読み返しも良い防波堤になります。
タスクソースを定義した後は、日々読み返す行動が必要です。タスクソースを見て、現状もかえりみた上で、じゃあ次は何しようかと考える（そしてタスク化する）のです。あるいは支障がない範囲で思い出せるなら、明示的にソースを見るなどという行動は要りません――が、そうかんたんにはいかないので、通常は意図的に読み返す機会を確保することになります。かといって、読み返しすぎても今度は麻痺してしまって形骸化する（確信的にサボることも含む）のが難しいところです。目標事項の場合は、進捗という形で 100% に近づいていくことを可視化できればモチベーションは維持しやすいです。維持事項はそうもいかず、事実上日々の読み返しやタスクを楽しめるかどうかが争点となります。
読み返すだけでは意味がないので、タスク化も行ないます。毎回行う必要はありませんが、毎回行うかどうか判断するのも面倒くさくて形骸化に繋がりがちです。かといって「毎日 2km 走る」のように予定にしてしまっても、これはこれは苦しくなります。どういうバランスだと続くのかは自分で微調整していかないといけません。別の言い方をすれば、微調整という営みは避けられません。微調整を行うことから逃げると十中八九形骸化します。「微調整する努力ができるかどうか」は一種の目安です。できない場合は、タスクソースの定義の部分でも述べたように、納得感や信念が足りないと思います。あるいは微調整という細かい営みを行えるだけの資質がないか、です。
この一連の流れを上手く言語化、体系化しているのがGTDやPARAメソッドです。どちらもタスクソースをリストアップしておくことと、定期的に読み返して必要ならタスク化を行うこと（特にGTDではレビューと呼んでます）を説いています。
もう一つ、納得感や信念を足らせるためには、自分についてよく理解しておく必要もあります。自己理解、自己認識、自己分析など色々な言い方がありますし、自己啓発の文脈でもよく語られますが、大事なことです。自分のことを理解しているからこそ、これは合う、これは合わない、こっちは合いそう、こっちは合わなそうといった判断や行動ができるのです。もはやタスク管理からは離れていますが、タスクを管理するのは私たち自身であり、かつ私たちは人間であって意志や事情や好き嫌いがあります。自己理解は実は非常に重要でして、ここができてないと自己判断もできず、言いなりになるか多忙に身を置いて誤魔化すかしかできなくなってしまいます（このような生き方が悪いと言っているわけではない）。

 連想事項の運用方向性は 3 つあります。
1: 連想リストの運用
2: 発散と収束の営み
3: 俯瞰のつくりこみ

 連想リスト連想リスト（トリガーリスト） とは、何らかの連想を引き出すための自問自答集・ヒント集のことです。チェックリストとも似ていますが、各項目を全部消化しなければならない制約はなく、もっと雑に使ってもいいものです。1 つの項目から 10 個連想してもいいですし、「何も浮かばないからこれはいいや」と無視しても構いません。とにかく連想を引き出すために、テキトーに使えばいいのです。
この連想リストをどれだけ揃えられるかが、日々どれだけ連想の質を上げられるかの分かれ目になります。私たちの人生は、よほど難しい仕事をしているのでなければ、基本的に答えは単純です。ただそれに至ったり、納得感を見出したりするのに苦戦しているだけです。ここをショートカットできるのが連想で、別の言い方をすれば「考え抜く」「思考の隙や死角をなくす」とでも言えましょうか。正解かどうかはわからないし、正しいかもわからないが、自分としては考え抜いたぞ、これ以上はないぞ――と自信を持って言えるようにしたいのです。特に現代は私たちの目も肥え、VUCA で先が読めない時代でもあるからこそ重要だと思います。とはいえ、何も無しに考え抜くことはできないので、連想リストなるヒントを揃えておいて、これベースに膨らませていきましょう、とするのです。
連想リストの例を挙げます。
生活:
やりたいことリスト
いつできるかはわからないが、いつかやりたいことをリストアップしたものです
GTD でも「いつかやるリスト」が存在します
項目数が数百、数千以上にのぼることもざらにあります
重複も肥大化も気にせずとにかく追記することと、眺めるときは完璧主義を捨てて肩の力を抜いて眺めることがポイントかと思います

人生について考えるときに見るリスト
書籍『28歳からのリアル』で取り上げている以下 8 要素を並べたものです
(1) 仕事、(2) 結婚、(3) お金、(4) 住まい、(5) 健康、(6) 親、(7) 趣味、(8) 常識
これを見ながらだと「結婚についてはどうしようか」「住まいは……」などと連想がしやすくて、筆者としても重宝しています

生活のコツ128
生活のコツを128並べてみる - 山下泰平の趣味の方法
明治時代の「簡易生活」を前提に、生活のコツを128個並べています
合う合わないはあるでしょうが、部分的にでも取り入れてみたいなど考えながら読むと生活の足しになります
筆者は道路で過ごすときの QoL の低さが長年悩みでしたが、043 を見て自分の方が気をつけるしかないと決断できました（そのために普段使うルートや時間帯を設計し直すタスクを追加したりした）


自己啓発リスト
自己啓発 - Wikipedia
Wiikpedia のページで、自己啓発の主要なテーマがリストアップされています
自分に足りない視点やソフトスキルを探したい、何とかしたいときに見ると連想が捗ります

仕事:
プロジェクトリスト
自分が抱えている仕事や用事をリストアップしたものです
どんな粒度で並べるか、読み返しの頻度はどうするかなど奥が深いですが、これを眺めれば「そろそろアレやっておかないとな」など思い出しやすくなります

ピープルリストやポジションリスト
自分が普段絡んでいる人や役割の名前をリストアップしたものです
仕事で次何をするべきかとか、組織内で今後どうしていこうか等を考えるときに役立ちます
人によっては図の方が連想しやすいかもしれません（連想リストからは外れますが）
プロジェクトではよく「体制図」が用意されていると思います
ポイントは自分にとって見やすく連想しやすいように作り直すことです


オズボーンのチェックリスト
アイデアを練るときに使うフレームワークとして有名だと思います
転用（他の用途は？）、応用（他の事例は？）、変更（新しい非言語的側面は？）、拡大（大きくできる？）、縮小（小さくできる？）、代用（別の何かで補える？）、再配置（構成要素の組み合わせを変えたら？）、逆転（逆にしたら？）、結合（いっしょくたにしたら？）

また（連想リストとは限りませんが）色んなリストを集めたコンセプトの書籍やウェブサイトもあるので、探してみるのも良いでしょう。
Amazon.co.jp: 仕事と自分を変える　「リスト」の魔法 (角川書店単行本) eBook : 堀 正岳: Kindleストア
Awesome List
ソフトウェア開発や IT の文脈になりますが、「そのジャンルの定番を集めたリスト」があります
本家: https://github.com/sindresorhus/awesome
解説: GitHubのawesomeリストが本当にawesomeなものばかりだから一度見てほしい #GitHub - Qiita
たとえばリモートワークネタを扱った awesome-remote-job なんてものもあります

ネット上でも色んな人が色んなリストをつくっていることがありますし、最近では ChatGPT にお願いして洗い出してもらうこともできます。

 連想リストと付き合うコツとにもかくにも、まずは 雑でもいいので使ってみる体験をする ことです。個人的にはこれができるかどうかがすべてだと思います。上記でプロジェクトリスト、ピープルリストやポジションリストを紹介しましたが、これらを実際に自分なりにやってみるのです。自分なりにプロジェクトや人や役割を洗い出してリスト化して、そのリストを眺めてみて、色々連想してみて、そのうち行動に起こしたいものをタスク化（あるいはすぐ行動できるならしてもいいですが）して――と、実体験することで連結リストが身近になります。特にリストは、所詮はただの箇条書きですので、わかった気にもなりやすいし、スルーや形骸化はもっとよく起こります。このハードルを越えるには、実際に手と頭を動かして、連想まで体験して「意外と悪くなかった」「楽しかった」「すぐに何とかなるわけではないが何とかなりそうと思えた」といった実感を得ることが最重要なのです。
次に、連想リストはできるだけ自分でカスタマイズ、メンテナンスしていきたいところです。思っているよりも合う・合わないが激しいので、自分に合うようリストの中身を微調整していくのが望ましいです（目標事項や維持事項ほどではない）。逆を言えば、微調整しなくても使えるならそれでも構いませんが、リストの活用はただでさえ形骸化しやすいので、違和感は少しでも取り除いていくことをおすすめします。
最後に、わからない単語をちゃんと調べることもおすすめしたいです。連想リストの項目内あるいは連想した事柄の中に「わからない単語」が混ざることがあります。わからないまま扱っていると、目に入る度に無視をする、という余計なノイズが発生します。これが積もるとバカになりませんし、筆者は 連想に頼るのが苦手な人の大半はこのノイズに潰されているからではないか とさえ思います。ノイズは無視せず、ちゃんと一つずつ調べていくのが良いと思います。といっても完璧主義的に把握するのではなくて、「なんとなくわかったからこれでいいや」とか「なんか面倒くさそうだから調べるやーめた」でも構いません。自分でそう判断したという実績が大事です。実績があればノイズはスルーしやすいです。

 発散と収束方向性の 2 つ目は 発散と収束 です。
発散とは、アイデアや情報を何でも出すことです。目に見える形で残す必要があります。テキストで箇条書きで書いてもいいですし、文章で思いついたことを長々と書いてもいい（フリーライティング）ですし、付箋を書いていっても構いません。マインドマップなど脳内のイメージを反映するような視覚性に寄った手法もあります。この時点では解釈や判断は行わず、とにかく量を重視します。
収束とは、発散したものをうまくまとめることです。発散されたものを律儀に使って上手くまとめあげる要約と、発散されたものもヒントでしかないと捉える 蒸留 があります。要約は論理性やストーリーを重視し、蒸留は内容の面白さや本質の捕捉を重視します。蒸留の概念はわかりづらいかもしれませんが、発散されたものはすべてヒントでしかなく、使うも使わないも自由ですし、勝手に解釈を加えて改変するのも自由です。
発散と収束は一般的に行き来します。発散したものを部分的に収束して、思いついたものはまた書き足して、どこかのタイミングで一度おおがかりな収束をして、まだ落ち着かないからもう一度発散して――のようなことも当たり前に行ないます。ブレインストーミングや KJ 法など発想法と呼ばれる手法もいくつか存在しますが、本質は発散と収束にすぎません。自分なりに発散と収束ができるのなら、方法は問いません。
さて、タスクソースの話に戻りますが、先ほどの連想リストが静的な連想事項であるなら、発散と収束は「動的な連想事項」である と言えます。タスクを生み出すかもしれないヒントを、発散と収束を通して生み出していくのです。発散にせよ、収束（特に蒸留）にせよ、連想を多用します。そうして連想したことを発散として 実際に書いて、それを見てさらに連想を引き出して、また書いて、整理して、ときには配置を変えたり削除したり束ねたりして（収束の結果もちゃんと反映して）――と書きながら進めていきます。
最終的には要約にせよ、蒸留にせよ、何らかのまとめが出ます（というよりたいていきりがないのでどこかで打ち切ります）。必要ならタスクも言語化します。動的な連想を繰り返してきたからこそ、これでよい、これ以上はたぶん無い、これ以上は仕方がないと自信を持って言える状態になります。
筆者個人はこの営みを非常によく使います。普段の仕事でも「さっき定例会議が終わったけど今週は何しようか」と発散と収束を少しやってみて、その結果「うん、この 3 つをやろう」とか「温めたいアイデアが一つあるからこれを詰めていくためのタスク化もしておこう」とか「打ち合わせ頻度増えるから今のうちに予定押さえておくか」とタスクを追加したり、といった行動が起こります。悩んでるときはよく適当に書き散らして（発散して）、軽くまとめたみたりもして（収束）、その結果「ああ、結局給料少なくて悩んでるんだな」「でもそのために過剰に努力する必要がないんだよな」「じゃあ現状維持しかなくない？」「強いて言えば出費を抑えるくらいか」「ミニマリズムの本を買ってみるか」などとやはり行動に繋がったりします。繋がらないこともありますが、ひとまず出し切ったとの解放感や達成感があるので気持ちは楽になります。
と、見るからに手間暇がかかる営みではありますが、自分を出し切るがゆえに納得感が得られやすいのがメリットです。

 発散と収束のコツ発散と収束は 自分ひとりで集中して行える環境を確保できるかどうか、そしてそのような 孤独な営みにそもそも耐えられるかがすべてです。発想法のやり方や使うツールなどテクニカルなコツもあります（※1）が、そんなものは勉強するなり試行錯誤するなりすればどうとでもなりますし、原始的には付箋と紙とペンでもできます。
発散と収束は連想に全面的に頼るものであり、連想とは非常に個人的な活動です。なぜなら連想されてくる事柄には個人的な内容を含むことがあるからです。人目があると、個人的な内容を見せるかどうかの判断に認知の大部分を使ってしまうため集中できません。誰にも邪魔されず、100% 自分のやりたいようにできるのが理想です。人のアイデアやコメントや情報はもちろん使いますが、使うときはひとりでなくてはなりません。
ともすると 複数人で行いがちですが、実は典型的な悪手です 。よほど実力が拮抗しており、信頼関係もあって、かつ脳の性能が優れている（脳内である程度発散と収束ができている）少人数のチームであれば構いませんが、そうでなければただの発散と収束ごっこになってしまいます。自分の力など 20% も出せていないでしょうし、発想とは名ばかりで、実際は場の空気感や権力者の言い分に従って断片的に恐る恐る意見を出すだけの会になってしまうことがよくあります。ともすると、そうなっていることにすら気づけません。複数人で行うのは、ひとりひとりが発散と収束を行った後に、その結果を持ち寄るときに限ります。
わかりやすいのが作家でしょう。マンガにせよ、小説にせよ、あるいはビジネス書でも何でもいいですが、本というレベルのコンテンツは基本的にひとりのライターが書いて、書いた後に編集者などにレビューしてもらうはずです。書く段階から複数人で一緒に書いていこうか、とはしませんし、それだとおそらく上手くいかないことは比較的容易にイメージできるのではないでしょうか。発想と収束も同じようなものです。誤解を恐れず言えば、クリエイティブな営みです。
そういうわけで、発散と収束はひとりで行うのが必須ですが、これは言い換えると孤独に耐えねばならないとも言えます。たとえば 1 時間の間、誰にも見せず、誰とも喋らずに、ただただひとりで目の前の発散物と収束物と向き合うことができるでしょうか。ここは思っている以上に特性に左右されます。できる人はできますし、できない人はやろうともしません。よく「できる」という人がいますが、実は「長時間ひとりで作業することはできる」というだけで、発散と収束はできなかったりします。発散と収束は、1 日数時間くらいしか続けられないほど疲れる（※2）ものでもあり、単に時間さえかければできてしまう「作業」とは全く異なるあり方です。思っている以上に向き不向きがあります。
一つの目安は「頭の中でだけではとても処理しきれない複雑で大量な事柄を」「第三者にも伝わるよう」表現しきれるかどうか、でしょう。10 万文字以上の本でも 30 分以上のプレゼンや講義でも構いません（※3）が、頭という限界を越えられるかどうかがポイントです。表現「しきれる」と書いたのも意図的であり、それなりの分量を秩序を持たせて扱うことも想定しています。付け焼き刃やその場のノリでは到底できないことです。越えるためには発散と収束が必要であり、その発散と収束にはひとりで集中する営みが必要です。表現しきれる人は、できていると言えるでしょう（※4）。
※
1 このテクニックやツールの部分も実は重厚で、これだけで本を何冊も書けてしまうくらいですので本書では割愛します。
2 疲れる理由は二つあると思います。一つは考えをひねり出すという行為そのものが非常に消耗しやすいことで、アイデア出しにより体験しやすいです。なぜ消耗しやすいかの理屈はわかりませんが、筆者としては「正解がない」かつ「大量の判断を行っている」が両方重なるからだと思っています。もう一つは、自分が向き合いたくない記憶とも向き合う必要があることです。残念なことに、そういうネガティブな記憶に限って色々と連想しやすかったりします。この醜さと向き合う苦しみに耐える（鈍感で耐えるまでもないのがベストですが才能と言えるでしょう）必要もあるのです。
3 発散と収束で行えることは本や講演に限りません。むしろもっと汎用的で、戦略や戦術、もっと言えば選択肢を死角なく考え尽くせるようになる、とも言えます。このあたりの資質はストレングス・ファインダーにおける「戦略性」だと筆者は考えます。加えて、孤独に耐えるには「内省」資質も要りそうです。筆者としては、発散と収束の適性はストレングスの資質で説明できる気がするんですよね。調べてみたいところです。
4 頭の限界を越えることなく本を書けたり喋ったりできる人もいます。そのような化け物レベルの性能を持つ人がプロと呼ばれる存在になるのだと筆者は思います。実際それほどの性能があるからこそ、食っていけるほど素早く動ける――特にそれなりに短い締切だったり複数の仕事を並行するマルチタスクだったりなど厳しい制約下でも結果を出していくことができるのです。逆を言えば、化け物でなくても、発散と収束を使えば（時間はかかるがそれなりには）できるようになりますし、筆者による本書はまさにその一例です。


 俯瞰のつくりこみ方向性の 3 つ目は、俯瞰のつくりこみです。
俯瞰（Overview） とは、全体または特定の範囲を眺めることです。通常は眺められる状態になっていないので、意識的につくりこむ必要があります。たとえば仕事で、ある案件を担当していて、長い目で見てもうちょっと上手くやりたいなーと思っていて、登場人物ベースで考えてみたい場合、登場人物を俯瞰できると良いですよね。しかしそのままでは俯瞰はできないので、登場人物の名前をリストアップしてみたり、顔社員つきで並べてみたりするのです。このように俯瞰時に使うものを 俯瞰物 と呼びます。この場合、俯瞰物として登場人物名のリストや顔写真の列挙をつくっています。
俯瞰を行うことで色々連想を引き出せます。頭の中で俯瞰できれば良いですが、たいていは難しいので、わざわざ俯瞰物をつくるわけです。

 俯瞰のコツまず俯瞰そのもののコツはありません。俯瞰物を見て、自分なりに連想したことを捉えるだけです。連想をさらに発展させたい場合は、発散と収束を行うのが良いでしょう。
肝心なのはそれよりも俯瞰の前、俯瞰物をつくる段階で、俯瞰物をつくるコツは 自分が使いやすいようにつくる ことです。特に通常は何らかの俯瞰物が用意されていることが多いです。たいていのプロジェクトには概要資料があったり、そこに体制図があったりしますし、タスク管理ツールでも様々なビューが用意されています。ともすると、それらをそのまま使いがちですが、アンチパターンです。連想は、少しでも自分にとって馴染みやすく違和感のない場所や見え方の方が捗ります。要は、自分にとっての理想的な俯瞰物をつくれるのは自分だけなので、自分でつくりましょうというわけです。
もちろん、自分にとっての理想なる正解は、最初は自分でもわからないので、しばらくは試行錯誤が続きます。といっても、まずは雑に俯瞰物をつくっていって、それから微修正していけばいいだけです。手段としてもアナログ・デジタルは問いません。自分のやりやすい方で結構です。一般論を言えば、空間的に配置できた方が融通が利くので、空間配置に長けた手段が良いでしょう。アナログだとやりやすいですが、デジタルに慣れているならデジタルでも構いません。あるいは筆者もそうですが、逆に空間だと馴染まない場合は、テキストによる列挙や箇条書きベースで俯瞰物をつくるのが良いかもしれません――とにかく、最適なやり方は本当に人それぞれです。
俯瞰物をつくる営みは面倒くさいですが、ここを越えないとスムーズな連想は引き出せません。この面倒くささに慣れてしまった方が早いと筆者は思います。もちろん、こんなことせずとも、既存の俯瞰物だけで連想が上手くいくならそれで結構です。ただ、それだと思うようにいかない場合もあるので、そんなときに自分でつくれるようになっておくと便利なのです。

 発想事項の運用発想事項の運用とは、「言語的につくられたインスピーション元」をいかにして見つけるか、またどのように付き合うか、との話になりますが、ここは非常に個人的かつ再現性もないため解説は割愛します。

 締切との向き合い方仕事にはしばしば締切が発生します。タスクソースの現実的な運用として、締切とどう向き合っていくかを深堀りしていきます。

 タスクソースは締切と相性は悪いまずタスクソース自体は締切――特にタイトな締切が存在する場面とは相性が悪いです。
タスクソースは、自分の裁量でタスクをつくるための源泉です。冒頭で解釈の公理についておさらいしましたが、率直に言えば、気分でタスク化しているにすぎません。当然ながら締切が存在する場合、気分でタスク化しているだけだと間に合わない可能性があります。アスリートタイプの人なら「間に合うようにタスク化する」こともできますが、万人向けではありません。
かといって最初からガッチガチにタスクを洗い出して管理するのも、私たち人間は怠け者なので難しいでしょうし、仮に仕事などでそうせざるをえない場合でも（単純な作業に帰着される世界でもなければ）正確な見積もりなどできませんから十中八九外れます。それを認めたくなくて残業でカバーしますよね。ひどい場合はサービス残業の形で正当な報酬がもらえないすらあります。外れるのに疲弊も加わっているので最悪です。プロジェクトだの案件だのと呼ばれる仕事は過酷だったり、最低でもワークライフバランスが一時的には崩れがちですが、それは計画という「そもそもそのとおりに踏襲することが現実的に難しい」ものををバカ真面目に行っていることと、計画ベースの管理に従い続けることによる疲弊とのダブルコンボが重なっているからです。

 ソースアプローチとプランアプローチここまでを整理します。仕事のやり方は二通りあるということです。
ソースアプローチ
タスクソースを運用すること
タスクソースから適宜タスク化を行う
主観に基づいて行えるが、締切と相性が悪い
いうなれば「探索的」

プランアプローチ
計画やスケジュールといったレベルで想定をつくり、そのとおりに動くこと
基本的に仕事はこの価値観で行うことが疑われていない
理に適っているように見えるが、どうせ計画は上手くいかない + カバーで残業するなど疲弊が増えやすいの二重苦で過酷になりやすい
いうなれば「計画的」


 ソースとプランの臨界点ここまでを踏まえると、両者の使い分けができれば良さそうに思えてきます。
状況にもよりますが、最も汎用的なのは 最初はソースアプローチを行ない、どこかでプランアプローチに切り替える ことです。プランアプローチばかりだと息切れしますし、ソースアプローチばかりだと締切に間に合わないので、両取りします。まずはソースアプローチにて楽に進めていき、ある程度見えてきたらプランをつくってガッと走り切るイメージです。別の言い方をすると、最初のうちは探索的に動いて、その後で計画的に動きましょうとなります。
現代の仕事はプランアプローチの考え方に支配されていますが、これは管理上都合が良いからです。計画をつくると数字化ができるため金銭（予算など）との対応も取りやすいですし、数字いじりしかできない無能な管理職達にも数字いじりの仕事を渡すことができます。数字いじりのあり方を複雑にして、何ならルールとしてしまえば、従業員を数字で管理してこき使うこともできますし、逆に「仕事のための仕事」を創出して余計なお金を取ったり中抜きしたりもできます。方法として優れているからではありません（この数字や管理こそが肝となる仕事や状況ももちろんあります）。
ソースアプローチを使うと、このプラン一辺倒なやり方から脱せます。まずはプランをつくらず、タスクソースからタスク化する、という形でマイペースにこなしていきます。そうすれば、マイペースではありますが、こなしてはいるので色々見えてきます。マイペースな分、疲弊も小さいので、より本質が見えたり、率直な議論ができたりすることも多いです。そうして色々見えてきたら、そこではじめてプランアプローチに切り替えて、あとは頑張って走り抜けます――このやり方なら、プランアプローチだけで疲弊することなく仕事をこなせます。
このとき重要なのが、どこでソースからプランに切り替えるかというタイミングです。この切り替えのベストタイミングを SP臨界点（ソースとプランの臨界点） と呼ばせてください。SP 臨界点の見極めが重要だということです。見極めのコツですが、何とも抽象的な言い方になりますが「見えてきたかどうか」です。ソースアプローチであれこれこなしていくうちに、情報や学びも増えてきて、どこかで「大体わかってきた」「あとはいけそう」と感じるポイントがあります。ここが SP 臨界点です。この状態になったら、ようやくプランをつくれます。少なくとも SP 臨界点の前、何もわからない状態からプランをつくるよりは、はるかに現実的かつ無理のないものになります。
ちなみに SP 臨界点が最初から見えている場合があります。後述もしますが単純な世界（たとえば作業に帰着できる仕事）であるケース、あるいはプロなど著しく実力があってすぐに臨界点が見えてしまっているケースなどです。この場合、あとは終わるまで作業できるかどうかが争点ですので、プランアプローチでいけます。ただ、そうは言っても、人間であり忘迷怠は生じるので、プランには余裕を持たせたい（持たせるための交渉や日頃の盤外戦も含む）ところです。このあたりはタスク管理の技術であり、プロでもできるとは限らないし、そもそもプロになれるほど生産性と行動力の高い人にタスク管理術を身につける余裕（そして適性）はないですから、基本的にはできません。だから慢性的に忙しい人が多いですし、秘書やマネージャーといった形で委譲する形態も言わずと知られています。

 その他の戦略ソースからプランに切り替える戦略を述べましたが、他にもあります。
1: ソースアプローチのみ使う
2: プランアプローチのみ使う
3: ソースアプローチ → プランアプローチ
4: プランアプローチ → ソースアプローチ
ここまで紹介してきた、SP 臨界点が要求される戦略が 3 です。残る 1, 2, 4 についてもかんたんに取り上げておきます。
1 については、ソースアプローチのみを使い続けるというものです。締切のあるタスクに対してはおすすめしません。この戦略は、締切がなく半永久的に続く（続けることができる）事柄に使います。維持事項が典型例ですが、マイペースであっても続けることが大事なので、自分なりにタスク化すればそれでいいのです。ただし、ソースアプローチだけでは一向に進展がない場合は、プランアプローチを入れてテコ入れする必要があります。あるいは「これ以上成長しなくてもいい」と開き直るのもアリです（特に趣味の場合）。
2 については、プランアプローチのみ使い続けるもので、特にビジネスでは現状最も自然な戦略です。最初から計画やスケジュールを組まされた経験のある読者の人も少なくないでしょう。基本的に現代の VUCA な状況では悪手だと筆者は考えますが、管理する側がこれしかやり方を知らないケースも多く、基本的にはこれになりがちです。一方で、これが有効なシチュエーションはまだまだ数多くあります。建築や製造など単純な世界（現実の物理的制約のみを相手にすればよく、ソフトウェアなど電子的な世界よりははるかに単純でプランアプローチが通用しやすいです）はそうですし、規模の大きなプロジェクトや組織では、そもそも秩序を持たせるために数字による管理が幅を利かせるようになるため、プランアプローチ一択になりがちです。
4 については、あまりありませんが、プロジェクトの中止が該当します。もう行う必要はなくなったが、ここまでやってきたものがあるので、残りをどうしようかと考えて、その分をソースアプローチで行っていきます。中止命令が厳しい場合は、勝手に行うと怒られたり処分されたりする可能性もありますが、中止となってはいそうですかと全部捨てるのはもったいないので、自分なりに足掻くわけですね。個人的にはノウハウ化や振り返りなど、自分の成長につながる活動を（許される範囲で）しておくと良いかなと思います。

 まとめタスクソースとはタスクの源泉であり、必要に応じてタスクをつくりだす（タスク化する）もの
いつ、どんなタスクをどれだけつくるかはその人次第で、正解はない

タスクソースとして以下が存在する
目標事項
維持事項
連想事項
発想事項

特にビジネスでありがちな「締切を持つ事柄」にも適用できる
プランアプローチはよく知られているが、タスクソースを用いたソースアプローチも可能
先にソースアプローチを行ない、見えてきてからプランアプローチに移るのがベター

余談ですが、本章で一部出てきた「探索的なあり方」については、後の章で詳しく提案します（探索的タスク管理）。