AIでコードを書ける時代に、開発者の役割はどう変わるのか――業務と技術をつなぐ内製化の担い手へ

AIでコードを書ける時代に、開発者の役割はどう変わるのか――業務と技術をつなぐ内製化の担い手へ

生成AIによって、ソフトウェア開発の進め方は大きく変わり始めています。

自然言語で指示を出せば、コードのたたき台が生成される。既存コードの説明、エラーの原因調査、テストコードの作成、画面や業務アプリの試作まで、AIが支援できる範囲は広がっています。

こうした変化を見ると、「将来、ソフトウェア開発者は必要なくなるのではないか」という疑問が生まれるのも自然です。

しかし、企業の実務で必要とされるのは、コードそのものではありません。

利用者が抱えている課題を理解し、業務に合った仕組みを設計し、既存システムやデータと接続し、変化に合わせて継続的に改善することです。コードは、その目的を実現するための手段の一つです。

AIがコードを書く速度を高めたとしても、「何を作るべきか」「その仕組みは本当に業務課題を解決するのか」「将来の変更に耐えられるか」といった判断まで、自動的に正しく行われるわけではありません。

AI時代に開発者の価値がなくなるのではなく、価値を発揮する場所が変わっていくと考える方が自然です。

これまで以上に重要になるのは、業務と技術の間に立ち、人の意図を実際に使える仕組みへ変換する役割です。

AIはコードを生成できても、業務の背景までは理解できない

AIは、与えられた指示をもとにコードを生成できます。

一覧画面を作る。検索条件を追加する。データを登録する処理を書く。APIから情報を取得する。こうした作業では、すでに高い効果を発揮しています。

一方で、企業の業務アプリを作るためには、指示として明示されていない背景まで考える必要があります。

たとえば、営業案件を管理するアプリを作る場合を考えてみます。

依頼内容が「顧客名、案件名、金額、ステータスを登録できる画面を作ってください」だけであれば、AIは短時間で画面を生成できます。

しかし、実務ではそれだけでは足りません。

同じ顧客が重複して登録された場合はどうするのか。失注案件を削除するのか、それとも履歴として残すのか。金額を変更できるのは営業担当者か、管理者だけか。見積提出後の変更には承認が必要か。担当者が異動した場合、案件を誰へ引き継ぐのか。

こうしたルールは、コードの書き方ではなく、業務の進め方に関わる問題です。

AIは入力された要件を処理できますが、利用者が何に困っているのか、どこで間違いやすいのか、どの例外が業務上重要なのかを、現場と同じ感覚で理解しているわけではありません。

開発者は、依頼された機能をそのまま作るだけではなく、その機能が必要になった背景を確認します。

「本当に必要なのは入力画面なのか」
「既存のシステムにある情報を表示すれば、入力自体を減らせないか」
「利用者が求めているのは新機能ではなく、現在の業務フローの整理ではないか」

こうした問いを立てることが、開発者の重要な役割です。

利用者の不便は、要件書だけでは分からない

業務アプリの品質は、機能が動くかどうかだけで決まりません。

利用者が迷わず操作できるか。必要な情報へすぐにたどり着けるか。入力ミスが起きにくいか。例外が発生したときに、業務を止めずに対応できるか。

これらを設計するには、利用者の行動を理解する必要があります。

要件書に「検索機能が必要」と書かれていても、なぜ検索に時間がかかっているのかは分かりません。

検索条件が多すぎるのかもしれません。顧客名の表記が統一されていないのかもしれません。必要な情報が複数システムに分かれているのかもしれません。そもそも検索するのではなく、担当者ごとに対応すべき案件を自動表示した方がよい場合もあります。

AIは提示された要件に対して、画面やコードを提案できます。

一方、利用者がどこで迷い、何を面倒に感じているのかを観察し、依頼された機能とは異なる解決策を提案するには、人の経験や共感が必要です。

開発者が現場との会話に参加する意味は、技術的な質問へ答えることだけではありません。

利用者の言葉をそのまま機能へ変換するのではなく、背景にある課題を見つけ、より適切な形に整理することです。

開発者は、人の意図をデジタルの仕組みに変える

AI時代の開発者は、単にコードを書く人ではありません。

人が実現したいことを理解し、それを技術的に成立する形へ変換する役割を担います。

現場の担当者は、業務をよく理解しています。

どの作業に時間がかかっているのか。どの情報を毎回確認しているのか。どこで例外が発生するのか。どの判断が担当者の経験に依存しているのか。

一方、開発者は、それらをシステムとして設計する知識を持っています。

