はじめに
今回は、大学の文化祭で使うWebアプリケーションを用件定義から設計、開発まで行なった話をしたいと思います。
プロのエンジニアから見ると拙い部分が多々あると思いますが、やさしい気持ちで見ていただけると嬉しいです。
恐怖の単独爆速開発計画
知人のサークルから謎解きイベントの解答システムを作ってほしいと誘われ、ユーザーのいるサービスを個人で開発した経験がなかったこともあり、良い機会だと考えて参画を決めました。
しかし、開発メンバーがなかなか集まらず、ようやく見つけたメンバーも開発直前に離脱してしまい、最終的に1人で開発を進める状況となりました。この話をいただいたのが8月末で、要件定義に取り掛かったのは9月から。文化祭が11月2日から4日だったため、実際に開発に充てられる期間は約1ヶ月というタイトなスケジュールでした。
チームには、自分以外にマーケティング（SNS運用など）、クリエイティブ（チラシ作成やアプリ用アセット制作）、謎解きの企画などを担当する約10名が参加していました。そのため、アプリが完成しなければ企画全体が成立しなくなるというプレッシャーを感じながら、開発を進めざるを得ない状況でした。
最速最良を目指すための要件定義
今回は、開発を始める前からカツカツの開発計画になることは目に見えていたので、できるだけ手戻りをなくしたいという思いから、要件定義は特に慎重に、丁寧に行なっていきました。
とはいえ、開発にできる限り早く着手するために、優先順位を明確にしてヒヤリングを行いました。特に、データベース構造に関わる部分（来客したグループのメンバー数は必要か？、来客日時は必要か？etc...）を最優先して決定してもらうように要求していきました。
また、エンジニア的な思想（こっちの方が実装しやすい等）がプロダクトに入り込まないように、小さなことでも逐次質問をしながら、設計を行なっていきました。
開発環境
技術選定
サクッとプロトタイプを作成して、他のメンバーにチェックしてもらうために、自分が一番慣れている技術を用いて開発を行いました。デプロイする際に動かなくなるのは面倒だったので、初めからDockerを用いて開発環境を整えています。
フロントのUIライブラリは、使ったことのないYamada UIを使ってみました。公式ドキュメントの使用例にドランゴンボールがたくさん出てきて面白かったです。
CI・CDの活用
開発を進めやすくするためにをCIを活用しました。サクサクと開発を進めるとコード品質が落ちてしまったり、Buildに落ちていることに気づかず、デプロイするときに修正する必要が生じたりなど、面倒なことになるので、開発初期からCIを整備しておきました。
また、手元の開発環境でもフロントエンドではBiomeでバックエンドではRuffを用いて自動フォーマッタを行いました。また、OpenAPIを用いてクライアントを自動生成することでAPI接続の手間を減らしました。初めて使用した技術でしたが、採用して良かったなと思います。
またCDについてはフロントエンドはAmplifyに、バックエンドはOIDCを用いてGitHubActionsからECRへイメージをpushするところまで行っています。（見ない間にAmplifyへのデプロイがすごく楽になっていて驚きました）
インフラ
こちらも開発初期からデプロイを行い、デプロイ環境で問題が生じないかを常に確認しながら開発を行いました。実際に作成したインフラ環境は以下です。
AWSを用いなくてもよかったのですが、個人的な勉強も兼ねてAWSを用いたインフラ構築を行いました。今回はマネコンをぽちぽちしながら作りましたが、次はIaCにも挑戦したいなぁ。と思っています。
意識したこと
文化祭でお金をいただくにしても、できるだけインフラにお金はかけたくないので、無料枠をフル活用してインフラを構築しました。今回の文化祭は3日間しか行われないため、できるだけサーバーレスな構成を目指しています。実際、インフラにかかった費用は0円でした。
また、3日間の文化祭の中で仮説検証を回していくために、来客数のデータ等を柔軟に取ってくるニーズがあったので、踏み台サーバーをEC2を用いて構築し、SQLを自由に叩けるようにしました。
課題
今回、DBもDynamoDBにしたかったのですが、そこまで多くのデータは保存されないこと、RDBでの開発の方が慣れているということもありRDSを採用しています。しかし、Lambdaとの疎通を取ろうとすると、LambdaをVPCに入れないといけなかったりRDS Proxyを挟まなくてはいけなかったり考慮すべき点が多くありました。今回は、アクセス数を見積もった時に必要ないと判断して、ここまできたら無料で構築してやろうと思い、RDS Proxy入れていません。
また、LambdaがECRからイメージを取得する時もNatGateway等で疎通をとる必要があると思いますが、有料なので今回は入れていません。次開発する機会があったら、SupabaseとかFirebase等のBaasを使います。。。
開発スケジュール
先述した通り、開発に割ける時間はわずか1ヶ月で、別でおこなっているインターンのタスクや大学の講義の合間を縫って開発を進めていきました。要件定義と全体設計は9月中に隔週でのミーティングを通して行い、10月から実装に入っていきました。
ここから、DBのスキーマを定義して、API開発を行っていきました。ここも設計を丁寧に行っていたので微修正はあったものの、3日程度で15個ほどのエンドポイントをサクッと実装できました。
最後に、フロントエンドを1週間かけて完成させて、チームメンバーからのフィードバックを受けました。開発期間は短かったものの、焦らず丁寧に要件を擦り合わせていたので、クリティカルな手戻りは発生せず、順調に実装を進めることができました。
完成したもの
クリエイティブメンバーのUIデザインをフロントで実装しました。実は大学では誰もが使用する授業支援システムのUIを真似ており、当日も非常に好評でした。
このアプリでは、メンバーの登録と、解答システム（正誤判定・秒数表示・ヒント表示）、点数計算（評定を出すところまで）を行っています。技術的な中身の話は色々と行いたいですが、ここでは割愛します。
また、自分以外のメンバーが自由に問題を追加・削除できるようにするために、管理画面も作成しました。全部で20個ほどの問題のバリエーションがあるのですが、自由に追加・削除できるようにしました。
まあ、SQLをGUIから叩けるようにしたぐらいの簡素なものですが。。自由に点数と来客数を見れるように、グループの情報も表示するようにしています。
文化祭初日
十分なテストができていない状態だったので、構成上全てが落ちることはないにせよ、ハラハラしながら本番を迎えましたが、結果的には元気に動いてくれてホッとしました。
初日はあいにくの雨で客足が少なかったのですが、運用上の問題点等が多く見つかりました。具体的には、謎解き前の説明に割く時間が長かったり、満員になった時にどのように待ち列を対処するか等の問題点が上がりました。また、客数のデータを見るとお昼時の来客数が顕著に減っているため、この時間帯にビラ配り等の集客施策をとる等の作戦を練りました。
文化祭2、3日目
2、3日目は、想定していた倍以上のお客さんに来ていただきました。オペレーションの大改善や施策がうまくはまり、天候による影響もあるかとは思いますが、多くのお客さんに謎解きを行ってもらうことができました！
結果的に、1292名もの方にアプリを利用していただけました。売り上げも目標の150%を達成し、とても満足のいく結果となりました。また、文化祭全体の満足度アンケートでも3位になり、客観的な良い評価も得ることができました。
感想
ユーザーが自分の開発したアプリケーションを実際に利用し、楽しんでいる姿を目の当たりにすることができたのは、非常に貴重な経験でした。これまで個人でユーザーを持つサービスを開発したことがなかったため、この体験が今後の開発への大きなモチベーションにつながりました。また、要件定義から設計、実装、運用までを一貫して1人で行えたことで、大きな自信を得ることができました。
さらに、エンジニアとの協業経験はあったものの、今回のようにビジネスメンバーと連携するのは初めてで、とても刺激的で学びの多い機会となりました。自分の書いたコードがプロジェクト全体に与える影響を実感したり、エンジニアが関わらなくても業務のパフォーマンスを大きく改善できる場面を経験したりと、多くの発見がありました。
おわりに
ここまで読んでいただきありがとうございました。
ご指摘やアドバイスがあればコメントで教えていただけると幸いです。