初めてのチーム開発
Ruby,MySQL,HTML,CSS,JavaScriptの基礎学習がざっと終わったので、初めてチーム開発をやりました。チームは4人1組で7チームありました。チーム開発をどのように行ったのか、どのような課題があったのか、どのように解決したのか、どのような結果になったのかを記していきます。開発したもの
チームで開発したアプリは、買い忘れを防止するアプリ「れしぴよ！」です。1.ログイン画面
2.レシピ選択画面
ここで、自分で登録したレシピやサンプルレシピを選択
3.材料編集画面
複数のレシピから材料の個数や量を統合。ここで必要なものを確認して、いらない食材にチェックをいれて削除したリストに入れる。
4.買い物リスト作成
ここでは削除された材料を消して、買い物リストを表示する。
5.履歴
ここで買い物リストを確認できる。項目をクリックすると買い物リストに飛ぶ。
チーム開発の流れ
①顔合わせ…自己紹介②アイデア決め…
身の回りで困ったことなどの痛みを出します。そして、その課題を解決できるようなアイデアを出します。ここではとりあえず思いついたものをどんどん挙ていきます。私たちの場合は、1人のメンバーが抱いている痛み（スーパーから帰った後に、食材の買い忘れに気づく問題。料理ごとのレシピを見るのが手間）というところに共感し、「もともとあるレシピから材料の分量を統合して表示させたら便利じゃないか」ということで開発スタートしました。
③スライド作成…先にプレゼン用のスライドのフレームを作成する。
④要件定義…
機能として何ができるか定義する。システムとして必要な要件をまとめる。
[私たちの場合]
◇メイン機能
1.ユーザーログイン（事前登録要）
2.ユーザは調理したい料理レシピを選択する。
3.選択した料理に必要な食材を自動計算し、買い物リストを作成。
4.ユーザは作成された買い物リストに対し以下操作を実施する。
・不要な食材のチェックを外す
・食材の必要個数書き換え可能
・メモ入力
5.4の内容が反映された買い物リストを表示。
⑤設計...後で困らないように全体像を整理しておく
[業務フロー]
最終的にメール送信の機能は優先度が低いという結論になり、実装しませんでした。
[画面遷移図]
[ワイヤーフレーム]
私たちはここを最初雑にやってしまったため、タスクだしのところで作り直すという作業が発生してしまいました。画像は修正したものです。（実装中に結構変更しました…）
[テーブル定義書]
エンティティの洗い出しを行って正規化しました。
ER図は以下のような感じになりました。
[技術アーキテクチャ]
フレームワークを使うことを禁止する縛りがあったので、ブラウザとサーバー間の情報の受け渡しはwebrickというサービスを使いました。
⑥タスク出し
ガントチャートで何日までに誰が何をやるのかまとめておく。（このとき自分がどのくらいで実装できるのか分からなかったので、デットラインから逆算して何日までにはこのタスクを終わらせるということを決めました。）
⑦実装
この段階ではプレゼンまで時間がなかったので、見せる機能を限定して実装していくという方針で動いてました。「れしぴよ！」のコア機能はレシピの材料を統合して買い物リストにできることなので、ログイン画面、検索画面、買い物リスト確認画面、買い物リスト表示画面の実装を最優先に作業していました。なんとか見せられるものはできました。
[私がやったこと]
私はフロントエンドを担当させてもらいました。作業を始める際、ワイヤーフレームが明確ではなかったので、もう一人のフロントのメンバーとずっと通話しながら、修正をしました。また、JavaScriptの学習が甘かったので、webrickとの通信のやり取りが難しく、発表に間に合わないと思い、もう一人フロントを担当していた優秀なメンバーにアラートをだして、その方に実装をお願いしました。（ほんとに助かりました…）その代わり、そのメンバーのデザインを担当するところを私がやらせていただきました。デザインはやったことなかったですが、画面を初めて見せたとき、「かわいくていいじゃん」と言われたときはうれしかったです。もちろんもっとこうした方が良いこと、雑な部分などは都度指摘して頂き、その部分を修正する作業も多かったです。あとは、発表のスライドも少し手伝わせて頂きました。
⑧プレゼン
7チームでプレゼンをしました。メンバーの発表者がユーモアを取り入れていただき、聴衆を引き付けるようなプレゼンでとてもよかったと思います。1番にはなれなかったですが、何とか見せられるものが作れてよかったですし自分の学びにもつながりました。（メンバーの皆さんが優秀過ぎました。）他のチームの作品もサービスとして普通にありそうなレベルの物があって、驚きました。最後に現役のエンジニアさんからフィードバックを貰い発表は終了しました。フィードバックの内容として改善点は、
①材料リストなのか買い物リストなのかのコンセプトをシャープにすればもっと良くなる
②料理選択の部分をソート機能があればもっとよかった。
③忘れ物をなくすのが1番の目的なので、忘れ物をなくすためのホーム画面かどうかを考えてみてほしい。（確かに…）
良かったところは
①レシピ内のデータを正規化しているところはあんまりないので、必要な分量を管理できるのは結構可能性ある。この着眼点はよかった。
②複数の料理に対して必要な材料が表示されるという部分はよかった。
③ログイン後の料理を表示する画面も整頓されていてよかった。
④レシピの編集画面で材料を変更したり、メモを書いたり複数の機能があって画面を分けたいと思うところを一つの画面で全部操作できるところが良かった。
という結果となりました。現役エンジニアさんの視点はさすがだなと感じると同時に、サービスとして出せるレベルになるにはまだまだ頑張らないといけない壁があることも実感しました。
チームとしてよかったところ。悪かったところ。改善すること
[よかったところ]・1週間に最低2回チーム会を開いて雑談し、意見やアラートを出しやすい雰囲気を作れたこと。
・誰にでも当てはまりやすい着眼点を持てたこと。
・人を引き付けるプレゼンができたこと。
・リーダーを決めて管理できたこと。
・発表に間に合うように見せる機能の優先順位を決めた。
[悪かったところ]
・DBの要件を事前に明確にしておくべき
・既存のアプリの分析が不足している
・材料リストなのか買い物リストなのかのコンセプトがぶれていた。卵が5個になったとき、店で売っている個数は大体4個6個10個とかなので、そこを考慮するべきだった。
・ワイヤーフレームが綿密ではなかった。
[try]
・作業に取り掛かる前に、サービスの全容を明確化し共有する。
・既存アプリの分析及び話し合いを綿密にする。つまり、既存サービスとの差別化を考える。
・ホーム画面は会員登録なしで、すぐにリストが見られるようにするべきだった。
・肯定的な見方ばかりではなく、批判的な見方もしてみる。
個人のよかったところ、悪かったところ。改善すること
[よかったところ]・アホみたいなアイデアでもとりあえずいっぱい出したところ。
・不明点をそのままにせず報告したこと。
・アラートを出せたこと。
・技術不足でもなんとかHTML、CSSで画面のレイアウトを完成できた（結構助けてもらいました…）
[悪かったところ]
・技術に関しての知識が不足していた。
・CSSの変な余白やボーダー線など、雑なところがあった。（指摘されて直しました。）
[try]
・なんとなくこうだろではなく、何故こうなるかをちゃんと考えて実装する。
・「まあこんなもんか」みたいに自分の中で自己完結せず、人の目を入れる。
・もっと勉強する。