Java未経験者を含む10人超のチームが、残業ゼロで製造単体を完走した。では、品質はどうだったのか

みなさん、こんにちは！
現役IT執行役員のグイグイです⚡

このところ、実際の開発プロジェクトでAI駆動開発を進めながら、その途中経過をnoteに書いています。

今回、約2ヶ月続いた製造・単体テストのフェーズが終わりました。

まず、生産性については明確な結果が出ました。

開発者は10名以上。その中にはJavaをほとんど経験していないメンバーもいれば、新人レベルのメンバーも複数います。

そんなチームで、全員が残業することなく、予定していた製造・単体テストを計画通りに完走しました。

全タスクの製造コードが完成し、単体テストコードも作成され、テストは全件グリーン。ソースコードレビューも一通り完了しています。

長くエンタープライズ系のシステム開発をやってきた人なら、これが普通ではない状況だということは分かると思います。

少なくとも、従来のやり方では簡単には起きません。

Java未経験者や新人を含めても、計画通りに終わった

今回のプロジェクトは、既存システムのスクラッチ刷新です。

それなりの規模があり、金融系なので、単純に画面を何枚か作れば終わるようなシステムでもありません。

この条件でJava経験者が少なく、新人も含めたチームを組めば、通常は経験者に負荷が寄ります。

若手が書いたコードをベテランが直し、設計の理解が足りなければ横について説明する。進捗が遅れれば、どこかで残業して吸収する。

あるいは最初から、新人やJava未経験者については十分な生産性を見込まず、計画側で調整する。

これまでなら、そうなることが多かったと思います。

今回は違いました。

設計書をもとにAIとSPECSを整理し、AIエージェントに実装させ、テストコードも作らせ、人間が確認する。

もちろん全部をAI任せにしているわけではありませんが、製造工程の多くで生成AIを使っています。

その結果、これまでなら経験者でなければ十分な生産性を出しにくかった領域でも、経験の浅いメンバーが実際の戦力として動けています。

少なくとも今回の現場では、生成AIによって製造の生産性は明らかに上がりました。

ここについては、もう疑っていません。

では、品質はどうだったのか

ここが今回書きたい本題です。

製造単体を終え、内部結合試験の準備に入った初日のことです。

テストケースを作っている途中で、設計そのものに問題がある箇所が見つかりました。

調べてみると、その問題については製造単体フェーズの時点ですでにAIが指摘していました。

今回、設計書からSPECを作成するときには、既存システムのソースコードとも突き合わせています。

その過程でAIは、

「設計書と現行実装に差異がある」

という趣旨の指摘をきちんと出していました。

ところが、それを確認した経験の浅いメンバーが、その指摘の意味を正しく読み取れていませんでした。

結果として問題なしと判断され、その前提のまま実装が進んでしまった。

それが内部結合試験のテストケースを作る段階になって、ようやく表面化しました。

これは、AIを使ったから起きた問題ではない

ここは誤解されたくないところです。

設計や仕様の間違いが、製造を終えた後や結合試験の準備段階で見つかること自体は、AI駆動開発特有の現象ではありません。

AIがない時代から、そんなことはいくらでもありました。

設計レビューをして、製造して、単体テストも全部通った。

それでも結合試験になって初めて、仕様の考慮漏れや設計上の矛盾に気づく。

システム開発を長くやっていれば、別に珍しい話ではありません。

なので今回の出来事を、

「AIを使ったから品質が落ちた」

と捉えるのは違います。

AIを使ったことで、それまで存在しなかった種類の問題が突然生まれたわけではありません。

今回面白いのは、別のところにあります。

AIは指摘していた。それでも見逃した

今回、AIは必要な情報を出していました。

それでも、人間側の判断で見逃しました。

ここがAI駆動開発としては重要だと思っています。

AIが、

「設計書と現行実装に差異があります」

と教えてくれていても、その差異が何を意味しているのかを人間が理解できなければ、その情報は活かされません。

そこで「問題なし」と判断してしまえば、その後の実装もその判断を前提に進みます。

つまり今回ボトルネックになったのは、コードを書く能力ではなく、AIが出した情報を読み取り、意味を判断する能力でした。

設計の意味を理解できるか。

現行ソースとの差異に違和感を持てるか。

その差異が仕様上問題なのか、それとも許容できるものなのかを判断できるか。

ここでは、設計知識や言語仕様、業務知識がそのまま効いてきます。

以前の記事で「AI駆動開発で差がつくのは、AIに何を渡さないかを決められる人だ」という話を書きました。

AIに全部やらせるのではなく、どこまで任せて、どこを人間が判断するのか。

今回起きたことは、その延長線上にあると思っています。

生産性が上がっても、品質保証の工程はなくならない

ここまでの結果を見て、今のところ自分の中では一つ整理できています。

AIは、製造の生産性を大きく変えます。

今回のプロジェクトでは、それを実際に確認できました。

一方で、だからといって、

「AIを使って作ったのだから、従来の品質確認工程を減らしても大丈夫だろう」

とはなりません。

単体テストには、単体テストで確認できる範囲があります。

結合試験には、複数の処理をつないで初めて確認できることがあります。

さらにシステム全体を動かしてみなければ見えない問題もあります。

これはAIを使おうが使うまいが変わりません。

今回も、製造コードは完成していました。

単体テストも全件グリーンでした。

レビューも終わっていました。

それでも、次の工程に進もうとしたところで設計上の問題が見つかりました。

だから、これまでソフトウェア開発が積み上げてきたレビューや各種試験のフレームワークは、AI駆動開発でも基本的には残すべきだと思っています。

AIによって製造が速くなったことと、品質を確認する必要がなくなったことは、同じではありません。

本当の評価は、ここから見えてくる

製造単体までの生産性については、想像していた以上の結果が出ました。

Java経験の浅いメンバーや新人を含む10名以上のチームが、約2ヶ月の製造単体を残業ゼロで予定通り終えた。

これは、私が17年間Javaの開発現場を見てきた中でも大きな変化です。

ただし、AI駆動開発全体の評価はまだ終わっていません。

ここから内部結合試験が始まります。

そこでどれだけバグが出るのか。

従来の開発と比べて多いのか、少ないのか。

どんな種類のバグが出るのか。

経験の浅いメンバーがAIを使って作った成果物が、最終的にどこまでの品質に到達するのか。

その結果を見ないことには、今回のAI駆動開発を本当の意味では評価できません。

ただ、今回の時点でも一つだけ分かったことがあります。

AIがコードを書く速度を上げても、品質を確認する工程まで代わりに引き受けてくれるわけではない。

そして、AIが正しい情報を出していても、その意味を読み取る人間が間違えれば、成果物も間違います。

製造単体までは終わりました。

ここから先で何が起きるのか。

内部結合試験の結果も、またそのまま書こうと思います。

#AI駆動開発
#生成AI
#システム開発
#ソフトウェア開発
#Java
#開発生産性
#品質管理
#テスト工程
#AIエージェント
#エンジニアリング