1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

人生2回目のチーム開発を行いまして(アニメ聖地巡礼アプリ開発)

Posted at

1.はじめに

自分は10月よりAPPRENTICE SHIP(内定直結型エンジニア学習プログラム)のカリキュラムに2期生として参加しています。
この記事は2回目のチーム開発を行なって、振り返りを記事にしたものとなります。

2.イントロ:前回の振り返り

前回、フルスタックフレームワークを使用せずにチーム開発を行いました。
その中での反省点が色々と浮き彫りになりました。
今回の開発ではその反省を踏まえて開発ができたのでしょうか?
前回のチーム開発備忘録の記事

3.2回目の開発体制と開発テーマ

さて、開発体制ですが1人増え4人体制となりました。
前回同様、初対面の方々と開発していく流れとなります。
その中で開発するテーマが「ワクワクするものを開発せよ!」
なかなかに掴みどころのない、テーマでしたが我々のチームはワクワクというテーマをどう捉えたかというと。。。

4.みんなで作る聖地巡礼アプリ「Animecca」

どういったアプリか?

ワクワクすると言えば色々あるとは思いますが、チーム内ではワクワクする体験をということで各自アイデアを持ち寄り、聖地巡礼アプリ「Animecca」を開発しました。

Animeccaは読んで字の如く、"アニメ"+"聖地"というアニメの聖地を探す、登録できるSNS型のアプリになります。

このアプリの特徴は

  • 何話のどのシーンで舞台となったか細かいところまで登録できる。
  • アニメ内に複数出てきた聖地を登録できる。
  • 自分の行きたい聖地をコレクションしておける。

など、既存のアプリでは出来なかった、細かいところまで登録できる聖地巡礼アプリを目指して開発をされました。

トップ画面
トップ画面では主に、都道府県または作品名から検索ができるようになっています。
localhost_3000_.png

都道府県検索結果画面
例えばですが、東京都で検索をするとGoogleMapが表示され、各聖地がピンで表示されます。
localhost_3000_prefecture_%E6%9D%B1%E4%BA%AC%E9%83%BD.png

聖地詳細画面
詳細画面では、どの話数、どこの秒数で出てきたかまで見れるようになっています。
localhost_3000_mecca_new (1).png

どういう技術で作られているか?

簡易アーキテクチャ図
名称未設定2.001.jpeg
フロントエンド : Next.js(TailwindCSS使用)
バックエンド : Ruby On Rails (APIモード)
DB : SQLite(開発環境のためRails標準のものを使用)
外部API : GoogleMap API / Aannict API
ソースコード管理 : Git/GitHub
環境構築 : Docker

5.開発

担当作業

主だった作業は全員で進めていきましたが、

  • dockerでの全体環境構築
  • バックエンド全般

の二つをメインを行いました。

前半 : アイディア出し〜要件定義

今回のチームでのアイデア出しは簡素に行い、全員が持ち寄った案の中から決めるものとなりました。
前回の開発では時間を掛けて考えていただけに、あっさりと決まりました。
要件定義では、ワイヤーフレームなども各自で考えたものをまとめて反映されるのはすごく良かったと思います。

良かった点

  • 早めに案が決まり、要件定義や設計に時間を割けたため、時間に余裕ができたのは良かった
  • 要件定義の部分でも、既存アプリに沿った作りとなったため、あまり迷わずに決めることができた

悪かった点

  • コンセプトは良かったが、既存のアプリとの差別化や、何に重きを置いて作るのかが迷走し掛けてしまった

中盤 : 設計〜タスクだし

設計段階では、環境構築まわりとバックエンド周りを担当しました。
前回開発で諦めてしまった、Dockerでの環境構築を行いました。
時間は掛かりましたが、この段階で動くところまで持って行けたので良かったです。

良かった点

  • Dockerでの環境構築はチーム内で共有することができた
  • APIなども各自考えたものをまとめたので認識ズレが途中で起きるなどがなかった
  • DB設計についても同じことが言える

悪かった点

  • Dokerは時間がかかることが予想されたため、早めに取り掛かっていたが、詰まったところでチーム内に情報を共有するなどが出来ていなかった

後半 : 開発〜ハッカソン

開発では、フロントとバックに分かれて開発を行い、バックエンドを中心に開発を行いました。
設計段階でAPIの設計をまとめて頂いたおかげで、ほとんど詰まることなく開発を行うことが出来ました。

良かった点

  • 何はともあれ、ハッカソンまでに動くものを作れたのは良かった
  • 責任範囲分担をすることで、開発に集中することができた

悪かった点

  • フロントとバックエンドの連携を確かめるのが、最後の最後になってしまい細かいところ直すのに余裕を持たせられなかった

全体を通しての改善点

  • 開発段階など情報交換 (特にフロントとバックエンドの間)が少ないように感じたので、もう少し連絡を密に取る必要があると思った。
  • Dockerを使用して、1メンバーでアプリの動作に不備が残ってしまったので、そういったことを早めに解消できる仕組みを作る必要性があった。

6.所感

2回目ということもあり、前回の反省を踏まえた上で開発が行えたので、詰まる箇所が少なくなりました。
ですが、Dockerでの環境構築がとりあえず動く状態で開発に移ったので、後半でエラーに詰まったりなど、時間を割くことが多かったです。
個人開発までには、環境構築は深掘りできたらと思う所存です。
ハッカソンではベストアワードは逃したものの、コメントを頂けたりなど、開発期間が短いながらもちゃんとしたものを作れたのは嬉しかったです。
次回はいよいよ、個人開発に移りますが今回の反省点を活かして開発をしていきたいです。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?