アジャイル・プログラム管理とは

アジャイル・プログラム管理とは、柔軟性、コラボレーション、反復開発、顧客フィードバックの優先順位付け、継続的な改善といったアジャイルの原則に基づいた複数の関連プロジェクト（プログラム）を管理するためのアプローチです。

アジャイルは、特定の方法論以上の原則を持つ哲学です。ただし、スクラム、エクストリーム・プログラミング（XP）、カンバンなど、アジャイル・プログラム管理の一部であることの多い、確立されたアジャイル方法論があります。アジャイル・プログラム管理は、当初はソフトウェア業界向けに、顧客により迅速により大きな価値を提供するために設計されましたが、現在では業種・業務をはるかに超えた用途で使用されています。

アジャイル・プログラム管理には通常、複数の関連プロジェクトが含まれます。個々のプロジェクトはアジャイル・フレームワークを使用して管理できますが、アジャイル・プログラム管理では、ライフサイクル全体にわたって、一連のプロジェクトを単一の一貫した全体に組み込みます。レベルを上げると、一連のプログラムと基礎となるプロジェクトが、より広範なポートフォリオ管理戦略の下で編成される場合があります。

アジャイル・プロジェクト管理では、特定のプロジェクトに焦点を当て、その１つのプロジェクトに関連する目標、タイムライン、リソース、チームの管理を行います。アジャイル・プログラム管理は、関連するプロジェクトのグループと、これらのプロジェクトをより広範な組織目標の下で統合するストラテジーを監督します。これら2つの分野は同じ機能の多くを共有していますが、範囲が異なり、アジャイル・プログラム・マネージャーはプログラムのストラテジー、リスク、利害関係者とのコミュニケーションなどにおいてより広範な役割を果たします。

簡単に、単純化しすぎた考え方をすると、プロジェクト管理は個々のプロジェクトの戦術的でタイムリーな実行に、より関心を持っているということです。一方、プログラム管理では、より戦略的なアプローチを採用し、プログラムの管轄下で個別のプロジェクトの包括的な成功を調整します。

分野としてのプロジェクト管理は、1950年代に米国で形成され始めました。1990 年代までに、「ウォーターフォール」と呼ばれる一連の手法が形式化されました。この手法では、プロジェクトの各フェーズを完了してからチーム全体が次のフェーズに移動します。しかし、ソフトウェアの活力と複雑さが増すにつれて、従来のプロジェクト管理やウォーターフォール手法は煩雑で、迅速に動き、頻繁に変更が発生するプロジェクトには理想的ではないことが判明しました。

2001年、ソフトウェア開発者のグループが、アジャイルなプロジェクト管理のためのアジャイル・マニフェストを作成しました。これには4つの主要な価値感と12の原則が含まれています。重要な価値観は次のとおりです。

• プロセスとツールに関する個人とインタラクション
  
  
• 包括的なドキュメントよりも動作するソフトウェア
  
  
• 契約交渉よりも顧客とのコラボレーション
  
  
• 計画に従うことよりも変化に対応すること

望ましい価値観は、望ましくないものの放棄を必要としません。たとえば、アジャイルの哲学では、計画の使用を禁止するのではなく、避けられない変化への対応と準備に重点が置かれています。

これらのアジャイルの原則はソフトウェア開発プロセスでますます人気を高めていますが、その哲学は、アジャイルなソフトウェア開発をはるかに超えています。アジャイルの原則は現在、ファッションからバイオテクノロジー、官公庁・自治体まで、さまざまな業種・業務で採用されています。

アジャイル・アプローチがウォーターフォールなどの従来の手法と異なるのは、アジャイル手法が最初から、反復的で協力的で柔軟であるように設計されていることです。アジャイル・プログラム管理システムでは、プロジェクトは迅速に作成され、定期的にレビューされ、チームや顧客の対応に応じて話し合いが行われ、変更されます。計画とアプローチは変更する必要があり、当初の計画に隷従する必要はないことが最初に想定されます。他のアプローチのように厳格な階層構造がなく、個々のチームメンバーに発言する権限が与えられます。

アジャイル・プログラム管理は具体的な方法論というよりは哲学であるため、アジャイルの実践の詳細は組織ごと、またはプログラムごとに大きく異なります。しかし、アジャイル・プログラム管理には一般的に見られるいくつかの側面があります。

アジャイル・プログラム管理には、複数の個別プロジェクトが含まれます。プロジェクト全体も個々のプロジェクトもアジャイル・フレームワーク内に編成される場合があります。アジャイル・プログラム管理には、プロジェクト・グループの全体的かつ全体的な視点が組み込まれます。多くの場合、予算編成、全体的なストラテジー、長期分析など、個々のプロジェクトの管理にははない要素が含まれます。

