「エンジニアのための時間管理術」を読んだ

今更感はありますが、 エンジニアのための時間管理術 を読みました。

概要

2005年の本で、訳書です。原題は「Time Management for System Administrators」です。 前書きにはプログラマにも役立つはずだがプログラマを対象として書いたわけではないと明言されています。 SA（システム管理者）つまり IT を専門にはやっていない会社のサーバーの管理などをしている部門の人（たぶん。私のイメージ。）向けに書かれた本のようです。 バックアップなどの定期的に実施するタスクや、突発的なトラブルへの対応などで割込みが多い中で、 いかに効率的に仕事を片付けるか、みたいな本です。

主に（特に前半で）語られるのは PDA(Personal Degital Assistant) もしくは PAA(Personal Analog Assistant) の活用を前提としたタイムマネジメント法です。 本書では総称して「オーガナイザー」と呼ばれています。 2005年の本なので古いです。PDA は今ではスマホで事足ります。 本書では「まだ PDA には○○の機能がないので云々」という記述がちょいちょい出ますが、 今であれば大抵スマホを使えば解決するのでその辺は読みながら「今の技術でやるならどうするか」を考えるきっかけにもなります。

時代的な違いとあとは文化的な違いもあるので、書かれていることをそっくり真似する（そもそも著者は本国での読者に対してもそのようなことは期待していませんが）ことができず、 必ず今この環境で自分にはどういうことができるのかを考える必要があるのは真面目に読む側にとっては学びを実践する第一歩になります。 あと、急に尖った発言でアレですが、日本人が「欧米ではみんなこうやっている。日本は時代遅れ！」みたいに語っちゃう系統ではないのもいいですね。 この手の本は選び方を間違えると意識高い系著者の輝かしい経歴（国際派！）を自慢するセルフブランディングの道具になりがちですからね。

いかにも欧米的な文体で読者に対して語りかけるような感じ（いわゆる「軽妙な語り口」というやつなのでしょうか）なので読みやすいです。 良い意味でエンジニアというかギークらしい理屈っぽさがあり、読者が読みながら「理想そうだけど現実にはできないんだって」と思ったところについては、 必ずセルフ反論をして現実的な解決策を示したり時には読者の中での「現実」が半分幻想であることなどを気付かせてくれます。

フワッとした感想だけだとすぐ忘れるので章ごとのあらすじやら感想を書きました。 全13章ありますが1章あたり10～20ページ程度なのでサクサク読めます。 各章の末尾には「まとめ」としてその章での簡潔な概要が箇条書きで示されますが、極力それをパクらないようにしながら書きました。

1章 タイムマネジメントの原則

タイムマネジメントの情報（スケジュールとかタスク一覧とか）は一か所に統合しましょう的なことが書かれています。 そしてタイムマネジメントの実践は習慣化して余計なことに脳を使わないようにしよう、という割と基本的なことが書かれています。イントロみたいな章です。

2章 集中と割込み

どうやって自分が集中できる環境をつくるかという話です。 それは PC の使い方の Tips のようなものであったり、早めにきて割込みが入りづらい時間に仕事を片付けようという話であったりします。 そして、割込みがあった場合の対処法が解説されています。 委任・記録・実行という3段階で述べられています。 ほかに対処できる人がいれば、その人に「委任」する。 自分しか対処できない内容でも緊急でなければそれを「記録」する。 本当に重大な内容の場合は自分の手を止めて対処し「実行」する。 という具合です。「記録」の段階は「記憶」にとどめておくのではなくきちんと「記録」するというのが大事みたいです。 忘れないという意味以上に相手をその場で満足させるために重要だということが述べられています。 逆の立場で考えたら非常にわかることです。

3章 ルーチン

ルーチン、日課です。 繰り返し発生するタスクは習慣化してそこに頭を使わなくもいいようにしよう、そしてそのルーチン化するための約束やタスクなどを記録するオーガナイザーを常に携行しよう、という話です。 筆者が実践しているルーチンが10種類、詳細に語られているので、参考にしやすいです。 スマホをちゃんとオーガナイザーとして使いこなせていればスマホはいつも持ち歩くのでやりやすいですね。 ただ職場ではスマホ禁止、とかであればそれ用に別のものを使用することも考えないといけないかもしれません。 セキュリティの要件で職場に会社貸与PC以外が持ち込めない場合はそれこそ PAA というか手帳を使いこなす必要があります。

4章 サイクルシステム

著者が試行錯誤の末に確立したという「サイクルシステム」についての概要が説明されます。 具体的なメソッドについては5, 6, 7章で説明されます。

