# メインテーマはなにか
形骸化したルールをどうにかしたい

# ターゲットはだれか
スクラム経験者

# 前提はなにか
ThetaのAndroidアプリチームの話
5年くらいの長期プロジェクトで、古参メンバーは誰一人いなくなった。
ルールだけが形骸化して残っている。

# 現れた効果はなにか
* 振り返り/計画にかかる時間が平均40%程減少
* ほぼ丸一日かかって終わらないことも多々あったが、今は大体3時前に片付くことが多い
* 日々の作業の徒労感の減少（体感）
* 無駄な固定作業をがしがし削っているのでプレイフィールが上がっている感じ
* 改善の活発化
* なんか不満に思うことがあったら次スプリントには改善する流れを自分で作れる
* 以前が形骸化していたともいう
* ※メンバーが一新されすぎて作業量の比較は無意味

# 話せることはなにか
## Thetaチームが4月からどう変わっているか
* 4つのボードを抱えていたのでテコ入れ
* 二重管理の無駄
* AAP, APEANDを統合してIssue管理に
* APE-IQはAWCに関連付けて動かすフローを作り（途中）、処理を一本化
* 本当は１ボードにしたかったけど、R側の利用方法に紐付いているため無理だった、しょうがない
* JiraからZubeへ以降
* 日々の必須作業の無駄
* Issueを作ると自動でReadyにチケットが作成される
* zubeボードでDoneするとIssueが自動Close
* Issueだからプルリクに#2200みたいにリンク貼れる
* KPTの効率化
* ↑に関連してるが、KPTもGithub上で行う
* Tryをその場でチケット化が可能　とりあえず全部チケット化して考えるルールにしている
* 最初の二ヶ月はあまりにもProblemが多く重かったため、Keepは出すだけだして共有するだけにして、Problemは全てTryに出して優先度つけて上からやっていった
* ストーリーポイント利用の廃止
* スクラムフレームワーク利用の無駄
* 固定作業の完全手順書作成
* 手順確認の無駄
* リリース作業等R側と固定してやらなきゃいけないことは1から10まで手順書作成
* diffffでチェック取る、とかそういうのはExcelに全てやらせる
* チーム内カレンダーのイベントごとに何をすればいいか、という手順を書く
* カレンダーはTeamsに紐付いたPlannerで作成
* outlookにインポート出来て嬉しい

# なんでうまくいったと思うか
* 心理的安全性が高かった
* ガンガン進める人がいた
* それにOKを出す人がいた
* 問題を指摘する人がいた
* 決定されたらそのスプリントはそれでやってみる。文句言わない（理想）
* スクラムコーチャー、スクラムマスターがいなかった
* スクラムフレームワークではこうだから、で決定されることがなかった
* 不要なわけではない。前提知識を持っている人がいたのでそれをもとに考えられた。
* ルールはなんでも記載した
* 細かいルールはぶっちゃけ見ない。
* 細かいルール（プルリク名をブランチ名そのままにするのやめるとか）は書かれててもそのときには見ない
* そういうのはチームメンバーが何となく理解しているものだし、誰か気づいた人が訂正すればいい。
* 訂正するためにみんなで決めたルールが記載されている必要がある。
* 新メンバーが入ってきた時にも使えると思う。ルールを見るのではなく人が訂正するのは一緒

# 今ある悩み
* ペアプロモブプロをしたいが否定派に阻まれている
* Problemを落ち着かせて、振り返りフレームワークを「いいこと」がいっぱい出るような形にしたい（FunDoneLearnみたいな）