スコープクリープ に対処する 4 つの基本方法

スコープクリープ はあらゆるソフトウェア開発プロジェクトに忍び寄り付きまといます。他のアジャイルプラクティスと同様、スコープクリープの管理方法はチームごとに異なり、この点はアトラシアンのチームも例外ではありません。そこで、どのようにスコープクリープを対処しているのかアトラシアンの 2 チームから直接学んでみることにしました。

私たちは JIRA Agile チームと Fusion チームの 2 チームの開発リーダーをインタビューしました。アトラシアン Fusion チームは JIRA や JIRA Agile と Dev Tools の統合を監督しています。この 2 チームは共同作業を行うことがよくあるのですが、スコープクリープの管理方法は驚くほど大きく異なっていることが分かりました。この 2 チームに関して語る前にまず、スコープクリープとは何か、そして、なぜ発生するのかについて確認してみましょう。

スコープが徐々に変形・拡大 (クリープ) し始めるタイミング

スコープクリープ とは、プロジェクトが進行するにつれ当初の目的を超えてプロジェクトが肥大することです (すなわち、当初のスプリント、エピック、リリースに予定外の作業が追加されます)。スコープクリープの発生理由は多数あります。以下にその例をいくつか挙げます:

• 市場環境が変化し異なる機能セットが必要となる
• ユーザーからのフィードバックで機能性能を変える必要があることが分かる
• チームが作業を進めるにつれ実装の複雑性や予期せぬ依存関係が明らかになる
• 初期のプロジェクトスコープへの理解不足が継続的な肥大化を招く (身近なはずです)

誤解してほしくないのですがスコープクリープは必ずしも悪いことではありません。

継続的にイテレーション、学習、外部インプットへの対応を実行しているアジャイルチームにとってスコープクリープは健全なサインとなることもあります。

Tweet

しかし、適切な管理や透明性のある対応を怠るとスコープクリープは問題へと変わります。

スコープクリープの原因とは関係なく (1) スコープクリープの発見方法、(2) その影響の理解方法、(3)データに基づいた決定で調整する方法、最後に (4) チーム全体への明確な変更の伝達方法、を理解することが重要です。

1. スコープクリープの発見方法

スコープクリープは大抵どこかにその兆候を見つけられるものですので、早期発見が重要です。なぜでしょうか? スコープクリープはリリースを遅らせ、さらに悪いことにソフトウェアに不必要なコードやリスクを招き入れることがあるからです。

では、JIRA Agile チームはどのようにスコープクリープを発見しているのでしょうか? 開発マネージャー、ミカエル・トカーの説明によれば、JIRA Agile チームは 2 週間のスプリントで作業をしていますが、スプリント期間に AtlasBoards、ガジェット、バーンダウンチャートがチームに非常に役立っているということです。テレビ画面に AtlasBoards をセットアップし、その中心に Sprint Health ウィジェットを表示し、その画面をチーム全員で取り囲みます。Sprint Health ウィジェットは、ステータス/カラムをグループ化したものを単に SUM (推定値) したバーを表示します。したがって、ミカエルとチーム全員はスプリント期間中のスコープ変更が目に見えるということです。

ミカエルは Atlasboards の他に、 Agile Sprint Health ガジェットと Agile Sprint Burndown ガジェットを JIRA ダッシュボードに設定することも推奨しています。なじみのないユーザーの皆さんにご説明すると、バーンダウンチャートはスプリントで完了すべき作業量の実績データと計画データを比較して描写します。このグラフはミカエルのような開発マネージャーにとってスプリント期間のチームの作業実績状況とスプリント目標に達成する見込みを確認するのに役立ちます。達成作業量のグラフが計画通りに進まない時は、何かよからぬ事態が発生しスコープクリープがその一因である可能性が高いことを示す大きなサインです。JIRA Agile レポートはすべてリアルタイムでデータ表示されるので、ミカエルは深く調査する必要なくグラフに現れる突出した値やパーセンテージの変化を見て取ることができます。

