新卒2年目が前例のない社内アーキテクチャハッカソンを成功させた話

こんにちは！アドプラットフォーム事業部でリードアプリケーションエンジニアをやっています、中野です！
前回記事を書いたのが入社してすぐで、そこからおよそ2年ぶりの執筆となりますので今回は2年分の気合い注入した記事をお届けしたいと思います。

テーマは社内アーキテクチャハッカソンについてです。
社内企画をやりたいけど、作り方や始め方がわからないという方。
あるいは、アドウェイズでどういう社内勉強会が開かれているのか知りたい方。
またまたあるいは、プロジェクトにおける人の巻き込み方の体験談を聞きたい方。

そんな方々に向けて、自分の学びをお伝えしていきたいと思います！

大きく以下4点にわけて紹介をしていきます！

「社内アーキテクチャハッカソン」とは？
本番の様子
コンテンツやルールを作る際に意識したこと
開催してみての学び

そもそも「社内アーキテクチャハッカソン」ってどんなもの？
ハッカソンの本番はどんな様子だった？
ハッカソンのコンテンツはどう作った？
何を学んだの？
終わりに

そもそも「社内アーキテクチャハッカソン」ってどんなもの？

ハッカソンについて

まず、ハッカソン自体をご存知ない方もいると思うので、基本から説明します。
ハッカソンはソフトウェア開発の業界でよく行われるイベントで、4~5人でチームを組み、一定期間内に特定のテーマに沿ったシステムを考え、発表するというものです。
今回は「アーキテクチャ」ハッカソンという名前の通り、AWSなどを使ったシステムアーキテクチャを考え、それをシステム構成図に起こして発表するということを行いました。
なので、イベントの成果物はこういうものになります↓

なんでやろうと思ったの？

私がハッカソンをやろうと思ったきっかけは昨年11月にFindyさん主催で行われたアーキテクチャカンファレンス2024に参加したことです。

これをきっかけにアーキテクチャについて学ぶ機会を社内でも設けたいという気持ちから今回の企画を構想しました。

この段階で、このハッカソンの目的として以下の2つを設定しました。

若手がアーキテクチャについて学ぶ機会にする
アドウェイズグループ内のエンジニアでの交流の機会にする

学びの場という点については、特に若手エンジニアは業務で0からのアーキテクチャ設計にガッツリ参加できる機会というのはあまり多くありません。
とはいえ、アーキテクチャは設計してみないと身につかないというジレンマもあると思っています。
ですので、この勉強会という場ではシニアメンバーには助言役に回ってもらい、若手に主導権を持って議論を進めてもらうことで、若手の成長を最大化するイベントとなることを目指しました。

また、グループ内のエンジニアでの交流の機会を設けたいということに関しては、実は広告事業本部とアドプラットフォーム事業部（ADWAYS DEEE）で交流の機会がそれほど多くないという背景があります。
※広告事業本部：主に広告代理店事業を担う部門。　
アドプラットフォーム事業部（ADWAYS DEEE）：筆者が所属する、自社プロダクト事業を担う部門。

業務で関わることは少ないですし、LT会などで稀に交流することもあるのですが、一緒にものを作る機会というのはほとんどないのが現状です。
そんな中、事業部を超えてこういったイベントを行うのは社内のエンジニア組織の活発化という意味で意義のあることではないかと考えました。

ルール・対象者

今回は以下のようなルールを設定しました。

出社してのオフライン開催
制限時間1時間
発表時間は質疑応答含め8分
チームは普段の業務で関わりの強いメンバー4~5人
成果物作成はFigJam上で行う
各チーム1〜2名いるジュニアメンバーが発表者を務める
各チーム1名いるシニアメンバーは意思決定禁止
参加者全員の投票で最も票数の多かったチームにはアーキテクツ賞を、技術改善ディビジョンのゼネラルマネージャーであるおかむさんの審査によって選ばれたチームには岡村賞を授与

