AIが真に明らかにしたこと

AIによってソフトウェア開発が速くなりました。

これは、おそらく間違いありません。

少なくとも、コードを書くという行為についていえば、以前なら数日かかっていたものが数時間でできる、 ということは珍しくなくなりました。小さなアプリケーションであれば、仕様を伝え、AIにコードを書かせ、 実行し、修正させるところまで含めて、驚くほど短時間で完成します。

では、それによってソフトウェア開発という仕事の価値そのものが小さくなったのでしょうか。

私は、少し違うのではないかと思っています。

むしろAIが明らかにしたのは、 そもそも私たちは、コードを書くという行為そのものに対して、それほど多くのお金を払っていたわけではなかった ということではないでしょうか。

漫画の原稿を描くことには、お金は発生していません

漫画を例にすると分かりやすいと思います。

漫画家が一本の漫画を描きます。

それに数か月かかったとしても、数時間で描けたとしても、その作業時間自体には、 本質的には何の値段も付いていません。

極端なことをいえば、誰にも頼まれていない漫画を三か月かけて描いたからといって、 三か月分の報酬が発生するわけではありません。

編集部に持ち込みます。
価値を認めてもらいます。
掲載されます。
読者に届けられます。

そこで初めて「原稿料」という形でお金が発生します。

ですから、漫画の価値は、描くのにどれだけ苦労したかでは決まりません。

三か月かけた原稿より、三時間で描いた原稿のほうが市場に受け入れられることも普通にあり得ます。

価値を決めているのは、制作に投入された労働量ではありません。

どれだけ市場に適合したものを作ることができたか です。

ソフトウェアも、本質的には同じだったのではないでしょうか。

コードを書くことがビジネスなのではありません

サービスでもアプリケーションでも、その価値を最終的に決めるのは、市場にどれだけ受け入れられるかです。

コードが100万行あるから価値があるわけではありません。

開発に100人月かかったから価値があるわけでもありません。

逆に、一人が数日で作ったものでも、何百万人もの問題を解決するのであれば、大きな価値を持ちます。

これはAI以前からそうでした。

ところが、ソフトウェア産業では長い間、「開発工数」と「価値」が近接して見えていました。

ソフトウェアを作るには、大量の人間と時間が必要だったからです。

そのため、

「これには10人月かかります」

という説明と、

「これは高価な仕事です」

という説明が、ほとんど同じ意味に見えていました。

AIは、この二つを分離し始めました。

実装コストが急激に下がったことで、 作るのが大変だから価値があったのではない という、当たり前の事実が急に見えるようになったのです。

AIによる高速化は、何に効くのでしょうか

では、AIによって開発速度が上がることには、どのようなビジネス上の意味があるのでしょう。

私は、製品のライフサイクルによって意味がかなり違うのではないかと思っています。

ゼロスクラッチの新規ビジネスの場合、AIによる高速化には非常に大きな意味があります。

なぜなら、 Try & Errorの回数を増やせるからです。

一つのサービスを作るのに半年かかるなら、一年間に試せるアイデアはせいぜい二つか三つです。

一方、一つの試作品を一週間で作れるなら、何十種類もの仮説を試すことができます。

AというUIは受け入れられるのでしょうか。
Bという課金モデルは成立するのでしょうか。
この機能をユーザーは本当に必要としているのでしょうか。
そもそも、このサービスには市場が存在するのでしょうか。

これらを短期間で確認できます。

新規ビジネスにおいては、AIによる開発高速化は、 成功する確率そのものを上げるというより、失敗するコストを下げ、試行回数を増やす ことに大きな価値があります。

これは非常に強力です。

成功したサービスでは、事情が変わります

しかし、すでに市場に受け入れられているサービスではどうでしょうか。

利用者がいます。
売上があります。
既存の業務がそのサービスを前提に動いています。

この段階になると、最重要課題は必ずしも「もっとたくさん機能を作ること」ではなくなります。

むしろ、 壊さずに変更すること の比重が大きくなります。

ユーザーが100万人いるサービスで、AIによって開発速度が10倍になったからといって、 機能を10倍の速度で追加したいかというと、私はかなり疑問です。

変更には常にリスクがあります。

仕様の複雑化も起きます。
サポート対象も増えます。
ユーザーが覚えなければならないことも増えます。
テスト対象も増えます。
運用上の例外も増えます。

成功している製品にとって、「たくさん変更できる能力」は必ずしもそのまま価値ではありません。

そこでAIの使い方も変わります。

たとえば、

• 既存コードの理解
• テストの拡充
• 古いライブラリからの移行
• リファクタリング
• 障害原因の調査
• ドキュメントの整理
• 長年放置されてきた技術負債の解消

こうした仕事でAIを使います。

私は、成熟したサービスではこちらのほうがAIの使い道として自然なのではないかと思っています。

つまり、新規開発では、

AI → 実験コスト低下 → Try & Errorの増加

成熟製品では、

AI → 保守・調査・改修コスト低下 → 製品の健全性向上

という違いがあるのではないでしょうか。

にもかかわらず、成熟した製品に対して、

「AIを導入したので開発速度を2倍にしましょう」

と単純に考えると、製品のライフサイクルとAIの使い方がミスマッチになります。

その結果として、Scrumを導入したのに「Scrum, but...」になるように、 「Codex, but...」や「Claude Code, but...」が発生します。

ツールがおかしいのではありません。

その組織が解決したかった問題と、そのツールによって改善した指標が一致していないのです。

