アジャイル開発が失敗するパターンと成功に導くための5つの心得

アジャイル開発が失敗するのはなぜ？

アジャイル開発とは、「イテレーション（Iteration：反復）」と呼ばれる短い開発期間の単位を採用し、各機能単位で「要件定義→設計→実装→テスト」のサイクルを繰り返すことで開発期間の短縮とリスクの軽減を図る開発モデルです。

従来のウォーターフォール開発に比べ効率的にシステム開発ができるため、多くの現場でアジャイル開発への挑戦が行われています。しかし、いざやってみたものの失敗に終わるケースも少なくありません。

アジャイル開発が失敗するのは、プロジェクトが「生き物」であることを忘れてしまったときです。木に竹をつないでも成長しないように、従来の開発姿勢に「アジャイルの良さそうなところ」を接ぎ木しようとしても上手くいきません。

アジャイル開発を成功させるには、プロジェクトに関わる組織全体の姿勢を、アジャイル開発に合ったものへと変えていかなければいけません。これが上手くできていないことが、日本でアジャイル開発が普及しない原因の1つです。

アジャイル開発の主なメリットは、「開発スピードが速い」「仕様変更に対応しやすい」「顧客に寄り添った開発ができる」ことです。仕様変更があっても各イテレーション内での影響に留まるほか、途中経過もわかりやすいため顧客とのコミュニケーションが取りやすいです。

一方で、「開発の方向性がブレやすい」「進捗管理が難しい」といったデメリットもあります。また、初めに要件を固める必要があり、正確性や安全性が求められる基幹システムの開発には向かないなど、向き不向きもあります。

アジャイル開発を検討する際には、こうした特徴もしっかりと把握しておく必要があります。

日本での普及率が低いとはいえ、DXが推進される中でアジャイル開発の需要は高まっています。需要の高さに比べてそれを担える人材の不足が課題になっており、アジャイル開発経験のあるプロジェクトマネージャー（PM）やスクラムマスターは価値の高い人材です。

プロジェクトマネージャーの年収は「マイナビエージェント職業別年収ランキング」での平均年収は670万円（※2023年4月執筆時点）、経済産業省2017年発表の「IT関連産業の給与等に関する実態調査結果」から近い職種のプロジェクトマネージャを参考にすると、平均年収891万円と分かりました。

国税庁2020年発表の「民間給与実態統計調査」における民間企業平均年収は433万円なので、プロジェクトマネージャーは一般平均年収よりもやや高めであることが分かります。

これは開発モデルや開発内容が考慮されていない数値なので、アジャイル開発を担えるPMやスクラムマスターとなればさらに年収が高いケースもあると予想されます。

【参考】：マイナビエージェント職業別年収ランキング ※【平均年収 調査対象者】2019年12月～2020年5月末までの間にマイナビエージェントサービスにご登録頂いた方 【参考】：IT関連産業における給与水準の実態① ~ 職種別（P7） 【参考】：民間給与実態統計調査-国税庁

アジャイル開発が失敗するときのパターン

アジャイル開発を導入しようとして失敗するパターンに共通しているのが、プロジェクトという生き物（有機体）への不適切な介入です。それには下記のようなパターンがあります。

経営トップ、あるいはクライアントであるユーザー企業から「このプロジェクトはアジャイルで」とオーダーされても、開発現場がすぐに順応することはできません。

特に、トップのアジャイル開発についての理解が不十分で、プロジェクトが機能する環境や支援を与えずに現場に「丸投げ」すると、成果を得る前に現場は枯死します。

トップがまず配慮すべき環境（土壌）とは、「契約と計画」を第一義とする従来のプロジェクトの枠組みをどのように、あるいはどこまでアジャイルに（柔軟に）するかということです。契約ありき・計画ありきの従来の価値観のまま、現場にアジャイル開発を要求するのは、砂漠で稲を育てようとするようなものです。

アジャイル開発を「開発手法の1つ」と考えたり、「従来のプロジェクトにあった問題のソリューション」と捉えたりするのも、失敗に終わるパターンの1つです。

