Go to Qiita Advent Calendar 2024 Top
LoginSignup
21
21

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

@sta

プレーンテキストによるタスク管理が捗る HERP

Last updated at Posted at 2019-11-15

はじめに

タスク管理はプレーンテキスト + テキストエディタベースで行うこともできる。これを「プレーンテキストによるタスク管理(PlainText Task Management、長いので pttm と略します )」と呼ぶことにする。

本記事について

本記事では、pttm が捗るかもしれない考え方やテクニックを雑多に紹介する。既に pttm をしている人、あるいはこれからやろうとしている人の参考になれば幸いである。

紹介内容は HERP - Home/Editable/Reachable/Personal という四つの観点で分けている。各観点毎に考え方やテクニックを雑多に書いていく。

考え方やテクニックについては、たとえば以下がある。

  • タスクの扱い方、捉え方、分け方
  • タスクの書き方
    • フォーマット
    • ネーミング
    • ……
  • 効率良くタスクを CRUD するための操作方法やアイデア
    • エディタの使い方
    • エディタの機能
    • エディタの設定
    • 外部ツールの利用や連携方法
    • ……

早い話、エディタ操作レベルのテクニックから「タスクとはこう扱うと良い」的な考え方まで多岐に渡る。

本記事で言及する「エディタ」について

筆者が秀丸エディタを使っていることもあり、もっぱら「国産テキストエディタ」を想定している。

例:

  • 秀丸エディタ
  • SAKURA Editor
  • EmEditor
  • Notepad++
  • mi(Mac)
  • ……

Vim/Emacs のようなエディタ派、VSCode/Atom のような IDE 派、あるいはクラウドのエディタツールを使っている人などは適宜読み替えてほしい。

本記事で使う記号

  • 太字 特に重要だと思う箇所
  • :pencil: 割と重要だと思う補足説明
  • :o: メリット
  • :x: デメリット

HERP とは

今回紹介する HERP という観点について、簡単にまとめる。

項目 説明
Home タスクリストが自分のホーム(行動の基点)になっている
Editable テキストエディタだけで完結する
Reachable ホームからすべてのタスクを辿れる(ホームを見て従えば全部まわる)
Personal 個人的なものである(誰かに見られることや共有することは想定してない)

Home

タスクリストが自分のホーム(行動の基点)になっていること。

  • スマホのホーム画面のように 最初に見る場所 をつくる
  • ホームにタスクを書き並べるのが基本で、収まらないものは適宜ゾーニングする(別の場所に移す)
  • なぜホームが必要？ → 二重管理せずに済むから
    • 「ホームさえ見ておけば良い」になる
    • 「とりあえずホームに書いておけば良い」になる

Editable

pttm が愛用テキストエディタ一つだけで完結すること。

  • pttm は 文章執筆やプログラミングのようにタスクをバリバリ書くもの
  • バリバリ書くには？ → 使い慣れたテキストエディタがベスト
  • エディタの設定や拡張機能はフル活用して少しでも書きやすく、見易く、使いやすく

Reachable

ホームからすべてのタスクを辿れる(ホームに従っておけば生活が全部まわる)こと。

  • タスクすべてをホームに書いて運用するのは無理
  • どうするか？ → 二段構えにする
    • a) 別の場所に書いておく
    • b) ホームから辿れるようにする
  • a) の別の場所に書いておくだけだと読めない・読まない・読みづらいので、b) でホームから明示的に誘導する・アクセスしやすくする必要がある

Personal

書いた内容が個人的なものであること。

  • 個人的である = 誰かに見られることや共有することを想定していない
  • 人目を気にして書くのは（表現を練る分）疲れるが、個人的な内容なら気にする必要がなく疲れにくい
  • 個人的なことも積極的にタスク化すると、pttm で管理できる範囲も広がる
    • Before: 仕事に必要な TODO のみ管理
    • After: 個人的な行動や振り返りのための記録など

HERP 詳細

ここからは HERP の各観点について、その観点に関するネタをまとめていく。言い換えると、以下のような構造で書く。

  • H(Home)
    • Home に関するネタ
    • Home に関するネタ
    • ……
  • E(Editable)
    • Editable に関するネタ
    • Editable に関するネタ
    • ……
  • ……

Home

タスクリストが自分のホーム(行動の基点)になっていること。

サマリー:

  • タスクはホーム(一つのテキストファイル)に集め、これを常時メンテするように
  • ホームに書ききれないものはゾーニング(別の役割を持つリストに移す)
  • タスクはフォーマットを定めると扱いやすくなる
    • かなり奥が深い

Home > ホームファイルをつくる

ホームファイルとはホームを表現した 一つのテキストファイル。

ファイルは何でも良い。たとえば:

  • デスクトップに home.txt
  • D:\todo.md
  • ……

運用について:

  • 一日のはじまりにこれを開いて、常にこれ見ながら＆メンテしながら日々過ごす
    • とりあえずここを見る
    • とりあえずここに書いておく
  • ホームファイルは日中常に開いておく or ワンタッチで開けるようにしておく
    • 「視線移動」「ウィンドウをアクティブにする」「開いてるタブを選ぶ」以上のコストは避けたい
    • これ以上のコストがかかると、ホームファイルを開く心理的ハードルが高くなる → 怠ける

PC 利用への特化について:

  • 「クラウドで連携してスマホからも読めるようにする」等は考えない
    • これのために PC 上での使いやすさ・書きやすさ・見やすさが犠牲になるケースが多い
  • 自分が使ってる PC 上（もっというと愛用テキストエディタ上）で使いやすく、見易く、書きやすくすることが第一

Home > ゾーニングする

ゾーン(Zone)とは:

  • 特定の用途や性質を持つタスクを集めた場所
  • ゾーンをつくったりメンテしたりすることを ゾーニング という

なぜゾーニングが必要か:

  • ごちゃごちゃしてすぐに破綻するから
    • ホームにただタスクを書き殴るのはありがちだがアンチパターン
    • 住まいは部屋や収納で仕切るし、プログラミングでは関数化・クラス化・モジュール化などを行う
    • pttm でも同様のアプローチを使うべき。その一例がゾーニング

Home > ゾーニングする > 二種類のゾーニング

ゾーニングの実現方法は二種類ある。

  • インゾーニング
    • ホーム内でゾーニング
    • ホームの中に複数のゾーンを儲ける
  • アウトゾーニング
    • ファイル外にゾーニング
    • 別ファイルにゾーンを切り出す

