計画を軌道修正するためには、時間配分の見直しが必要
いかん。(+_+) 最近、暑さで脳みそやられてきた。所用で少しの期間、出かけていたのだけれど、帰ってきてから頭の中が迷走している。何をどう計画して、どういう方向へ行けばいのか見えなくなってきた。
というのも、その原因は、出かける前にしていた作業を一時的に中断してしまったために、これまでの進行状況のいくつかの部分を忘れてしまい、どのような計画が最適なのか見えずらくなってしまったため。 ^^;
必要なのはレビュー
計画を立てるためのツールと言えば、RTM と Google タスクガジェット、そして、フリーマインドを使っている。しかし、この 3 つツール、使い方を間違えると頭を整理するどころか思考が拡散していき、余計に混乱することがある。
今、必要なのは軌道の安定を計ることであり、方向性を決めること。だから、やらなくてはいけないのはレビュー。「復習」であり「まとめ」ということになる。そして、それを元にして計画を立てなければいけない。わかっちゃいるのだけれど、つい大量に入ってくる日々の情報に惑わされ、新しいものに飛び付いてしまう。悪い癖。
レビューする時間を強制的に作る
「計画」は、計画する対象によって、非常に大きな粒度の違いが存在する。
- 年単位
- 月単位
- 週単位
- 日単位
- 時間単位
今回は狂ってしまったリズムを取り戻すために、
- 大雑把に「時間単位」で計画を立て、
- 時間を見積り、
- それを記録
していこうと思う。
なぜ、こんなことをするのかと言えば、拡散しがちな思考を強制的に方向付けるため。レビューの時間をキチンと取り、計画を考える時間もとる。スケジュールに書けばやらざる終えない。これ、ちゃんとできる人にとっては、当り前過ぎるのだけれど、
「GTD を試してみたけれど、レビューができなかったために上手く活用できなかった」
自分のようなタイプの人間には必要。なんでも明示的にするというのが結構大事。
思考の拡散と収束のバランスを取る
考える作業で、一番楽しい時間は、あまり整合性を考えずに連想と空想によって物事を関連付け、思考を拡散させるとき。無責任に考えほくそ笑む。これ醍醐味。細かいことを考えて、それを一つづつ潰していくのが楽しいと感じる人もいるみたいだが、自分はそういうのは苦手。適当に考える。これほど楽しいことはない。しかし、そればかりだと思考が収束せず、一向に前に進んだと感じることがない。やり過ぎると、逆にストレスにつながることもある。 (+_+) やはり物事にはバランスが必要。
「計画を立て、時間を見積り、評価する」というのは後者に属する。普段は、感覚に頼ることが多いけれど、細かく記録していないので見積りの精度がとても悪い。往々にして、できると考えている時間よりも少な目に見積ってしまう。これが時間を有効に使えない原因の一つ。「見積りしたときの値」と「実際に行った値」を比べることによって、自分の中の時間感覚を養いたい。
Google カレンダーで大雑把な時間管理
スケジュールを管理するためのツールはいろいろある。紙媒体から Web 上のものまで様々。紙媒体という選択も魅力的なのだけれど、ここは一つ Web で管理できるもので、なおかつ後々の連携を考え有名所を使うことにする。となればもう話は決まったようなもので、必然的に (？) Google カレンダーを使うことに。 (実はこれまで何度かチャレンジしては挫折している ^^; )
RTM を使っているならそれでいいのでは？と思うかもしれないが、スケジュールというのは時間軸に沿い、時間という均質な指標を軸にして視覚的に表示されてこそ時間感覚を養えると思うので、今回は Google カレンダーにした。 RTM はあくまでもタスクの管理であって、マクロな時間配分を決めるためのものではない。
ということで、ツールの使い分けの目処も立ってきた。 Google カレンダーでは大雑把に時間の使い方を計画するマクロな視点。その時間の中でのタスクは RTM で管理する。そして、それよりも粒度の小さい極小のタスクは Google タスクガジェットで。
要件と対策
では Google カレンダーをどう使えばいいのか？
再度、当初の要件を書き出しておく。
- 時間の見積りをしたい。
- 実績を記録したい。
- 上記二つを見て、すぐに時間配分を視覚的に把握できるようにしたい。
- 書き込みたいときに、すぐに入力できること。
要件 3 については、このために RTM ではなくて Google カレンダーを使うことにした最大の理由。特に、昨日と明日の予定を見ながら今日の時間配分を決めるときは、
を参考に。
要件 4 については、Prism を用いて Google カレンダーを独立したアプリとして起動するようにした。 (cf. ウェブサイトを Prism for Firefox を使って独立したアプリケーションに変換)
問題は要件 1, 2 。これに関しては、
を参考にした。そこでは、Google カレンダーにおいて「予定」と「実績」の二つのカレンダーを作成し、それぞれに記入する方法が紹介されていた。
次の図の「□大橋の予定」という緑のカレンダーが「予定のカレンダー」であり、朝の時点でお互いにそれぞれの「予定のカレンダー」を登録した状態で仕事を始めます。そして、仕事を片づけながら「実績のカレンダー」である「■大橋の実績」という青いカレンダーに実績を書き加えていくようにします。
(上記より)
上記は、二人で作業を進めていくときのことが書かれていたが、これを一人で行うことに。
時間を見積るための基準「リスクファクター分析」
後は、時間の見積りの方法が問題となる。これが一番難しい。何か大雑把でもいいから指針となるものはないだろうか？
| Javaデバッグ明快技法 | |
 |
