Chapter 25
文芸的タスク管理

2024.09.11に更新
最近タスク管理において頭角を現しつつある概念が一つあります。あえて名付けるなら文芸的タスク管理とでも呼べるでしょう。文芸的――つまりは文章を書く営みをベースとしたタスク管理です。
本章では文芸的タスク管理なる概念を筆者なりに整理します。

 文芸的タスク管理の概要
 文芸的タスク管理文芸的タスク管理（Literate Task Management, 以下 LTM と略します） とは、文芸的に行うタスク管理を指します。
文芸とは「文章を書く営み」と考えてください。ノートやメモといった言葉がよく似合うものです。芸術性は必要ありません。つまり LTM とは、文章を書く営みを通じたタスク管理を指します。日記でも日誌でも備忘録でも何でも良いですが、恒常的に 自分用の 文章を書くという前提があって、その中でタスクも扱うのです。もちろん、タスク管理にはタスクリストなどタスクをノイズ無しに集めた ビュー（見せ方） が必要ですし、前章で述べたようにデジタルで文章と付き合うならプレーンテキストの理解も要りますが、こういったものを上手く取り入れます。そうすることで文章を書く営みを大事にしつつタスク管理も行える、というバランスを手に入れることができます。

 メリットは文脈の尊重LTM のメリットは 文脈の尊重 です。文脈についてはコンテキストの章で詳しく取り上げましたが、文章を書くことで人生や生活や仕事といった文脈がクリアになります。これを読みつつ、書き足したり書き換えたりしつつ、タスクについて考えることで、より文脈を尊重したタスクを扱えます。

 目的は QoL の向上LTM の目的は QoLの向上 です。自分の文脈を踏まえて行動することは、純粋に心地が良いことです。
必ずしも生産性や成長に繋がらないことには注意してください。生産性を増やしたり、より成長したりしたいなら、文脈なんて無視して必要なタスクを気合を入れて消化するのみです。そうではなく、自分の文脈を尊重することを第一にするのが LTM です。その結果、向上するのは何かというと QoL に他なりません。ただし、文脈を尊重した方が（長い目で見れば）より早く上手くいくことも多いので、実は生産性や成長を求めている場面でも有効です。とはいえ、文章を読み書きする営みにはある程度の余裕が必要ですから、やはり目的としては QoL の向上、くらいに捉えておくのが良いでしょう。特に LTM は慌ただしい場面の打開には向いていません。

 ひとりで行うもの、かつ人を選ぶLTM は個人タスク管理の手段です。つまりひとりで行います。プロジェクトタスク管理やパートナータスク管理など、複数人で行うタスク管理の手法としては想定していません。本章でもあくまで個人タスク管理としての LTM を扱います。
また、LTM には向き不向きがあります。少なくとも文章を読み書きする営みを継続的に行えることと、読み書きする余裕があること（たとえば 1 日 1 時間以上を恒常的に確保できるか）、そしてアナログではなくデジタルツールを使うことの三つが必要です。この三つができない人は向いていません。ただし言語化能力や読み書きのスピードは気にしなくてもいいでしょう。タスク管理は本質的に個人的なものです。自分なりに文芸ができればそれでいいのです。

 文芸的●●のルーツ文芸的、のニュアンスを知るために軽くルーツをたどります。

 文芸的プログラミング一番有名で、かつ起源ともなっているのが文芸的プログラミングでしょう。
元はドナルド・クヌースが提唱した概念ですが、発想としてはドキュメント内にコードを書くようなプログラミングスタイルです。プログラミングは通常、プログラムコードを専用で記述し、それをコンピュータが読み取って実行します。コードを読むのは大変ですし、設計思想や意図などを残しておかないと後で改造できませんので、別途解説としてドキュメントも書くのですが、これはコードとは別に自然言語で書きます。あるいはコード内のコメント構文で残します。いずれにせよ「コード」と「ドキュメント（自然言語で書かれた詳しい解説）」を結びつけるのはかんたんではありませんでした。特に両者は整合性も持たせねばなりませんが、コードを更新した後に解説も更新するのは二重管理的であり骨が折れます。文芸的プログラミングは、この件について新たな選択肢を提案しており、「いやいや、だったらドキュメントを中心にして、この中にコードも書いちゃえばいいのでは」と言っているわけです。
現在よく知られている文芸的プログラミングは Jupyter Notebook だと思います。これはデータ分析で使われるもので、ノートブックと呼ばれるファイルに作業手順やメモ、実験したいプログラムコード、その実行結果などをすべて同梱できるものです。作業手順やメモというドキュメントの中に、実験用のコードと実験結果も入っているわけですね。実験という限定的な用途ではありますが、文芸的プログラミング的と言えます。

 文芸的タスク管理の可能性文芸的タスク管理の概念がいつ生まれたかは定かではありませんが、以下 2 つが見つかりました。
一つは 2020/06 の文芸的タスクマネジメント（文芸的タスク管理）のススメ - ari's worldです。記事では『ふりかえりも、計画づくりも、タスクばらし、と実行を分けずにドキュメントに記載していきます』とあり、流れとしては、思いついたことを何でも書く → 適当なタイミングで計画立て → タスクにばらしつつ実行、となっています。文芸的プログラミングから着想は得ていますが、文章にタスクを埋め込むというよりも、文章ベースで何でも書いて膨らませてそこからタスクを取り出していくアプローチとなっています。これはどちらかと言えば次章で解説する探索的タスク管理に近いです。
次が 2021/12 のプロジェクトリストを使わないプロジェクトリスト管理と文芸的タスク管理 | R-styleです。まさに文芸的タスク管理と言える考え方だと筆者は思いました。記事では『「タスク」を処理するその前に、それを生み出している「文脈」を扱えるようにしておきたい』とあります。行動としては『Todo.mdには、まず文章を書き、そこからタスクを起こすようにしている』と文章を書く営みをベースにしつつ、『Dropbox直下のフォルダ/ファイルをすべて走査し、そこにTodo.txtないしTodo.mdファイルが含まれているならば、その内容を抜粋して表示するスクリプトを書いた』とビューをつくる工夫もしています。やはり文芸的プログラミングから着想を得ています。

 ノートの必要性LTM ではノートが必要不可欠です。
たとえば以下は LTM ではありません。
X、LINE、Slack/Discord/Teams など短文の投稿とタイムライン表示から成る SNS やチャットシステム
はてなブログなどオンラインのブログシステム
アットウィキ、Pukiwiki、Mediawiki など従来の Wiki システム

GitHub Issues など BTS
Notion など多機能ノートツール
まず LTM を行うためには、文章をストレスフリーに書けなくてはなりません。誰かに見せるための文章を、重たい腰を上げて書くのでは成立しません。前章で書いた3秒の壁は言い過ぎにしても、息するように苦なく文章を書けるだけの軽さが必要です。世に存在する大部分の情報共有・コミュニケーションシステムはここを満たしていません し、多機能ノートツールも軽さの面で足りません。できれば前章のとおり「プレーンテキストを扱う」「オフラインのツール」が望ましいですが、後述するように一部オンラインツールでもできなくはないです。
次にまとまった文章を扱えなくてはなりません。一度に 1000 文字くらい書いたり、一日に 10000 文字書いたりすることもありますし、100 文字以内の短文、たとえば単語の羅列を一気に 100 個行うかもしれません。こういった場合でも問題なく動作してほしいですが、SNS やチャットシステムはこれを満たしません（あるいは満たせますが不便です）。ここを満たすには、複数行のテキストを扱えるポテンシャルを持つ「ノート」的なシステムが要ります。短文ベースの SNS やチャットでは足りません。
文章を書くと聞いて、上述したツールを思い浮かべた方も多いと思います。しかしそれでは LTM には足りないのです。十分な軽さを備え、かつノートのポテンシャルを持つツールが必要なのです。

 LTM の準備LTM を始めるために必要な手段や考え方を整理していきます。なお、LTM におけるタスク管理は次節で扱うこととし、本節ではそのための基礎（ノートの使い方や作り方）を解説します。

 LTM を回せるツールLTM にはノートが必要と書きましたが、では、どのようなノートツールがあればいいでしょうか。

 3つのアプローチ2024 年現在では、以下 3 つのアプローチがあると思います。
1: オフラインでプレーンテキストエディタ
2: ネットワーク型ノートツール
例: Scrapbox、Obsidian、その他 Roam Research や Logseq など
オフラインだったりオンラインだったりします

戦略の章でも第三世代的なノートツールとして取り上げています

3: アウトライナー
例: WorkFlowy、Dynalist
※厳密にはオフラインのアウトライナーもありますが本書では割愛します

