Alternative Architecture DOJO

オルターブースのクラウドネイティブ特化型ブログです。

ゾンビスクラムにならないための6つの問い

7月にscrumalliance.orgの認定スクラムマスターを取りました、花岡です。 オルターブース Advent Calendar 2022 10日目の記事です。

はじめに

スクラムというものは「理解は容易、習得は困難」とよく言われます。実際その通りスクラムガイドや関連書籍を読んでやってみたけど、どこか上手くいかなかったことがあると思います。

その原因はスクラムに対する誤解や理解不足、組織体制、スクラムガイドだけでは足りない実践知などさまざまな問題があると考えます。その中でゾンビスクラムといわれるアンチパターン的なスクラムを本記事では取り上げていきます。

本記事の対象者と前提知識

  • 前提知識
  • 対象者
    • スクラム経験者
    • スクラム未経験だけど知識として知っている
    • スクラムを採用検討もしくは採用している管理職や上長

ゾンビスクラムとは

著作者:DCStudio/出典:Freepik
ゾンビスクラムとは書籍ゾンビスクラムサバイバルガイドによると周りからは一見スクラムガイド通りのスクラムをやっているように見えます。スプリントプランニングはスプリント開始時、デイリースクラムは1日ごとに実施し、スプリントレビューとスプリントレトロスペクティブはスプリント終了時に開催しています。

しかしスクラムチームをよく見てみると動くプロダクトはなく、スプリントレビューでステークホルダーが動作を確認することなくプレゼン資料や進捗報告を受けるだけになっています。また開発者はスプリントバックログを単純にこなすだけに集中してしまい、スクラムマスターはただスクラムイベントのファシリテーターをこなすだけになっているなど、退屈で頭を使わず、心もない。誰もその状況を気にも留めていない、ゾンビのように心臓の鼓動が感じられないスクラムをゾンビスクラムと呼んでいます。

スクラムをやってみたけどなんだか上手くいっていないなと思ったら、ゾンビスクラムになっている可能性があります。 スクラムイベントやプラクティスをやれば、表面的にはスクラムを実践していると思い、実際には形だけでスクラムチームはいろいろな制約で身動きがとれず、スクラムが面倒な作業プロセスだと感じてしまいゾンビになっていくのはよくあるパターンです。

6の問い

なぜゾンビスクラムは起きてしまうのでしょうか。スクラムガイドに書いてあることはスクラムを実践する上で必要十分条件のことだけが書いてあります。それゆえに、現場で実践する際にはそのまま適応できず、部分的にスクラムを採用してしまうケースがあります。たとえば、デイリースクラムで現時点の状況がスプリントゴールに達成できるかでどうかを確認しないで、単に進捗報告会になっていたり、あるチームがスプリントの期間を固定せずに進捗状況によって可変にしてしまう場合などです。多くの場合は意図的に部分採用をしようとやっているわけではないとは思いますが、それはスクラムの利点を享受できないばかりか、苦労することが多くなります。
今回そうならないために、書籍を参考してゾンビスクラムになる原因の特定や改善のきっかけとなる6つの問いを考えました。

1. ステークホルダーと協調して価値あるプロダクト作りはできていますか

スクラムでのステークホルダーはプロダクトの利害に関わるすべての人を指しますが、ゾンビスクラムではその曖昧さから営業、マーケティング、上司など企業内部のステークホルダーだけに限定していることがあります。本来、プロダクトを実際に利用するユーザーやプロダクトに価値を感じてお金を払ってくれる顧客が真のステークホルダーであるべきですが、内部のステークホルダーにフォーカスしてしまうとプロダクトがユーザーや顧客のためではなく、内部のステークホルダー向けになってしまいます(ただし、内部のステークホルダーがユーザーや顧客である場合は別)。 それはプロダクトのインパクトやアウトカムに関わらないオーディエンスといえます。そのような状態のスクラムは、スプリントレビューでステークホルダーではなくステークホルダーからのフィードバックや仮説検証が出来ず、実際のインパクトやアウトカム(成果)が出なくなりプロダクトの成長の鈍化や開発の停止などにつながってしまします。
適切なステークホルダーを巻き込むためには、以下の質問が役に立つとゾンビスクラムサバイバルガイドに書いてあります。

  • この人は、普段からプロダクトを使っている人か、または使う予定の人か?
  • この人は、プロダクト開発にたくさんの投資をしているか?
  • この人は、あなたのプロダクトが扱う課題の解決に時間もお金も投資をしているか?

