スクラム

…昔からある「ラグビー」型のアプローチ、つまり、ラグビーのようにボールを前後に回しながらチームで一丸となってボールを運ぶというアプローチの方が、今日の競争に勝つための要求に合うかもしれない。

─野中・竹内, 『The New, New Product Development Game』

ScrumXPの概要

ほとんどのSAFeチームでは、チームベースのプロジェクト管理フレームワークとして、主にスクラムを使用している。スクラムは、機能横断的な自己組織化するチームがSAFeのコンテキストの中で活動するための、軽量だけれど規律のある、生産性の高いプロセスである。スクラムには、スクラムマスター、プロダクトオーナー、開発チームメンバーという3つの役割が規定されている[3]。スクラムマスターは、チームがスクラムの規則に準拠するのを助け、チームの内外で障害を取り除く、奉仕型リーダーである。プロダクトオーナー(PO)は、何を構築するかの定義を担当する。また、チームのバックログ(基本のスクラムではプロダクトバックログ、SAFeではチームバックログ)の所有者である。リーンの品質プラクティスとエクストリームプログラミング(XP)に触発されたエンジニアリング技術とを追加したSAFeのScrumXPチームは、SAFeにとって基本的なアジャイルの構成要素である。

しかしもちろん、SAFeのScrumXPチームは独立して仕事をしているわけではない。各チームはアジャイルリリース列車(ART)の一部であり、その中で協力して大きいシステムを構築する。そのシステムが努力の対象である。この目的に向かって、システム全体が反復を行い、時間が経つにつれてインクリメンタルに進化するよう、すべてのアジャイルチームは一緒に計画を立て、一緒に統合とデモを行い、一緒に学習する

詳細

ScrumXPアジャイルチームは、可能な限り同じ場所で働く、5~9人のメンバーから構成される、自己組織化および自己管理する機能横断的なグループである。チームの規模や構成は、コミュニケーションや相互作用や価値を納品する能力が最大になるよう最適化される。「自己組織化する」とは、チームリーダーや管理者という役割が、チームメンバーに作業を与えたり、その作業を見積もったり、チームの具体的な目標を確約したりすることもなければ、ソリューションをどれだけ正確に進展させるかを判断することもない、ということである。チームには反復の意図が提示され、その範囲のうちどれだけの部分を実際に確約できるかと、その価値のインクリメントをどうやって構築するかの判断は、チームだけに任される。チームは機能横断的なので、インクリメントを納品するために必要な役割やスキルは、チーム内にすべて備わっている。自己組織化および機能横断的という性質を備えたうえに、持続的なコミュニケーション、建設的な論争、動的な相互作用を行うことで、チームは生産的になり、チームメンバーにとって作業環境は楽しいものとなる。

スクラムではプロダクトオーナーおよびスクラムマスターという具体的な2つの役割が定義されているが、これらの役割はSAFeのScrumXPチームのメンバーであり、それぞれに特有の責任を負う。これらの役割については、SAFeのそれぞれのページで詳しく説明するが、以下ではその責任を要約して示す。

プロダクトオーナー(PO)

ScrumXPチームごとに一人のプロダクトオーナーがいて、チームバックログに関する責任を負う。プロダクトオーナーと他のチームメンバーとのやり取りは、毎日行われる重要で集中力の必要な活動である。そのため、各チームに専任のPOを置くか、最大でも2チームでPOを共有するのが、もっとも効果的なモデルである。そうすることでPOは、質問に答える、開発中の機能についてより詳細な情報を提供する、完成したストーリーをレビューしてベースラインに受け入れるなど、反復の実行時に効果的にチームをサポートすることができる。

スクラムマスター(SM)

スクラムマスターは、チームのファシリテーターでありアジャイルコーチである。その主な責任には、プロセスに沿って進められていることを確認する、チームにスクラム、XP、SAFeのプラクティスを教える、継続的な改善のための環境を整える、などがある。また、スクラムマスターには、通常、障害の除去を先頭に立って行う役割も課される。スクラムマスターの役割は、一人のチームメンバーがそれに専念することもあれば、他の作業と並行して行うこともある。逆に、専任のスクラムマスターが2、3のスクラムチームをサポートすることもある。

スクラムのプロセス

スクラムのプロセス自体は、ソリューションのシステム能力を素早く反復的に進化させ、生産性や品質を向上しよりよい成果を得るための継続的な改善を進めるための、軽量のプロジェクト管理フレームワークである。プロセスの中心は反復(注:スクラムではスプリントと呼んでいるが、SAFeではより汎用的な反復という用語を使用する)という短い時間枠(SAFeの場合は2週間)であり、その期間にチームは定義、構築、テスト、結果のレビューを行う。このスクラムのプロセスについて、この後のセクションで説明する。

反復の計画

反復は反復計画から始まる。これは時間枠が設定されたイベント(4時間以下)であり、その時間内にプロダクトオーナーがその反復のストーリーを提示する。その後、チームは、ストーリーをレビューし、受け入れ基準を定義し、必要であれば大きいストーリーを小さいストーリーに分割し、ストーリーポイントで見積もり、最終的に、既知のベロシティー(反復ごとのストーリーポイント数)に基づいて何を構築できるかを確約する。さらに、多くのチームは、ストーリーをタスクに分割し、タスクを時間単位で見積もって、今後の作業を詳しく理解する。最後に、チームはその反復の一連の目標を確約する。

