search term:

ライフスタイルとしての ScalaMatsuri

僕にとって ScalaMatsuri とはライフスタイルのようなものだ (他の 27名近くいるオーガナイザーも同じように思っているんじゃないだろうか)。確かに、近日東京で 550名を動員したカンファレンスがあって、それは成功に終わった。しかし、オーガナイザーは 2015年の 2/28 からかれこれ 11ヶ月間準備してきた。僕が関わったのは一部でしかないけども、ScalaMatsuri 2016 はこれまでで一番関わりの深いカンファレンスになったと思う。この何ヶ月の間 Slack、Hangout たまには対面で、さまざまな議論を重ねてきた。面白かったのは、一緒にアイディアを出し合ってそれが実現されるのをみることだったと思う。僕が奇抜なアイディアを出して、その詳細を誰かが実行してくれることもあれば、他の人が始めたことを元に僕が現場の作業をすることもあった。

色々言いたいことは「グローバルな技術カンファレンス」と「日本のコミュニティの交流」の両立でも書いちゃったので、かぶる部分もあると思う。

2015年3月

2015年の 3/16 の段階で既に ScalaMatsuri 2015 の準備は回り始めていた。何故覚えているかというとそれは麻植さん (@oe_uia) が法被を来て Scala Days San Francisco に登場したからだ。カンファレンスと一緒にスキーやスノボもできるようにということで、あの場の雰囲気で 2016年の 1月にずらそうというアイディアが生まれた。

ホテル街は Scala Days の会場から少し歩く所にあってその帰り道で麻植さんと CFP を公開して固定費で旅費サポートを付けようという話をしたのを覚えている。これは少なくとも 2014年 (カンファレンスでのユニバーサル・アクセスへ向けて) ぐらいから考えてるアイディアで、非公開で誰かを招待してその人達の旅費を払うのに比べていくつもの利点があると思っている。カンファレンスを延期したことで以前より長い準備期間を得ることができたので、やってみる見込みがたった。

Github issue all the things

今回から以前のカンファレンス準備で使われていた Trello や co-meeting から Slack と Github issue の組み合わせに乗り換えた。 両者はそれぞれを補完する関係にあって、よい決断だったと思う。ラベルを使って issue を担当チームに割り当てるという運用をしていて、これもうまくいっていたと思う。

小さいタスクが大量にできてきて Github issue で困ったのは、特定のタスクが今どういう状況にあるのかを把握するのが難しいということだった。何かが起こるのを待っているのか、もしくは誰かが作業中なのか、といったことだ。issue の subject に括弧書きでミニ・ステータスを書くということをやってみたけども、翻訳タスクなど事前に明確にステップが定義されているタスク類に関してはこの括弧書き方式はうまくいったと思う。

「和」を想起させる web サイト

準備の早期の段階ではオーガナイザーは月一ぐらいのペースで会っていたと思う。僕を含め東京に住んでない人もいるので、ミーティングは Google Hangout でストリームされて、Hangout もしくは Slack 経由で議論に参加できた。

5月に話題になったのは、海外からの登壇者や参加者にアピールするために「和」を想起させるような、綺麗な landing page 的なサイトを作ろうという話だった。クラウドワークスで公開コンペが行われてこのプロジェクトはデザイナさんに頼むことになった。それ以降のサイトのメンテは河内さん (@kawachi) が主に行っていて、サイトのソースも scalajp/2016.scalamatsuri.org で公開されている。

プロによる双方向通訳

2013年と 2014年は発表資料には字幕、実際の発表時には kaigi_subscreen クローンを使ってテキスト翻訳を提供するという作業をしてきた。(詳しくはこれを参照) 準備時間が何週間かあるので字幕の翻訳は何とかなったけども、ライブ翻訳の質は理想からは遠いものだった。2014年になって参加者も増えてくると、英語のセッションに付いていくのが難しいという不満の声も多く聞くようになった。プログラマの多くが普通に英語を聴いたり、会話しているベルリンやアムステルダムといった西欧の都市とは対照的な問題だと言える。

PyCon JP、YAPC::Asia Tokyo、Ruby Kaigi といった他のカンファレンスに続く形で僕達も KY Trade さんの双方向通訳を 2つの会場で採用することにした。全般的にこれは成功したと言えると思う。通訳の業者を調査したり、色々な調整を担当したのは翻訳チームリーダーの岡本さん (@okapies) が担当した。

tシャツデザイン

