十数年ほど付き合いのある同居人の友人が留学することになり、その準備に追われている。私もその準備を手伝っていて、一緒になって作業に取り組んでいる。
関連書類の準備とか、荷物の準備とか、 などなど。気になることが出てきたら留学エージェントに相談ミーティングしている。ミーティングはオンラインでできるので、非常に助かっている。
今回の作業は初回のため、さすがに一度タスクを洗い出ししてもポロポロと気になるタスクがでてくる状況で、友人が「タスクが追わらない～」と、さめざめと嘆き悲しんでいる。
一方の私は、仕事ではよくある話なので、まぁこんなもんだろ、別に時期もそこまで切羽詰まってるわけでもないし、量は多いが比較的マシなプロジェクト扱いである。そこそこキツいはキツいが。
とはいっても、それはタスク管理がようやく安定していたからそう言えるのであって、それまでは状況がわからずに疲弊していた。
まずは、タスク管理がうまくいかなかった頃からのどのように今の状態になったのかを簡単に説明愚痴しよう。
（共有タスクリストを導入するまでの段階１）友人はタスク管理を共有する必要性を感じなかった
友人と私の仕事環境は大いに違う。友人はどちらかといえば個人で進めるタイプの仕事で、複数人と一緒に進めるような仕事はあまりない。
そんなわけで、そもそもタスクの共有の必要性があるやいなや、という命題から、開始した。
そんな始まりだったので、タスクの少ない状況では全く必要性を感じず、タスクの共有はできなかった。
（段階２）とはいえ、LINEの専用グループを作った
タスク共有はできなかったものの、やりとりは個人LINEでやっていたところ、通常のLINEでは情報がまざるということで、専用のLINEグループを作るには至った。すごく大きな一歩である。
これによって、通常の会話と、専用の会話の区別をすることができた。
依頼するタスク、または依頼されるタスクはこの専用グループにてやり取りしている。ある程度のタスクの分量なら、ここでやり取りするのでもまあまあ対応できるのであった。
忙しくなってくると双方語気荒めになってきたので、丁寧語を導入した。気心知りすぎた二人の距離感を遠ざけるのにはちょうどよかったと思う。
（段階３）資料はGoogle Docsに保管した
資料はどうしたのか、というとGoogle Docsに保管した。友人でも、オンラインでもアクセスできる状況を作った。ほとんどの管理や操作は私だが、今後は友人も使うだろうと思われるのでGoogle Docsに置いている。
段階３とあるが、実際には段階１～２と同時並行である。
ファイリングのルールについてもひと悶着あったが、今回は割愛。
（段階４）友人がタスクについて話をしようとすると拒否する
友人は準備などに加え英語の勉強もしているため、いつもいっぱいいっぱいである。それで家に帰ってきて、準備のタスクについて声をかけようとするとこういわれる。「今は聞きたくない」、と。
……テメェ。
さすがにヤバくなってくると、聞く耳はできる。が、なんていうのか、話を聞いてくれるタイミングがシビアすぎる。相手がその気にならないと進まない。
タスクは管理はできるかもしれんが、機嫌までは管理できない。
（段階５）締め切りがシビア＆並行タスクが多数により共有タスクリスト設立と定期ミーティングの設定をセットする
最近になって、スケジュールがだんだんとシビアになってきたため、友人がようやく共有タスクリストを作るのに協力的になった。ついでに、その共有タスクを一緒に確認することについても合意を得た。毎週木曜日の夜にてカフェで実施。という約束をしていたが、最近は（本来の意味で状況が）ヤバい空気を感じて随時ミーティングをしている。
何より、友人が協力的になった。
共有タスク管理の最終体系
とまあ紆余曲折の結果、友人と自分とでタスク管理がそこそこ回るようになった。最終体系としては以下のような感じである。
しかもこれ、会社でほぼペアで作業進めているのと同じパターンである。
- タスク作業者
- 友人・自分
- コミュニケーション
- LINEグループ
- 共有タスクリスト
- TODO管理リスト（Evernoteにて保存）
- 共有タスクリスト更新者
- 自分（友人は基本ロムというか会議体の時のみ参照）
- 会議体
- 毎週木曜日実施（その他適宜開催）
この形態において、うまくいくのにはポイントがある。
リスト更新はほぼ自分
友人のネックは、管理するリストが増えるというのが問題だった。（友人は別途自分のタスクリストを持っている）そこで、リスト管理自体は私が行うことによって、管理からは外れることで解消している。友人のタスクは増えるが、管理は増えない。
会議体は必須（定期的に友人が共有タスクリストを見るタイミングを作る）
共有タスクリストを導入する意義は、情報共有したいことだ。特に、今回のように共有タスクをメンバーたる友人がほとんど見ない場合においては、強制的に定期的に共有タスクリストを見るタイミングが必要になってくる。このタイミングを会議体で実現している。
メンバーが協力的である
一重に、運営がよく回るようになったのは、メンバーが協力的になったことが大きいだろう。私の説明不足が原因の一つだったのは否定できない。
メンバーが及び腰である場合、話し合いにより、不安を取り除くという作業が必要だったのだろうと、今では思う。
共有タスクのリストについてはどうなのか、というと、次の見出しで説明しよう。
共有タスクリストのフォーマット
共有タスクのリストはシンプルかつ最小限になった。
今のところ、以下の４つの項目でまかなっている。
そしてこのリストの1行単位は、GTDでいうならプロジェクトにあたる。
- 記入日
- カテゴリ
- 詳細
- 次のアクション/FA/ステータス
各項目について補足しよう。
日付
記入した日。そのタスクが、この共有リストに出現した日としている。そのタスクが本当に発生した日となると、正確さが面倒すぎるので過去は追わないものとする。
これはタスクがいつから開始されたものかのスタートがわかる。日付が古いと結構長らく存在していることがわかる。この日付が古いとちゃんと対応しなきゃという気分になってくるので重要である。
カテゴリ
カテゴリというか、タイトルと概要枠。「留学/ビザ申請」などの粒度で、この話はどこに書くんだっけな？と追いかける目安になるのがここの枠。
最初はタスクの枠を区切る目的だけだったが、最近はタスクの概要を定める役割となっている。呼び名や概要やらマイルストーンやらといったものを記載している。
詳細
主に時系列進捗情報を記載する。
M/D
・なんとかかんとか
M/D
・どうたらこうたら
この、日付で記載するのがポイントだ。どの時点での情報追加なのかは、長いタスクになると重要になってくるため、記載日を書いておく。
正直長いタスクはこの時系列情報をどうやって簡潔に見返しができるかが肝となってくる。結局全部表示して追加更新していく、というのが今のところの最適解となっている。
メールでもらった情報は1日前だが、記載した日はその次の日ならその次の日でいい。細かい日程までは必要ない。
次のアクション/FA/ステータス
項目名にいろいろ書いてあるが、要するに最新の状態は何か、ということを表している。次のアクションがあるのか、待ち状態なのか、クローズしたのかその場合は結果はどうなのか。日付が書いてあるなら、その日になるまではほっといておいていいルールになる。
最初「次のアクション/FA」と「ステータス」に分けてたのだが、更新が面倒になってきたので、つい最近まとめてしまった。FAはファイナルアンサーだ。
実際例はこんな感じ。これは留学エージェントとのホームステイの契約手続きに関するプロジェクトだ。
カテゴリ。
１行目はタイトル。
３行目以降がどこからどこらへんまでをこのプロジェクトの枠としているのかを記載している。
４行目以降のリストは、マイルストーン。このプロジェクトで実際行われるであろうタスクを記載している。作業が終われば線を引いて進捗を記載することで、全体の進み具合がわかる感じになっている。
詳細。
こちらの方は実際の進捗更新である。上が新しく、下が古い情報となっている。資料記入して出してと依頼されて出したところ、別の会社のやつだったのでもう一度出してほしいという時系列の情報が記載されている。
URLは、提出先のURL。メールからの転記だが、このままアクセスできるので非常に便利である。
とまあ、構成自体は極めてシンプルで、汎用性が高く個人的には気に入っている。そのメリットをいくつか書こう。
フォーマットのメリットその１、全情報をワンスクロールで確認できる
タスク管理の不便なところは、カレンダー以外の情報を一括で把握するとなると画面切り替えが複数回発生する。それが、このフォーマットでは、１スクロールで行うことができる。
操作によどみがないため、ツールの使い方で悩むことがない。
また、ここでいう全情報とは、以下の通りだ。
- プロジェクトリスト
- 次のアクションリスト
- WaitForリスト（ここまではGTDのリスト）
- プロジェクトの概要
- プロジェクトの時系列情報
特に、「プロジェクトの時系列情報」が確認できるのが重要でありそして便利である。
1か月以上放置しながら滞留するプロジェクトがある場合、さあ手をつけるぞ！と思った時に昔の記憶をひっぱってくるのが面倒である。だが、時系列に書いておくと、前回までのあらすじがある程度わかるのでとにかく非常に便利なのである。
また、各行は、よく使っているものは上に、そうでないものは下に、と自然に並べ替えをする。これがそのまま、今の優先度順となるためわかりやすい。
フォーマットのメリットその２、ゆるい
このフォーマット、ただの表である。なので記入項目のルールがゆるい。このゆるさが本当に助かる。
「カテゴリ」は、今ではプロジェクトの定義要綱みたいな感じで作られているが、当初はそのプロジェクト範囲をゆるく定めている程度だった。最初は本当にカテゴリを記載するところから始まり、そして項目が増えていくにつれて、カテゴリという区分では足りなくなったのだが、そういったものを許容できるのもこの表のゆるさ所以ではないのだろうか。
項目の「詳細」では、進捗も書くし、関係するURLといったプロジェクト情報も記載できる。URLならすぐに飛ぶことができるので本当に便利である。
「次のアクション/FA/ステータス」は、最初「次のアクション/FA」と「ステータス」と別れていたものをくっつけた。くっつけた理由は、記入する内容が割とかぶることと、「次のアクション/FA」がいつのタイミングの話なのかがわかりにくくなってきたからだ。
そもそも、この二つの項目で分かりたかったことは、次のアクションが何なのか、そうでなければ待ちなのか、日付がきたら手をつけてもいいのか、といったような内容だ。だったらあまり分ける必要性もないのではと思うようにいたり、統一したというわけである。
また各所に出てくる日付。私が単にゆるいルール設定をしているのだがそういうゆるさで記入できるところはいい。ウェブサービスだとタイムスタンプの嘘やごまかしができなさ過ぎて、時たまその正確さがイラっと感じることもある。
プロジェクトの粒度は、進捗が進むにつれて具体的になっていく。記載のゆるさが、同じ表としてまとめるのを許容できているのだと思う。
フォーマットのメリットその３、全体タスク量が物理的に理解できる
タスクがいっぱいある。といってもそれがどれぐらいあってどのぐらい大変なのかというのは、傍目にはわかりにくい。頭の中で考えていれば尚更であるのだが、それを１つの表にすることで、物理的にこんなにもあるんじゃよー、というのが理解できる。
友人にも、「この行それぞれが一連のプロジェクトであり、これが全部同時並行で動いているんだから忙しくて当然である」と説明したところ、「プロジェクトが多すぎて辛すぎる」と疲弊していたのが若干軽減された。ように思われる。
手がつけられていない時は、ほかのタスク（行）に集中している時であり、明らかにほかのタスク（行）にかまっている暇などないのが明らかである。なので、理由があるため安心して放置することができる。
友人がタスクが多くてパニックしていた時期があった。このリストを作り、項番をふったことでこれだけ数があるのだと明確になったところで、落ち着いた。項番がよかったのか、それとも表がよかったのかは判断つきかねるが、この表だと、物理的な数量が把握しやすかったのだと思われる。
友人が協力的になった要因
今回うまく行った理由の大きな要因は、友人が協力的になったことだ。
友人が協力的になった理由の大要因は、のっぴきならない状況になってきた、の一言に尽きる。私がどうにかしたのではない、第三者の外的環境が、そうせざるをえなくしたのだと私は判断している。
まとめ
今回は長年仲のいい関係性のある友人同士だが、双方のタスク管理に大いに隔たりがある場合に、うまくいった事例として挙げた。
いかにどんなに仲がよくても、仕事の形態、タスク管理の仕方がずいぶん異なると、すり合わせに時間がかかる。
タスク管理は場合によって最適な実装が大幅に異なるものである。が、何かしらうまくいかなかった時に、このやり方を試してみてもいいかもしれない。
