昨年までは自分でプログラムを書くことは少なかったのですが、今年に入ってその時間が増えました。といっても、AIにコードを生成させているので、増えたのはAIに指示を出す時間と生成されたコードを確認する時間です。

この数か月、自社製品のポイントシステム「Cardfeel」やPOSレジ「コアレジ」で、機能追加やカスタマイズを生成AIを使って進めています。要件や仕様の整理にはChatGPTを使い、ソースコードの調査や実装にはCodex、Cursor、Claudeを使っています。

AIに任せる範囲は、プログラムの作成だけではありません。既存のソースコードの調査、影響範囲の洗い出し、実装方針の作成、テストコードやテスト項目の作成、ドキュメントの更新まで含みます。

ほんの1、2年前なら、かなりの時間が必要だった作業です。時代は変わったなと思います。

AIの使い方より大事なのはその前後

これからのエンジニアにとって、AIを使うことは前提になると思います。一方で、AIツールの操作方法そのものは、エンジニアの専門性としてはそれほど重要ではないとも思っています。

良い指示の出し方や、各ツールの特徴を理解する必要はありますが、基本的な使い方はAIに聞きながら短期間で身につけられます。プロンプトのちょっとしたテクニックも、モデルが進化するにつれて重要性が下がっていくと思います。

AIを操作できることと、AIを使って仕事を完了できることは別です。重要なのは、

・何を作るべきかを整理する
・AIに必要な情報を与える
・AIが作ったものが正しいか判断する
・問題があれば修正方法を決める
・最終的な品質に責任を持つ

といった、AIを使う前後の仕事です。これは、これまでプロジェクトリーダーや上級エンジニアに求められてきた仕事と重なります。

整っているのに間違っている

AIが生成する成果物には、少し厄介な特徴があります。文章もコードも見た目が整っているのです。

人が作った設計書やプログラムは、細部を見るとその人が全体像や重要なポイントをどの程度理解しているかが何となく分かります。説明に甘さがあったり、例外処理が雑だったり、似た処理が整理されずに並んでいたりすると、他の部分も慎重に確認した方がよいと判断できます。プロジェクトを長くやっていると、このような「成果物の品質感」からどこまで確認すべきかをある程度判断します。

ところが、AIの成果物は内容に問題があっても整って見えます。それらしい構造があり、クラスやメソッドの名前も自然でコメントも入っています。それでも前提を大きく誤解していたり、依頼していない処理や機能が含まれていたりすることがあります。この点は人が作る成果物とは違った意味でレビューが難しいです。

そこで複数の方法を組み合わせて確認します。

最初に行うのは、別のAIによるレビューです。例えばCodexで調査や実装を行った場合は、Claudeで生成されたソースコードや仕様を直接確認します。実装をおこなったAIの説明だけに頼らず、別のAIで元の仕様やソースコードを確認するのです。

次に可能な範囲でAIでテストコードを作成・実行し、その結果を確認します。そのうえで従来どおり人が実際の動作、設計、影響範囲を確認します。AIがレビューし、テストが通ったことだけを、正しさの根拠にはできないのです。

ソフトウェア開発は複雑さとの戦い

ソフトウェア開発は、システムの複雑さと人が理解できる限界との戦いだと思っています。オブジェクト指向やレイヤー分割などの設計手法も、現実の複雑な問題を、人が理解できる単位や構造に整理するためのものと認識しています。

AIは大量のコードやドキュメントを短時間で作れますが、指示された内容を漏れなく盛り込もうとする結果、必要以上に複雑な成果物を作ることがあります。あらゆるケースを説明した長い文書、将来使うか分からない拡張機能、細かく分割しすぎたクラスなどです。一見するとよくできた成果物に見えますが、人が理解しにくくなれば、内容を十分に確認できず、品質に責任を持てません。つまり、そのままでは実務上の価値が低いのです。

だから、AI開発では以前より単純化する努力が重要になります。当たり前の説明は省く。補足事項は備考にまとめる。共通点を抽象化して整理する。現在の仕様と検討中の案を混在させない。採用しなかった案が重要なら、現行仕様とは別の決定記録として残す。AI開発では、この努力が欠かせません。

AIが仕事をしやすい開発環境

AI開発で成果を上げられるかどうかは、開発環境の整備に大きく左右されます。当社のプロダクト開発では、次の整備を進めています。
・ソースコードと主要なドキュメントを同じGitリポジトリで管理する
・ドキュメントはAIが扱いやすいMarkdown形式で作成・維持する
・案件やタスクごとに、目的、前提、決定事項、対象外を記録する
・ドキュメントの冒頭に状態（作成中、確認済み、廃止など）を記載し、位置づけを明確にする

もっとも、既存システムに関する過去の文書を一気にMarkdownへ移行するのは合理的でも現実的でもありません。そこで、機能追加や修正を行う箇所から作業に合わせて整理しています。

ドキュメントはAIが扱いやすいように整えているのですが、結果として人にとっても現在の仕様や判断理由を探しやすい状態になります。AIが仕事をしやすい開発環境は、人にとっても仕事をしやすい開発環境なのだと思います。

