プロダクティビティ環境 （タスク管理という言葉が嫌いなのでこちらで）に、Trelloを導入したので、その辺りを書き留めておく。
Why（なぜ使い始めたのか）
これまで Things (やOmniFocus）では、ひとつの “プロジェクト” に今やりたいことや将来やるべきことも含めて全部を入れていた。つまり、Thingsの中である程度の進捗管理をしている状態だった。
週次レビューで既存のプロジェクトに対して主にやることは、足りないアクションを見つけ出して追加することだが、いわゆる大きいプロジェクトになると、足りないアクションを見つけるために有効なトリガーリストを作ることが難しくなっていたし、何しろ、大きいプロジェクトのレビューは、やる気が起きない。
How（どうやったのか）
そこで、Thingsとは別の場所にプロジェクトを俯瞰して確認する場所が欲しいと思っていた。そこは、プロジェクトがあり、そしてプロジェクトのマイルストーンがリストされているものがあれば十分。
What（具体的にどうしたか）
プロジェクトのリストと、それに紐づくマイルストーンのリストを書き出すにはいくつかの方法がある。NotionやDropbox Paperに書き出しておく、という方法もあるかもしれない。自分がとったのはKANBANを使った方式だった。
KANBANは主にソフトウェア開発で使われる進捗確認手法。カスタマイズ可能なので開発チームによって色んなやり方はあるが、自分の好みは「Todo」「doing」「Done」というレーンを作って、タスクカードを移動させることで進捗状況を見えるようにする。ソフトウェア開発でよく出てくる WIP = Woking in progress という言葉は、この「doing」のカードの数のことを示す。WIPは１に近づけた方が生産性が高いと言われている。
そしてそのKANBANの実装のためにTrelloを使った、というわけ。
実際に行動するときは Things だけを見るようにするというのを大原則に、週次レビューと週次レビューの間（つまり1週間）に必要がないことは Things 上では管理しないようにする。これは1週間でやらないアクションが全くThings上に存在しないのを目指すわけではないが、レビューで補完し、整理されることを期待・信頼して放っておくのに近い。
週次レビューの際は、ThingsとKANBANの同期を取ること、実際の状況とKANBANの同期を取ること、そして、Things側に足りないアクションがあれば追加する、ということをやっている。KANBANがアクションを出すためのトリガーリストになっている。
KANBANなので、もちろんプロジェクト毎のステータス管理もしていて、今実行する必要があるプロジェクトが “doing” に並んでいる状態になっている。
２つの言い方でもっと抽象的に言い直そう。
GTDの用語を借りると次のようになる。高度０は Things に任せていて、高度1000メートルと2000メートルは、KANBANで確認している。
そして、アジャイルの言葉を借りると、PBL （やりたいことリスト）をKANBANで管理していて、SBL（タスクリスト）をThingsで管理している。イテレーションは1週間。
最後に
実はThingsのすべてのプロジェクトをカード化したわけではない。ちょっとした日用品のお買い物とかはカード化する必要がないからだ。もしかしたらこれまでプロジェクト化していたがあまりにも小さ過ぎたものは、プロジェクト化せずにカードのみで管理するというものもあるかもしれない。
例えば、サッカーの試合や音楽のライブイベントなんかは、チケット抽選→購入から実際の公演日まで時間が離れていることが多く、プロジェクト化していたが、アクションが複雑なものではないので、カード化とシングルアクションで管理できそうにも思える。
まだ始めたばかりなので、ここから改善を繰り返したいと思うが、プロジェクトが大きければ大きいほど機能させやすい仕組みだと思うので、続けてみたい。
