企画の2つの方向性 ～ トップダウンとボトムアップ
さて、ジョーク系のWebサービスの企画を作る際、筆者は「トップダウン系」と「ボトムアップ系」の2つのアプローチを取ることが多いです。
トップダウン系は、まず「こういったものが作りたい」という明確な目標があり、その実現を目指して必要な技術を探したり、プログラムを作成したりして完成させる方法です。
ボトムアップ系は「こういった技術を使いたい」という部品がまずあり、その利用を目指してユーザーが喜びそうなサービスを考えて応用していく方法です。
企画の方向性による必要とされるものの違い
前者のトップダウン系では主に「センス」が要求されます。作りたいと考えているものがユーザーの求めている物と大きく離れていると、どんなに凄い技術を投入してもユーザーの評価は期待できません。
逆に後者のボトムアップ系では主に「ロジック」が要求されます。どうすればユーザーが喜ぶかを理詰めで考えながら、使いたい技術を利用する方法も考えなければならないからです。
とはいえ、どちらも割合の違いです。トップダウン系にせよボトムアップ系にせよ、センスとロジックの両方を満たさなければ、面白いジョーク系Webサービスが成立しません。
筆者が作ったWebサービスの発端
ちなみに、筆者が作ったWebサービスで言うと「全自動4コマ」はトップダウン系の企画です。「ネットを使って4コママンガを自動で作りたい」「そうすれば面白いはずだ」そういった明確なゴールがあり、その実現のために技術の探索とプログラムの開発を行いました。
一方「オートペディア」はボトムアップ系の企画です。「ネットからの情報収集、キーワード抽出、文章の評価・抽出、文章加工の技術がある」「これで何を作れば面白いだろうか？」といった具合に、技術ありきで企画を練って最終的なWebサービスまで作り上げていきました。
というわけで、「オートペディア」では、ボトムアップ的な「技術」から「笑い」への昇華をテーマにWebサービスの設計を行いました。以下、筆者の経験に基づいて考える「笑いの作り方」を紹介します。同じようにすれば「笑い」を必ず作り出せるとは限りませんが、他人のアプローチの仕方を知ることで、読者の方がより面白いWebサービスを立ち上げる際の一助になれば幸いです。
笑いとは何か？ ～ 笑いのメカニズム
先日、以下のような内容のメールをもらいました。
「Webサービスを作っているのですが面白くなりません。どうしてでしょうか？」
理由は簡単です。それは「笑いの仕掛け」が入っていないからです。
人間の2つの「笑い」
では、「笑い」とは何でしょうか？ シンプルに考えるために「笑い」を抽象化してみたいと思います。諸説あるでしょうが、ここでは「笑い」を「認知や思考の例外処理」と定義します。これはプログラムを設計する時と同じようなとらえ方です。通常の認知や思考の処理があり、そこにエラーが生じると「笑い」処理が行われるという考え方です。以下、この文脈で「笑い」を考えていきます。
人間は大きく分けて2種類の出来事に遭遇した時に笑います。ひとつは「予測が裏切られた時」、もうひとつは「予測通りになった時」です。人間の「笑い」は、大別するとこの2つに集約されます（注：ここでは、腋の下をくすぐった場合のような肉体的な刺激による笑いは省きます）。
人間の「笑い」という行動は知的活動です。人間は何かをする場合には結果を予測して行動します。そうすることで危険を避けて、生存する可能性を高める進化をしてきたからです。「笑い」は人間の脳内の活動に大きく関係しています。
予測が裏切られた時の笑い
まず「予測が裏切られた時の笑い」について説明します。人間は予測したことが裏切られた時に笑います。例えば、ある人が「野球をしようぜ」と言ったとします。それを聞いた人は野球のユニフォームを着てグラウンドに行くでしょう。そこで提案した本人がサッカーのユニフォームを着て、得意げに待っていたらどうでしょうか。その姿を見た人は意表をつかれ、思わず笑うかもしれません。「おいおい、野球って言っただろう！」とツッコミながら。
これは「当然野球のユニフォームを着ている」と思った相手が、違う格好をしていたせいで起こる笑いです。笑った人は「野球のユニフォームを着ている」と予測し、それが裏切られたことで「笑い」という反応を示したことになります。
この「笑い」をプログラム的に考えてみましょう。これは、認知や思考にエラーが起こった場合の例外処理ととらえることができます。予期できない状況に遭遇した時（tryで思考や認知のエラーを検出した時）、「笑い」という肉体反応を起こし（catch内で肉体反応を起こし）、そこで思考をいったん断ち切り、脳内のバッファを初期化して次の思考に移れるようにする。そういったアルゴリズムととらえることができます。
予測通りになった時の笑い
対して「予測通りになった時の笑い」は予測が当たったことによるものです。これは例外処理ではありません。例えば、目標を達成した時の喜びの笑い。繰り返しギャグを見た時に予想通りになったことに対する笑い。こういった笑いが「予測通りになった時の笑い」になります。
目標達成による「笑い」は、期待感の大きさによって生まれる「緊張」が「解放」されることによって発生するものと考えることができます。また、「繰り返しギャグ」の「笑い」は、事前に同じような「笑い」が与えられており、その繰り返しが起こることを期待して、実際に起こって満足するという流れになっているとみなせます。
どちらの「笑い」も「予測に対する期待感」が“過剰に大きい”ことが前提となります。そしてその期待が満たされることで弛緩し、「笑い」が生じることになると考えられます。
2つの笑いのまとめ
このように人間には2種類の「笑い」があります。そして、ジョーク系のWebサービスでは前者の「予測が裏切られた時の笑い」を積極的に利用します。
それでは、Webサービスのための「笑い」について考えていきましょう。
この人間の「笑い」の仕組みの考察から分かることが1つあります。それは何でしょうか？ それは、「笑い」の前には「予測」が必要だということです。
これらの考え方から、ジョーク系のWebサービスで人を笑わせるには「予測」「予測から想定される結果」「予測からずれた結果」という3つのイメージが作り手側になければならないと推測されます。つまり、これらのイメージがきちんとなければ、どれだけデザインに凝ったり、データ数を用意してもユーザーが面白いと思う結果は提供できないということになります。
少し例を挙げてみましょう。有名なジョーク系のWebサービスに「脳内メーカー」があります。これは「脳内を文字で表す」というサービスです。このコンテンツでは、「脳内を文字で表す」という前振りで、まずはユーザーに「だいたいこんなものが出るのではないか」という期待を持たせます。そして実際に名前を入力してボタンを押させた後、過激な文字や、過剰な文字数でもって、ユーザーの想像の斜め上の結果を表示します。「うわっ、“欲”がこんなにある！」「げっ、“遊”だらけじゃないか！」と予測を裏切るわけです。そうして「予測が裏切られた時の笑い」を発生させています。
それでは話を元に戻しましょう。以後は、この前提を元にどのようにジョーク系のWebサービスを開発していけばよいのかを考えていきます。
| 期待 | |||
| 普通 | 過剰 | ||
| 予測 | 予測通り | なし | 笑い |
| 予測を裏切る | 笑い | 失望 | |
