works4Life

GTDメインのタスク管理と生息してますログを記載しています。

2007/06 GTD Handling(1)

 今現在のGTDの回し方については、ゆくゆくはまとめておきたいと思っていましたが、GTDの実装振り返り | works4Lifeでもまとめようと思いたったので、以下にまとめます。

説明範囲

今回まとめる範囲は以下の通りです。

  • GTDの適用方法
  • mailの取り扱い
  • 電子ディレクトリの取り扱い
  • 物理フォルダの取り扱い

 GTDの適用方法をまとめるのは勿論ですが、プロジェクトをまわす中で、メールや書類やファイルの存在を無視できるものではありません。不完全なところは多分にありますが、一旦現状のステータスということで、とりあえず合わせてまとめておこうと思います。  

使用ツール

 使用ツールは、最近のツールを表示しています。

  • 基本リスト - デジタル(FitzNote)
  • チェック用リスト - デジタル(FitzNote)
  • プロジェクトファイル - デジタル(FitzNote)・紙・マニラフォルダ
  • カレンダー - スケジュール帳

仕事の中身

 まずはじめに私の仕事の中身を説明します。どんな仕事を行っていて、どういう形状の仕事で運用しているのか明確にするためです。人によっては、このような形状ではないこともあります。GTDがうまくいったりいかなかったりするのも、仕事の中身に合う合わないがあるからだと思っています。勿論仕事の具体的な内容は違えど、骨組みは一緒という考え方もありえますが正直判断も付かないのでひとまずオープンにします。

仕事の手順と構造化

 私はいくつかのシステムの運用を行っています。システムの運用は、複数のシステムを受け持っています。各システムに対して複数の問合せや、確認等の作業が発生します。なので、仕事のレイヤとしては以下のような感じになります。

 システム - 解決すべき事項(問合せ、エラー等) - 作業項目 仕事レイヤモデル

解決事項にフォーカスした際の仕事の流れ

 解決すべき事項にフォーカスしてみると、そこで発生する作業項目は、誰かに問い合わせたり、自分自身で調査したりです。自分以外にもロールが関与してきますし、メールを送信することもあります。メールが返信されるまでの連絡待ち時間が発生したりするのも、特徴の一つです。  つまりは、連続した作業ではなく、細切れの作業が複数個存在するような作業イメージになります。あるプロジェクトの流れの例をUMLのシーケンス図でまとめると以下のようになります。

作業項目実施フローモデル

 上から下に時間軸が流れているものとし、そのうち、棒線の部分が、今回のプロジェクトで従事している期間とみなして、上記の図を描いています。ここから読み取れるのは、連続した時間で作業を行うのではなく、断続した細切れの時間で作業を行っている、ということです。

 作業が細切れであることもそうですが、その細切れの間には別の流れ(プロジェクト)の細切れの作業が入ります。そうすると、何がどう進んでいるのかを確認することがすぐにいっぱいいっぱいになってわからなくなってしまうのです。  プロジェクトの概念自体は新しいものではありませんが、活動しているきがかりなことを総て区切ってしまい、一つのプロジェクトとして見なそうとするGTDの方法は、拡張されたものの見方といえます。

本来GTDで捉えたいものは?

 一旦GTDを行う目的について戻ります。GTDで行いたいことというのは、(1)プロジェクトがこの細切れ作業のうちどこまで進んでいるのかできるだけ最新の状態で確認できること、(2)このプロジェクトについて今後自分にどのような作業が待ち構えているのかを予め確認できること、というものです。

 (1)を行うことで、そのプロジェクトに対して自分がどこまで進んだかの立ち位置を確認することができます。これによって、振り回された感は経験されます。  (2)については、これはGTDで言うところの水のような心を手に入れるための手段の一つです。これから起こりうることがわかっていれば、事前の調整や余裕を確認することができます。そして何より、自分がこれから進むべき道がクリアになり、スケジュールを立てやすくなります。

次回について

 今回は、仕事のモデリングを行って、現状の仕事の内容をまとめました。  次回は、このプロジェクトをGTDに適用する方法についてまとめていこうと思います。