変化に素早く対応することは、アジャイルの哲学の核となる信条です。このためアジャイル・プログラム管理では、変化について、軌道を修正し、顧客に価値をもたらすために外出先でも改善を行う機会として捉えます。プロジェクトを小さな単位に分割して完了することで、組織はより柔軟に、より迅速に方向転換することができます

アジャイル・プログラム管理の重要な側面は、反復的なアプローチにあります。プログラム内の個々のプロジェクトは複数のバージョンを経ており、製品開発チームはそのたびに成果について話し合い、それを改善していきます。プロジェクト全体であれ、単一の側面であれ、優れた成果を継続的に提供することが重要です。顧客からのフィードバック、KPI、変化する要件に基づいて、反復ごとに製品を改良することも重要です。

アジャイルの優先順位付けにより、だらだらと続くEメールやその他のテキストベースのコミュニケーションよりも、対面での会話が優先されます。Eメール・スレッドでは、時間的制約やEメールの見逃しなどにより、数時間、数日、場合によっては数週間かかることもありますが、対面のコミュニケーションでは数分で同じタスクを完了できます。

アジャイル・プログラム管理では、プログラムの包括的な視点として、効率性と、不要または煩雑な要素の削除に重点を置き続ける必要があります。ドキュメンテーションは目的そのものではなく、目的への手段であり、必要なものだけを含める必要があります。

誠実さとオープンさは、アジャイル・プログラムを成功させるための鍵です。会話では、チームメンバー全員が発言できるようにする必要があります。この管理アプローチでは、全員の声が正当であり、聞き入れられます。

同時に、実現不可能なアイデアを、そのアイデアの考案者が今後発言をためらう原因となることがないようにして除外することを、受け入れなければなりません。「ふりかえり」（または「レトロ」、つまりフィードバックを収集したプロジェクト後の評価）の成功は、チームの透明性にもかかっています。

アジャイル・プログラム管理は、哲学として、特定のフレームワークの使用を必要としません。しかし、スクラムやカンバンなどの多くのプロジェクト管理フレームワークは、アジャイルの哲学と密接に関連しています。ここでは、最も一般的なフレームワークをいくつか紹介します。

スクラムは、共同チームプロジェクト作業のためのフレームワークです。この名前は頭字語に似ていますが、実際にはラグビーというスポーツに由来しています。このスポーツでは、スクラムで選手たちが腕を組んで敵に向かって協力して突き進んでいきます。これはある種、馬を使わない騎兵隊の突撃です。

アジャイルでは、スクラム・チームには3つの役割が含まれます。

• プロジェクト・マネージャー：スクラム・チームと利害関係者（ユーザー、顧客、親会社など）との間の連絡役です。プロジェクト・マネージャーは、予算、人員配置、フィードバックなどの外部要因をスクラム・チームに伝えると同時に、チームの進捗状況を利害関係者に伝える責任があります。
  
  
• スクラム・マスター： スクラム・マスターは、伝統的な「上司」というよりは、スクラム・メソッドの教師であり、指導、コミュニケーション、問題解決を促進する指揮者です。スクラム・マスターは通常、雇用や解雇の責任を負いません。
  
  
• 開発者またはチームメンバー： この用語は、例えばスクラムチームが業種・業務以外の業界にいる場合などには異なることがある。この役割が開発者、チーム・メンバー、スタッフ・メンバーなどと呼ばれる場合でも、この役割には階層がありません。チームの規模は3～9人程度が理想的ですが、大規模なグループは、スクラム・マスターが指導するのがより困難である傾向があります。これには、経営陣が過度な計画を立てることなく、チームが成功するためには誰が必要で何を必要とするかを個人が正確に決定する自己編成チームも含まれます。

スクラムには、他のチームベースの組織モデルとは別に、いくつかの特別な概念があります。プロダクト・バックログとは、チームがスクラム中に必要とする可能性のあるすべてのタスク、アイデア、要件、成果物、リソースのリポジトリーです。これは、その効率性と完全性を確保するために、チームによって常に更新および監視されることができます（そして実際に行う必要があります）。

スクラムでは、作業はスプリントに分けられ、通常1週間から4週間続きまづ。スプリントでは、チーム・メンバーは具体的な成果物の目標を達成するために働きます。その目標とは、作業モデル、モックアップ、プロトタイプ、あるいは完成品やソリューションの1つの機能や要素かもしれません。

