オズの魔法使い

ユーザテストを行うためにはプロトタイプが必要です。静的なインターフェイスならば目次ページとコンテンツページをいくつか用意するだけで済みますが、動的なインターフェイスの場合はそうはいきません。

例えば、会員登録であれば、「登録フォームに必要事項を入力する→フォームを送信する→送信確認ページが表示される→登録確認メールが自動的に送信される」という一連のプロセスをシミュレーションしなければなりません。普通に考えれば、小規模とはいえシステム開発を行うことになってしまいます。

ところが、ソフトウェアには“バグ”が付き物です。簡単なプロトタイプであっても、なかなか思うように動いてくれません。「テストを行うためのソフトウェアのテスト」を繰り返す羽目に陥ると、設計チームは疲れ果ててしまいます。

そんな時に、ちょっとしたトリックを使うと、システム開発を回避できることがあります。上記の例ならば、入力する内容を事前に決めておけば、入力データを動的に反映させる必要がなくなるので、送信ボタンを押した後は、事前に用意したデータ入力済みページを表示するだけで構いません。また、登録確認メールは、テスト関係者がタイミングを見計らって普通のメールソフトから送信しても、ユーザには見分けが付きません。

“段ボール箱”の自動販売機でも、人間が中に入れば商品を販売できます。音声コマンドを人間が聞いてシステムに入力を行えば、ユーザは声で操作できているように感じます。このようにコンピュータの代わりに「カーテンの陰から人が操作」して、あたかもシステムが動作しているように見せる手法を『オズの魔法使い』と言います。

映画「オズの魔法使い」では、クライマックスのシーンで恐ろしい姿をした巨大な「オズの大王」が現れます。人々が恐れおののいてひれ伏すのを横目に、主人公ドロシーが部屋の隅にある“カーテン”を開けると、そこでは貧相な老人が装置を操っていたのでした。なお、原作では、この老人は“ついたて”の向こうに隠れていました。

もちろん、これでシステムの動作を全てシミュレーションできる訳ではありませんが、工夫しだいでは、プロトタイプ制作の時間とコストを大幅に削減できます。「動作＝システム開発」と思い込むべきではありません。ユーザテストとは“お芝居”に過ぎません。芝居で使う小道具は「一見するとそう見える」程度で十分なのです。

【参考情報】

（１）Jeff Kelley: Where did the usability term Wizard of Oz come from?
http://www.musicman.net/oz.html
「オズの魔法使い」の名付け親による解説です。Kelly氏はIBMのワトソン研究所で人間工学やHCIを研究していた研究者であり、かつセミプロのクラシック歌手でもあるそうです。

（２）Alertbox： ユーザテストから得られる現実行動
http://www.usability.gr.jp/alertbox/20050214.html
ニールセン博士も「ユーザテストの参加者のほとんどは、“ウソ臭さ”を許容する」としています。