工数計算のやり方4ステップ【2026年版】稼働率を入れた計算例、エクセルの組み方、工期と費用への換算

「作業は全部洗い出したのに、なぜか毎回1.5倍の時間がかかる」——工数を出す立場になった方から、こうした相談をよく受けます。計算式は知っている。表も丁寧に作った。それでも実績と合わない。あるいは発注側として「合計210人日」という数字を受け取り、多いのか少ないのか判断できないまま決裁書を書こうとしている。どちらも、計算が下手なのではなく、計算に1つ足りない列があるだけです。

結論から言うと、工数計算は4つの数字を順に埋めるだけの作業です。作業を数えられる大きさに割り、1件あたりの所要を置き、件数を掛け、合計する。ここまでは掛け算と足し算しかありません。問題はそのあとで、合計した工数を期間に翻訳するときに稼働率を掛けていないと、計画は初日から見えない借金を背負って走り出すことになります。

人は所定労働時間のすべてを作業には使えません。朝会、進捗報告、レビュー、問い合わせ対応、他案件の割り込みが必ず入ります。1日8時間を丸ごと作業時間として計算した表は、その時点で現実から離れています。稼働率という1列を足すだけで、同じ表が説明できる根拠に変わります。

本記事では、工数計算の手順4段(作業分解→1件あたりの所要→件数→合計)、稼働率とバッファの反映、エクセルでの計算表の組み方と複数人で分担する場合の計算、工数から工期と費用を出す順序、間違えやすい7パターンと受け取った工数の検算、よくある質問の順に解説します。工数という言葉の定義、人時・人日・人月の換算、見積もり手法の4分類は「工数とは」の記事に譲り、本記事は計算の実務だけを扱います。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。見せていただく工数表は、作業の分解はどれも丁寧です。足りないのはたいてい、稼働率とバッファの1列だけです。この記事を読み終えるころには、自分の案件の工数を、他人に説明できる根拠つきで出せるようになるはずです。

工数計算の手順——作業を割る、1件あたりを置く、件数を掛ける、合計する

工数計算でつまずくのは、式が難しいからではありません。掛け算と足し算しか出てきません。実務で手が止まるのは「何を1件と数えるか」「1件あたり何人日と置くか」を決める場面です。ここでは、その決め方を4つの手順に分け、最後に会員制Webサービスを題材にした通しの計算例を置きます。

手順の全体像——4つの数字を順に埋めるだけ

工数計算の手順は、次の4段です。

1. 作業を割る: プロジェクトを、所要を見積もれる大きさの作業に分解する
2. 1件あたりの所要を置く: 作業1件を終えるのに何人日かかるかを決める(単位工数)
3. 件数を掛ける: その作業が何件あるかを数え、単位工数に掛ける
4. 合計する: すべての作業の小計を足し、付帯作業を加える

この4つが埋まれば工数は出ます。工数の定義や人時・人日・人月の換算そのものは「工数とは」の記事にまとめてありますので、単位の前提が曖昧な方は先にそちらをご確認ください。ここから先は、4つの数字の置き方だけを扱います。

手順1: 作業を「見積もれる大きさ」まで割る——粒度の決め方

最初にやるのは分解です。「開発」という塊のままでは、誰も所要を答えられません。「ログイン画面の実装」まで割れば、経験者なら数字が出ます。

分解の軸は2つだけ覚えれば足ります。成果物で割る(画面、API、帳票、テスト仕様書)と、工程で割る(設計、実装、単体テスト、結合テスト)です。この2軸で表を作ると、縦に成果物、横に工程が並び、埋めるべきマスが見えます。

粒度の目安は、末端が担当者1人で所要を言い切れる大きさです。中身を本人しか説明できないほど大きな塊が残っていると、見積もりの根拠になりません。逆に細かく割りすぎると、分解そのものに時間がかかってしまいます。分解にも工数がかかることを忘れないでください。この作業分解の考え方はWBS(作業分解構成図)と呼ばれますが、名前を知らなくても、上の2軸で表を作れば結果は同じです。

手順2〜3: 1件あたりの所要を置き、件数を掛ける——単位工数の作り方

分解が終わったら、1件あたり何人日かを置きます。これを単位工数と呼びます。置き方は3つです。

