「AIがコードを書くなら、もうプログラマーはいらない」。最近よく聞く言葉ですが、私は少し乱暴な議論だと思っています。

AIが書いたコードであっても、完成したシステムを使うのは人間です。そこで事故が起きれば、AIが責任を取ってくれるわけではありません。目的に合っているか、安全か、運用できるか、投資に見合うかを最後に判断するのは人です。

一方で、ソフトウェア開発産業が今までと同じままでいられるとも思いません。特に、人数と期間を掛け合わせて売上を立てる「人月」の考え方は、AIによって強く問い直されます。価値の中心が、作業時間から成果へ移るからです。

私はIT業界に長く関わり、開発そのものよりもIT人材育成、教育、検定、認定の事業を続けてきました。現場の友人や経営者と話すと、変化は未来の予測ではなく、すでに発注や育成の現場で始まっています。

変化が見えやすいのがSESや受託開発です。以前は、熟練した技術者を一人出すときに、これから育てたい若手を一緒に配置することがありました。先輩の仕事をそばで見て、実務を覚えてもらう。企業にとって重要な育成方法でした。

ところが今は、顧客がその追加要員を受け入れにくくなっています。顧客自身が生成AIを使い、作業の内容や必要工数を以前より把握できるようになったからです。「この仕事に本当に二人必要ですか」「この部分はAIで短縮できませんか」と問われます。

これは顧客が冷たくなったのではありません。調達の解像度が上がったのです。ベンダーに任せていた内容を、発注側も理解し、妥当性を判断し始めました。

事例: 熟練者と新人のセット提案が通らない

熟練者一人なら成果を期待できる。しかし新人の学習時間まで顧客が負担する理由は何か。そう聞かれたとき、「今までそうしてきたから」では説明になりません。

新人を同行させるなら、その人が議事録、テスト自動化、ドキュメント整備、データ整理などで明確な価値を出す設計が必要です。教育費を人月へ紛れ込ませるのではなく、育成と成果を両立する役割を定義する。人材育成の仕組みそのものを作り直さなければなりません。

若手の機会をなくしてよいわけではありません。むしろAI時代だからこそ、基礎を学び、失敗し、レビューを受ける場が必要です。ただし、その費用を誰が負担し、どの成果と結びつけるのかを透明にする必要があります。

プログラムを書く主体は変わります。人間が一行ずつ書いていたコードを、生成AIが短時間で作る。これはすでに日常になりつつあります。しかし「コードを書く人が減る」と「専門家が不要になる」は同じではありません。

外注先が作った請求書や設計書を発注者が承認する場合を考えてみてください。自分で作っていなくても、承認には確認と責任が伴います。AIの成果物も同じです。「AIが作ったので中身は分かりません」は、顧客にも社会にも通用しません。

動けばよいのか。要件を満たしているか。個人情報を漏らさないか。障害時に復旧できるか。別のシステムと安全につながるか。保守できる設計か。こうした問いに答え、承認できる人が必要です。

事例: AI生成コードが動いた後に確認すべきこと

AIへ「顧客情報を検索する画面を作ってください」と頼めば、見た目が整った画面はすぐにできます。しかし、権限の違う利用者に同じ情報を見せていないか、検索履歴が残るか、入力値から攻撃されないか、法定保存期間を守れるかまでは、別の確認です。

デモが動くことと、本番で責任を持って使えることの間には大きな距離があります。その距離を埋めるのが、設計、テスト、セキュリティ、運用、監査の専門性です。

AIは品質確認にも使えますが、その検査項目を決め、結果の妥当性を判断するのは人間です。AIを監督するためにも、対象を理解するスキルセットが欠かせません。

変化を整理すると、私は5つの段階で考えられると思います。

第一段階は、人間がコードを書く開発です。設計し、実装し、レビューし、テストする。従来の中心でした。

第二段階は、AIがコードを書く開発です。人間は要件を伝え、生成されたコードを直し、確認します。現在、多くの現場がここへ移っています。

第三段階は、AIエージェントがソフトウェアを作る開発です。単に一つの関数を書くのではなく、目標から計画を立て、複数ファイルを変更し、テストして修正する。実装工程のまとまりをAIが担います。

第四段階は、人間がAIチームを指揮する開発です。設計担当、実装担当、テスト担当、セキュリティ担当、運用担当といった複数のAIエージェントを組み合わせ、人が全体を管理します。

