Money Forward Developers Blog

株式会社マネーフォワード公式開発者向けブログです。技術や開発手法、イベント登壇などを発信します。サービスに関するご質問は、各サービス窓口までご連絡ください。

20230215130734

エンジニアのコミュニケーション課題をAWS GameDayで改善しろ！ 〜企画・運営編〜

TL;DR

この記事は「エンジニアのコミュニケーション課題をAWS GameDayで改善しろ！ 〜イベントレポート編〜」で宣言していた運営、企画編です。 下記記事とは視点を変えて社内企画として取り組んだAWS GameDayについてお伝えしようと思います。

moneyforward-dev.jp

この記事では社内イベントを通して、エンジニアにどのような価値を届けたいと考え、企画したかの裏側や思想、背景について記載をしています。 企画時点での課題や考え方であるため、歴史的遠近法により当時と現在で前提や背景が変わっている可能性があります、ご了承ください。 1 普段、知る機会が少ない社内イベントの裏側となるイベント設計と効果測定、そしてどのような活動がイベント開催までに必要であるかのご参考になればいいなと考えています。

本記事は以下の構成で社内企画を検討した流れを詳細に書いています。

  • 組織課題の整理、イベント目標の設定
  • イベントの効果測定方法、イベント開催にあたっての懸念事項
  • 全体ふりかえり、まとめ

本題に入る前に

交流が生まれるためには3つの前提が必要だと前回記事で紹介をしましたが、一応こちらでも再掲載しておきます。

  • 相手を知っていること
  • 相手が自分のことを理解していること
  • 相手と一定時間交流したことがあること（回数 * 時間）

今回の企画は「3つの前提条件を満たす機会創出」と「技術的な刺激をチームや部署に持ち帰ってもらう」の2つが目的です。 これらの目的をAWS GameDay（以降、GameDay）を通して提供したいと考えていました。

組織課題の整理、イベント目標の設定

なぜGameDayを開催したかは前回記事で書いたので割愛します。

イベントの効果測定と開催における懸念

今回のイベントの目標（重要度順）は次のようなものを考えていました。

  1. 組織横断の交流機会の創出
  2. チームビルディングを通した他者理解の促進
  3. 自身のスキルギャップの特定と自身のスキル特性の把握

イベントは開催することではなく、その後がより重要だと考えています。 イベントそのものは目標を達成するための手段の1つなので、次のような評価指標（KPI）とイベント後の施策を検討していました。

運営のKPI

参加者アンケートでは以下を満たすような設問を用意しようと考えました。 各項目は1から4の数値を指定してもらう形を取りました。1がネガティブ、4がポジティブになるように設計しています。 そのように設計した理由については後述します。

項目の設計

項目は大きく分けて3つです。

  • チーム外コミュニケーションが改善できそうか
  • 体験したことが実務で役立つか
  • 同僚やチームメンバーに勧めたいと思えるか

これらの項目は全て目標に到達することが可能であるか検証できるような設問として用意をしました。

評価基準の設計

各項目は1から4の数値を指定してもらう形を取りました、1がネガティブ、4がポジティブになるように設計しています。 アンケートでは設問を5段階ではなく、あえて4段階で評価するようにしています。 4段階評価にした理由は5段階評価では真ん中の3（どちらでもない、普通）に投票が集まりやすい傾向があるからです。 今回は今後のイベント開催の基準を作る試金石的な意味合いもあったので、良い悪いはっきりさせる4段階評価を採用しました。

参加者アンケートの結果

実際に参加者アンケートを回収した結果を一部抜粋し、紹介します。

全体満足度

全体の満足度です。結果としてはアンケート回答者の8割以上が満足する内容だったと感じてくれています。 企画者として満足してくれるイベントになっていると考えていましたが、それでも拭いきれなかった一抹の不安が杞憂に終わって一安心しました。

チーム外コミュニケーションが改善できそうか

