時間がかかってしまう理由

とにかくいろんなことで時間がかかる

島耕作のようなビジネス漫画の主人公はとにかく仕事ができます。まあ、仕事ができない主人公のストーリーをずっと追うよりも、きっと仕事のできるヒーローのような主人公を観ていた方がすっきりするからでしょう。

でも、実際には、社会で働いてみるとガッカリすることが多いものです。いや、きちんといろんなことができている人はよいのですが、特に私の場合はガッカリすることが多いです。最初にこれくらいでできるかなと思っていた作業が全然進まない。

気がついてみたら、進捗をどのように図るかすら分からない。大抵そういう場合は全体像が分かっていないので、全体からみた進捗状況なんて分かるわけがないのです。見知らぬ土地でどこに向かっているか分からないのに、あと一時間で到着するかどうかなんて分かるわけがありません。

そこで作業時間のかかる原因を列挙してみました。実はずっとこんなことを考えていたので、最初から私の結論は決まっています。それは「事前にルールを決めておいて、その通りに動く」……ということです。そのプログラムに添って動けばいいのに心理的圧力などで動けないことは多いのです。

 

何をすべきか考えること

特に初めての業務をする場合、ここに時間がかかります。いわゆる段取りを考えるフェーズです。そして、やむを得ないことながら「分かる範囲で考える」という大前提を明確に意識する必要があると思っています。当たり前なのに結構それを無視しがちだと思います。

で、前例のレールがない場合、ここはがんばって考え抜くしかありません。ただし、これがサラリーマンの前例仕事の場合は話は変わります。「分かる範囲」から逸脱しない方がよいというのが私の結論です。そして「分からない範囲」があるという前提で分かる人に相談するしかありません。

たとえば、何かを運ぶ仕事があるとします。電車で運ぶのか、自転車で運ぶのか、それとも……と、ここで考えるのは無駄です。個人事業であれば自由度が高いので、そこからデザインすることになりますが、サラリーマンの定型作業であれば、やり方が決まっていることが普通です。

つまり、電車で運ぶのか、自転車で運ぶのか……という分岐の先を考える前に、「前例ではどんな手段がありますか?」と聞くのが最善です。想定で分岐の先が広がるものは、とにかく先に進まないことが重要だと考えています。妄想が広がる分だけ時間が浪費されます。

 

調べなければ動けないこと

何かを調べなくては先に進めないことがあります。たとえば、森鴎外についてドキュメントを書かなくてはならない場合、当然ながら森鴎外について知っておく必要があります。この場合は完成形の程度を強く意識する必要があると考えています。

森鴎外の一生を書かなければならないのか、森鴎外の人生の一部を切り取って書くのか、そもそも著書の一部を引用するのか、それからそれを書くための時間は十分にあるのか、あと数時間で仕上げなくてはならないものなのか。それが明確でないと不幸なことになります。

今までの私の失敗から分析すると、何かを調べる前には「何のために調べるのか」と「最低限、何が分かっていればいいのか」という定義を明確にした方がよいようです。知識の森というのはとても奥深いもので、十分に注意しなければ、関係ないところにどんどん引き込まれていきます。

そのため調べると新たな分からないことが発生し、さらにそれを調べると、他の分からないことが発生することは珍しくありません。そこで迷わないように2階層以上は潜らないようにするのもコツです。

◆たとえば「Java言語」を調べるだけでも階層は深くなる

キャプチャ

概要を知りたい場合は、「用途」「特性」「開発環境」の次の枝までで止めておくべきですし、「用途」を知りたい場合は、うっかり気がついたら「開発環境」の善し悪しを調べていた……という自体は避けなければいけません。

 

 

分からないことに時間をかけること

基本的に、調査作業は疲労と時間をコストとして差し出さなくてはなりません。そして調査のための検索にも技術があります。端的に言えば「使えるキーワード」と「探すべき場所」が分かっていないといけません。ここで非常に残念な指摘を自分自身にするわけですが、「知らなければ聞く」のが一番です。

「こんなことも分からないのか」とか「これくらい自分で調べろよ」とか思われてしまうかも知れません。いいじゃないですか。事実、分からなかったのです。完全に分からないことを調査することは、分かっている人より確実に数倍効率性が違います。