単位工数が決まったら、件数を数えて掛けます。画面12本、API10本、帳票3本、というように数えられる単位で持つことが肝心です。件数と単位工数に分けておくと、「画面を12から9に減らせば4.5人日減ります」という会話ができます。総額だけを提示した見積もりが値切り交渉になりやすいのは、削る場所が見えないからです。

注意点が1つあります。過去の実績から単位工数を取る場合、2〜3年前の数字をそのまま使わないでください。AIによるコード生成が実装工程の所要を押し下げている一方で、生成されたコードのレビューと検証には従来以上の時間がかかります。実装は過大に、レビューは過小に見積もられがちなのが実情です。単位工数は年単位で見直してください。

手順4: 合計する——会員制Webサービスを題材にした通しの計算例

実際に通してみます。会員登録・ログイン・マイページ・問い合わせフォーム・管理画面からなる会員制Webサービスで、画面12本、API10本という規模を想定します。

ポイントは下4行です。開発環境の構築、レビュー、定例会議、リリース作業を入れると16人日、全体の約19%になります。当社では日本人PMによる設計レビューとGitプルリクエストによるコードレビューを標準の工程にしているため、この分を最初から体制の工数に含めています。付帯作業を後から足す運用にすると、必ず削られて消えるからです。

なお、レビューや手戻りをどこまで工数に含めるかという線引きの全体像は「工数とは」の記事で7カ所に整理していますので、数え漏れが心配な方はあわせてご覧ください。

ここまでで作業量の合計が出ました。ただし、この86人日を人数で割っても、正しい期間は出ません。次章で、その理由と直し方を扱います。

稼働率を入れないと計算は必ずずれる——実働時間の反映とバッファの置き場所

ここが本記事のいちばん重要な部分です。作業の分解が丁寧でも、1日8時間を丸ごと作業時間として計算していると、見積もりは必ず不足します。私が相談を受けた工数表のうち、分解が雑だったものはほとんどありません。足りないのは、たいてい稼働率とバッファの1列だけです。

1日8時間は作業時間ではない——稼働率という1列を前提に置く

所定労働時間が8時間でも、その8時間を作業に充てられる人はいません。朝会、進捗報告、レビューへの参加、チャットへの返信、他案件からの問い合わせ、採用面接や社内研修。こうした時間は工数表のどこにも現れませんが、確実に発生します。

所定労働時間のうち、実際に作業へ充てられる割合が稼働率です。この割合は役割と兼務の状況で変わるので、一律の数字を当てず、案件ごとに引き算で出してください(出し方は次項)。ここを100%で置いた計画は、突発対応を吸収する余地がないまま走り出すことになります。

この表を体制検討の最初に出すだけで、営業や経営層との会話が変わります。「2人出せば1か月でしょう」という見込みが、なぜ現実と合わないのかを数字で説明できるからです。

稼働率の出し方——使える時間を引き算で確定させる

稼働率は感覚で決めるものではなく、引き算で出せます。式は1本です。

稼働率 = その案件に充てられる時間 ÷ 本来の稼働可能時間

月の所定労働時間が160時間のメンバーで考えます。

このメンバーを「1人月」として計算に入れると、実態より4割以上多く見積もることになります。まず使える総時間を引き算で確定させ、そのうえでアサインを組んでください。特に兼務者が多い組織では、帳票上の空き時間と実際に使える時間が大きくずれるのが実情です。

私が相談を受けたある工数表は、作業分解は13階層まで丁寧に割られていたのに、所要日数を「工数÷人数」でそのまま出していました。同じ表に稼働率0.75の列を1つ足したところ、2か月で終わる予定が2.7か月になり、はじめて過去3案件の実績と一致しました。計算の精度を上げたのではなく、抜けていた前提を1つ入れただけです。

スキル係数の掛け方——担当者が決まったら現実に寄せる

単位工数は「平均的なスキルの人が作業した場合」で置きます。実際に割り当てるメンバーが決まっているなら、係数を掛けて現実に寄せてください。

見落とされやすいのは、係数を小さく置ける熟練者を入れると、その人のレビュー工数が増える点です。チーム全体では相殺されることも多く、個人の係数だけを見て全体の工数を削るのは失敗のもとです。

バッファは率を決めて1カ所に——稼働率との二重計上に注意

どれだけ丁寧に計算しても、見積もりは外れます。そこでバッファを置きますが、置き方には作法が2つあります。

