---
robots: noindex, nofollow
lang: ja
tags: KPT
---
# 20211012_生鮮PG作成_KPT

## ルール

- 取り組み方や進め方について振り返ること
（XXのタスクが遅れたのが悪かった、等はNG）
- 他の人と重複する内容や些細な内容でもよいので挙げること
- 個人攻撃は厳禁

## 手順

- よかったこと/悪かったこと（Keep/Problem）を書き出す
- 15分
- 書き出した内容について話す
- 30分
- Ploblemをもとに次にためすこと（Try）をきめる
- 15分
- 一定期間経過後にTryが実施できたかを評価する
- PG完了後に検証

## 良かったこと　Keep

- API開発でswaggerが標準で入っているのは良かった、テストがやり易い
- TeamsでのGitなどのツールに対する運用サポートが丁寧で良かった
- Merge時にソースレビューを行っているため、ミスが少なくなった
- ソースレビューが容易になった
- 新しく構築しているので、比較的綺麗に構築が進んでいる、上と同じ
- Teamsでの情報共有は周りも見れるので同じ躓きをすることが少なかった
- Front/BackでPGのタスクが明確になった
- Front/Backで分業できるようになった

## 悪かったこと・困っていること　Problem

- **遅延の原因はここに記述してください**
- (藤生)カンファレンス準備のため
- (藤生)共通ロジックの作成のため
- 予定工数に対して若干遅れている
- 100
- (飯塚)カンファレンス準備のため
- (飯塚)CSVダウンロード機能は生鮮では未実装だったため調査する必要があったため
- (飯塚)VIEWを用意することは自分にとっては大変だったため
- 予定工数に対して予定通りぐらい（VIEWを除いて）
- 100
- (取枡)他作業の割り込みのため
- (取枡)未完成基礎ロジック作成・調査のため
- (取枡)現状作成している企画管理のDB構造が他と比べて特殊なため、サンプルが少なく修学用PGとしては選択が悪かった
- (取枡)そもそものJava技術不足
- 予定工数に対して、企画管理が倍ぐらいになっている
- 今回で割り込み、4日（ちょっと多め
- (田口)カンファレンス準備のため
- (田口)他タスクが思ったより多かった
- (田口)設計対応内容が想定より多い
- 予定工数に対して
- (上岡)Java未経験による
- (上岡)Teamsで共有とは言え、やはり顔を合わせてよりは効率が悪い
- (上岡)大人数による開発の経験不足
- (上岡)技術的挑戦によるリスクが想定より大きい
- 予定工数に対して、予定通りには進められそう
- 1日3時間でふっているのでなんとかなりそう
- (尾﨑)複雑なプログラムのため汎用的に作るのが難しかった
- (尾﨑)カンファレンス準備のため
- (尾﨑)Blobの動作検証に時間が掛かった
- (尾﨑)リファクタリングに時間が掛かった
- 予定工数に対して、倍ぐらいかかっている（アップロードなので）
- 割り込みはMultiリリースや障害対応、もう終わったので今後は金曜のプレゼンがおわれば
- プレゼン準備 水曜1日、木曜休み
- LittleChangeリリース　2h
- ナンコクスーパーテスト 2h
- (北川)他業務の割り込みのため
- (北川)今回のリウボウストア様バージョンアップの打合せ準備のため
- 予定工数に対して
- Jasper着手できそうか？
- 今週落ち着くはず
- 2h/1d
- グロのPG仕様書が入ってくる
- 個別の課題が整理されて共有されていない（Teamsを追うのはしんどい）のでは？
- 必要な情報がTeamsのどこに有ったか探すのが大変だった
- API仕様が決まっていないので、フロントの実装が完結しづらい
- 仕様書が旧版のままで、F/Bの区切りを各担当者が考えないといけない
- 仕様書の書き方まで今回のやり方にあわせられていない
- VIEWを作りながら、PGすることが大変です。
- グロの時とやり方を変えたことにより詰まる箇所が多かった（Blob、トランザクション等
- F/Bの細かいタスク分割の境界線が不明瞭
- 担当者不在(主にBack)の汎用API作業について(AJAX動作の名称取得など)
- Backのコーディング規約がない
- 画面毎のViewの作成(多分ほぼ全画面で必要)
- 名称マスタ、部門マスタなどの頻度の高いロジックも、毎回取得しないといけない
- PDの時にプログラムの構成まで想定できていなかったためPGの際に仕様を考えながらの作業となった
- Redmineだけだとタスク粒度が大きく進捗がわかりにくい
- 開発環境を用意してもらったがまだ活用できていない（随時最新化していない）
- REXASS-5全体の環境が複雑なので、開発環境を作成するだけでも一仕事(今回のF/Bに限った話ではないけど)
- UnitTestがない
- エラー文言の定義がまだ共通化できていない
- 仕様書に書ききれていない処理が多かった
- 影響の大きいDB関連の修正が後半に発生してしまった
- eslint入れてない
- Pretterも
- 設計の説明がない
- Git内でのwarファイル管理

## 次にためすこと　Try

- 共通ロジックを先に作成
- 先にバックエンドでdummyのAPIを用意してからフロントを作成していく
- インターフェースを確定させればやりやすい
- フロント側でインターフェースを指定する
- それに対してバック側の制限を踏まえたインターフェースですすめる
- もっと先に技術部分を整えておく
- レビュー担当を明確にする
- Redmine登録？
- 疑問をそのままにしないようにする
- 議論にあげる
- Wiki等に課題（QA）を整理したほうがよいのでは
- 実装だけでなく仕様面のきめごともまとめる
- KnowlegeでQA作る
- 結論どうなったかが追いにくい
- 誰が書いたかAuthorを書く
- Viewの書き方、飯塚田口で一緒にやってみる
- マスタ情報を最初に全件取得し、使用する汎用機能実装
- Redmineとinstaganttの使い分け明確化
- ActionsでCD導入できれば
- VPN通すなりが必要
- Dockerでローカル環境構築
- テスト実施
- 品質を上げる手段、Junitやselenium？などの導入を検討
- エラー文言定義
- 初回分追加　田口
- ルールを揃えるためにツールを使う
- Checkstyle入れてみる
- eslint入れてない
- Pretterも
- 常時会議やってみる