第五段階は、人間が「何を作るべきか」を設計する段階です。技術的に作れるものではなく、顧客と社会にとって作る意味があるものを選ぶ。ここでは経営、業務、顧客理解、倫理、投資判断が重要になります。

段階が上がるほど、人間が手でコードを書く時間は減ります。しかし、判断と責任は軽くなりません。むしろ、AIが大量の成果物を高速に作るほど、間違った方向へ進んだときの影響も大きくなります。

AIチームを指揮するというと、管理画面から指示を出すだけの仕事に聞こえるかもしれません。実際は、それほど簡単ではありません。

開発AIが出した設計と、セキュリティAIの警告が矛盾する。テストAIは合格と判断したが、運用AIは監視が難しいと言う。短期の納期を優先すれば、将来の保守費用が増える。人間の管理者は、こうした衝突を理解して優先順位を決めます。

中身を見られない人が、AIの出力件数だけを管理すると危険です。現場の基本を知り、どこにリスクが潜むかを感じ取る力が要ります。これまで優れたプロジェクトマネジャーに求められてきた能力が、AI時代にはさらに重要になります。

事例: AIエージェントを増やせば速くなるとは限らない

複数のAIへ同時に仕事をさせれば、一見すると開発は速くなります。しかし、前提や設計方針がばらばらなら、統合作業が増えます。似た機能を別々に作り、テスト条件も一致せず、結局人間が整理し直すことになります。

必要なのは、ゴール、制約、品質基準、役割分担、受け渡し条件を最初に定めることです。人間の組織運営と同じで、人数を増やすだけでは成果は増えません。指揮の設計が要ります。

生成AIによって、私のように日常的にコードを書かない人でも、小さなアプリケーションを作れるようになりました。これは大きな民主化です。業務の集計、簡単な申請、情報整理、試作品などは、自分たちで素早く形にできます。

ただし、それだけで銀行、保険、行政、交通、医療を支える巨大な基幹システムまで簡単に置き換えられるわけではありません。私たちがAIで作れるのは、先人が築いたクラウド、データベース、通信、認証、OSなどの資産を利用できるからです。

下の層には、長年の失敗と改善から生まれた専門知識があります。AIがその知識を利用できても、現場固有の制約や責任まで自動的に理解するとは限りません。

AIの可能性を大きく評価しながら、できる範囲を過大評価しないことが大切です。生成結果には誤りやハルシネーションもあります。便利さと検証を必ずセットにする。それが超知性リテラシーの基本です。

これまでのITは、共通のプラットフォームを整えることで大きく発展しました。オフィスソフト、クラウド、グループウェアなど、多くの会社が同じ基盤を使えます。

一方、AIエージェントが現場へ入ると、医療、建築、製造、金融、教育でやりたいことは大きく異なります。同じAIモデルを使っても、業務手順、専門用語、規制、評価指標、失敗時の影響は違います。

だから、共通基盤だけでなく、業界の現場で手を動かせる人が必要になります。ここでFDE、Forward Deployed Engineer型の人材が活躍します。技術を説明して終わるのではなく、顧客の業務へ入り、AIを組み込み、成果が出るまで改善する人です。

ソフトウェア会社の競争力も、何人の技術者を抱えているかだけでは測れなくなります。どの業界の課題を理解しているか。AIを使ってどれだけ短期間に実装できるか。品質をどう保証するか。顧客の売上、コスト、速度、安心へどうつなげるかが問われます。

人月契約がすぐになくなるとは思いません。要件が変化しやすい仕事や、長期運用では、時間を基準にした契約が合理的な場合もあります。無理に成果報酬へ変えると、定義できない成果を巡って発注者と受注者が対立する危険もあります。

それでも、AIで作業時間が大幅に減るなら、時間の長さだけを価値にするモデルは持続しません。短時間で高品質な成果を出した会社ほど売上が減るという矛盾が生じるからです。

これからは、品質保証、業務改善、稼働率、リードタイム短縮、顧客体験など、価値に近い指標を組み合わせる必要があります。固定料金、段階的な成果報酬、運用改善の継続契約など、契約の設計も変わります。

重要なのは「AIを使ったから安い」ではありません。AIを指揮し、人間が責任を持つことで、より速く、より確かな成果を届ける。その能力に対して対価をいただく産業へ変わることです。

トランスフォーメーションは、何でも捨てて新しくすることではありません。私は「変わらないために変わる」という考え方が大切だと思っています。

顧客を幸せにする。社会に役立つ。安全なシステムを届ける。技術者が誇りを持って働く。こうした目的やポリシーは変える必要がありません。目的を守るために、道具、方法、組織、契約、スキルセットを変えます。

