はじめに

社内のもくもく会で、「勉強会の一環としてハッカソンをやってみたい」という声があがりました。そんな中、声をかけていただき、計2時間半の社内ハッカソンを主催しました！

結論から言うと、社内で生成AI系のイベントをやりたいけれど、ハンズオンはもうやったし、あまりハードルが高いのも…という方には、短時間のハッカソンをおすすめします。
本記事では、その短時間ハッカソンを運営する上で得た知見を中心にご紹介します。

そもそももくもく会とは？については、こちらをご参照ください。

社内でもくもく会をやってみた（エンジニア交流促進）

また参加者・撮影配信班側として参加された佐藤さんの記事も公開中です。運営側の視点が主な本記事と併せて、ぜひ参考にしてみてください。

【AWS×生成AIハッカソン】インフラ系エンジニアが社内イベントでBedrockに入門しました

ハッカソン概要

今回はオンライン＋オフラインのハイブリッド開催で行いました。
生成AIを使ったことがない社員にもAmazon Bedrockに触れてもらえるよう、エンジニア以外も参加可能なイベントにしています。

そのため、エンジニアでない職種やインフラエンジニアも気軽に参加できるように、コードを書くことは前提にしていません。
どちらかというと、アイデアを出し合う「アイデアソン」に近いイベントです。

通常のハッカソンは1日〜数日と長時間ですが、社内で開催する場合、業務の都合で1日を確保するのは難しいため、今回は2時間半で開催しました。

当日のタイムスケジュール↓

2時間半のハッカソンではできることが限られてくるため、運営側でさまざまな案を練り、準備を重ねました。

事前準備

企画検討

今回のハッカソンでは、以下9つのポイントを達成することを目指しました。

1. ローカルでの環境構築はしない（AWS上で完結できるように）
2. 最後に発表の時間を設けて、他のチームから学びを得られるようにする
3. アイディアソンの加点要素も狙えるように
4. 技術に尖ってる人がいれば、技術点も狙えるように
5. 社内の交流の意味も交えて、チーム戦にする
6. 1時間半で全員が「作れた！」という達成感を得られること
7. なるべく多くの人が来れるような時間設定をする
8. 全社員が自由に使えるAWS環境を持っているとは限らないので、事前に検証用アカウント(1つ)からIAMユーザーを作成する
9. 当日やっぱり参加・不参加は起こり得るので、チーム編成は当日まで柔軟に行えるようにする

こうした目標に基づき、テーマ設定とメンバーとの調整を繰り返しました。後々、もう少し削れる部分があったかなという反省もありましたが、次回に活かしていきます。

企画内容に従い、準備

準備TODOはこちらでした。

  • IAMユーザー作成・配布
  • 投票システムの作成
  • 終了後のアンケート準備
  • 当日の会場準備
  • チーム分け
  • 全社周知（1ヶ月前、1週間前、当日）

IAMユーザーの配布については、運営メンバー（みちのすけさん）が自動化システムを作ってくれたので、人数が増えても円滑に準備が行えました。特化したシステムがあると、準備がより簡単で当日もイベントらしさが出ます！

チーム分けは事前に参加登録していただいた人を、オンライン・オフライン同士で振り分け、当日チーム分けを発表するオペレーションに決めました。

当日

運営側の当日TODOリストは以下の通りです。
スムーズに進行できるよう、進行役2人、サポート3人で対応しました。

最初
・Meetの管理者権限設定する（Meetの設定で、最後に参加者を収集することができます）
・開始時にはタイマーを画面共有
・イベントが開始する旨を全社で周知する
途中
・あと何分かアナウンスする
投票
・どのチームが何を作ったか概要を1枚にまとめて、投票時間に画面共有する
クロージング
・最後アンケートお願いする

当日のお題

今回のハッカソンのお題は、なるべく前提知識に依存しないテーマになるよう

「社内ツールであったら良いなと思うもの」

を選定しました。
社内ツールなので様々な機密情報も紛れていると思い、漏洩などがなるべく起きないように注意事項を設けています。
また使用するデータをハッカソン内で作成したものに限ることで、ある程度の不公平さを軽減しました。

これで制作開始！となったものの、制作中アクシデントがいくつか発生。。

アクシデント① CloudShellのクォータ制限にひっかかる

CloudShellでバージニア北部 (US-EAST-1) に参加者15名分のリソースを立てようとしたところ、途中で

「リソースが作成できない」

という声が聞こえてきました。参加者によっては問題なく利用できている人もいたため、エラー内容を確認したところ、原因は「1リージョン内で使用できるCloudShellの同時シェル数」に関するクォータ制限でした。
（参考：https://docs.aws.amazon.com/ja_jp/cloudshell/latest/userguide/limits.html#shell-limits-per-region）