また、状況が許すのであれば、手分けをするも非常に有効だと感じています。新しい概念を頭の中にしみこませる場合、そこには当然得手不得手や特性が明確にあります。ひとつよりも複数の価値観と視点からアプローチすれば、必ず素早く目的にたどり着く人がいるはずです。

一人がたどり着くことができれば、そこから生の声でナビゲートすることが可能になります。また、分かったつもりになっていても、違う視点から質問を受けることによって、実は分かっていなかったことが判明することも珍しくありません。こういう発見こそがチームで仕事をする大きな意味だと思います。

 

 

試さなくてはならないこと

「まずはやってみてください」からスタートした仕事の場合、複数の方向性や手法があって、複数のアプローチがあることがほとんどです。もちろん、最初から「モデルになるような過去事例があれば教えてください」と聞いておくのがよいのですが、過去事例がないようなこともあります。

そんな時は、とにかく最初から完璧を目指さない心構えが重要です。そしてとにかく時間をかけないことに集中しないといけません。試さなくてはならないということは、何回もリトライが発生する可能性……というか、リスクがあります。その場合、丁寧にやったことも無駄になるリスクがあります。

乱暴かも知れませんが、たとえば提案書を作るのであれば、最初からパワーポイントで作らずに、A4の紙にラフを殴り書きするのも有効です。パワーポイントなどPC作業の強みはコピー&ペーストによる省力化ができる点ですが、弱みはちょっとした図でも体裁が思ったようにいかないことです。

概念図を作るのに体裁がうまく整わず、本質的な図がなかなか完成しないことも珍しくありません。一つの枠を動かしただけで、他の場所も派生的に調整しなければならず、かえって工数がかかることも珍しくありません。逆にどういう図を作ればよいか明確になっていればデジタル化は簡単です。

そして、さらっと作ったら、それが完成形でなくても、判断できる人に見せてしまうことです。早ければ早いほうがいいです。見せてみて「ぜんぜん違う!」となったとしても、早い時点からの手戻りには猶予時間がありますし、コメントする人も何もない状況に比べて明確で適切な指摘ができるはずです。

 

人を巻き込む、助けを求める

弱みを握られたくなくて、分からないことをありのままに白状できないこと。これは実際のところ、よくあることなのではないでしょうか。しかし、だからといって抱え込むと確実に事態は悪化します。何よりもまずいのは時間が経過すればするほど、より真実を言えなくなることではないでしょうか。

もちろん、他の人に助けを求めることは、その人の時間を奪い、その人の効率性を奪うことではあります。忙しい人であればあるほどコスト的な損失は大きいでしょう。しかし、抱え込んで抱え込んで、最後の瞬間に問題が破裂してしまった時、最初から対応をしなければならないのは、その「他の人」かもしれません。

そうなると、ひどく余裕のない短納期で「その人」が苦しむことになるかもしれません。そのような最悪な結末から逆算して考えると、最初から「他の人」を巻き込んで適切に支援してもらうことは、全体最適になり得ます。またその支援によって、今後は他の人の支援なしで仕事が遂行できる可能性も高まります。

さらに、最初からいろんな人を巻き込むことは「アラート」にもなります。あまりにも自分自身がその内容について分かっていなかった場合、個人的には不本意な結果になるかも知れませんが、最後まで抱え込んで問題が爆発するリスクを軽減することができます。これはストレス管理に属する対応でもあります。

 

時間をかけないことが最大のストレス管理

時間をかけてよいこと……というのはあまりない、というのが私の今までやらかしてきた失敗を振り返った感想です。時間をかければかけるほど、提出する側もされる側も「これだけ時間をかけているのだから、まともなものができていなければならない」という心理的バイアスに支配されます。

時間をかければかけるほど提出側は出しづらくなり、時間をかければかけるほど受領側は期待とかけ離れた質と量に対するギャップを強く感じることになるかもしれません。だからお互いにとって時間をかけないことが何よりも救いになるはずです。

仕事のリスク管理に関して、いつも私の脳裏をよぎる内なる言葉は「傷の浅い内に」です(苦笑)。そして最悪な言葉は「なんで今の時点でこんな状況なんだ」です。こうなると、すでに時遅しで、正しい方法ではリカバリーが困難になっています。時間外業務も、人員も追加になるかもしれません。

