細切れの時間と細切れのタスク。なぜやるべき事を後回しにしてしまうのか。 | A Day In The Boy's Life

A Day In The Boy's Life

とあるエンジニアのとある1日のつぶやき。

 

これはよくわかるし実際そうなっちゃうことも多い。

ただ、実際そうなってしまう理由を考えてみると状況や環境の制約などによるものも多いと思ったり。

 

 

細切れの時間の中でできること

 

1つは、本来やらないといけない優先度の高いタスクってある程度大きな時間の枠が必要なものが多かったりするわけなんですけど、それを押し込める時間が1日の中にあまりないという点。

会社でのスケジュールを見ていると、打ち合わせが飛び飛びで入っているし、決められた時間で作業しないといけないタスクもあるし、時間が空いたと思ったら「今いいですか?」とか声かけられるし、やらないといけないタスクを集中して実行する時間枠が取れなかったりするわけです。

エンジニア視点で言うと、コードを書くときには集中できる時間を確保したいと思いますし、バグをつぶしていたり調査しているときは誰も声をかけるなオーラを出そうとしたりして、なるべくそれに注力できる時間を確保したいと思うものの実際には他の要因に押しつぶされてしまうのが現状だったりもします。

 

もちろんこれはまとめた時間でやる必要がないわけなんですけど、やっぱり中途半端なところで打ち合わせに行って戻ってきて再開するのって気持ちの面でも持ち直すのに時間がかかったり、再開するときにどこまでやってたのか整理するのに時間がかかったりと非効率であったりもします。

ただ、それはタスクの細分化が下手なだけで、限られた時間の中で達成すべきタスクをうまく細切れにできるかということなんだと思います。

だから優先度が高くとも低くとも、その粒度が大きくとも小さくとも、うまくタスクを平準化するのがコツになってきます。

 

もう1点は、体調とかによって自分の中で制限をかけてしまうという点。

風邪気味だから今日は簡単なタスクだけにしようとか、二日酔いで頭痛くてこんな状態で重要なタスクこなしたら事故るから今日は事務処理の日にしようとか。

まぁこれは自己責任ではあるんですけど、体調によってものすごく集中して短期間でタスクをこなしていける日と、なんか気が乗らなくて集中できない日というのは誰しもあるのではないでしょうか。

 

優先度の低い細かいタスクとは言え、やらないといけないことには変わりはないので、集中する時間が取れなかったり気が乗らないというときはその細かいタスクを徹底的に潰してしまって、明日の集中できる時間を確保する取り組みに変えることも大事なのではないかと思ったりします。

 

 

優先度の低いタスクを隠す取り組み

 

こういうことは自分自身だけでなく、他者へ仕事をお願いするときにも同様に発生します。

優先度の高いものをやってほしいのに、低いものだけやたら頑張ってこなしている人を見ると「それじゃないのになー」とか思ったりするわけです。

若手のエンジニアにぼそっと不具合の事や機能の改善の話をすると、お願いしていることそっちのけで調査を始められたりすることがあります。

それはそれでありがたいことなんですけど、優先順位的には高くないし納期が迫っている別のタスクがあるならその分そっちに集中してほしいと思ったりします。

 

ですので、優先順位の低いタスクをお願いする場合は、各メンバーの稼働の状況を見て忙しそうなら手元にしまったままにし、余裕が出てきたタイミングでお願いするようなことをしたりします。

タスクを可視化してどういう優先度になっているのかを明示してからお願いする方が互いに仕事の順番を見誤らなくて済んだりもするんですけど、タスクを可視化するのは自分が抱えている業務以外にどんなタスクがあるのかという興味が生まれて集中力を分散してしまう結果にもなりかねないので諸刃の剣でもあると思ったりはします。

要は他が気になりだして本業がおろそかになってきたり、技術的な要素とかが含まれると「それ面白そう」という気持ちが生まれてきていつの間にかそればっかりやっているとか。

 

こういうのって経験を問わず陥る罠だったりもするので、優先順位は低いものの他にやらないといけないことがあるというその存在自体を隠してしまう方が集中して目の前の業務をこなしたりできるのではないかと思います。

優先順位が低いので最悪遅延が出てもそこまで支障はないでしょうし、細かいからそれほど時間もかからないものだったりもしますし、小出しにしてやるべき順番をうまくコントロールするのは特に若手メンバーなどでは有効な手段ではないかと思ったりします。