【学習内容】

・キックオフ！

【開発状況（0日目・1日目・2日目）】

・DB設計
・デプロイ準備

【キックオフ！】

先日メンバー発表がありついにアジャイル開発が始まりました。

僕のチームは5人体制(うち転職コース3名、フリーランス2名)で開発を進めていくことになりました。

チームメンバーは全員55期で、よくもまあこんなに優秀なメンバーばかり同じチームになったなあと実感しております。

ちなみに、僕はスクラムマスターとしてチームの諸々の調整を行っていくことになりました。

全員自走力がハンパない方ばかりなので僕が表立って立ち回るような場面は廻ってこないかと思っているので、あまり不安要素はないですが、メンバーが各々の長所を活かせるような環境づくりや、他チームとの親交、期を跨いだ交流や情報収集などに奔走したいと思います。

カリキュラム上では3ヶ月以内にメルカリを完成させることが求められますが、我々は常に2週間くらいのバッファを保ちつつ開発ができるよう駆け足気味で進めていきます。

さらに、若干頻度は落ちますが同時並行で今までどおり学習noteも更新していきます。

【開発状況（0日目）】

○メンバー全員がER図を作成し、Trelloにて共有

顔合わせしてから24時間以内にER図を作成し、Trelloに提出を行うという鬼畜スケジュールを設定しました。

ER図描画にあたって僕は「cacoo」というアプリを使用しました。

●（参考）ER図描画ツール
・cacoo
https://cacoo.com/ja/

他のメンバーが使用したアプリはこちら
Lucidchar1
https://www.lucidchart.com/pages/

【開発状況（1日目）】

○ER図を元にビデオ会議実施

全員期限内にER図を提出しました。（家族旅行の最中にER図を提出する猛者もいました）

それぞれのER図を確認したところ、多種多様なER図が挙がっていたので、1番精度が高そうなER図をベースにして、「zoom」という画面共有アプリケーションを用いてビデオ会議を実施しました。

●（参考）zoom
https://zoom.us/jp-jp/meetings.html

<結果>
・users絡みの情報は1つのテーブルで管理する方向になりました。

・products絡みの情報は非常に難解でした。「大項目」⇒「中項目」⇒「小項目」を実現するためのテーブル設計（こういうのを多階層カテゴリと呼びます）には各メンバーが苦労した模様です。

そんな中、いくつか画期的なアイディアが出ましたが、チーム全員の方向性が完璧に合致せず、理解度的にも怪しかったので、ペンディング事項にしました。

・その他（reviewsやcomments等）は特に話し合いはしませんでした。

<気付き>

本家メルカリについて、ブラウザ版とアプリ版では仕様が若干異なることが判明しました。

具体的には「★評価」、「ユーザーフォロー機能」はブラウザ版には備わっていませんでした。

基本的にはブラウザ版に準拠する形で開発を進め、余力があったら実装をする方向でいきます。

【開発状況（2日目）】

○オフラインミーティング

2週間後のスプリントレビューに向けて「DB設計・README班(3名)」と「デプロイ班(2名)」に分かれました。

ちなみにスプリントレビュー後は、「商品テーブル」、「ユーザテーブル」、「TOPページ」の3班に分かれて大きい機能から実装を進めていきます。

班分けをしましたが、各自が主体性を持って他の班が何をしているかを理解しながら横断的に開発を進めるようにします。

<結果>

□DB設計・README班

・DB設計、ER図作成
DB設計については、チーム全員が深い理解をする必要がありますが、ひとまず「DB設計・README班(3名)」が深い理解をしたのち、デプロイ班に内容を共有することになりました。

メルカリ本家の画面や入力フォームを1つづつ注意深く確認しながら、users,likes,commentsテーブル等のの確認を行いました。

また、多階層カテゴリ（products）については水曜日に別途オフラインミーティングを開催し、週末までにER図及びREADMEを完成させることを目標とします。

□デプロイ班

・デプロイにおける環境構築の注意点の作成
Ruby,rails,mysql,rbenvのバージョンをあわせないとエラーの原因になるため、不安要素を取り除くための手順書の作成に着手しました。

□その他
・AWS課金回避法の共有
本題からはやや逸れますが、AWSの課金を防ぐ手順のようなものを作成しました。

・素材集め
メルカリ本家より、画像データの収集等を行いました。
Rails newしたらとりあえず画像を放り込む予定です。

<気付き>

チーム開発がOne for all , All for one感といいますか、スクラム組んでる感がハンパないです。

チーム全員がそれぞれの個性や特徴を活かしてチームのために奔走しています。
（僕はプログラミングとは少し離れたところで奔走していましたが・・）

メルカリの仕様を注意深く確認していくと、これまでのカリキュラムやProgateでやったことの応用をすれば実装できそうな箇所が多々あることがわかりました。