「エンジニアのための時間管理術」を読んで仕事のやり方を見なおした

はじめに

オライリーフェアやってたので買いました。クリアファイルとメモ帳GET!!!

O'Reilly Japan - 2016年 ブックフェア開催中

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

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

おもにSA(System Administrator)向けの本であり、プログラマ向けではない、と最初に断られてあった。

私の仕事はソフトウェア開発業ではあるが、クラウドシステムの管理人もしているので一部当てはまるということ、仕事の整理や時間の管理に関してはソフトウェア開発でも当てはまると思った。（ソフトウェア開発といっても、プログラムを書く割合はかなり少なく、他者との調整や依頼、事務仕事も多くあるからだ）

で、今更時間管理術だ、タスク管理術だ、もうやめようよと思わなくもなかったが、単にオライリー本は面白いので読み物として興味があったのと、エンジニアに特化してる分得るものもあるだろうと思ったので読んでみた。

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

情報はひとつにまとめ、日常生活でも同じ管理システムを使うこと。オーガナイザと呼ぶが、手帳だ。筆者はPAA (Personal Analog Assistant）と呼ばれるアナログのものを推奨している。このあたりはどの時間管理術にも記載されてそうな内容だ。

集中と割り込み

「まとまった時間」に集中することの大切さと難しさを説いている。間違いなく、途中で話しかけられ、作業を中断し、再開するときにどこからだっけ、と探すのは明らかにロスで、バカにならない時間だ。

割り込みを追い払う方法として、委任、記録、実行の3つを紹介している。委任は「このひとにきいてくれ」と対処を委任する方法。記録は、ユーザは「自分の話をきいてくれれば」満足するので、そのアピールのために記録をすることが大切ということ。もちろん、あとでやらなければならない。最後の実行は本当にやらなければならない緊急の作業であればその場で実行するということだ。

また出社して最初の1時間はメールを見るのではなく作業に集中することをおすすめしている。

ルーチン

何曜日に必ずこうする。こういうときにこうする。必要な作業を見極め、頭を使わずによくしなさいという内容。

毎日少しずつ、の楽さに似てる気がします。例えば地下のカオスな結線を綺麗にすることを2週間ぐらいでやろうとして、毎日30分ぐらいやってましたね。これもルーチンを言えるでしょう。

こういったような、重要度または優先度が低いけどやったほうがいい仕事や、新しいものの学習、ニュースのチェックとかいうものはルーチン化したほうが良さそうです。

サイクルシステム

本書のメインとなる部分。

オーガナイザ（手帳のようなもの）で仕事を管理し、仕事の受付、遂行、完了までを1サイクルとして行えるシステムを構築しなさいと言っています。

これは実際自分も実践しました。txtのメモをテキストエディタに常時表示させておき、タスクを管理しています。

---

5/23月
schedule
AM出張
15:00-17:00 打ち合わせ

task
A 10m ◯◯さんにメール返信
B 10m 返却されたVM削除
B 1h コードのリファクタリング
A 30m 仕様検討、QAを担当にメール

Cランクのタスク
C 30m 教育受講計画立てる
C 10m 地下の結線図メンテ

C 30m構成管理用のサーバ立てる

優先度と、想定時間と内容をメモしています。終われば◯として、1日の終わりに削除します。残ったものは翌日に持ち越しです。

このとき優先度Cのものはどうしてもあとまわしになり、1日の最初に「今日はムリだ明日にしよう」となってしまうので、はじめから別セクションに記入することにしています。これらのタスクは集中力が切れたときに息抜きでやったりしています。

このようにスケジュールを決め、優先順位と想定時間を決め、1日の終わりには（アナログであれば）線で消して綺麗にして帰る、ということが本書でも説明されています。いかんせんデジタルなのできれいさっぱり今日の分は消す、とはならず翌日分にペーストなのですっきり感は薄いですが。

文章化

個人的にこの内容は非常に大切だと思いました。

情報を一元に集めたwikiのようなものが有効です。あるシステムのポリシーや、新しくサービスを開始する方法、ヘルプ、問い合わせ先がまとまっていると良いでしょう。ユーザはあなたに聞きに来る前にまずそのページを見て試してから来るはずです。

そしてこの文章化をしていれば、作業を他人に委任することができるため、重要だと私も思いました。

自動化

一度だけ行う難しい仕事と、頻繁に行う簡単な仕事を自動化するべきです。

自動化するときは、必ず手動で行い、その手動で行う手順をドキュメントに記載しましょう。それなしに自動化はなしえません。

aliasやmake、コマンド作成の方法が記載されていました。手段は何でもよいでしょう。

私がやってる自動化はほとんどシェルですね。何度も行う操作はドキュメントにまとめて誰でもできるように（このページにあるからまずやってみて）してます。

おわりに

その他にストレス、時間の浪費、電子メールといった内容もあげていました。ソフトウェアエンジニアではどれも大切なことだと思います。

この本をトリガーに自分の仕事を見なおしてみる、というのが1番良いやりかたかなと思います。

私は自分のタスク管理の方法を見なおしたのと、今後もドキュメント化を徹底して属人化を排除していく組織づくりを進めていきたいです。