今回は3（そう思う）、4（とてもそう思う）をあわせて97%を達成しました。 企画段階では3（そう思う）と4（とてもそう思う）をあわせて80%以上であることとしました。

今回は初めての企画なので参考数値もないため、参加者の80%が満足すればよいと考え、数値目標を設定しました。 結果から言えば、数値目標を大きく達成し、満足いく交流機会の創出ができました。 しかしながら、4（とてもそう思う）単体でみたときにおよそ70%ほどだったことを考えると、改善の余地がありそうです。

体験したことが実務で役立つか

80%以上が普段の業務に役立ちそうだと感じてくれており、おおむね高い評価をいただけました。 反面、今回のGameDayで出題した内容が普段の業務では使わない技術である方もいた可能性がアンケートから読み取れます。 こちらの数値目標は3（そう思う）と4（とてもそう思う）で70%で設定しましたが、前述の通り目標を大幅に上回る97%を達成することができました。

同僚やチームメンバーに勧めたいと思えるか

これは設問としては用意をしていませんでした。 意図的に用意しなかったというわけではなく、単純に漏れてしまった形です。反省🙇‍♂

ご意見ご感想の自由記入欄にて、他者へ推薦したい旨のコメントをいただいたので一部抜粋をして紹介します。

  • とても良い経験だったので次回も参加したい。もっといろいろなかたに参加してもらいたいイベントだった。
  • 普段触らないサービスを触る機会にもなり学びになった。インフラを普段触らない方々に対しても、障害時の対応方法や勘所を身につける良い教材だと思うので、定期的な開催してほしい

意図した通りの効果が生まれているコメントで一安心しました。 次回はちゃんと計測できるように設問を用意しておきます……。

運営のKPI 総括

一部ミスがありましたが、ほぼ全ての項目で当初目標とした数値を達成できました。 社内のエンジニアに新しい技術の刺激と交流の機会を創出できるよいイベントが、実施できたと自画自賛しています。🎉 イベント後に優勝チームの方に社内イベントでチーム戦略などを話してもらいましたが、とあるAWSサービスがとても重要な攻略の鍵を握っていたと話してもらいました。2

利用するサービスの話だけではなく、障害発生時のチーム体制や普段と異なるメンバーと組んだ場合のチーム戦略などチームビルディング的な面でも実務に活用できる要素を、楽しみながら学んでもらえたのではないかと思います。

運営からみたイベントの裏側

ここからはイベント企画者、運営者としてどういった点に苦慮していたのかをお話しします。

運営の不安

ここまではよいことばかりを書いていますが、うまくいかなかったことも当然ありました。 企画者として次のような不安や悩みを抱えながら企画、運営、実施を行いました。

  • そもそもどれくらいの人が興味を持ってくれるのか
    • 予算はどれだけあればいいのか
    • メンバーの増減で予算が急遽変動した場合どうすればいいか
  • メンバーの参加ハードルをどのように軽減するか
    • 不公平感や不満感を溜めてしまい、イベント開催することでメンバーの不満が溜まらないか
    • 運営がチーム編成をすることに強い反発がないか
    • 地方拠点のメンバーの参加コスト、家庭事情によるメンバーの参加難易度の差が不満の種にならないか

参加人数に対する不安

一番の悩みはやはり参加者の数です。 もし、参加者が必要十分な数が集まらなかった場合どうするか？というのが一番大きな不安でした。

今回社内のコミュニケーション活性化がイベント開催の目的だったため、他社と協力して開催する手段が取れませんでした。 そのため、必要十分な人数が集まらなかった場合、企画するまでに費やしたコストや相談を受けてくれたAWSの方々、そしてサポートしてくれたチームメンバーに迷惑をかけることになると思い、かなりヒヤヒヤしました。

また、全体の参加人数や地方開発拠点の参加者数によって予算が変動がするため、不確実性が高く応募者が一定数集まるまでかなり心配でした。 開催できそうだと確信できたときは胸をなでおろす思いでした。

参加ハードルの違い

