0
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?

More than 1 year has passed since last update.

チーム開発にて「買い物リスト作成アプリ」を作成した話

Posted at

1. はじめに

私はWEBエンジニアを目指す24歳です。

現在、株式会社ユーブルが運営しているアプレンティスシップに参加させていただいており、WEBエンジニアに必要な技術を習得すべく日々精進しております。

今回は、アプレンティスシップの一貫でチーム開発を初めて経験することが出来たため、振り返りをしていきたいと思います。

私達のチーム「エッグコーダーズ」が作成したWebアプリケーションは「料理人の助けとなる買い物リスト作成アプリ」です。その名も「レシピヨ!」。

チームメンバー全員がチーム開発が初めてであったため、反省すべき点は多くありましたが非常に良い経験になりました。開発エピソードをまとめましたので、最後まで読んでいただけると嬉しいです。

2. チーム開発の要件

期間 :2023/10/30(月) 〜 2023/12/4(月)

テーマ:自分たちの役に立つものを開発せよ

ベース:HTML/CSS/JavaScript/MySQL/Ruby or PHPを使用
※ Rails, Laravel, React などのフレームワークは使用しないこと

3. 開発背景

私は社会人になってから一人暮らしを始め、自炊をするようになりました。平日は仕事で買い物に行けないことが多いため、基本は休日に1週間分の食材をまとめて購入しています。そんな私が常日頃から抱えていた悩みが2つありました。

悩み1. 必要な食材の数(量)を考えるのがめんどくさい

1週間分の食材をまとめて購入するため、同じ食材を複数の料理で使用することがございます。そのため、どの料理にどれくらいの量が必要なのかを考え購入しないと、足らなかったり余ってしまったりする原因になってしまいます。

悩み2. 食材を買い忘れてしまう

買い出しから家に帰った時や料理をする時に買い忘れに気づき、スーパーに走ったり諦めることが度々ありました。スマートフォンにメモをすることで忘れないようにしているのですが、メモをする段階で入力漏れが生じていた場合は防ぎようがありません。それに加え、メモをする手間が発生するため、めんどくさがりやな私は次第に大丈夫だろうと高をくくってやらなくなります。

これらの悩みをチームメンバーに共有したところ、非常に共感していただけたため、今回のチーム開発のテーマにしました。

4. レシピヨについて

4-1. レシピヨの機能

必要な食材の自動計算

画面に表示されている料理を選択するだけで、必要な食材及び数量を自動計算し買い物リストとして出力します。これにより、食材の数量を手動で計算する必要がなくなり(悩み1)、メモを書く必要も入力漏れが起きることもなくなります(悩み2)。

買い物リスト編集機能

買い物リストが作成後、ユーザーに合わせて食材の削除や数量変更をすることが出来ます。冷蔵庫に余りの食材がある場合や、ユーザーの好き嫌いに合わせて食材の数量変更など、よりユーザーに柔軟に使用していただけるようにしています。

履歴機能

これまでに作成した買い物リストの履歴を確認することが出来ます。この機能により、前回と同じ料理を作りたい場合、1から作成するのではなく、履歴からすぐに買い物リストを確認することが出来ます。

4-2. レシピヨの完成図

4-2-1. ログイン画面

login.png

メールアドレスとパスワードを入力してログインボタンをクリックすることで、ホーム画面へ遷移します。時間の都合上、ユーザー認証は実施しておりません。

4-2-2. ホーム画面(料理選択画面)

home.png

作成する料理を選択し、決定ボタンをクリックします。
もし間違えてクリックしてしまった場合は、選択した料理欄の☓ボタンをクリックすることで選択を解除することが出来ます。

4-2-3. 買い物リスト編集画面

list_fix.png

こちらの画面で自動計算した材料の編集をすることが出来ます。
編集ができ次第、画面下部にある確定ボタンをクリックすることで、買い物リストを確定させます。

【編集機能】
・食材の左側についているチェックボックスをクリックすることで、買い物リストから削除
・食材ごとに数量も変更可能
・メモ欄は自由記載

4-2-4. 買い物リスト表示画面

list-display.png

先程、買い物リスト編集画面で確定したリストを表示します。

4-2-5. 履歴画面

list-history.png

これまで作成した買い物リストの一覧を表示させています。
確認したい買い物リストをクリックすることで、以前作成した買い物リストを確認することが出来ます。

5. 使用技術・ツール

使用技術

  • フロントエンド:HTML / CSS / JavaScript
  • バックエンド:Ruby
  • DB:MySQL
  • ソース管理:Git / GitHub

チーム開発のためのツール

  • Discode
    基本連絡、チーム会議、GitHubへのpush報告
  • Figma
    画面遷移図
  • Google Slides
    発表スライド
  • Google Sheets
    業務フロー、テーブル定義書、タスク出し、ガントチャート、振り返り