1 のプレーンテキストエディタは前章にて解説したとおり、プレーンテキストをテキストエディタまたは IDE で扱います。オフラインで動作するため軽快ですが、ほぼテキストを編集するだけですので高級な機能が無く、欲しい機能は基本的に自分でつくるなり工夫するなりしなくてはなりません。DIY 的と言えるでしょう。その気になれば、2 や 3 のポテンシャルを持たせることもできなくはありません（※1）。
2 のネットワーク型ノートツールは近年台頭してきた手段です。最大の特徴はノートとノートをリンクでつなぐことです。たとえばページAにて[[B]]と書くと、A → B へのリンクが繋がれます。ページ B を見ると、メタ情報として「A から接続されています」と表示されたりもします（バックリンク）し、文章中のリンクはもちろんクリックしてジャンプできます。ウェブページはリンクを辿って別のページに辿れますが、それと同じことを手元の、個人のノートでも行えるようにする（そのリンクも自分で紡いでいく）のです。こうすることでノート全体がネットワーク的となり、リンクを辿って探索したりリンクしている・されている周辺の情報を表示したり、といった形で情報を探しやすくなります。
ツールとしてはオンラインとオフラインがあります。Scrapbox はオンラインです。Obsidian や Logseq はオフラインです。ただしオフラインのツールもオンラインの機能（特にクラウドへの保存やデータ同期）を持っているか、工夫して付与させることができます。
3 のアウトライナーは、いささか特殊ですが、すべての情報を箇条書きで表現します。階層的に分類したり、並び替えたり、指定階層以下を折りたたんだりなど、階層化した箇条書きを柔軟に扱うことができます。LTM として出来なくもないという選択肢にすぎず、ネットワークをつくる能力が弱いのが難点です。本章ではこれ以降扱いません。
※
1 たとえば筆者は愛用の秀丸エディタをベースとして Hidemaru SCB や houtliner を自作しました。2024 年現在、houtliner は使っていませんが、Hidemaru SCB は愛用しています。一応公開はしていますが、自分用であり丁寧な解説もつくっていませんのでご容赦ください。あくまで参考として挙げただけです。


 おすすめのツールすでにお使いのツールがあれば、それでやってみるのが良いと思います。
そうではない場合のおすすめとしては、オンラインなら Scrapbox、オフラインならプレーンテキストエディタです。まずネットワーク型ノートツールとしては Scrapbox が圧倒的だと考えています。筆者のヘビーユーザーの一人ですが、他の追従を許しません。ただしオンラインゆえの制約もあります――文章を大量に書きたい場合や通信環境が強くない場合、あるいは仕事で使いたいがクラウドツールの許可を得づらい場合などです。このようなときは、オフラインの手段としてプレーンテキストエディタが使えます。

 余談1: 無限キャンバス vs ネットワーク型ノートネットワーク型ノートの対抗馬として 無限キャンバス が挙げられることがあります。これは Miro に代表されるようなホワイトボードツールのことで、多人数によるコラボレーション用途を想像しがちですが、この無限の二次元空間をひとりで使えば情報管理手段や仕事場としても優秀なのです。
無限キャンバスは、実は文芸的営みと似ています。単一のワークスペース内に「文脈」を――要は関係する情報を何でも全部入れてしまう点が同じなのです。従来のファイル管理やデータベースでは、特に 1000 ファイルなど分量が多いと破綻していましたが、この二つのやり方なら秩序を保てます。ネットワーク型ノートでは言語（テキスト）を重視してネットワーク構造をつくることで、無限キャンバスではテキストに限らず多様なコンテンツを空間上に配置していくことで保ちます。筆者の知る限り、大量の文脈を管理できるパラダイムはこの二つだけだと思います。
さて、LTM は無限キャンバスで行えるでしょうか。また向いているでしょうか。
結論を言うと、ネットワーク型ノートよりは向いていないと考えられます。まずここまで述べたとおり、タスク管理は言語を扱うものであり、個人タスク管理は自分のタスクを扱います、つまりは自分で言語化したものを扱うためノートツールに分があります。無限キャンバスは、他者の情報を貼り付けたり、グラフィカルにレイアウトしたりといった用途では強くて、言語というよりは視覚的・空間的な営みになります。情報管理や意思決定、あるいは創造のための準備や作業場としては良いですが、タスク管理とは相性が良くありません。本書で強調してきたとおり、個人タスク管理では言語と向き合わねばなりません。
無限キャンバスでもできないことはないと思いますが、結局ノートに頼ることになります。Ink & Switch の Embark という研究では（旅行計画の文脈ですが）無限キャンバスを使っていても結局メモを書くし、それを見て行動すると考察されています。メモとは文脈に他なりません。結局言語で文脈を残す（しかない）のです。ならば、テキストの管理に強いノートツールに分があります。

 余談2: ノートの欠点を補うノートのデメリットはビュー（見せ方）が弱いことです。LTM においても、ノートのどこかに書いたタスクをどうやって俯瞰するかは主要なトピックです。
肝心なのは ビューが弱いからといってノートを使うのをやめない ことです。文芸的な営みにはノートが最適です。でもノートはビューが弱い――だったらノートを諦めずビューを補えばいいだけです。2024 年現在では、まだ LTM におけるビューは不十分であるため（自作なり工夫なりできなければ）不満が出ます。それでもノートから離れないでください。ノートから離れた時点では LTM は終わります。特にビューを好む人が多く、無骨で言語的で情報密度の高いノートの世界は敬遠されがちですが、それでも（LTM をしたいのなら）ノートから離れてはいけないのです。
ビューの補完については、個人的には風向きが変わっていると感じます。特に生成 AI が大きいです。というのも、生成 AI はテキストを扱うのに長けており、現状でも要約をつくったり変換や翻訳を行ったりは可能だからです。そう遠くない将来、AI にノートを食わせて問いを投げかけるだけでタスクリストを教えてくれたり、もっと高度な、それこそ秘書のような柔軟な振る舞いをさせることも可能になるかもしれません。限定的にはすでに可能です（※1）し、タスク管理ではありませんが一部のノートツールや、それこそ前述の Miro でも AI 対話機能はすでにサポートしています。ChatGPT でもテキストの指示やデータから図表をつくることができます――というわけで、そう遠くないうちに、生成 AI を活用した、革新的なビューの補完方法も出てくるんじゃないか、それをタスク管理に応用したソリューションやツールも出てくるんじゃないかと筆者は楽観視しています。
※
1 課題を言えば、精度に難があることです。特にタスク管理として運用するとなると、絶対にタスクのヌケモレは避けたいわけですが、現状ではまだその域に達していません。たとえば一週間分のノートを与えて「今日以降存在するすべてのタスクを時系列的に並べて」と指示しても平気でヌケモレが生じます。生成 AI は確率的なアルゴリズムであり、もらった指示の続きとして最もありえそうな文面を学習データに基づいて生成しているだけです。特定の場所に書かれた特定の意味合いを持つ情報をすべて確実に抽出する、といった作業には構造的に向いていません（たとえ指示を工夫しても精度が多少上がるだけでそれなりに漏れます）。これでは怖くて使えません。もちろん、将来的にどうなるかはわかりませんし、筆者が未熟かつ無知なだけで、現状でもすでにタスク管理用途でも実用できるものを開発している例もあるかもしれません。


 LTM のスタイルノートツールを用いて、どのように LTM を進めていけばいいのでしょうか。やり方に正解は無いのですが、よく見られるものを 3 つにまとめました。
1 ダイアリーベース
2 プロジェクトベース
3 ネットワークベース
先に紹介するほどかんたんですが、LTM としては弱いです。つまり LTM の理想は 3 のネットワークベースです。
では個別に見ていきましょう。

 ダイアリーベースダイアリーベースは日単位でテキストを書くというシンプルなやり方です。まさに日記です。シンプルゆえに始めやすいですが、LTM としては機能しづらく、正直言って前章のPTTM（プレーンテキストによるタスク管理）を脱せません。所詮は日単位のテキスト群にすぎないからです。LTM としてタスクを認識したり、あとで洗い出して把握したり、あるいは単にタスクの文脈を読み直したりするためには、自分が書いたテキストをひたすら読み返す こととなります。職業プログラマーはコードを書く時間よりも自分や人が書いたコードを読む時間の方が多いと言いますし、作家も原稿を書く時間よりも推敲のために読み直して修正する時間の方が長いと聞きますが、同様にダイアリーベースの LTM 実践者でも、読む時間の方が長くなります。ですが自分が書いたテキストを読み返すのは退屈ですし、PTTM でも述べたとおり全面的な手作業でタスク管理を頑張る（特に日々メンテナンスする）のも大変です。ダイアリーベースでは LTM には足りないのです。

 プロジェクトベース次にプロジェクトベースですが、これはタスクをプロジェクトという単位で捉えて、1-プロジェクト 1-ノートで書くやり方です。ノートという単位はファイルでもページでも、あるいは■プロジェクト1のように区切ったエリアでも構いませんが、とにかくプロジェクトごとにエリアを分けて、そのプロジェクトに関する内容を全部そこに書き込むのです。たとえば引っ越しタスクが必要なら引っ越し.txt なり■引っ越しなりをつくって、そこに書き込むのです。こうすることで「プロジェクトAに関する情報はノートAにある」という風に対応付けられます。たとえるならノートという名の作業机をプロジェクトごとに用意します。デジタルなら空間的制約もありませんからいくらでもつくれます。その気になれば 10 はもちろん、100 でも 200 でもつくれます。
