はじめに

本稿では、仕事をする上での作業工数の見積もり方法について説明します。

工数とは何か

工数(こうすう¹)というのは、仕事において、あるひとつの作業を完了するまでにかかる総累計時間のことです。情報処理技術者試験に出てくるTAT(ターンアラウンドタイム)とは意味合いが異なります²。

例えば、ある作業に40時間(40H³)かかるとした場合、工数は40時間であるといえます。1日8時間勤務だとした場合、40時間は5人日(にんにち)と表現することができます。さらに、1ヶ月20日勤務だとした場合、0.25人月(にんげつ)と表現することもできます。

一般的に工数の単位は「人日」および「人月」で扱います。

学生時代は工数を気にすることはないですが、ITエンジニアとして会社で働くようになると、かならず工数を意識する必要があります。

なぜ工数を意識する必要があるのか

なぜ工数を意識する必要があるのかというと、社員が仕事できる勤務時間には限りがあるからです。
会社を経営している側ではなく、会社に所属しているサラリーマンは労働基準法により、労働時間の上限が決まっています。2015年の某大手の違法残業事件をきっかけに、残業規制が一段と厳しくなってきています。過労死ラインとなる時間外労働時間は80時間(1ヶ月あたり)とされています。

また、予算の都合もあります。一般的にサラリーマンは時間給⁴で、社員の働いた時間を給料として支払われるので、労働基準法的にセーフでも予算が不足していると、残業規制がかかることがあります。

20年以上前のバブルの時代は、「働き方改革」といった言葉もなかったですし、会社もお金がたくさんあったので、社員は異常なほどの残業をして働くのが当たり前でしたが、今はもうそのような時代ではなくなっています。

QCDのC

ITエンジニアは仕事をする際、常にQCDを意識する必要があります。

• Q=Quality, 品質
• C=Cost, 工数
• D=Delivery, 納期

本稿はQCDのうちの"C"に関するものとなります。

工数の見積もりの重要性

作業に着手する前に、まず作業にかかる工数の見積もりを行います。
前述した通り、ITエンジニアがプロとして仕事する場合、その作業に無限大の時間をかけて取り込んでよいわけではなく、かけられる時間に限りがあります。
また、ひとつの作業とは並行して別の作業を行わないといけない場合もあるため、ひとつの作業に予定以上の工数をかけてしまうと、他の作業に回す工数が足りなくなって、結果として作業進捗が遅れる原因となります。

そこで、最初に作業にかかる工数の「予測値」を決めるわけです。そして、この予測値(見積もり工数)は実際にかかる工数よりも超えない値にする必要があるため、この見積もりという作業は実は案外難易度の高い作業になり、苦手な人が多いです。

つまるところ、

実工数＜見積もり工数

が成立することが重要です。

もし、実工数が見積もり工数より増えてしまった場合、その作業が完了するまでそのまま作業を進めていくしかなく、それにより他の作業に回す工数が減ってしまったとしても、どこからから工数が補充されるわけでもないため、ITエンジニアはより苦しい状況に追い込まれます。

いわば、見積もり工数は自分自身を守る盾となるため、実工数より少なくならないようにしておくことが大事です。また、実工数が見積もり工数より増えてしまった場合、たいていは見積もりを出した人の責任になります⁵。

工数を見積もらなくてもよいケース(?)

上長から、作業工数の見積もりもなしに、
- 急ぎの案件だから、MM/DDまでにやるように。
と作業依頼を受けた場合は要注意です。

納期優先となっている可能性があり、納品まで工数度外視な働き方をせざるを得ないことがあります。むちゃくちゃな働き方をしても問題ないというのであれば、それでもよいのかもしれませんが、おすすめはしないです。

見積もりの仕方

概要

作業工数の見積もりは論理的に計算式で表現することが大切です。一番ダメなのが適当に見積もることです。

例えば、ITエンジニアの職種がプログラマだったとして、「ソフトウェアのバグ修正」にかかる工数を見積もるとしましょう。

• とりあえず、やってみないと分からないけど、3日間ぐらいかな。

3日間なので3人日(24H)という見積もり工数となりますが、この数字に何の根拠もないので、まったく信用性がありません。ただし、仕事ができるベテランエンジニアであれば、このやり方でも問題ないです。見積もり工数が適当ではなく、経験に基づく直感によるものだから信憑性があるからです。

適当ではなく、精度が高い見積もりを行うには、以下がポイントです。

• 作業を細分化して個々に数字を出す。
• 過去の実績をフィードバックする。
• バッファを加算する。
• 上長のクロスチェックを受ける。

作業の細分化

趣味でソフトウェア開発をしている場合は、ただひたすらにプログラミングするだけであることが多く、概ね以下の流れになります。

1. バグの原因を調べる
2. バグのコードを修正する
3. プログラムを動かして修正確認する

これが仕事となると、作業工程が大きく変わってきます。会社やプロジェクトにより文化が異なりますが、一般的には以下の流れになります。

1. バグの原因を調べる。
2. 原因が根本原因⁶であるかを判断する。根本原因でなければ1へ戻る。
3. なぜ、そのバグが摘出されたのかを見解を作る。
4. バグの修正方法を検討する。もっとも影響範囲が少なくなるように。
5. 設計バグであれば設計書を修正する。
6. ソースコードを修正する。
7. エビデンス⁷のクロスレビューを行う。レビューが完了するまで5と6を繰り返す。
8. 修正箇所に関して、プログラムの単体テストを行う。
9. 修正箇所に関して、プログラムの機能テストを行う。
10. 修正箇所に関して、レグレッションテスト⁸を行う。

以上のように、単純にソースコードを直せばよいとはならないことを理解する必要があります。一口に「バグ修正」と言っても、複数の項目に細分化されます。項目ごとに工数を見積もります。

過去の実績

作業はやはり実際にやってみないと分からないところがあるので、過去の実績があると、見積もった工数との乖離がないかを事前にチェックすることができます。

例えば、バグ修正にかかる作業の平均値が30時間であるのに、見積もった工数が20時間だとすると、乖離があり、さらに平均値より少ないため、本当にそんな少ない工数でやりきれるのが分かりません。

バッファの加算

見積もった工数にかならずバッファを足し込みます。バッファというのは余剰工数のことです。見積もりなんて、所詮は予測値でしかないため、実際に作業を進めてみると、事前に予想していなかった作業が出現することがありますし、思いのほか時間がかかる作業項目があるかもしれません。
そういったトラブルに対応するために、工数に余裕を持たせておくのです。

見積もった工数を1.5倍しておくとよいです。この「1.5倍」という数字に意味はなく、単なる筆者の経験則です。

見積もった工数×1.5

先の例では30人Hと算出されましたので、1.5倍して45人Hとします。

クロスチェック

最終的に算出した見積もり工数は上長のクロスチェックを受けます。
作業項目の見落としがないか、工数が少なすぎないかという観点で確認してもらい、問題があれば再度見積もり工数を見直します。

あとは上長にも見積もり工数に対して責任をもってもらうという意味合いもあります。

おわりに

工数は生ものです。プロジェクトが進んでいくと、当初余っていたはずの工数がだんだん足らなくなっていきます。原因は様々ですが、見積もり工数が少ないことがよくあります。
「どうして見積もり工数が少ないんだ！」と怒られないようにするためにも、きっちり見積もってから仕事を進めていきたいものですね。