二番目の懸念事項は参加ハードルの違いについてです。

マネーフォワードは東京の他に福岡、京都、大阪、名古屋に国内開発拠点が5箇所存在します。 それ以外にもベトナムのハノイとホーチミンの2拠点、インドにもメンバーがいます。

参加者を東京オフィス所属のみにした場合、金銭的な問題はほぼなくなりますが、イベント開催によって拠点ごとの機会の不平等さを運営が助長してしまうことになります。 かといって、国外メンバーを含めた参加条件にしてしまうと予算がかかりすぎてしまう可能性がありました。 この塩梅をどのように判断するかについて、当時とても頭を悩ませていました。

オンラインでも交流できるのではないか？という意見も当然あり、検討をしました。 しかし、目的と実現可能性のバランスを考慮し、参加者は以下の条件を満たす方のみと定義をしました。

  • 日本国内の開発拠点に在住するメンバーである
  • イベント開催時点で在職しているメンバー（見込みも含む）である

目的は「オフラインで濃密なコミュニケーションを生み出す」こと、そして実現可能性は初回の運営であるため、運営チームがコントロール可能な状態を優先したいことを考慮した結果、上記のような条件を設定することとなりました。3

「業務委託はメンバーに含まれるのか？」という質問もでましたが、「交通費は自己負担になってしまいますが、イベントを盛り上げてもらうためにも参加はOK」としました。 その他にも多少のゴタゴタはありましたが、事前に告知を行うことで大きなトラブルなく運営ができたのではないかと考えています。

社内オフラインイベントの課題

ぼくが30名を超える社内イベントを企画したのが初めてであること、オフラインで70名相当の社内イベントを企画するのが久しぶりであることなどさまざまな理由から勝手がわからずに困る事態がありました。

会場確保の困難さ

まずは会場確保の困難さです。 普段ぼくは京都開発拠点にいるので、東京オフィスの予約の取りにくさを正直甘く見積もっていました。 数ヶ月前に予約をしようと思ったら、まさかすでに予約されているとか思わなかったよね……。

幸い前日の同じ時間帯が空いていたので、会場予約を取り直しました。 自分ではかなり早めに動いたつもりでしたが、想定した以上の予約状況でした。 エンジニア以外の他職種もオフラインでイベント開催することが増えてきており、早めに会場を確保する重要性を肌で感じました。

開発機材の準備や整備の考慮漏れ

今回のイベントでは、貸会場や合宿といった形はとらず、東京オフィスのイベントスペースを使うことを考えていました。 そのため、元々設営されている電源設備だけでは足りないと思い、CIO室にお願いをして、電源タップを事前に一定数用意してもらいました。

ここまでは良かったのですが、実際にイベント開催してみると「もっと大型のディスプレイが欲しかった」や「ホワイトボードのようなものがほしかった」というフィードバックが出ました。 当初「執務エリアを使ってもよい」というレギュレーションを設定していたので、ディスプレイやホワイトボードは特別用意しなくても取りに行けるだろうと気軽に考えていましたが、想定できるものは全て事前に準備するくらいの気持ちが必要だなと痛感しました。

特に地方拠点からきているメンバーは初出張の方もおり、オフィスのどこになにがあるかわからず、気軽に自分たちで環境を整えることが難しく、配慮が足りていませんでした。

当日オペレーションの想定不備

イベント開催日当日、急遽やむを得ない事情（体調や家庭事情など）によりイベントに参加できない方が何名かいらっしゃいました。 欠席者が出るかもしれないとは思っていたのですが、発生した際のオペレーションとやらなければいけないことの想定が甘く、他の運営メンバーとあたふたしながらチーム編成やその他運営上の調整をしていました。 このあたりは事前にケアできる内容だったので完全に運営不備だったと反省しています。

また、開始15分前には集まってほしいと事前アナウンスしていたにも関わらず、開始時間になっても集まらない人が数名いました。 それ自体を責めるわけではないのですが、集まっていない場合のオペレーションを運営側で考えられておらず、司会進行の時間管理に影響が出てしまいました。

