技術カンファレンスに通って、わかった 11 個の気付き

2018 年に仕事をしながらも休日や平日の夜に様々なイベントやカンファレンスに行ってきたので、そこで得た知見をまとめる。

箇条書きで得た知見をまとめた

先に列挙しておく。

  • 🙆【得られたコト】技術動向を知れる・感じられる
  • 🙆‍‍【‍ 得られたコト】コネクションが繋がる
  • 🙅‍♂️【得られないコト】実装する機会と時間
  • 🙅‍♂️【得られないコト】時間・気力・体力
  • 💡【気付き】聞くだけのカンファレンス通いは微妙
  • 💡【気付き】「はてぶ」にスライドが上がる=イベントがあった
  • 💡【気付き】連日のカンファレンスは避ける
  • 💡【気付き】休憩を入れる
  • 💡【気付き】セッションを選ぶポイントは「誰」の「何」の発表?
  • 💡【気付き】事前に当日の予定は決めておく
  • 💡【気付き】公式 Twitter はフォローしておく
  • 💡【気付き】聴講中は Twitter のハッシュタグでウォッチ
  • 💡【気付き】運営は常に発展途上
  • 💡【気付き】モチベーションが簡単に上がる
  • 💡【気付き】コミュニティごとの色がある

🤔 行かないと得られない「なにか」を知りに行く

そもそも、なぜカンファレンスに行ったのか?

今までは特にカンファレンスに行かずに発表されたスライドを見て満足していた。 だがカンファレンスに行くことでしか得られない「なにか」があるのではないか?という疑問があった。 体験を通して知りたかったので 2018 年の後半らへんからいろいろなカンファレンスに行ってみた。

あと、単純に楽しそうだったからもある。

🗓6~10 個くらいのイベントに行ってきた

小さなイベント・勉強会・テック系以外も含めるとおそらく 10 個くらいには行ってきた。

今振り返ると思ったよりも少ない感じがあるが年の後半に集中していたのもある。

何はともあれ、その中でも主要な 6 個のカンファレンスを元に得られた知見をまとめる。

  1. Erlang & Elixir Fest JP 2018 まとめ – Arsaga Partners Techblog – Medium

  2. HaskellDay2018 のまとめ – namiki – Medium

  3. 【まとめ】日本をぶち上げる iNTERFACE SHIFT2018 | エンジニア目線のキャリア戦略の学び

  4. 東京 Node 学園祭 2018(Conference@JP)のまとめ

  5. HTML5Conference2018Japan のまとめ

  6. 【まとめ】PHP Conference 2018 | カンファレンステーマ『Growth』と PHP 離れの現実

🙆【得られたコト】技術動向を知れる・感じられる

「発表内容」や「複数の人の発言の断片」からその技術の動向が知れる。

ただ、「発表内容」自体はカンファレンスに行かないでも大抵ネットに上がる情報で十分だった。 また、「自分の感じている技術動向」と「発表者の発言から伝わる技術動向」で大きな差がなかった。

つまり、「発表内容」・「技術動向」はキチンと日々の情報収集を行っていればカンファレンス通いをしないでも十分、というのが自分の結論。

🙆‍‍【‍ 得られたコト】コネクションが繋がる

ハードルは高いがコネクションを得られる可能性はある。

会話を行うのも大抵はカンファレンス後の懇談会となる。 だが、時間は 2h くらいだ。 しかも、複数人と会話するので 1 人あたりにかけられる時間はかなり短い。 そのため、登壇者の中で会話したい 1~2 人を事前に絞っておき、ピンポイントで話しかけに行くと良かった。

もはや「懇談会中はその人としか話さない!」くらいの意気込みで絞ったほうが効果的だと思う。

🙅‍♂️【得られないコト】実装する機会と時間

カンファレンスばかり行くと知識量は増えるが実装力は上がらない。

問題なのは頭でっかちに知識量だけ増えて実装力が向上していた気になってしまいそうになった点である。 俗に言う、「わかる」と「できる」には大きな差がある、というやつだ。

🙅‍♂️【得られないコト】時間・気力・体力

想像しているよりも移動時間や発表を聞くことに時間がかかる。

また、1 日を通してカンファレンスを聞くとかなり体力・気力が持ってかれる。

「カンファレンス聞いた後に〜〜する」は結構大変なので、そこにタスクを詰めないほうが無難。

💡【気付き】聞くだけのカンファレンス通いは微妙

「聞く」だけに行くなら、行かないでも良い。

カンファレンスをただただ聴講しに行くだけならネットに上がる情報でも十分だった。 確かに口頭で補足される内容があったり、そもそも口頭説明前提で作られているスライドもある。 だが、カンファレンスに行くコストは結構かかるので投資対効果は悪い。

趣味としてのカンファレンス巡りは良いが、学習としてのカンファレンス通いは効率が悪く感じた。

💡【気付き】「はてぶ」にスライドが上がる=イベントがあった

スライドなどがはてぶホットエントリーによく上がっている。 そもそもスライドは発表用の資料である。 つまり、スライドがネットに上がるということはその裏で発表会があるわけだ。

冷静に考えれば当たり前だが、意外と意識していなかった。

💡【気付き】連日のカンファレンスは避ける