納期が迫るほどスケジュールの立て直しは不能となり、リソースもギリギリまたは確保できない状態で無理をすることになります。そこまで無理をした提出物も到底満足できるものでない可能性があり、さらにその後に修正作業が追加で必要になることも普通です。これはまったく無駄なことです。

まずはできることを素早く行い、他人を巻き込んで連携することです。そこの初速を早くすることが、おそらく唯一の仕事上のリスクを減らす方法だと考えています。言うは易し……で、私自身、このことを意識しながら仕事に向かう日々ですが……まあ、とにかくがんばりましょう!

それでは、また!

ダメな人なりのTaskchute2

世の中にはすごい人多すぎ!

……と感じている層のためのブログでございます(苦笑)。そうそう。ブログを読むとね、「私はこういうの、完全に普通だから……」みたいな、すごい人、多いじゃないですか。嫌みのつもりではないんだろうけど、読めば読むほど「あなたとは違うんですよ」的なオーラが漂っていて近づけない感じのブログ。

と、そんなわけで、トップダウンアプローチでなく、私はボトムアップのアプローチで、低いところからじりじりとあがっていくスタンスのコンテンツを提供する所存です。さて、そんな視点でTaskchuteについて書いてみようかと思います。私はTaskchuteを使い始めてから数年経っています。具体的には3~4年というところでしょうか。

そもそもTaskchuteってなんなのかというと、

  1. 有料のExcelマクロです(無料版もあります)
  2. タスクを管理するツールです(時間の記録ができます)
  3. 作業時間の見積もりができます(何時に帰れるのか)
  4. かなり緻密な繰り返し設定ができます(最終営業日の2日前……とか)

というものです。もっとすごい詳しい人が書くとさらに書けるのでしょうが、少なくとも私がありがたいと思っている主な要素は4点です。……で、数年も使っているのだから、そうとう使いこなしているのでしょう?……と、言われると、ぜんぜんそんなことはありません。開発者に申し訳ない限りですが。

 

 

残念な人はTaskchuteをどう使っているのか

たとえば、すごい人はTaskchuteに「7つの習慣」の概念を組み合わせて使っていたりします。具体的には「急ぎでかつ重要」「急ぎだけど重要じゃない」「急がないけど重要」「急がなくてもいいし重要でもない」という4つの領域分けをするという具合に分類したり。もちろんそういう消費時間のチューニングは重要です。

ただし、残念ながら誰にでもできるようなことではありません。もちろんできた方がいいには違いないのだけど、モノによっては急ぎなのかどうかも分からないものもあります。たとえば、複数人でプロジェクト計画を立てていたとして、最初大急ぎでやっていた作業が、他の作業の進捗によって優先度を下げてもいい内容に変わることもありますし、その逆もあります。

そんな言い訳もありながら、私は多くのTaskchuteエバンジェリストのように華麗なTaskchute使いではありません。あえて異論を正々堂々と書くならば、他の人にとっていいソリューションが私にとって最適とは限らない。……ので、私にとって最適な方法でTaskchuteを使っています。ということでしょうか。

では、どのような私がなぜTaskchuteを使っているのか。どのような用途で使っているのか、を書いてみます。

 

(1) 今何をしていたのかを思い出したい

若年性健忘症というわけでもないはずです。そもそも若年ではありませんので……という残念な脇道はさておき、集中することが目の前にあると、メールをチェックしていたはずが、メールの内容にのめり込み、さらにはその添付ファイルにのめり込むというアクシデントは痛すぎます。

そうならないように、15分タイマーをよく使います。音が鳴ると恥ずかしいので静かにピカピカするキッチンタイマーです。うまくTaskchuteのタイムライン上を走れている時は必要がないのですが、たまについ何かに没頭している時にタイマーが光ると、「あ、ヤバい。何してたんだっけ?」とTaskchuteに目をやると、本来やっていたはずの作業に戻れるので便利です。

この没頭防止タイマーですが、15分間隔だと、少なくとも1分は自己管理ができる範囲だとして、最悪14分間は無駄な時間を作ってしまうリスクがあります。しかし、これを5分間隔にしてしまうとさすがに今度は集中力を削り始めます。なので、いろいろと試行錯誤した挙げ句に今は15分間隔で仕掛けています。

