はじめに
今回のWebアプリケーションは「ワクワクするものを作ろう」というコンセプトで作成しました。ワクワクするものって何だろうというところを考えるところからこの開発はスタートし、なんとか形にできたので共有したいと思い、この記事を書いています。作成したWebアプリケーションは、「みんなで作る全国聖地巡礼マップAnimecca」です。正直未熟な部分もあるかと思いますが、温かい目で見て頂ければ幸いです。開発背景
なぜこのアプリを作ったのか。どんな課題を解決したのかについて記載します。チームメンバーでワクワクするものについて話し合うところからスタートしました。まず、自分がワクワクすることについて、それぞれ書き出し共有しました。例えば、「旅行に行くとき」・「アニメを見ること」・「コンビニの新しいスイーツ」等さまざまな意見が出ました。ふと、アニメ好きのチームメンバーの1人が旅行の話になったとき、アニメの聖地巡礼マップが使いにくいという話を聞きました。そこで実際に既存の聖地巡礼マップを見ていくと、聖地情報がきれいにまとめられているサイトだけども共有機能がなかったり、聖地情報を共有して投稿できるサイトだけどサービスが終了していたり、そもそも聖地の情報が少なく実際にアニメのどのシーンなのかといったことが分からないといった課題を発見しました。であれば、それぞれのサイトのよい部分を集めて作れば、アニメ好きのユーザーが聖地巡礼旅行を計画しやすくなるし、同じような趣味の人たち同士で聖地を共有できるというワクワクする体験を提供できるのではないかと考え、開発をスタートしました。
使用技術
・フロントエンド: React/Next.js/TailwindCSS・バックエンド: Ruby on Rails
・DB:SQLite
・開発環境: Docker/Docker Compose
・外部API: AnictAPI/GoogleMapsAPI
・ソース管理: Git/Github
完成したアプリと機能一覧
TOPページとハンバーガーメニューここでは聖地を日本地図から探したり、作品から探したりできます。（北海道がハンバーガーメニューで隠れています…）
聖地登録ページ
ここでは聖地の登録ができます。作品名、話数、どのシーンなのか、聖地名、場所、概要、画像を登録できます。作品名はAnictのAPIから作品Titleを取ってきているので、検索の文字に応じて予測変換が出てきます。
GoogleMapsAPIを使っているため、場所はグーグルマップにピンを刺して入力することができます。
聖地一覧ページ
ここは東京の聖地一覧です。自分や他のユーザーが登録した情報を見ることができます。右側をクリックすると、ページ詳細に遷移できます。
聖地詳細ページ
聖地詳細ページです。聖地の登録で登録した内容を見ることができます。ハートマークをクリックすると、マイリストに登録できます。
マイリストページ
ここは他のユーザーの投稿した聖地情報をまとめておくことができます。
ログイン・会員登録ページ
ログインページと会員登録ができます。JWT認証を使っています。また、パスワードは6文字以上で名前の被りがないようにバリデーションを設けています。
私がやったこと
・要件定義・画面遷移図作成
・ER図作成とDB設計
・ワイヤーフレームの作成
・TOPページの実装
・ハンバーガーメニューの実装
・ログインと会員登録ページのひな型の実装
・ロゴの作成
・発表スライド・原稿作成
・発表
要件定義
ここではどんなことがアプリではできるのかを決めました。・登録する項目は作品名、何話、何分・何秒のシーン、場所、実写の画像、概要（感想、場所の詳細情報など）
・地図と作品名から検索できる
・ユーザーが行った聖地を登録できる（公開する）
・ユーザー登録
・ユーザーが行きたい聖地リストを登録できる（マイページのみ）
画面遷移図
簡易的な画面遷移図です。当初はどの画面からでもハンバーガーメニューで遷移できるようにしようと考えていました。ただTOP画面から詳細画面にはいく必要ないことに気づき、最終的に各都道府県の聖地一覧ページとマイリストから遷移するようにしました。
ER図とDB設計
Webアプリケーションを運用するにあたってどのような情報が必要か洗い出してその関係性を明確にしました。DB設計
ER図
環境構築
チームメンバーの中に、以前Dockerを使っての開発経験がある方がいらっしゃったので、その方にイメージファイルを作ってもらい、メンバーの環境を整えました。正直私はDockerに関するキャッチアップをしていなかったので、その方が作ってくださったドキュメントをみて、ローカル環境を構築しました。（ありがたい…）オリジナルのプロダクトを作るときは、キャッチアップして取り入れてみたいです。実装してみて思ったこと
Topページ
TOPページの日本地図から探すところの実装が自分にとって複雑なデザインだったので、どうやって実装するか悩みました。デザインしていた時はそんなに苦労しないだろうと安易に考えていましたが、実際に実装してみるとそんなことは全くなかったです。よくエンジニアとデザイナーの仲が悪くなりやすいみたいな話を聞きますが、まさか過去の自分との仲が悪くなるとは思いませんでした。
どうやって解決したかというと、似たようなデザインのサイトを探してきて、そのサイトをディベロッパーツールで検証しました。その結果、Position:absoluteにTopとLeftの位置を細かく調整して作られていることに気づき、その方法を参考にして、無事それっぽいものを作ることができました。
もっと良くするなら、ホバーしたときに文字の色を変える等、ユーザーにとって分かりやすくなるようにするとよかったなと思いました。
ハンバーガーメニュー
最初はヘッダーに機能を設置しようと思っていましたが、ハンバーガーメニューの方がすっきりしていいと思うという意見から実装することになりました。実装期間が1週間という縛りがあったため、Qiitaの記事を参考にハンバーガーメニューの実装を行いました。ハンバーガーメニューを開くと、他のコンテンツが見にくくなるという問題があったため、CSSを調整し小さくコンパクトに収まるよう改善しました。
ロゴの作成
Figmaというアプリを使って作成しました。デザインはAIにそれっぽい画像を作ってもらい、それをトレースする形で作成しました。
発表
本来別の方が発表する予定でしたが、発表前日にその方のローカル環境がその方特有のエラーでアプリが動作しないという問題が起きました。当日までにその問題が解決しなかったため、急遽私が発表することになりました。メンバーさんにもスライドの添削を手伝っていただき、発表数分前まで練習するというギリギリの状態になってしまいました。ワンスライドワンメッセージを意識して、伝わりやすい構成を意識して作りました。どうなるかと思いましたが、結果的に他のメンバーやメンターさんからも良かったと言ってもらえて安心しました。
作品自体の評価について
結果的に聖地巡礼というテーマとワクワクするものを作るというコンセプトが一致していたため、全体で2番目という評価をいただくことができました。他のチームの皆さんが作られた作品も全部素晴らしくて、中にはそのままサービスとして出せるぐらいクオリティの高い作品もありました。
チームの良かった部分と課題
良かったところ
・プロダクトのテーマが良かった。
・ルール決めを最初のしていたのが良かった。
・作るものを早く決められたのが良かった。
・バックエンドとフロントのコミュニケーションがよく取れていた。
・進捗報告ができた。
・Docker導入できた。
・画面共有で分からないところをみんなで解決する努力をした。
改善するところ
・最後の方はもっとチーム会を開催した方が良かった。
・連携が最後の最後になった。
・最初の方はだれがいつなにをしているのか把握してなかった。
・Docker環境が原因でエラーが多発した。
・発表者の問題が発覚した時点で、エラーが解決できないことを考慮して誰が代わりにやるか決めておくべきだった。
TRYすること
・最初にAPIなどバックとフロントがつながる部分をいつ作るのか最初に決めた方が良かった。
・環境構築の事前通告をもっとするべき。
・技術について人任せにせず、自分たちも調べる。
・困っていることをしっかり伝える。
・新規性を掘りさげる
・競合調査をもっとする。
個人の良かった部分と課題
良かったところ
・プレゼンをうまくできた。
・複雑なデザインを実装できた。
・ハンバーガーメニューが実装できた。
・チームの意見がまとまらず膠着状態のときに、何か発言して前に進めることができた。
・レスポンスを早く返すことを意識して実行した。
改善点
・もっとロジカルな実装の部分をできたらよかった。
・JavaScriptの理解が低い。
・考えがまとまってないのに、とりあえず発言してみることが多かったので、説明し直すことが何度かあった。
TRYすること
・JavaScriptの勉強を頑張る。
・もっと自分からこのタスクをやりますぐらいの主体性をもつ。
・論理的思考を意識する。
最後に
ここまで読んでくださりありがとうございました。前回のチーム開発よりもモダンな技術を使って開発することができたことや、他のメンバーさんの技術力の高さを肌で感じられたことは自分にとって良い経験になったと思います。それと同時に、自身の技術力の低さ等の問題点も浮き彫りになり、それをひしひしと感じています。次はオリジナルプロダクトの作成に入るので、技術力の低さはそこで苦しみながら身に着けていきたいと思います。