Lean Baseball

No Engineering, No Baseball.

小さいプロダクト開発におけるGCP利用の勘どころ - 個人的なプロダクトを三日でローンチした話

私個人の話なのですが.

最近は仕事でAWSやGCPのサーバレスアーキテクチャにふれる機会が増えた*1と同時に,

  • 自分が気になる世の中のニュース(グルメとかいろいろ)だけをいい感じに集めてまとめて読みたい
  • その中でも特に⚾, 速報とかいい感じに通知させたい

という怠け者欲ライフハック欲が高まってきたので, GCP(とちょっとしたPythonスクリプト)でSlack Botを作りました.

趣味開発で雑にはじめた結果, 三日程度でできちゃった*2のでその知見をメモ代わりに残します.

おしながき

TL;DR

  • GCPでクローラーを軸にしたBot作るなら「Cloud Functions」「Cloud Pub/Sub」「Cloud Scheduler」三つの組み合わせで爆速でイケる!
  • 気になる料金は...これからわかるが試算した結果, (今回の使い方だと)月額$1.0程度
  • 個人開発を楽しんでいこう, イベントがない今時期だからこそ

対象読者

「GCPとはなんぞや?」「Slackなにそれおいしいの?」的な解説はしません, わかってる前提で話を進めます.

  • 情報を収集したり使ったりする手段をいい感じにして怠けたい人,
  • 何でも良いのでプログラミングができる人かつ, 個人とか趣味で開発とかが好き・苦にならない人. ちなみに出てくる言語はPythonです.*3
  • サーバレスアーキテクチャ覚えたいなあー, とかGCP使ったサーバレスってどんな感じなん?っていうエンジニアな人.*4

作ったもの

全体像は絵で描くとこんな感じです.

f:id:shinyorke:20200314152038p:plain
この絵がすべてです.

左から順を追って説明すると,

  1. Cloud Scheduler」が毎日の活動時間中に10分間隔で発火, 「Cloud Pub/Sub」の指定したトピックにメッセージを送付
  2. Cloud Pub/Sub」のメッセージをトリガーにして「Cloud Functions」が起動
  3. Functions内の関数(Pythonで実装)がサイトのクローリングとクレンジングをした上でメッセにまとめてSlackにPost.

なお, 通知の制御(主に重複とか, 何回も通知が来るのはウザい)は「Cloud Firestore」に通知の状態を持っておくことによって実現しています.*5

割となんてことは無いSlack Botだと思ってくれればと思います.

GCPをフル活用して実質三日でBotをローンチした

Bot自体は先週の土日(3/7, 3/8)のそれぞれ半日でコードを書いて完成.*6

GCPへのローンチは, 一昨日(3/13)に仕事終わりのオフィスに居残ってビール片手にGCPのサービスを検証しまくった結果, 3時間くらいでできました.*7

Gitのコミットログ + GCP上の作業時間を合計すると多分12時間ちょいです, ハッカソンで作品作ったぐらいのボリュームですね.

Bot本体の開発

元々うっすらと, 「やきう⚾の情報をまとめるBot欲しいなー」と思っていて*8, いつ作ろうかと思案していた矢先に,

というやりとり*9&ウチ(JX通信社)のつよつよマンから聞いたrequests-htmlを(ちょっとドキュメントとコードを読んだ後に)おすすめしたのですが,

ワイ「使ったこと無いモノを薦めるのもアレだしちょっと遊びでコード書くか*10

というモチベーションの元, サクッと仕様を決めて開発をスタートしました.

なお, 開発そのものはrequests-htmlを程よく使うことによりアッサリいけました*11&大人にクローラーを開発する話は過去のエントリーに結構書いたので今回は省略します.

shinyorke.hatenablog.com

物足りない方は是非クローラー本をご参考に :bow:*12

GCPの何を使うかで試行錯誤

このエントリーの肝はむしろここです.

運用は最初からGCPと決めていました.

