なぜあなたのスクラムはいつも非効率なのか
スクラムが非効率になる原因は、会議の不足ではなく、権限、チーム構成、デリバリーの仕組みにあることが少なくありません。ソフトウェア開発の現場でよく見られるスクラムのアンチパターンを整理します。
スクラムは、複雑な問題に対応するための軽量なフレームワークです。
反復的かつ漸進的なアプローチを採用し、限られた期間内に検査可能な成果を生み出し、その結果に基づいて次の行動を適応させます。
スクラムの考え方は 1990 年代に形づくられ、スクラムガイドの初版は 2010 年に公開されました。
その後、研修、コンサルティング、認定資格が普及し、スクラムは多くのソフトウェアチームがアジャイルを導入するときの定番になりました。
しかし、多くの企業が導入しているのはスクラムの外見だけです。
- 毎日立って進捗を報告する
- 1〜2 週間ごとにスプリントを区切る
- Jira 上でチケットを移動する
- スクラムマスターが定例会議を進行する
儀式はすべてそろっているのに、デリバリーは速くならず、会議だけが増えていきます。
多くの場合、問題はチームが「十分にアジャイルではない」ことではありません。会社がプロセスの名称だけを変え、権限、意思決定、デリバリーの仕組みを変えていないことです。
スクラムの構成
2020 年版スクラムガイドによると、スクラムチームには 3 つの責任があり、スプリントの中で 4 つの正式なイベントを実施し、3 つのスクラムの作成物を扱います。
3 つの責任
プロダクトオーナー
プロダクトオーナーは、プロダクトの価値を最大化すること、プロダクトバックログを管理して並べ替えること、そしてチームがプロダクトゴールを理解できるようにすることに責任を持ちます。
プロダクトオーナーは、要求をエンジニアに転送するだけの窓口ではありません。また、複数のステークホルダーが投票で物事を決める委員会でもありません。
誰でも緊急案件を差し込んだり、優先順位を自由に変更したりできるなら、プロダクトオーナーにあるのは肩書だけで、実際の決定権はありません。
スクラムマスター
スクラムマスターは、スクラムチームの有効性に責任を持ちます。チームと組織がスクラムを理解できるよう支援し、障害を取り除き、それぞれのイベントが本来の目的を果たせるようにします。
プロジェクトマネージャーでも、議事録係でも、チケットの更新を追い回すプロセス警察でもありません。
開発者
開発者はスプリントを計画し、品質を維持し、各スプリントで完成の定義を満たすインクリメントを作成します。
ここでいう「開発者」はプログラマーだけを意味しません。インクリメントの作成に直接関わるすべてのメンバーを指します。
スプリントと 4 つの正式なイベント
スプリントは、スクラムにおける他のイベントを内包するものです。期間は 1 か月以内で、その中でスプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブを実施します。
スプリントプランニング
チームは、そのスプリントになぜ価値があるのか、何を完了できるのか、どのように取り組むのかを決め、スプリントゴールとスプリントバックログを作ります。
デイリースクラム
デイリースクラムは、開発者がスプリントゴールに向けた進捗を検査し、その日の計画を適応させるためのイベントです。上司に昨日の作業を順番に報告する場ではありません。
スプリントレビュー
チームとステークホルダーが成果や環境の変化を検査し、次に何をするかを話し合います。スライドを見せて拍手をもらうだけの成果発表会ではありません。
スプリントレトロスペクティブ
チームは、協働の仕方、プロセス、ツール、品質を検査し、次のスプリントで実行できる改善を見つけます。
3 つのスクラムの作成物
スクラムの 3 つの作成物は、プロダクトバックログ、スプリントバックログ、インクリメントです。それぞれに対応する確約は、プロダクトゴール、スプリントゴール、完成の定義です。
- プロダクトバックログ：プロダクトを改善するために必要な作業を並べた一覧
- スプリントバックログ：スプリントゴール、選択したプロダクトバックログアイテム、およびそれらを提供するための計画
- インクリメント：完成の定義を満たし、利用可能な状態になったプロダクトの価値
これらは文書を増やすためのものではありません。作業を透明にし、チームが実際の結果を検査して適応できるようにするためのものです。
なぜスクラムがうまく機能しないのか
スクラムマスターが人事評価権も握っている
スクラムガイドは、マネージャーがスクラムマスターを兼任することを明示的に禁止していません。本当の問題は、その権限がどのように使われるかです。
スクラムマスターがメンバーの評価、昇進、雇用の継続まで決める場合、チームはレトロスペクティブで失敗について率直に話せません。スプリントプランニングで無理なコミットメントを断ることも難しくなります。
本来は検査と適応のためにあるイベントが、最後にはマネージャーの好みに合わせて組み替えられます。チームは表面上こそ自己管理していても、実際には指示を待ったままです。
仕事を割り当て、個人を評価する習慣を手放せないマネージャーは、スクラムマスターを兼任するべきではありません。
『The Great ScrumMaster』では、マネージャーがスクラムマスターに向いていない理由について説明されています。
マネージャーがデイリースクラムを点呼に変える
スクラムチームの内部に、従来型の上下関係はありません。
プロダクトオーナーは目標と順序を示し、スクラムマスターはチームの有効性を高め、開発者はどのように仕事を完了するかを自己管理します。
ところが、マネージャーがデイリースクラムに入り、ボードの前で一人ずつ問い詰め始めます。
- このチケットはなぜまだ終わっていないのか？
- 昨日は具体的に何をしたのか？
- 今日中にリリースできるのか？
こうしてデイリースクラムは、開発者のための協働イベントから、毎日 15 分間の人事評価面談に変わります。
メンバーは進捗をよく見せ、問題を隠し、説明しやすい形に作業を細分化するようになります。ボードは忙しそうに見えますが、本当のリスクが見つかるのは遅くなります。
プロダクトオーナーに並べ替える権限がない
もう一つよくある問題は、すべてのマネージャーがプロダクトオーナーのように振る舞うことです。
営業は顧客の要求が最優先だと言い、運用は障害対応が最優先だと言い、経営者はスプリントの途中で「簡単なはず」の新しい要求を差し込みます。
本来のプロダクトオーナーは、全員のためにチケットを作ることしかできず、割り込みを拒否することも、何を先に行うかを決めることもできません。
この状況では、スプリントゴールに何の拘束力もありません。チームは最も価値のある成果を届けるのではなく、その日に最も声の大きい人へ対応し続けます。
スクラムには、プロダクトバックログの並べ替えに責任を持ち、その判断を組織から尊重される一人のプロダクトオーナーが必要です。
MVP はデモするだけでリリースしない
私が現場で何度も見てきた問題の一つは、チームがデモ可能な MVP を作ったのに、リリースしないことです。
スプリントが終わっても、新しいシステムはエンジニアのローカル環境か会議室にしか存在しません。デモが終わると、さらに機能を積み上げ、数か月後にまとめてリリースします。
これは漸進的なデリバリーではありません。小さなウォーターフォール開発を複数のスプリントに分割しただけです。
インクリメントは、毎回のスプリントで全ユーザーに正式リリースしなければならないという意味ではありません。しかし、少なくとも完成の定義を満たし、利用可能であり、次のスプリントでテストや統合を終えなければリリースできない状態であってはいけません。
実際のユーザーが成果に触れられなければ、本当のフィードバックは得られません。デモで出た意見だけを頼りに、プロダクトの方向性を推測することになります。
チームが共同でインクリメントを作れない
DBA、DevOps エンジニア、ネットワークエンジニア、フロントエンドエンジニア、バックエンドエンジニア、マーケティング担当者が一人ずついるチームを想像してください。
全員が同じボードを使っていても、それぞれの仕事に関連性がなく、共同で一つのプロダクトインクリメントを作ることができません。
マーケティング担当者にファイアウォールの設定変更が割り当てられ、フロントエンドエンジニアが Kubernetes に Prometheus Operator を構築し、DBA が Google Tag Manager を調整するよう指示されるなら、問題はメンバーが専門外のことを学びたくないからではありません。最初からチームの境界が間違っています。
クロスファンクショナルとは、全員が何でもできるという意味ではありません。スクラムチーム全体として、インクリメントを完成させるために必要なスキルを持ち、一つのプロダクトゴールに共同で責任を持つという意味です。
同じ部署のメンバーが互いに無関係な依頼を処理しているだけなら、カンバンや一般的な業務管理の方が適しているかもしれません。無理にスクラムを当てはめる必要はありません。
このようなチーム構成を見ると、会社が意図的に社員を退職へ追い込もうとしているのではないかとさえ疑います。
スプリントが短すぎて会議しか残らない
以前、6 週間後にリリースしなければならないため、スプリントを 1 週間に短縮したプロジェクトがありました。
その結果、毎週プランニング、レビュー、レトロスペクティブを行い、その上でチーム間の調整やリリース作業も必要になりました。エンジニアが問題を理解し始めたころには、次のプランニングが始まります。
短いスプリントはフィードバックを早められますが、その期間内にチームが利用可能なインクリメントを完成できることが前提です。
大量の外部承認、部門間の待ち時間、手作業のデプロイが必要なら、スプリントを短くしても会議の割合が増えるだけで、デリバリーは速くなりません。
まず待ち時間と依存関係を解消し、その後で適切なスプリントの長さを決めるべきです。
スクラムマスターがソフトウェア開発を理解せず、関わろうともしない
「PMP を持っていても優秀な PM とは限らない。ただし、PM の仕事を得る助けにはなるかもしれない」
スクラムマスターも同じです。資格を持ち、研修を受け、コーチングを経験したからといって、チームの改善を支援できるとは限りません。
私の考えでは、ソフトウェアチームのスクラムマスターは、最も優秀なエンジニアである必要も、主要な開発作業を担う必要もありません。しかし、ソフトウェア開発をまったく理解していない人や、「コードを書きたくない」という理由でスクラムマスターを選ぶ人は、この役割にまったく適していません。
チームの障害は、多くの場合、開発プロセスの中にあります。要求は技術的に実現可能か、技術的負債がなぜデリバリーを遅らせているのか、テストやデプロイはどこで止まっているのか、サービス間の依存関係はスプリントゴールにどう影響するのか。スクラムマスターがこうした話を理解できず、理解しようともしないなら、本当の障害があるのか、仕事の進め方を改善すべきなのかを判断できません。
これは、スクラムマスターが開発者の仕事を奪うべきだという意味ではありません。少なくともソフトウェア開発に実際に関わった経験を持ち、要求、設計、実装、テスト、デプロイまで、機能が届けられる一連の流れを理解している必要があります。現在は主要な開発を担当していなくても、「技術には触れない」を自分の役割としてはいけません。
台本どおりに会議を進行し、ベロシティを計算し、チケットの更新を催促することしかできないなら、技術チームの外側に技術を理解しない管理層を一つ増やすだけです。チームの有効性を高めることはできません。
優れたスクラムマスターは、チームの代わりにすべてを決める人ではありません。問題を透明にし、組織的な障害の除去を支援し、チームが自分たちで問題を解決できるようにします。
ベロシティを KPI にする
ベロシティは、同じチームが自分たちのデリバリー能力を理解するためには役立ちます。しかし、異なるチーム同士を比較するためには使えず、人事評価指標にするべきでもありません。
マネージャーがスプリントごとにベロシティを上げるよう求めると、最も簡単に変えられるのは生産性ではなく、ストーリーポイントの見積もりです。
これまで 3 ポイントだった作業を 5 ポイントにすれば、グラフはすぐに伸びます。しかし、プロダクトが早く届けられるわけではありません。
本当に見るべきなのは、チームがより安定してスプリントゴールを達成できているか、インクリメントが本当に利用可能か、アイデアから実際のユーザーフィードバックまでにどれだけ時間がかかるか、同じ問題が繰り返されていないかです。
本当にスクラムが必要かを先に確認する
スクラムは、要求と解決策の両方を、実装とフィードバックを通じて段階的に探る必要がある複雑な仕事に向いています。
互いに無関係な依頼を大量に処理し、優先順位が頻繁に変わり、それぞれの作業を独立して完了できるなら、カンバンの方が自然かもしれません。
要求、技術、デリバリー方法が十分に明確なら、「アジャイル」を名乗るためだけに定例イベントを増やす必要はありません。
スクラムを導入する前に、次の質問に答えてみてください。
- チームは一つのプロダクトゴールに共同で責任を持っているか？
- プロダクトオーナーはプロダクトバックログの順序を本当に決められるか？
- チームは一つのスプリント内でインクリメントを完成させる能力を持っているか？
- 完成の定義にテスト、統合、必要なリリース準備が含まれているか？
- スプリントレビューでステークホルダーから有効なフィードバックを得られるか？
- レトロスペクティブで決めた改善は実際に実行されているか？
- チームは罰を受けることなく問題を明らかにできるか？
ほとんどの答えが「いいえ」なら、スクラムの儀式を増やしても役には立ちません。
まとめ
スクラムを導入しただけで、チームが自動的に速くなるわけではありません。
スクラムが行うのは、透明性、検査、適応を通じて、組織に元から存在する問題を早く表面化させることです。
決定権のないプロダクトオーナー、マイクロマネジメントを続ける上司、独立してデリバリーできないチーム、時間のかかるリリースプロセス。これらは、スプリントやボードを作っただけでは消えません。
会社が問題を認識し、権限、チームの境界、デリバリーの仕組みを変える意思を持って初めて、スクラムは機能します。
週次会議をデイリースクラムと呼び、要求一覧をプロダクトバックログと呼び、ベロシティで業績を測るだけなら、スクラムがもたらすのはアジリティではなく、より多くの会議です。
一方で、ウォーターフォール開発を採用しているからといって、チームが遅れているわけでもありません。
要求が明確で変更が少なく、各工程の責任と受け入れ基準を事前に定義できるなら、ウォーターフォール開発は計画、予算、納期をより明確にできます。厳格な審査、規制文書、ハードウェア統合が必要なプロジェクトでは、スクラムより適している場合もあります。
開発手法に優劣はありません。スクラム、カンバン、ウォーターフォールは、チームが仕事を完了するための道具であり、信奉すべき教義ではありません。
チームが価値ある成果を安定して予測可能な形で提供できるなら、それは優れた開発手法です。反対に、ある手法が待ち時間、会議、コミュニケーションコストを増やし、プロジェクトの進行を妨げるようになったなら、見直すべきです。必要であれば、使うこと自体をやめるべきです。
チームが本当に目指すべきなのは、「スクラムを正しく実践できているか」ではありません。「価値あるプロダクトを継続的に届けられるか」です。