例として「今日やる」「やった」「明日以降やる」「メモ」の 4 ゾーンについて、それぞれどう表現するかを見てみる。

インゾーニングだと、たとえばこうなる。

tasklist.md

# メモ
……
……
……

# 今日やる
……
……
……

# やった
……
……
……

# 明日以降やる
……
……
……

ただし「各タスクがどのゾーンに属しているか」を表す書き方はいくつかある。上記は「見出し配下に書く」だが、もう一つ、「タグとして付与する」もある。以下に例を示す。

tasklist.md

[メモ] ……
[メモ] ……
[メモ] ……
[今日やる] ……
[今日やる] ……
[今日やる] ……
[やった] ……
[やった]……
[やった]……
[明日以降やる] ……
[明日以降やる] ……
[明日以降やる] ……

話を元に戻す。続いてアウトゾーニング。

アウトゾーニングだと、たとえばこうなる。

tasklist_today_todo.md

# 今日やる
……
……
……

tasklist_done.md

# やった
……
……
……

tasklist_tomorrow.md

# 明日以降やる
……
……
……

memo.md

# メモ
……
……
……

Home > ゾーニングする > 二種類のゾーニング > コツ

インゾーニングのコツ:

  • エディタの機能で ゾーンを塊として扱えるようにする のが基本
    • アウトライン、シンボル、ファンクションリスト etc
  • 各ゾーンにはなるべく一瞬でアクセスしたい
    • 例1: 「キー一発で前後のゾーンにジャンプ」系の操作を実現する(見出し単位の移動、関数単位の移動 etc)
    • 例2: ●今日やる 的な記法を決め、移動時は ● で検索する

アウトゾーニングのコツ:

  • 各ゾーンは a) 最初から開いておくか、 b) 素早く開けるようにするか
  • a) 最初から開いておく案
    • タブで開く、分割ウィンドウで開くなど
    • キー一発(たとえば Alt + Left/Right)で前後タブや前後分割領域に移動 ← これくらいの素早さが欲しい
    • Ctrl + 1 で 1 番目のタブを開く ← こういう系でもいい
  • b) 素早く開けるようにする案
    • エディタのブックマーク機能
    • エディタのファイル履歴機能
    • エディタではないがプログラムランチャで(私は AutoHotkey + fenrir を使っている)

インゾーニングとアウトゾーニングはどちらが良い？:

  • 個人の好み
    • このゾーンはファイル内がいい、このゾーンは別ファイルでいい ← こういうフィーリングに素直に従うと上手くいきやすい
    • :pencil: というかタスク管理は個人の好みを突き詰めるものなので、自分がやりやすい・やりづらいと感じたことは素直に反映していくのが吉
  • ただし頻繁にゾーンをつくる・消す人はファイル内(インゾーニング)が良い
    • というかファイル外(アウトゾーニング)だとファイル操作が入るので面倒くさいと思う
    • でも人によっては「インよりアウトの方が楽」という人もいるかも
    • まあやりやすい方で

Home > ゾーニングする > 主なゾーン

よく使われるゾーン。

  • 今日やるゾーン
  • 明日以降やるゾーン
  • xx月xx日にやるゾーン
  • 気になることゾーン(インボックス)
    • 気になることをとりあえず書いておく
    • 書く時は書くだけ（十数秒以内でさっさと書く）、その場で検討や整理はしない
    • 検討や整理はあとでやる
    • いわゆる インボックス と呼ばれる概念
  • 予定ゾーン(カレンダー)
    • 何月何日何時にどこで何がある、系のネタ
    • よほど物好きでなければ普通にカレンダーで良い
  • ネタゾーン
    • ブログネタ、開発ネタ、ツイートネタ……
  • 日記・つぶやきゾーン
    • 感情の吐き出し場所
    • 吐き出すだけで楽になるし、衝動的に他人にぶつけてしまうのも防げる
    • 蓄積すれば、後で振り返られる
    • ローカル一人ツイッターと言うとわかりやすいかも？

特に「xx月xx日にやるゾーン」の運用は 日間割 と呼び、非常に重要な概念となっている。少し詳しく。

日間割では日単位でゾーンを設け、かつ「今日は今日の日ゾーンに書いてあるタスクを全部潰す」ことを心がける。こうすることで「今日は今日の日ゾーンのタスクだけ終わらせれば良い」と目標が明確になるし、それ以外のタスクは「この日に置いておこう」「とりあえず 11 日後に考えてみるか」といったように 未来への配置(先送り) もできる。タスク管理がグンと楽になる。

Home > フォーマットを設計する

タスクはある程度フォーマットを定めた方が管理しやすい。なぜ？:

  • 読みやすいから
  • シンタックスハイライトで強調できるから
  • 書き方に迷いがなくなり、管理しやすくなるから
  • フィルタリングや分類がしやすくなるから

フォーマット設計の指針:

  • 一行一タスク にはとりあえず従っておく
  • 一タスクの書き方については、a) フリーフォーマット派か、b) フォーマット定める派か
  • a) フリーフォーマット派
    • お好きなように書いてください
    • フリーフォーマットで成立するならそれで良い
    • よほど扱うタスクが少ない or 頭の処理能力凄い、じゃないと成立しないと思うが……
  • b) フォーマット定める派
    • フォーマットの設計 ≒ 属性 の設計
    • 必要な属性の有無と順序を明らかにする
    • どんなフォーマットが良いかは人それぞれ

Home > フォーマットを設計する > 主な属性

