AI前提の開発における品質保証
こんにちは、エンジニアの安達です。
タンプでは、プロダクト開発のさまざまな工程にAIを取り入れています。
要件定義や設計、実装といった工程をAIが支援することで、以前よりも短い時間で進められるようになりました。
一方で、AIを前提に開発を進めるほど、新しい課題も生まれます。
それは、人間がすべての成果物の細部まで把握することが難しくなるということです。
AIが生成した要件定義を細かく確認し、設計書をすべて読み、コードのdiffを一行ずつ確認し、テストコードまで詳細にレビューする。
一定の安心感は得られますが、人間がすべてを確認することを前提にしてしまうと、最終的には人間のレビュー速度が開発速度の上限になります。
AIによって開発を高速化したにもかかわらず、品質保証だけが従来と同じ方法のままでは、開発全体としては十分にスケールしません。
そこでタンプでは、人間がすべてを把握することに依存しない品質保証を目指しています。
事故をゼロにするのではなく、一つのミスで事故にならないようにする
品質保証を考える上で、前提としていることがあります。
それは、不具合やミスを完全にゼロにすることはできないということです。
人間も間違えますし、AIも間違えます。レビューにも見落としがありますし、テストですべてのケースを網羅することもできません。
そこで参考にしているのが、スイスチーズモデルの考え方です。