Fusion チームの場合は、スコープクリープの発見はスコープ変更の種類ごとに異なります。チームリーダーのブルース・テンプルトンによれば、製品オーナーが「XYZ をするまでリリースしないでください」と伝えてくる実世界のスコープクリープは最も分かりやすく発見するのが最も簡単なものです。テンプルトンは JIRA Portfolio でストーリーを作成し、彼のチームはそのストーリーに見通しを割り当て影響を確認します。一方、予期せぬ変数 (例えば、API 変更や機能を別のページレイアウトに一致させる必要) が引き起こすスコープは、詳細な Bamboo ビルドと早期・継続統合することで発見します。

Fusion チームは他のチームに依存しているので、ブルースはスコープ変更を発見するために「スクラムのスクラム」ミーティングも活用します。「スクラムのスクラム」は大規模プロジェクトの作業を実行中の複数のスクラムチームで行う複数チーム合同スタンドアップです。スクラムのスクラムはナレッジ (知識) 共有を可能にし、スコープクリープなどの重要課題を早期に表面化できます。

2. スコープクリープの影響の理解方法

レポート、ガジェット、JIRA Portfolio のようなツールを使えば、スコープクリープがスプリントの作業負荷に忍び寄っている場合、簡単に把握できます。次のステップは、少々複雑なスコープクリープの影響の管理です。ミカエルが説明するように、スコープクリープへの対応は「緩和だけでなく理解が重要です」。

先に述べたようにスコープ変更は幅広く、すでにコミットした作業を完成するために必要となった新しいストーリーの追加や、チーム内の専門家がスプリントの期間中に作業がなくなり追加作業が必要となった場合まで様々です。もっとよくある状況は、プロダクトマネージャーが利害関係者から緊急リクエストを受けた場合でしょう。このようなすべての状況において、スコープが追加される前か追加直後にチームリーダーはプロダクトマネージャーと話し合います。

ミカエルの表現では、チームリーダーが最も気にするのは 1 回のスプリント期間で「コミットし、完了した作業量」です。したがって、新しいストーリーが追加された場合は、優先度が高い場合は特に、次回のスタンドアップでチームに伝達します。JIRA Agile チームにとっては変更をチーム全員に早期に伝達することがスコープクリープの影響の理解に含まれます。そして、新しい作業追加の見通しとそのトレードオフに関する話し合いにつながります。

一方、ブルースがすぐに関心を持つのはスコープ変更がチームの作業完了時間にどのような影響を与えるかということです。したがって、JIRA Portfolio を使って多種多様な「What-If シナリオ」を検討し、スコープ変更が Fusion チームのロードマップに与える影響を確認します。

このシナリオプランニングは通常、ブルースと Fusion チームのプロダクトマネージャーと共に行われ、リリース日やスコープ、リソース (すなわち、人員) などの変数の調整を試みます。ブルースはこれを「レバーいじり」と呼んでいます。適切なバランスや優れた妥協点を見つけるまでこのレバーいじりが実行されます。スコープクリープが発生したら、すべてのオプションを検討してデータに基づいた決断を行うことが重要です。

3. スコープクリープに基づいた作業負荷の再編成方法

これでスコープ変更を発見し、その原因を理解できるようになりました。次に決断を下す必要があります。スコープ変更を受け入れリリースを遅らせますか? リソースを増やしますか? 初期要件を削減しますか? チームは何をすればいいのでしょうか?!

