---
tags: LALab, インセプションデッキチーム
---

# 支援のロードマップ（うさぎ&あんこうチーム）
## 支援のゴール（インセプションデッキチームで立案）
### mission 1
- UserStory
- **顧客の開発者は**、内製化チームとしてアジャイル開発ができるようになりたい
- なぜなら、
- 短いサイクルで品質の良いプロダクトを届けてオーナーに認められたいから。

- Acceptance Criteria
- 以下の状態が持続できていること
- イテレーション単位でプロダクトを開発者以外が触れる環境にリリースしていること
- イテレーション単位でPOもしくはエンドユーザからのフィードバックをもらっていること
- POもしくはエンドユーザからのフィードバックを元にプロダクトを成長させていること
- イテレーション単位で製造品質と価値品質を確保できるようになっていること
- スコープに柔軟性を持たせ、開発タスクの優先順位を入れ替えていること
- 自己組織化チームとして自律的にカイゼンのサイクルが回っていること（検査と適応）

## マイルストーンの設定（各チームで実施）

### mission1

**観点**

1. イテレーション単位でプロダクトを開発者以外が触れる環境にリリースしていること
* **評価**：◯と△の中間
* **達成時期**：
* 銀座に閉じた話
* イテレーション単位でリリースする環境がある
* イテレーション単位でユーザ価値のあるプロダクトを開発できている
* 基板側も巻き込んだ話（後でいい）
* システム全体としてイテレーション単位でリリースできる状態である

> FJ開発メンバーからのコメント：
> イテレーション毎にSTリリースまでできている
> イレギュラーケースの場合は
> 本番環境もしようと思えばできる（仕組みとしては整っている）
> バグを残していたり、後回ししていることもあるのでは？

1. イテレーション単位でPOもしくはエンドユーザからのフィードバックをもらっていること
* **評価**：□
* **達成時期**：
* POからフィードバックをもらう(開発チーム-PO)
* イテレーション単位でフィードバックをもらえる場を設ける
* 適切なフィードバックをもらえるように状況を整える(目的の共有など)
* エンドユーザからフィードバックをもらう(開発チーム&PO-エンドユーザ)（後で）
* POが開発チームの一員というチーム構成になっている
* イテレーション単位でフィードバックをもらえる場を設ける
* 適切なフィードバックをもらえるように状況を整える

> FJ開発メンバーからのコメント：
> PO代理（小林さん、澤田さん）までならフィードバックをもらえている
> オーナー部からはもらえていない→色々今後問題も起こりそう
> 改善系のフィードバックよりもバグ系のフィードバックの方がいまは多そう
> POレビューでは少しは改善系のフィードバックももらえているかも？

1. POもしくはエンドユーザからのフィードバックを元にプロダクトを成長させていること
* **評価**：□
* **達成時期**：
* POと開発チームで連携してプロダクトを成長させる
* POの思いを開発チームが理解できている
* 成長につながるアイデアをPOと開発チームで議論できている
* POの思いを開発チームがプロダクトに反映させられる
* エンドユーザーからフィードバックをもらい、バックログに落とす（後で）
* エンドユーザからのフィードバックを適切に解釈できている

> FJ開発メンバーからのコメント：
> PO代理の方々や開発メンバーから、よくしようという意見が多く出てきている
> 開発期間がなくなってきていて、「もっとこうしよう」のような実装に時間を避けていない（「仕様に合わせる」ための実装に時間が割かれている）
> POやエンドユーザーからはフィードバックをもらえていない

1. イテレーション単位で製造品質と価値品質を確保できるようになっていること
* **評価**：□
* **達成時期**：
* ペアで作業する
* ペア作業（モブ作業）の価値をチームメンバーが理解している
* ペアでする作業、しない作業の意識合わせ
* みんなペアで作業する
* CI/CDが整っている
* CI/CDパイプラインをプロジェクトに導入
* CI/CDパイプラインでunitテスト、E2Eテストが実行されるようにする
* TDDを実施する
* TDDワークショップの実施（価値の理解）
* 実プロジェクトにおいてTDD経験者とペアでTDD実施してみる
* チームの文化として根付いている（品質マスターを立てたりして）
* みんなTDDする
* TDDしないときの意識合わせ
* 自動Unitテストを実施する
* Unitテストのガイドライン（粒度、種類、カバレッジ）の策定
* vueのunitテストの導入
* カバレッジを出力できるようにする
* E2Eが実施できている
* E2Eのガイドライン（粒度や目的）の策定
* E2Eのモジュールをプロジェクトに導入
* 多摩側まで繋いだE2Eにする
* プロダクトバックログに対してオーナーの合意を得る
* 作成したPBLをオーナーに見せるようにする
* インクリメントに対してオーナーにレビューしてもらう
* 何がインクリメントかを分かるようにする
* その部分をオーナーに診てもらう

> FJ開発メンバーからのコメント：
> 製造品質の取り組みはおおよそできていそう
> 自動化できている部分はできているが、まだまだ改善の余地はある
> POやエンドユーザーからフィードバックをもらえていない
> テストの粒度が人によってまちまち
> 開発チーム内のルールもあまりない
> 十分にテストできているか確認する仕組みもない

1. スコープに柔軟性を持たせ、開発タスクの優先順位を入れ替えていること
* **評価**：△
* **達成時期**：
* プロダクトバックログをオーナーも見れる、触れる形式にする
* 1スプリントで消化できるポイントが明確になっている
* 飛び入りタスクをPBLに追加する時のルールを決める
(「タスクを追加する人は、合計ポイントがベロシティを上回らないよう意識する」など)

> FJ開発メンバーからのコメント：
> 柔軟性を持ってやれている
> 飛び入りのタスクが降ってきてもPO代理と調整したりやるやらないを決定できている
> オーナーへという観点ではできていない

1. 自己組織化チームとして自律的にカイゼンのサイクルが回っていること（検査と適応）
* **評価**：△
* **達成時期**：
* レトロスペクティブをイテレーション単位で行う
* レトロで生まれたAction Itemを次のイテレーションで実施する
* Actionした結果、課題が解決したかを次回レトロで振り返る

> FJ開発メンバーからのコメント：
> レトロ→アクションアイテム→実践を自分たちで進められている
> 最近は、先週のTryが解決しているかの確認
> スクラムマスターがいなくなった場合に自分たちで実践できるか

---

## これからどう進める？

* 1ヶ月後までのアクションアイテムをざっくり決めて進める
- [x] 検討をどう進めるか決める → FJミーティング後30分〜1時間
- [x] ファシリ誰やるか決める → 持ち回りで実施
* 直近1ヶ月でやっていくべきoyやっていくとよい支援を洗い出してみる（マイルストーンの観点のことは一旦置いておく）

* その後で、マイストーンの観点1~6に紐づけられそうなものは紐づけてみる

* 1ヶ月後までのアクション

* E2Eについて
* Clientサイド
- 申請系
- [x] 入力チェック
- [x] 状態チェック
- [ ] 登録
- [x] 参照系（特定のユーザーの参照）
* Serverサイド
- API
- [x] GET
- [ ] POST
- Batch（Chakram使用）
- [ ] 1段階：エラーログがはかれたら、アラートあげる
- [ ] 2段階：AWS CLIでDynamoDBに期待値が格納されていることを確認する仕組みづくり