アジャイル方式の基本

アジャイル方式とは？

アジャイル方式はプロジェクト管理へのアプローチ手法であり、プロジェクトをまとめるために4つの主なピラーと12の原則を使用しています。このアジャイル方式の概要には、アジャイルアプローチについて知っておくべき内容がすべて含まれています。

アジャイルマニフェストブックの4つの主なピラーは、評価用に設計されています：

1. プロセスやツールよりも個人やインタラクションを優先する
2. 総合的な文書よりも実用的なソフトウェアを優先する
3. 契約交渉よりも顧客とのコラボレーションを優先する
4. 計画に従うよりも変化に対応する

アジャイルとは、プロジェクトのプラニングと実行に関する現在の手法やスプリントをベースとし、プロジェクトを通してプラン、スコープ、デザインを継続的に順応させ、成熟させると定義できます。 

アジャイル方式の定義によると、アジャイルプロジェクトとは、インクリメンタルで一貫性のある方法で顧客またはクライアントに実用的な製品を頻繁に提供する反復可能なアプローチを必要とします。この革新的なアプローチによって、プロジェクトチームは変更や要件の変化による遅れなしに、一貫性を持って明確な製品を提供することができるのです。  

アジャイル方式には顧客も大きく関与しており、プロジェクトチームと顧客の両方が頻繁にプロセスのレビューを行います。 

アジャイルプロジェクトの実行には複数の異なるフレームワークが使用できます。より一般的なフレームワークには以下が含まれます：

• スクラム
• カンバン
• エクストリームプログラミング
• DSDM

アジャイル方式の詳細を説明するビデオ（約5分）は こちらからご覧ください。

アジャイル方式の歴史

ソースによって情報が異なりますが、アジャイル方式の歴史は 1990年代、, 1975年、またさらに1960年代にまで遡ります。しかしながら、2001年にリリースされたアジャイルソフトウェア開発のマニフェストの作成でアジャイルが定着してきたことには誰もが同意するでしょう。 

アジャイルマニフェストは ソフトウェア開発の新しい方法として2001年2月に作成され、本マニフェストは、優秀なソフトウェア開発者がユタ州に集まり、業界が抱える問題や潜在的なソリューションについて話し合って生まれました。 

当時集まったグループは、ソフトウェア業界が製品を迅速に市場に出すための新しい方法を開発する必要があることを理解していました。彼らの目標は、製品のコストへの影響やプロダクションスケジュールの遅れを最小限にとどめながら、製品やプロジェクトの変更を可能にする新規手法の開発でした。

プロジェクトを、シンプルにまた迅速に開発しテストが実施できる短期のイテレーションに分割することによって、最終成果物を待つ必要なしに顧客のレビューを行い、変更を取り入れることができます。ソフトウェア開発のアジャイル方式はこのようにして生まれたのです。

アジャイルマニフェストは本来、ソフトウェア開発の管理ソリューションとして草案されましたが、アジャイル方式はその後進化を続け、各業界や各種ビジネスでのプロジェクトにも利用されるようになりました。 

アジャイル の12の原則

アジャイルソフトウェア開発のマニフェストは、すべてのプロジェクトがフォローすべき12のアジャイル原則について説明しています。以下をご覧ください： 

