はじめに
社会人になると、必ず先輩や上司から作業がいつ終わるのか確認されます。
その際に、工数見積の方法を知っていないと信頼を失うことになりかねません。
例えば、以下のようなケースで信頼を落とします
- 作業工数が答えられない
- 作業工数の見積根拠を答えられない
- 見積もった作業工数より、実際の工数がかかる
この記事を読むことで、基本的な工数見積の方法が身に付き、信頼を落とすことを減らすことができますので、目を通してみてください。
シンプルな作業見積方法
工数見積方法を解説していこうと思いますが、見積工数時間の報告の仕方のキホンをまずお伝えします。
以下の内容を伝えると良いです。
- 作業にかかる時間(見積もった工数)
- その根拠
- 作業リスク
例えば、「作業にかかる時間は3時間で、その根拠は〇〇で、〇〇のリスクが発生する可能性があります」のような形です。
まずは、工数の見積から説明していきます。そのあとに、作業リスクについても説明していきます。
もっともシンプルな見積方法
まず、例として、以下の3つの機能のテストケースを担当する想定で話を進めます
最もシンプルな見積は、以下の式で表せます。
見積工数 = テストケース数の合計 × 1件あたりにかかるテストケース時間
例えば、上の例で表すと、以下のようになります。
見積時間 = (10 + 20 + 30) × 5分
見積時間 = 300分
ただし、この場合、1件あたりにかかるテストケース時間の根拠を聞かれた場合に困ります。
1件あたりにかかるテストケース時間は、テストケースの内容を見てみて、どれくらいかかるか想定した値を入れてもよいです。(1件のテストケース単位での見積は、細分化されているためそこまで乖離が出ないはずなので)
より精度を上げるためには、実際に2～3件実施してみて、その実績値を使用するとよいです。
まず、これがシンプルな見積方法となります。
コツは、なるべく作業を細分化・数値化し、全体のボリュームを算出することです。
では次に、一つステップアップした、見積方法を説明します。
作業の重みを考えて工数見積を行う
先ほどのテストケースがもし、以下のように機能ごとにテストケース実施の難しさが違う場合どうでしょうか。
先ほどの計算式だと、どの機能も1件当たりのテストケース時間は同じで考えてましたが、機能ごとに難易度が違うとなると、見積した時間と、実際の作業時間とに差異が発生します。
差異を少なくするためには、機能ごとに、1テストケースあたりの時間を見積と良いです。
例えば、1テストケース当たりの見積時間が、機能A = 5分、機能Bは20分、機能Cは10分だとします。
その場合の作業見積時間は、以下となります。
作業見積時間 = (10ケース × 5分) + (20ケース × 20分) + (30ケース × 10分)
作業見積時間 = 750分
このように、作業難易度を考慮して見積をしていくことで、実際の作業との乖離を減らすことができます。
次にリスクに関して説明していきます。
作業リスクに関して
リスクは、将来のいずれかの時において何か悪い事象が起こる可能性のあるものをいいます。
例えば、「風邪が流行っているので、ここ1週間で休む可能性があります」のような形です。
作業する際に、発生しそうなリスクがある場合は、作業見積時間とともに上司に伝えます。
そうすることで、上司はリスクを把握し、そのリスクに対して、リスクが起こった時の問題を軽減や、そもそも回避する方法をとることができるからです。
先ほどの3つの機能のテストケースに、以下のような条件があった場合を考えます。
機能Cは機能Bを使用している(機能Cは機能Bに依存している)場合、リスクが発生します。
例えば、テストCの機能テストをする場合、機能Bのテストおよび不具合の修正が終わっていないとテストできないため、その点がリスクになります。
報告の仕方
今までの、テストケースの例をもとに報告の例を挙げます。
報告の内容は、以下の3つでした。
- 作業にかかる時間(見積もった時間)
- その根拠
- 作業リスク
これに当てはめると、
作業にかかる予定時間は、
12時間半(750分)の予定で明日の午前中を目途に完了予定です。
根拠は、
機能Aは10ケースあり、1ケース当たり5分
機能Bは20ケースあり、1ケース当たり20分
機能Cは30ケースあり、1ケース当たり10分
かかる想定です。
1ケース当たりの時間は実際に2ケースずつ行った平均値を採用しています。
リスクは、
機能Bは、機能Cで使用しているため、機能Bに不具合があり、機能Cの実施の際に機能Bの不具合が残っている場合、機能Cのテストケース実施ができない可能性があります。
のような形で報告するとよいでしょう。
さらに見積精度をあげるために
さらに見積精度を上げるためには、以下を行うと効果的です。
- 見積時間と実際の作業時間の差異を見比べて、どこに差異があったか把握する
- 実際に作業した時間と生産内容を記録しておく(例えば、ソースコード100行記載したときに、5時間かかったなど)
特に後者の、自分自身の生産性がどの程度なのかを記録しておくと、今後の作業見積の参考になるため、とっておくとよいです。
最後に
作業工数の見積は、プログラマだけではなく、プロジェクトを受注する際ももちろん行います。
プロジェクトの成功率は、工数見積の正しさで大きく変わってきますのでとても重要です。
また、工数見積の根拠やリスクをわかりやすく伝えることで上司や、お客様へ納得してもらえるため、根拠を伝えるスキルも重要ですので、少しずつ経験を積み、見積精度を高めていくと良いです。
シンプルな工数見積方法について記載しましたが、以下の内容も解説してますのでご参考ください。
コメント