ちなみに、「1時間は資料作成をする」と決めて実施している場合でも、15分タイマーは有効です。集中すればするほど体感時間は短くなるので、1回目のタイマー点滅で残り時間4分の3です。たいていそんな時の気分としては「まだ15分しかたっていないのに」というところですが、泣いても笑っても4分の1を消化してしまったのです。

今のペースで終わりまでどのくらいかかるだろうか。何かを削るべきか、削っても無理なのか、もしかすると進め方を変えるべきか。提出期限があるものであれば、スコープを縮小する交渉の余地はないものなのか。仲間のいるものであれば、一部をお願いして並列作業で進められないか……などなど、節目で戦術を考えることができます。

 

(2) 次に何をすべきか忘れてしまいたい

これはTaskchuteを使っていて最も助かる機能のうちのひとつです。毎日の繰り返しタスクなどは順番が決まっていても、それを暗記するのはやや面倒です。たとえば、朝に、昨日の作業実績を書いて、その次に……と続くのですが、そもそも私は暗記が苦手です。というか、Taskchuteを使う以上はタスクの暗記をしてはいけないと考えています。

なぜなのか。暗記ができるくらいならTaskchuteはいらないからです。私は記憶力に自信がありません。むしろ記憶力に頼った時には何かを忘れるリスクが増えているとすら考えています。なので、あえて記憶に頼らないことでタスクの安全性を確保しているのです。苦手な記憶力で脳に負担をかけるよりは、集中力にパワーを振り分けるために忘れてしまいたいほどです。

それから、タスクの暗記をしない理由は、前日の作業によって次の日の手順を変えた方がよい場合があります。たとえば何かの報告を翌朝に行う場合。前日の作業で、報告の前に確認タスクを入れてからの方がいいなと思った場合、翌日の該当タスクの前に、確認タスクを追加しておくのです。

こういう運用をする場合、タスクの暗記はリスクにしかなりません。うっかりタスクを実施してから、その前段階に行うべき確認忘れに気がつくことになります。なので、Taskchuteを使うなら使うで、タスク管理は依存しきってしまった方が安全性はむしろ高まると考えています。もちろん電子データの消失リスクに備えてアナログメモもさっと残しておくわけですが。

 

(3) 何をしたか思い出すのに苦労したくない

Taskchuteを使っている時の特有のありがたみとして、「今日は忙しかったな。でも、何で忙しかったんだろう?」というモヤモヤが残ることは「ほぼ」なくなりました。何で忙しかったのかというのは「だいたい」追うことができます。今日できたことと、できていないことがだいたい把握できます。

本当はレビューをするのが最適なのですが、私は残念ながらそこまではできていません。書きっぱなしです。とはいえ、意外とひとつの作業をしていて、その数週間後に類似案件をしなければならなくなった時、何にどの程度時間がかかるのか……というのは追えるようになっています。

たとえば提案書を書くのに、どの程度調査に時間を要したか……などの過去実績は役に立ちます。やや、残念な事例を書くならば、「自分への期待値」と「その残念な結果」を知ることができます。このくらいなら1時間でできるだろうと踏んで、実際には3時間かかってしまっていたとか。

ちなみに、できうる限り正直ベースで記載するようにしています。誰に報告するというものではなく、自分専用のログなのでかっこつけても仕方ありませんし。なので、体調が悪い時は休憩時間が増える傾向にあります。Taskchuteが地味に便利なところとして、カテゴリ毎に色が塗り分けられます。

なので、先ほど書いたとおり週次レビューなどはしないのですが、一日使っているだけでも、「あれ?ちょっと今日、休憩時間が多すぎだな……」と気づくことが容易になります。記録していないと、ちょこちょこととる休憩はさほど気にならないかもしれませんが、客観的な数字として残るとなると注意を向けることができます。

 

思い通りに記録できなかった時にどうするか

正直、ここがTaskchuteエバンジェリストとの決定的な違いでしょう。Taskchuteの理想的な使い方は分単位で計画して、分単位で記録することと言われています。逆にそのガイドラインが「完璧主義者」を断崖絶壁に突き落とす原因になるんじゃないのかと感じているところです。「完全にできないのならやめてしまえ!」という気持ち……とても分かります。

