はじめに
社会人になると、いろんなタスクがあちこちからやってきて、対応するのが大変になります。
新卒で入社したばかりの新人ITエンジニアさんも、この先現場に投入されるといろんなタスクがやってきて忙しくなってくると思います。
そこでこのエントリでは、僕が仕事をする上で大事にしているポイントをいろいろと書いてみます。
この先もし、忙しくて忙殺されそうになったときは、このエントリを思い出して読み直してみてください。
このエントリの対象読者
僕はRailsプログラマとして働いているので、同じようにプログラマやITエンジニアとして働いている方を想定読者とします。
ただし、タスク管理という観点においては、技術職であってもそうでなくてもあまり変わりはないかもしれません。
また、タスク管理は仕事だけでなく、プライベートでも必要になるスキルです。
（たとえば結婚式の準備とか、勉強会の企画とか）
これから書く内容は、そういったプライベートのタスクをこなす際にも同じように適用できると思います。
【もくじ】
なるべく早く反応する
お客さんからメール等で連絡や問い合わせがあった場合はなるべく早く反応を返すようにしています。
すぐに返答できない場合は「明日の午前中までに返信します」みたいに答えて、だいたいの期限を切った上で対応を後回しにします。
よくないのは「自分の手が空くまで全く返信しない」とか「完全な回答ができあがるまで返信しない」という対応です。
こうなると相手は自分の声が届いているのか、それともまったく届いていないのかわからなくなり、不安を感じてしまいます。
ただし、「なるべく早く」といっても「必ず5分以内」とか、そこまでの早さは必要ありません。
目安としては「遅くとも半日以内」という感覚です。（メールや掲示板のような非同期的なコミュニケーションの場合）
また、ここではあくまで「反応」するだけです。（あなたのメッセージはたしかに受け取りましたよ！と返すだけ）
「すぐに対応を開始する」の意味ではないことに注意してください。
期限を確認する
問い合わせや作業依頼が来た場合は、（瞬殺で対応可能な場合を除いて）必ず対応期限を確認するようにしています。
緊急を要する要件でないのなら、TODOリストに入れて、しかるべきタイミングで対応します。
「問い合わせが来た！早く答えなきゃ！」とすぐに対応してしまうと、そのぶん他のタスクがどんどん遅れてしまいます。
つまり、タスク対応はLIFO（Last In First Out、後入れ先出し）にしたらダメ、ということです。
WHYを確認する
「これをこうしてほしい」というような依頼が来た場合は、言われたとおりにやるのではなく、その背景やWHYも確認するようにしています。
WHYを確認すると、以下のような効用が得られます。
- お客さんにとって、もっと良い解決策を提供できるかもしれない
- お客さんから言われた方法よりも、もっと簡単なやりかたで問題を解決できるかもしれない
- 実は手を動かす必要性すらないかもしれない
つまり、WHYを確認することでお互いにwin-winな別の解決策が見つかるかもしれない、というわけです。
日数がかかるタスクは定期的にハートビートを送る
大きなタスクだったり、他に並行して取り組んでいるタスクがあったりする場合は、タスクの完了までに日数がかかります。
そういったタスクに取り組んでいる場合は、1週間に1回ぐらいの頻度でタスクの依頼者やステークホルダーに進捗を報告するようにしています。
これは自ら発信する「生存報告」のようなものです。
僕はこの生存報告のことを「ハートビート」と呼んでいます。
ハートビートとは、心臓の鼓動、拍動、心拍という意味の英単語で、ITの分野では、通信ネットワーク上で機器が外部に一定間隔で発する、自らが正常に動作していることを知らせる信号やデータを指すことが多い。
ハートビートとは - IT用語辞典 e-Words
ハートビートは進捗が芳しくない場合でも必ず発信します。
タスクを依頼してから何週間も音信不通だと、タスクが進んでいるのか止まっているのか相手はわからないので、依頼者は不安を感じます。
ハートビートを送るのは相手を不安にさせないためです。
「そこそこの出来」でまずレビューしてもらう
比較的大きめのタスクに取り組むときは、「それっぽい雑な成果物」が出来た時点でレビューを依頼し、フィードバックをもらうようにしています。
「最後まで完璧に作り込んでからレビューしてもらう」という方式は危険です。
なぜなら、自分の誤解や思い込みを含んだまま最後まで突っ走ると手戻りが発生して余計に時間が掛かるからです。
そうならないように「そこそこ」の成果物を見せて、方向性が間違っていないことをお互いに確認し合う方が効率的です。
初回レビューのタイミングは予め決めておく
また、タスクに着手する前から「ざっくりこれぐらい作って、いったんレビューしてもらう」という計画を立てておくようにします。
「ざっくり作った状態」というのはプログラムでいうと、たとえば「エラー処理や見た目の仕上げは未着手だが、正常系の操作であればいちおう動く」といった状態です。
つまり、「エラー処理や見た目の仕上げ」は「初回レビューのあとに着手する」という計画を事前に立てておくことが大事です。
「拙速は巧遅に勝る」
これに関連する話として「拙速は巧遅に勝る（または、巧遅は拙速に如かず）」という格言があります。
仕事の出来がよくて遅いよりは、出来はわるくとも速いほうがよい。
巧遅は拙速に如かず(コウチハセッソクニシカズ)とは - コトバンク
「出来が悪いものより、出来のいいものの方がよい」のは当然ではあるものの、仕事をする上では「出来の良さを追求して遅くなる」よりは「スピードを重視してそこそこの出来で終わらせる」方がいい結果になることもよくあります。
運が良ければ、自分ではそこそこだと思っていた出来で、OKをもらえる可能性もあります。
完璧を目指して遅くなるよりも、そこそこの出来で早く完成する方が仕事の効率が良いことは言うまでもありません。
優先順位を付ける＆優先順位の高いタスクから着手する
タスクは優先順位の高いものから順に着手します、というと「何をそんな当たり前のことを」と思われるかもしれませんが、これは「言うは易く行うは難し」かもしれません。
まず、優先順位に従って行動するためには、優先順位を正しく付けなければなりません。
どういったタスクが優先順位が高いのかというと、たとえば期限が近いタスクや、期限はまだ先だがスケジュールを逆算すると早めに着手しないと後で首が絞まりそうな大きめのタスクが優先順位の高いタスクに該当します。
また、「質問に対する回答が得られないと着手できないタスク」については、早めにしかるべき担当者に質問を投げて回答を待つ必要があります。
次に、優先順位さえ付ければ大丈夫かというと、必ずしもそうではありません。
悲しいことに「優先順位は高いが、着手するのには腰が重いタスク」というものもよくあります。
これはなかなか厄介で、僕も「あー、このタスクやらなきゃ・・・」と思いながら、つい「優先度の高くない簡単なタスク」から片付けようとしてしまったり、ついTwitterやYouTubeを開いて現実逃避してしまったりすることがよくあります😅
とはいえ、最終的には「今やらないと後で首が絞まるから」と自分に言い聞かせて、えいっと着手するようにしています。
小さなタスクはスキマ時間に終わらせる
大きなプログラムを書いたりするときは、まとまった時間（少なくとも1時間以上）がないと着手しづらいです。
「本当はコードを書きたいけど、あと30分したら会議が始まっちゃうんだよなあ。う〜ん」というときは、5分から10分ぐらいで終わる小さいタスクを片付けるようにしています。
こういうケースでは多少優先順位が低いタスクを対応しても構いません。
「忙しいからまだできていません」は「優先順位が低いからまだできていません」だと心得る
やろうと思っているタスクがなかなか完了しない（または着手できない）ときはつい、「自分がずっと忙しいからだ」と考えてしまいがちです。
ですが、「忙しさ」は定性的な基準なので、「忙しさ」をタスクが完了しない原因にしてしまうと状況の改善が難しくなります。
実際のところ、そのタスクが完了しないのは「自分が忙しいから」というよりもむしろ、「そのタスクの優先順位が低いから」という理由である場合がほとんどです。
優先順位をきちんと付けておけば、「今は他の優先順位の高いタスクに取り組んでいるんだから、このタスクがまだ終わっていないのはおかしな状況ではない」と、合理的に考えることができます。
もしそのタスクを早く終わらせる必要があるのであれば、自分の忙しさをどうこうすることよりもむしろ、「他のタスクとの優先順位を見直すこと」の方が有効なアクションになります。
「想像による見積もり」から、「実感に基づく見積もり」に早めにシフトする
タスクが自分のところにやってきたときは、「だいたいこれぐらいでできるかな」と、そのタスクにかかる時間を見積もると思います。
これまでにやったことがあるタスクであれば、見積もりと実績のズレは起きにくいですが、「今までにやったことがないタスク」の場合は見積もりが難しいです。
そういうタスクはなるべく早めに「ちょこっとかじってみる」ことを心がけています。
実際にそのタスクに着手してみると、「む、これは思った以上に時間がかかりそうだぞ」とか「いや、意外とサクサク進むのでは？」というような「実感」が得られます。
「だいたいこれぐらいかなー（やったことないけど）」という想像の見積もりよりも、実感に基づく見積もりの方がより正確なはずです。
自分の記憶を頼りにしない（タスクはTODOリストで管理する）
仕事をしていると、いろんなタスクがあちこちから舞い込んできます。
あれもしなきゃ、これもしなきゃ、というTODOを頭の中で管理するのはよっぽどの記憶力の持ち主でないかぎり、至難の業です。
なので、新しいタスクが発生したときは、仕事上のタスクもプライベートのタスクも含めて、早めにTODOリストに書き出すようにしています。
TODOリストに書き出せば、自分の頭の中からは消えてしまっても大丈夫です。
パソコンで言うと、自分の記憶がメモリで、TODOリストがハードディスク（今は全部SSDか）、という感じですね。
「あれもしなきゃ、これもしなきゃ！あー大変、たいへん！」という気持ちは、なるべく早く頭の中から追い出しましょう。
その方が「今、自分の目の前にあるタスク」に集中しやすくなります。
TODOリストはEvernoteで管理
ちなみに僕は自分のTODOリストはEvernoteで管理するようにしています。
Evernoteは、
- 箇条書きをネストできる
- チェックボックスでDONEを管理できる
- 重要なタスクは太字や蛍光ペンで強調できる
- MacやiPhoneなど、いろんなデバイスでデータを同期させられる
といった点が気に入っています。
タスクが多すぎてパンクしそうなときは、マインドマップを描いて状況を俯瞰する
並行していろんなタスクに取り組んでいると、TODOリストですらいっぱいになってきて、「タスク多すぎー！もう無理〜！！」という気持ちになってくるときがたまにあります。
そういうとき、僕は自分の心を落ち着かせるために、紙の上にマインドマップを描いて「この1〜2週間で終わらせるべきタスク」を整理します。
「そもそもマインドマップって何？」という方は、こちらの本をご覧ください。
タスクがたくさんあるときは、モニタの中のTODOリストよりも、紙の上に描いたマインドマップの方がタスクを一望しやすいです。
マインドマップを描いたら、優先順位の高いタスクが目立つように赤ペンで色を付けます。
そして、タスクが完了したらそのタスクを二重線で消していきます。
こんなふうにタスクを消化していくと、客観的に自分の状況が把握できて、難局を乗り越えられることが多いです。
大きなタスクは小さなタスクに分解する
何時間も（あるいは何日も）かかるような大きなタスクは事前に小さなタスクに分解します。
「小さなタスク」の目安は、だいたい30分から1時間ぐらい、長くても2〜3時間で終わるぐらいのボリュームです。
大きなタスクが「でーん！」とTODOリストに載っているとなかなかDONEになりませんが、小さなタスクであれば小気味よくDONEにしていくことができます。
タスクを小さく分解して「進捗してるぞ、着実に前に進んでるぞ」という感覚を自分の中で味わえるようにしておくことも、仕事をする上では大事です。
1〜2週間先のスケジュールを常に把握する
大きめのタスクはスケジュールを逆算して早めに着手しないと、期限の直前に自分の首が絞まってきます。
また、タスクは複数並行してこなさければいけないときもあります。
各タスクに期限があると、それぞれの進捗をうまく管理しないとこっちのタスクは期限に間に合ったが、そっちのタスクは期限をオーバーしてしまった、ということが起きてしまいます。
（余談ですが、複数のタスクを並行してこなしているときは、こんなふうに「3個以上のお手玉を床に落とさないように必死に頑張っている自分の図」が頭の中に浮かんできます）
大きなタスクや並行して対応するタスクがたくさんあるときに気を付けなければいけないのは、「うっかり忘れていた祝日の存在」や「うっかり忘れていたミーティングの存在」です。
連休が入っていたり、ミーティングが連続して設定されていたりすることを忘れていると、「げっ、来週って3連休になってるの！？😱」と気づいた瞬間にタスクに費やせる時間が一気に減って、あっという間に自分の首が絞まってしまいます。
そうならないように僕は1〜2週間先のスケジュールや祝日を手書きのスケジュール表で管理するようにしています。
仕事中はこのスケジュール表をときどきチェックしながら、期限をオーバーしないようにタスクの対応予定を逆算しています。
このタスク管理方法については以下のエントリで詳しくまとめているので、気になる方はこちらをご覧ください。
blog.jnito.com
困ったら早めに人に頼る
タスクにも簡単なタスクと難しいタスクがあります。
特に、プログラムを組むときは「初めて使うライブラリなので使い方がわからん！」とか、「原因不明のエラーが出て全然解決できねえ！！」みたいなことがときどき発生します。
そんなとき、20〜30分悩んでうまくいかなかった場合は、自分のアホさ加減を素直に受け入れて、トラブルを解決してくれそうな誰かに頼るようにしています。
なぜなら一人でずっと悩むより、誰かに頼ってぱっと解決する方が圧倒的に効率が良いからです。
自分も誰かに頼られる人間であることを目指す
もちろん、四六時中「助けて、助けて」と連呼しているばかりでは、他の人の足を引っ張るだけの存在になってしまいます。
そうならないように、自分の得意分野と苦手分野を把握し、自分の得意分野については「みんな、どんどん頼っていいよ！」と宣言しておきましょう。
そうすることで、チームメンバーと「持ちつ持たれつ」の関係を築くことができます。
心が折れそうになったときも誰かにヘルプを求める
上の例では「自分の書いたコードが動かない」というような、「瞬間的に困った状況」を例に出しましたが、「忙しすぎて精神的につらい」とか「仕事がうまくいかなくて心が折れそう」みたいな「長らく続いている困った状況」に陥ったときも同じです。
一人で悩んでいると同じ考えがグルグル巡って抜け出せなくなることも多いです。
「ヤバい」と感じたら早めに「メーデー、メーデー！」と叫んで周りに助けを求めましょう。
無理をせず、体調を整えて安定したパフォーマンスを出せるようにする
一般論として、責任感が強くて真面目な人ほど、「ちゃんとやらなきゃ、ちゃんとやらなきゃ・・・！！」という思いが強くなって、ついつい頑張りすぎてしまう傾向があると思います。
もちろん、頑張ること自体は良いことなのですが、「頑張る＝無理をする」になるのはちょっと危険です。
なぜなら、無理をしすぎると体調を崩す原因になるからです。
いくら頑張ってハードに働いても、体調を崩して2〜3日穴を空けてしまったら、ハードに働いた分がチャラになってしまいます。（下手するとマイナスになるかも）
それよりも「無理をしすぎないようにする」「無理をしない代わりに体調管理をしっかりして、突然穴を空けてしまわないようにする」とした方が、継続して安定したパフォーマンスを発揮できます。
「ついつい無理をしてしまう真面目な人」は体調を崩さないように、適度に力を抜く方法を探してみましょう。
自分の限界を把握する＆限界を超えてまでタスクを引き受けない
「無理をしない」というのは、「無理をしなければならない状況を作り出さない」ということと、ほぼイコールだったりします。
つまり、「ここまでなら大丈夫」「ここを超えると黄色信号」という自分のキャパシティを把握し、黄色信号になりそうな場合はタスクを引き受けない（またはタスクのボリュームや期限を調整してもらう）、ということも大事です。
まとめ
というわけで、このエントリでは僕が仕事をする上で大事にしていることをいろいろとまとめてみました。
どれも当たり前のことばかりだったかもしれませんが、僕の経験上「当たり前のことを全部きっちりできる人」というのは世の中では意外と少ないと思います。（もちろん僕もときどきミスします！）
ここまで、あれこれいろんなことを書いたのですが、ざっくりと基本的な考え方をまとめるなら、
- 相手の期待に応える（できれば期待以上の成果を出す）
- 相手をガッカリさせない
というこの2点に尽きるような気がします。（2点といっても、どちらも実質的に同じことを言ってますね）
つまり、「相手に期待に応えること / 相手をガッカリさせないこと」が相手にとっての価値になり、それが自分の評価につながります。
仕事っていうのは結局のところ、そういうことの繰り返しなんじゃないかなーと思います。
だから、このエントリで書いた「大事なこと」は、どれも最終的に「相手に期待に応えること / 相手をガッカリさせないこと」につながっているはずです。
そして、そのゴールをいかに効率よく、少ない工数で達成するか、というポイントも重要です。
みなさんもこのエントリの内容を参考にして、自分なりの「仕事の進め方」を工夫してみてください！
あわせて読みたい
ここで挙げたポイントは僕が独自で編みだしたものばかりではなく、今僕が勤めている株式会社ソニックガーデンに入ってから学んだことも多いです。
同じような話は社長の倉貫さんのブログにもたくさん載っているので、興味がある方はこちらもどうぞ。
その昔読んだこの本も僕のタスク管理・時間管理に大きな影響を与えています。
「今の忙しさをなんとかしたい！」と思っている方は、ぜひ読んでみてください。
- 作者:Thomas A. Limoncelli
- 発売日: 2006/10/19
- メディア: 単行本（ソフトカバー）
