エンジニアの工数を経営者が理解するための基礎知識

著者：野原琉海（業務効率化に特化したエンジニア）

「ボタンを1個追加するだけじゃないんですか? なぜ2週間もかかるんですか?」

エンジニアに発注した経験のある経営者と話すと、この類の話が必ず出てくる。最初は「エンジニアが大げさに言っているんじゃないか」と思っていた方も多い。でも実態は違う。エンジニアが2週間と言うのには理由がある。

業務効率化に特化したエンジニアとして、中小企業の経営者と開発会社・フリーランスエンジニアのあいだに入る仕事をしていると、このコミュニケーションのズレを日常的に目にする。費用が当初見積もりの2倍になった、納期が3ヶ月延びた、完成したシステムが想定と違った。これらのトラブルの多くは、工数の理解のズレから来ている。

この記事では、工数の基礎となる人日・人月の概念から、見積もりがズレる構造、工数を膨らませてしまう経営者側の発注パターン、AI時代の工数の変化、実務で使える3つのスタンスまで整理する。エンジニアリングの専門知識は不要だ。発注者として最低限知っておくべきことだけに絞った。

工数とは「人数×時間の合計量」のこと

工数とは、ある作業を完了させるために必要な「作業量の合計」だ。単純に言えば、何人が何日かけるか、の総量を指す。

システム開発では主に3つの単位が使われる。

人時（MH: Man-Hour）

1人のエンジニアが1時間でこなせる作業量。バグ修正や軽微なテキスト変更などに使われることが多い。

人日（MD: Man-Day）

1人のエンジニアが1日（8時間）でこなせる作業量。「3人日の作業」なら、1人で3日、または3人で1日という意味になる。機能追加や部分的な改修の見積もりに使われる。

人月（MM: Man-Month）

1人のエンジニアが1ヶ月（稼働日で約20日・160時間）でこなせる作業量。「2人月」なら、1人なら2ヶ月、2人なら1ヶ月かかる作業量だ。大型システムの開発全体の見積もりに使われる。

ここで経営者の多くが誤解するのが「人数を増やせば比例して早く終わる」という考え方だ。

実際には、人が増えるほどコミュニケーションコストも増える。設計の方針合わせ、コードのルール統一、レビューの往復、作業の重複チェック。これらは人数が多いほど複雑になる。遅れているプロジェクトに人を追加投入するとさらに遅れる、というのはソフトウェア開発の現場では半世紀前から指摘されていることで、「人月の神話（ブルックスの法則）」として知られている。

具体的に言うと、4人で進めているプロジェクトに急きょ2人追加した場合、最初の1〜2週間は追いつくどころか生産性が一時的に落ちることすらある。新メンバーへの説明・引き継ぎ・方針確認に既存メンバーの時間が取られるからだ。「人を増やせば早くなる」は製造業の発想であって、ソフトウェア開発には通用しないケースが多い。

「ボタン1個」の見積もりが2週間になる理由

「ボタンを1個追加する」という依頼を受けたエンジニアが頭の中で考えることを、実際に追ってみる。

• このボタンはどのページに配置するのか
• 押した後に何が起きるか（フォームへの遷移? メール送信? 決済処理?）
• スマートフォンでの表示はどうするのか
• データベースへの書き込みは発生するか
• エラーが起きた時の画面をどう処理するか
• 既存の機能を壊さないかの確認はどうやるか
• セキュリティ上の問題はないか（外部からの不正なデータが送られてきた場合の処理は?）
• ブラウザごとの動作確認は必要か

この答えが何も決まっていない状態で開発を始めることはできない。まず要件を固める時間が必要だ。

次に実際の開発工程を見ると、こういう流れになる。

「ボタンを置く」作業は実装工程の0.5〜1人日だ。ところが前後の工程を合わせると、最低でも3〜7日になる。既存のシステムが複雑だったり、仕様が途中で変わったりすれば2週間になることもある。

