第1回　コミュニケーション編

YAPC::Asia Tokyoに限らず、本業の傍ら運営されているイベントの類いは、スタッフが作業できる時間や場所が必ずしも一致しない事が大きな問題の1つであると思います。

例えば同じ会社に勤める会社員であれば、毎日同じような時間に出社しかなり近い場所で一日中仕事をしているので、ちょっとした会話で問題を解決したり、進捗の確認をしたりすることができます。また、物理的にも心理的にも距離が近く、お互いの性質や仕事の進め方などもある程度は知っているでしょう。しかしイベント運営の場合、スタッフが全員別々の仕事をしつつ勤務時間や内容が合わないのでは、少し意図的に工夫しないとコミュニケーションは取れません。

それではYAPC::Asia Tokyo 2015の準備段階では、スタッフの間でどのようにコミュニケーションを行ってきたのかを少し解説してみたいと思います。

歴史

YAPC::Asia Tokyoは2006年から続いており今年で10周年を迎えるのですが、実は2011年くらいまではほぼ1人ないし2人の運営者の力業で全てをまかなっていました。イベント当日だけ手伝っていただく『ボランティアスタッフ』は数十人集めていたのですが、企画や準備などはこのような少人数で回せていました。そのため、それまで『チームを運営して行く』と言うことや『コミュニケーションの取り方』に注力する必要はありませんでした。

しかしながら徐々にイベントの規模が大きくなり、2012年の準備をしている頃、ついに参加者数が1,000人の大台にのるかのらないかくらいになってきました。当時運営をしていた筆者と櫛井優介氏が「これはさすがにそろそろもっと人を入れないときついし、このままではスタッフの新陳代謝も不可能になってくるだろう」と思い、『⁠ボランティアスタッフ』の他に数名の『コアスタッフ』を設けるという形で、運営を初めてチーム制にすることにしたのです。

この当時は前述した主催2人が毎週ミーティングを行い、その結果からのTODOをメーリングリストでコアスタッフに流すと言う形で情報の伝達を行っていました。つまり、基本的にトップの2人が全ての意思決定を行っていたので、それほど『チーム運営』と言うものに気を使う必要はなかったわけです。この形式ですとトップの責任は増えますが、少人数で迅速に意思決定を行えるため、効率はかなり良かったです。その傍ら、コアスタッフに任せられるタスクは実作業のみになることが多く、それほど多くの裁量を与えることができなかったことが悔やまれました。ちなみに、この当時実際にコアスタッフにやってもらった内容としてはTシャツやノベルティの発注、それとカンファレンス当日の各セクションのリーダー的な役割でした。

2014年は櫛井氏も筆者もプライベートで多忙になることがわかっていましたし、そろそろ違う人が主催をやるべきだという思いから一旦我々は運営から身を引きました。ですがその後の2014年9月頃、YAPC::Asia Tokyo 2015の開催が決まり、それとともYAPC::Asia Tokyoに一旦終止符を打つことが決まり、それならばと筆者が主催として復活することが決まりました。1年間主催を休んでいた筆者ですが、復活することを決めたのちまず考えたのは『チーム制での運営』と『そのチーム間のコミュニケーションの方法』でした。

と言うのも、2013年までと同じ体制で運営しようとした場合、櫛井氏と二人三脚で仕切っていた諸々のタスクを今度は1人で仕切る必要があるわけですが、それが1年のブランクもある自分には到底不可能なことだとわかっていたからです。YAPC::Asia Tokyo史上最大となる2,000人の参加者を見込むイベントを運営するには、チームを作り、チームのメンバーたちに可能な限りの裁量を与えてタスクを回す体制が必要でした。そのためにはまず、チーム間でのコミュニケーションの方法を考える必要がありました。

コミュニケーションのコストを抑えるツール群

YAPC::Asia Tokyoに関わるスタッフは、前述したとおり筆者を含め全員本業をこなしつつ空いている時間で運営に関わっています。筆者を含めたコアスタッフの人数は10人程度ですが、会社も職種も働き方も違うため、この少ない人数であってもスタッフ全員が定期的に一同に集まる事は現実的に不可能でした。

このように、ただでさえコミュニケーションを行う事が難しい状態では、とにかくコミュニケーションコストを可能な限り下げなければいけません。コミュニケーションするためのコストが高いと、連絡漏れや間違いが起きやすくなるだけでなく、そもそもコミュニケーションをしようと言う意思を挫く事が多々あります。また、コストが高いままでも力業でとにかく頑張ってコミュニケーションを取ると言うやり方もできなくはないですが、それではイベント運営や、あるいは本業にまで支障が出てしまうことも考えられます。ただでさえ少人数のスタッフなのに、これでは本末転倒になりかねません。

