Moiz's journal

プログラミングやFPGAなどの技術系の趣味に関するブログです

自分のtodo.txt運用メモ

先日こんな記事がホットエントリーに上がっているのを見ました。

qiita.com

なんと、マイナーなTODO管理メソッド、todo.txtが紹介されているではないですか! 自分はここ数年仕事関係のタスクはほぼすべてtodo.txtで管理しているヘビーユーザーです。これは便乗して布教に協力するしかありません。
todo.txt自体の説明は上記の記事が詳しいので、ここでは実際に自分がどういう形で運用しているか、紹介します。

何故todo.txtが良いのか。

まず、自分にとってのtodo.txtの利点はこんなところです

  • ポータブル
    ファイル一つでツールに基本的に依存しないので、複数環境での共有が簡単
    環境を変わるのもファイルコピー一つで楽
  • 軽量
    ファイル一つなので。フロントエンドツールを使うにしても、テキストベースなので軽量
  • 柔軟
    テキストで一行に書けることならなんでも書ける。ルールはあるが無視しても良いし、独自ルールを足してもよい
    例えばドキュメントのURLを書くこともできる。
  • GTDとの親和性
    自分はもう十年以上GTDを実践してきているので、GTDに向いているというのは大きな利点です。他のツールだと、自分のワークフローと微妙にあわないところが出てきてしまい、不便を強いられる事がありますが、todo.txtならそういうことはありません。

「柔軟性」についてですが、先ほど紹介した記事についたブックーマークを読むと、todo.txtの形式について、ガチガチに決まっていると思ってしまった人がいるようで残念です。形式はあくまでガイドラインで、自分の用途にあわなければ変更して構いません。ガイドに従うとフロントエンドツールとの連携がしやすいという利点はありますが、それだけです。

使用する形式について

じゃあ自分がどういう形式で使っているかというと、こんな感じです。

基本的に使用する要素

  • Project (+)
  • Context (@)

これだけです。

補助的に使用する要素

  • Priority (A/B/C)
    次にやるタスクを目立たせるのにだけ使う。例えば今日はせめてこのタスクを終わらせようというものにBのプライオリティをつけて目立たせる。次にやるタスクにAのプライオリティをつける。それ以外、基本的にはつけない。

  • 日付 (Creation Date, Completion Date)
    自分ではつけないけれど、フロントエンドツールが自動でつける分には削除しない

  • 期限
    たまに気が向いたら使う。(あまり役にたっていない)

サブプロジェクト

todo.txtにはサブプロジェクトを示す形式は明確には決まっていません。自分はこんな感じに運用しています

  • メインプロジェクトについてプロジェクト名を決める
    例えば、車の修理なら+FixCarなどになります

  • サブプロジェクト名はメインプロジェクト名とサブプロジェクト名を_で繋げる
    例えば、車の修理の予約は+FixCar_MakeAppointmentになります

こうしておくと、+FixCarを検索すると、+FixCarと+FixCar_MakeAppointment両方のタスクが見つかります。

コンテキスト

自分の仕事は基本的にオフィスまたはホームオフィスでコンピュータの前でやるので、本来の意味のコンテキストだと、ほとんどのタスクは@Computerになってしまいます。これではコンテキストの意味がないので、こんなコンテキストを設定しています。

  • @Computer
    普通の「仕事」。ドキュメントを書いたり、コードを書いたり・読んだり、などなど

  • @Respond
    メールやチケットの返事など、誰かの仕事をアンブロックするタスク

  • @Review
    読んでおかなければならない資料など。受け身のインプット

  • @Anywhere
    上記以外の仕事で隙間時間などにできる小さなタスク

  • @Agenda
    誰かと話すときのためのリマインダー。ミーティング時のトピックのメモにもなる

  • @Reference
    必要な書類のURL、Gmail上の特定のメールへのリンク、など、プロジェクトに必要なリファレンス

  • @Wait
    誰かを待っているというリマインダー。GTDのWait Forのためのもの。

  • @Idea
    タスクに分解する前のぼんやりしたアイデアの一時退避用。ウィークリーレビューでかならずタスクに分解する

  • @Someday
    GTDのSomeday Maybe用のもの。実際にはタスクの墓場に近いのが悩み

  • @Office
    オフィスで実際に自分が体を動かして行うタスク。例えば、セキュリティバッジの更新作業など

実際の流れ

環境

自分はtodo.txtの本体は自分の仕事環境からアクセスできるネットワーク上においています。
これで、複数環境(ノートPCとデスクトップなど)から同一タスク群にアクセスできます。

フロントエンドとしてはtodo.txt-cliを使っています。

github.com

例えばTake a vacationというタスクを追加したければ、コマンドラインからこんな風に入力します。

$> todo.sh add Take a vacation

タスクの追加

例えば、何か解決しなくてはならない問題が書かれているメールを見た場合、次のような流れでタスクを設定します。
例として、誰かが自分の書類に不備を見つけたとします。

  • プロジェクトを作る
    プロジェクト名はぱっとわかるものにします。すでにこれが大きなプロジェクトの一部の場合サブプロジェクト名をつけます。
     例えば既存のプロジェクトが+Icarusだとすると、こうなります
    @Project +Icarus_DocAFix Correct the spec doc A for project Icarus https://url.of.the/email/link
    GmailなどではメールのURLが取得できるので、いっしょにはりつけておきます。

  • タスクを決める
     必要なタスクを追加していきます。この場合、こんな感じになると思います

    • ドキュメントの不具合を確認する
      @Review Review the comment in doc A about spec mismatch +Icarus_DocAFix https://ursl.of.the/doc/link

    • スペック修正のチケットが必要なら、チケットを発行
      @Computer File a ticket for spec update +Icarus_DocAFix https://ursl.of.the/doc/link

    • スペック更新について、他チームのリーダーと話し合う
      @Agenda with Team A lead - Spec update +Icarus_DocAFix https://ursl.of.the/doc/link

    • ドキュメントレビューの終了を待つリマインダー
      @Wait for Team B to complete the doc update review +Icarus_DocAFix https://ursl.of.the/doc/link

タスクの消化

前述の通り私は`todo.txt-cliを使っているので、こんな流れになります。

  • 先ずプロジェクトまたは、コンテキストのリストを出す
    todo.sh lsc
    todo.sh lsprj

  • 出てきたタスクの中から次にやるものにプライオリティをつける(単なるリマインダー)
    todo.sh pri 12 A

  • 実行したタスクを消す
    todo.sh do 12

もちろん、todo.txt-cliを使わずテキストファイルをそのまま編集しても構いません。 臨機応変さがtodo.txtの強みです

そのほか

他には基本的にGTDに従って運用しています。
特にウィークリーレビューは重要だと思います。

終わり

以上、自分がどのようにtodo.txtを使っているか紹介してみました。
これはあくまで自分の例なので、まったく同じフローが役立つ人はあまりいないと思いますが、todo.txtは実用にも耐えうるツールだという例としてとっていただければ幸いです。