既に2008年となりましたが、中途半端なままではいけませんので引き続き書いていきます。
この頃、レビューについては実行チェックリストを用意して、それを実行すればよいように手順を組んでました。
手順の作成
参考にしたページ
基本的にはＧＴＤのレビュー作業＋フライデー８＋週ごとに会社で行いたいことです。
会社用と家用とWeeklyReviewをわけて実施
David Allenでは、リストは公私で統一しなさいと話していました。が、レビューについてプライベートまでも範囲に含めてしまうと、とても時間がかかる。仕事関連のレビューは会社でするので、公私別個にレビューを実施しました。
でも、公私を別に実施するのは結構時間的にもつらいです。仕事ではいろいろ含めて作業を行っているので3時間ぐらいはかかります。家でもやっぱり2時間は大幅にかかってしまいます。仕事については、時間がない日もあるので、最低限これだけはやっておこう、という項目をつくっておけばよかったなと反省しています。
会社でのWeeklyReview
WeeklyReview
├さようなら、過去よ
｜├同期作業
｜｜├fitzNOTEとメール項目を同期する
｜｜├fitzNOTEで進捗を更新する
｜｜├Supportリストを更新する
｜｜└SupportリストからWeeklyReportを作成し、上司にメールする
｜├ノーパソバックアップ その１の手順
｜｜├機体取り出す
｜｜├電源つける
｜｜├operaでメール受信する
｜｜├npopでメールリスト受信する
｜｜└共有サーバから関連ディレクトリをPCにバックアップ
｜├作業記録を更新する
｜｜├工数登録
｜｜｜├当該週のログのtxtを開く
｜｜｜├xls作業
｜｜｜｜├xlsに貼り付け
｜｜｜｜├project整形
｜｜｜｜├整形ボタン押す
｜｜｜｜└データ調整
｜｜｜└工数システムに登録
｜｜└勤怠登録
｜├交通費・旅費を精算する
｜｜├共有スケジューラで登録する項目を確定する
｜｜├精算システムで登録する
｜｜└共有スケジューラに登録した項目に♪を付ける
｜├資料の同期
｜｜├電子ディレクトリ
｜｜└物理ファイル
｜｜ ├4段棚からマニラファイルを集めて、ラベルの必要がないかチェックする
｜｜ ├テプラを借りてくる
｜｜ ├ラベルのないものを追加する
｜｜ └テプラを返してくる
｜├ノーパソバックアップ（２）
｜｜├デスクトップからノートへバックアップ
｜｜｜├usr-project
｜｜｜├usr-project-archive
｜｜｜├usr-backup
｜｜｜└usr-references
｜｜└npopでメール削除
｜├机の上を拭く
｜└休憩
└こんにちは、未来
├収集
｜└気になることを収集する
├整理
｜├1番目の棚：Inboxを処理する
｜└fitzNOTEのInboxを処理する
├整頓
｜└Desknet'sから翌週の予定を手帳に転記する
└スケジューリング
└来週のおおよそのやりたいことを決めておく
手順レベルでの作業リストが以上になります。会社で示すWeeklyReviewとは、この手順を上から順にやり、最後まで終わらせることにあたります。
作業について、どういう意図で作っていたのかまとめておきます。
同期作業
この場合の同期作業は、メール・電子ディレクトリ・fitzNOTEに分散しているプロジェクトをfitzNOTEに集めるためのものです。メールを起点にプロジェクトが発生する場合は、メール上でリストを作ることでプロジェクトをひとまず切ったりします。なので、データが場所場所によって統一されないので、これをレビュー時に同期させます。
ノーパソバックアップ その１の手順
バックアップ作業は時間がかかるので、先に実行しはじめます。ツールを起動して、後はほっときます。
作業記録を更新する
各案件ごとに時間を統計していたので、それをまとめます。これが結構面倒。このデータ取りのためだけに、ギプスをしていたのです。ここまで厳密になる必要もないのですが、思い出す煩わしさが嫌で、作業する煩わしさを選択しました。
交通費・旅費を精算する
まとまってくるとやる気がそげるので週間単位で精算します。精算しないと結構つらいことになるんですよね、こういった事務処理。この作業があるせいなのか、会社でのWeeklyReviewはマメに実施していました。
資料の同期
物理的な資料もそうですが、電子的な資料もちょっとしてる間に分散します。それをプロジェクト用のディレクトリやフォルダにいれてしまいます。
ノーパソバックアップ（２）
バックアップ作業その２です。時間経過のタイミングは、何回かWeeklyReviewをして最適化して、この場所になりました。（１）のバックアップ作業が終わってなかったら後回しして、次の作業に向かいます。
机の上を拭く
掃除です。フライデー８に書かれたままに取り入れたレビュー項目ですが、定期的に行うと、デスクトップ回りがリセットされて気持ちがよくなります。WeeklyReviewって何をしたらわかんないよって場合は、まずは定期的に机の周りを掃除することからでも初めてもいいかもしれません。
収集
GTDの収集ステップに相当します。ただし、仕事関連に関するものを収集しようとしていました。が、直近に関する仕事の内容については洗い出されているので、この作業が効果的に働くことは少ないです。処理～実行ステップが滞りがなければ、収集はそれほど問題ないみたいです。
整理
GTDの処理ステップです。
整頓
GTDの整理ステップに相当するようにつくりました。
とはいえ、実際やっていたのは、カレンダーリスト関連の同期作業です。
家でのWeeklyReview
WeeklyReportで最後に表示した2007/5/26の内容を以下に示します。
Home WeeklyReview-20070526
├０．初動
｜└■掃除機をかける
├１．収集
｜├■テーブルに処遇不明なものを家から集めてくる
｜├■Inboxからものをテーブルにぶちまける
｜├■Inboxを空にしたらもとに戻す
｜├■Remember The MilkのInboxをfitzNOTEのInboxにいれなおす
｜└■頭からしぼりだす
├準備
｜├■財布を用意する
｜├■手帳を持ってくる
｜├■ペンを用意する
｜├■タイマーを用意する
｜├■はさみを用意する
｜├□Inboxボックスを用意する
｜├■Projectボックスを用意する
｜├□ラベルライターを用意する
｜└■ゴミ箱を用意する
├２．処理
｜├■テーブルにあるものを処理する
｜├■Remember The MilkのCalendar項目を確認する
｜├■fitzNOTEのInboxを処理する
｜└リストの更新
｜ ├■Projectで検索をする
｜ └■上から順に、一番最後のActionのステータスを確認し、現状と一致していなければ更新する
├３．整理
｜└レシート精算
｜ ├■excelを起動しよう
｜ ├■財布からレシートを出す
｜ └■excelにレシートを登録する
├４．レビュー
｜├■プロジェクトの進捗を確認する
｜｜├ラベルが「プロジェクト」で検索する
｜｜└上から順にループ
｜｜ ├現在の状態をProjectの詳細に時間とともに記述する
｜｜ └2週間進んでいなければSomedayに差し戻す
｜├■反省を書く
｜├■スケジュールプランニング
｜├□GoogleReaderを初期化する
｜└WeeklyReportをworks4Lifeに書く
└保留
├デフラグする
├PCのバックアップをする
└DiigoのInboxを処理する
仕事と家でのWeeklyReviewの違い
家では実施するのに一番きつかったので、準備の部分を明確にしていました。が、それでも難しいは難しいんですよねー。もうちょっと来週もしよう！ と思えるような何かがあればいいのですが、それを見つけるまでにはいたりませんでした。
WeeklyReviewの手順は毎回見直す
WeeklyReviewの手順は毎回見直し、どうやったら時間がかからないかを考えて手順を組み替えます。
反省点
仕事のレビューは実施しやすいが家では実施が困難
仕事上では、WeeklyReviewの中に上司への週次連絡も含まれています。これは、必ず行わなければならないことなので、それにあわせて全部やってしまおうと、サイクルを実施するのが容易でした。
が、それは仕事だけの話。家ではなかなか難しいです。時間もかかるし、結構くたくたになってしまいます。スッキリするのはわかっているけれども、面倒くさがってやらなくても生きていけることを知っているので、仕事よりは、やらなくちゃ！ という危機感は少なく難しいです。
レビュー作業はある程度の時間が必要なため、時間が少なくなった場合の対応ができない
仕事で行うにせよ、家で行うにせよ、WeeklyReviewはそれなりの時間がかかります。なので、本当に時間がなくなってしまったときには、この時間も削減しなくてはなりません。が、上記のWeeklyReviewは時間がそれなりにあることが前提とされています。なので、時間がなくなった時に、これだけやっておこう！ というような最低限スペックがなくて、困った時がありました。
上記の手順はノートにメールを取得する作業を時間差にわけて作業を実施しています。こういう作業を取り外すのが、上記の手順ではなかなかに難しいのです。
最低限しなければならないことと、オプションで行いたいことを別々に分けて作っておいた方がいいなと思いました。
レビューは状況に依存しているため、プロジェクトが変更した等の状況の変化に応じてレビューの手順を組みなおす必要がある
2007年6月に仕事の状況が変わったため、WeeklyReviewの内容も変わりました。GTDは復旧対応が他のシステムよりやりやすいといいます。が、それにしても状況にどっぷりな手順だと、これを解きなおすのには一苦労しました。
どちらかというと、各手順をブロック単位でまとめておいて、実行するように捕らえる必要があったなぁと今では思います。
仕事時のレビューの順番はエネルギー的には不適切
会社のレビューは、過去に対する作業と、未来に対する作業を別々にわけていました。で、掃除をして過去から未来へと新たな出発をする！というストーリーのもと、アクションを組んでたわけです。
一応。でも、GTDでは収集から始めるのがよいとあったし、実際途中で収集ステップをするのはそれなりのエネルギーが必要です。なので、仕事で行っていた手順は、エネルギーの消費効率から考えると不適切かなと、今では思います。実施の順番は、エネルギー消費の高いものから低いものへが、一番なめらかです。
レビュー手順の反省のまとめ
反省をまとめるとこんな感じです。
- 状況時間に応じて実行できるように、ブロック単位でレビュー項目を作っておくとよい
- どんな状況でも、最小限実施するレビュー項目を決めておくとよい
- レビュー項目の順番は、収集→処理→整理→レビュー→実行で行うのが望ましい
最後に：WeeklyReviewに時間をかけないようにするには？
もっと対極的に見てWeeklyReviewがどうしていやかを考えると、時間がとてもかかるからなんですよね。それには時間を短縮すれば問題ない。それじゃあ、簡単に時間短縮するためにはどうしたらいいか？ この解決策の一つは、収集ステップと処理ステップの対象となる『物』の数を減らすことです。WeeklyReviewで対象となる『物』の数を減らすにはどうしたらいいのか？ それは、実行時に湧き出る『物』について、その場で処理ステップを実施し、2分で実行可能ならばその場で実施してしまうことです。
これって、掃除の極意である「こまめに掃除する」というのとほぼ同意だと思います。友人で、キッチンのきれいな人は、私と話している間でも、何気に食器や道具やらを拭いていたりします。この何気なく行われている動作こそが、常にきれいを保つ分け目なのでしょう。
WeeklyReviewで処理をするのが嫌になったら、丁度それが変化の境目です。これからは、日常で2分間ルールを実施する体制になったということです。WeeklyReviewでなくとも、日常生活で2分間ルールを実施していこうと改めて思った次第でございます。