GTD Handling 2007/06 （１０） 実行

<![CDATA[

えーと、足掛け半年ぐらいの連載ですが、一応最後です。

今回のエントリでは、実行ステップ時の行動についてまとめますとゆーか単に羅列で書いてます。FitzNOTEでは、ActionリストやWaitForリストは特に用意せず、Projectノードの配下にアクション用のノードを作るだけでした。

１．気になることがあったらInboxに

何か気になることがあったらそのままInboxに入れる。とりあえずなんでも入れて、どうでもいいデータは参照リストか削除にします。

２．途中でプロジェクトが発生したらその場でプロジェクト化

プロジェクト化するのは基本は処理ステップの時ですが、実行ステップでは臨機応変に、一部のみを処理ステップを実施したりします。

２．１．アクションはわかる範囲で追加しておく

7並べをやっている時に出せる手を複数考えておきますよね。あんな感じで、自分がわかる範囲で次にするであろうアクションを登録しておきます。そうすると、今実行中の作業が終わったら、迷わずに作業することができます。

プロジェクトが完了するまでのアクションがわかる場合もありますが、そうでない場合もあります。その時は、反対に先へ先へと進んで、わからない先が判るように進めておきます。

『仕事を成し遂げる技術』では、NextActionリストのみしかアクションリストとしてはありません。ですが、電子ツールを使う最大のメリットは、ちょっと先の未来を補完できることにありますのでこれを有用に使います。視界が少しだけ広くなった霧の世界を進むようなイメージです。

今回は、プロジェクト発生時に追記する形を取っていますが、アクションを完了して、リストを更新する時にでも追加して問題ありません。ただ、実行するより以前に前もってどんなアクションがやって来るのかを知っておくのが大切なのです。

３．データの更新は時間のある時に

NextActionリストはいわゆるやることリストではありますが、現実の状態とリアルタイムに同期したリストが必要というわけではありません。ので、余裕のある時にデータを更新しておきます。

４．何を実行するかを選択する基準は、「行動を選ぶための４つのモデル」がベース

『仕事を成し遂げる技術』で説明されているモデルがやはり私にとってはベストです。

• 状況（コンテクスト）
• 実行できる時間
• 気力の確認
• 重要かどうか

５．コンテクストは用いない

作業量は詰め込んでというほどではなかったので取り入れていませんでした。『仕事を成し遂げる技術』で必要となるアクション数も、20個以上ある場合に取り入れるとよいと書いてあります。私は、2007/4～6時点においては、そこまでありませんでした。

それ以前にFitzNOTEがそこをうまく丸め込める状況ではなかったのが一番の原因ですが。。

６．Actionのライフサイクル

FitzNOTEでは自動的にラベルを貼り付ける機能はないので、自分でNextActionとそうでないアクションを区別する必要があります。私は以下のようにライフサイクルを決めて、ラベルとチェック項目を利用していました。

ただのノード
↓
（NextActionになった）
↓
アクションのラベルを貼ったノード
↓
（作業が完了した）
↓
アクションのラベルを貼って、作業完了となったノード

７．プロジェクトのライフサイクルと完了時の作業

ただのノード
↓
（プロジェクト化）
↓
プロジェクトのラベルの貼ったノード
↓
（プロジェクトが完了した）
↓
プロジェクトのラベルが貼ってある、作業中のノード
↓
（週次報告した）
↓
プロジェクトのラベルが貼ってある、作業完了のノード

プロジェクトは、プロジェクト化の時点でラベルを貼って他のノードと区別します。アクションのノードとは異なり、プロジェクトは上司にWeeklyReportで連絡する必要があります。そのため、連絡してアーカイブ化してよいかどうかは、進捗度を「作業中」と切り分けることで区別しました。

毎週行っていたWeeklyReport作成後に、「作業中」の進捗度は「作業完了」とし、そのプロジェクトは、Project-Archiveに移動しました。

Project-Archiveに移動するタイミングで、関連する資料をまとめるため、このプロジェクト配下のデータをテキストファイルにエクスポートします。関連するメールについても同様にエクスポートし、プロジェクトのディレクトリに配置します。なんらかの問題があった場合、少なくともディレクトリを見れば、関連する資料を取得することができるようにしておきました。この完了作業は結構面倒ですが、気持ちを落ち着かせるためにも必要な作業で]]