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日でええやろ。これで聞いてみよ。
・そんなにボリュームはないから見出し作ってざっくり書いて、全体まとめるぐらいで回りそうやね。
・じゃあアクションはこんな感じで登録してと、はい終わり

この時の考えのベースになっているのは「自然に計画するためのモデル」です。

最後に

簡単な例でしたが、具体例の説明はこれで終了です。各アクションに時間を設定しないのは、時間が限られてないからこそ問題なく動けると思います。余裕があると、いつでも実行できるとたかをくくってしまいがちです。そういった場合は、反対にアクションを時間にアサインする方がいいかもしれません。

GTDはわかりにくい概念です。今まで既存の項目からは、全くことなった取り決めごとなので理解しにくいのももっともです。

なので、今回は計画と比較してGTDはどのように異なるのかを考えてみました。

通常の計画

旅行の計画、貯金の計画、私達はいろいろ計画を行います。さてそんな計画たちですが、GTDと比較する前にどんなものなのかちょっと展開してみましょう。

計画のイメージ

計画というといろいろ人によって、こういうものだというイメージが異なります。私の計画というと、以下のようなことをイメージします。

1. あれやって、これやって、それが終わったらこっちをやって、Ａちゃんの仕事が完了したらあっちをお願いする。
2. 家で大掃除の際に、母は台所を掃除し、息子には網戸の掃除と洗車をお願いし、父親には布団とカーペットの干すのをしてもらって、洗面所と風呂と洗濯物をお願いし、祖母には掃除機をお願いしようと考えている。
3. （0点のテストを持ちつつ、学校からの帰路）お父さんが丁度帰る頃を見計らって、お母さんに渡す、素直に謝っているとそのうちお母さんの罵声がひとしきり轟き、そしたら丁度お父さんが帰って来て、仲裁に入る、そしたら怒られる時間が短時間で済む！ …ハズ。

計画とは、どうやら、自分が実行することであれ、自分以外の誰かが実行することであれ、数歩先のだれかが実行することを考える、これが基本のイメージだと私は考えているようです。

仕事の内容だともっと確実に実現しなくてはいけないため、実現するまでの実行することを考える等、目的までを網羅する必要があるようになります。

計画のための要素

それでは、何が決まったら、それは計画するということになるのでしょうか？ 上記の見出しで、イメージを展開したので、ここからまとめて抽象化しました。それが以下の通り。

• 誰かが何がしかの作業を行うこと（＝アクション）
• 回りの状況の変化

例えば3番目のイメージでは、0点のテストをもって帰って、いかに最小限に怒られるように済ますかについて計画を立てていますが、これについて、どこがどう相当するのか考えてみましょう。

一つ目は、誰かが何がしかの作業を行うこと＝アクションです。このうち、「お母さんに渡す」「素直に謝っていると」というのは自分の行うアクションです。

二つ目は、回りの状況の変化についてです。これは「お母さんの罵声がひとしきり轟き」「お父さんが帰って来て、仲裁に入る」がそれにあたります。お母さんもお父さんも、自分の計画した通りに動くかどうかはわかりませんので、それで状況の変化になります。計画は、自分の行動以外にも、周りの状況の変化を当てにする場合もあるのです。

つまり、計画をすると二つの要素が絡み合うことがわかります。計画を立てる側と、それ以外＝回りの状況です。物を作る場合においても、Ａ、Ｂ、Ｃ、という手順を行うにしても、Ｂの行動を起こす際には、Ａの行動が成功しているという暗黙の回りの状況の変化が想定されています。Ｃの行動を起こす際には、ＡとＢの行動が成功しているという暗黙の回りの状況の変化が想定しています。このように、暗黙の成功の了解がありつつ、計画は成り立っていることがわかりました。

計画が計画通りに行かない時にはどうするのか？

でも、そんなにいろいろな計画をめぐらしても、もちろん計画通りに行かない場合もあります。そもそも計画していたアクションがうまくいかなかった場合と、それから回りの状況の変化に次のアクションが合わない場合があります。このうち、後者の場合について考えてみましょう。

