1547日目のカンファレンス | 3.実行委員長 -- PHPカンファレンス関西2024
実行委員長の役割は、カンファレンスによって異なります。
PHPカンファレンス関西2024の場合、運営組織の顔であり、責任者であり、リーダーでした。そのため、他の実行委員にタスクを依頼するだけでなく、考えるべきことも数多くありました。
この記事では、私がカンファレンスの実行委員長として重要だと考えていた役割や考え方、それに基づいて行った行動についてお話しします。（ちょっと偉そうな話が多いですが許してください）
目次
この記事は連載記事（全4回）の第3回です。
第1回：開催失敗から再開まで
第2回：組織づくり
第3回：実行委員長
理想を持って動く
"開催テーマ" をよく飲み込む
自分の理想を実現するために助けてもらっている
依頼内容は具体によらず抽象で
最初の企画はトップダウンで
実行委員会での立ち回り
チーム間の連携担当になる
ボトルネックにならない
とはいえ、素早さが求められる場面では動く
リスク管理
絶対的な心理的安全性の確保
心理的安全性確保のために意識していたこと
主役は自分ではない
第4回：ぺちこん関西2024は成功か?失敗か?
理想を持って動く
実行委員長には、自分の中に明確な理想を描き、その理想を実現するために行動することが求められます。まずは、理想をどのように捉え、それをどのように扱うべきかについてお話しします。
"開催テーマ" をよく飲み込む
前回の記事で、「わかりやすい開催テーマ」の重要性について触れました。
開催テーマを明確に提示することは、実行委員をはじめとする全ステークホルダーに方向性を理解してもらい、各種判断の軸として活用するために不可欠です。
これは実行委員長自身にも当てはまります。
実行委員長が開催テーマに基づいて適切な判断を下すためには、誰よりも深く開催テーマを理解し、それを自分の中にしっかりと落とし込んでいる必要があります。
もちろん、開催テーマを決めるのは実行委員長自身です。開催テーマを決めると同時に、しっかり反芻して自分のものにすることが望ましいでしょう。
テーマを決める際には、カンファレンスを通じて実現したい世界がどのようなものか、何が達成されていればその世界が実現できたと言えるのかを、時間をかけて深く考える必要があります。じっ く り 考えた上で、誰に何を言われてもブレないよう、し っ か り とそのイメージを自分の中に築き上げることが大切です。もはや自己暗示に近いかもしれません。しかし、ここで実行委員長がどれだけ自分の中にめざす世界を創れているかによって、カンファレンスの出来が変わると思っています。
理想で言えば、開催テーマについて何時間でも語っていられる状態になることができればベストです。それぐらい、実行委員長がテーマをよく理解できているかが重要です。
自分の理想を実現するために助けてもらっている
以前、職場の先輩から「仕事をするときは、上司の代わりにその仕事をしていると思いなさい。」というアドバイスを受けたことがあります。
この言葉は、仕事をする際に自分の視座を上げるための助言でした。しかし、実行委員長としての立場では、逆の考え方をする必要があると感じています。
つまり「自分の理想を実現するために、（ボランティアである）実行委員に助けてもらっている」と考えるのです。
この考え方に基づくと、自分の判断軸がブレにくくなります。何か意見を求められた時も、「自分はなにがしたかったのか」「自分の理想を実現するためにはどっちがいいのか」と理想に立ち返って判断することができます。
私の場合、特に、少し手間がかかる依頼や面倒なタスクをメンバーにお願いする際には、この基準に基づいてそのタスクが本当に必要かどうかを見極めていました。こうした基準を持つことで、メンバーにも納得感を持ってもらえる依頼を心がけることにしていました。
依頼内容は具体によらず抽象で
実行委員長が自分の理想をしっかりとイメージできたら、その理想を実現するために各チームへタスクを依頼します。このときに重要なことは「依頼内容の抽象度を高くすること」です。
実行委員長自身が30人に分身できれば、カンファレンスは開催できるでしょう。しかし、残念ながら実行委員長はただの人間 です。そのため、実行委員の助けを借りる必要がありますが、個々のタスクを細かく指示していては、実行委員長自身の時間と体力がいくらあっても足りません。
そこで、頼みたいことの抽象度を高くすることで依頼の量を少なくします。
抽象度の高い依頼をすることで、チームが自主的にアクションを考え、動ける環境を整えることができます。これにより、実行委員長が直接関与しなければならない場面を最小限に抑えられます。
先の記事で触れた通り、PHPカンファレンス関西2024では、各チームに「ミッション」を設定し、そのミッションを達成を目指すように依頼しました。この「ミッション」こそが、 "抽象度の高い依頼" です。
以下に依頼の抽象度を図にまとめました。一番抽象度が高いものは、実行委員全員が目指すべき「開催テーマ」です。その下に各チームごとの「チームミッション」が位置し、さらにそのミッションを達成するための具体的なアクションが続きます。
こんなイメージをしながら進めていました
もちろん、チームミッションだけを依頼すればすべてがスムーズに進むわけではありません。チームミッションを達成するための企画や、場合によってはその企画を実現するための具体的なアクションについても、少し指示を出した方が良い場面もあります。しかし、チームが徐々に波に乗ってくると、依頼の抽象度を少しずつ上げても、内容を察して動いてくれるようになります。そのため、どのあたりの抽象度で依頼を行うかは、そのチームごとに調整する必要があります。どの程度の抽象度がそのチームに最適なのかは、その時々の状況に応じて探りながら判断することが望ましいです。
ひょっとすると、思っていた解決策以外のアクションでチームがミッション達成に動き出してヤキモキするのでは？と不安に思う方もいるかもしれません。しかし、大切なのは「思い通りに人を動かすこと」ではなく、「開催テーマに掲げた世界の実現」です。
つまり、多少想定外のアプローチであっても、開催テーマが示す理想の世界が実現できるのであれば、何の問題もないのです。それに、チームの方が実行委員長よりも優れた解決策を提案することは珍しくありません。また、実行委員はボランティアでカンファレンス運営に関わろうとしてくれた熱意ある人たちです。運営に対するモチベーションは高く、「何としてもカンファレンスを成功させたい」と考えているメンバーばかりです。開催テーマさえ伝えていれば、必ず成し遂げてくれます。（これは私自身が何度も実感したことなので間違いないです。）
ただし、実行委員から具体的な方法について相談があった場合には、積極的に対応すべきです。抽象的な依頼はあくまで効率的な依頼の方法論であり、実行委員に具体を考えさせることが目的ではありません。また、チームの方向性が怪しくなり、高度が下がってきたと感じたら、実行委員長がパタパタと仰いで再び上昇できるよう軌道修正を行いましょう。チームの力を最大限に引き出すためには、抽象と具体のバランスを見極めながら柔軟に対応することが求められます。
最初の企画はトップダウンで
先ほど、チームへのタスク依頼では抽象度を上げることの重要性についてお話ししました。しかし、抽象的な依頼のみを投げっぱなしではチームは動きません。どのようにアクションを取ればいいのかある程度イメージを伝える必要があります。
特に、チーム立ち上げ当初はメンバー同士がお互いをよく知らず、心理的安全性が十分に確保されていないため、活発な議論が起きづらい状態です。そのような状況で、抽象度の高い依頼だけを渡しても、どう動けばよいのかわからず、結果として行動に移してもらえない可能性があります。
そのため、最初の段階では、抽象度を少し下げた具体的な依頼を渡す方がスムーズに進みます。具体的な方向性を示すことで、チームが安心して動き出せる環境を作り、徐々に自律的な行動ができる状態を目指します。
たとえば、「新しいコミュニティ参画者を増やすために、知り合いを誘ってくれたら安くなるチケットを販売してほしい」や「初参加の人に会話のきっかけを与えるために、トレーディングシールを作ってほしい」など、Whyの後のHowも少し伝えるようなイメージです。
PHPカンファレンス関西2024では、これらの企画案を事前に実行委員長が検討し、全体企画資料としてまとめて実行委員に提示しました。
各ミッションやアクションだけでなく他の基本情報も記載している
このアプローチは、第1回の記事で述べた2020年の失敗からの反省に基づいています。当時、私は全員でカンファレンスを作り上げようと考えた結果、議論がなかなか進まず、準備が滞ってしまいました。その経験を踏まえ、実行委員長が自ら実現したいテーマに基づいて企画を先に考え、トップダウンで依頼する形を取ることで、準備をスムーズかつ迅速に進められるようにしました。
もちろん、実行委員から出てきたアイディアを否定するわけではありません。チームが打ち解け、関係性が深まるにつれて、メンバーからもさまざまなアイディアが提案されるようになるでしょう。
そのような場合には、アイディアが「開催テーマ」に沿っているかどうかを確認し、予算や人的リソースなどの現実的な条件を考慮した上で、実施の可否を検討します。（"できる"と言われたら基本的にお任せすることにしていました。）
実際、PHPカンファレンス関西でも、顔出しパネルや別部屋への中継はスタッフからの発案でした。
スタッフからの発案で作成決定しました
もちろんですが、アイディアが活発に出てくるようにするためには、アイスブレイクも重要な要素です。
PHPカンファレンス関西2024では、基本的にオンラインで作業進めていたのですが、2回ほどオフラインで顔を合わせる機会を設けました。すると、オフラインで直接顔を合わせた後は、その次の議論が活発になる傾向がありました。
私はアイスブレイクの雰囲気を作り出すことが苦手なので、アイスブレイクを上手に進められる他の実行委員を見つけて頼ることで、もっとより良いチーム環境を作ることができたのではないかと感じています。
実行委員会での立ち回り
実行委員長が実行委員会内でどのように動くべきかは、実行委員会の規模や構成によって異なるでしょう。ここでは、PHPカンファレンス関西2024における私の立ち回りを例にお話しします。組織によって「チームリーダ」や「チームメンバ」が担うべき役割や意識すべきことも含まれている場合があるかもしれません。
先にPHPカンファレンス関西2024の実行委員会がどのようなメンバで構成されていたのかをおさらいしておきましょう。
PHPカンファレンス関西2024実行委員会の特徴
全員で25人
5チーム構成
お互い初対面が多い
ほとんどのメンバがカンファレンス運営未経験
カンファレンス自体参加したことないメンバも
というか実行委員長もカンファレンススタッフ未経験
チーム間の連携担当になる
前回の記事で述べた通り、チーム制には「横のチームとの繋がりが薄くなる」という弱点があります。実際、PHPカンファレンス関西2024の実行委員会は、人数が多い上に初対面の人が多い組織だったため、隣のチームに話しかけるだけでも「はじめまして」と挨拶をしながら入っていかなければならない状況でした。
そこで、実行委員長がチーム間の連携役として機能することで、連携ミスによるリスクを軽減するように動きました。
まず、各チームが進めているタスクや進捗状況を全員が把握できるようにするため、隔週を目安に各チームの進捗をまとめた「会報」を作成し、全員に共有しました。
この「会報」によって、実行委員が他のチームの動きを個別に確認する手間を省きつつ、全体の進行状況を把握しながら自分のタスクを進められる環境を整えました。
"不定期"とありますが隔週目処で共有していました
（間に合わなかった時もある…）
この「会報」は実行委員メンバーからも好評でした。しかし、チーム間の情報連携ツールとして十分だったかという点については、別の課題が残ります。実際、後日実行委員メンバーに回答してもらったアンケートでは、「全体の把握」が一番大変だったこととして挙げられたケースが複数ありました。そのため、次回のカンファレンスでは、情報共有の方法やツールについて再検討し、より効果的な連携手段を模索する必要があるかもしれません。
また、会報での情報共有以外にも、実行委員長は各チームの誰が何を担当しているのかを把握しているため、チーム間で質問が発生した際には「誰に質問すればいいか」といったサポートを行うことも行いました。
この役割には、情報が実行委員長に集約されていることで迅速に対応できるという利点があります。しかし同時に、実行委員長自身の状況把握力が問われる場面でもありました。
ボトルネックにならない
今回の組織体制では、あらゆる判断が実行委員長に集中する仕組みとなっていました。そのため、実行委員長の反応速度がタスクの消化スピードに直結すると考え、私自身がボトルネックにならないよう心がけました。
具体的には、実行委員長に回ってきたタスクは速攻で終わらせるようにしていました。また、私の性格上、タスクを溜め込むと自分のメンタル的に動きが鈍くなる傾向があるため、チャットの返信は可能な限り迅速に行い、「宿題」となった案件については早めに時間を確保して対応するよう努めました。
また、手を動かす必要がある作業については、自分で抱え込まず、メンバに依頼しました。人によっては「自分の仕事を他人に押し付けている」と感じて気が引けるかもしれません。しかし、実行委員長がボトルネックになることこそが、実行委員会全体にとって最も悪影響を及ぼします。実作業はメンバに任せ、指示出しや判断に専念することが実行委員長としての基本姿勢だと考えています。
とはいえ、素早さが求められる場面では動く
基本的には、指示出しに専念し、実作業はメンバーに任せることが実行委員長のセオリーだと考えています。しかし、一部には例外があります。それは「スピード感が求められる作業」です。
たとえば、スポンサーから火急の依頼メールが来た場合が挙げられます。担当者を経由して実行委員長に判断を仰ぎ、さらにその指示をもとに対応を進めている間に、手遅れになってしまう可能性もあります。このようなケースでは、実行委員長が直接作業を行うことで、迅速な対応を実現し、実行委員会全体の対応速度を上げることができます。（もちろん、必要な確認は行いますし、場合によってはメンバに依頼もします。）
PHPカンファレンス関西2024では、この考えに基づき、SNS投稿の一部を実行委員長が直接担当する場合がありました。SNSではスピード感のある投稿が求められる場合があります。たとえば、実行委員会から事前にわかっている告知をする場合はメンバに依頼し、一方で、一般の方からSNS上で質問が寄せられた場合には、実行委員長が直接回答することで、迅速な対応を心がけました。
余談ですが… PHPカンファレンス関西2024において、この「実行委員長は指示出しに徹する」の原則を思いっきり無視してしまったコンテンツがあります。「めもり〜ちゃんのオススメトーク診断」です。
このコンテンツは、企画段階で実装のイメージが自分の中で完全にできてしまい、結局我慢できず、自分で手を動かしてしまいました… 笑。
（さすがに質問の作成はメディアチームにお願いしました。）
（この段階ではめもり〜ちゃん出演のアイディアはなかった）
リスク管理
実行委員長は、カンファレンスの開催に対して最終的な責任を負う立場です。そのため、カンファレンスの開催を阻害する可能性があるリスクを事前に把握し、危機的な状況に陥りそうな場合には、適切な対応を迅速に取ることが求められます。
リスクの大きさや対応の必要性を適切に判断するため、PHPカンファレンス関西2024では、いくつかの「重要指標」や「マイルストーン」を設定していました。これらの指標やマイルストーンを定期的に監視し、実行委員メンバへ常に情報を開示することで、全体の透明性を確保しながらリスク管理を行いました。
たとえば、チケットの販売状況については日次でチャットに投稿し、常に最新の状況を把握できるようにしていました。また、スポンサーからの連絡やその他の重要なメールについても、検知次第チャット上で確認できる仕組みを整えていました。
関西弁なのは私の趣味
また、リスクが大きすぎるものについては、危機的状況に陥った際にどのような対策を取るべきかを事前に決めておくことで、緊急時にも迅速に対応できるようにしていました。
PHPカンファレンス関西2024の場合、6年ぶりの開催ということもあり、最大の懸念材料は予算の確保でした。そのため、予算確保に関しては、具体的なマイルストーンとデッドラインを設け、目標が達成できなかった場合にどのように予算を捻出するかまで事前に決めていました。
絶対的な心理的安全性の確保
もうひとつ、実行委員長の立ち回り方で、守らなければならないことがあります。それは、絶対的な心理的安全性です。
繰り返しますが、実行委員は全員ボランティアです。ボランティアとして参加する組織は、メンバーにとって居心地が良くなければなりません。
実行委員長は実行委員会の責任者として、委員会の雰囲気を良好に保つ責任があります。また、その立場上、意図せずメンバーに圧力をかけてしまう可能性があるため、心理的安全性を確保することを常に意識して行動していました。
私の場合、以下のようなことを意識して心理的安全性の確保に努めていました。ただし、心理的安全性の確保方法や、雰囲気の作り方は人によってやり方があると思いますので、これが唯一の正解というわけではありません。
（意識はしていたのですが… その、時々、焦っている感情が滲み出ていたかもしれません💦 ミーティング後に "やっちまったぁ！！" と思うことも何回かあり…… ごめんなさい💦）
心理的安全性確保のために意識していたこと
ポジティブな雰囲気作り
いいことがあったら一緒に喜ぶ
適度に冗談を言う
許される範囲でふざける
雑談をはさむ
絵文字を多用してみる
ネガティブな雰囲気防止
うまくいかない時に不機嫌オーラを出さない
悪いことがあってもカバーできればOKと考える
目的が達成されれば方法にはこだわらない
悪いことした時は謝る!
また、この分野は私自身が得意とはいえず、今回苦労した部分のひとつでもあり、それと同時に今回集まってくださったメンバ全員の温かい人柄に助けられた部分でもあります。もし、雰囲気作りが苦手な実行委員長であれば、この役割を得意なメンバーに任せるのも一つの方法かもしれません。
主役は自分ではない
技術カンファレンスはなにかしらの目的を持って開催されます。
PHPカンファレンス関西2024では、「開催テーマ」を策定することでその目的を明確にしましたが、テーマを設定していないカンファレンスでも、「所属組織外の人と接点を持つ」「関係者が楽しく技術を語れる」「カンファレンスを知らない人に知ってもらう」「みんなで楽しむ」など（宣言されていないかもしれませんが）目的があるはずです。
「主催する目的」を考える際に注意したかったことが、「実行委員長による外部への露出」でした。今回の場合、実行委員長が目立つことは、カンファレンスの目的ではありません。
実行委員長は、カンファレンスの責任者であり「顔」としての役割を担います。そのため、広報の先頭に立つことが求められる場面もあります。しかし、それはあくまでカンファレンスの目的を達成するための手段であり、「先頭に立つこと」そのものが目的ではないと考えていました。
個人的には、今回のカンファレンスでこの線引きにとても悩みました。要するに、私の場合はテーマ実現のために「実行委員長のカンファレンス」にはしたくなかったのです。これは、最初の記事で述べた通り、私がカンファレンスを通じて「周りで技術を高め合える場を作るきっかけ」にしてほしいと考えていたことに起因しています。実行委員長が目立つことで、カンファレンス全体がその個人の成果や活動として見られるのではなく、コミュニティ全体の力によって成り立つものとして認識されるべきだと考えていました。
先頭に立って盛り上げたい… しかし、今後もこのカンファレンスが継続し、技術を高め合える場を作り続けるためには、自分に依存する状態は避けるべきだと感じていました。何よりも、多くの人に協力してもらいながら準備を進めている以上、カンファレンスの主役は実際に登壇する "登壇者"、もしくは "コミュニティに関わる全員" にしたかったのです。
（ただ、他のカンファレンスでは実行委員長がちょうどよく立ち回っていることもあり、もう少し露出を増やしても良かったのではないかと感じる部分もあります。少し私が考えすぎていたのかもしれません。。。）
さて、ここまで、どのようにカンファレンスの準備を進めてきたかを説明しました。
次の記事では、いよいよ当日の様子や、各企画の結果、そしてカンファレンスが成功したのかについて触れます。
PHPカンファレンス関西は、2025年の開催に向けて、スタッフを募集中です。
詳細な説明は以下動画から！！
https://www.youtube.com/watch?v=qYW9tTvn3Hs
申し込みは、以下のフォームからお願いします！！
https://docs.google.com/forms/d/e/1FAIpQLSenjwQIDWyqQMfphURhR0cYNCtq1lWJHTiKPxVUB8w_1UX0ew/viewform