失敗から学ぶスクラム3本柱の重要性/注意点

スクラム

はじめに

こんにちは、株式会社レコチョク システム開発推進部に所属する西村といいます。

私は現在、とあるプロジェクト(以降、プロジェクトXと記載)でスクラム開発を行っているのですが、
あまりにもスクラムの3本柱が概念的すぎて実践するのが非常に難しいです。

そこで今回は以下の開発者の方に向けて、実際に発生した問題からスクラムの3本柱がなぜ重要なのか/何に注意すべきかを考えていきたいと思います。

  • 対象の読者
    • 「スクラム開発を初めて経験している」
    • 「まだスクラム開発について深く理解していない」

スクラムについて

失敗事例を紹介する前にスクラム & 現在のスクラム環境ついて紹介したいと思います。

スクラムとは…？

プロダクト開発において現在地を測るために有用なフレームワーク

  • 「プロジェクトX」では以下を認識しながらスクラム開発を行っています。
    • 目標に対してチームがどこにいるのか？
    • 目標からどれぐらい離れているのか？

スクラムの3本柱

スクラムの成功には、透明性、検査、適応の3つの要素が欠かせません。

スクラムの3本柱 意味
透明性 現在の正しい情報が1箇所に整理されており、次の行動が誘発されている状態
検査 現状の目標・目的が明確であり、目標・目的に対する現状が明確であり、この差分が把握され続けている状態
適応 現状の目標・目的が明確であり、目標・目的に対する現状が明確であり、この差分を埋め続けている状態

これをスクラムの3本柱といいます。

プロジェクトXのスクラム環境

スクラムイベント

  • スプリント: １週間
スクラムイベント 説明
スプリントプランニング スプリントの目標とタスクを計画するミーティング
デイリースクラム 進捗報告と問題点を共有するミーティング
スプリントレビュー スプリントの成果物を評価・フィードバックするミーティング
スプリントレトロスペクティブ スプリントを振り返り、継続点と改善点を議論するミーティング

ロール一覧

チームメンバー 主な仕事 役割
プロダクトオーナー 各ページの内容準備・確認 / その他関係者との調整 投資対効果の最大化
開発者 デザイン作成・HTML/CSS開発 生産性の最大化
スクラムマスター スクラムに関するサポート プロダクトオーナーと開発者の実現確率の最大化

チームで利用しているツール

利用ツール サービス名
プロジェクト管理ツール Jira Software(以降、Jiraと記載)
コミュニケーションツール Slack, Microsoft Teams(以降、Teamsと記載)
スプリントレトロスペクティブ用ツール GitHub(Projects)

スクラムの3本柱に関する失敗事例

スクラムの3本柱が守られなかったことで引き起こされた事例について紹介したいと思います。

透明性に関する事例

問題点

「プロジェクトX」チームは透明性を考慮し、全ての情報をJiraで管理することをルールにしました。しかしSlackやTeamsなどのコミュニケーションツールを使用したミーティングにて、口頭で合意した内容やチャットで確定した内容がJiraに記録されないケースが発生しました。その結果、開発者の実装がプロダクトオーナーの意図と異なる方向に進んでしまい、手戻りが発生する事態となりました。

反省点
  • 情報が1箇所に整理されていない
    • 透明性: 「現在の正しい情報が1箇所に整理されており」に違反
    • 複数のツールを利用することで情報が散在、それを集約できていなかった
まとめ

結果: 透明性を守らないことで手戻りが発生し、開発者が必要とする生産性が低下した！
注意点: 1箇所確認すれば、全ての決定事項を把握できるような状態にするべき(※口頭の決定事項も必ず更新)
解決策: 決定事項は必ずJiraのコメントに記載し、メンションを付けて周知する → 問題改善できました！

検査に関する事例

問題点

開発者は「実装 → コードレビュー/レビュー修正 → 検証反映」の手順を経て、成果物を評価(スプリントレビュー)していました。

例として、とある画面は
– 1スプリント目: 実装
– 2スプリント目: コードレビュー/レビュー修正
– 3スプリント目: コードレビュー/レビュー修正 + 検証反映(スプリントレビュー)

という期間で開発を行っていました。そのためスプリント3まで成果物を披露する機会がありませんでした。その結果、検証反映後にプロダクトオーナー目線の指摘点が多く発生し、コードレビュー/レビュー修正の内容に手戻りが発生してしまいました。

反省点
  • スプリント毎に成果物の進捗を把握していなかった
    • 検査: 「この差分が把握され続けている状態」に違反
まとめ

結果: 検査を守らないと手戻りが発生し、開発者が必要とする生産性が低下した！
注意点: できるだけスプリント毎で目標との差分を把握する、また評価できる環境を準備するべき
解決策: 途中経過だとしても評価する価値があるのならば、スプリントレビューにて評価を行う → 実践中！

適応に関する事例

問題点

「プロジェクトX」チームは毎週、スプリントレトロスペクティブを実施しています。そこではスプリント内の反省点をもとに現状の改善活動を行っています。しかし改善活動を取り組むにあたって、「環境を改善する」という目的から「改善案を実施する」という手段にすり替わり、1度改善策を実行すると、それ以降その課題について言及されることはなく、チームは改善策以上の成長をすることはありませんでした。

反省点
  • 目的と手段が入れ替わり、改善を継続できていなかった
    • 適応: 「この差分を埋め続けている状態」 に違反
まとめ

結果: 適応を守らないとチームが成長することができない！(生産性が向上しない)
注意点: 検査・適応を繰り返し、常に目標に対して最適な方法を追求するべき
解決策: 実施した改善策をスプリントレトロスペクティブで再評価し、継続 or 解決策を出す → 実践中！

全体まとめ

今回はスクラムでの失敗事例からスクラム3本柱の重要性と注意点を考えてみました。
スクラムの3本柱はあまりにも概念的で様々な箇所で注意すべきことがあり、担保することが非常に難しいです。
大変ですが、頑張って少しずつ学んでいきましょう。
自分も買ったけど手を付けていなかったアジャイルサムライを読んで、より理解を深めたいと思います。
最後まで読んでいただき、ありがとうございました。

参考

スクラム