計画のイメージの中の2つ目の例について。このイメージの中では、母親はいろいろと家族の皆に行動してもらうよう計画を立てています。しかしながら肝心の大掃除の日、祖母がぎっくり腰で動けなくなってしまいました。なので、母親は祖母の作業は息子にしてもらうように変えました。これも計画を変えたことの一つです。

仕事で顧客から依頼された作業をやっていた場合、その顧客が、これこれこういう風に変えてほしい、と突然リクエストがあった場合にも計画を見直さなくてはいけなくなるかもしれません。そのリクエストを検討して受け入れるとなると、計画を変える必要があります。

計画はあくまで計画であり、万事うまくいくとは限りません。その場合、状況が変化する毎に、計画は再計画する必要があることがわかります。

計画のまとめ

計画には、目的を遂行するために何がしかのアクションを行うことを想定します。しかしながら計画を実行すると、状況が計画通りには変化するとは限りません。目的を遂行するためには、その状況に合わせて都度計画を変更する必要があります。

しかしながら、状況が変化することをうっかり忘れるパターンも多いのです。これについては、「仕事は楽しいかね」という本にも同じことが書いており、丁度主人公が企業して失敗した理由が、回りが変わるのを見落としていたと指摘されていたように思います。

高速回転で状況が変わる場合の計画の仕方

さて、計画は実行するアクションを考える、状況毎にアクションを考え直すという二つの作業が含まれていることがわかりました。

仕事中の広義の意味でのプロジェクトは状況はゆったりと変化します。だから、プロジェクトでは、週一回のペースで回りの状況を確認し、スケジュールを見直すようにすればよい、とよく言われています。ですが、そんなペースで確認できない場合もあります。

では、状況がゆったりと変化するのではなく、もっと高速に状況が変化する場合＝高速回転で状況が変わる場合、仮に計画を立てるとするならば、計画はどのように立てればいいのでしょうか？ 高速回転で状況が変わるという場合は、スポーツの試合を考えるとわかりやすいかと思います。ここではイメージを共有しやすいということで、RPGゲームの戦闘シーンについて考えてみたいと思います。

RPGの戦闘シーンのプロセス

RPGの戦闘シーンを例にもってきたのには、イメージを共有しやすいという点もありますが、プロセスがわかりやすいということもあります。ＲＰＧの戦闘シーンのプロセスは、大まかには以下のプロセスになります。

1. 味方のアクションの実行
2. 敵のアクションの実行
3. １に戻る

そして、1の味方のアクションの実行は、通常「味方のターン」と呼ばれ、敵の場合では「敵のターン」と呼ばれます。そしてそれが一巡してまとめて「1ターン」と呼ぶこともあります。ここの場合では、簡単に説明するため、以下のように呼ぶことにします。

• 1の「味方のアクションの実行」→「味方のターン」
• 2の「敵のアクションの実行」→「敵のターン」
• 1,2のアクション→「1ターン」

状況が変化するのは、味方のターンでもそうですし、敵のターンでも変化します。敵味方のヒットポイントが変化したり、攻撃力・防御力が増減したり、敵が増えたり等いろいろな変化があります。ボスキャラになると、受けた攻撃によって、ボスキャラ自身が進化を遂げるという状況の変化すらあります。

戦闘シーンでの想定範囲

さて、ここで質問です。通常の中ボスキャラの戦闘シーンにおいて、味方のアクションを何ターン分想定しますか？

私もRPGが好きなので、RPGもよくプレイしましたが、正直2ターン分考えればいい方です。中ボスキャラの場合は、ザコキャラと異なり長期戦になるし、どんな技を繰り広げるかは数ターン過ぎないとわかりません。だから、敵のターンが終わる毎にヒットポイントの様子を見つつ、攻撃を繰り出すか、防御をあげたり魔法防御をあげたりするのかを考えます。

仕事のプロジェクトのような場合と比べると、高速回転で状況が変化する場合においては、ほんの数手先しか考えてないことがわかります。少なくとも私はそのぐらいしか考えません。

ともかくにも、高速回転で状況が変わる場合と、そうでない場合においては、計画する範囲が随分異なるということを理解して下さい。

GTDと計画

で、最終的にもっていきたかったGTDと計画の関係です。GTDは、日々変化する状況の中で、一体どこまでを把握すればつつがなく生活できるのかを考えたやり方です。そして、自分自身に焦点をあててみると、この日々変化する状況って高速回転で状況が変化する場合と似てるんじゃないの、と思うに至ったのであります。