ScalaMatsuri はカッコいい tシャツを作るべきだと思っていて、今年はそれをやる絶好の機会だった。 Web サイトと同じく、日本の祭りというコンセプトを想起させる tシャツが欲しかった。それと同時に、和柄でもチンピラっぽくなってしまったり国粋的になってしまうことは避けたかった。デザインのモチーフは神輿を担ぐのに職人さんが来てそうな法被とか鯉口シャツ。

このコンセプトを知人のつてでグラフィックデザイナーの Shun Sasaki さんに持ち込んで、実際の形に仕上げてもらった。佐々木さんが色々提案をして、「藍色はもっと黒に近いもの」とか、僕個人の意見と他の企画チームのメンバーの意見を取り込んでフィードバックを返すというのを繰り返す作業だ。

カタカナとかひらがなみたいな日本っぽいタイポグラフィを使ってみたらどうか、などと僕が実験的な方向に導いてしまい、結局それはデザインとしてアバンギャルドすぎて、やっぱりテキストを極限まで排除したミニマルにしようと方向転換するということもあった。そんな我儘にも佐々木さんは始終普通に対応してくれて、最終デザインは僕としては満足度の高いものとなった。

僕が一人で tシャツばっかりこだわっていたけども、青山さん (@aoiroaoino) は ScalaMatsuri が提供するノベルティであるスタッフ用パーカ、参加者用のトートバッグ、シール、ノートなど他の全てのものを担当していた。商品を選んだり、サンプルを取り寄せたり、これも様々なステップがある作業だ。佐々木さんの tシャツデザインが、今年のノベルティ全品のデザインとして採用されることになった。

8月4日、公開 CFP

海外からはるばる日本でトークをやってもらうことを説得するとき、大切なのは十分に時間の余裕を与えることだ。

僕たちは 8/4 の時点で CFP を公開したから、だいたいカンファレンスの 6ヶ月前に開始して、10/15 まで受け付けていた。幸いなことにこの期間は Scala World とも重なっていたので、そこでも麻植さんが Matsuri 普及の根回しを地道に行っていた。最終的に 60 本の英語セッション、57 本の日本語セッションの提案をもらうことができた。

セッションは Google Forms を使って集められた。岩永さん (@kiris) はこれを Github issue に変換するというような自動化を実装していた。

ユニバーサル・アクセス

ScalaMatsuri オーガナイザーの中で僕が推していたアジェンダの一つに行動規範というものがある。世界中の技術カンファレンスで参加者の間口が広がっていく中、不愉快な状況とかハラスメント事件などの報告が増えてきている。もしくは、今までもずっとこういうことは起こり続けていて、最近になってやっとそれを公の場で話すための言葉を得たというだけのことかもしれない。いずれにせよ、2014年に ScalaMatsuri は PNW Scala、nescala、Scala Days でも採用されている Geek Feminism 由来の行動規範を採用した。

しかし、We Still Let Harassers Participate In Our Community や人づてで聞いた他の酷いインシデントを省みるにつれ、ただ単に webサイトに普通の行動規範を載せているだけでは不十分だということが自分の中で明確になった。

第一に僕が提案したのは人に言い寄ること (making advances)、つまりナンパ行為などに関してより厳格な規則を採用することを提案した。厳格というか、禁止した。この話をすると参加者の行動を制限するという考えに対して不快感を覚える人が多い。それは普通のリアクションだと思う。しかし、考えて欲しいのはやられる側の不快感とそれが僕たちのカンファレンス与える被害はそれを何倍も上回るものだということだ。誰かが勇気を出して公開 CFP にセッションを出して、トークを頑張って準備して、当日も緊張を乗り越えて発表したのに関わらず、どこかの勘違いした人のリアクションが「可愛い。今度電話してもいい?」である状況を想像してほしい。残念なことに、これは結構よくある話だったりする。

次に、もしセッション中に何かインシデントが発生した場合にどのように対応するべきかというプロトコルを議論した。各部屋ごとにレフリーを置いて、後で、もしくは必要ならばセッションを中断して警告を出すという方式にした。少なくともセッションという枠内ではレフリーの判定が絶対ということにした。

いくらルールばかり作っても、理念とか背景となる考え方を効果的に伝えることができないと無用の長物だ。Virgin Atlantic や Virgin America といった航空会社のマナービデオからヒントを得て、CoC を紹介するための動画を作ってはどうかという提案をした:

動画にすることで重要なポイントを逃さずに伝えることができるのと、一度作れば複数回再利用できるという利点がある。最初はこのアイディアは無理かと思われたけども、麻植さん (@oe_uia) が乗り気で、彼がアーティストのひなた かほりさんとの共同作業で実現してくれた。まず 9セットのキャラクターが提案されて、その中から僕たちオーガナイザーが選んだのは動物たちだった。話すポイントとしてまとめたものをひなたさんが絵コンテとして出してくれて、それをもとに台本を何回も練っていくという作業を行った。声はプロの声優の鈴夏 あやが一人四役で録音した。