1つは率です。新しい技術を使う、要件が固まっていない、外部システムと連携するといった不確実性が重なるほど、率を厚く置きます。この記事の題材では15%と置いており、先ほどの86人日なら約13人日、合計99人日です。

もう1つは置き場所です。各作業に少しずつ隠すのではなく、プロジェクト全体で1カ所にまとめて持ってください。担当者が各自2割ずつ上乗せしたバッファは、全体では2割どころではない量になり、しかもほぼ確実に使い切られます。まとめて持ち、誰の判断で取り崩すかを決めておくほうが、結果として総量は小さくなります。

そしてここが要注意です。稼働率とバッファは役割が違うので、二重に計上しないでください。稼働率は「1日に使える時間が減る」ことを表し、バッファは「想定していなかった作業が出てくる」ことを表します。ところが実務では、稼働率0.8で割り戻したうえに、さらに「余裕を見て」20%を乗せてしまう計算をよく見かけます。これでは同じリスクを2回数えることになり、見積もりは1.5倍に膨らみます。稼働率で吸収するのか、バッファで吸収するのか、どちらの列で見るかを先に決めてから表を作ってください。

エクセルで工数計算表を組む——列の設計、関数、複数人で分担する場合の計算

前章までの考え方を、そのまま表計算ソフトに落とします。専用ツールを導入しなくても、列を正しく設計すれば工数計算は十分に回ります。ここでは列の構成、使う関数、複数人で分担するときの計算、そしてエクセルで足りなくなる条件の順に見ていきます。

最小構成の12列——工程から差異まで、そのまま使える列名

工数計算表に必要な列は12です。下の表をそのまま1行目に並べてください。

この構成の利点は、前提が列として残ることです。「稼働率を0.75から0.8に変えたら何日縮むか」を、I列を書き換えるだけで即座に出せます。総額だけを持っている表では、この再計算ができません。

バッファは行に混ぜず、表の下に「バッファ(合計の15%)」という1行を独立して置いてください。前章で述べたとおり、誰の判断で取り崩すかを明示するためです。

使う関数は3つで足りる——SUMIF・SUMPRODUCT・NETWORKDAYS

複雑な関数は要りません。次の3つで実務は回ります。

• SUMIF: 工程別の集計に使います。=SUMIF(A:A,"実装",H:H) で実装工程の工数が出ます。工程別の比率(設計が何%、テストが何%)を見るときに必須です
• SUMPRODUCT: 単位工数×件数を一括で合計します。=SUMPRODUCT(D2:D14,E2:E14) で、F列がなくても総作業量が出ます。検算用にもう1本持っておくと安心です
• NETWORKDAYS: 開始日と終了日から土日祝を除いた営業日数を返します。=NETWORKDAYS(開始日,終了日,祝日リスト) の形で使い、算出した所要日数をカレンダー上の日付に変換するときに使います

祝日リストのシートを1枚作っておくと、ベトナムの祝日(2026年で年12日。労働法112条の法定は11日で、2026年からベトナム文化の日が加わる)やテト(2026年は2月14日〜22日)のように、日本と異なる稼働カレンダーを持つチームの計算にも同じ表が使えます。

複数人で分担する計算——0.5人月×2人が1人月にならない理由

ここが計算を間違えやすい場所です。「20人日の作業を2人でやれば10日」という計算は、次の3つを無視しています。

1. 分割できない作業がある: 1人が5日かけて書く設計書を、5人で1日にはできません。順序の制約がある作業は人数で割れません
2. レビューの往復が増える: 人数が増えると、確認と調整の組み合わせが増えます。2人なら1経路、5人なら10経路になり、その調整自体が工数になります
3. 兼務のスイッチングコスト: 複数案件を兼務する人は、案件を切り替えるたびに思考の切り替えが発生し、名目の割り当て時間ほどには作業が進みません

3つ目を数字にすると、こうなります。0.5人月(10人日)の枠を2人から確保した場合、単純合計は20人日ですが、この記事の題材として兼務効率を0.75と置くと、実質15人日分の作業しか進みません。専任1名(20人日)と同じにはならないわけです。