これまで過去のYAPC::Asia Tokyoではスタッフ間の連絡手段としてFacebookグループ、IRC、メーリングリストなどを試してきたのですが、それらが今回使えるかどうかを検討してみることにしました。それぞれ一長一短なのですが、いくつかの理由で上記のツール類は今回利用を見送りました。具体的な理由としては以下のとおりです。

Facebookグループ: スレッドの位置が不定で、最後に「いいね」やコメントがついたポストがページ上部にくるため、順序がわからなくなり混乱しがちでした。また、Facebookメッセージでは時系列ははっきりしていますが、話題が流れてしまいがちです。
IRC: チャット用のツールとしては便利なのですが、コアスタッフには非エンジニアも数名おり、彼らが参加するにはUI/UXにフレンドリーさが欠けていました。
メーリングリスト: 使い方はわかりやすいのですが、いざリアルタイムな会話をしようとする場合においてその方法がありません。

もちろんこれらのツール類も運用の仕方によっては目的を達成するのは可能でしょうし、実際にこれらを利用してイベント運営を行っていることもあるとは思います。しかし、今回は諸々を考慮してそれ以外のツールを使う事にしました。

次に実際に使用したツール類について選定理由やどのような形で運用を行ったのかを説明したいと思います。

Slack

まずは「会話」部分を担うツールを考えました。いくら非同期でのコミュニケーションが前提でもやはり会話は必要です。そこでIRCに近い感覚のツールを導入したかったのですが、今回はSlackがちょうど登場してきたタイミングであったのでSlackの導入を決めました。

Slackは以下のような特徴があり、導入直後からぴたりとはまりました。

比較的導入が簡単
非エンジニアにとっても使用方法がわかりやすい
スマートフォンからの利用方法もわかりやすい
Integrationを使う事によって他サービスとの連携が容易

特に非エンジニアにとって使用方法がわかりやすいと言うのは重要なポイントでした。我々のチームには全くプログラミング・エンジニアリングとは関係ないメンバーもいるので、彼らが気持ちよく使えるツールが必要でした。

このように便利なツールなのですが、ありがちな運用として各プロジェクトごとに小さななチャンネル（Slackにおけるチャットルームのようなもの）を作って必要な人だけ各チャンネルに参加するという形になることが多々あります。これはメーリングリストと同じような運用方法ですが、これをするとどのチャンネルでどのような情報のやり取りが行われているのか把握しづらくなり、少人数チームの会話ツールとしての魅力が半減してしまいます。特にプライベートチャンネル（特定の人だけが入れる承認制のチャンネル）を使い始めると情報を得られる人と得られない人と差が出てき始めるのでそのような状態だけはどうしても避けたい気持ちがありました。前にも書いた通りSlackはあくまでオープンな「会話」のミディアムとして使いたかったのです。

そこであくまでチームメンバー同士の会話を重視した使い方をするために、Slackのチャンネルは以下のように限定しました。

#generalチャンネルで真面目なアナウンスメントや議論等を行う
#randomチャンネルでどんなくだらない話でも良いので常に雑談を行う

#generalチャンネルは重要事項やTODO的なものがポストされるので必ず確認してもらいます。ただし重要事項の伝達のみに限ってコミュニケーションを行うと逆にそれ以外の何も伝わらず、結果一緒にチームに参加しているお互いの事が何もわからず本番を迎えてしまいそうだったので、別チャンネルを用意することにしました。

#randomチャンネルはディスカッションにも使いますが、基本用途はチームビルディングのためです。雑談は直接イベント運営には関係ありませんが、他のスタッフがどういう人なのか、どういう事に興味があるのか、どういうことが得意なのかを知ってもらうために利用しています。これによりリモート・非同期で活動しているチームメンバー同士が働きやすいようになります。また#randomチャンネルは雑談をするためのチャンネルですので、特に用がなければ無視してもよいチャンネルとなっています。

基本全ての会話はこのSlackに2つのチャンネルを通して行われます。もちろん会話は流れてしまいますのでTODO管理等はSlackではできませんのが、Slackでの会話から始まり他のツールでそれ以外のコミュニケーションを行います。

GitHub

Slackは会話するには素晴らしいのですが、やはりログが流れてしまうと困る事は多々あります。そのような用途にはGitHubを使っています。GitHubでプライベートレポジトリを作成して、そこで「週報」と「TODO」の管理をしています。

