TdX講演会#01「チームと開発者Kaigiづくり」 － DroidKaigi

「東京工業大学CBECプログラム」 http://cbec-titech.connpass.com/event/28644/ での講演資料です。DroidKaigi 2016での課題発見と解決について振り返り、「モデル」という言葉でまとめた資料です

Transcript

1. チームと 開発者Kaigiづくり 2016/04/22 @mhidaka 1
2. アジェンダ • DroidKaigiとは • イベント概要 • モチベーション • DroidKaigiの抱える課題 • 経験のなさ、お金のなさ、組織のなさ • ビジョンだけがあった • エンジニアたちの取り組み • 理想となるモデルの構築 • 課題の発見 • 手法の共有 2
3. DroidKaigiとは？ 開発者会議の真実 3
4. Android Developer’s Conference 4
6. 開発者カンファレンス 6
7. 45 Sessions by professional engineers 6 Speakers from overseas 500 attendees mobile engineers 7
8. Purpose Android技術情報の共有 とコミュニケーション 8
9. 主催者として関わりました mhidaka 9
10. コミュニティ活動 • techbooster.org • モバイル開発者向けサイトを運営 • 500以上のAndroid技術情報 • ソースコードはオープンソース 開発者カンファレンスの運営 技術共有、導入へのコミット 10
11. 自分で技術書をつくったりしてます
12. 開発者会議：エンジニア自身が運営 12
13. Motivation 13
14. CC BY 4.0 Google 14
15. DroidKaigiの抱える課題 開発者会議の真実 15
16. 3つの弱点 経験がない：大規模カンファレンスの知識なし 組織がない：必要な役職がわからない お金がない：あるほうが珍しい 16
17. 何もない荒野だった！！ 17
18. 経験がない はじめての大規模カンファレンス • 最終的な動員は600人、45セッション（4並列/2日間） • トラブルなく終えることができました。 マニュアルというものが存在しない世界 • 世の中には、いろんな開発者会議があるが別々の運営母体。 • ゼロからつくり上げることに 「何をしたらいいのか」がわからない • 役割、人的リソース、日程感、すべてが不明 18
19. モチベーションは 人一倍。やるしかない。 19
20. チームの目標だけはハッキリしていた • DroidKaigiはエンジニアが主役のAndroidカンファレンス • Android技術情報の共有とコミュニケーションが目的 • 幸い、運営に関わる人数は多かった。 • 30人程度がアクティブ • 開発者会議当日は40人体制で運営 20
21. チームの問題点 課題発見 議論の推進 役割の分担 21
22. Kaigiまでの試行錯誤 エンジニアの考えるチームビルディング 22
23. 「何も決まってない＝自由」ではない そもそも何について話せばよいかで迷う • 今必要なことが何か分からなくなる 要望が具体的にならない • コミュニケーションをとりたい！→どうすればよい？ • みんなに来て欲しい！→どうすれば来てくれる？ 結果としてタスク化できず、リソースが余りだす • リソースが余っても、やるべきことがなくなったわけではない 23
24. チームづくりに設計書はない 24
25. 開発者会議のモデルを作る モデリング • 模倣する例になるもの。手本。模範 • 特定の質において優れた事例だとみなされている人や物 • 物、体系やプロセスに関して計算、操作、予測の手助けと するために、単純化した記述のこと。現実よりも記号化し た説明 25 注意：実際はGitHub/Issueの単位で進行。「モデル」という単語を意識して進めてたわけじゃないよ！ 後から考えると何らかのストーリーを作ってから議論が加速したね、という振り返りだよ！
26. モデルを作るとは • 開発者会議に必要な要素（コンポーネント）をみつけて、相互 の関係を明らかにしていく • たとえば食事なら、手順として明確化できる メニューを 決める 買い出しを する 調理する 食べる 26
27. 議論を促すための仮説と検証 仮説 • 他のカンファレンスの調査：YAPC、ScalaMatsuri、GoCon、RubyKaigi 大きなカンファレンスでは1人あたり1万円の予算が必要とわかる • 具体化するためのモデル構築。DroidKaigiで必要な要素を抽出、会議をデザ インする 検証 • 目標に向けて不足している要素の洗い出し • 予算やカンファレンスの機能に応じてモデルを変更 27
28. ごく簡単な会議モデルで 議論の出発点を作る 場所を探す 講演者を集 める プログラム を決める 集客する 当日楽しむ 28
29. 開発者会議はパラメータが多い • 場所を探す、と一口に言っても • 予算 • 支払条件 • 開催日時 • 交通アクセス • 収容人数 • 会場の広さ • 部屋の数 • 人の動線 • 設備 29
30. パラメータに制約：議論を活性化 • 場所を探す、をより具体的にする • 予算 ：なるべく安く • 支払条件 ：利用1ヶ月前 • 開催日時 ：2月16日、17日の2日間 • 交通アクセス • 収容人数 ：400人超 • 会場の広さ ：基調講演は参加者全員が集まりたい • 部屋の数 ：4つは欲しい • 人の動線 • 設備 ：プロジェクタとマイク 30
31. モデルを具体化 • 「場所を探す」をさらに分割 • 多くの視点があったので過不足なく抽出 （人数が少ないと漏れていたと思う） 実績調査 候補選定 設備下見 会場予約 31
32. モデルの効果 • チームの方向性を一致、バラバラを向いていた力をまとめる • それぞれが活動に使える時間は限られているが、議論に参加しやすい • 言い換えると単純に「計画」と「実施」 DroidKaigiは当初計画時点での厳密さは捨てて進んだ。物事をすすめ ていくなかで詳細にしていった 目標の共有 全体が同じ方向で議論 32
33. 役割の分担：モデルをどんどん育てる • 会場 • 本会場、アフターパーティ、講堂、施設、動線計画 • 準備 • 配布物、掲示物、当日備品、ランチ、パーティ、予算編成 • 企画 • セッション公募、プログラム作成、基調講演 • 開催 • 誘導、受付、司会、基調講演の進行、案内、撮影、録画、撤収 • 広報 • 告知、Webサイト、企業協賛 33
34. 課題の再発見 • 議論の中で変化を許容する • モデルは過程と検証をくりかえす中で変化する • 最初から決まっておいてほしい場合、まったく適用できずに詰む • 昨日と今日は違うことを言っても構わない • 似た議論があればマニュアルなどで整備、繰り返せる体制 34
35. 会場の様子 出来上がったもの 運営してる人も楽しい開発者会議 35
36. Kaigiづくりのポイント • 運営はボランタリーベース • ビジョンの共有が前提 • 共有できないのであれば、得るものは何もない • モチベーションを保つ。消耗は良くない • 不確定要素を共有する • モデルを用意しても最後まで計画は確定しなかった • 毎週土曜日に進捗管理おじさんが現れるようにした • 現実にはもっとグダグダと進む。こんな綺麗ではない！ • 欲しいものを求めた結果ご飯がしぬほど豪華になった 36 講演はスピーカーを信頼して任せる。運営は当日の環境をめっちゃ良くする、って気持ちが強かった
37. 開発者が喜ぶものは寿司だ 37
38. Kaigiづくりを体験してみよう 38
39. ワーク：Kaigiの役割からモデルを作る せっかくなので独自性を出してみてください 独自性の例：「アフターパーティに寿司を出す」 • 会場 • 本会場、アフターパーティ、講堂、施設、動線計画 • 準備 • 配布物、掲示物、当日備品、ランチ、パーティ、予算編成 • 企画 • セッション公募、プログラム作成、基調講演 • 開催 • 誘導、受付、司会、基調講演の進行、案内、撮影、録画、撤収 • 広報 • 告知、Webサイト、企業協賛 39