# Bubby's振り返り
### Keep(よかった点)
- (中田)デザイン、マークアップ、ロジックの実装担当を明確に分けたことで得意分野の実装を進めることができスピード感が出た
- (葉坂)進捗確認、疑問点解消の場として定例の実施。また、自分が実装している機能の共有する場ともなっており、属人化を防ごうとする動きができていた。
- (近藤)ミーティングを通じていろんな方の考えを聞いたり、意見を出しながら進められた部分もあったので、良かったと思います。
- (吉田)少しでも疑問点や理解があやふやな箇所があれば、MTG時にその場で解決させていたおかげで、実装作業などで大きな見当違いを起こさずに進めることが出来た。
- (福丸)ミーティング時に不明点や仕様確認をすることが出来たことによって、スムーズに着手することが出来た。また、色んな意見を聞くこともでき、より良い実装を考えながら着手が出来ていた。

### Problem(悪かった点)
- (中田)既存サービス踏襲（キッズダイアリー）ということで見えない機能があり工数が膨らんでしまった
- (葉坂)仕様の未確定な部分が多く、先方への仕様確認や仕様の決めの部分でかなり工数が取られていたので、(最初のフェーズから後回しにした機能とはいえ)予約周りの実装に取り掛かるまでに時間がかかっていた。
- (葉坂)タスク管理が複数のツールで行われていた。
- (近藤)キッズダイアリーを踏襲したデザインで進め、手探りで制作をした部分も多く、実際に実装をしていただく時に、改めて画面機能の検討をする時間が増えてしまいました。
- (吉田)作業工数の見積もりを見誤ることが多かった。
- (吉田)自分が実装において、ハマってしまっていることに気が付きづらいときがあり、時間が経ってしまっていたことがあった。
- (福丸)実装されていると思っていたところが実際は実装されておらず、テスト時にバグとして発見されたこと。

### Try(悪かった点の改善/挑戦したいこと)
- (中田)既存サービスの踏襲をやる際、見積もりのバッファを再考する。解析・確認をするフェーズを考慮し、要件定義段階で機能を確定させるようにする
- (葉坂)大きめの機能(今回の場合は予約周り等)の仕様決めは後回しにせず、早い段階で行う。
- (葉坂)1つのツールだけでタスク管理が行われるようにルールを明確化すると良さそう。
- (近藤)可能であれば、最初の段階(先方に機能の提案や仕様を確定する段階)で、実装をしていただく方にも意見をいただき、制作をしていけるようにしたいです。
- (吉田)影響範囲や実装範囲などを調査してから、改めて作業見積もりを考えるようにする。
- (吉田)実装で詰まり、15〜30分間思考停止している時間があると思ったら、すぐに周りの方々に助言を頂くようにする。
- (福丸)スタッフの入れ替わり時に、残タスクに関して全体で把握し、タスクとして詳細をまとめておく。
- (福丸)ミーティング時に意見を聞くことにより、より良い実装に繋がると実感したので、今後は自分の意見も伝えていくよう心がける。

# まとめ
- 既存サービスのマイグレーションの見積もりはバッファを考慮する。
- 機能に対するタスクを洗い出し、きちんと管理する。タスクに対してもれなく事前に見積もりをする。
- 要件定義段階でエンジニアもレビューに参加する機会を作る。（アサイン予定のない者でもよい）
- 比較的平和なプロジェクトだった