Above & Beyond

日々のアウトプット記録

Mercari SXSW 2019 報告会

参加報告

03/28(木) は「Mercari SXSW 2019 報告会」に参加してきました。

mercaridev.connpass.com

f:id:kabukawa:20190324221624p:plain:w500

会場は 株式会社メルカリ さん。

f:id:kabukawa:20190330144550j:plain

相変わらず広くてきれいなスペースです。しかも六本木ヒルズ。

ここに来たのは Search Engineering Tech Talk #1 という勉強会で来たとき以来なのでちょうど1ヶ月ぶりですね。

kabukawa.hatenablog.jp

目次

Mercari SXSW 2019 報告会 とは

イベントの概要から引用します。

2019年3月8日から17日にかけて、アメリカ合衆国テキサス州オースティンで音楽と映像とインタラクティブメディアの祭典である SXSW ( サウス・バイ・サウスウエスト ) が開催されます。 https://www.sxsw.com/ SXSW と聞くと 音楽と 映像 のイメージが強いかもしれませんが、昨今の SXSW では Blockchain や AI/Machine Learning、さらに VR/AR などといった、巷で話題の注目すべき技術が取り上げられ、技術のショーケースとも言えるイベントとなっています。 メルカリでは 2018 年に引き続き Mercari BOLD Scholarship を実施し、学生とともに SXSW を視察してきます。 本報告会では、いくつかのトピックを挙げ、BOLD Scholarship 成果報告会と合わせて現地で得た生の情報をお伝えいたします。

Mercari BOLD Scholarship についてはこちらを参照してください。

tech.mercari.com

何故参加したか

以前参加した CES 2019の報告会がものすごく刺激が有って楽しかったので、Mercari の R4D の勉強会にまた参加したいなぁと思っていたのと、Mercari BOLD Scholarship の報告が面白そうと思って参加しました。

kabukawa.hatenablog.jp

タイムテーブル

時刻 説明
18:30〜 Check-in
18:45〜 Warm-up: 写真で見る SXSW 2019
Mercari, Inc. R4D XR 諸星 一行 @ikkou
19:00〜 Opening
19:05～19:45 Mercari BOLD Scholarship for SXSW 2019 成果発表 ( 10min )
topic 1 : デザイナー志望の学生がSXSWで見た【デザインと未来】
Ryohei Ano @e__cafe
topic 2 : SXSWで見えた未来の生活
Haruka Aoki @haruka0109_a
topic 3 : SXSW2019 - FOOD&TECH -
Masaki Ohno @Masaki_ponpoko
topic 4 : 出会い、学び、共有する。 -現地で感じるSXSWの本質とは-
Chihiro Ban @baaan_ch
19:45～20:00 Short Talk I: SXSWでみたXR関連トピックス!!
Mercari, Inc. Internship @zawazawatw × @omeme_1231
20:00～20:05 Break time
20:05～20:20 Short Talk II: Yet Another South by South west, Gaming and Film Festival
Mercari, Inc. R4D XR 里見 充則 @gravitino
20:20～20:35 Short Talk III: jollyは見た！Interactive Innovation Awards 2019
Mercari, Inc. Engineering Office 七島 偉之 @jollyjoester
20:35～20:50 Short Talk IV: SWSXで気づいた今までのロボットに足りなかったもの
Mercari, Inc. ブランディングメディアチーム 原田 和英 @kazuhide
Mercari, Inc. ブランディングメディアチーム 宮川 直実
20:50～21:05 Short Talk V: Japan to Texas
Guest: LINE株式会社 Developer Relations 藤原 聖 @satorufujiwara
21:10～22:00 Wrap up party

内容

既に当日のツイートが纏められています。早っ！

Mercari SXSW 2019 報告会 まとめ #mercariSXSW

togetter.com

最初にお弁当と飲み物が配られて和やかな雰囲気の中で始まりました。 f:id:kabukawa:20190330145046j:plain

Warm-up: 写真で見る SXSW 2019

Mercari, Inc. R4D XR 諸星 一行 @ikkou さん

f:id:kabukawa:20190330145448j:plain:w300

speakerdeck.com

こちらを参照すると話されていた内容＋時間の関係で飛ばされたところ等も書かれているので是非こちらを参照してください。

twitter.com

ツイート：

