Guide Ja Japanese
User Manual:
Open the PDF directly: View PDF 
.
Page Count: 18
| Download | |
| Open PDF In Browser | View PDF |
Scrum@Scale ガイドの目的 スクラムは、もともとスクラムガイドで概説されているように、単一のチームによって複雑 なプロダクトを開発、提供、および維持することができる。発行以来、複数チームの協力が 求められる、プロダクト、プロセス、サービス、システムなどの開発にまで広がりを見せて いる。Scrum@Scale は、組織戦略の全体を最適化する方法として、チームの新しいエコシス テムを効率的に調整するために作成された。これは、単一スクラムチームを、組織で機能横 断的に自然に拡張するというスケールフリーなアーキテクチャにより、“最小で実行可能な官 僚制” の導入を通じて目的を達成するものである。 このガイドには、Scrum@Scale フレームワーク、スケール化ルール、スケール化イベント、 といったコンポーネントの定義と、エンタープライズ向け成果物、およびそれらを結びつけ るルールが含まれている。 ジェフ・サザーランド博士は、スクラムの背後にある原則、複雑な適応システム理論、ゲー ム理論、オブジェクト指向技術に基づき Scrum@Scale を開発した。このガイドは、多くの経 験豊かなスクラムの実践者のフィールドワークの結果に基づいて開発されている。このガイ ドは、読者が自分自身で Scrum@Scale を実践できることを目的としている。 なぜ Scrum@Scale か? スクラムは、単一のチームが持続可能なペースを維持し、その最適な能力で働くことがで きるようにデザインされている。現場では、組織内のスクラムチーム数の増加に伴いアウト プット (プロダクト) とベロシティの低下が見受けられる (冗長な作業やチーム横断依存のよ うな問題のため)。リニアなスケーラビリティを得るためには、複数のチームを効果的に調 整するためのフレームワークが必要であることが明白である。Scrum@Scale は、スケールフ リーアーキテクチャで目的を達成するためにデザインされている。 スケールフリーアーキテクチャを利用することによって、組織は成長するための特定の方法 に任意の規則のセットの決定や方法を強制されない。むしろ、それは、そのユニークなニー ズ、および組織を作る個人のグループにより受け入れられうる変化の持続可能なペースに有 機的に基づくかもしれない。Scrum@Scale モデルのシンプルさはスケールフリーアーキテク チャに必須で、チームあたり生産性を、より多くのチームが作成されると減少させる特別な 複雑さを導入することを慎重に避ける。 Scrum@Scale は、すべての部門、プロダクト、およびサービスといった、組織全体を横断的 にスケールするようにデザインされている。それは、産業、政府、または学界の組織のすべ てのタイプの複数定義域を横断的に適用できる。 1 Scrum@Scale の定義 スクラム: 現実的で高価値のプロダクトを生産性と創造性をもってデリバリするため、複雑 な問題への順応的対処に取り組むことができるフレームワーク。 スクラムガイドは、根本的な透明性をもった検査と適応性が、革新、顧客満足、性能、およ びチーム幸福を駆動するという、最小のフィーチャーセットである。 Scrum@Scale: 現実的で高価値のプロダクトを創造的にデリバリするため、複雑な問題への 順応的対処に取り組むことができるスクラムガイドとともに、複数スクラムチームが一貫し て機能するネットワーク内のフレームワーク。 注意: これら “プロダクト” は、スクラムチームのドメインに応じて、ハードウェア、ソフト ウェア、複雑に統合されたシステム、プロセス、サービスなどであるかもしれない。 Scrum@Scale とは: · 軽量 - 最小で実行可能な官僚制 · 理解しやすい - スクラムチームだけから成る · 習得は難しい - 新しい運用モデルを身に着ける必要がある Scrum@Scale は、スクラムをスケールするためのフレームワークである。それは、スクラム をスケールするために、スクラムを使用してスケールすることを抜本的に簡素化する。 スクラムでは、“How” と “What” の責任の分離に注意する必要がある。Scrum@Scale でも同 様に、チームの最適な生産性を達成を邪魔する、無駄な組織上の衝突を取り除くために、権 限と責務を明確に理解し、注意する必要がある。 Scrum@Scale は、組織変革の戦略とインプリメンテーションをカスタマイズすることを可能 にするコンポーネントから成る。それらは、彼らが最も重要であると判断した領域、または 変更の必要性が最も高い領域で段階的に優先順位を付けた変更の取り組みを目標とし、順次 進んでいく能力を与える。 これら 2 つの権限を分離されており、Scrum@Scale は、2 つのサイクルを含んでいる: スク ラムマスターサイクル (“How”)、およびプロダクトオーナーサイクル (“What”) であり、2 つ ポイントで接触する。まとめると、これらのサイクルは、一直線上に複数のチームの取り組 みを調整するための強力なフレームワークを作り出す。 2 R フレームワーク Scrum@Scale の構成要素⃝ 価値駆動文化 “What” および “How” の責務の分離以外では、Scrum@Scale は、実証的な環境で価値駆動文 化を創り出すことで、健全な組織を構築することをさらなる目的としている。スクラムにお ける価値とは次のようなものがある: オープン性、勇気、集中、敬意、コミットメント。こ れらの価値が、経験的意思決定を促進する。それは、透明性、検査、および適応の 3 つの柱 により成り立っている。 オープン性は、すべての作業とプロセスへの透明性を保証する。さもなくば誠実な検査と、 より良いものに適合していくことはできない。勇気は、革新的な方法で、より迅速な価値を デリバリするために必要な、大胆な飛躍することを示す。 集中とコミットメントは、自分たちで自分たちの責務を全うする方法を見つけることを示し、 顧客へ価値を届けることを最優先とするということである。最後に、これらすべては、他の だれも成しえないことを行っている作業者個人個人へのリスペクトに支えられた環境なくし ては成しえない。 Scrum@Scale は、持続可能なペースで働くための積極的な環境を育て、努力の最前線で顧客 が直面する価値を届けるというコミットメントをもたらす、変革リーダーシップモデルをサ ポートすることによって、組織の成長を支援する。 3 Scrum@Scale を始める 大きなチームネットワークを構築する際は、小さなチームのセットのためのスケーラブル なリファレンスモデルを開発することが重要である。複数のチームが展開されている場合、 スクラム実装の弱点は拡大されるであろう。初期のスケーリング問題の多くは、組織の方針 や手続き、またはハイパフォーマンスを阻む開発プラクティスとチームの不満である。 従って、最初のチャレンジは、スクラムを上手く回す小さなチームのセットを作成すること である。これは、エグゼクティブ・アクション・チーム (EAT) による作成が最善の達成方 法である。エグゼクティブ・アクション・チーム (EAT) は、変革戦略の策定と実行の責務が あるためだ。EAT は、リファレンスモデルの存続を保証するために政治的、財政的に権限を 与えられた個々人で構成されなければならない。チームのこのセットは、アジリティを阻害 する組織的な問題を通じて働き、組織横断的なスクラムをスケールするためのパターンとし て使われうるリファレンスモデルを作成する。 チームのリファレンスモデルが揃ってくると、デリバリの遅延のもととなる障害物やボトル ネック、ムダ、ビジネスのアジリティを妨げが見えるようになる。これらの問題を取り除く ための最も効果的な方法は、全体の価値ストリームが最適化されるように組織横断的にスク ラムを広げることである。 Scrum@Scale は、組織へのスクラムの浸透により、リニアな生産性のスケーリングを達成す る。また、組織の具体的な戦略、プロダクト、およびサービスと整合し、有機的にベロシティ と品質を広げる。 スクラムマスターサイクル チームレベルプロセス チームレベルプロセス はスクラムマスターサイクルとプロダクトオーナーサイクルのファー ストタッチポイントを構成する。それは、スクラムガイドではっきりとレイアウトされてい る。それは、3 つの成果物、5 つのイベント 3 つのルールとして構成されている。そのゴール はチームレベルプロセスを: · · · · 完成と品質がテストされた作業のフローの最大化する 時間とともにチームのパフォーマンスが向上する チームが持続可能かつより豊な方法で運用する 顧客フィードバックループを加速する 4 “How” を調整する - スクラムオブスクラム 顧客に価値をデリバリするために調整が必要な複数のチームの 1 セットは “スクラムオブス クラム” (SoS) を構成する。このチームは、すべての参加チームのすべてのスプリントの終 わりに、製品の潜在的に出荷可能なプロダクトインクリメントを完全に統合したセットに責 任を持つスクラムチームである。SoS はリリースチームとして機能し、顧客に直接価値を提 供できる必要がある。これを効果的に行うには、スクラムガイドと一貫している必要がある。 すなわち、それ自身のロール、成果物、およびイベントを持っている: ロール: SoS は、すべてのスプリントの終わりに、完全に統合された潜在的に出荷可能なプロダクト インクリメントを提供するために必要なスキルをすべて備えている必要がある。(経験豊富 なアーキテクト、QA リーダー、その他の運用スキルが必要な場合がある) 問題の優先順位 付けを解決するために、プロダクトオーナーの表現も持っている。スクラムオブスクラムの スクラムマスターを Scrum of Scrums Master (SoSM) と呼ぶ。 イベント: SoSM は、障害物の除去が “準備完了” であること、チームがどのように除去するのが最善か、 “完了” とするための方法について識別したうえで、バックログリファインメントイベントを ファシリテートするべきだ。個々のチームが成功した学習やプロセスのカイゼンをチームの 代表が共有して、SoS 内のチーム横断的にそれらのプラクティスを標準化する SoS レトロス ペクティブに特に注意する必要があります。SoS は参加チームが出くわす障害物にリアルタ イムで対応する必要があるため、各チームの少なくとも 1 人の代表 (通常はチームのスクラム マスター) は、スケール化デイリースクラム (SDS) を行う。スケール化デイリースクラムに 参加する必要がある。SDS イベントはデイリースクラムを反映し、チームのネットワークの コラボレーションとパフォーマンスを最適化する。参加チームの人はだれでも、必要に応じ て参加することができる。 SDS に付け加えると: · 15 分以下のタイムボックス · プロダクトオーナーチームの各代表が出席する必要がある · チームの代表が上手く行っていること、終わったもの、チームどうしがさらに効果的 に協力し合えるにはどうしたら良いかについて議論するフォーラムである。例えば次 のようなものがある: · 自分のチームのスプリントゴールの達成を妨げるであろう障害物は何か (または、 今後のリリースへの影響)? · 自分のチームは、他のチームのスプリントゴールの達成を妨げるであろう何らか のことをしているか (または、今後のリリースへの影響)? · 自分たちはチーム間の新たな依存関係を発見したか、または既存の依存関係を解 決する方法を発見したか? · 自分たちがは発見したチーム横断的にテコ入れできるカイゼンは何か? 5 スクラムオブスクラムマスター (SoSM) スクラムオブスクラムマスター (SoSM) は、共同チームの努力の結果であるリリースに責任 があり、次のようなにすべきである: · · · · 進捗状況の見える化 組織に対してバックログにおける障害物が見えるようにする チームが自分自身で対処できない障害物を取り除く チーム横断的な依存関係やバックログ配布に特に注意を払い、障害物に対する優先順 位付けを容易にする · スクラムオブスクラムの効果をカイゼンする · 1 回のスプリント毎に潜在的ににリリース可能なプロダクトインクリメントをデプロ イするためにプロダクトオーナーと近くで働く · プロダクトオーナーのリリースプランとチームのデプロイメントを調整する SoS のスケーリング 組織や実装の規模によっては、非常に複雑なプロダクトをデリバリするために複数の SoS が 必要な場合がある。そのような場合、複数のスクラムオブスクラムから スクラムオブスク ラムオブスクラム (SoSoS) のスクラムを作成することができる。SoSoS は無限にスケーラ ブルな Scrum チームの有機的パターンである。 各 SoSoS ごとに SoSoSM が必要である。各成果物、イベントのスケーリングされたバージョ ンが必要です。 SoS をスケールすることで、組織内のコミュニケーション経路の数が削減され、複雑さがカ プセル化される。SoSoS は、SoS と 1 つのスクラムチームとのインタフェースを提供するの とまったく同じ方法で SoS とのインタフェースを提供する。これにより、リニアなスケーラ ビリティが可能となる。 6 Sample Diagrams: 注意: スクラムガイドでは最適なチームサイズを 3 人から 9 人と定義しているが、ハーバー ドの調査では最適なチームサイズは 4.6 人であると判断されている。1 ハイパフォーマンスな スクラムチームにおける実験では、作業を行っている 4 人または 5 人が最適なサイズである ことが繰り返し示されている。このパターン、1 つの SoS 内のチーム数を同じにすることが、 リニアなスケーラビリティにとって不可欠である。したがって、上記および後の図では、5 人のチームを表すために五角形としている。これらの図は単なる例であり、実際の組織図は 大きく異なる場合がある。 経営層上位レベルアクションチーム アジャイル組織全体のスクラムオブスクラムは、Executive Action Team (EAT) と呼ば れる。リーダーシップチームは、独自のガイドラインと手順によるリファレンスモデル運用 により組織で一つのアジャイルの泡を作る。それは、アジャイルではない組織のどのような 部分でも効果的に統合される。アジャイルエコシステムを所有するということは、スクラム を実装し、スクラムのロールが作成されサポートされていることを保証するということだ。 EAT は、SoS によって除去できない障害物に対する最終手段である。したがって、それを除 去するために政治的、経済的に権限を与えられた人物で構成されなければならない。EAT の 機能は、複数の SoS(または SoSoS) を調整することと、SoS 内のチームの数と同じである非 1 Hackman, J Richard, Leading teams: Setting the stage for great performances, Harvard Business Press, 2002 7 アジャイル部分とのインタフェースすることである。スクラムチームと同様に、PO と SM が必要である。EAT は、スクラムチームとして毎日顔を合わせるのがベストかもしれない。 彼らはスプリントごとに少なくとも 1 回会合する必要があり、透明性のあるバックログを持 ち合わせている必要がある。 Sample Diagram showing an EAT coordinating 5 groupings of 25 teams: 8 EAT のバックログと責務 スクラムは、従来のプロジェクト管理とは異なるアジャイルな運用システムである。SM 組 織全体は EAT に対して報告を行う。これは、組織内で、このアジャイルな運用システムを、 確立、維持、実装強化することによって、実現するための責務である。EAT の役割は、組 織変換バックログ (達成すべきアジャイルイニシアチブの優先順位付けされたリスト) を作成 し、それが実施されていることを確認することである。たとえば、旧組織に伝統的な製品開 発ライフサイクルが存在する場合、新しいアジャイルな製品開発ライフサイクルを作成し、 実装し、サポートする必要がある。通常は、従来の方法よりも品質とコンプライアンスの問 題をサポートするが、異なるルールやガイドラインを使用し、異なる方法で実装する。EAT は、プロダクトオーナー組織が作成され、資金提供され、努力への支援表明を保証する。 EAT は、組織内のスクラムの品質に責任を負う。その責務には以下のものが含まれるが、こ れらに限定されることはない: · 組織でスケール可能なリファレンスモデルのためのアジャイルな運用システムを作成 する。それは、アジリティを得るための企業の運用ルール、手続き、ガイドラインを 含む。 · 組織でスクラムの品質を評価しカイゼンする · ビジネスにおけるアジリティのための組織力を構築する · スクラムのプロフェッショナルのための継続的学習のためのセンターを作成する · 新しい働き方の探求支援を行う 最後に、EAT は、立ち上げ、PO 間の協力により SoS を反映したプロダクトオーナー組織の サポート、PO 機能をスケールさせることを行っていく必要がある。これらの PO チームと 主要ステークホルダーは、 メタスクラム として知られている。 スクラムマスターサイクルの出力と成果 SM 組織 (SoS、SoSoS、および EAT) は、スクラムマスターサイクルの他のコンポーネント、 すなわち継続的カイゼンと障害物の除去、チーム横断的な調整、および開発を完了するため に全体として機能する。 継続的カイゼンと障害物除去の目的は以下のとおり: · 障害物を特定し視点を変える機会 · 障害物の優先順位付けと除去のための健全かつ構造化された環境を維持する。また、そ の結果として得られるカイゼンを検証する · 効果的な変更のための組織における可視性を確保する チーム横断的調整の目的は以下のとおり: 9 · 関連する複数のチーム間の同様のプロセスを調整する · チーム間のチーム横断的な依存関係を緩和し障害物とならないようにする · 一貫性のある出力のために、チームの規範とガイドラインの整合性を維持する SoS の目的はリリースチームとして機能することであり、プロダクトのデプロイメントはで あり、何がリリースに含まれているかはプロダクトオーナーの範疇である。したがって、(SoS の) デプロイメントの目的は次のとおり: · 価値ある完成品の一貫した流れを顧客に届ける · 異なるチームの作業をシームレスな一つの製品に統合する · 高品質な顧客経験を確保する プロダクトオーナーサイクル “What” を調整する - メタスクラム チームネットワークへのフィードバックとして共有バックログを調整する必要のあるプロダ クトオーナーのグループ、それ自体がメタスクラムと呼ばれるチームである。SoS 毎に対応 するメタスクラムがある。メタスクラムは、チームの優先順位を一直線に調整しつつ、チー ムのバックログを調整し、ステークホルダーがバックログをサポートできるように連携を構 築する。ある 1 チームのプロダクトオーナーは、自チームのバックログの構成と優先順位付 けの責務があり、共有メタスクラムバックログから自チームのバックログにバックログを引 き出したり、自身の裁量で独自のバックログを生成したりする。 メタスクラムには、スケール化されたバックログリファインメントがある、スケール化バッ クログリファインメントミーティングである。 · 各チームの PO(または代理人) の出席は必須 · このイベントは、リーダーシップ、ステークホルダーのための会である。または、顧 客が自身の意見を表現する このイベントは、バックログを準備完了にするため、スプリントごとに少なくとも 1 回、必 要に応じて頻繁に行う。 メタスクラムの主たる機能はは以下のとおり: · 製品の全体像を可視化し、組織に見えるようにする · バックログの実装の安全なサポートを確保するために主要なステークホルダーとの連 携を構築する · 唯一の優先順位付けられたバックログを生成することで、作業の重複を避けることが できる 10 · · · · SoS のすべてのチームに適用させる最小限で統一的な “Done の定義” を作成する SoS が提起した依存関係を排除する 調整されたリリースプランを生成する 製品への洞察力を与えるメトリクスを決定し監視する SoS のように、メタスクラムは自立したスクラムチームとして機能します。したがって、チー ム内の議論を順調に進めさせれ、SM として振る舞うことのできる誰かが必要となる。また、 メタスクラムがカバーするすべてのチームのための唯一のプロダクトバックログ生成を調整 する責務を負う、たった一人の人物が必要である。この人物は、チーフプロダクトオーナーに 指定される。 チーフプロダクトオーナー (CPO) チーフプロダクトオーナーは、メタスクラムを通じて、個々のチームで働くプロダクトオー ナー間の優先順位を調整する。ステークホルダーおよび顧客ニーズに合わせ、バックログの 優先順位を調整する。SoSM のように、この役割を果たすことを選択した個別チームの PO である場合もあれば、この役割に特化した個人の場合もある。彼らの主な責務は通常の PO と同じである。しかしスケール化では: · 製品全体の戦略的ビジョンを設定する · 全チームに配布する、価値により優先順位付けされた唯一のバックログを作成する · これらのアイテムは、チーム PO のものよりも大きなプロダクトバックログアイ テムとなる · 効率的なデプロイのためにメタスクラムチームが生成するリリースプランのために、関 連する SoSM と緊密に連携する · 顧客プロダクトのフィードバックを監視し、それに応じてバックログを調整する メタスクラムのスケーリング SoS が SoSoS へ拡張可能なのと同様に、メタスクラムも同じメカニズムで拡張する。これら の拡張ユニットには特定の用語はなく、CPO の特定の拡張された肩書もない。これは、各組 織で独自開発することを奨励する。以下の図では、拡大された PO の肩書に “チーフ” を追加 することにしている。 参考図: 11 注意: 上記は、五角形は、理想サイズのスクラムチームと理想サイズのメタスクラムを表し ている。これらの図は単なる例であり、あなたの組織図では大きく異なる場合がある。 エグゼクティブメタスクラム (EMS) メタスクラムは、関連する SoS とともに、無限にスケール可能なプロダクトオーナーのネッ トワークデザインを可能にするアジャイル組織全体のメタスクラムはエグゼクティブメタス クラムである。EMS は、組織のビジョンを持ち、共通の目的に沿ってすべてのチームを調整 しながら、会社全体の戦略的な優先事項を設定します。 25 チームの 5 つのグループを調整する EMS を示す参考図: 12 プロダクトオーナー組織の出力と成果 PO 組織 (多様なメタスクラム、CPO、エグゼクティブメタスクラム) は、プロダクトオー ナーサイクル: 戦略的ビジョン、バックログ優先順位付け、バックログ分解とリファインメ ント、リリースプランニングの全体を満足させるための構成要素として機能する。 戦略的ビジョンを設定する目的は以下のとおり: · 組織全体を共有済みの進行経路に沿って明確に整列させる · 組織の存在意義を説得力を以て明確にする · ミッションにおいてキーとなる資産を活用するために組織が何をすべきかについて説 明する · 急速に変化するマーケットの状況に対応する 13 バックログ優先順位付けの目的は以下のとおり: · デリバリする製品、機能、サービスの注文を明確に識別する · バックログの順序付けにおける価値創造、リスク軽減、内部依存関係を反映する · バックログの分解とリファインメントに先立ち、アジャイル組織全体のハイレベルイ ニシアチブを優先する バックログ分解とリファインメントの目的は以下のとおり: · 複雑な製品やプロジェクトを、1 つのチーム 1 つのスプリントで完成させることができ る独立した機能要素に分割する · 新たな要件と顧客からのフィードバックを収集し、抽出する · すべてのバックログアイテムが本当に “Ready” であることを確認して、個々のチーム が引き取れるようにする リリースプランニングの目的は以下のとおり: · 主要機能のデリバリ予測 · ステークホルダーへ納期を伝える · 必要に応じて優先順位を更新する PO/SM サイクルの接続 フィードバックを理解する フィードバックコンポーネントは、PO と SM サイクルが接触する 2 番目のポイントである。 プロダクトフィードバックは、プロダクトバックログの調整を通じて継続的改良を推進し、 同時に、リリースフィードバックが、デプロイメカニズムの調整を通じて継続的カイゼンを 推進する。フィードバックの取得と分析の目的は以下の通り: · · · · · 自分たちの仮説を検証する 顧客がプロダクトをどのように使用し、相互作用するかを理解する 新しい機能や機能性のアイデアを収集する 既存の機能の改良を定義する リリース計画とステークホルダー整合性をカイゼンするために、製品/プロジェクト完 了までの進捗状況を更新する · デプロイ方法と仕組みのカイゼンを識別する 14 メトリクスと透明性 スクラムが最適に機能するために、根本的な透明性が不可欠であり、スクラムの価値を抱擁 した組織でのみ可能となる。これは、組織に、誠実な進捗状況アクセス、製品とプロセスを 検査、適応させる能力を組織に与える。これは、スクラムガイドで示されているスクラムの 経験的性質の基礎となっている。 SM と PO サイクル双方において、SM と PO 分離組織によって決定されるメトリクスを必要 とする。メトリクスは、特定組織だけでなく、それらの組織内の特定機能にも固有となるで あろう。Scrum@Scale は特定のメトリクスセットを必要としていないが、最低限のものにつ いて示す。組織が計測すべきものは以下である: · · · · 生産性 - e.g. スプリントごとに届けられるプロダクトの作業量の変化 価値のデリバリ - e.g. チームの労力あたりのビジネス価値 品質 - e.g. 不具合率またはサービス停止時間 持続可能性 - e.g. チームの幸福 メトリクスと透明性を持つことの目的は以下のおとり: · チームメンバーを含むすべての意思決定者に、適切な判断を下すための適切なコンテ キストを提供する · 過剰な是正を避けるためにフィードバックサイクルをできるだけ短くする · チーム、ステークホルダー、リーダーシップによる最小限の努力を要求する 組織デザインにおける考慮点 Scrum@Scale のスケールフリーの性質により、フレームワーク自体と同様に、組織の設計を コンポーネントベースにすることができる。これにより、マーケットに応じてチームのリバ ランスやリファクタリングが可能となる。組織が成長するにつれて、分散チームのメリット を得ることが重要となるであろう。一部の組織では、他には利用できない才能があり、アウ トソーシング開発を通じて、必要に応じて拡大したり縮小することができる。Scrum@Scale は、長いラグタイム、コミュニケーション妥協、品質劣化を避けながら、これを行う方法を 示し、サイズとグローバル分散の両方でリニアなスケーラビリティを実現する。2 2 Sutherland, Jeff and Schoonheim, Guido and Rustenburg, Eelco and Rijk, Maurits, “Fully distributed scrum: The secret sauce for hyperproductive offshored development teams”, AGILE’08. Conference, IEEE: 339-344, 2008 15 この組織図では、ナレッジ & インフラストラクチャチームが、各チームのスタッフが非常 に少ない専門家の仮想チームを表している。彼らはスクラムチームと SLA を結ぶグループと して調整を行い、要求は、透明性をもつ優先順位付けされたバックログへ変換を行う各専門 分野ごとの PO を通じて流れる。重要な点は、これらのチームが一緒に座っている個人のサ イロではないということである (白抜き五角形で表されている理由)。彼らのチームメンバー は実際のスクラムチームに座っているが、バックログ配布とプロセスカイゼンのために、こ の仮想スクラムを構成する 16 顧客関係、法務/コンプライアンス、および人事部門は、組織の必要な部分であり、他のす べてが頼る独立したスクラムチームとして存在するため、ここに含まれている。 EAT & EMS の表現に関する最後の注記: この図では、一部のメンバーが両方のチームに在 席しているため、重複して表現している。非常に小規模な組織や実装では、EAT と EMS は まったく同じチームメンバーで構成されている場合がある。 後書 Scrum@Scale は生産性を向上させ、組織全体を高品質で大幅にカイゼンされた作業環境で半 分の時間で 2 倍の作業を行うように設計されている。このフレームワークを適切に実装して いる大規模な組織は、品質と革新性を向上させながら、製品とサービスのコストを削減して いる。 Scrum@Scale は、組織にスクラムで浸透させるように設計されている。リーダーシップ、人 事、法務、コンサルティング & トレーニング、製品 & サービスチームを含むすべてのチー ムで、組織の合理化と強化を行うと同時に同じスタイルのスクラムを実装する。 うまく実装されたスクラムにより、組織全体を運営することができる。 謝辞 我々は、IDX 社において、スクラムを何百ものチームに広げることを最初に許してくれたこ とで、スクラムオブスクラムが作成できたと認識している。3 PentientKeeper 社ではメタス クラムを作成し、4 革新的な製品の高速開発を可能にし、OpenView Venture Partners はスク ラムを組織全体に拡大した。5 Intel 社の 25,000 人以上によるスクラムの実践は、スケールフ リーアーキテクチャ無しには “何もスケールない” ことを私たちに教え、最大のスクラムチー ム製品部門を持つ SAP 社は、2,000 のスクラムチームがともに働くためには、メタスクラム におけるマネジメントの関与が必須であるということを教えてくれた。 Amazon, GE, 3M, Toyota, Spotify, Maersk, Comcast, AT&T と多くの企業で Jeff Sutherland とこれらのコンセプトを実装のために働いてくれているアジャイルコーチとトレーナーたち は、異なるドメインの幅広い企業をまたがりこれらコンセプトをテストすることに役立ち続 けてくれている。 3 Sutherland, Jeff, “Inventing and Reinventing SCRUM in five Companies”, Sur le site officiel de l’alliance agile, 2001 4 Sutherland, Jeff, “Future of scrum: Parallel pipelining of sprints in complex projects”, Proceedings of the Agile Development Conference, IEEE Computer Society 90-102, 2005. 5 Sutherland, Jeff and Altman, Igor, “Take no prisoners: How a venture capital group does scrum”, Agile Conference, 2009. AGILE’09, IEEE 350-355. 2009 17 最後に、Avi Schneier と Alex Sutherland は、この文書の作成と編集において非常に貴重な 存在である。 18
Source Exif Data:
File Type : PDF File Type Extension : pdf MIME Type : application/pdf PDF Version : 1.5 Linearized : No Page Count : 18 Creator : TeX output 2018.08.27:1555 Producer : dvipdfmx (20180217) Create Date : 2018:08:27 15:55:19+09:00EXIF Metadata provided by EXIF.tools