はじめに
他の記事でも紹介している通り、弊社スマレジはAI Dev Ex Conference 2026にスポンサー、登壇した。
この記事では、イベント参加時に他の参加者のかたと会話した内容から自分自身で考えたことをいくつかのトピックとしてまとめていく。
QA・テストについて
開発においてAI活用が進む中、ボトルネックは上流もしくは下流に移動している、もしくは元々開発において実装はボトルネックではなかった、というのが各社スポンサーブースでのアンケートやエンジニアが口を揃えて感じている印象。
開発において重要なのは、何を作るのか、といった要求定義、要件定義の精度と本当に作りたいものを作れているか、品質は確かか、といった作ったものに対する評価と検証になる
よくあるのがQAが社内受託のようになっているパターンで、抱えているQA作業が多すぎて機能していないパターンです。いろんな会社のエンジニアにこの辺りの品質管理をどうやっているんですか、という質問をして自分なりに考えた結果、理想としては下記のような形になりそう。
- 要件定義段階でQAチームがテスト設計の視点から参加して意見を出す
- 実装と並行してテスト設計が進行しており、実装が完了する頃にはテスト設計が完了している
- テスト実行は開発エンジニアが行う(自動テスト、手動テストどちらも含む)
テスト自動化に関してはE2EテストのメンテナンスコストがAI活用によって下がり利用しやすくはなっているが、引き続き単体テスト、結合テストも書いていく必要がありそう。
この辺りは自分の担当しているプロジェクトはほとんどが軽めなクリーンアーキテクチャで作っているのでフレームワークなど外部への依存は切り離せているのであまり障害はなさそう。
また、フロントエンドのテストにおいてはどうしても目視でのUIテストが必要になる。ただ、愚直にできるだけロジックとUIを分離して、vitestなどでの単体テストを書いて自動化比率を増やしていく。
AIエージェント自体を作成して、プロダクト理解、テスト設計支援といった部分は自律したエージェントに大部分の実行、補助を移譲していく仕組みが必要そう。
ちなみにスマレジでは各プロダクトへの問い合わせをエンジニアに直接聞く代わりにまずはAIに聞いて回答できる仕組み「AI仕様回答くん」というエージェントを用意している。slackアプリを入り口として、特定リポジトリのコードを探索して現状の実装について回答することができる仕組みで、これをテスト設計に活用している
ドメイン駆動設計について
AIの活用が進むにつれて、上流側の課題がより浮き彫りになってくるという話もイベントで散見された。また、仕様理解もAI活用の副作用として認知が遅れるいわゆる「認知的負債」が問題になっている。
この問題への対処として、設計書などをHTMLで作る方法などが話題だが、ドメイン駆動設計、もっと簡単にいうと業務に詳しい人と一緒に業務のモデリングをやることの重要性が上がってきている、と話してた人が数人いた。
自分の感触も同じで、自分はもっとわかりやすくするためにイベントストーミングをやる機会が増えた。まずはイベントを書き出してみましょう、というところから、詰まるところこの業務はこういうモデルなんですかね？という会話をしていく。
案外この時作成した資料が実装の途中でAIに任せて何をやっていたかを忘れた時に役に立ったりする。
労力をイベントストーミングやモデルにしっかりとかけておけば、具体的な実装部分はAIが結構うまくやってくれる。
これから先はより一層ドメイン駆動設計、もっというと業務にむきあう時間が重要になるはずで、ここは私自身の登壇資料の内容とも似ており、AI活用が進むにつれて、ユーザーが本当に必要なものをどれだけソフトウェアに落とし込めるかが重要になってくると思う。
反対に言えば、すでにモデリングされていたり要求が明確なものをコードにするエンジニアはすでに不要になっている。
教育について
コードを書くだけのエンジニアが不要になるに従って、どうやってジュニアエンジニアや新卒をシニアエンジニアまで育てるのか、その方法にも変化が現れていると思う。まず前提として、AI登場以後に適切な教育プログラムでシニア相当まで育った人はまだ出てきていない世代だと思う。
僕自身がWEB開発経験4年半程度で、そのうち3年以上はAIに触れているものの、WEB開発経験以前にC言語での組み込みやら単体テスト経験があるので対象外だと思う。
また、そもそもエンジニア全体の母数の中で、適切にシニアエンジニアになれる人は本当にわずかだと思う。適正のある人は3年程度で駆け上がっていく道のりに、一生かかっても到達できない可能性もあり、教育というのは単に育てるというだけではなく、選別を含んでいる単語だと思っている。
これらの前提の上で、簡単なコードや自動化を経て徐々に理解できる範囲を広げながら技術を習得するという従来のステップアップ方法がAIによって奪われているのが現実だと思う。ただ、よくよく考えてみると自分自身は特に業務で簡単なコードを書くことで成長したと感じたことはないかもしれない。必要なのは、定期的に自分自身に何が不足しているかを考えるメタ認知と、不足していると思う点について納得いくまで時間をかけるだけの余裕だった。つまり、毎週5000文字程度のブログを書くと決めて守り続けたことが一番成長につながったと思う。
理解の次は実践で、ここは本当にAIによって奪われつつある。ただ、理解を先に進められているとAIに実装を任せられるので、理解が曖昧な部分を整理してシニアと議論して深められればまだ完全に成長の過程が失われたわけではないかもしれない。ただ、シニアの工数はAI登場以前よりも貴重になっているので、成長したいと思っている人に本当に時間を割けるのかは怪しい。
結局のところ、OJTを前提としたこれまでの教育方法はもう破綻が見えてきており、成長したい人にタスクを振るならシニアがAIに直接振ってタスクを完了させた方が早く、確実に、負荷が少なく完成してしまう。なので組織としてはより教育だけを目的とした研修や学校的な仕組みに寄っていくんじゃないか、と思っている。
ソフトウェアの基礎をサボらず習得すると同時に、AIによって楽をできるところとそのリスクの理解がより一層重要になってくる。
まとめ
いずれも組織的な課題、仕組みを変革するタイミングが来ている。個人での活用や試行といった段階は去年で終わっており、費用対効果が求められるようになっているので、組織としてもAI前提の構造に変化するしかない。
そしてそれは徐々に線形に変われるようなものではなく、従来の仕組みをほとんど捨てて取り組まないと到底間に合わないと思う。それほどまでにAIの登場によってソフトウェアの発展は数十倍のスピードになってしまった。
