もっと良くなる ! あなたの「デモ」を良くする 8 Tips

全てのデモには「目的 (何を伝えたいか)」が必要です。

• コンソール操作の簡単さを伝えたい !
• ターミナル操作で正常に動いていることを伝えたい !
• このサービスとこのサービスをうまく連携できていることを伝えたい !

逆に明確な目的を決めず、何となくデモを作ってしまうと、まとまりがなく、長々と操作を続けてる姿を見せるだけになってしまいます。デモを見てる側も「これは何を見せられているんだろう・・・。」という気持ちになってしまう可能性もあります。

また「デモ説明スライド」は実際にお客様に見せますが、見せない個人用のドキュメントもあわせて作っています。私は以下の 2 点をまとめています。

• デモ手順
• 想定質問と回答案

特に「デモ手順」は重要で、全てのデモ手順を覚えておくことはできません。アドリブで操作をしてしまうとうまく動かず「あれ・・・。動かないですねぇ・・・。えーっと、えーっと」と慌てている姿をお見せすることになってしまいます。簡単なデモであっても、デモ手順をまとめておくと、安心して進められます。

また「デモ説明スライド」でお客様がデモを見て学ぶ準備が整う付随効果として「デモを見ながらお客様が新しい疑問を抱ける」ことが挙げられます。デモに対する質疑応答を盛り上げるのも重要で Tips. 6 で紹介しますが、想定質問と回答案をまとめておくことで、安心して回答できます。

デモで使う環境名やリソース名に名前を付けるときに「具体的で・わかりやすく・意味のある名前」を付けることを意識しています。アンチパターンは demo や test など、特に意味がなくわかりにくい名前を付けてしまうことです。お客様がデモを見たときにどういう意味なのか伝わりづらく、また自分自身も数ヶ月後にデモを見直すと、何をデモしたのかわからなくなってしまうのではないでしょうか。

例えば AWS Lambda 関数を新しく作るときに、AWS Lambda 関数名を demo にして作ることもできますが、具体的にどういう用途なのかというストーリー性がなく「ただデモを眺めているだけ」になってしまいます。そこで、AWS Lambda 関数名を resize-image-demo にするだけでも「画像をリサイズする AWS Lambda 関数の例なんだな」と、より具体的にストーリーを伝えられます。

また、名前に関して、もう 1 つ重要な Tips を紹介します。それは「重複しない名前を使うこと」です。

よく見るアンチパターンを紹介しましょう。「さて、“demo” という AWS Lambda 関数を作ってみたいと思います。あれ・・・。えーっとエラーが出ますね。なになに "その名前が付いた関数がすでに存在します。" あー、なるほど。さっき動作確認をしたときに同じ名前で作ってしまって消し忘れていました。では今日は "demo2" にしましょう。」見覚えのある光景なのではないでしょうか。

そこで「日付」や「2, 3 文字のランダム文字列」など、何かしら重複しないサフィックス (接尾辞) を使うことで回避できます。これらの Tips を組み合わせると AWS Lambda 関数名 demo よりも resize-image-demo が良く、さらに resize-image-demo-20220601 の方が繰り返しに強い名前になります。

わかりやすい名前に関しては以下の記事にもまとめているので合わせてご覧ください。

初学者にもわかりやすい「名前」って何だろう ? »

例えば Amazon S3 バケットや AWS Lambda 関数などを「その場で作って消す」デモであれば、コンソール操作でササッと見せられますが、事前にデモ環境を構築した状態で「伝えたいところだけ」デモをするパターンも多いと思います。デモで本当に伝えたい部分にフォーカスするためにも重要です。

• Amazon EC2 インスタンスを起動するために Amazon VPC を事前に構築しておく
• アプリケーションをデプロイするために Amazon EC2 インスタンスを事前に起動しておく

そして、多くのデモ環境は継続的に使います。設定を変えることもあるでしょうし、デモ内容を修正することもあります。また、異なる AWS アカウントにデモ環境を移動することもあります。そのときに、コンソール操作で構築をしてしまうと、再現性が低くなってしまいます。それなりに複雑な設定だったりすると、同じ状態に戻せなくなるかもしれません。

そこで、Infrastructure as Code です。AWS CloudFormation でも AWS CDK でも Terraform でも良いですし、AWS CLI でも良いと思います。使い慣れたツールを活用して、デモ環境を簡単に再現でき、継続的にメンテナンスできるようにしておくことが重要です。また、データベースなどを構築するときに、初期データセットを投入するような作業も手作業にせず、自動化しておくと便利です。

さらに GitHub のリポジトリに表示されるドキュメントファイル README.md に Tips.2 で紹介した「デモ説明スライド」と「デモ手順」と「想定質問と回答案」をまとめています。他にもデモを作るときに「考えた (もしくは諦めた) 設計判断」も一緒にまとめています。これは私が個人的に好きな Design Doc や ADR (Architecture Decision Record) というプラクティスにインスパイアされたものです。

Tips. 4 で紹介した通り、デモに必要な環境を事前に構築しておくと、デモ中の不要な待ち時間を減らせます。しかし、デモ手順の関係上、どうしても待ち時間が発生してしまうことがあります。以下はサンプルです。

• Amazon EC2 インスタンスを起動する (30 秒 ~)
• Amazon EC2 Auto Scaling でスケールアウトする (4, 5 分 ~)
• 複数の Amazon EC2 インスタンスにローリングデプロイをする (10 分 ~)
• Amazon EKS クラスタ (コントロールプレーンとデータプレーン) を構築する (15 分 ~)

デモは内容だけではなく、実はうまく見せることでより「映えるデモ」になります。

よく見るアンチパターンは、画面全体を表示してしまって情報量が多く「お客様がどこを見れば良いのかわからない」という状態になっていることです。デモを作った本人は当然ながら着目する場所を把握していますが、お客様の立場だと、実はわかりにくかったりします。

特にオンラインでは「ここ !」や「そこ !」という「相対的な位置表現」は伝わりにくいですし、マウスカーソルを高速に動かしても、実は配信遅延が起きていて、わかりにくいということさえあります。