アジャイル開発を最初に提唱した開発者たちが書いた有名な文書に「アジャイルソフトウェア開発宣言」があります。そこに記されているのが次の「宣言」です。

プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、

これは、アジャイル開発が根付いて育ち、実を結ぶ環境が従来のウォーターフォール開発とは全く異なることを示しています。つまり、アジャイル開発は単なる手法やソリューションではなく、1つの「ソフトウェア開発文化」なのです。

ウォーターフォール開発の文化にアジャイル開発の「良いところ」を部分的に取り入れようとするのは、喩えて言うなら、明治維新のときの日本が士農工商の身分差別を温存したまま文明開化をしようとするようなものでしょう。

プロジェクトマネージャにアジャイル開発の経験・理解が乏しい場合も、失敗の確率が高くなります。「プロセスやツールよりも個人と対話を」を重視するはずが、個人のモチベーションを高めることができず、クリエイティブなコミュニケーションを引き出すことができないからです。

「動くソフトウェア」の開発が予定通りに進まなかった場合、ユーザー企業の反感を買うかもしれません。「ドキュメントよりも動くソフトウェアを」とはいっても、品質管理部門がドキュメントも要求してくるかもしれません。

そんなときのPMやスクラムマスターの対応次第で、チームの士気が一気に低下する可能性があります。

初期の計画よりも変化への柔軟な対応を旨とするアジャイル開発では、ユーザー企業を巻き込んでプロジェクトを進めていく必要があります。

「アジャイル開発宣言」の補足文書である「アジャイル宣言の背後にある原則」で「ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません」と述べられているのも同じ意味です。

ユーザー企業や営業とのコミュニケーションがギクシャクしている中で、あるいは丸投げされた状態では「変化への対応」が困難で、アジャイル開発を成功させることはできません。

アジャイル開発を成功させる5つの心得

アジャイル開発を成功させるには、発注側と開発現場の双方に、アジャイル開発は1つの「有機的なソフトウェア開発文化」であるという認識が必要です。

失敗の多さに比例して「アジャイルは疲れる」「意味ない」「アジャイルは嫌い」といったネガティブな声も目立ちますが、失敗の本質を理解し正しい認識を持つことで、アジャイル開発のメリットを発揮した開発を行うことができます。

自社開発の場合は経営サイドが、委託開発の場合はユーザー企業が、アジャイル開発の本質をよく理解しようとすることが大切です。

「アジャイルなら短期間で開発できる」「低コストで開発が可能」などの部分的な理解、いいとこ取りの発想でアジャイル開発を指示しても上手くいきません。

RFP（提案依頼書）に「アジャイル開発で」と書くだけではなく、アジャイル開発を指示する場合は発注側が何をしなければならないのかを充分に理解しておく必要があります。

ビジネスである以上、アジャイル開発でも契約と計画は必須です。アジャイル開発の「契約交渉よりも顧客との協調を」「計画に従うことよりも変化への対応を」という原則に従うのは簡単ではありません。

しかし、ウォーターフォール開発でも初めから粒度の細かい計画を立てられるわけではなく、変化の対応の経験がないわけでもありません。どのようなプロジェクトにも「やってみなければ分らない」ことがあるからです。

より機敏に、柔軟に対応が可能な契約や計画をどのように立てるかに対する一義的な答えはなく、発注サイドと開発サイドが経験を積みながら相互理解を深めて行くしかありません。それによって、プロジェクトの内容に合わせて、契約と計画の柔軟性、変更許容度にある程度の目途をつけられるようになります。

PM、スクラムマスターにアジャイル開発の経験が豊富な人を据えることは、関係者との協議においても、開発チーム内のコミュニケーションにおいても、プロジェクトの成否を決める重要なポイントです。

「アジャイル宣言の背後にある原則」の1つに「意欲に満ちた人々に環境と支援を与え、仕事が無事終わるまで彼らを信頼します」と述べられています。ビジネス側と開発側をつないでアジャイル開発の原則を遂行するキーマンとなるのがPMです。