一見すると上手く行きそうですが、たいていの人にはまだ難しいでしょう。プロジェクトベースは本質的には 継続的な整理整頓をテキストベースで行え に等しいです。つまり整理整頓が得意な人でないと成立しません。現実でも一つの机が散らかるように、おそらく未整理.txt みたいな場所に何でも書き込んで、テキストが増えすぎて破綻するでしょう。仮に物理的な整理整頓が得意な人でも、プレーンテキストをきちんと扱えるスキルや素養が必要ですから（これがないと操作の手間がいちいち大きくて面倒くさくなる → 形骸化する）上手くいくとは限りません。他にも「プロジェクト」という単位をどう捉えればいいのかとか、プロジェクトをまたいだ事項――たとえばプロジェクト A にも B にも絡むメモをどこに書けばいいのかといった問題も出てきます。まさか A にも B にもコピーするわけにはいきませんし、2 つならまだしも 3 つだとしたらどうでしょう。面倒くさすぎて形骸化します。

 ネットワークベースこのあたりの問題点を比較的上手く解決するためには、新しいパラダイムが必要でした。それがネットワークベースです。これは一つの話題を一つの単位に書いて、かつ話題と話題をリンクで繋ぐことでネットワーク状の構造をつくるやり方です。プロジェクトベースでは 1-プロジェクト 1-ノートでしたが、ネットワークベースでは 1-話題 1-ノートです。話題（トピック）はタスクやタスクを表現するプロジェクトに限らず、何でも良くて、それこそ「炊き込みご飯ってめっちゃ美味いんだな.txt」をつくっても良いのです。これを筆者は トピック指向 と呼んでいます。話題 A に関することをノート A に書くのです。話題の単位は大きくても小さくても構いませんし、タスクなどわかりやすい単位である必要さえありません。この性質上、ノートの数は数百では済まず、数千、場合によっては数万以上もありえます。もちろんデジタルだからこそできることです。筆者が思うに、このパラダイムを確立したのは Scrapbox だと思います。正直これを体感したければ Scrapbox を重用するのが最も確実です。
このトピック指向を実現するためには、特殊なツールが必要です。それがすでに紹介したネットワーク型ノートツールとなります。

 ネットワークはプロジェクトとダイアリーを包含するネットワークベースの良い点は、プロジェクトベースとダイアリーベースも包含できることです。単にプロジェクト単位でノートをつくればプロジェクトベースになりますし、もちろん日単位でノートをつくればダイアリーベースにもできます。プロジェクトにせよ、ダイアリーにせよ、歴史があって私達にも馴染みやすいため使わない手はありません。むしろ積極的に使います。
ただ、ネットワークベースですので、それだけではないのです。たとえば 2024/08/05 の日記ノートに「炊き込みご飯ってめっちゃ美味いんだな」と書いて、これをリンク化すれば、「炊き込みご飯ってめっちゃ美味いんだな」ノートがつくられます。炊き込みご飯に関する気付きや思いを書き溜めることができるでしょう。ここからさらに「レシピサイト調べたいな」とか「実家は定食屋だし炊き込みご飯屋とかビジネスとしてアリなのでは」と話題が広がるかもしれません。これらもまたノート化して、さらに書き込んで――と、このようにリンクをつくってネットワークを広げていくことができます。
ただのダイアリーやプロジェクトでは到達できない高みがあります。人間の脳、交通網やインターネット、人間関係などネットワークは実は非常に馴染みのある構造であり、これを個人のノートにも取り入れることで圧倒的な書きやすさと読みやすさ（辿りやすさ）を実現できます。第二の脳と呼んでもいいくらいの、濃厚なノートをつくることが現実的に可能なのです。そして、ここまで時代が追いついたことで、ようやく LTM も可能となったのです。

 ⚠ LTM ≒ ネットワークここまでを踏まえると、LTM の推奨ツールはネットワーク型エディタ、推奨スタイルはネットワークベース、となります。以降ではこの前提で進みます。
つまり 以降では LTM としてネットワーク型エディタかつネットワークベースなスタイルを用いることを前提として解説します。

 ホームをどうつくるか通常私たちには自宅（住み込み等も含む）があり、生活の拠点になっています。仕事においてもオフィスの自席や作業場といった拠点があります。少し前にノマドワーカーという言葉が流行りましたし、今もリモートワークにより拠点を持たない生き方も可能となっていますが、そういった生き方でも短期的な拠点はつくるはずです。
LTM も同じで、まずは拠点をつくらねばなりません。これを ホーム と呼ばせてください。このホームのやり方にいくつかスタイルがあり、よく見られるものを紹介します。以下の 4 つです。
1 ホームノート
2 ホームビュー
動的なホーム
3 日付ノート
4 トランク

オフラインで手作業が多い場合は 1 のホームノート、3 の日付ノート、4 のトランクが良いでしょう。どれが合っているかは人によります。どれも運用難度は大差ないので、ひととおり試すのも良いでしょう。Scrapbox などオンラインで、かつビューも用意されている場合は 2 のホームビューが使えます。
続いて各詳細を見ていきましょう。
※ちなみにツールによってはノートのことを「ページ」と呼ぶことがあります。1つの情報単位を何と呼ぶかはツール次第です。Scrapbox ではページです。本書では「ノート」を使います。

 ホームノート唯一の玄関口に相当するノートを一つつくります。これを ホームノート と呼びます。
ホームノートは玄関であり、あなたが LTM として書いてきたノートのすべてはここから辿れるようになっています。何をどう書くかはすべてあなたが決めます。散らかった机のように長々と書き散らしても良いですし、案件Aに関する記述を「案件Aノート」をつくってそっちに移しつつホームノートからは案件Aノートへのリンクを一行だけ書く、でも良いでしょう。
構造的にはおそらく以下の 3 つが生まれるはずです。
1 ホームノート上で書き散らしているもの
2 ある程度まとめてはいるが、ホームノートに直接書いているもの
3 リンク集
ホームノートに書いてないものは別ノートに存在しますが、それだと辿れないのでホームノートからリンクを張ります。この性質上、ホームノートにはリンクが並んでリンク集になります

リンク集についてはホームノートに直接書く必要はありません。たとえば「もう見てない」という名前のノートをつくって、これをリンク集にすればいいでしょう。ホームノートからは「もう見てない」ノートに1行だけリンクがあり、「もう見てない」ノートには実際にもう見ていないノート達のリンクが何百と並んでいる――なんてこともありえます。この何百のリンクをホームノートに置くと邪魔なので、「もう見てない」という名前のノートを一段つくってそこに入れるわけです。
要は玄関口を自分で上手くメンテナンスしなさい、というやり方ですので、自分で整理整頓できるならこれで十分です。できない場合はビューに頼ったホームビューや、日単位で強制的に移動させられる日付ノートを使うと良いでしょう。

 ホームビュー自分がつくったノート達を上手く見せるビューをホームにすること、あるいはしたものを ホームビュー と呼びます。
ホームビューでは、おそらくノートをリストなりカードなりで一覧表示したり、検索ボックスを出したりソートやフィルタリング用の部品を置いたり、あるいは新しくノートをつくる手段が整っていたりするでしょう。ビューですので、ここで直接ノートを書くことはできません。かわりにノートの管理、特に俯瞰が行えます。
もちろん、このようなビューはただのノートツールではつくれないため、ビューを持つツールを使う必要があります（自分でプログラミングしてつくることもできますが本書では割愛）。それもただのビューではなく、ホームとして使えるだけのポテンシャルが必要です。事実上ビューとして相当優れている必要があります。
筆者がよく知るビューは Scrapbox です。以下は筆者が持つプロジェクトの例です（私的なコンテンツなのでぼかしています）。
これはプロジェクトというワークスペース内にページというノートをつくる構造ですが、このプロジェクトがビューとなっており、カード形式で一覧表示します。ここから読みたいカードを開いたり、＋ボタン（上部の緑色のボタン）で新しくカードをつくったり、検索やソートやフィルタリングもできます。よく使うカードはピン留めして最上部に固定しておけば開きやすいです――と、ホームビューを使いたいならこれくらいのビューが必要でしょう。

 日付ノート日単位で日付名のノートをつくり、今日は「今日の日付名のノート」をホームとするやり方を 日付ノート と呼ばせてください。