フォーマットの設計に役立ちそうな、主な属性を取り上げておく。

  • タスクの名前
    • これは必須属性かと思う
  • タスクの詳細
    • タスク名は簡潔にして、この詳細欄に詳しい内容を書くという運用
    • pttm では「タスクの名前」にこの属性も兼務させるのが定石
  • 状態
    • 未完了 or 終了済の二値
    • :o: 「終わったもの」と「終わってないもの」を視覚的に区別できる
  • 実行日
    • いつやるか
    • :o: この属性があると時間割ならぬ日間割としてタスクを操作(配置)できる
  • 発生日・完了日
    • そのタスクが発生(記入)した日と、そのタスクを完了した日
    • :o: どのタスクをいつ完了したかというログが残る
    • :o: 発生日基点で「このタスク当分手を付けてないな」が可視化される
  • 優先度
    • タスクの優先度
    • 案1: A, B, ... などアルファベットや数字で付ける
    • 案2: 上に書いた行ほど優先度を高くする
    • :o: 多数のタスクに対して、あまり迷わずに消化していけるようになる
  • 階層関係(サブタスク)
    • タスクの依存関係や包含関係
    • 例: タスク A はサブタスク B, C, D から成る
    • pttm ではインデントで書く
    • :o: タスクを俯瞰しやすい・進捗がわかりやすい（6個中3個終わってる etc）
    • :o: タスクに取り組みやすい（サブタスクが洗ってあると行動しやすい）
  • スター
    • 付ける or 付けないの二値
    • :o: とりあえず目立たせたいものにつけておく（簡単に扱える）
  • ラベル
    • タスクを分類するためのタグ
    • 呼び名は色々ある。たとえばカテゴリ、タグ、プロジェクト、コンテキスト etc
    • :o: 大量のタスクから必要タスクのみ抽出(検索)するのに重宝する
  • 見積時間
    • そのタスクを終えるのに要する時間
    • :o: 「今日のタスクリスト全部終えるのにあと n 分」といった計算(生活の見積もり)ができる
    • 運用が非常に手間
  • 開始時間・終了時間
    • そのタスクを開始した時刻・終了した時刻
    • :o: 「このタスクをこの日のこの時間に終えた」というログを残せる
    • 運用が非常に手間

Home > フォーマットを設計する > 属性との付き合い方

  • まずはシンプルに始めてみる
    • 例: フリーフォーマットでやってみる
  • 何か不便を感じたら、それを解消する属性を試しに導入してみる
  • 何か不便を感じたら、どの属性をどう書くかを規定してみる

抽象的すぎてピンと来ないで、続いて具体例を挙げる。

Home > フォーマットを設計する > フォーマット例

どんな属性を使ってどんなフォーマットをつくるか、いくつか例を示す。

フリーフォーマットマン:

  • タスク名
タスク1
タスク2
タスク3 これしんどいから明日でもいいや

TODOリスト:

  • タスク名, 状態
GFM 的

  - [x] タスク1
  - [x] タスク2
  - [ ] タスク3

少し楽したら

  [x] タスク1
  [x] タスク2
  [ ] タスク3

もっと楽したら

  x タスク1
  x タスク2
    タスク3

スペースさえだるいなら

  xタスク1
  xタスク2
  タスク3

日本語でも英語でも打ちたいなら(xとｘを両方容認する)

  ｘタスク1
  ｘタスク2
  タスク3
  xtask4
  task5

WBS 的なフリーフォーマット:

  • タスク名、階層関係
  • 階層はインデントで表現するのが楽
タスク1
  aaaする
  bbbする
  cccする
タスク2
  pppする
  qqqする
タスク3
  xxx-1
    yyy
    zzz
  xxx-2
    yyy
  xxx-3
    yyy
    zzz

日間割:

  • タスク名, 状態, 実行日
  • 日間割とは？
    • 時間割 ← 時単位でやることを配置したもの
    • 日間割 ← 日単位でやること（タスク）を配置したもの
下記は YYYY/MM/DD という接頭辞で「いつやるか」を表現している。

2019/11/11 タスク1
2019/11/11 [x] タスク2
2019/11/12 タスク3
2019/11/11 タスク4
2019/11/11 [x] タスク5
2019/11/14 タスク6
2019/11/13 タスク7
2019/11/11 タスク8
2019/11/12 タスク9

日間割 + Sortable:

  • タスク名, 状態, 実行日, ソート用記号
  • Sortable とは ソートするだけで良い感じに並ぶようなフォーマットである ということ
    • Sortable にしておくとソート処理かけるだけで並ぶので楽
下記では先頭にソート用記号を導入。
スペースが未処理で、「x」が終了済を意味する。
「x」はスペースより後に来るので、
終了済タスクを未処理タスクより後ろに配置できる。

  2019/11/11 タスク1
  2019/11/11 タスク4
  2019/11/11 タスク8
  2019/11/12 タスク3
  2019/11/12 タスク9
  2019/11/13 タスク7
  2019/11/14 タスク6
x 2019/11/11 タスク2
x 2019/11/11 タスク5

行動のすべてをログ化したいタスク管理ガチ勢の一例:

  • タスク名, 状態, 実行日, 開始時間・終了時間, ソート用記号
  • 私が使っている Tritask を例に示す
    • Sortable にも対応している
  2019/11/11 Mon             タスク1
  2019/11/11 Mon             タスク2
  2019/11/11 Mon             タスク4
  2019/11/11 Mon             タスク6
2 2019/11/12 Tue             タスク3
2 2019/11/14 Thu             タスク5

Home > フォーマットを設計する > フォーマット設計のコツ

  • 自分が読みやすいことは必須
    • :x: 191031 ← これは読みづらい
    • :o: 2019/10/31 ← 曜日気にしないならこれくらいか
    • :o: 2019/10/31(Thu) ← 普通は曜日気にするしこれくらい欲しいよね
    • :o: 2019/10/31(木) ← 妥協したくない英語アレルギーならこれを
  • なるべく覚えやすく(そらで書け)、手で打ちやすいものに
  • エディタの機能で入力を省力化できるなら、あえて煩雑でもいい(でも読みやすさは欲しい)
    • 特に日付系を扱うなら省力化は必須
    • 2019/10/31(Thu) ← これを手で打つのはしんどい。。。
    • :point_right: 省力化については「Editable > 入力を省力化する > 主な手段」の項を参照
  • 何の文字を使うか検討したい場合は 半角英数字記号と全角英数字かなカナ記号の一覧まとめ - Qiita これが使えるかと

Editable

テキストエディタだけで完結すること。

サマリー:

  • 愛用テキストエディタ内でゴリゴリ操作するのが一番早い
  • CLI ツール、Markdown、プレビューなど当たり前に使ってることが最適とは限らない
  • 文字入力を省力化する方法は色々あるので使うべし

Editable > コンソールを使わない

タスク管理においてコンソールを使うケースは意外とありえる。

  • TODO 系のコマンドラインツールを使う場合
  • Markdown（で書いたタスクリスト）をビルドする場合

しかし pttm ではこれらを使わず、なるべく愛用エディタ内で完結したい。

