生成AIで未経験言語の開発はできる。それでも納品まで担う技術者に必要なこと。
コード生成を任せる時代に、エンジニアは何を理解し、何に責任を持つのか。
「この言語は触ったことがありません」
以前なら、その一言で案件への参加をためらうことがありました。
文法を調べ、開発環境を整え、既存コードの書き方を読み、エラーの意味を追う。簡単な処理を一つ動かすまでにも時間がかかります。経験のない言語であれば、どこから手をつければよいか分からないまま、最初の数時間が過ぎることもあります。
いまは、その入口が変わり始めています。
生成AIに既存コードの一部を渡し、処理の流れを確認する。エラー文と該当箇所を見せて、原因の候補を出してもらう。近い書き方のコード案を作り、そこから既存の実装に合う形へ直していく。未経験の言語やフレームワークでも、最初のたたき台を持てるようになりました。
ディーシステムでも、生成AIを活用し、これまで扱った経験のない言語で開発を進め、納品まで行った実績があります。
そこで見えたのは、生成AIで入口を越えられることと、納品まで進める仕事は同じではないということでした。
コードが出ても、納品は終わりません。
未経験言語でも、開発の入口は広がった
未経験言語で止まりやすいのは、書く前の段階です。
最初にどのファイルを見るのかが分からない。処理の呼び出し元を追うにも、言語やフレームワークの作法が見えていない。エラー文を読んでも、設定の問題なのか、書き方の問題なのか判断しづらい。
生成AIを使うと、その入口に見当をつけやすくなります。
既存コードを読み込ませて、処理の役割を確認する。似た実装がどこにあるかを探す。エラー原因の候補を出してもらい、まず見るべき場所を絞る。画面表示やAPI呼び出しのたたき台を作るところまで、以前より速く進められるようになりました。
これは、経験の浅い技術者にとっても前向きな変化です。
いきなりすべてを理解してから書き始めるのではなく、AIが出した案を見ながら、既存コードとの違いを追うことができます。書けないから止まるのではなく、出てきたものを読み、どこが合っていて、どこが怪しいかを確認するところから入れる。
未経験言語への挑戦は、以前より現実的になっています。
ディーシステムでのAIで納品まで進めた実績
ディーシステムでも、生成AIを使いながら、未経験言語での開発から納品まで進めた事例があります。
最初の調査では、AIが大きく役立ちました。慣れていない言語の構文を確認し、既存コードの処理を読み解き、エラーの原因を探る。自分だけで調べるよりも、最初の仮説を持つまでの時間は短くなります。
ただ、現場で行ったのは、AIの出力をそのまま納品物にすることではありません。
返ってきたコード案を既存の実装に合わせて読み直す。命名、例外処理、ログの出し方が他の処理とずれていないかを見る。要件に対して足りない条件がないかを確認し、テストで落ちた箇所を直す。顧客に渡す前には、どの変更がどの要件に対応しているかを説明できる状態にします。
未経験言語でも、AIによって入口には立てます。
その後、納品まで進めるには、出力を読み、直し、試し、説明できるところまで持っていく仕事があります。ディーシステムでの実績は、その工程を含めたものです。
動くコードと、納品できる機能の間には仕事がある
AIが出したコードを実行して、画面上で動いたとします。
そこで終わりにはできません。
たとえば、検索条件を一つ追加する場合でも、確認は画面だけでは済みません。その条件がANDなのかORなのか、未入力のときにどう扱うのか、権限によって結果が変わるのかを見ます。さらに、同じ条件が帳票やCSV出力、夜間バッチ、外部連携で使われていないかも確認します。
画面上では正しく見えても、別の機能で参照されていることがあります。過去データでは値の持ち方が違うかもしれません。月末処理と重なると、普段は出ない条件でエラーになることもあります。
コードが動くことと、顧客の業務の中で使えることは同じではありません。
納品まで担う技術者は、動いた後の状態を見ます。どの要件に対応しているか、既存システムのどこに触れたか、どのテストで確認したか。問題が起きたときに、原因を追える形で残せているかも見ます。
検索条件を一つ足しただけでも、次に見る場所はまだ残っています。
要件が曖昧なままでは、AIへの指示も曖昧になる
生成AIへの指示は、こちらが理解している要件に引っ張られます。
「検索条件を追加してください」とだけ伝えれば、AIはそれらしいコード案を返してくれるかもしれません。画面に入力欄を足し、検索処理に条件を追加し、結果を表示するところまで書ける場合もあります。
そのコード案を見た後で、足りない条件が見えてくることがあります。
部分一致なのか、完全一致なのか。複数条件を入れたとき、どの順番で絞り込むのか。権限によって見せてはいけないデータはないか。帳票やCSV出力にも同じ条件を反映するのか。
AIの出力が悪いというより、渡した問いが不足している場合があります。
要件が曖昧なままでは、AIへの指示も曖昧になります。返ってきたコードを見てから、「そもそも何を満たせばよかったのか」に戻ることもあります。
そこで必要になるのは、顧客の使い方、既存機能、データの流れを見直すことです。AIに聞く前にすべてを固めるというより、返ってきた案をきっかけに、不足している要件を見つけていく感覚に近いかもしれません。
AIに任せる単位を小さくすると、確認する場所が見える
未経験言語でAIを使うとき、大きな機能を丸ごと任せると確認が難しくなります。
どの処理が増えたのか、既存コードのどこに影響したのか、テストでどこまで見るべきかが追いにくくなるからです。レビューする側も、変更の意図をつかむまでに時間がかかります。
そのため、任せる単位を小さくします。
まず、既存コードの処理を説明させる。次に、検索条件を一つ追加する案を出させる。返ってきたコードを差分として読み、命名や例外処理が既存の書き方に合っているかを見る。テスト案も、正常系と異常系を分けて確認する。
小さく任せると、見る場所が具体になります。
自分でゼロから書けない処理でも、差分としてなら読めることがあります。既存コードと違う書き方が混ざっていないか、共通部品を使うべきところで個別実装になっていないか、例外が握りつぶされていないか。未経験言語でも、確認できる部分はあります。
AIを使うことで、書き始める時間は短くなります。
その時間を、差分確認、レビュー準備、テスト条件の整理へ戻せると、未経験言語での開発も納品に近づいていきます。
テスト観点は増やせても、顧客固有の条件は人が見る
生成AIにテスト観点を出してもらうことはできます。
検索できるか、未入力の場合にどうなるか、存在しない値を入れたときにエラーにならないか。文字数が長い場合や特殊文字を含む場合、権限が違う場合の観点も出せます。
観点を広げるうえで、AIは役に立ちます。
そこに顧客固有の条件を重ねる作業が残ります。
月末だけ実行される処理がある。過去データに、現在とは違う形式の値が残っている。特定の部署だけが使う権限がある。外部システムとの連携時刻が決まっている。障害時の手順では、先に止めてはいけない処理がある。
一般的なテスト観点だけでは、こうした条件まで届かないことがあります。
だから、AIが出した観点に、過去の問い合わせや不具合履歴、運用担当者が気にしている時間帯を重ねます。画面では問題なく見えても、月末処理や外部連携と合わせたときにどうなるかを確認します。
テストは、コードが正しいかを見る作業に閉じません。顧客の業務の中で使われたとき、どこで止まりそうかを見つける作業でもあります。
若手が学ぶべきことは、減ったのではなく変わった
生成AIを使うと、若手や経験の浅い技術者も、実装の入口に立ちやすくなります。
分からない言語でも、構文を調べるところから始められる。既存コードの意味を聞ける。エラーの原因候補を出せる。最初のコード案を作れる。
ここで学びが減るわけではありません。
変わるのは、学び始める場所です。
AIが出したコードを読み、既存コードとの差分を見る。レビューで指摘された理由を記録する。テストで失敗した条件を残す。なぜその修正が必要だったのかを、自分の言葉で説明できるようにする。
未経験言語で書けるようになることだけが学びではありません。
どの要件を見落としていたのか、どの影響範囲を確認していなかったのか。AIが出したコードのどこを信じすぎたのか。レビューで直した箇所には、次に見るべき観点が残っています。
早く答えに近づけるからこそ、途中で何を確認したかを残しておかないと、理解が追いつかないまま進むことがあります。
若手にとって、AIを使わないことが目的にはなりません。使った後に、何を読み、何を直し、何を次回の確認項目として残すか。その積み重ねが、次の仕事で効いてきます。
顧客が求めているのは、AIが書いたコードではない
顧客が受け取るのは、コードそのものではありません。
業務の中で動く機能です。
検索結果が正しく表示される。権限によって見える範囲が変わる。帳票や外部連携に余計な影響が出ない。問題が起きたときには、原因を追い、どこを直したのか説明できる。
顧客にとって、コードを誰が書いたかは中心ではありません。AIを使ったかどうかより、その機能が業務の中で使えるか、問題が起きたときに対応できるかが見られます。
「AIが書いたので分かりません」とは言えません。
納品する以上、技術者はそのコードを読んでいる必要があります。どの要件に対応し、どの既存処理に触れ、どのテストで確認したのか。残っている注意点があれば、それも説明できる状態にしておきます。
AIを使った開発でも、顧客へ渡す前の確認は残ります。そこを飛ばすと、コードはできても、納品できる仕事にはなりません。
AIを使うほど、説明できる範囲が問われる
ディーシステムでの生成AIを活用した未経験言語での開発から納品までの経験で残ったのは、AIが書けるから人の仕事がなくなるという話ではありませんでした。出力されたコードを読み、既存システムに合わせ、影響を確認し、テストし、顧客へ説明できる状態にする。そこまで進めて、ようやく納品に近づきます。
コードを早く出せることは、強みになります。
その先で、どこまで理解しているか。どの条件を確認したか。どのテストで確かめたか。問題が起きたとき、顧客へ何を説明できるか。
AIを使うほど、技術者の差は別の場所に見えてきます。
未経験言語での開発を可能にしたのは、AIの出力だけではありませんでした。
その出力を読み、直し、試し、説明できるところまで持っていく人の仕事がありました。
ディーシステムでは、生成AIを使った開発でも、コード生成だけで終わらせず、レビュー、テスト、顧客説明まで含めて納品へつなげる経験を大切にしています。