反復が始まる前から、スクラムチームは、次の反復中に納品する作業を確実に理解できるよう、チームのバックログ項目を詳細化して、新しい反復の内容を準備している。

作業の可視化

実行時には、チームはストーリーを構築しテストする。その目的は、2、3日に一度、1、2のストーリーを納品することである。このように順に実施することで、仕掛かり作業の数を制限し、反復を「ウォーターフォール式に」行うことを避ける。チームは「大きな見やすい情報発信」によって、反復実行中の進捗を理解し追跡する。チームのストーリーボードによって、反復の中のストーリーとその進捗が可視化される。その際、図1のように、開発ステップを縦の列に使用し、時間の経過と共にストーリーを左から右に移動させる。

図1.  チームのストーリーボードの例

チームによっては、一部のステップに仕掛かり作業制限も適用して、反復内での「プル」プロセスを作成し、継続的に作業のバランスをとってスループットを向上させる。実際に、多くのチームではスクラムとカンバンのベストプラクティスを統合し、反復全体を通した作業のフローを促進している。この場合、上記の単純なストーリーボードは、さらに構造化の進んだカンバンボードへと進化する。ScrumXPチームでのカンバンの使い方について詳しくは、「チームカンバン」のページを参照してほしい。

デイリースタンドアップミーティングとの連携

チームは毎日、デイリースタンドアップミーティング(DSU)という公式の儀式を行う。これは、現在の状態を確認し、問題を上に伝え、他のチームメンバーから助けを得るためのものである。このミーティングで、各チームメンバーは、昨日何をしたか、今日何をするかと、困っている「障害」があればそれを説明する。これは連携のための毎日のミーティングなので、短く要領を得たものにするようスクラムマスターは気を配らなければならない。DSUは、15分以内で、ストーリーボードの前に立ったままで行う。

ただし、チームのコミュニケーションはそこで終わることなく、反復の間じゅう、チームメンバーは継続的にやり取りを行う。ScrumXPで可能な限りチームが同じ場所に集まっていることが好まれる主な理由は、このようなコミュニケーションを促進するためである。

価値のデモとプロセスの改善

それぞれの反復の終わりに、チームはチームデモ反復の振り返りを行う。デモでは反復中に完成させたストーリーそれぞれのデモを行い、その合計がその反復においてチームが追加した価値となる。これは正式な状況報告というよりも、反復の具体的な成果のレビューである。その後、チームは簡単な振り返りを行う。これは、反復、プロセス、うまくいったこと、現在の障害について考える時間である。それからチームは次の反復に向けた改善ストーリーを考える。

品質の作り込み

SAFeで述べられているように、「ひどいコードは大規模展開できない」。そのため、SAFeの中心的価値の1つに「品質の作り込み」が挙げられている。「品質の作り込み」は、ソリューションの作成者によってコードレベルやコンポーネントレベルで開始される。そうでなければ、ソリューションが統合され、コンポーネントからシステムやソリューションへと拡大した後で品質を確保することは困難であり、不可能な場合もある。

チームがコードやコンポーネントに確実に品質を作り込めるよう、SAFeでは、5つのエンジニアリングおよび品質のプラクティスについて説明している。これらは、XPの信条から発想を得て、スクラムのプロジェクト管理プラクティスに書き加えられたものである。具体的には、継続的インテグレーションテストファーストリファクタリング、ペアワーク、共同所有である。チームによっては、この5つの他に、ペアプログラミングやメタファーなど[2]、XPのプラクティスも使用している場合がある。

ScrumXPチームは「列車に乗って」いる

チームが機能横断的だとはいっても、さまざまな技術プラットフォームや、ハードウェア、ソフトウェア、システムエンジニアリングなどの多様な分野を含む大規模システムの場合、7、8人のチームでエンドユーザー価値を納品するのは必ずしも現実的ではない。通常はもっと多くのチームが必要になる。それに対処するため、SAFeのアジャイルチームは、アジャイルリリース列車(ART)の中で仕事をする。ARTは、使命との整合を取り、チームが他のチームと協調して大きなソリューションシステム能力を構築するためのコラボレーション環境となる。ScrumXPチームは、ARTの一部として、一緒に計画を立て、一緒に統合とデモを行い一緒に学習する。その様子を図2に示す。

図2.  SAFeのアジャイルチームは、一緒に計画を立て、一緒に統合とデモを行い、一緒に学習する

この「責任共有プログラム」への各チームの参加については、「アジャイルチーム」のページで詳しく定義する。

ScrumXPチームのリーダーシップ

管理者は通常、機能横断的なチームには含まれない。ただし、フィーチャーやコンポーネントやサブシステムを中心にそれらのチームを最初に編成したり、ARTの設計や構造を決めるのは、たいていはチームからの情報に基づいて管理者が担当する。その後に続く継続的な管理は、通常、チームを具体的な技術的成果へと導く専門家としての管理者から、リーン-アジャイルなリーダーおよびイネイブラー/人材育成者としての管理者へと、質的な変化を遂げる。


 

さらに知りたい場合

[1] Kniberg, Henrik.Scrum and XP from the Trenches. lulu.com, 2015.(邦訳:塹壕より Scrum と XP、InfoQ Minibook、2008)

[2] Beck, Kent and Cynthia Andres.Extreme Programming Explained:Embrace Change, 2nd edition.Addison-Wesley, 2004.(邦訳:エクストリームプログラミング、オーム社、2015)

[3] Sutherland, Jeff and Ken Schwaber.Scrumguides.org.

Last update:19 October 2015