というのも、他のツールや画面を使うと、操作感の違いや意識の切り替えなどで疲弊しやすいから。たとえ一回の切り替えが誤差であっても、一日何十何百回とやれば効いてくる。

:pencil: pttm では一日何十何百と操作を行うので、操作コストは少しでも抑えたい。

以下いくつか補足。

TODO 系のコマンドラインツールについて補足:

  • できればやめたい
  • あるいは、せいぜいゾーンの一部を実現するのに使う程度
  • :pencil: そもそもコマンドラインツールだけでタスク管理が足りてしまうなら、pttm は不要だと思う

Markdown などのビルドについて補足:

  • これもできればやめたい
  • エディタ上でも読みやすいよう設定を工夫する
    • シンタックスハイライト
    • フォント
    • ……

Editable > Markdown にこだわらない

Markdown は人気だが、必ずしも pttm に適しているとは限らない。たとえば、いちいち - XXXX とか - [x] とか書くのは正直だるい。

本当にタスク管理に特化したいなら、Markdown にこだわらず、より簡単な記法を考えるのもアリ だ。

たとえば日本語メインならそのまま打てる ・XXXX の方が楽だし、タスクの終了も「・ の後に x をつけるだけ」にすればシンプル。もう少し楽をするなら、入力モードを問わずに動作させるために「x または ｘ をつける」としても良いだろう。

ちなみに私は以前、箇条書きに特化した記法を自製したことがある。

ともあれ、もし Markdown（など普段愛用している記法）にとらわれているなら、本当にその書き方が（pttm においても）ベストであるか、今一度考えてみよう。

ただし「普段愛用してて慣れてる」「別の記法覚えるのだるい」といった場合は、無理に変えなくても良い。このあたりは個人の好みだろう。

ちなみに今の私は、以下のように「慣れた Markdown で書くけど、文法守るのは緩め」という感じにしている。

  • 普段は Markdown で書く
    • 拡張子は .md
    • Markdown のハイライトも効く
  • タスクを書く時は Markdown に従わないこともある
    • 例1: リスト表記使わないことがある
    • 例2: リストを ・ で並べることがある
    • 例3: TODO の終了を x …… のように「x つけるだけ」で済ませることがある

Editable > プレビューしない

Markdown などで書いている場合に、二画面でプレビューする……なんてこともありがちだが、正直微妙だ。

  • （二画面を専有する分）画面が狭くなる
  • プレビューに絡む処理待ちが発生する
  • 「ちゃんとプレビューされたかな」という意識や修正のコストに振り回される

どれも微々たるものだが、積み重なると大きなストレスや疲労に繋がる。繰り返すが、Editable であること（テキストエディタ内で完結すること）が最もストレスフリーである。

ストレスを減らしたいなら、まずはエディタ上で工夫する。

例: GFM の TODO 記法をプレビューしたい

  • :x: IDE などを使って二画面プレビューする
  • :o: シンタックスハイライト設定で - [x] や * [x] の時に「打ち消し線を入れる」、みたいな設定を追加する

:coffee: ちなみにハイライト設定をいじる難易度はエディタ次第。Visual Studio Code は高めな印象。私が愛用する秀丸エディタだと 設定画面だけで簡潔する ので楽(画面ポチポチゲーなところはあるが)。Sublime Text も難しかった記憶が。あとは知らない。

Editable > メモ帳や付箋などの「軽いメモ手段」に逃げない

（タスクになりそうなちょっとした）メモを書くのにメモ帳や付箋といった「軽いメモツール」を使うことがあるが、これもできれば避けたいところ。

  • 愛用エディタとは操作感が異なるので疲れる
  • ウィンドウや意識の切り替えといったコストも発生する
  • 一回なら微差でも、蓄積すると疲弊に繋がる

じゃあどうするか:

  • a) メモは「メモ用のゾーン」に書く
    • ランチャー・ホットキー・ショートカットキー等で memo.md を素早く開く？
    • $ memo XXXXX 的なコマンドを用意しておく？
    • pbpaste >> ~/memo.md 的なスクリをホットキーで呼び出す？
    • ……
  • b) 新規タブ・新規ウィンドウして、そこに書く
    • :o: 簡単で使いやすい
    • :x: 保存しないとうっかり閉じて失っちゃう可能性が
    • :x: 新規タブ・ウィンドウが逆にノイズやストレスになることも

やり方は色々あるので適宜工夫すること。しつこいが、とにかく愛用エディタ内で完結させる方向に倒すのが基本。

Editable > 入力を省力化する

タスク管理をしていると、しばしば「手で打つのが面倒な値」を扱うことになる。

打つのが面倒な値の例:

  • 日付時刻系(実行日や開始時間・終了時間 etc)
  • 人名
  • プロジェクト名
  • ……

これらをいちいち手打ちするのは面倒くさいため、なんとかして入力を省力化する。

Editable > 入力を省力化する > 主な手段

  • コピペ（後述する Prefix Cloning など）
  • 人名ショートコーディング
    • :x: 山田さん
    • :o: 山田
    • :o: yamada
    • :o: yam
    • 少なくとも敬称略は要らない
    • 「山田(yamada)だからya……は少し短いからyamくらいでいいか」 ← こんな感じで軽く決めてく
    • こういう思考プロセスはあまり変わらないので、思いつきでも定着しやすい
    • 定着しそうにないなら無理せず yamada くらいで
    • 視認性を重視するならあえて漢字で書いてもいい（立場を表現するために敬称を書くのもあり）
    • 要するに個人の好み
  • エディタの機能
    • スニペット挿入
    • 入力補完（今開いてるファイル中の単語からの補完）
    • 辞書補完（辞書ファイル中の単語から補完）
    • メニュー等で選択肢を表示させ、選んだものを入力する的なマクロ
    • ……
    • 無論これら機能はショートカットキーで一発で呼べるようにしたい
  • スニペット系ツール

Editable > 入力を省力化する > コピペを省力化する

タスク（を表す行）をコピーペーストして増やす作業や、カットペーストして別の行やゾーンに移す作業は頻発するので、少しでも効率化する。

Editable > 入力を省力化する > Prefix Cloning を使う

Prefix Cloning も覚えたい。説明が難しいのでいきなり例を示すが、たとえば「今週中に会社自席の引っ越しを完了させる」タスクがある場合、 Prefix Cloning で検討するとこうなる。

  • 1: 引っ越し: という行を書く
  • 2: 1 をコピー
  • 3: 10～20個くらいダダダっとペースト(これが Prefix Cloning)
  • 4: ペーストした 3 に、具体的なタスクや心配事などを書き殴っていく

