要件の「認識ズレ」をなくすBrSE×AI｜Adobe Commerce開発の実践記録②

開発の手戻りは、コードを書く段階だけでなく、要件が開発者に伝わる段階でも数多く生まれます。資料に書かれていない前提、読み手によって解釈が分かれる表現。こうした小さなズレは、後工程に進むほど大きな手戻りになります。

本記事は、Adobe Commerce開発の全工程にAIを組み込んだ取り組みを紹介するシリーズの第2回です。今回は、日本側の要件を開発・QAが使える設計・仕様に構造化する「BrSE（ブリッジSE）」の仕事に、AIをどう組み込んだかをご紹介します。

ECサイトの開発では、業務担当者が書いた日本語の要件資料が起点になります。ただし資料には、書き手にとって当たり前の前提が省かれていたり、複数の解釈ができる表現が含まれていたりします。

• 要件の段階で気づけば、確認の連絡1本で済む
• 設計や実装のあとで気づくと、作り直しが発生する
• テストやリリース直前で気づくと、スケジュール全体に影響する

つまり、要件の認識ズレは早く見つけるほど安く直せます。だからこそ、要件を開発・QAに渡す「上流の入口」の精度が、開発全体の品質とコストを左右します。

この「上流の入口」を担うのが、BrSE（ブリッジSE）です。当社の開発体制では、海外拠点の開発チームと日本側の間にBrSEが入り、要件を橋渡ししています。

BrSEの役割は、単なる翻訳ではありません。日本語の一次情報を読み解き、開発者とQA担当者がそのまま作業に使える設計・仕様に翻訳して構造化することです。

• 要件の曖昧な点や抜け漏れを見つけ、業務担当者に確認する
• 業務の流れやデータの構造を、設計書や図に整理する
• 開発とQAが同じ前提で作業できるよう、仕様を一つにまとめる

資料を読み込み、整理し、確認する作業の量が多いこの役割に、AIの力が大きく効きます。

BrSEは、生成AI（Claude）を主に次の5つの場面で使っています。

どの場面でも、AIが担うのは「初稿づくりと論点の洗い出し」です。確定させるのは人であり、AIが示した不明点は推測で埋めず、業務担当者への確認事項として扱います。

確認質問の例

AIが挙げる確認質問は、たとえば次のようなものです（説明のための例です）。

• セール価格と会員価格が重なった場合、どちらを優先しますか
• 在庫が0になった商品は、一覧に「売り切れ」と表示しますか、それとも非表示にしますか
• 注文後のキャンセルは、どの時点まで受け付けますか（出荷前まで、など）

いずれも資料には書かれていないものの、決めておかないと実装やテストで判断が分かれる点です。

こうした質問を着手前に業務担当者へ確認しておくことで、「作ってみたら想定と違った」という手戻りを防いでいます。

設計・仕様の初稿づくりが日単位から時間単位になり、確認のやり取りも減りました。数値はいずれも担当者の実感値です。

注目したいのは、作業時間の短縮だけではない点です。確認の往復や仕様に関する質問が減ったことは、仕様が最初から伝わる形で渡せるようになったことを示しています。上流の設計・仕様の精度が上がるほど、下流の開発・QAでの手戻りは減っていきます。

今後は、BrSEの取り組みをさらに一歩進めます。日本語の詳細設計を起点に、BrSE、開発、QAまでを一気通貫でつなぐ流れを構想しています。

1. 日本語の設計書を「原本」として一元管理し、版を管理する
2. 原本の変更が、開発用・QA用の資料に速やかに反映されるようにする
3. 上流の変更が下流に伝わるまでの時間差をなくす

要件は開発の途中でも変わるものです。変更が起きても、開発とQAが常に最新の仕様で作業できる状態をつくることで、認識ズレによる手戻りをさらに減らしていきます。

コウェルのAI駆動開発の全体像は、サービスページでご紹介しています。サービスページ「AI駆動開発」

開発の品質は、要件がどれだけ正確に開発・QAへ届くかで大きく変わります。BrSEがAIを使って日本側の要件を構造化し、曖昧な点を上流で確認することで、認識ズレによる手戻りを減らすことができます。AIが初稿と論点を出し、人が確認して確定する。この分担が、スピードと正確さを両立させる鍵です。

関連リンク

• サービスページ「AI駆動開発」
• 第1回：AIに「書かせない」AI駆動開発｜Adobe Commerce開発の実践記録①
• 第3回：コードレビューとQAを「人に依存させない」AI活用｜Adobe Commerce開発の実践記録③
• LIXIL様向け Claude Code 集中レクチャー実施レポート（お客様社内でのAI活用・内製化を支援した事例）