はじめに
まず、今回の話の前提となる 「スプラッシュプロジェクト」 について簡単に説明します。
こちらの記事に詳細が書いてあるのでぜひ読んでみてください。
スプラッシュプロジェクトとは、ITプロダクトを量産することで、ITプロダクト開発チームのプレゼンスを高める ことを目的とした社内プロジェクトです。
学習目的の取り組みという位置付けのため、
- 業務外プロジェクトであること
- 費用対効果が出ないプロダクトでも OK
というルールで運用しています。
「とにかく作る」「アウトプットを増やす」ことを重視したプロジェクトです。
スプラッシュが抱えていた課題
業務外 PJ という性質上、どうしても優先度が下がりやすく、定期的な進捗共有の場でも
「今週は進捗ありません」
という報告が増えていきました。
この状態では、
- プロダクトは増えない
- 成果が見えない
- 結果としてプレゼンスも上がらない
といったように、本来の目的からどんどん離れてしまいます。
そこで考えた打開策
「いつかやる」ではなく、
アウトプットに踏み出しやすい場 を作れないか。
そこで考えたのが、
1 日で“動くもの”を作り切るハッカソン
でした。
プロジェクト名の「スプラッシュ」にちなみ、このハッカソンは**「スプラッシュデー」** と名付けて開催することにしました。
準備編：一番大変だったのは「お題」
事前準備
まず今回は参加人数が 11 人と多かったため、打ち上げのお店、会場の座席確保などをしました。
また、昼どきに外で食べるのは難しそうだったため、お弁当を手配する形にしました。
ハッカソン形式の検討
並行して進めたのが、ハッカソンの中身決めです。
最初は「午前中に各自が担当しているプロダクトについて相談会を行い、午後にそれを解消する」という案もありました。
ただ、この案には懸念がありました。
各プロダクトの技術スタックや背景を把握するだけで時間がかかりますし、すでにリリース済みのプロダクトも少なくありません。
目先の「進捗がない」という課題には効きますが、プレゼンス向上という本来の目的には弱いと感じました。
そこで方向転換し、新規プロダクトを 1 日で作る形式 に決定しました。
お題の検討
次に一番悩んだのがお題です。
現在は AI 駆動開発が当たり前になりつつあり、正直なところ 2 人いれば UI 付きのプロダクトは問題なく作れてしまいます。
今回は参加人数が 11 人だったため、2 人チーム × 4、3 人チーム × 1 の 計 5 チーム編成となり、必然的に お題も 5 つ用意する必要がありました。
さらに、これまで先輩方が多くの価値あるプロダクトを作ってきたこともあり、「何でもいいから作ろう」というのは難しくなっていました。
そのため、まず以下の方法で候補を洗い出しました。
- チーム内でお題を募集する
- 未着手のスプラッシュ案一覧からテーマを拾う
そこから、当日に外部チームとの調整が発生しそうなものは1日で動くものを作ることのブロッカーになる可能性があったため除外しました。
準備段階の反省点を挙げると、開催日が近いタイミングで企画を詰めたため、外部 API を使うようなお題を除外してしまったことです。
次に、それぞれの案について「何の課題を解決したいのか」を言語化し、他のお題と統合できないか、逆に分解できないかをしっかり検討しました。
当日編：1 日でも「ちゃんと動くもの」は作れる
まず、当日は以下のスケジュールで実施しました。
| 時刻 | 内容 |
|---|---|
| 10:00~10:30 | キックオフ |
| 10:30~12:00 | 開発 |
| 12:00~13:00 | お昼ごはん |
| 13:00~15:00 | 開発 |
| 15:00~15:15 | 中間報告 |
| 15:15~17:30 | 開発 |
| 17:30~18:00 | 最終発表 |
キックオフ
では、お題とチーム分けを発表し、ルールを共有しました。
ルールはシンプルで、以下の 2 点です。
- 必ず「動くもの」を作ること
- AI を遠慮なく使うこと
午前の開発
キックオフ後はチームごとに近くに座ってもらい、開発をスタートしました。
午前中は、どのチームも設計をどう進めるかに時間を使っている印象でした。
ホワイトボードに書き出して整理しているチームもあり、ハッカソンらしい光景だと感じました。
午後の進行と中間発表
午後も各チームが開発に集中し、15 時時点で中間発表を実施しました。
「今どこまでできているか」「発表までに何をやるか」を見える化することで、ラストスパートに向けた意識合わせができたのは良かった点です。
どのチームも UI は完成しており、あとはバックエンドの整備や連携の実装といった段階にある印象でした。
最終発表
中間発表から最終発表までは、どのチームもラストスパートという雰囲気で、1 日の中で最も集中していた時間帯でした。
気づけばあっという間に 17 時半になり、最後に全員で集まって成果発表を行いました。
成果発表では、1 日の作業の振り返りに加え、実装した機能や使用した技術について説明してもらい、あわせてデモを実演してもらいました。
作成したプロダクト
タスク管理ツール
- 利用技術
- 言語: TypeScript
- 実行環境: Bun
- フレームワーク: Hono
- データベース: MySQL
- インフラ構成管理: Terraform
- クラウド: AWS
- EC2
- ECR
- S3
- CloudFront
- 機能
- タスクの作成、編集、削除が可能
- ユーザーにタスクを割り当てる機能
- 割り当てられたタスクは、該当ユーザーの画面に表示される
- タスクの進捗状況をリアルタイムで管理
- 画面
- TOP画面
- TOP画面
タスクの作業時間を記録するタスクログ
-
利用技術
- 言語: JavaScript
- 実行環境: Electron
- フレームワーク: Electron Forge
- データベース: SQLite
- グラフ描画: Chart.js
-
機能
- タスクごとの作業時間を計測できる
- タイマーの開始、一時停止、再開、停止に対応
- 作業履歴をタイムラインで確認できる
- 日・週・月単位で作業時間を集計、可視化できる
- タグによる分類や絞り込みができる
- ミニウィンドウ表示に対応
-
画面
- TOP画面
-
解析画面
好き嫌いやアレルギーを考慮した食堂レコメンド
-
利用技術
- 言語: TypeScript, JavaScript
- フレームワーク: Next.js
- クラウド: AWS
- Lambda
- API Gateway
- Bedrock knowledgebase
-
機能
- 好み、苦手、アレルギーを入力できる
- AIが社食メニューからおすすめ出社日を提案
- おすすめ理由とスコアを表示
-
画面
- TOP画面
- レコメンド画面
オフライン MTG を検知して Slack 通知するツール
- 利用技術
- 言語: Python
- クラウド: AWS
- Lambda
- S3
- Bedrock
- カレンダー連携: Microsoft Graph API
- 機能
- Outlookカレンダーから予定を取得
- 予定情報の解析・整形
- 予定内容をSlackに通知が可能
- 通知画面
感謝を送り合える「ありがとう」ツール
-
利用技術
- 言語: TypeScript, Python
- フレームワーク: Next.js
- クラウド:AWS
- Amplify
- Lambda
- API Gateway
- DynamoDB
-
機能
- 感謝メッセージを送信できる
- 受け取った感謝メッセージを一覧で表示
- メッセージの送信・受信履歴を管理
- メッセージ送信時の確認ダイアログ表示
-
画面
- TOP画面
- ありがとう送信画面
正直、「1 日でここまで作れるのか」と驚かされる内容でした。
やってみて良かったこと
今回一番良かったのは、他のメンバーの AI の使い方が見えたこと です。
プロンプトの作り方や、どこまで AI に任せるかといった判断を間近で見られるのは、かなり学びがありました。
また、自然と知見共有が生まれ、技術的な引き出しが増えた実感もあります。
新しい技術を試そうとする動きが活発だったのも印象的でした。
一方で反省点としては、月末開催だったため AI 利用枠がかなりギリギリだったことです。
次回はそのあたりも考慮し、月初での開催にしたいところです。
今後について
今回作ったプロダクトは、作って終わりにするつもりはありません。
MVP まで仕上げて部署内向けにリリースし、実際に使ってもらってフィードバックを集め継続的に改善していく予定です。
このスプラッシュデーをきっかけに、別のスプラッシュの進捗が自発的に生まれたり、
部署内外から「これ作れない？」と声をかけてもらえる状態を目指しています。
結果的に、チームのプレゼンス向上につながれば、この取り組みは成功だと思っています。
まとめ
今回は、社内ハッカソン「スプラッシュデー」についてまとめました。
インターン向けの企画に続き、今回は開発メンバーに向けた企画を実施することができました。
イベント企画において「目的を明確にすること」や、「会社にもたらす価値を意識すること」を改めて考える良い機会になりました。
今後、社内でイベントを企画しようとしている方の参考になれば幸いです。