AI時代にコスト削減の議論は無意味、必要なのはPdM能力だ

はい、どうもこんにちは佐藤です！

先日、後輩くんとこんな話をしました。

「AI で作れるようになってきたから、今後はコストを考えるようになってくるんですかね？」

いい質問ですよね。作るのが速く安くなるなら、次に効いてくるのは価格競争だろう。そう考えるのは自然です。AIでバリバリ個人開発している私も、昔なら同じことを言っていたと思います。

でも、いまの私の答えはこうでした。

そうはならないですね。

いや、もう少し正確に言うと、AI 時代にコスト削減の議論をしても、ほとんど意味がないのです。コストで戦う土俵に乗った瞬間に、私たちのような中小や個人事業主（個人開発者）は負けます。そして、開発費に本当に効くのはまったく別のところにあって、それは全部 PdM の仕事だったりします。

その理由を書いていきますね！

コスト勝負になったら、資本が全部持っていく

まず、大前提の話から。

AI で開発コストが下がるとして、下がるのは誰にとってでしょうか？　全員にとってですよね。自分だけが安く作れるようになるわけではありません。

そして、みんなが等しく安く作れる世界では、何が勝敗を決めるのか。物量です。

ハリウッド映画を思い浮かべてください。あの世界では、コストを削って勝った会社などありません。1 本に何百億円も突っ込んで、世界中で同時公開して、市場ごと持っていく。制作費を 2 割減らす工夫より、2 倍の資本を投じて 10 倍の宣伝を打つ方がはるかに強いのです。

ソフトウェアも同じ構図になりつつあります。資本が多いところは、コストなど気にせずに作ります。3 案作って 2 案捨てても平気ですし、ユーザーが集まるまで赤字で回し続けられます。彼らにとって開発費は、事業全体から見れば微々たるものです。

そこに私たちが「うちは AI を使っているので 3 割安く作れます」と言って乗り込んだらどうなるか。

同じ土俵で、資金力だけが違う勝負になります。

これ、勝てないやつですよね。コスト削減は、コストが勝敗を分ける市場でしか意味を持ちません。AI で誰でも作れるようになった市場は、もうそういう市場ではなくなってきているのです。

中小と個人が生き残るのは「ちょっとズレたもの」を作る側

では、私たちはどこで戦うのか。

私は、日本の同人誌文化みたいになると思っています。

商業誌がやらない、やれない、ちょっとズレたもの。特定の誰かにだけ深く刺さるもの。大資本が「市場が小さすぎる」と判断して手を出さない領域。そこに小さいプレイヤーが入り込んで、濃い読者を掴む。あの構造です。

業務システムの世界でも似たことが起きます。大手のパッケージは最大公約数を取りにいくので、どうしても現場の癖に合いません。「うちの検品はこの順番じゃないと回らない」みたいな話は、大資本のプロダクトからは必ずこぼれ落ちます。そこを拾って作れるのが、私たちの立ち位置なのです。

さて、ここで質問です。

そのズレた 1 本を作るとき、コストは争点になるでしょうか？

なりませんよね。そもそも他に選択肢がないのですから。顧客が見ているのは「自分たちの業務が回るかどうか」であって、他社より 20 万円安いかどうかは選択肢の上位には入りません。

コスト削減という話題は、比較可能な同じものが並んでいるときにだけ発生します。ズレたものを作っている限り、そこは主戦場になりません。

中小企業や個人事業主にとっては、選ばれるための競争ではなく、利益を確保するためのコスト削減と意味が変わってきます。

断っておくと、日常業務の自動化はこの話に含みません

ここまで読んで「いや、AI でコスト削減できるって話は普通にあるでしょう」と思った方。その通りです。

私の研究室でも、日常業務の自動化については コスト削減の意味が大きいと言い続けています。

毎朝 30 分かけていた集計を n8n で自動化する
問い合わせメールの一次仕分けを AI に任せる
勤怠の打刻漏れチェックを Slack ボットに巡回させる

この手の話は、削った時間がそのまま人件費として浮きます。効果も測りやすい。やらない理由がない領域です。

この記事で言っているのは、そこではありません。受託や自社プロダクトの「システム開発」そのものの話です。

日常業務の自動化は「すでにやっている作業をゼロに近づける」ゲームなので、コストの計算がきれいに立ちます。一方でシステム開発は「まだ存在しないものを決めながら作る」ゲームですから、コストの大半は作業単価ではなく 決めそこないの回数 に乗ってくるのです。

同じ「コスト削減」という言葉でも、効く場所がまるで違います。ここを混ぜて話すと、議論がねじれます。

以降は、システム開発の話だけをします。

開発費にいちばん効くのは「やらないと決める」こと

では、システム開発で利益を確保するためのコストに効くものは何でしょうか。

私の答えは 2 つです。やらないことを決めることと、仕様の調整で試行錯誤をしないこと。まずは前者から。

AI がシステムを作れるようになって、はっきり変わったことがあります。顧客側からの要望が明らかに大きくなったのです。

「AI ですぐできるんですよね？」

この一言のあとに続く要望リストが、以前の倍くらいの長さになっています。そして困ったことに、その中には運用で絶対に使わない仕組みがけっこう混ざっています。

たとえば、ある業務システムで「マスタを画面から自由に編集できるようにしたい」という要望が出たことがありました。作るのは簡単です。AI に任せれば半日でしょう。でも現場に聞くと、マスタを触るのは年に 1、2 回で、しかも情報システム部門が直接データを直している。誰も使わない画面になるのが目に見えていました。

