2007-01-14 [Sun]
「エンジニアのための時間管理術」再読メモのラスト。
-------
システムに関する見地
�△泙任鮟颪い浸�はGtdStyleWikiメインだったのだが、わずか2週間で目まぐるしくシステムを変えてしまい、現在は以下のようになっている。
◎ベース
タスク・ToDo管理
Remember The Milk（RTM）
※USBに入れているFirefox Portableで見る。
◎サブステーション
システム手帳
フランクリン・プランナー／ポケットサイズ、デイリー見開き2ページ
ベースは最終的な情報の蓄積場所で、WEB上のRTMに入力・処理する。
手帳は移動中のサブステーションとして機能させる。
PCを持ち運べない場所や、即効性が求められる際に手帳で管理しておき、最終的にRTMに落とし込む。
ただし整合性を意識しすぎると面倒なので、完全に同期しなくてもよい。
要するに自分の中でどちらかを使って管理できていればそれでよい。
◎カレンダー
Googleカレンダー（RTMと連動）
またはフランクリン・プランナー
カレンダーはRTMと連動させることに成功したが、あまり参照していない。
RTMとの同期が行われるのが遅すぎるので、使えない印象。
無論Googleカレンダー単体としては優れているが、そうなると
RTMと連動する部分が生きてこず、使い方が難しい。
最終的にはプランナーだけの方が便利なような気がしている。
◎その他新しく加えたアイテム
･資格取得兼プライベート日記
PukiWiki
･iPodの再生回数履歴出力
Last.fm
･Google版OneNote？
Google Notebook
といったところ。
あまりタスクやToDoには関係ないが。
-------
前回第4章まで見ていたので、第5章。
5章は筆者の提唱・使用するサイクルシステムのまとめ。
サイクルシステムは単純に言うとカレンダーからその日の予定に落とし込み、その日のタスクを時間換算で設定することで一日の予定を立て、出来ないタスクを明日に回すことで一日の仕事を無理なく計画できるシステムの事。
特に、社内のシステム管理者のような、PCでのルーティンワークメインだが割り込みが数多く入るタイプの職業に有効と思われる。
フランクリン・プランナーとも似ているが、思想的な部分はない。
専ら実践的なテクニック、というか筆者の行っている具体例が延々と並べられる。
以下中身を見ていく。
･一日の初めに計画を立てる。
カレンダーから予め決まっている予定や会議を、一日のスケジュールに落とし込む。
プランナーでいえば、Appointment Scheduleに入れる。
･作業項目をリストアップし、埋めていく。
プランナーでいうとPrioritized Daily Task Listになる。
プランナーでは時間を書く欄がないが、サイクルシステムでは大まかな所要時間も入れている。
例えばBOBのPCのインストールに3Hといった具合。
また、留守番電話のメッセージも聞いてタスクリストに書き込み、聞いたものは線を引いて済みにしているが、これは必要ないだろう。
もしやるとすれば、伝言を誰かに伝えるといったタスクを書き、すぐにメールかメモを書いて伝えるといった対応を取る方が良い。
･タスクをリストアップ後、それぞれに優先順位を設定しスケジュールを組みなおす。
プランナーで言うとABCの欄にA1やB2といった感じで入れる。
全ての作業リストについて一覧が出来ると、優先順位とかかる時間が分かる。
時間の合計が8時間以内であればよいが、それを超えている場合は、優先順位が低いものを翌日に回すように設定しなおす。
プランナーでいうと ⇒先送り となる。
また、RTMでいうようなProjectの項目（複数のアクションが必要になるもの）については、作業を更に細かく小分けにし、小さい単位で落とし込んでいく。
このようにして優先度の高い作業から今日中に終わるように計画し、実際に作業に取り掛かる。
一日の最後に全ての項目が済み、または翌日に延期になっていることを確認し、退社する。
翌日、出社後に、また同じように行う。
カレンダーから今日のスケジュールに落とし込み、作業リストの一覧を作り、優先順位の高い作業から順に取り掛かる。
昨日延期した作業が今日の作業項目に上がっているはずなので、それらも処理できれば行う。
基本的にはこれだけである。
他には、筆者は紙とペンによるPAAを使っているが、PDAを使っても良いし、自分が使い慣れたシステムを使うよう薦めている。
この辺はGTDの概念と共通している。
上記を見ていくと、筆者が使っているというだけあり、フランクリン・プランナーだけで十分実践できそうな気がする。
-------
6章。
6章ではサイクルシステムにおけるカレンダーの使用法について記される。
サイクルシステムではカレンダーを主に3つの目的で使用する。
1.今日のスケジュールよりもずっと先の予定や行事、会議の時間をふさいでおく。
2.何かのイベントの告知や重要な期日を書き込んでおく。
3.PAAを使用している場合、現在使用しているページよりもずっと先の項目をカレンダーに記録する。
P101 PAAでの繰り返し作業への対処
はプランナーを使ったリフィル運用として参考になる。
-------
7章。
サイクルシステムにおいて目標を立てるやり方。
目標のスパンは長期的で人生における目標設定となる。
基本的にはフランクリン・コヴィーが提唱しているミッション・ステートメントと同じ。
-------
8章。
サイクルシステムにおける優先順位に関する提言。
基本的に作業は優先順位の高いものから片付けていけばよいが、機械的にやるのではなく、幾つかのメソッドに従って行った方がいいという話。
例えば、
･ユーザが急いでいる処理
早くアカウント作らないと、メールが取れないユーザからクレームが来る。
･行った後に”待ち”が入るタスク
注文をして品物が届くのを待つためには、早く注文書に着手しないといけない。
･故障
システムに障害が発生した場合は全てのタスクを中断してでも回復に着手すべきである。
こういった例のように、機械的にABCで作業の優先度を決めても、実際にユーザの立場から出来るだけ早く行った方がいいタスクはないかどうか、再度検討する。
ユーザだけでなく、上司からの依頼も、他のタスクより優先させて出来るだけ早くやるべきである。
ほかには、上司の権限を使ってタスクを他の担当者に割り振ったり、或いはタスク自体を行うかどうかを上司に委任する「上方委任」というのが面白い。
-------
9章。
ストレスと休暇について。
割愛。
-------
10章。
電子メールの管理。
割愛。
-------
11章。
時間の浪費。
オフィスでの交流ってのは俺の苦手な部分だけど、これ意外とばかに出来ないんだよね。
以前の拠点ではプログラム打っては色んな部署に顔を出し、設計書書いてはまたウロウロって人がいたけど、今考えると、情報収集とかコミュニケーションを兼ねてしていたんだと思う。
（単なる気分転換かもしれないけど。）
普通の人は彼みたいに大胆になれないけど（彼は物凄く出来る”スーパースマート”だったので黙認されていた。）、昼休みとか、交流は出来るだけしたほうがいいというのが今の俺の意見。
ほかにはP164〜165で如何に効率よく会議を行うかについて述べられている。
P166テレビを見ない。
これはすごい同感だなあ。
俺ももうテレビなくても全然困らない生活してるし。
まあ災害が起きた時に映像が見れるってのと、「プロフェッショナル仕事の流儀」見るくらいかな。
でもほとんど見てない、というか見たい番組がない。
テレビ大好きっ子だった俺が見向きもしないというのは、単に飽きたのか、コンテンツ自体がつまらなくなってるのか、或いはその両方か。
P168の部屋の清掃サービスってのはどうなんだろう。
日本だとどのくらいかかるんだろうか。
-------
12章。
社内のITリポジトリの文書化について。
Wikiを使うことへの提言。
社内ではないが、俺もプライベートで使い始めている。
mixiが交流促進兼くだけたフォーマットでのアウトプットだとすると、Wikiは非交流兼体系だったフォーマットでのアウトプット。
無論これは俺の例に過ぎず、交流兼くだけたフォーマットのWikiユーザもたくさんいるだろう。
Wikiは手っ取り早く情報を公開したりシェアするには便利なツールだが、唯一記法が面倒くさいのが難点。
HPビルダーのようなコンテンツジェネレータがあれば便利なんだけど。
-------
13章。
自動化。頻繁に行う作業をマクロやシェルで自動化する案。
まあ、社内管理者とか運用系のサーバエンジニアでもない限り、あまり関係ない話ではある。
もしくは専門書をあたった方がいい。
-------
以上。
 | エンジニアのための時間管理術 Thomas A. Limoncelli 株式会社クイープ オライリー・ジャパン 2006-10-19 売り上げランキング : 2237 おすすめ平均  Amazonで詳しく見る by G-Tools |
