アジャイルチーム

アジャイルチームは最高だ。

─SAFeのマントラ

アジャイルチームの概要

アジャイルの運動(その一部は2001年のアジャイル宣言に表現されている)は、ソフトウェアやシステムの開発方法の大きな転換点となった。SAFeは、この変化をベースにして、価値を作成し納品する構成要素としてのアジャイルチームに権限を委譲するよう作成されている。

権限委譲されたモチベーションの高いメンバーで構成された有能なアジャイルチームがなければ、組織がアジャイルを大規模展開して、エンタープライズリーン-アジャイル開発のビジネス面の大きな利点を手にすることはできない。リーン-アジャイルなリーダーのもっとも重要な責任は、このアジャイルチームを作成し、指導することである。

SAFeのアジャイルチームは、ソリューションの価値の定義構築テストのすべてを短い反復という時間枠の中で行う能力と権限を持った個人から構成される、機能横断的なグループである。このチームには、必要に応じてプログラムレベルや価値のストリームレベルの専門家のサポートを受けながら、この価値の納品を成功させるために必要なメンバーが含まれる。これは、ローカルの要求や設計に関する権限を、実際の作業を担当するチームに委譲するという点で、SAFeの「意思決定を分散する」の原則に合致している。

SAFeのアジャイルチームは、単独で機能するわけではない。アジャイルチームはアジャイルリリース列車(ART)に不可欠な要素であり、複数のアジャイルチームが共同責任としてARTの価値を納品する。すべてのチームが列車に乗っているし、チームの乗っていない列車は存在しない。チームは、列車というコンテキストで列車のビジョンに沿って仕事をし、他のチームと協調し、ARTの主要イベントに参加する。チームと列車は切り離せない。全体は部分の総和に勝る。

詳細

アジャイルチームは、専任のメンバーで構成される少人数のグループであり(スクラムでは5~9人)、短い固定期間の中で価値のインクリメントを定義(コンポーネント/フィーチャーの推敲と設計)、構築(コンポーネント/フィーチャーの実装)、テスト(テストケースの実行とコンポーネント/フィーチャーの検証)するために必要なスキルをグループとして備えている。アジャイルリリース列車(ART)のコンテキストにおいて、チームは、権限を委譲され、自己組織化および自己管理し、顧客のニーズや期待を満足させる結果を納品する責任を持つ。ソフトウェアやハードウェアやファームウェア、あるいはそれを組み合わせたものなど、開発するものはチームによって異なるが、ほとんどの場合、チームはフィーチャーを納品するのに必要なさまざまな分野の協調を象徴する。

企業は、人を仕事に割り当てるのではなく仕事をチームや列車に割り当てることで、ソリューションを納品する能力を容赦なく改善することに熱心な、長期にわたって存続するチーム(や複数のチームからなるチーム)の作成を支援することができる。この点で、SAFeは、管理者が個人に対して作業を指示するという従来型のアプローチとは異なっている。何を構築するかやフィーチャー/コンポーネントをどう構築するかを決めるのは、管理者ではなくSAFeチームである。リーン-アジャイルなリーダーは、優秀なチームを育成し、その能力をさらに高めるために必要な、ビジョンとリーダーシップと自治を提供する。個々のチームメンバーに作業項目を割り当てる必要はなくなる。こうすることで、意思決定の分散が、個々の担当者のレベルにまでいきわたる。

役割と責任

機能ごとに縦割りされたステージゲートの開発モデルでは、分断された機能ごとの部署で作成されたものを、長いライフサイクルの終盤でまとめて、やっとユーザーの価値が納品される。SAFeを導入することでこのモデルから足を洗うことができる。アジャイルチームは、このような機能すべてに関して、自分で実施するかそれに関与し、反復ごとに価値を納品する。

  • チームは自身の作業を管理する責任を負う。
  • チームは作業の規模と複雑さを見積もる。
  • チームはアーキテクチャー指針に基づいて、担当範囲の技術設計を決定する。
  • チームは反復またはプログラムインクリメント(PI)の時間枠の中で完了できる作業を確約する。
  • チームは価値に責任を持ち、成果物の品質を継続的に改善できるよう構築を行う。
  • チームは常に全力で改善の方法を模索する。

密度の高い協調

チームが責任を果たすには、常にコミュニケーションを行って協調し、権限を持って迅速かつ有効な意思決定をしなければならない。可能な限り同じ場所で仕事をし、時間ごと、日ごと、週ごとのコミュニケーションを図る。標準的にどのようなチームミーティングをするかは選択したフレームワークによって変わるが、デイリースタンドアップミーティングや、反復計画チームデモ、各反復の最後の振り返りなどが行われる可能性がある。各チームメンバーは1つのチームの専任であり、週の労働時間すべてをその仕事に集中する。チームメンバーは、継続的かつ積極的に、他のチームと連携を取り、依存関係を管理し、障害を解決する。チーム内の関係は基本的に信頼に基づいていて、その信頼は使命、反復のゴール、チームのPI目標を共有することで育成される。チームの学習サイクルに組み込まれた定期的なフィードバックループによって、協調作業が継続的に改善される。価値を目に見える形で納品するたびに、信頼が高まり、不確実性とリスクが低減し、自信が育まれる。ビジョンの共有と、顧客に価値を納品するという確約が、アジャイルチームのモチベーションとなる。

