AI時代こそ、ブリッジSE（BrSE）の真価。翻訳から設計・合意形成へ

はじめに

新しい世代の大規模言語モデル（LLM）により、ソフトウェア開発ライフサイクル（SDLC）の多くの工程が変わりつつあります。AIは基本設計書の読み込み、ボイラープレートコードの生成、単体テストの下書きを、以前よりはるかに短い時間でこなせるようになりました。

これは、ブリッジSE（BrSE）の役割に大きな問いを投げかけています。仕様書の翻訳や基本的なコードレビューを主な業務とする場合、その多くはすでにAIで対応できるようになっているためです。

そこでARIS Vietnamが選んだ方向性は「シフトレフト」です。BrSEが上流工程に軸足を移し、業務分析（Business Analysis）とシステムアーキテクチャ（System Architecture）に注力します。これは、ARIS VietnamがBrSEチームに掲げている考え方でもあります。

「AIを活かす。人が判断し、合意をつくる。」

1. AI時代のBrSEに求められる4つの力

情報を中継する役割にとどまらず、これからのBrSEはソリューションアーキテクトに近い役割を担います。重点は次の4つです。

本質を見抜く：要望の背景と業務課題を捉える 資料を機械的に翻訳するのではなく、お客様の業務ロジックを技術的なロジックに置き換えます。あわせて、可用性・拡張性・セキュリティなどの非機能要件（NFR）を早い段階で明確にします。

解決策を描く：技術・コスト・リスクを見極める モノリスとマイクロサービス、RESTとgRPCといった技術選択のトレードオフを比較します。AWSやAzureのインフラコストも試算し、仕様に従うだけでなく、お客様に代替案をご提案します。

合意をつくる：日越の認識を揃え、判断を前へ API仕様を確定し、データフローを設計し、ボトルネックを解消します。ベトナムの開発チームと日本側のプロダクトオーナーが、技術面で同じ理解を持てる状態をつくります。

信頼を築く：対話と責任でプロジェクトを導く ダウンタイムを抑え、障害に強いシステムを設計します。技術的な判断については、お客様のCTO・CIOに対して自ら説明責任を果たします。

2. BrSEの役割の変化

3. 事例：WMSプロジェクトを支えたアーキテクチャ思考

日本のEC向けWMS（倉庫管理システム）案件で、シニアBrSE／ソリューションアーキテクトを務めるVo Ngoc Hoang Namに話を聞きました。お客様の情報は守秘義務に基づき伏せています。

――EC向けWMSでは、非常に高い同時処理性能が求められます。BrSEの技術的な考え方は、プロジェクトにどう影響しますか。

Nam： 取引量が非常に多いシステムでは、仕様書を受け取って人手だけで回すやり方では対応できません。私はAIを使って日本語の業務資料を素早く読み込み、そのぶんの時間をアーキテクチャの検討に充てています。お客様は業務を深く理解されていますが、システム負荷に関するリスクは早い段階では見えにくいことがあります。開発者が実装を始める前に単一障害点（SPOF）を洗い出し、対処しておくことが私の役割です。

――お客様と一緒にアーキテクチャを見直した具体例を教えてください。

Nam： あるとき、お客様からフラッシュセール機能の仕様をいただきました。当初の処理の流れは「ユーザーが注文 → APIを呼び出し → マスターDB上の在庫レコードをロック → 在庫をリアルタイムで更新」というものでした。

セール時には非常に多くのユーザーが同時にアクセスすると想定されており、この流れではデータベースでロック競合、デッドロック、タイムアウトの起きるリスクが高いと判断しました。そこで、この方式は避けるべきだとお伝えし、非同期処理を前提に設計し直しました。

1. フラッシュセール対象商品の在庫データをRedisに載せ、インメモリで低レイテンシに処理する。
2. 注文時は、Redis上の在庫をアトミックな操作（DECRやLuaスクリプトなど）で減算し、在庫以上の販売（オーバーセル）を防ぐ。
3. その後、イベントをメッセージキュー（RabbitMQ/Kafka）に送る。ワーカーがイベントを処理してマスターDBへ順次反映し、冪等な処理で二重書き込みを防ぐ。
4. 定期的な突合ジョブで、Redisとマスターデータベースの在庫を照合する。

日本側のCTOとの打ち合わせでは、方式ごとのTPS（1秒あたりのトランザクション数）とAWSコストの試算をお見せしました。新しい方式であればフラッシュセールの負荷に耐えられ、オーバーセルを防ぎ、ピークのたびにインフラコストが膨らむこともありません。お客様にはこの方式への切り替えをご承認いただきました。技術の知識がプロジェクト全体を守った場面でした。

――いまのBrSEに向けて、アドバイスをお願いします。

Nam： AIを翻訳ツールとしてだけ使うのは、もったいない使い方です。ボイラープレートコードや資料の下書きのような繰り返しの作業はAIに任せ、自分は全体のアーキテクチャを設計する立場へとステップアップしてほしいです。マスターDBに障害が起きたとき、AIは責任を負えませんし、お客様との交渉を代わりに担うこともできません。BrSEの価値は、システム全体を考える力とオーナーシップにあります。

4. ARIS Vietnamでの取り組み

「AIが支援し、人が判断する」という考え方は、ARIS Vietnamが発表したHybrid Delivery Modelの原則でもあります。AIの活用範囲はプロジェクトごとにお客様と合意し、メインブランチへの変更はすべてエンジニアがレビュー・承認します。

BrSEチームにとっては、AIで短縮できた時間を、AIには代われない仕事に充てることを意味します。要件の明確化、アーキテクチャ設計、そしてベトナムのチームと日本のお客様との合意形成です。ARIS VietnamのPM／BrSE体制は、ベトナムオフショア開発のご案内でご紹介しています。プロジェクトでの認識ズレを防ぐ方法は、オフショア開発のコミュニケーション課題に関する記事をご覧ください。

翻訳の先へ。事業を共につくるパートナーへ。

これからのBrSEは、コードを書く時間が減り、設計に向き合う時間が増え、より大きな価値を生み出します。