1. 最優先事項は、価値あるソフトウェアを早く継続的に開発して顧客を満足させることです。アジャイル手法の第1の原則は、顧客がプロジェクト終了時に1つの製品を受け取るのではなく、プロジェクト全体を通してプロジェクト成果物やイテレーションを定期的に受け取るべきであると述べています。  
2. アジャイルのプロセスは開発後半であっても要件の変更を受け入れます。変更を利用して顧客の競争優位性を向上させる マニフェスト作成者が発見した問題の1つは、従来のプロジェクト管理では、最終段階で顧客から変更があった場合にその対応が困難なことです。本原則はアジャイルプロジェクトが最終段階での変更に適応し、遅れを最小限に抑える機能を有することを保証しています。 
3. 実用的なソフトウェアを数週間または数か月ごとに（短い方が好まれる）頻繁に納品するアジャイルプロジェクトはより頻繁で短期のタイムラインを特徴とし、実用的なソフトウェアを高速で納品します。1週間から4週間ごとのスプリントまたは間隔に分割され、各スプリントの終了時に製品を納品します。  
4. ビジネス関係者および開発者は、プロジェクト期間を通して日々協力する 本アジャイル原則では、プロジェクト関係者との定期的なコミュニケーションがプロジェクトの成功に不可欠であると述べており、プロジェクトチームと主要関係者間との日々のミーティングなどがこれに含まれています。   
5. やる気のある人材でプロジェクトを構築し、彼らが必要とする環境とサポートを提供し、作業を完了できるとスタッフを信用するアジャイルプロジェクト管理手法の主なコンセプトは、適切な場所に適切な人材を配置し、作業を順調にこなすために必要な自主性を与えることです。プロジェクトチームを作成する際は、企業内の職務や役職ではなく個人の能力をベースにすることが重要です。プロジェクトマネージャーはチームを細かく管理するのではなく、チームにやる気を与えサポートすることに重点を置かなければなりません。
6. 開発チームに、また開発チーム内で情報を伝達する最も効率的で効果的な方法は、直接会って話をすることです。 アジャイルマニフェストの作成者は、チームとプロジェクト関係者ができるだけ同じロケーションで作業をすることの重要性を確信しています。直接会ってコミュニケーションを取ることは、メールや電話などの他のオプションに比べてより効果的だからです。チームが同じロケーションで作業できない場合でも、言葉以外のジェスチャーなどでビデオコンファレンスが同程度の効果を発揮します。   
7. 実用的なソフトウェアはプロジェクト進行において最も重要です。アジャイル手法で重要とされるのは完成した実用的な成果物の提供であり、プロジェクト文書などの他の補足要件より常に優先されなければなりません。作業に費やした時間や経過時間などの他のメトリックスは、実用的な製品の納品に比べると重要ではありません。 
8. アジャイルプロセスは継続的な開発を促進します。スポンサーや開発者、およびユーザーは、一定のペースを無制限に保てなければなりません。 この原則によると、アジャイルプロジェクトはプロジェクトを通してそれぞれの反復サイクルおよびスプリントで一定のペースを保ちます。このように分割することで、実用的な製品を頻繁に納品する際に残業やスケジュールの再調整が必要になることもなく、チームが長期に渡って繰り返し使用できるサイクルを構築できます。 
9. 卓越した技術とすぐれたデザインに継続的に目を向けることにより、機敏性を向上アジャイルプロジェクトの最大の焦点は、時間をかけて一貫してエンド製品の改善を続け、進歩し続けることです。言い換えると、各イテレーションは前のイテレーションから常に向上を続け、チームが常に新規改革に向けて努力をするということです。 
10. 簡素化（実施する必要のない作業をできるだけ増やす）は不可欠です。アジャイルプロジェクトの目標は、必要最低限の作業で求められる製品を完成し、仕様を満たすことです。顧客にバリューを提供せず、プロジェクトの成果を向上させない文書やステップ、プロセス、作業は避けるか除外します。 
11. 自主性を持ったチームが提供する最高のアーキテクチャ、要件およびデザインアジャイルは、最高の成果と製品を提供するために、やる気があり自主性やスキルを持ったチームが必要であるという信念に基づいています。チームにはチームの結成と構成に必要な権限が与えられなければなりません。またメンバーには、管理者からの妨害なしに適切な方法でコラボレーションをとり革新を進めていくための自由が与えられなければならないのです。 
12. チームはより効果的な方法を定期的に反映し、状況に合わせて自身の行動を調整します。 優秀で自立性を持ったチームを確立するには、自身のスキルやプロセスの上達に重点を置き、継続的な成長と改善を目指すことが求められます。今後の改善方法などについて話し合いを持つなど、ここではチームのパフォーマンスの定期的な見直しが求められます。 

アジャイルプロジェクトマネジメントの利点

アジャイルプロジェクトマネジメントの利点は数多くありますが、以下のような組織やプロジェクトタイプに特に適しています：

• 時間の経過とともに進化するプロジェクトや、開始時に明確なスコープや要件を持たないプロジェクト
• テクノロジー業界のように急速に変化する環境に携わる組織 
• プロジェクト期間を通して、顧客や外部関係者と密に連携を取る作業が必要な組織
• プロセスや製品の改善に重点を置き、常に革新を目指す企業 
• 相互依存するタスクが多く、チームが密に協力し頻繁にコミュニケーションを取る必要のあるプロジェクト 
• 最終成果物を構築する前に試作品を作成する必要がある企業 
• 次のバージョンやドラフトに移行する前に、各製品のイテレーションについて関係者からの迅速なフィードバックが必要なプロジェクト

アジャイル方式の採用に見られる5つの大きな利点をご覧ください：