たとえば今日が 2024/08/06 なら「2024-08-06」という名前のノートがあって、そこがホームになります。明日は「2024-08-07」ノートがホームになるでしょう。戦略の章で述べたデイリーエリアの概念そのものです。
日付ノートは、ホテルでたとえるなら毎日部屋を変えるようなものです。部屋を移る手間はかかりますが、毎日新しい部屋を使うことができます。ホームノートでは散らかってしまうという場合は、日付ノートをホームにするのが良いでしょう。
ここで一つジレンマが起きます。よく使うリンク集や毎日高頻度にメンテナンスするテキスト（典型例はデイリータスクリスト）といったものはほぼ必ず登場しますが、これらは常に手元に置いておきたいです。日付ノートがホームだと、毎日移動させることになってしまいます。これは手間ですし、これらが長大になってくると日付ノート自体も長くなってしまい使いづらいです。じゃあこれらを、たとえば「倉庫」という名前のノートをつくってそっちに退避させて、日付ノートでは「倉庫」ノートへのリンクを一行だけ書くことにしようかと考えますが、これだと倉庫の中身を見る度に毎回リンク先を開かねばなりません。それは大変だからと、じゃあ日付ノートと「倉庫」ノートを両方とも（別ウィンドウや別タブの形で）常に表示させておけばいいかと考えますが、これはこれで日付ノートと「倉庫」ノートを行ったり来たりすることになって タスクが漏れます。タスクリストとしてちゃんと書いてたはずなのに、なぜかスルーしてしまった、ということが起こり得ます。二つ以上に分散しちゃうと、注意も分散してしまって忘迷怠が起こりやすくなるからです。なので ホームとして常に表示し、常に見るノートは一つだけに留めたい ところです（※1）。
このように毎日使うテキストを日付ノートで扱うのは意外と難しいのです。面倒くささを減らして、かつ忘迷怠も最小限にするバランスは各自で探ることになります。
実用的にはハイブリッドに使うのが良いと思います。たとえばホームノートとハイブリッドにする場合、ホームはホームノートとしておき、ホームノートには当月分の日付ノートへのリンク集をつくるのです。一番の上を今日の日付ノートへのリンクにすれば、今日の分は一番上のリンクからアクセスすればいいと単純化できます。また Scrapbox では今日の日付ページをピン留めすることで、ホームビューをホームとしつつも今日の日付ノートにもすぐにアクセスできる形を実現できます（ホームビューと日付ノートのハイブリッド）――つまり日付ノートを唯一のホームにするよりも、何か別のホームをつくった上で、そこから日付ノートにもアクセスしやすくしておくという形にするのです。その上で日単位でメリハリをつけたい部分は日付ノート側で扱うようにするのです。そういう意味では、上述したバランスとは「日付ノートに何を入れるか（どこまで入れるか）」のバランスとも言えます。
※
1 ただしディスプレイが大きいとか複数のディスプレイがある等、表示領域が潤沢な場合は例外です。日付ノートも倉庫ノートもどちらも常に表示できます。


 トランクトランク（Trunk） とは直訳すると「幹」で、幹から多数の枝葉が伸びているイメージです。トランクとは「多数のリンクを伸ばしたノート」を指します。そういう意味ではホームノートやリンク集は最も太いトランクですし、日付ノートも日単位で色々リンクを張るという意味ではそこそこ太いトランクですが、何もこれらに限らなくてもいいのです。
仮に今日から LTM を始めるとして、よくわからないのでとりあえず「テスト」という名前のノートをつくったとします。ここで日々タスクリストを書いたり、メモを書いたり、思考や検討や調査の結果も書いたりして過ごしていくとしましょう。何もしないとテキストが肥大化するばかりですが、ネットワークですので別途ノートをつくってそこへのリンクを張る、という形で逃がしても良いわけです。たとえば引っ越しネタは「引っ越し」ノートに、転職ネタは「転職したい」ノートに、日付ノートは「2024-08-06」ノートや「2024-08-07」ノートに、といった形でどんどん逃がしていきます。もちろん逃がしただけだと後で辿れないので、「テスト」ノートからはリンクを張っています。このとき「テスト」ノートはトランク的と言えます。「テスト」ノートで過ごせば過ごすほど、多くのリンク（枝）が増えていくでしょう。
しばらくして転職が完了し、引っ越しもできたとします。生活が一新されたようなものですが、「テスト」ノートはそのままです。すでにここはごちゃごちゃしているでしょうから、思い切ってホームを変えましょう。仮に大阪から岡山に引っ越したとして、ノート名は何でもいいですが「岡山新生活」とでもしておきましょうか。「岡山新生活」ノートをつくり、「テスト」ノートから必要なテキストをコピペしてきます。以降はこの「岡山新生活」ノートがホームです。今後はここからリンクが生えていくでしょう。可能ならあとで辿れるように、「テスト」ノートに跡地の旨と「岡山新生活」へのリンクを書いておくと優しいですね。
さて、さらに月日が経ちまして、岡山での新生活も落ち着いてきました。長期休暇も取れそうです。旅行に行きたくなってきました。「2024 旅行」ノートをつくりましょう。旅行に関する検討は（「岡山新生活」ノートではなく）こちらでやることになるでしょう。つまり「2024 旅行」ノートもそれなりのトランクにはなると思われます。このようにホームに限らず、必要に応じてトランクをつくるのもアリです。
と、しばらく例を膨らませてみましたが、何が言いたいかというと、トランクの使い方は定住的でなくても良い ということです。遊牧民のようにホームを転々とするやり方でも構わないのです。ただし、後々辿りたくなったときに困ってしまうので、可能ならリンクをちゃんとつけて辿れるようにしておきましょう。立つ鳥跡を濁さずと言いますが、遊牧的にトランクを切り替える場合はリンクくらいは残しましょう。別の言い方をすると、別れるときには別れの挨拶や送迎会といった儀式をしますが、遊牧的な LTM においては「リンクをつける」ことが儀式に相当すると考えてください。

 まとめLTM の準備と題して、以下の点を述べてきました。
ネットワーク型エディタを使うこと
ネットワークベースを使うこと
ダイアリーベースやプロジェクトベースも使えます

ホームをつくること
ホームノート、日付ノート、トランクの 3 つ
ビューが備わっているなら、そこをホームとしたホームビューもアリ

ですが、ここまで述べてきたのはノートの話です。肝心のタスク管理の話はまだ出ていませんので、次節から詳しく見ていきます。

 LTM におけるタスク管理ここまでで LTM はノートを使うこと、ネットワーク的につくること、特にホームをつくって広げていくことを強調してきました。
いよいよタスク管理の部分に入っていきます。ネットワーク的なノートの世界において、どのようにタスクを読み書きしていけばいいのでしょうか――その考え方とやり方を詳しく見ていきます。

 ホームをつくるとにかくまずはホームをつくります。
迷うなら「ホーム」でも「デスクトップ」でも「てすと」でも何でも良いので、何か一つノートをつくってそこをホームにしてください。ホームは後で変えることもできますが、ホームなる概念が定着しないことには始まりません。
加えて、数秒以内に記入開始できる状態にしたいです。3秒の壁はタスクを追加する時の話ですが、ここでは「ノートに何か書き込む時」の話をしています。どこに書き込むかは複数考えられますが、もっともシンプルなのはホームです。つまりホームへの書き込みを数秒以内に開始できる状態にしたいです。この素早さを達成するには、基本的には「常に開いておく」か、少なくともボタンやショートカットキー一発で起動できることが必要でしょう。開始までの早さは本当に重要ですので、0.x 秒でも縮める努力をしてください。開始までが遅いと書く腰が上がりにくく、LTM の挫折に引きずり込まれてしまいます。X など SNS をチラ見している人は多いと思いますが、イメージとしてはそれと同じです。おそらく即座にチラ見できるようにしているはずです。それを「ホームに何か書き込む」ことに関しても行いたいのです。

 タスクに関する情報は 3 種類あるLTM において、タスクに関する情報が 3 種類ほど存在することを押さえてください。
メモ
タスク
タスクビュー
タスクノート