こんな感じだろうか。

これを、

  引っ越し: 

こうして、

  引っ越し: 
  引っ越し: 
  引っ越し: 
  引っ越し: 
  引っ越し: 
  引っ越し: 
  引っ越し: 
  引っ越し: 
  引っ越し: 
  引っ越し: 
  ……

それからタスクを書き殴っていく。

  引っ越し: どこ引っ越す？
  引っ越し: 処分したい持ち物は？
  引っ越し: 会社手続き調べな
  引っ越し: 両親に連絡
  引っ越し: 全体スケジュール組んでみる
  引っ越し: 業者探す
  引っ越し: 
  引っ越し: 
  引っ越し: 
  ……

Prefix Cloning の良い点は、各タスク行の Prefix(接頭辞) が共通しているおかげで、管理がしやすい こと。

特に別のゾーンに移した後、後で読み返した時に、Prefix があるおかげで「あ、これは引っ越しに関するタスクだな」とわかる。逆に、Prefix 無しに上記作業をやっちゃうと、後で読み返しても「なんだっけこれ」とわからない or 理解するのに頭使う（そしてこれが積み重なると後々疲れてくる）。

たとえば、これだけ見てもたぶん思い出せないが、

全体スケジュール組んでみる

これなら思い出しやすいだろう。

引っ越し: 全体スケジュール組んでみる

Prefix Cloning のまとめ:

  • タスクを洗い出す時に「Prefix を固定した行」をコピペで増やしてから洗い出す手法
  • Prefix が付いてるので(たとえ別ゾーンに移した後でも)管理しやすい

Editable > 入力を省力化する > ファイルパスや URL を素早く開けるようにする

タスクとしてパス（ファイルパスや URL）を併記することは多い。たとえば:

  • 「あとで読みたいもの」のパスをタスクとして貼り付けておく場合
  • 定期的に行うタスクの実施内容として(チェックリストや手順などを記した)パスを併記している場合

このような場合に、いちいちパスをコピペしてブラウザやファイラーのアドレスバーにペーストしていたのでは面倒くさい ので、素早く開ける機能を使いたい。

例:

  • a) クリッカブルリンク(クリックするだけで開ける)
  • b) 「カーソル位置のパスを開く」的な機能
  • c) （エディタの機能ではないが）クリップボードにコピーされているパスを XXX で開く

どんな機能があるかはエディタ次第だろう。a) と b) が両方あると楽。無い場合、拡張機能やマクロなどでつくれるならつくっても良いレベル。私は b) について自作した。

c) については、私は以下のようにしている。

※細かい話なので読み飛ばし可。あとスクリプトは割愛。

  • 前提
    • 普段は Firefox 使ってる
    • 社内サイトの一部は IE でしか読めない
  • やりたいこと
    • 社内サイトの URL を IE で開きたい
  • やったこと
    • AutoHotkey で #o::run,D:\work\script\open_from_clipboard.bat (Win + O で open_from_clipboard.bat を呼ぶホットキー)
    • open_from_clipboard.bat からは python スクリ読んでる
    • python スクリでは「クリップボードの中身をゲットして、社内 URL だったら、IE で開く」的な処理

結果として「社内 URL をコピー」 → 「Win + O キーを押す」で社内サイトを開ける。まだまだ無駄はあるが、少なくともアドレスバーに貼り付けるよりは楽だ。

Reachable

ホームからすべてのタスクを辿れる(ホームを見て従えば全部まわる)こと。

サマリー:

  • ファイルは一箇所に集め、素早くアクセスできるようにする
  • タスクの書き方を誘導して、辿るのに要するコストを下げる
    • 誘導指示（～～を見て、と書いたタスク）
    • 手順指示（～～を～～回音読して、～～を～～に転記して、など具体的な指示を書いたタスク）
  • 予定（日時と場所が拘束されるタスク）はリマインダーで対処する

Reachable > ワンプレイス

タスクリスト(を書いたファイルたち)は一フォルダ内に収めたい。

理由:

  • 「この中にある」と明確なので覚えやすい
  • 管理(バージョン管理やバックアップ含む)しやすい
  • grep できる

よくあるアンチパターンとして、以下のように「一部のファイルだけ別のフォルダにある」というケースがあるが、

  • タスクリストは D:\dropbox\tasklist に置いてる
  • でもホームは C:\Users\Stakiran\Desktop\home.md として置いている

これだとすべてのタスクリストを統一的に扱えずストレスになるので避けたい。

どうしても複数箇所に配置したい場合は、エイリアス(ショートカット)を使うなどして「ポインタを張る」ようにする。以下はショートカットを使う例。

例: どうしてもデスクトップに置きたい場合

  • タスクリストは D:\dropbox\tasklist に置いてる
  • ホームも D:\dropbox\tasklist\home.md
  • デスクトップには C:\Users\Stakiran\Desktop\home.md.lnk のようにショートカットを置く
    • デスクトップにエイリアスを置いて希望を満たしつつも、実体は D:\dropbox\tasklist という一つの場所に集約されている

あくまでも「ワンプレイスに全部集まっている」状態を崩さないようにする。

:pencil: ちなみに私は GitHub(GitLab) に text というプライベートリポジトリをつくり、ここにすべてのタスクリストを集めている。バージョン管理や「GitHub からの検索」もできて地味に便利。

Reachable > 他ファイルを素早く開く

ワンプレイスに集約したタスクリスト(を書いたファイルたち)は、できるだけ素早く開きたい。

主なアプローチは二つある:

  • a) 愛用エディタの機能で開く
    • ブックマーク機能
    • ファイル履歴
  • b) 愛用エディタ以外のツールを使う
    • プログラムランチャー
    • ファイラー

:coffee: 以下、具体例として私が普段使っているものを紹介する。Windows + 秀丸エディタ + AutoHotkey + fenrir。これ以外を使っている方は適宜読み替えるなり想像するなり読み飛ばすなり。

Reachable > 他ファイルを素早く開く > エディタ機能について

  • 秀丸エディタを使っている
  • ブックマーク機能
    • ブラウザのブックマーク機能のファイル版で
    • 階層化可能なポップアップメニュー UI
    • よく使うファイルはここに入れておけば Alt → B で辿れる
  • ファイル履歴
    • 最近開いたファイルを約 60-80 件保存
    • 私はデフォ機能の表示順が気に入らないのでマクロで自製した
    • Alt + H で呼び出せるようにしてある
    • 扱うファイル数多くない時期は大体これで事足りてる