顧客との継続的なコミュニケーション

従来のプロジェクト管理手法では、プロジェクトの開始時と終了時にのみチームと顧客とコミュニケーションを取っていましたが、プロジェクト開始時に顧客の要件や期待が適切に把握されていない場合、また時の経過と共に変化した場合は、手遅れになるまでプロジェクトチームに情報が届かないことがあります。アジャイル方式であれば、全プロセスを通してコミュニケーションを取り、反復的に製品を納品することによって、チームが軌道を外れることはなく、完成した製品は顧客の要件を正確に満たしたものになります。  

順応する能力 

プロジェクトの途中で顧客からスコープ変更の要請があったとしたらどうでしょうか？プロジェクト管理の従来のアプローチの場合は変更は不可能であるか、プロジェクトのコストとスケジュールが大幅に増加します。アジャイル方式であれば、変更内容を次の反復に容易に追加でき、プロジェクトが大幅に進行している段階であっても最低限の努力で変更を取り入れることができます。   

より迅速な納品

アジャイルには継続的な開発アプローチが組み込まれているため、チームは常に実用的な製品を提供できます。顧客が完成品の納品を6ヶ月から12ヶ月待つのではなく、かなり短い間隔（通常は2週間から4週間ごと）でその時点のバージョンの製品を受領できるのです。 

低リスクのプロジェクト

チームは製品のバージョンを定期的に開発し、早い段階で顧客からのフィードバックを得ているため、プロジェクトが失敗するリスクを最小限にできます。 大きなプロジェクトをイテレーションに分割することで、リスクはイテレーションまたはドラフトのみの失敗ですみます。製品納品前の最終テストで問題を発見するのではなく、問題が大きくなる前に早い時点で見つけ、対応でき、問題が発覚する前やプロジェクトがキャンセルになる前に費やす時間やコストが少なくてすむのです。 

継続的な革新

アジャイルは、新製品や機能の革新および開発につながるコラボレーションと継続的改善をサポートします。チームを同じロケーションに配置し日々のミーティングを持つことで、自由に意見を出し合い、アイディアを生み出すことができるのです。アジャイルは、誰から出たものであってもベストのアイディアを採用するという「アイディア主義」をサポートしています。プロジェクトチーム、その他の関係者および顧客が、1つのチームとして機能や特性に関してアイディアを出すことができます。T 

アジャイルプロジェクトマネジメントを避けるべきとき

アジャイル方式には数多くの利点がありますが、すべてのプロジェクトや組織に適しているわけではありません。どのような場合にはアジャイルプロジェクト管理手法が適していないのでしょうか？またアジャイル方式の利点と欠点とは何でしょうか？

以下はアジャイル方式手法が適していない4つの例です：

プロジェクトの成果が安定しており十分理解されている場合 

アジャイルの目的は、プロジェクトを反復的なプロジェクト管理段階に分割して、プロジェクトの内容変更や不確実性にかかるコストを削減することです。不確実性が少なく変更の可能性が少ない場合には、アジャイル方式は最も効果的なアプローチではないでしょう。規制が厳しい業界やプロジェクトの多くの要件がすでに既知のものである場合は、反復プラニングや複数のドラフトを作成する必要はありません。   

プロジェクトは反復可能な成果物を作成する必要があります。 

定義では、プロジェクトは始まりと終わりのある「一時的な努力」であり、独自の製品、サービス、成果を構築するものでなければなりません。もし顧客が全く同じ家を5件建てるようリクエストし、あなたはそれぞれの家ごとに5つの異なるプロジェクトを作成し、それぞれプロジェクトチームを構成した場合はどうでしょうか？アジャイルを使用した場合、全く同一の家が5軒建つのではなく、それぞれ異なった家が5軒建ってしまいます。アジャイルの欠点の1つは再現性を求めるプロジェクトには利用できないことです。 

顧客がアジャイルを求めない場合  

アジャイルプロジェクトでは最終顧客との密なコミュニケーションが必要ですが、顧客によってはプロジェクトに費やす時間や能力、また要求がないこともあります。プロジェクトが低バリューであったりリスクが少ない場合は、顧客はプロジェクトの主なステージや最終的な納品時にのみ関与する従来のアプローチを求める可能性もあります。 

貴社がアジャイルをサポートできない場合  

貴社や貴チームがアジャイルを採用する準備ができていない場合、アジャイル方式サイクルの使用はプロジェクトにリスクを及ぼす可能性があります。 

