DroidKaigi2017のスタッフ参加で学んだコミュニケーションを円滑にする気付き

TOP

スマホアプリチームの岩田です。

残っていた代休を使い、3月9日と10日に開催されたDroidKaigi 2017にスタッフとして参加しました。

スタッフ参加ははじめてでしたが、経験から学んだツールの活用方法やコミュニケーションを円滑におこなうための気付きなどについて、時系列を追ってお伝えしたいと思います。

DroidKaigiとは

DroidKaigiの公式サイトでは、イベントを以下のように説明しています。

“DroidKaigiはエンジニアが主役のAndroidカンファレンスです。 Android技術情報の共有とコミュニケーションを目的に、2017/3/9(木)、3/10(金)の2日間開催します。” 参照:DroidKaigi2017

実際に、発表者や参加者の多くがエンジニアであり、また運営スタッフもエンジニアが主体(エンジニア以外にも学生や主婦の方などもいます)。まさにエンジニアによる、エンジニアのための、エンジニアのAndroidカンファレンスでした。

DroidKaigiは2015年、2016年の過去に2回開催しており、回を重ねるごとに参加者・登壇者が増えています。今回は60以上のセッションが行われ、参加登録者数も600人を超えました。スタッフ75名、スポンサー企業の方やその他関係者を含めれば800人を超える人数が関わる巨大なカンファレンスとなりました。

