何を確かめれば合格か。実装前に人が決める理由

AIが実装もテストも書くと、テストが実装の写し鏡になり、検証として成立しません。全部通っても、それは「頼んだとおりに動く」ことの証明にはなりません。何を確かめれば合格かは、実装が始まる前に人が決めます。中身は三つあります。受け入れ条件を発注側の言葉で先に文書にすること、テストの方針を決めること、AIが一日に出す量のうち、どこを人が読むかを決めることです。誰が引き受けるのかで挙げた三つの決めごとの、三つ目です。

テストが実装の写し鏡になる、とは

人が実装し、人がテストを書くときは、二人の目が入ります。実装した人の思い込みを、テストを書いた人が気づくことがあります。役割が分かれているからこそ、片方の見落としをもう片方が拾えます。AIが実装とテストの両方を書くと、この二人目の目がありません。実装のとおりに動くことを、実装のとおりに書いたテストが確認するだけになります。

結果は、テストが全部通ることです。しかし、それは「実装した通りに動く」ことしか確認していません。「頼んだ通りに動く」かどうかは、確認されていません。この差が、本番で壊れる原因になります。

この二つは別のことです。テストが通ったことを、出してよい根拠にしないことが最初の一歩です。ソフトウェア開発では、実装した人とは別の立場が確認を担う考え方が以前からあります。AIが実装とテストの両方を書く状況は、この役割分担を一人分に圧縮してしまいます。だからこそ、確かめる側の基準を、実装が始まる前に人の手で用意しておく必要があります。

実装前に決める、合格の物差し

実装が始まってから合格条件を決めると、実装に合わせて基準が動きます。実装前に、次の三つを文書にします。

受け入れ条件

何ができていれば合格かを、実装する側の言葉ではなく、発注側の言葉で先に書きます。実装が終わってから書くと、実装に合わせた基準になり、後出しの物差しになります。

テスト方針

どこまでをテストで確認し、どこからを人が確認するかを分けます。AIの実装範囲とテストの範囲が同じままだと、テストの網が実装の形をなぞるだけになり、抜けが見えません。

レビュー範囲

AIが出したコードのうち、人が必ず読む部分を先に決めます。範囲を決めずに全部読もうとすると、量が多く、実際にはどこも深く読まれません。

三つとも、実装が始まる前に決まっていることが条件です。実装が進んでから決めると、後出しの基準になります。

レビュー範囲は、なぜ絞る必要があるか

AIが一日に出すコードの量は、人が一日に全部読める量を超えます。全部読むことを前提にすると、レビューが形だけになり、結局どこも深く読まれません。人の集中力には限りがあり、量が増えるほど一件あたりの読み込みは浅くなります。

絞る基準は、影響の大きさです。外部に公開される入出力、金額や個人情報を扱う処理、他のシステムと連携する部分は必ず読みます。表示だけが変わる部分や、内部でしか使わない補助的な処理は、テストの結果で判断してよい範囲に回します。

この線引きを実装前に決めておくと、レビューする人が「今日はどこを読むか」で迷わなくなります。迷う時間が減った分だけ、影響の大きい部分に時間を割けます。

受け入れ条件は、仕様の割り方と地続きになっている

受け入れ条件を発注側の言葉で書くには、そもそも仕様がAIに渡せる粒度まで割れていることが前提になります。仕様が大きな塊のままだと、何ができていれば合格かを一文で書けません。人向けの要件定義を、AIに渡せる粒度まで割る方法で書いた分割の単位が、ここでの受け入れ条件の粒度と一致します。

同様に、AIにどこまで渡してよいかという線引きが決まっていないと、テスト方針の中で「AIが生成した部分」と「人が書いた部分」の境界も曖昧になります。この案件でAIに何を渡してよいかで決めた範囲が、レビュー範囲の設計にも影響します。

テスト方針を分けるときの目安

どこまでをテストで確認し、どこからを人が確認するかを分けるとき、目安になるのは「入力の組み合わせが有限で、機械的に判定できるか」です。入力の形式が決まっていて、正しいか誤りかを機械的に判定できる部分は、テストで確認する範囲に向いています。反対に、複数の選択肢のうちどれが利用者にとって望ましいかという、判断が分かれる部分は、人が確認する範囲に残します。

この分け方をしておくと、AIが実装した範囲のうち、どこがテストで守られ、どこが人の目でしか守られないかが見えるようになります。人が確認する範囲が広いほど、レビューにかける時間の見積もりも立てやすくなります。

開発を頼まなくても、ここだけ相談できる

受け入れ条件の書き方、テスト方針の分け方、レビュー範囲の線引きだけでも相談できます。実装を当社が担当しない案件でも同じです。内製チームがすでに動いている場合は、途中から合流して合格の物差しだけを一緒に固めることもできます。考え方はAboutに、相談はお問い合わせに相談の窓口を置いています。

よくある質問

テストが全部通っているのに、なぜ合格と言えないのですか

AIが実装とテストの両方を書くと、テストが実装の写し鏡になるためです。実装のとおりに動くことは確認できても、頼んだとおりに動くことは確認できていません。

受け入れ条件は誰が書くのですか

発注側です。実装する側の言葉ではなく、何ができていれば合格かを発注側の言葉で書きます。実装前に文書にします。

受け入れ条件と、いわゆる単体テスト・結合テストはどう関係しますか

単体テストや結合テストは、実装が仕様のとおりに動くかを内側から確認するものです。受け入れ条件は、発注側が外側から見て合格と判断するための基準です。両方が必要で、片方だけでは足りません。

テスト方針とは、具体的に何を決めるのですか

どこまでをテストで確認し、どこからを人が目で確認するかの分担です。AIの実装範囲とテストの範囲が同じにならないようにします。

レビュー範囲を絞ってよいのですか。全部読むべきではないですか

全部読むことを前提にすると、量が多く、実際にはどこも深く読まれません。影響の大きい部分（外部公開、金額、個人情報、他システム連携）を先に決めて、そこは必ず読みます。

この合格の物差しは、実装が始まってからでも決められますか

決められますが、実装に合わせた後出しの基準になります。実装前に決めることで、基準が実装から独立します。

雛形やチェックリストは公開していますか

この記事では出していません。何が決まっていないと止まるかまでを書いています。案件ごとに書き起こします。

AIが書いたコードのレビューは、エンジニアが読む観点と同じですか

違います。エンジニアの読み方は実装の正しさを見ますが、ここで言うレビュー範囲は、発注側が出してよいと判断するための範囲です。

開発を頼まなくても、この部分だけ相談できますか

できます。受け入れ条件、テスト方針、レビュー範囲の設計だけをお受けしています。

受け入れ条件とテスト方針は、同時に決める必要がありますか

同時に決めることを勧めます。受け入れ条件が先に決まっていないと、テスト方針を立てる根拠がありません。

レビュー範囲を決めても、AIが出したコード全体の品質は保証されますか

保証にはなりません。レビュー範囲は、限られた時間の中で優先して確認する場所を決める考え方です。範囲外の部分はテストの結果で判断します。