開催場所についてですが、オフラインとオンライン両方が選択肢としては上がっていました。
そのうえで今回は懇親会などを予定していたこと、また今後オフラインでイベントを行うための練習という意味も兼ねてオフライン開催を選択しました。
とはいえ、オンライン開催したほうがおそらく参加者は集まっただろうという感覚もあるので、今後開催する際には改めて状況を検討しながら開催場所を決める必要がありそうです。

制限時間については、ハッカソン後の懇親会の時間や発表時間諸々を考慮した結果、検討時間として1時間以上取るのが難しいと判断しました。
そのため、1時間である程度の成果物を作れるよう課題設定やチームメンバー設計を行う必要がありました。（この辺の話は後ほどお伝えします）

また、見慣れないルールとしてチームメンバーの職位に応じたロールの分担があります。
これはつまり、各チームのメンバー構成を以下のように設定したということです。

このルールを設定した理由としては、この短い制限時間でシニアメンバーを解き放ってしまうと、シニアメンバーの無双状態になってしまい他メンバーが置いてけぼりになる危険があると判断したためです。
なので、あくまでシニアメンバーはチームのサポートに徹してもらう形にしました。
とはいえ、このルールを設けても経験の浅いジュニアメンバーがついていけなくなる可能性は残ると考えたので、最後の発表はジュニアメンバーに行ってもらうことでこれを解決する作りにしました。
これによってジュニアメンバーが成果物を理解していないと発表できないという状況を意図的に作り出しました。

このような形で、参加メンバーの学びを最大化することを目標にルールを策定しました。

ハッカソンの本番はどんな様子だった？

今回の企画はアーキテクチャを扱うハッカソンであり、これに学びの場という意味も込めて 「Adways Architecture Academy（A3）」 というイベント名で開催しました。

本番で扱った課題

本番では以下のようなホテルの予約システム作成に関する課題を出しました↓

この課題ではざっくり以下のようなユースケースを設け、それをもとにした機能要件・非機能要件を定義しました。

1時間で検討するには一見分量が多く見えますが、考えてほしいことと考えなくてもいいことを明確にしてあるので、結果的にはちょうどいい分量になったと思います。

本番当日の様子

実際本番はうまくいったのか？

本番に関しては参加者の協力が大きく、初めてにしてはかなりうまくいったと思います。
ここでは本番当日の様子を写真付きでお伝えします。

当日はまず開会式で、企画の目的やルール、会の流れを説明しました。

その後、各チームに別れてアーキテクチャを設計してもらいました。
アーキテクチャの検討は当初1時間の予定でしたが、参加者からの要望が多かったため、10分延長した計1時間10分の時間を設けました。

検討が終わった後には、各チームで設計したアーキテクチャを発表しました。
発表時間は3分程度とかなり短かったため、どのチームもアーキテクチャ検討の後の休憩時間を利用して発表の準備をしていました。

各チームの発表後には他のチームからの質疑応答を行いました。
質疑応答は発表では話されなかった内容の深堀りが行われており、非常に活発な議論がなされていました。

全てのチームの発表が終わった後にはハッカソンの参加者投票と結果発表、表彰が行われました。
その後は懇親会が行われ、食事をしながら交流を深めました。

本番後のアンケートと振り返り

企画後には参加者にアンケートの回答をしてもらいました。
アンケート結果では、参加者の満足度は平均4.8点（5点満点）と非常に高く、大変好評でした。
また、参加者の主観での成果物の完成度としては概ね6〜8割程度の完成度だったという声が多く、私が当初想定していたのと同程度のラインに着地させることができたと思います。
ただ、アンケートの中で「もっと時間が欲しかった」というお声も非常に多く頂いていたので、次回以降開催する際にはそもそもメンバーがもっと忙しくない時期にやるなど、時間を多く取れる工夫が必要だと感じました。

また、これらの結果を踏まえつつ、本番後には早めに振り返りを行いました。
今回の企画では運営での課題とハッカソンでの課題がそれぞれありそうだったので、別日付・別メンバーで計2度の振り返りを実施しました。

