月末、23時。経理担当の田中さん(仮名、従業員80名の卸売会社)は、締め処理の画面をただ見つめていた。「処理中」の表示が消えない。10分前まで普通に動いていた販売管理システムが、全部署が一斉に締め作業を始めた瞬間から重くなり、ついに固まった。営業部からは「見積が出せない」、倉庫からは「出荷データが反映されない」と内線が鳴り続ける。情シス担当は一人しかいない。サーバーの再起動を試みるが、直らない。結局その日は手作業の紙伝票に戻し、翌朝には社長への報告書を書くことになった。
これは特別な会社の特別な事故ではない。決算期、繁忙期、キャンペーン当日。多くの中小企業が「なぜかその日だけシステムが落ちる」を年に一度は経験している。そして厄介なのは、同じ失敗が翌年も、翌々年も繰り返されることだ。原因を突き止めないまま「また落ちた」で終わらせてしまうからだ。
この記事では、そうした事態を未然に防ぐための「負荷テスト」について、専門用語を避けながら、中小企業が現実的に取り組める範囲でどこまでやるべきかを解説する。エンジニアではない経営者やシステム担当者が、外部のベンダーと対等に会話するための土台になることを目指したい。
負荷テストとは何か、身近な例で考える
負荷テストを一言でいえば「大勢の人が同時にシステムを使ったらどうなるかを、本番より先に確かめておくこと」だ。
飲食店に例えるとわかりやすい。ランチタイムに20人が一斉に来店したら、厨房は回るか。レジは詰まらないか。ホールスタッフは足りるか。これを実際に混雑する前に、リハーサルとして試しておくのが負荷テストにあたる。厨房のオペレーションが一人客相手にはスムーズでも、20人同時だと全く別の問題が起きる。注文が交錯する、食材の在庫管理が追いつかない、会計待ちの行列ができる。システムも全く同じ構造の問題を抱えている。
具体的にシステムの世界で言えば、負荷テストとは「同時に何人がアクセスしても、画面が固まらず、処理が止まらず、データが壊れないか」を、実際に多数のアクセスを人工的に発生させて検証する作業だ。専門のツールを使い、あたかも100人、1000人が同時にボタンを押しているかのような状況を作り出し、システムの反応を観察する。処理にかかる時間が伸びていないか、途中でエラーが出ていないか、サーバーの負荷(CPUやメモリの使用率)がどこまで上がるかを数値で確認する。
大切なのは、負荷テストが「壊れるかどうかのテスト」ではなく「どこまでなら耐えられるかを知るテスト」だということだ。100人までは快適、200人を超えると遅くなり始める、300人で処理が詰まり始める――こうした限界値を事前に把握しておければ、繁忙期に何人までのアクセスなら安全か、逆算して備えることができる。
なぜ「普通のテスト」だけでは見つからないのか
新しいシステムを導入する際、多くの企業はテストをきちんと行っている。担当者が一人で画面を操作し、注文が正しく登録されるか、金額の計算が合っているか、印刷はきれいに出るか。いわゆる機能テストだ。これ自体は欠かせない工程であり、軽視してよいものではない。
問題は、このテストが基本的に「一人が順番に操作する」ことを前提にしている点にある。一人が使う分には何の問題もなかったシステムが、50人が同時に使った途端に不具合を起こすことは珍しくない。理由は単純で、複数人が同時に同じデータを読み書きしようとすると、機能テストでは絶対に発生しない種類の競合が起きるからだ。
たとえば在庫管理システムで、二人の担当者が同時に同じ商品の在庫を1個ずつ減らす処理をしたとする。タイミングによっては、片方の処理が上書きされてしまい、実際には2個減ったはずなのに記録上は1個しか減っていない、ということが起こり得る。一人で操作している限りは絶対に表面化しないバグだ。
もう一つの理由は、サーバーという「共有される資源」の限界にある。普段は1人、2人が使うだけのシステムでも、裏側では一つのサーバー、一つのデータベースを全社員が共有している。同時に押し寄せるアクセスが増えれば増えるほど、そのサーバーの処理能力という一本のパイプに水が集中し、やがて流れが詰まる。この「詰まり方」は、実際に多人数で同時アクセスしてみない限り、机上の計算だけでは正確に予測できない。だからこそ、普段の機能テストとは別に、負荷テストという工程が必要になる。
負荷テストが特に必要になる場面
すべてのシステムに厳密な負荷テストが要るわけではない。ただし、次のような特徴を持つ業務では、優先度を上げて検討すべきだ。
- 月末月初、決算期など、特定の日に処理が集中する経理・販売管理システム
- 朝礼や始業時刻に全社員が一斉にログインする勤怠管理・グループウェア
- セールやキャンペーンの開始時刻にアクセスが跳ね上がるECサイト、予約サイト
- 台風や災害など、繁忙期以外にも予測不能なタイミングでアクセスが急増しうる問い合わせシステム
- 新規顧客獲得のためテレビCMやSNS広告を予定しており、公開直後にアクセス集中が見込まれるサービス
共通しているのは「アクセスが均等に分散せず、特定の時間に集中する」という性質だ。1日の総アクセス数が同じでも、24時間かけて分散するのと、始業直後の10分間に集中するのとでは、システムにかかる負荷はまったく別物になる。繁忙期がある業種、キャンペーンで人を呼び込む業種ほど、負荷テストの重要性は高い。
逆に言えば、社内の限られた人数がゆるやかに使うだけの小規模な業務システムであれば、簡易的な確認で十分なケースも多い。すべてに同じ予算とレベルの負荷テストを課す必要はない。自社の業務がどちらのタイプに当てはまるか、まずそこを見極めることが最初の一歩になる。
中小企業が現実的にできる進め方と費用感
負荷テストと聞くと、大企業が数百万円をかけて行う大掛かりな工程を想像するかもしれない。しかし実際には、企業の規模と予算に応じた現実的な進め方がいくつも存在する。段階を追って考えてみたい。
ステップ1 想定人数を数字で言語化する
まず最初にやるべきは、専門ツールを使う前の準備作業だ。「繁忙期に、何時何分ごろ、何人が、何の操作を同時にするか」を具体的な数字で書き出す。「月末の17時から18時にかけて、経理3名と各部署の担当者20名、合計23名が締め処理の入力と確認を同時に行う」といった具合だ。この数字を出さないまま業者に「負荷テストをお願いします」と依頼すると、想定人数が実態とずれたまま話が進んでしまう。ここは経営者や現場担当者にしかできない、最も重要な工程だ。
ステップ2 無料〜低コストのツールで自分たちで試す
想定人数が数十人規模で、社内にシステム担当者が一人でもいる場合、無料の負荷テストツールを使って自社で試すことも可能だ。代表的なものに、オープンソースのApache JMeterやk6といったツールがある。導入コストはかからないが、設定や結果の読み解きにはある程度の学習が必要になる。社内で完結させたい場合、まずは外部の技術者に半日〜数日のスポット支援を依頼し、ツールの使い方だけ教わるという方法も現実的だ。費用感としては、スポット支援で10万円〜30万円程度が目安になる。
ステップ3 本格的な負荷テストを外部に依頼する
ECサイトの大型セールや、全国規模のキャンペーンなど、失敗した際の損失が大きい場面では、専門業者に依頼する価値がある。想定シナリオの設計、テスト実施、結果分析とボトルネックの特定、改善提案までを一式で行う場合、規模にもよるが30万円〜100万円程度が一般的な相場だ。決して安くはないが、繁忙期に一日システムが止まった場合の機会損失や信用の毀損と比べれば、決して高い投資ではない。
ステップ4 結果を「対策」に変換する
負荷テストは、実施して終わりではない。「200人を超えると処理が3秒から15秒に遅くなる」という結果が出たなら、その先に必ず対策の議論が必要になる。サーバーの増強で解決できるのか、処理の順番を見直す必要があるのか、あるいはピーク時間をあえて分散させる業務ルールの変更で対応できるのか。負荷テストの結果を読み解き、次の一手に落とし込むところまでがワンセットだと考えてほしい。
よくある失敗パターン
負荷テストにまつわる失敗には、いくつかの典型的なパターンがある。自社が同じ轍を踏んでいないか、チェックしてみてほしい。
- 負荷テストを一切行わずにリリースし、初めての繁忙期に本番環境で問題が発覚する。冒頭の卸売会社のケースがまさにこれにあたる。新システム導入時のテストは機能面だけで終わっており、誰も「全員が同時に使ったらどうなるか」を確認していなかった。
- 負荷テストは実施したが、想定した同時アクセス数が実態とかけ離れていた。「50人でテストして問題なかった」としても、実際の繁忙期には管理画面からの操作に加えて、取引先や顧客からの外部アクセスも重なり、実質150人分の負荷がかかっていた、というケースは多い。テストのシナリオ設計が甘いと、テスト自体は成功していても本番では通用しない。
- サーバー側の性能だけを見て、データベースやネットワークなど他の要因を見落とす。負荷が集中したときに詰まる箇所は、サーバーではなくデータベースへの問い合わせ処理だった、というのはよくある話だ。一箇所だけ確認して安心してしまうと、別の箇所で本番中に足をすくわれる。
- 負荷テストを実施したものの、結果の数字を読み解ける人が社内にいないため、改善につながらないまま放置される。テストレポートが専門用語だらけで、経営者が読んでも意味がわからず、そのままファイルに閉じられてしまうケースだ。契約時に「結果を非エンジニアにも説明してもらえるか」を確認しておくと、この失敗は避けられる。
- 一度負荷テストをして問題がなかったからと、その後何年も同じ設定のまま放置する。社員数が増え、取引先が増え、扱うデータ量が増えているのに、テストは導入時の一回きり。システムは生き物のように状況が変わっていくものだと捉え、事業規模が大きく変わった節目には再度の確認を検討したい。
これらに共通するのは、いずれも「そのとき現場で対応していた人」の落ち度ではないということだ。繁忙期に踏ん張って手作業でしのいだ担当者も、限られた予算の中で最善を尽くした情シス担当者も、多くの場合は精一杯やっている。問題は、事前にリスクを見える化する仕組みが整っていなかったことにある。壁にぶつかってから走り出すのではなく、壁の高さを先に測っておく。負荷テストは、まさにそのための地道な準備作業だ。
まとめ
負荷テストとは、大勢が同時にシステムを使う状況を事前に再現し、どこまでなら耐えられるかを数字で把握しておく作業だ。通常の機能テストでは絶対に見つからない種類の問題を炙り出すことができる。
すべての中小企業が大掛かりな負荷テストを行う必要はない。ただし、月末月初や決算期に処理が集中する業務システム、キャンペーンでアクセスが跳ね上がるECサイトなど、繁忙期のある業務ほど、その重要性は高くなる。まずは自社の繁忙期に「誰が、何時に、何人で、何をするか」を数字で書き出すところから始めてみてほしい。それだけでも、次に打つべき手が見えてくるはずだ。
繁忙期のたびにシステムと格闘し、それでも顧客や社内のために踏ん張り続けている担当者は多い。その努力が報われるように、事前の備えという壁を一つ越えておく。今日書き出したその想定人数のメモが、来年の月末に固まらない画面を作る、最初の一行になる。