理由としては,

  • 自分自身のお勉強・知見を得る目的で, 「経験ほぼゼロのGCPでサーバレス」な開発に挑戦したかった.*13
  • プライベートで使っている分析環境およびデータセットはGCP上にまとめている
  • AWS Lambdaでやればきっと瞬殺で終わる&Lambdaも良いサービスだがGCP上での経験が積みたくて(大切なので二度言う)

サーバレスなモノは(GCPに限らず他のクラウドプラットフォームも)従量課金でSlackのBot一個程度ならたかがしれてるだろう.

というのもあり, やりたいモノであったGCPに振り切りました.

今回は,

  • 動かすのはPythonスクリプト
  • Cron的なJOBに従い動くバッチである
  • Web(HTTP)でオープンにするようなAPIとかはナシ

というシンプルな条件の元,

  • プランA「GCE(Google Compute Engine)」上でDockerのContainerとして定期実行
  • プランB「Cloud Run + Cloud Scheduler」の組み合わせでやる
  • プランC「Cloud Functions + Cloud Scheduler」←今回採用した構成

この3つのプランから考え, プランB・プランCをどっちも動かしてお試ししました(プランAは既にやったことあるので考えただけ).

プランA「GCEを使う」

まず真っ先に思いついたのが,

  • 開発したBotをDocker imageにしてGCR(Google Container Registry)にpush
  • GCRに上げたimageからGCEのVMを起動, バッチとして動かす

でした.

これについては既に個人の野球分析でやった実績*14があり楽っちゃ楽なのですが,

  • 言うてもVMなのでずっと立ち上げっぱなしにする必要がある.
  • Botを動かす時間はせいぜい一日10時間ちょい, 残りの14時間はリソースを遊ばせることに.
  • (なんとなくの)試算で$1/日, 一ヶ月で$30前後と予想, 払える金額だが遊んでる時間が長いのでもったいない!

こっちとしては使った時間だけお金を払いたい感じなので即効で却下しました.

プランB「Cloud Run + Cloud Scheduler」

次に考えた&試したのが,

  • 開発したBotをDocker imageにしてGCR(Google Container Registry)にpush
  • Cloud Runのサービスとして起動, Cloud Schedulerからトリガーを出して動かす

でした.

これは実際に公式のクイックスタートを追いながらWeb APIとして立ち上げ, Cloud SchedulerからAPIを叩いて実行してうまくいきました, これは楽だし便利.

ただ,

  • 別にWebアプリを作りたいわけではない
  • 現時点ではCloud RunはWebのトリガーでしか動かないと思ってました. Pub/Sub対応してたのにこのエントリーを書いてる途中に気がついたorz*15
  • 言うてもBotなコードなので別にDocker化するほどでも無いのでは(今更)

若干の勘違いと調査不足は置いておいて, 原点に立ち直った私は「Botとしてもっとシンプルな方法でいこうぜ!」って事で舵を切り直しました.

採用した構成「Cloud Functions + Cloud Scheduler」

というわけで今回採用した構成はこちらになりました.

f:id:shinyorke:20200314152038p:plain
【再掲】この絵がすべてです.

Cloud FunctionsのPub/Sub使うよチュートリアルに従いサンプルを作成, Cloud SchedulerからのトリガーでPub/Subのトピックにメッセしたら今までの試行錯誤は何だったのか?的な感じでうまくいきました👍

使った感想としては,

  • requirements.txtを用意するだけでライブラリのインストールとかよしなにしてくれるのすごく楽.*16
  • 運用後のデバッグがくっそ楽.エラーレポーティングが詳細でわかりやすい(Sentryとかいらない).

ちなみにエラーレポーティングはこんな感じでリンク先を掘るとかなり詳細に追えて素晴らしいです.

f:id:shinyorke:20200315124215p:plain
かなり助かる

さて気になるお値段は?

個人プロジェクトそしてもちろん仕事もコスト管理大事です.

ということで今回の構成(Functions + Pub/Sub + Scheduler + Firestore)において,