経営者に見えているのは「ボタンを配置する工程」だけで、その前後に何があるかが見えていない。これが見積もりへの不満の正体だ。見積もりを見て「高い」と感じるなら、まず工程の内訳を確認することをすすめる。

工数を増やしてしまう経営者の発注パターン

責める話ではなく、工数の概念がないまま発注すると自然とこうなる、という話だ。知っておくだけで外注のコストが変わる。

業務効率化に特化したエンジニアとして複数の中小企業の開発案件に関わってきた経験から言うと、工数が当初の2倍以上になるケースの多くは、技術的な問題ではなく発注側のコミュニケーションパターンに原因がある。

パターン1：「細かいことはお任せします」

善意で言っている言葉だが、エンジニアにとっては「要件定義から全部自分でやってください」という意味になる。要件定義は開発全体の工数の20〜30%を占めることが多い。「任せる」という一言が、見積もりに含まれない隠れたコスト要因になっている。

パターン2：「ちょっとこれも追加できますか?」

開発が始まった後に機能を追加する依頼は、最もコストが跳ね上がるパターンだ。すでに設計したコードを変え、テストをやり直し、場合によっては別の機能に影響が出ないか確認し直す必要が生じる。開発前なら1人日で対応できた変更が、途中追加だと3〜5人日以上かかることも珍しくない。

パターン3：「急いでお願いします」

納期を詰めると、テストとレビューが省略されやすくなる。短期的には早く仕上がるが、リリース後にバグが出て修正対応が発生する。結果的に合計工数は増える。品質の問題は後から問題として返ってくる。

開発前に仕様書と画面設計（ワイヤーフレーム）を用意して渡せる案件は、見積もりの精度が格段に上がる。逆に何も決まっていない状態で「とりあえず作ってみて」と依頼すると、費用が青天井になりやすい。システム開発の外注で失敗するパターンと回避策でも詳しく整理しているので、これからシステム開発を外注しようとしている方はあわせて読んでほしい。

AI時代に工数はどう変わったか

「AIがあるから以前より早くできるはず」という期待を持って発注してくる経営者が増えてきた。実際、GitHub CopilotやClaude Codeのようなコーディング支援ツールを使うと、コードを書く速度は確かに上がっている。生産性が2〜3倍になるエンジニアもいる。

ただし、開発全体の工数に占める「コードを書く作業」の割合は30〜50%程度だ。残りは要件定義、設計の検討、テスト、コードレビュー、デプロイ作業などで構成される。

AIは「コードを書くスピード」を上げるが、「開発全体の工数を半分にする」わけではない。この前提のまま外注先に「AIを使えば早くなりますよね?」と言うと、現場のエンジニアとの齟齬が生まれやすい。

一方で、要件定義フェーズでのドキュメント作成や、テスト仕様書の作成などにはAIが効果を発揮する場面はある。「AIだから早い」ではなく「どの工程にAIが効くか」を理解した上で発注するのが現実的だ。

中小企業がAIを業務に取り込む際の進め方については中小企業のAI導入｜最初の3ヶ月で何をすべきかでも整理している。また、社内にAI・IT判断ができる人間がいない場合の選択肢についてはAI活用を内製するvsAI顧問に外注する｜中小企業向け判断基準が参考になる。

見積もりの内訳を正しく読む方法

工数見積もりに内訳を確認する習慣を持つだけで、外注のトラブルは大幅に減る。

典型的な見積もりの内訳（20人日規模のシステム改修の場合）

• 要件定義・設計: 4〜6人日（全体の20〜30%）
• 実装: 8〜10人日（全体の40〜50%）
• テスト: 4〜5人日（全体の20〜25%）
• コードレビュー・修正: 2〜3人日（全体の10〜15%）
• デプロイ・最終確認: 1〜2人日（全体の5〜10%）

「実装: 20人日」だけ書いてある見積もりは、テストとレビューが含まれているのかどうかが不明だ。後からテスト費用が追加請求されるケースがある。見積もりを受け取ったら、まずこの内訳の内訳を確認する習慣を持ってほしい。

