オンラインITスクールのチーム開発型ハッカソンに、3回目の参加で初めてリーダーとして挑戦しました。
制作したのは、「めんどくさくない」をコンセプトにした家計簿アプリ「いくらつかった？」です。
5人チームの中で、私はリーダー兼フロントエンド担当として、Figmaでの全画面デザイン、フロントエンド実装、一部バックエンド実装、発表資料の作成を担当しました。
期間は1月4日の顔合わせから、2月28日の最終発表までの約2か月。この2か月の中に、開発途中での技術変更、デザインの全面作り直し、リーダーとしての進行管理が詰まっていました。
結果は5チーム中3位。1回目のハッカソンのような優勝の話ではありません。それでも、この2か月で向き合ったことは、今の私がチーム開発を進めるうえでの土台になっています。
この記事では、その過程を書きます。
目次
「続かない家計簿ユーザー」のためのアプリを、既存アプリの研究から設計する
1月4日の顔合わせから、要件定義とデザイン決定までに約2週間半。正直、ここが最初に手こずったところでした。
ペルソナは、家計簿を始めたいけれど、続かずに挫折してきた人。多くの家計簿アプリは初期設定や機能が多く、何を見ればいいか分からなくなることがあります。
だからこそ、私たちは正確さよりも続けられることを優先しました。口座連携や難しい設定なしで使える、シンプルな家計簿アプリを目指しました。
画面配置を決めるときは、既存の家計簿アプリを何個もダウンロードし、メンバー全員で触りました。
ここは使いやすい、この動線はもっとシンプルにしたい。そうした気づきを共有しながら、画面遷移案に落とし込んでいきました。自分の感覚だけではなく、実際のアプリの良し悪しをチームの共通言語にして設計を進めた形です。
開発2週間半、突然の技術変更
当初、フロントエンドはReactで進める予定でした。メンターにも相談しながら、ファイル構成やデザインの準備を進めていました。
しかし1月19日、ハッカソンの方針としてReactは使用しないことになり、進めていた構成を見直す必要が出てきました。
決まった以上、悩んでいる時間はありません。Reactを前提に作っていたデザインと実装計画を、残り期間でどう組み直すか。そこに頭を切り替えました。
そこからの5日間で、2つのことを並行して進めました。
1つは、技術の再調査です。Reactを使わない構成で何が使えるかを洗い直し、Tailwind CSSと組み合わせて使えるdaisyUIを見つけました。これなら、統一感のあるUIを短期間で組めると判断しました。
もう1つは、デザインの全面作り直しです。
新デザインは、やわらかい凹凸感のあるニューモーフィズムを基調にしました。理由は2つあります。
1つは、実装コストです。Tailwind CSSとdaisyUIでカード・ボタン・入力欄などの部品を使い回しやすく、残り期間でも統一感のあるUIを実現できると考えました。
もう1つは、ペルソナとの相性です。想定ユーザーである新卒一人暮らしの若い世代には、装飾の多い画面よりも、シンプルでシックな、家計簿を続けやすい落ち着いたデザインが合うと考えました。
実装しやすいか。ユーザーに合うか。技術とデザインの両面から成立する案として、1月24日までに全画面のデザインを完成させました。
前のデザインを気に入ってくれていたメンバーもいましたが、新しい案を共有すると「これもいいね」と受け入れてもらえました。チームの空気を切らさずに再スタートできたことは、大きかったと思います。
「動く状態」を絶やさないための備え
このハッカソンは、メンバー全員が本業と並行して参加していました。仕事が忙しい時期には進捗が遅れることもあります。それが5人チームとなると、調整の難しさは想像以上でした。
ただ、リーダーとして決めていたことがあります。
進捗が遅れているからといって、その人の担当をすぐに引き取って、学習の機会を奪うようなことはしたくない。全員が作りきったと言えるチームにしたい。
その一方で、期限までに完成させる責任もあります。この両立が、リーダーとしての一番の課題でした。
出した答えは、備えておくことです。
画面の実装と並行して、フロント側の動作確認に使う仮の処理も書き進めておきました。
そのうえで、事前に決めた期日までに間に合わない部分は、仮の形でつなぐことにしました。完成を最優先するための基準として、チームで共有していました。
切り替えの判断を期限ギリギリに迫られるのではなく、事前にチームの合意として持っておく。誰かを急かすのではなく、遅れが出ても完成まで持っていける仕組みを作る方向で、チームを進めました。
終盤は、この基準をもとに実装の分担を柔軟に組み替えながら、必要なところは自分でもバックエンドを書いて進めました。
結果として、予定していた機能はすべて完成しました。もしもの状況に備えていたからこそ、状況が変わっても慌てずに完成まで走り切れたのだと思っています。
デザインから実装まで、必要な機能を形にする
実装では、カレンダー表示、収支の入力・編集・削除、カテゴリ管理、共有機能、アカウント管理まわりを担当しました。
特に共有機能では、グループ・メンバー・作成者権限の関係を整理しました。
そのうえで、DBのテーブル設計からmodels、views、urls、templatesまで順に実装しました。
作成者と参加者で操作を分ける権限制御や、メールアドレスでユーザーを検索して招待する仕組みまで作り込みました。
フロント側では、JavaScriptでモーダルやスライダーの挙動を調整しました。Chart.jsを使い、支出の傾向を可視化する円グラフ画面も実装しました。
デザイン面では、ライトモードとダークモードの両方をFigmaで設計しました。
さらに、Figmaのフレーム名を実装ファイルのパスと対応させました。デザインと実装の紐づけが、チームの誰にでも分かる状態にするためです。
▼ 実装した画面。ダークモードの切り替えにも対応しています
深夜2時のチーム
この2か月は、リーダーとして気持ちが張り詰める場面も多くありました。それでも走り切れたのは、チームの存在です。
技術的に詰まったときに一緒に手を動かしてくれるメンバーがいて、深夜まで作業や相談をしながら進めた日もありました。あの時間は、今でも私のチーム開発の原風景になっています。
なお、AWSでの本番公開やAIによるレシート読み取りは、チームメンバーが担当してくれた領域です。自分の担当外を安心して任せられる体制があったことも、完成まで走り切れた大きな要因でした。
結果と学んだこと
最終発表は2月28日。結果は5チーム中3位でした。
悔しさはありますが、審査では発表資料やUI/UXについてコメントをいただきました。チームで形にしてきた内容を伝えるために資料を作り込み、デザイン面でも何度も見直してきた部分だったので、評価につながったことは大きな励みになりました。
デザインの全面作り直しを経てなお、UI/UXが評価ポイントとして残ったことは、あの5日間の判断が間違っていなかったという答え合わせになりました。
一番の学びは、リーダーの仕事は決めることよりも、備えることだということです。
技術の変更も、進捗の変動も、自分ではコントロールできません。でも、そうなったらどうするかを先に考えて動いておくことはできます。
仮の処理を用意し、切り替えの期日を事前に決めておくこと。それが、今回の開発で私なりに考えた備えでした。この姿勢は、これからどんな環境でも持ち続けたいと思っています。
3回のハッカソンを経て
1回目のハッカソンでは、一人のメンバーとしてVS Codeの操作から調べていました。
2回目のHabiではサブリーダーとして、Figmaプロトタイプによる要件定義の認識合わせを主導しました。
そして3回目の今回は、リーダーとしてデザイン・実装・進行管理・発表資料まで、チームの完成に必要なことを横断して担いました。
メンバー、サブリーダー、リーダー。役割が変わるたびに見える景色が変わることを、3回のチーム開発で体感してきました。
次はこの経験を、実務の場でのチーム開発や、ユーザーに届くUI実装につなげていきたいです。