特に運営においては、こういったイベントも開発プロジェクトと同じでステークホルダーマップをきっちり作って誰にどう関わってもらうかを明確にしておくことが重要だという話が出ました。
その他運営、課題作成、評価基準など、様々な観点から意見をいただけたので今後の企画の参考にしていこうと思います。

ハッカソンのコンテンツはどう作った？

ここからは上記のハッカソンのコンテンツやルールを作る際に特に意識したことをお伝えします。

社内企画も設計が大事

まずはじめに私が学んだことは社内企画のコンテンツにもシステムと同じように設計が必要不可欠ということです。
そのために、まずは要件定義が必要と考えました。
今回、初期段階でざっくり決まっていた要件は以下になります。

制限時間が1時間
オフライン開催
開催は3月中
若手の学びを最大化する
エンジニアの交流の場にする（事業部を超えて開催する）
参加者に楽しいと感じてもらう

これらの要件をもとに、どういうコンテンツにするかを考えていきました。
具体的にはPoCとしてβテストを開催し、その際のコンテンツにこれらの要件を反映させることで要件とコンテンツのすり合わせを行いました。

社内企画もPoCが大事

次に私が感じたことは社内企画もシステム開発と同じようにPoCとプロトタイピングをする必要があるということです。
PoCとはProof of Conceptの略で、あるアイデアの実現可能性を確認するために簡単な実装をしてみることを指します。
一方のプロトタイピングは、実現可能性があると分かったアイデアについて、機能や設計に問題ないかを確認するためのPoCよりさらに詳細を詰めた実装のことを指します。

今回の社内企画においてはβテストがまさにPoCやプロトタイピングに当たります。
3月の本番開催までにβテストは2度実施しているので、特に1回目のβテストについてはPoCとしての意味合いが、2回目のβテストについてはプロトタイピングとしての意味合いが強かったかなという風に思います。

これらのβテストは広告事業本部、アドプラットフォーム事業部それぞれから自分と関わりの深いメンバーを集めて実施しました。
1回目は自分の同期の23新卒のエンジニアに参加してもらい、制限時間や課題の難易度の検証、成果物が出来上がっていく過程のイメージを掴むことを目的としました。
この時の課題はzendeskのような問い合わせチケット管理のSaaSを作成するというものでした。

結果、進行のイメージは掴めたのですが、課題の難易度について現状のままでは以下のようなリスクが有るということに気づきました。

成果物の完成度
- 当初、成果物の完成度は参加者の主観で6〜8割程度になることを想定していた
- しかし、βテスト後のヒアリングでは「4〜5割程度しか完成しなかった」という声が多かった
進め方
- 始まってからの20分〜30分程度を課題の解釈や要件検討・ユースケース検討に使っていた
  - 肝心のアーキテクチャ検討に使えている時間が少ないことが気になった
  - 実際のシステム開発においてはこの過程はとても重要だが、今回はアーキテクチャを学ぶことに主眼をおいているので、それ以外の時間はできる限り減らしたい気持ちがあった

これを受け、2回目のβテストでは以下のような対応策を講じ、特に序盤の動きをスムーズにすることを目指しました。

追加課題を減らす
ユースケースを最初から図示してイメージしやすくしておく
アーキテクチャを最初からある程度書いておいて何をすれば良いのかわかりやすくしておく

また、テーマとしてもマルチテナントSaaSのような複雑なシステム開発は採用せず、よりイメージのしやすいチケット販売サイトの開発をテーマとすることで成果物の完成度が上がることを期待しました。

さらに、2回目のβテストではそれぞれの事業部から関わりのある先輩と後輩1人ずつに参加してもらい、シニアとジュニアのロールを担ってもらいました。これによってロール分担のルールが実際に機能するかどうかの検証を行いました。

結果として2回目のβテストでは次のようなことがわかりました。

