スクラムによるリスク管理

はじめに

複雑な状況下でのプロダクト開発は、予測不可能で、不確実な性質があるため、常にリスクを伴います。ビジネス、マーケット、テクノロジー、アーキテクチャ、統合、通過、金融、マーケティングなど、不確実性には多くのタイプがあります。もはや、プロダクトを提供しながら多くのリスクに直面することが定番です。それは、もう当たり前のことであり、自然なことです。したがって、すべきことはリスクを管理することだけです。

よくある勘違い

興味深いことに、アジャイルチームにとってリスクは気にならないという信念に出会うことが多くなりました。あるいは、スクラムではリスクを管理する必要がないとか、リスクはウォーターフォールにあるとかです。あるいは、「私たちはアジャイルであり、私たちはスクラムを実践しているから、リスクはない」とかです。リスクのある要求とは？リスクのあるビジネス戦略とは？リスクのあるテクノロジーとは？

スクラムで仕事をしていると、リスクのことを忘れがちです。そうではない場合は、従来のリスク管理とスクラムのプラクティスを混ぜて用いることがあります。このハイブリッドなアプローチでは、効果的でないか、役に立たないかもしれません。従来のリスク管理で、チームがスクラムを実践している場合、リスク管理を適応する方法で行うことに気づかないため、適応性を失ってしまいがちです。結果は、おそらく満足のいくものにはならないでしょう。そのリスクはスクラムチーム以外の外部の人によって、ときどき管理されることになるでしょう。そのような状況では、透明性の欠如につながります。また、チームのエンパワーメントや自己組織化にも影響する可能性があります。

事実

リスクは、どこかに帰属するというものではありません。スクラムであれ、計画駆動な開発であれ、行っているアプローチに関わらず、リスクはすべてに存在しています。もちろん、事実、スクラムではリスクを管理しているのです。

スクラムでリスクを管理するには

常に実証的に。短く答えるならば、「透明性」、「検査」、「適応」を用いることです。私は、組織と協力してプロセスをよりよく示すステートメントとして「実証主義」を展開しています。

スクラムチームと利害関係者が共に、現存するリスクをリストアップします。そして、プロダクト（ソリューション、フィーチャー、ビジネスなど）に対する出現率や影響について議論します。そして、リスクを分類します。リスクがビジネスによるものなのか、通過によるものなのか、マーケットによるものなのか、テクノロジーなのか、アーキテクチャに関連するものかなどです。この実践がスクラムチームと共に仕事をするときに役に立っています。中でも重要なのは、「価値」をもたらす可能性を議論することです。これらのリスクをどのように管理するかについて、いくつかの戦略を立てます。「具体的な脅威に対して注意を払う価値があるか？」とか、「出現率や影響が低いので見送っても大丈夫か？」とかです。

一度実施したら、リスクのリストを頻繁に見直しし、それに応じて適応させていくことが必要です。そうでないと、リスクのリストが包括的ではあるものの、現状にそぐわない時代遅れなリストになってしまうからです。私は、エンゲージメントや創造性の向上やビジネスとITの統合のための、コラボレーションモデルでのショートセッションを行うことをいつも推奨しています。それは実証的でなければなりません。必要に応じてなのですが、それでも頻繁にリスクを見直しします。それぞれのプロダクトバックロブアイテム（PBI）にリスク情報も追加します。ビジネス価値についての情報を追加することで PBI が完成します。

「スクラムでリスク管理をするタイミングはいつなのか？」とよく聞かれます。どのようにしたらいいでしょうか？スクラムチームには、多くのスクラムイベントや追加したミーティングがあります。スクラムチームは、リスクを管理するためのさらに別のミーティングをスケジュールしようとはしません。もちろん、そんなことはしないでください。では、スクラムではいつリスクを管理するのでしょうか？

いつでも！

スクラムイベントは、リスク管理を支援できる実証的なものである

スクラムイベントをリスクの管理にも活用します。実際に多くのチームがそれを行っています。頻繁かつ知らず知らずに直感的に行っているのです。ただし努力は必要だということは彼らのDNAなのです。