文脈
メモとは、あとで処理する事柄を素早く一時的に残しておくことです。メモの章でも述べたとおり、できるだけ早く書ける素早さが重要となります。もちろん、書けたとしても後で拾えないと意味がないので、あとできちんと処理できるよう工夫もします。
タスクとは、やることです。Must でも Should でも Want でも何でもいいので、「やる！」と決まったもの、あるいは決めたいものを指します。
タスクはビューで俯瞰できねばなりません。自動でタスクを拾ってビューにするか、自分の手作業でリスト化するなどしてビューにするか、やり方は色々あります。また、どこに書くかについても、GTD のネクストアクションのように「あらゆるタスクを一箇所に集める」やり方（※1）もあれば、ノートごとにタスクリストエリアをつくってそこに集める（つまり複数に分散する）やり方もあります。いずれにせよ、複数のタスクを、俯瞰するために集める必要があるわけです。これを タスクビュー と呼びます。
もう一つ、タスクはそれ自体が色々な情報を持ちます。属性を含め 3A の話はすでにしました。ただし LTM は文芸的な世界ですから、これら属性なり関係なり機能といったものを全部テキストで表現することになります。また、文脈を尊重して QoL を上げると書いたように、開始時間だとか締切だとか分類だとかやったやらなかったとか進捗だとかいった、そういった「管理」的なことはしたくないわけです。もっと伸び伸びしたいのです。そのためには――と考えたときに、前述したトピック指向が出てきます。タスク T があるとするなら、T というノートをつくってしまい、T については全部そこに書き込めばいいのです。ついでに、T と関係ありそうなノートがあればリンクも張ります。こうすることで、T というノートに（その中身 or リンクで繋がった接続という形で）T に関する情報、つまりは文脈が集まるのです。というより、集めるのです。と、少し長くなりましたが、この T のように、タスクそれ自体に関するノートを タスクノート と呼びます。
つまり LTM ではタスクノートの形で各タスクの文脈をノート的・ネットワーク的につくりつつ、タスク管理もちゃんとやるためにタスクビューも適宜つくって俯瞰もする、という戦略を取る のです。この両輪から攻める程度でタスク管理を行えるようにしたいのです。従来のようなザ・管理的なやり方はしません。それはただのタスク管理であって文芸的タスク管理ではないからです。
さて、最後に文脈ですが、これはメモでもタスクでもない、すべての情報を指します。早い話、ノートに書いたことはすべて文脈です。この中から色んな発想や情報やタスクや意思決定が生まれます。指示されたことに黙って従うわけでもなく、正解がなくて動けないわけでもなく、LTM として書いて貯めてきた文脈の力を借りて、自分なりに意思決定して前に進むのです。十分な文脈が集まっていれば、たいていは自然な結論が出ます（何もわからないのでとりあえずやってみよう等も含めて）。そして、LTM を行えば文脈は集まります。ノートにあれこれ書き込んでいくからです。第二の脳と書きましたが、LTM では頭の中で考えてタスクリストを書いて終わりではありません。考えたことを全部（でなくてもいいですが）ノートに書き込み、その書き込みをメンテナンスしていくのです。ノートを育てるのです。育てたノートは文脈の宝庫になります。そうでなくとも文脈を育てる育成場として機能します。
※
1 ここで GTD のネクストアクションを持ち出したのは、タスクを一箇所に集める例としてわかりやすいと思ったからです。GTD ではインボックスやプロジェクトといった形でワークフローに基づいて「気になること」をフィルターしていき、最終的に「具体的に行動可能な小さなアクション」が出てきます。これを集めたのがネクストアクションです。仮に 20 くらいプロジェクトがあって、1 プロジェクトあたり 5 個のアクションがあるとしたら、単純計算で 100 個のネクストアクションが集まります。実際は途中で別のフィルターに行ったり（たとえば「Someday（いつかやる）」や「Waiting（連絡待ち）」など）、収集ステップで大量に気になることをインプットしたりするので 100 より増えたり減ったりします。ともかく、ネクストアクションには次にやればいいことが集まっているわけで、理想的には、ネクストアクションから一つ選んで行動 → また一つ選んで行動、のような過ごし方になるはずです。ネクストアクションという場所一つだけを相手にすればいいのです。「一箇所に集める」は、このニュアンスです。


 エリアとマークメモとタスクの二つは、後で処理しなければならないものです。メモは早く読み返さないと（何を書いているか）忘れてしまいますし、タスクは忘迷怠を起こさずにこなさなければなりません。
では、LTM においてメモやタスクを「後で処理する」ためには、どうすればいいでしょうか。
本質は至ってシンプルで、後で改めて読み返すしかありません。となれば問題となるのは読み返しのコストです。読み返すための労力をできるだけ減らせばいいのです。何も工夫しないなら極論すべてのノートをを一から読み返せばいいだけですが、現実的ではありません。LTM ではノート数は数百、数千、下手すると万も超えるのです。
読み返しの労力を減らす戦略も、二つしかありません。
エリア
あとで読み返すエリアを決めておき、そこに書いたものを後で読み返す

マーク
読み返す部分にマークをつけておき、あとでまとめて検索・表示する
つまり「マークがついたものを表示する」ビューをつくる

本当はもう一つ、生成 AI に全部読ませてリマインドしてもらうやり方もあるのですが、余談で述べたとおり精度の面で実用的ではないため割愛します。

 エリアまずエリアですが、これは全面的に手作業で行うものです。特定のノートまたは特定のノートの特定の場所を「後で読み返す場所（エリア）」と定めて、そこに書き込んでおき、別のタイミングでそこを読み返すのです。ホームはエリアの一つですが、エリアというにはしばしば大きくなりすぎるため意味がありません。
エリアはもっと小さいものです。たとえばホームに「デイリータスクリスト」を書く領域をつくって、その日やるタスクを全部突っ込んで、かつ高頻度に読み返すようにします。これはデイリータスクリストというエリアをつくっていると言えます。もちろん、やり方はこれだけではなく、「デイリータスクリスト」ノートを別途つくってもいいですし、「プロジェクトA」ノートと「プロジェクトB」ノートをつくってそれぞれにデイリータスクリストエリアをつくってもいいかもしれません。
重要なのは書き込みのしやすさ、そして 後でちゃんと読み返せるかどうか です。ホームであれば毎日高頻度に目にするはずですから、何も工夫せずとも読み返せるでしょう。その分、慣れすぎてしまって「読んだつもりなのに普通にスルーしてしまう」恐れもあります。別にノートをつくって丸ごとエリアにすれば、慣れすぎは防げますが、今度はアクセスがしづらくなります。このあたりのバランスは動線の章でも述べました（ネグレクテッド）。また、カレンダーやリマインドを使って「このノートのこのエリアをチェックしろ！」と自分に教えるよう仕込むこともできます。GTD のレビューのように定期的なイベントにしてもいいでしょう、たとえば「読み返すエリアの一覧」をつくっておいて、週次レビューで全部読み返す、などです。
エリアは手作業的で、非常に面倒くさく思えますが、LTM では意外と機能します。そもそも LTM では恒常的にノートに書き込んだり、リンクを張ったり、新しいノートをつくったり、といったことをしているので土地勘や地理感のように定着してきます。目的の場所にも高々数ホップ（リンクを1つ辿ることをホップといいます）で到達できますし、どのノートからどのリンクを辿ればいいかも定着しているゆえに「わかる」ので迷いません。そもそも定着するまでが長い可能性はありますが、意外と手間は少ないのです。

 マークタグがついたものを一覧表示する機能はお馴染みだと思いますが、マークとはまさにこれのことです。後で読み返したい文章（特に特定の行）に何らかの印（マーク）をつけておいて、あとでその印を検索して「印がついている部分」だけを抽出します。
手段としては、最もかんたんなのはノートツールが持つ検索機能を使うことです。エディタの場合は「全文検索」とか「Grep」と呼ばれていることもあります。これら検索機能は特定のキーワードにマッチする部分を表示します。つまりキーワードとしてマークを指定することで、マークのついた部分を表示できます。
さて、残る問題はマークをどうするかです。昔は @task など記号（この例ではアットマーク）つきの文字を書いたり、●task や ■task のように記号を付けるのが主流でしたが、現代では絵文字も使えます。絵文字は視覚的に目につきやすいのがメリットで、検索による一覧表示というよりは普段ノートを読み書きしているときに目に入りやすいのが便利です。タスクを表す絵文字というと難しいですが、自分が分かればいいので📒（ノート）、✅（チェック）、🏃（ランナー）、📌（ピン）、💣（バクダン）など何でも構いません。可能なら終了を示す✅は別に決めておいて、未終了を示すマークが欲しいです。💣タスク1が完了したときは✅💣未タスク1のように重ねて書けば完了したことはわかります。
マークによる検索結果はビューと呼ぶことができます。タスクにのみマークをつけることを徹底しているのなら、検索結果は事実上タスクビューとなります。しかし、ビューを見るためにはいちいち検索を行わねばならず、この手間が命取りになります。手間がかかると怠けてしまい、怠惰が続くと形骸化まっしぐらです。したがって 検索結果を開く手間はできるだけ抑えてください。ショートカット的な機能があるならそれで一発で呼び出せるようにしたり、ウェブアプリ型のノートツールであれば検索結果のページをブックマークしておいたり、もちろん自分で検索処理や検索結果を表示するスクリプトなどをつくっても良いでしょう。エディタを使っている場合、エディタの拡張機能を駆使することでも工夫できそうです。とにかく、マークを使う場合はビューをいかに手間なくつくれるかが重要ですので、この点は妥協しないでください。
さらに高度なやり方として、マーク以外にもタスクの属性をつけておくことが挙げられます。たとえばhownでは[2002-10-22]@ タスクという形でタスクを書きます（@の他にも!や+や-を使い分けます）が、これは日付系属性をつけています。そして、あとでビューをつくるときにこの日付と現在日を比べて、より近いものを一覧の上位に出すとか、逆に下位に沈ませるといった工夫をします。詳細は割愛しますが、現在日ベースで優先順位を自然に制御できるのです。もちろん、この書き方を読み込んでちゃんと処理するようhownがつくられてるから動作するわけで、自分でこれと同じことがしたいのなら自分でつくるしかありません。hownは文芸的タスク管理の上手い例と言えるでしょう。

 LTM でカバーできない部分の対処LTM は文芸的な営みであり、目的も QoL の向上です。要は文章を読み書きして自己満足感や自己肯定感を高めましょう、ついでにタスク管理もある程度行えるようにしましょう、というだけにすぎません。タスク管理としてあらゆることを行えるだけのポテンシャルなどないのです。LTM ではカバーしきれない部分がどうしても出てきます。これを アンカバード（Uncovered） と呼びます。
