April 6, 2026
清水 亮 ryo_shimizu
新潟県長岡市生まれ。1990年代よりプログラマーとしてゲーム業界、モバイル業界などで数社の立ち上げに関わる。現在も現役のプログラマーとして日夜AI開発に情熱を捧げている。
筆者がまだ会社を立ち上げたばかりの頃、前の会社の上司と雑談をしていたことがある。
「最近なにやってんの?」
「今日は見積もりを作らなければなりません」
「ああ見積もりか。見積もりはクリエイティブな仕事だよね」
そんなふうに考えたことが一度もなかったので、エッと思った。
しかし、上司の発言に立ち戻って、見積もりはクリエイティブなものだと考えるようになって、会社は結果的に軌道に乗っていった。
筆者の場合、大手企業からの下請けでソフトウェア開発を行う仕事が多かった。いわゆる「請負仕事」である。こういうことをする小規模な会社はたくさんあるから、筆者の経験が読者諸氏の役に立つかもしれない。
ソフトウェアの受託開発の場合、見積もりの基本は人月単価と工数だ。
人月単価とは、ある人間を一ヶ月拘束した場合にかかる費用を指す。
「この仕事には⚪︎⚪︎をする人が一人、3ヶ月と、⚪︎⚪︎をする人が二人、六ヶ月必要なので合計15人月」のように見積もる。
この「⚪︎⚪︎」という職種がプランナーなのかプログラマーなのかデザイナーなのかサウンドなのかによって単価と工数が変化することもある。
ゲーム開発の場合は、ディレクター、プランナー、シナリオライナー、プログラマー、グラフィックデザイナー、サウンドデザイナー、テスターのような職種があって、それぞれ人月単価と工数を見積もり、合計すればポン、という形であがる。
しかし、実際には、この「人月単価」と実際にかかっている「その人のための経費」は完全に連動しているわけではない。
たとえば同じ人月単価であっても、その人の給料は100万円だったり60万円だったりする。
もちろん給料だけじゃなくて社会保険料やオフィスの地代家賃光熱費、彼らを管理するためのバックオフィス部門の人件費といった間接費が乗っているので完全に連動させたら会社は潰れてしまう。
ということは、「人月単価」というのは、単なる方便でしかない。
AIをソフトウェア開発に活用するようになると、この「人月単価」は大きく変動することになる。なぜなら生産性が従来と全く違うからだ。
かつて筆者は、サラリーマン時代、人月単価150万円で仕事を請けていた。しかしもしも今、自分に人月単価をつけるとしたら、人月単価は1000万円くらいになるだろう。というのも、同じことがもっとたくさんできてしまうからである。それまで20営業日かかっていたことが、実質半日で終わるとしたら、それでも安いくらいなのだ。
もちろん1000万円で一ヶ月拘束されるよりも、100万円で10社に分散して拘束されるほうが効率がいい。ということは、相対的には各社の負担は安くなるというパラドックスが生まれる。それまでは人月150万円だった人が100万円で雇えるようになる。というのも、AIを使っている場合、半分以上が待ち時間になるからだ。
仮に1000万円で一ヶ月拘束された場合、1000万円で期待される成果を出すのは難しくなる。待ち時間が含まれているからである。
ということは、本来、ソフトウェア開発の見積もりに人月単価を使うのはもはや実情から乖離していると言わざるを得ない。
見積もりがクリエイティブな仕事であるというのは、例えば別の考え方を適用できるからだ。
たとえばミドルウェアという考え方がある。
ミドルウェアは、ソフトウェアである。それは有形・無形な財産、ノウハウのようなものであって、静的なものではない。したがって、ミドルウェアというのは、開発する前に買い手を見つけることができる。
「こういうミドルウェアを作っているんですがどうでしょう?」と見込み客に売り込めば、ミドルウェアには値段がつく。面白いのは、ミドルウェアにも他のソフトウェアにも、価格と人月単価は何の関係もない。
たとえばWindows11 Homeの日本語版は15,000円程度だが、これはMicrosoftの社員の人月単価と全く無関係に決められている。
ある会社と開発契約をするときに、ミドルウェアはライセンス料として先払いでもらうことができる。なぜなら既存のソフトウェア資産だからだ。Windows Homeを使うのに、Windowsの代金を先払いするのは当然のことだ。同じように、自社のミドルウェアは、先払いでミドルウェアの料金をもらうことができる。ではその後には何が待っているのか、それは「顧客向けのカスタマイズ」という人月作業だ。
この人月作業の工数は、圧縮することが極端に難しい。なぜなら、AIがプログラムを書くように、顧客を無視して勝手に進めることが不可能だからだ。つまりコミュニケーションコストが発生する。したがってこの部分を圧縮するのはかなり難しい。
最良かつ最善なのは自分自信でAIを使って直接プログラムを作ることだが、十分な知識と経験のない人がバイブコーディングだけに頼って実業務のシステムを構築すると、とんでもないトラブルを巻き起こす危険性がまだ高い。
また別の見方では、そもそも見積もりとはコミュニケーションであるという考え方がある。
いわば、ラブレターのようなもので、高く見積り過ぎれば信用を失い、安く見積り過ぎればジリ貧になる。
ところが見積もりは、キャッシュフローの次に経営者の頭を悩ませるものでもある。
ラブレターである以上は、フラれる可能性もある。相手は相見積もりという形で、二股、三股をかけているかもしれない。その中で選ばれるラブレターをどう書くか。
過去に見たことのある他者のよくない見積もりでは、「一式 ⚪︎⚪︎⚪︎⚪︎円」というのがあった。
何が起きるかわからないソフトウェア開発の世界で、「一式」では話にならない。
クライアントはこの「一式」の根拠が知りたいのである。
しかしこの時代ほど見積もりが難しくなった時代は過去にちょっとない。すくなくともソフトウェア開発においてこれほど見積もりの難易度が高い時代はないのではないだろうか。
もしも筆者が現役の経営者だったら、見積もりについての考え方やテクニックなどをとても人前で話す気にはならない。それは厳然たる企業秘密だからだ。見積もりはどこの会社も他者に見せられるのを嫌がるし、それをすることを信義則に反すると考える会社もある。
筆者は見積もりが通らずにカッとなって自暴自棄な行動をとったり、やぶれかぶれに激安の見積もりをしてドツボにハマる中小企業経営者をよく見てきた。
しかし見積もりで一番大事なことは、顧客が得をするように作るということである。
この当たり前の原則がわからない経営者や営業担当者が少なくない。
「顧客が得をする」とはどういうことか、このことがすわなち「こちらが損をする」ことを意味するわけではない。ここを履き違える人が多すぎる。
「まず顧客が得をして、その後に我々も得をする」という取引を見つけなければならない。
これは何も筆者が突拍子もない話をしているのではなく、経済学者のアダム・スミスが18世紀から言っていたことだ。
彼は「国富論」の中でこう言っている。
“Whether the advantages which one country has over another be natural or acquired is in this respect of no consequence. As long as the one country has those advantages, and the other wants them, it will always be more advantageous for the latter rather to buy of the former than to make.”
The Wealth of Nations, Adam Smith, 1776
ある国が他国より得意な生産分野を持っていて、他方がそれを必要としているなら、後者にとっては自前で作るより前者から買うほうが有利だ
これは国際貿易の話だが、企業間の話にも適用できる。
たとえば、すごい肉を生産する業者と、すごいパンを生産する業者があったら、その二つを組み合わせてハンバーガーを作る専門業社が出現することで、双方にとって顧客の開拓を行うことを意味し、Win-Win-Winになり得る。他の分野で強みを持つ会社に対してAIを使ったソフトウェアソリューションを提供する会社は、Win-Winになり得る。なぜなら、そのソフトウェアがあることによって新しい付加価値を生み出し、顧客の利益を実際に向上させることができるからだ。
Win-Loseの関係を見つけるのではなくWin-Winの関係を見つける。そのためには、顧客の目的が何かということをきちんとコミュニケーションして理解しなければならない。顧客の目的がわかれば、見積もりは自動的に説得力を持つことができる。
しかし見積もりに関する話は非常にセンシティブであるため、こういう場所に書けることは少ない。しかし実際に見積もりについて悩む人は少なくないだろう。
というわけで本音ベースの「見積もり論」に関連するセミナーに、今月登壇します。
詳細は以下
