「プロジェクト管理」に試行錯誤

「プロジェクト管理」と言っても、個人のタスク管理の中での話で、システム開発とかの話ではないので念のため。

プロジェクトの定義

タスク管理上で言う『プロジェクト』が何かというのは、最近佐々木さんが日経ウーマンオンラインに書かれた>記事の定義が一番しっくり来たので、引用してそのまま使わせて頂く。

プロジェクトの定義はちょっと面倒ですが、ここでは「1日で終わらない一連のタスクを終わらせると成果が残る仕事」としておきます。

『睡眠による断絶』を乗り越えるための「プロジェクト管理」

スピードハック研究会（SH研)に入会すると、特典として過去の期の動画レクチャーの一部を見ることができるのだが、その中に、「Evernoteでプロジェクト管理」というのがあった。

１つの仕事に2日以上かかわるときには、『睡眠による断絶』を乗り越えるために「プロジェクト管理」が必要であり、それによって常に最終目的地を見失わないようにすることができる、という。そして、「プロジェクト管理」では、プロジェクト毎にカルテ＝プロジェクトノートを作ってそこに情報を集約し、プロジェクトノートを見れば、そのプロジェクトの「これまで」と「これから」がわかるようにする。具体的には、タスクリスト、作業記録、参照資料をそこに集約しておく。で、ここではこのプロジェクトノートをEvernoteで作ってみましょう、という話になっている。

プロジェクトノート？？

と、ここまで見て我が身を振り返ってみると、仕事で取り扱うのはすべてここでいうプロジェクトなので、並行して結構な数を走らせているわけだけれど、それぞれにプロジェクトノートを作る、なんていう発想は全くなく、明示でタスクリストを作ったり作業記録をつけたりしたことはなかった。

外からトリガーがかかるものがほとんどなので、それに対応する形で進めていてなんとなくそれで済んでしまっていた（こう書くと、ずいぶん受け身な姿勢だが、実際そうだった）。さすがに立て込んでくると漏れたり落ちたりしそうになるので、今週中や今日中に完了させるべきことはリストアップすることはあるが、それも毎回１からアナログのノートに書き出しているので、しばらく手がつけられないものはそのまま放置されてしまったりすることもよくあった。

また、作業記録の方も、業務を処理すればそれで終わらせていたため、翌日以降に再開するとまずそれまで何をしていたかを再度参照資料から追いかけて思い出す必要があった。少なからずここに時間がかかっていた(特に日があいた場合などは)のだが、あまりにそれが通常過ぎて、そこに問題があるという認識は全くなかった。

WinGTDにトライ

で、へぇぇぇぇ！！と思ってやろうとしたのだが、職場でEvernoteを使うのは現実的でないので、代替手段がないか質問したところ、紹介されたのがはまラボさんで提唱されているWinGTDである。

GTD自体が少しご無沙汰？で、ピンとこなかったりしたので、WinGTDの元になっているEvernote×GTDについてのはまラボさんの記事を読んだり、はまさんの著書「会社員のための究極のタスク管理　「君ならまかせて安心」と言われる仕事術」（電子書籍）を読んだりした。

会社員のための究極のタスク管理　「君ならまかせて安心」と言われる仕事術 　5つのコツで「時間」と「情報」は自由に使える！ (impress QuickBooks)

その結果、一度同じようにやってみよう、ということで始めてみた。フォルダとテキストファイルで構築するGTDベースのプロジェクト管理、ということになる。

フォルダの構成

考え方とか実践の詳細は、上記の記事や電子書籍を読んで頂くとして、現状私のやり方としては、（いまだに）Windows XPのMy Documentsの下に00_Projectsという親フォルダを作り、その下に、プロジェクト管理用のフォルダを作っている。現状のフォルダ構成は、こんな感じ。概ねはまさんの基本分類に従っている。まだ始めて日が浅いので、そこまで詳細な分類にはなっていない。