アンカバードの例と対処を以下にまとめます。
ルーチンタスクとオルタスク
詳細はプレーンテキストの章を参照

タスクや文脈を他者に見せること
これもプレーンテキストの章で書きました
LTM は自分のみが読み書きすることを想定しており、そのままでは見せられないはずです
他人にも見える場所での LTM もできなくはないですが、人目があると伸び伸びと書けなくて破綻しやすいため推奨しません


属性に基づいた細かい管理や高機能なビュー
通常のタスク管理ツールを使ってください

締切を厳格に守らねばならない、厳しめのタスク管理
通常のタスク管理ツールを使ってください
必要ならカレンダーやリマインダーに頼ったり、イベント（強制力の働く場）への参加や設定も検討してください → オルタスクとしてで扱っています

とはいえ、アンカバードのやり方ばかりに頼っていては LTM などできません。なるべく LTM で完結できるように工夫して、どうしても面倒くさい部分だけは諦めて別のやり方でやるくらいが良いでしょう。
料理や DIY と似たようなものです。世の中にすでに良いものがあるから自分でつくるのはやめよう、としてしまっては何もできません。そんなことは百も承知で、それでも QoL を上げるためにあえて自分でつくってみるのです。実際楽しかったりもします。LTM も同じで、タスク管理ツールで行えることを、あえて文芸的に、自分で、ノートを使ってやってみるのです。とはいえ何でもかんでも再現していては大変ですから、調味料は市販のものを使うとか、ドリルは電動のものを使おうなど面倒なところは端折ります。LTM も同じで、アンカバードは面倒くさいので既存の手段に頼るのがベターです。

 文脈の捉え方とつくりかた
 捉え方LTM にはメモとタスクと文脈があって、メモとタスク以外はすべて文脈だと書きました。ノートに書いたことはすべて文脈になるとも書きました。そもそも文脈とは何でしょうか。
LTM の目的は QoL の向上と書きましたが、タスク管理ではあるのでタスクを扱うことで向上させます。どのように扱うかというと、文芸的に行います――つまりは文章を読み書きします。通常、タスク管理は「やらないといけないもの」が降ってきて四の五の言わずに対応するしかない、ただリソースにも限りがあるから優先順位とタイミングは考えないといけない、といったニュアンスを持ちますが、LTM はそうではなく、日頃扱っている文章からタスクを決めます。自分主導で行うタスク管理 であり、ヒントとして自分が書いてきた文章を使うのです。
文脈とはヒントです。
それゆえ正解はありません。仮に航海日誌のように淡々と事実と出来事だけを書くとしたら、それは客観的記録を文脈にしていると言えますし、感情をだらだら長々と書くとしたら主観を文脈にしていると言えます。書籍や SNS から有益な概念や金言を集めて考察するのもアリですし、誰にも通じないような深い思索や哲学におぼれてもいいでしょう。とにかく、書いたことは何でも文脈になりますし、LTM ではそれら文脈からタスクを導きます。
タスクを導くという点もポイントです。書いて終わりではなく、タスクという行動を伴う必要があります。なぜなら、行動しなければ何も変わらないからです。行動の起こし方には色々ありますが、LTM ではノートに書いて考え、書いたそれらを育てるやり方を選びます。書いて、読み返して、考えて、反映して、を繰り返して積み重ねていくことで納得の行く結論や意思決定を出すのです。正しい、正しくないと言っているのではなく、あくまで LTM ではそうしますという話です。
小難しく書きましたが、まとめると以下のとおりです。
LTM では、
ノートに書いたこと（文脈）をベースに考えを広げていく
行動を伴わせたいので、どこかで行動――すなわちタスクを導く必要はある

何を書くか、つまり文脈は何かという問いに正解はない

 つくりかたでは文脈はどのようにつくっていけばいいのでしょうか。言い換えると何を書いていけばいいのでしょうか。
ポイントは三つあると思います。
一つは自分が書きたいことを書くことです。LTM は今日も、明日も、ずっと読み書きを続けていく営みですから、そもそも読み書きが続かないと話になりません。嫌いなことやどうでもいいことはそもそも続きません。書きたいと思えるようなことを積極的に取り入れるのがまずは大事です。日記でもいいですし、趣味の話を全開にしても構いません。物申したいことや愚痴があるならそれを書いてもいいでしょう。とにかく、書くことが続きそうな題材を遠慮なく選んでください。
二つ目は「深堀りできるネタ」を捉えることです。最低でも現時点で見えているタスク――直近やらないといけないことから、そのうちやりたいことやできればやっておきたいこと、あるいはやりたくないけどやるべきだと思っていることまで、タスクになりうるものなら何でもです。趣味で深堀りしたいものがあればそれを含めても構いません。深堀りできれば何でも良いです。振り返りの章で取り上げたトリガーリストも便利です（深堀りできそうなネタを貯めておく）し、SNS やニュースや書籍を日頃からキャッチアップするのもよく使われる手です。発信者の方はご存知だと思いますが、意識としては「ネタ探しのアンテナを張っておく」感じです。ビビっと来たこと、特に色々深堀りしたそうなことを見つけたら、ぜひともメモして貯めたいです。あるいは別の言い方をするなら、業務中でも雑談をすることがあると思いますし、雑談であっても話を深堀りすることがあると思います。そのおかげで仕事に繋がることもよくあると思います。LTM も似たようなもので、要は自分に直接関係するタスクのみを扱うのではなく、扱いたいものは何でも扱ってみましょう ということです。そうすることで LTM の書き方にも慣れていきますし、自分の向き不向きや興味好奇や調子動機も見えてきます。こういうネタなら深堀りできそう、しやすそうという「美味しいネタ」が見えてきます。人は自分なりの軸がないと自律的に動けませんが、これら美味しいネタがまさに軸になるのです。
もう一つ、頭の中の棚卸しも適宜行うと良いでしょう。GTDでは収集ステップと呼ばれていますが、1～2 時間などたっぷり時間を確保した上で、思いついたことを何でも書くのです。書いたものを見ていると、さらに色々思いつくのでそれも書きます。そのうち関連や本質が見えてくるので、整理もしていきます。こうすることで色々見えてきます。脳内で考えるだけでは堂々巡りにしかなりませんが、書いたものをベースにしていくことで（疲れはしますが）進んでいけるのです。ブレスト（ブレインストーミング）、フリーライティング、KJ法など、この手の営みは多数存在しますが、手法は重要ではありません。たっぷり時間を確保して、書いたことをベースに考えを広げて・深めていければそれでいいのです。自分のための営みですから正解もありません。自分なりに存分に楽しめればそれでいいです。LTM の場合、これを行う用のノートをつくって書き殴るだけで済みます。ノートの名前は「ブレスト1」でも「2024/08/11」でも「2024/08/11 07:25:47」でも「8/11 フリーライティングするぜ」でも何でもいいです。何ならノートさえつくらずに、ホーム上で始めてもいいです。とにかく、LTM であれば、書くことは気軽にできるのですから、さっさと始めてしまえばいいのです。このような営みを探索と呼びます。深堀りできるネタを、脳内に潜って探しに行くイメージです。
三つ目は自問自答です。一つ目や二つ目により、書くことは集まりますが、そこにどんな風に自分なりに書き足していくかがまだ足りません。自分で書かないと、ただの収集や陳列で終わってしまいます。自分の言葉で書くためには、自問自答が最適です。たとえば以下のような問いをします。
自分はどう思うか
行動に繋げるとしたら何ができそうか
（嫉妬や羨望が湧き上がったとして）なぜそう感じてしまうのか
建前としてはどうするべきか、一方で本心ではどう考えているか
自分なりに面白いと感じる部分はどこか
自分が続きをやるとしたら、どうやるか etc
最初はどんな問いを選べばいいか混乱すると思いますが、頑張って続けてみてください。最初のうちはトリガーリストをつくって、それを見ながらでもいいでしょう。次第に「自分が好む問い」が見えてきて、息するように書き足していけるようになります。たとえば筆者の場合、「凄えと言われそうな上手いことを言いたい」という物申したさ、「新しい仕事術や概念をつくりたい」というものづくりの欲求、あとは自分のためになる学びや知識を吸収するために「自分の言葉で表現したい」とする気持ちなどが強いです。問いの形で表現するとしたら、「皆に凄えと思われる見解やツッコミは何か言えないか？」「ここからどんな新しい概念を導けるだろう？」「これを理解するために自分だったらどう表現する？」となるでしょうか。もちろん、これは私の好みであって、これが正解というわけではありません。

 ライティングスタック私たちは通常、頭の中に原本があります。頭の中の原本を言語化して人に伝えたり何かを書いたりします。これを筆者は イメージスタック（Image Stack） と呼んでいます。頭の中のイメージを積み重ねていく感じです。