表の稼働率(0.85・0.55)は、この記事の題材として置いた値です。実際には前項の引き算で、メンバーごとに出してください。この置き方では、同じ「1人月」でも実際に進む作業量が1.5倍以上違います。当社が体制をご提供するときに1名単位の専任を基本にし、増員は約1週間、縮小や交代は1か月単位という形にしているのは、この差を発注側に負担させないためです。介護記録SaaSのCareViewerでは日本語対応のブリッジSE1名とフルスタックエンジニア2名の専任体制を組み、週次で優先順位を判断しながら進めています。あなたの計算表は、兼務者を専任と同じ1人として数えていないでしょうか。

エクセルの限界が出る3つの条件——ここを超えたらツールを検討する

表計算ソフトは、見積もりの計算そのものには十分です。限界が出るのは、次の3条件のいずれかに当てはまったときです。

1. 複数人が同時に編集する: ファイルの先祖返りが起きます。クラウドの表計算に移すか、工数管理ツールを検討する段階です
2. 実績工数を毎日入力し続ける: K列の入力が滞ると、差異分析ができません。入力を習慣にできないなら、カレンダー連携や自動記録の仕組みを持つツールのほうが現実的です
3. 案件を横断して集計する: 誰がどの案件にどれだけ入っているかを横断で見る必要が出たら、ファイル分割では追えません

逆に言えば、単一案件の見積もりを作り、実績を週次で振り返る程度であれば、専用ツールを入れる必要はありません。工数計算ツールを導入しても、1件あたりの所要をいくらと置くかは人が決めます。ツールが改善するのは記録の手間であって、見積もりの精度そのものではない、と考えておくのが安全です。

工数から工期と費用を出す順序——この順番を逆にすると必ず破綻する

工数が出たら、次は期間と金額です。ここで大切なのは計算そのものより順序です。私は説明するとき必ず要素に分解しますが、工期と費用は分解の順番を間違えると、途中で前提が失われます。順に見ていきます。

5段階の順序——工数→実働日数→期間→人数→金額

正しい順序は次の5段です。

5段目だけ注意してください。費用は「作業した工数」ではなく「体制を拘束した期間」で決まります。稼働率0.75で3.3か月拘束するなら、請求の根拠になるのは3.3か月分です。この差を理解していないと、「作業は5人月のはずなのに6.6人月分の請求が来た」という誤解が生まれます。

数値例: 86人日の案件を2人で回すと何か月・いくらか

前章の会員制Webサービスで通します。

1. 総工数: 86人日 + バッファ15%(13人日) = 99人日
2. 実働換算: 99人日 ÷ 稼働率0.75 = 132人日
3. 期間: 132人日 ÷ 2人 = 66営業日 ÷ 20日 = 約3.3か月
4. 人数と体制: 2名(うち1名は設計とレビューを兼ねる)。要件定義期は1名、実装期は2名という山なりの配置も可能
5. 金額: 2名 × 3.3か月 = 6.6人月

この6.6人月に単価を掛ければ概算費用です。ソフトウェア開発データ白書2025のプログラマ単価40.1万円で計算すると、6.6 × 40.1万円 = 約265万円になります。当社の公開単価であれば、実務3年目安のエンジニアが1,500USD(1USD=150円換算目安で約22.5万円)なので、6.6 × 22.5万円 = 約149万円です。

ここで注意したいのは、単価が半分なら費用も半分、と単純にはならない点です。オフショアで開発する場合は日本語での要件伝達を担うブリッジSEや日本人PMの工数が乗ります。当社が推奨するパターンA(日本人PM/ブリッジSEをフロントに置く体制)では、この分を最初から見積もりに含めています。単価の相場と内訳、職種別の違いについては「人月単価」の記事をご覧ください。

逆から考える場合——予算と納期が先に決まっているときの詰め方

実務では、予算と納期が先に決まっていることのほうが多いはずです。その場合も、順序を逆にするのではなく、同じ順序を上りに使います。

予算600万円、人月単価40万円なら、買える拘束は600 ÷ 40 = 15人月 = 300人日です。ここで「300人日分の作業ができる」と考えるのが典型的な誤りで、稼働率0.75を掛けた225人日分の作業量が実際に進む範囲になります。さらにバッファ15%を確保するなら、作れる機能は約196人日相当です。