キャラデザインのときに気をつけたのはバイキンマン、モンスター、ジャイアンというような明らかな悪役を避けたことだ。誰しもが偏見とか差別的な種となるものを持っていて、マジョリティ・グループは往々にして逆側がどう感じているかを意識していないことが多いという考えを取り入れたかったからだ。 行動規範の主となる目的はハラスメントが発生した時の対応方法が確定していることにある。しかし、より重要な二次的な効果は ScalaMatsuri がどこで線引をしているかというのを先制でシグナルすることにある。このシグナルがあることで、最初から「TPO 的にまずいかな」と思わせることで思慮に欠ける軽率なコメントを事前に予防できればいいと思っている。また、登壇や参加を考えている人たちへ、「matsuri は歓迎していますよ」というシグナルとしても届いてほしいと思う。

ただし、当然 ScalaMatsuri のオーガナイザーだって、個人としてマサチューセッツのヒッピーみたいな人ばかりではない。ただ、多様性があって楽しいカンファレンスという成果は誰もが認識していることだと思う。そういう意味では、このような努力に関して積極的にバックアップしてくれた人たちも、そうじゃなくてもここまで前線を上げることを容認してくれたオーガナイザー全員に僕個人としてすごく感謝している。

CFP 翻訳

翻訳チームのタスクで今回一番作業量が多かったのは 117本もらってきた CFP のセッション案のタイトルとアブストラクトを英語と日本語に訳すという作業だったと思う。僕が翻訳したのはそのうち 50本で、残りも他のメンバーが訳したものをレビューしたり訳し直したり、直されたりということをやっていた。翻訳チームのメンバーはあんまり固定していなくて、岡本さん (@okapies)、竹井さん (@taketon_)、木村さん (@kimutansk)、田中豪さん (@tan_go238)、田中翔さん (@tshowis)、岡田さん (@ocadaruma)、大村さん (@everpeace)、青山さん (@aoiroaoino)、河内さん (@kawachi) と複数名が関わっていた感じだ。

この翻訳する作業が必要だったのは国内と海外の両方から登壇者も参加者も呼びたかったためだ。もう一つの大きな理由は今年投票制に踏み切ったことにある。

一般投票制

nescala のファンとして、僕は一般投票推しだった。投票と言うと簡単に聞こえるが、どのパラメータを集計するかを考え始めると結構難しい問題だったりする。例えば、日本語と英語の言語比率はどう分けるべきだろうか? 英語のセッション案の 80% は 40分枠で、日本語のセッション案の半分以上は 15分枠だった。一人何票づつ投票すべきだろうか?

将軍スポンサーさん各社のお陰でスケジュールの半数を海外からの招待できそうという見込みが立っていたので、1日目は40分枠、15分枠ともに言語比率を 1:1 にすることにした。つまり、両言語とも 40分枠は 8人、15分枠は 3人という計算だ。 次に、カテゴリーごとの回答数を候補者の 25% に設定した。競争率を一定としたことで、言語をまたいで人気度を比較できるようしたわけだ。

独自の投票システムを実装する時間が無かったため、セッション名だけをランダムな順で表示する Google Forms を使って投票を行った。そのため、投票者はセッションをアブストラクトを読むためには、また別のランダム順に並んでいる別のページから探してくるということをやる羽目になった。これにより、多くの人がタイトルだけを見て投票するということが起こった可能性がある。もし、今後投票制を行う場合は、アブストラクトをちゃんと読めるようにするシステムの実装を検討するべきだ。

何百人もの人が 22本のセッションを選ぶ過程で観測されたのは、結果が似たようなトピックのクラスタを形成するということだ。もう一つ結果を見て気付いたのは、6本か 8本ぐらい他よりも明らかに多くの票を得たセッションがあったけど、あとは 1, 2票の差で緩やかな曲線を描いていることだ。

ScalaMatsuri のような複数トラックのカンファレンスの場合は、純粋な投票制とういうのはベストな結果を得られないのではないかと思い始めている。例えば、「FP 入門」とか「DDD 入門」というトピックが人気だったとしてもその内容で 10本やるのは楽しいカンファレンスと言えないだろう。回避策としては、投票で選ぶのは上位3位か 4位ぐらいにして、残りはオーガナイザーが手で選ぶということが考えられる。また、投票者がサイコロを投げて決めたとしても 全てのセッションに 25% 得票できる確率があったため、それを大幅に下回ったセッションは回避するべきという情報も得られたことも書いておきたい。

