工数見積もりの方法と失敗する原因を解説

工数の見積方法は様々であり、システムによっても工数や金額が異なります。同じシステムを作ったとしても担当者によっても工数の数え方が異なります。あまりにも安く短い工数だと品質が確保できなかったり、納期通りにシステム開発が完了しなかったりする可能性があります。
ただ、システム開発には多くの工数が含まれるために、適切に工数を判断するには経験と知識が必要です。
本記事では、工数見積もりで失敗しないために、見積もりの方法や失敗しないポイントについて具体的に解説していきます。
ぜひ工数見積もりの参考にしてください。

工数見積もりの重要性

スピード重視で工数見積もりを簡単に済ませてしまい詳細の設計などがおろそかになってしまうと、見積もった工程と実際の開発スケジュールと大きな乖離が発生することになります。スケジュールが大幅に遅れると納期に間に合わず発注者に迷惑を掛けるだけでなく、遅延による追加請求を支払う可能性もあります。
正しく見積もりの内容を見定め、詳細に細部まで検討して工数を見積もることが重要になります。

工数見積もりの方法

工数見積もりの方法としては様々な方法がありますが、本記事では代表的な4つの方法についてご紹介していきます。どの方法もよく使われており、マスターすることをおすすめします。

• ボトムアップ（工数積み上げ）
• トップダウン（類推見積もり）
• パラメトリック（係数モデル）
• 三点見積もり

ボトムアップ（工数積み上げ）

ボトムアップによる工数見積もりは、工数積み上げとも呼ばれ、開発するシステムの要素を一つ一つ抽出・積算して全体を見積もる方法です。

ボトムアップ方法のメリットとしては、漏れなく抜けなく工数に必要な工程をピックアップできるため、かなり確度の高い工数を構築することができる点です。

その一方で、大規模プロジェクトや新規分野プロジェクトにおいては、詳細な工程を算出することが困難であり、工数積み上げができないデメリットが存在します。

そのため、ある程度中規模のシステム開発プロジェクトにボトムアップによる工数見積もりが利用されます。

トップダウン（類推見積もり）

トップダウンによる工数見積もりは、コストや類似例から工数を見積もる方法で、類推見積もりとも呼ばれます。

一番参考にされる工数は、過去に行った類似システムの工数になります。担当者のスキルにより実際にかかった工数となるため、ある程度妥当な工数が作成できることがメリットです。

類似システムの開発を行ったことがない場合は、担当者の経験から開発コスト規模感を算定し、そのコストから工数を想定します。

このトップダウン方法は、担当者のスキルに左右されるため、担当者がどれだけシステム開発を経験したかによって工数精度が決まります。

パラメトリック（係数モデル）

必要な要件要素やシステム設計要素を点数化し、それらの総合点から工数見積もりをする方法をパラメトリックと言います。
パラメトリック方法は、工数算定において係数を使用するため係数モデルとも呼ばれます。

パラメトリックによる見積もりは、誰が計算しても工数が機械的に算出され、再現性が高い結果が得られることがメリットとなります。
担当者の経験から算定されるトップダウン方法に比べ、担当者によらず標準化しやすいことも特徴です。

ただし、使用する係数が正しいことが前提の方法であるため、単価やスキルが変わる場合は係数がずれてくるため、適宜係数の見直しが必要になります。

三点見積もり

システム開発プロジェクトの代表で集まり、システム開発工程の規模感を話し合って、最頻値、楽観値、悲観値の三点から見積もる方法を三点見積もりと言います。

上記の値を使用した工数算定式は以下になります。
（悲観値＋４×最頻値＋楽観値）÷６

• 悲観値：リスクも考慮し一番遅れた場合の値
• 最頻値：実現性のあるもっとも妥当な値
• 楽観値：ミスや遅延がなく最短で終了する値

妥当な工数だけなく、最短最長の工数を考慮して余裕やリスクを数式にしたものが三点見積もりになります。外乱により工数変動が多くなる工程が含まれている場合に利用されます。

見積もりの対象項目