「Botが10,000回/月 APIをコール」したときのコスト(月額)を試算してみました.

サービス 試算した金額 根拠
Cloud Functions $1.0 回数は無料枠内, 送信は5GB未満, 関数の実行時間を60秒未満とした時のリソース金額のみ上乗せ, ちなみにメモリは128MB
Cloud Pub/Sub $0 TiB単位で課金, 流石にそこまでいかない
Cloud Scheduler $0 請求アカウント全体で1つのJobのみ, 無料枠に収まる
Firestore $0 100,000ものドキュメントは無い, 行って10,000程度なので無料枠内

一ヶ月あたりたった$1.0, 見誤ったとしても$3.0ぐらいだなとわかりました.

毎日飲んでいるりんご黒酢と胡麻麦茶のほうが高い*17くらいです, やった.

先ほどのGCEを使った例の試算だと(状況にもよりますが)少なくとも$20以上はかかるので全然お安いといえます.

世の中サーバレスなアーキテクチャで開発することが流行っていますが, コスト面ではかなり美味しいのがわかります.*18

結び - 個人的プロジェクトのすすめ

昨今の新型肺炎の騒ぎで色々と辛かったりきついこともあるかと思いますが!

こういう時にふと時間ができたら個人開発をオススメしたいなと.

  • スキルや経験といった自己投資として. 例えばサーバレスなアーキテクチャは実際使わないとわからないモノも多いのでこういうときに試すといいよとか.*19
  • 自分自身の生活や仕事の効率化・ライフハックとして. 普段めんどくさいことを1日2日かけてプログラミングで楽できるのは良いことだし, そこで空いた時間で別のこともできます.*20
  • 結果的に仕事に活きたり次のチャンスに繋がる.

最近は個人開発も結構フォーカスされてる&事例も増えているのでキャッチアップすると良いかなと.

というわけで, GCPを使った小さいプロダクト開発の記録でした.

*1:それはなぜかというと, 現在在籍しているJX通信社がサーバレスアーキテクチャな会社だからです.

*2:ちなみにすべての情報ソースに対して開発終わったわけではないです&今回は野球のソースを中心に紹介します.

*3:Cloud Functionsがサポートしている言語ならどれでもいいです, 現時点ではNode.js, Go langそしてPythonの三択となります.

*4:個人ブログなので会社の見解とか諸々関係ないですが, 弊社を気にしてくださる方は読んでくれたほうが嬉しいです.

*5:これは書くと長いので端折りますが控えめに言って便利でした.

*6:自宅, カフェ, 外の居酒屋と場所を転々としながらクローラー作った

*7:ちなみにウチの会社は金曜日の夜や週末などに自発的に仕事以外のもくもくをする人がいたり, 有志でボードゲームとかを嗜んだりとTGIFチックな活動がとても雰囲気良いです.

*8:開幕に間に合わせましたが肝心の開幕がいつなのかっていうツラミ

*9:その後のむーむーさんの成果は大変素晴らしいまとめなブログとしてまとまっているのでご興味ある方是非&このエントリーでやってることとほぼ被っています(AWSかGCPの違いですね).

*10:人にオススメするものは事後でもいいので触っておく, が私の基本的なスタンスです.

*11:これはまた別の機会に書きたい

*12:これはマジ名著です.

*13:過去にGAEや後述するGCE(Compute Engine)および今はBigQueryやGKEとか使っていますが, サーバレスの小さいSaaSは普段AWSでやってたのでほぼ未経験

*14:昨年検証した, 類似性スコアの算出に使いました, 全選手を総当りで計算する必要があった&半日回せば後は用済みっていう使い方でした(こういう使い方をする分にはVMは大変素晴らしいです).

*15:Pub/Sub無理かーって思ってたらブログ書いてる最中にPub/Subイケるよって見つけました.

*16:個人的にはここがAWS Lambdaより楽で助かるな感あります, まあserverlessとか使えばいいんですけど.

*17:合わせて270円くらいです, これが毎日.

