オンラインITスクールのチーム開発型ハッカソンで、明太子をテーマにしたチャットアプリ「Cod Roe～めんたいチャット～」を制作しました。結果として、7チーム中1位で優勝しました。
開発期間は約2か月、チームは4人（フロントエンド2名・バックエンド2名）。私はフロントエンド担当として、Figmaでの画面設計と、HTML/CSS/JavaScriptによる実装を担当しました。
こう書くと順調そうに見えますが、当時の私はHTML/CSSを本格的に書いた経験がほとんどなく、VS CodeもGitHubもFigmaも触るのが初めてでした。エディタの操作やコミットの仕方から調べる状態でのスタートです。
この記事では、そこからUI設計と実装を形にしていった過程を書きます。
目次
ペルソナから考えた、「明太子×チャットアプリ」の要件定義
お題は決まっていたものの、誰のために、何を解決するアプリなのかは白紙でした。要件定義という言葉自体が曖昧な状態だったので、開発初週はペルソナ設定から始めました。
チームで雑談を重ねながら、課題を具体化していくところからのスタートです。
その中で出てきたのが、明太子を食べる機会が減っていることや、価格が高く感じられることでした。福岡と明太子という地域性も踏まえて生まれたペルソナが、孫娘が明太子嫌いで悩む、75歳の明太子会社役員・原田太造さんです。
太造さんの悩みは、若者の明太子離れや、新たな需要の掘り起こしでした。そこに応える形で、可愛いキャラクターで若い世代に届く、明太子の需要を高めるチャットアプリという方向性を決定しました。
あわせてMVP（最低限必要な機能）と追加機能を早い段階で切り分けました。「まずMVPを完成させて中間発表へ、その後に追加機能」という流れで、スケジュールを組みました。
振り返ると、要件定義に約1週間、デザインは環境構築と並行して約1週間、残りを実装に充てる配分でした。最後まで大きくブレずに進められたのは、最初に方向性と優先順位を整理できたからだと思います。
キャラクター「めんたい」から始まった、世界観とUI設計
このハッカソンではAIの使用が禁止されていましたが、キャラクター画像の生成だけは許可されていました。そこで各自がキャラクターを生成してみることにしました。
思った通りには生成できませんでしたが、それぞれの案の良いところを組み合わせて調整していきました。その結果、アプリの顔となるキャラクター「めんたい」が生まれました。
UIの配色は、このめんたいのカラーを基準に決めました。感覚で色を選ぶのではなく、相性の良い3〜4色をまとめてくれる配色サイトのカラーチャートを使いました。
キャラクターの色を起点に、アプリ全体の配色ルールとして統一し、明太子らしい温かみのあるピンク系でまとめました。チャットアプリに親しみやすい世界観を持たせることを意識しています。
Figmaの使い方は、書籍と動画で基本を押さえつつ、ほとんどはとにかく手を動かすことで覚えました。画面設計では、ログイン・ホーム・チャットルームといった主要画面を先に作りました。
そこから、この画面にたどり着くまでにどんなページが必要かを逆算して、枝を広げていく進め方にしました。結果として、アカウント管理からチャットの作成・編集まで、25画面以上の遷移図としてまとまりました。
デザインは1人で抱え込まず、チームのチャットルームに「このデザインどう？」「ボタンはどっちがいい？」と頻繁に投げていました。フィードバックをもらい、週次ミーティングでも確認しながら進めました。
画面遷移の認識ズレを、プロトタイプで解決する
デザインが完成し、いざコーディングに入ろうというタイミングで問題が起きました。メンバー間で画面遷移の認識が合っていなかったのです。
静止画のデザインを見ているだけでは、このボタンを押したらどこへ行くのか、という解釈が人によって違っていました。
そこで、Figmaのプロトタイプ機能で画面同士をつなぎました。実際にタップして遷移を確認できる状態にして、すぐに共有しました。
動きとして見えるようになったことで認識のズレが解消され、その後の実装がスムーズに進みました。
この「言葉や静止画で伝わらないなら、動くもので見せる」という経験は、のちのチーム開発でも活きる大きな学びになりました。
Figmaで引いた線を、自分のコードで再現する
実装では、アカウント管理まわりを中心に、画面の実装を幅広く担当しました。
具体的には、新規登録画面、プロフィール画面、ユーザー名・メールアドレス・パスワード・プロフィール画像の変更画面、ホーム画面、チャット作成画面、チャットルームの各種設定変更画面などです。
JavaScriptでは、ホーム画面の「プライベート・グループ・オープン」3種類のチャットを切り替える部分を実装しました。
一番苦戦したのは、やはり最初のCSSです。Figma上ではきれいに見えていても、flexboxの挙動や親子要素の関係が理解できておらず、思い通りの配置になりませんでした。
書籍や動画で基礎を学び直しながら、ブラウザでの見え方を確認しては、Figmaとの差を詰めていきました。どうしても解決できないときは、メンバーやメンターと一緒に試行錯誤して乗り越えました。
環境構築で使ったDockerも初めてのツールでした。docker compose buildやdocker compose upといったコマンドをただ打つのではなく、何をしているのかを都度調べながら使うことを意識しました。
GitHubで肝を冷やした話
GitHubも「ブランチって何？」という状態からのスタートでした。フロントエンド2名で画面ごとに分担していたため、終盤はCSSの管理が複雑になり、コンフリクトも頻発しました。
中でも忘れられないのが、1週間ほどcommitをしていなかったときのことです。
stashの理解が浅いまま変更を退避し、本来必要だったpopができていませんでした。しかもstashに名前を付けていなかったので、どれが自分の作業内容なのかも分からない状態になってしまいました。
メンターに相談すると、「この中にもないなら、もう戻せない」と言われ、本当に肝を冷やしました。
この失敗から、こまめなcommit・stashへの命名・早めの差分整理の重要性を痛感しました。ブランチを切って作業すること、mainを最新にしてから取り込むことなど、基本的な流れも実践の中で身につけていきました。
週1回のミーティングに加えて、普段から作業部屋に自然と集まって「詰まったらすぐ聞ける」環境があったことも、1人で抱え込まずに進められた大きな要因です。
結果と学んだこと
最終発表では、中間発表に続き、発表資料の作成を担当しました。チームとして伝えたい内容を整理し、機能・UI/UX・デモ・発表まで一貫した形で臨めるように準備しました。
結果は7チーム中1位での優勝でした。
評価項目には、「直感的で誰でも使いやすいUI/UX」や「プロダクトの一貫性」が含まれていました。キャラクターの色を起点に配色ルールを作り、世界観を統一してきた設計が評価につながったことは、大きな自信になりました。
一番の学びは、デザインと実装はつながっているということです。
画面を作るときには、見た目の雰囲気だけでなく、実装のしやすさや、ユーザーが迷わず操作できるかまで考える必要があります。
Figmaで引いた線を自分のコードで再現する経験を通して、それを体感しました。
この経験が、次のチーム開発の土台になった
このハッカソンで痛感した、先に可視化する大切さは、その後の開発に直結しています。
2回目のチーム開発（人生の目標管理アプリ「Habi」）では、要件定義の段階で自らFigmaプロトタイプを作成して認識合わせを主導しました。
3回目の家計簿アプリ「いくらつかった？」では、リーダーとして技術選定やUIの共通ルール設計、進行管理を担当しています。
VS Codeの操作から調べていた1回目から、設計と進行を担う3回目まで。この初めてのハッカソンが、私の開発スタイルの原点になっています。
この経験を通して、私は先に可視化して認識をそろえることと、デザインの意図を実装で再現することを大切にするようになりました。現在の制作やチーム開発でも、この視点を軸に取り組んでいます。
