目次
1. はじめに
2. 制作したアプリについて
3. 開発手順
4. 担当した箇所
5. 振り返り
6. おわりに
1. はじめに
私は現在『アプレンティス』というエンジニア実習サービスに参加して、プログラミングの学習をしています。アプレンティスでは、受講生同士で 3 ～ 4 人のチームになりアプリを開発するという課題があります。今回はその第 2 回目となります。
前回のチーム開発の記事はこちらです。
前回は複数人での開発が初めてだったため分からないことだらけで、色々な苦労やトラブルがありました。それを何とか乗り切り、多くの学びや反省を得た体験となりました。
今回は、その反省を活かして開発を進めていきたいと考えていました。開発を終えてみて、前回とはまた違った苦労や学びがあったのでまとめていきたいと思います。
2. 制作したアプリについて
制作したアプリは、『みんなで作る全国聖地巡礼マップ Animecca』 です。
テーマ
今回のチーム開発のテーマは、『ワクワクするものを開発せよ』 です。チームメンバー各自がアイデアを考えて持ち寄り、その中から『聖地巡礼マップ』を作ることに決まりました。大好きなアニメの舞台となった場所に訪れる、そんなワクワクする体験をサポートできるようなアプリを作成していきたいと思います。
Animecca のコンセプト
まず私たちは、既存の聖地巡礼マップサービスを探してみました。その多くは人気の聖地を選定して載せている情報サイトで、ユーザーが自分で聖地を投稿することはできないものでした。ユーザーが投稿できそうなサイトも見つけたのですが、その機能は現在稼働していないようでした。
聖地の情報は、既存の情報サイトで探せるかもしれません。ですが、訪れた聖地の情報や感動した体験を、同じアニメ好きの人と共有したいと思うアニメファンも多いはずです。
そこで、ユーザーが聖地を投稿したりマイリストを作れる SNS 型の聖地巡礼マップアプリを作成しようということになりました。私たちは、以下のようなユーザーの需要に応えたいと考えました。
- 有名なあの聖地だけではなくて、自分が好きなシーンのこんな聖地も知ってほしい！
- 自分だけの行きたいリストを作って眺めて、次はどこに行こうかワクワクしたい！
- 訪れた聖地を地図にまとめてコレクションしておきたい！
- 情報サイトには載っていないマイナーな聖地、今期アニメ最新の聖地情報も知りたい！
アプリの機能
Animecca の主な機能を紹介します。
トップ画面：
日本地図または作品名から聖地を検索できます。
検索結果画面：
例として東京都で検索した結果です。東京都に登録されている聖地一覧と、地図にはピンが表示されます。
詳細画面：
検索画面やマイリストから詳細画面に遷移できます。
ユーザー登録 / ログイン画面：
ユーザー登録をし、ログインするとトークンが発行されます。聖地の登録やマイリスト機能などはトークンを検証することで行います。
聖地登録画面：
聖地の登録では、その聖地が登場するシーンの秒数という細かい情報を登録できるのもポイントです。
アニメタイトルは外部 API から取得しており、予測変換でタイトルが出るようになっています。
聖地の場所は施設名などを入力して検索し、地図から候補を選択することができます。
マイリスト画面：
検索結果画面や詳細画面でハートマークをクリックすると、マイリストに登録ができます。マイリストに登録している聖地一覧と、地図にはピンが表示されます。
使用技術
フロントエンド：Next.js / Tailwind CSS
バックエンド：Ruby on Rails
データベース：SQLite
開発環境：Docker Compose
インフラ：なし (今回はローカルで開発しました。)
ソース管理：Git / GitHub
外部 API： Google Maps Platform API (Places API / Maps JavaScript API) / Annict Developers
3. 開発手順
Step1. 前回チーム開発の反省点などを共有
アプリのテーマが決まった後は、前回のチーム開発で設計や開発をどのように進めたかといったことや反省点を共有しました。
チームの一人は、メンバー同士のOSやソフトウェアのバージョンの違いで大変な思いをしたとのことで、開発環境には Docker を導入しようということになりました。
私は、前回は開発中盤まで進捗管理をせずに進めてしまっていたという反省から、今回は早い段階で PM を決めたいと思っていました。ですが今回は毎週 PM を交代制で回すという決まりがあったので良かったです。自分の番にしっかりと務めようと思いました。
Step2. 外部 API の調査と確認
実装したい機能として、施設名からの場所検索や地図の表示、正式なアニメタイトルの取得などがありました。これらの機能には外部 API が必要だということは分かりますが、想定している使い方が実際にできるかどうかが分からなかったため、分担して調査し機能を確認しました。
Step3. 設計
チーム会を重ねながら皆で設計を進めていきました。
画面ラフ
ワイヤーフレーム
テーブル設計
Step4. 環境構築
チームの方が Docker で環境構築をし、GitHub 上にプロジェクトを作成してくれました。
Step5. エンドポイントの設計
実装する機能がほぼ固まったところで、エンドポイントの設計書を作成しました。
Step6. デザインイメージ決定
それぞれ参考サイトを持ち寄り、見た目のイメージをすり合わせました。
Step7. 役割分担とタスク出し
フロントエンドとバックエンドで 2 人ずつに分かれることにしました。私はフロント担当になったので、ここからはフロントの作業を進めていきます。
フロントエンドのタスク出しをして、もう一人のフロントエンド担当の方とページごとに分担して進めることにしました。
Step8. 実装
フロント環境構築
前回のチーム開発でコーディングルールを決めていなかったという反省点があったため、今回は静的解析ツールと整形ツールを入れようと決めていました。
ESLintと Prettier を導入し設定ファイルを作成し、Next.js のディレクトリ構成も決めて環境構築を行いました。
以下の記事を参考にしました。
実装
ここまで来たらついに実装に入ります！こうして記事を書いてみると、実装はプロジェクトの数ある工程の一つに過ぎないのだなと改めて思いました。コンセプトや設計など基盤をしっかり作った上で実装に進むことが大切だなと思いました。
4. 担当した箇所
以下の作業を主に担当しました。
- 画面遷移図ラフ
- デザインラフ (figma)
- API 設計書
- フロントエンドの環境構築
- Google Maps API 周りの機能
- フロント側の登録機能、表示機能等
5. 振り返り
良かった点
・ API 設計書を作成したこと
当たり前すぎるかもしれませんが、実際に進める中で、作っておくと便利というより作っておかないといけないものだということが分かりました。設計書を元にバックエンド担当の方が機能提供のエンドポイントを実装してくれて、私も設計書を見てレスポンス内容を確認しながらフロントエンドの実装を進めました。
今回私が作成した設計書は、今見ると情報が全く足りていないのですが...今後作成する際は、エラーレスポンスなども含めしっかり設計しておけば、この後の開発をスムーズに進められるだろうということが分かり勉強になりました。
・ フロントとバックを切り離して作業を進められた
エンドポイントを利用した設計にしたため、フロントエンドとバックエンドで作業を分担して進めることができました。前回のチーム開発の時はエンドポイントというもの自体知らなかったので、だいぶ成長を感じました。
バックエンド担当の方が実装してくれたエンドポイントにリクエストを投げれば機能を使えることに感動しました。バックエンドと相談しながら必要なレスポンスを足してもらうなどのやり取りをして、実際の開発現場のことが少しだけ想像できた気がして嬉しかったです。
・ ローテーションで PM
今回のチーム開発では、PM 担当を週ごとに回していくというルールがありました。前回のチーム開発での反省から、発表日から逆算した計画を早めに立てたいと思っていました。自分が PM 担当の週に、発表までのスケジュールを可視化して共有したり、毎回のチーム会の内容(議題、決めたこと、次回までの課題)を残せるように議事録を書きました。チームを前に進められるように自分なりに努力しました。
反省点や大変だったこと
・ チームでの開発環境の共有
Docker 環境でフレームワークや JWT 認証、外部 API などを使ったためか、Docker 周りその他のエラーが度々起きて苦労しました。今の知識ではエラーの原因特定や対処も難しいなと感じましたが、経験を積んでできるようになっていければと思いました。
問題は、チーム全員の環境構築が問題なくできたかを確認するという基本的なことを怠ってしまったことです。環境構築を早めに済ませることまではチームの方がやってくださったのですが、その後チーム全員の環境構築ができたかどうかを最優先で確認してから、実装に進むべきでした。
・ フロントエンドとバックエンドでの進捗共有
フロントエンドとバックエンドを分けて作業できたのは良かったのですが、微妙に足並みがそろわず、お互いにまだペアとなる機能ができていないので実際に動くかどうか試せないという状況が発表会数日前まで続いていました。フロントエンドとバックエンドでこまめに報告しあい、早い段階で連携がうまくいっているかを確認しながら進めないといけなかったなと思いました。どの機能から作っていくかといった打ち合わせも必要でした。
・ フロントエンドの作業分担の方法
今回はもう一人のフロント担当の方とページごとに分担したのですが、共通の機能やデザイン部分をどう進めるかが難しかったです。共通コンポーネントを二人ともいじってしまったり、別ページの似た機能をそれぞれ作っていたりということがありました。
バックエンドとフロントエンド間と同様に、やはりもっとよく話し合って、実装順序や分担を細かく決めておくことが必要だなと思いました。バックエンドとの連携をもっと早くしたかったことから考えても、まずは機能から作ってバックエンドと連携させていくのが良いのかなと思いました。
発表会後のメンターさんからのアドバイスで、報告というよりも毎日進捗を一言二言だけでもつぶやくことを習慣化するのもいいよとのことで、これはぜひ取り入れたいなと思いました。
6. おわりに
今後について
チーム皆で一生懸命作った Animecca ですが、残念ながら賞をいただくことはできませんでした。ですが講評では、テーマが面白いと褒めていただきました。『テーマを決めて、それに必要な機能を素直に実装していて良いと思った』というコメントが心に残っています。必要な機能は作れているけど、あと一歩何かが刺さらなかったのかなとも思いました。
このあたりをもっと掘り下げて、地図の機能をもっと充実させたり、マイリストをもっとわくわくする仕様にしたり、など想像は広がります。
講師の方から、実際にユーザーがついたプロダクトに成長させるところまで開発を続けてはどうかというありがたい提案をいただきました。それには機能追加、エラー処理、セキュリティ対策、宣伝などが必要で、とても勉強になりそうだし実際に使ってもらえたら嬉しいし挑戦してみたい気持ちにはなりました。ですが、まずは各自オリジナルプロダクトに集中しようということになりました。今回はこれで Animecca プロジェクトはいったん解散となりますが、またチャレンジしたいです！
まとめ
フレームワークの導入やエンドポイントを介してやり取りしたり、外部 API を使ったりと、前回よりだいぶ本格的な開発体験ができたのではないかなと思います。チームのことを考えながら実装を進めるのは一人とは違ったやりがいがあるし、一人では作れないようなものが作れて楽しいです。
今回は諦めましたが、運営のことまで想像できたのも良かったです。今回学んだこと大変だったことを今後に活かしてこれからも頑張っていきたいです。