ライトニングトークはやっているけど、ランクアップして枠をもった登壇にトライしたい人に届けるTipsです。
はじめに
この度、私はdb tech showcase ONLINE 2020にて「RDS脳なあなたにKVSモデリングのノウハウを公開！AWS DynamoDB、Azure CosmosDBでのKVS設計はこうしよう！」と題して登壇させていただきました。この登壇スライドを作っていく過程で得た経験値をみなさんへ共有させていただきます！
私自身、LT系は普通にこなしてきました。発表当日に資料を書くとかザラでしたが、40分枠となるとノリでは埋まらないですよね。
スケジュール感
だいたいこんな感じでした。
- 約3ヶ月前 募集開始(Call for papersや、社内連絡により)が募集が始まり手を挙げる
- 約2ヶ月前 ネタ決めをする
- 約1ヶ月前 全体のストーリーを決める
- 約3週間前 つらい時期。とりあえず書く。書く＋ディスカッションを繰り返す
- 約2週間前 間に合わないと、事務局に事前連絡する。
- 約1週間前 レコーディング動画の締め切り（※ONLINE系の場合）
- 約3日前 締め切りをオーバしてしまったが無事提出する
後々厳しくなってきます。が、まぁそんなものです。早めに仕上げるといいスライドができる確率は上がります。だからと言ってそれがいいとは限りませんが、プロなのですから、いいスライドを作れるよう努力しましょう。
Tips
以降で、スケジュール感にあわせてTipsを記載していきます。
ネタ決めをする。そのネタの絞り方。
基本的に次のどちらかになるかと思います。
- いままでの知見を記事にして共有する
- これから試したいことを試して記事にして共有する
「いままでの知見を共有する」の一択です。10分程度のライトニングトークであれば「これから試すこと」について話してもいかもしれません。ライブ感もあります。ただ40分程度の枠をもって登壇する場合は「いままでの知見を記事にする」にしましょう。最新技術を試してかっこいいところを見せたい気持ちはわかりますが、それは、この場ではありません。
プロジェクト等で実際に使った技術の経験や苦労の話ほど、納得感、腹落ち感、重みのあるストーリーはありません。どんな小さいことでもその経験値に勝るものはありませんし、視聴者はそれを欲しています。
- 「いままでの知見を記事にして共有する」 → 枠をもった登壇で。
- 「これから試したいことを試して記事にして共有する」 → ライトニングトークで。
です。
全体のストーリーを決める。そのストーリーの決め方。
ここでやることは2点です。
- 経験したこと、感じたことを、つらつらと書いてみる。
- 手伝ってくれる人を2人ばかり集める。私の場合は人事部長と技術部長に手伝ってもらいました。
経験したこと、感じたことを、とりあえずなにも考えずつらつらと書く。
私の場合はこの程度のメモから始めました。（はずかしいけど。お見せします。）
■自己紹介
■KVSの認識は一般的にはXXXXなんだけど、実際にやってみると、XXXXとかXXXとか、大変なことがあるよね
・インデックス設計
・valueで検索したいんだけど、普通KVSではできないし。
・モデリングとか
・KVSのモデリングって大変だったなー。
■KVSの紹介を書く(googleで検索すればでてくる話は重くしない。１枚程度。)
■KVSの特徴（雑な感じで）
・おおーすげー。的な
■KVSの特徴（まじめな感じで）
・昨今のシステムでKVSが求められているのはなぜか？
・そもそもRDBからKVSでが生まれたのは。。。。
・ACIDにも触れる。でも、欠点もある。
■KVSを取り巻く環境（KVSプロダクト、エコシステム系）
・ざっと調べておく、必要であれば書く程度
■KVSは使うべきか、使わざるべきか。
・どのタイミングで判断するか
・提案・構成設計時点、ソレ以外では無理。
・なぜ、私はKVSを使ってこなかったのか。
・俺、KVS嫌い。（スライドには書かない。言葉ではいう。そうそうとか思う人がいる。）
・新しいモデリング手法を拒否している。なぜだ？
・正規化を崩すことが考えられない。体が拒否している。
・結局、正規化をくずしまくるということなので、当初デザインしたモデルが成り立たなくなる。
（ああ、このひと、俺と一緒だ。と思わせると、聞いてくれる。RDB側の人間だと思ってもらう）
・KVSで実装するべき検討が必要になっ
・よくわかんないけど。最初にKVSありきで設計検討をするで、できないところをRDB化する。
■正規化をくずす、くずさないについて
・なぜ、モデリングにおいて正規化が必要なのか。
・論理設計における正規化、物理設計における非正規化
・ゴールは、システムの安定化、パフォーマンスにある。
■KVS設計はこうする！
・RDBと同じ設計手順で考える。ただしKVSならでは、はある。
・検索のためのINDEXをどう作るか
・読み取り一貫性を保証するを、どのパターンで補償するか。
・RDSでも同じ、KVSでも同じ。様は検索
・なにを検索キーとするか。なにを検索キーとせずに、あきらめるか。
・トランザクション処理ってできないじゃん。って言われるので
■開発するだけではなく、運用面も考えてみる。
■AWS DynamoDB/Azure Cosmosの特徴
■KVSはこう使え！
■RECAPページを作る。
「伝えたいメッセージ」を先に書くという方法もあるのかもしれませんが、私の場合は、それに固執してしまうと時間ばかりが過ぎてしまうので、まずは自分が知見として得たことで共有したいことをまず書ききることにしました。
あとからそれを眺めると「伝えたいメッセージ」が浮き上がってきます。結果OKです。
手伝ってくれる人を2人ばかり集める。集めてディスカッションをする。
今思い返しても2人がベストでした。1人でも3人でもありませんでした。
お手伝いいただける人と書いたネタでディスカッションをしましょう。「俺はこんな話をしたいんだよね」というラフな感じで。これを１週間おきに２，３回繰り返し、「つらつらと書いたネタ」をどんどんアップデートしていきます。そうすることで、徐々にストーリー感が生まれ、躍動感をもたせることができるようになります。
私の場合、このディスカッションによって単なる「KVSの紹介」から「見向きもしなかったKVSを使ってみたら、最高だったよ。」というストーリに仕立て上げることができました。
つらい時期。とりあえず書く。書く＋ディスカッションを繰り返す
はい。そろそろ見て見ぬ振りをする時期です。毎日書き続けるのは苦痛です。自分の「やる気スイッチ」を探すこともしません。
その時は、1人で考えずにお手伝いいただく2人と、どんどんディスカッションをしましょう。ディスカッションを通して危機感が生まれます。危機感は生まれるが、「その時だけ危機感」という私みたいな人は、どうしましょうね。いいアイデアがあれば教えて下さい。
スライドに文章はあんまり書かないほうが良い。
技術者はスライドに文章を埋め込みがちです。スライドは後で残ることを考えてしまい、どうしても文章を埋めたくなります。スライドに文章を書いてしまうと、説明する前に視聴者はそれを先に読んでしまいます。それは飽きさせてしまうことにも繋がります。
重要なのはスライドではなく発表者の発言なので、スライドは極力メッセージのみにしましょう。あー。この人の発表を聞きたいなー。と思わせるスライドがよいと思います。
レコーディング動画は分けて録画しない。一気にしゃべってしまいましょう。
ONLINE登壇だと、事前レコーディングとなります。事前レコーディングだからといって、細かく分けて録画するのではなく、一気にしゃべってしまいましょう。聴いている人にライブ感が伝わります。
スライドの見た目は大事。
フォントは大事です。統一されたきれいなフォントを使うとスライドの見た目がグンっとよくなります。
最後に、アウトプットするということ。
アウトプットは、し続けましょう。たまに「アウトプットするものがない」という人がいます。それは常日頃のインプットの量が足りないだけです。アウトプットの品質が高い人は、相当なインプット量になっています。
と同時に、常にいまやっている事をどうアウトプットしてやろうか。という心がけが意識が大事です。私もまだまだですが、みなさんもこの記事を機にアウトプットへの熱を燃やしていただければと思います。
以上、私の実体験と私の気持ちを共有しただけの記事でした。