制度設計における学び（登壇支援制度の作成）
こんにちは。M&AクラウドのEMの鈴木（@yamotuki）です。この記事では「制度設計」についてノウハウを共有したいと思います。
エンジニアメンバーが外部のカンファレンス登壇をするときの支援について制度を作ったので、その知見をアウトプットするものです。
登壇支援制度を作る背景
今回は制度を作って推奨したい行動として「登壇」をピックアップしました。M&Aクラウドの開発チームはもともと全員インフルエンサーというバリューを掲げていました。
これまでも登壇したい人については、社内でネタ出し、情報収集手伝い、登壇資料のレビュー、登壇練習などみんなで支援してきました。
登壇が業務なのかプライベートなのかの線引きは特になく、お休みの日になればたまにカンファレンスに遊びに行って喋る、というような形でした。
私がEMになってから全員インフルエンサーのバリューをさらに強化し、チームの技術力向上と認知向上を目指してきました。その中の手法の一つとして、一部メンバーの半期の目標の中に登壇や記事作成を入れていました。目標に入れるということは、それを休日に行ったとしても業務になります。業務であるなら交通費や宿泊費を出さなければいけません。一方で、交通費が高額になるケースで手放しで全てお支払いできるほど会社に余裕はありません。（スタートアップなので。現金は一定あるが、今は投資を受けて売り上げと利益をあげていこうというフェーズです。無駄使いはできません。）。
経営陣含む関係者に、登壇することで会社にメリットがあるんだよ、と示さなければお金は出せないわけです。
そこで、登壇のメリットを集めて、「ここまでだったら会社としてもリターンがあるから業務扱いにしようね」という制度設計をすることになりました。
登壇制度詳細
以下に制度の資料を示します（一部センシティブ情報と実行詳細を抜いています）。
この資料には「コミュニティへの貢献」は入っていません。取り巻くエンジニア文化は置いておいて、会社がお金を出す以上は会社にとってのメリットを示す必要があり、以下の表現になっております。ここについては、エンジニア文化としてコミュニティに属し、貢献するというのが裏情報としてあるという前提でお読みください。
できるだけ空雨傘フレームワークに沿って事実と解釈、提案を分離しようとしています。資料作成方法は書籍「問題解決の全体観」や「ドキュメントコミュニケーションの全体観」を参考にしています。
現状（空）
M&Aクラウドの開発チームでは「全員インフルエンサー」をバリューとして掲げ、外部発信をすることを推奨している。
外部発信は新規採用、メンバーのスキルアップの2点に寄与している。
また、一部メンバー個人の目標に登壇回数などが入っていて、登壇という行為自体は業務の一部と解釈するのが自然。一方で現在は登壇については各個人がボランティア的にやっている状態であり、労務上の問題がある。
このような状態であっても2022年は10月時点で合計13回の登壇がなされている。
解釈（雨）
労務的に問題のある状態は、上場を目指すスタートアップとしては監査に影響がある可能性があり、解消はMUSTであると認識
「全員インフルエンサー」のバリューは他社に例が無く、弊社エンジニアリング組織特有のものである。このバリューを通して1. 採用の強化 2. スキルの高い人員を育成 3. 定着、の3点を強化できる。強化できると考える理由は以下のもの。
採用について
CTO協会による「開発者体験ブランド力調査レポート」によれば転職先として重視することとして3位に同僚の技術的レベルが高いこと（上位平均30社で62%）が入っている。また、アンケート回答者のエンジニアが認知している配信チャンネルとして 1. 所属エンジニアのテックブログやQiita等の技術情報の発信（同76%）, 2. 所属エンジニアの登壇している技術イベント（同66%）が挙げられている。WACULによれば「入社した企業は「就職/転職活動前から社名を知っていた」という回答が60％」という調査結果があり、特に採用においては、弊社使用技術に興味があるエンジニアが集まるカンファレンスに登壇することは長期視点で有効であると推測される。「同僚の技術的レベルが高いこと」が求められるのであれば、登壇の内容についてチームとして支援をし、内容の質を上げる活動も必要である。
補足: CTO協会のレポートで挙げられている転職先として重視することTOP3は以下のものであり、いずれも同程度に重視されていることが窺える（3位だからといって重視される率が低いわけではない）。
リモートワーク等の働き方に柔軟性があること（上位平均30社で66%）
利用している技術スタックに親和性/興味関心があること（同64%）
同僚の技術的レベルが高いこと（同62%）
スキルの高い人材の育成について
登壇を通してメンバーのスキル向上が見込める
情報を整理して人に伝えるスキルの向上
多くの人の前で話すため、より正確な情報を得ようとして技術や行動への理解が進む。
定着について
採用についての項目で記述したが、「同僚の技術的レベルが高いこと」は入社時だけでなく日常業務でも同様に多くのエンジニアが大切にするポイントであると認識しており、技術レベルを上げることが定着につながると考えている。
解決策（傘）
労務的な問題を解消し、1. 採用の強化 2. スキルの高い人員を育成 3. 定着 この３点を促進するための解決策を以下のように提案する。
登壇に関わる勤怠について
登壇とその他セッションの聴講で10-16時のコアタイムをカバーできる場合には平日に振替休日を取れる。
業務に関わる技術に関連する登壇は業務と見なし、弊社出張規定に基づき交通費・宿泊費を支払う。
対象は大規模カンファレンスのみとする。
大規模カンファレンスとは？
丸1日以上開催されることを前提に、(トラック数) × (開催日数)が2以上になるもの（※元資料にはカンファレンス早見表が付属。この記事では略）
目的を達成するために上記の解決策がベストだと考える理由。
原則として業務として扱う理由
チームとして登壇の質を上げる方向にするため。「同僚の技術的レベルが高いこと」が転職先検討で重要であると「雨」で書いた。個々人に任せたボランティア（=業務外活動、交通費は一部補助といった制度）ではなく、アイディア出し・資料相互レビュー・リハーサルなどもチームとして支援したい。
「3. 定着」視点。登壇はエネルギーを使う活動である。登壇後は休養が必要であり、弊社勤怠のルールの上で振替休日を取れる形をとる。
補助を非課税の交通費・宿泊費として支払うため。業務外の補助としてしまうと法定外福利となり課税対象。
大規模カンファレンスのみ、という足切りを入れる理由
「1. 採用の強化」視点では、より多くの視聴者と、弊社と登壇者と同列の参加者としての社外登壇者が多くおり、採用潜在層にリーチすることが重要。
「2. スキルの高い人材の育成」視点でも、単に友人がいる程度の小規模勉強会ではなく、規模の大きな勉強会に登壇し、一定の緊張感の元で登壇準備をして発表することで、スキルアップ効果が見込めると考える。
弊社ではこれまで PHP Conference（2022年xx万）, PHPerKaigi（2022年プラチナxx万）, VueFes（2022年xx万） といった大規模イベントにスポンサーを行なっており、認知拡大を目指してきた。仮にx人が登壇し、一人当たりx万円を支出した場合でもxx万となり、スポンサーと同等の広報効果が得られると考えている。
※聴講のみの参加は休日出勤業務としては扱わない。ここに書かれているのは登壇+聴講のケースで、仮に2日間のうち1日登壇した場合には1日のみ振替休日を取れる。聴講のみは、2022/10/19時点では個人の判断による行動とする。理由はエンジニア人数が少ない弊社の現状にあり、仮に数人のエンジニアが土日聴講して平日二日間いないケースが増えると開発スケジュールへのインパクトが大きいため。 将来的に聴講のみも補助対象となる可能性はあるが、完全に未定。
登壇制度設計の詳細論点
リターンがあるのか
数値としてROIをガッツリ出すのか、バリューや哲学だからやるのだ、と打ち出すのかは難しいポイント。
単に採用文脈だけを打ち出すと、他の経路の方がROI良いのではないか？と突っ込まれる可能性があるので、定着やスキルアップなど、あえて定量化が難しいものを混ぜることで数値+定性のリターンを提案する。
使えそうな予算があるか
出張費予算はもともとなかった。今回は広報予算があったのでそれを転用する形で提案。
福利厚生なのか、業務出張なのか
最初は福利厚生として扱う方向で考えていた。ただ、福利厚生だと、課税所得扱いになり社員の手取りが減るし、業務扱いではないのでお休みが取れない。目標に入れている業務扱いなのに振替休日を取れないのはおかしいので、福利厚生案は没。
補助なのか全額なのか
同上の議論。福利厚生であるなら補助扱いにできる。小さいカンファレンスも含めた全ての遠方カンファレンスを業務扱いにすると費用支出が許容できないので、やむなく規模での線引きをした。
ハック予防をするべきか
遠方のLTばかりとかでハックされたらどうするのか。
問題ない。一定の広報効果はあるし、同僚の目がある。ハックばかりが横行したら制度を考え直せば良い。我々は大企業ではない。
小規模カンファレンスについては？
この資料では未定義です。夕方に開催されているようなカンファレンスは業務に近い内容であれば業務として勤怠内で行くといいと考えています。交通費支給もOK。ただ、遠方の小規模カンファレンスについては個別相談。
その他制度設計ノウハウ
誰が関係者なのか
今回のケースだと、最終的にプロダクト開発部の予算として支出しているのでプロダクト開発部の課長と部長が関係者。その他に、休日出勤や振替休日の扱いがあるので労務、交通費や出張費の扱いがあるので経理とも相談して進める。福利厚生なのか経費なのかなのか論点を関係者から初期段階でヒアリングしておく。
はっきりさせないまま走り出すと、提案をしたがどこかで止まってしまうということがあり得る。関係者を洗って懸念点を潰しておくのが大事。独りよがりの提案は通らない。
妥協点を探す
振替休日を取れる条件についての話。
登壇部分だけだと1日の労働にならないので振替休日を取れないと分かった。登壇+聴講で1日いたことにすることにより振替休日を取れるように整理した。全社の労務ルールから変えに行くとめちゃめちゃ大変でいつまで経っても制度が作れないので、今の大枠のルールの中で妥協点を探して作るのが大事。
背景情報大事
「解決策」のところだけを提案するのは「突然の傘」と呼ばれる状態（書籍「問題解決の全体観」より）。突然の傘だと前提を共有していない人には伝わらない。仮にマネージャー会議に持って行った場合には理解がされないのでなかなか承認が取れない。結局今回は、予算がプロダクト部の中で収まることがわかったのでマネージャー会議では追認のみで問題なかったが、仮に全社予算を使うようなプランだと特に大事。
終わりに
大規模カンファレンスだったら交通費・宿泊費出るので、地方のカンファレンスにもメンバーがお邪魔することがあると思います。一緒にカンファレンス盛り上げていきましょう！