普段運営している社外向けのイベントでは多少集まりが悪くても、司会進行に問題ないことが多いのですが、今回は参加者全員に伝える注意事項や連絡事項があったため、事前に想定されるケースを見込んで動くべきでした。 こちらも反省事項ですね。

社内オフラインイベントの課題まとめ

その他にもチームの席を用意したのですが、「バラバラに座るよりもチームごとに固めたほうがいいのではないか？」と指摘され、急遽スライドなどに仮チーム名をテーブルに貼る、会場説明のスライドに仮チーム名を記載するなどの対応を行いました。

ですが、直前に決まったため「自分はXXチームだがどこに座ればいいか？」という問い合わせが発生したり、事前に告知できていなかったため、参加者の混乱を招いてしまいました。 また、参加者の名札を用意しなかったことで、会場からイベント開始までの時間に初対面同士のメンバーが気まずい感じになってしまうなど、工夫が足りない事態を生み出してしまいました。

ただ、「チームごとに席を決める」は結果として、とてもスムーズな進行につながったので素晴らしい提案でした。 指摘をしてくれた @achamixx に感謝。 名札は「社員証があるのでそれでいいかな」と思っていましたが、実際にはSlackのアイコンなどがなく、ひと目でわかりにくかったので、要改善だなと思いました。

他にも細々とした課題はありますが、オフラインだからこその課題から社内向けイベントだと問題になる課題などがあり、普段の社外向けイベントとは違った難しさやケースの考慮、運用フローの重要性を認識しました。

個人的には東京オフィスのゴミ捨て場がどこにあり、どうやって出せばいいかが分からず困りました。 実際の当日のオペレーションの練り込み具合が足りていないことがわかりますね。

疲れ切っていたあとに「そういえばどうやるんだっけ？」となってしまい、疲労が倍増したように感じました。 運営は終わったあと、会場から撤退するまでのフローをきちんと考えないといけないと改めて感じました。

イベントを開催したことでわかったこと、反省すべき点が数多く見つけられました。 反省はすべき点もありますが、次回はもっとうまく企画できそうだという自信につながりました。

コミュニケーション言語の壁

弊社は現在エンジニア組織の英語化を進めており、日本語が話せない英語話者が社内にいます。 そういった方も参加することを念頭においた工夫を行いました。

コミュニケーション言語が英語のみの方は、できるだけ英語が話せるメンバーや日本語話者だが英語も話せるメンバーをチームに組み込むなどの工夫を行いました。 また、イベント進行で使用するスライドは、できるだけ英語で記載を行うようにAWS様に対応をお願いしたり、開催までの事前アナウンスやイベント詳細も英語と日本語の2つを用意するようにしていました。 反面、運営メンバーが少なかったため、ベストエフォートでできる範囲の対応を心がけました。

改善のサイクルを回すために最も重要なことは「継続開催できること」です。 そのため、運営チームが疲弊して「もうやりたくない」とならないことが重要です。

できる範囲で頑張り、どうしても手が回らないところは他チームに翻訳をお願いしたり、英語が得意な日本語話者の参加者にサポートをお願いしたりするなどの対応を取りました

個人的に次回は当日のイベントアナウンスを英語で行い、英語話者もより楽しめる環境を提供したいと考えています。

全体ふりかえり、まとめ

全体のふりかえりです。 今回、初めてきちんと企画提案書を出し、1つのプロジェクトを進行することができました。 当然のように自分ひとりでは達成できず、多くの方にサポートしてもらったり、イベント2週間前にコロナに感染してしまったりと他の運営メンバーには迷惑をかけてしまいましたが、無事やり遂げことができよかったと感じています。

反面、次回はもう少しチームとしてプロジェクトを推進できる体制をきちんと作り上げ、できることを増やして満足度を高めたいと考えています。 総評は100点満点中70〜80点くらいではないかと自己採点しています。