エンジニアの単価の目安

エンジニアの単価は役割とスキルレベルによって大きく異なる。

1人月90万円のエンジニアなら、1人日あたり約4.5万円（90万円÷20稼働日）になる。見積もりが人日ベースで出てくる場合は、この換算で単価の妥当性を確認できる。

見積もりへの疑問の持ち方も大切だ。「高い」という感情的な反応より、「なぜこの工数か」を聞く方が建設的だ。具体的には次の3つの質問を活用してほしい。

• 「要件定義の○人日は何を具体的に行うのですか」
• 「テストはどの範囲まで実施しますか（ブラウザ・デバイス・ケース数）」
• 「類似規模のプロジェクト事例はありますか」

この3つに明確に答えられない業者は、見積もりの根拠が薄い可能性がある。フリーランスエンジニアへの依頼方法についてはフリーランスエンジニアの探し方｜中小企業が開発を依頼するための基礎知識でもまとめているので参考にしてほしい。

工数トラブルを防ぐ経営者の行動3つ

細かい技術の計算はできなくていい。この3点を意識するだけで、外注のトラブルはかなり減る。

1. 要件が固まってから見積もりを取る

「何を作るか」を決めてから見積もりを依頼する。曖昧な状態で取った見積もりは、後から必ず増える。見積もりの数字が信用できるのは、要件が決まっている時だけだ。理想を言えば、ワイヤーフレーム（画面の設計図）を用意できていると、見積もりの精度が格段に上がる。「費用感を知るための概算見積もり」と「確定版の見積もり」を分けて考えることも重要だ。

2. 変更の依頼は早い段階でする

「やっぱりこうしたい」は、開発着手前に伝えるほどコストへの影響が小さい。開発中・テスト中・リリース後と後になるほど、修正の影響範囲は広がりコストは跳ね上がる。開発中の変更コストは開発前の3〜5倍、リリース後の変更は10倍以上になるケースもある。「まだ言わなくていいか」と思っていることを早めに共有する習慣が、コスト管理に直結する。

3. 「なぜこの工数か」を説明してもらう

見積もりに違和感を覚えたら、内訳と理由を必ず聞く。説明ができない業者は要注意だし、説明してもらっても意味が分からなければ、それは双方に理解のギャップがある。理由を聞く習慣を持つだけで、適正な発注かどうかの判断精度は上がる。

自社でエンジニアを持てない中小企業がこうした判断を適切に行えるようサポートするのが、AI顧問の役割の一つだ。エンジニアへの発注・社内IT課題全般の相談についてはAI顧問とは？中小企業が知るべきサービスの全体像と費用相場を参考にしてほしい。

まとめ：工数の理解がコスト管理の第一歩

工数とは人数×時間の合計量で、人日・人月という単位で表される。「ボタン1個」に2週間かかる理由は、見えない工程が多いこと、要件が曖昧なことにある。

経営者側の発注の仕方（「任せます」「追加で」「急いで」）が工数増加の原因になることも多い。これは善意からくる言葉だが、エンジニア側には別の意味として伝わっている。

AIツールの登場でコーディング効率は上がっているが、開発全体の工数を半分にするという理解は現実とは合っていない。要件定義・テスト・レビューは省略できない工程として残り続ける。

工数の概念を持った上で発注すれば、無用な費用超過・納期遅延・関係悪化を大幅に減らせる。これは技術の知識ではなく、発注者としての基礎リテラシーだ。

関連記事

• システム開発の外注で失敗するパターンと回避策
• フリーランスエンジニアの探し方｜中小企業が開発を依頼するための基礎知識
• 中小企業のAI導入｜最初の3ヶ月で何をすべきか
• AI顧問とは？中小企業が知るべきサービスの全体像と費用相場
• AI活用を内製するvsAI顧問に外注する｜中小企業向け判断基準