エンジニアインターン生の交流会イベントを開催してみた話

こんにちは。わり算グループでインターンをしている小野です。

4/15にインターン交流会を開催してみました。その経緯や内容を報告をさせていただきます。　（補足：わり算グループとは）

複数のサービス間でリソース等を共有することで、サービス同士の依存が大きくなって成長や安定を妨げてしまうことがあります。それらの依存を解消し、サービスの成長スピードや安定性を高めるために、サービスを分割していく(-> わり算!!!)ことを主目的に置いているグループです。

きっかけは1つの呟き

このインターン交流会は、僕と同じわり算グループでインターンをしている松本さんが書いた1つの呟きをきっかけに始まりました。

彼の話によれば、インターン生同士のつながりをもっと持ちたいがなかなか機会がなくて困っている、とのこと。確かにマネーフォワードには沢山のインターン生がいますが、所属している部署が違うとお互いに交流する機会は少ないです。僕はこの課題を解決できないか考えてみることにしました。

課題について

どのような課題なのか？

インターン生が交流することによって期待することは、以下のものが考えています。　

インターン生

他の部署ではどんなことをやっているのか知りたい
学生目線から、企業について情報交換がしたい
- 例）A社でインターン経験がある佐藤くんはB社でインターン経験がある斎藤くんの話が聞きたい
（エンジニアの場合）技術について話ができる友達が欲しい

会社

部署を跨いだ横断的なタスクを任せるきっかけになる
インターン生の会社に対するイメージアップにつながる

誰の課題を解決するのか？

当初は対象を『エンジニアインターン生』としていましたが、交流の機会がないのはエンジニアインターン生だけではないと思い、誰を対象とするべきかから考え始めました。マネーフォワードにはたくさんのインターン生がいて、職種も様々です。

検討の結果、今回はエンジニアのインターン生を対象とすることに決めました。自分自身、および課題感を持っている友人がエンジニアインターンであり、エンジニアという共通点を活かした関わり方ができると考えたからです。

企画について上長に相談

企画についてVPoEの渋谷さん、CTOの中出さんに相談したところ、瞬殺で業務活動として認めていただきました。インターン生でも裁量を持ってやらせてもらえることに感謝をしながらこうしてエンジニアインターン生交流会企画が始まりました。

どのように運営をしていくか？

運営を手伝ってくれるメンバー（僕を含めたインターン生2人、社員2人）がいたのですが運営をする上で2点気にかけていたことがありました。

時間をお互いにかけ過ぎない
- 本業はエンジニアリングなので業務に支障の出ない範囲でみんながやれるようにしようと考えていました
考える上での物差しを定める
- 何かの決断を迫られた時に考える基準がないと一貫した意思決定ができないのでコンセプトを定めました

参加人数をどのように確保するか？

せっかく頑張って企画しても参加する人数が少なかったら、運営する側のモチベーションも上がらないし当日の雰囲気も活気がないものになってしまいます。リマインドも定期的にして、日程調整に返信をしていないインターン生の方にはDMを送りました。

目標には及びませんでしたが、10人のインターン生（当日キャンセルが2人だったのである意味では目標達成？）が参加してくれました。

どのような意思決定があったのか

小さいものから大きいものまでまとめていきたいと思います。

企画の内容を社員 vs インターン生にするのはどうか？(何人かの方から頂いた意見だった) -> インターン生のみで勝ち負けを作らない問題を解く企画にする
- 2つの点において今回は見送る形にした
  - 交流がメインで参加のハードルを下げたいので勝ち負けを作りたくない（コンセプトの1つ）
  - 一番やりたいことはインターン生の交流なのでインターン生のみを参加対象としたい
解く問題は“競技プログラミングのようなアルゴリズム問題” or “CodeKataにあるようなアプリケーションを作っていく問題“の何方にするか？ -> CodeKataにあるようなアプリケーションを作っていく問題にする
- アルゴリズム問題の特徴
  - コードの当たり外れが一発でわかる
  - アルゴリズム -> 意見や役割が偏る可能性がある
- アプリケーションを作っていく問題
  - コードの当たり外れが目視確認のみ
  - 実際のアプリケーションを作るのに近い -> 議論しやすいし役割を回しやすい
使用言語を自由にする or 事前に運営側の方で決めるの何方にするか -> 事前に運営側の方で使用言語を決める
- 使用言語を自由にする
  - 一番参加者に優しい（言語ごとのリポジトリを運営側で準備するので自由だと大変）
- 事前に運営側の方で決める
  - マネーフォワードで一般的に使われている言語を指定すれば問題なくできそう

当日の様子

何をやったのか？

事前に運営側が環境セットアップをしたリポジトリをgit cloneする -> 各チーム(2人~3人)ごとにブランチを切って、チーム内の誰かが画面共有してコードを書く役割を担い、問題を解くモブプログラミングのようなことをしました。後半戦になるタイミングでコードを書いていた人がgit push, コードをこれから書く人がgit pullして続きを書いていきました。

当日の流れ

挨拶 5分
前半戦 25分
後半戦 25分　(コードを書く人交代)
締め&写真撮影 5分

の合計1時間で企画しました。

取り組んだ問題

