はじめに
プレーンテキストとは
タスク管理は言語で扱うものであり、読み書きの営みは避けられません。ですので読み書きに手間がかかると容易に形骸化してしてしまいます。それでも仕事の文脈なら我慢して使うでしょうが、個人タスク管理ではそこまでしないでしょう。
では、この「読み書きのしづらさ」はどうやって解消すればいいでしょうか。幸いにも先駆者がいます。プログラムコードや大量のドキュメントを扱うエンジニアです。彼らはデジタルな読み書きの考え方とツールを知っています。少しでも生産性を上げるために研鑽や工夫を惜しまない人もいます。そのような人達によって蓄積されてきた叡智があります。
この叡智は、一言でいうと プレーンテキスト(Plain Text) です。直訳すると「素のテキスト」となりますが、キーボードやタッチパネルで文字入力したときに入力される文字情報を指します。コンピュータが扱う共通言語ともなっており、プレーンテキストは PC でもスマホでもあらゆるデバイスやツールで扱うことができます。しかし、文字サイズや色やリンクといった装飾情報は含んでいません。たとえば Microsoft Word で「大きな赤色の文字」を書いたとして、これを LINE や X に貼り付けてもそのとおりにはなりません。おそらく装飾を失った、単なる文字が貼り付けられるでしょう。装飾情報はツール固有であるため、他のツールでは通用しないのです。しかし元の文字情報、プレーンテキスト部分は共通言語であるため通用します。
私たちは言葉を読み書きしますが、デジタル上で読み書きするための共通言語がプレーンテキストなのです。
小難しく書きましたが、以下二点を押さえてください。
- 1: デジタル上で読み書きを扱う際には「プレーンテキスト」を扱う
- 2: プレーンテキストとは装飾の無い、素の文字情報を指す
アナログのような柔軟タスク管理をデジタルでやるには
手帳などアナログな手段でタスク管理する人も多いと思います。デジタルの方が一般的には便利ですが、なぜあえてアナログを使うのでしょうか。
その理由の一つが 言語情報を自由自在に扱えるから です。紙面の好きな場所に書けますし、要らなければ打ち消し線を引いて潰したり、重要なタスクを目立たせたりできます。紙面やインクの許す限り、どこにでも、どのようにでも書けるのです。特別なスキルは不要で、読み書きができるのなら誰でもできます。
逆を言うと、デジタルの流儀を知り、スキルを身につければ、アナログと同じように自由自在に扱えるようになります。すでに述べたとおりデジタルには操作の早さ、修正のしやすさ、データ同期によるアクセスのしやすさといったメリットがあるのでした。つまり、アナログの専売特許だった「自由自在」を、メリットの多いデジタルにおいても実現できる ようになるのです。
そして、そのデジタルの流儀やスキルにあたる部分、その根本がプレーンテキストです。デジタルな世界ではプレーンテキストで読み書きされるので、プレーンテキストについて知ることが「自在に扱えるようになること」への近道となります。
プレーンテキストを知る
プレーンテキストによるタスク管理を始める前に、まずはプレーンテキスト自体の解説をしていきます。すでにご存知の方は読み飛ばしてください。
紙やペンを自在に使える人は多いと思いますが、なぜかというと紙やペンの仕様を知っているからです。たとえば文字を消したい場合は鉛筆(シャーペン)と消しゴムを使いますし、消す回数が少なければボールペンで済みます。あるいはボールペンでミスをしても、打ち消し線を引いたり、すぐ別にスペースに移動したりすればどうとでもなるので、紙の広さや枚数を潤沢に用意する手もあります。何らかのレイアウトがほしい方は、自分で一から線を引いてつくらなくても市販の方眼紙や日記帳が使えます――と、当たり前に聞こえるかもしれませんが、これは私たちがアナログの仕様を知っているからです。
さて、デジタルの仕様は、ここまで書いたようにプレーンテキストです。本節ではプレーンテキストの仕様を解説することで、アナログと同じように自在に使えるようになることを目指します。
はじめに
- PC 、かつ Windows を対象とします
- スマホは当てはまらないかもしれません、Mac など他の OS も当てはまらないかもしれません
- 適宜読み替えてください
- 可能ならばエディット領域を適当に用意して、動かしながら試すと良いでしょう
- 複数行入力が可能なものなら何でも構いません
- メモ帳などのテキストエディタ、ウェブサービスやウェブサイトの入力フォーム etc
- 筆者の方でも用意してみました: https://stakiran.github.io/textarea/
- 以下は解説しません
- 基本的な文字入力方法
より本格的に学びたい方は、拙作ですがこちらの書籍もおすすめします。タスク管理無関係の、執筆者向けの本ですが、プレーンテキストを知って使いこなすための解説にも力点を置いています。
行を並べる世界です
プレーンテキストは行を並べる世界です。
たとえば下記は「あああ」という行が 3 つあります。
あああ
あああ
あああ
いいい
ううう
その後、空行 と呼ばれる空の行が 1 つあって、「いいい」行があります。さらに空行を 2 つはさんで、「ううう」行があります。
このようにプレーンテキストは行から構成されます。アナログだと二次元的に縦横に自由に書き込むことができますが、プレーンテキストではできません。行を並べることしかできません。したがって、タスク管理を行う場合も「1-行 1-タスク」のようなルールで運用されることが多いです。
使える文字は様々です
プレーンテキストで扱えるのは文字だけですが、色んな文字が使えます。
ひらがな
カタカナ
漢字
空白文字 半角スペース「 」、全角スペース「 」、タブ「 」
記号類その1 (^_^) ← このように顔文字もつくれます
記号類その2 ■ ® ※ 〆 ∞ ……、「きごう」で変換すると入力できます
絵文字 ✅ 👍 💣 🐰 🚃、「うさぎ」「でんしゃ」などで変換すると(絵文字があれば)入力できます
タスク管理を行う場合、単調な見栄えにいかにアクセントをつけてわかりやすくするかは肝ですが、これらの文字を上手く工夫することになります。たとえば「ごみ捨て」タスクを終了させたい場合、以下のような書き方が考えられます。スペースで微妙に間隔を開けたり、Xも大文字だったり小文字だったりと細かいですが、どれが正解ということはなく、個人の好みとなります。
✅ごみ捨て
✅ ごみ捨て
[X] ごみ捨て
X ごみ捨て
Xごみ捨て
xごみ捨て
余談ですが、使える文字の一覧を手早く見たい方は拙作のこちらの記事も役に立つと思います: 半角英数字記号と全角英数字かなカナ記号の一覧まとめ #記号 - Qiita
保存する単位も様々です
アナログでは紙に書くだけで自動的に残りますが、プレーンテキストでは何らかの形で保存する必要があります。
PC 上で行う場合、テキストエディタで開いて、書いたものを ファイル として保存するのが最も馴染み深いでしょう。たとえば task.txt などです。この task.txt を開けば、書いたものが見えます。続きを書いて保存することもできます。
何らかのアプリを使う場合、アプリ上で書いて保存するか、あるいは自動保存されます。このとき使われる単位は様々で、たとえば以下のような名前が使われます。
- プロジェクト
- ワークスペース
- ページ
- ファイル
- ノート
- ドキュメント
タスク管理を行う場合も、この保存単位は意識することになります。ファイルで運用する場合、task.txt に全部書くのか、2024_07.txt みたいに月単位で書くのか、それとも「タスク」フォルダをつくったあとに「引っ越し.txt」「案件A.txt」みたいにタスク単位でファイルをつくるのかなど、様々考えられます。
カーソルを中心に操作します
プレーンテキストはカーソル位置から操作します。文字の入力も消去も同様です。以下に例を示します。
範囲選択してから行うコピーや貼り付けなども操作の一つです。以下に例を示します。
また行が長いテキストのどこを表示するかについても、現在カーソルが存在する位置の周辺が常に表示されます。仮に 300 行のテキストがあるとすると、おそらく画面内に表示しきるのは不可能でしょう(仮にできたとしても文字が小さくて読めません)。行末の付近を表示したいなら、カーソルを行末まで移動させる必要があります。以下に例を示します。
厳密には「表示範囲」と「カーソル位置」は別物で、カーソル位置を変えずに表示範囲だけ変えることもできます(いわゆるスクロール操作がこれです)が、何かしら操作を行うとカーソル位置まで戻ってしまいます。結局、操作はカーソル位置基点でしか行えないので、常にカーソルを移動させる必要があります。
ここまでいくつかの例を示しましたが、何が言いたいかというと プレーンテキストの操作はカーソル操作をいかに上手くやれるか にかかっています。アナログにおいて、ペンを所定の位置に素早く持っていくのはかんたんですが、デジタルでこれに相当するのがカーソルを操作することです。
タスク管理を行う場合も、当然ながらカーソルの操作は頻発します。上述した GIF は筆者による手慣れた操作であり、これくらい自在に行えるとペンのように難なく扱えます。逆に、操作がままならないと、カーソルキー(矢印キー)の連打や押しっぱなしなどで原始的に移動するくらいしかできなくなり消耗しやすいでしょう。消耗しやすいと形骸化に繋がります。
デジタル特有の操作も可能です
デジタルな手段の良い点は、アナログの制約を超えられることです。プレーンテキストの操作においても便利なものがいくつかあります。例を示します。
- 複製がかんたんに行えます
- いわゆるコピペ(コピー&ペースト)
- 検索ができます
- アナログだと人間が目で見て探す必要がありますが、デジタルだと一瞬です
- 失敗してもすぐに消せます
タスク管理では同じタスクを使いまわしたり、どこかに書いたはずのタスクを探したり、もちろん文字入力も行うので入力ミス時に修正したりもしますが、アナログのときよりもかんたんに行えます。かんたんに行えるからこそ、アナログでは実現できなかった管理も実現できようになります。たとえば人は(些細な行動やルーチンも含めれば)一日に数十ものタスクを抱えていますが、これのすべてを管理することも可能です。アナログのペンと紙で行うのは苦しいでしょう。デジタルだからこそです。
まとめ
プレーンテキストを知ると題して、プレーンテキスト自体の性質をざっと解説しました。
- 行を並べます
- 使える文字は様々です(絵文字もあります)
- 保存する単位も様々です(ファイルだけではありません)
- カーソルを中心に操作します(ので、カーソル操作に慣れることが大事です)
- 複製、検索、修正が用意などデジタルの恩恵があります。
アナログだと紙とペンという制約に引きずられますが、デジタルではこのプレーンテキストの制約に引きずられます。これらを理解しておくと、この後プレーンテキストによるタスク管理を考える際にも役に立ちます。
プレーンテキストを扱う道具を知る
続いてプレーンテキストを扱うための道具について解説していきます。こちらについても、ご存知の方は読み飛ばしてもらって構いません。なおディスプレイやキーボードといったハードウェア(デバイス)の話はしません。
まず道具は大別すると以下の 5 種類です。
- 1: 文字入力エンジン(IMEと呼ばれます)
- 2: エディットツール
- 3: ファイル形式と記法
- 4: 情報管理ツール(保存単位を扱うツールの話)
- 5: ヘルパー
1: 文字入力エンジン
IME(Input Method Editor) の名前で知られており、私たちが普段文字入力を行う際にバックグラウンドで動いているプログラムです。これがないと文字入力、特に変換は行えません。
メジャーなのは以下の 3 つです。
- MS-IME(標準)
- Google 日本語入力
- ATOK
通常、私たちが意識することはありません。何もしていなければ標準の IME が使われています。Windows なら MS-IME ですし、Mac だと「日本語入力プログラム」です(昔は「ことえり」という IME でした)。これら標準が気に入らない場合は、Google 日本語入力や ATOK を別途インストールすることになります。昔は標準 の IME は低性能、Google 日本語入力は語彙力とスピード、ATOK は変換の精度が特徴でしたが、最近ではほとんど差がなくなっています。標準の IME で問題ありません。
では、どんなときに意識するでしょうか。細かい設定やカスタマイズは奥深いので割愛しますが、よく使われるのが 辞書登録 です。たとえば「じしょ」で変換すると「辞書」という漢字を出せますが、これは「じしょ」という読みに「辞書」という漢字があらかじめ登録されているからです。これをカスタムで登録できる機能が IME にはあり、よく使う単語を登録しておくと便利なのです。
筆者の例をいくつか挙げます。
- 「だん」で「✅」
- ✅ を完了マークとして使うと便利なのでよく使います
- Done の読みで「だん」です
- 「ぼうめいたい」で「忘迷怠」
- 忘迷怠についてはすでに解説しましたが、筆者の独自用語です
- 独自用語を使っている場合、通常の変換では出せないので、このように登録しておくと便利です
- 「になって」で「担って」が 出ないようにする
- Google 日本語入力には 抑制単語機能があり、変換で出ないようにできます
- 「~になって」という言い方はよく使いますが、その度に「担って」が出てきて鬱陶しいので、出ないようにしています
2: エディットツール
入力先となるツールのことです。エディタと呼びます。
主に 3 つあります
以下のとおりです。
- テキストエディタ
- IDE
- ウェブアプリ
テキストエディタはプレーンテキストの編集に特化したエディタです。動作が軽く、オフラインでも動作します。動作面は重要であり、プレーンテキストで管理タスクを行う際にはまず考えたい選択肢です。デメリットとしては、本当にプレーンテキストを書くことしか能がないため、それ以外で不便になりやすいことです。たとえばファイルの管理を行う機能はありません。もう一つ、見た目が味気ないため、見た目を重視する人には厳しいかもしれません。
IDE は統合開発環境とも呼ばれ、元はプログラミングをこれ一つで行うための「エディタ機能も付いた多機能道具箱」でしたが、プレーンテキストを扱うのにも優れています。これを使ってタスク管理を行う人もいますし、筆者も Mac ではこれを使っています。昔は日本語の扱いに難がありましたが、今ではこれだけで書籍の執筆さえ行えるほどになりました。メリットは豊富なカスタマイズ性の高さと、検索やファイル管理などの周辺機能が充実していることです。デメリットは習熟に時間がかかることです(元はプログラマー向けのツールです)。IDE はテキストエディタと同様、PC 上でオフラインで動かすものですが、最近ではオンラインで動かせるものも出てきています。
ウェブアプリはオンライン前提で動くツール全般を指しますが、エディット機能を持つものも少なくありません。日記やブログを書くためのサービスもそうですし、X など SNS もそうなら、Slack や Teams などのビジネスチャットもある意味そうです。基本的に複数人で使うか、公開するかが前提となっていますが、非公開にしてひとりで使えばエディタとしても使えます。メリットは、現代人であればおそらく最も慣れている(本章では対象にしていませんがスマホでも使えます)ことです。デメリットは、エディタではないためテキストエディタや IDE ほど利便性には優れないことと、オンラインであるため動作の重さや接続切れといった問題が生じうることです。またデータはサービス側に保存されるため、アカウントを停止されたりサービスが終了したりするとデータも失ってしまいます。
3 つの特徴を比較
表形式で特徴を整理してみましょう。
手段 | 動作の軽さ | オフラインか | エディタのポテンシャル | 習熟のしやすさ | カスタマイズ性 |
---|---|---|---|---|---|
テキストエディタ | ⭕ | ⭕ | ⭕ | 🔺 | ⭕ |
IDE | 🔺 | 🔺 | ⭕ | ❌ | ⭕ |
ウェブアプリ | 🔺 | ❌ | ❌ | ⭕ | ❌ |
では、プレーンテキストでタスク管理を行う際のおすすめはどれでしょうか。答えると まずはテキストエディタを検討してください。IDE でも行けるなら構いません。ウェブアプリは「無い」と考えてください ――となります。
まずウェブアプリは外してください。プレーンテキストを扱うには貧弱ですし、何よりオンラインで通信が発生することが最大のネックです。オンラインという性質上、多少アプリの出来と通信回線が良くても軽微な待ち時間や接続不良はどうしても生じます。プレーンテキストをガシガシ操作している最中に、アットランダムでこれらが起きるのは本当にストレスです。たとえば数秒の遅れであっても、です。車でたとえるなら、前方の車が急にアットランダムで速度を緩めるようなものです。秒数的には大した違いにはなりませんが、イラッとする感じがわかるかと思います。ウェブアプリは、タスク管理を行う手段自体としては優秀ですが、プレーンテキストによるタスク管理の手段としては貧弱です。あえて言うなら論外です。選択肢からは外してください。
とするとテキストエディタか、IDE かになりますが、どちらでも構いません。ご自身に合うものを使ってください。ただし標準のエディタでは物足りなくなることが多いため、人気の無償エディタか、有償のエディタを使うのがおすすめです。もちろん、まずは標準のものを使ってみて、物足りなくなってから別のを試すこともできます。強引ですが家でたとえると、テキストエディタは田舎の家で、IDE は都会の家のようなものです。テキストエディタは田舎なので自分で DIY を頑張る形になりますが、小回りがききます。IDE は都会であり色んな道具やグッズやサービスを駆使して比較的手間なく工夫できますが、それらを学ぶコストはかかりますし中身もブラックボックスなので小回りがあまり利きません。どちらが合うかは人それぞれです。
各エディタの例
最後に現存するエディタの例を挙げておきます。
※なおプログラマーの方にはお馴染みのエディタ類(Vim や Emacs など)は割愛します
- 「テキストエディタ」
- 標準
- Windows ではメモ帳
- Mac ではテキストエディット
- プレーンテキストを扱う場合は、設定からフォーマットを「標準テキスト」にしておく必要があります
- 無償
- Windows では SAKURA Editor
- Mac では mi、CotEditor
- 有償
- Windows では秀丸エディタ
- 筆者は普段これを使っています
- Windows では秀丸エディタ
- 標準
- 「IDE」
- 無償
-
Visual Studio Code
- VSCode の略称で親しまれています。IDE のデファクトスタンダードです
-
Visual Studio Code
- 無償
- 「ウェブアプリ」
- チャット
- LINE、Teams、Slack
- ノート
- Notion、Google Docs、OneNote
- Wiki
- Scrapbox、esa
- ブログ
- note、はてなブログ
- SNS
- X
- BTS(バグ管理システム)
- GitHub
- チャット
テキストエディタにせよ、IDE にせよ、選択肢はあまり多くありません。エディタというジャンルは歴史が深い上に、参入も容易ではないからです。特に IDE は、2024 年現在では VSCode がデファクトスタンダードだと考えて差し支えありません。
IDE を試したいなら VSCode を試してみてください。これで挫折するなら IDE はまだ早いか、向いていません。テキストエディタにしてください。
3: ファイル形式と記法
自然言語には「英語」や「日本語」といった言語の種類があります。また日本語にも口語体や文語体、小説や技術文書、箇条書きや散文など色んな書き方があります。
プレーンテキストも同じです。具体的には ファイル形式 と 文法 があります。
ファイル形式 とは、プレーンテキストとして記載する情報をどんなファイル(の種類)で扱うかを示したものです。以下に例を挙げます。
- task.txt(テキスト形式)
- task.md(Markdown形式)
- task.json(JSON形式)
最初の txt は汎用的な形式で、たとえるなら「自然言語」のようなものです。英語でも日本語でも何でも書けます。最後の json は機械用の汎用的な形式で、たとえるなら「プログラミング言語」のようなものです。人間が通常コミュニケーションを取るためにプログラミング言語を使うことはありませんが、同様に、人間が通常テキストを読み書きする際に json を扱うことはありません。json はあくまでプログラムが情報を扱うための構造、つまりは「データ」にすぎません。プレーンテキストによるタスク管理として使うこともありません。
真ん中の md は Markdown 形式で、特定の表現をつくるために設計されたものです。これを マークアップ言語 と呼びます。たとえば「見出し」を表現するのに # 大見出し
と書きます(※1)。半角のシャープを使え、というルールです。そうすると、プログラム側でこれを読み取って、実際に大見出し(文字を大きく表示したり目次に含めたり)で表示してくれます。つまり「こういう感じで書けば、こういう感じで表示しますよ」が事前にルール化されているので、それに従って書くことで、そう表示させることができるのです。プレーンテキスト自体は素のテキストであり、装飾情報は持たないと冒頭で述べましたが、マークアップ言語はいわば 書くときはプレーンテキストで、読むときは(プログラムの力で装飾情報をつけて)読みやすく という仕組みなのです。
つまりタスク管理を行う際は、次のいずれかを使うことになります。
- 汎用的な形式 → txt
- マークアップ言語 → たとえば Markdown
次に 記法 ですが、上述した Markdown や JSON は記法です。「特定の表現をつくるために設計されたもの」がまさに記法です。つまり Markdown は Markdown 記法ですし、JSON は JSON 記法とも言えます。
ファイル形式と記法の関係ですが、記法をファイルの形で示したのがファイル形式です。Markdown 記法をファイルで示す場合、.md をつけて task.md とするのです。この .md の部分は拡張子と呼び、記法ごとに存在します。その気になれば、独自のタスク管理記法を考案して、独自の拡張子をつけることもできます。拡張子は(個人で使う分には)自由に使っていいので、たとえば筆者(sta)が独自のタスク管理記法 sta 記法なるものをつくって、task.sta としてもいいのです。
この記法がどこで役に立つかというと、テキストエディタや IDE では拡張子ごとに表示設定を変えます。txt には txt の表示設定、md には md の表示設定があるわけですね。たとえば md の表示設定では、# 大見出し
を強調表示したり、目次を自動生成したりできます。これはエディタが md の表示設定としてそのような設定を組み込んでいるからなのです。つまり、独自に sta 記法などをつくった場合でも、(エディタの表示設定を自分でつくれるのなら)独自の表示を行わせることができます。ただし、ここにはエディタの高度なカスタマイズが必要となるため、本書では割愛します。
ここまでをまとめます。
- プレーンテキストには様々な記法が存在し、記法ごとにファイル形式(拡張子)なるものがある
- ファイル形式がなぜ要るかというと、形式ごとに(拡張子ごとに)エディタが表示設定を独立させるため
- 主な記法は以下
- テキスト形式(.txt)。汎用的
- Markdown形式(.md)。マークアップ言語
- その気になれば独自記法もつくれる
タスク管理を行う場合、いずれかの記法を使うことになります。汎用的な .txt を使って好き勝手に書いてもいいですし、Markdown に従うこともできます。Markdown は文章を書く記法のデファクトスタンダードですから知っておくと何かと便利です。あるいは、自分で独自の記法を考えることもできます。ただエディタをカスタマイズして表示設定を作る部分が高度(本書でも解説しません)です。単に自分で書いて、自分で見るだけなら、.txt にて独自記法を書くだけで問題ありません。
- ※
- 1 マークアップ言語としてよく知られたのが HTML です。普段見ているウェブサイトは、HTML で書かれたものをブラウザが読み取って装飾をつけて表示したものです。HTML では大見出しは
<h1>大見出し</h1>
と書きます。いちいち囲まないといけないので、人間が書くにはたいへんです。Markdown だと#
をつけるだけで済むので、比較的楽です。そういう意味では、Markdown は軽量マークアップ言語と呼ばれることもあります。人間にとってより軽量に、かんたんに書きやすいからです。
- 1 マークアップ言語としてよく知られたのが HTML です。普段見ているウェブサイトは、HTML で書かれたものをブラウザが読み取って装飾をつけて表示したものです。HTML では大見出しは
4: 情報管理ツール
ファイルなど保存単位を扱うことを情報管理と呼ぶことにします。プレーンテキストを扱う際は、この情報管理の目線も事実上要求されます。
アプローチとしては以下があります。
- 1 使わない
- 使う
- 2 ファイラー
- 3 ウェブアプリ
1 の使わない選択肢は、保存単位内で構造をつくるということです。たとえば日単位でタスクリストをつくる形の運用がしたい場合、情報管理的に考えるなら 2024-07-30.txt のように日単位でファイルをつくろう等と考えますが、1 のアプローチはそうではなく、task.txt の中に ■2024/07/30
のようなエリアをつくろう、といった考えをします。戦略の章にて Monolith を取り上げましたが、まさにこのアプローチです。実は、プレーンテキストでタスク管理したい場合はこのアプローチがベストです。情報単位間(たとえばファイル間)を行き来するコストは高い ので、極力減らした方がいいのです。記法やエディタの使い方を工夫できれば減らせます。
2 のファイラーは、ファイルを管理するツールであるファイラーを指します。標準でも備わっており、Windows でいうエクスプローラー、Mac でいう Finder がこれにあたります。フォルダがあって、その中身を表示するウィンドウがあって――といった使い心地ですよね。あれもファイラーなのです。タスク管理では、標準のファイラーでも十分機能します。ただし運用のルールをきちんと定めることと、ルールを守るための日々の行動・メンテナンスをきちんと行うことが求められます。
仮に 1 日 1 ファイルをつくる運用にするなら 2024/07/30 になったから 2024-07-30.txt をつくる、前日のタスクリストからも転記するといった行動も自分で行わないといけません。またファイルが溜まったら整理もしたくなるでしょう。つまり ファイラーのアプローチでは整理整頓の営みから逃れられません。一方で、シンプルな運用を確立できるのなら逃れることもできます。たとえば 1 フォルダ内にすべてのファイルをフラットに置くようにすれば、整理は要りません。1 日 1 ファイルつくるとしても、年で高々 365 個ですから、実は整理など不要です。むしろ私たちは整理したがる欲求を持っており、いかに抗えるかの戦いとなります。
標準以外のファイラーもあります。前述の VSCode はファイラーの機能を持っており、VSCode の画面内でファイルの追加や削除ができます(検索もできます)。またTablacus Explorerのように、エクスプローラーよりも便利な機能とカスタマイズ性を備えた高度なツールもあります。そもそもエンジニアなど PC の玄人は、エクスプローラーのようなグラフィカルなファイラー自体を使わずコマンドで済ませており、多数の便利コマンドを駆使してファイラーと同等レベルの利便性を確保していたりもします。要はファイルを上手く運用できればそれでよく、方法は色々あるのです。
3 のウェブアプリは、PC 上にファイルを保存する以外のアプローチです。情報はクラウド上に保存され、利用者が見ることとなる単位も様々です。ページ、ノート、ドキュメントもあればプロジェクトやワークスペースといった高級な単位で扱われることもあります。
5: ヘルパー
プレーンテキストを書くことを支援するツールや仕組みが存在します。前述した IME の辞書登録もその一つですが、他にもあります。
-
Text Expansion
- たとえば
d[[
と入力すると現在日付(2024/07/30など)が挿入されます - このように「短縮語」から「スニペット」を挿入する手法です
-
d[[
が短縮語で、2024/07/30がスニペット - スニペットとして複数行の文章や、日付を始めとする動的な情報を扱うこともできる
-
- たとえば
- クリップボード履歴
- コピーした情報を複数保持し、後で利用できるようにしたもの
- 従来は専用ツールが必要でしたが、Windows 10 からは標準機能として使えます(Win + V キー)
- アウトライン
- テキストエディタの機能ですが、見出しを検出して目次をつくるものです
- 目次を見て内容全体を俯瞰したり、特定の見出しにジャンプしたりできます
- これを使いこなすにはエディタ側のカスタマイズが必要で、高度なトピックスです
- 一方で既存の文法を使うのならば、既存の設定をそのまま使えます
- たとえば VSCode で Markdown を使うと、見出しベースの目次を(自分でカスタマイズせずに)使えます
- OCR
他にも様々なヘルパーがあります。要は 一から手打ちで書いたり、原始的なスクロールなどで探したりといった手間を減らす 手段が色々あるということです。
おすすめの道具構成
ここまでを踏まえた上で、(プレーンテキストでタスク管理する際の)おすすめの道具構成を解説します。
文字入力エンジン――IME については、何でも構いません。重要なのは辞書登録であり、よく使う単語は登録しておきたいです。ただでさえプレーンテキストで見栄えに差がないため、いくつかの強調(特にタスクの終了を示す✅や[X]
のような書き方)をすぐに入力できると便利です。
エディットツールについては、テキストエディタ/IDE/ウェブアプリがありましたが、テキストエディタか IDE のいずれかにしてください。ウェブアプリは向いてない上にストレスフルです。すでに使い慣れたエディタがあるなら、それで構いません。プレーンテキスト自体はどのエディタでも編集できます。必要ならエディタを変えればいいだけですので、あまり肩ひじを張らず、自分にとって使いやすそうなものをとりあえず使えば良いです。
ファイル形式と記法については、まずは汎用的な .txt を使うと良いでしょう。記法は自分で考えれば良いのです。タスク管理は本質的に個人的なものである、とは本書の主たるメッセージですが、プレーンテキストでも例外はありません。十中八九「自分は こういう記法でこう書くのが合っている」のような癖が出てきます。.txt であればどう書いても問題ないので、まずは .txt で構いません。そのうち慣れてくると「見栄えにメリハリをつけたい」「見出しを書いて目次も出せるようにしたい」といった希望が出てきますが、そうなったら次は Markdown 記法に手を出しましょう。Markdown 記法は、学ぶのは少々大変ですが、文章を書くのに十分な能力を持っており各エディタも色んな便宜をサポートしています。Markdown に従えばこれら恩恵にあやかれます。ただし学ぶのが少々大変なので、まずは .txt で慣れるのが良いと筆者は考えます。本書でも解説はしません(拙作に譲ります or 解説記事も多いので独学も可能です)。
情報管理ツールについては、まずは Monolith 的に単一ファイルでの運用をおすすめしたいです(つまりファイラーは使わない)。それで苦しくなってきたら、別途ファイルを増やしていき、ファイルの数自体が増えてきて初めてファイル管理を考えたいです。いきなりファイル管理を考え始めても難しいので、まずは小さく始めたいのです。
ヘルパーについては、なくても困りませんので無理して使う必要はありません。あれば便利なのは間違いないので、余力があれば一つずつ勉強・試行して取り入れていくのが良いと思います。
まとめ:
- IME は何でも良い
- むしろ重要なのは辞書登録。強調を担う書き方はすぐに入力したい
- エディタはテキストエディタ or IDE のいずれか
- エディタ自体は重要ではない。どのエディタでもプレーンテキストは扱えるため
- 自分に合ったもの、合ってそうなものを使えば良い
- ファイル形式と記法は、まずは .txt を使う
- おそらく自分の癖に従った記法が出てくるので、素直に反映する
- 慣れてきて不便を感じてきたら Markdown にも手を出す
- ファイルの管理・運用はまずは考えないで、単一ファイルに全部書く、で良い
- ファイルが増えてきてから考えれば良い
- ヘルパーは無くて良いが、あれば便利なので余力があればぜひ
PTTM の基礎
ここまででプレーンテキストを扱うための基礎が整いました。ここからは プレーンテキストによるタスク管理(Plain Text based Task Management, PTTM) の話に入っていきます。
PTTM の目的は「自由自在」の獲得
プレーンテキストタスク管理(以下 PTTM)とは、プレーンテキストとエディタを用いてタスク管理を行うことです。
目的は 自由自在にタスク管理を行うこと にあります。アナログに管理している人は、紙とペンを用いて自由自在にタスク(を示した単語や文章や記号、場合によっては絵も)を扱っていると思いますが、この感じをデジタルでも行えるようにしたいのです。
タスク管理というと、特にデジタルでは煩雑な画面、画面遷移、通信や処理による表示待ちなどを伴いますが、これらは無視できないストレスになりがちです。そもそもこのようになっているのはプロジェクトタスク管理の影響で、ビジネスにも通用して、かつ多人数で管理することも成功させるためには、どうしても煩雑になってしまいます。統一感も必要(むしろ重要)ですから、皆に同じツールを使わせることにもなります。
一方で、個人タスク管理を行う場合は、そこまでは要らないことが多いです。むしろ、自分なりのタスク管理を定着させるために、いかに自分に馴染めるようなやり方や工夫ができるかを探す方がはるかに大事です。既存の、ビジネス向けのタスク管理ツールでは中々難しいことです(できるにしてもツールのやり方に私たちが無理やり適応せざるをえません)。かといって、自分でタスク管理ツールをつくるのはエンジニアでもなければ不可能ですし、エンジニアであっても多大なコストがかかるものです。
自分用の、小回りの利くタスク管理を行うにはどうすればいいのでしょうか――すでに述べたとおり、プレーンテキストをエディタで扱うようにすれば、テキストをどう書きどう回すかの部分で工夫ができます。
PTTM≒タスクリストの運用
PTTM ではどのようにタスク管理を行うでしょうか。
言ってしまうと、タスクリストの運用を工夫するだけです。工夫として用いるのが属性です。
タスクリストの中で最も有名なのは TODO リスト であり、これはタスクとして「名前」と「状態」の 2 つのみがサポートされたものですが、すぐに破綻することでも知られています。例を挙げつつ、属性を用いて工夫するという点を見ていきましょう。
TODO リストの例を一つ挙げます。
ごみ捨て
新しい冷蔵庫を調べる
✅家電量販店
通販
✅上司が前買い替えた言ってたので話聞く
コバエうるさいので対処したい
2 つほどタスクが終わっています。たぶん冷蔵庫を調べるタスクの一環として、家電量販店と上司に聞く分は終わったということでしょう。この程度ならすぐ思い出せるかもしれませんが、仕事にせよ私生活にせよ、タスク管理を続けていると、このリストはあっという間もぐちゃぐちゃになります。早ければ明日を待たずに破綻するでしょう。
そうならないためには、属性を上手く導入して、もっと上手く管理できるようにします。たとえば実行日属性を導入して、さらに毎日その日のタスクリストだけ完了させたら OK(デイリータスクリスト)とのルールも入れたとすると、以下のようになります。
■今日: 2024/07/29
ごみ捨て
新しい冷蔵庫を調べる
✅家電量販店
✅上司が前買い替えた言ってたので話聞く
通販
■2024/07/30
■2024/07/31
コバエうるさいので対処したい
■2024/08/01
コバエ対策が二日後に先送りされたことや、今日ごみ捨てをしたかったのにまだしてないことなどがわかります。通販については、新しい冷蔵庫を通販で調べたいのでしょう。おそらく退社後に調べられるでしょう。今日やるのが面倒なら、7/30(明日に先送り)や7/31(明後日に先送り)に記載を移すことで先送りできます。ごみ捨てについても、また忘れてしまわないように何らかの対策をした方がいいでしょう。これも今日やりたくないなら、たとえば明日 7/30 のところに「ごみ捨て忘れないための対策を考える」などと書いておけば、いったんは忘れずに済みます――と、このように時間軸を導入しただけでもだいぶ融通がきくようになりました。
もちろんこれは完璧には程遠いです。たとえば明日 7/30 になったら、どのように書き換えればいいのでしょうか。おそらく以下のようにするでしょうが、
■今日: 2024/07/30
ごみ捨て
新しい冷蔵庫を調べる
通販
■2024/07/31
コバエうるさいので対処したい
■2024/08/01
手作業でいちいち行うのは面倒くさいですよね。この手間をどうやって薄めるかは腕の見せ所です。我慢して受け入れるのもアリだったりします(し、日常生活の家事や仕事の雑務が泥臭いのと同様、タスク管理も泥臭いのである程度は受け入れて慣れた方が有利ではあります)。
また、7/29 に終わった「✅家電量販店」タスクと「✅上司が前買い替えた言ってたので話聞く」タスクの扱いはどうすればいいでしょうか。消せばいいのでしょうか、それとも別の場所に記録として残しておきましょうか。後者の場合、どんなファイル名で残しましょうか。たとえば普段使うファイルは tasks.txt にして、過去の記録は tasks_old.txt とでもしておいてこっちに書いておけば、とりあえずはなんとかなるでしょう。以下に例を示します。
[task.txt]
■今日: 2024/07/30
ごみ捨て
新しい冷蔵庫を調べる
通販
■2024/07/31
コバエうるさいので対処したい
■2024/08/01
[tasks_old.txt]
■2024/07/29
✅家電量販店
✅上司が前買い替えた言ってたので話聞く
これはファイル自体を分けており、情報管理(道具の項で述べた 4:)の話です。おすすめとしては「まずは単一のファイルで行う」と書きましたが、過去行ったタスクという「記録」は、あっても邪魔なので別ファイルに移した方がいいのです。
さらに言えば、今日は今日のタスクに集中するべきであって、明日以降のタスクもあまり目に入れたくない、という人もいるかもしれません。その場合は tasks.txt を today.txt、tomorrow.txt に分けて、today.txt には常に今日のタスクが並ぶようにするのもアリかもしれません。ついでに tasks_old.txt も yesterday.txt に変更すると、次のようになります。
[today.txt]
■今日: 2024/07/30
ごみ捨て
新しい冷蔵庫を調べる
通販
[tomorrow.txt]
■2024/07/31
コバエうるさいので対処したい
■2024/08/01
[yesterday.txt]
■2024/07/29
✅家電量販店
✅上司が前買い替えた言ってたので話聞く
この 3 ファイル構成は今日、明日以降、昨日以前(記録)を示しているのでわかりやすそうです。しかしファイルが分かれているので、いちいち行ったり来たりするのが面倒くさそうです。じゃあ、おすすめのとおり、1 ファイルでまとめるとしたらどうでしょうか。色んな記法がありますが、たとえば以下のように線で区切ってみましょう。
■================
■今日
■================
■2024/07/30
ごみ捨て
新しい冷蔵庫を調べる
通販
●================
●明日以降
●================
■2024/07/31
コバエうるさいので対処したい
■2024/08/01
★================
★昨日以前
★================
■2024/07/27
...
■2024/07/28
...
■2024/07/29
✅家電量販店
✅上司が前買い替えた言ってたので話聞く
いかがでしょうか。1 ファイル内なので(エディタによるカーソル操作の技術にもよりますが)操作自体は楽になったはずです。慣れるまでは見づらいかもしれません。おそらくスクロールも頻発するでしょう。上記の例では些細な工夫をしており、明日以降のタスクを見たければ「●」で検索、昨日以前の記録を見たければ「★」で検索することで、すぐ飛べるようになっています(エディタの検索機能を使います)。
もう少しお付き合いください。行数がやたら長いのを何とかできれば、もっと使いやすくなると考えたとしましょう。次のように 1 行 1 タスクで書いてみましょう。
2024/07/30 ごみ捨て
2024/07/30 新しい冷蔵庫を調べる
2024/07/30 通販
2024/07/31 コバエうるさいので対処したい
2024/08/01
2024/07/29 ✅家電量販店
2024/07/29 ✅上司が前買い替えた言ってたので話聞く
ずいぶんとスッキリしましたね。一見すると良さそうですが、タスクごとに日付がついているため、先送りが非常に面倒くさいです。いちいち 2024/07/30
のような日付を手で書かないといけません。逆に、これ以前の例で見てきたやり方は、タスク自体を別の行に移すだけで日付を変更できていたので便利だったのです。折衷案として、ヘルパーの Text Expansion を使うと、たとえば d[[
と打って 2024/07/30
が入力される、のようなことができるのでほんの少し楽できます。
例はこのくらいにしておきましょう。
属性とファイルの分け方を工夫することで自分なりに運用していく、とのエッセンスを感じていただけましたら幸いです。これが PTTM です。
冒頭でも述べたとおり、PTTM も所詮はタスクリストを運用するだけです。ただし属性とファイルの分け方を工夫することで、何とか上手くいくように模索します。正解はありません。その人にあったやり方というものがあります。別の言い方をすると、あなたに合ったやり方はあなたにしかわからず、したがって自分で模索していくこととなります。模索という営みに耐えられない方は、PTTM からは回れ右しましょう。
先人の実践例
参考までに、PTTM を実践されていると思しき方の記事やページをいくつか紹介しておきます。PTTM からして筆者の造語であるため、事例を探すのは容易ではないですが、プレーンテキスト タスク管理
などで検索すると少しは見つかります。
眺めてみると本当に人それぞれだなとわかります。todo.txt というフレームワークを用いたものもあれば、-
と x
を使うシンプルなものもありますし、Markdown に頼っているものもありますね。
おわりに
基礎編は以上です。これだけでも自分なりに PTTM を始めることができるはずです。
とはいえ、PTTM には先人の知恵が色々とあります。次節では「設計」と題して、ご自身の PTTM を考える上で役立つ「よく知られたテクニックや考え方」を紹介していきます。
PTTM の設計
自分なりの PTTM を設計する際に役立つヒントを紹介します。
原則
PTTM の管理範囲を決める
Ans: PTTM としてどこまでをタスク管理するかを定めます。
生活や仕事のすべてを管理する必要はありません(もちろんしても OK です)。たとえば複数持つ仕事のうち、A案件だけを PTTM で管理してみようといったスモールスタートも可能です。
管理範囲を決めておかないと迷いが生じるので、さっさと決めてしまうことをおすすめします。選択肢は事実上二つで、特定の対象だけを管理するか、生活のすべてを管理するかの二択です。筆者としては後者をおすすめします。というのも、個人タスク管理では、たいてい複数の役割や文脈をまたいだ検討が必要となるからです。仕事中にプライベートのタスクを少し微調整したい(逆も然り)、なんてこともよくあります。もちろん(特に)仕事とプライベートは、仕事側が機密的であるため安直にいっしょくたにはできないかもしれませんが、それでもなるべくいっしょくたに扱うことを目指してみてください。少し脱線しますが、ワークライフバランスにおいても、近年では仕事と生活をしっかり分けるのはむしろ難しくて、両者の境界はもっと曖昧だよね、もっと融通利かせた生き方ができるといいよねとする考え方が出てきています(ワークインライフやワークアズライフ)が、タスク管理も同じです。境界が曖昧なので、なるべく全部を管理してしまった方が融通が利きます。おそらく大半の労働者は(組織の一員として)機密性が要求されますので、仕事用とプライベート用の二つの PTTM を回すことになるでしょう。
動線化する
Ans: PTTM で使うプレーンテキストファイルは、毎日頻繁に使う場所にします。
動線については前の章で解説しましたが、毎日頻繁に通る場所を指します。このような場所があれば頻繁に目に入るので、忘れることなく対処やメンテナンスができます。あるいは忘れていても、見れば思い出せます。
PTTM ではテキスト(として書いたタスク)を頻繁に読み書きするため、動線化は必須です。RSAFサイクルを取り入れたいです。面倒くさいと考えるのではなく、面倒と感じないほど手になじませたいのです。正直言うと、この動線化が定着するかどうかが PTTM の成功の分かれ目とさえ考えます。
誰にも見せない
Ans: PTTM の中身はプライベートなものであるため、誰にも見せてはいけません。
個人タスク管理が形骸化する主因の一つは「恥ずかしいから」です。誰かに見られたり、見せてなくても見られる可能性があったりすると、心理的にセーブがかかって 一部のタスクを書かなくなります。たとえばアダルトな営みに関するタスク、セクシャルマイノリティに関する手術、障害に関する通院や調査、現職や家庭には伏せておきたい転職活動などは、慣れていないと本人自身も恥ずかしくてタスク化(つまりタスクとしてテキストにおこす)できないものです。書くタスクと書かないタスクがあればあるほど、タスク管理は形骸化します。何を書くか書かないかの判断に認知コストを費やすのと、人間は元来面倒くさがりですから書かない側の自分に寄ってしまってサボってしまうためです。
この恥ずかしさのリスクを潰せている状態を 管理的安全性 と呼ばせてください。管理的安全性は極限まで確保したいです。誰かに見せない、見られないようにするのはもちろん、潜在的に見られる可能性も極力潰してください。そのような環境が無いのなら、何とかしてつくってください。特にありがちなのは、職場など複数人で過ごすことが当たり前の環境において PTTM を始める場合で、同僚などから「何してるの?」的なツッコミがよく入ります。これでは管理的安全性などあったものではありません。初期のうちは適当にごまかして、さっさと慣れてもらうのが良いでしょう。慣れてもらって「そういうキャラ」と定着すれば、もう深入りはされなくなりいたずらに覗き込まれたり注目されたりすることも減るでしょう。
PTTM の管理対象を決める
Ans: PTTM はテキストを書くため割と何でも扱えますが、何を扱うか(というより 何を扱わないか)は決めた方が良いです。
PTTM はテキストを書くため、その気になればタスクに限らず割と何でも管理できますが、向いていないこともあります。たとえば予定はカレンダーで管理した方がやりやすそうですし、だらだらと日記や思考を書いてもいたずらに時間を使うばかりで(タスク管理としては)あまり意味がないどころか情報量的に圧迫されてしまって読み返しづらくなります。読み返しがなくなると形骸化につながります。要するに何でも扱おうとすると破綻します。
なんだか上手くいかないという場合は、まずは何でも扱いすぎてないかを疑ってください。PTTM はプレーンテキストゆえに紙面上は無限に書けますが、これを使う人間側の認知能力が限られているので、自分のタスク管理に本当に必要なものをシンプルに扱うことを心がけてください。
PTTM で扱うべきではないものについては後述します。
振り返りを行う
Ans: PTTM はテキストの読み書きとメンテナンスを行うものなので、振り返りの習慣が身についていると強いです。
PTTM では残タスクの確認、明日以降のタスクの確認、終わったタスクの反映(完了にする)、その他タスクリストの軽微な修正――このような確認やメンテナンスを頻繁に行います。特に日をまたいだタイミングではメンテナンスの量も増えがちですし、週や月といった単位で俯瞰して反省したり今後を検討したりといったことも必要でしょう。振り返りの章でも DWMY、Day/Week/Month/Yearの頻度が存在することを述べました。定期的に振り返りを行って、メンテナンスにあてることをおすすめします。というより、振り返りの形で確保しないと中々メンテナンスできず、メンテナンスできないと形骸化に繋がります。
部屋やデスクも散らかりすぎると収拾がつかなくなるため、たまには掃除するわけですが、PTTM でも必要です。PTTM として普段使っているテキストを健全に保つためのメンテナンスを、こまめに行う必要があるのです。その機会を捻出するのが振り返りです。
詳細は振り返りの章を参照してください。
3 秒の壁を突破する
Ans: 新しいタスクを追加したい場合、3 秒以内に追加することを目指してください。
今現在忙しいときに、今すぐというわけではないが後でやっておきたい or やらねばならないタスクが発生したとします。どうすればいいでしょうか。PTTM を行っている場合、正解は「そのタスクをささっとメモしておく」です。メモしておけば、あとで見返したときに処理できるからです。私たちは記憶能力を過大評価しがちで「いやまあ忘れないでしょ」とメモするのを怠けがちですが、それで忘れないなら苦労はしません。忘れます。忘れないためには、その場でメモを完了させることが必要です(※1)。
筆者としては、一つの目安として 3 秒を掲げています。3 秒以内にメモを取れる(メモの完了ではなく開始、つまり書き始めるまでの話です)ことを目指してください。これができるくらい素早くメモが取れるなら、あなたの PTTM は手に馴染んでいます。逆に、3 秒以内にできないとしたら、まだ馴染んでいません。馴染んでいない手法やツールを使い続けるのは苦行なので、そのうち形骸化してしまうかもしれません。タスク管理は、特に PTTM はちょっとしたサボりが肥大化していって形骸化に繋がるのですが、この「さっさとメモしておく」場面は、サボりやすい場面の筆頭です。これを凌げるかどうかは PTTM 定着の目安であり、凌ぐためには 3 秒くらいでササッとこなせるくらいの軽さが要ると思います。これ以上かかってしまうと「面倒くさい」が勝ってしまい、サボります。
秒数にこだわりはなく、人によっては 5 秒でも 10 秒でも良いですが、ニュアンスとしてはできるだけ早く、それも「ササッと」のレベルで手間も感じず、息するように行えるレベルだと強調したいです。それくらい手に馴染んでようやく定着するものだと感じるからです。そういうわけで、3 秒の壁はぜひ壊してみてください。壊すための工夫は惜しまないでください。
- ※
- 1 この素早さが最も必要なのは、ナレッジワーカーやクリエイターと呼ばれるような創造的な人達だと筆者は考えます。アイデアをメモするためです。アイデアはいつ湧くかわかりませんし、湧いたときにメモして捉えなければ未来永劫忘れます。アイデアの重要性は言うまでもないと思いますが、メモができないとその重要なものを逃してしまうのです。メモについてはメモの章もあるので参照してください。
扱わないもの
オルタスクは扱わない
Ans: オルタスク は直接扱わず、別のツールで扱います。
第 3 部では「タスクのようでタスクでないもの」としてオルタスクを紹介しました。コンテナ、イベント、モットー、メモ、タスクソースがあります。これらを PTTM で扱おうとしても分が悪いため、各章で述べたような専用のやり方やツールを使いましょう。
ただし PTTM にて限定的に扱えることはあります。コンテナは見出し表記などで区切る形で実現できます。■2024/07/30
のように日単位で時系列的に区切る例はすでに示しました。また、以下のようにインデント(字下げ)を用いれば階層的な表現もできます。いくつか例を示します。
■引っ越しエリア(2スペースでインデント)
引っ越し
引越し先の検討
北海道を調べる
地元を調べる
都内で家賃安いエリアをもう一度調べたい
全体スケジュール
梱包や粗大ごみとか
自転車要らないので捨てたい
冷蔵庫買い替えておきたい
(まだ洗い出し途中。。。)
■引っ越しエリア(2スペースでインデント + 先頭に`・`もつけた)
・引っ越し
・引越し先の検討
・北海道を調べる
・地元を調べる
・都内で家賃安いエリアをもう一度調べたい
・全体スケジュール
・梱包や粗大ごみとか
・自転車要らないので捨てたい
・冷蔵庫買い替えておきたい
・(まだ洗い出し途中。。。)
■引っ越しエリア(Markdownのリスト表記)
- 引っ越し
- 引越し先の検討
- 北海道を調べる
- 地元を調べる
- 都内で家賃安いエリアをもう一度調べたい
- 全体スケジュール
- 梱包や粗大ごみとか
- 自転車要らないので捨てたい
- 冷蔵庫買い替えておきたい
- (まだ洗い出し途中。。。)
またメモについては、むしろ普段 PTTM を行っているファイルに直接書くのが最も自然です。しかしメモが溜まると処理が苦しくなるので、振り返りを日単位以上の高頻度に行って、溜めずに処理していく(別のツールに移すなりタスクとして書き直すなり)べきです。PTTM が使えない場面(外出先でスマホしかなく PC が使えない等)であれば、別の手段でメモしましょう。後で忘れないように、PTTM 側に「スマホに書いたメモを回収する」のようなタスクを入れておくとさらにグッドです。
ルーチンタスクは扱わない
Ans: ルーチンタスク についても、別のツールで管理します。
定期的に行うタスクを本書ではルーチンタスクと呼んでいますが、このルーチンタスクも PTTM で管理するのは厳しいです。たとえば毎週火曜日と金曜日に可燃ごみのゴミ捨てを行いたい場合、毎日、一日の最初(あるいは前日の最後)に火曜日もしくは金曜日であることを確認して、もしそうなら「可燃ごみ」タスクを追加する(あるいは常に追加した後、火金以外なら削除する)作業が必要です。非常に面倒くさいでしょうし、ルーチンタスクは他にも多数あります。やってられません。ルーチンタスクは、専用のツールで管理しましょう。
概念
デイリータスクリストを導入する
Ans: デイリータスクリスト(今日やることリスト)はぜひとも導入したいです。
戦略の章にて Dailer を取り上げましたが、タスクリストを日単位で区切る営みはぜひとも導入したいです。たとえば今日が 2024/07/31 なら ■2024/07/31
のようにして今日のエリアを設けて、今日はここに書いてあるタスクだけを終わらせたら OK とするのです。明日になったら ■2024/08/01
を今日エリアにします。こうすることで「今日はここまでやればいい」とのメリハリがつきます。人は終わりを設けてメリハリをつけないとガス欠しちゃいますので、この考え方はぜひともおすすめしたいです。
「曖昧な日付感」を導入する
Ans: 2024/07/31、2024/08/01 のような分け方よりも「今日」「明日以降」の方がシンプルです。
日単位でタスクを区切る際、どのように分けるかに悩まれるかもしれませんが、主に 2 つのやり方があります。
- 2024/07/31、2024/08/01、2024/08/02 など日付ごとに分ける
- 今日、明日以降、来週以降など意味的に分ける
日付ごとに分ける場合、見やすいですがメンテナンスが大変です。まだ書いてない日付の区切り(たとえば ■2024/08/25
のような文字列)を書く手間もありますし、おそらく「今日」は一番上に表示させたいですから、毎日今日に相当する部分を一番上に移動させる手間も生じます。
意味的に分ける場合、メンテナンスはある程度端折れますが、正確な日付(実行日)がわからず後回しにされがち――つまりはタスクが溜まりがちです。
可能なら日付ベースをおすすめしますが、メンテナンスが大変で挫折してしまっては元も子もありません。メンテナンスを軽くしたい場合は、意味ベースが良いでしょう。日付の扱いが曖昧ということで、タイトルは「曖昧な日付感」としています。
以下に 2 つのやり方で書いたものをそれぞれ挙げてみます(中身は ChatGPT で生成)。比較してみてください。
日付ベース
■2024/07/31
- プレゼン準備
- 開発環境設定
- 進捗報告
■2024/08/01
- ユーザーテスト
- バグ修正
- 仕様書更新
- チーム会議
- 新機能のアイデア出し
■2024/08/02
- プロジェクト計画見直し
- チームブレインストーミング
- プレゼン発表
- クライアントのフィードバック確認
- バグ修正
意味ベース(曖昧な日付感)
■今日
- プレゼン準備
- 開発環境設定
- 進捗報告
■明日以降
- ユーザーテスト
- バグ修正
- 仕様書更新
- チーム会議
- 新機能のアイデア出し
- プロジェクト計画見直し
- チームブレインストーミング
- プレゼン発表
- クライアントのフィードバック確認
- バグ修正
日付ベースの場合、2024/07/31 のように日単位で区切る他に、週で区切ったり月単位で区切ったりすることもできます。日単位よりはメンテナンスが楽になります。日報ならぬ週報や月報のイメージです。その分、いつどのタスクを行うかという日レベルの正確性も損なわれます。
意味ベースの場合、空行や区切り線などを工夫すれば「時期的な広がり」を持たせることができます。たとえば以下は空行が多いほど離れていることを示したものです。
■明日以降
- ユーザーテスト
- バグ修正
- 仕様書更新
- チーム会議
- 新機能のアイデア出し
- プロジェクト計画見直し
- チームブレインストーミング
- プレゼン発表
- クライアントのフィードバック確認
- バグ修正
1行離れていると1日分、2行離れていると2日分のように対応させてもいいですし、1行だと明日中/2行だと今週/3行以上は直近じゃなくても大丈夫を意味する、などにしても良いでしょう。何ならもっと雑に、感覚的に扱ってもいいです。空行だと縦長になるのが嫌であれば、以下のように区切り線の数(|
を使いましたが-
や=
でも構いません)で表すこともできます。
■明日以降
- ユーザーテスト
- バグ修正
|
- 仕様書更新
- チーム会議
||
- 新機能のアイデア出し
- プロジェクト計画見直し
- チームブレインストーミング
|||
- プレゼン発表
|
- クライアントのフィードバック確認
- バグ修正
フォーマットを統一する
Ans: PTTM において見やすさは重要で、その見やすさを確保するのがフォーマットです。
PTTM はプレーンテキスト――つまりは文字情報ばかりを扱うため、動画や絵や図表と比べると見づらいです。仮に読書好きや活字中毒者がいたとしても、「自分が書いた、タスクに関するテキスト」は味気なくてつまらないため、やはり見づらく感じます。この見づらいテキストと毎日毎日向き合うことになるのですが、ここで挫けてしまう方も見受けられます。少しでも見づらさを減らして負担を減らしていくべきです。
そのために行えるのがフォーマットの統一です。正解はありませんが、こんなレイアウトで書こう、こんな記法で書こう、というのを自分なりに決めて、守るようにします。すでにここまで見てきた例でも、日単位のエリアは ■2024/07/31
のように ■
を使ってきましたし、一つのタスクは一行で書いてますし、タスクを表す場合に-
や・
をつけたりもしています。こんな感じで、どういうときにどんな風に書くかを統一するのです。
統一したフォーマットに従うことは、最初は苦しいかもしれませんが、そのうち慣れてきます。目が慣れてくると文字が滑らず、素早く読めるようになります。PTTM を続けたいなら絶対にやっておきたい投資です。
ちなみにフォーマットは自分で一から考える必要はありません。Markdown のような既存の文法に頼るのもいいですし、先人の実践例など他の人が使われているものをパクってもいいです。それで済むならしめたものです。人によっては、いまいち納得がいかなくて、自分で模索したくなることがあります。その場合はとことん試行錯誤しましょう。模索していくうちに愛着が湧いてきます。この、自分でつくりあげていくときに湧いてくる愛着は、挫折しがちな PTTM のモチベーションを支えてくれます。
スペースは半角で統一する
Ans: スペースで空白を開ける場面は多いですが、半角スペースで統一したいです。
箇条書きでタスクを階層的に並べたり、空白を入れて見た目を微調整したり、とスペースを使う場面は多いです。このスペース、半角スペース「
」と全角スペース「
」がありますが、前者の半角スペースを常に使うことをおすすめします。全角スペースは百害あって一利なし――は言い過ぎですが、デジタルの世界では何かとトラブルになりがちなものの一つです。プレーンテキストを扱う際も例外ではありません。少なくとも検索時にスペースの可能性が二種類あると検索しづらいですし、エディタの機能でインデントをまとめて上げ下げする(以下例)際も全角だと行われない、など地味に不便を被ります。
全角分のスペースが欲しいなら半角スペースを複数回使えばいいですし、小説など特殊な場合に例外的に入力したくなったら Shift キーを押しながらスペースキーを押すことで全角になります(Google 日本語入力の場合)。
常に半角スペースを使うには設定が必要です。詳しくは IME の設定画面を探してください。検索してもすぐに見つかると思います。ちなみに Mac の標準の IME ではかんたんにはできないようです。
まとめ
- PTTM
- プレーンテキストによるタスク管理
- アナログで紙とペンで自由自在に書くように、デジタルでも自由自在に書いてタスク管理したい
- そのためにはデジタルのお作法「プレーンテキスト」を踏まえる必要がある
- 使う道具
- IME、エディタ、ファイル形式・記法、情報管理(≒ファイル管理)、ヘルパーの 5 つ
- まずは標準のIME、テキストエディタ or IDE、.txt、単一ファイルがおすすめ
- ヘルパーは最悪なくてもいいが、あればあるだけ便利になる
- PTTM の設計
- 本章の原則や先人の事例を参考にして、自分なりに模索する
- 模索という営みからは逃れられない
- メンテナンスからも逃れられない
- プレーンテキストの読み書きはずっと続く
- 息するようにこなせるようになりたい
- なれたら定着するし、なれないとおそらく挫折する