*18:エンジニアリングの基本は「限られたリソースを上手く使い切る」だと思っていてそれがサーバレスな仕組みのピタゴラスイッチでできるのはかなり良いことだと思います.

*19:最初の方に述べた通り今回は自分がGCPに慣れるためにやりました.

*20:いわゆる, 「退屈なこと」「仕事ごっこ」をいい感じにするってことです.

「イシューからはじめよ」はデータサイエンスも同じだよって話をSports Analyst Meetupでしてきた⚾

言いたいことはタイトルそのままです.

ちょっと前の話ですが, 2/16に開かれた「Sports Analyst Meetup #6(通称#spoana )」というイベントでこんな話をさせてもらいました.

当日はイベントそのものが大盛況でしたし楽しかったです.

聞いていただいた皆様, 運営の皆様素敵な機会とフィードバックをいただきありがとうございました.

このエントリーはそんな#spoanaでお話させていただいたことを振り返りつつ, 原則論であり大切なアクションである「イシューからはじめよ」という話を交えて補足したいと思います*1.

TL;DR

このエントリーで言いたいことの要約です. あえて一言で言うと「イシューからはじめよ」を実践しましょう!

  • 「どこが問題か?を見極める」「数字じゃなくて答えを出す」ことにこだわり, やっていくとデータサイエンスは捗る(しそれが基本)
  • ガチでスポーツ・アナリティクスをやるなら, スタジアムに行く時間を削ってでもプログラミングと数学を頑張りましょう.
  • スタジアムに行けない今は悲しいですが, むしろデータサイエンス・分析のチャンスかもしれないよ?

スタメン

スポアナで話したこと

実は以前から話したいテーマでした.

  • データサイエンスでプログラミングはマストじゃない. ISSUEに合わせて道具を変えよう(≒道具への偏った拘りはナンセンス)
  • 「どこが問題か?を見極める」「数字じゃなくて答えを出す」にフォーカスしよう(大事なのは指標そのものじゃなくて課題設定とその答え)
  • 言うてもPythonとセイバーメトリクス楽しいやで!

...というのを, 「仕事としてスポーツアナリティクスをしたい人」「趣味としてスポーツアナリティクスを楽しみたい人」に話せればいいなと思い, いい感じに話をまとめました.

登壇のきっかけ

そもそものキッカケですが, 前回のスポアナに参加した際, 運営の皆さんに「もしよかったら次ロングトークとかしたいです」とお話した所, 早速オファーを頂いたのが登壇のキッカケでした.

時期的に, デブサミが近かったこと, どっちも野球の統計(セイバーメトリクス)の話を織り交ぜる前提だったので同時並行で準備を進めていい感じにやりました.*2

知らない人に”よく聞かれること”をタイトルに

話す内容は前述の通り,

  • ISSUEに合わせて道具を変えよう
  • 「どこが問題か?を見極める」「数字じゃなくて答えを出す」にフォーカス
  • Pythonとセイバーメトリクス is 最高!

だったのですが, 正味な話タイトル決めるのがおっくうで当面の間「イマドキなスポーツアナリティクスのためのプログラミング入門 - セイバーメトリクス風味」という仮タイトルで進行中, ふと書いたこの一枚のスライド.

f:id:shinyorke:20200227165335p:plain
ネタっぽく書いたやつがそのまま本タイトルに

これが発表の一週間前に降臨してきたのでそのまま採用しました.

実際問題, そもそも発表したかった背景の一つとして,

  • TwitterやFacebookなどで, はじめましての人・アカウントからくる最初のメッセージが「Pythonおしえてください」「野球のデータ分析やりたい」
  • 原則として, 自分のSNSはメンション・DMの返信は確約しない方針かつ, これらはノウハウの話も多分に含まれているためタダで返答はまずありえない.
  • とはいえホントにこれらのメッセ多いのと, いい加減共通回答あってもいいなぁ.

という課題を解決したかったのでやりました.