CloudShell使うリージョンを分け、バージニア北部のリソースを参照するようにコードを変更することで解決しましたが、手順は、ある程度の人数を集めて予行しておくことの必要性を実感しました。
（1アカウント内で実施する場合は特に）

アクシデント② モデルの有効化漏れ

クォータ制限を解決したと思ったら、次に報告されたのが、

「Amazon Bedrock knowledge baseで同期ボタンを押しても同期が始まらない」

という問題でした。

私は問題なく同期できていたのに、参加者が同期できないという事態でした。
何が原因かと調査してみると、原因は「モデルの有効化漏れ」。

手慣れたモデルを使って作業していたのですが、手順書では異なるモデルが指定されており、実はそのモデルが有効化されていなかったというミスでした。
使用したいモデルの有効化を追加で実施し、エラーを解消しましたが、手順書に沿って準備を進め、問題発生時に原因を突き止める大切さを痛感しました。
結果的に、参加者の皆さんにはご迷惑をおかけすることに…。

結果発表

アクシデントもありつつも、各チーム様々な案が発表されました。
1時間半と短い時間でしたが、全てのチーム動くものを発表されていました。（すごい！）
実際に発表されたテーマは以下です！

ツッコミどころがあるテーマや実用性の高そうなものまでチームの色が出ています！

クロージング

アクシデントがありつつも、なんとか予定通りに発表と投票ができました。最後にアンケートもお願いして無事終了。

あって良かったもの

  • BGM

オフライン・オンラインで共通してBGMを流すとイベントっぽくなって良いです。
特に作業時間があるハッカソンは、BGMがあるとシーンとして空気になりづらく、わいわいした雰囲気を維持することができます。

  • 軽食（オフライン限定）

今回はお腹が空く時間帯に被っていたのもありますが、作業やアイディアに詰まった時に食べれるような軽食があると良いですね。
今回はドーナツを別の運営の方が買ってきてくれました！

改善点

  • スキル幅が広い場合は、環境構築を一緒に実施する

今回は生成AIのキャッチアップとしてよくあるRAGの構成や生成AIで用いられる単語、ハッカソンでのコツをお伝えしましたが、その後の環境のセットアップはチームにお任せしていました。
ただ、これだとチーム内でのサポートに依存してしまい、足並みもバラバラになるので、最初に全員で環境のセットアップは行うべきでした。
ハッカソンでもハンズオン要素がある場合は、全体で一緒に実施することを推奨します！

  • オンラインは管理者がブレイクアウトルームを作る

オンライン・オフラインのハイブリッドでの開催でしたが、オンラインチームはチーム発表後使いなれたツールで会話してもらうのが良いだろうと、こちらからは用意していませんでした。（全員共通でMeetには入っていたので連絡は取れるだろうと慢心）
ただ実際はチームそれぞれがMeetのコメントでツール選定をする必要があり、混乱を招くきっかけとなりました。
またそれぞれどこで通話しているかも運営側で把握できないことにつながったため、運営側によるブレイクアウトルームの作成は必須です。

  • 当日のイベントチャンネルを作る

2つ目に関連しますが、今回最終的に何人来るか不明確のまま進んだこともあり、事前にイベント用のチャンネルを作りませんでした。
当日も配信上でお知らせすれば、と言う考えから作成しなかったのですが、やはりチームごとの作業になるのでイベント用で1つ作成した方が良かったです。

  • 対象者を絞る

最終的には全員が完遂できるように、という目標にしましたが、初期段階では「生成AIを初めての方」「生成使い慣れてる人も」という幅広いターゲットを設定していたのでテーマ設定に苦戦しました。
やはりターゲットはある程度狭くしないと、運営側はやりづらさがあります。

気づき

ハッカソンを主催していて、最も気づかされたことは、運営側は「参加者に楽しんでほしい」という思いでいっぱいなのですが、実際には当日何かと対応に追われ、「楽しい雰囲気を実感する余裕がない」という点です。（今回はアクシデントが多かったこともありますが…）

これは決して「楽しくなかった」ということではなく、慌ただしく対応している間にイベントが終わり、参加者が楽しんでいる瞬間を見られなかった、という状況です。

運営として反省点は多かったものの、参加者の皆さんからいただいたアンケートには「楽しかった」という声が多く、とても救われました。至らない点もたくさんあったかと思いますが、良かった点や改善点についてフィードバックをいただけたことが、なによりありがたかったです。

普段、社内外のイベントに参加して「アンケートをお願いします！」と声をかけられることがありますが、その意味を本当の意味で理解できました。
これからは運営側へのフィードバック（特に良かった点）をより一層積極的に伝えていきたいと思います！

まとめ

今回の運営を通じて感じたこと、反省点、改善点をまとめました。少しでも参考になれば嬉しいです！