続いて見積もりの対象項目について紹介します。それぞれ重要な項目になるので、抜け漏れなく工数に項目として盛り込みましょう。

項目①要件定義費用

システム開発において最初に行う要件定義を見積もり項目として入れます。要件定義は発注者の要求をシステム化する上で重要な工程であり、この工程の良否によりプロジェクトの完成度が変わります。

発注者へ要求内容を詳細ヒアリングして要件仕様を固めることが肝要になるため、本工数は多めに設定しておきましょう。

項目②設計費用

次にシステム化する要件を設計する費用が必要になります。

発注者の仕様に応じた全体システムの構築する上で、クライアントやサーバーやネットワーク環境を設計するため費用を見積もります。

担当者のスキルや社内外リソースにより設計範囲や期間が変わるため、詳細に費用を積み上げましょう。

項目③デザイン費用

昔のシステムに比べ、最近のシステムはUI（ユーザーインターフェース）の項目が豊富なこともあり、システムの画面レイアウトに費用がかかります。

プログラマーだけでなく営業やSE（システムエンジニア）の意見も取り入れ、発注者に使いやすいシステムを開発するにはそれなりの工数がかかります。

項目④開発費用

システム開発における開発費は、プログラマーのプログラミング費用になります。既成のシステムを導入する場合でも、発注者仕様にカスタマイズするために開発費用は必要になります。

プログラミングするだけでなく、プログラム構成を考えるエンジニアリング工程も含めて工数を積み上げるようにしましょう。

項目⑤導入費用

導入費用は、発注者が指定する事務所などの現地にシステムを設置する費用を指します。

システムを設置するためには、ネットワーク環境やシステム設置施工費用が含まれるため、現地を視察して利用できる既設環境を確認しましょう。

現地改造が必要な部分も発生する可能性もあり、改造工数も忘れずに盛り込みます。

項目⑥購入費用

システム開発は既存設備で対応することが難しいため、クライアントPCやサーバーなどを新調する必要があります。ほとんどが購入品となるので、購入費用として工数を算出します。

最近はクラウドサーバーを利用するシステムが多く、既設の発注者が所有するPCを利用して専用アプリをインストールするケースが増えています。

上記の場合はアプリのライセンスが購入費用になります。

項目⑦交通費用

近年はコロナ禍によりテレワークが促進された背景もあり、システム設置場所まで出張することは少なくなっています。打合せやシステム設定をリモート接続で行うこともでき、交通費自体が縮小されています。

一方で、システムが複雑化した昨今、システムに疎くなっているユーザーが増えている事実もあります。発注者から現地レクチャーを要望されることもあるため、レクチャー回数に応じた交通費用を工数に入れておきましょう。

項目⑧保守費用

システムを継続的に利用するには、保守が必須となります。

保守費用はユーザーがあまり意識せず、後々トラブルになることが多いため、利用ユーザーに向けて保守内容を説明して工数に保守費用を入れておきましょう。

最近は長期保守契約を結ぶことが好まれるため、長期バックアップ体制構築に必要な費用を盛り込みましょう。

工数見積もりが失敗する原因

工数見積もりが失敗する理由は、見積もり内容が甘いことに由来することがほとんどです。
詳細に見積もったつもりでも、後工程になったときに意外と抜けていることに気づくことが多いのです。

予算内でプロジェクトを納品できるよう失敗する原因を理解する必要があります。ここでは失敗原因について紹介していきます。

原因①工数を細分化していない

十分にシステム機能やプロジェクト全体の動きを理解していないと、工数見積もりが甘くなってしまいます。
それに加えて、実現性のない工程が含まれているとやり直しが発生してしまいます。

以上のことが起きる原因としては、工数を細分化できていないことにあります。

担当者のスキル次第で細分化できるレベルは変わりますが、認識齟齬が出ない程度に仕様書を固めて発注者と認識を合わせることで失敗は回避できます。

システム開発に慣れてくると、前と同じでも大丈夫だろうと考えがちです。しかし、使う人や環境が毎回異なるためにシステム一つ一つは必ず違うところがあるはずです。工数をなるべく細分化して関係者に確認しましょう。

原因②ヒアリングが不足している

