仕事をいつ終えられるか？

システム開発に携わっていると仕様変更やバグ対応など予定していなかった突発的な作業が度々舞い込んでくる。

その時、進捗管理を担当している方から聞かれることがある。

進捗管理者「その対応っていつ頃終わりそうっすか？」

聞かれた時、頭をフル回転させて大体の作業の流れをイメージする。

（え～と…まずお客さんに不明瞭な要件を確認して、その後は設計書にも反映して、レビューもするだろうし、並行して進めている他作業もあるし、バッファも見込んでおきたいから…）

そして、回答する。

私「3日くらいで終わると思います。」

すると、大概は嫌そうな顔をされるか、そんなにかかるのかと否定的な意見を言われがちである。
3日かかるとした根拠を説明してもイマイチな反応をされる。

では、どうすれば導き出した工数に納得してもらうことができるのか？

工数に求められていること

工数を見積もる方法はググればいくらでも記事が見つかる。

しかし、突発的な作業に対する工数や期限の正確性や正当性は、実は案外どうでもよかったりする。

進捗管理者は「いつ頃終わりそうっすか？」と聞いている一方で、内心は「いつ頃までに終わらせてほしい」とか「○○日あればできるだろう」いう期待値となる工数をこっそり隠し持っている。

できるかできないか、が開発者にとって重要だが、
期待しているより早いか遅いか、が進捗管理者にとって重要なのである。

極論、早ければ早いほど進捗管理者にとって嬉しい（ただし、品質が担保されることが前提。）

期待値の裏にあるもの

進捗管理者の期待値（工数）に根拠は無い。
明確な見積りを行った上で早いだの遅いだの意見する人もいるかもしれないが非常に稀な人だろう。

期待値は経験と感覚で工数を導き出している。つまり、ただの勘である。

そんな根拠のない期待値に合わせて無茶な工数で「できます！」なんて言ってしまうと残業でカバーする羽目になりとても辛い思いをする。
残業でもカバーできないとなると、結果的に周囲に迷惑がかかり信用を失ってしまうかもしれない。

予定外な作業が舞い込んだ時、通常ならスケジュールを柔軟に変更・調整すべきである。
（スケジュールを延ばす、他の作業を止める、誰かに作業を依頼する など。）

しかし、実際のシステム開発の場において、スケジュールの変更・調整を前向きに捉える人は少ない。

理由はお偉いさん方の圧力だったり予算の都合だったり遅延している感じがして嫌だったり人手不足だったり様々である。

「いつ頃終わりそうっすか？」にどう回答すべきか？

「いつ頃終わりそうっすか？」の軽いノリのような質問に対して、進捗管理者の期待に無理に応える必要はない。
なぜなら期待値はただの勘でしかない場合が多いから。

もちろん、期待よりも早く、そして正確に作業を終えられる優秀なエンジニアもいると思う。
しかし、経験もスキルもバックボーンも人それぞれ違いがある。品質や作業スピードに差が出るのは当然だし、だからこそレビューをする。

やってみたら案外、期待通りに作業が終わったなんてこともあるかもしれない。
しかし、それは結果論であり結局のところやってみないとわからない。

だから、自分の見積りには自信を持って伝えればいい。

自信を持って必要な工数を伝えると場が荒れてしまうのであれば、その場での回答を避けて後ほど改めて個別に回答すればよい。