納期が3か月と決まっているなら、225人日 ÷ (3か月 × 20日) = 3.75人、つまり4名体制が必要です。そのうえで「4名を3か月確保できるか」「その4名で分割できない設計工程をどう回すか」を検討します。人を増やしても工期が比例して縮まない理由(教育とキャッチアップ、調整経路の増加、分割できない作業)は「工数とは」の記事で整理していますので、増員で納期を詰めようとしている方はあわせてご確認ください。

範囲が予算に収まらないときは、単価を叩くのではなく件数を減らすのが筋です。画面を12本から9本にすれば、設計と実装とテストを合わせて約7人日、稼働率込みで約9人日分の期間が縮みます。件数と単位工数に分けて計算しておく利点は、この会話ができることにあります。

当社の場合——単価を公開し、1名単位・最小構成から前提を合わせる

当社(TALENTBASE VIETNAM)がベトナム・ホーチミンで開発体制をご提供するときは、この計算の前提を最初に合わせます。単価は公開しており、実務3年目安で1,500USD(約22.5万円)、5年で2,000USD、10年目安・ブリッジSEで3,000USDです。グループで保有する2,000名以上のIT人財データベース(日本語N1〜N2相当を含む)から直接アサインするため、協力会社を経由する仲介マージンが単価に乗りません。

最小構成は日本人PMフロント+2〜3人月で月額約80万円〜、1名から開始でき、最短2週間で稼働します。工数が読み切れない段階で大きな体制を組む必要はありません。流れは打ち合わせ→アサイン(約1週間)→候補者面談(約1週間)→開始で、契約と支払いは日本国内法人・日本法準拠、海外送金は不要です。

次章では、ここまでの計算でつまずきやすい場所を7つに整理し、発注側が受け取った工数を検算する方法を示します。

工数計算でよくある間違い7パターンと、受け取った工数の検算

計算がずれる原因は無数にあるように見えて、実際には数種類に集約されます。ここでは操作として間違えやすい7パターンを整理し、発注側が受け取った工数を検算する方法、そして次回に活かすための実績の残し方を扱います。

間違い7パターン——8時間前提・二重計上・区間分けの失敗ほか

7つのうち1と2と6は、いずれも「使える時間を多く見積もっている」という同じ根を持ちます。この3つを潰すだけで、ずれの大半は消えます。

なお、作業そのものの数え漏れ(会議・レビュー・手戻り・環境構築・調査・テストデータ・リリース作業)は、計算の操作ミスではなく分解の問題です。7カ所の一覧は「工数とは」の記事に整理してありますので、合計を出す前にそちらで確認してください。

受け取った工数を検算する4問——件数・単位工数・稼働率・バッファ

発注側の立場で「合計210人日」という数字を受け取ったとき、金額から入ると必ず主観的な議論になります。次の4問を順に聞くほうが建設的です。

この4問に数字で答えられる会社は、見積もりの作り方そのものが整っています。逆に「経験から総合的に判断しています」としか返ってこない場合、その数字は検算のしようがありません。

そして減らしたいときは、単価ではなく1問目の件数に戻ってください。画面を3本減らす、管理画面を初期リリースから外す、といった範囲の調整のほうが、値引き交渉より確実に工数が減ります。見積書の項目別の読み方については「システム開発 見積もり 内訳」の記事で扱っています。

実績を残して次回に使う——予実差異は3列あれば足りる

工数計算の精度は、才能ではなく蓄積で決まります。前章の表のK列(実績工数)とL列(差異)を埋め、作業が終わるたびに1行ずつ振り返るだけで十分です。

見るべきは3つです。どの工程がずれたか(SUMIFで工程別に集計する)、単位工数がずれたのか件数がずれたのか、稼働率の想定が合っていたか。この3点を記録しておけば、次の案件では同じ場所を直せます。

ただし、管理そのものに工数をかけすぎないでください。全タスクを15分単位で入力させると、入力だけで週に数時間が消えます。まとまった作業ごと、週次程度の粒度で十分です。工数の実績と進捗をどう報告に載せるかについては「進捗管理とは」の記事で扱っています。管理のための管理にならないよう、要注意です。

工数計算で外すのは当たり前で、問題は外れた理由が分からないまま次に進むことです。稼働率を何%で置いたかを記録している表は、外れても次に活かせます。記録がない表は、何度作り直しても同じ精度のままです。

工数計算に関するよくある質問

最後に、工数の計算について実際によくいただく質問を5つ取り上げます。いずれも表を作り始めた直後、あるいは出てきた数字を判断する場面で必ず出てくるものです。