例えば、9時に会社について、まずは上司からいきなり追加の仕事のリクエスト。しかも最優先というから一番真っ先に作業をし始める。それが終わったら今度は同僚のＢさんから、作業の相談。それで30分消化。それが終わったら今度は電話がかかって応対。という風に回りからリクエストがありーの、電話がかかりーの、等々いろいろなことが発生します。電車に乗ってる間に考えた計画なんて、１から全てパアです。

GTDは計画できないんじゃなくて、敢えて計画しない

だったら、そもそも計画なんてやめちまえ。ちょっと先のターンだけ考えて、後はやってくる敵を撃破だ！ そんな風に日々を繰り広げようとしているのがGTDなのであり、日々の状況を高速回転で状況が変わると見立てて敢えて計画しないような考え方で成り立っています。しかしながら、高速回転で状況が変わる場合でも、最低限の計画というか方針は成り立っています。ただ、長期戦の計画と比べて、計画している範囲が非常に短くなっているだけなんです。

じゃあ、通常の計画と高速回転用の計画＝GTDだとどこが違うのか、というのが気になるところですよね。

GTDが最低限想定するアクションは、各プロジェクトの次のターンだけ

GTDが最低限必要とするのは、次のアクション、この一歩進むステップのみです。次のアクションだけは、現在の状況に依存しているため、実行する可能性も高く、また実行した後の高価も非常に高いのです。

NextActionリストはアクションを実行する時期は約束していない

Davidの提唱するGTDのNextActionリストでは、その作業を行う実行時期は約束しません。現時点で、作業できる範囲はNextActionリストに挙がっているアクションと、Calendarリストにある今日の日付のアクションやイベントに限定されます。

NextActionリストが実行する時期を約束しない点は、理解されにくいことの一つです。GTDが約束するのは、確実に実現できることにのみです。だから、その日にその週に実行できるかできないか、なんてことは決して約束しません。なぜなら、日々は高速回転で状況が変化するからです。その日にその週にその作業をこなせるなんて、とてもじゃないけど約束できません。

とにかく、Calendarリスト以外のリスト、Somedayリスト、Projectリスト、Actionリストにおいて、時間の次元はないものと考えてください。これは、自分自身がリストと取り決めただけに過ぎません。人間の頭と同様、時間の次元はこれらのリストには存在しません。

そこから、今日実施するのか、次の週実施するのかを決めるのかは、GTDならば、レビューステップになることを区別するようにして下さい。

仕事の中でも言うじゃありませんか、できない仕事はできないということが大切だって。自分に対しても、できないことは約束してはダメなのです。

まとめ。通常の計画とGTDの取り決めの範囲

今までの内容のまとめです。最終的にわかりたいことは、通常の計画とGTDの取り決めにはどのように差異があるか、ということです。

計画には、本来3つの手順が存在します。

1. 目的を実現するための、作業を全て洗い出しする
2. 作業について、作業する期間を決める
3. 作業について、作業する人を決める

通常の計画では、時間をかけて考え、この3つを明らかにします。で、仕事の場合はこれがはっきりしておかないと、後からえっらいことになってしまいます。

一方、GTDは、1について次のアクションのみを実行し、2について決めません。３については、ほとんどが自分が行うことなので、ほとんど決めません（GTDのフローチャートに、人に任すという選択肢がありますが、ここでは一旦考慮から外しています）。これをまとめると以下の通りです。

1. 目的を実現するための、作業を全て次の作業のみ洗い出しする
2. 作業について、作業する期間を決める
3. 作業について、作業する人を決める

斜線の部分は実施しない所です。このように、GTDでは、通常の計画より少ない範囲で決め事をしています。

GTDの約束すること

『約束する』という言葉は、GTDを理解するうえで、重要なキーワードとなります。GTDでは、できない約束はしません。GTDの各種リストであっても、できない約束はしていません。通常の計画よりも約束する範囲が少ないのはそのためです。

GTDは

、自分と約束することを非常に大切にしています。まずは、このエントリでは、どの部分においてGTDは約束するのかを理解していただけると嬉しいです。