AIで作ったアプリを「他人」としてテストする方法（ユーザーがバグを見つける前に）

なぜ、他人が使うとバグが見つかるのか？

それは、あなたが自分で作ったものの使い方をすでに完璧に知っているからだ——マウスを正しい場所に動かし、過去の日付を試すことはなく、デスクトップでしかテストしていない。「他人テスト」とは、完成したアプリをまだ見たことのない誰かに渡し、実際のユーザーより先に、何が壊れ、何に戸惑い、何で手が止まるのかをリアルタイムで観察することだ。

AIビルダーで予約アプリを作ったとする。自分でテストする——日付を選び、名前を入力し、確定する。ちゃんと動く。

同僚に試してもらう——日付を選ぶと、タイムゾーンがズレている。戸惑う。そして離脱する。

お母さんに試してもらう——うっかり過去の日付を選んだら、アプリがクラッシュする。

スマホで友人に試してもらう——日付ピッカーが動かない（フィールドをタップできない）。

どれも直すのが難しいバグではない。ただ、どれもあなたには見えない。自分が作ったものの使い方を完璧に知っているからだ。他人なら、あなたが見落としたエッジケースをすべて見つけてくれる。朗報なのは、他人テストはお金がかからず、それでいて本当に重要な問題を拾い上げてくれるということだ。

「他人」としてアプリをテストするには？

アプリの存在すら知らない誰かに渡し、ぶっつけ本番で使ってもらい、何がうまく動かず、何に戸惑うかをメモする。QAチームは要らない。必要なのは1人と10分だけだ。

方法1：本物の人に頼む（所要15分）

友人にメッセージを送る。「ちょっとこれ試して、感想教えてくれる？」リンクを渡し、5〜10分ほど自由に触ってもらったら、こう聞く。

何をしようとした？
想像していた通りに動いた？
どこで戸惑った？
どこを変えたい？

意外な答えが返ってくるはずだ。「送信ボタンが見つからなかった」（モーダルの中に隠れていたから）。「メールアドレスの入力が必須だと知らなかった」（必須マークを付けていなかったから）。「水曜日を選んだのに、なぜ予約が火曜日になってるの？」（自分では気づかなかったタイムゾーンの問題）。

なぜ効くのか： 本物の人は、正常なルートだけでなく、あなたが思いもしなかった「うっかり壊れている」ルートまで踏んでくれる。

注意点： 相手はたぶんあなたに気を使う。本当にダメな部分でも、あなたを傷つけたくなくて言わないかもしれない。言葉より、表情を見ること。

方法2：普段使わない端末でテストする（所要5分）

デスクトップで作ったなら、スマホでテストする。スマホで作ったなら、タブレットでテストする。

アプリを開いて、次を試す。

端に近いボタンをタップする（切れているかもしれない）
何も考えずにスクロールする（ちゃんと動く？）
日付を入力する（ちゃんとした日付ピッカーがある？それとも手入力前提？）
アプリが画像を扱うなら、写真を撮ってみる（形式は？サイズは？速さは？）

たいていのAIビルダーはレスポンシブレイアウトをかなりうまく作ってくれる。それでも、幅375pxや低速回線で何が壊れるかは、実際に見ると驚くはずだ。

なぜ効くのか： モバイルでは、アプリの体感速度も操作の仕方もまるで別物になる。デスクトップなら2秒のデータベース呼び出しも気にならないが、4G回線のモバイルだと「壊れている」ように感じられる。

注意点： これはあなたの根気次第だ。1つの端末で、1つのフローを最初から最後まで試す。あちこち見て回るのではなく、タスクをこなすこと。

方法3：チェックリストテスト（所要10分）

まだ本物の人にお願いする準備ができていないなら、自分自身を「他人」のつもりでテストする。

アプリを開く。何を作っていたかは_忘れる_。このアプリは何をするものだと思う？
クリックできそうなものを最初に見つけたものから選ぶ。それに何をさせたかったかは_考えない_。想像通りに動く？
ヘルプテキストを見ずに、メインのタスク（何かを予約する、フォームに入力する、投稿を作るなど）を最後までやってみる。一発でうまくいった？
必須項目を探す。目に見える形でマークされている？（色だけでは、誰にでも見えるとは限らない。）
わざとミスをする（何かを空欄にする、不正なデータを入力する）。アプリは何が間違っているか教えてくれる？
スマホで試す。文字は読める？ボタンはタップできる？

これは本物のテスターの代わりにはならないが、まったくテストせずにリリースするよりはずっとましだ。

誰かにテストしてもらうとき、何を観察すべきか？

ためらい、回避行動、わかりにくいエラー表示、もっさりしたモバイル体験、そして消えたように見えるデータ——これらはすべて、具体的で直せる問題を指し示している。

ためらい： ボタンをクリックする前に一瞬止まるなら、そのボタンはわかりやすくない。「これって入力するものですか？」と聞かれるなら、そのフィールドの表示が不十分だ。

回避行動： 何かがうまくいかず、別のやり方を試すなら、そこにはUXの断崖がある。（ボタンをクリックする代わりにEnterキーでフォームを送信しようとする。×ボタンの代わりにトリプルクリックでフィールドを消そうとする。）

エラー表示： ネットワークエラー、バリデーションエラー、タイムアウトなど何かが失敗したとき、アプリはどうすればいいかを教えてくれる？それとも、ただ赤い箱を怒ったように表示するだけ？

モバイル体験： タップが反応するまで3秒かかるなら、ユーザーはアプリが壊れていると思うだろう（実際には壊れておらず、ただ回線が遅いだけかもしれないが、_壊れているように感じる_ことに変わりはない）。コントラストが低すぎて文字が読めないなら、ユーザーは文句を言わない。ただ離れていくだけだ。

データの混乱： 何かを作成したのに後から見つけられない、あるいは保存したつもりが保存されていない——これはデータベーススキーマの中に潜むバグだ。ビルダーはおそらく、あなたが指示した通りに動いている。ただ、その指示の内容が、ユーザーの期待と食い違っているのだ。

他人が見つけたバグは、AIビルダーで直せるのか？

直せる。あなたが「問題だと思うこと」ではなく「実際に見たこと」を説明しさえすれば、ビルダーがそのまま修正してくれる。自分の手で直す必要はない。

「日付フィールドがモバイルで動かない」 → ビルダーが、ちゃんとした日付ピッカーに差し替えてくれる。
「フォームのどの項目が必須かわからない」 → ビルダーが、視覚的な目印を追加してくれる。
「送信する場所が見つからない」 → ビルダーが、ボタンを大きくするか、位置を変えてくれる。
「入力ミスをしても、何が悪かったのかわからない」 → ビルダーが、インラインのバリデーションを追加してくれる。

大事なのは、「問題だと思うこと」ではなく「実際に見たこと」を具体的に伝えることだ。「アプリがわかりにくい」では役に立たない。「3つのフィールドを入力したあと、次にどこをクリックすればいいかわからなかった」なら役に立つ。

毎回、他人テストを

「完成した」と言う前に、本物のユーザーに共有する前に、あなたが作ったと知らない誰かに渡そう。ぶっつけ本番で使ってもらい、何が壊れるかをメモする。

見つかるはずだ。

存在すら知らなかったバグ
思っていたより難しいワークフロー
あなたが当然だと思っていたのに、ユーザーは共有していない前提

すばらしいのは、このテストが無料で、10分しかかからず、それでいて「これ、なんで動かないの？」というメッセージを半分に減らしてくれることだ。

スマホのタイムゾーンをどこか変な場所に切り替えて、あなたのアプリを使ってみてほしい。何か面白いことに気づいたら、また教えてほしい。