システムチームが抱えていた問題
手持ち無沙汰なエンジニアがいた
情報共有がバケツリレーで行われていた
責任者⇔社員⇔非社員
経営者やシステム利用者⇔部署間調整者⇔システムチーム個人間でのコミュニケーションが目立つ
リリーススピードが上がらない（検証待ちも多かったのだが…）
経営者からの提案
CTOを招き入れる
現場の反応
招くならプロダクトオーナーではないか（技術顧問も同意見）
経営者の判断
人ではなく、仕組みで改善を試みる
以前スクラムを挑戦して断念したが、再挑戦してみたらどうか
以前スクラムに挑戦して断念した理由
メンバー全員、スクラムを少し調べた程度で即実践に入ったため、よくわかっていなかった
十数個のストーリーポイントの合意形成を図るのに１か月費やす（各ストーリーポイントが全員一致するまで、ひたすらディスカッション）
経営者とシステムチーム責任者でスクラム「再」勉強
- システムチーム責任者が内容まとめてチームに共有する
- 理想論のような印象を受けるも、スクラムの全体像は把握できた
- ただ、実践してみないと分からない
サブタスクで実践
-
ロール
- PO：経営者
- SM：システムチーム責任者
- システムチーム：4名
-
POとSMでPBLを作成
- スプレッドシートで管理
- システムチームはPBL作成に関与しない（この時点では）
- ストーリーポイントは「価値 - 見積 = 優先」
-
SMとシステムチームでSBLを作成
- GitHub Projects で管理
- タスクは時間で見積
- チーム全員で見積る
- 要件定義や仕様まとめのみのスプリントもあり（この時点では）
実践してみた結果
要件定義や仕様まとめのみのストーリーポイントが曖昧
終わらないスプリントは延長
1スプリントで1ストーリーのみの対応が多い
スプリントレビューの場がない（検証依頼のみ）
振り返り参加人数少ない＆時間が短い
更にスクラムの情報収集を行う
機能と期日が確約されているプロジェクトでスクラム
-
良かった点
- 社員、非社員関係なくオープンでコミュニケーションが取れるようになってきた
- 期日は死守できた
- スプリントレビューの場を設けた
-
良くなかった点
- 期日を死守することに専念した為、スプリントの終わりでなくリリース後に振り返りをまとめて実施することとなった
- 仕様の全体像を把握していないチームメンバーが多数存在した
- 実装時に発覚する既存仕様及びコードの課題が山盛りとなった
「仕様の全体像を把握していない」ことへの取り組み
テストファーストの思想を導入する
ユニットテストの導入は即時にはできないので、実装前にデシジョンテーブルを作成してパターンを網羅する
スクラムチームで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
現状の課題
スクラム開発におけるデザイナーの付き合い方
デザインチーム単独でのスクラムを試みているが、二重スクラムみたいなことになり、
POの時間が取れない問題が加速するのではという懸念PBLの項目が予定より早く終わった場合の動き方
サブタスクか次回スプリントで着手予定のストーリーを取るか-
大掛かりなDB設計はどのタイミングで行うか
スプリント0かスプリント中に行うのかテーブル設計が出来てないと、運用設計（通常業務、マスタ登録など）も出来ないので、そもそもコーディングにはいるべきではないと考える
上記のような意見もあり、スプリント0で実施する方向にて検討中
今後の取り組み
- ドメイン駆動設計の導入
- ユニットテストの導入
- スクラムの全社導入