チームはアジャイル手法を選択できる

SAFeチームは、主にスクラムチームカンバンに基づいて、選んだアジャイルプラクティスを使用する。ほとんどのSAFeチームは、プロジェクト管理と納品の基本のフレームワークとしてスクラムを採用している。スクラムのプロダクトオーナーは、分散して行われる意思決定(これはチームへ権限委譲するために不可欠である)に参加し、それをサポートする。スクラムマスターは、チームが納品目標に向かって進むのを補助し、自己管理する優秀なチームの構築を支援する。

しかし、スクラムを使っているからといって他を使用できないわけではない。チームは、ユーザーエクスペリエンス(UX)に基づくエンジニアリングや品質の作り込みのプラクティスを用いて、規律ある開発を進め、品質を向上する。共同所有、ペアワーク、コーディング標準、テストファースト、継続的インテグレーションといったプラクティスを実施することで、ものごとがリーンになる。品質が作り込まれ、開発プロセスで効率を直接管理できるからである。そこにアジャイルアーキテクチャーが加わると、質の高いソリューション開発の全体像が完成する。

ただし、SAFeはフローベースのシステムなので、ほとんどのチームではさらに、カンバンを使用して作業の可視化やWIP制限の設定を行ったり、累積フロー図でボトルネックや重要なチャンスを明らかにしてスループットを改善したりしている。保守チームやDevOpsシステムチームといった一部のチームでは、基本のプラクティスとしてカンバンを使用することも多い。計画策定や確約といったスクラムの要素は、作業や需要によって負荷が左右されたり、優先順位が頻繁に変わる環境では、あまり効果的に働かないためである。

アジャイルチームは列車に乗っている

SAFeのアジャイルチームは独立して機能するのではない。ARTに動力を供給し、これまで以上に価値の高い動くソリューションのインクリメントを協力して構築する。チームがスクラムを使っているかカンバンを使っているか、あるいは両者を融合しているかを問わず、列車を規定し指針を与える共通のフレームワークの中ですべてのチームが稼働する。すべてのチームは、一緒に計画を立て一緒に統合とデモを行い一緒に学習する。その様子を図1に示す。

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

一緒に計画を立てる

すべてのチーム(可能であればすべてのチームメンバー)がPI計画ミーティングに参加し、一緒に一連のPI目標を計画し、確約する。共通のビジョンロードマップのもとに仕事をし、目標を達成するために協力する。内容に関する権限を持つ役割が明確になっているため、計画や実行のプロセスが円滑に進む。プロダクトオーナーは、内容の権限を持つプロダクト管理という上位のチームの一員である(カンバンチームの場合にはこの役割に別の名前が付けられていることもある)。チームがそれぞれに持っているチームバックログは、主にプログラムバックログをもとに作成される。

さらに、すべてのアジャイルチームは、経済的枠組みに従って、ARTの一部として、共通のアプローチで行われる見積もり作業に参加する。これは、意思決定権限を持つ人が経済性に基づいて行動方針を決めるうえで、有意義であると立証されている。それを達成する方法は選択した手法によってさまざまだが、結果は同じである。これについてはスクラムチームカンバンのページで詳しく説明する。

一緒に統合とデモを行う

質の高い複雑なシステムを納品するには、チーム間の密度の高い協力と協調が必須である。それを行うために、チームは共通のARTのリズムで動き、各反復の最初に反復のゴールを発表し伝える。また、ART同期ミーティングで他のチームに最新情報を伝え、他チームのチームメンバーとやり取りすることで積極的に依存関係を管理する。

もちろん、単にチームがゴールに向かって「スプリント」するだけでなく、質の高い評価可能なインクリメントに向かってシステムを「スプリント」させることが目標である。そのために、チームは品質を作り込み、反復全体を通じてチーム内および列車全体で継続的に統合を行う。また同時に、反復の終わりごとに全体のシステムデモを行うことができるよう協力する。

一緒に学習する

SAFeのチームメンバー全員が容赦ない改善に取り組む(「リーン-アジャイルの考え方」のページの第4の柱を参照)。チームレベルの振り返りや適宜行われるプロセス向上のほかに、チームは上のレベルの検査と適応ミーティングに参加して、改善ストーリーを洗い出して優先順位を付け、それをそのあとのPI計画セッションに組み入れる。こうすることで、チームやARTが一度に1つずつ反復やPIを進む過程で「ループが閉じる」。そしてもちろん、学習は振り返りだけでなされるのではなく、個人やチームが機能のスキルや機能横断的なスキルを向上できるよう結成された専門技能コミュニティーにおいても、継続的に行われる。


さらに知りたい場合

[1] Leffingwell, Dean.Scaling Software Agility:Best Practices for Large Enterprises.Addison-Wesley, 2007.(邦訳:アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス、翔泳社、2010)

[2] Lencioni, Patrick.The Five Dysfunctions of a Team:A Leadership Fable.Jossey-Bass, 2002. (邦訳:あなたのチームは、機能してますか?、翔泳社、2003)

[3] Cohn, Mike.Succeeding with Agile:Software Development Using Scrum.Addison-Wesley, 2009.

[4] Manifesto for Agile Software Development.http://agilemanifesto.org/.

Last update:19 October 2015