アジャイル開発においてはアジャイルモデルの本質を理解しているPMやスクラムマスターの存在が欠かせません。アジャイル開発の経験があるアジャイル人材は社会的にも需要が高いです。

経験を活かしPMなどへの転職を目指す際は、転職エージェントを利用して最適な現場を見つけましょう。

「原則」のもう1つに「ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません」とあります。

2週間ごとの「動くソフトウェア」のイテレーション（反復）が間に合わなかったと言ってビジネス側が怒る、開発側は2週間ごとの徹夜に疲弊するというよくある失敗パターンを回避するには、「日々一緒に働く」しかありません。

アジャイル開発で重視される「フェイス・トゥ・フェイスのコミュニケーション」とは、エンジニアたちのコミュニケーションだけではありません。ビジネス側の人間が不在の、開発者間だけのコミュニケーションでは議論が前に進まないことが多いのです。

アジャイル開発が初めてのチームの場合は、教育機会・訓練期間を設けて、マインドセットすることが肝要です。

その役を担うのはもちろんPMで、各プロセスにおけるシーンを想定した、経験に基づく具体的な説明が求められます。メンバーがそれぞれに持っているアジャイル開発についての知識やイメージを修正・統一しておく必要もあります。

「アジャイル開発宣言の背後にある原則」を読み直してみよう

上記の各所に紹介してきた「アジャイル開発宣言の背後にある原則」を、ここで改めて読み直してみましょう。下記の12の原則には、失敗を避けるために理解しておきたい「アジャイル開発の本質」が端的に示されています。

1.顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。 2.要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。 3.動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。 4.ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。 5.意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。 6.情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。 7.動くソフトウェアこそが進捗の最も重要な尺度です。 8.アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。 9.技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。 10.シンプルさ（ムダなく作れる量を最大限にすること）が本質です。 11.最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。 12.チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。

以上の「原則」には、エンジニアだけではコントロールできないものが多く含まれていますが、エンジニアなしにはどれも無意味であるとも言えます。これは、まさにアジャイル開発のプロジェクトが、関係者のすべてが有機的につながっている「生き物」であることを示しています。

アジャイル開発においては、どのエンジニアも「開発の駒」ではなく、「一緒に働く」「意欲に満ちた」「信頼される」人間なのです。

アジャイル開発の本質を理解して失敗を避けよう

アジャイル開発が失敗する根本的な原因は「アジャイル開発の本質を理解していないこと」です。この記事で紹介した失敗パターンと、アジャイル開発宣言に基づく成功の心得を心に留め、開発の失敗を避けましょう。

アジャイル開発の経験があるエンジニアは需要が高いです。プロジェクトを成功に導くことができれば、その経験を活かしてアジャイル開発におけるPMやスクラムマスターとして活躍する道も開けます。

アジャイル開発に携わりたい、経験を活かしてキャリアアップしたいという方は、転職活動を通じて最適な環境を探すことをおすすめします。

そこでぜひご活用いただきたいのがマイナビIT エージェントです。 

マイナビIT エージェントは、IT・Webエンジニア向けの無料の転職⽀援サービスです。

IT・Webエンジニアの転職事情に詳しいキャリアアドバイザーが、あなたのご経験やスキルをお伺いし、転職活動のプランをご提案致します。

アドバイザーは企業側の人事担当者と直接連携を取れますので、求人票に載っていない企業情報も確認することができます。残業時間や給与面など、働き方などをしっかり確認の上で応募企業を選んでいくのが良いでしょう。

・資格やプログラミングの勉強をしているけれど、企業が求めるレベルに達しているのかわからない ・スキルアップをして市場価値を上げていける企業の選び方を知りたい ・数多くあるITエンジニアの職種の中で、自分に向いている仕事は何か知りたい

こうした悩みを抱えていらっしゃる方は、まずは無料登録でキャリアカウンセリングをおすすめ致します。