そんなエピソードを最初に軽くお話したのですが,

33.4%はいつもの鉄板ネタなので察しですが笑, 同じく当日ロングトークされていた廣澤さんをはじめ, 他数人の方から後日同じようなメッセ・問い合わせが来るなあって事で結果的には「プロもしくは元プロのスポーツアナリティクスな人」の共通課題として捉えてもらえたみたいでラッキーでした, こういう話はどこかしら年中あるわけで*3.

あなたのイシューはなんですか?

発表内容としては, セイバーメトリクスの統計モデル(類似性スコア)を使ったデモを先頭打者として, プログラミング言語や選び方の話, 学習の心構え(後述)などを話したのですが.

本命の話は,

「ISSUEの程度に合わせて道具を選ぼう, プログラミング云々を語るのはナンセンス」

でした.

f:id:shinyorke:20200227173024p:plain
すぐ出せるものか?段階を踏むものか?どっち??

昨今のデータサイエンスとか統計, AIブームもそうなのですがどうしても手法や手段の話題が先行しがちです.

が実際の仕事だと,

  • そもそも解きたい課題, いわゆる「イシュー」ってなんだ?それは解像度が高い(答えが出る)話なのか?
  • 雑でもいいからイシューに対する答えを出す, 答えから新しいイシューを作ってさらに実験していく
  • ドメイン知識も大事だが, まずは課題・事象を構造的に理解する&解像度が低ければ不要なものを捨てる.