当日取り組んだ問題を紹介します。（一部抜粋してあります）古濱さんが作成した問題だったのですが、クオリティが高くて解きながら感動していました。

みなさんはマネーフォワードの物理会議室で提供されている予約システムを使ったことがありますか？(カレンダーや会議室ごとの iPad から利用可能) リモートワークがメインになってから長いのであまり利用したことがない人もいるかもしれませんが、ちょっとした複雑さを持っているシステムなのでこれを実装してみましょう

Step1 予約の登録と確認まずはある会議室の前の iPad のシステムから実装してみましょう

好きな時刻から 15min / 30min / 60min の時間の予約を登録することができる

想定外の時間(e.g. 10min / 90min ...)の予約が登録しようとされた場合には登録させない

現在登録されている予約の開始時刻と終了時刻の組が一覧で確認できる

Step2 予約の延長

登録済みの予約に対して一意な識別子が採番されている

識別子と延長時間から予約時間を延長することができる

延長時間は 15min / 30min / 60min のみ許可されている

想定外の時間(e.g. 10min / 90min ...)を延長しようとされた場合には延長させない

許可されている延長時間だとしても、延長した場合に他の予約と重複する場合には延長させない

同一の予約の延長は何回でも許可されている

参加者の様子

真剣に楽しく取り組んでいる様子が伺えました。

運営サイド

運営サイドは正直ハプニングだらけでした..

参加者の一人をカレンダーに招待し忘れ、そのことに始まってから気づいた
始まる直前に一人参加できない人が出てきてペアを組み直さないといけなくなった
Zoomのホスト権限を担当の人に事前に渡し忘れていた
Zoomのブレイクアウトルームで見に来た社員さんを移動させるのに時間を使ってほとんどコーディングができなかった
リポジトリへの招待やチーム決めなど、事前にできたモノを直前までやっておらず、アナウンスが直前になった

反省

参加者からのフィードバックから

当日はバタバタでしたが、参加者の方には満足して頂くことができたようです。

＜満足度アンケート結果＞

最後に懇親会的な時間が欲しかった

という意見もいただいたので次回開催する上での参考にしたいと思います。

当日の運営サイドの動きについて

起こったハプニングを次やるときはどう防ぐかについてまとめてみます。

参加者の一人をカレンダーに招待し忘れ、そのことに始まってから気づいた
- これはカレンダーの招待が全員に来たかどうか事前にSlackで確認するべきでした。
Zoomのホスト権限を担当の人に事前に渡し忘れていたリポジトリへの招待やチーム決めなど、事前にできたモノを直前までやっておらず、アナウンスが直前になった
- 当日確認するチェック項目を準備しておくべきでした。
Zoomのブレイクアウトルームで見に来た社員さんを移動させるのに時間を使ってほとんどコーディングができなかった
- 参加者が自由にルームを移動できる設定にすべきでした

全体を通して

良かった点

もう1人の運営メンバーにはすごく企画が楽しかった！と言ってもらい、僕自身も楽しみながら取り組めたので雰囲気よく出来たのは良かったです。 考える基準を揃えたことによって一貫した考えで物事を考えることができたのが雰囲気よくやれたことに繋がったのではないか？と思っています。また、運営メンバーに加わってもらった古濱さん、Brownさんには本当に助けていただきました。意思決定をする上で新しい選択肢を提示してもらったり、考慮漏れを指摘してもらったり縁の下の力持ちのような存在でした。

改善点

本業はエンジニアリングで影響のない範囲でみんながやれるようにしようと考えていました

とかっこいいことを言っていましたが、実際の取り組みへと全然落とし込めていなかったです。手戻りを何度か繰り返してしまった場面がありました。この原因は運営に当たってトップダウン型の考え方ができなかったからだと思います。今回の例で言うと、インターン交流会というやりたいことが決まった -> 実現したいことに向けてやっておくべきことを洗い出す -> やっておくべきことはいつまでに終わらせるべきなのか決めると言ったプロセスを踏むべきだったなと思っています。行き当たりばったりで必要なことを考え、その場で解決しようとしてしまったことは反省しています。

運営メンバーが行った工夫について

問題について

今回問題を作るに当たって古濱さんが考えていたコンセプトは以下の通りです。解いていて感動するような問題を作った背景にはこのような意図がありました。

50min と短い時間での実装になるので、非対話型プログラムを作るようにする
TDD じゃなくてもいいが、正解不正解はわかるようにしたい
- 競プロのようなアルゴリズム問題にはならないようにする

参加者の環境について

今回企画内容の詳細全般を担当した松本さんは参加者がスムーズにコーディングできるように事前に運営側が環境セットアップをしたリポジトリ・チームごとのブランチを用意していました。

運営をしてみての感想

自分達で課題を定義し仮説を立てて解決しようと試みることの楽しさを実感することができました。今回の企画が一つの呟きから始まったように日常に潜む課題を発見し解決することはこれからもやっていきたいです。また自由に取り組むことの責任も学びました。今回の企画は自分でやりたいと思って取り組んだものでした。自発的にやっているのでモチベーションが上がるのですが、やりたいことをやるからには成功させなければならないというプレッシャーも感じていました。きちんと成果を出すことが求められる会社としての厳しさも教えてもらいました。