改善すべき点はありますが、目的としたこと、目標設定として設定した項目が達成でき、ひとまず満足しています。 当初、社内ISUCONを想定していましたが、こちらを開催していた場合、実現可能性が低かったと言わざるを得ないと感じました。

自分たちだけでやりきれるといえないイベントを開催した場合、労力と期日の面で達成が困難だったことが想定され、満足度はより低くなったのではないかと思います。 仮に開催することができたとしても、きちんと楽しんでもらうイベント導線、そして楽しんだあとのイベント設計にまで落とし込むことは時間的にも労力的にも厳しかったでしょう。

AWS様のご協力の元、GameDayという仕組みを使わせていただけて本当に助かりました。 「楽しかったで終わってしまう」社内イベントでは今回の目的に沿わないため、GameDayを開催して良かったと考えています。

企画者としてはおおむね満足していますが、次の機会には以下のようなことに取り組んでみたいと考えています。

  • 参加者100名の大規模社内イベントにしたい
    • 参加人数で開催できるかどうかをもう心配したくないｗ
  • イベント終了後から表彰チーム発表までにチームのふりかえりタイムを用意したい
    • イベント後にも交流できる設計になっていなかった
  • イベントの実況中継を社内に配信したい
    • 参加できなかった人も楽しめるイベントにしたい
  • CTO/VPoEチームを作ってイベントを盛り上げたい
    • CTO/VPoEチームのすごさを実感してもらう機会を作りたい
    • CTO/VPoEチームをなぎ倒す凄腕エンジニアを知ってもらう機会を作りたい
    • 今回は運営のタスクがパツパツでお願いできるだけの余力がなかった
  • イベントアナウンスの英語化
    • 英語話者も楽しめるコンテンツに昇華させたい

次回開催はまだ未定ですが、秋はカンファレンスなどで大変なので夏頃に開催したいなと考えています。 また、次は企画をやりつつ、当日は参加者として参戦してみたいですね。

それとは別にISUCONのようなパフォーマンスチューニングの社内イベントやセールスやカスタマーサクセスなど他業種も巻き込んだハッカソンなども開催できるようになるといいんですが、まずはGameDayを安定運営できるようになるほうが先かなと考えています。 手放しで運営できるようになってから、これらのイベントの企画、運営に着手したいと思います。

なにかを作り上げてリリースするという体験はやはり特別なものがあります。 マネーフォワードでは50以上のサービスをリリースしています。

GameDayで体験したように様々なサービスがAPIで連携していく世界を構築するためにLet's make it together!してくれるエンジニアを絶賛募集中です。 よければカジュアル面談や選考のほうにお進みいただけると嬉しいです。

hrmos.co

……ということで「エンジニアのコミュニケーション課題をAWS GameDayで改善しろ！ 〜企画・運営編〜」を終わらせてもらおうと思います。 最後に宣伝です。

1月31日（水） 19時より「ソフトウェアデリバリー」をテーマにしたイベントを開催します。 会場は東京のマネーフォワード本社で開催予定です。 Findy Team+ Awardを受賞した弊社とグループ会社の方に来ていただき、登壇いただく予定です。 イベントでは懇親会も予定していますので、オフィスを見学するつもりで遊びに来ていただければと思います。

当日は司会進行でぼくも京都から東京に出張している予定です。 こちらのブログを読まれた方はぜひ懇親会でお声がけいただければと思います。

moneyforward.connpass.com

イベントを企画するにあたり参考にしたブログや記事

余談という名の雑記

ここから先は余談という名のボツになったコンテンツです。 それなりの文章量があるので、単純にボツにするのがもったいなかったので余談として供養しています。

Know How だけでなく Know Who を流通させる仕組みを作る

「コミュニケーション」という言葉が持つ範囲はあまりにも大きく、広いです。 そのためなのか、以下のような状況を目にすることがあります。4

  • お互いの前提となるコンテキストがズレているため、議論が平行線を辿っている状態
  • コミュニケーションの不足から双方の理解度にズレが発生してしまっている状態