一方、LTM では異なる考え方に則ります。ノートに書いたことを原本にするのです。頭の中は、ノートに書いたことを読み込んであれこれ考えたりするための作業場にすぎません。原本はあくまでもノートにあります。ということは、日常的にノートを読み書きして育てていくことになります。仮に自分の人生哲学が 3 つあるとするなら、それは頭の中に留めるのではなく、ノートとして書いておくべきです。そして哲学が変わったのなら、その旨もノートに反映します。ノートが原本です。これを ライティングスタック（Writing Stack） と呼んでいます。
LTM が定着するかどうかは、このライティングスタックの考え方に染まれるかどうかにかかっていると筆者は思います。もちろん、人間なのでイメージスタックを完全に脱することはできませんが、それでも（特に LTM として扱う事項については）ライティングスタックに寄せたいです。これくらい考え方を変えないと、LTM という読み書きの営みは続きません。作家にとっては書いた文章が原本ですし、プログラマーにとっては書いたコードが原本ですが、同様に LTM を行う者にとって書いたノートが原本です。このライティングスタックの考え方を採用するからこそ、書くことができるのです。
特にタスクについては、なるべくライティングスタックを採用してください。タスク管理の主な恩恵は「脳内ではなくタスク管理ツール側に保存しているから脳内がスッキリする」ですが、LTM も例外ではありません。LTM を正しく運用できていると、然るべきノートを然るべきタイミングで見ることで思い出せる・切り替えられるようになり、頭の中にあれこれタスクを保持しておく必要がなくなります。その分、ノートの読み書きや思考に集中できます。慌ただしいシチュエーションには向いていませんが、このようなあり方は自律的で創造的な生き方であり、QoL を高めます。

 切り出し有益と思われる文章や単語は積極的に切り出してください。切り出し とは、指定した文章（単語でも良い）をノート名にして別ノートとして独立させることです。
たとえば、ちょっと前節の文章を引用してみますが、
LTM が定着するかどうかは、このライティングスタックの考え方に染まれるかどうかにかかっていると筆者は思います。もちろん、人間なのでイメージスタックを完全に脱することはできませんが、それでも（特に LTM として扱う事項については）ライティングスタックに寄せたいです。これくらい考え方を変えないと、LTM という読み書きの営みは続きません。作家にとっては書いた文章が原本ですし、プログラマーにとっては書いたコードが原本ですが、同様に LTM を行う者にとって書いたノートが原本です。このライティングスタックの考え方を採用するからこそ、書くことができるのです。
ライティングスタックの概念を勉強し、定着させたいなら、何かしら切り出しを行うのが良いです。切り出し方は色々ありますが、筆者なら「LTM を行う者にとって書いたノートが原本」を選びます。これはつまり「LTM を行う者にとって書いたノートが原本」という名前のノートを新たにつくるということです。
実際の動き方としては、以下のように該当部分をリンクにします。Scrapbox だと[ ]、Obsidian だと[[ ]]で囲むことで行えます。他のノートツールを使っている場合はその記法に従ってください。
……（中略）……プログラマーにとっては書いたコードが原本ですが、同様に[LTM を行う者にとって書いたノートが原本]です。このライティングスタックの考え方を採用するからこそ、書くことができるのです。
これでリンク化されるので、リンクをクリックして「LTM を行う者にとって書いたノートが原本」ノートを開きます。自分なりの学びを書いたり、リンク元ノートへのリンクを記載したりなどすれば良いでしょう。
こうすることで、以後「LTM を行う者にとって書いたノートが原本」という名前のノートが使えるようになります。部品化とも言えます。たとえば別のノートで LTM の勉強をしているときに「あ、これノートの方を原本にするってことだよな」と気づいたら、この「LTM を行う者にとって書いたノートが原本」ノートへのリンクを書き足すことができます。「LTM を行う者にとって書いたノートが原本」という知識が使われたのです。これを続けていくと、「LTM を行う者にとって書いたノートが原本」ノート側にも「どのページから使われたのか」が貯まっていきます。使われる機会が多いほど自分にとって重要そうだとわかりますし、自発的に再度読み返すことで新たな発見があるかもしれません。
作家は良いと思ったことわざや格言を貯めておいて、文中で使うと思います。プログラマーも、便利なスニペット（コード片）は使い回しますし、関数やモジュールやライブラリといった形で部品化もします。同様に、LTM では文章を何でも部品化できます。ノートにはノート名（タイトル）と本文があるので、詳細は本文に書いておいて、本質だけをノート名に含めればいいのです。この部品化のやり方は色々ありますが、最も頻出するのが切り出しなのです。
この切り出しは、タスクを扱う場面でもよく使います。わからない用語があったときにその用語名で切り出して、辞書や検索などで勉強したことを書き足しておくとか、Aさんのチャットメッセージを引用した上で、ここについては私はこう思うんだけどなぁということで該当部分を切り出してから自分の考えを書いてみるなど。ひと手間はかかりますが、切り出してちゃんと（あるいは雑でも良い）扱ってみることで文脈が強化されます。もっと言えば納得感を導きやすくなります。少なくとも自分はこう考えたのだと胸を張れますし、ノートとして残しておけば後々目にして再利用なり触発なりも起きるかもしれません。
無論、すべてについていちいち切り出すわけにはいきませんが、少しずつでも積み重ねていくことで、後々変わってきます。勉強も練習も地道に少しずつ重ねていきますが、LTM でも同様です。大げさに言えば、切り出しが文脈をつくります。切り出したノートは、言わばあなたの選択であり、あなたの文脈です。あなたなりの文脈を、切り出しによって日々積み重ねていくのです。

 微修正とエイリアスライティングスタックや切り出しの話をしてきました。文章なら何でも部品化することができ、部品を使う（リンクを張る）ことでノート間の繋がりが出来てきてネットワークが育ちます。ノートという原本が育っていくのです。まさに第二の脳です。
さて、このときに重要な原則が一つあります。ノート名は少しでもわかりやすく、あるいはキャッチーにするということです。リンクはノート名がベースとなっていますから、ノート名をどう書くか次第で扱いやすさ（見やすさや言及のしやすさ）が変わってきます。扱いやすさが低いと再読解や再利用の機会も失われて、忘れてしまいますので、明示的に確保していきたいのです。
まず自分にとってわかりやすい名前にします。前節では「LTM を行う者にとって書いたノートが原本」ノートをつくりましたが、この表現が気に入らなければ修正するべきです。以下にいくつか例を挙げます。
修正前
「LTM を行う者にとって書いたノートが原本」

修正後の例
「LTM を行う者にとっては、書いたノートが原本」
「LTM では書いたノートが原本」
「文芸的タスク管理では書いたノートが原本」
「書いたノートが原本」
「ノートが原本」

正解はないですし、原意の尊重や厳密性が重要とも限りません。自分にとってわかりやすいかどうかがすべてです。もちろん原意を尊重する方がやりやすいならそれでも構いません。
次に エイリアス（別名） も便利なので積極的に使いたいです。たとえば「LTM を行う者にとって書いたノートが原本」という名前を尊重しつつも、自分としては「ノートが原本」と「文芸的タスク管理では書いたノートが原本」が使いやすいなぁと思ったら、全部つくればいいのです。
こうすれば「ノートが原本」ノートからでも、あるいは「文芸的タスク管理では書いたノートが原本」ノートからでも「LTM を行う者にとって書いたノートが原本」ノートにたどり着けます。これはあくまでも一例で、「LTM を行う者にとって書いたノートが原本」にリンクを集めるようにしていますが、もちろん別のノートに集めても構いません。
エイリアスを使う場合は、1-ソース n-エイリアスを心がけてください。エイリアスを集める先（ソース）はただ一つであるべきです。また、無闇にエイリアスを増やしてもあとで混乱するだけですので、「どうしても二つとも残したい」とか「なぜか知らないけど二択で迷う」など、自然と n パターンに分岐してしまう（n=2 が多い）ときに限ってエイリアスを使うくらいがバランスが良いです。

 アイキャッチとエキサイトメントLTM を続けていくとノートがたくさん貯まります。リンクもたくさん集まります。そして、それらはテキストとしてずらりと並んでいます。いわば活字の海となっています。慣れた者であっても、これらを読み返すのは中々にハードです。そもそもすべてのノートを読み返したりメンテナンスしたりすることは非現実的でしょう。
