マネーフォワードのプロポーザルが2倍なるまでの足跡 〜あるいは苦難の道を歩む方法〜
この記事は、Money Forward Engineering 2 Advent Calendar 2022の22日目の投稿です。
21日目は ちーずさんの「ぼくたちがかんがえたさいきょうのStorybook 〜より高品質なコンポーネントを求めて〜」です。
ワールドカップ決勝が終わったと思ったらもう12月も終わってしまうんですね、心が追いついていなくて途方に暮れてる今日このごろ、皆さんどうお過ごしですか？
ぼくはアルゼンチンが優勝していまでも浮かれまくってます。
背景
この記事は「カンファレンスにプロポーザルを出してほしいけどアナウンスだけしても出してもらえない！」と嘆いていた過去の自分に当てたメッセージです。
発端は技術広報に就任した2021年のとあるメンバーの一言がきっかけです。
「カンファレンススポンサーの目標は露出することだから達成できましたよ」
みなさんがこの言葉をみたときにどのような感情を抱くでしょうか？
ぼくは当時とても申し訳ない発言をさせてしまったと感じていました。
当時のぼくはこの発言の前後で以下の課題を感じていました。
主軸となる、とある技術カンファレンスのプロポーザル提出数が0だった
事前準備が足りずカンファレンスでの存在感や魅力づけが十分に行えなかった
カンファレンスにお金を出すだけになってしまい、モヤモヤを感じていた
発言したメンバーはできる限りの協力をしてくれましたが、そのメンバーに上記のような発言をさせてしまったことを後悔しました。
それと同時に、このままではマネーフォワードが将来カンファレンスにスポンサードする意義が少ないと考え、スポンサードをやめてしまう可能性を生んでいるのではないか？と考えました。
本記事は当時の自分が悩んだり悔やんだり悪戦苦闘した結果、およそ1年ほどでプロポーザル提出数が1.5〜2倍に改善した活動の一端をお伝えしたいと思います。
この記事を読んだ組織のプロポーザル提出数、そして登壇数が増えると書いた価値があるので嬉しいです。
結論
いつも長文書き太郎なので、先に結論からお伝えするとプロポーザルを提出してもらうために必要なのは「きっかけ作り」と「外部からのフィードバック」です。
社内イベントできっかけを作り、そこに参加したメンバー同士でフィードバックし合うことでプロポーザルを出す仕組みづくりに成功しました。
結果、プロポーザルの提出数は平均して2倍、プロポーザル採択率はカンファレンスごとに異なるものの1.5〜2倍ほどに向上しました。
詳細についてはぼくの経験を時系列で追いかけて、お伝えしたいと思います。
なぜプロポーザルは提出されないか？
まず最初に考えたことは「なぜプロポーザルや登壇が少ないのか？」です。
登壇に関しては自分たちでコントロールできないものなので早々に検討対象から外し、「なぜプロポーザルは提出されないか？」にフォーカスして検討しました。
当時、ぼくもカンファレンスにプロポーザルを出したことがなかったため、自分自身をサンプルケースとしてふりかえりました。
その結果、以下の心理的ハードルがありそうだとわかりました。
どのようなテーマを話せばいいのかわからない
特別にすごい業務（OSS開発や最新技術の導入など）をしているわけではない
登壇に対する動機（モチベーション）がない
登壇に対するインセンティブがわからない
これ以外にも理由はあるかもしれませんが、ひとまず自分が出せる状況を作り、それでも駄目な場合はまた原因を調べて対応策を練ろうと考えました。
「プロポーザルを出す」をエンジニアリングする
「ブログやLTで話すようなテーマに関しては思いつくものの、カンファレンスに登壇して話す技術的に深い話がない。」
当時の自分はそう考えていました。
ところが期せずして悩みが生まれた半年後に登壇する機会を得ます。
それがGo Conference 2022 Springで登壇したMotto Go Forward Goを支える文化とコミュニティ 〜なぜ我々はコミュニティにコントリビュートするのか？〜のセッションでした。
当時考えていたことはこちらのブログにまとめています。
表舞台と裏舞台からみたGo Conference 2022 Spring
きっかけはKyoto.go #25 Go Conference CfP壁打ち会です。
このイベントは同じくKyoto.goの運営メンバーだった @yebis0942 とぼくで「どういったテーマで応募するといいか？」を相談する会でした。
その中で以下をおこない、結果プロポーザルの雛形を作るという体験を得ます。
CFP Descriptionを熟読する
過去に同じイベントに登壇しているセッションから傾向を把握する
「自分にしか話せない」ことはなにか？を考える
話そうとするテーマについてレビューをお願いする
レビュー結果を受けて「どこに重きを置くか」を明確にする
時系列で説明していきたいと思います。
まずGo Conference のプロポーザルの募集要項であるPapercallにあるCFP Descriptionを確認しました。
その中に「Selection Criteria」にプロポーザルに書かれてほしいことが、「Supplement」にプロポーザルに書かれてほしくないことが記載されていることを把握します。
特にぼくが重視したのはSelection Criteriaの次の一文です。
5. Impact: The goal of the talk. What new idea, technique, tool, or information will the audience leave your presentation with?
「参加した人になにを伝えたいのか？」
この一文でそれまで「自分が話せるテーマ」から答えを探そうとしていたのが「参加者に自分にしか伝えられない価値はなにか？」に思考がチェンジします。
特別を話すのではなく、自分が話すことが特別になる
当時をふりかえると「自分が話せるテーマ」からプロポーザルを捻り出そうとしていましたが、この行為は自分にはとても難しいものでした。
普段の業務で特別なことをしているわけではないので、セッションで話すようなカンファレンスに参加するエンジニアに持って返ってもらえるようなテーマは思いつけませんでした。
自分だけが伝えられる価値はなにか？と再考したときに、「Kyoto.go、Kyoto.rb、Go Conference と3つのコミュニティ運営者の自分だからこそ、改めてコミュニティの価値を再定義する、問いかけるようなテーマを話せるのではないか？」と気づけました。
当時はまだコロナ禍で、活動を休止したり中にはコミュニティ活動そのものが持続できなくなり廃止される、あるいはオンラインに移行したことでローカルコミュニティである必要性を見失っているように感じていました。
そこでローカルコミュニティを運営し、オンラインながらKyotoというワードを重視している自分だからこそ伝えられることがあるのではないか？と考え、プロポーザルの骨子を考えました。
セッションを通して解決したい課題と目的が明確になったことで初めて「これならプロポーザルを出せそうだ」と考えることができました。
話せそうなテーマが見えたので yebis0942 さんと話しながら以下のことを確認しました。
Go Conferenceにはあまりコミュニティに関するセッションはないこと
GopherCon 2020ではダイバーシティに関するセッションがあること
国内の大規模カンファレンスでもコミュニティに関するセッションがあること
余談ですが、A Rainbow of Gophers: Building A More Diverse Community はこれからを生きる我々にとても有意義なセッションだと感じました（個人的感想）。
（閑話休題）
これらを踏まえ、コロナ禍でも活動し続けたKyoto.goの取り組みを紹介し、オンラインに移行しつつあるローカルコミュニティの価値を再度問うことに一定の需要と価値があることを確認します。
このイベントでは核となるテーマと骨子までしか話せませんでしたが、後日「こういったテーマの登壇をしようと考えているがアウトラインのレビューをしてもらえないか？」と登壇経験がある同僚に相談し、フィードバックをもらいました。
その際、返ってきたレビューでは「なぜ他のコミュニティではできないのか？」「Kyoto.goである必然性はどこにあるか？」とフィードバックをもらい、全体のテーマの軸は変えずにもらったフィードバックを反映したアウトラインに変更、肉付けしていく作業をおこないました。
そして提出し、採択されたものが先程の登壇セッションです。
登壇に対する動機（モチベーション）がない
過去の自分には積極的に登壇するモチベーションがありませんでした。せいぜいが「機会があれば（いつか、あるいはそのうちに）登壇してみたい」くらいの温度感です。
これは特別な人が登壇をするという思い込み以外にも、採用に関わらないポジションだったことが大きく影響しているのではないか？と推測しています。
ぼくが所属するマネーフォワード京都・大阪開発拠点では多くの場合、エンジニア採用を人事の方に任せっきりにするのではなく、自分たちも採用活動を行っています。
採用候補者にスカウトメールを送るのもエンジニアがやりますし、カジュアル面談や面接などもエンジニアが普段の開発の合間を縫っておこないます。
おそらく、最近のソフトウェアエンジニア業界であれば、特に目新しい要素はないと思います。
これがどうつながるのか？というと登壇というのは採用候補潜在層に対してとても効果的なアプローチであるということです。
どういう人がどんな思いで開発しているのか、その技術力や思想はどうか？などはなかなかテキストでは表現しきれない温度感や空気感を伝えることができます。
イベントやカンファレンスでの登壇はテキストで行えない魅力付けを補助し、採用候補潜在層に対して強力なメッセージを送ることができます。
個人的にはテンプレのようなスカウトメールを1000通送るよりも、1000人がいる場で20〜40分話すほうが圧倒的にコストパフォーマンスがよいと考えています。
ぼくが登壇する場合、エンジニア採用のためだけではありませんが採用や認知度向上が動機の一部を担っています。
登壇に対するインセンティブがわからない
普段の業務でも大変なのに登壇なんて…と思う方も多いのではないかと思います。
少なくともぼく自身はそう考えていましたし、いまでもそう考えることはあります。
ではなぜ大変だと思うのに登壇をするのでしょうか？
これには2つの思いがあります。
1つ目は「個人としてのブランディングが高まる」から。
2つ目は「コミュニティに対する恩返しができる」から。
まずは1つ目の「個人としてのブランディングが高まる」について説明していきます。
マネーフォワードでは業務時間中にテックブログを書いてもいいと明言されています。
この活動は実はブログに限らず、登壇資料やOSSコントリビューション、コミュニティ活動なども含まれます。
無制限に活動できるわけではないので、上司の許諾は必要になりますが、ぼく自身も業務時間でGo Conference の運営作業を行ったり、Kyoto.rbなどのご当地ローカルコミュニティのイベントの対応などを使わせてもらうことがあります。
登壇というのは先程も述べたようにテキスト以上にインパクトを残します。
そのため、「○○に登壇したluccafort」という印象は○○について詳しい、あるいはコネクションがあるというブランディングを社内、社外の両方にもたらします。
結果、それらの積み重ねがいま技術広報として働くぼくのインセンティブになっています。
これらの効果は複利なので積み重ねていくことがなによりも効果的であると考えます。
ぼくが技術広報を選択したのはたまたまですが、エンジニアであってもこれらの恩恵はありますし、おそらくはエンジニアであることのほうが恩恵は大きいでしょう。
これによって会社に依存しない技術力、あるいは評価を得ることができます。
登壇に対する最大のインセンティブは社外でも通用する評価を得ることではないかと考えます。
2つ目ですが、これはシンプルでぼくはOSSやコミュニティに参加する様々な方のおかげでエンジニアを続けることができました。なのでその恩返しがしたいと考えていた…ということです。
プロポーザルを出す、あるいはカンファレンスに登壇するというのは言語コミュニティに直接的に恩返しをできる貴重な機会です。
いままでは「すごいことをやっているから登壇できる」と思い込んでいたので、プロポーザルを提出したことはありませんでしたが
「話してほしいと考えるのは採択する側の役目ですよ」 by tenntenn
と言われてから考えを変え、自分が伝えたいことがあればプロポーザルを提出するようになりました。
その結果、採択されないこともあります（KotlinFestやiOSDCは採択されませんでしたが結果このブログに昇華されています）が自分の中で「少なくともプロポーザルは出せた」と納得できる気持ちと「どうやれば採択されるテーマになるのか？」をふりかえる機会が生まれました。
これはエンジニアとしてのアウトカムの1つではないかと思います。
すごいから登壇するのではなく、登壇するからすごくなっていく…そんな実感を得られたのはとても新鮮でした。
4つの仮説と経験から気づいた2つの障壁
4つの仮説からプロポーザルにおいて最も高い障壁とは、プロポーザルの詳細を読むきっかけがないことだと気づきました。
プロポーザルを出したことがない過去の自分は募集要項である「プロポーザルを読んでいなかった」のです。当たり前ですがまずプロポーザルを読まなければ応募できるわけがありませんでした。
そして「自分だから話せること」に気づくためには周りからのフィードバックが足りていないことにも気づきました。
動機とインセンティブに関しては他人をコントロールすることができないため、優先順位を下げ、より自分の中で障壁として大きいと感じたこれら2つにフォーカスする意思決定をしました。
プロポーザルを阻む大きな障壁が「きっかけ作り」と「価値感のフィードバック」だとすると、なにから取り組むといいのでしょうか？
ぼくの場合はたまたま自分が主催するイベントがきっかけで気づくことができましたが再現性を高めるにはどうすればいいのでしょうか？
ぼくは「きっかけ」をイベント化してしまうのがコスパが高く効果的だと考えました。
なによりもこの手法は言語やフレームワークなど特定の技術に依存しません。
そこでカンファレンスのプロポーザル応募がある度に「プロポーザルを読んでネタを出す会」を社内でも社外でも開催しました。
イベントを開催する時間は30分 * 2回です。
1回目はプロポーザルを読んだり、過去の登壇セッションを確認し自分たちがどういったことが話せるかのアイディア出しをおこないます。
2回目は1回目で出たアイディアから聞いてみたいものに投票し、「なぜ投票したか？」「どういう情報があると嬉しいか？」を投票者に話してもらうようにしました。
この仕組み自体は以前マネーフォワード 京都開発拠点でマネーフォワード クラウド会計Plusの開発時におこなっていた、Retrospectiveのやり方を踏襲しました。
手法的にはLEAN COFFEEがイメージに近いのではないかと思います。
取り組みの結果
この取り組みをスポンサードするカンファレンスごとに行ったところ、およそプロポーザル提出数が2倍、プロポーザル採択率がおよそ1.5〜2倍に跳ね上がりました。
社内のネタ出し会を切っ掛けに応募したのですが
実際に応募したメンバーが登壇レポートを書いてくれていますがその中でもきっかけになったと書かれています。
会社によっては技術顧問の方がいると思いますので、プロポーザルの応募が開始したらすぐに予定をおさえてネタだし会を開催するといいでしょう。
技術顧問の方からおそらく「こういったテーマではどうか？」というような提案や「そのテーマには○○の価値があるので出してみましょう！」と背中を押してくれると思います。
まとめ
過去の苦い経験から小さな改善を行うことで、プロポーザル提出数が最大2倍にまで増やすことができました。
もちろん、一番たいへんだったのは当事者であり、登壇者であるエンジニア本人です。
ですが、最終的に登壇が終わったあとで「もうちょっとこうすればよかった！」や「次回は準備にもっと時間をかけていいものにしたい！」などポジティブな意見ばかりだったので成功といえるのかなと考えています。
弊社マネーフォワードではコントリビューション（貢献）を推奨しています。
それは組織である会社に対してもそうですが、会社で使っているOSSプロダクトやそれを支えるソフトウェアコミュニティにも貢献してほしいと考えています。
そして、貢献とは「ひと > もの > おかね」だと考えています。予算があれば、スポンサードでお金を出すのは非常に簡単です。
これは安易な道ですが、必ず課題が解決されるわけではありません。
我々が目指したいと考えているのは苦難の道であったとしても、課題を解決する道です。
結果、それらの貢献が巡り巡ってマネーフォワードのユーザーが困っているお金の課題を解決する、それが弊社が大事にするValueの1つである「UserFocus」につながると考えています。
マネーフォワードでは「お金 だけ を出すスポンサードはしたくない」と考えています。
個人的な課題からコミュニティでの活動を通じて課題の改善、そして実際にカンファレンスに登壇者が出ているというエンジニアと組織、そしてコミュニティへの三方良しな貢献につながりました。
この記事がきっかけでソフトウェアエンジニアの貢献の選択肢が広がってくれると嬉しいです。
【宣伝】
最後に宣伝です。
今回紹介したプロポーザルのテーマを出し合うイベントを来月開催します。
Kyoto.goはオンラインで開催しているのでもしご都合がつく方や具体的にどういうことをしてるのか知りたい方がいたらご参加してみてください。