アジャイルを利用する準備ができていない例を５つご紹介します：:

1. アジャイルが十分理解されていない場合。貴社や貴チームがアジャイルのトレーニングを受けていない、またその原則、慣行、フレームワークを十分理解していない場合は、アジャイルを使用する準備ができていません。 
2. 主な関係者が反対している。プロジェクトのスポンサーであっても、主要なチームメンバーであっても、アジャイル方式の採用に反対する者がいた場合、その問題を事前に解決しない限りアジャイル方式の採用は成功しません。 
3. 組織は日々のコラボレーションをサポートすることはできません。チームメンバー間の日々のコミュニケーションやオープンなコラボレーションに大きな障害がある場合は、アジャイルは最適なアプローチではありません。 
4. 会社組織はクロスファンクショナルチーム（部門横断型）をサポートすることはできません。アジャイルプロジェクトでは、プロジェクトの期間中、様々な部門のスタッフが顔を合わせ、コミュニケーションを取り、強力する必要があります。サイロ型組織の場合はアジャイルの使用は現実的ではありません。  
5. 多数文書の作成が必要な場合。貴社が大量の文書やテストレポートを求める場合は、アジャイルの採用にはコストがかかり過ぎるかもしれません。アジャイルの12の原則のうちの1つは、プロジェクトレポート、要件追跡メトリックスの削減に基づいています。

アジャイル vs スクラム

アジャイル方式は、アジャイルマニフェストに記されている4つのバリューと12のアジャイルソフトウェア開発原則に基づいてプロジェクトを計画する際の優良事例について説明しています。スクラムとアジャイルの比較をご覧になったことがあるかもしれません。スクラムは「明確に定義された目標に向けて、チームワーク、説明責任および反復的進歩を強調したプロジェクト管理のフレームワークである」と定義されています。言い換えると、スクラムは、これらのアジャイル原則、バリュー、優良事例の採用に使用できるフレームワークと言えます。  

アジャイルとスクラムの違いを理解するには、アジャイル方式をプロジェクト管理に採用するためのガイドラインがスクラムであると考えればよいでしょう。スクラムはアジャイルの考え方を首尾よく採用するために必要なルール、役割、イベント、ツール、中間生成物を提供します。 

アジャイルとスクラムの主な違いとは：プロジェクトで達成したいプロセスがアジャイルであり、スクラムはそれを達成するためのツールです。スクラムとアジャイルが同じ意味で使われる例を耳にされたことがあると思いますが、それはアジャイルの中で最も人気のあるフレームワークがスクラムだからです。しかしアジャイルプロジェクトの計画と実行に使用できるフレームワークはスクラムだけではありません。 

アジャイル vs ウォーターフォールプロジェクトマネジメント

アジャイル方式とウォーターフォールプロジェクト管理は、プロジェクト構築で人気のある2つの手法です。プロジェクトの計画および実行方法を決定する際はまずアジャイルとウォーターフォールプロジェクト管理を比較し、どちらが適しているかを評価します。 

ウォーターフォールはより伝統的なプロジェクト管理アプローチでより直線的なフローを使用します。プロジェクトを明確に定義し、開始時に期限が限定しており、成果物が明確に定義されたプロジェクトに適しています。言い換えると、プロジェクトの主な制約が理解され文書化されている場合は、ウォーターフォールが最適なオプションと言えるでしょう。 

アジャイルプロジェクト管理とウォーターフォールの違いを理解するためにはまず、以下に記されたウォーターフォールの主な原則をご覧ください： 

• すべての要件を前もって収集する
• すべての作業を、構造化され、順次的で、事前に定義されたフェーズで完了する 
• 製品開発および構築の終了後にのみテストを実施する

アジャイルはこれと対照的に、主な制約が十分理解されていないプロジェクトに対応できるよう構築されています。

先ほど述べたように、アジャイルの定義には反復的なアプローチと柔軟な対応が含まれています。プロジェクトをステージごとにまたは「スプリント」ごとに計画できます。プロジェクトの進捗に伴ってプランが成熟および進化し、より多くの情報を収集することができるのです。 

ウォーターフォールプロジェクト管理とアジャイルのどちらを利用するか決定する際は、最終成果物の成熟度と、プロジェクト開始時点でのプロジェクト成果と要件をどの程度理解しているかが最終的にその判断基準となります。

追加のアジャイルリソース

アジャイル方式について、またアジャイル方式を首尾よく実行する方法についてさらに掘り下げて考えるアジャイルリソースをご紹介します：