スプリント中、チーム・メンバーは「毎日のスクラム」または「スタンドアップ」で1日1回ミーティングを行います。これらの会議は、スクラムの原則に従って、非常に高いレベルのものとなります。所要時間は15分以内で、毎日のスクラムでは、チーム・メンバーが進捗状況や作業の妨げとなる障害を手短に、可能な限り簡潔に発表します。場合によっては、特定のチーム・メンバーが毎日のスクラムで発表された内容についてさらに話し合うために、日常のスクラム後のミーティングを中断することがあります。

スプリントの最後には、チーム・メンバー、スクラム・マスター、プロジェクト・マネージャーなどのチーム全体が集まり、構築されたものについてレビューし、話し合います。プロジェクト・マネージャーは、ユーザーや大規模組織などの利害関係者からの変更を伝えることができ、議論の後で、チームはそれらの変更を次のスプリントに取り入れることができます。

カンバンは、プロジェクトを管理および追跡するための視覚的なシステムです。カンバンボードは、プロジェクトに関するチームの進捗状況を視覚的に表現し、個々のサブタスクがいくつかあるカテゴリーののいずれかに分類されます。これらのカテゴリには通常、次のものが含まれます。

• バックログ：まだ別のカテゴリーに移行されていないすべてのタスクです。プロジェクトの開始時には、すべてのタスクがバックログにあります。
  
  
• 実行中：進行中のタスク
  
  
• レビュー中：最初の完了段階に到達し、他のユーザーによって評価されているタスク
  
  
• 完了：完了したタスク。

「カンバン」は、標識（カン）と板（バン）という言葉を組み合わせた日本語で、看板やメッセージボードのような意味です。カンバンは、アナログとデジタルの両方の形式で作成できます。アナログ形式では、物理的なポストイットが個々のタスクに使用されることが多く、完了すると列から列へと移動します。

カンバンボードのデジタル・バージョンも多数あり、メンバーの一部または全員がリモートワーカーであるプロジェクト・チームには特に役立ちます。

エクストリーム・プログラミング（XP）は、もともとソフトウェア・エンジニアがソフトウェアの品質、応答性、速度を向上させるために設計したアジャイル手法です。基本概念はアジャイルの一形態であり、テスト可能な作成タイムラインのさらに小さなバーストに依存しています。

XPでは、プロジェクト全体の個々の要素が繰り返しテストされ、時にはそれを壊すことを意図したテストが行われることさえああります。そして個々のアスペクトは、最大限の互換性を確保するために、しばしば毎週、一緒にテストが行われます。

コミュニケーションにおいては、XPは極限までシンプルであることを信頼します。ドキュメンテーションは、シンプルな言語、概念、メタファーを使用して、他のチームメンバーが理解できるように、可能な限り最小限のものにすることが意図されています。この簡素さは、実際のタスクの設計にも適用されます。 XPプロジェクトは、将来の追加機能を考慮せずに設計されることが多く、それらをプロジェクトのリリースには無関係なものと見なしています。これは、YAGNI（You Aren's Gonna Need It、あなたはこれを必要としない）として知られていることもあります。

XPはすべてのプロジェクトに適しているわけではありません。拡張性や大幅な再作業を必要としないプロジェクトにのみXPを使用することが重要です。

SAFeは、リーン・アジャイル開発手法、DevOps、システム思考に基づいた一連の原則と実践です。大規模アジャイル・フレームワーク（SAFe）は（名前が示すとおり）大規模組織全体でアジャイル・フレームワークを拡張し、複数のプロジェクトを調整して、機能横断性と相互運用性を確保するように設計されています。これは主に、計画増分（PI）ロードマップを含む構造を通じて行われます。

これらのロードマップ内のタスクは、俯瞰的な視点からタスクを特定できるように、さまざまな方法で参照されます。同化には、「イネーブラー」（他のタスクとの依存関係）、「エピック」（特定のビジネス・ニーズのために設計されたより大きな取り組み）、および「ストーリー」（ユーザーまたはビジネスの観点からの必要な機能）が含まれます。

規律あるアジャイルは、完全な方法論というよりは、一連の原則、約束、ガイドラインと見なされています。これは、軽量でミニマルかつハイブリッドなプログラム管理アプローチであり、個々のチームメンバーに大きな自由をもたらすものです。

スクラムやSAFeなどの一部のアジャイル・フレームワークには、規範的な方法論と手順が含まれています。この特異性は、特定のプロジェクトでは素晴らしいことですが、DAはチーム・メンバーに、より多くの自由と機敏性を提供することを目指しています。基本概念により、個人は特定のワークフローに最適な概念とフレームワークを選択できます。スクラムは、特により大きなプログラムの見通しでは、一部では機能する場合がありますが、それ以外では機能しません。DAは個人の手に大きな力を与えるため、知識が豊富で独立性が高く、基本的なアジャイルの概念にすでに精通しているチーム・メンバーが存在するプロジェクトに最適です。