どのデータを正式な情報源にするのか。どの処理を自動化するのか。どこで人の確認を挟むのか。複数のシステムをどう接続するのか。変更しやすい構造をどう作るのか。

開発者の役割は、現場の要望を一方的に受け取って実装することでも、技術的な正しさだけを優先することでもありません。

業務上の意図と技術上の制約を両方理解し、実際に使える仕組みへ落とし込むことです。

AIは、その変換作業を支援する強力な道具になります。しかし、何を重視し、何を捨て、どのような設計を選ぶかという判断は、引き続き人が担います。

AIは代替者ではなく、新しいチームメンバーになる

AIを開発へ取り入れる際には、すべてを任せる自動化ツールというより、新しいチームメンバーとして捉えると理解しやすくなります。

AIは、短時間で複数の案を出せます。

画面構成の候補を作る。異なる実装方法を比較する。繰り返し処理を書く。テストの観点を洗い出す。ドキュメントの下書きを作る。

人が一つの案を考えている間に、AIは複数の選択肢を提示できます。

開発者は、その中から目的に合った案を選び、必要な修正を加えます。

この関係は、経験の浅いメンバーと一緒に仕事をする場面にも似ています。

AIが出した内容をそのまま採用するのではなく、前提を説明し、判断基準を伝え、結果を確認し、改善を指示する必要があります。

期待した結果が得られなければ、指示の出し方を変えるだけではなく、要件や設計そのものを見直すこともあります。

AIが生成したコードであっても、採用して本番へ反映する以上、その結果に責任を持つのは開発チームです。

誰が書いたコードかではなく、誰が確認し、承認し、運用するかが重要になります。

開発者には「作る力」に加えて「教える力」が求められる

AIを活用した開発では、開発者がAIに対する指導者の役割を担います。

AIへ適切な指示を与えるためには、自分たちが何を良い状態と考えているのかを言語化する必要があります。

どのような画面が使いやすいのか。どのようなコードを保守しやすいと考えるのか。エラーが発生した場合に、どのような情報を利用者へ表示するのか。データを更新する前に、どの条件を確認するのか。

これまで経験や慣習として共有されていた判断基準を、AIが理解できる形へ整理する必要があります。

これは、単なるプロンプト作成の技術ではありません。

チームの開発方針、業務ルール、設計原則、利用者に提供したい体験を明確にする作業です。

AIへ説明する過程で、人間のチーム内でも曖昧だった部分が見えることがあります。

「この処理は、なぜこの順番なのか」
「この例外は、どの条件で発生するのか」
「入力エラーの場合、処理を止めるのか、それとも警告だけを出すのか」

AIを適切に使うために業務や設計を言語化することは、チームの知識を整理し、属人化を減らすことにもつながります。

開発者は、生成された選択肢を編集する役割も担う

AIは大量のコードや設計案を生成できます。

しかし、選択肢が増えれば、どれを採用するかという判断が必要になります。

生成されたコードが動作していても、長期的に保守しやすいとは限りません。短期的には簡単な実装でも、データ量や利用者が増えたときに問題になる場合があります。画面として見栄えが良くても、現場の作業手順に合わないこともあります。

開発者は、AIが生成したものを並べるだけではなく、目的に合わせて選び、組み合わせ、不要な部分を取り除きます。

音楽の選曲や編集に近い役割ともいえます。

一つひとつの要素をすべて自分で作らなくても、何をどの順番で配置し、全体としてどのような体験を作るかには、人の意図が必要です。

開発者の価値は、コードを書く量だけでは測れなくなります。

どの技術を使わないかを判断すること。複雑な要件を単純な構造へ整理すること。短期的な要望と長期的な保守性のバランスを取ること。

こうした編集や選択の質が、より重要になります。

AIを活用した業務アプリ開発では、生成の速さだけでなく、現場の要望をどのように整理し、実際のデータや業務フローへつなげるかが重要です。

Retool上で自然言語、画面編集、コードを組み合わせて業務アプリを構築する流れを確認したい方は、Retoolデモをご覧ください。

お問い合わせ

定型作業をAIへ任せることで、開発者は重要な判断に集中できる

ソフトウェア開発には、創造的な作業だけでなく、多くの繰り返し作業があります。

似たような登録・更新処理を書く。定型的な入力チェックを追加する。テストデータを用意する。既存コードの説明を作る。ドキュメントを更新する。

こうした作業は必要ですが、開発者が本来集中すべき判断に使える時間を減らします。

AIに定型作業を任せることで、開発者は次のような領域に時間を使いやすくなります。

