勘定系刷新PMのテスト工程管理と移行リハーサル実務ガイド
- 金融PMのテスト工程は、結合テスト・総合テスト・移行リハーサル・本番切替リハーサルの4段階に分けて計画すると抜け漏れが減る。
- 大型勘定系刷新では移行リハーサルを3〜5回、中小規模の基幹系刷新では1〜2回実施するのが僕の体感値での目安である。
- 障害発生時の切り戻し判断は、影響範囲・復旧見込み時間・連絡網の3点をテスト計画書に事前定義しておくべきである。
「リハーサルでは何も出なかったのに、本番当日に不具合が見つかったんです」——先日、ある地方銀行の勘定系刷新PMを担当されている方から、こんな相談をいただきました。話を詳しく伺うと、リハーサルで使ったデータ量と実施時間帯が本番とずれていて、検証したはずの手順が本番の負荷では成立していなかったことがわかりました。
0. 結論:テスト工程は「起きた後」ではなく「起きる前」に設計する
結論から先に申し上げると、テスト工程で本当に守るべきなのは「不具合をゼロにすること」ではなく、「起きたときにどう判断するかを事前に決めておくこと」だと僕は考えています。金融システムのテストは、機能検証だけでなく、移行手順そのものをリハーサルする工程が独立して存在する点が事業会社のシステム開発と大きく異なります。この記事では、総合テストから移行リハーサル、本番切替判断までの実務手順を、僕が支援してきた勘定系刷新・BaaS移行プロジェクトでの経験を踏まえてお伝えします。
1. なぜ金融PMにとってテスト工程が生命線なのか
勘定系刷新やBaaS移行のプロジェクトでは、要件定義や設計工程にどれだけ時間をかけても、最終的な成否はテスト工程で決まると言っても言い過ぎではないと僕は感じています。理由は単純で、金融システムは「止まっても後で直せばいい」システムではないからです。口座残高や取引履歴のデータが1件でも狂えば、それは顧客への実害に直結します。事業会社のWebサービス開発であれば、リリース後に小さな不具合を見つけて修正するというサイクルが許容されますが、金融システムの移行は基本的に一発勝負です。あるBaaS案件では、リリース後の軽微な不具合修正であっても金融機関側の変更管理プロセスを通す必要があり、修正のリリースまでに2週間以上かかったこともありました。だからこそ、総合テストと移行リハーサルという2つの検証工程を、機能検証と手順検証という別の目的として明確に分けて計画する必要があります。この切り分けが曖昧なままだと、機能は正しいのに移行手順が本番の時間内に終わらない、という事態を後工程まで発見できません。
2. 総合テスト計画の設計:ケース設計と環境準備の実務
総合テストの設計で僕がまず確認するのは、テストケースが「正常系」だけでなく「異常系」と「境界値」を網羅しているかという点です。特に勘定系では、月末月初のバッチ処理、休日を跨ぐ取引、他行との連携タイミングなど、日常運用では発生頻度が低いケースほど本番障害の温床になります。テスト環境は本番と完全に同一構成が理想ですが、コストの制約から難しい場合も多く、その際は「どの差分なら許容できるか」をベンダーと合意しておくことが実務上重要です。僕がよく確認するのは、サーバースペックの差分だけでなく、外部接続先のスタブ(模擬環境)が本番の応答速度をどこまで再現できているかという点で、スタブの応答が本番より速すぎると、後工程の移行リハーサルで初めて処理時間の遅延に気づくことになります。
| テスト種別 | 目的 | 実施回数の目安(体感値) | 主な参加者 |
|---|---|---|---|
| 結合テスト | モジュール間の連携動作を検証 | 1〜2回 | 開発ベンダー各社 |
| 総合テスト | 業務シナリオ単位で機能を検証 | 1〜2回 | ベンダー・業務部門 |
| 移行リハーサル | 本番同等データで移行手順を検証 | 大型案件で3〜5回、中小規模で1〜2回 | PM・インフラ・業務部門 |
| 本番切替リハーサル | 切替当日の役割分担と時間管理を検証 | 1回 | 全ステークホルダー |
この表の回数はあくまで僕がこれまで関わった案件から得た体感値であり、公的な統計ではありません。システムの規模、移行対象データの件数、外部接続先の数によって必要な回数は変わりますので、初回のリハーサル結果を見てから追加の要否を判断するのが現実的です。
3. 移行リハーサルの実務手順:本番同等データで検証する
移行リハーサルは、総合テストが終わった機能を前提に「本番と同じ手順・同じ量のデータで移行作業そのものが時間内に終わるか」を確認する工程です。以前僕が支援した地方銀行の勘定系刷新案件では、3回目の移行リハーサルで夜間バッチの処理時間が想定を大きく超え、休日出勤で対応にあたったことがありました。原因を調べると、テスト環境で使っていたデータ量が本番の実データ件数の約6割程度しかなく、件数が増えたことでソート処理の負荷が想定以上に膨らんでいたことがわかりました。この経験から、僕は移行リハーサルで使うデータは可能な限り本番と同等の件数に近づけること、そして処理時間には必ず2〜3割の余裕(バッファ)を持たせて計画することを、以降の案件でも徹底するようにしています。具体的な進め方としては、まず1回目のリハーサルで手順そのものの抜け漏れを洗い出し、2回目で本番同等のデータ量に近づけて時間計測を行い、3回目以降で当日の役割分担と連絡経路までを含めた通し稽古にする、という3段階の設計が僕の中では定番になっています。1回あたりの所要時間は、大型勘定系刷新であれば準備を含めて8〜12時間、深夜から翌朝にかけての実施になることが多く、参加者の体力面への配慮も計画段階で考慮すべき点です。実施時間の内訳で言うと、環境準備とデータ投入だけで2〜3時間、移行バッチの実行に4〜6時間、結果検証と報告会に1〜2時間という配分になることが多く、この内訳を事前に共有しておくと参加者の勤務シフト調整もしやすくなります。リハーサルの実施タイミングも重要です。平日の日中に実施すると、業務部門のメンバーが通常業務と兼務になり、検証の精度が落ちがちです。可能であれば休日や夜間帯に、本番切替と同じ時間軸で実施することをお勧めします。
4. 障害発生時の切り戻し判断とコミュニケーション設計
移行リハーサルや本番切替当日に不具合が発生したとき、最も現場が混乱するのは「これは切り戻すべきなのか、このまま様子を見るべきなのか」という判断です。この判断を当日の現場感覚に委ねてしまうと、影響範囲の見立てがぶれて意思決定が遅れ、結果的に対応時間そのものが延びてしまいます。僕がテスト計画書に必ず盛り込むようにしているのは、次の3点をあらかじめ数値で定義しておくことです。1つ目は影響範囲の判定基準(対象顧客数や勘定科目の範囲)、2つ目は復旧見込み時間の上限(この時間を超えたら切り戻すという線引き)、3つ目は判断者と連絡網(誰が最終判断を下し、誰にどの順番で連絡するか)です。この3点が事前に決まっているだけで、当日の会議室の空気は大きく変わります。加えて、連絡網は電話番号やチャットのIDを列挙するだけでなく、「一次連絡から30分以内に応答がない場合は代理判断者に切り替える」というエスカレーションのルールまで書いておくと、深夜帯の対応でも判断が滞りません。以前、移行リハーサルの深夜帯で判断者本人と連絡がつかず、代理判断者への切り替えルールがなかったために約1時間、作業チーム全員が待機状態になったことがありました。この反省から、僕はその後の案件では判断者を必ず正副2名体制にし、両者の連絡先を事前にリハーサル参加者全員へ共有するようにしています。
5. テスト工程でPMが陥りやすい失敗と対処
僕がこれまで見てきた中で多い失敗は、大きく3つのパターンに分かれます。1つ目は、テストケースの網羅性をベンダー任せにしてしまい、業務部門の視点が抜け落ちるパターンです。ベンダーは仕様書通りに動くかどうかは検証できますが、「実際の業務運用でその画面がどう使われるか」までは見えていないことが多いため、業務部門のレビューを必ず工程に組み込む必要があります。2つ目は、リハーサルで見つかった課題を「軽微だから」と先送りしてしまうパターンです。軽微に見える課題ほど、本番の実データ量やタイミングが重なったときに想定外の挙動を示すことがあり、僕の体感では、先送りした課題の再発率は決して低くありません。見つかった課題は、優先度に関わらず必ず解消担当と期限を決めてクローズする運用を徹底することをお勧めします。3つ目は、リハーサル参加者を毎回同じメンバーで固定してしまうパターンです。本番当日は休暇や体調不良で担当者が入れ替わる可能性がありますので、少なくとも1回は代理要員だけでリハーサルを回してみることで、手順書の粒度が本当に十分かを確認できます。これら3つの失敗に共通するのは、いずれも「本番当日に初めて表面化する」という点です。テスト工程の設計段階でこの3つを意識的にチェックリスト化しておくだけで、本番直前になって慌てる場面はかなり減らせるはずです。
6. ケース比較:勘定系刷新とBaaS移行でテスト設計はどう変わるか
勘定系刷新とBaaS・組込金融のプロジェクトでは、テスト工程で重視するポイントが異なると僕は感じています。勘定系刷新では、自行内の既存システムからの移行データ整合性と、夜間バッチの処理時間が最大の論点になります。一方でBaaS移行では、自社システムの検証だけでなく、提携先の金融機関やAPI基盤側との結合テストが工程のボトルネックになりやすく、相手方のテスト環境の空き状況によってスケジュールが左右されることが多いのが実務上の悩みどころです。僕の経験では、BaaS案件の移行リハーサルは接続先ごとに最低1回は個別に確保し、全接続先を同時に通す統合リハーサルを別途1回設ける、という2段構えの計画にすると、どの接続先で問題が起きたのかを切り分けやすくなります。接続先が3〜4行程度の案件であれば、個別リハーサルと統合リハーサルを合わせて4〜5回で収まることが多い一方、接続先が増えるほどスケジュール調整だけで数か月を要することもあり、この調整コストは見積もり段階で軽視されがちだと感じています。勘定系刷新のように単一の巨大システムを扱う場合と、BaaS移行のように複数の外部接続先を扱う場合とでは、リハーサルの「単位」の切り方そのものを変える必要がある、という点は意識しておいて損はないはずです。
(結論)
テスト工程の設計は、地味で目立たない作業に見えるかもしれませんが、金融PMの実務の中でも最もプロジェクトの成否を左右する工程の一つだと僕は考えています。総合テストと移行リハーサルの役割を分け、切り戻し判断の基準を事前に数値で決めておく。この2つを徹底するだけで、本番当日の混乱はかなり減らせるはずです。皆さんいかがでしたでしょうか。では今日もがんばりましょう。
よくある質問
Q. 移行リハーサルは何回くらい実施すればいいですか?
結論から言うと、僕の体感値では大型勘定系刷新で3〜5回、中小規模の基幹系刷新で1〜2回が目安です。回数はシステム規模と移行対象データの件数で変わるため、まずは初回リハーサルの結果を見てから追加回数を判断するのが実務的です。BaaS移行のように接続先金融機関が複数ある場合は、接続先ごとに1回ずつ確保する設計にしています。
Q. テスト工程で金融PMが最も注意すべきことは何ですか?
結論としては、切り戻し判断の基準を本番実施前に文書化しておくことです。当日の判断を現場任せにすると影響範囲の見立てがぶれて意思決定が遅れます。影響範囲・復旧見込み時間・連絡網の3点を数値と役割名で事前に決めておくことが重要です。
Q. 総合テストと移行リハーサルの違いは何ですか?
総合テストはシステム機能が仕様通り動くかを検証する工程で、移行リハーサルは本番同等のデータと手順で移行作業そのものを通しで検証する工程です。総合テストで機能を固め、移行リハーサルで運用手順とデータ量への耐性を確認する、という役割分担になります。
IT人材業界20年、ギークリー創業を経て現職。個人として通算4,200名のキャリア面談を実施してきた経験に基づき監修しています。本文中の年収・難易度等は独自ガイドの目安値であり、個人の経験・企業により変動します。