俺は俗にIT土方といわれるような仕事をしているが、この作業では、負荷が急激に上がるものとそうでないものがあり、負荷が上がる仕事ではGTDや既存のライフハックなどは全く役に立たない。
そうした状況ではいつまでに必要なやるべきことと成果物、情報ノードを押さえた
タスクを進行させるためのマイルストーン図を瞬時に頭で描く能力が必要になる。

GTDは元々、人的、時間的リソースに余裕はあるが管理が出来てないエグゼクティブのための仕事術であり、基本的に実行者の負荷状況を考慮していない。
人生を高度何フィートに例えるといった気の長い視点すら提起されている。

また、流行のライフハックスについては、断片的なテクニックや考えに留まり、それらを実際の自分の仕事に適用させることは、まずほとんどといってない。

これらが仕事で使えるのは負荷が高い作業でも平常時と同様こなせる程度の熟練したスキルがある人、ルーティンワークメインで作業がフラットであり、それを効率化すればよい人などである。

SEの仕事というのは、調理場や鉄火場と同じで、限られたリソース
（時間、人、自分のスキル、協働者のスキル、人やドキュメントの情報ノード）で作るものを期限内にどんどん作っていかなければならず、それは自分の手や体、頭を動かすしかないので、頭の中身を搾り出したり、ウィッシュリストを作ったり、引き出しを整理する余裕などはどこにもない。
今日XX時までに数十台あるサーバのパフォーマンスデータのグラフをPDFで送付、などという状況では、それ以外に振り向けるリソースは存在しない。

今更ながら、現在出回っている仕事術やライフハック系の本がこうした状況を何も考慮せず書かれていることに驚かされる。

それで、GTDや仕事術などは、実際の仕事では何の役にも立たないと思っている。

が、仕事の状態というのは、ピーク時がずっと永久に続くかというと、そういうものでもない。
作業の谷間とか、フラットな状態、高負荷のタスクが収束期にあるときには、なだらかな下降線を描くように、或いはカオスとエントロピーの最中から突然何もない場所に放り込まれたように、負荷がない状況になることがある。
言い換えれば一見やる事のない暇な状態である。

実際には、こうした谷の時期と、急激に負荷が上がる山の時期がタスクや案件の発生と収束に従って交互に訪れていると思われる。

この谷の時期には、比較的リソースや精神的な余裕があり、GTD的に作業を進めることが有効になる。

この時期は、怒涛のカオスの中で様々な出来事があった後、それらを整理する必要がある時期にあたる。
手を動かすのでなく、作業の完了に向けてフラグメント化された頭の中身をリビルドしていく。

やり残した仕事はないか、成果物はもれてないか、構成は仕様を満たしているか、客先に確認することはないか、次の日程調整など、放っておくと霧散してしまうような事柄をキャッチアップしていくのに、GTD的なやり方が向いている。
頭の中だけでなく、とっ散らかった書類のファイリングや、ドキュメントのフォルダ整理などもこの時期にやっておく必要がある。

谷の時期では、拡散方向にあるタスクや情報を一箇所に留めおくため、GTDスキームを使ってそれらを一つずつ洗い出し、然るべき場所に定め、処理していく。

山の時期では頭の瞬発力の勝負となるため、この時期に信用できるのは自分の脳細胞だけである。
そうした時期は頭にリソースを集中させることが最も重要となる。
頭を信用せずむしろリソースから開放しようとするGTDは全く向いていない。
これが俺のGTDが早々に崩壊した一つの原因だ。

（※頭だけで処理するのは長期間は向いてないが、短期間での処理速度は最も高速になる。
頭以外のシステムに入力する手間や並んだリストを眺めている暇はない。）

（※厳密には、俺も頭だけ信用しているわけではない。
俺は記憶力、殊長期記憶に関しては相当に自信がないので、頭が覚えているうちに、起きている状況や、作業手順、押さえるべき情報はほぼ同時進行でメモするか、テキストに書き出して然るべきフォーマットにまとめている。
これらは数時間経つとあやふやになり、翌日には確実に覚えていない。
状況と同時に記録していくのが俺の鉄火場での作業方法になる。
この場合、記録には極力作業自体を妨げないスピードと、適度な情報を拾い上げる熟練が必要になる。
例えばメモ帳や秀丸は単にメモを残すにはいいが、体系化された情報を短時間にまとめるには向いてない。
その場合はMindManagerを使うなど状況によって使い分ける。

また、作業前に人と口頭で話して打ち合わせた場合でも、簡単なメールを送って互いの認識を確認したり、他社や自社人員と協働で作業する場合に必要だと思ったら即席でタスク管理シートや進捗管理ファイルを作ってそれで管理するようにしている。

が、俺以外にそうしたことをしている人は余り見かけない。）

殴り書きです。
推敲ゼロ。


最近思っているのは、ＳＥ特に構築系のＳＥにはＧＴＤに代表される仕事術は使えないんじゃないかということだ。

ＧＴＤのような体系化された方式は、タスクの難度や置かれた状況、納期や優先度などを考慮されているわけではないので、使えないのではないかということ。

また、巷にあるライフハック本に関しても同じことが言える。
俺は啓発本は大嫌いだが、ツールやなんかのハックは大好きなので、ライフハック系の本だけはよく読んでいる。
が、それらの本では問題がある。
タスクを”一般的な”ものに想定しているため、例えばメールチェックをして、日報書いて、プレゼン資料をまとめて、ＴＥＬで調整して・・というようなことを前提して書かれているが、そんなのは時間がなくても処理はできる。

メールは確かに一日数百通レベルになり、しかも重大案件と、どうでもいい内容が混在してくるとかなり辛いが、それでもそのレベルであれば処理は出来るのだ。

俺が直面しているのは、自分では処理が難しい、技術的な課題ばかりである。
よって、幾ら仕事術でどうこうしようと思っても、全く意味がない。
思いついたところで、出来ないのが関の山だからだ。

こういう状況では、むしろいかに人に頭を下げて回るかということが重要になる。つまり自分が知らなくても他人が知っていれば結果として同じということがいえる。
自分はその体系の入り口とか概念しか分からないが、実装に関してお願いするなら、誰か。では、どうやって巻き込むか、といったことの方がはるかに現実的にタスクを処理する近道なのである。

昔から、実はそうだったのだが、最近そのことに気づき、かなり強くそう思うようになっている。
もちろん、自分で技術的課題を解決できるときもあるが、人に頼んで何とかしてもらうことの方が圧倒的に多い。
タスクは担当者＝自分が解決すべき責任があるが、方法は他人に聞いてもいいというねじれ現象からこうしたことが起こっている。

今のＩＴはかなり分野が細分化し、一人で何でもできるスーパーＳＥは普通の職場に１，２人くらいしかいなくなっている。
よって、ただでさえ知らない分野があるのは当たり前であり、俺は知識、経験とも乏しいため、なお更そのような状況に置かれている。
俺が先日来から書いているフォーカスとは、この状況を何とかするためのものだ。


俺の置かれているような状況では、一般的にいわれる仕事術などは基本的に無駄である。
以前からの繰り返しになるが、ＧＴＤを会社でやっている人は実は余裕がある人だ。
なんか雑然としてるけど何とかしたいな〜と漠然と思うほど「余裕がある」人である。
本当に困難なタスクにまみれてＧＴＤで処理できる人はごく一部の通じるスキルを持っている人だ。

ＧＴＤ的な考えは万能ともいえるものであり、どの局面でも通じる。
しかし、スキーマに落とすと、途端会社でのタスクがハードであればあるほどに耐えなくなる。

よって、俺が思うにＧＴＤとは主に私生活用の方法論である。