リアルタイムシステムのテストで見抜く致命的欠陥7つの兆候

リアルタイムシステムのテストが「機能テスト通過＝OK」で終わらない理由

オークション、抽選、チケット販売、マッチング、オンライン投票、ライブ配信への同時参加──こうしたリアルタイムシステムのテストは、機能テストを通過しても本番公開直後に不具合が噴き出しやすい領域です。「同じ瞬間に多数のユーザーが同じ資源を奪い合う」機能は、いま多くの受託開発で組み込みが求められています。

機能テストが通ることと、本番と同じ条件で正しく動くことは、まったく別の話です。開発環境で1人が順番にボタンを押して確認するテストは、あくまで「1人ずつなら正しく動く」ことしか証明していません。数十人、数百人が同時に同じ操作をぶつけたとき、システムが期待どおりに動くかは別途検証が必要です。

そして本番で顕在化した不具合の被害は、通常の画面表示バグとは桁違いになりがちです。1人しか当選しないはずのくじで2人に当選メールが飛べば、その後の返金対応・お詫び・二次被害の説明で数日から数週間の工数が飛びます。決済が二重に走れば、金銭的な返金だけでなく、決済代行会社への説明、監督官庁への報告義務、SNSでの拡散対応まで発生し得ます。

高橋寿一『知識ゼロから学ぶソフトウェアテスト 第3版』でも、ソフトウェアテストで大切なのは「どの部分にバグが出やすいのか、そこにどのようなテスト手法を適用すれば十分な品質が得られるかを知ること」だと語られています。同時アクセスが集中するリアルタイム系の機能は、まさに「バグが出やすい・出たときの損失が大きい」領域の代表格であり、機能テスト通過を成果報告のゴールにしてしまうと、最も危険な場所を見落とすことになります。

本記事では、内部実装の話は極力せず、外部からシステムを観察するブラックボックステスターの視点で、見抜くべき症状と、少人数体制でも実行できる検証手順、外部委託の判断軸を整理していきます。

業務系リアルタイム機能で拾うべき見えない不具合の症状カタログ

リアルタイム機能で発生する致命的な不具合は、コードを読まなくても「ユーザーから見て何が起きているか」の観点で整理できます。ここで扱うのは、抽選・決済・予約・チャット・ライブ配信参加など、業務系リアルタイム機能で実際に噴き出しやすい5つの症状に絞っています。汎用的なゲームや大規模SNS特有の症状ではなく、受託開発の現場で遭遇率が高いものだけを並べました。

このリストは、そのままテスト観点シートに転記できる形にしてあります。

症状1：二重受理・二重当選・二重課金（並行更新の衝突）

「1人しか当たらないはずのくじで、同じユーザーが2回当選と表示される」「決済ボタンを1回押しただけなのに、明細に同じ金額が2件並んでいる」「予約枠が1つしかないのに、2人の名前が同時に入っている」──こういった見え方は、同時に発生した操作が想定どおりにさばけていない典型的なサインです。抽選・EC決済・座席予約系で最も遭遇率が高い症状です。

症状2：順序逆転（イベント順序保証の破綻）

「後から押した操作が、先に押した操作より前に反映されている」「先にキャンセルしたはずなのに、キャンセルより後の追加操作が生き残っている」。時系列が守られない挙動は、リアルタイム機能に対する信頼を一気に失わせます。チャット・掲示板系の投稿順序や、受発注系のステータス遷移で顕在化しやすい症状です。

症状3：幽霊接続（切断検知の遅延）

「通信が切れて画面を閉じたはずのユーザーが、参加者一覧にずっと残っている」「オフラインになっているはずのアカウントが、まだログイン中と表示される」。実際には存在しないユーザーが残ることで、集計や課金の基準が狂います。オンライン会議・ライブ配信参加者数・当直勤怠系で問題化しやすい症状です。

症状4：復帰時の状態ズレ（再同期の失敗）

「トンネルでWi-Fiが切れた後、電波が戻ったら自分の操作が消えている」「逆に、同じ操作が二重に反映されている」。通信環境が不安定な現代のユーザーにとって、この症状は日常的に踏みやすい地雷です。営業支援系・現場作業報告系・モバイル決済系で頻発します。

症状5：特定条件だけ極端に遅い（末端応答の劣化）

