【工数で価格を決める商慣行は、誰のためにあったのか】〜システム開発の"見積もり"を読み解く経営者の視点〜
「10人月・300万円」という見積もりを受け取ったとき、経営者はどう読んできたか。多くの場合、「人数×時間＝難易度＝妥当な価格」という等式を、ほぼ無条件に受け入れてきたのではないだろうか。工数という単位が分からないから問い返せない、ベンダーが専門家だから任せるしかない、という判断である。だがAIが1日以内で実装できる範囲が急速に広がりつつある今、「かかった時間と人数」を根拠にした価格設定は、発注者にとっての判断材料として機能しなくなりつつある。本稿では、工数単価ビジネスとは何だったのかという構造を経営者の言葉で整理し、発注の判断軸をどう持ち直すべきかを示す。
「工数」という単位が、発注者の判断を封じていた
工数とは「供給者側の都合」から生まれた単位である
工数とは、あるタスクを完成させるために必要な「人×時間」の量を表す単位だ。1人が1か月かかれば1人月、2人が1か月かかれば2人月、という計算である。これ自体は開発の規模を推計するための内部指標として、ある時期まで一定の合理性があった。問題は、この内部指標がそのまま発注者への価格説明に使われ続けてきたことだ。
経営者の立場からすると、工数という単位には専門的な響きがあり、「それだけの作業量がある」という権威を帯びている。反論するには技術的な知識が要るように見える。結果として、工数という言葉が一種の「説明責任の終わり」として機能し、発注者がそれ以上踏み込めない構造を作り出していた。
「難しそうだから高い」という心理に乗っかる構造
行動経済学の観点で見ると、発注者側にも固有のバイアスが働いている。人間は、理解できないものを「難しい＝価値がある」と判断しやすい。専門用語が並んだ見積書を前にしたとき、分からないこと自体が「妥当だ」という感覚を強化するのである。これは認知的流暢性（処理の難しさが判断に影響する現象）として知られている傾向だ。
つまり発注者は、価格の妥当性を「完成品の価値」ではなく「作業の複雑さの印象」で判断してきた。この構造が続く限り、発注者は価格の根拠を問えないまま、見積もりを承認し続けることになる。
「10人月・300万円」に隠れている問いを立てる習慣がなかった
本来、発注者が問うべき問いはシンプルである。「それで何ができるようになるのか」「完成した状態はどう定義されるのか」「なぜその人数・期間が必要なのか」の3つだ。しかし多くの経営者は、この問いを立てることをしてこなかった。工数という言語の壁が、問い自体を「素人の質問」のように感じさせてきたためだ。
AIの登場が、工数の「根拠」を崩し始めた
「1日で実装できる」範囲が広がっているという現実
生成AIと開発支援ツールの進化によって、従来であれば数週間を要していた実装作業が、AIを活用した開発者の手で数日以内に完成するケースが現れている。これは「AIが万能だ」という話ではない。「かつて10人月かかっていた作業が、今も10人月かかるとは限らない」という現実が生まれた、ということだ。
この変化が重要なのは、工数を価格根拠にした見積もりの正当性が、自動的に崩れ始めているからである。仮に以前と同じ機能を作るとして、AI活用により実作業が半分の期間で完了するなら、工数を基準にした価格は誰の利益を守るためのものか、という問いが生まれる。
「時間がかかった」ことは「価値がある」の証明にならない
完成品が同じであれば、早く届くほうが良い。これはビジネスにおける当たり前の感覚のはずだ。製造業で考えれば分かりやすい。同じ製品を半分の時間で作れる工場ができたとき、「時間がかかった方が品質がある」とは言わない。時間のかかり方は製造者側の問題であって、発注者が負担する理由にはならない。
ところがシステム開発においては、この感覚がずっと曖昧にされてきた。工数が多いほど価格が上がる構造では、開発者が効率的になるほど受け取る対価が減るという逆転した構造が生まれる。これは発注者にとっての損でもあるが、長期的には開発者側にとっても健全ではない。
「工数」から「価値」へ——問い直しが始まっている
欧米の一部では、システム開発の価格設定を工数ではなく「成果物の価値」に基づいて設定するアプローチが広がりつつある。日本でも、SaaSの普及とAI活用の拡大が、この問い直しを促している。完成した機能が何を解決するのか、業務にどう貢献するのかを軸に価格が設定される方向への移行である。
この流れは、発注者である経営者にとっては追い風だ。ただし、「価値」で交渉するためには、発注者自身が「何のために作るのか」「完成状態をどう定義するか」を言語化できていなければならない。ツールが変わっても、発注者側の前提整備なしには判断軸は持てない。
発注者が「判断できなかった」本当の理由
「専門家に任せた」は判断の放棄と同じだった
経営者がベンダーに任せきりにしてきた背景には、「ITは専門家の領域だ」という意識がある。この意識自体は完全に誤りではないが、「任せる」と「判断を放棄する」は別のことだ。設計の細部を任せることと、発注の目的・完成条件・価格の妥当性について問わないことは、まったく異なる。
セキュリティの世界でも同様の構造がある。「セキュリティはIT担当者に任せている」と言う経営者が、実際には何が守られていて何が守られていないかを把握できていない。任せた結果、判断の軸が社内に残らない。専門家への委任は、経営判断を外注することにはならないのだが、現実には多くの場面でそう運用されてきた。
「言語化されていない要件」は必ず後でコストになる
工数ビジネスの構造には、もう一つの問題がある。要件が曖昧なまま開発が始まると、後から工数が増えるという仕組みだ。「追加要件が発生したため、2人月追加が必要です」という連絡は、システム開発を経験した経営者なら一度は受け取っているはずだ。
この問題の根本は、発注者が「作りたいもの」を言語化できていなかったことにある。曖昧な要件のまま進めた結果、途中での変更・追加が発生し、工数が積み上がる。工数単価モデルでは、要件が曖昧なほど発注者が損をする構造になっている。AI活用でコストが下がったとしても、この構造は変わらない。
「完成形を定義する」は経営者の仕事である
発注前に「完成した状態」を定義することは、エンジニアの仕事ではなく経営者の仕事だ。「どの業務が、どう変わるのか」「誰が何のために使うのか」「使えるようになったと判断する基準は何か」——これらを言語化する責任は、発注者側にある。
前提が整っていない発注は、工数ベースであれ価値ベースであれ、失敗する。調達の形が変わっても、発注者側の準備不足は問題の種類を変えるだけで、問題そのものをなくさない。
今、経営者が持つべき「調達の判断軸」
「何のために作るか」から逆算する発注の組み立て方
発注の判断軸を持つための出発点はシンプルだ。「この開発が完了したとき、何が変わっているか」を先に定義することである。業務の何が解決されるか、どのコストが減るか、どのリスクが下がるか。この問いに答えられない状態での発注は、完成形の検証もできない。
AIの活用によって開発コストが下がる可能性があるとしても、発注者が完成形を定義できなければ、その恩恵は受け取れない。安くなった分だけ不要な機能が追加されるだけになる。
「工数」ではなく「成果」で会話できるベンダーを選ぶ
判断軸を持った発注者が次にすべきことは、成果で会話できるベンダーを選ぶことだ。「10人月かかります」という説明しかできないベンダーと、「この機能によってこの業務工程が削減されます」という説明ができるベンダーとでは、発注者との対話の質がまったく異なる。
ベンダー選定の基準を「実績件数」「技術力の印象」「金額の安さ」に置いてきた経営者は、この視点で選定基準を見直す必要がある。信頼の根拠を「権威や規模」ではなく「説明の質と成果の定義」に移すことが、調達判断の精度を上げる。
AI時代の調達は「発注者のリテラシー」で差がつく
AIの進化が開発コストを変えることは、発注者にとって機会でもあり、リスクでもある。機会は「同じ予算でより多くを得られる可能性」。リスクは「判断軸を持たないまま、より早く・より安く・より不透明な調達が増える可能性」だ。
発注の判断軸を持てるかどうかが、AI時代の中小企業にとって調達品質の決定的な差になる。工数という単位に守られていた曖昧さが消えつつある今、発注者側のリテラシーが問われる局面に入っている。
結論 — 経営者が取るべき次の一歩
工数単価ビジネスは、「技術が分からない発注者」と「工数で価格を説明するベンダー」の間に成立してきた商慣行だ。AIの登場がその根拠を揺るがしている今、発注者が持つべきは「工数への不信」ではなく、「完成形を定義し、成果で問う」という発注の軸である。
経営者は、システム開発の発注において「何が完成したら成功か」を言語化する責任を、ベンダーに委ねることなく自社で果たすべきである。
第一歩は、次のIT投資の前に「この開発が終わったとき、何がどう変わるか」を1枚の紙に書き出すことだ。それができなければ、発注の判断軸はまだ整っていない。
