アジャイル開発失敗の原因とは

ここ数年、お客様から良く相談されるようになった話題として、
「アジャイル開発にチャレンジしたけど頓挫してしまった」とか、
「アジャイル開発中のシステムがいつまでたっても使えるレベルにならない」といった、
アジャイル型の開発手法にまつわる問題や悩みがあります。

もちろんアジャイル開発の成功ケースも数え切れない程ありますから、このような問題が出てくるのはそれだけアジャイルが世の中に浸透してきた結果とも言えるでしょう。

要件定義、設計、製造・・・と、システム全体を計画的・不可逆的に開発していくウォーターフォール型に対し、自律的・反復的に少しずつ開発していくアジャイル型の手法は、「ビジネスの変化に柔軟に対応でき、また高い生産性をもたらすもの」であり、「硬直的な旧来のウォーターフォール型の開発手法はやがて廃れ、すべてアジャイルに置き換わる」と考えている方も多いと思います。

そのような優れた手法にも関わらず、失敗してしまうケースがあるのはなぜなのでしょうか？

弘中 伸典のシステム企画一問一答シリーズ、今回はシステム企画において開発手法をどのように検討すべきか、考えてみましょう。

Qなぜアジャイル開発で失敗するの？

様々な要因はあるのですが、ほとんどの失敗ケースに見られる根本的な原因はほぼ一つです。
いきなりですが、今回の答え。

A使いどころを間違えているから

まず、「これまでウォーターフォール型で開発していたすべてのシステムは、アジャイル型の開発手法に変えることによって短期間・低コストで開発できる」という捉え方が誤解なのです（ある意味では誤解ではなく正解と言えますが・・・詳細は後述します）。

例えば、製造業において生産管理システムを再構築するケース。

これにアジャイル型の手法を適用すべきなのでしょうか？

異論も多いかと承知はしていますが、私の答えは「NO」です。

まず、業務もシステムもすでに確立されたものが存在し、またビジネスロジックや管理する情報が頻繁に変化する業務領域でもないため、最初にシステムに求められる要件や仕様をキッチリ固めることが可能なはずです。
また、生産管理システムは50%の完成度では業務に使用することができません。基本的に100%完成して初めて意味を成すものです。
従って、アジャイル型でも開発は可能ですが、ウォーターフォール型で全体を計画的に開発した方が生産性は高くなるはずです（もし生産性が低いのであれば、それは開発手法の問題ではなく、業務を分析して要件や仕様を固めるスキルの欠如か、使いもしないドキュメントを大量に作成させるといったPMの計画力不足の可能性が高いと思われます）。

例えるなら、料理を一人前ずつ作るのがアジャイル、全員分まとめて作るのがウォーターフォールだとして、「カレー100人分を作る」ことが最初に分かっているなら、ウォーターフォールでまとめて作った方が効率的なのは当然ですよね。

では、アジャイルが向いているケースとは。

例えば、「お店の新メニューとして、春の草原を吹き抜ける風をイメージしたおでんを開発して欲しい！」と言われた場合。正解が分からないので何回も作って試食して貰い、徐々に完成させていく必要があります。試食のために毎回100人分を作っていては時間とお金の無駄ですよね。

システムの例で言えば、ネット販売のwebサイトなど。
実際に利用者に使ってもらって操作性などのフィードバックを貰わないことには、最初から自分たちで100%正解が分かりません。それならば、50%の出来で公開し、意見を反映させながら徐々に完成させていく方が効率的であり、アジャイル型の手法を適用すべき、ということになります。

つまり、それぞれ向き不向きがある訳で。
「これからはアジャイルが主流だから！」とか言われ、あまり深く考えずに採用してしまうことは危険なのです。

そもそも。
「アジャイル開発」とは、何かアジャイルのマニュアルのようなものがあって単純にそれに従えば良いというものではなく、本質的には「生産性を高めるために自分たちで知恵を絞って仕事を工夫すること」なのです。先人たちが知恵を絞った結果としての「ベストプラクティス」は存在しますが、あくまで「知恵を絞る出発点」として捉える必要があります。

極論すれば、自分たちで知恵を絞って考え抜いたところ、結果的に洗練度を高めたウォーターフォール型手法に行き着いた、というのもある意味でアジャイル開発と言えます（「これまでウォーターフォール型で開発していたすべてのシステムは、アジャイル型の開発手法に変えることによって短期間・低コストで開発できる」が正解と言ったのは、このためです。なんの工夫もなされていないウォーターフォールが非効率になりがちなのは間違いありません）。

「アジャイル or ウォーターフォール」という単純な視点ではなく、業務やシステムの特性を見極めながら、開発の進め方を自ら考え工夫するということが重要であること、開発手法検討の際のご参考にしていただければ幸いです。

それではまた次回！