topic 1 : デザイナー志望の学生がSXSWで見た【デザインと未来】

Ryohei Ano @e__cafe さん

f:id:kabukawa:20190330151815j:plain:w300

speakerdeck.com

note：

note.mu

ツイート：

topic 2 : SXSWで見えた未来の生活

Haruka Aoki @haruka0109_a さん

f:id:kabukawa:20190330151836j:plain:w300

www.slideshare.net

ツイート：

topic 3 : SXSW2019 - FOOD&TECH -

Masaki Ohno @Masaki_ponpoko さん

f:id:kabukawa:20190330151902j:plain:w300

speakerdeck.com

togetter.com

ツイート：

topic 4 : 出会い、学び、共有する。 -現地で感じるSXSWの本質とは-

Chihiro Ban @baaan_ch さん

f:id:kabukawa:20190330151927j:plain:w300

当日はリモートからの参加でした。

speakerdeck.com

banchii1118.hatenablog.com

banchii1118.hatenablog.com

ツイート：

Short Talk I: SXSWでみたXR関連トピックス!!

Mercari, Inc. Internship @zawazawatw さん
Mercari, Inc. Internship @omeme_1231 さん

f:id:kabukawa:20190330152041j:plain:w300 f:id:kabukawa:20190330152024j:plain:w300

www.slideshare.net

zawazawahtn.hatenablog.com

zawazawahtn.hatenablog.com

note.mu

ツイート：

Short Talk II: Yet Another South by South west, Gaming and Film Festival

Mercari, Inc. R4D XR 里見 充則 @gravitino さん

f:id:kabukawa:20190330152142j:plain:w300

www.slideshare.net

ツイート：

Short Talk III: jollyは見た！Interactive Innovation Awards 2019

Mercari, Inc. Engineering Office 七島 偉之 @jollyjoester さん

f:id:kabukawa:20190330152225j:plain:w300

speakerdeck.com

ツイート：

Short Talk IV: SWSXで気づいた今までのロボットに足りなかったもの

Mercari, Inc. ブランディングメディアチーム 原田 和英 @kazuhide さん
Mercari, Inc. ブランディングメディアチーム 宮川 直実 さん

f:id:kabukawa:20190330152312j:plain:w300 f:id:kabukawa:20190330152255j:plain:w300

[資料は非公開だそうです]

ツイート：

Short Talk V: Japan to Texas

Guest: LINE株式会社 Developer Relations 藤原 聖 @satorufujiwara さん

f:id:kabukawa:20190330152411j:plain:w300

[資料は非公開だそうです]

ツイート：

その他

今回発表のなかった方も含めて、SXSW 2019に参加したMercari R4Dの方々のツイートの纏めがこちらです。

メルカリメンバーの見た #SXSW2019 まとめ #mercariSXSW togetter.com

こちらは Nakaji Kohki / リリカちゃん @nkjzm さんの Twitter モーメントです。

【SXSW2019】オースティン視察まとめ #mercariSXSW twitter.com

懇親会

セッションが盛り上がって時間が押していましたが、皆さん熱心にスピーカーの方々と話をされているのが印象的でした。

まとめ

当日はとにかく圧倒的なアウトプットを受け止めるので精一杯で咀嚼する余裕がありませんでした。 こうやって振り返って見てみると、改めて凄いなぁと思います。

Mercari BOLD Scholarship という取り組みを始めたからこそ、これだけの成果を見ることができた訳で、素晴らしいなぁと思いました。

アウトプットも感じたことをストレートに出していて新鮮でしたし、刺激をたくさん受けました。

本当に参加できたことに感謝です。

ありがとうございました！

Docker Meetup Tokyo #29 (Docker Bday #6)

参加報告

03/27(水) は「Docker Meetup Tokyo #29 (Docker Bday #6)」に参加してきました。

dockerjp.connpass.com

f:id:kabukawa:20190324220349p:plain

会場は 日本電信電話株式会社 さんの ソフトウェアイノベーションセンタ 。

f:id:kabukawa:20190329124800j:plain

目次

Docker Meetup Tokyo とは

グループの概要から引用します。

オープンソースの軽量コンテナ Docker のmeetupです.

何故参加したか

なんだかんだ言いつつも、コンテナと言えばDockerだと思いますし、面白いから、ですかね。

タイムテーブル (Time table)