「同じ操作をしても、一部のユーザーだけ画面が固まったまま数秒待たされ、そのまま離脱している」。全ユーザーが均等に遅いなら気づきやすいのですが、一部だけ遅い場合は障害として認識されず、静かに離脱率だけが上がっていきます。予約系・イベント参加受付系での機会損失に直結します。

症状名	ユーザーからの見え方	業務被害の例
二重受理・二重課金	1回の操作で2件以上の記録が残る	返金対応、二重当選の謝罪、法的リスク
順序逆転	操作の前後関係が入れ替わる	「キャンセル済みなのに請求」等の信用失墜
幽霊接続	離脱済みのユーザーが参加中扱い	参加人数の水増し、集計ミス
復帰時の状態ズレ	通信復帰後に操作が消える／増える	操作の再送、問い合わせ増加
特定条件だけ遅い	一部ユーザーだけ画面が固まる	サイレント離脱、機会損失

これら5つの症状は、内部実装を1行も読まずに「画面と業務データを突き合わせる」だけで検出できます。最初にやるべきは、この症状リストを社内テストの観点表に加えることです。用語の業界標準対応（例：症状1＝race condition、症状2＝順序保証の破綻、症状5＝tail latency）は開発者と会話するときの共通語彙として控えておく程度で十分で、検証者が主戦場にすべきは「ユーザー画面から見える現象」の側です。

内部実装を知らなくてもできるブラックボックス検証パターン

前章の症状は、日常のオフィス環境では再現しにくいものばかりです。1台のPCで、1人のテスターが、安定した社内Wi-Fiで、順番に操作を確認しているうちは、まず出てきません。少人数のQAでも実施できる検証は、「あえて社内環境では起きない条件を人力で作る」ことに尽きます。

高橋寿一氏も先の書籍のなかで「バグを全部見つけるのは無理だと心得ろ」と繰り返し語っています。だからこそ、狙いを絞って壊しにいく検証設計が必要になります。以下の5つは、いずれも特別なツールを必要としない、物理と手順だけで実現できる検証パターンです。

検証1：実機×複数端末での並行操作

PC、スマートフォン、タブレットを同時に手元に並べ、それぞれ別アカウントでログインして、同じ操作を同じ瞬間にぶつけます。1人でも4〜5台までは同時に扱えます。予備端末が足りない場合は、開発者・営業の私物端末を業務利用する社内ルールを事前に整備しておくと、当日の調整が一気に楽になります。

検証2：複数回線の組合せ

家庭用光回線、モバイル回線（4G/5G）、社内Wi-Fi、モバイルルーターなど、異なる経路で同じ機能にアクセスします。回線ごとにレスポンスの遅さが違うため、症状2や症状5が浮かびやすくなります。ただし、サーバ内部起因の順序逆転や末端応答の劣化そのものは、経路を変えても再現しないケースがあり、そこは後述の外部委託枠での多人数負荷検証で補うのが現実的です。

検証3：意図的な通信断の注入

ボタンを押した直後、応答が返る前に機内モードをONにする。応答後にOFFに戻す。この「電波が一瞬切れた」状態を各画面で試すと、症状3・症状4が現れます。テスト計画には「押下→即機内モード→10秒後解除」など、時間を固定した手順書を用意しておくと再現性が担保できます。

検証4：同時操作の人力再現

チームメンバー数人が声をかけ合い、「せーの」で同じボタンを押します。原始的ですが、社内で最も簡単に多重操作を再現できます。他PJメンバーとの調整は昼休み直前の5分など、全員が席にいる時間帯を狙うと調整コストを最小化できます。専用のSlackチャンネルで開始時刻を予告しておくのも有効です。

検証5：期待動作マトリクスとの突合

事前に「この操作をしたら、こう見えるのが正しい」という表を作り、検証1〜4の結果を実測と突き合わせます。マトリクスがないと、目の前で不具合が起きていても「これはバグか仕様か」の判定ができません。

検証パターン	必要な準備	検出しやすい症状
実機×複数端末	端末4〜5台、複数アカウント	症状1・症状2
複数回線	モバイル回線、家庭回線、社内Wi-Fi	症状5
通信断注入	実機の機内モード切替のみ	症状3・症状4
同時操作の人力再現	声かけできる同僚3〜5人	症状1・症状2
期待動作マトリクス突合	事前に作った期待動作表	全症状の判定基準