課題に対する説明の量や難易度は本番においても第2回βテストと同等程度で問題なさそう
課題の説明量が増えた影響で課題を読む時間が増え、読み漏らしも起こりやすくなった
普段関わらない先輩社員がチームにいるとメンバーが萎縮して意思決定の速度が落ちやすい

1に関しては吉報で、課題に関してはあとは質を上げていけばいいだけということがこの時点でわかり、非常に進めやすくなりました。
2についても、課題を最初に全体で説明する時間を取ることで簡単に解決できそうという結論になりました。

問題となったのが3で、いちばん簡単な解決策としてチーム自体を業務組織上のチームに寄せてしまうというものが挙がりました。
しかし、それだと当初目標としていたグループ内のエンジニアの交流の場としての意義が薄れてしまうという懸念があり、どちらに振り切るかの決断を必要としました。
結果、今回は上記の解決策を採用し、普段関わりのあるメンバーでチームを組んでもらうことにしました。
この意思決定の理由としては、関わりのないメンバーでチームを組むとアイスブレイクが必要となることや、意思決定速度の低下による成果物の完成度低下を懸念したことが挙げられます。
特に今回は初回ということもあり、まずは参加メンバーに楽しんでもらい、次回以降の足がかりとしたいという気持ちもあったのでこのような形を取りました。
結果的にはうまく行ったのですが、やはり交流に関するアンケート項目結果は低い値となってしまったので、次回以降開催する場合にはもう少しやり方を工夫したいなと思っています。

	役割	目的	学んだこと
βテスト1回目	PoC	制限時間や課題の難易度の検証、成果物が出来上がっていく過程のイメージを掴む	期待をしていた成果物の完成度や進め方とのギャップがあることに気づいた
βテスト2回目	プロトタイピング	イメージしやすい課題にすることで、成果物の完成度を上げるジュニア・シニアのロール分担がうまく機能するか	課題の方向性が決まったより検討に時間を使うためチームメンバーの調整を行う

社内企画もレビューが大事

社内企画においてもコードと同じでレビューをしてもらうことが非常に重要ということを痛感しました。
今回で言うと以下のようなものは全てレビュー対象でした。

本番までに必要なタスク
告知文
本番の課題
本番のルール
チームメンバーの割り振り

ここでは特に本番課題のレビューについてお伝えします。

まず、本番課題を作るにあたって参考にしたのがArchitectural Katasというサイトです。

これは「ソフトウェアアーキテクチャの基礎」という本の中で著者のNeal Fordさんが紹介しているサイトで、アーキテクチャ設計の訓練をするための教材です。
当初はこれをそのまま利用しようかと思ったのですが、それだと制限時間的に難易度が高いということで、自分たちの要件に合わせてアレンジしていきました。
このアレンジに際して、例えばホテルのサイト利用者数に関する相場の数値や課題の要件候補についてはGeminiに相談しながらブラッシュアップしていきました。
その後、テクニカルマネージャーという部署全体の技術リードをするメンバーにレビューをしてもらい、それらの意見をまとめながら課題を完成させていくという流れを取りました。

当初はテクニカルマネージャーの内、審査員として参加いただいているおかむさんにのみレビューをお願いするつもりでした。
しかし、おかむさんから「テクニカルマネージャーの定例で今回の課題のレビューを議題にしよう」という提案を頂き、おかげで複数人の目でレビューをしてもらえる事になりました。

テクニカルマネージャーのレビューでは例えば以下のような意見を頂きました。

アーキテクチャ設計とアプリケーション設計が入り混じっているので、非機能要件を増やしてアーキテクチャ設計に振ったほうが良い
データの流れを明確にしてもらうことで参加者に自分たちが作ったアーキテクチャの解像度を上げてもらったほうが良い
UI/UXに関連した要件もありそうだけど、アーキテクチャのことを考えるのであれば除外しても良いかも

本番の課題ではアーキテクチャ的に検討する事項が少ないということを自分としても悩んでいたので、それを非常にスマートな形で解決してもらえたことで課題の質がかなり向上したと思います。

