「見積もり」「工数」の考え方をまとめてみます

By: Luigi Mengato

2021年4月から、大きな仕事を引き受けるので、工数や見積もりについて考え方をまとめてみます。

書籍としてこれまで参考になったものは以下の2冊です。

・中島聡「なぜ、あなたの仕事は終わらないのか スピードは最強の武器である」
・オライリージャパン「ソフトウェア開発 ―頭とからだで覚えるソフトウェア開発の基本」

極論を言えば、どちらの著書も似たことを言っています。
おそらく問題の起こりにくい開発というのはどこでもこういうものなのかも知れないと私は思っていますし、現場でも実践しています。

ここから本題です。

「工数」は発注者へ「約束した時間」だと考えています。

まず、工数を考える目安として「できると考えられる時間 x 1.5」が基本となります。
どんなに簡単な機能であっても、必ず 1.5 をかけます。
この 1.5 という数字は、調整して構いません。

「x1.5」＝「必ず出来る時間」と考えるより「余裕をもって完成できる時間」と考えた方が良いです。
実際の仕事の仕方としては「元の時間より短時間」で終わらせるつもりで取り組みます。

どんなに時間があるように思えても、急な用事というものは必ず生まれます。
でも、あなたの仕事は絶対に終わらせなくてはなりません。

そのための時間が「x1.5」であり、これは「必ず守るべき約束の時間」です。

早く終わることができるなら、あなたへの信用度は増すでしょう。
余裕をもって仕事ができるし、無理をして体を壊すことは避けられ、部下に嫌われることもありません。
余分な時間に思えても、これが「実際の現実に使える最適な時間の計算方法」です。

次に大事なのは、なるべく短い期間で「プロトタイプ」を作って、発注者の意見を聞くことです。
「プロトタイプ」が作れないなら、進捗報告でも構いません。
何にせよ、定期的に顧客からの「フィードバック」を受けることが大切です。

もし何のフィードバックも受けないまま進行した場合。
期日になって公開したところ、思っていたものと違う、と言われたら、かけた時間がすべて無駄になります。
残念ですが、現場ではよくあることです。

開発した時間を無駄にしないためにも、フィードバックは必要です。

それでも、顧客がすべてをひっくり返すことはあります。
担当が変わったり、新しい技術が出てきたり。原因は色々あります。それが現実です。

ただ、フィードバックを繰り返し受けてきた過程があるのなら、作り直しとなれば追加の工数や時間は提案がしやすいでしょう。
それに、顧客からフィードバックを受けて作ってきたものが、すべて無駄になる可能性は低いです（フィードバックがないものであれば、本当にすべてが無駄になることがありえます）。

現場に即した考え方としては、長期のプロジェクトであれば、契約や見積もりは「分割」して考えます。
その方が、双方とも、予算が立てやすく、見積もりも確実性が上がります。
よく「第1フェーズ」「第2フェーズ」と言ったりします。

基本機能は第1フェーズで、過程で出てきた機能追加は、第2フェーズで仕切り直します、といった感じです。
顧客や上司に説明しやすいですし、どちらも仕事が続くので、良い解決方法です。

「工数」は発注者へ「約束した時間」であり、それを守るために「プロトタイプ」を作ったり「フィードバック」を行う。
長くなりそうなプロジェクトは「フェーズ」で分割する。
こうした考え方が「信頼される仕事の仕方」になっていくのではと思います。