ステークホルダーは課題が解決してリターンを得られるならば、時間やお金を投資してくれます。それゆえに開発しているプロダクトに対して適切な助言やフィードバックをくれます。正しいステークホルダーを見つけ、それに含まれる人、含まれない人を整理していきましょう。

2. 動くプロダクトや価値あるインクリメントはありますか

1では適切なステークホルダーを見つけることに言及しましたが、そもそもスプリントレビューで動くプロダクトやインクリメントがなければ適切なフィードバックが得られず、ステークホルダーも積極的にプロダクトに関わろうとはしなくなります。フィードバックがなければ、プロダクトが間違った方向に向かっているかという検査ができず、ムダに時間とお金と労力を割いてしまう可能性があります。

動くプロダクト、インクリメントを用意できない原因は以下のものが考えられます。

  • デプロイの自動化やCI/CD環境が整っていない
  • 完成の定義が整っていない
  • スプリント内でリリース可能にすることの価値が理解できていない
  • スプリントで扱うプロダクトアイテムバックログのサイズが大きすぎる等

環境やプロセスが適切に整っていなかったり、早くリリースできることによる市場の反応や競争力の獲得など検査と適応の価値を見いだせていないことによるものがあるかと思います。これらを見直すことがフィードバックループを上手く回せるようになるためのきっかけになるでしょう。

3. ゴールは適切に設定できていますか

スクラムではゴール(目標)の設定が重要です。プロダクトゴールはスクラムチームの長期的な目標でプロダクトの将来を表しています。スプリントゴールはスプリントでプロダクトゴールを達成するために必要な短期的な目標で開発者が達成を確約するためのものです。
ゴールを適切に設定すれば、スクラムチームはゴールの達成に向かって集中し、プロダクトのインパクトやアウトカムを出すために必要な行動を起こすようになります。
しかし、ゾンビスクラムになってしまうとは明確なゴールがなく、感情も向上心もなくふらふらと歩いているだけでインパクトやアウトカムが出ずにただ単に作業をこなしたというアウトプットに終止してしまいます。

では、どのように適切なゴールを設定すれば良いのでしょうか?プロダクトゴールやスプリントゴールを考えるにはいくつかの質問を元に考えることが重要です。

  • プロダクトゴールを設定する
    • このプロダクトゴールは、どのように私たちを助けてくれるのか?
    • このプロダクトゴールは、ステークホルダーにどのような変化や成果をもたらすのか?
    • プロダクトゴールが正確かどうか?それはどうすればわかるのか?
    • どうやって指標を計測するか?このプロダクトゴールにいつ到達するか?どうやって知ることができるのか?
  • スプリントゴールを設定する
    • プロダクトゴールを達成するために必要なものはなにか?
    • スプリントゴールを達成するとステークホルダーにどのような変化や成果をもたらすのか?
    • スプリントゴールが曖昧なモノではなく、達成の判断が可能か?

適切なゴールを設定するのは難しいですが、スクラムチームが健全なスクラムを実施するための必要な作業です。ゴールが明確であればあるほど、透明性が確保でき、ゾンビスクラムから回復できます。

4. スクラムイベントは機械的になっていませんか

スクラムでは5つのイベントを定義しています。

  • スプリント: 他のイベントの実施するための期間の決められたタイムボックス
  • スプリントプランニング: スプリントゴールを決め、達成にスプリントバックログを計画する
  • デイリースクラム: スプリントゴールへの進捗状況を検査する
  • スプリントレビュー: ステークホルダーからプロダクトのフィードバックを収集する
  • スプリントレトロスペクティブ: スプリントのふりかえりを行う