あなたの場合で、もし実証的なリスク管理が実施されていないならば、スクラムイベントで、リスクについての会話を始めるところから検討してみてください。

スクラムのイベント

• デイリースクラム
  このイベントには、スプリントゴールを目指すためのリスクの管理、アイテムの進捗が含まれています。
• スプリントプランニング
  スプリントプランニングの間に、予測を立てます。それからスプリントバックログとスプリントゴールを設定します。予測とは、全ての不確実性です。つまり、リスクのことです。
• スプリントレビュー
  このイベントは、現時点のインクリメントと展望を討論しながら、ビジネスとテクノロジーのリスクについて議論する理想的な機会です。この会話は、今後のプロダクトバックログアイテム（PBI）に影響を与えるかもしれません。
• スプリントレトロスペクティブ
  スクラムチームとして何を改善すべきかを実りのある会話の機会です。これにより、プロセス、人、テクノロジー（PPT: People, Process, Technology）のリスクを軽減するためと考えることもできます。
• スプリント自体
  スプリントの期間の長さは、利害関係者と分断することによるリスクとして議論できます。スプリントの長さを制限することは、しばしばリスクを制限することになります。完成した潜在的にリリース可能なインクリメントをデリバリーする可能性を考慮に入れましょう。

スクラムの活動

• プロダクトバックログリファインメント
  スクラムチームと利害関係者にとっては、リスクについての議論を盛り込むよい機会となります。
  • リスクが高くても価値がある PBI はどれか？
  • リスクが高くて大きな価値ももたらさない要素はどれか？
  • それをプロダクトバックログに入れておく価値があるのか？
  • 仮説を検証するためにどのような実験を行う必要があるか？

スクラムの作成物は、リスク管理を支援できる実証的なものである

• インクリメント
  インクリメントとリリース戦略も、全てリスク管理のためのものです。実際に完成したものをデリバリーする（潜在的にリリス可能なインクリメントや、それをマーケットにリリースすること）までのリスクを最小限におさえることができるかもしれません。完成の定義（DoD: Definition of Done）は、品質とインクリメントの「リリースの準備」（作業完了し、統合し、リリース可能になったもの）をより良く取り扱うための戦略として反映します。
• プロダクトバックログ
  プロダクトオーナー（PO）は、プロダクトバックログを管理する責務を持ちます。POの活動のひとつとして、プロダクトバックログアイテム（PBI）の優先順位付けがあります。PBI の優先順位付けでは何を考慮することになるでしょうか？明らかにリスクと価値（それから、規模や依存関係など）です。
• スプリントバックログ
  開発チームの活動としては、自身のリスクを管理することが含まれます。スプリントバックログのアイテムの修正・調整や、妨害要因の指摘、見える化の促進、仕掛かりの制限、実験からの学びなど、どうしたら、より良いスプリントゴールを達成できるのかといったリスク管理でもあります。

スクラムでリスクを管理すべきは誰か？

もっとも短くてわかりやすい答えは、以下です。

スクラムチームのメンバー全員に、スクラムチームのそれぞれの役割に依りますが、関連するリスクを管理する責務があります。

リスクは妨害要因ではなく、機会になる

リスクがある PBI が、リリースした後にかなりの価値が期待できるとしましょう。あなたならどうしますか？

私ならば、あなたの仮説を検証するために実験することをお勧めします。リスクがチャンスに変わるかもしれませんので。

まとめ: スクラムでどうリスクを管理するのか

• コンスタントに、スクラムイベント、作成物、メトリクスなどを活用する
• リスク軽減のための戦略を持ち、戦略を頻繁に見直す
• 短期間かつ低コストに実験する、仮説を検証する、データを収集する、決定を下す。そして早期にリスクを取り除く
• プロダクトバックログにリスクに関する情報を入れ込むことを検討する
• 日々、透明性を確保するように講じる
• 実証主義の観点で考える
• 見える化する