デモはなぜ失敗するのでしょう？

先日のデベロッパーキャンプのセッションビデオをせっせと作っています。今回、次期バージョンのJBuilderに搭載予定の「Application Factories」という新機能を、デモを交えて紹介しました。もちろん開発途中の機能で、プレゼンを担当したDavid Iは、「先週金曜日のビルド」を入れて、デモに挑みました。

デモには大なり、小なりのミスがつきものです。しかし、ベータバージョンは、思わぬところで動作が安定しなかったり、十分にテストされつくしていないために、本番ではまってしまうことがあります。今回のDavidのデモは、そんなに大事件というほどではありませんでしたが、「ベータ版なのでごめんなさい」とJBuilderを再起動する一幕がありました。

もっとも、ビデオ版では、その辺は編集しておりまして、フィールドテスト版のあやしいスプラッシュスクリーンもご覧いただけない仕様になっています。

こちらがお蔵入りになった再起動中のシーン

さて、ベータバージョンで果敢に行うデモだけでなくても、しばしばデモに失敗するケースに遭遇します。特に開発ツール系のデモは、いくつかのステップを踏んで、物を作っていくため、結構綱渡りです。もちろん、デモに失敗したからといって、プレゼンがだめかというとそういうわけでもなく、「こんな風につくるのか」というイメージは伝わるものなのですが、やっぱり、バシッと決めたいですよね。

そこで、過去の経験から、デモに失敗するケースを考察してみました。

なんといってもタイプミスである
変数名を間違えている、セミコロンを忘れた、コード補完でうっかり隣のメソッドを選んでしまった、など、とにかくコード入力で間違えるというのがありがちなパターン。対策としては、おちついてゆっくりタイプする、弾き語りのように、しゃべりながらタイプできる練習をする、など。あと、そもそもタイプ量を減らしてしまう。最悪はまったときのことを考えて、メモ帳なんかにコードの断片を用意しておく、などもよい方法です。タイピングではまっていると、会場がしーんとなってますます冷や汗たらたらなので、脱出パラシュートは常備しておきましょう。

手順をひとつ飛ばす
これもありがちな間違い。最初にやらなきゃいけない設定を忘れたとか、オプションのチェックをひとつ忘れたとか。ウィザードを再実行してはまってしまった、なんていうのはよく聞く話です。これを防ぐには、やはり手順リスト。舞台では、指差し確認して進めましょう。

環境が違う！
「何度も練習したのに本番のマシンの設定が違うから～」これは、プロとしては恥ずかしい言い訳です。やはり本番環境でしっかりチェックしておきましょう。ネットワーク関係は、当日の状況にも依存するので、必ずうまくつながらないときのバックアップシナリオを考えておきましょう。

魔が差す
好調に用意したデモが進み、お客さんの反応も上々で、ついうっかり、いつもより余計に見せてしまうことがあります。そのサービス精神はすばらしいのですが、一度もやったことないことを舞台の上で見せてはいけません。しばしば、絶好調のデモが、悪夢と化してしまいます。

本番に限ってマシンが重い！
おはらいが足りないのか分かりませんが、本番に限ってマシンが重く、実行ボタンを押したきりなかなか戻ってこないことなどがあります。ソフトも緊張しているんでしょうが、たいていの場合、リハーサルで本番と同じ順序、同じソフトの起動状況で確認していないことが原因です。本番では裏でPowerPointが動いていたり、いくつもデモを実行してきて、ファイルをいくつも開いていたりという状況が、練習のときとは違っていたりするものです。

色々書いてきましたが、よいデモというのは、必ずしも全部見せるてんこ盛りのデモではない、という点が重要です。デモによって何を見せたいのか、プレゼンで説明したことの何を補いたいかをよく吟味して、できるだけシンプルに分かりやすく見せるようにシナリオを組み立てるべきです。そうすれば、失敗はしないはずです。多分そのはずなんだけどなぁ。