アジャイルプロセスを拡張するためのフレームワークの選択
アジャイルは、効率性、生産性、コラボレーションを向上させるために多くの組織や企業が採用している、人気のプロジェクト管理手法です。プロジェクト管理やソフトウェア開発で、すでにアジャイル手法を活用している方も多いと思います。そして、このアプローチの利点を組織全体へと拡張することができないか、検討している方もいらっしゃると思います。
良いニュースは、適切なフレームワークがあれば、アジャイルプロセスを拡張できるということです。そこで、この記事では、アジャイルプロセスを拡張する方法を解説し、SAFe、LeSS、DA、SoSなど、チームでの使用を検討すべきフレームワークをいくつか取り上げます。
主な内容：
- 大規模アジャイルの定義
- 大規模アジャイルの考慮事項
- Scrum＠Scale（S@S）
- 大規模スクラム(LeSS)
- ディシプリンドアジャイル(DA)
- 大規模アジャイルフレームワーク(SAFe)
- その他の優れた手法
- フレームワークの選択
- 今日からアジャイルチームを拡張する
大規模アジャイルの定義
多くの組織では、プロジェクト管理にアジャイルの原則を取り入れています。自身のチームが、既に取り入れているようであれば、他のチームや部門でもその利点を体験できるように、アジャイルプロセスを拡張する必要性を感じているかもしれません。
大規模アジャイルとは、組織内の部門を超えたあらゆるチームにアジャイル手法を導入するプロセスのことです。アジャイルプロセスを拡張することで、チームレベルでの業務プロセスを合理化し、より大きなグループが同様の手順に従うことを可能にし、組織全体でプロジェクトに対して持続的かつ効果的にアプローチできるようになります。
アジャイルプロセスを拡張することには多くの利点があります。まず、レポートラインを整理し、個々のコントリビューターから経営幹部まで、階層構造の一部として何が期待されているかを明らかにすることができます。これには、目標設定、マイルストーン、承認プロセスなどが含まれます。その結果、プロジェクト管理の改善だけでなく、コミュニケーションの増加、コラボレーションの改善、変化する要件に対応できる柔軟なチーム作りが可能になります。
アジャイルプロセスを拡張するとき、プロジェクトマネージャーは単なる計画やプロセス以上のものを必要とします。進捗追跡ツールは、リーダーシップに依存関係やリスクについてのインサイトをもたらし、チームが協力する必要がある箇所を示し、進捗を妨げる可能性のあるものを特定することができます。また、取り組みの優先順位を決める際に、透明性を確保することができます。
リモートチームやハイブリッドチームの場合、適切なコラボレーションを促進するために、コミュニケーションツールも必要です。チームの文化が異なれば、普段のやり取りの手段も異なることを考慮し、選択するプラットフォームは、組織全体から関係者やコントリビューターが比較的容易に集まることができるものであるべきです。
アジャイルプロセスを拡張するタイミングは、拡大する理由を関係者に納得させることと同じくらい重要です。ひとつ検討すべきことは、既存の開発アプローチが需要を満たしているかどうかということです。もし需要を満たしていないのであれば、原因はリソースの割り当てだけではない可能性があります。アジャイルプロセスを拡張することで、チーム間の依存関係の管理を改善し、関係者の承認にかかる時間を短縮することができます。また、マーケティングやカスタマーサクセスなどの他の部門が、顧客などの外部グループとコミュニケーションをとるために必要な情報を備えることができます。
もちろん、大規模アジャイルの実施には課題もあります。プロジェクト管理、要件設定、承認などにおいて、確立されたプロセスや手順を優先するため、各個人の好みの方法を放棄することを求められることが多くあります。従業員は、仕事の組織化、分配、測定の方法が透明化されたことで、自分の貢献に対してより責任を持つようになります。
コラボレーションが進むと、ほかのチームとの成果物に対する説明責任を問われることに慣れていない部門は、当初負担を強いられることもあります。アジャイル開発やその拡張をサポートするシステムやソフトウェアツールの導入も、まずそれを展開し、チームメンバーに適切な使用方法をトレーニングする必要があるため、導入当初はプロセスがスローダウンする可能性があります。
大規模アジャイルの考慮事項
アジャイル手法はひとつではありません。組織の特定のニーズや構造に応じて、多くの異なるフレームワークやアプローチを使用することができます。自社に適したものを選んだり、新しいアプローチに切り替えたりすることは、アジャイル手法に精通していないプロジェクトマネージャーや関係者にとって、思い通りにならずフラストレーションが溜まるものです。
この後、S@S、LeSS、DA、SAFeなど、アジャイルプロセスをスケールアップするために利用される、人気のあるフレームワークのいくつかを紹介します。それぞれ、より大規模な組織で利用するために、柔軟に導入できるように設計されています。
自社に最適な大規模アジャイルフレームワークを選ぶ際に考慮すべき要素がいくつかあります。まず、フレームワークにどれだけの柔軟性が必要かで判断するのがよいでしょう。また、導入に時間がかかる新しいフレームワークを選択するよりも、現在のフレームワークを拡張するほうが理にかなっていることがあります。また、複数のチームや部門をプロセスに組み込むには、異なるアプローチが必要になるため、フレームワークをどの程度広範囲に導入する必要があるかということも課題です。
また、どのような種類のアジャイル手法でも、導入する際の課題も考えておく必要があります。既に何回か触れましたが、どのようなプロセス変更においても重要なのは、個々のコントリビューターのマインドセットです。プロジェクトマネージャーや関係者は、チームがこれまで経験したことのない透明性や手順の遵守を要求し、慣れ親しんだ仕事のやり方を変えるように動機付ける必要があります。このような組織文化の変化は、アジャイルアプローチを心から信じ、従業員を育成強化したいと願うマネージャーによって促進されます。
大半のチームがアジャイル手法としてスクラムを採用していることは重要です。そのため、多くの大規模アジャイルフレームワークは、一貫性とよりシームレスな実装のために、スクラム手法をベースに構築されています。ここでは、さまざまな大規模アジャイル方法論について、基本的なものからより複雑なものへと説明していきます。
Scrum＠Scale（S@S）
Scrum＠Scale（S@S）は、アジャイルを拡張するための最もシンプルなフレームワークです。多くのプロジェクトマネージャーがチームレベルで慣れ親しんでいるスクラムプロセスを拡張し、より広範囲の状況に適用したものです。
基本的に、スクラムでは、共通の目的のためにチームが協力します。このアプローチを拡張するには、開発チームをベースとして、その他のチームを上部に積み重ねたピラミッドを想像してください。これは、プロセスを前進させるために必要な主要なコントリビューターや関係者を表しています。このように整理することで、各チームが階層構造と役割について把握し、プロセス、タスク、承認を組織化することができます。
スクラム開発は、透明性と適応性を優先し、明確に定義された目標を達成するために反復的に作業する経験的なアプローチです。スクラムは、タスクの明確な優先順位付けと定期的なミーティングによってチームを組織化し、あらゆる開発障壁を軽減するように構成されています。増分タスクが最小単位に分解され、チームによって難易度が評価されるため、完成までの期間をより正確に予測でき、機能要件や成果物の定義も明確になります。
スクラムチームは、プロダクトオーナー、スクラムリーダー、開発者からなるメンバーで構成され、メンバーは、毎日のスタンドアップミーティングから計画セッション、スプリントレビューに至るまで、さまざまなイベントに参加します。
S@Sでは、これらの基本を取り入れ、組織全体で小規模で管理可能なチームにわけて適用します。開発プロセスを追加したり、重ねたりすることもあります。また、他の種類のチームを解体して、異なるビジネスユニット間で成果物が明確になるようにすることもあります。スクラムマスターは、フレームワーク全体を統括し、チーム間の効率改善や障害となる部分を正確に指摘するために指名されます。
Scrum＠Scale（S@S）は正式名称であることに注意してください。スクラムオブスクラム（SoS）は複数のチームを組織化するための方法ですが、用語が似ているため、Scrum＠Scale（S@S）と混同されることがよくあります。
大規模スクラム(LeSS)
大規模スクラム(LeSS)は、Scrum@Scaleの構造がもう少し整えられており、チームの成長に合わせた拡張が可能になります。LeSSはスクラムのフレームワークをひとつスクラムチームで洗練し、一人のスクラムマスターがバックログを作成し、個々のタスクを定義する責任を負います。そして、さまざまなスクラムのコントリビューターがこの構造の下に分散して配置され、ひとつ製品に統合される個々の成果物を任されます。
LeSSは単一チームのアプローチとして機能し、スクラム別のセッションではなく、全員参加型のセッションでミーティングやレビューを簡素化します。
S@Sのように、LeSSはスクラムの開発原則に依存しますが、リーン製品開発の原則にも依存します。このフレームワークは、タスクに費やされるリソースや時間の無駄を低減することを目的としています。このアプローチでは、スプリントと呼ばれる短い開発サイクルにより、販売可能な製品を繰り返し生産し、より効率的に市場に投入することができます。また、コントリビューター全員をひとつのチームにまとめるか、スクラムチームを集めてレビューやミーティングをおこない、理解を深めることで、コミュニケーションの障壁を取り除きます。
LeSSの主な特徴のひとつは、あらゆるチームとコントリビューターが、使用可能な製品をつくるために同じ時間軸で作業していることです。開発段階の異なるチームがそれぞれのコンポーネントや機能に取り組むのではなく、同じスプリントで結果を出すために、タスクを分解し、協力して作業します。全員が同一のバックログと共有タスクリストにもとづいて作業し、より規則的かつ効率的にソリューションを提供するよう努めます。
ディシプリンドアジャイル(DA)
もう少し構造化したい場合は、ディシプリンドアジャイル（DA）フレームワークがあります。DAフレームワークはツールキットであり、プロダクトオーナーとスクラムマスターが、組織独自のニーズに応じてアプローチをカスタマイズすることを可能にします。このフレームワークの主な目標のひとつは、開発タスクと変更を反復することによって意思決定プロセスを簡素化することです。
DAは、スプリントやバックログといったスクラムの側面を取り入れていますが、「ピープルファースト」であり、先に進むために必要な意思決定をリーダーがおこなうことができます。また、より広く組織全体に適用し、そのプロセスに対処し、開発の運用方法に組織の意見を取り入れることができます。
このアプローチは、より構造化されています。ディシプリンドアジャイルは通常、マインドセット、ピープル、フロー、プラクティスという4つの主要な側面に取り組みます。それぞれの側面には、あらゆるレベルの人々（ピープル）が従うべき役割、責任、ライフサイクル、ワークフローなどが定義されています。
DAのもうひとつの特徴は、リーダーが開発構造と反復プロセスを特定のニーズに合わせてカスタマイズできることです。そのため、DAが導入されるとプロセスが硬直化する可能性がありますが、導入時にプロジェクト管理について定義しておくと、かなり柔軟に対応することができます。DAは、構造化は求めているが、スクラムを、そのままではビジネスプロセスには適用できない大企業などに特に適しています。
大規模アジャイルフレームワーク(SAFe)
大規模な導入向けに構築されたプロセスを検討している組織にとっては、大規模アジャイルフレームワーク（SAFe）が選択対象になります。このフレームワークは、チームレベルと組織レベルの両方で計画を立て、組織全体で効率化のための対策を策定することを目的としています。
SAFeは、特にチームに適用する場合、概ねスクラムに似ていますが、プログラムとポートフォリオの視点を加えることで、リーダーやマネージャーが、タスクレベルまで仕事量に優先順位をつけることができるようになっています。
SAFeでは、チームメンバー全員が同じイニシアチブに取り組むのではなく、大規模な開発者のグループが、それぞれのチームのイニシアチブを同時並行で反復するアプローチをとります。これらのチームはアジャイルリリーストレイン（ART）と呼ばれ、共通のプロジェクトや成果物を中心に形成され、大きな枠組みの中で、設定されたイニシアチブを完了するために作業をおこないます。つまり、あるチームは、別のチームとはまったく異なるものに取り組んでいる可能性があります。これにより、大規模組織は、情報の流れを発展させながら、運用と目的を合理化することができます。
ポートフォリオレベルの活動が先導し、エグゼクティブリーダーが製品やサービスのビジョンを定める責任を負います。プロジェクトマネージャーは、これをビジネス戦略に沿った成果物に落とし込みます。その結果、トップダウンのアプローチが形成され、リーダーが期待値を設定し、ARTにイニシアチブが割り当てられ、チームには全体像に組み上がるタスクが指定されます。
SAFeでは、成功について定義し、タスクと目標の整合性を直接取るのと同時に、別々の開発グループがそれぞれの速度で作業できるため、アジャイルプロセスを利用するチームにとって最も現実的な指針を提供します。しかし、複雑なアジャイルフレームワークであることは確かであり、組織によっては厳密すぎるフレームワークであるかもしれません。また、トップダウンで指示が出されるため、経営陣がより実践的な役割を担うことになり、開発者の自発性を制限し、アジャイルプロセスであることを制限してしまうこともあります。
その他の優れた手法
これまで解説したのフレームワークは、最も一般的に使用されているものですが、検討する価値のあるほかのフレームワークを次にいくつか紹介します。
Nexus
Nexusは、若干の変更点を除いてScrum＠Scaleに似ており、アジャイルチーム間の取り組みの調整において、上層部のプロジェクト管理者と関係者がより大きな発言権を持つことができます。特に、スプリント計画は全チームが同時に実行し、スプリントレビューとレトロスペクティブミーティングにはスクラムチームが集まり、全員が共有プロセスの経験を聞くことができます。
Spotifyモデル
Spotifyモデルは、開発部門のみを対象にしたものではなく、組織全体をより広範囲に組織化する方法です。グループの中にグループを設置し、個人が企業目標に沿ったタスクと成果物を定義できるようにします。このモデルはマトリックス構造に似ていますが、典型的なアジャイルフレームワークよりも個々のコントリビューターに自律性が与えられているため、説明責任が欠如する可能性があります。
エンタープライズカンバン
もうひとつの比較的新しいモデルは、エンタープライズカンバンです。これは、基本的に、カンバンプロジェクト管理手法を組織のあらゆる側面や部門に適用するものです。エンタープライズカンバンでは、コントリビューターが従うべき明確なワークフローを確立し、通常は可視化用途のソフトウェアと組み合わされますが、組織がどのように構成されるべきかの詳細を示すものではありません。
フレームワークの選択
フレームワークを選択することは、時間がかかり、困難が伴うことが予想されます。しかし、非常に多くの選択肢があるため、どんな組織でも独自のニーズに合ったフレームワークを見つけることができます。アジャイルの目的には、自社のニーズを満たすために適応または浸透させることができるプロセスや手順を確立することが含まれることも忘れないでください。
また、スクラムのようなフレームワークをすでに導入している組織では、変更管理の問題を軽減するために同様のアプローチを選択することが理にかなっている場合があります。組織が急速に成長している場合や、近い将来、開発チームがエンタープライズレベルの規模になることが想定されるのであれば、成長に合わせて拡張できるように、より複雑なフレームワークを導入する価値があるかもしれません。
スクラムベースのフレームワークは、フラットな組織や、タスクを進めるために複雑な要件を必要としない組織に適している傾向があります。対照的に、SAFeのようなフレームワークは、業務全般にわたって行動を規定し、従来的なビジネス目標に確実に結びつけいたい組織に適しているかもしれません。
アジャイルフレームワークの選定過程で登場することの多い3つの重要な要素は次のとおりです。
- サイズ： 大規模な組織では、一般的に、SAFeやSpotifyモデルのような、構造化されたアプローチから利点を得ることができます。小規模なチームには、既存のスクラムプロセスから構築されているS@SやLeSSの方が適合しやすいかもしれません
- 構造： SAFeのようなより厳格なフレームワークは、出力をコントロールしたいトップダウンの組織に好まれることが多いようです。DAのようなより柔軟なフレームワークは、ニーズのある成長中の小規模な組織にとって、より魅力的かもしれません
- 俊敏性： 開発チームをアジャイルにし、需要を満たし、反復生産の必要性を満たしたい組織は、柔軟性をもたらすフレームワークを望むでしょう
今日からアジャイルチームを拡張する
いくつかのアジャイルフレームワークについて理解を深めたところで、自社のビジネスニーズにもとづいて、最適なフレームワークを評価することができます。組織はそれぞれ独自の面があるので、100%フィットするものを見つけるのは難しいかもしれせんが、それは一般的なことです。アジャイルフレームワークは、特定のユースケースに比較的容易に適合させることができます。そして、アジャイルチームを拡張する際に、いくつかのロードマップから選ぶことができます。
アジャイル手法に取り組む準備ができたら、どのフレームワークが魅力的か、あるいは自社のニーズに最も適していると思われるかを検討しましょう。そして、組織の重要な関係者に意見を求め、この記事を自由に共有してください。関係者の声に耳を傾け、長所や短所を比較することで、正しい選択が明らかになるはずです。
大規模アジャイルフレームワークを選択したら、戦略を実行するために優れたプロジェクト管理ツールが必要です。Adobe Workfrontは、作業を戦略に結びつけ、より優れたコラボレーションを促進し、測定可能なビジネス成果を達成するための作業管理ソフトウェアです。各部門の従業員、データ、プロセス、テクノロジーをつなぎ合わせ、プロジェクトの開始から終了に至るまで、ライフサイクル全体を包括的に管理できます。
Adobe Workfrontの詳細については、製品ツアーまたは概要動画でご確認ください.