予定やタスクについては発生し次第オーガナイザーに記録しておくと、そこで一旦その予定やタスクについて忘れておくことができます。 それによって生じた脳のリソースをもっと重要でクリエイティブなことに回せます。 まぁよくある話です。

5章 サイクルシステム：作業リストとスケジュール

やるべき作業一覧について、使える時間や優先度に基づいて順番を決めます。 そしてどうやっても定時内に収まらない場合は優先度の低いタスクを翌日に回すことができます。 なんとなく目の前にあるタスクの山をちまちま処理し、いって定時になったらできなかった分は翌日に回す、もしくは残業して間に合わせる、 というやり方よりよほど健全です。 ここら辺は PDA 、PAA 両方についてオススメの方法が詳細に語られます（改めて文章化するのはあまり意味がないので詳細は書きません）。

6章 サイクルシステム：カレンダーの管理

前章では、1日2日単位でタスクの管理をする方法について説明されていますが、 この章ではカレンダーを使って長いスパンでのタスクの管理について説明されます。 大局的な予定を考えるので、キャリアプランを考える場合には非常に重要です。 また、年間での会社のスケジュール（繁忙期はいつとか）を把握してそれに合わせたスケジュールを組むことも大切です。

仕事用のカレンダーとプライベートのカレンダーを一つにまとめると両者の間で矛盾が生じにくく、 プライベートの大事な予定を逃すことがなくなるのでオススメらしいです。

7章 サイクルシステム：人生の目標

この章では前章（年単位）よりさらに大局的な計画、目標について考えます。 1年、5年、10年？といったスパンです。 その場合は「いつまでに」と「具体的な完了条件」を定めることが重要です。 そうでないと曖昧なままズルズルいってしまうので。

そして、5~7章までの流れを逆に行うことで自分の人生の目標を果たすために必要な日々のタスクが決っていくわけです。

8章 優先順位

いかにしてその人にとって、また周囲の環境にとって適切な優先順位を決めるかの話です。 1日の中でのタスクの優先順位も緊急度以外の判断基準があります。 例えば時間のかかるインストールとかアップデートなんかはさっさとやって放置した方がいいですよね。 あとは顧客対応とか。

プロジェクトの優先順位についての考え方もいろいろ参考になります。 お金をもらって仕事をしている以上、「簡単だけど表面的な効果しか生まないプロジェクト」より「困難だけど大きな成果が得られるプロジェクト」を優先しろという話です。

上司に自分のキャリアプランについて明確に語っておくのも重要というより必要だといいます。 そうすることで上司はそのキャリアプランに対して有益なプロジェクトを優先的に回してくれるはずです。 それが上司の仕事なので。 また、上司が特に熱を入れて取り組んでいるプロジェクトには自分の方から貢献できるようにすると良いらしいです。 それはそのことが美徳だとかいう意味ではなく上司からの信頼が厚くなれば単純に自分も得をするからです。 さっき述べた自分のキャリアプランにとって有益な仕事を回してくれることも当然多くなるでしょう。

9章 ストレスの管理

個人的にとても好きな章です。 下手な自己啓発よりよほど地に足のついた議論で、「そりゃそうでしょ」と思ってしまいがちな内容でも実際に著者の語りを読むとあまりの説得力にスカッとする、そんな感じです。 休暇の過ごし方についての節では「本当にリラックスした状態になるまで3日を要する」と書かれていて大型連休の前半は引きこもることが多い私には救いにもなりました。

また、仕事のメールは絶対に見るなというのもありました。 実際、大規模障害みたいな本当の緊急事態は向こうから連絡来ますしね。 そして休暇を取るためには自分が休んでも大丈夫な環境を作るのが必須なのでそれについても説明されます。 自分が休む期間だけなんとかなれば良いので今の自分のタスクを完璧に引き継げるようにする必要などないことも説明されます。 それでもどう足掻いても休めない、というのは状況がおかしくてそのタスクを割り振った上司のミスであることは明らかなのでちゃんとそれを表明しよう、という感じです。 ありがちな言い訳を粉砕していく感じがいいですね。 働き方改革だなんだとか騒がなくてもここに書いてあることを実践すればそれで済む話なのでは、と思いました。

10章 電子メールの管理

