はじめに
わたしが Google プロジェクト管理:プロフェッショナル認定証で得られた素晴らしい体験を、要点をまとめ小さく分割して、わかりやすく簡潔に紹介していきます。
興味があれば、ぜひ "Google プロジェクト管理:プロフェッショナル認定証" を受講してみてください。
アジャイルとウォーターフォールの違い〜概要
アジャイルはウォーターフォールの厳格な直線的プロセスに対抗して作られたものです。
| 開発手法 | 内容 |
|---|---|
| ウォーターフォール | 予測可能性を求め、変化を避けようとする。 |
| アジャイル | 世界、市場、ユーザーが不確実で予測不可能であるという現実を受け入れる。 |
例えば、顧客は機能Aが欲しいと言ったが、最終的な結果が出たとき、本当は機能Bが欲しかったと気づくかもしれない。
アジャイルは、この問題を解決するために、顧客からのフィードバックをより迅速に得て、顧客が本当に望んでいるものをチームが作る ことを目的としています。
アジャイルにおけるプロセス合理化
アジャイルの考え方で仕事をすることの一部は、より効率的に仕事をする方法を常に探し求めることです。私たちは、製品の品質や価値を下げることなく、プロセスを合理化する方法を見つけることで、これを実現しています。
- 合理化で重要なのは、 無駄を省く ことです。例えば、不必要な文書作成は無駄の一形態です。
- もうひとつの無駄は、何週間も何ヶ月もかけて機能を作り上げたのに、ユーザーやステークホルダーである 顧客がその機能を結局は気に入っていない ことが判明することです。
チームと関係者のコラボレーションを強化することで、この2つの無駄を削減または排除することができます。コラボレーションが増えれば、文書化が減り、製品に関するフィードバックも早くなる。
アジャイルとウォーターフォールの違い〜要件
ウォーターフォール
- プロジェクトのスコープと要件を列挙した製品要求文書が必要でしょう。
- 正式に承認されたプロジェクト計画が必要であり、これらの計画を作成し承認することだけを仕事とするチームを持つかもしれません。
- 変更管理委員会を設置し、要件に対する変更を管理するための正式で厳格なプロセスを設けることもできます。これらはすべて、クライアントやステークホルダーが望まないものを作らないようにチームを守るためのものであり、スコープクリープにつながる可能性のある変更を最小限に抑えることを目的としています。
- 正式に承認されたプロジェクト計画は、望ましい最終製品が分かっていて、理解されている場合にうまく機能します。例えば、義務付けられた規制に基づいて、明確な要件と目標を持つプロジェクトをリードするような場合です。しかし、そうでない場合、ウォーターフォール型のチームは、成果物全体を作り上げ、最終的に顧客がその成果物を気に入っていないことが後で分かるというリスクを負うことになります。
アジャイル
- アジャイルでは、要件はより動的なものとして扱われ、チームがフィードバックや新しい情報を受け取るにつれて変化することが期待されます。
- 通常、プロジェクトが始まると、最初の要件や機能のアイデアがありますが、その要件や機能のリストは、プロジェクトを通じて継続的に増加し、変化していきます。
- チームはステークホルダーと協力して要件に優先順位を付け、常に緊急性の高いもの、価値の高いものをリストの先頭に移動させます。
- そして、リストの順番を下げていき、反復して要件に取り組みます。リストを順に見ていくことで、チームは自分たちの仕事に対するフィードバックを迅速かつ頻繁に得ることができる。
- 各反復の終わりに、チームはフィードバックを得て、次に進む前に要件に必要な調整を行うことができます。
アジャイルとウォーターフォールの違い〜ドキュメント
ウォーターフォール
- フェーズ間のハンドオフやプロジェクト内の異なるチーム間のハンドオフが多いため、多くの文書化が必要です。
- 作業が大きな塊で行われるため、プロジェクトの各フェーズでより多くのドキュメントを残す必要があります。
アジャイル
- リアルタイムで、人と人との会話が重視されます。これは、文書がゼロになるということではなく、その形態が異なるだけです。
- 厳密な変更管理と承認プロセスを経た大きな公式文書の代わりに、 目的を達成するのに十分な詳細さを持つ短い文書 があります。これらの文書は、チームが仕事を成し遂げるために知っておくべきことにもっと焦点を当て、必要なときだけ書かれるものです。
アジャイルとウォーターフォールの違い〜成果物
ウォーターフォール
- 多くの場合、最後の最後まで成果物をリリースすることはありません。
- 最終的な成果物のリリースは、大きなイベントや重大発表のように感じられ、大騒ぎになり、非常に楽しく、エキサイティングなものになることが多いです。
アジャイル
- アジャイルも同じようにエキサイティングですが、リリースはより頻繁に行われます。そのため、各リリースはそれほど正式なお祝いではありませんが、同じようにエキサイティングなものになるように積み重ねられていきます。
- 新しい新興産業や市場など、プロジェクトに不確実性が多い場合、プロジェクトの成果物を着実にリリースすることで、アジャイルチームはフィードバックを得ながら学習することができます。定期的なフィードバックがなければ、チームは顧客が望んでいないものを提供してしまうかもしれない。
アジャイルとウォーターフォールを融合させる理由
アジャイル・プロジェクト管理は、同じフェーズとタスクをほとんど含みますが、やり方が違うだけです。この2つのアプローチには明確な違いがありますが、プロジェクトの種類やプロジェクトチームによっては、この2つのアプローチを組み合わせることが非常に有効な場合もあります 。
ここでは、アジャイルとウォーターフォールを融合させる理由をいくつか紹介します。
- ステークホルダー、顧客、スポンサーは、従来のアプローチやワークフローを使うことに抵抗がない、あるいは従来の成果物を提供する方が理解しやすく従いやすいが、プロジェクトチームはすでにスクラムを確立しており、継続を希望している場合。もしかしたら、承認のための大規模なRFPなど、特定の伝統的な作業プロセスを主張する制約があるかもしれない。
- あるいは、大規模なプロジェクトに参加しているベンダーの1社がすでに伝統的なアプローチに従っており、チーム間の統合には何らかの手法の混合が必要な場合もあります。
このような場合、プロジェクトマネージャーは、ウォーターフォールとアジャイルを融合させることで、プロジェクトの異なる部分を、プロジェクトの要件を満たしながら、他の部分やプロジェクト全体に悪影響を与えない方法で作業できるようにすることができます。
- 例えば、既存のベンダーは、アジャイルアプローチの実験に興味を持つ人もいるかもしれないが、全員ではない。この場合、早い段階でこれらのベンダーを議論に参加させ、賛同を得るとともに、懸念に対処することが望まれる。あるサービスは、コストにも気を配る必要があるので、従来の予算管理コントロールを使って、プログラムの予算がオーバーしないようにすることも必要です。
アジャイルとウォーターフォールを組み合わせることで、どちらか一方に固執することなく、より高い価値を付加できる場合があります。プロジェクトの様々な部分が、プロジェクト全体に悪影響を与えることなく、あるプロセスから恩恵を受けることができるのであれば、それを利用すればいいのです。