00_Projects
　└000_InBox
　└021_1st　(緊急性：大　影響力：大）
　└022_2nd　(緊急性：小　影響力：大）
　└023_3rd　(緊急性：大　影響力：小)
　└024_4th　(緊急性：小　影響力：小)
　└031_返事待ち
　└032_時期待ち
　└040_任せている
　└060_いつか／たぶんやる
　└900_Archive

1st〜4thは、いまActiveなタスクを持っている仕事の置き場で、上記の電子書籍で紹介されている優先順位を決めるマトリクス(緊急性×影響力）に依っている。影響力は、組織の利益・他人からの信頼をベースにして判断する、とされていて、これは「７つの習慣」で言われる『重要度』よりも組織人としては分かりやすく頷けるところが多かったのでそのまま採用している。

プロジェクトノートのファイル名

そして、これらのフォルダに入れられるプロジェクトノートは、テキストファイルで作っていて、ファイル名を「日付+プロジェクト名.txt」にしている。私は職場でもエディタに秀丸を使っていて（なぜか入社したらライセンスが余ってますので使いますか?と言われた）、秀丸では、1行目に入れたテキストがそのままファイル名に採用される(スペースは無視される)ので、1行目に日付とプロジェクト名を入れるようにしている。日付は、当初締め切り日を入れていたのだが、私の場合これでは扱いにくいということが判明したので（明確な締め切り日が設定されていないことが多い：どれもASAP、プロジェクトが長く、タスクの締め切りがあるだけなのでどんどん締め切り日が動いてしまう）、最近は発生日を入れるように変更している。

プロジェクト名は、自分が分かるような名称を適宜つけていて、あまり明確なルールはない。あまり長くなると見にくいので、一覧したときにすぐにどの案件だったかが分かる程度のものになるように心がけている。

プロジェクトノートのテンプレート

プロジェクトノートの中身は、上述したSH研のプロジェクトノートに倣って、タスクリスト、作業記録、参照資料の３種である。但し、タスクリストの前に、そのプロジェクトのゴール、目的、理由を書くようにしている。これは、はまさんの書籍で紹介されていたプロジェクトノートには、まずゴール、続いて目的が記入されていたことにヒントをもらっている。

プロジェクトノートをタスクリストから始めてしまうと、比較的粒度の細かいやるべきことばかりが並んでしまい、ともするとなぜこの仕事をしているのかを見失ってしまう。それではせっかくプロジェクトノートを見てもすぐにアクションにとりかかるだけになってしまう可能性が高く、ある意味今までと変わらない(作業記録をちゃんとつけていけば、そして毎回それを読み直していれば思い出すことも多いので、変わらないというのは言い過ぎなんだけれども）。

そこで、なんのためにこの仕事をしているのかに常に戻ることができるように、トップにゴール、目的、そして理由を書くようにしてみたのだ。

まず理由から｜「わけ」と「思い」

目的と理由って、裏返しの関係で同じじゃないの？と思われるかもしれない。ある意味それは正しいのだけど、頭の働きからすると、両方見えるようにここに書き出すことには意味があって、それもまず目的ではなくて理由の方から書き出す。

自分がこの仕事をやろうと思ったのはなぜか？と考えると、それが要対応だからということの他にも大抵の場合「わけ」が出てくる。そこには組織にとって、自分にとってこれをやる意味が見える。何故それを今やるべきだと考えるのか、自分は、という『思い』もここに入ってくる。

こういう『思い』や『わけ』を自分に客観的に見えるようにここに書き出すと、目的が書きやすくなる。というか、いきなり目的やゴールから書こうとすると、なんだかしっくり来ない、妙に綺麗事っぽい借りてきたようなものが並んでしまい、あってもなくても変わらないものに仕上がる傾向があるのだ。だから、出発点として理由を考えるというのは、少なくとも私にとってはとても重要なのである。

ということなので、重要なゴール・目的・理由の３点セットだが、重要なだけに、少し時間をかけて自分の頭の中のもやもやしたものを整理してやらないとうまく乗らない。特に、降ってきたばかりの仕事というのは、自分の中で意味づけがうまく発酵熟成していなくて、書くのが辛い。

ということがわかってきたので、最初にプロジェクトノートを起こすときには、無理にこの３点セットを書こうとしないで、まずは降ってきたきっかけとなった出来事を作業記録の欄に書き付けて、そこからタスクが切り出せるのなら、タスクリストの欄にも書いておく。そして、３点セットは、次回以降このプロジェクトノートを見るときにまた考えるようにしている。で、かけそうなタイミングになっていると自分が感じたら、書いてみる、といわりと緩い感じで進めている。なので、軽めのプロジェクトなどは、ここを書く前にプロジェクト自体が完了してしまったりすることもある（のはご愛敬）。

ちなみに、理由→目的→ゴールの順に書き上げるが、表示される位置は上記しているようにゴール→目的→理由の順にしている。これは、いったん書いてしまえば、タスクを実行するときにはゴールから目に入った方が取り組みやすいから、という理由による。考えるときの順序と実行するときに参照する順序は違うから、ということになるだろうか。

プロジェクトの洗い出しとノートの作成

とりあえず、上記のようにプロジェクトノートのテンプレートとフォルダを決めて、いったん手持ちの仕事を半日かけて洗い出し、大量のプロジェクトノートを作成した。テキストファイルで良かった。なにしろ会社のマシンはパワーがなくて与えられている容量が25Gという状態なので思いものを常時取り扱うのは無理。ストレスになって続かない。

作成したプロジェクトノートを一応の基準に従ってフォルダに移動させてみたところ、案の定1stが大量になってしまい、一体いつになったら帰れるんだよ?状態になったので、ここをチューンして10以下に減らす。

プロジェクトノートを作ったからと言って、その中のタスクをいつまでにどれだけの時間をかけて仕上げればいいのかは見えてこない。これはまた次の段階の工夫になる。

とはいえ、仕事上の個々のプロジェクトについていちいちその参照資料を見なくてもよくなった、というのは大変大きな変化で、その日の仕事の終わりに何をしたか、どうしてしたかをノートに記録として残しておくだけでここまで大きく違うというのはやってみなければわからなかった。

これまでは、仕事を再開する度に、色々なドキュメントが保管されているサーバ上のフォルダやらローカルのフォルダ、あるいは引き出しの書類などの実体物をいちいち確認していた。他から流入してきた参照資料、メール、自分で作った報告書等の成果物もある。ドラフトも残ってはいるが、そこに意図は当然ながら残されていないので、少し時間が経つと、一体何を思ってこれを作ったのかまるで思い出せなくて、思い出すために色々な資料を再度見直すということもよくあったし、おそらく当初の意図とは違ったものを仕上げてしまっていることしばしばあると思われる。

なんて単純なことをなんて長い間見落として仕事をしていたのだろうと思うと、失われた時間の大きさに呆然とするとともに、以後の生産性が確実に上がることを思ってわくわくしたのだった。