---

プロジェクトを理解する前に、全体を計画しなければならなかった？意外な発見があるかもしれません！

スクラムを使う前、私たちのチームは、顧客の要求を満たさない、まったく見当違いのソフトウェアやハードウェア製品を作り、届けていました。

仕事の中で、外部の企業から、ソフトウェア製品やサービスをどう作るべきかを押し付けられる時期がありました。

能力成熟度モデル（CMM）, ISO 9001:2008 などの派生的な仕組みは、正しいソフトウェアを正しい方法で作れるよう、会社を支援しようとしました。

どの程度成功したかは、本書の対象ではありません。本書は、ほとんど使われなくなった手順を批判するのではなく、スクラムのプロセスと枠組みの利点に注目します。

ただし、スクラムによるソフトウェアエンジニアリング以前の、これらのプロセス改善の枠組みが、段階的な方法を勧めていたことには触れておく必要があります。私たちは、その段階的な開発方法を、 ウォーターフォール型ソフトウェアエンジニアリングモデル.

と呼びました。このモデルでは、各プロジェクトは要求分析から始まり、顧客が必要とし、望むものを理解しようとしました。

次に要求を設計し、実装し、テストで検証し、本番環境で保守しました。そして、ソフトウェアエンジニアリングのライフサイクルの終わりに到達するはずでした。

しかし、現実はそのとおりには進みませんでした！

ウォーターフォール手法とスクラムの枠組み

従来のウォーターフォール型ソフトウェア開発モデルの工程

ウォーターフォールモデルのある段階で予期しない遅れが起こると、その後の段階への悪影響を避けられませんでした。

研究によると、調査対象となった失敗したソフトウェアプロジェクトの80%を超えるもので、ウォーターフォール手法の利用が、失敗の重要な要因の一つでした。 なぜでしょうか？

左の図のように、ウォーターフォールでは、異なる段階が厳密に順番に並びます。前の段階が終わるまで、次は始められません。戻ることは、多くの場合、苦痛と費用を伴い、チームをいら立たせ、時間もかかります。

プロジェクトの時間軸は最初に計画します。リリース可能なプロダクトを届けるのは、最後だけです。一つの段階が遅れると、ほかのすべての段階も遅れます。

これを避けるため、ウォーターフォールのプロジェクトマネージャーは、通常、あらゆる可能性を事前に予測しようとします。最初期の段階で、要求をできる限り細かく、完全に定義しようとするのです。しかし、初期の要求定義は難しいことが多く、多くの要求はプロジェクトの途中で変わります。または、変えるべきになります。

研究では、より大規模で複雑なプロジェクトでは、最初の要求の約60%が、途中で変わることが示されています。定義どおりに実装しても、顧客が実際には必要としないものもあります。その実装に費やす時間とお金は、顧客により大きな付加価値をもたらす機能に使えたかもしれません。

段階に分けることで、プロジェクトマネージャーは各段階を別々に見積もることになります。しかし、実際には、その多くは独立していません。互いに関わり、並行して進みます。

たとえば、テストが始まる前に開発が完了したと考えるのは、合理的ではありません。それでも、残念ながら、ウォーターフォールはまさにそのように進められていました。

ウォーターフォールによるソフトウェア開発は、小規模で単純なプロジェクトには使えます。 しかし、大規模で複雑なプロジェクトでは、この方法は無謀とまでは言わなくても、非常に危険です。スクラムによる開発とデリバリーの枠組みより費用がかかることが多く、常に効率が劣ります。

スクラム以前の私たちは、スクラムのスキルを持つ専門家の導きもなく、チーム間でソフトウェアを行ったり来たりさせていました。そのため、 仕事は官僚的で、複雑で、生産性の低いものになりました.

。最終的に、製品だけでなく、従業員の士気と組織の使命に取り組む姿勢も、大きく損なわれました。