MENU

for Ideal Design

AI

AI時代、ソフトウェアは安くなるほど価値を増していく!?開発現場の過去とこれから

業務改善 AI 仕事 データ活用 エンジニア

ソフトウェアは安くなるほど価値を増していく

ポイント

▸時間の圧縮
かつて数十人が数ヶ月かけていた開発を少人数が数週間で実現する、ソフトウェア開発の進化。

▸実行しながら学ぶ組織
事前に詳細要件を固める大規模な計画から、小さく作り、実際に使って顧客や現場の反応を確認しながら改善を繰り返す開発・経営アプローチの転換。

▸価値の移動
価値の中心は課題設定へ移行。開発コストが下がればこれまで採算が合わずに諦めていた領域にもソフトウェアが広がり、解決できる課題の総量が増えていく。

こんにちは、ワークスアイディの奥西です。

AIによって開発が自動化されたら、エンジニアの仕事は減ってしまうのでしょうか?

企業の経営者や管理職の方とお話ししていると、このようなご質問をよく受けます。

確かに、AIに要件を伝えれば画面のプロトタイプやプログラムが短時間で作られ、エラーの原因や修正案まで提示される時代になりました。ソフトウェアを作るために必要な時間とコストは急速に下がっています。

『ITエンジニアの仕事が減る問題について』

皆さんはいかがお考えでしょうか?色々なご意見があると思います。
しかし、ここで重要なのは、開発コストの低下を単なる“仕事の減少”と捉えないことだと私は考えています。

ソフトウェアの歴史を振り返ると、作ることが簡単になるたびに、適用領域は広がってきました。

高価で作れなかった業務システム、小規模すぎて採算が合わなかったサービス、現場の一部にしか存在しない細かな課題――。それらが技術の進歩によって、次々と開発対象になってきています。

ポジショントークのように聞こえるかもしれませんが、ソフトウェアは安くなるほど価値を失うのではありません。安く・速く作れるようになるほど、より多くの課題を解決し、企業の競争力を高める存在になると私は考えます。

本日は、『AI時代ソフトウェアは安くなるほど、価値を増していく』をテーマに、開発現場のこれまでの経緯や背景を振り返りながら、今後を考察していきましょう!

2000年代の開発現場 ――すべてを自分たちで作る“職人の世界”

2000年代、企業が本格的なECサイトや業務システムを立ち上げることは、現在よりもはるかに大きな投資を伴う重い経営判断でした。

当時の開発チームが担当するのは、単にプログラムを書くことだけではありません。
これらを自分たちで考えなければなりませんでした。

  • インフラの調達:物理サーバーを購入し、データセンターと契約する
  • 環境構築:ネットワークを構築し、データベースを設定する
  • 運用計画:セキュリティ対策・バックアップ・障害監視・アクセス急増への備えを講じる

たとえば、テレビや雑誌で商品が紹介されてECサイトへのアクセスが急増する可能性があるとします。

現在であれば、クラウド上の計算資源を自動的に増減させる設計ができますが、当時は将来のアクセス数を予測し、複数のサーバーやロードバランサーをあらかじめ調達しておく必要がありました。

予想を回った場合:高価な設備が使われずに無駄になってしまう
予想を回った場合:サイトが停止して大きな販売機会損失になる

当時のシステム開発は、技術的な問題であると同時に“設備投資の問題”でもあったのです。

アプリケーション開発においても手作業が多く、商品表示・会員登録・決済・在庫管理など、現在では外部サービスで実現できる機能も、一つひとつ設計・実装しなければなりませんでした。

開発環境と本番環境の差で「開発者の手元では動くのに、サーバーでは動かない」という問題も日常茶飯事で、高度で幅広い専門性と経験を持つ『何でも屋』な職人たちが、膨大な作業を積み上げることによってようやく一つのサービスが完成していた時代。

当時は優れたアイデアがあっても、資本や技術者が足りなければ実現できませんでした。
つまり、“ソフトウェアを作れること自体”が企業の大きな参入障壁だったのです。

クラウドと自動化がもたらした開発の“時間の圧縮”

2010年以降、開発現場にはさまざまな技術革新が起こりました。

クラウドサービスの普及によって、物理サーバーを購入せずに必要資源をすぐ利用できるようになりました。数ヶ月かかっていた調達が管理画面上の操作で完了し、需要に応じたスケールが可能に。設備を“所有”することから“必要な分だけ利用”することへと、インフラの考え方そのものが変化しました。

DockerやKubernetesなどの技術によって、アプリケーションの動く環境を標準化し、展開や拡張が容易になりましたし、GitHubを中心とする共同開発環境・CI/CD・自動テスト・監視サービスが整備され、開発した機能を安全かつ継続的に提供する仕組みも整っていきました。

アプリケーション開発では、Django・React・Next.jsなどのフレームワークが繰り返しの実装作業を簡略化しましたし、Shopifyなどのプラットフォームを使えば、決済・在庫・配送・販促などの機能もゼロから開発せずに済みます。

ここで起きたのは、単なる“作業の効率化”ではありません。
かつて数十人が数ヶ月かけていた開発を少人数が数週間で実現する、数週間必要だった試作品を数日で顧客に見せる。まさにソフトウェア開発における“時間の圧縮”です。

そして、時間が圧縮されたことで、企業の意思決定のスピードも大きく変わりました。

💡開発・経営アプローチの変化

  • 従来の開発:
    失敗の損失が大きいため、意思決定は慎重。事前に詳細要件を固め、長期利用を前提に現場の要望をすべて盛り込んだ大規模な計画を立てがち
  • 現代の開発:
    安く速く試せるため、小さく作り、実際に使って顧客や現場の反応を確認しながら改善を繰り返す