Reachable > 他ファイルを素早く開く > 愛用エディタ以外のツール > プログラムランチャー

  • AutoHotkey + fenrir を使っている
  • fenrir
    • 事前スキャン型のインクリメンタルサーチプログラムランチャ
    • D:\text\tasklist をスキャンする設定
    • fenrir 自体は D:\bin\fenrirs\fenrir に置いてる
  • AutoHotkey
    • 以下のようなコードで「Alt + 1 キーで fenrir を呼ぶ」を実現

結果として「Alt + 1 キー」 → 「ファイル名入力」するだけで、D:\text\tasklist 内のファイルをインクリメンタルサーチできる。

; fenrir - local text
!1::
  run, D:\bin\fenrirs\fenrir\fenrir.exe /t /pathfile=D:\bin\fenrirs\tasklist\path /scanfile=D:\bin\fenrirs\tasklist\scan.ini /initfile=D:\bin\fenrirs\fenrir\data\fenrir.ini /instantfile=D:\bin\fenrirs\fenrir\data\instant.ini /cmddir=D:\bin\fenrirs\fenrir\cmd, D:\bin\fenrirs\fenrir
return

Reachable > 他ファイルを素早く開く > 愛用エディタ以外のツール > ファイラー

b 案としてプログラムランチャーではなくファイラーを使う手もある。

★image欲しい？

  • Tablacus Explorer を使っている
    • 上下分割の二画面
    • よく使うタブを開いてロックしてる（10～20 個くらい）
  • Tablacus Explorer は画面左上で常に表示させてる
  • タブの一つに D:\text\tasklist がある

つまり（Tablacus Explorer のタブの一つとして）常に D:\text\tasklist が表示されている。配下のファイルを開きたい時は、マウス使うなり Alt + Tab で切り替えるなりしてすぐにアクセスできる。

Reachable > 誘導指示を書く

ホーム内で管理しづらく or 管理できなくて外に出したゾーンについては、「適切な頻度とタイミング」でアクセスする必要がある。そのためにはホーム側にそのような指示（誘導指示）を明示的に書く。

例: 予定をカレンダーで管理している場合

  • ホームだけ見ていてもカレンダーを確認できない → 予定忘れちゃう
  • カレンダーはどうやって確認すればいいの？ → こまめに確認すればいい
  • もっと言うと、予定を忘れない程度の頻度でカレンダーに目を通せばいい

pttm では次のように考える。

  • 「予定を忘れない程度の頻度でカレンダーに目を通す」ことを保証するようなタスクをホームに書けばいい
    • これが誘導指示
    • このタスクはあなたをカレンダーに誘導している

具体的にどうするか:

  • 「カレンダーを見ろ」というタスクをホームに書く

これであなたはカレンダーを見ることを忘れない。そしてカレンダーを読みさえすれば、そこに書いてある予定も全部確認するので予定も忘れない。つまり「カレンダーを見ろ」というタスク（誘導指示）のおかげで予定を網羅できる。

Reachable > 誘導指示を書く > ルーチンタスクへのいざない

※小難しい概念が続きます。しかも長いです。物好きな方はぜひ。

さきほど誘導指示の項では「カレンダーを見ろ」という例を挙げたが、このやり方だけでは問題がある。一度書いただけでは次の日以降「カレンダーを見ろ」タスクが発生しない。これでは翌日以降カレンダーを見ることを忘れてしまう。

この問題にはどうやって対処するべきか。これには ルーチンタスク という考え方が必要になる。

順に見ていこう。翌日以降カレンダーを見ることを忘れてしまうのが問題だった。

忘れないようにするためにはどうするか:

  • 一日一回「カレンダーを見ろ」タスクが出現するようにする
    • :point_right: 日間割 が必要になる

たとえば YYYY/MM/DD TASKNAME というフォーマットで pttm していたとするなら、以下のように書けば良い。

2019/11/13 カレンダーを見ろ
2019/11/14 カレンダーを見ろ
2019/11/15 カレンダーを見ろ
2019/11/16 カレンダーを見ろ
……

今日が 13 日なら 2019/11/13 カレンダーを見ろ を消化すればいいし、明日は 2019/11/14 カレンダーを見ろ を、明後日は 2019/11/15 カレンダーを見ろ を消化すればいい。これで翌日以降も忘れない。

しかし仕込みは手作業でやらねばならず、これが超面倒くさい。何かしら工夫は必要だろう。理想を言うなら、お望みの頻度で 勝手に（自動で） 出現してほしい。

理想的な運用:

  • 定期的に自動で出現してくれる
    • 例: 1日1回、「カレンダーを見ろ」という指示がホームに出現する
  • 出現頻度は変えることができる
    • 普段は1日2回だが、最近おとなしいし2日に1回に変えちゃおう ← こういったことができる

では、理想的な運用を実現するためにはどうすれば良いのだろう？おおよそ以下のような仕組みが必要となる。

理想的な運用の実現に必要なこと:

  • ホームを導入していること
  • ホームに日間割を導入しており、タスクを指定日に配置できること
  • ホームにデイリータスク(※1)を導入していること
    • ※1 今日のゴール = 今日の日ゾーン内のタスクを全部終わらせる、という運用方法
  • ホーム上で「n日に1回登場させるタスク」を容易に実現できること
    • 最悪全てを手順＋手作業で実現してもいいが、しんどすぎる
    • 何らかの省力化・自動化は必須
    • タスク管理ツールの「繰り返しタスク」「定期的なタスク」的な機能を使うのもアリ
  • ……

小難しく書いているが、要するに

  • a) 定期的に表示されるタスク(ルーチンタスク) という仕組みを愛用テキストエディタ内で実現する
  • b) a) の仕組みを使って「カレンダーを見て直近の予定を頭に入れておけ(出現頻度:1日1回)」をつくる
  • c) ルーチンタスク b) を「今日の日ゾーン」に配置する

という感じ。こうすれば1日1回、ホームに「カレンダーを見て直近の予定を頭に入れておけ」タスクが出てくる。これは（あなたが素直に従うとしたら） 一日一回カレンダーを読む機会を得たことに等しい。