まず定期的にタスクの棚卸しをしないとマネージャー役の筆者が現在どのようなタスクが残っているのかわからなくなるので週報を毎週書いています。

週報は毎週月曜に自動的にひな形が作成され、レポジトリにコミットされます。レポジトリへのプッシュはSlackに通知されますので、これが到着したら週報書き開始の合図です。週報は正直筆者も大嫌いなのですが、この週報を強制的に書かされる事により自分が今持っているタスクの洗い出しを行う事ができるのと、ポイントポイントでの状態を後で見られるのが良いと考えています。週報には簡単な箇条書き程度で「やったこと」「⁠やること」「⁠問題点」があれば書きます。

GitHubにはこれの他、issueを使ってTODO管理を行います。これは皆様の想像通りで、エンジニアリングプロジェクトを進めるのと同じように担当者を決めて進捗確認をして、タスクが終了すれば該当issueはクローズします。

Google Drive

Slack・GitHubで進めた事項をまとめた物や、予算管理等のスプレッドシート的なツールが必要なもの、スタッフ以外にもシェアするドキュメントなどはGoogle Driveで管理・共有しています。

こちらの運用はシンプルで、ドライブ内にスタッフ全員に共有するフォルダを作り、その中に全てのドキュメントを保存するだけです。一旦共有フォルダを作ってしまえばあとはその中のドキュメントは全てスタッフに見えるので、あとは特に考える必要はありません。

Google Driveがさらに便利な点はスポンサー企業等に送る資料も「URLを知っている人に公開する」設定にしておけば「世界中の人に丸見えは嫌だけど別にそこまで秘密でもない情報」を配布する際の絶妙なアクセス管理を行う事ができることです。今回全ての配付資料はこの仕組みを使いました。

リアル会議・飲み会

情報のやり取りはこれまで書いてきたように、基本Slack、GitHub、Google Driveだけで行いました。イベント運営のためだけであればこれで事足りるのですが、やはり完全にリモート・非同期のコミュニケーションのみでは若干物足りない部分も出てきます。例えば企画を考える際にはやはりその場の雰囲気やノリで新しいアイデアが生まれることもあります。TODO管理もやはり顔を見ながらだと思い出すこともあります。

そのような部分を拾うために準備開始当初から1月に1回、コアスタッフ内で集まれる人を全員呼んでミーティングを行っています。ミーティングと言ってもどこかの会議室で行うのではなく、居酒屋等で行います。最初の1時間弱ほどで主催である筆者からの全体状況の報告、各スタッフからの報告を行いそのとき決定できることはそこで決定してしまいます。あとは普通の飲み会をしつつイベントに関して話すことがあれば話します。

最初の1時間で話す内容は例えば現物を見ないとわからないノベルティの選定などを主なテーマにし、それ以外の報告はとにかく端的に行って終わりとします。筆者はだらだら行うミーティングは非効率の極みと考えていますので、この月イチミーティングでの真面目な話はもうとにかくサクサクと終わらせます。逆により重要なのはその後の雑談と懇親部分だと考えています。

まずひとつには給料ももらわずに色々と仕事をしていただいているスタッフの皆さんへの、ささやかなお礼と言う意味があります。YAPC::Asia Tokyo 2015規模のイベントを企画・運営していくのはそれなりの重労働ですので、この程度では全く足りていないのは重々承知なのですが、それでも何もしないよりははるかにマシということでこのようなミーティング形式にしています。

もう一つは単純にチームビルディングのためです。スタッフ同士が1回も顔を合わせずにイベントを開催することも不可能ではありませんが、その場合当日になってお互いが誰だかよくわからない状況で様々な処理を行わざるを得ない状況が生まれてしまうことがあります。それを回避し、チームとしての連帯感を高めるためにこのような状況を月に1回作っています。

まとめ

以上YAPC::Asia Tokyo 2015の準備における運営スタッフ間のコミュニケーションの行い方を軽く説明してみました。

連絡事項の伝達、という意味では顔を合わせたりSlackのようなリアルタイムコミュニケーションツールやミーティングなどは必要なかったりするのですが、YAPC::Asia Tokyo 2015では連絡事項の伝達だけではなくチームとしての連帯感やコミュニケーションの促進をより重視してこのような形にしてみたつもりです。

最終的にこれがどのように評価されるかは今年8月にYAPC::Asia Tokyo 2015が開催されるまでわかりませんが、今のところは良い感じで回っていると思います。他のイベント運営で同じ方式が成果をあげるかどうかはわかりませんが、何かの参考になれば幸いです。