初期制作の構成要素

1. 1. コンテンツプラン
   2. 外部基調講演者のキャスティングとストーリー設計
   3. スポンサーリクルーティング
   4. イベント事務局の設置
   5. イベント管理プラットフォームの選定、開発
      1. 必要な機能を先に決める
      2. このブログが想定するオンラインイベントのPF要件は？
      3. プラットフォームは代理店に提案してもらう
      4. 開発には時間がかかる
      5. 要件定義~開発
   6. デザインコンセプト開発
   7. イベントサイトのラフデザイン
   8. イベントサイトの機能要件定義
   9. 収録会場、配信計画（事前収録 vs ライブ配信、会場の選定）
   10. 集客計画（社内、広告、ソーシャル、パートナーなど）
   11. インセンティブ計画

みんな大好き、プラットフォーム選定

オンラインイベントをやるとなると、いきなりプラットフォームから検討をスタートするケースを見ることがありますが、猿人的にはあまりお勧めしません。

プラットフォームから入ってしまうと、そのプラットフォームの機能や癖に縛られた状態で、イベント企画を考えていくことになってしまうからです。「すごくたくさん機能があるし、これで間違いない！」と思って選定したけれど、プロジェクトが進んで行く過程で、「この機能もあの機能も使わない」とか、逆に「あれはできないの？これはできないの？」という現象に陥り、機能に振り回されるような結果になることもあります。

どんな機能が必要なのかを先に決める

じゃーどうやったら機能の袋小路に入らずに済むのか？というと、シンプルに「目的を達成するために最低限どんな機能が必要になるのか？」を選定するタイミングで明確に持っていればいいだけの話です。初期計画、基本計画で検討・決定してきた内容が、今回のオンラインイベントに「どんな機能をもっていればいいのか？」を必然的に決めてくれるはずです。

このブログが想定するオンラインイベントで考えてみる

一例として、このブログが想定しているオンラインイベントで必要とされる要件はというと、こんな感じになります。

※便宜上、あんまり複雑になりすぎないようにシンプルにしていますので、その点はご了承あれ。

【全体共通】

• UIデザインはカスタマイズ可能か

• 機能はカスタマイズ可能か

【登録関連機能】

• DB（登録フォーム）を自由に設計できるか

• 講演ごとに事前登録ができるか

• 登録時アンケート設定ができるか

• カレンダー登録ができるか

• 登録情報（プロフィールや事前登録講演）をユーザー自身が編集できるか自動返信やステップ配信などメール設定はできるか

• その他

【イベント機能】

• ライブ配信、疑似ライブ配信、オンデマンド配信ができるか

• 目標数に対して、配信時の同時接続数は十分か

• 各配信にアンケート設定ができるか

• チャットやQ＆A、投票機能はあるか

• 講演資料、関連資料や動画の掲載ができるか

• アーカイブ配信は可能か

• 商談機能はあるか

• 展示を3Dブースのような見せ方はできるか

※展示については視聴者にどんなエクスペリエンスを提供したいかにより、機能と費用、納期が大きく変動します。得たい効果とともに明確にしておきましょう。

【管理者関連機能】

• 管理画面は直感的に扱えるか

• 管理ユーザー毎のアクセス制限を設定できるか

• 参加承認/否認機能はあるか

• ドメイン排除は可能か

• 検索機能は十分か

• 必要なログがとれるか

※どこまでのログを必要とするかは、企業によって様々です。イベント全体への参加者数、各講演視聴者数/視聴回数/視聴時間、資料PDFのDL回数、オンデマンド動画の再生回数、アンケート回答など、何をどこまで取りたいかは、予め明確にしておくと良いです。

プラットフォームは代理店に提案してもらう

盛り込みたい機能を明らかにしたら、次は実際にプラットフォームを探すフェーズになります。ここでのポイントは「イベント開催の支援パートナーに選んだ代理店に提案してもらう」ことです。Google検索すればたくさんのプラットフォームを見つけることはできますが、それぞれの詳細を調査するだけで、かなりの時間を費やすことになってしまいます。代理店はいろいろなプラットフォームを使用した経験もありますし、今回のイベント要件に合わせて適切なプラットフォームを提案してくれるはずです。

開発には時間がかかる

さて、選定が終わったからといって、すぐにイベントサイトを作っていけるわけではありません。たいていのBtoBオンラインイベントの場合、主催企業のブランディングをしっかりと反映させたデザインをサイト上に実現する必要がありますし、ステークホルダーも多いためプラットフォームが予め装備しているシンプルな機能だけでは不十分なことが多いです。大きくカスタマイズを行う、つまり、開発が必要になることになります。

フロントエンドだけでなく、バックエンドにも開発が必要になることも多々ありますので、開発にはかなりの時間を要します。ここは、リアルイベントの制作を行う時とは大きく異なるポイントとなりますので、イベント担当責任者は【カスタマイズには時間がかかるものである】としっかり理解しておく必要があります。

要件定義~開発

選定の際にある程度の機能要件を出しておいたとして、では今回のイベントの中でそれら機能がどのように実装されていて欲しいのかを固めていく作業に入っていきます。いわゆる要件定義です。

実はここが最大に重要なマイルストーンのひとつでもあります。

ここで決めた要件に沿って、プラットフォームのカスタマイズ開発が進んでいくわけですから、多大な労力と時間とコストをかけて作った後で、「やっぱ違うなあ」なんてわけにはいかないためです。リアルイベントの展示会で例えるなら、施工日にブースを立て込んだ後に、もう一回デザインしなおすっていうのと同じ話ですので、そりゃあもうヤバみですよね。

さて、要件定義のやり方ですが、ここではサイトマップに沿って、主要なページ一つひとつのワイヤーフレームとともに定義をしていくのがお勧めの進め方です。

さすがに口頭や文字だけでは理解はしにくいですし、何よりも仕上がりのイメージが掴みにくく、ミスコミュニケーションの元になります。各ページ上に配置したい要素、ページ上の構成(レイアウト)、クリック時の挙動や、ページ遷移の動きの確認なども含めて、可能な限りここで一気に行うことで、主催側も制作する開発側も、共通の認識をもつことができます。

もちろん構築後のテストサイト上の方が確認はしやすいのですが、残念ながら、その時点で大きな変更はできないことが多いため、要件定義の時がもっとも担当者が想像力（創造力）と集中力を高め、気合を入れるマイルストーンなのです。逆に言うと、この要件定義の質が高ければ高いほど、オンラインイベントのサイトクオリティは良くなるということになります。（そして、コンテンツクオリティも高ければ、それは最高のオンラインイベントになります）

ということで、本日はここまでとして、次回はプラットフォームの要件定義と平行して行うべき、デザインコンセプトの話を書いていきます。