さて、このルーチンタスクだが、テキストエディタで実現するのは簡単ではない。自製が必要だろう。

最後に実装例として私の Tritask を示す。

Tritask では以下のようにして実装している。

  • 登場人物
    • 秀丸エディタ
    • helper.py(指定ファイルの指定行の rep:N を指定日後に更新する機能を持つ)
  • 1: エディタから helper.py を呼び出す
    • このとき、エディタのマクロ機能で「カーソル位置の行番号」を渡す
  • 2: helper.py が rep:N を更新し、当該ファイルを直接書き換える
  • 3: エディタには更新検出機能があるため、2: が起きたら自動でリロードしてくれる

結果として、見かけ上は「エディタから直接 rep:N を更新した」ように見える。割とシームレスにルーチンタスクを実現できていると思う。

Reachable > 手順指示を書く

誘導指示だけでは迷い（具体的に何やればいんだっけ？）や怠け（今日はやらなくていいや）が発生することがある。これらを防ぐためには「誘導される先で具体的に何をすればいいか」も併せて指示する（手順指示）と良い。

例: 予定をカレンダーで管理している場合

  • ホームに「カレンダーを見ろ @1」という誘導指示を登録したとする
    • @1 は「1日に1回」の意。@7 で週に一度(7日に1回)。
  • この誘導指示では迷いや怠けが発生しやすい
    • カレンダーをどのように見ればいいの？
    • カレンダーを見たらどうなるの？見た後は何をするの？
    • 今日は見なくていいや
    • ……

そこで手順指示を導入する。たとえば以下のようにする。

  • 例1: 「カレンダーを開いて直近一週間の予定を見ろ @1」
  • 例2: 「カレンダーを開いて直近一週間の予定すべてを 2 回ずつ脳内音読しろ @1」
  • 例3: 「カレンダーを開いて直近一週間の予定すべてを calendar.md に転記しろ @1」

これなら何をすればいいかも自明だ。迷いや怠けもない。

Reachable > リマインダーを仕込む

予定（日時と場所が拘束されるタスク）はタスクリストだけでは対処できない ので、リマインダーを使うしかない。目覚まし時計やアラームは偉大な発明だとつくづく思う。

リマインダーとは:

  • 指定時刻に指定内容を通知してくれる仕組みのこと
  • 例
    • 目覚まし時計
    • スマホのアラーム機能
    • iPhone のリマインダー機能
    • Outlook のアラーム
    • ドアに買い物リストを貼り付けておく（動線に設置するリマインダでパッシブリマインドという）

リマインダーの意義:

  • 何かに集中していたとしても 気付けるので忘れない
    • 予定（日時と場所が拘束されるタスク）に忘れずに気付ける、おそらく唯一の手段
    • 予定はタスクリストだけでは対処できない

リマインダーの注意点:

  • 事前に仕込んでおく必要がある
  • 作用範囲を離れると意味がないので、離れないよう注意
    • 例1: 目覚まし時計が聞こえない場所にいると意味がない
    • 例2: iPhone を持っていないとリマインダーをセットしていても意味がない
  • リマインドされたときにすぐに行動に移せるようにしておく
    • でないと「あと 5 分」などと抗ってしまう → 結局忘れる、に陥る

以下細かい話やマニアックな話をつらつらと書く。どんなリマインド手段が使えるかの参考になるかもしれない。

Reachable > リマインダーを仕込む > システムリマインドとヒューマンリマインド

システムリマインドとは何らかの機械・プログラムを用いてリマインドを仕込むこと。

  • メリット
    • 機械は正確であるため、ほぼ確実にリマインドされる
  • デメリット
    • 機械は融通が利かないため、厳密に仕込まないと正しくリマインドされない

ヒューマンリマインドとは人に用いてリマインドを仕込むこと。

  • メリット
    • 人は融通が利くため、感覚的に仕込める
  • デメリット
    • 人は正確ではないため、確実にリマインドされるとは限らない
    • 任意のタイミングで任意の個数だけ仕込めない
    • リマインド用途であることがバレて不和を買ってしまう恐れがある

Reachable > リマインダーを仕込む > アクティブリマインドとパッシブリマインド

アクティブリマインドとは仕組みから対象者にはたらきかけてくれるリマインド。

対象者はリマインドを仕込み、そのリマインダーが及ぶ範囲内(作用範囲)で過ごしているだけでリマインドしてもらえる。たとえば目覚まし時計は、目覚まし時計が聞こえる範囲で過ごしているだけで、目覚まし時計から音という形でリマインドしてくれる。

パッシブリマインドとは「用件を記した何かを対象者が読めば当該用件を思い出せる」「確実に読める場所に要件を配置しておけばいい」という発想のリマインド。

パッシブリマインドでは用件を動線に配置する。動線とは「家のドア」や「毎日使うキーボード」など日常生活で一日複数回は経由する場所（目に入れる空間）のこと。動線に配置しておけば、自然と目に入るため忘れる率はかなり低い。

Reachable > リマインダーを仕込む > リリマインド

リリマインド(Re-Remind / Relentless Remind)とは対象者が用件に確実に気付けるよう、何度も執拗にリマインドを行うこと。

例:

  • スヌーズ機能全般
  • BlackTimer
    • 筆者自製のバッチファイル謹製ツール
    • 指定時間後に最大化したメモ帳を起動することで通知するリマインダー
    • 閉じないと 30 秒ごとにメモ帳を開き続ける（リリマインド）
  • commainder
    • BlackTimer のコマンドラインで使える版
    • 例: r 3 カップラーメンできたで
    • 私は普段これを使っている

Personal

タスクリストが個人的なものであること。

サマリー:

  • 誰かに見られることを想定しなければ、(表現を練る必要がない分)タスクを書くコストは最小限で済む
  • 明らかに自分にしか通じない言葉も使って良い、むしろ書きやすさ・読みやすさのためなら積極的に使う
  • 仕事に限らず「気になったこと」は何でも書いちゃう

Personal > 覗き見を防ぐ

「このホームやタスクリストは自分だけが読むものだ」という前提で運用するのは良いが、前提を立てただけでは うっかり他人に見られてしまうリスク は減らない。

もしこのようなリスクがあるなら、物理的・論理的・心理的に「そんなリスクはない or ほとんどない」と保証できるよう工夫するべきだろう。そうしないと結局人に見られることを想定した書き方になってしまい、（表現を練る分）ライティングコストが発生する。