ことが基本かつ, 上手くいくときはこれらがきれいに回るケースです(≒大抵の場合, これがきれいにできないから上手く行かない*4

仕事にしても趣味にしても, スポーツアナリティクスで成果を出したい!という人はぜひ,

  • やりたいこと・課題に感じていることをまず構造的に分解し, 言語化する
  • 言語化したことの「インプット」「アウトプット」を決め, 手を動かして実験してみる
  • 実験結果を#spoanaなり#bpstudy(Baseball Play Study)なりで話してみたり, ブログにしてみたりする

を繰り返しながら課題を作る・捉える力を養うと良いのかなって思っています.

そしてこれはそのまま「イシューからはじめる」話なのでぜひこれを参考にしてほしいかなとも思います.

イシューからはじめよ――知的生産の「シンプルな本質」

イシューからはじめよ――知的生産の「シンプルな本質」

  • 作者:安宅和人
  • 発売日: 2010/11/24
  • メディア: 単行本(ソフトカバー)

どんなにPythonやRを使いこなしても, データサイエンス・統計の知識に優れていても「本当にやるべきイシュー」が作れない・捉えられない人はこの手の仕事無理です.

っていうことです.

ファン心理は課題特定(と仕事にする時)の大きな障壁

「あなたのイシューはなんですか? 」は, スポーツアナリティクスのみならず, データサイエンスやる人の全員の共通事項かと思いますが.

スポーツアナリティクスの文脈で言うとこれが一番話したい内容でした.

f:id:shinyorke:20200227160934p:plain
一言で言うとこういう話でした.

本気でスポーツアナリティクスで結果出したければ球場に行く以上にプログラミングと数学に没頭しましょう, リソース割こうぜ!

そういう話です.

特に, スポーツアナリティクスを仕事にしたい人・希望している人からよく聞く話なのですが,

  • 「映画のマネー・ボール」にあこがれてスポーツデータ分析の仕事をしたくなりました
  • 野球は好きで, ○○のファンです&球場によく行きます, 応援歌をスラで歌えます, etc...
  • 「プログラミングに興味」があって「今勉強している最中」です

人それぞれ多少ブレはありますがこれがステレオタイプで, そんなあこがれを持たれている皆さんに,

若い人もミドル・シニアの人も, この現状でデータ分析の仕事に就くのは厳しいですよ?考え方・生活スタイル変えていかないとキッツイですよ??

というニュアンスでブログ等で発信している(つもり)なのでこれを敢えて明確に言うことにしました.

  • 映画のマネー・ボールは正直データ分析の話はありません, データサイエンスな話は書籍の方がより素晴らしいです.*5
  • 野球好きは私も一緒で, 球場によく行く人・応援や選手のことを知っている人は個人として深くリスペクトします. が, セイバーメトリクスや統計的な世界線ではたして役立つでしょうか?*6
  • プログラミングに興味・勉強中は素晴らしいし応援します. が, お給料を稼ぐレベルに到達するのは「興味」「勉強中」だけでは不足しています.*7

データアナリスト・サイエンティスト(とエンジニア)は色んな局面で客観性・言語化力を求められる職種な一方, 「ファンとしての心理・行動」は主観性が大変強いモノで相性はあんまり良くない, 趣味でスポーツアナリティクスをするときも「客観性」があればあるほどより良い内容になります.

発表中, 壇上から眺めた感じですとこの前後の話をした時が一番静かだった気がするのできっと伝わってるのかな?

ちょいと厳しい話・視点かもですが本気でやりたい方の刺激・参考になれば幸いです.

結び - スタジアムに行けない私たちが今すべきこと

これはまさについ最近のホットトピックスですが.

npb.jp

オープン戦がすべて無観客になったり, 他競技ですと公式戦の延期・無観客試合への変更も多く聞いています.

これは1ファンとしてのわたしも辛いです...が!?

「野生の野球データサイエンティスト的には仕込みの時間がもらえるぞ!!!」

というチャンス・モチベーションにもつながっています.

これは私が球場に行くより, ネットやTV観戦しながらデータを眺めたり分析するのが大好きだからってのもありますが,

本気でスポーツアナリティクスを目指す人, 特に仕事にしたい人はこのタイミングを活かして挑戦してみては?

と思っています&実際に仕事にした先輩としてもこれを強くおすすめします.

今度は#spoanaでもっとオタク(かつ良質なISSUEとしての)ネタをやりたいな...

*1:ホントはもうちょっと早く振り返るつもりでしたが, かなり良い感じのお祭りがあったため遅れました苦笑, この顛末の話はきっと会社のブログとかで披露できるはず&FASTALERTよろしくお願いいたします!

*2:という事情で, スライドの約2割はデブサミからの使い回しですが話の軸は全く異なる内容となっています.

*3:個人的な本音は「人に聞く前にまずやってみてからだろ」「人のノウハウ・知見は聞けばタダで教えてくれるようなもんじゃないぞ」なのですが, そこで突き放すのもアレなので発表にしたったって意味合いもあります.

*4:偉い人や上司に言われてAIプロジェクトが上手く行かない・頓挫するケースとかわかりやすいと思います, ちなみにこの手の話に不幸にも巻き込まれた時はポジティブにとらえて試したいことをやる, それを上手く成果として着地するようにすると良いでしょうとも思います(過去の経験より&スポアナでもそんな感想・フィードバックありました)

*5:データなオタクが救う風の話にまとまってる映画版は単体作品として面白いですが決してデータサイエンスな話ではありません.

*6:マーケティング等で約立つのはわかりますけどね.

*7:という話は去年機会あって話をしてみました.このエントリーを参照.

シニア・エンジニアの簡単なお仕事 - デブサミ2020で登壇しました

【TL;DR】デブサミで喋ってきました.

f:id:shinyorke:20200215115709j:plain
高く飛び続けましょうって話でした.

事前登録から多くの方々にご登録いただき, (写真は自粛しましたが)壇上から見る限り, 立ち見も出ていたみたいで感謝感激でした.

数あるセッションの中からお越しいただき(+来られなかった方もリハーサルとか諸々でサポート・応援)ありがとうございました.*1

このエントリーではスライド・発表でいい足りなかったことを補足という形で残したいと思います(発表準備の話を含めて).

スタメン

当日の様子など

スライドは初めてアスペクト比を16:9で作成した関係上, すべて書き下ろしになりました.*2

また, CodeZineさんのTogetterまとめをはじめ, 数多くのレポートを頂き感謝です!

スライド

100枚ありますが割とサクッと読める出来だと勝手に思ってます.

ちなみに当日は45分のお時間を頂いていましたが, 42分ちょいで終わりました.*3

反響とか

CodeZineさんのTogetterまとめに感謝!

togetter.com

何人か既視感ある人いるけどそれはさておき

多くのツイート・感想をいただき涙モノでした.

中には素敵な言語化まで...ありがたい.

短距離ではなくマラソンっていう話、アウトプットする人みんな言ってる

この辺は皆さん印象に残った(かつ自分としても訴えたいポイント)みたいで良かったです.

また, こちらについても初言及しました.

お気持ち的にはこんな感じです.

野生とはいえ, プロレベルの野球データサイエンティストでありエンジニアなのでね.

こういうやりとりができるのもデブサミならではだなと思いました.*4

数々のサポート

また, 当日および本番前から, 所属のJX通信社のメンバーから,

  • 写真撮影
  • 社内SlackやTwitterでの盛り上げ
  • (これは元々のルールですが)勉強会・イベント登壇・参加は業務時間中OK
  • Wantedlyコンテンツほか, 企画段階からのサポート
  • 後述の通り, リハーサル場所として会社のイベントスペースを快く提供

と数多くの支援をいただきました.

会社の事例ではなく, 個人の話にも関わらず前のめりでサポートしてくれて涙モノでした.

ホントにありがとうございました!&裏話とかはTechブログで後日公開したいと思いますのでそちらをお楽しみにどうぞ.

登壇に至るまでのあれこれ

キッカケは至ってシンプルでした.

デブサミ2020の案内が回ってきて,

  • そろそろデブサミでまた登壇したいなっていう欲が出てきた, ちなみに前回は2018冬でした.
  • 幸いにもテーマはある(正に今回の話)
  • 「野球エンジニアになったけど卒業しました」という話は禊(みそぎ)としてどこかですべきだよね自分.

という感じでしっかりストーリーを練った上で応募を出した所, 見事選考が通り, 2年ぶり2回目のデブサミが決まりました.*5

事前準備

今後の自分のため&今後同じく登壇する人の参考になれば幸いです.

スライドの構成・ストーリー

資料の構成は最初から「未来・過去・今」という人々自分のドラマ, と最初から決めていました.*6

f:id:shinyorke:20200215124628p:plain
個人運用しているSlackで壁打ちしました

途中, 「コミュニティ・マネジメントの話はいらない」となり, 代わりにセイバーメトリクスの要素を大きめにした以外, 昨年12/28(年末年始休み初日)に構想した内容ほぼそのままでスライドもデモも出来ました.

なお, 基本的なお話はすべてこちらのエントリーで固まっていたのでこのエントリーから色々と引用しました.

shinyorke.hatenablog.com

デモと野球データサイエンス

また, (デブサミだけじゃなくて色々と分析・研究してる文脈で)データベースとアプリを作ろう, という企画もあった&せっかくなのでいい感じに披露しよう!ということで,

  • Nuxt.js
  • FastAPI
  • その他使いたいもの色々

でデモ開発と分析をしました...という話はいくつかエントリーを書いたりしました.

tech.jxpress.net

shinyorke.hatenablog.com

shinyorke.hatenablog.com

どれもこれもいい感じに反響・反応があり良かったです.

また, 一部の話は本編スライドでも引用したりと結果的に資料構成がシャープになった気がします.

スライド作成(とタイトルのひみつ)

スライドはデモアプリ開発が落ち着いた今年のはじめにやりはじめました.

なぜスライドよりアプリが先かというと,

「対話および, 動くソフトウェアを元に変化への対応」

を愚直にやるためでした.*7

スライド作成は,

  • 3つの拘り「客観的な視点と言語化, プログラミングし続ける, 野球大好き」とともに.
  • 3つの時代「ミライ」「 過去」「今」を生き抜くために.
  • 4つの道具「エンジニアリング」「データサイエンス」「アジャイル」「セイバーメトリクス」を磨き続ける.

の, 334を揺るぎない前提として, 順番に書き始めました.

なお, タイトルの「生涯イチ・エンジニア」「I want to be part of the Senior Engineer(私は強いエンジニアの一員でありたい)」の由来ですが,

  • 「生涯イチ・エンジニア」はスライドにも入れたとおり, 故・野村克也さまのありがたいお言葉から引用(2018年のデブサミから心に決めて使っている言い回しです).
  • 「I want to be part of the Senior Engineer(私は強いエンジニアの一員でありたい)」は私が愛してやまないイギリスのバンド, RADIOHEAD*8の名曲「The Bends」の歌詞をアレンジ*9

ちなみにThe Bendsの件は作業中にアルバムそのものを聴いていて,

I want to live, breathe

(私は生きていたい, 息をしたい)

I want to be part of the human race

(私は人々の一員でありたい)

っていう節が何度も心に刺さり, 「これじゃん!」っていうことで決まりました.*10

リハーサル

45分の発表が久々だったので,

  • ストーリーとデモ, スライドの最初が出来たあたりで短めリハ. これは自分が運営しているPythonもくもく自習室の成果発表として.
  • 社内で45分完成版のリハ. 社員限定で45分計測の上やりきり.
  • 本番前の会場リハ. これは登壇者全員が必ずやるもので, 機材チェックがメイン.

と念入りに3回のリハーサルを実施しました.*11

結果, 尺通りに終わるかつ, 言及したいポイントもしっかり伝わってよかったです.*12

特に引っ越したばっかりの新オフィスのイベントスペースを借り切ってのリハーサルはすごく気分が良く, 30人は入るスペースで通しリハが出来たのは最高でした.*13

ふりかえり - 反省とネクストアクション

反省としては, タイトルに「野球」と入れなかった事ですかね...

「野球統計・セイバーメトリクスと共に語るよ!」ぐらいのモノを入れておけばもっと盛り上がった気がしました.*14

ちなみに明日はそんな野球の話をガッツリしてきます.

spoana.connpass.com

まだ参加可能みたいなのでご興味ある方はぜひ!*15

*1:立ち見たくさん出たの, PyCon JP以外では人生初でした(デブサミ2018の時は空席あった記憶)

*2:愛用しているAzusa Colorsにシレッと16:9対応があったのと, 最近のプロジェクターで4:3のみってのも見かけなくなったので今回を機にエイッと作りました. 故にスライド作る時間掛かってしまいましたが汗

*3:会社でリハーサルしたときには40分だったのでもうちょいゆっくりやったろ!って思ってゆっくりめにしてもこれでしたw

*4:いい形で本音を披露できたのは気持ちよかったです.

*5:ちなみに, 2015年あたりに公募で出して落選したのでそのリベンジが出来たのは良かった.

*6:どこからの引用かはご想像におまかせします🎸

*7:に, 加えてJX通信社の社内勉強会の期日が先でそっちに見せるものないとかっこ悪い!っていう現実的な理由もありました, 動くソフトウェアありきってことで

*8:ちなみに私のアカウント名shinyorkeのyorkeはThom Yorkeからの引用です.

*9:だから途中でベン図出したんですよっていうネタ解説.

*10:更に細かい話をすると発表当日の服装はRADIOHEADのTシャツで「Fitter Happier」の歌詞なデザインでした.

*11:前回デブサミはリハーサル・壁打ちナシのぶっつけ本番でした, 結果成功したものの満足はしてなかったので今回は計画立ててやりました.

*12:社内45分リハとほぼ同じ内容でした, 完全なスクリプトは書いてないので言ってることは少々違いますが.

*13:おそらくですが本番会場より良いプロジェクターとスクリーンでした笑

*14:ツイートを追うと野球わからないとかあったので...これは申し訳ない真似をした

*15:今までやったことないスタイルの野球ネタやります