GTDでプロジェクトをこなす具体例（１）で、具体的な作業を書きましたので、今回は各作業について補足解説…というか、補足コメントをします。
GTDのステップに無理くり適用するとするならば
補足コメントの前に、仮に各作業を無理やりにGTDのステップに適用してみます。仮に（仮にですよ）各作業をGTDのステップに適用するならば、以下のような感じかと思います。あまり自信はないです。
収集ステップ
- ０．上司に説明資料作ってと言われる
処理ステップ
- １．d-cubedに、プロジェクトを作成する
- ３．d-cubedに締め切りを登録する。
整理ステップ・レビューステップ
- ２．d-cubedに、とりあえずわかるだけのアクションをプロジェクトに列挙する。
実行ステップ
- ４．登録したアクションの1番目と2番目の「上司にどんなものを作るのか確認する」と「上司とレビュー日（できれば1回目と2回目）を決めておく」を行う
- ５．登録したアクションを順ぐりにひたすらこなす
- ６．第1回レビューをする
- ７．修正する
- ８．第2回レビューは実施しないので、d-cubedのプロジェクトのアクションから「上司と再レビューを行う」と二つ目の「レビュー分を修正する」を削除するor完了とする
補足コメントでは、どうして上記のようなステップに適用したのかを踏まえて、コメントしていきたいと思います。
各作業の補足コメント
０．上司に説明資料作ってと言われる
この内容が収集ステップの「物」として取り扱われることには、特に違和感はないと思います。
１．d-cubedに、プロジェクトを作成する
収集ステップで収集された「資料作って」は、ほとんど考える時間もなく、すんなりプロジェクトリストに配置されます。それが、この作業。GTDのステップ的には処理ステップにあたります。d-cubedでプロジェクト登録されることで、プロジェクトリストに配置されます。
GTDのワークフローには、一番初めに「これはなんですか？」という質問がありますが、ここは端折っていますというかあんまり考えたことない。今回に限らず、私は「これはなんですか？」というのを意識して行うことはあまりないです。
ちなみに今回のパターンは、収集リストに明示することなく処理ステップされたパターンです。
２．d-cubedに、とりあえずわかるだけのアクションをプロジェクトに列挙する。
GTDのワークフローでは、「物」が「プロジェクト」とみなされたら次のアクションを考える、という風になっています。これが、この作業に相当します。
ワークフロー自体は次のアクションは1個でいいとあるけれども、それはNextActionリストに記述することを想定しているからです。d-cubedでは、プロジェクト配下にActionを設定するので、複数ステップでもわかる分だけ登録していても問題ありません。で、d-cubedでは、SummeryReviewのティダラーなどで、登録されたActionのうち一番上部で配置された未解決のアクションが、コンテキスト毎に表示されます。
また、GTDのワークフローの処理ステップの一番初めにある「これはなんですか？」ですが、仮にしているとするならば、この時点です。
プロジェクトのアクションを洗い出しする際には、『仕事を成し遂げる技術』の「自然に計画するためのモデル」をベースにして考えをめぐらします。
３．d-cubedに締め切りを登録する。
日付の情報は、プロジェクトの情報とは別々に取り扱います。
今回の場合、12月6日は、今回のプロジェクトの〆切り日です。しかしながら、その日自体に何かをする必要はありません。けれども、その日を思い出す必要はあるのだから、それでカレンダーに記述する必要がある。というわけで、プロジェクトのリマインダとして登録します。必要であれば、自分の使っているスケジュール帳にも記述しておくとよいでしょう。
紙のプロジェクトリストならば、プロジェクトリストの項目の右側に〆切りを書いて、なおかつ自分の使っているカレンダーに記述しておく、というような作業がベターです。
でも、12月6日がプロジェクトの締め切りであるという紙を、43Folderの12月6日にセットする、これは多分意味を成さないです。というのも、そもそも12月6日までに作業を完了しなくてはならないのに、12月6日に思い出すようでは遅いからです。もしセットするのであれば、〆切り前の２～３日前の方が望ましいでしょう。
リマインダを設定するのは、その日までにアクションが終わりきるかどうかを考える指標となります。
４．登録したアクションの1番目と2番目の「上司にどんなものを作るのか確認する」と「上司とレビュー日（できれば1回目と2回目）を決めておく」を行う
この作業がプロジェクトの一番初めの作業になっているのは、プロジェクトを定義するのが自分ではなく上司であること、レビューの作業に関与するのが他の人間でしかもかつ時間のリソースが限られた人間であること、という二つの理由からです。
ここのポイントは二つあって、一つは、このプロジェクトのゴール設定を、「上司にどんなものを作るのか確認する」というアクションで決めること。もう一つは「上司とレビュー日（できれば1回目と2回目）を決めておく」で上司に関係する作業をまえもって行うことです。
一つ目のポイントは、プロジェクトの定義について。実は、GTDのワークフローをすると、プロジェクトの定義を一体どこですれば最適なのか、というのがわかりにくいのです。しいていうなら、GTDのワークフローでプロジェクトリストに追加した後に行う、「次のアクションは？」という部分でプロジェクトを定義するのではないかなー、と思います。で、ここで言いたいのは、そのプロジェクトの定義であるベクトル（スタートとエンドと方向性）を決めること自体を、フロー中に行うのではなく、アクションとして別立てしていることです。
二つ目のポイントは、ネックになりそうな部分はまえもって作業を行うということです。今回であれば、上司のレビューに割く時間を確保できるかどうかでした。なので、これをプロジェクトの一番初めに聞いておきます。
プロジェクトで遅延する場合で、どうにもならないのは自分の作業以外の場合です。つまり、作業が他の人のターンであった場合。これについては相手にお願いして無理に行ってもらったりすれば、どうにかなる場合もありますが、確実性があるとはいえませんし、相手にも迷惑がかかります。だから、予め作業を行っておいた方がいいのです。
このような自分の都合で変更しにくいことには、他の人が関与するようなレビュー・ミーティング等、相手が作業を行うようなメールの返信受取・作業依頼・作業確認等、があります。
５．登録したアクションを順ぐりにひたすらこなす
方針は基本的に、「いつも前倒し」です。いついつにこれを実行するという、期日を決めての実行は、しません。前のアクションが終わったら次のアクションができるようになるだけです。
計画通りに終わらなかったといって落ち込むような環境を、無闇に作る必要はありません。目的は、計画通りに作業を行うことではなく、締め切りまでに作業を終わらせることだからです。
６．第1回レビューをする
レビューをします。
７．修正する
資料を修正します。
８．第2回レビューは実施しないので、d-cubedのプロジェクトのアクションから「上司と再レビューを行う」と二つ目の「レビュー分を修正する」を削除するor完了とする
このような、想定していたアクションがなくなってしまうこともよくあることです。その場合は、削除したり、勝手に完了したりして対応します。
９．終了
d-cubedでアーカイブ化をすると、現在稼動中のプロジェクトから消すことができます。
他補足
NextActionにも日付を持たせるようなスケジューリングは必要なのか？
NextActionに日付を持たせることは、不要です。むしろ決めておく必要があるのは、プロジェクト自体の〆切りです。
それに、このプロジェクト以外に並行して動くプロジェクトもありますし、割り込み型のアクションも発生します。それに、アクションをその日その時間にすることが必須というわけではありません。最低限の条件は、プロジェクトの〆切り前に全てのアクションを終わらせることです。可能であるなら、12月5日に全てのアクションを実行しても問題ないのです。
プロジェクトの立てるきわ
- １．d-cubedに、プロジェクトを作成する
- ２．d-cubedに、とりあえずわかるだけのアクションをプロジェクトに列挙する。
- ３．d-cubedに締め切りを登録する。
この３つの作業は一気に行っています。ここら辺でむにゃむにゃ考えつつアクションの整理まで終わらせます。この時考えているというと、ざっとこんな風です。
・えーっと資料を作るということだけど、そもそもどんな資料を作ったらええんじゃ？ ・というか細かいのが必要なんか、それともざっくりでいいのか… ・お客さんに説明するって言ってたけど、絵が多い方がええんかな、としたらパワポか… ・にしてもお客さんてどのお客さんやろ？ Tさんやと厳しいんだよね。 ・とりあえずわからんので上司に聞いてみるか ・そういや上司見つかんないんだよね。一緒にレビュー日も決めとこ。 ・一応何かあった時を考えて2回レビューやることにしとく。 ・レビューは、だいたい12月3日と5日でええやろ。これで聞いてみよ。 ・そんなにボリュームはないから見出し作ってざっくり書いて、全体まとめるぐらいで回りそうやね。 ・じゃあアクションはこんな感じで登録してと、はい終わり
この時の考えのベースになっているのは「自然に計画するためのモデル」です。
最後に
簡単な例でしたが、具体例の説明はこれで終了です。各アクションに時間を設定しないのは、時間が限られてないからこそ問題なく動けると思います。余裕があると、いつでも実行できるとたかをくくってしまいがちです。そういった場合は、反対にアクションを時間にアサインする方がいいかもしれません。
