見出し画像

仕事の工数見積もりを”正しく”できるものなのか

はじめに

近年、ソフトウェア開発のプロジェクトに関わらず、仕事の現場(いわゆる職場)でも労力やそれを割いた時間のことを「工数」と表現するようになった。

あらゆる仕事がプロジェクト化したからとも言えるが、生産性や効率性、合理性などの観点から日本の労働現場でも無駄が排除され、意味のある行動しか評価されない厳しい時代にやっと突入していると言えるのかもしれない。

仕事のプロジェクト化がもたらす効用として、コスト超過や納期遅延などのプロジェクト失敗を避けるため、コストやスケジュールの管理、いわゆる「プロジェクトマネジメント」が導入されることだろう。

今回、扱おうとしている工数見積もりなんてものはプロジェクトマネジメントにおける基礎となるものだが、逆に、これを誤るだけでプロジェクト自体が瓦解するような事態に陥ってしまう。

フルタイムの従業員からパートやアルバイトの方々までが「いつまでにできそうか」と聞かれ、さも当然のように答えている工数見積もり。果たして、そんなにおいそれと簡単にできるものなのかどうかを考えてみたい。

はじめましての方から頻繁に起こしいただく方まで、ようこそ。
どうも、ゑんどう @ryosuke_endo です。

業務工数がプロジェクトマネジメントで最も重要な理由

プロジェクトマネジメントにおいて必要なのは納期である。

さらに言えば、それ以外は不要だと述べることすら可能だ。それほどにプロジェクトマネジメントをする立場からすると、納期を守ることは絶対に死守しなければならない最終防衛ラインだと言える。

納期を遅らせるとは、会社や部署単位での活動を遅延することを意味し、ひいては売上や利益が生じなくなることも想定されてしまう。

つまり、プロジェクトマネジメントが下手くそでプロジェクト自体が延々と繰り返されるような状態を生み出してしまうことは、自らをコストセンター長に任命されることを厭わないと宣言することを同義だ。

わざわざ、そんな不名誉を被ろうとすることほどの物好きは少数派だろう。仮に手を挙げることができるのだとしたら、それは抜本的な改革が可能だと判断した優秀な従業員ぐらいなもので、それ以外の中途半端な人間が手を挙げようものなら火傷だけでは済まないだろう。

業務工数とは、納期を守るための計算を立てる上で必須の項目であり、これが間違っているとすべての計算が合わなくなる。全ての計算、とは納期までの逆算したスケジュールが崩れ、納期を守れなくなるだけでなく、業務に付帯する全てのコストまでが膨らみ、プロジェクトが失敗する。

業務工数の見積もりとは、そこまで熾烈なものであることを自覚しながら出すものであると全ての業務担当者は腹に据えるべきだ。

「それがかなり重要であることは分かったけれど、正確な見積もりなんてどう出したらいいのか」

当然の疑問だ。当然過ぎて涙が出てくる。

そう、業務工数の見積もりがあらゆるプロジェクトにおける基礎となり、重要な屋台骨であることは理解できたが、それを守るためには正確な見積もりが必要になる。

世の中には業務工数の見積もりを正確に出すための研究をしてくれている人たちもいるのだが、文末に幾つかの論文を貼っておくので興味がある方は覗いて欲しい。

これらをいくつか覗くことで共通している工数見積もりの罠が見えてくる。
それは「主観」だ。

熟練者や専門家であろうと主観が入れば間違える

主観。非常に厄介で面倒な存在である。

上述したように、業務工数とはプロジェクトマネジメントの肝になる。予定していた工数を実際が通り越すことは、すなわち巻き返しや余計なリカバリーが生じることを意味する。

正確な工数見積もりができていれば何の問題もなかった業務工数を誤って見積もっていたがために、納期を過ぎてしまうことやスケジュールの見直しを迫られることになる。

では、誰が間違えるのか。
見積もりをする人間、全員である。

見積もりを間違える最も大きな要因は主観であることはすでに記載したが、上司から部下に向かって「いつまでに出せる?」と聞いておきながら想定していた時間よりもかかる返答が返ってくると「それは時間がかかりすぎだ。もっと短くしろ」とかいって主観をぶちまけてしまうことで設定する見積もりが正確ではなくなっていく。

業務を行うのが上司であれば、その見積もりは正しいのかもしれない。しかし、いま見積もりを行うべきは業務の担当者である部下である。実際の業務担当者こそ、過去ログから自らの業務速度を把握しているのだから、誰よりも正確に見積もりを出せるはずである。

しかし、部下は部下で他の仕事も担当していることから、上司から面倒な仕事を押し付けられそうになっている状況に嫌気がさしつつ、それなりの回答をしているわけだが、ここへ存分に主観が入り込んでいる。

つまり、この上司と部下の対応図において、正確な見積もりを上司も出すための支援をできていないし、部下側も余計な主観が入り込んだことによって正確な見積もりが出せない状況になっている。

工数見積もりに必要なのは、機械的な過程や経緯による算出だ。

Windows95で右クリックを実現したエンジニア、中嶋聡は自著『なぜ、あなたの仕事は終わらないのか』の中で見積もりを出すためには実際に着手する必要があることに加え、仮に40時間でやるように納期指定がされていたとしたら調査期間として8時間もらい、その中で8割の完成にまで持っていくことを推奨している。

2割の時間内に仕事の8割を終わらせるのだ、と。そこで8割まで持っていけないようであればリスケを依頼し、なんとか納期を守るための工数を確保するのだと強い語気で中島は書いている。

ここから得られる学びは、カッコつけたメンツや誇張、見栄といった主観なんてクソどうでもいいって話だ。

仕事を正確に見積もるためには、自分の仕事速度を中心に過去実績から丁寧に分析する必要があり、そこに一切の主観的、情動的な変数を織り交ぜてはならない。ただ、自らを機械とみなして工数捻出をするのみである。

おわりに

「そうですねぇ、、来週の月曜日までには…」とか「なるはやで!」こんなやりとりをしている従業員の方々は多いのではないか。

なるはやって何だよ。そんな曖昧でいい加減な締切指示の出し方なんてあるか。しかも、唐突に言い出してるんじゃないよ。

部下側として働いている人たちの中には、そうやって不満と不安をないまぜにしながら過ごしている人たちも少なくはないだろう。

そうやって主観的でいい加減な納期を指定しておきながら、他の納期については厳しめに詰めてくるってのが上司って生き物だ。仕方がないと諦める他にない。

だからこそ、せめて自分を守るために正確な納期、工数を算出することは必要なのである。ぜひ、これからは自らを機械だと規定し、業務をどれだけの工数がかかっているのかを計りながら業務を行い、記録をつけていくことをオススメする。

それによって正確な業務見積もりが可能になるはずである。知らんけど。

ではでは。

ゑんどう

参考文献

  1. 熟練者判断を取り入れたソフトウェア開発工数見積りモデル|角田 雅照、 門田 暁人、ジャッキー キョン、松本 健一

  2. 重回帰モデルによる熟練者見積もり工数の補正の試み|角田 雅照

  3. ソフトウェア規模見積り技術の最近の流れ -行数による評価から機能量による評価へ-|西山 茂

  4. なぜ、あなたの仕事は終わらないのか|中嶋聡

最後までお読みいただき、本当にありがとうございます。 お読みいただき、それについてコメントつきで各SNSへ投稿していただけたら即座に反応の上でお礼を申し上げます!