-------
システムに関する見地
�△泙任鮟颪い浸�はGtdStyleWikiメインだったのだが、わずか2週間で目まぐるしくシステムを変えてしまい、現在は以下のようになっている。
◎ベース
タスク・ToDo管理
Remember The Milk（RTM）
※USBに入れているFirefox Portableで見る。
◎サブステーション
システム手帳
フランクリン・プランナー／ポケットサイズ、デイリー見開き2ページ
ベースは最終的な情報の蓄積場所で、WEB上のRTMに入力・処理する。
手帳は移動中のサブステーションとして機能させる。
PCを持ち運べない場所や、即効性が求められる際に手帳で管理しておき、最終的にRTMに落とし込む。
ただし整合性を意識しすぎると面倒なので、完全に同期しなくてもよい。
要するに自分の中でどちらかを使って管理できていればそれでよい。
◎カレンダー
Googleカレンダー（RTMと連動）
またはフランクリン・プランナー
カレンダーはRTMと連動させることに成功したが、あまり参照していない。
RTMとの同期が行われるのが遅すぎるので、使えない印象。
無論Googleカレンダー単体としては優れているが、そうなると
RTMと連動する部分が生きてこず、使い方が難しい。
最終的にはプランナーだけの方が便利なような気がしている。
◎その他新しく加えたアイテム
･資格取得兼プライベート日記
PukiWiki
･iPodの再生回数履歴出力
Last.fm
･Google版OneNote？
Google Notebook
といったところ。
あまりタスクやToDoには関係ないが。
-------
前回第4章まで見ていたので、第5章。
5章は筆者の提唱・使用するサイクルシステムのまとめ。
サイクルシステムは単純に言うとカレンダーからその日の予定に落とし込み、その日のタスクを時間換算で設定することで一日の予定を立て、出来ないタスクを明日に回すことで一日の仕事を無理なく計画できるシステムの事。
特に、社内のシステム管理者のような、PCでのルーティンワークメインだが割り込みが数多く入るタイプの職業に有効と思われる。
フランクリン・プランナーとも似ているが、思想的な部分はない。
専ら実践的なテクニック、というか筆者の行っている具体例が延々と並べられる。
以下中身を見ていく。
･一日の初めに計画を立てる。
カレンダーから予め決まっている予定や会議を、一日のスケジュールに落とし込む。
プランナーでいえば、Appointment Scheduleに入れる。
･作業項目をリストアップし、埋めていく。
プランナーでいうとPrioritized Daily Task Listになる。
プランナーでは時間を書く欄がないが、サイクルシステムでは大まかな所要時間も入れている。
例えばBOBのPCのインストールに3Hといった具合。
また、留守番電話のメッセージも聞いてタスクリストに書き込み、聞いたものは線を引いて済みにしているが、これは必要ないだろう。
もしやるとすれば、伝言を誰かに伝えるといったタスクを書き、すぐにメールかメモを書いて伝えるといった対応を取る方が良い。
･タスクをリストアップ後、それぞれに優先順位を設定しスケジュールを組みなおす。
プランナーで言うとABCの欄にA1やB2といった感じで入れる。
全ての作業リストについて一覧が出来ると、優先順位とかかる時間が分かる。
時間の合計が8時間以内であればよいが、それを超えている場合は、優先順位が低いものを翌日に回すように設定しなおす。
プランナーでいうと ⇒先送り となる。
また、RTMでいうようなProjectの項目（複数のアクションが必要になるもの）については、作業を更に細かく小分けにし、小さい単位で落とし込んでいく。
このようにして優先度の高い作業から今日中に終わるように計画し、実際に作業に取り掛かる。
一日の最後に全ての項目が済み、または翌日に延期になっていることを確認し、退社する。
翌日、出社後に、また同じように行う。
カレンダーから今日のスケジュールに落とし込み、作業リストの一覧を作り、優先順位の高い作業から順に取り掛かる。
昨日延期した作業が今日の作業項目に上がっているはずなので、それらも処理できれば行う。
基本的にはこれだけである。
他には、筆者は紙とペンによるPAAを使っているが、PDAを使っても良いし、自分が使い慣れたシステムを使うよう薦めている。
この辺はGTDの概念と共通している。
上記を見ていくと、筆者が使っているというだけあり、フランクリン・プランナーだけで十分実践できそうな気がする。
-------
6章。
6章ではサイクルシステムにおけるカレンダーの使用法について記される。
サイクルシステムではカレンダーを主に3つの目的で使用する。
1.今日のスケジュールよりもずっと先の予定や行事、会議の時間をふさいでおく。
2.何かのイベントの告知や重要な期日を書き込んでおく。
3.PAAを使用している場合、現在使用しているページよりもずっと先の項目をカレンダーに記録する。
P101 PAAでの繰り返し作業への対処
はプランナーを使ったリフィル運用として参考になる。
-------
7章。
サイクルシステムにおいて目標を立てるやり方。
目標のスパンは長期的で人生における目標設定となる。
基本的にはフランクリン・コヴィーが提唱しているミッション・ステートメントと同じ。
-------
8章。
サイクルシステムにおける優先順位に関する提言。
基本的に作業は優先順位の高いものから片付けていけばよいが、機械的にやるのではなく、幾つかのメソッドに従って行った方がいいという話。
例えば、
･ユーザが急いでいる処理
早くアカウント作らないと、メールが取れないユーザからクレームが来る。
･行った後に”待ち”が入るタスク
注文をして品物が届くのを待つためには、早く注文書に着手しないといけない。
･故障
システムに障害が発生した場合は全てのタスクを中断してでも回復に着手すべきである。
こういった例のように、機械的にABCで作業の優先度を決めても、実際にユーザの立場から出来るだけ早く行った方がいいタスクはないかどうか、再度検討する。
ユーザだけでなく、上司からの依頼も、他のタスクより優先させて出来るだけ早くやるべきである。
ほかには、上司の権限を使ってタスクを他の担当者に割り振ったり、或いはタスク自体を行うかどうかを上司に委任する「上方委任」というのが面白い。
-------
9章。
ストレスと休暇について。
割愛。
-------
10章。
電子メールの管理。
割愛。
-------
11章。
時間の浪費。
オフィスでの交流ってのは俺の苦手な部分だけど、これ意外とばかに出来ないんだよね。
以前の拠点ではプログラム打っては色んな部署に顔を出し、設計書書いてはまたウロウロって人がいたけど、今考えると、情報収集とかコミュニケーションを兼ねてしていたんだと思う。
（単なる気分転換かもしれないけど。）
普通の人は彼みたいに大胆になれないけど（彼は物凄く出来る”スーパースマート”だったので黙認されていた。）、昼休みとか、交流は出来るだけしたほうがいいというのが今の俺の意見。
ほかにはP164〜165で如何に効率よく会議を行うかについて述べられている。
P166テレビを見ない。
これはすごい同感だなあ。
俺ももうテレビなくても全然困らない生活してるし。
まあ災害が起きた時に映像が見れるってのと、「プロフェッショナル仕事の流儀」見るくらいかな。
でもほとんど見てない、というか見たい番組がない。
テレビ大好きっ子だった俺が見向きもしないというのは、単に飽きたのか、コンテンツ自体がつまらなくなってるのか、或いはその両方か。
P168の部屋の清掃サービスってのはどうなんだろう。
日本だとどのくらいかかるんだろうか。
-------
12章。
社内のITリポジトリの文書化について。
Wikiを使うことへの提言。
社内ではないが、俺もプライベートで使い始めている。
mixiが交流促進兼くだけたフォーマットでのアウトプットだとすると、Wikiは非交流兼体系だったフォーマットでのアウトプット。
無論これは俺の例に過ぎず、交流兼くだけたフォーマットのWikiユーザもたくさんいるだろう。
Wikiは手っ取り早く情報を公開したりシェアするには便利なツールだが、唯一記法が面倒くさいのが難点。
HPビルダーのようなコンテンツジェネレータがあれば便利なんだけど。
-------
13章。
自動化。頻繁に行う作業をマクロやシェルで自動化する案。
まあ、社内管理者とか運用系のサーバエンジニアでもない限り、あまり関係ない話ではある。
もしくは専門書をあたった方がいい。
-------
以上。
