情報システム部門・IT部門が強くなるためのプラットフォーム

攻めの情シス研究所

情シスにノウハウを。
情シスが会社を強くします。

他システム連携テスト(外部連携テスト)は誰が行うべきか?

2024

12/18

他システム連携テスト(外部連携テスト)は誰が行うべきか?

即答

「他システム連携テストは、誰がやるべきですか?」

あるプロジェクトで、情シスメンバーから質問を受けます。

そこで、私は即答しました。

「情シスです!」

原則として、受入テストは「ユーザー」主体で行うべきです。

ただし、他システム連携テスト(外部連携テスト)だけは違います。

ここは、例外的に「情シス」なのです。

すると、質問してきた方も「ですよね〜」と納得していました。

なぜ、他システム連携テストは、ユーザーではなく情シスがやるのでしょうか?

情シスがやるべき理由

理由は、大きく2つあります。

① ユーザーでは環境を準備できないから

他システム連携テストを行うためには、「テスト環境」が必要です。

テスト用の連携フォルダを作成したり、相手先のテスト環境と接続したり、テスト用にバッチスケジュールを設定したり、諸々の環境準備をしないといけません。

これらは、ユーザーにできるのでしょうか?

おそらく、任せたところで1mmも進まないでしょう。

これは、完全に情シスの領域です。情シスで環境を準備し、テストするのが最も早いのです。
 

② 業務知識よりも現行仕様が重要だから

他システム連携テストでは「業務知識」があまり必要とされません。むしろ、現行のシステム連携の「仕様理解」を必要とします。

連携方式は自動バッチなのか手動なのか、ファイル連携なのかAPI接続なのか、Viewを使って抽出しているのか、ファイルはどこに配置するのか、ファイル形式はCSVか、文字コードは何か、エラーチェックは…等々。

このように、他システム連携というのは、極めて「システム寄り」のテストなのです。

これらの仕様を理解するには、現行の仕様書を読み解かないといけません。

仕様書を見て、処理条件や各項目のマッピングを理解した上で、テストケースをイメージしていきます。

システム仕様書は、ユーザーには難解です。普段から見慣れている情シスの方が、スムーズにテストを実行できます。

つまり、情シスがテストした方が圧倒的に早いのです。

業務観点での確認は?

ちなみに、以下の疑問があるかもしれません。

「他システム連携における業務観点でのテストが必要なのでは?」

これは確かに必要です。

しかし、それは「どこでやるか」という論点にすぎません。「要求機能テスト」や「シナリオテスト」など、他のユーザー主体のテストに組み込めばよい話です。

システム環境や仕様書に不慣れなユーザーに任せるのではなく、情シスがさっさとテストしてしまう。バグがあれば早めにベンダーに連携して、後続のテスト影響を最小化する。

これが、他システム連携テストの考え方です。

他システム連携テストのポイント

情シスがテストをする上で、ポイントは以下の通り。

① 疎通確認として割り切る

前提として「他システム連携機能」は、ベンダーがしっかりテストを行っています。そのため、ベンダーと同じ確認をするのはもったいないです。

では、ベンダーが確認できないことは何でしょうか?

それは、他システムを「直接操作」し、そこから出力された「本番ファイル」を用いてテストを行うことです。

そこでエラーが出ずに、無事に連携できれば「だいたいOK」なのです。

「疎通確認」として、大雑把に確認するのみ。

細かいテストはベンダーがやっています。データ項目マッピングやエラーチェック等の「網羅的なテスト」はベンダーの領域。それらは、ベンダーから「テスト結果」を受領し、確認すればいいだけです。

もっといえば、テスト結果は受領するだけでいいのかもしれません。テスト結果を提出している時点で、ベンダー側の適切なプロセスが行われた証明でもあるからです。サンプリングでいくつか確認すれば十分でしょう。
 

② 本番データ全件でテストする

本番データは「トラブルメーカー」といえます。ベンダー想定外の「イレギュラー」が多く含まれているからです。

例えば、設計書に定義されていないコード値が設定されていたり、日付の型が仕様と異なったりします。外字が文字化けしたり、桁数オーバーの文字列でエラーになったりもします。初期値(Null or スペース or ゼロ)の認識相違で誤動作が発生することは、日常茶飯事です。

このように多様な異常値を効率的に検出するには、どうしたらいいのでしょうか?

「全件」です。本番データ全件で動かしてみることです。

そこでエラーが出なければOK、エラーが出たら該当箇所を調査する。これが最短なのです。

その結果、対応策は2つのどちらかとなります。
・システム連携仕様を変更する
・他システム側のイレギュラーデータを修正する
 

③ アウトプット側を重点的に確認する

例えば、販売管理システムの場合、受注システムからデータを取り込みます。システム的には「インプット」です。

一方で、会計システムに仕訳データを送り出します。システム的には「アウトプット」です。

このインプットとアウトプットのどちらを重点的に確認した方がいいでしょうか?

それは「アウトプット」です。

なぜなら、ベンダーは連携先の会計システムを直接動かすことができないからです。

そのため、ユーザー側で、実際に会計システムを動かしてみて、出力ファイルがエラーなく取り込めるかどうかを確認します。

私の経験上、問題が発生しやすいのはアウトプット側です。

ベンダーに足りない部分だけをテストする

「集中的にテストし、終わらせました!」

冒頭の情シスメンバーは、他システム連携を集中的に実施しました。

なんと、1週間で5つのインタフェースのテストをすべて完了させます。

それでいいと思います。

受入テストフェーズは、ユーザーも情シスも忙殺されています。

他システム連携テストで、工数をとられるわけにはいかないのです。

さっさと終わらせて、情シスはユーザーフォローやベンダー調整、プロジェクト管理等にパワーを割くべきです。

そのためには「ベンダーに足りない部分だけをテストする」という発想が重要になってきます。

貴社のIT部門・情報システム部門は、他システム連携テストを速やかに終わらせていますでしょうか?

(↓他システム連携テスト項目書のサンプルはこちら↓)
他システム連携テスト(外部連携テスト)項目書の作り方(サンプル画像付き)

関連コラム

御社のシステム発注は、なぜ「ベンダー選び」で失敗するのか

情シスコンサルタント
田村 昇平

情シス(IT部門、情報システム部門)を支援するコンサルタント。

支援した情シスは20社以上、プロジェクト数は60以上に及ぶ。ITベンダー側で10年、ユーザー企業側で13年のITプロジェクト経験を経て、情シスコンサルティング株式会社を設立。

多くの現場経験をもとに、プロジェクトの全工程を網羅した業界初のユーザー企業側ノウハウ集『システム発注から導入までを成功させる90の鉄則』を上梓、好評を得る。同書は多くの情シスで研修教材にもなっている。

また、プロジェクトの膨大な課題を悶絶しながらさばいていくうちに、失敗する原因は「上流工程」にあるとの結論にたどり着く。そのため、ベンダー選定までの上流工程のノウハウを編み出し『御社のシステム発注は、なぜ「ベンダー選び」で失敗するのか』を上梓し、情シスにインストールするようになる。

「情シスが会社を強くする」という信念のもと、情シスの現場を日々奔走している。

著書の詳細は、こちらをご覧ください。