スクラムを選ぶ理由：定義されたプロセスと経験的なプロセス

計画と意思決定の合理的なツールを適用できる、かなり単純で比較的予測可能なプロジェクトがあります。より複雑または予測不可能な他のプロジェクトでは、自己組織化とイノベーションにさらに依存する別のアプローチが必要です。

ほとんどのソフトウェア開発プロジェクトは、人、要件、テクノロジーの3つの要素が収束しているため、本質的に複雑で予測不可能であると考えられています。プロジェクトの提供と管理に使用されるさまざまなアプローチは、プロセス制御モデルとプロジェクトの複雑さのコンテキストでより簡単に理解できます。

定義されたプロセス—従来の計画主導のアプローチ

従来、プロジェクトが開始されると、要件パッケージが作成され、「サインオフ」されます。プロジェクトマネージャーは、このサインオフによって一連の要件が固定され、計画を開始できると想定しています。プロジェクトマネージャーは、要件を完了するのにかかる時間を見積もり、プロジェクト計画を作成します。計画では、プロジェクトが特定の日付までに終了することを予測しており、その日付が顧客に通知されます。

このアプローチの根本的な欠陥は、すべてを推進する計画が、要件が固定されており、変更されないという仮定に基づいていることです。経験から、これは決して当てはまらないことがわかっています。要件が修正されることはありません—常に変化します。要件が変更されると、計画が影響を受けます。その結果、完了日も変更する必要があります。残念ながら、多くの場合、それは不可能であり、チームはコミットした日付までに納品する必要があります。これは、大きな危機が発生し、プロジェクトが制御不能になり始めたときです。

経験的プロセス—アジャイルバリュードリブンアプローチ

価値主導のアジャイルアプローチは、考え方全体を切り替える経験論 に基づいて います。最初から、事前に存在する要件はすべて修正されておらず、変更されることを前提としています。

アジャイルの考え方は、特定の日付までに納品する必要があることも前提としています。このアプローチは時間とリソースを修正し、要件を未定のままにします。私たちにとって、このアプローチは、ソフトウェアを作成するという現実により近いものです。今では、価値主導の概念全体が完全に理にかなっています。すべての要件を満たすことができるかどうかわからない一定の時間があれば（要件が変わるため、要件を完了するために必要な時間が変わるため）、自然な反応は、要件を優先して最初に完了することです。顧客に最大の価値を付加するもの。

「納期までに完了していない要件はどうですか？」とお考えかもしれません。これが、価値主導型のアプローチを使用する理由です。すべての要件が納期までに完了するわけではないという事実を認めます。重要な質問は、顧客に価値を提供するシステムをサポートするのに十分な機能を提供したかどうかです。

ソフトウェアプロジェクトの失敗率

2015  CHAOSレポートは、 StandishGroup によって最近リリースされました 。CHAOSレポートは、1994年から毎年発行されており、ソフトウェア開発業界の状況のスナップショットです。今年のレポートでは、小さな拡張機能から大規模なシステムリエンジニアリングの実装に至るまで、世界中の50,000件のプロジェクトを調査しました。今年のレポートには、以前の調査でカバーされたいくつかの追加の要因を見て、成功の定義が強化されています。

結果は、ソフトウェア開発プロジェクトから成功する結果を達成するために行われるべき作業がまだあることを示しています。この表は、成功要因の新しい定義を使用して、過去5年間のプロジェクトの結果をまとめたものです（時間通りに、予算内で、満足のいく結果が得られます）。

近年のアジャイル開発手法の採用により、アジャイルプロジェクトと従来のウォーターフォールプロジェクトの間でプロジェクトの成果を比較することが可能になりました。この表に示すように、すべてのプロジェクトサイズで、アジャイルアプローチにより、プロジェクトはより成功し、完全な失敗は少なくなりました。

従来のアプローチの問題は何ですか？

従来の計画ベースのアプローチは、それ自体に欠陥はありません。今日のソフトウェア業界には適していません。計画ベースのアプローチは、元々、建設業界に端を発する従来のプロジェクト管理の概念に基づいていました。建設業界では、計画ベースのアプローチが適しています。要件である青写真は固定されており、建物の建設中に変更されることはおそらくありません。鋼製の柱を作ったり、コンクリートを流し込んだりするのにかかる時間を見積もることができます。

従来の計画ベースのアプローチが建設業界に適しているがソフトウェア業界には適していない理由は、経験的システムの制御方法（ソフトウェア開発など）と定義済みシステムの制御方法（建設や製造など）の違いに帰着します。 ）。次の表は、定義されたプロセスの特性と経験的なプロセスの特性の違いを示しています。

表を読んだ後、ソフトウェア開発は間違いなく経験的なプロセスであり、定義されたプロセスではないことが簡単にわかります。問題は、私たちが定義されたプロセスとして何年にもわたってソフトウェア開発に取り組んできたということです—そしてそのアプローチは機能しません。

参考文献

1. スタンディッシュグループ2015カオスレポート
2. 不完全な言葉で敏捷になる— Greg Smith＆Ahmed Sidky

その他のスクラムリーディング

• 3分でスクラム
• 5つのスクラム値は何ですか？
• スクラムの進化とは何ですか？
• 従来のプロジェクト管理とアジャイルプロジェクト管理
• スクラムをマスターするのが難しいのはなぜですか？
• スクラムの速度とは何ですか？
• アジャイルとは何ですか？スクラムとは何ですか？