1547日間のカンファレンス | 2.組織づくり -- PHPカンファレンス関西2024 回顧録
はじめに
前回の記事で、PHPカンファレンス関西2024の開催までの経緯を記載しました。
この記事では、PHPカンファレンス関西2024における実行委員会の組織編成や、運営方法について触れます。
目次
この記事は連載記事（全4回）の第2回です。
第1回：開催失敗から再開まで
第2回：組織づくり
はじめに
方向性を揃える
並列してタスクを進めることができる
カンファレンスの"方向性"を揃える
開催テーマの効果
開催テーマがなかったら？
実際に策定した開催テーマ
実際に効果はあったのか？
準備作業の並列化
採用した組織構成とその理想
抽象度高めの "チームミッション" を用意
決められるところは先に決める
第3回：実行委員長
第4回：ぺちこん関西2024は成功か?失敗か?
実行委員会の組織づくりは、「方向性を揃えること」と「並列してタスク実行ができること」を意識して行われています。
方向性を揃える
言うまでもなく、実行委員会のメンバーは同じ目的を共有し、方向性を揃えることが不可欠です。
特に、今回集まったメンバーは、私を含めてカンファレンス運営の経験が豊富ではありませんでした。そのため、全員が同じカンファレンスの完成図をイメージしながら作業を進められるよう、方向性を統一することが重要でした。
並列してタスクを進めることができる
PHPカンファレンス関西2024では、参加人数の目標を400人に設定しました。
これだけの規模のイベント準備を、すべてを直列的に進めていては到底間に合いません。そのため、タスクを適切に分割し、並列的に進行できる体制を整えることが不可欠でした。
本記事では、この2つをどのように実現したのかを中心にお話しします。
カンファレンスの"方向性"を揃える
実行委員メンバは、一部、他のカンファレンスでお話ししたことがある方を除けば、ほとんどが私と初対面の方々でした。
関西でPHPカンファレンスが開催されていない間、私自身も関西でのコミュニティ活動があまりできていなかったため、メンバそれぞれがどういう人なのかを十分に理解しないまま運営を進める必要がありました。
つまり、ほぼ初対面のメンバーと、カンファレンス運営に関する共通認識がない状態でチームを動かす必要があったのです。この状況下で多くのタスクを効率よくこなすためには、どうすればいいのか…その際に役立ったのが、事前に作成していた「開催テーマ」でした。
開催テーマの効果
開催が決まった時、まず私が取り掛かったことが「わかりやすいテーマの提示」でした。
いわゆる「ミッション・ビジョン・バリュー（MVV）」に当たるものです。テーマには、大きく2つの効果があります。
ひとつめの効果は、実行委員全員にカンファレンスの目的を明確かつ一貫して伝えられることです。私は、カンファレンスはただ開催するだけでは不十分で、その場で何かしらの効果を生むものでなければならないと考えています。そしてなにより、私には前回の記事で述べた通り、「カンファレンスで実現したい世界」がありました。どのような効果をもたらすカンファレンスをつくろうとしているのか目的を明確にすることで、全員が同じ方向を目指して進める体制を作ることができます。実行委員はこの目的に沿った議論を行い、アイディアを考え、実現に向かうことができるようになります。
テーマは、全員が同じ方向を目指せる体制にすることが目的です。そのため、よくある「何を実現したいのか伝わらないタイプのテーマ」では不十分です。例えば "元気" や "つながり"、"Let's Go!!" といったテーマでは、関係者が具体的に何を目指せば良いのかを理解するのは難しいでしょう。カンファレンスによってどのような世界を実現したいのか、どのような状態を目指せば良いのかがわかる、明確な文言であることが求められます。
ふたつめの効果は、実行委員長である私自身の判断軸となることです。今回の組織体制では、実行委員長である私が多くの細かい判断を求められることが目に見えていました。そのため、実行委員長である私自身に「一貫してブレない軸」が必要でした。
「開催テーマ」は、私がその場の思いつきで判断をしないようにするための指針として機能します。また、どのアイディアを優先するべきかを決める基準にもなります。
開催テーマがなかったら？
ではもし、「開催テーマ」やそれに相当する「開催の目的」がない状態でカンファレンスを運営した場合、どうなるでしょう？
目的がない団体では、“開催すること自体がゴール” になってしまいます。その結果、メンバーそれぞれがやりたいことがバラバラになり、何かアイディアが出ても議論が平行線をたどる可能性が高くなるでしょう。なぜなら、そのアイディアに賛同する理由も反対する理由も、すべて個人の主観に依存してしまうからです。
また、そもそも目的がなければアイディアも出てきません。アイディアとは、目的に沿った課題を解決するための方法論です。目的と解決すべき課題が明確でなければ、アイディアは単なる「思いつき」に過ぎません。
さらには目的が欠如していると判断軸もブレブレになるでしょう。たとえば、「Aチームではこう言っているのに、Bチームでは矛盾する判断をしてしまう」「A案とB案があるが、どちらを採用すべきかわからない」といった混乱が容易に生じてしまいます。
個人的にも、この開催テーマ設定にはかなりこだわりました。というのも、「関西を盛り上げたい」「関西を活性化したい」「関西でコミュニティをつくりたい」といった一見聞こえの良いフレーズはよく耳にするものの、「では、関西でコミュニティをつくって具体的にどうしたいのか？」をしっかり語る人が少ないように感じていたからです。きっとその「盛り上げたい」という表現の奥にあるであろう「実現したい世界」聞かせてほしいと思うのです。そして自分が開催する時には、ただの交流会で終わらせるのではなく、参加者が望むなら、情報交換やモチベーションの向上など、具体的な利益を得られるコミュニティを目指したかったのです。
MVVについては、以下の書籍を参考にしました。
プロダクトマネジメントに関する書籍ですが、"プロダクト"を"カンファレンス"に読み替えて読むことができます。
実際に策定した開催テーマ
実際に、私が実現したかった世界を言語化し、設定した「開催テーマ」が以下です。
開催テーマは1つの主題と、3つの実現内容によって構成されています。
このテーマは、関わっていただくすべてのステークホルダーに必ず提示しました。先に述べた通り、関わる全ての人がカンファレンスの目指す方向性を統一するためです。実行委員会の募集時にはもちろんのこと、スポンサー募集資料、公式Note、さらには登壇者向けの説明資料にも、このテーマを記載しました。
以下に内容を一つずつ紹介します。
メインテーマ：関西PHPエンジニアコミュニティの立ち上げ
他地域に負けないエンジニア文化を作り、技術を高め合える文化/場をつくる
今回のPHPカンファレンス関西は6年ぶりの開催であり、まずはコミュニティを一から立ち上げる必要があると考えました。また、自分のカンファレンス開催へのモチベーションは、前回の記事で述べた通り、自身の周囲で感じる閉塞感の打破でした。技術について語り合える仲間を求めていたのです。これらを言語化し、「技術を高め合える場をつくる」ことを目的として掲げました。
新たなコミュニティ参画者の発掘
技術イベント経験がない関西エンジニアに参加/登壇をしてもらえるイベントを目指します。
「コミュニティをつくる」ということは、そのコミュニティに参加してれる人を継続的に増やす必要があります。関西での開催が6年ぶりであることを考慮し、これまで技術イベントに参加したことがないエンジニアにも足を運んでもらえるイベントを目指しました。そのためは堅苦しいイベントにするのではなく、ワクワクするようなコンテンツを用意し、「参加して楽しかった」と思えるカンファレンスにすることが絶対条件でした。
関西での技術情報共有の場となる
関西のエンジニアが最新の技術情報に触れることができる機会を創出します。
参加して楽しい"だけ"のカンファレンスは目指す姿ではありません。主題にあるように、技術を高め合えることができるようなコンテンツを用意し、参加した人が「多くの学びや気づきを持ち帰れた」と感じられるカンファレンスにすることを目標としました。
持続可能な運営体制
定期的な開催を通じて情報をアップデートするためのイベントとして有り続けます。
実は、このテーマは見た目以上に非常に重い意味を持っています。というのも、PHPカンファレンスは2018以降、開催が叶わない状態が続いていたからです。文化を作るためには継続してカンファレンスが存在し続ける必要があります。「来年のPHPカンファレンス関西で会いましょう」「成果が出たから次のPHPカンファレンス関西で発表しよう」と言ってもらえる場所を作り、“文化” を築くためには、これまで開催できなかった要因を振り返り、持続可能な組織体制を構築する必要があると考えました。
実際、このテーマに基づいて今回のカンファレンスで発生した準備作業は、すべてドキュメント化して保存しています。これにより、次回以降の運営がスムーズに進む基盤をつくろうと考えました。
実際に効果はあったのか？
この「テーマを設定する」施策は非常に効果があったと考えています。
実際に作業へ関わっていただいた方々から「とても分かりやすかった」との声をいただくこともありました。また、登壇者からもTwitter（現X）で「こういうテーマに沿ってプロポーザルを考えればいいのね」といった反応が寄せられ、テーマがガイドラインとして機能していることを実感しました。
なにより、当初の予定通り、各種企画の優先度付けや予算配分もこのテーマに基づいて判断を下すことができました。これは実行委員長の精神的苦痛の回避にも役立ちました。せっかく出してくれたアイディアをリジェクトするのは辛いことですが、理由があるといくらか和らぎます…。
準備作業の並列化
PHPカンファレンス関西の2018年開催時には、約350人の参加を見込んでいたそうです。これを踏まえ、PHPカンファレンス関西2024では400人の参加を目標に設定しました。
これだけの人数が参加する規模のイベントでは、すべての準備作業を直列で進めていては到底間に合いません。そのため、タスクを適切に分割し、並列化して効率的に実施する必要がありました。
余談ですが、前回開催からの引き継ぎが一切ない状態で、さらにカンファレンス運営未経験者ばかりの組織で400人の参加目標を掲げるのは、無謀に思えるかもしれません。実際、この目標は根拠のない数字でした（笑）。私が「やるからには前回を超える！」「私たちなら超えられる！」と信じて決めた値に過ぎません。
そもそも、前回開催時の資料に記載されていた「350人」という数字も、実際に達成されたかどうかの記録が残っていない、不確実なものです。しかし、開催するからには参加人数目標を設定しないわけにはいきません。カンファレンスの規模を示すため、スポンサーを初めとする関係者へ提示する必要があるからです。だからこそ、私たちは「覚悟をキめて数字を決める」しかなかったのです。
並列してタスクを完了させ、準備を迅速に進めるために、依存関係が強いタスクごとにチームを編成し、それぞれが並行して作業を進められるよう工夫しました。
採用した組織構成とその理想
以下は、実際に採用したチーム分けの図です。4～5人のメンバで構成されたチームを5つ作成しました。
各チームマネジメント/進捗管理は私が担当しました。ただし、この構成では実行委員長への負荷が非常に大きくなります。実際、全チームのマネジメントを行うために、すべてのミーティングに出席して状況を把握するのは骨の折れる作業であり、この構成は今後の実行委員長が採用すべきではない「アンチパターン」であると考えています。それでも、今回この構成を選択したのは、ほぼ初対面のメンバが揃った状態でスタートしたため、誰をリーダーに任命するか判断が難しかったからです。このため、コミュニティ立ち上げ時特有のコストと割り切り、実行委員長の高負荷は初めから許容することにしていました。
（実行委員の皆さんには、私のバタバタが伝わってしまい、気を使わせてしまったかと思います。。。ただ、準備が進むにつれて各チームが自走するようになり、この負荷は徐々に軽減されていきました。これに関しては、チームメンバの協力に感謝しかありません。）
（図の下にあるように、以前のPHPカンファレンス関西を知っている数人のアドバイザーにもご協力いただきました。特に会計や規約周りはアドバイザーの方々がいなければ回らなかったと思います。本当に感謝しています。）
理想論で言えば、各チームにリーダーを立てて、それぞれがチームのマネジメントを行うべきでしょう。または、下図のように、マネジメントを担当する人数を絞り、複数人が複数のチームを管理する形が考えられます。この場合、マネジメントを行うメンバー同士が定期的に認識を共有する仕組みを設けることで、チーム間の連携を保つことができると思います。いずれの方法を採用するにしても、次回以降の開催では、実行委員長がすべてを確認するような体制は避けるべきでしょう。
さて、チームを作った後は、各チームに並行してタスクを依頼しないといけません。しかし、細部に至るまで実行委員長が全て指示を出していては、実行委員長の体が足りなくなってしまいます。そこで用意したのがタスク内容を抽象的に示した「チームミッション」です。
抽象度高めの "チームミッション" を用意
実行委員長がすべてのタスクを詳細に用意することができない以上、各チーそこで、各チームに対して「チームミッション」という抽象度を上げた指針を用意し、そのミッションを達成するために動いてもらう形を取りました。ここでも「開催テーマ」が大きな効果を発揮しました。
私が実現したいカンファレンスは、テーマに定義した通り「他地域に負けないエンジニア文化を作り、技術を高め合える文化/場をつくるコミュニティの立ち上げ」を目指すものです。であれば、各チームに依頼するタスクも、抽象度を上げていけばこのテーマに辿り着きます。個々のタスクとこのテーマの中間にある「チーム目標」をメンバが認識できるよう、各チームのミッションを用意しました。
とはいえ、抽象度の高いチーム目標である「ミッション」だけでは、具体的にどのように動けばいいかわかりづらくなります。特にチーム結成当初はお互いにコミュニケーションもうまくいかないので、主体的にミッション達成のための行動を起こすことは難しいでしょう。そのため、ミッションを実現するためにどういう作業が必要かをブレイクダウンした「やってほしいこと」とそれぞれのマイルストーンも併せて伝えました。
具体的にやってほしいことのみを伝えると、こちらの意図と違う捉え方になりかねませんが、こちらの目指す方向を「開催テーマ」と「ミッション」で伝えているので、大きな齟齬は発生しなくなります。
実際に設定した「ミッション」と「やってほしいこと」は下図の通りです。
これらのミッションは、全体テーマと一緒に「全体企画資料」として実行委員全員に共有しました。この資料には、自チームのミッションだけでなく、他チームのミッションも掲載しています。チーム間連携時にどのようなことをやっているか理解してもらうためです。（全体企画資料については、次の記事で詳しく取り上げます。）
"全体企画資料"にて共有した
決められるところは先に決める
チーム内のタスクも並行して進められるよう工夫してもらいました。
タスクを分解し、先にできるところは先に実施してもらったのです。
全員で1つのイベントを実施しようとしているので、どうしてもタスクには依存関係ができてしまいます。特に時系列に関する依存関係は厄介です。
たとえば、トークの採択作業では、作業開始時にプロポーザルの募集をすべて締め切っている必要があります。募集締め切りまでは採択作業ができません。
PHPカンファレンス関西2024実行委員会のメンバは全員ボランティアです。全員が実行委員会以外の"本業"を持っており、必要なときに無理やり時間を確保できるとは限りません。
そのために、1つに見えるタスクを分解して、依存関係がない部分を進めることができるようにしました。
たとえば、先ほどのトーク採択作業の場合、先に"採択/登壇者チーム"のみなさんに「採択フロー」を検討してもらい、プロポーザル募集終了時にはフローに従って決めればいいようにしました。これによって、プロポーザル締め切り時に長い採択会議をする必要はなくなりました。（実際、2時間の会議を3回予定していましたが、2時間の会議1回と1時間で決め切ることができました。とはいえ、タイムテーブルに落とし込むところはどうしても時間がかかりましたが…）
全実行委員の意見を採択に反映させるため、プロポーザル募集締め切り前に投票/採択ルールを作成し事前確認を依頼してもらいました
また、PHPerシール（参加者のTwitter（現X）のアイコンを印刷したシールを配る企画）も、"名札/特別企画チーム"の皆さんがチケット販売前に技術検証や発注フローを確認してくれていたおかげで、とてもスムーズに発注することができました。
9/23には入稿先の検討や技術検証を分担して行っていただいていました
実は、このチーム制には弱点があります。それは「横のチームとの繋がりが薄くなる」ということです。横のチームとのつながりが薄くなると、全体の進捗状況が見えづらく、メンバが動きづらくなってしまいます。今回、この問題は実行委員長が橋渡し役をすることでカバーしようとしました。これについては、次の記事で触れることとします。
PHPカンファレンス関西2024の実行委員会では、「開催テーマ」を用いて全員の方向性をそろえ、チーム制を導入した上で抽象度の高い依頼をすることで各チームが目標に向かって準備を進めていける状態をつくりました。
次回はこのような組織の中で実行委員長が何を考えながら動いていたかについてまとめます。
PHPカンファレンス関西は、2025年の開催に向けて、スタッフを募集中です。
詳細な説明は以下動画から！！
https://www.youtube.com/watch?v=qYW9tTvn3Hs
申し込みは、以下のフォームからお願いします！！
https://docs.google.com/forms/d/e/1FAIpQLSenjwQIDWyqQMfphURhR0cYNCtq1lWJHTiKPxVUB8w_1UX0ew/viewform