ぼくはマネーフォワードに入社するまで30〜50名ほどの中小企業や零細のスタートアップで働くことが多く、このような課題にあまり遭遇したことがありませんでした。 ではなぜ小さな組織では起こらなかったことが、大きな組織で起こるのでしょうか？

これは以下のような条件があったのではないかと推測します。

  • チームや組織が小さく見通しがよかった
  • 30人程度の組織の場合、問題が発生した場合の責任のとり方や相談先が明確である
  • 組織 ≒ チームなのでメンバーの人となりをだいたい把握できている

鍵は「相手を知っている、自分が知られている」というコミュニケーションの根幹の情報が足りないからではないかと考えました。 過去に弊社社内で話題になったSmartHRさんの以下の記事でも同様の課題があったことがわかります。

blog.shojimiyata.com

相手のことを知っている場合と知らない場合では会話をするにせよ、テキストでチャットを送るにせよ心理的ハードルは異なります。 一般的には知らない場合のほうがハードルは高く感じるでしょう。

この状況は相手が何に対して不快と感じるかわからない、相手がなにを楽しむのかわからないという相手の理解度に対する不透明性が起因していると考えています。 コミュニケーション相手の情報量と相手が持つ自分の情報量が増えるほどに不確実性は減少します。

ですが、「相手のことをもっと理解しましょう！」といっても必然性がなければ、相手に興味を持つことは難しいでしょう。 ではどういったときにチーム間を飛び越えて相手のことを深く知ろうというアクションが生まれるのでしょうか？

そう考えたとき、ふと脳裏に、障害対応をしていたときほど「綿密なコミュニケーションと連携が必須な状況で相互理解」が深まったことを思い出しました。 ぼく自身もソーシャルゲームの開発をした際のトラブルシューティング時にチームメンバーやカスタマーサポートの方、プランナーやディレクターと綿密にコミュニケーションを取り、1つの目標を達成するのに熱狂、熱中していました。 このことから重要なのは「トラブルシューティングのような具体的に困った事象を元に"臨場感"を体験する」ことではないかと考えました。

エンジニアの興味や関心を「技術ｘ障害対応」で引き出し、競技性をもたせることでメンバーに対する相互理解を加速させることがコミュニケーションを活性化させるよい手段だと考えました。

エンジニアが障害から学ぶことは多々ありますが、その中でもメンバーがどの技術に詳しく、どのようなコミュニケーションを好むかは実際に体験を通して経験することでより詳細に学ぶことができます。 それを限りなく本番に近い形で再現する方法があれば、これらの課題を一度に改善することができるのではないかと考えました。

経験することでより記憶が鮮明になる理由についてはエピソード記憶や意味記憶で調べてもらうといいでしょう。 5 ぼくは専門家ではないのですが、ここでは経験したほうがより鮮明に記憶に残るということが重要ということを検討する際に意識したので、参考にさせていただきました。

ユーザー中心組織論では「納得感は実体験の振り返りから生まれる」と書かれています。 コミュニケーションの重要性は普段の開発だけでは、体験しにくいではないかと思います。 そういった経験、体験を提供する機会を創出することが、拡大し続ける組織では重要なのだと感じました。

交流の少ないメンバー同士でどうチームビルディングするかを設計する

当たり前ですが、いざイベントをやるぞ！となったときにそのイベントがチーム競技だった場合、多くの人が慣れ親しんだ方とチームを組みたいと考えるでしょう。 前述したようによく知る相手のほうが心理的ハードルは低くなり、慣れ親しんだメンバーで組みたいと考えるのが自然です。

ですが、それではコミュニケーションの改善は行えず、現状維持にしかなりません。 マネーフォワードだけでなく、世界全体が変化し続ける状態では、現状維持は実質的な後退を意味します。 より個としても、組織としても強くなるためには多様性という「曖昧さ」を受け入れる力が必要になると考えました。