ぶっちゃけ、何か作業をやっている時に、「すみません、ここなんですけど……」と来られたら、Taskchuteに目をやる前に、その人の顔を見ます。「ああ、あの件ですね」と言いながら、なんだっけと必死で思い出す(苦笑)。その脳内検索時間にCPUをとられている間なんかにTaskchuteの操作なんてできませんよ。

また、そんな状況なので、割込みタスクを入れるにしても、何を入れればいいのかとっさに分からない。目の前の人が誰だっけ?……という状況すらあったりします。(多数のプロジェクトに関連すると、新規プロジェクトのメンバーが初顔あわせしたばかりという方もいらっしゃるので。)

気がついたら打ち合せが始まってしまっていて、終わった時間だけ分かっている……という時、以前はできる限り思い出して時間の記録を遡ってしていました。それが完全にできないこともフラストレーションに繋がっていました。だって、想像で時間記録しているわけですから、時間的錯覚をそのまま記録しているのかもしれないのです。

メールを出した時間など、作業終了時間の目安になるものがあれば、そこから記録の保管をすることは可能です。しかし、入り組んだ状況だったりすると、記録忘れを補完するために数十分かかりかねない状況になることもあります。すると非常にバカバカしい記録が残るのです。「Taskchuteの記録補完(22分)」とか。

そこで、決して褒められる方法でないことは承知していますが、記録忘れが分かった時点で、それまで実施しているはずだったタスクを一旦終了させます。そして、終了時コメントに「○○の件打合わせ。××さんに電話。☆☆についての調査を含む。」と書いて終わりにしてしまいます。

非常に残念ながら、前タスクがほとんど終わっていない場合は、前タスクの開始時刻を空白に戻し、「使途不明」というグレーの枠を新たに挿入して、そこの終了時コメントに同様にやったことの概要を記載します。記録としては残念だし、自分の中の「完璧主義者」がうずきます。しかし、それでいいのです。

 

ひとつのルール違反のためにやめるのか

理想型というのはあるでしょう。おそらくTaskchuteにもあります。全ての割込みを確実に記録に残し、緻密なタスク計画を分単位で完遂していくこと。これがパーフェクトにできている人はおそらくいることでしょう。しかし、私は数年使ってみてもそのような使い方は未だになじめません。

特に独立していて一人で動いていた時には、そこそこタスクログも記録できていたような気がしますが、サラリーマンに戻ってみると、無視できない人はたくさんでてくるのです。エライ人がやってきて「ちょっといいですか?」と聞かれている時に、「ちょっと待ってくださいね」とTaskchuteに割込み記載なんてできません。

ましてや、「割込み◆山田さん」(仮に割り込んできた人が山田さんだったとして)と書かないまでも、「山田さん」とTaskchuteに記載するところを見られたくもないのです。おそらく私の感覚だけの話だと思うのですが、なんかそれはとても失礼なような気がするのです。(後からこっそりと書くのはアリだとしても)

まあ、そこから呼ばれて、打ち合せになり、そこから人が増えて確認事項対応をして、調査して……という流れでTaskchuteをコースアウトすることも少なくはありません。基本的にノートPCよりもA4アナログノートを持って打ち合せをすることが多いので、打ち合せになるとTaskchuteの記録は途絶えます。

もう、やめちゃおうか……と思ったことは過去にたくさんあります。特にTaskchuteを使いこなしているようなブログを読むと、「ああ、素晴らしいけど、そこまでやるの、きついよ。」って。

それでも、結果的に私はまだTaskchuteを使っています。本来の運用から見ると、フル機能を活かす使い方ではないにせよ、私なりに使い道があるからです。すべての道具が万人にとって万能にならない以上、そういう割り切りで使うと方向性があってもいいと考えています。

逆にそうやっていくと、優秀な人たちが気づかない使い道に気づけるのかも知れません。私はTaskchute優等生とは違う道を歩くしかないように感じているのですが、そこにこそTaskchuteに適応できなかった人に対するソリューション提供ができるんじゃないかなと思っています。

ま、Taskchuteに限らず、このブログではそんな視点をお伝えしていければいいのかなと思っています。

それではまた。