時間割

2013年の準備中に時間割を組んでる人たちに、Scala Days 2011 がやったみたいに 20分休憩をいくつか挟んだ方がいいよという話したのを覚えている。確かこの年の進行はそこそこうまくいっていたと思う。

2014年のプログラムはこの情報が抜けてしまった。おそらく、会場が隣同士だからかスケジュールは 5分か 10分の休憩だけでギチギチに組まれていた。さらに割り当ての時間よりもオーバーして話す登壇者がいたり、Linux のラップトップをプロジェクタにつなげるのを手こずったりして進行は大幅に遅れた。

今年も時間割に差し出がましく口出しをして、40分トーク + 20分休憩のシステムを復活させてもらった。トークを時間通りに始めたければ、出席する参加者は数分前には座っている必要がある。100人から 400人の人が部屋を出入りするだけで 5分から 10分はかかるだろう。さらにトイレとか階段みたいな遅くなるポイントを計算に入れる必要がある。20分休憩方式だと、参加者がコーヒーを一杯のんでスポンサーブースをひやかしに行くぐらいの余裕がある。

Scala Days からもう一つ借りてきたのはタイムキーパー担当の人をつけたことだ。以下は登壇者の人たちに僕が送ったメールからの抜粋だ:

To make sure everyone gets their turn, we’d have to be fairly strict about keeping time.

  1. Your scheduled END time does not change even if you can’t connect to the projector in the first 10 minutes. Please come early to get your PC connected.
  2. Someone who would be holding up a sign 10, 5, and 1 minute before the time is up.
  3. A bell would ring at the end.
  4. If possible, we’ll try to cut the sound off after exceeding 5 minutes past the end.

全員が順番に話せるように、時間に関しては厳守でお願いします。

  1. もし仮に最初の 10分間をプロジェクタとつなげるのに使ったとしても終了時刻は変わりません。お早めに会場に来て PC をつなげて下さい。
  2. セッション終了の 10分、5分、1分前に誰かが合図を行います。
  3. 時間切れするとベルが鳴ります。
  4. 5分超過した場合は、もし可能ならばマイクの電源を落としますのでご注意ください。

僕の知るかぎり、今年の進行はだいたい時間通りにいったと思う。

セッションの配置

セッションが選ばれた後、どう配置するかの提案をした。大きな制約として、メインの会場である国際交流会議場は 400人収容できるが、他の二つの会場であるメディアホールと会議室1 は 100人のみの収容で、さらに会議室1 には通訳さんがいないということがあった。

午前のセッションは、メインの会場を使って Reactive System とは何かということやそれがマイクロサービスとどう関わってくるのかという説明に使って、他のトピックは小さい会場に回した。午後のセッションは実践的関数型プログラミングに関連するトピックをメインの会場に持ってきて、Reactive System を含む他のトピックはメディアホールで続けるようにした。

瀬良さんのセッションがかなり人気で部屋から人が溢れるという事態が発生したらしい。これは会場の大きさに差があって、かつ各言語のバランスを取っていたからどうしても起こりうることだと思う。日本語のセッションの過半数の申請が 15分枠だったことを考えるとメインの会場に配置したのは妥当だったと思う。

スケジュールを公開するにあたって、web サイトをいじるというようなこともやった:

登壇者のサポート

CFP 関連に関わっていたのと翻訳チームにも入っているということで、以前のカンファレンスに比べて今年は特に海外からの登壇者の人たちと連絡する機会が多かった。

トラベル情報ページがあれば便利だと思ったので、まずはそれを書いた。これは選定された登壇者の人たちに CoC とか旅費サポートの制限に関する情報などと一緒に連絡された。

次に、登壇者の人たち全員に簡単にメールを打てるように Google Groups を作った。受け取る側も、ScalaMatsuri 関連のメッセージがリストから来ることで何らかの処理ができるはずなので便利になるはずだと思う。

12月22日、発表資料の字幕

最初に開催したときから、発表が日本語だとしても資料は英語にするということはずっとやってきてることだ。それに追加して、日本語での字幕も発表資料に付けている。今年少し工夫したのは字幕のフォーマットをちゃんと連絡したことだ。

翻訳チームは当日5週間前の 12/22 までに登壇者から発表資料を受け取って、英語話者の方の日本語字幕を付ける作業をした。日本語話者の方には英語本文と日本語字幕の両方をお願いして、僕たちが英語の部分をチェックするという作業を行った。当日にプロの通訳さんよりも関数型プログラミングや Scala 関連の専門用語に関しては多分僕たちの方が詳しいと思うので字幕を付けることで通訳さんの補助にもなったと勝手に思っている。