また、個人的な学びとして「モブレビューは人数が多いほど精度が上がる」ということを非常に強く感じました。
特に、優秀なメンバーであるほどそれぞれが持っている観点が異なっていることが多いので、より多くの観点を得ることができると思います。
もちろん、全てのレビューを複数人でやる必要はありませんが今回の本番課題のように、企画のコアとなる部分については複数人の有識者にレビューをもらうということは非常に有用だと思います。

何を学んだの？

社内企画 = コミュニティである

今回の企画で非常に苦労したのが参加者集めの部分です。
というのも告知した当初にはβテストで協力要請をしていたメンバーしか参加表明をしてくれなかったからです。
これではβテストと本番の差分がなくなってあまり実りのある企画にならない懸念がありました。
この問題については結果的にはユニットマネージャーにトップダウンでチーム内に呼びかけてもらい、なんとかメンバーを集めることができました。
この過程で私がで学んだのが「社内企画 = コミュニティ」であるということです。

私は当初、企画の告知をしたら数十人のメンバーが自然に集まると思い込んでいました。
というのも、別で開催されていた「Adways Lightning Talk（ALT）」というLTイベントには20人以上の人が集まっていたので、同じ勉強会であれば人は集まるだろうと考えていました。
つまり、当初の私は「企画の内容や目的」に人が集まるという風に考えていたのです。
ですが、これは大きな誤解でした。
実際には「勉強会」という目的には人が集まらず、「Adways Architecture Academy（A3）」というコミュニティに人が集まる、あるいは「Adways Architecture Academy（A3）」というコミュニティのメンバーからこの企画への参加者が生まれるのです。

こう考えると、なぜβテストのメンバーが告知してすぐに参加表明をしてくれたのかも理解できます。
それはこのメンバーがβテストに参加した時点で意図せず「Adways Architecture Academy（A3）」という今回の企画のコミュニティメンバーになっていたからです。

今回は、ユニットマネージャーの協力もありなんとか人数を集めることができましたが、次回以降はこの「コミュニティの輪を広げていく」という意識を持ちつつ企画運営をしていく必要があると感じています。

勉強会は業務である

私自身、この企画の準備をしているときから「あくまで業務外の勉強会なので、周りに負担をかけないよう、自分ひとりでできるだけ進めなくては」という意識がありました。
この意識に引っ張られて、イベントに関するノウハウを持ったメンバーへの相談が遅れたり、会自体の時間を各チームの業務に支障が出ないような短い時間に設定したりといった遠慮に起因する問題が生まれていました。

しかし、本番後に行った振り返りで、運営メンバーの方から「勉強会は業務だし、divメンバーにもそういう考え方を持っていってほしい」というお言葉を頂きました。
この言葉をもらって初めて、今回の企画も業務の一環として展開してよかったんだという意識を持つことができました。
今後は「勉強会は業務である」という考え方を大切にしながら、参加メンバーに最大限の価値を提供するということをより一層意識した企画を開催していきたいと思います。

運営にはノウハウが必要である

これもかなり当たり前のことなのですが、企画当初の自分は「今まで出たセミナーとかイベントを参考にすれば本番のお手伝いをお願いするくらいで後は一人でできるだろう」と考えていました。
しかし、実際には当日の食事の管理や広報への協力要請、会議室の確保などイベント運営にはそれ相応のノウハウが必要となります。
今回は初めてのイベント企画だったこともあり、企画内容を練ることばかりに目が言ってこれらのノウハウが必要であるということに気づくのが遅れてしまいました。

このことから、こういった社内企画に限らず、新しいことを行う際にはノウハウを持った有識者を早い段階から巻き込んで意見をもらうということが非常に重要であるということを学びました。初動で意見をもらいさえすれば、その後そのメンバーに運営に入ってもらうべきかは後から判断できるので、とにかく関わりそうな人には早い段階で頭出ししておくことが大事そうです。