Q1. 工数計算ツールは導入したほうがよいですか

単一案件の見積もりを作る段階では、表計算ソフトで十分です。ツールの導入を検討すべきなのは、複数人が同時に編集する、実績工数を毎日入力し続ける、案件を横断して稼働状況を集計する、のいずれかに当てはまったときです。ツールが改善するのは記録と集計の手間であって、1件あたりの所要をいくらと置くかは人が決めます。見積もりの精度そのものが上がるわけではない点にご注意ください。

Q2. 稼働率は何%で置けばよいですか

一律の数字を全員に当てないでください。その人の月の所定労働時間から、会議・報告・レビュー・他案件対応の時間を引き算し、当該案件に使える時間の割合として出すのが確実です。高い順に並べると、専任で短期集中のメンバー、問い合わせ対応を持つ専任、複数案件を兼務するメンバー、調整と報告が業務の中心になるPM・リーダー職という順になります。案件が始まったら、実績で置き直してください。

Q3. バッファは何%見ればよいですか

率は不確実性の大きさで決めてください。新しい技術を使う、要件が固まっていない、外部システムと連携するといった条件が重なるほど厚く置きます。置き方のコツは、各作業に少しずつ隠さず、プロジェクト全体で1カ所にまとめて持つことです。ただし稼働率で余裕を見込んだうえにバッファを乗せると二重計上になります。どちらの列で吸収するかを先に決めてください。

Q4. 複数案件を兼務するメンバーの工数はどう計算しますか

名目の割り当て時間をそのまま足さないでください。兼務者は案件を切り替えるたびに思考の切り替えが発生し、名目の割り当て時間ほどには作業が進みません。0.5人月(10人日)を2人から確保しても、実質はそれより少ない日数しか進まないと見てください。計算では兼務者の稼働率を専任より低く置き、可能であれば専任の時間帯をブロックする調整を先に行うほうが確実です。当社が1名単位の専任を基本にし、増員を約1週間、縮小・交代を1か月単位で対応しているのも同じ理由です。

Q5. 計算した工数が予算や納期を超えてしまったらどうしますか

打ち手は3つで、優先順位もこの順です。第1に範囲を削る——件数(画面数・機能数)を減らせば、設計・実装・テストが連動して減ります。第2に納期を延ばす——同じ工数でも人数を減らせば月あたりの費用は下がります。第3に人を増やす——ただし後半の増員は教育と調整の工数が乗るため効きにくく、最後の手段です。いずれの場合も、削った件数と縮んだ工数を表の上で示してから交渉に臨むこと。

まとめ: 工数計算は分解・単位工数・件数・合計の4段——最後に稼働率で割り戻す

工数の計算は、4つの数字を順に埋めるだけの作業です。作業を見積もれる大きさまで割り、1件あたりの所要(単位工数)を置き、件数を掛け、合計する。会員制Webサービスの例では、要件定義から付帯作業まで13行で合計86人日になりました。式は掛け算と足し算しかありません。

実務で差がつくのはそのあとです。1日8時間は作業時間ではありません。会議・報告・レビュー・他案件対応を引き算して稼働率を出し、合計工数をその稼働率で割り戻してはじめて、期間に翻訳できます。86人日にバッファ15%を足した99人日は、稼働率0.75なら132人日、2人体制で約3.3か月、拘束6.6人月です。ここに単価を掛けて金額が出ます。順序は工数→実働日数→期間→人数→金額の一本道で、逆から考えると稼働率とバッファが調整弁として削られ、計算が計算でなくなります。そして稼働率とバッファは役割が違うので、二重に計上しないでください。表計算ソフトなら12列と3つの関数(SUMIF・SUMPRODUCT・NETWORKDAYS)で組めます。

出てきた工数を検算するときは、金額ではなく「何を何件で数えているか」「1件あたり何人日か」「稼働率は何%か」「バッファは何%でどこにあるか」の4問から入ってください。範囲を減らしたいときも、値引き交渉より件数を削るほうが確実です。工数という言葉の定義や人時・人日・人月の換算、見積もり手法の使い分けは工数とは、単価の相場と内訳は人月単価の相場もあわせてご覧ください。現在の体制と要件をお聞かせいただければ、必要な工数の目安と体制、概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。