PMP受験者が、一発合格のために必ず理解したいアジャイル入門とライフサイクルの選択をまとめました。
この記事は、PMP試験対策講座と演習問題解説を作成しながら作りました。
問題演習をする前に、必ず理解したいポイントをまとめたので、ぜひご一読ください。
アジャイル入門
アジャイル宣言とマインドセット
ソフトウェア業界の思想家リーダーたちは、2001年に「アジャイルソフトウェア開発宣言」を公表することでアジャイル運動を正式なものとしました。
私たちは、ソフトウェア開発の実践あるいは実践の手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。
「アジャイル宣言４つの価値」アジャイル実務ガイドから引用
これらの価値に由来する12の明確な原則。
「アジャイル宣言の背後にある12の原則」アジャイル実務ガイドから引用
- 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
- 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
- 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
- ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
- 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
- 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
- 動くソフトウェアこそが進歩の最も重要な尺度です。
- アジャイル・プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
- 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
- シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
- 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
- チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。
アジャイルアプローチと他アプローチの範囲
以下の図は、アジャイルの位置づけを示しています。アジャイルが、あらゆる種類のアプローチ・技法・フレームワーク・手法・実務慣行を総称する用語であることを示します。例えばアジャイルとカンバンは、リーンの一部であることを示しています。アジャイルとカンバンは、「価値に焦点」、「小さいバッチ・サイズ」、「ムダの排除」などのリーンが持つ概念を備えています。
一般に、アジャイルの価値と原則を満たすふたつの戦略があります。期待する結果を出すために意図的に設計され、実績が証明されている正式なアジャイル・アプローチを採用します。ふたつの戦略を一言で説明すると、1つ目は計画的なアプローチ方法、2つ目は柔軟なアプローチ方法です。1つずつ詳細に説明します。
- 期待する結果を出すために計画的,意図的に設計されたアプローチ
- プロジェクトの状況に適した方法で実務慣行を変更するアプローチ
第一の戦略は、期待する結果を出すために意図的に設計され、実績が証明されている正式なアジャイル・アプローチを採用することです。それを変更したりテーラリングする前に、アジャイル・アプローチを学習し理解するために時間をかけます。時期尚早で行き当たりばったりにテーラリングすると、このアプローチの効果は最小限になり、ベネフィットも制限されます。
第二の戦略は、プロジェクトの状況に適した方法で実務慣行を変更するアプローチです。コア・バリューや原則の進展を実現するために、プロジェクトの状況に適した方法でプロジェクトの状況に適した方法プロジェクトの実務慣行を変更します。タイムボックスを使用してフィーチャーを作成するか、または特定の技法を使って反復的にフィーチャーを洗練します。ひとつの大きなプロジェクトをいくつかのリリースに分割することを検討し、プロジェクトの成功に役立つ変更を実施します。変更は、組織の正式な実務慣行の一部である必要はありません。最終ゴールはアジャイルを行うこと自体ではなく、継続的に価値を顧客に提供し、よりよいビジネス成果を達成することです。
ステーシーマトリクス
ステーシーマトリクスは、ラルフ・ステーシー氏が発表したモデルであり、プロジェクトの不確実性に対する特性を示しています。不確実性が高い、というのは変更が高確率で発生したり、プロジェクトが複雑化しやすいことを示します。以下のマトリクスでは、縦軸に要求事項の不確実性を、横軸に技術の不確実性を表しています。このマトリクスは、開発アプローチを決定するときのガイドとなります。技術の不確実性が高いというのは、ITやAIなど先進の技術が刻一刻とめざましく更新されるようなことを指します。マトリクスに注目すると、単純な領域は予測型（従来型、ウォーターフォール）が向いており、煩雑な領域は適応型（アジャイル）が向いています。混沌の領域では、プロジェクトを行うべきではありません。
プロジェクトライフサイクルの選択
プロジェクトには多くの形態があり、さまざまなアプローチ・ライフサイクルの中から選択して推進します。プロジェクトチームは、成功率の高いアプローチを選択するために、アプローチごとの特徴を理解する必要があります。
プロジェクトライフサイクルの特性
PMIが発行するアジャイル実務ガイドでは、次のように定義される4つのライフサイクルを紹介しています。
- 予測型ライフサイクル
- 従来型のアプローチ。計画駆動型ともいう。ほとんどのことを事前に計画し、一回のパスで実行する。
- 反復型アプローチ
- 未完成の作業を改善し修正するために、作業のフィードバックができるようにするアプローチ。
- 漸進型(ぜんしんがた)ライフサイクル
- 顧客が直ちに使用できる完成した成果物を提供するアプローチ
- アジャイル型ライフサイクル
- 作業項目を洗練し頻繁にデリバリーする反復型かつ漸進型のアプローチ
| アプローチ | 要求事項 | アクティビティ | デリバリー | 目標 |
|---|---|---|---|---|
| 予測型 | 固定 | プロジェクト全体で1回実行 | 1回のデリバリー | コストのマネジメント |
| 反復型 | 動的 | 適切になるまで反復 | 1回のデリバリー | ソリューションの適切さ |
| 漸進型 | 動的 | 増分毎に1回実行 | 頻繁で小さなデリバリー | スピード |
| アジャイル型 | 動的 | 適切になるまで反復 | 頻繁で小さなデリバリー | 頻繁なデリバリーとフィードバックを適用した顧客価値 |
予測型のアプローチというのは、国内の製造業でも従来から採用されてきた方法です。しっかり計画して、予算の稟議をとおした後に、設計検証を経て一発で製品リリースする方法です。予算と期日を決めてから行うため、予算と期日を守りやすい反面、やりたいこと（要求事項）に沿えない可能性が高いといえます。なぜなら、計画段階ですべての要求事項を捉えることは難しく、試作やテストを行ったあとに潜在的なニーズに気が付くことも少なくありません。ニーズや技術の入れ替わりが激しいソフトウェアの業界では、予測型アプローチに限界が生じ、新しいアプローチが研究されました。それがアジャイル型のアプローチです。なお、予測型のソフトウェア開発で、軽い気持ちで度重なる変更を生じさせ、それがソフトウェア開発者の労働環境を悪くしたことから「デスマーチ」という言葉があります。
アジャイル型のアプローチは、欧米のソフトウェア開発現場で採用され、近年は日本でも流行りつつある方法です。成果を小出しにし、顧客が求める成果物に徐々に近づける方法です。開発側が抱く完成イメージと、顧客が抱く完成イメージとのギャップは生じるものだと考えており、顧客の意見を取り入れながら成果物を小出しします。アジャイル型のアプローチは、スクラムと呼ばれるチームを結成し、イテレーションと呼ばれる2週間程度の活動を繰り返し行います。各イテレーションの終了時にレトロスペクティブと呼ばれる振り返りを行い、課題解決をチームで共有した上で次回のイテレーションに臨みます。成果物は、ユーザーストーリーと呼ばれる顧客の要望リストのようなものが元となり、これをプロダクトオーナーが優先順位付けし、プロダクトバックログとしてストックします。チームは、プロダクトバックログを取り出し、成果物に変えて顧客からレビューをもらいます。顧客の要望事項が変わった場合は、適切にマネジメントしながら変更要求に応えます。具体的にはユーザーストーリーとプロダクトバックログを変更する形で変更に応えます。アジャイル型は変更要求に柔軟に対応し、適切な成果物が得られるまで継続させるアプローチ手法です。
これらの予測型とアジャイル型の間に、反復型と漸進型があります。反復型は予測型に近く、漸進型はアジャイル型に近いです。反復型は、成果物を1回だけ提供します。ソリューションの適切さを重視しており、一度で確実に要求に応えることを重視します。アクティビティ、つまり試作やテストを繰り返し行い、成果物は一発です。建設や機械構造物など、何回も成果物を作れないが失敗は許されない場合にマッチします。その一方、漸進型は、頻繁で小さな成果物の提供を続けます。スピードを重視しており、一度のアクティビティ（試作やテスト）で、サッと納品します。アプリのアップデートなど、ある程度失敗が許されるが早く市場投入したい場面にマッチします。
COMMENT