少人数の兼任QAでも、道具は身の回りにあるスマートフォンと社内メンバーだけで、致命的欠陥の多くは炙り出せます。

一方で、開発本業を抱えたまま自分の手で回そうとすると、途端に日程が詰まります。「開発でテストまで手が回らない」状況が続くようなら、開発でテストまで手が回らないときのテスト代行活用の考え方も合わせて確認しておくと、判断基準を持ちやすくなります。

本番相当の多人数同時検証は、自社だけでできるか？の判断軸

前章のブラックボックス検証で炙り出せるのは、あくまで「数人〜十数人規模で見える症状」です。しかし本番のリアルタイム機能では、数十人・数百人・数千人が同時にアクセスすることがあります。この規模を社内で再現しようとすると、途端に無理が出ます。

理由はシンプルで、社内メンバーだけでは、数十人が別々の回線・別々の端末・別々の物理拠点から同時にアクセスする状況を作れないからです。全員が同じ社内Wi-Fiに繋がっていれば、経路がひとつに集約されてしまい、本番と同じ条件にはなりません。

ここで役立つのが、「業務知識の依存度」と「必要な物理動員規模」の2軸で切り分ける発想です。業務知識の依存度が高い検証は、外部に一から説明するより自社で押さえるほうが速いです。逆に、単純に「同じ操作をする人数と回線を揃える」種類の検証は、外部の力を借りたほうが効率的です。

検証カテゴリ	業務知識依存度	物理動員規模	推奨アサイン
業務ユースケースの網羅	高	小	自社の兼任QA
症状カタログのブラックボックス検証	中	小〜中	自社の兼任QA
数十人以上の同時操作再現	低〜中	大	外部委託
多回線・多端末を混在させた並行検証	低	大	外部委託
現地拠点を分けた分散アクセス	低	大	外部委託

「ここから外」と決めるラインは、あくまで目安として次の観点を持っておくと迷いません。同時操作10人以上、3種類以上の異なる回線、別々の地理的拠点からの同時アクセス、いずれかに該当する検証。加えて、当選枠・在庫・予約枠など「共有リソースを複数ユーザーが同時に奪い合う機能」であれば、動員規模が小さくても外部委託を検討する価値があります。共有リソース系の症状は、少人数の同時操作では稀にしか出ないためです。

なお、外部委託の費用感は、同時操作10〜30人規模で数十万円〜百万円台の案件が一般的です。ぶれ幅が大きいので、見積もり時には次の単価項目を必ず確認しておくと比較しやすくなります。

• 1人日単価（テスター1人×1日でいくらか）
• 端末レンタル費用（実機の種類と台数）
• 回線種別（モバイル回線・光回線・海外回線の追加料金）
• 拠点数（同一拠点／複数拠点／在宅分散）
• 事前準備工数（NG定義・シナリオ整備を委託先に依頼するかどうか）

負荷や性能まわりの全体像を先に整理しておきたい場合は、パフォーマンステスト完全入門や、負荷テストの基本と実践の完全ガイドで、リアルタイム検証と隣接領域の棲み分けを確認しておくと、外部への依頼内容がはっきりします。

外部に依頼する前に揃える情報と最短準備手順

外部に検証を依頼するときに、テストの質を左右する最大の要因は、依頼側がどれだけ情報を渡せるかです。同じ委託先に発注しても、「NGの定義」が明確な案件と、そうでない案件では、検出できる不具合の数と質がまったく変わります。

「動作確認をお願いします」だけの依頼では、外部は最大限の成果を出せません。発注前に整えておくべき情報は次のとおりですが、いずれも既存資産の使い回しで最短で埋められます。

