CASE SD-05

基幹請求システムと Salesforce をつなぐデータ連携基盤の刷新にあたり、仕様の一次情報が基本設計書・詳細設計書・現行の実ファイル・各種定義書に分散していました。記載どおりに実装すると現行と食い違う箇所が複数あり、どれが正なのかを一つずつ突き合わせて確定させる必要がありました。

連携項目は多数にわたり、Salesforce 側のオブジェクト定義もプロジェクト進行と並行して固まっていく状況でした。確認すべき論点が多いままでは、お客様側の確認負荷が開発の律速になります。

またバッチ連携基盤は「異常が起きたときに気づけること」が要件そのものです。取り込み漏れやサイレントな失敗が請求データの欠損につながるため、テストが通ることではなく「壊したときにテストが落ちること」を確かめられる品質担保の仕組みが求められました。

要件定義では、受領資料と現行の実ファイルを AI エージェントに横断的に読み込ませ、記載の矛盾・欠落・参照切れを機械的に洗い出しました。抽出結果は項目対比表と課題表に集約し、お客様への確認は「当方の理解はこうです、相違があればご指摘ください」という既定確定の形式に統一。回答をお待ちする論点を絞り込み、確認負荷を下げながら仕様を確定させていきました。決着した論点は課題一覧から「決定の記録」へ移し、いつ・誰が・何を決めたかを追える状態を維持しています。

開発は、設計側が作成した指示書をもとに開発機のコーディングエージェント（Claude Code）が実装し、提出された報告書を設計側が独立環境で検証する、という反復サイクルで進めました。1 サイクルを 1 フェーズとして番号管理し、フェーズを重ねながら機能と品質を積み上げています。

検証では、報告書の数値をクリーンな環境で再現できるかを毎回確認し、是正箇所をあえて元に戻した「逆パッチ」を注入してテストが落ちることを実測しました。あわせてミューテーションテスト（コードを機械的に変異させ、テストが検知できるかを測る手法）と、計測器そのものを検証する陽性対照を組み合わせ、検知できていない箇所が残っていないかを検算しています。インフラは Bicep でコード化し、検証環境は常設せず必要なときに立ち上げる方針としました。