タスク管理弱者なりの、タスク管理ツールとの向き合い方
はじめに
私はタスク管理弱者です。弱者なりに色々勉強・工夫してきたので、自分なりのタスク管理の考え方をまとめます。あまり特別なことはありません。
タスク管理の目的
以下のような具合です。総じて「真っ当な社会人としてふるまうため」「期限ギリギリでつらい思いをしないため」にやっています。
- タスクの存在を忘れないため
- タスクが今どういう状態(未着手、仕掛かり、レビュー待ち、完了など)にあるのかを把握するため
- タスクをいつまでに完了させなければならないのか把握するため
- これまでやってきたことを記録し、将来の参考にするため
用語の定義
この記事で言うところの「タスク管理ツール」とは、主にTrelloやAsanaといったカンバンベースのツールのことです。表現に関する説明は、いずれも私の使い方における定義です。
- ボード…リストの集合。プロジェクトを表現します。
- リスト…カードの集合。各タスクの状態を表現します。
- カード…タスク管理ツールにおける最小単位。ここのタスクを表現します。
ボード構成
自身のタスクを管理するためのSelf Boardがまずあって、そこからプロジェクトとして成立するものは個々のProject Boardとして切り出して管理します。Self Boardで管理するのは、Project Board(s) + プロジェクトと呼ぶに足らないタスクやその種（アイデア）です。
グッドプラクティス
私がやってきた中で継続すべきだなと思っていることを列挙します。
リスケを恐れずに期間を設定する
各タスクに対応期間が設定されていないとタスク管理もクソもありません。最も基本的で重要なことです。入力された期間を頼りに稼働負荷を示すグラフを作ってくれるタスク管理ツールもあるので、自分の忙しさを定量的に、俯瞰で把握するためにも必要です。どうせ未来のことなどよく分からないし、何せ私達はタスク管理弱者です。適当に設定して、リスケできるならすればいいし、できないなら期限前日に泣く泣く残業する経験を何度もすれば、見積もりの精度が上がる、余裕を持ったスケジューリングをするといった変化を余儀なくされるはずです。
参考：カスタムフィールドで「もともとの期間」を設定する
タスクの対応期間を設定するフィールドは1つしかないので、リスケすると予定と実績がどれだけ解離したかが分かりません（カードの変更記録として記録されることもありますが、見づらいです）。カスタムフィールドの作成が可能なら、「もともと予定していた期間」と「現在の期間」を記録するフィールドを分けるのもよいです。
完了条件を設ける
どうしたらそのタスクが完了と呼べるのか定義し、可能なら書いておきましょう。忘れるので。私の場合、後述しますがタスク名がそのまま完了条件を示すことも多く、わざわざ別途定義するようなことはあまりないです。
参考：レビューをそのタスクに含めるか、レビューのカードを別途作るか？
ケースバイケースですが、以下のうち前者が優先されるならタスクに含めて（タスク内チェックリストで表現するとか）、後者が優先されるなら別途カードを作るとよいです。
- リスト（:=タスクの状態）を逆戻りさせたくない
- タスクをDoingに長居させたくない
レビューを実施するタイミングが週次などで定められている場合は前者でよいと思いますが、私は業務の性質上定期レビュー的なものがなく、レビューの調整というタスクが発生します。調整もタスクとして管理したほうが都合がよい（タスクが細かくブレイクダウンされているので厳密に管理できる、Doneする機会が多いので「進んでいる」感があって嬉しい）ので、別でカードを作っています。
タスク名は「主語+述語」で表現する（:=タスクをブレイクダウンする）
タスク名を単語のみにすると、完了条件がよく分からなかったり、ブレイクダウンの余地があることに気付きにくいです。私の場合は、例えば「基本設計書を作る」「基本設計書レビューを調整する」「基本設計書レビューを実施する」のようになります。
チェックリストは備忘に留める
カードの中でチェックリストを表現できるものが多いです。本来カードとして表現すべき内容をチェックリストで表現するのは、バッドプラクティスです。対応期間が設定できない、設定できても前述のようなワークロード可視化機能で単一のタスクとして扱われないなどといった弊害もあります。
タスク管理のレビュー機会を定めて、チームメンバーやマネージャーの前でDoneする
各カードのタスクが完了条件を満たしたら、Reviewingリストに移動します。週次などのミーティングで完了した旨と必要であればそのアウトプットを示し、合意を以てDoneリストへ移動します。