• NGの定義（症状仕様書）：本記事の症状カタログを転記し、既存の障害チケットのタイトルをコピペするだけで5〜10項目埋まります。表現は「二重当選が発生してはいけない」など具体的な形に。
• 主要ユースケース：要件定義書の機能一覧の上位3件をシナリオ形式に転記します。誰が・いつ・何のために使うかを1行ずつ書き足すだけで十分です。
• 想定利用パターン：アクセスログの日中ピーク時刻、平常時と最大時の同時利用者数、既知の範囲でよいので数値を書き出します。
• 既知のリスク・過去の障害履歴：直近1年の障害チケットと、開発者が「ここは怖い」と話している箇所を正直に共有します。隠すほど検証工数は膨らみます。
• 業務の全体像：機能単体ではなく、その機能が業務のどこに位置するかを図やフローで渡します。既存の要件定義書の業務フロー図を1枚転記すれば足りるケースが多いです。

これらを揃えて渡すと、外部のテスターは「限られた期間のなかで、業務上のリスクが大きい箇所から優先して壊しにいく」動き方ができます。逆にこれらが揃わないと、「どこを重点的に見ればいいのか」判断できず、一般的なブラックボックス検証しか実施されません。

発注前チェックリストとしては、次の順番で確認しておくと迷いません。

• 症状仕様書（NG定義）が5〜10項目書き出されている
• 主要ユースケースがシナリオ形式で3件以上ある
• ピーク時間・同時利用者数の想定が数値で書ける
• 過去の障害・怪しい挙動が正直に共有できている
• 業務全体像の図（1枚）が用意できている
• 委託先に渡してはいけない機密の線引きが済んでいる
• 検証結果を受け取ったあとの社内対応フローが決まっている

検証費用の妥当性を数字で示す枠組み

外部委託の予算を通すには、「なぜこの検証費用を払う価値があるのか」を数字で説明する必要があります。コードを書かなくても、費用対効果は組み立てられます。

基本の枠組みはシンプルで、期待損失 =（1件あたり被害額 + 1件あたり対応工数の人件費換算）× 年間発生確率、で組み立てます。この式に自社の数字を当てはめるだけで、社内でテストの妥当性を説明できます。

各項目は「テンプレートの空欄」として扱い、次の手順で自社の実数値に置き換えてください。

• 1件あたり被害額：過去1年の類似障害チケットを開き、返金額・お詫び費用・カスタマーサポートの延べ対応時間×時給・営業/管理職の対応時間×時給を積み上げます。金銭以外のコストを金額換算するのがポイントです。
• 1件あたり対応工数の人件費換算：発覚から収束までの延べ人日を、社内平均の人日単価で金額化します。開発チーム全体が2〜3日通常業務を止めて対応する工数は、それだけで数百万円規模になり得ます。
• 年間発生確率：類似機能の過去1年の障害発生件数から推定します。ゼロ件でも「一度起きたら」の影響が大きいなら、1件/年を最低ラインに置いて計算します。IPAのソフトウェア開発分析データ集は、業界横断のバグ発生傾向を参考にする材料として使えます。

項目	見積もり方	埋め方の情報源
1件あたり被害額	返金＋CS対応＋営業対応の合算	過去の障害チケット、CSログ
1件あたり対応工数の人件費換算	発覚〜収束の延べ人日×人日単価	障害振り返り議事録、勤怠
年間発生確率	類似障害の過去1年件数から推定	障害管理台帳、IPAデータ
期待損失（年間）	上記3項目を式に代入	自社実数で算出
検証費用	外部委託＋社内工数	見積書、内部工数配賦

さらに「一度でも本番で起きたら、既存クライアントの解約や新規失注につながる」観点を加えると、社内での説得力が増します。信頼失墜は数字にしにくいですが、「この案件を失うといくら失うか」という具体名で語ると議論が具体化します。

なお、本番で発生する不具合そのものを構造的に減らす体制づくりについては、リリース後のバグを減らすテスト体制の作り方も参考になります。

リリース前チェックリスト（症状・検証・外注）

ここまでの内容を、自分のプロジェクトに落として使える形に凝縮します。次の表は、リアルタイム機能を含む案件のリリース前レビューに、そのまま持ち込めるチェックリストです。

