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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

スレッドテーマ:仕事の現場:ビジネス




2007-06-05 [Tue]
仕事術が通じない仕事では、何を拠り所とするか
殴り書きです。
推敲ゼロ。


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

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

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

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

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

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

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

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


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

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

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




2007-05-30 [Wed]
拡散と集中/GTDとフォーカス
「GTDが使えない」エントリについて、works4Lifeさんからご自身の経験を踏まえた内容のエントリがアップされていて、参考にさせていただくべく、読ませてもらっている。
(ありがとうございます。)

前回は二日くらい全く寝てないこともあり、かなり切れ気味で書いていたのだが、ブログというのは本来、きれいにまとめたりするだけじゃなく、リアルタイム性を重視したいと俺は思っているので、あえてあまりまとまりがない状態でも後で却ってその方が記録になると思い、そうしている。
(昨今、トラフィックを集めようとまとめに走るブログが多い気がする。)

以下は、今日メタ・フレームを構築しながら、今の俺にとって何が必要であるかを書いていたもの。
そのまま掲載する。

---

俺は去年の年末からGTDに興味を持ち、4月の時点である程度ツールに落とし込み運用するまでに至るが、5月から新しい会社でインフラを始め、そこで先日のエントリに書いたようにGTDという手法だけでは管理がうまくいってないのが現状だ。
そのような中で、GTDとは別の手法を模索する必要を感じている。

俺がいま自分のWorkに有効でないかと思っているのは、GTDよりもフォーカスと呼べるものである。
フォーカスというのは以下に書くような概念について仮に与えた名称で、ある物事をどのような方向から捉えて進めるかという方法になる。
進行のための方法論とも呼べるし、仕事についての視座の定義とも呼べる。

■GTDの特徴のおさらい
GTDは拡散した雑事と精神的な雑念を一箇所に統合するのに適している。

環境的に拡散したもの
精神的に拡散したもの
→一つのシステムへ入力し管理。

向いていること:
目に見えない部分を可視化することで、必要なこととそうでないことを明確化し、作業効率を高める。
精神的な余裕を生み出すことで、脳の更なるキャパシティを活用する。
必要なこと、そうでもないこと全てを洗い出し、もやもやした状態をなくす。

向いてないこと:
まずツールレベルでは、一般的なGTDツールでは勤怠や社内作業を管理できない。
手法としては、あるタスクを集中的に行う場合の方法論がない。
マインドマップはアイデアを出す方法だが、マインドマップで出たアイデアをどう進めるかが定義されていない。


■フォーカスとは?
フォーカスは、GTDとは逆に集中を行うために用いる。
フォーカスでは、あるタスクに対し、以下のようなことを重視する。

どのような視点から捉えるか

どのような方向から進めるか

作業範囲が明確でない場合、「どの範囲まで」と自分で定義するか(ワイド)

作業や対人の優先度はどう設定するか

PERT図のように、どのようなフローで進めるのがベストかを定義。(対人、分岐条件、関連タスク)
社内や客先との関係もあるので、必ずしも早い=常にベストではない。

本や資料、WEBをどの程度読んでから仕事を始めるか
(斜め読みして重要事項だけ抜き出す、全体像だけ捉える、必要最低限を捉える、人に聞く部分と自分で調べる部分、関連資料を全て読み記憶できるところまで読み込むなどの場合分け)

情報源はどこにアクセスするのが最も最適か
(本、WEB、社内資料、人、客先、ベンダ 人間や組織も情報ノードとして捉える)

情報捜索術、情報格納術、情報管理術

■誰に有効か
GTD或いはGTD的な考えは、ある程度誰に対しても有効になるが、フォーカスは、必ずしも誰にでも向いているわけではない。

俺がやっているように、インフラやSEワークで、概念や用語、ツールやインフラ機器の設定など、新しいことを次々に覚えて即形にすることを求められる職の人や、それが発生した場合には適している。
PGの人にも有効だろう。
PGでは特に開発作業が機能単位で厳密に工程化、線表化されているので、GTDで自分で管理する必要も余りない。

社内のルーティンワークがメインで、既に技術的にはクリアしているが、余りにも管理の数が多かったり、管理が煩雑であったり、日々のルーティンをより効率化したい人には、フォーカスは必要ではない。
また普段の生活においても必要ではない。

---

以上が現在思っている内容。
まだ、忙しいといっても、6時半とか7時には帰れているので、時間や作業の難易度、対人関係が問題になっているのではない。
もっと大変な時期もあったし。

