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

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

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

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

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

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

経営者からの提案

CTOを招き入れる

現場の反応

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

経営者の判断

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

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

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

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

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

スクラム 仕事が４倍速くなる“世界標準”のチーム戦術

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

サブタスクで実践

• ロール

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

• POとSMでPBLを作成

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

• SMとシステムチームでSBLを作成

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

実践してみた結果

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

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

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

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

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

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

スクラム現場ガイド
エッセンシャル スクラム

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

• 良かった点

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

• 良くなかった点

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

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

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

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

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

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

• 良かった点

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

• 良くなかった点

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

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

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

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

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

• 見積りが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で実施する方向にて検討中

今後の取り組み

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