当日はTwitterトレンドにハッシュタグ(#droidkaigi)が載るくらいに大盛況でした。

参加した経緯

自分は過去2回のDroidKaigiには参加していません。ただ、DroidKaigi2016が終わったころたまたまTwitter上でDroidKaigiの運営スタッフをしていた友人たちが次回の話をしているところを目撃しました。去年から「勉強会に参加する側から作る側に回る」を個人目標としていたこともあり、せっかくならば作る側で参加したいと思いました。そこで友人に紹介してもらったことが、スタッフとして参加した経緯です。

準備期間

準備は次のように進んでいきました。

定例会議

準備を開始したのは2016年の4月から。キックオフミーティングは4月25日におこないました。およそ11ヶ月をかけてイベントを作り上げていたことになります。

キックオフミーティングからは都内某所で顔をあわせて定例ミーティングを実施しました。頻度は、だいたい月に1回です。開催1ヶ月前ぐらいからは毎週水曜に集まるようにして最後の追い込みをしました。仕事や家庭の事情で定例ミーティングに来れないメンバーはGoogle ハングアウトを利用し、ミーティングの会話をリアルタイムで聞きながら、必要があれば発言するスタイルで参加していました。

定例ミーティングの議事録はGoogle ドキュメントを利用しました。事前にアジェンダがスタッフ内に共有され、必要な人が議題を書き込んでおくスタイルです。ミーティング中は書記を決めて記入したり、その場で書き込める人が複数人でリアルタイムに追記を行います。Google ドキュメントでの議事録は先に共有して、いつでも誰でもどこでも議題を追記できるので大変便利でした。自分のあげた議題は自分がメモを追記できスムーズに会議が進みました。仕事の打ち合わせにも取り入れる事ができそうなノウハウです。

普段の連絡手段

普段の主な連絡手段はSlackです。担当ごとにチャンネルを分けていたので、最終的には36チャンネルとなっていました。担当の作業を進めていく上で必要な相談事のやりとりのほか、他のイベントの感想が情報交換されることもありました。イベント前日、Day 0のスピーカーズディナーには運営スタッフがSlackの絵文字を使った缶バッジを作って持ってきて配りました。運営スタッフ間の交流の場として、Slackは欠かせない存在でした。

課題管理

課題管理に使用したのはGitHubです。Privateのリポジトリを作成し、プロジェクトのIssue上ですべての課題を管理していました。Issueのテンプレートに必ず書くよう設定されていたのは概要、期限、DONEの条件です。誰が見ても分かりやすいよう、明瞭な運用が行われていました。

過去2回分のリポジトリも今回の運営メンバーに共有されており、Wikiにはノウハウが蓄積されていました。過去の情報がキチンと整理されているので、初めて参加した自分でも担当の作業をスムーズに行うことができました。

オフラインでの定例ミーティング以外にも、毎週土曜にはSlackを使ってミーティングしてIssueを棚卸ししました。

特定の人物に負担がかかるのを避けるため、ミーティングごとに司会進行役を決めたのも特徴的でした。司会者がIssueのマイルストーンが期日付近になっているIssueを洗い出し、必要があれば担当にSlack上でmentionを送ります。終わっていると判断できれば閉じるなど、Slack上にIssueへのリンクを貼りながら進めていきました。

週に1度棚卸しをするメリットは放置されているIssueを無くし、止まっているIssueを拾い上げられることです。ただ、開催1〜2ヶ月前ぐらいからタスクが爆発的に増えてIssue数は膨大な数に。すべてのIssueを見てまわるには、1時間かかるほどに膨れあがってしまいました。

2回ほど司会進行を担当しましたが意外と全部を見てまわるのはしんどく疲れる作業だと感じました。次回やる機会があれば、負担を減らすような改善を行いたいと思っています。

途中からマイルストーンが設定されていない事態も多々発生し、ミーティングに時間がかかる要因となってきていました。運営メンバーの1人がIssueをチェックし、マイルストーンが設定されていなければIssue上にコメントで「マイルストーンが設定されていないよ」と教えてくれるBotを作ってくれました。これでかなりの数、マイルストーンが設定されていないIssueを削減できた気がします。

f:id:g-editor:20170413155727p:plain

また、ミーティング開始10分前にSlackのremind機能で通知が届くようにしました。ミーティングの開始時間に集まりが悪いという問題を解消するためです。ミーティングに参加するメンバーは、Slackbotへreactionをつけて出席を表明しました。Slackでのミーティングは運用開始当初は10時スタートでしたが、エンジニアの朝は遅いため、途中から11時開始に変更されました。

担当

自分はプログラムの募集とパンフの情報整理を担当しました。

プログラムの募集

プログラムへ応募してくれた方ならご存知の通り、プログラムの募集にはGoogle フォームを利用しました。DroidKaigiでは海外からのスピーカーも募集しています。フォームに英語訳をつける必要があり、スキル的に無理だったため英語担当の方に協力してもらいました。

周到に準備していたはずでしたが、プログラム採択の投票を運営内で行った際に自分が担当していた集計でミスが発生し、工程のスケジュール決定担当者に迷惑をかけてしまう事態となりました。代表に手伝ってもらい何とか事態を収拾できましたが、自分だけでこなせるかと思っていた分、上手くできなくて悔しかったです。次回への反省として、集計用のデータは1人が1箇所にまとめて管理することが大切だと学びました。

パンフの情報整理

パンフの作成にあたり、デザイン担当の方へお願いするため情報を整理しました。デザイン担当の方とほとんどお会いしたことがない状態でのスタートだったこともあり、とても苦労しました。事前にコミュニケーションがとれていないので、仕事の頼み方やその方が使える時間のリソース、スムーズな依頼方法などがわからず、手探りで仕事を進めていったためです。

途中から、デザイン担当の方と直接の面識のある方にサポートしていただけたことで、かなり助けてもらえました。

パンフレット制作で大変だったことは、情報の集計業務です。パンフレットに必要な情報は担当がそれぞれ違います。それらを1つずつ集めていきました。Slackではさまざまなチャンネルに参加し、パンフレット進行用のチャンネルに担当者や詳しい人をInviteしたりなどして奔走しました。

Slackは組織が縦に分割された作業の場合、複数チャンネルに分かれているのは便利に感じます。しかし、横断的に情報を集めたいときに複数チャンネルに分かれていると、いろいろなところにお伺いを立てる必要があります。コミュニケーションは大変です。情報収集が上手くできず、デザイン担当の方には迷惑をかけてしまいました。

自分がパンフレット担当に割り当てられたときは既に期日も迫っていたこともあり、一部の情報を掲載しきれなくなりそうなこともありました。しかし、別の運営スタッフの方が別途ペライチの紙に追加情報を載せる動きを進めてくれたおかげで、参加者の方に情報をもれなく伝えることができ、助かりました。

Day 1 - Day 2

イベント当日、自分の担当は主に撮影係でした。望遠レンズ片手に中腰で会場を走り回っていました。*1

無事開催するかに見えたDroidKaigiですが、開催間もなく、アクシデントが発生しました。キャパオーバーで参加者の受付がウェルカムトーク開始時刻までに終わらなかったのです。当日までの準備でいろいろとスタッフが計画を練っていましたが、受付で一人あたりにかかる時間が想像以上で同時にさばける人数が想定を下回ってしまいました。

ギリギリまで粘りましたが、ウェルカムトークが始まる時間は迫ります。そこで、受付は当日中におこなえばOKと、レギュレーションを変更しました。土壇場で判断できる代表の責任と決断力が見えました。

f:id:g-editor:20170330111540j:plain ウェルカムトークの様子

f:id:g-editor:20170330110206j:plain 企画でチェキで撮ってみんなでプレートに貼ってました

f:id:g-editor:20170330110159j:plain バリスタの方を呼んで無限カフェラテを実施してもらいました

個人的ふりかえり

最後に、運営スタッフをやってみた振り返りをしてみたいと思います。

コラボレーションツールの活用

ぐるなびではSlack、JIRAGitLabGoogle ドライブを利用しています。今回の運営スタッフで得たツールの利用方法のノウハウは社内でも応用できそうでした。特にGoogle ドキュメントを利用し、リアルタイムで複数人が編集できる議事録の運用は既にチーム内でおこなおうとしています。

Slackではreaction機能を利用した投票の実施、remaind機能が役に立ったので実践していきたいです。また、GitLabやJIRAでマイルストーンが設定されていない場合に通知してくれるBotを作ったら便利そうだと思いました。

主体性を持って動く

運営スタッフのみんなが「誰かがやるだろう」という考え方ではなくて「自分がやる」という主体性を持った考え方で動いているように感じられました。仕事でも「誰かがやるだろう」「指示が来たらやろう」というような考え方ではなく、仕事を自分事に捉え、「自分がやる」と主体性を持って働くことの重要性を改めて確信しました。

褒める・感謝する

運営スタッフの代表がやっていたことですが、どんなことでも褒めていました。失敗しても褒める、「○○までできてありがとう」と感謝する。とにかく褒めて感謝するというスタイルで雰囲気の良いチームとなりました。開催1ヶ月前ぐらいの定例ミーティングで急遽実施したのは、隣の人を褒め合うという催しです。褒め合う、感謝し合うチームを作ると雰囲気が良くなり、お互いの作業を助け合う文化ができると実感しました。

横のつながりをつくる

ウェルカムトークの内容のひとつに「DroidKaigiはエンジニアが参加して、直接話をし、一緒に盛り上がるという場のちからがある」という趣旨のものがありました。実際に運営11ヶ月間おこなってきて、直接会い、話をし、盛り上がることで生まれる一体感を覚えました。

実際に自分もスタッフとして参加することで人との繋がりを広げ、一緒に家でたこ焼きパーティをするような仲になったメンバーもいます。苦楽をともにして一緒に盛り上げていくという経験を積むことで新しい仲間を作れた気がしています。

Twitter上では「アイコンでよく見る○○さんにようやく会えた」「新しい繋がりを作れた」というような感想が流れており、DoroidKaigiに参加することで多くの刺激を得られたようでした。

まとめ

こんな雰囲気で11ヶ月ほど運営スタッフを続けていろいろと用意してきました。新しい仲間ができたり、仕事でも活かせそうな知見を得ることもできました。今後はこの得た知見を社内に展開していこうと思います。


岩田直樹

ボルダリングとロードバイクが好きなエンジニアっぽいヘンジニア。
三度の飯とビールが好き。IoT界隈やフロントエンド、アプリの勉強会と幅広く出没してます。
好きなエディタはVimです。

*1:しかし、活動量計で見た感じだと、おもったよりも消費カロリーが伸びていませんでした。カンファレンスダイエットは失敗でした