はじめに
仕事をしていると、人それぞれ仕事の進め方や、タスクに対する考え方など、様々あることを感じます。
その中で、タスクに圧迫されている・いつもなんとなく期限を過ぎてしまっているなんて方はいないでしょうか？
その結果、残業が多く疲弊してしまう・段々と仕事に圧迫されてしまうなんてことも、ちらほら見受けられます。
そんな時に、以下のような動画を見つけました。
中島聡 - なぜあなたの仕事は終わらないのか（TED）
この動画では、「2-8の法則」という名前で、「最初の2割の時間で、仕事の8割を終わらせる」というテクニック面・実践面での話が主でした。（できているかは別として）僕も結構似たような感覚があるな？なんておこがましいことを思ったため、せっかくなら書籍も読んでみようと購入しました。
そしてその1章では、タイトルにもある「どうして仕事が終わらないのか」の原因が挙げられています。
以下三つです。
①：安請け合いしてしまう
②：ギリギリまでやらない
③：計画の見積もりをしない
書籍では、具体的なエピソードとともにそれぞれ語られますが、もう少し個人的な視点で掘ってみようと思いました。
今回は①：安請け合いしてしまうについて、考えて見たいと思います。
安請け合いしてしまうとは？
まず、タスクを安請け合いしてしまうとはどういうことなのか、少し整理しておきます。
一言でいうと、「実際にかかる時間より短く見積もってしまう」ということだと思います。そのままですね。
ただ、意外とこれ起きがちです。（僕も然りですが）あの人結構攻めた見積もり出すな〜と思う時は、大体上記の状況です。割と、感覚的ですが当たっているものです。
では、どうして実際にかかる時間と見積もりのズレが発生してしまうのか、より詳細に見て見たいと思います。
安請け合いしてしまう原因
①応用問題を見ずに請け負ってしまう
この応用問題という表現は、本書籍から借りています。
簡単に内容まとめると、以下のような内容です。
テスト前半の基本的な問題は、教わったことそのままやれば解ける。しかし、応用問題はそうとは限らない。
ある時はひらめきによりすぐ解けることもあるが、何かの見落としや発想が出てこないなどによりドツボにハマるなど、実際に取り組んでみないと、どれくらいかかるのかわからない。
「タスクの表層だけ見てしまうと、実際にかかる時間を見誤る」という解釈なのではないかなと思っています。
例えば、チケットのタイトルや最初の印象からは「簡単そうだな」と思ったとしても、実際そのコードを見に行くと想定より複雑で時間かかりそう、とか、フロントエンドだけで大丈夫だと思っていたけどapiからの情報が足りていなかった、とか、僕らはタスクにかかる時間を軽く見てしまいがちだと思っています。
その結果、「すみません、思ったよりこうなっていて、、、」なんてことに。
また、「それじゃあ実際やってみないとわからないのでは？」と思うかもしれませんが、その通りです。実際、この本にもどれくらいかかるかは、やってみないとわからないという旨が記載されています。
ここで、大事なのは「期限序盤に一気に取り組む」ことです。見積もりの誤りではありません。
序盤で「やばい、これもっとかかりそうだな、、」と思えれば、その報告をして柔軟に対応できます。
しかし、序盤を悠長に過ごすと、気づいた時にはもう遅い、となりがちです。
見積もりを正確に、というのは難しいので、余裕を持ち、伸びるようであれば早く、という意識が良いのかもしれないです。
②他の業務を捨象してしまう
この書籍でも触れられていましたが、あるタスクAがあったとして、あなたは仕事の時間全てをタスクAだけに割けるわけではないでしょう。
メールの受信・送信、ミーティング、デプロイ作業、他のタスク、突発的なエラー対応、恒常的な業務など、様々な仕事を抱えているはずです。
また、自分のタスクでなくても、検証環境を使いたいけど他の人と被ってしまった、なんてことも起こり得ます。
そこで、もし、そのタスクに2日（16時間ほど）割ければ終わるな、と思ったとして素直に2日で請け負ってしまと、絶対に納期には間に合わないでしょう。それだけに取り組めればいいのですが、現実はそううまくできてはいません。
突発的なエラー対応等は予想もできないのでそれを盛り込むのは、、という場合もあるかもしれないですが、想定通りに行くことの方が少ないです。
「他のことがうまく行けば、これくらい、、、！」という楽観的・理想的見積もりは、おそらく少し余裕を持たせたほうが良いというお告げな気がします。
アニメや漫画なら都合よくなってくれるかもしれないですが。うーん。
③いい顔してしまう・見栄を張ってしまう
いい顔、しちゃいませんか？人間、やはり「できないやつと思われたくない」と思ってしまいがちです。
別に無理に短い期限を言わなくていい場面でも、なんとなく早めに見積もってしまったり、もう余裕がないのにできると言ってしまったり。。。わかります。
その瞬間は、もしかしたらよく思われるかもしれません。しかし、もしそれでできないと、そのタスクが遅れるだけでなく、後続のタスクもおそらく遅れが出ます。
結果として、余裕をもって伝えた場合より、いい印象にはならないと思います。
一番よくないのが、自分で自分を下げてしまう可能性があることです。「あぁ、迷惑をかけてしまった」という感情が付きまとい、次は期待に応えようと、また無理をした期限設定で頷いてしまう、そしてまた、、、なんて負のスパイラルにハマることは一番避けたいところです。
それであれば、最初から無理をしない、それどころか少し余裕があるくらいで見積もって、期限通りならそれでよし、巻けばさらによし、くらいの感覚でいるほうが、双方にとって良い状態が作れるのではないか？なんて思ったりします。
※ここは相手といい関係を作るために踏ん張るところだ！という狙いがあってそうするのも一つの手かもしれないですが、それが慢性的にならないようには注意すべきでしょう。
④タスク完了の認識ズレ
これは意識的なところだと思いますが、「1週間」というタスク期限がどこまでか？という認識がずれていることもあります。
例えば、僕は1週間の期限だとしたら、「approveされ、マージできる状態」が1週間後だと考えます。
ですので、最初に提出するのはできれば2~3日目、遅くとも4日目には出ないと厳しいな、と思います。
しかし、「1週間で提出すればOK」と考える方もいると思います。この場合、とりあえず5日目に提出と考えているので、最終的な完了はその先、ということになります。
これは、どちらが正しいというわけではなく、それぞれの考え方のクセみたいなものだと思っています。
そのような状態で見積もりをしても、双方の考えていることが違うため、結果として「安請け負い」となってしまいます。（1週間後に提出と思っていたけど、相手はどうやら完了が1週間後と思っているため無理をしないといけなくなる、みたいな）
これは、最初に想定の認識合わせをしておきたいところです。もしそういう機会がない・すでに大きいプロジェクトで人も多いみたいな状態であれば、「最終的な完了」を見越して見積もる・こなすほうが無難かなと感じています。
⑤タスクを振る側の想定ミス
これも、あります。特にプロジェクトに入ってまもない場合など、すでにチケットに想定時間などが記載されている場合もあります。
しかし、これを盲信してはいけません。タスクを振る側もすべて把握しているわけではない場合も多いからです。
簡単そうなバグチケットを切ったつもりが、いろいろなクラスが絡み合っていて、、なんてこともあります。
こういう時、特に最初の頃は「自分より経験のある人がそういっているんだから、自分が間違っているんだ」みたいな思考になりがちです。
ただ、そのコードを実際に見に行って違和感や懸念を感じたのなら、素直に話してみるほうが良いと思います。結構、あー、確かに、、、みたいになることが多いです。
また、実際に自分の想定が間違っていたとしても、見えていなかった情報をもらえたりするなど、結果としてタスクを早く完了することができる可能性も上がります。
※心理的安全がないと厳しいかもしれませんが、、
間違うことは悪ではないですし、相手も絶対ではないです。自信を持って、話して見ましょう！
終わりに
よく、「スピードが大事！」とか、「早いエンジニアは信頼される！」などの記述をみます。
それは間違いではないと思いますが、そればかりに気を取られ、結果としてタスク完了できなければ本末転倒です。
また、無理な設定をしてしまうと、自分としては残業もして頑張っているのに、期限に終わらず、しんどい思いだけが残ってしまいます。品質もボロボロになりがちですし。
ですので、素直な期限感を伝えていけると良いかなと思っています。
あまり見栄を張らず、それでいて余裕のありすぎないような、、なんてことは難しいかもしれませんが、自分の首を絞めすぎないようにしてほしいなと思います。
株式会社シンシア
株式会社xincereでは、実務未経験のエンジニアの方や学生エンジニアインターンを採用し一緒に働いています。
※ シンシアにおける働き方の様子はこちら
シンシアでは、年間100人程度の実務未経験の方が応募し技術面接を受けます。
その経験を通し、実務未経験者の方にぜひ身につけて欲しい技術力（文法）をここでは紹介していきます。