https://dev.classmethod.jp/articles/the-essence-of-scrum-that-i-want-to-explain-to-customers/
みなさんこんにちは、CX事業本部Delivery部のかみとです。
受託開発のプロジェクトをスクラムで始める際、アジャイル開発やスクラムのフレームワークに対する認識がお客様とベンダー間で一致していることが望ましいのですが、アジャイルやスクラムの経験有無、理解度の違いなどによって異なった認識のままプロジェクトが開始してしまうことで、後々プロジェクトの進行に影響を及ぼしてしまうことがあると思います。
これがただの小さな認識のズレで、プロジェクト進めていく中で調整可能なものであればいいのですが、そもそもの前提が違うくらいの大きな認識相違となってしまった場合、プロジェクトとしてはもちろんお客様との信頼関係にも悪影響を与えかねません。
そういった状況を避けるためにも、なるべくプロジェクト開始前にお客様との間でアジャイル開発にまつわる、よくある誤解を解消しておくのはとても大切なことだと思います。
このブログでは、スクラムでプロジェクトを始める際に、私が最初にお客様に伝えておきたいと思っているスクラムのエッセンスの部分を整理してみました。
スクラムガイドには載っていないけど、実際のプロジェクトでよくある誤解やアジャイルあるあるの内容が中心となっています。
別の言い方をすれば、どこかで誰かが言ったことの寄せ集めの情報とも言えます。すでにこの手の話は耳にタコだよという方はそっ閉じいただければと思います。
最近こそあまり見かけることはなくなったと思いますが、「アジャイル導入によりコスト削減」や「納期の大幅な短縮に成功」といった記事のように、アジャイルをコスト対策の手段という見方で取り上げられることがあったように思います。
アジャイルは最小限で価値のある単位で開発し、短期間で動くものを早くリリースすることには違いありませんが、それは「早くリリースしてフィードバックをもらい、その結果を素早く適用する」ことが目的なので、その本質は「変化に適応する」という部分にあります。
プロダクトの初期リリースは実用最小限の製品（MVP）としてリリースするため、プロダクト初期リリースは比較的早い段階で行うことになりますが、この初期リリースはあくまでもMVPであり、当初の要件の全てを盛り込んだものではありません。
アジャイル開発においてはプロダクトは下図のように小さい単位で価値提供を行い、変化しながら進むこととなります。したがって、最終的にトータルコストで見るとウォーターフォール開発のような従来型の開発手法の予算より最終的にコストが上がっている可能性も否定できません。
逆に要件や機能詳細が最初から明確で、かつ要件変更が発生しないようなケースでは、ウォーターフォール開発のほうが効率的といえるでしょう。
しかし、ソフトウェア開発のあらゆる場面では、当初予定していた要件が不要になることは往々にしてあり得ます。
例えば以下のようなケースなどが考えられます。