カテゴリ	確認項目	完了
症状の兆候	二重受理・二重当選・二重課金が起きないことを実機検証で確認したか	□
症状の兆候	順序逆転が起きないことを複数回線で確認したか	□
症状の兆候	幽霊接続（離脱ユーザー残留）を通信断シナリオで確認したか	□
症状の兆候	復帰時の状態ズレを機内モード切替で確認したか	□
症状の兆候	特定条件下でのレスポンス遅延を回線別に確認したか	□
検証網羅	実機×複数端末×複数回線の組合せを1回以上実施したか	□
検証網羅	期待動作マトリクスと実測結果を突き合わせたか	□
内製×外注	業務知識依存の高い領域を自社で押さえたか	□
内製×外注	数十人規模の同時操作検証を外部委託枠で確保したか	□
依頼準備	NG定義（症状仕様書）を5〜10項目書き出したか	□
依頼準備	主要ユースケースを3件以上シナリオ化したか	□
依頼準備	過去の障害・怪しい挙動を委託先に共有したか	□
費用対効果	期待損失と検証費用を数字で比較したか	□

このチェックリストは、リリース前1〜2週間の時点で全項目を確認するのが理想です。仮に一部の項目が「未完了」で残っていても、どの項目が抜けているかが可視化されているだけで、リリース判断の質は格段に上がります。

チェックリストは一度作れば、次以降のプロジェクトでも使い回せます。プロジェクトごとに1〜2項目ずつ追加していけば、社内でリアルタイム機能を含む案件に対する「共通の目線」ができあがり、属人化を防げます。用語の共通化については、JSTQB公式サイトで公開されているシラバス・用語集を社内の辞書として活用すると、委託先や開発チームとの会話が噛み合いやすくなります。

よくある質問

Q1. 内部実装を知らないブラックボックス検証だけで、本当に致命的欠陥は見つかりますか？

多くは見つかります。ただし、社内で数人が同時操作する検証で拾えるのは、比較的発生確率が高い症状に限られます。数百人規模の同時アクセスで初めて表面化する末端応答の劣化などは、外部委託枠での多人数負荷検証と組み合わせて初めて拾いきれます。「社内で拾えるもの／外部でしか拾えないもの」の切り分けを事前に決めることが、抜け漏れを防ぐ最短ルートです。

Q2. 症状カタログはどのタイミングで作ればよいですか？

要件定義の直後、遅くとも詳細設計の完了までに1度作り、実装フェーズの途中でレビューをかけるのが理想です。開発者が「ここは同時アクセスで危ない」と感じている勘所を、症状の言葉に変換しておくと、後工程のテスト設計と発注準備がスムーズになります。

Q3. 外部委託と社内検証の予算配分の目安はありますか？

案件ごとに大きく異なるため一律の比率はありませんが、業務知識依存の高いユースケース網羅は社内で押さえ、動員規模が必要な多人数同時操作は外部に切り出す、という切り分けが基本です。予算が限られる場合は、症状カタログのうち「一度起きたら賠償・信用失墜のリスクが最も大きい2〜3件」に絞り、その症状の検出に必要な検証だけを外部委託する、というスコープ圧縮が有効です。

まとめ ── 今日から始める品質担保の一歩

同時アクセスを扱う機能のテストというと、専門部隊がいなければ手が出せない領域のように感じられるかもしれません。しかし本記事で見てきたとおり、致命的な欠陥の多くは、内部実装を知らなくても「症状ベース」で観察できます。

必要なのは、コードを読む力ではなく、ユーザーから何が見えているかを整理する視点です。症状カタログを作り、実機と複数回線でブラックボックス検証を回し、社内でどこまで押さえ、どこから外に頼るかを線引きする。この一連の流れは、開発と兼任で品質確認を回している立場でも今日から始められます。

そして、社内でどうしても再現できない多人数同時検証や、業務日程の関係で兼任QAが手を回せない領域が明確になったら、そこは外部の力を借りると割り切ってよい部分です。リアルタイムシステムのテストで大切なのは、「全部自社でやること」ではなく、「本番で致命的欠陥が出ないこと」です。

まずは症状カタログを社内のテスト観点シートに書き足すところから始めてみてください。それだけでも、リリース直前に慌てて見つかる不具合の数は減らせます。そのうえで、社内では再現しきれない範囲について「外部と組む前提の予算枠」を来期の計画に入れておくと、次のリアルタイム案件で品質と納期を両立させやすくなります。

テスト体制の見直しや、リリース前検証について具体的に相談したい場合は、お問い合わせフォームからお気軽にご相談ください。現在のプロジェクトの状況に合わせて、どの範囲を社内で押さえ、どこから外部に切り出すかの整理をお手伝いします。