そもそも見られても構わないなら対策不要

タスクリスト程度であれば、そもそも「別に見られても構わない」ことも多いだろう。であれば特に覗き見対策は必要ない。というか人によっては、

  • :cat: 「覗き見されたら困るような記述って何？」

と疑問に思うことだろう。

いくつか例を示す。

  • 知られたくない予定や日程
    • 例1: xxxの件でホットライン告発
    • 例2: 同期に異動できる枠ないか訊いてみる
  • 後の振り返りのために、タスクという名の日記を書いている場合
    • その時感じた不満や怒りを日時付きで書いているとか
  • 感情を表現するために人名表現をダイレクトに書いている場合
    • 例1: 「satoh さんと面談」 ← これは無難
    • 例2: 「satoh と面談……」 ← ちょっと失礼
    • 例3: 「クソ上司との面談」 ← 見られたらやばい
  • 業務無関係の、私的なタスクを書いている場合
    • 例1: 「昼休憩は髪切るぞ」
    • 例2: 「帰りラノベ買う」
    • 例3: 「隣部署新人来てる 女の子多いらしい 見に行こう」

工夫の例

見られたら困るタスクや事柄を扱っている場合は、リスクを減らすための対策が必要となるだろう。

いくつか例を挙げる。

見られないようにする:

  • 後ろの席や通りがかる人から見られないようにする
    • ディスプレイや障害物の位置や角度
    • 座席の位置
  • 誰かが来た時にとっさに隠せるようにする
    • ボスが来た を使う
    • 別のソースや設定ファイルを開いておいて、来たらタブを切り替える
  • 目に入ってもよくわからんと思われるような画面構成をつくる
    • エディタのフォントを小さくする
    • ターミナル、ブラウザ、ファイラーなどウィンドウを多数並べる
    • 画像やグラフの表示されたウィンドウを大きく表示する(注目をそっちに誘導する)
  • 知り合いがいない場所に移動して仕事する(ノート PC)
  • ……

興味を持たれないキャラを演出する:

  • エンジニア・プログラマーとしてバリバリタイピングする
    • 非エンジニア・非プログラマーに限り「こいつ何してるかよーわからん」と思われ興味を持たれづらい
  • やむを得ない自虐・露悪
    • :dog: 「私、頭が悪いので、思考過程もいちいち書かないとろくに仕事にならないんです」
    • :cat: 「私、コミュ障なんでチャットとかだとめちゃくちゃ喋ります」
  • ……

Personal > 自分語を使う

タスクはわかりやすく書くべきだが、自分にとってのわかりやすさは必ずしも客観的なわかりやすさではない。つまり 他の人には理解不能でも自分にとってはわかりやすい表現 というものがある。これを「自分語」と呼ぶことにする。

自分語は（他人に通じないため）使うのをためらいがちだが、pttm では積極的に使っていい。

たとえば私は「メールとチャットのチェック」を「mail」「chat」「mc」などと書くが、これは他人には通じない。mail という単語に「チャットも見る」という意味があるとは読めないだろうし、mc に至っては何の略語かまるで不明だ。それでも私自身がわかる（その上、打ちやすい）ので問題無い。

こういう自分語（特に短く打てるもの）は積極的に使っていきたい。使えば使うほど入力や読解の省力化に繋がる。

:pencil: 自分語が無い場合は無理してひねり出さなくても良い。というより、自分語とは「それを一言で表現するならどう書くか」という直感に等しい。ひねり出さずとも自然と出てくる。逆に、自然と出てこないのであれば、それは自分語ではないから、素直に「メールとチャットのチェック」とか「メールチャット見る」とか「mail chat」と書いておくのが無難だろう。

Personal > インボックス

Home > ゾーニングする > 主なゾーンの項でも少し紹介したが、インボックスという概念はぜひとも取り入れたい。

インボックスとは:

  • 「気になること」を蓄えておく領域のこと
  • 気になることはとりあえずインボックスに溜めるようにする
    • 十数秒以内でさっさとメモする
    • この時、書いたことをその場で検討しない
  • 検討は後でやる

インボックスのメリット:

  • 頭の中に溜まってるモヤモヤを外に出してスッキリできる
  • 頭の中でくすぶってることやふと思いついたことなど失わずに済む
  • 「とりあえずインボックスに入れておけば忘れない」「どうせ後で検討する」という安心感がある

インボックスの運用方法:

  • インボックス用のゾーンを確保する
    • 例1: ホームに # インボックス を設ける
    • 例2: inbox.md をつくる
  • インボックスに 3 秒でアクセスする方法を整備する
    • 例1: エディタのブックマーク機能で # インボックス 行にジャンプする
    • 例2: プログラムランチャーで inbox.md を開く設定をつくる
  • 「インボックスに溜まった内容を処理する」タスクを追加する
    • 定期的・習慣的に行えるようにしたい
    • pttm で完結するならルーチンタスクとして設定する :point_right: Reachable > 誘導指示を書く > ルーチンタスクへのいざない
    • あるいは（pttm からは離れるが）カレンダーの「定期的な予定」的な機能で忘れないようにする
    • 要するに 溜まった内容を忘れず定期的に処理できるように する
    • :pencil: 定期的に処理しないと溜まりまくって破綻するので重要

インボックスに溜まった内容の処理フロー:

  • 好きなやり方で良いが、何かしらフローを決めておくと機械的に処理できて楽
    • 判断には意外とコストがかかるので手順化して省力化するのは重要
  • インボックスの発案である GTD（リンクは後述） の考え方を参考にすると良い

インボックスに「気になること」を入れるタイミング

  • a) 思いついた時に都度
    • 上述したように素早く(PC 使ってる最中なら 3 秒以内)記入開始したい
    • :pencil: ここが遅いと「書くのダルい」となってサボる
  • b)「気になること洗い出し合宿」を開催
    • 数十分から数時間くらい、誰にも邪魔されない環境を確保してからやる
    • テキストエディタにひたすら書き殴る
  • a の都度だけに目が行きがちだが、b の合宿もスッキリするので適宜開くと良い

インボックスについて詳しく知りたければ、GTD について学習すると良い。

おわりに

pttm が捗るかもしれない考え方やテクニックを HERP(Home/Editable/Reachable/Personal) という観点で雑多に紹介してみました。参考になれば幸いです。

21
21
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
21
21

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?