一つひとつの防御策には穴があります。しかし、異なる種類の防御策を何層も重ねることで、すべての穴が同時に重ならない限り、大きな事故にはつながりません。
タンプでも、一つのレビューや一人のエンジニアに品質を依存させるのではなく、開発から本番運用まで複数の防御策を用意しています。
重要なのは、一つひとつのチェックを完璧にすることではありません。
どこか一つでミスが発生しても、別の仕組みで検知できる状態を作ることです。
要件定義・設計・実装を分け、それぞれでレビューする
AIに開発を任せる場合でも、要件定義から実装までを一気に進めることはしていません。
タンプでは、大きく
-
要件定義
-
設計
-
実装
という工程に分け、それぞれを独立した成果物として扱っています。
各工程では、まずAIによる一次レビューを行い、その後に人間による二次レビューを行います。
AIには、成果物の抜け漏れや矛盾、既存ルールとの不整合などを広く確認させます。
一方で人間は、細かな表現をすべて確認するというよりも、
-
そもそもの方向性が正しいか
-
重要な前提を間違えていないか
-
事業上の意図とずれていないか
-
リスクの高い判断が含まれていないか
といった部分を中心に確認します。
網羅的な確認をAIに寄せ、人間は重要な判断に集中することで、レビューコストを抑えながら品質を担保しています。
上流のコンテキストを下流へつなぐ
AIを使った開発では、各工程単体の品質だけでなく、工程をまたぐときの認識のずれも重要な問題になります。
要求から要件定義、要件定義から設計、設計から実装へ進むたびに、元の意図が少しずつ変わってしまえば、最終的には正しく動くコードであっても、作りたかったものとは違うものが完成してしまいます。
そこで、上流工程の成果物を下流工程のコンテキストとして引き継ぐようにしています。
要求をもとに要件定義を行い、設計時には要求と要件定義を参照し、実装時には要求・要件定義・設計を参照します。
それぞれのAIがゼロから前提を推測するのではなく、なぜこの設計になっているのか、なぜこの実装が必要なのかを上流までたどれる状態を作ります。
AIの精度だけに依存するのではなく、AIに渡すコンテキストそのものを管理することも、品質保証の一部だと考えています。
機械的に揃えられるものは、人間が見ない
実装においては、人間がレビューする前に、機械的に判定できるものをできるだけ自動化しています。
たとえば、
-
formatter
-
linter
-
型チェック
-
静的解析
などです。
AIが生成するコードには、書き方の揺れが発生することがあります。
しかし、機械的に統一できる部分まで人間がレビューで指摘する必要はありません。
また、静的解析では表現しにくいコーディング規約については、AIによるレビューを行います。
つまり、
機械的に判断できるものはツールに任せる。
文章として定義されたルールとの照合はAIに任せる。
設計判断やリスク判断は人間が見る。
という形で役割を分けています。
人間のレビューコストを下げるためには、レビューそのものを効率化するだけではなく、そもそも人間が見る必要のないものを減らすことが重要です。
テストも一つの種類に依存しない
レビューを通過したコードであっても、不具合が含まれている可能性はあります。
そのため、テストについても一種類ですべてを保証しようとはしていません。
タンプでは、
-
単体テスト
-
統合テスト
-
E2Eテスト
-
受け入れテスト
と、異なるレイヤーのテストを用意しています。
単体テストでは局所的なロジックを確認し、統合テストでは複数のコンポーネントをまたいだ動作を確認します。
E2Eテストではユーザー操作を含めたシステム全体の動きを確認し、受け入れテストでは、最終的に事業側が期待している要件を満たしているかを確認します。
ここでも考え方は同じです。
AIが生成したコードが正しいことを信じるのではなく、仮に間違ったコードが生成されても、どこかのテストで検知できる可能性を高めることを重視しています。
小さい変更を継続的にリリースする
開発中にどれだけ品質保証を行っても、本番環境で初めて発覚する問題を完全になくすことはできません。
そのため、タンプではトランクベース開発を採用し、小さな変更を継続的にmasterへ取り込むようにしています。
大きな変更をまとめてリリースするよりも、一つひとつの変更を小さく保つことで、不具合が発生した場合にも原因を特定しやすくなります。
影響範囲も限定されやすく、問題があった際の修正も小さくできます。
一方で、すべての変更を同じ強度で確認しているわけではありません。
特に注意しているのが、データベースの変更など、問題が発生した際に簡単にはロールバックできない変更です。
戻しやすい変更まで過度に慎重に扱うのではなく、失敗したときに戻しにくい変更へ人間の注意を集中させるようにしています。
品質保証にかけるコストも、変更のリスクに応じて変える必要があります。
本番で発生した問題をすぐに検知する
本番リリース後についても、品質保証の範囲だと考えています。
タンプではDatadogを中心に監視とアラートを構築しており、本番で問題が発生した場合には、できるだけ早く検知できるようにしています。
また、アラートが発生した際には、AIが一次調査を行い、エラーが発生している機能やログ、影響範囲などを確認し、障害の深刻度をAIが判定します。
そして、一定以上の深刻度であると判断した場合には、エンジニアへ招集を呼びかけます。
人間がアラートを見てから調査を開始するのではなく、
検知 → 一次調査 → 影響度の判定
までをAIが行うことで、人間は対応が必要な問題にすぐ集中できます。
AIをコード生成だけに使うのではなく、リリース後の品質保証にも組み込むことで、問題が発生してから復旧するまでの時間を短くすることを目指しています。
「不具合を出さない」だけが品質保証ではない
品質保証というと「いかに不具合を本番へ出さないか」という観点で考えることが多くありました。
もちろん、それは今でも重要ですが、AIによって開発量が増えていく中では、それだけでは不十分だと考えています。
不具合の発生確率を下げることに加えて、
-
変更を小さくする
-
影響範囲を小さくする
-
問題をすぐ検知する
-
深刻度をすぐ判断する
-
必要な人をすぐ集める
-
すぐ修正できる状態にする
ところまで含めて設計する必要があります。
つまり、
不具合を出さない能力だけでなく、不具合が出ても大きな事故にしない能力を高める。
これも品質保証の一部です。
人間がすべてを見るのではなく、仕組みで品質を守る
AI前提の開発では、人間がすべてのコードや成果物を細部まで把握していることを、品質保証の前提にはできなくなっていきます。
AIも人間も間違えることを前提として、
-
工程を分ける
-
各工程でAIと人間がレビューする
-
上流から下流へコンテキストをつなぐ
-
機械的に確認できるものは自動化する
-
複数の種類のテストを用意する
-
小さな変更を継続的にリリースする
-
戻しにくい変更を重点的に確認する
-
本番の問題をすぐに検知し、AIで一次調査する
という複数の仕組みを組み合わせています。
一つの防御策だけで事故を防ぐのではなく、それぞれに穴があることを前提として、何層もの仕組みで補い合う。
AIによって開発速度が上がっていくほど、品質を人間の注意力だけに依存させないことが重要になります。
人間がすべてを見るのではなく、仕組み全体で品質を支える。
これが、タンプで現在取り組んでいるAI前提の品質保証です。
仲間を募集しています
タンプでは、プロダクト開発だけでなく、AIを前提とした開発プロセスにも一緒に取り組むエンジニアを募集しています。
興味を持っていただけた方は、ぜひ採用サイトをご覧ください。
採用サイト:https://recruit.tanp.jp/