鈴木 義幸
おすすめ平均 
あらゆる言語のプログラマに
Amazonで詳しく見る by G-Tools |
上記の本には
「リスクファクター分析」(p64)
という手法が書かれている。これを使うとプロジェクトに必要な時間を 8パーセントの誤差の範囲で見積ることができるらしい。どのくらい有効でメジャーな方法か知らないけれど、指針にしてみることに。
やり方は、
- プロジェクトをタスクに分割する。
- 次にタスクにかかる時間を見積る。
ここが特徴的。
方法が正確にわかっているものとして見積ります。ここでは調査の時間を考慮せず、タスクの完了に必要な時間のみを見積ります。(太字は引用者による, p66)
「方法が正確にわかっていた」としても、経験のないものを見積るというのはかなり難しい。これを次のステップで吸収する。
やや主観的な基準をベースとして、タスクの危険度を決定し、 A ~ F でのランク分けをします。
6 段階、A ~ F の基準を要約すると、次のような感じ。
- A : × 1 : 何度も経験した作業で、やり方を熟知している。
- B : × 2 : 経験はあるが、どうやってやるか覚えてはいない。しかし、何を参考にすればよいのかの検討はついている。
- C : × 4 : 方法は同僚の誰かが知っているだろう。
- D : × 8 : 解決策はあるようだが、現時点ではどのように解決すればいいのかわからない。
- E : × 16 : 方法を考えることは大変だけれど、なんとかできそう。
- F : × 32 : 不可能だと思うけれど、それを証明できない。
ただし、基準の横に記載されれている
× ○○
という数値は、最初に見積りをした時間との積をとり、最終的な見積り時間を算出するためのもの。数値は自体は 2 の 0乗、1乗、2乗...となっている。つまり、不確定な要素があるほど、そのタスクの完了までに指数関数的に時間が必要となると仮定しているということ。
最初の見積りのときに、未知の事柄に対して、「方法がわかっているものとする」という前提が難しい。この辺はあまり考えても仕方がないので、
- 大雑把に「順調にタスクをこなせた」場合の楽観的な見積り時間を考え、
- 次にタスクに対して、「不確定要素がどのくらいあるかと思うか」を 6 段階で評定し、
- それに対して、上記のような数値との積をとって見積り時間にする
とりあえずそんな風に考えておくことことにする。
