14:15 - 14:59

検証を開発の内側のループに組み込む

前の段階では、Minionが複数のリポジトリに変更を作り、ドラフトPR（レビュー用ですが、まだマージの準備ができていないPR）を作成しました。この章では、その変更を共有CI（継続的インテグレーション）の前に、開発者の近くで検証します。

「内側」と「外側」のループ

ここでいう内側のループ（inner loop）は、開発環境の中で早く実行できる確認の流れです。「内側」は、確認が弱いという意味ではありません。変更を作った場所の近くで、より早い段階に実行するという意味です。

検証を後ろに集めると、問題が見つかるまでに時間がかかります。さらに、共有CIの計算資源も使います。Uberの説明では、コードの静的解析、シミュレーターを使った画面とFigma（画面設計を作るツール）の比較、フロントエンドとバックエンドの連携確認を、内側のループへ移します。

図：コード、画面、連携の確認を内側に置き、その後にCIとエージェントによるレビューを残した流れです。動画の14分18秒の図を見る

この図が示す重要な点は、検証を一つの場所へ移して終わりにしないことです。内側では、修正をすぐに返せる確認を行います。その後の外側には、共有CIやレビューがあります。したがって、内側の確認は外側の確認を置き換えるのではなく、問題を早く発見して修正するための補助になります。

三つの確認を早い段階で行う

1. 静的解析

静的解析（static analysis）は、プログラムを完全に実行しなくても、コードの規則違反などを調べる方法です。たとえば、エージェントが作った変更に、リポジトリのコード規則に反する書き方があるとします。開発Pod（エージェントが作業する環境）の中でそれを検出できれば、共有CIを待たずに修正できます。

これは、検証を省略する例ではありません。同じ種類の確認を、修正の近くへ移す例です。発見から修正までの時間が短くなるため、次の確認へ進む前に問題を小さくできます。外側のCIで行う確認が不要になるわけではありません。

2. Figmaとの画面比較

次に、生成された画面を設計と比べます。今回の例では、スタジアムでの乗車場所を選ぶ画面を、Figmaの仕様と照合します。シミュレーターまたはエミュレーターで画面を実際に表示し、その結果を設計と比較することで、見た目の違いを早く見つけられます。

補足： Figmaの画像は、もともとは設計を共有するための成果物です。しかし、画面を表示して比較する仕組みと組み合わせれば、設計を検証可能な基準として使えます。これは、設計資料をそのまま本番の品質保証にするという意味ではありません。比較で見つかった違いを、開発中に確認するという意味です。

3. フロントエンドとバックエンドの連携

画面だけが正しく見えても、機能全体が正しく動くとは限りません。モバイルのフロントエンド（利用者が操作する部分）は、バックエンド（サービスやデータを提供する部分）に依存するからです。

そのため、デモではステージング環境（本番の前に連携を確認する環境）のバックエンドを使って、モバイルクライアントとの流れを確認します。画面の表示、リクエスト、サービスからの応答など、サービスの境界をまたぐ動作を早い段階で調べます。

図：モバイルクライアントを、ステージング環境のバックエンドサービスに対して確認しています。動画の14分48秒のチェックを見る

例：モバイル画面のコードだけを調べて問題がなくても、バックエンドの応答形式が想定と違えば、乗車場所を選ぶ流れは失敗します。画面単体の確認と、サービスをつないだ確認は別です。後者を共有CIの前に行えば、連携の問題を早く修正できます。

内側で速く、外側で広く確認する

この考え方の目的は、検証を一か所に集中させることではありません。内側のループでは、コード、画面、サービス連携について、開発者が短い時間で結果を受け取り、修正を繰り返します。これにより、共有CIへ送る変更をより整った状態にできます。

一方、外側のループには、後から行うCIとレビューが残ります。共有環境での確認や人による判断には、内側だけでは得られない証拠があります。ですから、速い内側の確認と、より広い外側の確認を組み合わせることが大切です。

Uberのこの説明から読み取れる中心的な考えは、エージェントがコードを生成できるかどうかだけではありません。生成後の証拠を、開発の流れの中で早く作れるかどうかも重要です。内側のループを厚くすると、問題の発見と修正を前倒しできます。それでも、最終的なCIとレビューを残すことで、早さと厳密さを両立します。