技術面接は、予定していた一時間を少し過ぎていた。
画面共有を終えると、面接官はノートパソコンを閉じた。コーディング課題の話も、これまで担当したシステムの話も一通り終わっている。あとは挨拶をして退室するだけだと思っていた。
「最後に、少し意地の悪い質問をしてもいいですか」
面接官はそう言って、机の上のペンを置いた。
「普段、AIにコードを書かせていますよね」
「はい。設計の相談にも、実装やテストにも使っています」
「では、AIがあなたの100倍の速さでコードを書けるとします。構文もライブラリも、あなたより詳しい。それでも、会社があなたをプログラマーとして雇う理由は何ですか」
すぐには答えられなかった。
100倍という数字が正しいかどうかは問題ではない。面接官が聞きたいのは、もっと単純なことだった。コードを書く速さで機械に勝てなくなったとき、自分は何のためにいるのか。
私は少し考えてから口を開いた。
「コードを書く速さでは、勝てないと思います」
面接官は黙って続きを待っていた。
「ただ、コードが速く出てくることと、必要なソフトウェアを作れることは、同じではありません」
コードはすぐに出てきた。決めることは残った
以前、営業部から顧客管理画面を使いやすくしてほしいと頼まれたことがある。
その要望をAIへ渡すと、検索条件の追加、一覧の並べ替え、入力フォームの分割など、もっともらしい改善案がすぐに返ってきた。画面のコードも短時間で形になった。
ところが、営業担当へ話を聞くと、問題は画面の見た目ではなかった。担当者ごとに顧客の状態を表す言葉が違い、新しく入った人が入力を間違えていた。検索を速くしても、フォームをきれいにしても、それだけでは解決しない。
「AIにもっと詳しく質問させれば、その問題も見つけられるのでは？」
面接官が聞いた。
「質問の候補は出せます。でも、誰に聞くべきか、言っていることが食い違ったときにどちらを優先するかは、その会社の事情を知らないと決められません」
営業は入力を減らしたい。管理部門は監査のために記録を増やしたい。経営側は今月中の公開を求め、開発側はデータ構造から直さなければ後で困ると考えている。
どの意見も、本人の立場から見れば間違ってはいない。実際の仕事では、その中から今回やることと見送ることを決め、納得してもらう必要がある。
「コードを書く前に、何を直せば仕事が楽になるのかを確かめる。その部分は、まだ人がかなり働かないと進みません」
きれいな設計が、現場で使えるとは限らない
面接官は別の角度から聞いた。
「要件が決まれば、設計もAIに任せられますよね。アクセス数や可用性を伝えれば、かなり詳しい構成を出せます」
「出せます。ただ、その構成を運用できるかは別です」
私は、別の案件で検討した構成を思い出した。AIへ条件を渡すと、イベント駆動、複数のサービス、分散キャッシュ、冗長化された基盤を組み合わせた案が出てきた。資料としてはよくできていた。
しかし、その案件の開発者は四人で、公開まで六週間しかなかった。夜間の障害対応を担当できる人も限られていた。既存のデータベースを今期中に置き換えることもできない。
結局、既存のアプリケーションを拡張し、時間のかかる処理だけを非同期ジョブへ分けた。理想的な構成ではないが、チームが理解して運用できる範囲に収めた。
「それは妥協ですか」
「はい。ただし、理由を説明できる妥協です。予算や人数を無視した設計は、図ではきれいでも、運用が始まると誰も面倒を見られません」
技術的に可能な案を並べることと、今の組織が扱える案を選ぶことは違う。選ばなかった案の利点も欠点も分かったうえで、今回はどこまでやるかを決める必要がある。
障害が起きた夜に残る仕事
「でも、コードレビューもAIができます。人より多くのパターンを確認できる場合もある」
「そこは私も使っています。人だけで見るより、見落としが減ることもあります」
私は以前、決済処理の障害対応に入った夜のことを話した。
リトライ処理を含む変更が本番へ入り、特定の条件で同じ決済要求が二度送られていた。テストは通っていたが、外部サービス側で処理が完了した直後に通信が切れた場合を十分に確認できていなかった。
変更を作ったのが人かAIかは、その場では重要ではない。まず追加の処理を止め、ログを確認し、影響を受けた注文を特定する。返金方法を決め、顧客対応の担当へ状況を伝え、翌朝までに説明できる資料を作る必要があった。
「AIに調査を手伝わせることはできます。でも、どの時点でサービスを止めるか、誰へ連絡するか、どの対応なら利用者への影響を抑えられるかは、その場で誰かが決めなければなりません」
面接官は少し考えてから聞いた。
「つまり、責任を持つ人が必要だと」
「責任という言葉だけでは足りないと思います。状況を整理し、分からないことが残った状態でも、次に何をするかを決める人です」
AIより速く書くことは目標にしていない
私は、AIを使わずに働くつもりはないと付け加えた。
実装の下書き、テストケースの洗い出し、既存コードの調査、ログの整理。速く任せられる作業は多い。自分で一から書くことにこだわれば、かえって仕事は遅くなる。
ただし、いきなり「この機能を作って」とだけ頼むことは減った。最初に、誰が何に困っているのか、守るべき制約は何か、失敗したときにどう振る舞うべきかを書く。実装前には複数案と不明点を出してもらい、採用する案を決めてからコードを書かせる。
受け取った差分についても、動作するかだけではなく、なぜこの構成になったのか、データが増えたらどこが詰まるのか、元へ戻す方法があるかを確認する。
「AIを使えること自体は、すぐに珍しくなくなると思います。差が出るのは、出てきたものを説明できるか、採用しない判断ができるかです」
もう一度、最初の質問に答える
面接官は、最初と同じ質問を言い直した。
「では、AIがあなたより100倍速くコードを書けるとしても、会社があなたを雇う理由はある、と」
「あると思います」
今度は迷わず答えた。
「私はAIより速くコードを書けません。けれど、何を作るべきかを確かめ、会社の事情に合わせて方法を選び、出てきたコードを確認し、本番で問題が起きたら対応できます。コードを書く作業はAIに手伝ってもらいますが、判断まで任せきりにはしません。それが、今の私を雇う理由です」
面接官は職務経歴書へ目を落とし、数秒してからうなずいた。
「分かりました。今日の面接は以上です」
部屋を出たあとも、質問は頭に残っていた。仕事がなくならないと言い切れるほど楽観的ではない。これまで時間をかけて覚えた作業の一部は、これから確実に短くなる。
それでも、自分の役割をコードの入力作業だけで考える必要はない。作る前に確かめること、採用する案を選ぶこと、公開してよいか判断すること、問題が起きたあとに対応すること。実装が速くなるほど、こうした仕事を避けては通れなくなる。
まとめ
この話で言いたかったのは、人にしかできない仕事を無理に探すことではありません。AIにもできる作業は任せながら、プロジェクトを進めるために誰かが決めなければならないことを引き受ける、ということです。
コードの生成速度と、開発の速さは同じではない
コードが早く完成しても、要求が曖昧なままなら作り直しになります。チームが運用できない設計を選べば、公開後の負担が増えます。レビューや検証を省けば、生成に使った時間以上の手戻りが発生します。
速いコード生成を実際の開発速度へ変えるには、要件の確認、設計の選択、レビュー、運用までつなげる必要があります。
プログラマーに残る仕事
今後、特に重要になるのは次のような仕事です。
- 利用者や現場へ話を聞き、本当に困っていることを確かめる
- 予算、人数、期限を踏まえて、実行可能な設計を選ぶ
- 生成されたコードを読み、見落とされた条件や危険な変更を探す
- 本番へ出すかを判断し、問題が起きたときに対応する
これは「コードを書かなくてよい」という意味ではありません。コードを読めず、動きを説明できなければ、AIの出力を評価することもできません。基礎的な実装力は、書くためだけでなく、判断するためにも必要です。
経験に応じて意識したいこと
若手は、AIが答えを出す前に自分で考える時間を残した方がよいでしょう。エラーを読み、ドキュメントを探し、小さく失敗する経験が、あとで出力を評価する基準になります。
中堅は、定型的な実装の速さだけに頼らず、複数機能にまたがる設計、障害対応、チーム内の調整、業務知識へ仕事の範囲を広げる必要があります。
経験の長いエンジニアには、個人の実装速度だけでなく、AIを導入したときの品質管理、費用、権限、チーム全体の進め方を設計する役割があります。
次にAIへ依頼する前に
次の実装を頼む前に、少なくとも三つだけ自分の言葉で書きます。
- 誰が、何に困っているのか
- 守らなければならない制約は何か
- 失敗したとき、どうなってほしいのか
生成された差分を受け取ったら、自分だけで変更内容と採用理由を説明してみます。説明できない部分があれば、そこはまだ任せきりにしてよい状態ではありません。
AIより速くコードを書く必要はありません。速く書かれたコードを、実際に使えるソフトウェアへ変えることが、これからのプログラマーの仕事になります。