• 業務課題の理解

• 利用者との対話

• アプリ全体の構造設計

• データモデルの整理

• 複数システムの接続方法

• セキュリティや権限の設計

• 使いやすい画面と業務フロー

• 将来の変更を考慮した保守性

• AIが生成した内容の確認と改善

AIが開発者の仕事を減らすというより、開発者が使う時間の配分を変えると考えられます。

定型的なコード作成に使っていた時間を、業務成果や利用者体験に関わる判断へ移すことができます。

AIが間違えたときに気づけるのは、経験を持つ人である

AIが生成するコードは、見た目には正しく動作することがあります。

しかし、動作することと、業務に適していることは同じではありません。

正常な入力では問題がなくても、例外データで処理が止まるかもしれません。小規模な検証では速く動いても、本番のデータ量では性能が不足する場合があります。利用者が入力できる値を適切に制限していなければ、データの整合性が崩れる可能性もあります。

AIが出した結果の問題に気づくためには、何が正しい状態なのかを知っている必要があります。

開発経験がある人は、コードそのものだけでなく、その変更が周辺の機能へ与える影響を考えます。

今は動いていても、将来の変更が難しくならないか。似たような処理が複数の場所に重複していないか。障害が起きたときに原因を追えるか。利用者が想定外の操作をした場合にどうなるか。

AI時代には、コードを生成する技術だけでなく、生成された内容を評価する力が重要になります。

開発者の経験は、AIが間違えないようにするためだけのものではありません。間違えたときに早く気づき、影響を判断し、適切に修正するために必要です。

日本企業の内製化では、開発者の役割がさらに重要になる

日本企業の内製化では、開発者の不足が課題として挙げられることがあります。

業務部門からは多くの改善要望が寄せられる一方で、IT部門は基幹システムの保守、セキュリティ対応、インフラ運用、外部ベンダーとの調整など、幅広い業務を担っています。

AIによって業務部門がアプリのたたき台を作れるようになれば、IT部門への依頼を減らせる可能性があります。

しかし、それは開発者が不要になることを意味しません。

現場が作った試作品を、実際の業務で使える状態へ整えるには、次のような判断が必要です。

• どのシステムを正式なデータソースにするか

• 既存データとどのように接続するか

• 誰が閲覧・更新できるか

• 本番データを書き換える前に承認が必要か

• 類似したアプリが乱立しないよう、何を共通化するか

• 障害や業務変更が起きたとき、誰が保守するか

AIは、現場のアイデアを短時間で可視化することを支援します。

開発者は、そのアイデアを企業のシステムや運用の中へ組み込み、継続的に使える状態にします。

AI時代の内製化では、現場と開発者の距離を縮めることが重要です。

現場が要件を渡して完成を待つのではなく、初期段階から一緒に試し、画面を見ながら業務ルールを確認し、必要な修正を重ねる。AIによって試作が速くなるほど、この協働を短いサイクルで行えるようになります。

市民開発と専門開発者は、対立するものではない

ローコードや生成AIによって、非エンジニアでもアプリや自動化を作りやすくなっています。

この変化は、現場が業務改善に参加する機会を広げます。

現場担当者は、自分たちの業務を最もよく理解しています。必要な情報、使いやすい画面、例外的な処理を具体的に説明できます。

一方で、業務アプリが複数のシステムへ接続され、重要なデータを扱い、多くの利用者に展開されるようになると、専門的な設計が必要です。

市民開発と専門開発者は、どちらか一方を選ぶものではありません。

現場が業務要件と改善案を形にし、開発者がデータ接続、共通機能、複雑なロジック、運用設計を担う。役割を分けることで、開発者がすべての画面を一から作らなくても、組織全体の改善を支えられます。

この分担によって、開発者は個別の依頼を処理する担当者から、組織が安全に内製化を進めるための基盤を作る担当者へ変わっていきます。

Retoolで、現場の知見と開発者の専門性を組み合わせる

Retoolは、社内業務アプリ、管理画面、ワークフロー、AIを活用した業務支援ツールを構築するための開発プラットフォームです。

自然言語で作りたいアプリを伝えて初期案を生成し、その後、画面を確認しながら編集したり、必要に応じてコードで拡張したりできます。

ここで重要なのは、AIが生成したアプリをそのまま利用することではありません。

現場担当者は、必要な画面、業務の流れ、利用者が確認すべき情報を伝えます。開発者は、接続するデータ、処理の設計、複雑な業務ロジック、保守しやすい構造を整えます。