ソフトウェア開発の現場には、もともと二つの世界がありました

もう一つ、AIによって非常に面白い変化が起きています。

ソフトウェア開発の現場には、以前から二種類の知識が存在していました。

一つは、 ソフトウェアをどう作るかという技術的知識 です。

もう一つは、 そのソフトウェアが存在するビジネス領域についての知識 です。

ここでは便宜上、前者を「技術側」、後者を「ドメイン側」と呼ぶことにします。

私が見てきた範囲では、優れた開発リーダーが必ずしも最もプログラミング能力の高い人だったわけではありません。

むしろ、その製品が何をするものなのか、誰が使うのか、何が重要なのかを深く理解している人が リーダーになることのほうが多かったように思います。

これは考えてみれば当然です。

どんなに高度な技術を使っても、ユーザーが必要としていないものを作れば失敗します。

問題は、企業によっては、この「技術側」と「ドメイン側」が、人としても組織としても大きく分離していることです。

すると、面白い対立が起きます。

ドメイン側から見ると、

「なぜ、こんな簡単なことができないのでしょうか？」

となります。仕様としては非常に単純に見えるからです。

一方、技術側から見ると、

「なぜ、こんな簡単な技術上の理由が分からないのでしょうか？」

となります。

既存システムとの整合性。
データ構造。
トランザクション。
互換性。
セキュリティ。
性能。
過去の経緯。

技術側には、簡単にできない理由が見えています。

双方とも、自分の見えている世界では正しいのです。

しかし、見えている世界が違います。

この対立は昔からありました。

AIによって、組織内の力関係が変わりました

そしてAIは、この関係にかなり大きな変化をもたらしました。

特に恩恵を受けたのは、ドメイン側です。

彼らは以前、

「これは3人月かかります」
「今期の開発リソースでは無理です」
「技術的に難しいです」

と言われれば、それ以上どうしようもありませんでした。

本当に難しいのでしょうか。
単に優先順位が低いのでしょうか。
既存システムの問題なのでしょうか。
担当者がやりたくないだけなのでしょうか。

ドメイン側には判断する手段がありませんでした。

ところが今では、

「ではAIに作らせてみましょう」

ということができます。

そして実際、一晩で動くものができてしまう場合もあります。

もちろん、それがそのまま商用品になるわけではありません。

セキュリティも品質保証も運用設計も必要です。

しかし、 少なくともこのアイデアが技術的に成立するのか というところまでは、ドメイン側自身が確認できるようになりました。

これは単なる「プログラミングの民主化」以上の変化だと思います。

AIは、 組織内に存在していた知識の非対称性を一部破壊しました。

以前なら技術側だけが持っていた「作れる／作れない」に関する交渉力を、 ドメイン側も持ち始めたのです。

だから現在、一部の組織では、ドメイン側がAIを非常に歓迎し、 技術側が警戒するという構図が生まれています。

そしてドメイン側の主張の一部は、実際に正しいのです。

AIを使えば、本当に速くできることはかなりあります。

これまで人月の問題だと思われていたものの一部が、単なる実装コストだったことも 明らかになりつつあります。

しかし「作れる」と「売れる」は違います

ここでもう一度、漫画の話に戻ります。

漫画を速く描けるようになりました。

だからといって、その漫画が売れるわけではありません。

ソフトウェアも同じです。

AIによってアプリケーションを一日で作れるようになりました。

それは素晴らしいことです。

しかし、

• 作れること
• 公開できること
• 利用者に使ってもらえること
• 商品として販売できること
• 会社として責任を持って提供できること

これらは全部違います。

商用ソフトウェアの場合、会社は単なるコードに対して責任を持つわけではありません。

正常に動くこと。
重要なデータを失わないこと。
誤操作を防ぐこと。
セキュリティ上の問題を放置しないこと。
障害が起きたとき対応すること。
外部APIが変更されたら追従すること。
問い合わせに答えること。
必要なら何年も保守すること。

そして最終的には、

「この状態なら顧客に提供してよい」

と判断することです。

ここに責任があります。

そして商用ソフトウェアにおける対価のかなりの部分は、 実はこの責任に対して支払われているのではないでしょうか。

開発者は何に対してお金をもらっていたのでしょうか

AIによってコードを書くコストが急速に下がり始めたことで、 私は逆にこの問題が見えやすくなったと思っています。

開発者は、コードを書くからお金をもらっていたのでしょうか。

もちろん、それも仕事の一部です。

しかし、本質はそこではなかったのではないでしょうか。

何を作るのか判断します。
どう作るのか判断します。
どこまでテストすればよいのか判断します。
何を捨てるのか判断します。
この変更は安全なのか判断します。
いつリリースするのか判断します。
問題が起きたら原因を特定します。
必要なら直します。

そして、 自分たちが作ったものに責任を持ちます。

そのために報酬を受け取っていたのではないでしょうか。

AIによって、実装という作業の価格はこれからさらに下がるでしょう。

しかし、それによってソフトウェア開発そのものの価値が消えるとは、私は思いません。

むしろ逆です。

AIは、 ソフトウェア開発において、本当はどこに価値があったのか を露出させ始めました。

コードを書くことではありません。

たくさん作ることでもありません。

市場に必要とされるものを見つけ、
それを社会に出せる状態にし、
その結果に責任を持つことです。

AIが真に明らかにしたのは、案外そんな古典的なことなのではないでしょうか。

Written by T.Wakimura
August 2026