大規模スクラム（通称LeSS）は、スクラムが処理するために構築されたものよりも大規模なチーム、またはチームのグループのために特別に設計された、スクラムのバージョンです。LeSSには引き続きスプリントや毎日のスクラム・ミーティング、レビューが含まれていますが、大規模なチームがその魂を失うことなくアジャイルを拡張して目標を確実に達成するための追加のガイドラインがいくつかあります。

LeSSでは、アジャイル・プロジェクト管理でのように、個々のチームが計画した個別のスプリントではなく、すべてのチームが共通のスプリントに取り組みます。また、プログラム全体に必要なすべてのタスクを網羅した共有バックログもあります。スプリントの計画には、すべてのチームに対する全体的な計画会議と、個々のチームによる個別のスプリント計画会議の2種類の会議が含まれます。

Nexusは、いくつかの追加、削除、変更を加えたスクラムに似たフレームワークです。その主な違いは、コーチとして機能する別のチームメンバーのグループであるNexus統合チームが加わっていることです。NITはスクラム・チームのメンバーが含まれることが多く、障害への対処、支援の提供、アジャイル・プロセスを通じたチームへの指導を担います。NITには、毎日のスクラムとは別に、独自のミーティングがあります。

スクラムはアジャイル・プロジェクト管理における特定のプロジェクトにとって驚異的な概念ですが、アジャイル・プログラム管理について話し合うとき、実際にはチームのチームについて話し合っています。ここでScrum@Scaleが登場します。

Scrum@Scaleでは、すべてのアジャイル・チーム・メンバーが交換可能なスクラム・チームの一員とみなされ、分野を超えたコラボレーションが可能になります。大規模なプログラムが提示する課題をリアルタイムで支援するために、新しいチーム・メンバーが数名います。最高プロダクト・オーナー（CPO）は、すべてのスクラムの単一のバックログを作成し、個々のプロダクト・オーナーと調整を行います。同様の役割に、スクラム・マスター間の取り組みおよびスクラム・マスター間を調整するスクラム・オブ・スクラム・マスターがあります。

リーンは、非効率性を減らし、成果物の品質を継続的に改善することを目的とした方法論です。アジャイルの範疇に含まれると考えられることが多いです。しかし、アジャイルは哲学ですが、リーンはより具体的なツールとガイドラインを備えた方法論です。リーンは非効率性と無駄を最小限に抑えることに最も関心がある一歩で、アジャイルは主に反復、フィードバック、柔軟性に重点を置いています。

リーンには、次の5つの主な原則があります。

• 価値の特定：基本的には、目標が何であるかを正確に把握し、付加価値のないものはすべて排除します。
  
  
• バリュー・ストリームのマッピング：カンバンボードなどの管理ツールを使用して、製品ロードマップを視覚化します。基本的には、プロジェクトの計画を最初から最後まで視覚化することです。
  
  
• ワークフローの作成：考えられる障害を探しながら、特定のステップで製造プロセスを構築します。目標は、可能な限り流動的なワークフローを構築することです。
  
  
• プル・システムの確立： プル・システムは、顧客の要求に応じて、チーム・メンバーがよりより多くの作業の準備ができている場合にのみ、新しいタスクを作成することに依存します。これは多くの場合、タスク・キューを使用して行われます。
  
  
• 継続的な改善：さまざまな手法を用いて、継続的に価値を創造し、製品を改善します。それには、リーン・シックス・シグマやカイゼンなどの方法論や哲学、または永続的なテストと有益なフィードバック・ループを促すスクラムなどの構造化フレームワークが含まれる場合があります。

アジャイル・プログラム管理は、関連する方法論を用いて、プロジェクトの納品を改善する多くの方法を提供します。

• 具体性：継続的に反復することで、アジャイル・チームはプロジェクト全体を闇雲に改善しようとするのではなく、顧客が望んでいることを正確に絞り込むことができます。
  
  
• 効率：アジャイル・プログラム管理には、無駄、ドキュメンテーション、お役所仕事の削減を目的とした信条が含まれます。
  
  
• 汎用性：顧客からのフィードバックに迅速に対応できる汎用性は、アジャイル・プログラム管理の基本的な部分です。アジャイル・チームは、プロジェクトの開始前に、そのプロセス中に変更が行われることを知っています。
  
  
• チームの士気：アジャイル・プログラム管理は、オープン性と透明性を促し、個々のチームメンバーが発言できるようにすることを奨励します。序列は、誠実さと献身的なチームワークと比べて重要ではありません。