JIRA Agile チームは Epic Burndown とそのサイドバーのレポート表示の中にある Release Burndown チャートを使い、プロジェクトを大局的に検証してスコープクリープを管理しています。Epic Burndown チャートは、スプリントごとに分類してエピック完了に向けたチームの進捗状況を示します。対象エピック完了までスプリント何回分の作業量が残っているかを示す作業見通しも表示します。スコープクリープの観点で最も重要なのは、このチャートは作業追加時と追加量 (Release Burndown チャートはリリースレベルで同じ情報をハイライトします) をハイライトすることです。チームは最初 10 回のスプリントでエピックを完了しようと考えていたかもしれませんが、6 回のスプリントの後 Epic Burndown は残りの作業量は 6 スプリント分と示しています。

JIRA Agile チームとは異なり、Fusion チームはバーンダウンチャートへの依存度は低く、JIRA Portfolio を使った What-If シナリオプランニングへの依存度が高くなっています。「ウォーゲームの実行」で可能性のあるスコープ変更のオプションと影響をすべて可視化できるからです。JIRA Portfolio の What-If シナリオと JIRA Agile のバーンダウンチャートが利害関係者にデータポイントを提供し、チームの決断を助けるとしても、処置を講じて困難な (本当に困難です!) 決断をするのはチーム次第です。

リーン・アジャイル基本方針に基づけば、チームができるだけ早急に最新機能のリリースを望むことに異論はなく、したがって、新しい MVP (実用最小限の製品) が合意されます。この方法だと、チームがエピックにスプリントを追加する場合よりも新しい機能が早期にカスタマーの手に届きます。このようなトレードオフは、機能やリリースがプロジェクト開始当初にチームが届けるつもりだったものとは異なることを意味します。しかし、それは問題ありません。 意識的な調整はアジャイルの本質です。

決断したら、ブルースのようなチームリーダーは JIRA Portfolio や JIRA Agile でバックログ (ストーリー、エピック、イニシアチブ) を整理し直すことができます。JIRA Portfolio の場合だと、新しいバックログは新しいリリース日程に基づいてロードマップを自動更新します。リアルタイムデータを使用することで、週末返上の最悪の指令の代わりに達成可能な作業量を再編成できます。

4. スコープクリープの影響の伝達方法

決断したら、全員に最新情報を伝えることがスコープクリープ対処時の最終ステップです。スコープ追加はチームの士気を落とすことがあります。書類上はチームが達成しようとしていた作業が達成できなかったかのように見えるからです。スコープが追加された理由と今後のスプリント、エピック、リリース、プロジェクトにどんな影響がありうるのかをチーム全体に理解してもらうことが重要です。

JIRA Agile チームの場合、チームリーダーとプロダクトマネージャーの間でスコープ追加に関連した話し合いが行われる一方、開発マネージャーのミカエルは進行中の作業を注意深く見守ります。スコープクリープは JIRA Agile チームのふりかえりミーティングでの話し合いの大きなテーマでもあります。これらのミーティングで参加者全員に決定内容や必要に応じて新しいゲームプラン内容、次のスプリントで見込まれる内容を理解してもらいます。JIRA Agile チームでは全員にできるかぎり早期かつ頻繁にスコープ変更が伝えられます。

ブルースは、JIRA Portfolio を使ったスコープ変更の影響の伝達は、紙ナプキンの裏に走り書きした計算ではなくデータに基づいた見通しを伝えられるのでかなり自由にできると感じています。ブルースは JIRA Portfolio で使えるあらゆるオプションを理解しているので、JIRA Portfolio は利害関係者とオープンな意見交換ができる優れた手段です。また、チーム全体が Fusion ロードマップにアクセスできるので、納入可能日やリリース日に関して全員が共通理解を持てます。

スコープクリープは不可避

スコープクリープは避けられないもので対処が必要です。本稿ではアトラシアンでのスコープクリープの対処法を説明しました。今度はあなたの対処方法も是非知りたいと思います。コメント欄でスコープクリープの効果的な方法やヒントを教えてください。本稿が役立ったと感じていただけた場合はご利用のソーシャルネットワークで是非シェアしてください。 あなたの周りの JIRA ユーザーの仲間たちに感謝されますよ! ?