はじめに
2025年6月に、株式会社ログラスへQAエンジニアとして入社しましたAkinovと申します。
過去、ゲーム・エンターテイメント向けBtoCのウォーターフォール開発におけるQA業務に長年携わってきた事から、BtoB・アジャイル開発ともにほぼ未経験、日々試行錯誤＆学びを得ながら業務に取り組んでおります。
今回、本ブログの執筆に際して過去のテックブログを参照した所、エンジニア視点でのBtoBとBtoCの違いについて言及されている記事がありました。
【参考】 ユーザーの価値と向き合う上でのBtoBとBtoCの違い
自分も過去の、特に多様なエンドユーザーを対象とした各種エッジケースのテスト観点を整理の上、テスト実施やチームメンバーへの指導を行ってきました。
よって、今回は過去のBtoC向けのテスト観点がログラスの各種サービスに活かせるのか、も踏まえ、テスト観点の整理及びBtoBへの適用をお題とし、記事に取りまとめる事としました。
エッジケースのテスト分類
では、以下に主なエッジケースの分類、及びログラスを中心に、どのように適用できそうかの考察を行います。
1)閾値
いままでの経験
こちらは最も代表的、「数字を見たら真っ先に上限がいくつかを考えろ」と言われる『閾値』です。
古の某RPGでは、HPが65535(=FFFFh)を超えるとHPがマイナスになって一歩歩いただけで死ぬキャラを作れる、と言われたものです。
当然、テストにあたっては各所の数値について閾値を確認させてもらうのですが、
「上限値は無 限です」
と回答されたら拳を固く握りしめてください。
また、閾値の情報を共有して頂いても、そこで終わりではありません。
「その閾値を超えられるか」「閾値を超える操作をした場合どうなるか」
まで確認しましょう。
レベル99に達したら、そこでゲームを止めるでしょうか。
所持金がMAXになったら、そこで資金稼ぎをしなくなるでしょうか。
もしかしたら、表示上では上限に達していても、内部では数値をカウントし続けていて思わぬ問題を起こそうとしているかもしれません。
なお、現在は3D表示のゲームが主流ですが、当たり判定(Collision/衝突判定)も形を変えた閾値と捉えています。
ログラスでの学び
閾値については、当然ログラスを始めとしたBtoBサービスでも重要視される観点であろうと考えます。
実際の数字だけではなく、例えば取り扱える科目や部署の数など、一見して見えづらいもののお客様の業態・規模によっては想定外となり得ると考え、テストに組み込んでいきます。
2)矛盾処理
いままでの経験
約20年前、ニンテンドーDSというゲームハードが発売されました。世界でも大人気のハードでしたが、自分は違う意味でワクワクしていました。
ボタンとタッチスクリーンが同時に操作できる。
そう、メニューの「決定」と「キャンセル」、「上」と「下」を同時に押す事が可能になったのです。
このように、「アクセルとブレーキを同時に踏むような処理があり得る」機能・要素を想定して処理の優先順位を決める(たいていはブレーキを踏む方を優先)必要があります。
先に挙げたのは「操作の矛盾処理」ですが、同様に特定の組み合わせ等で「設定の矛盾処理」も発生し得ます。
一例としては「ミスとクリアを同時に発生させる」「特定の条件で、相反する組織へ同時に所属できる」といったものになります。
ログラスでの学び
ログラスでは操作での矛盾はリアルタイム性をそこまで求められないため、操作面での矛盾というのはほぼないものと考えています。
どちらかというと、入力したデータと設定の矛盾、例えば「すでに存在しない科目に計上しようとしていた」などは、長期で利用頂いている顧客ほど発生の確率が上がるパターンでは…と推測しています。
3)重ね処理
いままでの経験
Aの処理を行なっている最中に別の処理Bを行う等、異なる処理を重ねる・または同時に行うケースは往々にしてあり得ます。特にマルチプレイ系のゲームでは起こり得るケースと考えます。
メンバーが全員揃ってさぁ戦いに出撃！…と思ったら同時にチームを離脱していた、など。
その検知タイミングや、条件を満たさない場合の処理・通知なども考慮する必要があります。
さもないと、仲間が抜けて自分一人で「参加する仲間が多いほど強くなる龍」と戦う事態に陥るかもしれません。
ログラスでの学び
リアルタイムでの操作を必ずしも求められないログラスではあまりないかな…と考えていましたが、調べてみると意外にありますね。
複数のお客様での同時編集や、ダウンロード・アップロード中の編集・更新など。これらは今後のテストでも「あり得る事」として、観点は漏らさないように留意していきます。
4)中断処理
いままでの経験
スマホでゲームをプレイ中に電話がかかってきたので一度電話に出る→ゲームに戻る、といった事はこのご時世よくあります。通信状態により一時的に操作できない、などもあり得ますね。
こちらも、中断〜復帰までの処理や、どのような状態で復帰するかに応じた処理(例えばアクション性を求められるのであればいったんポーズをかける、ネットワークのマルチプレイであれば早めに離脱処理を入れてあげる代わりに、通信が復帰したら同じ場所へなど)を想定する必要があります。
ガチャを回した瞬間に通信が途絶→復帰したらお金は引かれているけどガチャは回った事になっていなかった、などは最悪のケースといえるでしょう。
ログラスでの学び
この後の「処理負荷」にも関連しますが、実際にログラスを利用されているお客様の状況を確認した所、特に大容量のデータをアップロード・ダウンロードされるお客様が多数いらっしゃいます。
また、過去には処理中断から復帰できなくなるという事例も発生したと社内で聞きました(すでに対応済み)。
ログラスを利用される環境では、通信状態が頻繁に変化するケースは想定しなくてもよさそうに思いますが、取り扱うデータの量が多くなるため、各種処理中に中断が発生しえるケースは引き続き観点に取り入れていきます。
5)処理負荷
いままでの経験
ゲームにおける負荷のかかり方は2種類あると考えています。
a)瞬間的な処理負荷
古のゲーマーの方なら 「秒間16連射」 という単語を聞いた事があるかと思います。また、意図せずして普通のメニューでも「パパン」と連打してしまうケースや、プレイの仕方がよく分からずガチャガチャとコントローラを操作してしまう、いわゆるガチャプレイを行われる場合もあるでしょう。
どこまでの操作を有効とするのか、無効となった以降の操作は無視してよいのか、といった基準の決めがないと、連続で入力した履歴が残り続け、いつまでも他の操作が行えないといったケースがあり得ます(ありました)。
操作以外ですと、例えばSNSで年を越した瞬間の「あけおめ」ラッシュなども該当するでしょう。もはや風物詩ですね。
b)長期的な処理負荷
こちらは大量にエネミーが出現するタイプのゲームや、マルチプレイのオンラインゲームでユーザーが一定の場所に多数集まる、といったケースが想定されます。
オンラインゲームの経験者であれば「トレイン」という迷惑行為(プレイヤーに付いてくる敵を大量に引き連れてエリア内を巡り歩き、操作を重くさせたり周囲のプレイヤーを襲わせたりする)をご存じの方もいるかと思います。
過去にサーバーの処理上限テストでは、ルーム入室の上限までユーザーが入った後に
「1分間声出し、始め！」
の号令に合わせて、全員が一斉にテキストチャットを大量に投下する、といった事もやっていました。
ログラスでの学び
「中断処理」の項でも述べましたが、ログラスではお客様がお持ちの大量かつ多様な経営管理データを投入でき、効率よく分析につなげられるかが非常に重要だと考えています。
データ量もさる事ながら、その階層や科目数・部署や子会社の数といった要素でも変わり得る内容ですので、処理の高速化とともに、お客様に適切に状況を通知するといった対応も必要であろうと考えます。
6)エラー処理及び通知
いままでの経験
この項だけ、多少毛色が異なりまして。
先の1〜5の各種エッジケースにて、ユーザーの行なった操作や処理に制限・中断が発生する場合、それをユーザーに伝える必要が生じます。また、可能であればユーザーに自己解決してもらえれば不満や問い合わせの負荷低減にもつながります。
よって、発生する問題に応じて適切なエラーを通知するとともに、その エラーメッセージの内容(発生した事象が正しく伝わるか、自己解決できる場合はその内容を示唆しているか) も求められます。
ここが不足していると、ユーザーの不満〜ユーザー離れにも直結し得ます。
ログラスでの学び
自分が研修で弊社サービス『経営管理ログラス』を触り始めた際、システムを理解しないままあれこれ試してエラー連発させたのですが、その時に感じたのが
「画面ごとにエラーメッセージの粒度が違うな？」
「処理によってエラーメッセージの出るタイミングがちょっと違うな？」
といったサービス全体の「エラーの伝え方」に対する課題でした(同期入社の、同じくゲーム業界から転身したQAエンジニアと話した際も、同じ感想を抱いたようです)。
これが分かっただけでも、エラー出しまくった甲斐があったな！と感じたものです。
これらはテスト観点と同時に、UI/UX改善・向上の観点でも積極的に取り組んでいきたい所です。
※すでに社内デザイナーは同様の課題を認識しており、改善に向けた取り組みを進めております。今後よりよい体験をお届けできる事を期待して頂ければ幸いです
最後に
今回は、過去の経験を基に、BtoCとBtoBのテストの違いを題材として記事を取りまとめてみました。
今後もログラスでのテスト経験を積むとともに、顧客によりよい価値を提供できるよう、テスト手法・テスト観点のマリアージュが出来ればと考えています。
拙い記事で恐縮ですが、最後までお読み頂きありがとうございました。
Discussion