これは、開発手法の変化であると同時に、経営の変化です。

ワークスアイディでも、ノーコード・ローコードツール『kintone』や『PowerApps』を活用した支援が大幅に増えました。

完璧な計画より、仮説検証を繰り返しながら正解に近づいていく。
ソフトウェア開発の進化は、企業に“計画してから実行する組織”から“実行しながら学ぶ組織”への転換を促してきたのです。

AIと協働し、新たな需要を生み出す未来

AIの登場によって、ソフトウェアの開発時間はさらに圧縮されようとしています。

GitHub Copilot・Cursor・Claude Code・CodexなどのAIツールは、部分的な補完を超え、コードベースを読み、複数ファイルの編集やコマンドを実行しながら、機能開発や不具合修正・テスト・レビューなどを支援する存在に。

GitHubの調査では、Copilotを利用した開発者がプログラミング課題を平均55%速く完了したという結果も報告されています。

一方で、AIによる生産性向上を実感する技術者が増えているものの、その効果は組織文化や開発プロセスの状態によって左右されることが示されています。

つまり、“AIツールを導入すれば、自動的に開発力が高まるわけではない”という現実もあります。

プロンプト力よりも『業務の棚卸し』が先決

AI導入支援の現場でこのようなご相談をよくいただきます。

「アカウントは配布したが、数か月後も一部の人しか使っていない」
「社員のプロンプト力が足りない」

しかし現場に詳しくお話を伺うと、原因はプロンプトのスキルではなく、“自分たちの業務のどこに時間がかかり、何を解決したいのかが整理できていないこと”にありました。“AIで何ができるか”は知っていても、“自分たちの業務の何が問題なのか”を言語化できていなかったのです。

そこでプロンプト研修を増やす前に、まず日常業務の棚卸しを実施しました。

報告書毎週作っている報告書は、誰が何のために読んでいるのか
転記作業複数のシステムから数字を転記する作業は、本当に必要なのか
資料作成会議資料のうち、実際の意思決定に使われている情報はどれか
問い合わせ対応顧客から繰り返し寄せられる問い合わせに、どんな共通点があるか

業務を一つずつ分解すると、“AIを使えそうな仕事”ではなく“そもそも変えるべき仕事”が明確になっていきました。

『作れる』ことと『組織で使える』ことの違い

また別の企業では、現場主導で業務アプリの試作品を短期間で作成しました。デモの評判は上々で、経営会議でも「すぐに全社展開しよう」という声が上がりましたが、実際の運用を確認すると『入力データの定義が部署ごとにバラバラ』『責任者が決まっていない』という課題が見つかりました。

さらに、AIが出した結果を誰が確認するのか、誤りがあった場合に誰が対応するのかも曖昧で、“技術的には作れても、組織として使えない状態”です。

AI時代は試作品を作るスピードが非常に速くなります。その結果、これまでは開発の後半で浮き彫りになっていた業務ルールや組織の課題が、早い段階で表面化するようになります。

AIが企業に突きつけているのは技術の問題だけではありません。長年うやむやにされてきた業務ルールや責任分担を見直すきっかけを与えてくれているのです。

だからこそ、AI活用を拡大するために重要なのは、AIの使い方を学ぶこと以上に“ビジネスの課題を発見し、構造化する力”ですね。

ソフトウェア開発の価値の変化

現場の「面倒だ」という声を、単なる不満として処理するのではなく、情報の滞留・判断の遅延・重複作業の発生点を見極める。そのうえで、AIに任せる部分、人が判断する部分、業務そのものを廃止する部分を設計する必要があります。

これからの開発者にも同じ変化が起きます。
これらが実現していくと、AIの言語モデルを活用する手段だけではなくコーディングモデルやローコードツール活用して、課題を解決していくためのアプリケーションが増えていくと考えています。

一方で2026年の現在も、コードを1行ずつ書く能力が不要になったわけではありません。しかし、価値の中心は“製造”から何を作るべきかを決める上流(課題設定)”確実に移っています。

そして開発コストが下がれば、これまで採算が合わずに諦めていた領域にもソフトウェアが広がっていきます。

  • 一部の社員だけが行う業務のための小さなシステム
  • 特定の顧客に合わせた個別最適化サービス
  • 熟練者の判断を支援する専門ツール
  • 地域や業界に固有の課題を解決するニッチなアプリ

以前なら「利用者が少ないから作れない」と判断されていた領域にも挑戦できるようになり、結果として、ソフトウェアで解決できる課題の総量が増えていくと考えています。

まとめ

ソフトウェア開発の歴史は、人の仕事が技術に奪われてきた歴史ではありません。人間が、より価値の高い問題に時間を使えるようになってきた歴史です。

AIは、この流れをさらに加速させます。ただし、AI導入そのものは競争力ではありません。

誰でも同じツールを利用できる時代だからこそ、ツールの有無ではなく、“どの課題に使い、どのように業務や組織を変えていけるか”が企業の差になります。

優位に立つのは、従来の方法に固執する企業でも、AIに丸投げする企業でもありません。技術の特性と限界を理解し、人間の経験や判断と組み合わせながら仕事の新しい形を作れる企業ですね。

これまで見過ごされていた課題を発見し、より多くのアイデアを形にし、より多くの顧客や社員に新しい体験を届けられる時代です。

安くなったソフトウェア進化したAIを使い、私たちはどのような新しい価値を生み出していくのか――。ワークスアイディも、その問いにしっかり応えられるサービスを確立していきたいと思います。

ぜひ皆さまの会社でも、『ソフトウェアの価値』について一度議論してみてください!

それでは、本日もGOOD JOB!!

 

▼こちらもおすすめ