The ‘relay race’ approach to product development… may conflict with the goals of maximum speed and flexibility. Instead, a holistic or ‘rugby’ approach—where a team tries to go the distance as a unit, passing the ball back and forth—may better serve today’s competitive requirements.
—Hirotaka Takeuchi and Ikujiro Nonaka, “The New New Product Development Game” [1]
SAFe Scrum
注: SAFeスクラムについての詳細は、スクラムシリーズのフレームワークの追加記事をご覧ください。これには、スクラムマスター / チームコーチ、イテレーション、イテレーションプランニング、イテレーションゴール、イテレーションレビュー、イテレーションレトロスペクティブが含まれています。
学習を始めますか？
検索ツールを使用して現在の提供内容を探索するか、特定のコースについて詳しく学びましょう。
定義: SAFeスクラムはART内でチームが使用するアジャイル手法の1つで、短いタイムボックスでバリューをカスタマーにデリバリーします。 SAFeスクラムチームはイテレーション、カンバンシステム、スクラムイベントを使って仕事の計画、実行、デモ、レトロスペクティブを行います。
多くのチームが、SAFeスクラムを主要なアジャイルチームのプロセスとして使用していますが、SAFeスクラムに限定しているわけではありません。SAFeチームカンバンを利用する場合があります。とはいえ、SAFeチームはすべて、作り込み品質のテクニックや、スクラムでは定義されていないその他の実践と活動を適用します。SAFeスクラムチームは、他のアジャイルチームやARTステークホルダーと協力し、顧客にベネフィットをもたらすソリューションの構築とデプロイを行います。
この記事では、アジャイルチームがSAFeスクラムを適用する方法について説明します。
詳細
SAFeスクラムを適用するアジャイルチームは、共通の目標を達成するために定期的なイベントのケイデンスに従い、企業と顧客にバリューをデリバリーします。 チームは、権限と自律性を備えており、自分たちの仕事を計画し、実行し、管理し、自分たちのスコープ内で意思決定を行なって、変化する状況に最も適した方法で適応します。SAFe原則＃9「意思決定を分散する」は、ベクトルを確実に揃え、SAFeスクラムチームに対するマネジメントからの指示を最小限にします。
実際、チームは自分たちの仕事の進め方と、イテレーションのタイムボックス内でコミット可能なスコープを決定します。チームは、イテレーションゴールを定義し、そのゴールにコミットしながら、ストーリーと受け入れ基準を記述したバックログ項目を作成し、精緻化します。その後、ソリューションのインクリメントごとに新しい機能を構築し、テストし、デプロイを行って、確実に品質を作り込みます。
さらに、スクラムチームは、バリューのインクリメントを開発し、デリバリーするために必要なすべての役割とスキルを備えているので、制約と他のチームとの依存関係を最小限に抑えて活動できるようにデザインされています。スクラムチームの自己管理と機能横断的な性質は、絶え間ないコミュニケーション、建設的な対立、活動的な対話とともに、より楽しく、生産的な仕事の環境を作り出します。
SAFeスクラムのサイクル
図1は、SAFeの用語（例えば、スプリントのことをイテレーションと呼んでいる）を使用して基本的なスクラムのサイクルを示しています。このサイクル内の各イベントは、進捗状況を点検し、軌道修正を行う機会を提供します。これらのイベントは、オーバーヘッドを減らすために、しばしば同じ時間と場所で開催されます。
次のセクションでは、SAFeスクラムのサイクルの概要について説明します。
スクラムのイテレーションとイベント（イテレーションプランニング、イテレーションレビュー、イテレーションレトロスペクティブなど）は以下のセクションで簡単に説明し、SAFeの記事で詳細を説明します。
チームバックログ
チームバックログには、ソリューションを前進させるために必要な今後の仕事がすべて保持されます。仕事の大部分はユーザーストーリーによって把握されますが、その他の仕事や活動 (トレーニング、サポートなど) も含まれる場合があります。チームバックログは、PIプランニング中に部分的に埋まり、チームは自分たちのPIオブジェクティブを確立しているはずです。チームはバックログを継続的に精緻化し、重大なリスクや予期せぬ事態を招くことなく実装する準備が整ったストーリーが常にバックログに含まれるようにします。バックログリファインメント中に、チームは今後のユーザーストーリーやフィーチャー（適切な場合）をレビューして、定義し、話し合い、見積り、今後のバックログ項目の受け入れ基準を設定します。バックログリファインメントは、イテレーションを通して継続的に行われます。
イテレーション
イテレーション（スプリント）はスクラムの鼓動であり、より大きなPIタイムボックス内の仕事のリズムを作り出します。イテレーションを達成するために必要なすべての仕事は、イテレーションの間に発生します（プランニング、チームシンク、イテレーションレビュー、レトロプロスペクティブ）。 各イテレーションは標準の固定された長さのタイムボックスであり、通常は2週間です。
チームは、イテレーション中に、機能するテスト済みのソフトウェア、ソリューションや、その他の価値あるアーティファクトとして、高品質のバリューのインクリメントをデリバリーします。イテレーションは継続的で順序立てられており、新しいイテレーションは前のイテレーションが終わるとすぐに開始されます。
イテレーションプランニング
イテレーションプランニングは、イテレーションの最初のイベントです。 通常、スクラムマスター / チームコーチがこのイベントを進行します。チームメンバー全員が協力して、今後のイテレーションでチームバックログをどれだけデリバリーできるかを決定します。デリバリーするバックログのストーリーをイテレーションゴールにまとめます。チームは、結果として得られた計画をイテレーションバックログに記録します。プロダクトオーナーは、参加者が、最も重要なチームバックログの項目と、それらがイテレーションゴールとPIオブジェクティブにどのようにマッピングされるかについて、話し合う準備をしっかりと整えます。スクラムチームは、計画や助言を提供するためにその他の人を招待することができます。
イテレーションプランニングは、以下のトピックを取り上げます。[2]
- なぜ、このイテレーションには価値があるか
- このイテレーションで何ができるようになるのか
- その仕事はどうしたら完了できるのか
- 選んだ仕事はどうしたら完了できるのか
イテレーションプランニングの全体を通じて、チームは各ストーリーの受け入れ基準を詳述し、そのストーリーを完成させるためにかかる工数を見積ります。チームは、イテレーションで利用可能なキャパシティを基に候補とするストーリーを選択します。選択された各項目ごとに、チームは「完了の定義(DoD)」を満たすバリューのインクリメントを生み出すのに必要な仕事を計画して、完了できるようにします。インクリメンタルなシステム機能の開発を継続的に行うには、仕事が正しく完了していることを確実にするために、スケーラブルな「完了の定義」が必要です（作り込み品質の記事の中のスケーラブルな「完了の定義」を参照してください）。
イテレーションプランニングでは、多くの場合、バックログ項目をユーザーストーリーやイネーブラーストーリーに分解する必要があり、通常は1日か2日で完了できるようにします。チームは、イテレーション内での仕事をどうやったら完了できるのかを決定します。プランニングが完了すると、チームはその仕事にコミットし、イテレーションのバックログを見える場所（ストーリーボード、カンバンボード、アジャイルプロジェクトマネジメントツールなど）に記録します。プランニングは、2週間のイテレーションに対して最大でも約2時間のタイムボックスで行います。
イテレーションゴール
イテレーションゴールは、アジャイルチームがイテレーションで達成することに合意したビジネス目標と技術的な目標のハイレベルな要約です。これらの目標は、自己組織的で自己管理する複数のアジャイルチームを調整するために不可欠です。イテレーションゴールには以下の利点があります。
- 共通の目的に向けてチームメンバーのベクトルを揃える
- 共通のART PIオブジェクティブに向けて複数のチームのベクトルを揃え、依存関係を管理するのに役立つ
- 透明性とマネジメント情報をもたらす
チームがイテレーションプランニングを完了し、イテレーションバックログを作成すると、次のイテレーションのための仕事を、イテレーションゴールの集まりとして合成し、イテレーションがなぜ価値があるのかを定義します。これらのゴールは、イテレーションバックログから派生し、PIオブジェクティブとベクトルが揃えられます。POは計画する前に最初のゴールの集まりを定義することを選択をする場合がありますが、これにより「計画する理由」と「計画する内容」の理解が深まります。
イテレーションゴールは、ベクトルを合わせ、依存関係を管理し、PIの実行中に必要な調整を行うために、アジャイルチーム、ARTステークホルダー、マネジメントに対して情報と共通言語をもたらします。
イテレーションバックログ
イテレーションプランニング中に、チームはチームバックログから項目を引き出し、イテレーションバックログを作成します。イテレーション中に完了するつもりのものをバックログに入れておきます。PIプランニングはハイレベルであるため、イテレーションごとに調整が必要になる可能性があります。さらに、チームは以前のイテレーションだけでなく、システムデモやコラボレーションする他のチームからもフィードバックをもらいます。ローカルチームの懸案事項（欠陥、技術的負債、保守）、ARTバックログ、コミット済みのチームPIオブジェクティブ、全部がイテレーションバックログのコンテンツに影響を与えます。
デリバリー
SAFeでは、スクラムチームはARTが要求するケイデンスと同期の中で活動し、ベクトル合わせと依存関係の管理を促進し、ソリューション全体のための学習サイクルを迅速に統合します。
イテレーションの間、各チームは協力して、イテレーションプランニング中に特定したストーリーを定義し、構築し、テストします。ストーリー、カンバンボード、チームシンクイベントを使用して、イテレーションの進行状況を追跡し、バリューフローを改善します。チームはイテレーションを通してストーリーをデリバリーし、タイムボックスを「ウォーターフォール化」することを避けます。チームは、システムを正しく構築するために作り込み品質の実践を適用します。完成済みのストーリーはイテレーション通じて、またイテレーションレビューの際にデモされます。
チームシンク
チームシンクは短いミーティング（通常15分以下）で、イテレーションゴールに向けた進捗状況を確認し、コミュニケーションを取り、今後の計画済みの仕事を調整するために、ほぼ毎日開催されます。チームは、チームシンクに任意の構造やテクニックを使って、翌日の仕事を調整するためのアクションプランを作成します。しかし、チームメンバーが調整できるのはチームシンクのみではありません。チームは協力して仕事の調整や必要に応じてリプランについて話し合います。
ハイパフォーマンスチームは、チームシンクを利用して、チームがコミット済みのイテレーションゴールを達成できるよう、互いに助け合う機会を見つけます。スクラムマスター / チームコーチは、もっとディスカッションが必要なトピックを「ミートアフター」ボードに書き出します。関係者だけがミートアフターに残り、これらのトピックについてより詳細に話し合います。チームシンクが効果的でない場合は、解決のために体系的なアプローチを必要とする深刻な問題の兆候である可能性があり、多くの場合、スクラムマスター / チームコーチの責任となります。
インクリメント
図1で示されているインクリメントは、イテレーションごとに新しいソリューションの機能がどのように進化するかを表しています。各インクリメントは、それ以前のすべてインクリメントに追加され、検証され、すべてのインクリメントが一緒に動作するようにします。各インクリメントは、「完了の定義(DoD)」中の合意済みの品質基準を満たす、動作し、テスト済みで使用可能なソリューションです。さらにまた、チームはイテレーション内で複数のインクリメントをデリバリーすることが可能です。イテレーションレビューでは、すべてのチームのインクリメント全体を検査します。
イテレーションレビュー
スクラムチームにとって、イテレーションレビューはイテレーションの最後から2番目のイベントです。各チームはイテレーションの成果を検査し、主要なステークホルダーに対して自分たちの仕事の結果を提示し、イテレーションゴールとPIオブジェクティブに対する進捗状況を評価します。また、プロダクトやプロセスへの今後の適応を決定します。結果に基づき、ステークホルダーとチームは次に何をすべきかを共同で検討します。さらに、チームバックログは、新たな機会に対応するために調整される場合があります。イテレーションレビューは、2週間のイテレーションに対して最大90分のタイムボックスが設定されます。
イテレーションレトロスペクティブ
イテレーションレトロスペクティブは、イテレーションの最後のイベントです。その主な目的は、イテレーションを振り返り、プロセスとソリューションを改善するための新しいアイデアを導き出すことです。レトロスペクティブは、SAFeコアバリューの一つである「たゆまぬ改善」のコンセプトを浸透させるのに役立ちます。チームは、何がうまくいったのか、どのような問題に直面したのか、それらの問題がどのように解決されたのか（あるいは、解決されなかったのか）について話し合います。チームは最も役立ちそうな改善点を特定します。これらの改善点はできるだけ早く対処するか、次のイテレーションのためのバックログに記録されます。レトロスペクティブは、2週間のイテレーションに対して最大約60分のタイムボックスが設定されます。
システムデモへの参加
システムデモは、ART内のすべてのチームによってデリバリーされた最新のイテレーションの新しいフィーチャーの統合ビューを提供します。各チームのデモは、ARTステークホルダーに、PI期間中の進捗状況の客観的な指標を提供します。ARTの全員がシステムデモに関与するか、少なくとも出席します。
進捗状況の追跡
チームはカンバンボードを使用して、イテレーションの進捗状況を追跡します（図2）。成熟したスクラムチームは、タイムボックスを「ウォーターフォール化」することなく、イテレーションを通じてストーリーをデリバリーします。
SAFeスクラムの役割
スクラムチームの規模（通常10人以下）と構造により、コミュニケーション、対話、バリューをデリバリーする能力が最適化されます。「スクラムチームは、機敏性を保つのに十分な規模と、スプリント内の重要な仕事を完了するのに十分な規模です。[2]」
すべてのSAFeアジャイルチーム（スクラムを実行している人も含む）には2つの専門的なチームの役割があり、それぞれに固有の責任があります（図3）。
- スクラムマスター / チームコーチ (パートタイムの役割の場合もある) は、顧客にデリバリーする仕事の流れを調整する責任があります。スクラムの原則とリーンアジャイル原則をコーチングし、進捗の阻害要因を取り除き、チームの自己組織化と自己管理を促進することで、高いパフォーマンスとたゆまぬ改善のための環境を醸成します。多くのSAFeスクラムマスター / チームコーチは、DevOps、作り込み品質、カンバン、フローなどのコーチングといった追加の責任も担っています。
- プロダクトオーナー（通常はフルタイムの役割）は、顧客のニーズと期待を理解しています。POらは、チームバックログのコンテンツオーナーとして機能し、チームバックログの優先順位を付け、チームが正しいものを正しい方法で構築できるよう支援します。
トレイン上のアジャイルチーム
チームは機能横断的であるにもかかわらず、ひとつのアジャイルチームでは、大規模なシステムに対して完全なエンドユーザーバリューをデリバリーできない可能性があります。これには、さまざまな技術基盤や、ハードウェア、ソフトウェア、システムエンジニアリングなどのさまざまな分野が含まれます。しかしながら、チームはフローを最適化するために、できる限り独立してエンドツーエンドのバリューをデリバリーするよう努める必要があります。大きな目的をサポートする際に、SAFeアジャイルチームは、大規模なソリューションを構築し、依存関係を軽減または排除する方法を見つけ出し、チームフローとARTフローを改善するために、他のチームとベクトルを揃え、協働する環境を用意しつつ、アジャイルリリーストレイン(ART)内で活動します。
図4に示すように、ARTの一環として、すべてのチームが共同で計画し、共同でデモを実施し、共同で学習します。これにより、ローカルな懸案事項とARTの大きな目的の両方に集中することができます。また、このベクトル合わせにより、チームはバリューの探索、統合、デプロイ、リリースを独立して行えるようになります。
アジャイルチームの記事では、さらに、ここで共有された顧客バリューをデリバリーする責任に関するチームの関係を定義しています。
詳しく学ぶ
[1] Takeuchi, Hirotaka, and Ikujiro Nonaka. “The New, New Product Development Game,” Harvard Business Review, January 1986.
[2] Sutherland, Jeff, and Ken Schwaber. “The 2020 Scrum Guide,” Scrumguides.org.
最終更新： 2023年4月12日