時間 内容 発表者 (敬称略)
18:30 開場 (Door open)
19:00 イベントスタート (Event begins) Akihiro Suda (@AkihiroSuda)
19:05 簡易コンテナを作ってみる Gorilla (@gorilla0513)
19:20 コンテナベースアプリケーションの設計原則と現実 Kazuki Higashiguchi (@hgsgtk)
19:35 Dive into BuildKit LLB Hiromu Nakamura (@po3rin)
19:50 開発・CI・運用における Docker 戦略（クラシコムの場合） takeru0757
20:05 スポンサーセッション1 CREATIONLINE
20:15 スポンサーセッション2 Forkwell (Grooves Inc.)
20:25 ネットワーキング (Networking) 各自
21:50 撤収開始 (Clean-up) 有志
22:00 終了 (Door close)

内容

Akihiro Suda (@AkihiroSuda) さんによるオープニング。

f:id:kabukawa:20190329133338j:plain:w300

今回はDocker 誕生から6周年を祝う Birthday イベントも兼ねて行われました。

f:id:kabukawa:20190329134709j:plain:w500

Docker 社公式Blogでも世界中で Docker 誕生から6周年を祝う Birthday イベント が行われていることが書かれています。(もちろん日本も！)

blog.docker.com

そしてもう一つ。DockerCon 2019のチケットが 20% OFF になる登録コードが発表されました。DockerCon 2019に参加しようと考えている方は是非利用してください！

dockercon19.smarteventscloud.com

DOCKERBDAY20 です！

f:id:kabukawa:20190329134412j:plain:w300

Dockerの周辺OSS

Gorilla (@gorilla0513)

f:id:kabukawa:20190329133051j:plain:w300

f:id:kabukawa:20190329131857p:plain