ノートと継続的に向き合うためのモチベーション、なるものを何とかして保つ必要があります。ここで使えるのがアイキャッチとエキサイトメントです。
アイキャッチ とは、ブログ記事に差し込まれる画像やサムネ――動画のサムネイルなどが有名ですが、目を引く要素を指します。LTM においてはキャッチーなノート名、画像、GIF、動画などが該当します。要は活字の海に視覚的なアクセントを持たせることで、ノート全体を賑わせます。扱うコンテンツはタスク管理に関係しなくても構いません。筆者の場合、SNS でバズったポストの画像や VTuber の動画、あるいは自分で撮影したゲーム動画やダンス動画などを掲載しています。一見するとタスク管理には関係ないですが、これらのおかげでテンションが上がって、ノートを読み返すモチベーションも増えるため総合的にはプラスになります。特に自分のコンテンツを、まるで自慢するかのように展示することは自己肯定感を高めるメリットもあります（人を選びます）。
アイキャッチを行えるノートツールは非常に限られています。オフラインでエディタを使っている場合は厳しいでしょう。本章では Scrapbox を推していますが、動画像の挿入やサムネイル表示に対応した Saas 型のツールを事実上使うことになります――と書くと、動画像といった非言語要素が重要に思えますが、実はそれだけではありません。キャッチーなノート名をつけることも意外と重要です。LTM はノートであり、ノートであるからにはテキストは避けられませんので、テキスト自体でアイキャッチを確保することもサボらない方が良いでしょう。SNS やニュースでもキャッチーな見出しはよく見られますが、あのイメージです。自分にとって自然な表現や、自分を鼓舞する表現を追求していきましょう。ただし、他人の言葉を展示するだけだと「自分の」文脈が育まれないため要注意です。他人のコンテンツを保存するばかりですと、LTM というより、ただのブックマーク展示場となってしまいます。
次に エキサイトメント ですが、これは作業興奮を引き起こしやすくする構成にすることです。より具体的に言えば、書きかけのノートを優先的に表示することです。これも Scrapbox がお手本で、Date Modified という「更新した順にページ（ノート）を並べる」機能があったり、特定のページをピン留めして常に最上位に表示したりできます。こういった機能を使えば、やりかけのノート――いわば未完成の、中途半端なノートが先に表示されるので、手を付けやすくなるのです。Scrapbox のようなビューを持たない手段を使っている場合は、ビューを自分でつくってください。たとえばリンクを並べて自分なりの即席リンク集をつくってください。面倒ではありますが、この一手間を加えていかないとエキサイトメントは確保できません。
エキサイトメントは広く確保すれば良いというものでもありません。やりかけのノートがたくさん並んでいると、それはそれで判断に迷ってしまって消耗します。おすすめはピン留めのイメージで常に固定しておくノート（静的なエキサイトメント）と、Date Modified のように動的に並び替えられるビュー（動的なエキサイトメント）を使い分けることです。前者、静的なエキサイトメントは、自分のキャパシティを守りたいです。筆者は 3～7 個以内に抑えています。後者、動的なエキサイトメントは定期的に、または不定期に眺めて、目についたノートに手を加える形で雑に向き合います。筆者は週に一度の振り返りを除けば、基本的に不定期に適当に眺めて、目についたノートをいじくっています。筆者にとっては、これくらいが最適なバランスと思われます。これ以上個数を広げたり、眺める頻度を増やしたりしても、かえって苦痛になります。ノートの読み書きには正解がなく、正解に向けて進めばいいという単純な世界には落とし込めません。正解がない分、毎回大量の判断や思考を必要とするので、思っている以上に疲れますし、判断に迷うと書いた通り、実際はその疲労を警戒して「そもそも手がつかなくなる」「なぜか腰が上がらない」ことがよく起きます。これを防ぐためには、静的と動的の両面に対して、自分に合った広さを想定することが肝心なのです。サステナビリティと言うと大げさですが、末永く続けるつもりで、無理のない範囲でやりましょう。

 おわりにネットワーク的なノートの世界において、どのようにタスクを読み書きしていけばいいかを紹介しました。
本説で強調したのは、タスク管理そのもののやり方や考え方というよりも、ノートのつくりかた――特に文脈をどう紡いでいくかという点です。「タスク管理じゃなくてノートテイキング（ノート取り）の話じゃないか」と思われたかもしれませんが、そのとおりです。 文芸的タスク管理は一応タスク管理といいつつも、本質はノートテイキングです。ノートをつくることで文脈が固まり、文脈が固まればタスクの自ずも固まってきます。さらに言えば、固まったタスクは、LTM ではなく通常のタスク管理ツールで管理した方が上手くいくことが多いです。
これを私は 見えてきたらさっさと行動する と捉えています。タスク管理にはタスクを決める段階と、決めたタスクをひたすら消化する段階がありますが、LTM が扱っているのは前者なのです。前者を、QoL を高めながら楽しくこなすために、自分の自分による自分のためだけのノートをつくるのです。冒頭でも LTM のメリットは文脈の尊重、目的は QoL の向上と書きましたが、後者の消化を重視する人には LTM は向いていません。
しかし、完全に向いてないかというと、そうでもなくて、文脈を尊重するからこそ消化も上手くしていけることもあります。スタンスの章でもコンテキスト（文脈）を重視するコンテキストンを取り上げました。とはいえ、慌ただしい状況下で瞬発的に次々とこなさないといけない場面ではさすがに役に立ちません。
LTM の意義は、前者の「タスクを決める段階」にフォーカスした手法であることです。元々タスク管理と呼ばれるものは後者、やると決まったタスクをいかに消化するかにフォーカスするものばかりでした。しかし現代は我々の目も肥え、水準も上がり、自律的に生きやすくなりました。こういう時代では何をどうやるかを自分で決めることもできます。いきなり決めるのは難しいですが、継続的に学びと考えを続けることで見えてきます。頭の中だけで続けるのは難しいのでノートに書きます。従来の手法でこれを行うのは困難でしたが、ネットワーク型ノートツールが出てきたことで可能になったのです。

 まとめ概要と考え方:
LTM（文芸的タスク管理）とは、文章を読み書きする営みをベースとしながらタスク管理も行うというもの
メモ、タスク、文脈を扱う
メモは一時的に素早く書いておき、あとでちゃんと処理するもの
タスクはタスクの個別詳細を書くタスクノートと、複数のタスクを俯瞰するタスクビューの両輪から扱う
文脈とはノートに書いたことのすべて。何を書き、メンテナンスしていくかは自分次第だが、それがそのまま自分という文脈になる

日々文脈を自分なりにノートに紡いでいき、「見えてきたら」タスク化して行動する。見えるまでの調査・思考・検討などの段階でノートを使うのが LTM

LTM はライティングスタックに則る
原本は頭の中ではなくノートにある。ノートが第二の脳になる

タスクが見えてきたら、あるいはノートで扱いづらい事柄（アンカバード）は、素直に別のツールに頼るのが良い
しかしノートが定着しているのなら、適切なノートにタスクリストを書いておくくらいの手間でも意外と回る
そうは言っても所詮はノートであり、できることには限度がある（アンカバード）ので、別のツールに頼ることも忘れない
極論、予定が多い人がカレンダーを使うことは避けられない、ここもノートで全部カバーしようとするのはやりすぎ

目的やポテンシャル:
LTM の目的は QoL の向上
自分のノートを読み書きすることは純粋に楽しいし、自分と深く向き合うので満足感も高くなる
ストイックに生産性や成長を追い求めるというよりは、QoL を高める営み

LTM ではノートを読み書きするための恒常的な余裕が必要
最低でも1日1時間、ノートを読み書きする余裕が恒常的に欲しい
慌ただしい場面との相性は悪い

手段:
LTM ではネットワーク型ノートツールを使う
Scrapbox のようなオンラインで出来の良いツールか、Obsidian などオフラインでも動作できるエディタか
肝心なのはノートとしてザクザク読み書きできるポテンシャルと、[ ]や[[ ]]といった記法でリンク化してノート同士を繋いでネットワーク化できる世界観

タスク管理というよりもネットワーク型ノートのノート術が重要となる
本章でもいくつかのテクニックを紹介している
例: ホーム、日付ノート、トランク、エリアとマーク、切り出し、エイリアス等