たとえば、現場が「未対応の問い合わせを優先度順に表示し、担当者を割り当てる画面が必要」と説明します。

AIを使って初期画面を作り、現場と確認しながら表示項目や操作方法を調整します。そのうえで、開発者がCRMや問い合わせ管理システムとの接続、優先度の計算、更新処理、例外時の動作を整えます。

Retoolでは、自然言語による生成、ビジュアルな編集、コードによる実装を同じ環境で組み合わせられます。

現場と開発者が別々の成果物を受け渡すのではなく、一つのアプリを見ながら改善を進められるため、業務要件と実装のずれを減らしやすくなります。

AIは最初の作成を速め、現場は業務知識を提供し、開発者は全体を設計して品質を整える。

この組み合わせによって、AIを単なるコード生成ツールではなく、内製化を進めるための共同作業の基盤として活用できます。

AI時代の開発者に求められる能力

AIによってコード生成が一般化しても、従来の開発知識が不要になるわけではありません。

むしろ、AIの出力を正しく評価し、業務へ適用するために、基礎的な技術理解は引き続き必要です。

そのうえで、次の能力がより重要になります。

業務を理解する力

利用者の依頼を機能として受け取るだけでなく、背景にある課題や業務の流れを理解します。

問いを立てる力

依頼された機能が本当に必要なのか、より簡単な解決方法がないかを考えます。

全体を設計する力

一つの画面だけでなく、データ、他システム、利用者、運用まで含めて考えます。

AIへ条件を伝える力

期待する結果、避けるべき実装、業務ルール、確認条件を明確に言語化します。

出力を評価する力

生成されたコードや画面が、正しく、安全で、保守しやすいかを判断します。

現場と協働する力

技術用語だけで説明せず、利用者と共通の画面や業務フローを見ながら改善します。

AI時代の開発者は、技術の専門家であると同時に、設計者、編集者、指導者、業務部門との橋渡し役になります。

AIを活用した開発で確認したいポイント

AIを業務アプリ開発へ取り入れる際には、次の点を確認しておくと進めやすくなります。

1．AIに任せる作業を決める

コードのたたき台、画面案、テスト作成、ドキュメントなど、AIに任せやすい作業を整理します。

2．人が判断する部分を明確にする

業務要件、アーキテクチャ、データ設計、重要な更新処理、本番公開など、責任を伴う判断は人が行います。

3．正しい状態を定義する

AIの出力を評価できるよう、業務ルール、受け入れ条件、例外時の動作を明確にします。

4．小さく試して確認する

最初から大規模なシステムを作るのではなく、一つの画面や一つの業務から始めます。

5．生成後に編集できる環境を選ぶ

最初の出力を作り直すだけでなく、画面、処理、コードを個別に確認・修正できることが重要です。

6．現場からフィードバックを受ける

動作するかどうかだけではなく、実際の業務で使いやすいかを確認します。

7．運用する人を決める

作成後の改善、障害対応、業務変更への対応を誰が担うかを明確にします。

AIによって最初の構築が速くなっても、業務アプリは公開後も変化します。

作成の速さだけでなく、確認、改善、保守まで含めた体制を考えることが重要です。

まとめ：AI時代ほど、開発者の判断が重要になる

AIは、ソフトウェア開発者の仕事を大きく変えます。

定型的なコード作成や調査にかかる時間は減り、アプリの初期案を作る速度は上がります。業務部門も、自分たちの改善アイデアを以前より簡単に形にできるようになります。

しかし、企業が必要としているのは、生成されたコードの量ではありません。

利用者の課題を解決し、既存のデータやシステムとつながり、継続的に運用できる仕組みです。

何を作るべきかを判断する。利用者が本当に困っていることを見つける。複数の選択肢から適切な設計を選ぶ。AIが生成した内容の問題に気づく。現場と協働しながら改善を続ける。

これらは、AIによってコードを書く速度が上がるほど、より重要になります。

AI時代の開発者は、すべてを自分で書く人から、人とAIを含む開発全体を設計する人へ変わっていきます。

コードの作成をAIに支援してもらいながら、人は業務、利用者、システム全体に責任を持つ。

その協働によって、開発者はより多くの時間を、実際の業務課題を解決するために使えるようになります。

AIを活用した業務アプリ開発では、現場の改善アイデアを素早く形にしながら、開発者がデータ接続や業務ロジックを整える進め方が重要です。

自然言語による生成から、画面編集、コードによる拡張まで、Retoolでの構築イメージを確認したい方は、Retoolデモをご覧ください。

お問い合わせ