AIドリブンの開発プロセス

最初の草案をエージェントが書くとき、BrSEと開発者とQAはどう連携するのか

概要

• 対象の役割: BrSE、QA、開発、デザイン、翻訳
• 形式: 役割ごとに1プラグイン、個別に導入
• 状況: QAは日常運用中、他の役割は展開中

1. 機械可読な仕様
2. 一度だけ正規化
3. 先にテストケース
4. ケースに沿って実装
5. 不具合が輪を閉じる

漏れた不具合は新しいテストケースになり、輪は工程3へ戻ります。

以前の課題

旧プロセスは機能ごとに数日かかっていた

ベンダー資料ではなく、自分たちで計測した2つの数字です。

• QAは1機能の結合テストケース作成に約2日
• 開発者は手作業の単体テスト実施にさらに約1日

テストの着手が常に遅すぎた

テストケースがコードの後に来るため、コードを形づくれません。

• 結合テストケースが存在しないうちに開発者が機能を作り終えていた
• 開発者が単独で生成したケースは薄く、不具合はQA工程で表面化し、起票と対応の手間が増えていた

全員が別の資料を見ていた

最も手戻りを生む、静かな失敗です。

• 開発者とQAが異なるバージョンの基本設計を使うことが常態化していた
• 各自がAIに独自の要約を作らせるため、1行も書かないうちに認識がずれていた

ステップ

人だけでなく機械のために仕様を書く

資料は後続すべての入力なので、エージェントが読める形である必要があります。

• 新規案件は基本設計をMarkdownで書き、gitに置いて履歴を明示する
• 仕様変更は自由記述ではなく決まったチケット様式に従う

仕様の正規化を一度だけ、中央で行う

正規化された版を一度作り、全役割がそれを使います。

• 着手前に社内規約への適合を確認する
• 基準を満たさない資料はコードに流さず作成者へ差し戻す

コードより先にテストケースを作る

従来の順序を逆にする工程で、最も効く部分です。

• QAが正規化された仕様から結合テストケースを生成し、自ら確認する
• 確認済みのケースを共有レジストリに取り込み、その機能の基準とする
• 以後は新規開発も仕様変更も不具合修正も、まずレジストリを更新する

解釈ではなくテストケースに対して実装する

開発者は仕様を読み直すのではなく、ケースを直接取得します。

• MCPサーバーがレジストリを公開し、エージェントは一度の往復でケースを取得する
• コードは開発者の解釈ではなくレジストリの全ケースを満たす必要がある
• 引き渡し前にE2Eテストを生成して実行し、除外したケースは理由を明記する

不具合が漏れたら輪を閉じる

不具合は欠陥であると同時に、欠けていたテストケースとして扱います。

• 生成された網羅率は品質の証明ではないため、QAは手動テストを続ける
• ケース不足で漏れた場合は、そのケースをレジストリに追加する
• 修正時に自動テストを作り直し、仕様、ケース、コード、テストが結び付いた状態を保つ

原則

操作ではなく指示する

人は成果物を作る側から、見極める側に移ります。

• 仕様、デザイン、コード、テストケース、レビューの草案はエージェントが担う
• 人の仕事は結果を判断し、次回のためにエージェントを改善することになる

すべてをエージェント向けに最適化する

全工程にエージェントがいるなら、形式もそれに合わせます。

• 表計算よりMarkdownとJSON
• 履歴も入力の一部なので、共有ドライブよりgit
• エージェントに探させるのではなく、専用のMCPサーバーを用意する

制約

• 相応の予算が必要です。実務上は一人一つの有料エージェント契約で、費用を出せないチームには適用できません。
• プロセスと納品形式を自分で選べることが前提です。顧客が双方を指定する場合、ここの大半は適用できません。
• 特定ベンダーの環境に依存しています。別のエージェント基盤で標準化済みのチームは作り直しが必要です。
• エージェントは自分の出力を守ろうとします。自己点検させると、欠陥を見つけるより正当化することが多くなります。
• 生成結果は実行のたびに揺れます。同じ仕様でも別のケース群が出るため、マージ前の人手レビューが必須です。

なぜ文書にしたのか

多くのチームでAIの利用は個人的なものにとどまっています。ある開発者は良い指示 文を持ち、あるQAは別のものを持ち、誰かにとって有効だったものが次の案件まで残 りません。出力の質は、その時キーボードの前にいる人によって上下します。

このページのプロセスは、その問題のために存在します。個人の指示の巧拙の話では なく、入力と形式と工程の順序を固定することで、誰が実行してもチームとして一貫 した成果物が出るようにする話です。

実際に変わったこと

最も重要な変更は順序です。旧来はコードが先にあり、テストケースが後からそれを 記述していました。今はテストケースが先にあり、コードはそれを満たすように作ら れます。プロセスの他の要素は、その逆転を可能にするために存在します。エージェ ントが読める仕様、正規化された唯一の版、そして開発者のエージェントが人を介さ ず到達できるレジストリです。

真似する前に伝えたいこと

道具ではなくレジストリから始めてください。プラグインは置き換えが利きます。価 値を運んでいるのは、すべての役割が読み書きする合意されたテストケース群がある という一点です。それだけでも効果の大半は得られますし、それが無ければどんな道 具でも効果は出ません。

よくある質問

QAの仕事は不要になりますか。

いいえ。前工程に移るだけです。QAは開発が満たすべき受け入れ基準を定義し、その後も手動でテストします。なくなるのは2日分の入力作業であって、判断ではありません。

エージェントがテストケースを作り話するのはどう防ぎますか。

完全には防げません。だからこそ人のレビューを経ないものは共有レジストリに入らず、レジストリはgit上でプルリクエスト経由にしています。

実際の効果は何でしたか。

最大の効果は速度ではなく、テストがコーディングの前に来ることです。数値化できるのは、旧プロセスで機能ごとに必要だったテストケース作成2日と手動単体テスト1日の部分です。

私の案件にも適用できますか。

三点次第です。チームにエージェント予算があるか、プロセスを自分で決められるか、納品形式を自分で選べるか。いずれかが他者に固定されている場合、全体ではなく一部の適用になります。