これも当然、全員が期日内の資料を提出してくれるわけもなく、カンファレンス当日まで翻訳の作業は続いていた。

実際の ScalaMatsuri

1日目は CoC レフリーをやっていたのでだいたいがメインの国際交流会議場に張り付いてセッションを見ていた。 僕が知る限りは、ScalaMatsuri 2016 ではハラスメントのインシデントは無かったと思う。

セッションの後で何人かと飲みに行くという機会もあったが、あっという間に 2日間は過ぎてしまった。登壇者とか参加者の人たちにもっと話しかける努力をしなかったのが自分の中での大きな反省点だ。逆に、僕に声を掛けていただいた皆さんには感謝している。

ランチ時間に @lyrical_logicalさんと Scala での型クラスが「ファーストクラス」という話から始まって lubbing の話をしたりしていた。観測されている問題点は Scala コンパイラの振る舞いとライブラリ側の実装の組み合わせに起因する所も多く、特に Scala コレクションライブラリの設計が、というところで意気投合した。自分は普通に Scala を書きたいだけなんだけど、（オーバーロードされすぎで意味論が汚染されている）継承は型推論には必要ないと言うと、Scala ではないというふうに思われるのはどうも納得がいかない所もある。いずれにせよ、こういう廊下セッションの方が本セッションよりも面白い。

猫という考え方

Cats の背景となっている考え方のを発表した。簡単に要約できるポイントに敢えて昇華させないで、複雑な背景も含めて伝えようとした。関数型プログラミングをちゃんと扱ったセッションには他にもあるだろうという期待があったので、その動機付けとしての背景に重点をおいたつもりだった。

Thinking in Cats from Eugene Yokota

色々詰め込んだ割には消化不足でちゃんと解説しきれてなかったのが色々各方面に申し訳ない。

sbt 人間

2日目のアンカンファレンスでは sbt 入門的な内容を発表資料無しで行った。 こっちは聴衆も小さめで、楽に話せる内容だったので、Cats の話よりはうまくいったと思う。

無制限のコーヒー

竹下さん (@takezoux2) のアイディアだと思うけど、今年のカンファレンス中ずっと学生ボランティアチームが複数のコーヒーマシンを使ってノンストップでコーヒーが淹れられていた。これは天才的だと言える。セッションの合間にコーヒーを飲んだりお菓子を食べるために人が集まってきて、そこで型システムの安全性などの会話が行われるからだ。このシステムは来年でも続けてほしい。ちなみに竹下さんは企画チームという、会場、広報と翻訳以外のほぼ全部をやっていたチームのリーダーで、CFP、ノベルティ、食事関連を担当したオーガナイザーの音頭を竹下さんが取っていた。

今後の課題

ScalaMatsuri は明らかに大きくなってきているため、今後とも継続的に運営をスケールさせる必要がある。これ以上運営を大きくさせる必要は無いと思うが、システムを堅牢化してより新しい人が入ってきて、いくつかタスクをこなして、去っていくというのをより簡単にできるようにするべきだと思う。そのためには、今いるオーガナイザーが全体のプロセスや詳細をドキュメント化して、毎年何でも再発明・再発見するのを避けるべきだと思う。

あと今年は取り組むことができなかったのはカンファレンスを赤ちゃんとか子供に優しいものにすることだ。日本のお祭りならば境内に子供が走り回っているが、僕はそれが Matsuri の目指す方向の一つだと考えている。いくつかの航空会社がやっているように入り口付近の座席をいくつかプライオリティーシートとして用意して（実はこれは今年導入した）、明示的に聴衆に赤ちゃんを許可したい。

もっと大きい子供用にはプログラミング・ワークショップを行ったり、子供が遊んだり親がまったりできる遊戯エリアがあっても面白いと思う。親がセッションをいくつか見に行っている間、プロの保育士が子供の相手をしてくれれば理想的だと思う。

まとめ

僕の考えた ScalaMatsuri 2016 の大きな目標は

この 2つだった。

これを実現するためには、オーガナイザーによる継続的なプラン立てと、ボランティアさんやプロの協力が必要だった。CyberAgent さん、chatwork さん、Maverick さん、Septeni Original さんをはじめとするスポンサー各社の協力がなければこれらは不可能だっただろう。業務内でも色々やらせてもらってたので Typesafe社にも感謝したい。

実際のお祭りと同じで、醍醐味はオーガナイザー同士であれこれ言いながら夢を描いて、年に一回それが実現するのを見ることにあると思う。多分またキックオフがあるので、興味がある方は是非参加してみてください。