ただ、この方法は絶対に仕事で使えると思って研鑽してきたことが、脆くも瓦解したショックが大きかった。
俺にとっては、自宅と会社でやるGTDは同じだと思っていた(と楽観視した。)ことがまず甘かったこと。
そして、各人の置かれたステータスによってGTDが有効になったり、大して意味がなかったりということが分からなかったことでショックが大きくなったようだ。

今は最初の状態から幾分持ち直し、新たに上記に書いたようなフォーカスという概念で再構築を試みようとしている。

なお、ツールのほうは、EXCELをマクロ化したりして何とかしたいのだが、時間とスキルがないためうまくいっていない。
全部手入力なのでこちらは相変わらず大きなストレスになっている。
社内ツールもそういったものは全くない(Notesがデフォであるが、中途半端なので全く役に立たない)ため、自分で何とかしなければならない。
works4Lifeさんのnomicoさんのところは、社内ツールが整備されているようでうらやましいです。

ただ、今日GTDをやってよかったと思ったのは、MindManagerで用件定義をまとめることを思いついたこと。
メタ・フレームの構築用件が色々あり、俺は初めてなのでそれをどうまとめるか悩んでいたが、分厚い本やWEBの資料があり、EXCELで始めたものの早々に断念した。

で、なんかいい方法はないかと考え、3月に試用版を試したMindManagerを使って一気に書くことにした。
タスクの進捗度もアイコンがあり、クリックで25%ずつ表示でき、100%だとチェックマークになる。
定義=タスク管理にもなるところが素晴らしい。

これで、午後の作業はかなり進み、今日はMSDEを入れるところまで進めることが出来た。
MindManagerがなければ危ないところだった。
色々使えるツールを試したのが、ここにきて役に立っている。

評価版のMindManagerはBASICですが、これは自腹出しても買おうと思ってます。
(BASICは2万8千、Proは4万2千)




2007-05-28 [Mon]
GTDとか役に立たねぇ
GTD=仕事には使えない説が俺の中で説得力を持ち始めてます。

もちろん私生活ではいいけど、仕事でGTDとかやってる暇なし。

本読んで、構築して、はまって、で、どこにフォーカスあてるかって話し。

はまってる状況でタスクがどうとかいってる暇はなく、優先度と、難易度を考えて、瞬時にPERT法みたいなやつを脳内で描いて、フロー考えて、この出方でいいかとかいろいろ考えて結局失敗してる。

ログ取られる危険があるから、WEBのGTDツールなんてとてもじゃないが使えない。

仕事でGTDやってる人は、実はかなり余裕がある状態じゃないかと思う。

こないだのエントリでも書いたように、GTDと仕事のセグメントってのは実は全然相容れない。

仕事術からGTDっていうのが流行ったわけだが、実は現場の仕事にはまるで耐えないってどうよこれ?

以前提示したGTDの階層に一つを加えて、7階層としたほうがいいのではないか。

■GTDの7階層

レベル1.開始期(06年12月)
雑誌の特集やWEBのエントリなどでGTDのことを知り、興味を持つが、何から手を付ければいいか分からない時期。

レベル2.学習期(06年12月)
簡単なツール選び。
WEBで関連エントリなどを探して読み込む。
試しにレビューを毎週行ってみる。

レベル3.実践期(07年1月〜2月)
デビッド・アレンの原典をあたり、学習をより深める。
徹底したツール選び。
関連したエントリを読むだけでなく、自分でも経験などを書くようになる。

レベル4.探求期(07年2月〜3月)
理論としてのGTD、自分が求める内容は何か、それらを実装するツール、といった理念と現実との乖離があり、その統合を行うため、様々に情報収集、思考、実践する。

レベル5.運用期(07年4月)
ツールがフィットし始め、意識せず自然に運用出来るようになる。
レビューも週次に固定しなくても回るようになる。

レベル6.展開期(07年4月)
GTDを全ての考え方・メソッドの根幹におき、他のライフハックスやメソッド、ツールなどの次元における統合と展開を模索する。

レベル7.崩壊期(07年5月)
GTDが実は仕事にはまるで使えなかったことを思い知る。




2007-05-17 [Thu]
タスク管理ツールに最適解はあるか
就社して二日目。
今日も放置されていたので、何が必要かと自分で色々とタスクを洗い出していたが、拠点ツールのNotesは、はっきりいって使い辛い。
いただけない点は、以下のようなことから。

