冒頭の駄文
皆さんお久しぶりです、初めてのかたははじめまして。 3年ぶりに祇園祭が開催されたり、また感染者数が上がっていたりとなかなか難しい情勢ですが、蒸し暑さで体調を崩さないようお気をつけください。 ぼくは先日夏風邪を引きました……。
今日はマネーフォワードで月イチで開催しているEngineering All Handsという社内イベントの運営裏話をしようと思います。
基本的に運営メンバーが限られているのであまり知る機会がない事柄ですし、社内メンバーも意外と知ってる人はいないと思います。 社内に限定する意味合いもないので、公開ドキュメントとしてエンジニアブログで現状のログとサマリーを残しておこうと思います。 この記事が、これから社内イベントを企画する、あるいはしているがうまくいっていないと感じられている方の参考になると嬉しいです。
余談ですが、技術広報は夏から秋にかけてカンファレンスの準備や企画で大変忙しい繁忙期にあたります。 自分で設定した「四半期に1回記事を投稿する」ノルマを早めに達成しておきたい…みたいな思惑があったりなかったりします。
この記事はエンジニアリング戦略室 エンジニアエンゲージメントグループ 技術広報の @luccafort の提供でお送りします。 それではいつもどおり長文ですが、旅のお供にどうぞ。
序
マネーフォワードでは2022年3月からEngineering All Handsという社内イベントを月次で開催しています。 それ以前にも社内イベントは開催されていたようなのですが、複合的な理由とコロナ禍によってイベント開催がある時期を境にプツリと途絶えてしまいます。
[余談]: Engineering All Hands以前の様子
Engineering All Hands以前に開催していたイベント名は エンジニア総会 です。 割としっかり運営されていたのですが、ある時を境にピタリと開催が止まってしまいます。
※1 MR: Merged Requestの意。当時はGitHubではなく、GitLabを全社として使っていたようです。
理由については、ぼくが入社前だったこともあり、又聞きでしかないですが、以下のようなことが起因しているようです。 全容を把握しているメンバーが退職していることもあり、多分に憶測が含まれているという大前提でお聞きください。
- 元々はボトムアップでの知見共有の場づくりとして始まった。
- 組織が拡大していくタイミングで「ゆるく知見を共有する場」から「組織として横串の活動を強化する場」に性質が変化し始めた。
- 規模が拡大する毎にカジュアルさが失われ、しかし運営コストは肥大化していった。
- イベント参加に対する義務感が増す一方で、運営コストは上がり続けるが参加者の満足度は下がるという現象が発生する。
- 運営コストの肥大化と参加者の満足度の低下が分水嶺を超えてしまい、開催されなくなる。
そして、その流れのまま、コロナ禍に突入したこともあり実質的な廃止状態になってしまった…ということのようです。
以下は当時（コロナ禍前）開催されていたエンジニア総会の懇親会のドキュメントから拝借した図。 （また感染者が増えてきたので難しいと思いますが、オフラインイベントが恋しいです……）
脇道にそれますが、総会という言葉の持つ印象と今後エンジニア組織が英語化するとKaigiや総会といったワードを使うのは避けたほうがいいだろう、ということで現在はEngineering All Handsになっています。 名称決定に関してはメルカリさん、メルペイさんを大いに参考にさせていただきました、ありがとうございます。 社内イベント名には組織の色や背景が出やすいので各社の名称を調べてみると面白いかもしれません。
- メルカリのエンジニア全員が集まるEngineering All Hands(定例会議)の立ち上げと改善
- メルペイの社内エンジニア向け All Hands（ Engineer All Hands ）の運営 Tips
個人的にも、マネーフォワードのエンジニア組織の母体が日々拡大・拡張していることもあり、「隣のチームはわかっても隣の隣はわからない」という課題感を持っていました。 マネーフォワードでは「スモールチーム」「権限移譲」を強く推し進めてきました。
プロダクトにとってこれらが最適解である一方、他のチームと設計思想や技術スタック、細かいところだとPull Requestのお作法が違うなどの社内コミュニケーションを行う際の軋轢を生むこともありました。 この課題に対して、なにかしら対応をしたいとは考えていたのですが、当時はまだ技術広報ではなく1エンジニアだったこともあり、「なんとなくやったほうがいいのではないか？」から抜け出せませんでした。
その後、ぼくが技術広報として就任し社内外の情報発信に関するアレコレに携わるようになります。 そうした活動を通してメンバーから「組織横断のエンジニア向け社内イベントを開催したい」という要望がちらほら上がり始めます。 ところがこの要望はいくつかの理由から保留にさせてもらっていました。
- オンラインでのイベント開催イメージが持てないこと
- イベント開催でなにを達成するかが不明瞭であること
- 運営リソースが足りないこと
- 継続的な運営体制を構築する時間がないこと
やりたい気持ちはありつつも、「マネーフォワードのエンジニアにとって価値があるイベント」の定義ができないと不満が続出して、すぐに運営が立ち行かなくなることが想定されました。 気軽にやってみよう！とするには巻き込むエンジニアの数と累計時間、費用対効果を考慮する必要があります。
片手間では運営するのはなかなか難しいことが予め見えていましたし、当時技術広報になり立てだったこともあり難しさを感じていました。 そこで、すでに社内イベントで先行事例となっているCDO（Chief Design Officer）のセルジオさんにヒアリングをさせてもらうなどをした結果、「必要になるまでイベントの企画・運営を考えない」という意思決定をおこないました。 これは過去に読んだ イシューからはじめよ ― 知的生産の「シンプルな本質」に書かれていた次の一文が大きく影響しています。
過去にCTO中出から「どうですか？」という形で提案されますが、このときは「まだ手元に情報がないので、そのときではない」と一旦断っています。
※2 TEG: CTO室テクニカルエンハンスメントグループのこと。エンジニアリング戦略室の前身となったグループの省略名。 ※3 DevRel室: 現エンジニアリング戦略室のこと。当時は名前がまだなくDevRel室という仮名を使っていた。
エンジニアには馴染みのあるYAGNI原則を採用し、ハレーションが起こる直前まで保留することで時間的な猶予を確保しました。 これはいま考えてもよい判断だったと思います。 仮に「いまどうしてもやらなければいけないんだ！」という熱意のある方が現れたら、そのメンバーを巻き込んで体制つくりをすればいいと考えていました。
その間にも、マネーフォワードのエンジニア組織は拡大し続け、ついにそろそろ着手しないとマズいねという雰囲気が漂い始めます。 問題はいつもぼくらが楽観視した予想よりも圧倒的に早くやってきますね…とても困る。
破
そんな感じでやりたい気持ちはあるが……ぐぬぬ！という感じで前に進まない日々を過ごしていましたが、ある日ゲームチェンジャーが登場します。 そのゲームチェンジャーの名前はっ！！！……VPoEにして現在ぼくの上司でもある高井です。
高井が入社した経緯は公式noteからインタビュー記事が出ているので、「どんな人なんだろう？」と思われたかたはどうぞ。
より魅力的なエンジニアチームへ ～マネーフォワードが目指すユニークな組織づくり～
当時の技術広報が感じる課題として「手は打っているが単体の戦術レベルでしかない。より大きく周りを巻き込むためには戦略レベルが必要になる。」がありました。
そこで、高井が入ってすぐに「我々が目指すべき目的・目標はなにか？」という話をしました。 特別なことはしておらず、ビジネスフレームワークとしてよく使われる「To-Be/As-Is分析」のフレームワークを使って、技術広報としての理想と現実、それに対するギャップ、そしてどうすればギャップを解消することができるのか？を話し合いました。
このとき話し合った内容だけでブログが1記事出来上がってしまうので、詳細はここでは割愛します。 気になるかたはマネーフォワードの社内ドキュメントツール内にあるので ぜひご入社ください。
閑話休題。 ともあれ、議論の結果、「エンジニア組織全体でチームや所属に関わらず技術情報が活発に交換され、土台となる技術・知識は共有財産として育てつつ、自分たちの強みを更に活かせるようなコミュニケーションが加速している組織が理想だ」と結論付けました。
この時点で技術広報は「広報という名前を冠しているが、社外への情報発信は手段の1つだ」とわかりました。 より重要なことは「社内の組織コミュニケーションが活性化された結果、社内・社外を問わず情報発信が加速している状態である」と定義します。
[余談]: 技術広報はDevRelやDeveloper Advocateとなにが違うのか？
自身の役職名である技術広報を名乗るとよく「最近話題のDevRel、もしくはDeveloper Advocateのようなものですか？」とご質問いただくことがあります。
技術広報の役割は各社で異なっており、技術広報はこれです！と明確に答えづらいのですが、技術広報はDeRelなどの役割の内、社内への働きかけに特化した役職だと考えています。 DevRelやDeveloper Advocateは社内向けの流れと社外向けの流れ、双方を持つ存在ですが、技術広報はそのうちの1つのみを責務としより特化した形になると考えています。
この定義はあくまでも、 マネーフォワード内での定義であるという前提 がありますが、元々広報や採用、マーケティングやブランディングなど幅広い領域を越境することが求められる性質があるため、名前を正しく定義することは難しいと思います。 組織にとって最適な名前がついていればいいと思います。
個人的意見ですが、マネーフォワードにおける技術広報の役職名はDeveloper Successのほうが実態を表していると考えています。 理由の多くはSales SuccessやCustomer Successと同じく、スタンスやおこなっている業務が能動的である必要があり、目指すべき最終目標が「開発者にとっての成功を促す、成功体験を積み上げる」ことに起因します。
この公衆（パブリック）に対して情報・意見を双方向に伝え受け入れながら、望ましい関係（リレーションズ）を構築し維持することがパブリック・リレーションズである[2]。
Wikipedia パブリック・リレーションズより引用。
技術広報として社外へのゆるやかな双方向のコミュニケーションは行っているが積極的には行っていません。 将来的におこなうかもしれませんが、現状は不要、あるいは出来ないと考え、DevRelやDeveloper Advocateのような役割ではないと結論づけました。
技術広報としてそう考えた理由は「自社のAPIを使ってもらい、そこで得たフィードバックを開発チームに還元する」というDevRelの大きな責務や働きをする目的がないためです。
遠くない将来に、そういったポジションが生まれると想定していますが、いま現在の対象は「社外から社内」の流れではなく、「社内から社外」の流れだと考えたため、仮名であったDevRel室はこの時点で消え、エンジニアリング戦略室が適切であると考えました。 このあたりは全てぼくが考えたわけではありませんが、考えていたことの内いくつかは共通していると思います。 プログラミングでも名前をつけるのはとても重要なので、実態を表す言葉を使うようにしています。
さて、これで技術広報のギャップが明らかになりました。 このギャップに対して3つの施策が考えられ、その施策の1つ「チームから社内、社内からチームへのノウハウ・ノウフーの流通を促進する場作り」を満たす案として「エンジニア組織を横断する社内イベントの企画・運営」案が上がります。
[余談]: 伝えておしまいではなく、浸透するまで愚直に繰り返す。
この施策のタイトルはEngineering All Handsで使用する運営スライドに必ず明記しています。 目的というものは「作ったらおしまい」とはなりません。 メンバーやチーム全体に伝わる、浸透するまでがやり抜くことが重要です。
正直くどいとは思いますが、こういった地道な説明の効果は馬鹿にできないので、毎回イベントの冒頭で口頭と文字でお伝えしています。
このとき出た話題として以下のような意思決定をおこない、このイベントの企画・運営方針の骨子が定まりました。
- 運営チームのコストを極力減らし、継続可能な運営体制とコンテンツを提供すること。
- イベントの型が定まるまでは運営がコンテンツ管理を行う。
- 全てのマネーフォワードに関係するメンバーが参加し、楽しみ、有意義だと感じてもらえること。
- 場を作るだけでなく、場を使ってもらう企画・運営をおこなう。
- 目的・目標に対する指標を立て、下限を下回ったらテコ入れをおこなう。それまでは雑事を気にしすぎない。
骨子ができあがったので、このあとは実際にどういうコンテンツにしていくかを話し合うのですが、このあたりはあまり参考になるような情報はありません。 愚直に話し合いを重ねて、「これがベストではないか？」というところにコンテンツ設計を落とし込んでいきました。
イベントをどう設計したか？
マネーフォワードのEngineering All Handsはオンラインで開催しています。 これはぼく自身が京都在住であるな点も無関係ではありませんが、以下のようなメリットがあると考えて選択しています。
- 会場確保やスケジュール調整などのロジスティック周りの仕事がない。
- 録画の収録コストがオフライン開催により簡単。
- 参加ハードルのコストが低い。
- 業務時間中に気軽にスケジュールを設定しやすい。
- 開発拠点所属メンバーが参加しやすい。
この中でも特にメリットだと考えているのが「時間」と「場所」に関わるものです。 ロジスティック周り会場確保のスケジュール調整や後片付けはどうしても大変になる傾向がありますし、エンジニアのかたに原則参加をお願いしている関係上、業務時間中におこなう必要があります。
その点、オンラインだと自宅でラジオ代わりにBGMとして聞きながらコーディングをしたり、緊急対応などの差し込みの予定が入ってきたときも抜けやすいというメリットがあります。 どう楽しむかの選択権を参加者側に委ねられるというのは大きなメリットです。
運営としてはもっと真剣に向き合ってほしい！という思いがなくはないですが、多くの場合それは運営側のエゴでしょう。 それよりは真剣に向き合ってくれるようなコンテンツをどうすれば作り上げられるか？という方向で悩むのが健全です。
反面、いいことだらけとはいきません。オンラインならではの課題も当然あります。 どうしてもオンラインという性質上「参加してる感」や「お祭り感」を感じにくいイベント設計になってしまいます。 Q&Aをおこなう、質問を拾うなど参加感を高める選択肢は無数にありますが、限られた時間の中で何を捨てて何を拾うかはいまなお苦慮しているのが現実です。 いまはまだよい対応策は考えられていませんが、今後も毎回イベント後に回収しているフィードバックを元に改善していくうちにマネーフォワードに最適な解決策が見つかるだろうと考えています。
重要なのは「参加しているエンジニアが楽しめることと運営チームの運営コストのバランスがちょうど釣り合う」ということです。 どちらかに偏らないことが肝要なので、そのために創意工夫を重ねていきたいと思います。
[余談]: フィードバックされたコメントの一例紹介
フィードバックされたものの中から一例を紹介します。 ポジティブ・ネガティブ双方のコメントをしてもらえており、個人的に凹むこともありますがそれはそれで貴重な意見、考えだと感じているのでありがたく全て目を通し、イベントの改善につなげていきたいと考えています。
知っている内容が多く、参加する価値を感じなかった
かなり手痛いコメントですが、これは企画・運営当初から出てくると予想していました。 正直この意見は大変ありがたいと思っていて、自分たちのクオリティコントロールが不足、あるいは見当違いな方向にあると気づかせてくれます。 正直、こういったメッセージをみると凹みます。凹むんですが「どういった内容だとナレッジとして価値があると感じてもらえるか？」や「どういうコンテンツのテーマだと技術トークを楽しんでもらえるか？」「運営としてどういった演出、設計をするとよいか？」などをふりかえる良い機会になっています。
コンテンツのテーマを伏せた意味がわからない。
これは第2回か3回のときに「次回のコンテンツは…内緒です！」としていたことに対するフィードバックになります。 コンテンツのテーマが事前にわかってしまうと「既知の内容だと思い、参加するメンバーが減少するのではないか？」という仮説を立てました。 テーマが事前にわからないことによるデメリットはないと考えていましたが、隠された！と思われてしまった…という失敗談です。 これ以降はコンテンツテーマと登壇者は必ず公開しています。
非日本語話者に向け、同時通訳をしてほしい。日本語話者以外にも配慮してほしい
当初、同時通訳をおこなうコストが高いと考えていました。 これは同時通訳するかたのコストもそうですが、登壇者のかたに事前に資料を共有してもらう必要があることから当初コストが高すぎるとして行っていませんでした。
最低限の対応として、スライドは必ず「英語、もしくは日英併記であること」というレギュレーションを設けさせてもらい、徐々に非日本語話者への対応を進めていく想定でした。 ところが、社内に非日本語話者をサポートするチームが発足、そちらのチームから「イベントの翻訳・通訳サポートします！」と打診いただけたことで想定よりも半年以上前倒しで同時通訳の体制が整うことになりました。
まだまだ対応が不完全なところはあるのですが、徐々に改善されていると考えています。 今後に期待をしてもらえればと考えています。
その他、開催頻度や開催時間に関する問い合わせ
マネーフォワードには多種多様なエンジニアの方がいます。 また開発拠点も日本国内だけでなく、ベトナムのハノイ・ホーチミンにもあります。 そうするとどうやっても開催時間の調整がうまくできないチームが発生したり、開催頻度が高すぎるといったコメントをいただくことがあります。
現状、時間に関する問題はベストが見つけられていないのですが、運営として以下のように考えています。
- 月の労働時間が160時間（20日 x 8時間換算）の内、1/160時間なので許容範囲と考えていること。
- イベントの目的は「ノウハウ・ノウフーの流通を促進すること」なので45分では話しきれず、90分ではダレてしまう…間の1時間がキリもよくトータルバランスがいいと考えていること。
- 時間帯に関してはどこに移動させても不平不満がでる、14時〜15時のお昼休み明けで集中力が低下しやすい時間帯に脳の負荷を高めないイベントを差し込むのがバランスよいと考えていること。
- 四半期ではリードタイムが長いため、コンテンツのクオリティーの高さを求めてしまう。月次くらい定期的な方が意識が薄れず開催時期を忘れにくいと考えていること。
急
そして、組織・チーム発足からおよそ半年が経過しました。 初回の開催が3月だったのでおよそ4ヶ月ほどイベントの企画・運営を経験したことになります。 なにもない0からスタートしたEngineering All Handsもそれなりに回数を重ねたことで「こういう運営体制にするとよい」というものが徐々に見え始めてきました。
まずイベント企画・運営は準備がそのイベントの質を決めます、ですがリソースは有限なためできるだけ高効率で企画・運営を回せる体制づくりが重要になってきます。 社内イベントでは社外イベントと異なり、費用対効果をしっかりと見極めながら、試行錯誤をすることがとても大きな要因になります。
そこで、運営するにあたり、必ず用意しているものを軽く紹介させていただきます。
- 運営スライド
- フィードバックのアンケートフォーム
- トークスクリプト
- オンライン会場
の4つです。
細かな点を上げると他にもありますが、最悪他のドキュメントなどはなくても運営が可能だと考えているため今回割愛しました。 WBSなどもあるに越したことはないのですが、イベント企画をおこない何度か開催し、イベントの型が定まってからでもいいと思い対象からは除外しました。
なお、これらのドキュメントは社内のメンバーであれば誰でも閲覧が可能になっています。 これは持続可能なイベント企画・運営の一環として「できるだけパブリックかつオープンな場に誰でもアクセスできることでイベントの形態を真似したり、改良することができる」ことを念頭においています。 将来的にぼくがマネーフォワードを去っても、イベントが休止されることのないように運営が使用しているドキュメントはほぼ全て公開、アクセス可能な状態にしています。
また、単純にアクセスできるだけだと引き継ぎ作業が発生するため、イベントレポートを用意しこれらのドキュメントのリンクをまとめています。 後任者はこのイベントレポートだけ知っていればいい状態を目指し、メンテナンスしています。
これらの取り組みを地道に継続して活動した結果か、最近イベント運営にとって大きな変化が訪れました。
それは「社内にナレッジを共有したいのでEngineering All Handsの時間を使わせてほしい」という依頼です。 これは当初から一つの結果として期待していったものの1つ「場を作るだけでなく、場を使ってもらう企画・運営をおこなう。」であり、マネーフォワードのEngineering All Handsというイベントがどういうスタンスのイベントか？が浸透し始めた結果だと考えています。
依頼を受けたのはまだ3回なのですが、今後より増えていくのではないかと考えています。 自分たちで作り上げる場として、取り組んできた場作りの成果が出始めたのではないかと考えています。
依頼したひとの中には「こういった登壇は初めてです」という方もいたので、そういう方には「ネタの壁打ちから付き合えます！」と一声かけ、実際に壁打ちしたことで「どういうコンテンツを作成すればいいか？」のお手伝いできたのではないかと思います。 技術広報が最も大事にすべきことは「お願い」ではなく「一緒に並走する」ことではないかと思います、並走できないときはそもそも走らない、といった意思決定も重要になると思います。
[余談]: Engineering All Handsの運営体制
Engineering All Handsの運営体制ですが、以下の構成メンバーによって運営されています。
- アドバイザー: 高井
- 司会・運営: ぼく
- 運営サポート
- エンジニア: 1名
- People Forward本部: 1名
- 登壇者: エンジニア2名
アドバイザーは上司の高井にお願いしています。 イベントの方向性がブレていないか？ぼくが迷っている・悩んでいることの壁打ちやイベントのふりかえりに参加してもらうというコンサルティング的な立ち位置で助けてもらっています。 ぼく自身がかなりフィードバックコメントを真正面から受け止めてしまったり、杞憂な事柄に脳内リソースを使ってしまうことが多々あるのでそういったときの方向修正してもらっています。
2回目くらいまではほぼぼくだけで運営してましたが、出来なくはないが何かの予定と重なるとかなりしんどいということがわかり、まずPeople Forward本部のメンバーに助けてもらえないかを相談にいきました。 幸い、とても前のめりに「ぜひ協力したいです！」と言っていただき、月次でローテーションを組み新入社員紹介周りのタスクを巻き取っていただけました。 個人情報が絡むこと、連絡経路が複数あると新入社員の方が混乱することなどからお願いしましたがとても助かっています。
エンジニアの運営サポートは当日イベント中にスライドや自己紹介のURLの共有をしてもらうメンバーです。やることは複雑でも難しいことでもないんですが、当日ぼくが司会をする関係上、できるだけ脳内リソースを圧迫しない形で運営をしたいと考えお願いをしています。 これによって司会進行をしながら考えることが大幅に減らすことに成功しました。 工夫した、というわけではありませんがやってもらうことを社内ドキュメントにまとめて誰でもできるようにしたのは割と良かったと思います。 繰り返し行われることなので再現性を高めたり、属人性を排除することで、効率を高めていけるのではないかと期待しています。
登壇者は毎回運営チームでふりかえりをして翌月、「どんなテーマだとマネーフォワード全体にプラスになるナレッジになるだろうか？どのような技術だとチーム内に持ち帰ってコミュニケーションする材料になるだろうか？」という観点でテーマを決めています。
いくつか代表例を紹介すると…
ナレッジ共有（知見共有パート）では「採用活動」や「Technical Program Manager（TPM）」が反響が大きく、テックトーク（技術パート）では「UX設計」や「Enabling SRE」、「ポストモーテム」あたりのウケが良かった印象です。
最後に司会と主な運営をしているぼくです。 最もタスク量が多いんですが運営と司会でそれぞれ分けてみました。
- 運営
- イベントレポートの作成
- 通訳・翻訳チームに仕事の依頼
- 開催告知とリマインド
- フィードバックのアンケートフォーム作成
- 配信設定
- 次回開催の各テーマ決め
- 登壇候補者の打診
- 登壇者アサイン
- 司会
- トークスクリプトの作成
- 運営スライドの作成
- 当日司会
ざっくり書き出してみましたが、まあまあやることが多そうにみえます。1つ1つのタスクはそれほど難しかったり時間がかかるものではありませんが、多岐に渡るのが少し面倒だなと感じています。 いくつかのタスクに関しては自動化できると考えているので、今後は自動化して時間を捻出していくつもりです。
まとめ
まだまだ課題や問題は山積みですが、社内イベントは「弾み車」のようなもので試行回数と改善を積み重ねることで、より大きなパワーを生み出すことができます。 目的を最初に定義したことで、イベント企画・運営がブレずにおこなえました。 （弾み車ってなんですか？というかたはビジョナリー・カンパニー 弾み車の法則をご覧ください、100ページほどなのでスラスラ読めます。）
イベント運営に必要なスキルは開発現場においても必要なスキルだと感じています。 技術広報というエンジニアでもなく、広報でもない不思議な役職についた当初は「エンジニアとしてもう戻れないのではないか？」と不安に思っていました。
ところが、実際やってみると誰よりも社内ドキュメントを読んだり、専門外の知識をインプットする必要があり、ある日突然これまでのプログラミング能力が0になるわけではないことに気づきます。
そう考えるようになってからは、さほど気にならなくなりました。 必要なら社内のプロダクトコードを見て回って辻PRを出したり、OSSにコミットすればいいので杞憂だったと感じています。
そして、技術広報の活動はいわゆるプロダクトオーナーに近いのではないかと考えています。 役割の中にマネジメントやリーダーシップといったものも含んでいますが、基本的には
- 理想と現実からギャップを見出し
- ギャップに対して最適かつ最良の仮説を立て
- MVPを実装しながら
- 日々の活動を経過測量し改善を重ね
- 目的・目標に近づけること
ではないかと考えます。
そのために技術広報は周りのエンジニアやチーム、組織を巻き込んで大きな動きを作る必要が生まれ、結果マネジメントスキルやリーダーシップ、コーチング・ティーチングなどの幅広いソフトスキルが必要になります。 ある意味では「組織というプロダクトを開発している」と言えると考えています、そう考えるとミニCTOといったほうが技術広報よりも適切かもしれません。
エンジニアもプロダクトオーナーも技術広報も基本的には「問題解決者」なので大きな方針転換をした！という感覚はありません。 ただいままでとは系統の違う書籍や学びが必要にはなったので、そこは最初苦労するポイントかもしれません。 すでにマネジメント職やリーダー職をされているかたは地続きで挑戦することができると思います。
技術広報が目指す最終的なゴールは、マネーフォワードの文化が「アウトプットすることが当たり前になり、社会にコントリビューションすることができる」になっていることです。 いまはまだ小さな第一歩を踏み出したところですが、今後この「弾み車」は加速度的にパワーを増していくことでしょう。
その時はまた新しい課題と向き合うことになると思いますが、まずは文化を作るために苦しくても楽しんで前に進んでいける、そんな再現性のある環境を作っていきたいと考えています。
最後に
マネーフォワードではチームや組織をもっと前へ進めるエンジニアを絶賛募集中です。 エンジニアに限らず、全方位全職種募集中ですので、ご興味あればぜひご応募ください。
「まずはお話から〜」というかたも大歓迎です。 沢山部署やチーム、ポジションがあるのでどれがいいかわからない！というかたはオープンポジションからご応募ください。
最後に、今回の記事でマネーフォワードの技術広報に興味を持った方がいたらMeetyもやってるのでざっくばらんにお話しましょう。 転職目的でなく、組織を良くしていくための壁打ち役としてお使いしてもらって大丈夫です。 組織のいいところをもっとForwardしたいかた、雑にお話しませんか？
それでは、また3ヶ月後にお会いしましょう。 ばーい！
マネーフォワードでは、エンジニアを募集しています。 ご応募お待ちしています。
【会社情報】 ■Wantedly ■株式会社マネーフォワード ■福岡開発拠点 ■関西開発拠点（大阪/京都）
【SNS】 ■マネーフォワード公式note ■Twitter - 【公式】マネーフォワード ■Twitter - Money Forward Developers ■connpass - マネーフォワード ■YouTube - Money Forward Developers