人や組織が変化へ向き合うときの参考として、私の著書『マインド・トランスフォーメーション　AI時代の思考革命』も、必要に応じて手に取っていただければと思います。技術の変化だけでなく、人間側のマインドセットをどう更新するかを考えています。

ソフトウェア会社は、AIに仕事を奪われるのを待つ必要はありません。自らAIをチームに迎え、開発プロセスを作り替え、業界知識を深め、成果へ責任を持つ側へ移ればよいのです。

技術者個人も同じです。コードを書く力を捨てるのではありません。その理解を使ってAIの出力を見抜き、指示し、設計し、顧客へ説明する力を加えます。キャリアパスは作業者から指揮者へ、さらに「何を作るべきか」を決める設計者へ広がります。

読者の皆さんはどうでしょうか。自社の売上は人数と時間だけに依存していないでしょうか。AIで短縮できた時間を、単なる値下げではなく、顧客の成果へ変えられているでしょうか。

まず一つの案件で、作業時間ではなく成果を言葉にしてください。次に、AIへ任せる工程、人が検査する工程、責任者が承認する工程を分けてください。そして、その新しい開発方法を若手の人材育成やリスキリングへつなげてください。

人を売る産業から、AIを指揮して成果を売る産業へ。これはプログラマーが消える話ではありません。技術者とソフトウェア会社が、より本質的な価値へ移る話です。

ここで見落としてはいけないのは、価格の決め方だけを変えても、産業構造は変わらないことです。提案、見積もり、要件定義、開発、検査、運用、育成までを一つの流れとして見直す必要があります。AIで短縮した時間を、顧客との対話や現場観察、品質確認、新しい価値の検証へ振り向ける。それによって初めて、生産性向上が単なるコスト削減ではなく、顧客成果の拡大につながります。また、経営者は売上だけでなく、AIが生み出した成果物を誰が承認し、問題発生時に誰が説明するのかを明確にしなければなりません。技術者には、コードの生成速度だけでなく、要件を問い直す力、テスト観点を設計する力、業務担当者の言葉を技術へ翻訳する力が求められます。若手育成でも、書き方を覚えるだけでなく、AIの提案を比較し、根拠を説明し、改善する訓練が重要です。

２年先の未来を先取り。AI・DX・超知性ASI時代のデジタル戦略を読み解くPodcast「DX企画書のネタ帳」。未来を先取りする実践的なヒントを毎日お届けしています。

今回の音声配信はこちらです。Spotifyで聴く

DX推進やデジタル化で道に迷ったら、DX相談・壁打ちもご活用ください。

近森満（ちかもり みつる） 株式会社サートプロ 代表取締役CEO ／ DXコンサルタント／IT人材育成／検定事業化 IT技術者の教育支援と人材育成を専門とする事業化コンサルタントとして、2006年に株式会社サートプロを創業し、IoT検定・+DX認定・アジャイル検定などの資格制度を創出。独自の技術者向け教育研修の開発に定評があり、実践的なスキル向上を支援。経済産業省DX推進ラボおよびIoT推進ラボのメンターとして自治体や中小企業のDX推進を支援。近年は超知性ASIスキル可視化にも取り組み、次世代技術の普及に注力している。

■株式会社サートプロ 代表取締役CEO
近森満

■所属・役職
・IoT検定制度委員会 事務局長（IoT検定、＋DX認定、超知性ASI検定）
・一般社団法人 IT職業能力支援機構 理事長（Android資格）
・電気・電子系技術者育成協議会 副理事長（E検定）
・組込みソフトウェア管理者技術者育成研究会 メンバー（組込み）
・ET教育フォーラム合同会社 代表（コンテンツ制作）
・経済産業省 地方版IoT推進ラボ ビジネス創出事業メンター（IoT支援）
・経済産業省 地域DX推進ラボ ビジネス創出事業メンター（DX支援）
・デジタル庁 デジタル推進委員（デジタル化支援）
・DX事業共同組合 設立理事（DX推進）
・一般社団法人日本サステナブルビジネス機構 幹事（SDGs認証）
・”一億総活躍社会を実現する”共生日本協議会 理事（DEI支援）
・アジャイル開発技術者検定試験コンソーシアム 事務局長（Agile検定）
・一般社団法人国際サイバーセキュリティ協会 事務局長（IACS認定）

X (Twitter)

Facebook

YouTube

note