・メールソフトとしては、受信時間が表示されない。更に、メールに返信するときに、オプションから履歴あり返信を選ばないと、相手とのやり取りの履歴が挿入されない。
一応メールソフトのくせに、履歴を選ぶ手間があるというとてつもないバカソフトだ。Outlookに匹敵するクソ仕様である。
・タスク管理ツールとしては、タスクの開始日や依頼者、連絡先の項目がない。
またデフォルトで公開なので、オプションでいちいちシークレットにしないと非公開にできず面倒くさい。
・スケジュールとしては時間と予定を入れられるが、勤怠のフォーマットではないので使い物にならない。
但し、他の人が自分の今日の予定を参照する分には有効。
ただ外出先の予定がある人しか入力してないので、実質自分には入力する必要がない。
むしろ空気読まずに入れてるとローカルルールに反して反感買いそう。

Notesでは何も管理出来そうになく、更にここの拠点はNotes以外のインストールソフトは何もなく、シェアウェアはアウトでフリーのみなら使ってもいいという環境。

メールは我慢して使うにしても、他の部分は何とかしないとやばいと思って、応急処置でEXCELで自己管理用のフォーマットを作っていた。
ちなみに、こういった要求を満たすフリーソフトがないかどうかざっくり調べたが、なかった。
(MSのProjectでも使えればまだ何とかなるのだが…。)

会社で自己管理するには、最低以下のようなものが必要である。

・勤怠管理表
月ごとにその日の開始時間・終了時間と、稼動工数を書く。
いわゆる普通の勤怠。

・作業詳細管理表
これは、その日にどういった作業をしたかの詳細を書く。
また、その日予定している作業、作業の依頼者、報告の有無、報告先、作業期限、作業実績などを記入する。
勤怠管理表と一緒にすると煩雑になるので、勤怠管理との関係は、日にちをキーにしている。

・タスク管理表
これは、作業詳細から、日にちを取り除き、進捗率やタスクの状態など、純粋にタスクだけを管理する。
タスクにはNo付けしており、作業詳細表との関係はこれをキーにしている。
作業詳細は、日に対する作業の内容なので、日が不確かであったり、保留していたり、随時だったりすると作業詳細では管理し辛い。
そこで、タスクのみを扱う管理表が必要になるというわけだ。

・移動費・出張旅費管理表
今の状態ではあまり発生はしないが、移動や出張はそのうち発生するので、今のうちに作っておく。
いわゆる一般的なフォーマットで、日にち、開始地点、目的地、移動手段、金額、領収書の有無、清算システムへの入力状態などを記入。
移動手段などは予め決まっているので、リストで作ってプルダウンから選択できるようにしておく。
他の管理表との関係は、日にちをキーにする。


で、作ったはいいが、GTDメソッドをある程度理解したと思っている俺でさえ、GTDツールがこうした会社でのタスクや作業管理に全く適さないことに今更ながら気づいた。
まあ、半年ぶりに仕事に復帰したので、当たり前であるが。

それは、なぜかというと、家のタスクと会社のタスクは性質が異なるからだ。

家は、
・作業期限がない。仮に期限があっても守るかどうかは自分の腹次第。
・報告義務がないので、アバウトに管理しても良い。
・自分の頭の中や周囲の雑然とした物事を管理するので、日にちという枠でタスクを管理する必要がない。
・どの作業に何時間かかったかなど、作業時間を計測する必要がない。

結果、タスクのステータスの移動がスムーズに行え、完了したタスクがアーカイブするまで残り、タスクとプロジェクトの関係が明確な仕様であればある程度要を為す。

会社はそれとは逆で、
・作業期限がある。
・報告義務がある。
・日にち、時間という枠でシビアに管理する必要がある。
・かかった作業時間を計測しておくほうが何かと都合がいい。

こちらは、より厳密さが求められ、他者との関係も多く、タスク単体のステータス以外にも連動項目が増える。


こうなると、俺が回しているのはあくまで家用の適当でいいGTDで、会社のシビアな管理が求められるGTDに対しては、認識やツールを改めて再構築する必要があったということになる。
ツールは応急処置を施したが、会社のそれは既にGTDというものではなく、別の管理体系の話しになっているような気もする。

無論、GTDをこれまで学習、実践してきたからこそ、この意識にたどり着いたのであり、これまでの試行錯誤は無駄ではない。

スレッドテーマ:仕事の現場:ビジネス




main