6. 作業内容

ここまでレシピヨの開発背景やアプリの説明をしてきました。
以降は、具体的な作業内容及び振り返りをしていきます。

私達は以下のスケジュールでチーム開発を進めていきました。WEB技術の基盤がしっかりと身についていないため、10/30(月)〜11/26(日)は個人の勉強を優先し、11/27(月)〜12/3(日)はチーム開発に注力するというスケジュールになっております。

期間 内容
10/30 - 11/12 アイデア決め、スライド作成、要件定義
11/13 - 11/26 設計、タスク出し、環境構築
11/27 - 12/3 実装、プレゼン準備
12/3 チーム開発 発表日

参考に、個人の勉強は以下スケジュールで進めました。

期間 内容
10/16 - 10/29 Ruby
10/30 - 11/12 MySQL
11/13 - 11/26 HTML/CSS/JavaScript

6-1. アイディア決め

一番最初に行ったことがアイディア決めです。

具体的にはDiscordのチャンネルを用いて、チームメンバーでブレストを実施しアイディア決めを行いました。ブレストのやり方やメリットをチーム内で再確認したほうが良いと思ったので、私はブレストについて調べ会議前にチームメンバーへ共有することで、より効率的に進めることができました。その際、参考にしたのは以下2つの記事です。

https://qiita.com/rapirapi/items/5fbe8905fe0314e9e09b

https://qiita.com/refty10/items/8945e99da3023372598e

6-2. 要件定義・スライド作成

続いて、システムとして必要な要件をまとめるために要件定義を実施しました。

機能を明確化にするだけでなく、優先順位をつけることで課題を解決するために必要な機能から優先して作成するようにしました。優先順位をつけた結果は以下のとおりです。

優先度(高)

  1. ユーザーログイン

  2. ユーザは調理したい料理レシピを選択する。

  3. 選択した料理に必要な食材を自動計算し、買い物リストを作成。

  4. ユーザは作成された買い物リストに対し以下操作を実施する。

    ・不要な食材のチェックを外す

    ・食材の必要個数書き換え可能

    ・メモ入力

  5. 3の内容が反映された買い物リストを表示。

優先度(中)

  • ユーザーによるレシピ登録
  • レシピ検索

優先度(低)

  • 買い物リストをメールで送信
  • レシピのお気に入り登録
  • サンプルレシピは卵料理のみ
  • 卵のマスコットキャラクター
  • 再ログイン猶予時間の設定
  • 過去履歴機能

要件定義と並行してスライドの作成も実施しました。

スライド作成を最初に実施する理由としては、課題、ターゲット、概要を明文化することでチーム内で作成するもののイメージがブレないようにするため、課題とコンセプトが一致しているかを明確化するための2点があります。

6-3. 設計

続いて、全体像を把握するために以下5つの設計を実施しました。

  • 業務フロー
  • 画面遷移図
  • ワイヤーフレーム
  • テーブル定義書
  • 技術アーキテクチャ

6-3-1. 業務フロー

ユーザーの操作の流れを図にまとめました。

flow.png

6-3-2. 画面遷移図

必要なページを洗い出して、ページの流れを図にまとめました。

画面遷移図.png

6-3-3. ワイヤーフレーム

ページごとにワイヤーフレーム・機能・データをまとめました。

ワイヤーフレーム.png

6-3-4. テーブル定義書

データベースのテーブル構成を定義しました。

テーブル定義書.png

6-3-5. 技術アーキテクチャ

使用した技術構成は以下の通りです。

技術アーキテクチャ.png

6-4. タスク出し

フロント・バック・発表の3つの分類に分けてタスクだしをしました。
一つ一つの作業を細かく分類し、誰がどこのタスクを担当するかを決定しました。

タスクだし.png

7. チーム開発の振り返り

7-1. 個人の振り返り

良かった点

  • 司会・議事を担当したこと
    私は司会と議事の役割をに積極的に担い、チーム開発がより円滑に進められるよう取り組んできました。特に意識していたことは、チーム会議の最後に、今回の実施事項(決定事項)、次回の実施事項・宿題について話すことです。これらのことを最後に必ず確認するという意識を持つだけで、曖昧な箇所を見つけるきっかけにもなりました。また、議事録をDiscordにて共有することで、チーム会議の振り返りがしやすくなり、会議内容の明確化にもつながったと思っております。
  • わからないことや疑問に感じたことを正直に言えたこと
    私は「間違っててもいいから発言すること」を意識してチーム開発を取り組んできました。チーム開発を進めていく中で、わからないことやチームメンバーと意見が食い違うことが多くありました。技術力がなくて恥ずかしい、人とぶつかりたくないという考えを捨てて正直に話すことで、自分・チームの考えに納得して進めることができたと感じています。また、チームメンバーから教えてもらったことは、チーム会議後に勉強し自分の力にする行動が出来ていたことも良かったと思っています。
  • メンバーへのサポート
    2つのことを意識しメンバーへサポートすることが出来ました。
    1つ目が即返信をすることです。悩んでいる箇所のせいで作業を進めることができない状況は、非常に時間が勿体ありません。そのため、相談の連絡が来たときはすぐに返信することで、そのような時間を少しでも減らすことが出来ました。
    2つ目がメッセージではなく通話を使用することです。通話のほうが、画面共有をしながら説明ができるため、より正確な情報を簡単に伝えることができます。また、通話のほうがお互いの仲も深めることができるため、今後の開発にプラスな影響を与えられると思っております。