連日のカンファレンス・イベント通いは体力・気力が予想以上にキツイ。

よほど行きたいモノがかぶっているケースでない限りは諦めるべき。

💡【気付き】休憩を入れる

聴講を頑張りすぎない。

カンファレンスを聞くことは思っているよりも物理的な体力が必要。 授業を1〜6限まで集中して聞いてメモして…と同じようなもので集中力が必要。 移動コストをかけてカンファレンスに行ったからには全部集中して聞きたい!と思うがメリハリも大事。 長丁場ならあえて休憩するセッションを作ったりして全セッション聞かずに途中で帰ったりしても良いと思う。

💡【気付き】セッションを選ぶポイントは「誰」の「何」の発表?

「どこの会社の発表なのか?」 という考えを重視すると 「技術的・一般的に知名度の高い会社名だから見てみよう」 という社名ブランドに依存してセッションを選んでしまう。

また、「メインホールの登壇だから」という理由も危ない。 なぜならスポンサー枠だからメインホールでの登壇ができている、というビジネス的な理由があることを留意すべき。

そのためどれを聴講するかを選ぶ観点として「何」と「誰」が大事だった。

「何」については発表のセッションのタイトルなどからもわかるので判断材料にされやすい。 だが、それと同じくらい「誰」が発表するかも大事だ。

大抵はカンファレンスサイトに登壇者の Twitter や Github のリンクなどがある。 そこから登壇者のバックグランドを調べて判断材料にすると良いセッションを聞ける確率が上がった。

💡【気付き】事前に当日の予定は決めておく

複数ルームのセッションがあるカンファレンスの場合は必ず事前にどのセッションに行くかは決めておく。

移動が多いセッションだと早く移動しないと席が取れない可能性もある。 また、当日はかなりドタバタするので必ず事前に行く順番は決めておく。

💡【気付き】公式 Twitter はフォローしておく

当日、諸事情で部屋割りが変わったり、時間変更が起きたり、というイレギュラーは起きる可能性がある。 その結果、出遅れて部屋が満席になり登壇が聞けれない可能性もある。 事前に公式 Twitter をフォローしておき情報をキャッチしておけば、そのようなリスクは減る。

💡【気付き】聴講中は Twitter のハッシュタグでウォッチ

聞き漏らした内容を Tweet してくれる人がいる。 また、発表内容に対する意見をツイートする人もいる。 大抵のカンファレンス・イベントではハッシュタグが指定されるのでツイートしないでもウォッチはしておいたほうが良い。

💡【気付き】運営は常に発展途上

運営は有志で行ってくれていることを理解して感謝している。

その上であえて言うなら

  • カンファレンスに WIFI が通ってなかったり、
  • カンファレンスサイトが HTTPS でなく HTTP だったり、
  • デザインも何故かシャドウがないなんちゃってマテリアルデザインだったり、
  • タイムテーブルの縦横が逆の方が見やすい UI だったり

etc…と、各カンファレンス・イベントのそれぞれの運営に対するアラやツッコミ所はかなりある。 だが、運営は常に発展途上であることをきちんと理解する。 もしこのツッコミどころに物申したいなら、本人が次のカンファレンススタッフとしてそこを改善していくべき、だという認識を持つほうが良い。

💡【気付き】モチベーションが簡単に上がる

カンファレンスに行っても実装することは無いし、実装を強制することもない。 だが、その制限が逆にモチベーションを上げてくれる。

もしモチベーションが低下している人がいたらカンファレンス・イベントに行かすと良い。 理想はカンファレンスの次の日にまとまった時間を取れて、そこで実装や学習を行える環境を作ること。 日々の業務でモチベーション低下が起きてしまうこともある以上、モチベーションコントロールも大事な要素だと思う。

そのため、「カンファレンスを聴講する」という行動をモチベーションを上げる手段の1つとして考えておくとよい。

💡【気付き】コミュニティごとの色がある

所感だがそれぞれ下記のような色があった。

  • JS・Elixir   →  どこのシステムでもモダンな構成・ツール・サービスを利用している
  • Haskell   →   WAF での利用は少なく学術的な内容が多い
  • PHP   →  前提として長年運用しているサービスに対する知見で、対象者も初心者から上級者まで広い

💡【気付き】聴講せずに LT しに行くべき

LT は「入門者が勉強した」レベルの内容がかなり多いので、積極的に行うと良い。

完全に聴講者としてどのカンファレンスも参加したが LT で参加しても良かったと思う。 LT とはいえ登壇なのでその「経験」は個人の能力や経歴にきちんと蓄積される。 もちろん、ネタがあれば LT でなくて普通に登壇者として登壇しても全然問題無いケースも多かった。 (一部コミュニティや人によっては別だったが)大抵はマサカリは投げてこないように見える。

📊 まとめ

趣味としてのカンファレンス巡りはかなり楽しかったしカンファレンス通い慣れもした。 ただ、カンファレンスばかりに行っているといい加減に自分で実装したくなる。 カンファレンスの聴講はモチベーションが簡単に上がるので、今後はそういう使い方や立ち位置くらいに据えようと思う。

今後の基本方針としては「カンファレンスに行ったら LT で良いので自分が発表する」をモットーにしようと思う。