スキップしてメイン コンテンツに移動

Reading: エンジニアのための時間管理術

冒頭でまず6つのテーマについて述べている。

1. タイムマネジメントに関するものをすべて 1 か所にまとめる。
2. 今取り組んでいることに頭を使い、それ以外のことには外部ストレージを使用する。
3. 定期的に行うことに対しては日課(ルーチン)を定める。
4. 習慣やモットーを身につけることにより、事前に決断を下す。
5. プロジェクトタイムでは集中力を維持する。
6. これらのツールを仕事以外の時間にも応用し、日常生活を改善する。

「それを気の利いた頭文字にうまく組み入れるとか?」 いいえ、そのようなことは絶対にありません。

この辺りが地味にクスッとさせられた。こういう調子が終始挟み込まれる。

ちなみに、6つあって、最初の章でプロジェクトタイムでは集中力を維持するの深堀り、次の章でルーチンについて深掘りしていたので、この調子で6つのテーマごとに進むのかと思って読み進めていたけれど、他の点については章を進めながら随所に散りばめられている感じだった。

とはいえ、手元ではそれらしくメモしたのでそのようにまとめてみる。

1. タイムマネジメントに関するものをすべて 1 か所にまとめる。

  • PDA(今で言うスマホ)かPPA(要は手帳的な)いずれかでまとめる
  • 著者はPPAを使用していて365日分のルーズリーフを買って対応しているらしいがその理由はそれに慣れ親しんでいるからだという


2. 今取り組んでいることに頭を使い、それ以外のことには外部ストレージを使用する。

  • 今日やること、明日やること、それぞれの優先度は何か
    • 優先順位は3つしかない
      • 期限が今日で今すぐ終わらせる必要がある
      • 期限が近づいている
      • それ以外
    • そのほかの優先度の付け方に関すること
      • 要求によっては急ぎのものがある
      • 「急いで着手し、待つ」作業はすぐに開始する
      • 要求によっては長くかかるものがある
      • システムが故障から復旧するまですべての作業を中断する
      • 「ブラックホールタスク」には、すぐに行われることが期待される作業が完了するまで、手をつけない
  • 人生のおける目標、1年後、5年後何をしたいか、そのためには何が必要かを明確にして定期的に振り返る
    • 目標を再確認する日を決める
    • 具体的に目標までに必要なアクションを洗い出して実施していく


3. 定期的に行うことに対しては日課(ルーチン)を定める。

  • いつやっても良いがやらないと問題になることは定期的に実施するタイミングやトリガーを決めてしまう
    • 自分の場合だと会社の打刻や勤怠提出など
    • 他にも掃除の類や読書、技術習得活動、運動、レシート整理、日誌更新、机の整理……


4. 習慣やモットーを身につけることにより、事前に決断を下す。

  • いつやっても良いがやらないと問題になることは定期的に実施するタイミングやトリガーを決めてしまう

5. プロジェクトタイムでは集中力を維持する。

  • 誰かがあなたに何かを頼んできたとして、それはある問題の対処に一番あなたが最適だと思ったから。なので、プロジェクトタイムだとしても無下に扱ってはいけない。相手の要求を受け入れる姿勢を見せる。
    • 相手を責めるのではなくて、担当者を明らかにするとか、自分に聞かれなくてもわかるようにするとか、手の打ちようがあると。
    • ドアから向かって一直線の間に自分以外の誰かを配置すれば、一番近いからという理由で声をかけられる可能性は減る。
  • 出社後最初の1時間をメールチェックに当てない
    • 集中力が高くプロジェクトを遂行可能な時間帯により適した活動をする
    • 通知はオフにする


6. これらのツールを仕事以外の時間にも応用し、日常生活を改善する。

  •    自分の場合だとTrelloが良さそう

ルーチンと習慣・モットーの部分はちょっと話が曖昧で、どう切り分けたらいいかわからないところもあった。まあそこを明確に分けても分けなくても価値に大きな差異はなさそう。
人生の目標の話のあたりがなんだか以前に少し取り組もうとしていたGetting Thing Done(GTD)に似ていると思ったら、最後におすすめの書籍として言及していたので著者も影響を受けているらしい。

また、タスクの発生時には次の3つのいずれかで対応するとのこと。割り込み主導(到着順)はやめるべきと書いていた。

  • 委任(より適切な人に頼む)
  • 記録(後でやることとして書き残す)
  • 実行(上のパターンがダメだった場合に直ちに実行する)

頼まれてから完了させるまでに2分もかからないことはいちいちメモせずさっさとやった方がいいとのことで、その辺りも実践的で良かった。

エンジニア(システムアドミニストレーター)向けということで、負荷が高まってしまっている時の喩え話もわかりやすい。

ネットワークの負荷が低い場合は、どのような方法でもうまくいきますが、ネットワークの負荷が高い場合は、より構造化されたシステムが必要です。作業リストが単純である場合は、どのような優先順位方式でもうまくいきますが、依頼が殺到している場合には、より高度な手法が必要です。
ただし、ネットワークが混雑してくると、QoS 方式でないスイッチは、最後に受け取ったパケットを消失させます。 要するに、新しいパケットを保持するためのバッファスペースが残っていないので、 そのパケットを無視するのです。QoS 方式のスイッチは、ネットワークの混雑に別 の方法で対処します。バッファがいっぱいになったら、新たに受け取ったパケットを消失させるのではなく、バッファの「途中」から優先順位の低いパケットを選び出し、それを削除するのです。


ちなみに書かれたのが2003年なので仕方がないけれど、2020年の今では消えてなくなるインクは、少なくとも日本では割と普遍的な気がする。

消えてなくなるインクはマンガの中の話ですし、犬が宿題を食べてしまうなんてこともありません。