仕事術に関して３冊

　わずか二回目の記事にしてこんな内容になるのは正直心苦しい。私にとって最高の読書体験とは、知的好奇心を満たすための純粋なものである。紹介する本はひたすらわくわくするものでありたい。しかしながら読書をするためには衣食住と書籍の原資が必要となり、そのための労働は避けがたいものである。労働は往々にして体力だけでなく精神力を削るものであり、せっかく賃金を得ても終業後に文字を読む気力すら削がれている場合がある。これでは本末転倒である。そこでまずは、労働において主たるストレス減となっている山積みの仕事を制御し心に平穏をもたらすために、業務における自身のタスク管理の方法を体系化することを考えた。

　とはいえ仮にも会社員として何年も働きながらも場当たり的な仕事の進め方を続けてきたアホなんて自分だけに違いない。きっと過去に同様のことを考えた人は星の数ほどいるに決まっている。賢明な人々がノウハウを蓄積していることだろう。ゼロから我流を編み出すなどという回り道はせずに、本屋へ行こう。こんな基本的なことが書かれた本なんて、もしかしたら名刺の渡し方などが書いてあるビジネスマナーの本の隣くらいに置いてあるかもしれない。

　案の定仕事術についての本は山のようにあったが、大半はワンポイントアドバイスをまとめたTIPS集のようなもので、求めていたものとは異なるように思えた。若干がっかりしつつ気分転換に技術書のコーナーを眺めると、こんな本を見つけた。我らがオライリーの、しかもエンジニアのためと銘打たれた本である。中身をめくってみたところ、内容も期待に近そうだったので購入した。

　 エンジニアのための時間管理術（Time Management for System Administrators / Thomas A. Limoncelli）

　本書には、著者が「サイクルシステム」と呼ぶツールを用いた、日々のスケジューリングやルーチンをはじめとした時間管理術が書かれている。

　大きな方針として能力やエネルギーを大事なことに集中させるという目的があり、そのために情報を一か所にまとめて記録することで脳が記憶に割く労力を減らしたり、頻度が多い業務をルーチン化することで小さな思考の負荷を減らしたりする。集中する環境を保つために、割り込みの依頼を悪印象を与えずに追い払う方法まで書かれていたりする。

　自分の求める「体系化された仕事方法」に近しい内容で、大変参考になった。 タイトル通りエンジニアに、特にシステム管理者に向けられた内容ではあるが、基本的な考え方については非エンジニアにも一読の価値はあるように思う。

　次に、あとがきでエンジニアに限らない一般向けの本として紹介されていたものも参考になりそうだったので読んでみた。

　はじめてのGTD ストレスフリーの整理術（Getting Things Done / David Allen）

　読んでみるとたしかに「エンジニアのための～」の元ネタと思われる内容も多いが、本書が対象とする範囲はより広く、仕事だけでなく人生においてこの方法を実践しようというような本である。どうやらGTD(Getting Things Done)といえば仕事術界隈（？）では有名らしく、同じ著者から同一テーマの書籍が何冊も出ていたり、調べるとOutlookをGTD用にカスタマイズする方法のページがいくつも見つかったりする。

　GTDの要点は次のリンクのワークフローに集約されているように思う。記載されている内容も、このワークフローの具体的な実践方法とその効用が大半である。

　GTDのワークフロー

　気になることすべてを一か所にまとめワークフローに沿って順次処理するだけでも、闇雲に動く場合と比べて幾分頭がすっきりするのが感じられた。しかしながら実践にあたって、ワークフローをどの程度の頻度でどのようなタイミングで処理すべきかを掴めずにいた。そんなときに再び書店を彷徨い見つけたのが次の本である。

　仕事に追われない仕事術 マニャーナの法則（Do It Tomorrow And Other Secrets of Time Management / Mark Forster）

　なんと魅力的なタイトルだろうか。本書が示すのは、今日新たに発生した仕事は集めておき、選別したうえで翌日まとめて処理する、という仕事術である。根底にあるのは、衝動に踊らされずに理性で制御しろという考え方だ。新規メールの通知になんとなく手を付けるのではなく、あらかじめ決めておいた仕事を遂行する。そのために一日の猶予を設けて、仕事の見極めを行う。組織のシステムとして即応が求められる仕事（例えば火災発生による消防署員の出動）以外には、場当たり的な対応はしない。どうしても緊急で対処が必要な場合もあるが、あまりにそれが多いのは組織やシステムに問題がある。

　回すサイクルを日単位に区切るかはさておき（多くの人は一日おきの対応では求められる業務スピードに合わないのではないだろうか）、衝動的に反応せずに一定時間の蓄積を経て選別をするという原則は大いに参考にできるかと思う。仕事に限らず日常生活でも身につまされる原則だ。また、蓄積・選別のフローは前述のGTDとも相性が良さそうである。

　現在自分は以上の３冊の内容を組み合わせて試しており、少なくとも場当たり的に対処するよりは仕事を制御可能になったように感じている。留意点として、関係者が多岐に渡りタスク間の依存関係が複雑なプロジェクトや、複数プロジェクトが並行した場合の長期的なスケジュール管理についてはこれらの本では述べられていない。今のところはプロジェクト単位でタスクをツリー状にし依存関係と期日を記入して管理しているが、このあたりは今後プロジェクトマネジメント関連の書籍を参照したい。仮にも開発業務に携わっておきながら今まで体系立った手法を学習してこなかった自分を恥じるばかりである。

　また、これらの方法を活用すればどんな量の仕事もこなせるのかというともちろんそんなわけはない。時間は有限だ。自身を管理したうえで仕事の取捨選択を組織・上司に要求することが必要だという点は「エンジニアのための～」と「仕事に追われない～」で共通して述べられているところである。GTDに関してはそもそも期日管理に関する言及がほとんどない（そういう意味では「仕事術」の本ではあっても「タイムマネジメント」の本ではない）。「トレードオフから目をそむけても、トレードオフから逃れることはできない。」のだ。

　当初は主にタスク管理によって業務量に対する制御可能感を得ることを課題とした一連の取り組みであったが、仕事のやり方を体系立てて自分の行動ルールを明文化していくことで、業務遂行自体に対しても精神的な負荷が減ったように思う。場当たりで対処していた場合にはミスが個人に帰属するように感じたが、明文化したルールに則った行動のミスはルールの不備であり、ルールの修正を考えるのみである。自身をプログラミング・デバッグしている気分になり、比較的ドライに対処できる。これは思いがけない副次効果だったので、ぜひこの方向を突き詰め、感情を切り離した業務遂行プロセスを確立したい。