『ほとんどの SA は電子メールを管理するのではなく電子メールに管理されています。』と冒頭で語られます。 反論できない。 ここではとにかくメールは全て削除 or アーカイブするのが良い、というスタンスで議論が進んでいきます。 このご時世だとアーカイブはほぼ無限の容量が確保できるのですぐに実践できます。 1年前のメールを見返すことはあるのか？仮にもしその必要があれば絶対にリマインドなりが来るはずです（逆の立場ならそうするでしょう）。 また、受信したメールを振り分けるときに分類を詳細にしても無意味どころか逆効果だと述べられます。 几帳面な人ほど陥りやすそうですね。 分類する作業にかける時間や後から探す際のことを考えれば納得です。

11章 時間の浪費

言うまでもなく時間の浪費をなくそう、という章です。 2ちゃんねるのまとめサイトを毎日ひたすら巡回して読み漁っていたころを思い出します。 新着の記事を見つけて読む手順をいくら効率化しても、記事を読む習慣そのものをやめた方がはるかに時間の節約になります。 自分が何かしらに対して時間を浪費していることをまず自覚し、そしてその習慣を絶つことが必要です。 例えば未読のメールを延々と消化し続けたり、重要ではないしょうもないタスクにひたすら時間をつぎ込んだり、などです。

無駄な会議をなくすための掟についての説明を読むと、自分の職場の優秀な人がとうに実践していた、というありがちな展開もあります。 定期的な進捗を共有する「進捗会議」と何かの作業を完結させるための「作業会議」とを明確に区別することが大切だと述べられています。 進捗会議で自分のつまっているところを議論しても他の人にとってはただ時間を奪っているだけに等しいのでやめよう、などです。 ちなみにそういう場合はその進捗会議の直後に議論することを約束すれば、関係者とのスケジュール合わせをまた頑張る必要もないので良いと書かれています。

12章 文書化

文書化しようという章です（そのまま）。 いわゆる業務の標準化と似た側面があります。 もちろん紙の文書ではなく Web 上のコンテンツとしてです。 後述するように要は Wiki を書けというお話です。

作業手順ノウハウの属人化を防ぐことができるので自分が休暇を取りやすくなります。 また、その作業をやることになった人がその度に毎回広大なネットの海を調べたり試行錯誤して時間を使ったり、 経験者に質問してその人の時間を奪う必要がなくなります。 もちろん顧客向けであれば「読めばわかる」ようなことで毎回問い合わせが来ることを避けられることになります。 ここでいきなり私個人の感想を挟んで恐縮なのですが、Wiki を書くのは良いアウトプットになるので修行の身としてはそういう利点も美味しいです。

じゃあどんな文書を作るのかですが、顧客向けの文書であればどこにヘルプを投げればよいのか（お問い合わせ先）や明文化すべきポリシーなどが挙げられます。 たしかにそうだ。 社内向けのものなら作業内容のチェックリストとかですね。 このとき作り込み過ぎるのはよくないです。最低限箇条書きになっていれば良いのです。 いつでも修正できますし Wiki を読んだ他の人がやってくれるかもしれないですし。

そして Wiki を活用せよというお話になります。 最近のメジャーなプロジェクト管理ツールには大抵 Wiki が付いています。 だいたい Markdown 記法やバージョニングが有効なので、サクッと箇条書き程度で書いて社内で見られるようにしておけば、 誰かがいい感じに補足してくれるかもしれませんし何かあれば切り戻しも容易です。 Markdown って素晴らしいですよね。 学習コスト低いですし少しでも慣れればプレビューしなくてもほとんど同じぐらい整った文書として読めてしまいます。

13章 自動化

頻繁に行う単純作業はスクリプトを書いて自動化しようぜという章です。 凡ミスを防ぎ（再現性）、作業の適用対象が増えても負担が変わらない（スケーラビリティ）という、 少なく見積もっても二つのメリットを同時に享受できるのでしない手はないというやつです。 また、一度だけ行う難しい作業についてはその作業ログを残せるという意味で自動化することが重要です。

頻繁に行う難しい作業は？と思いましたが、その場合は上司に相談して自動化のためだけに工数を使えるように交渉するか SaaS を導入するよう交渉する、 と書かれておりこういう方針を明確に区分するっていいなと思いました。 意地で解決するのではなくその難易度相応の対応法を上司の協力を仰ぎながらやる。 当たり前のことのようですが「スクリプトを書く」ことと「SaaS を導入する」では粒度が全然違うので、 実装のことだけ考えているとかえって見えてこないなんてことはよくあります。 ちょっとまとめっぽいことを言うと、本書ではこの手（そもそも論）の解決策の提言がたくさんあるので、ハッとすることが多いです。 一般論としては理解しているはずなのに個別の事象になると急に視野が狭まって見えてこないアレですね。