AIの使い方も、出てくる品質も、「人によって違う」をなくす。
第2回は、AIへのルール、テスト、セキュリティを仕組みとして標準化した話と、そこから見えてきたオフショア開発との相性についてお伝えします。
- AIへのルールと開発の進め方を、テンプレートで標準化する方法
- テストもAIに書かせ、書き漏れを自動で見つける品質の仕組み
- 人の注意に頼らない、6つのセキュリティ対策
- 設計は日本、実装はAIとオフショアで進める体制
「人によって違う」が、いちばんのボトルネック
第1回では、AIが読める場所にプロジェクトの情報を集める「準備」についてお話ししました。情報がそろうと、次に見えてくる課題があります。AIの使い方が、人によってバラバラなことです。
ある人はAIに細かく指示を出し、ある人はほぼ任せきりにする。テストを書かせる人もいれば、書かせない人もいる。その結果、同じチームの中でも成果物の品質がそろわず、レビューする側の負担が増えていきました。
AIで開発のスピードが上がるほど、このばらつきは大きな問題になります。そこで私たちは、AIへのルール、品質の確かめ方、安全の守り方を「仕組み」として標準化することにしました。
仕組み① AIへのルールと進め方をテンプレートで標準化
まず取り組んだのが、AIへのルールの共通化です。全社共通のテンプレートを用意し、新しいプロジェクトでもすぐに同じ前提でAIを使い始められるようにしました。
Issue（タスク）を起点にした開発の流れ
進め方もそろえました。私たちの開発は、すべてIssue（タスク）から始まります。AIと人の役割分担は次のとおりです。
- 1調査するAI
- 2Issueを作成するAI
- 3内容をレビューする（承認されるまで実装しない）人
- 4実装する（テストも一緒に書く）AI
- 5動作を確認する人
- 6変更をレビューし、承認して取り込む人
ポイントは3番目です。人が内容を承認するまで、AIは実装に入りません。「何を作るか」を人が確かめてから手を動かすので、方向違いの実装に時間を使うことがなくなりました。
仕組み② テストもAIに書かせ、書き漏れは自動で見つける
AIで実装が速くなっても、品質が落ちては意味がありません。私たちは、性質の違う3種類のテストを使い分けています。
| テストの種類 | 確かめること | 見つかる不具合の例 |
|---|---|---|
| 単体テスト | 1つの関数や部品の動き | 計算や条件分岐の誤り |
| 結合テスト | 実際に起動したサーバーへのやり取り | 認証チェックの順番が違う、つなぎ込みの漏れ |
| E2Eテスト | 実際のブラウザでの操作 | ボタンを押しても画面が切り替わらない |
実際、単体テストはすべて通っているのに、画面を操作すると期待どおりに動かない、という不具合を画面操作のテストで見つけたことが何度もあります。1種類のテストだけでは、守りきれないのです。
「テストを書く」をAIのルールにする
テストを後から人が頑張って書き足す運用は、長続きしません。そこで、AIへのルールに「ソースコードを変えたら、テストも追加・修正・削除すること」と明記しました。AIを通した開発では、実装と一緒にテストが自然にそろいます。
一方で、人が直接コードを書き換えることもあります。そのときに備えて、「コードは変わったのにテストが変わっていない」変更を自動で検知して知らせるチェックも入れています。止めるのではなく気づきを与える仕組みで、AI経由でも人の手でも、同じ規律が保たれるようにしています。
※ 画面操作や結合のテストは、本番環境では実行しないことも明文化しています。テスト用のデータが本番に残ったり、実際の通知が送られたりする事故を防ぐためです。
仕組み③ 安全は、人の注意ではなく仕組みで守る
AIで開発量が増えるほど、目視のチェックだけでは守りきれなくなります。私たちは次の6つを、仕組みとして組み込んでいます。
秘密情報の混入を、登録時に止める
APIキーやカード番号などの形式を、コードを登録する瞬間に自動で検査。見つかれば登録を拒否し、チャットに通知します。
公開設定を、毎日自動でチェック
1日2回、すべてのリポジトリの公開設定を確認し、誤って公開されていればすぐに知らせます。
AIに読ませないファイルを決める
環境設定やログ、認証情報など、AIが読む必要のないファイルは、設定で読めないようにしています。
個人情報は、AIに渡す前に伏せる
AIエージェントがAIモデルへ送る内容から、個人情報を自動で伏字にしてから送っています。
取り込みは、必ず人が承認する
AIが作った変更が、人の確認なしに本番に入ることはありません。最後の判断は人が持ちます。
アカウントを一元管理する
認証の仕組みを1つにまとめ、人だけでなくAIエージェントのアカウントも同じ枠組みで管理しています。
体制 AIが実装を担うから、オフショアとの相性が良い
こうした仕組みを整えて見えてきたのが、AI開発とオフショア開発の相性の良さです。私たちのチームには、インドネシアのメンバーも多く参加しています。
- 1設計：要件定義と設計を行い、設計リポジトリに残す日本
- 2共通の前提：設計書・AIへのルール・テストをリポジトリで共有する全員
- 3実装：AIが同じ前提で実装し、テストも作るインドネシア × AI
- 4確認と承認：自動チェックの結果を確かめ、承認して取り込む日本
これまでのオフショア開発
- 仕様の読み違いや言葉の壁で手戻りが起きる
- 品質が担当者のスキルに左右される
- 日本側のレビューの負担が大きい
AI × オフショア開発
- AIが設計とルールを読み、同じ前提で実装する
- テストと自動チェックで品質をそろえる
- 設計書は母語で読め、やり取りはAI翻訳付きのチャットで
オフショア開発で長く課題とされてきた品質のばらつきは、実装の多くをAIが担い、テストと自動チェックで確かめることで、かなり小さくなりました。第1回でご紹介した3つの言語に切り替えられる設計書も、この体制を支えています。
設計という「何を作るか」を決める部分に日本のメンバーが集中し、実装はAIと海外のメンバーで速く進める。AIを前提にすると、こうした役割分担が自然に成り立ちます。
やってみて分かったこと
ルールは「書いて共有」して初めて効く
口頭やチャットで伝えたルールは、人によって伝わり方が変わります。ファイルにして全員が同じものを使うことが標準化の第一歩でした。
止めるより、気づかせる
すべてを禁止すると開発が止まります。危険なものだけを確実に止め、それ以外は「気づき」を返す仕組みのほうが定着しました。
人は「最初」と「最後」を持つ
何を作るかの承認と、取り込む前の承認。この2点を人が押さえておけば、その間はAIに大きく任せられます。
チェックリスト：まずはここから
- AIへのルールを1つのファイルにまとめ、チームで共有する
人によって指示が違う状態をなくすのが最初の一歩です。 - 「承認されるまで実装しない」を進め方に入れる
AIが作業を始める前に、人が内容を確かめるタイミングを1つ決めます。 - 「コードを変えたらテストも直す」をAIのルールに書く
テストが後回しになるのを、AIの側で防げます。 - 秘密情報の混入チェックを自動化する
登録の時点で止める仕組みは、一度入れればずっと働き続けます。
関連する記事
シリーズの全体像は第0回、情報をAIが読める形に整える話は第1回でご紹介しています。AIを使った開発ルールの整備や、オフショアを組み合わせた開発体制のご相談もお気軽にどうぞ。
シリーズ第1回を読む次回は「第3回 自動化：Issueを起点にAIエージェントが動く」。AIとの会話からそのままタスクを起票し、エージェントが実装から変更の提出までを担う仕組みをご紹介します。
コメント