スクラムを本格的に導入してみた！


## システムチームが抱えていた問題

- 手持ち無沙汰なエンジニアがいた

- 情報共有がバケツリレーで行われていた
  責任者⇔社員⇔非社員
  経営者やシステム利用者⇔部署間調整者⇔システムチーム

- 個人間でのコミュニケーションが目立つ

- リリーススピードが上がらない（検証待ちも多かったのだが…）

## 経営者からの提案

CTOを招き入れる

## 現場の反応

招くならプロダクトオーナーではないか（技術顧問も同意見）

## 経営者の判断

人ではなく、仕組みで改善を試みる
以前スクラムを挑戦して断念したが、再挑戦してみたらどうか

## 以前スクラムに挑戦して断念した理由

- メンバー全員、スクラムを少し調べた程度で即実践に入ったため、よくわかっていなかった

- 十数個のストーリーポイントの合意形成を図るのに１か月費やす（各ストーリーポイントが全員一致するまで、ひたすらディスカッション）

## 経営者とシステムチーム責任者でスクラム「再」勉強

[スクラム 仕事が４倍速くなる“世界標準”のチーム戦術](https://www.amazon.co.jp/dp/B010COOG9O)

- システムチーム責任者が内容まとめてチームに共有する
  - 理想論のような印象を受けるも、スクラムの全体像は把握できた
  - ただ、実践してみないと分からない

## サブタスクで実践

- ロール
  - PO：経営者
  - SM：システムチーム責任者
  - システムチーム：4名

- POとSMでPBLを作成
  - スプレッドシートで管理
  - システムチームはPBL作成に関与しない（この時点では）
  - ストーリーポイントは「価値 - 見積 = 優先」

- SMとシステムチームでSBLを作成
  - GitHub Projects で管理
  - タスクは時間で見積
  - チーム全員で見積る
  - 要件定義や仕様まとめのみのスプリントもあり（この時点では）

## 実践してみた結果

- 要件定義や仕様まとめのみのストーリーポイントが曖昧

- 終わらないスプリントは延長

- 1スプリントで1ストーリーのみの対応が多い

- スプリントレビューの場がない（検証依頼のみ）

- 振り返り参加人数少ない＆時間が短い

## 更にスクラムの情報収集を行う

[スクラム現場ガイド](https://www.amazon.co.jp/dp/4839951993)
[エッセンシャル スクラム](https://www.amazon.co.jp/dp/B00MB6GO7E)

## 機能と期日が確約されているプロジェクトでスクラム

- 良かった点
  - 社員、非社員関係なくオープンでコミュニケーションが取れるようになってきた
  - 期日は死守できた
  - スプリントレビューの場を設けた

- 良くなかった点
  - 期日を死守することに専念した為、スプリントの終わりでなくリリース後に振り返りをまとめて実施することとなった
  - 仕様の全体像を把握していないチームメンバーが多数存在した
  - 実装時に発覚する既存仕様及びコードの課題が山盛りとなった

## 「仕様の全体像を把握していない」ことへの取り組み

- テストファーストの思想を導入する

- ユニットテストの導入は即時にはできないので、実装前にデシジョンテーブルを作成してパターンを網羅する

## スクラムチームでPBL作成の練習

- 題材は「機能と期日が確約されているプロジェクト」の残課題

- 良かった点
  - ストーリーへの落とし込みが経験できた
  - 合意形成をとりながらストーリーポイントを決めれた

- 良くなかった点
  - 司会を決めるのにもたついた
  - 司会が質問してもだんまりがあった
  - 20個以上ある課題を5個しかPBLに転記できなかった

## この頃から指針を求める声が強まったので規約を作ってみた

- 各ロールの役割を自社作業に照らし合わせ明確にする

- ストーリーポイントは「価値 - 見積 = 優先」とする

- 見積りは「S、M、Lとフィボナッチ数列」

|  XS |  S  |  M  |  L  |  XL | XXL |
| :-: | :-: | :-: | :-: | :-: | :-: |
|  1  |  2  |  3  |  5  |  8  |  13 |


- 見積りがXXL（13）を超える場合はストーリーを分割する

- スプリント期間は１週間とする

- 要件定義や仕様まとめのみのスプリントは実施しない

- 内部検証できるモノをスプリント内で構築することを確約する

- SBLのタスク見積りで１人日を超える場合は分割する

- スプリント期間内にタスクが完了しなかった場合はPBLに戻す

- デイリースクラムは毎朝15分以内とする

- スプリントレビューはスプリント終了日に実施する

- スプリントレトロスペクティブはスプリントレビュー後に実施する

## ステークホルダー、PO、SM、チームの役割を明確にしてスクラム

- ロール
  - ステークホルダー：経営者
  - PO：デザインチーム責任者
  - SM：システムチーム責任者
  - システムチーム：4名

- 1スプリント目
  - デザインチームが別タスクで動けなかったため、システムチームに待ちが発生

- 2スプリント目
  - POでマルチタスクが発生して時間がとれない
  - POの他部署調整にて、行って来いのバケツリレー共有が発生
  - 今までの業務仕様がベストかどうかの判断をせずに、「今まで」を貫き通そうとする
  - システムチーム内で作業branchの取り扱いで揉める
  - システムチーム内で仕様に関するメモ書きを残して欲しいと訴える者の出現（メモ書き欄は用意していたが、誰もが積極的に書かなかった）

- 3スプリント目
  - 同じストーリーでデザイン、システムチームの作業見積りが異なったため、ストーリーの優先に差異が発生
  - 様々な人がコードを好みで書くので異文化が増えた

- 良かった点
  - PBLの見積り時に参照できる、相対的比較値となる実績が残せた

- 改善
  - POは他部署調整の際、システムチームの人間を上手に巻き込むことを意識
  - SMは「指示」ではなく「促す」ことを意識
  - スクラム認識合わせの場を設ける（勉強したことの共有）
  - ブランチの構成は「master&develop&feature」とする
  - コード規約を作る
  - 「価値 - 見積 = 優先」ストーリーポイントをやめる
      - 価値はステークホルダーとPO ~~の軸とチームの両軸から~~ が提示する
      - 見積はストーリーで作業が発生する部署がそれぞれ提示する
      - 価値と見積のそれぞれを考慮して「優先」を決める

## 現状の課題

- スクラム開発におけるデザイナーの付き合い方
  デザインチーム単独でのスクラムを試みているが、二重スクラムみたいなことになり、
  POの時間が取れない問題が加速するのではという懸念

- PBLの項目が予定より早く終わった場合の動き方
  サブタスクか次回スプリントで着手予定のストーリーを取るか

- 大掛かりなDB設計はどのタイミングで行うか
  スプリント0かスプリント中に行うのか
  > テーブル設計が出来てないと、運用設計（通常業務、マスタ登録など）も出来ないので、そもそもコーディングにはいるべきではないと考える

    上記のような意見もあり、スプリント0で実施する方向にて検討中

## 今後の取り組み

- ドメイン駆動設計の導入
- ユニットテストの導入
- スクラムの全社導入