Try make a simple container(Docker Meetup Docker #29) - Google スライド

コンテナと仮想化の違いについて

f:id:kabukawa:20190329143114p:plain:w300 f:id:kabukawa:20190329143128p:plain:w300

  • 仮想化はコンピューター自身をソフトウェアで仮想化した環境を作る
  • コンテナは　Linuxカーネルの機能を利用してリソースを分離・制限する

リソースを分離・制限している仕組み、namespace と control groups(cgroup)について

f:id:kabukawa:20190329143606p:plain:w300 f:id:kabukawa:20190329143623p:plain:w300

どのように namespaces を使っているか？

system call 機能
unshare system call 現在のプロセスを新しいnamespaceに関連付け
clone system call 新しいプロセスを新しいnamespaceに関連付け
setns system call 現在のプロセスを既存のnamespaceに関連付け

どのように control groups を使っているか？

  • cgroup-tools(libcgroup) を使用
    • cgcreate: 新しい group を作成
    • cgdelete: 既存の group を削除
    • cgexec: 既存の group 上でコマンドを実行
  • cgroupfs によるファイル操作
mkdir /sys/fs/cgroup/cpu/$UUID
sudo echo 50000 | sudo tee /sys/fs/cgroup/cpu/$UUID/cpu.cfs_quota_us
echo $$ | sudo tee /sys/fs/cgroup/cpu/$UUID/cgroup.procs

コンテナツールとして紹介されていた３つのツール。3つとも日本の方が作成。

MINCS github.com

aqr(AQuaRium) github.com

Haconiwa github.com

まとめ

f:id:kabukawa:20190329150635p:plain:w500

Gorilla (@gorilla0513) さん作成のツールについてはこちらで。

qiita.com

個人メモ：

  • コンテナは　Linux カーネルの持つ namespace と control group という仕組みの組み合わせで実現されている。
  • System Call とか cgroup とか カーネルランド/ユーザーランド はLinux使いとしては知っていたけど、改めて復習した感じ。
  • 仕組みがわかれば bash とgo でコンテナを作成できるというのが面白い。そういう風に使うのか、という驚き。

コンテナベースアプリケーションの設計原則と現実

Kazuki Higashiguchi (@hgsgtk)

f:id:kabukawa:20190329133112j:plain:w300

speakerdeck.com

トークの概要

1.構成

構成の機能

  • "実行時"データ（起動時に必要）
  • 環境ごとに異なる
  • 多くの値

構成に対する要求

  • 階層的に管理する
  • 構成をわかりやすくする
  • 設定を外部化する
  • アプリケーションから設定を取り除く
  • 最小限のアクセシビリティ
  • 設定にクレデンシャルが含まれている

関連する原則

構成：実例

devblog.thebase.in

設定：実際の問題

  • クラウドベンダが提供する機能に依存
  • うまく統合された機能なら、「シンプル」に
  • そうでない場合は「複雑」になる場合がある

例：Fargate＆Parameter Store

  • パラメータストアを外部設定ストアとして使用する例
  • プラットフォームバージョン1.3より前と後で異なる

2.ロギング

ロギングに対する要求

  • リアルタイム
    • 「今起こっていること」を知る
  • 可用性 *ログが無い、ということが無い
  • 検索中
    • 問題の原因の特定を「簡単」にする

関連する原則

“06. LOGS”

  • ログをイベントストリームとして扱う
  • ファイルシステムに依存しない
  • STDOUT / STDERRの「ログ」
  • ツールを使用する（例：ElasticSearch、Logstash、Kibana）
    • 集約の要件を満たすため
    • ログの処理、保管

ロギング：実例

qiita.com

3.アプリケーションの構築

アプリケーションの構築に対する要求

  • 依存関係管理      * アプリケーションの依存関係を管理する
  • 異なる環境で稼働      * ローカルでの稼働、品質保証、状態、本番稼働

アプリケーションコンポーネント

  • ランタイムエンジン
  • コード
  • 依存関係
  • 構成(設定)

コンテナアプリケーション

  • コンテナには以下のものを含む
    • ランタイムエンジン
    • コード
    • 依存関係
  • 構成(設定)は起動時に注入

関連する原則

アプリケーションを構築する：本当の問題

  • ベストプラクティス：同じコンテナがすべての環境を提供
  • しかし、ローカル環境では、開発効率も重要

自分たちに合ったバランスを見つける

  • Docker for local
    • メリットを弱める
    • 開発者を強化する
  • 適切なバランスを見つける必要性

4.モニタリング

モニタリングに対する要求

  • 健康状態をチェックする      * モニタリングするアプリの健康
  • メトリクスを見続ける      * メトリクスを見続ける

関連する原則

HIGH OBSERVABILITY PRINCIPLE (HOP)

  • コンテナを「ブラックボックス」のように扱う
  • さまざまなステータスチェック用のAPIを提供する
    • 活動状況
    • 準備状況
  • STDOUT / STDERRに重要なイベントを記録する

Health endpoint パターン

Mackerel Container Agen

mackerel.io

個人メモ：

  • 最後のモニタリングの部分、Health endpoint パターンとか聞き覚えがあると思ったら先週参加した Rancher Meetupで @songmu さんが話していた内容だった。

kabukawa.hatenablog.jp

*「Practical Monitoring」は 日本語版は「入門監視」ですね。

入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

  • これだけの内容を話すにはもっと時間が必要ですね、と内容を読み直してこれを書きながら思いました。

Dive into BuildKit LLB

Hiromu Nakamura (@po3rin)

f:id:kabukawa:20190329133130j:plain:w300

speakerdeck.com

Buildkitの内部の仕組みなどについての内容。

Moby とは

BuildKit とは

  • Moby Engineの現在のビルド機能の内部を置き換えることを目的とした新しいコードベース
  • Docker v18.0.6以降では 環境変数で BuildKit を有効にできる

LLB(Low-Level intermediate build format)

  • BuildKitはローレベル中間ビルドフォーマット(LLB：Low-Level intermediate build format)を採用し、ビルドの実行パスを依存グラフ構造で表現できるようにした。
  • BuildKitがビルド高速化を可能にした立役者。
  • 命令間の依存関係をDAG(Directed Acyclic Graph)として表現することで、命令の並列実行と正確なキャッシュ判定を実現

llb2dot

  • DockerfileをLLBとして解析しDOT言語に変換するツール

github.com

llb2dotについての発表資料も見つけたので貼っておきます。

speakerdeck.com

DAG(directed acyclic graph) in LLB

f:id:kabukawa:20190330122621p:plain:w500

LLBは任意の入力を変換して生成。最終的に build deamon がビルド成果物を指定されたexporterの形式で出力

f:id:kabukawa:20190330122657p:plain:w500

LLBの構造の仕様

github.com

Function to convert Dockerfile to LLB

github.com

Dockerfile2LLB は内部でDockerfileをASTに変換しているので、DockerfileのLinterも作成可能

github.com

ビルドフローを見ると、LLBさえ生成できれば、Frontendは何を使っても良いことになる

オリジナルの BuildKit LLB frontendの例

github.com

カスタムフロントエンドを作成する簡単な方法

  1. 任意のフォーマットからLLBに変換する処理を作る
  2. buildkitが提供するGateway APIを使う
  3. 一連の処理をバイナリ化してDockerイメージで実行できるようにしておく

[f:id:kabukawa:20190330125043p:plainw500]

個人メモ：

  • LLBというのを初めて知った。
  • llb2dotを使うとDockerfileのビルドを可視化できる。これは面白い。
  • 面白そうなので引き続きLLBについてはウォッチしていきたい。

開発・CI・運用における Docker 戦略（クラシコムの場合）

takeru0757

f:id:kabukawa:20190329133144j:plain:w300

speakerdeck.com

クラシコムの ”北欧、暮らしの道具店” のコンテナ化を紹介。

hokuohkurashi.com

技術スタック

課題

  • アプリケーションが細分化されている
    • 連携する複数アプリケーション・ミドルウェア（※マイクロサービスではない）
  • Opsworksでデプロイ
    • Chefのコードが肥大化していて秘伝のタレみたいな状態に。

コンテナ(Docker)化で達成したいこと

f:id:kabukawa:20190403142811p:plain

The Twelve-Factor App （日本語訳）

  1. エンジニア間における開発環境の統一
    • 自分用につくった docker-compose.yml + Dockerfile を独立したリポジトリとして社内で共有。
    • → エンジニア間での開発環境は統一できつつある ☺
  2. 開発とCIにおける環境の統一（進行中）
    • 環境を統一したいのに、必要となるものが微妙に違う
      • 開発環境：PHP + Xdebug + node + nginx
      • CI：PHP + Xdebug + node + git (for CircleCI)
    • 異なるものを1つのものでカバーするのは違和感がある。
    • ベースとなるDockerfileから派生版を作るスクリプトを書いてみたりしているが、使い方のノウハウが必要になってしまうのが課題。
    • Dockerfileで条件分岐が欲しい
    • docker build でターゲット指定すると条件分岐的なことができる docker build --target
  3. プロダクションと開発・CIにおける環境の統一（進行中）
    • 本番環境のコンテナ化。
    • 昨年、アプリケーションの１つを全面的に書き換えを行い、それに併せてKubernetesを導入しようとしたが挫折
    • 現在はAWS ECSを導入する方向で進んでいる。（将来的にはKubernetesに再チャレンジしたい）

docs.docker.com

クラシコムさんのコンテナ化についてはこちらも参照してください。

speakerdeck.com

個人メモ：

  • 条件分岐をできるようにすると結局複雑化して秘伝のタレ、みたいになる気がしなくもない。
  • どうしても参加したいから登壇した、というところが凄い。
  • 会場の反応を見る限り、コンテナ化をする時に悩むポイントはあまり変わらないのかな、と思った。

スポンサーセッション1

CREATIONLINE

f:id:kabukawa:20190329133158j:plain:w300

クリエーションラインさんの提供するDocker, Chef, などなど。k8s のサービスとトレーニング

www.creationline.com

DockerやKubernetesに対応するコンテナイメージ共有ソフトウェア「Beiran」

beiran.io

スポンサーセッション2

Forkwell (Grooves Inc.)

懇親会

ケーキがあると盛り上がりますね！しかも今回はお寿司もあって豪華！

f:id:kabukawa:20190329133219j:plain

ケーキもお寿司もとても美味しかったです！ 去年に引き続き、Tシャツもいただきました！ありがとうございます！

まとめ

最近抽選から外れたり、他の勉強会と日程が重なって参加できなかったりしたので、今回はだいぶ久しぶりでの参加でした。 でも、去年に引き続きBirthdayイベントに参加できたのは本当に幸運だったと思います。

話されている内容も、どれも内容が濃くて勉強になることがたくさんありました。 1年経って、勢いは未だ衰えず。スピーカーや参加者、そしてスタッフの方々の熱気が本当に凄いなと感じました。 (その感じがこの記事を通して読んでいる人に伝わるといいなと思います)

スピーカー、スタッフ、参加者の皆様、ありがとうございました！

勉強会の参加者として自分が気をつけてること

思ったこと

勉強会に参加したいなと思ったら、誰でも気軽にConnpass等のサイトから申し込んで参加することができます。 勉強会に参加すれば知識を得られるだけでなくエンジニア同士のつながりもできるので、個人的にはできるだけ沢山のエンジニアが参加してほしいと思っています。 一方で、気軽に参加できるあまり、他の参加者から迷惑と思われたり主催者に迷惑をかけるような行為が問題になっている、という現実もあります。 そこで、このエントリでは、勉強会の参加者として自分が気をつけてることを書いてみます。

f:id:kabukawa:20190328133629p:plain

目次

大前提

企業の開く「セミナー」とは違って、勉強会を開催・運営している人の多くはコミュニティの一員として、ボランティアで参加をしています。 異論は有ると思いますが、勉強会というのは自分たちが好きなことについて知りたい/知識などを共有したいということで集まったコミュニティだと自分は理解しています。なので自分が勉強会に参加するときには

「コミュニティに参加する」

という気持ちで参加するように心がけています。

コミュニティなので、

  • 「売りたい人」「買いたい人」
  • 「教える人」「教えてもらう人」
  • 「運営する人」「参加する人」

という 一方的な関係ではなく、一緒に作り上げていくもの。 これがこれから書く内容の大前提となる考え方です。

参加前に気をつけていること

  1. 直前のキャンセルはなるべく避ける
  2. 事前に用意すべきものなどが指定されている場合はきちんと準備する
  3. 受付/入館方法をよく確認する
  4. 会場で用意されている設備を確認する
  5. スマフォに入れているアプリ

いまさら言うまでもなく、どれも確認しておかないと自分だけでなく主催者や他の参加者にも迷惑をかけることになるので、自分は必ず確認しています。

1. 直前のキャンセルはなるべく避ける

勉強会の主催者は参加者の人数によって、例えば会場の椅子の数や懇親会の飲み物、食べ物などをどれだけ用意すればいいか決めています。 開催の当日にキャンセルが発生すると、

  • 事前準備(会場設営、ノベルティ、飲み物や食べ物など)が無駄になる
  • 代わりに繰り上げになった人が当日調整する余裕がなくて参加できない

といったことが発生することになります。 もちろん、当日急に体調が悪くなったり、業務の都合で参加できなくなることはあるので仕方ない部分もありますが、参加できないと分かったら早めにキャンセル処理をしましょう。更にまずいのは キャンセル処理さえせずに参加しない行為 です。キャンセル処理をしなかったばっかりに参加できたはずの人を参加できなくしてしまう。自分が逆の立場だったら嫌だなと思うので、本当に気をつけています。まとめると

  • キャンセル処理は必ず行う。
  • できるだけ早くキャンセルする。

ということが大事、ということです。

あと、これとは逆に、体調が悪いのに無理やり参加するというのも避けたほうが良いです。せっかくの勉強会なのに楽しく参加できないのは勿体無いですし、もし他の人に病気を伝染すようなことになったら大変です。体調が悪いときは無理せずキャンセルしましょう。

勉強会によっては以下のようなものが後日公開されることが多いので、キャンセルしたとしても内容をフォローアップできると思います。

  • 発表資料が共有される
  • Twitterで内容などがシェアされる
  • イベントレポートやブログが主催者や参加者によって公開される
  • 動画配信若しくは動画アーカイブ公開などがある

2. 事前に用意すべきものなどが指定されている場合はきちんと準備する

勉強会によっては、ハンズオン等で事前にPCにソフトウエアをセットアップして持ち込むことなどが指定されている場合があります。 こちらについても必ず事前に用意するようにしています。

  • インストールに時間が掛かるから事前にインストールを指定されている可能性がある
  • インストール済みであることを前提に勉強会(ハンズオン)が進行する

セットアップがうまくいかない場合もありますが、 事前に用意すれば嵌ったとしても時間の余裕があって調べたり主催者などに聞いたりすることもできる ので、これも大事なポイントだと思います。

よくわからないから当日会場でセットアップ方法を主催者に聞きながらやればいいや、みたいな感じで当日参加するのは避けたほうが良い です。

  • 会場でセットアップすると、貴重なWi-Fiの帯域を専有することになり、他の参加者にも迷惑がかかる
  • 会場でセットアップに手こずると、本題の方に着手できず何をするために参加したのかわからなくなる

各自のPCに何がインストールされているとか分かりませんし、OSのバージョンによる違いなどは主催者側もすべて対処できるわけではないです。 他の参加者の方がサポートしてくれるかもしれませんが、自分のPCのことが分かっていなければサポートもできません。 勉強会はパソコン教室ではありません。 事前に用意することで、どこがうまくいかないのかを知ることができますし、自分自身の勉強にもなります。

3. 受付/入館方法をよく確認する

これも事前に確認しておく必要があります。 会場によっては以下のようなものが受付時に必要になります。 (全部が必要なわけではなく、イベントページなどで指定されたものを用意しておくことになります) どんなものが受付に必要なのか、イベントページで必ず事前に確認しておいたほうが良いです。

  • メールなどで送られてくるQRコード若しくは入館用の来訪者番号
  • Connpass等のユーザー名
  • 参加票
  • 名刺

多くの場合、ユーザー名や参加票はスマフォ画面に表示して見せるだけでOKですが、たまに印刷したものが必要になるイベントも有ります。

名刺については、申込時の名前との確認や当日の名札として必要になるもので、個人名刺でも大丈夫です。 (少なくとも自分が参加した勉強会で駄目だったことはありませんでした)。 懇親会などでネットワーキングをするのに名刺交換をすることも多いので、10枚位は持っておいたほうが良いと思います。 (自分は持っています)

入館方法についても注意が必要です。 直接会場の入口まで行ける場合もあれば、別フロアで受付を済ませてから会場のある場所までエレベーターなどで移動するような場合もあります。 いずれにしても、イベントページや主催者からのメールで指示がされていると思いますので、必ず事前に確認しておきます。

入館方法についてはもう一つ大事なことが。 どうしても開始時間に間に合わず、遅刻するケースは結構あると思います。 時間によっては受付が撤収されてしまうこともあるので、遅刻した場合の入館方法も確認しておくと安心です。 受付が撤収される運用の場合はイベントページに

  • xxx時まで受付机を設置
  • 以降に来た場合はTwitter等で連絡して迎えに来てもらう

といった指示が書かれていることが多いです。必ず確認します。

あ、一番大事なことなんですけど、会場の場所は事前に必ず確認しておいたほうが良いです。 地下鉄の場合は特に、出口とか確認しておかないと結構迷います。 (経験者談)

4. 会場で用意されている設備を確認する

これは主にPCを持ち込む場合が該当しますが

  • 電源の有無
  • Wi-Fiの有無

は確認しておいたほうが良いと思います。

電源は提供されている会場も無くはないのですが、コンセントの設置形状の関係でMacBookの電源を挿すと抜けなくなるとか数が限られていることがあるので、3つ口くらいのタップを用意しておくと良いかもしれません。(自分のPCはバッテリーが結構持つので1日がかりのカンファレンスに参加するとかじゃなければタップは持ち歩きませんが、)

Wi-Fiについては会場によっては登壇者とスタッフのみに開放していたり用意されていない事もあるので、テザリングを使えるようにしておくとか、PCを諦めてスマフォのみで参加するといった対処が必要になったりします。なので事前に確認(イベントページにWi-Fiの有無は書いてあることが多いです)をしておいたほうが良いと思います。

5. スマフォに入れているアプリ

以前記事を書いたので、参考にしてください。

kabukawa.hatenablog.jp

カメラのシャッター音については最近いろいろな会場で指摘を受けることが多いので、無音化若しくは無音のカメラアプリは入れておいたほうが良いと思います。

Android(自分が使っているやつ。機能制限は有るけど無料版もあります)

play.google.com

iPhone(Microsoftが提供する無料のアプリ)

Microsoft Pix カメラ

Microsoft Pix カメラ

  • Microsoft Corporation
  • 写真／ビデオ
  • 無料

デジカメは機種によるので参考までに記事を貼っておきます。

higashisa.com

参加時に気をつけていることを書こうと思っていたのですが、だいぶ長くなったので次回にします。

勉強会に参加するに当たっての参考にしてもらえると嬉しいです。