実装は人が見切れる単位で進める

AIに大きな機能の実装をまとめて指示すると、かなり広い範囲まで一度に変更できます。それでも実際の開発では、調査、方針決定、実装、テストを小さな単位に分けて進めるようにしています。

これはAIの能力が足りないからではなく、人が変更内容を理解し、問題があったときに原因を特定し、必要に応じて元に戻せる状態を維持するためです。

例えば、ある機能の変更を行う場合でも、最初から関連するすべての処理を一度に変更するのではなく、
・現在の仕様と処理を調査する
・変更内容と影響範囲を整理する
・中心となる処理を変更する
・テストを追加して動作を確認する
といった形で段階を分けます。

AIは、一度に多くのファイルを変更することができます。しかし、変更量が人の理解できる範囲を超えると、レビューの精度は下がります。問題が発生した場合も、どの変更が原因なのか分かりにくくなります。さらに、途中の方針に誤りがあったときの後戻りも大きくなります。

そのため、AIが一度に実行できる範囲ではなく、人が見切れる範囲を基準に作業を分けます。

実装を段階的に進め、コミットも意味のある単位に分け、それぞれの段階で確認する。これは従来のソフトウェア開発でも大事なことでした。AIによって大きな変更を簡単に行えるようになったため、むしろ以前より重要になったと思います。

コードを書く量が減っても、技術は必要

これから、エンジニアが手でコードを書く量は減っていくと思います。一方で、AIが作ったコードを読み、処理の流れを理解し、変更の妥当性を判断する必要は、当面なくならないと思います。

そのため、オブジェクト指向、依存性注入、トランザクション、非同期処理など、既存のプログラムを理解するための知識は必要です。

さらに重要度が上がるのは、アーキテクチャ設計、データベースの論理設計、情報セキュリティ、テスト、障害対応などの知識です。どれも、これまでは上級エンジニアやプロジェクトリーダーに求められることが多かった能力です。

ここでいうリーダーは、人員管理だけを行う管理者ではありません。技術を理解し、何をどのように作るかを決め、プロジェクトを安全に進める人です。

私は会社設立以前から、プロジェクトマネージャの仕事は技術をベースにする仕事だと考えています。AI時代には、この考え方がさらに重要になると思います。

学ぶなら基本情報、次に応用情報

経験が浅いエンジニアから何を勉強すればよいかと聞かれることがありますが、まず基本情報技術者試験、次に応用情報技術者試験を勧めます。

資格を取得することだけが目的ではありません。コンピューター、データベース、ネットワーク、セキュリティ、システム設計、プロジェクト管理などを体系的に学ぶことに価値があります。

さらに深く学ぶなら、情報セキュリティの知識を充実させることやリレーショナルデータベースの論理設計をしっかり学ぶことがよいと思います。

AIで作業速度が上がるほど、人は短時間に多くの判断を求められます。そのため、エンジニアの基礎知識は以前より重要になります。

しっかりした基礎知識があれば、それを基にAIへの指示や成果物の確認を効率よく的確に進められます。基礎知識の価値は下がるどころか、AI開発時代においては上がると思うのです。

経験数年のエンジニアにとってはチャンス

当社では現在、ソフトウェア開発の経験が数年程度あるエンジニアを募集しています。入社時点でアーキテクチャ設計や顧客対応まですべてできる必要はありません。

まずは既存のソースコードを読みながら、小規模な機能追加や不具合修正、テストから担当します。慣れてきた領域から、調査、設計、リリース、本番保守、見積り、顧客対応へと担当範囲を広げていきます。

いきなり一人で全部を任せるわけではありませんが、指示された箇所のコードだけを書いて仕事を終えるのではなく、変更の目的や影響範囲を理解し、一つの機能やシステムに責任を持てるエンジニアを目指してほしいと思っています。

AIによって、指示どおりにコードを書く仕事は減っていくと思います。一方で、経験が浅いうちから、調査、設計、テスト、ドキュメント作成まで、幅広い仕事に取り組みやすくなりました。

使い方次第では、これまでより早い段階で、上級エンジニアが担ってきた仕事の一部を経験できます。これは、経験数年のエンジニアにとって大きなチャンスだと思います。

責任は人。作業はAI。

来年や再来年のソフトウェア開発がどうなっているかは、正直なところ分かりません。

人がコードをほとんど書かなくなるかもしれませんし、AIが作ったコードを一行ずつ読む仕事も減っていくかもしれません。

それでも、人の仕事は残ります。作業量は減っても、一つ一つの判断の重要度は上がっていくと思います。

・何を作るかを決める
・具体化する過程で方向性を示し、承認する
・アーキテクチャを決める
・実装状況を把握する
・テスト結果を確認し、リリースの可否を判断する

そして、一番大事な「お客様に対して品質に責任を持つ」という仕事が残ります。AIがどれだけ進化しても、AI自身がお客様に対して責任を負うことはありません。

私は、これを「責任は人。作業はAI。」と捉えています。AIに仕事を丸投げするのではなく、人が目的と責任を持ち、そのための作業をAIに任せる。

こうした開発を面白いと思うエンジニアと一緒に仕事をしたいです。