４．レビューは「殿、ご決断を！」
このステップでは、再びお殿様のご登場です。お殿様と臣下とが集まり、次のことを確認するのがこのステップの役目です。
・現状のステータスを確認すること ・プロジェクトをどのように進めていくかを確定すること
ちょうどこのタイミングで、今までの時間を振り返り、これからの時間を予定します。 大きなプロジェクトに携わっているのであれば、現状の稼動状況で問題ないかどうか、事件は発生していないかをお殿様にご報告します。そして、特に問題がなければ粛々と、そうでなければ対策を、といった風に、プロジェクトに対してご決断するのがお殿様の役目です。
とはいえ、漫然とやっていては、このステップをやっていても、やりました感というのがなく難しいところです。レビューで何をするか、を明確にするのが一番初めに差し掛かる問題ではないかと思います。 レビューの中で、作業項目に落とし込んだり、プロジェクトに対してチェック項目を作る、といったように、チェックリストを作って実施すると、やった感があがります。
５．実行は「と～のさんのたーめなーらえんやーこらや」の臣下の役目
４．レビューのステップを完了し、お殿様が許可が出たところで実行作業にうつります。もちろんこの仕事を行うのは臣下になります。お殿様のご決断した内容に合わせて、お殿様の目指す理想郷のため、えんやこらと臣下は働くのです。つまり自分なわけですが。 こうして、着々とお殿様の理想郷へと続くわけですが、1週間後に１．収集ステップを再開すると、お殿様の要望が増えて理想郷が近づいてんだか遠ざかってんだかわかりゃしないという状況になるのでした。
最後に
最後は随分尻つぼみな文量になってしまいましたが、3回にわけてまとめた夢想家と実行家にみるGTDのステップの説明は以上になります。 自分自身の中をみてみると、二つの役目を使い分け、自分の理想を現実に実現するように動いており、そしてGTDのリストはこういった理想の状態を、二つの役目の中で情報共有することに役立っていることを説明したかった内容でした。 実際、WeeklyReviewで上段にたってプロジェクトの進捗を確認すると、1週間を1スパンと考えるので、個々の作業ではどんな感じで動いているのか掴みづらいのです。自分自身が実行したにも関わらずです。
また、GTDのリストのやりとりでは頭の中でお殿様と臣下にわけていますが、会社の中ではナチュラルに似たことが発生しています。上司と部下の間の情報共有がそれにあたります。上司と部下の間では週次、日次といった単位で部下から上司に報告しますが、これがちょうどGTDのWeeklyReviewのプロジェクトの進捗確認に当たります。
GTD自体が、経験則から抽出された理論の特性上、あらゆる場所でGTDの手順を内包しているものに出くわすことと思います。どういったところが各ステップに対応するのか考えていくと、GTDをより一層理解を深めることができると思います。