悪かった点

  • 不確定な要素があるまま開発を進めてしまったこと
    「どうやってバックエンドとフロントエンドで通信するのか」「Fetch APIとXMLHttpRequestのどちらを使用すべきか」など、技術的なやり方については実装時に調べれば問題ないでしょうという理由で後回しにしていました。実際今回はなんとかなりましたが、もし技術的に不可能であった場合、要件定義からやり直しになる可能性がありました。そのため、不確定な要素をなくすことが開発において非常に重要だということを学びました。
  • JavaScript のコードがきれいではない
    完成させることを第一優先しすぎてしまい、似たようなコードを複数のJSファイルに記載している箇所があります。また、記載したコードで想定している処理を動かすことは出来ているが、もっと短く簡単にかけるのではないかと感じる箇所が多くありました。知識があまりない状態でのチーム開発であったため、時間との兼ね合いで完成を優先させるのは仕方がないが、次回のチーム開発に向けてコードのリファクタリングは実施し、知識をつけていきたいです。

7-2. チームの振り返り

良かった点

  • WEBアプリが完成出来たこと
    メンバー全員が初めてのチーム開発で、自分達が考えたアプリを期間内に開発出来たことが非常に良かったです。正直最初は出来ないのではないかと不安でしたが、メンバー一人ひとりが責任を持って取り組んだ結果が形となったと思っております。
  • 密なコミュニケーション
    ミーティングを頻繁に実施し、チームで考える・共有する時間を多く設けました。個人の勉強期間(10/30〜11/26)は最低週2回、チーム開発期間(11/27~12/3)は毎日実施しました。ミーティングを多く実施することで、様々な意見を取り入れることができることに加え、チームメンバー同士も話しやすくなり気軽に意見を言いやすくなったと感じました。また、個別の勉強の相談などもして、勉強に対するモチベーション向上にも繋がりました。
  • 画面遷移図での共有
    私達のチームでは画面遷移図が非常な重要な役割を果たしてくれました。各画面間の流れや相互作用を明確に示すことが出来ていたため、チーム内でのイメージ共有をスムーズに実施することが出来たと感じています。また、画面遷移図を用いて疑問や課題を明らかにして、それに対して話し合うという方法でチーム開発の穴を解消してきました。

悪かった点

  • 課題と機能の整合性が取れていなかったこと
    私たちは「必要な食材の数(量)を考えるのがめんどくさい」「食材を買い忘れてしまう」という二つの課題に対応するアプリケーションの開発に取り組んでいました。しかし、この二つの課題を同時に満たそうとすることで、オリジナリティが欠けるものになってしまいました。そのため、一つの明確な課題に集中することで、既存サービスにない強みを持ったアプリの開発につながると感じました。
  • 既存サービスの分析不足
    課題を解決するという点に目が行き過ぎており、既存サービスの分析が不足しておりました。既存サービスの良い点を参考にしたり、比較することによって、よりオリジナリティのあるアプリを作成することが出来たのではないかと思いました。また、チーム会議で機能やデザインを話し合う際、既存サービスを用いて説明することでより理解がしやすくなるメリットもあると感じました。そのため、テーマを決める段階で既存サービスの分析を実施し、既存サービスとの差別化を意識したいです。

8. まとめ(感想)

最後に初めてのチーム開発を通しての感想を書いて終わりにしたいと思います。

まずは最後まで一緒に走り抜けてくれたチームメンバーに感謝をしたいです。一人の考えではこのサービスは生まれなかったですし、お互いの意見をぶつけ合って1つのプロダクトを作ることがここまで楽しいとは思いませんでした。偶然組み合わされたメンバーでの開発でしたが、このチームで開発が出来てよかったです。

今回得た経験と知識は、私の今後のエンジニア人生において非常に重要な財産になると思います。次回のチーム開発では、これらの学びを活かし、更に成長できるように努めます。

長文読んでいただいてありがとうございました。

0
0
1

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
0
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?