こういうものを 1 つ作ると、費用は作った瞬間で終わりません。テストの対象が増え、権限設計が複雑になり、画面の説明を運用マニュアルに書き、機能改修のたびに影響範囲として検討されます。作った 1 機能は、その後ずっと課金され続けるのです。

システム開発というのは、本来こういう進め方をするものでした。

運用が回る最低限を作って、少しずつ大きくしていく。

この原則は AI 時代でも変わりません。むしろ、作るのが速くなったぶん、止める判断と先送りする判断の価値が跳ね上がっています。

先延ばしにしたら、設計がまとまった話

これは実際に体験した話です。

ある業務システムで「この機能を追加したい」という相談がありました。作れます。すぐ作れます。でも運用が回り始めたばかりだったので、いったん先延ばしにしました。

そのまま数週間、使ってもらいました。

すると、どうなったか。同じ領域の要件が他にもいくつか出てきたのです。しかも並べてみると、それぞれ単発で作るよりも、まとめて 1 つの設計として片付けた方が明らかにきれいな形をしていました。

もしあのとき即座に作っていたら、1 つ目を作って、2 つ目で構造が合わずに直して、3 つ目でまた直して……という道をたどっていたはずです。作り直しのたびに設計を考え、AI に指示を出し、出てきたものを確認する。その往復が丸ごと発生していました。

一呼吸おいたおかげで、全体を見渡してから 1 回で設計できました。結果として、AI に消費させるトークンも大幅に少なくて済んでいます。

「すぐやる」が正義ではありません。寝かせることで、要件の方が勝手に形を整えてくれることがあるのです。

仕様を決め切らないほど、AI は高くつく

もう 1 つが、試行錯誤のコストです。

仕様を決め切らないまま着手すると、何が起きるでしょうか。作り直しですよね。そしてこの作り直し、AI 時代には 2 種類のやり取りを同時に発生させます。

顧客との調整のやり取り（こうじゃなかった、ああしたい）
AI に書かせ直すやり取り（前提が変わったのでここから作り直して）

人間が手で書いていた時代は、後者が「自分が書き直す」だったので、痛みが自分の中で閉じていました。いまは AI に文脈を渡し直すコストが乗ります。既存コードとの整合も確認しなければなりません。速く作れる時代だからこそ、決めそこないの請求書が大きくなるのです。

ここでよく反論をもらいます。「決め切らないでいいのがアジャイルでしょう」と。

アジャイルでやるなら、それでいいと思います。試行錯誤を織り込んだ進め方ですし、そのための体制も作りますよね。

でも、業務システムはウォーターフォールで決めていけます。

現場の業務フローは、明日いきなり変わったりしません。誰が何を入力して、どこで承認されて、どの帳票が出るのか。これは着手前に決め切れる情報です。少なくともコアの部分の要件定義から設計だけは、先に固められます。

私が SIer にいたころ、要件定義に何か月もかけていました。当時は正直「長すぎるだろう」と思っていた工程ですし、本質的なやり取り以外も目立ちました。でも、いま振り返るとあれには意味がありました。コアの業務モデルを確定させてから実装に入るという順序そのものが価値だったのです。本質的でないと感じたやり取りは、今後追加されるかもしれない機能の伏線でもありました。

AI 時代になって、実装のコストは劇的に下がりました。そのぶん、コスト構造の中で要件定義の比重が相対的に上がっています。工程全体に占める「決める」の割合は、むしろ増えているのです。

もちろん、全部を決め切る必要はありません。周辺機能や画面の細部は後回しでいい。コアだけ決め切る。これだけで作り直しの回数はごっそり減ります。

それ、全部 PdM の仕事ですよね

ここまで挙げてきたものを並べてみましょう。

要望に対して「それは作らない」「それは後で」と判断する
運用が回る最低限の線を引く
コアの業務モデルを決め切ってから着手する
要件が育つのを待って、まとめて設計する

これ、全部 PdM の仕事です。

コーディングの速度でも、単価でも、フレームワークの選定でもありません。何を作らないかを決める仕事が、AI 時代の開発コストをほぼ支配しているのです。

そしてもう 1 つ大事なことがあります。

この PdM の仕事は、窓口に立つ人だけのものではありません。

顧客と話すのは 1 人かもしれませんが、「その機能、運用で使われますか？」と最初に気づけるのは、たいてい実装している人です。データ構造を見た瞬間に「この要件、あと 2 つ来るぞ」と勘が働くのもエンジニアですよね。画面を作りながら「この導線、現場は絶対に通らない」と気づくのはデザイナーです。

つまり、プログラマもデザイナも PdM の仕事に関わっていくことになります。というより、関われる人でないと価値が出しにくくなります。

言われたものを速く作る能力は、AI が持っていってしまいました。残るのは、言われたものの中から作るべきものを選ぶ能力です。

だから、キャリアの話としてもここに行き着きます。PdM 能力を上げていくこと。窓口の役割を取りにいくという意味ではなくて、自分の担当範囲の中で「作らない判断」ができるようになるということです。

まとめ

というわけで、AI 時代にコスト削減の話をしても意味がないよ！って話でした！

あ。正確には、削れる場所が上流にしかなくなった って感じですねっ。

コスト勝負に持ち込めば資本が勝ちます。私たちが生き残るのはズレたものを作る側で、そこでは価格が争点になりません。そして開発費を本当に動かすのは、単価でも実装速度でもなく、やらないと決める判断と、コアを決め切る要件定義です。それは全部、PdM の仕事でした。

明日からできることは 1 つだけ。コアの要件定義と設計だけは決め切ってから、AI に手をつけさせる。

これだけで、作り直しの往復がごっそり消えます。ぜひみなさんも試してみてください！