Helpfeelでエンジニアや今出川FMの裏方等をしている 
id:Pasta-K です。
Nota株式会社は10月から社名が変わって株式会社Helpfeelになるのですが、それを記念した「Nota Reborn Calendar 2022」という企画をやっていまして、この記事はその10日目の記事になります。
本編とは関係ないんですが、僕が当時のNota Incにアルバイトとして入社したのが2014年8月だったはずなので、長いもので丸8年が経過したことになります。いや〜、まさかこんなに大きくなって社名が変わる日が来るとは感慨深いですね。
本編とは関係ないこと続きでもう1つ書いておくと、実は「Nota Reborn Calendar 2022」のページ内に埋め込んでいる一覧の作成も僕が担当しました。Google SpreadsheetからGoogle App ScriptでJSONを生成して、ページ内に各記事のリンクを展開しています。Atom Feedも同時に生成してフィードを購読することもできるようにしました。一覧を生成するフロントエンドはせっかくなので、Svelte+Vite+TypeScriptで書いていて、まぁまぁ面白かったので、その辺の話も機会があればしようかと思いますが……
この記事ではタイトル通り、「Nota Tech Conf 2022 Springの"全員登壇"を支えた技術」ということで、去る2022年5月17日〜19日に開催したNota Tech Conf 2022 Springの話をしようと思います。
「Nota Tech Conf 2022 Spring」についてはこちらの記事をどうぞ。
"全員登壇"を支えた技術
今回のテーマは「全員登壇」。エンジニアやデザイナーなどが所属する開発部の人数も10人を越えてきたところで、今が一番人数的にもちょうど良い塩梅かなということでチャレンジしました。アウトプットに熱心なメンバー以外にも多様なメンバーが居て、多様な問題にチャレンジしていることを知ってもらいたいという思いにもマッチしていたかと思います。
準備や配信やオペレーションなどは前回から踏襲できた*1ので、そんなに困らなかったのですが、今回僕の頭を一番悩ませたのは如何に「全員登壇」を成立させるかということでした。
Helpfeelのエンジニアはアウトプットが比較的活発なメンバーが多い一方で対外発表などの経験が無いメンバーも居ます。今回この「全員登壇」を社内メンバーに共有した際も歓迎と共に困惑の声が寄せられました。例えば、
- 「15分なんて長くて話せない」
- 「5分とかで終わってもいいですか」
と言った反応です。
こういった声にどう向き合って、どういう風にトーク構成の相談に乗っていたかということをお伝えしようと思います。
短いトークの難しさについて
まず、前述のような反応が来るのは正直予想していました。その一方で僕としては「5分で面白くて、観ている人が感銘を受けて、さらには一緒に働きたいと思ってもらえるトークをする方が難しいのでは？」ということを第一に伝えました。まぁプレゼンテーションというのはなんでもそうだと思いますが、話者が取り組んだ内容などの「前提」が十分に共有されていないと、本編の問題解決への共感が薄れたり、聴衆を十分に惹きつけることが出来ないと思います。
これは僕自身が関わっているテックカンファレンスのトークプロポーザルでもよく見られる現象なのですが、トーク時間を20分 or 40分や30分 or 1時間で選択できるようにすると、短い方を選ぶ人の方が多いというのが体感としてありました。そしてこれは個人の感想なのですが、そういった応募の中にはもっと時間を使ってじっくり話せばもっともっと面白くなるのになって思うものも少なくないと感じています。そういったトークは往々にして、問題解決方法について発表しているのですが、技術要素の紹介や解決方法のアプローチを話すことで時間いっぱいになっているように思います。もちろんそれが本題でメインの要素ではあるのですが、それを話すための前提の共有が欠けている結果、ぼんやりとした技術的なカッコよさだけが印象に残って終わり、となったりしてしまいます。
今回のNota Tech Conf 2022のトーク時間15分にこれらをざっくり押し込めると
- 前提3分
- 本編10分
- バッファ2分
という構成になって、「あれ？意外と10分しか話せないな？」「時間が足りないな？」ってなるかと思います。
当初、登壇経験の浅いメンバーは概ね「長く話せるほど面白い話が出来ないので、手短に終わらせたい」と考えているようでした。こういう話をメンバーに伝えた上で、登壇で発表したいこと自体のフォーカスを絞って8分くらいの内容を作って、あとはその本編を補足する前提の共有だったり、補足だったりをしっかりして、聴衆の取りこぼしがないように固めていけば15分話せるようになるはずということで、ほぼ全員の登壇予定者と1on1をして、発表内容の骨子を一緒に作っていきました。（ここの骨子を作っていくときの話は後述します）
LTっていう5分で終わるトークもありますが、あれはあれで別のパワーが要ると思うので、ここでは一旦考えないことにします。
長いトークの難しさ
Nota Tech Conf 2022では基本的には長いトークは用意していないのですが、Keynote系だったり対談に長い時間を割くというのはあるので、対比のために長いトークについても少し言及しておきます。
先ほどの話を読むと、じゃあ時間を伸ばせば良いのかってなりそうですが、そもそもそういう話でもないというのは共感してもらえるかと思います。
長いトークをやるには、話し続けるだけの体力も話題も必要ですし、ちゃんと練習すると毎回その時間だけ掛かります*2。1つの大きな話題に対して、枝葉をしっかり用意して、止めどなくトークを続ける必要があります。聴衆の集中力を保つ工夫をしないと聴衆は居眠りをしてしまうかもしれません。
つまり帯に短し襷に長しな時間ではなく、伝えたいことを伝えきるために適切な時間を選択する必要があるということです。ですが、今回のNota Tech Conf 2022では選択の余地は特になく「15分」という時間が与えられているので、次は15分の中の構成について考えてみます。
トークの構成について考える
15分でトークをすると決まっているなら、大きな話題は流れに合わせて詰め込んでも3つくらいということで構成を練ることになるかと思います。今回は各々のトークの相談に乗る際に、こういう感じで3分割して伝えていました。
- 序盤
- 話題に共感してもらったり理解をしてもらうための前提となるバックグラウンドを話す
- どういう問題と向き合っていたか。何故その問題を解決しないといけないか。
- 中盤
- 本編となる部分です。
- そのバックグラウンドがある上で、どういうソリューションを作ったか、どういうアプローチをしたか、どういう失敗をしたかなどを話すことになる
- フィナーレ
- トークをまとめたりするパートです。
- ここでなんか良いこと言えるとカッコいいのですが、伝えたい結論とかもここになるかと思います。
「伝えたいこと」がピークに来る構成になっているか
トーク話者として伝えたいことと聴衆が覚えて帰ることが意外と一致しないトークになることが多々あるかと思います。なので、さらに一歩下がって客観視し直してみれるように「覚えて帰って欲しいこと(パンチライン)」と「聴衆が感動するポイント」を書き出してもらって見比べるというのをやりました。具体的にはこういう内容です。
「覚えて帰って欲しいこと(パンチライン)」
ここは話者が一番伝えたいことを書くところです。ここの自分の言葉が相手に響くように前提条件などを説明しつつ、自分のテンションを高める持って行く構成にする
「聴衆が感動するポイント」
ここは客観的に見て、あなたのトークのどこに感銘を受けるのかを書くところです。機能について話すなら、成果物ではなくて、過程での苦労ポイントなどがそういう点になるはず。自分が他人のトークを聞いたときに覚えていることを思い出してみよう。
この2つのポイントが一致するのが最高の状態であるかと思うんですが、意外と本人的には良い感じに話せているんだけど、蓋を開けてみるとみんな過程を覚えてて、最終的なところは覚えてないみたいなトークもありますよね。例えば、「途中で出てきたXXXってやつ便利そう」とか。
実際、この2つを書いてみてくださいと言ったところ、機械的に同じことを書いているように見える人が複数居ました。これを一緒に1on1形式で見ていって、自分の思い通りに感動させるには聴衆をもっともっと惹き込んだりする仕組みが要るよねっていうことを色んな人に伝えました。話を聞いていて、感動する・感銘を受けるということは、そこまでの積み上げがしっかりしていて、そのこと自体を聴衆がある程度「自分ごと化」している必要があります。
映画でもラストシーンで感動する映画ってそこまでのストーリーテリングがあって、ちゃんと観衆が感動するためのお膳立てがされていると素直に受け入れられますが、突然「お涙ちょうだい」なラストシーンだけがやってきて一気に冷めるなんてこともよくありますよね。
そういったものを可視化して俯瞰する手段として、アニメーション監督の新海誠さんが過去にTweetしていた「感情グラフのようなもの」は非常に良いなと思ったので紹介します。
先ほどの感情グラフのようなものを、脚本のブラッシュアップと同時に何稿も重ねて行ったのでした。 pic.twitter.com/mGrZR8MA2o
— 新海誠 (@shinkaimakoto) 2017年4月24日
こういうのを自分のトークに当てはめてみると、自分のトークがどういう起伏になっているか、途中で失速してないか、自分が伝えたい話の直前にちゃんと聴衆のピークを高められているかということを客観的に考える時に非常に助けになるかと思っていて、こういうことを意識してみると良いよと伝えていました。
まとめ
今回は「全員登壇」ということで開発部にいる多様なメンバーに自信を持って発表してもらうために相談に乗ったり、お膳立てをした際に伝えたりしたことについて紹介しました。自分はこうしているよとかがあったら是非教えて下さい！！
おまけ: その他の差分などについて雑多に
今回は2回目ということもあり、比較的昨年に用意したスキームに乗っかっていけるところも多々ありましたので、思いつくものを雑多に並べておきます。
例えば、配信は引き続きStreamYardを使いました。差分と言うと、配信の画質を上げるために課金をしたのとStreamYardにプリセットされたBGMを流す機能が増えていたので、それを利用して開始前などにBGMを流したくらいかと思います。あ、そうそう、StreamYard上で背景を消す処理が出来るようになっていたのも便利でした（昨年の開催時はグリーンスクリーンの処理だけしかなかった）。
また、今回も画面にオーバーレイする要素やOP・EDのスライド、配信終了後の画面などはデザイナーチームに作成してもらいました。
前回の開催から1年が経過する中で、YouTubeやタクシー広告用に動画が制作されていて、いくつか長尺のものもあったので休憩時間などに流していました。事例インタビュー動画を見てもらうキッカケにも出来たんじゃないかなと思っています。コンテンツが始まるときと終わる時はブランドCMで統一するなどはちょっとしたこだわりでした。
一方で、いろんな人に参加してもらえるようになった結果、ROM専というかScrapboxに書き込みながら見てくれる人数が少なかったので、来年以降の視聴者との双方向のやり取りについては少しテコ入れをしたいなと思っています。
今回はQ＆Aセッションなどもなく、僕の手元環境が進化してStreamYardの操作をほぼ一人で回せたので裏方が少し暇になってしまったというのがあったのですが、少ないメンバーでも回せるようになったというポジティブなポイントでもあるかと思いましたので、その分は来年のより別のチャレンジにパワーや人員を割きたいなと思っています。
詳しくはぜひMeetyでお話しましょう！よろしくおねがいします！！！