イベントをこなせば表面的にはスクラムをしているといえるかもしれません。しかし退屈で機械的にイベントをこなすだけで、ただムダに時間を過ごすとものだと感じている人がいればそれは生気のないゾンビスクラムとなっているでしょう。それはもしかしたらスプリントレトロスペクティブが上手く機能していないからかもしれません。スクラムイベントを楽しく魅力的なモノにするには、レトロスペクティブの方法を変えたり、デイリースクラムの質問の方法を変えてみるなど方法はあります。詳しく述べるにはこの記事の趣旨から外れますので、ふりかえりガイドブックゾンビスクラムサバイバルガイドをご参照ください。

5. 継続的に改善ができていますか

ゾンビスクラムチームはスプリントが失敗しても成功しても、何ら興味を持たず、士気は低く、それを改善しようとも思わないチームです。 改善の機会のないチームはゾンビのように、あちらこちら手足がなく、うめき声が聞こえます。完了できなかったプロダクトバックログは当たり前のように次のスプリントに持ち越し、スプリントゴールはあいまいかそもそも設定されていなかったり、開発者やプロダクトオーナーは目の前のタスクをどれだけ完了させるかに集中していたりと心臓の鼓動が感じられない状態になっています。 そのような状況は失敗から学ぶことを恐れ(心理的安全性がない)、スプリントレトロスペクティブでは具体的な改善案が出ていないか実行できていない可能性があります。

スクラムイベントで検査と適応によって失敗したこと成功したことなどを学習できるようになっています。とくに、スプリントレトロスペクティブが仕事の進め方についてふりかえるイベントではありますが、レトロスペクティブが上手く回っていないと継続的な改善ができずに、心臓の鼓動がだんだんと静かになっていきます。

まずはスプリントレトロスペクティブで仕事の進め方や心理的安全性についてふりかえりの方法を変えたり、強化する必要があります。 心理的安全性を可視化するワークショップ「片思いマッピング」やふりかえりのやり方をふりかえる「ふりかえりのふりかえり」などワークショップを通して改善をしていくとよいでしょう。他にもふりかえりの方法はありますが、詳細はふりかえりガイドブックが参考になります。

6. チームは自律的に行動し、プロダクトに対する重要な決定権をもっていますか(自己組織化できているか)

自己組織化とは、無秩序だった個々の物体や要素が自律的な振る舞いの結果、秩序だった構造ができあがることです。自然界では雪の結晶や種が植物に成長するなどの事例があります。スクラムにおいては「自己管理」とも呼びます。その「自己管理」ができるようにするには、スクラムチームが自分たちでステークホルダーとのコラボレーション、開発、保守、実験、検証などプロダクトに関して必要となり得るすべての活動に責任を持ち、自分たちで作業を管理できるようにするための必要な権限を十分に持つ必要があります。

それらがないゾンビスクラムは、スクラムチームではない管理職がプロダクトに関する権限や決定を持っていたり、そもそもプロダクト開発に必要な技術的なスキルや専門性を持っていないため、外部の専門家に依存していたりします。そのような状況であれば、チーム内であれば数分で片付く作業が数日から数週間待たないと完了できないようになってしまいます。

スプリントゴールを達成するには、必要な権限やスキルを十分にもつクロスファンクショナルチームを形成する必要があります。そのためには管理職によるスクラムチームの支援も必要です。既存の統制やフレームワーク、標準化された解決策などをスクラムチームに強要せず、チームに必要な権限や支援を与えるようにすることが重要です。管理職が意思決定でチームを導くのではなく、スクラムチームが自分たちで物事を決定できるような環境づくりで成功に導きましょう。

さいごに

6つの問いを書きましたが、これ以外にもゾンビスクラムになってしまう原因はあると思います。詳細はゾンビスクラムサバイバルガイドをご参照ください。ゾンビスクラムを改善するための問いや重要なヒント、実験など健全なスクラムを実践するための役に立つ知識がのっています。ぜひ、あなたの組織やチームの人と一緒に読んで、できるところからゾンビスクラム退治に挑んでいってほしいです。

参考