こんにちは。QuipperのWebエンジニア@sat0yuです。
今回はFablic社さんと共同で開催したミートアップの内容と、その企画・準備から得られた知見をご紹介したいと思います。 OSS開発のようなスタイルで各人が得意な分野で協力し、驚くようなスピード感をもって準備期間１週間足らずでミートアップを開催するに至りました。
本記事で触れる内容
- オープンなOSS開発スタイルとイベント企画は相性が良いことが分かった
- 事業フェーズが似ている２社でSlack shared channelを作った
- OpenSpace形式のミートアップは初対面でも盛り上がった
OpenSpaceとは
はじめに、本ミートアップのメインコンテンツとなるOpenSpaceという形式をご紹介します。 日本ではまだあまり馴染みのない言葉で、筆者も今回初めて知りました。
OpenSpace https://martinfowler.com/bliki/OpenSpace.html
（訳：http://bliki-ja.github.io/OpenSpace/）
OpenSpace形式の一番の利点は、何と言っても細々とした準備が不要なことでしょう。 非常に簡単なフォーマットに従うだけで実践できます。
- はじめに話したいテーマを持った人（オーナー）が手を上げ、テーマについて説明する
- そのテーマについて話したい人はそのオーナーのテーブルに集まる
- 時間を区切って各テーブルで各テーマについて語る
- 最後にオーナーが話した内容のサマリを発表する
OpenSpaceでは議論への参加が余儀なくされるため、プレゼンやLT形式に比べて参加者の能動性が増します。 とはいっても知見を持たない人でないと参加できないといったことは全くなく「わからないことを有識者に直接質問できる場」としても機能するところがミソです。
ミートアップ実現までの時系列
Fablic社さんとの間でSlackのshared channel #faq-product-meetup-jpが開通したことがミートアップ企画のスタートとなりました1。
開通したのは5/15(火)夕方。早速、面白そうな匂いを嗅ぎ付けたエンジニア、デザイナー、プロダクト開発に携わる人員がぞくぞくと集結します。 そして発起人の@yuya-takeyamaから会の骨子が共有されます。
翌日には調整さんが準備され、早速その日のうちに開催日が決定。 同時に本ミートアップの成否を担う偉大なドキュメントが共有されます。
Slackチャネル開通からミートアップ開催決定まで1日、開催日時までは5日を切っています。
せっかく新しいオフィスになったので2Quipper側が会場提供する（したい）が、
あまりにも迅速にスケジュールが決まってしまい会場が抑えられないかもしれないハプニング。
弊社一番の急進派当事者意識を持つ@mtsmfmが偉い人に掛け合い、弊社自慢のカフェスペース利用許可を獲得してきます。
開催日時・場所の決定を皮切りにして、他の参加メンバーも次々とミートアップ実現にコミットしていきます。 両社とも意見よりも行動で示すメンバーが多く、みるみるうちに企画が出来上がっていきます。
そしていよいよミートアップ開催となりました。 メインコンテンツとなるOpenSpaceでは、各人は好みの話題のテーブルに移って議論を交わします。
議論のテーマは、マイクロサービス、フロントエンド、決済、デザイナーとデベロッパー、Docker、VPoE、DB分割、金、買収、親会社…など。 当初の目論見どおり、どの話題も共感できる部分が多くとても盛り上がりました。
個人的には、マイクロサービスに関する事例やそこでの知見、懸念点などについて、とてもカジュアルな雰囲気で話せたのは良かったと感じています。 じつはQuipperにおいても、CTO率いるチームによってマイクロサービス化が鋭意進捗しています。
OSS開発スタイルのイベント運営
これだけだとただの活動報告になってしまいますので、ここでは「なぜこれほど迅速にミートアップ実施に至れたか」について考察しようと思います。 とくに、タイトルにもある「OSS開発スタイル」に関して、それがなぜ「イベント企画」と相性が良いのかと考えてみます。
会社単位のイベントを企画する場合も、準備に要するTodo項目自体は有志の勉強会と大差ありません。 むしろ気を払うべきは各Todoの「質」の部分になります。 今回のミートアップでは、非常に限られた期間という制約の中で「質」の部分をどのように担保するかが問題でした。
本ミートアップに関しては以下に挙げる２つの点がうまく機能したことで、準備の「質」が担保され参加者の満足度を高めることができたと考えています。
- 参加メンバーの属性と自律的な貢献
- 透明性の高いコミュニケーション
1.参加メンバーの属性と自律的な貢献
今回のように意思決定が多く発生しかつ時間も限られている状況においては、いかにして各人の自律的な行動を促進し、共通のゴールに向かわせるかがキーとなります。
今回の参加メンバーは全員がエンジニア＆デザイナでした。 エンジニアやデザイナのロールを担う多くの人は、基本的には何かを「創り、アウトプットすること」を生業とします。 加えて、両社メンバーは普段からPullRequestを通じたコミュニケーションに慣れていたこともあり、自然と「行動→承認」形式のやりとりが盛んに生まれました。
- PRライクなコミュニケーションが多く見られた
- ×「〜だと嬉しい」「〜だったらいいな」
- ○「〜しておきました」「〜で良いですか？」
本ミートアップ準備に関しては、このようなPRライクなコミュニケーションが非常に相性がうまく働くと思います。 メンバー各人が自由にかつ無駄なく協力し、非常にスピード感を持って準備を進められました。
2. 透明性の高いコミュニケーション
OSSの強みの１つとして、透明性を挙げることに異論はないと思います。 どのような改善が必要か、だれが変更を加えたか、誰が賛成（反対）しているか、Githubリポジトリを覗けばすべての情報を見ることができます。
本ミートアップではGithubの代わりにSlack shared channel と Google Docs が上手く機能しました。 Google Docsは説明の必要はないと思います。shared channelは昨年秋ごろに登場したSlackの機能です。
- 決まったことがすぐに文章化・共有される
- 何が足りていないか・何を改善できるかが一目瞭然
- Slackリアクションを使った賛否表明
準備に必要なすべての事項をslack上でやりとりし、決まったことは適宜共有ドキュメントに残していきました。 これにより準備のモレ・情報伝達のモレを防ぐことができました。
また、Slackリアクションによるコミュニケーションが両社の文化として根付いていたため、 会社を超えて他メンバーの感触・温度感を知ることができ、円滑なコミュニケーションが生まれました。
要改善ポイント
OSS開発スタイルでイベント運営を行う場合の注意点も浮き彫りになりました。 というのも、開催後にメンバーから集めたフィードバックにおいて「会自体の進行・ファシリテーションが必要だった」という声が多くあったのです。 プログラムが事前に共有されていたとはいえ、最低限進行を取り仕切る係を決めておくべきでした。
各人が高い当事者意識を発揮して準備が進んでしまった結果、良くも悪くも「決定者」のロールが曖昧になっていたようです。 その結果、誰が話す時間なのかを読み合うお見合い状態が生まれたり、今は何をする時間だろうという若干の混乱がありました。 オープンソースプロジェクトと同様に、「メインコミッター」を決めておくと良かったのかもしれません。
まとめ
twitter上でのコミュニケーションを発端に、実準備期間１週間で二社合同ミートアップを開催しました。 全ての情報・コミュニケーションをオープンにし参加者全員の協力を仰ぐことで、非常に高速にかつ満足度の高いイベントを企画することができました。
- twitter上における両社一部エンジニアの交流が発端となり、４月下旬に両社合計6名が参加する飲み会が開催されました。解散時には全員から「これは是非、合同ミートアップせねば」との声があがるほど盛り上がり、それがshared channel開通の発端となっています。↩
- ゴールデンウィーク明けから目黒オフィスに移転になりました。新オフィスに関してもあとで誰かが記事を書くはず。最高のオフィス環境になりました。↩