発注者からのヒアリングが足りていないと、仕様の見積もりが甘くなります。そのまま進めてしまい、システム完成手前で発注者の指摘により開発のやり直しが発生することがあります。

また、発注者の気が途中で変わって仕様が変更・追加されることもあります。それを防ぐために、要件定義の段階で発注者と開発対象外範囲についても話しておくことが良いです。

例えば、入力が煩雑な項目はシステム化し、簡単に入力できるところは変更・追加費用がかかるためシステム化しないと発注者と取り決めることです。

この場合、システム化範囲が重要ではなく、きちんと発注者とシステム化しない箇所をヒアリングで話し、変更・追加は費用になることを事前に話していることが重要です。

システム仕様だけに着目せず、仕様以外の箇所も丁寧にヒアリングすることで工数増加は防げます。

原因③バッファを設けていない

余裕を見込まずに工程をみっちり組んでしまうと、後工程で発生したトラブルを吸収できずに納期遅れになる可能性があります。
また、プロジェクト開始前は担当者が少なく、開始まで時間がないことから、十分にシステム設計を詳細に検討することができません。

スケジュールにバッファを設けることは重要で、各工程におけるトラブルや想定外の詳細設計検討工程を吸収でき、突然の仕様変更にも柔軟に対応できます。

一方で、バッファを詰め込みすぎると、発注者が納期を縮めようと交渉してきます。バッファを入れつつもスケジュール短縮を許容できるところは縮めるように努力しましょう。

工数見積もりを失敗しないためのポイント

次に工数見積もりで失敗しないポイントについて紹介します。要点を抑えれば正確な見積もりを作ることが可能になります。

ポイント①ロードマップを作成する

プロジェクトに必要な工数を積み上げ、全体ロードマップを作成することをおすすめします。

一つ一つの工数を詳細に見積もることも重要ですが、全体を通してシステム完成までの道筋を可視化することで抜けている工程が見えてきます。
工数積み上げだけでは見えてこなかった重要な項目が発見でき、工数見積もり精度が高くなります。

ロードマップを作成することで、システム完成までのストーリーを明確にできるため、発注者側も完成までのイメージが掴みやすくなって後戻りリスクが減らせます。

ポイント②複数人でレビューを行う

工数見積もりを関係者間でシェアして、複数人でレビューを行うと工数見積もり間違いを修正できることがあります。

いくら丁寧に工数をチェックしていても、自分の作った資料は先入観が含まれていて間違いを見抜けない可能性があります。必ず2人以上にレビューしてもらうことが重要です。

加えて、プロジェクトに参画しているメンバーに確認してもらうだけでなく、発注者にも工数見積もりを詳細に説明しましょう。
特に開発後期のUIについてユーザー目線で工数不足に気づくことも多く、プロジェクト開始前に気づけば工数修正できます。

ポイント③ツールを活用する

工数見積の失敗を防ぐために、ツールの活用は非常に有用です。

作業工程毎の時間を把握するツールとしてTimeCrowdが挙げられます。TimeCrowdは「誰が」「何に」「どれぐらい」時間をかけたのかをひと目で確認できるツールで、工数把握に役立ちます。

ツールで蓄積した知識を利用して、システム開発に必要な工数を算出でき、見積もり業務の短縮化と効率化を図ることもできます。

以前経験した工数が細かければ細かいほど、正確なスケジュールを作成することができます。

見積もり方法は余裕を持って冷静且つ丁寧に

工数見積もりの方法、見積もり項目、失敗する原因、失敗しないポイントについて紹介してきました。
工数見積もりはシステム開発プロジェクトの導入で一番重要な工程になっており、この工数をいかに的確に見積もるかによってリソースの余裕具合が変わってきます。
発注者に無理な納期を突きつけられても、冷静に開発工数を見積もって、実現可能なプロジェクトになるよう発注者に必要工数を説明しましょう。
そうすれば必ずプロジェクトは成功し、発注者と受注者でwin-winの関係が築けるはずです。

工数見積もりに悩んだ際にはEMEAO!へのご相談を一度ご検討ください。