かといって見知らぬ人と何の準備もなく、いきなりチームを組まされてもなかなかうまくコミュニケーションは取れないでしょう。 イベントでの体験が悪ければマイナスの記憶だけが残ってしまう可能性があり、運営としてその点をとても危惧していました。 どうすればこれらの課題に立ち向かえるのか？を考えたときに、ふと脳裏に数年前に会計Plusチーム 6 で開発していた際に行ったバリューカードのことを思い出しました。

wevox.io

Wevoxのバリューカードはとても良くできていて、誰がどういった価値観を大事にするのか、なぜそれを大事にしたいと考えているのかを知るとてもよいきっかけになりました。

このことから「自己開示を行う必然性」が生まれる仕組みを提供することで「知らない人」から「同じチームの人」へと解像度を高めることができるのではないかと考えました。 相手を知り、自分を知ってもらう仕組みがあり、コミュニケーションの必然性が生まれる場の3つを作用させることが重要ではないかと考えました。

それだけでは内発的動機づけが弱いので、競技性をもたせることでゲーム要素が生み出す没入感が生まれ、結果としてWorking out loudな取り組みが生まれるはずだと考えました。

blog.studysapuri.jp

より深い没入感を生み出すためにはノイズが少ない環境であることが望ましいでしょう。 没入しようとしている最中に誰かに話しかけられてしまうと集中力が途切れてしまうような現象は、おそらく誰もが体験しているはずです。

また、没入する際に自分以外の相手の反応速度も重要です。 レスポンスまでのリードタイムが長いということは別のことを考える余地が生まれてしまうことを意味します。 そのため、できるだけ素早いレスポンスが返ってくる環境、状態であることが望ましいと考えました。

これらの条件をある程度満たす環境を用意することでコミュニケーションにおける心理的ハードルを超えやすくなるのではないかと考えました。

熱狂や没入を生み出す環境設計

そのため、ハッカソンのような企画よりはISUCONのような「より短時間に綿密なコミュニケーションが発生する仕組み」のほうが向いていると考え、企画しました。

熱狂や没入を生み出すには目の前のわかりやすい課題に集中するほうが簡単だからです。 ハッカソンでは課題の共感を得るところから始める必要があり、短時間で効果を上げるという意味でISUCONのような施策のほうがふさわしいと考えました。

副次的効果として自身の長所短所を理解しているシニアエンジニア以上のメンバーのふるまいをみて、まだ長所や短所を理解しきれていないジュニアなメンバーは今回のイベントを通して自己理解が深まり成長のための糧にできるのではないかと考えました。 シニア以上のメンバーは即席のメンバーでどのようにチームビルディングするとより効果的なチームになるかを考えることで相手を深く知る重要性を体験できます。 エンジニアリングスキルの高い低いに関わらず、1つの施策が複数の効果をもたらすことができるよいトレーニングになると考えました。

最終的に実現可能性の観点から社内ISUCONではなく、GameDayというイベント施策を検討、実施することにつながりました。

  1. 氷菓 「古典部」シリーズ (角川文庫) の一節より引用。↩
  2. 毎月一回マネーフォワードでは全エンジニアが参加するオンライン型の社内イベントを開催しています。その中の技術トピックを共有する時間を使ってナレッジをシェアしてもらいました。↩
  3. 個人的にオンラインはまだオフラインを完全に置き換えるための「何か」が足りないと感じています。今年一年、オンライン・オフライン両方のイベントに参加して体験した結果ですが、今後この「何か」を埋めることができればオンラインでの開催も視野に入れたいと考えています。↩
  4. 異なる価値観の人間がある程度集まれば自然発生するものだと考えています。↩
  5. エピソード記憶と意味記憶 を参考のこと。↩
  6. マネーフォワード クラウド会計Plus を開発するチームを指します。当時マネーフォワード 京都開発拠点では主に会計Plusチームのメンバーが多く所属していました。↩