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

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

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

### アジャイル開発の「型」だけ模倣しても上手くいかない

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

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

### アジャイル開発のメリットとデメリット

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

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

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

<center>[エンジニア転職を成功させるため<br/>ぜひ*『マイナビIT エージェント』*をご活用ください！](https://mynavi-agent.jp/it/?utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv12_2)</center>

### アジャイル人材の需要は高い

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

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

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

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

【参考】：[マイナビエージェント職業別年収ランキング](https://mynavi-agent.jp/helpful/income2020/category/it01/?utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv12_2)
※【平均年収 調査対象者】2019年12月～2020年5月末までの間にマイナビエージェントサービスにご登録頂いた方
【参考】：[IT関連産業における給与水準の実態① ~ 職種別（P7）](https://warp.da.ndl.go.jp/info:ndljp/pid/11623215/www.meti.go.jp/press/2017/08/20170821001/20170821001-1.pdf)
【参考】：[民間給与実態統計調査-国税庁](https://www.nta.go.jp/publication/statistics/kokuzeicho/minkan2020/pdf/002.pdf)

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

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

### トップが理解不足のまま「アジャイルで行こう」と指示する

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

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

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

### アジャイル開発を「手法」「ソリューション」と考える

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

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

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

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

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

### 指導者不在のままプロジェクトをスタートする

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

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

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

### ユーザー企業を巻き込むことができない

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

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

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

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

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

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

### 1.経営サイド、ユーザー企業がアジャイル開発の本質、文化を理解する

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

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

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

### 2.契約と計画の柔軟性、変更許容度にある程度の目途をつけておく

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

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

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

### 3.プロジェクトマネージャにアジャイル開発の経験がある人を招聘する

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

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

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

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

<center>[あなたに合った企業選びをサポート致します。<br/>エンジニア転職のご相談はぜひ<br/>*『マイナビIT エージェント』*へ！](https://mynavi-agent.jp/it/?utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv12_2)</center>

### 4.開発現場に丸投げしないでユーザー企業も一緒に働く

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

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

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

### 5.チームのメンバーを教育する機会、期間を設ける

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

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

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

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

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

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

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

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

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

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

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

そこでぜひご活用いただきたいのが[マイナビIT エージェント](https://mynavi-agent.jp/it/?utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv12_2)です。 

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

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

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

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

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

近年、プロジェクト開発において「これはアジャイル開発で行こう」と言われることが増えてきました。しかし、流行りに乗って安易に取り組んで失敗に終わるケースも少なくありません。本記事では、アジャイル開発が失敗するパターンと、成功に導くための心得について解説します。

アジャイル開発を便利な開発手法やソリューションと考えると失敗する

アジャイル開発を1つの開発文化と捉えて、その精神を理解することが成功の鍵

ビジネス側とエンジニアが一緒に働き、前向きに協力し合うことが肝要

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

## ウォーターフォールとアジャイルの違い

システムエンジニアを目指す上で必ず知っておくべき言葉は、システム開発における代表的な手法、ウォーターフォール・モデルとアジャイル・モデルです。**いずれのモデルも効率的なシステム開発には有効な手法ですが、両者の違いについて正しく理解しておく必要があります。

**この記事ではウォーターフォール開発とアジャイル開発について、それぞれの特徴と違い、それらが適したシステム開発について解説していきます。

## ウォーターフォール・モデルとは

ウォーターフォール・モデルは、システム開発の現場では最もポピュラーな開発手法です。**特に基幹系の開発や、大規模開発において主に使われています。**ここでは、ウォーターフォール・モデルの概要、適したシステム開発、向かないシステム開発についてそれぞれ見ていきましょう。

### ウォーターフォール・モデルの概要

ウォーターフォール（WaterFall）は英語で滝のことですが、滝のように上から下に向かって水が流れ落ちるように、上流工程から下流工程に向かって工程が進んでいくのが特徴です。

ウォーターフォール・モデルという言葉は、米国の科学者W.W.ロイス氏が1970年に発表した論文の内容が元だと言われていますが、「ウォーターフォール」という名称が使われたのは、TRW社に属するBellとThayerだとされています。

いずれにしても、ウォーターフォール・モデルは米国電気電子学会 （IEEE）で文書化され、誕生から半世紀を経て定着をしていきました。ウォーターフォール・モデルの大きな特徴としては、**前工程が完了しないと次の工程に進むことができないという点にあります。**

### ウォーターフォール・モデルの手順

ウォーターフォール・モデルはその名の通り、上から下に向かって進んでいきます。**ウォーターフォール・モデルでは大きな括りでとらえると、【要件定義】⇒【設計】⇒【製造】⇒【テスト】⇒【リリース】という工程で進んでいきます。**

要件定義工程ではユーザーやクライアントの要求を明確にし、その要求を実現するために必要な機能・要件・性能などを明らかにします。ここが曖昧であったり、要件を出し切れていなかったりすると、多くの場合はシステム開発に失敗します。

### ウォーターフォール・モデルが適したプロジェクト

ウォーターフォール・モデルが適したシステム開発業務とは、どのような開発なのでしょうか？それはシステム開発の途中で、**仕様変更を前提としない仕組みの開発です。**ウォーターフォールでは上から下に向かって工程が進むため、システム開発の途中で仕様変更が起きると、要件定義まで遡らなければなりません。

途中で仕様変更が少ないシステムには、基幹システムがあります。基幹システムでは要件や仕様が細かく決まっており、その仕様に従って着々と開発していきます。

逆に言えば、要件定義でミスを生じると、修正が非常に難しくなります。これまで基幹システムの開発に失敗しているケースは、そのほとんどが要件定義のミスによるものと考えられます。

### ウォーターフォール・モデルが適さないプロジェクト

ウォーターフォール・モデルが適さないシステム開発業務は、**システム開発の途中で仕様変更が起きやすいシステムの開発です。**代表的なものとしては、Webサービスの開発があります。

Webサービスではユーザビリティ（Usability）が重視されます。ユーザビリティ（Usability）には「使いやすさ」「可用性」「有用性」などの意味があり、それらは机上で設計するのは難しく、実際に作ったシステムをユーザーに見てもらい、触ってもらう必要があります。

そのため、仕様変更や手戻りが難しいウォーターフォール・モデルによる開発はあまり適しません。

アジャイル・モデルは、**柔軟性やスピードを優先したシステム開発の手法の1つで、現在の主流となっている手法です。**伝統的な開発手法であるウォーターフォール・モデルとよく比較されます。

ここでは、アジャイル・モデルの概要、アジャイル・モデルが適したシステム開発、適さないシステム開発についてそれぞれ見ていきましょう。

アジャイル（Agile）とは「素早い」を意味する英語です。イテレーション（Iteration）「反復の意味」 と呼ばれる短い開発期間の単位を採用して、**開発期間の短縮とリスクの軽減を目的とする開発手法です**。

モバイル分野などの日進月歩のスピードでテクノロジーが進化している分野、要件が途中で変更されるような分野との相性が良い方式です。

アジャイル・モデルでは小さな単位で計画・設計・実装・テストを繰り返すため、途中で問題が生じてもその影響がイテレーション内にとどまり、プロジェクト全体への影響が少ないというメリットがあります。

アジャイル・モデルと似た手法でスパイラル・モデルがあり混同しがちですが、スパイラル・モデルはプロトタイプ（試作）を提供しながらユーザーの要望に近づけ、品質向上を目指していく手法です。工数が膨れやすいため、潤沢な予算やリソースを確保できないと、とん挫するリスクがあります。

アジャイル開発の特徴、メリット・デメリット、DXとの関係など

### アジャイルソフトウェア宣言

アジャイル・モデル登場の発端は、「スクラム」や「XP」などの開発手法を提唱した技術者たちによって出された、**2001年に「アジャイルソフトウェア開発宣言」※にあります。**

日本で初めてアジャイル・モデルが採用されたのは、2000年代の半ば頃です。2009年には「アジャイルジャパン」※1が初めて開催され、毎年継続的に開催され、日本におけるアジャイル・モデルの普及に貢献しています。

*【参考】：※[アジャイルソフトウェア開発宣言](https://agilejapanexpo.com/)*

*【参考】：※1[Agile Japan EXPO ](https://agilemanifesto.org/iso/ja/manifesto.html)*

アジャイル開発宣言の内容を解説！開発に活かす道筋を探る

アジャイル・モデルでは、チーム単位で、**要件定義・設計・実装・テスト・リリースなどの開発工程を小さな機能の単位で繰り返して行います。**まさしく素早く（Agile）、ユーザーと一緒に機能のブラッシュアップを図りながら、システムを作り上げていくという手順で進めます。全ての機能を横断的に進めていくウォーターフォール・モデルとは異なり、比較的軽量で柔軟な開発手法です。

### アジャイル・モデルが適したプロジェクト

アジャイル・モデルが適するシステム開発業務は、ユーザーの要求にマッチしたシステムやサービスをスピーディにリリースすることを優先し、ブラッシュアップしていくようなシステム開発です。

つまり、**出来上がりの都度、ユーザーやクライアントの承認を得られたものから逐次リリースしていく方式です。**

### アジャイル・モデルが適さないプロジェクト

アジャイル・モデルが適さないシステム開発は、**「正確性や安全性が求められるシステム」です。**例えば、財務・会計システムなどの基幹システム構築では初めに要件を固める必要があります。

会計基準に従って詳細設計まで行うため、基本的に要件の変更はありません。また、企業会計は厳しい監査を受けるため、システム設計に関するドキュメントは必須です。

そのため、基幹システムの開発はウォーターフォール・モデルによる開発が一般的であり、ウォーターフォール・モデルは適さないという説が根強くあります。

### アジャイル・モデルの3つの開発手法

伝統的な開発手法であるウォーターフォール・モデルに代わり、要件変更や仕様変更に柔軟な対応が可能なアジャイル開発は主流になってきていますが、アジャイル・モデルにはいくつかの手法があります。ここでは、**アジャイル・モデルの代表的な手法について3つ紹介します。**

*1.スクラム*
アジャイル・モデルでは最も有名な手法です。ラグビーのスクラムが語源で、ラグビーのようにチームが一丸となり、コミュニケーションを重視しながらシステム開発を進めます。チームには以下の3つの役割を持つメンバーがいます。

▪プロダクト・オーナー：プロジェクトチーム全体の管理者
▪スクラム・マスター：開発のチームリーダー
▪開発者：システムの開発に携わるエンジニア

*2.エクストリーム・プログラミング（略称：XP）* 
エクストリーム・プログラミングはエンジニア、中でもプログラマー重視の開発手法です。ペアでコードを共有し、相互チェックと助け合いでプログラミングを進めます。これにより、仕様変更やエラーなどに柔軟かつ効率的に対応を行います。

*3.ユーザー機能駆動開発（略称：FDD）*
「顧客価値」にフォーカスした開発手法です。顧客の課題抽出、課題解決に向けた機能選定を重視し、プロジェクトマネジメントに重きを置いています。

また、イテレーションの期間は短く設定されるため、工程の手戻りのリスクが比較的大きく、進捗管理を定量的に行う必要があります。アジャイル・モデルの中ではウォーターフォール・モデルに近い手法とされています。

## メリット・デメリットを比較

ウォーターフォール・モデルとアジャイル・モデルにおいて重要なのは、それぞれの違い、メリット・デメリットを理解した上で、システム開発に最適な手法を選定できるようになることにあります。以下に、それぞれのメリット・デメリットについて見ていきましょう。

### ウォーターフォール・モデルのメリット・デメリット

ウォーターフォール・モデルの代表的なメリットとデメリットは以下の通りです。

*■メリット*
ウォーターフォール・モデルのメリットとしては、**開発計画や予算見積りが容易で、その精度が高いことです。**また、開発内容や必要な人材があらかじめ明確になっており、開発に必要な人材・スキル・リソース確保が計画的に行えるため、プロジェクトマネジメントが行いやすいモデルです。

*■デメリット*
ウォーターフォール・モデルでは、各工程を順番にこなしていきます。そのため、システム開発が大きく進捗した後に、新たな要件が追加されたり、大きな不具合が見つかったりすると、大きな手戻りが発生するリスクがあります。これによって開発に関わる時間とコストが当初計画から大きくぶれてしまいます。

### アジャイル・モデルのメリット・デメリット

続いて、アジャイル・モデルの代表的なメリットとデメリットを紹介します。

*■メリット*
アジャイル・モデルでは、反復（イテレーション）ごとに開発とリリースを行うため、**短期間でプロダクトやサービスをユーザーに提供できる点が大きなメリットです。**また独立した小さな単位で開発を進めるため、仕様変更や手戻りの影響が最小限で済む点もメリットです。

*■デメリット*
アジャイル・モデルはユーザーのニーズや要件に柔軟に対応できる反面、この柔軟さゆえにシステム開発が当初の方針から外れてしまったり、予算や全体スケジュールの管理がしにくかったりといったデメリットがあります。

アジャイル開発のメリット・デメリットや代表的な手法について解説！

## いずれの手法にも対応できるエンジニアを目指しましょう

ここまで、ウォーターフォール・モデルとアジャイル・モデルについて比較を交えながら紹介してきました。どちらが優れている・劣っているという訳ではなく、それぞれに向き不向き・一長一短があります。

**大切なことは、そのプロジェクトにどちらの手法が向いているかを正しく判断することです。**他に両モデルを併用したハイブリッド・モデルもありますので、選択肢として検討してください。

システムを開発する上でそれぞれのモデルについてより知識を深め、いかなるプロジェクトにも対応できるよう準備しておくことが求められます。当記事を参考に、今後もさらなる理解を深めましょう。

システム開発でよく使われる代表的な開発手法の「ウォーターフォール型」と「アジャイル型」の違いとは何なのでしょうか？それぞれの手法の意味・内容・システム開発での向き・不向き、メリット・デメリットを解説します。システムエンジニアを目指す方はぜひ理解を深めてください。

ウォーターフォール・モデルとアジャイル・モデル手法のそれぞれの特徴や違い

ウォーターフォール・モデルとアジャイル・モデルそれぞれに適したプロジェクト、不向きなプロジェクト

ウォーターフォール・モデルとアジャイル・モデルのメリット、デメリット

ウォーターフォール開発とアジャイル開発の違いは？メリット・デメリットも解説

「アジャイル開発宣言（アジャイルマニフェスト）」はいつ発表されたのでしょうか。それは2001年に17人のソフトウェア開発者のグループが発表しました。内容は従来型の開発手法に対するアンチテーゼ（反対表明）です。

### 従来型の開発手法に対する開発者たちに共通の問題意識

米国ユタ州のソルトレイクシティの郊外に集まった開発者たちは、ソフトウェアの開発手法に対する考え方はそれぞれ異なっていましたが、誰もが開発の現状には不満を抱いていました。

**開発者たちに共通した問題意識は、企業の論理やプロセスとソフトウェア開発のいわば「反りの悪さ」です。**

ソフトウェア開発が大規模になり、大きなプロジェクトが長期間かけて開発に取り組むようになるほど、この反りの悪さが目立つようになってきたと彼らは感じていました。具体的に言うと、「契約」と「計画・管理」を前提にする従来のビジネスプロセスは、時としてソフトウェア開発の障害になると感じたのです。

### アジャイル開発宣言を読んでみる

アジャイル開発宣言は、正式には「アジャイルソフトウェア開発宣言」で、下記のような全文223字（英文68word）の簡潔な「マニフェスト」です。

*アジャイルソフトウェア開発宣言*

私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。


プロセスやツールよりも*個人と対話を*、
包括的なドキュメントよりも*動くソフトウェアを*、
契約交渉よりも*顧客との協調を*、
計画に従うことよりも*変化への対応を*、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。

大規模なソフトウェア開発で重視されてきたプロセス・ドキュメント・契約・計画よりも、**チームの対話・ソフトウェアを動かしてみること・顧客満足・変化への対応という4つの価値をより重視すべきだというのです。**

【参考】[アジャイルソフトウェア開発宣言](https://agilemanifesto.org/iso/ja/manifesto.html)

## アジャイル開発宣言が提唱する開発姿勢

この「宣言」には、「アジャイル開発宣言の背景にある原則」という文書が付属していて、そこには彼らがソフトウェア開発において重要だと考える12の原則（開発姿勢）が列挙されています。

### ソフトウェア開発に求められる12の原則　

「アジャイル開発宣言の背景にある原則」を要約すると次のようになります。

1.*顧客満足を最優先*し、ソフトウェアを迅速・継続的に提供する
2.開発後期であっても*変更を歓迎*し、それによってクライアントの競争力を高める
3.動くソフトウェアをできるだけ*短い間隔でリリースする*
4.営業と開発は、*プロジェクト内で*日々一緒に働くべきである
5.意欲のある人を集めて*良い環境を提供し、プロジェクト終了まで支援*する
6.*フェイス・トゥ・フェイス*で話をし、情報を伝える
7.*動くソフトウェアこそが進捗の尺度*である
8.一定のペースを継続的に維持できる、*持続可能な開発プロセス*が求められる
9.技術的卓越性と優れた設計に対する*注意を怠らず、機敏に対応する*
10.*ムダなく作るシンプルさ*が開発の本質である
11.*自己組織的なチーム*から最良のアーキテクチャ（設計への発想）が生みだされる
12.*チームの効率を定期的に振り返り*、やり方を調整する

これらの原則を読んでまずイメージされるのは、革新的な製品を世に送り出したスタートアップ企業の少人数によるプロジェクトの生き生きとした開発の様子です。

この原則や開発姿勢を否定的にとらえる人はいないでしょうが、問題は**企業とベンダーが関わる（大規模）ソフトウェア開発で、この柔軟性・創造性・効率性が発揮できるのかということです。**

### 流行語としてのアジャイル開発　

IТエンジニアでアジャイル開発について聞いたことがない人はいないくらい、この言葉は大流行しています。しかし、日々のプロジェクトの業務でアジャイル開発の原則が取り入れられていると感じているエンジニアはごく少数派に留まるでしょう。

IТ企業もアジャイル開発の価値と原則に賛同するところは少なくありませんが、**それをソフトウェア開発戦略の中心に据えて本気で取り組んでいる企業は、大企業ではほとんど見当たらないと言ってもよい状況です。**

誰しもがアジャイル開発の原則を「ソフトウェア開発の1つの理想形」として受け入れますが、それを現在進行しているプロジェクトにどう結び付けていけばよいのか分からないのです。

### アジャイル開発は「ソリューション」ではない　

アジャイル開発が流行語の域をなかなか抜けられない理由は、**アジャイル開発を従来のプロジェクトに存在する問題点のソリューションと捉える間違いにあります。**

例えば、クライアント企業とベンダー企業が、プロジェクトにアジャイル開発の手法を取り入れようと話し合ってプロジェクトマネージャーに指示したとしても、それが上手くいくとは考えられません。

なぜなら、アジャイル開発は「契約」のあり方から考え直さないと機能しないからです。アジャイル開発の原則がソフトウェア開発に携わる人々の「マインドセット」であることは確かですが、*従来の契約・計画・管理の枠組みでエンジニアたちにマインドセットを求めても難しく、理不尽なダブルバインドになるだけです。*

そもそも**「ソフトウェア開発に携わる人々」の枠をプロジェクト内部に限定したのでは、アジャイル開発の原則は維持できません。**企業戦略を策定する経営トップ・営業部門・システム運営部門・ベンダー企業のトップなど、あらゆるステークホルダーを巻き込んだ検討や支援が必要となります。

### ダークアジャイルを生む土壌とは

アジャイル開発が流行することで、というよりアジャイル開発という「言葉」が流行することで出現したのが「ダークアジャイル」と呼ばれるものです。これは、**手っ取り早いアジャイル開発のマニュアルやそれをコーチする人たちを指し、それによって苦しめられたエンジニアたちは少なくありません。**

このようなダークアジャイルを生むのも、アジャイル開発をソリューションあるいは特効薬と考える管理サイドの誤解です。よく言われるような「大規模プロジェクトはウォーターフォール開発で、小規模プジェクトはアジャイル開発で」という考えは、*ソフトウェア開発に内在する問題の矮小化あるいはすり替え*に過ぎない場合があります。

## 開発関係者のすべてが「アジャイル開発の哲学」を理解する必要がある

アジャイル開発の原則を受け入れ、その良き成果を手に入れるには、広い意味での開発関係者のすべてが*アジャイル開発の原則を貫く哲学を理解する必要があります。*

*「宣言」で太字で強調されている個人と対話は「個人と対話する」という意味ではなく、「個人＆対話」です。*「プロセスやツールよりも個人が重要であり、対話が重要である」と述べられています。個人（Individuals）は、分割できない全人格としての人というニュアンスで、その個人間の相互作用（interactions）つまり対話が重要だというのです。

これは、**エンジニアをプロセスの中の「駒」として捉えるのではなく、あくまで「人」として捉えようということです。**それを示しているのが、12の原則にある次の言葉です。*「意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。」*

「このプロセスに従え」「このツールを使え」というのは管理には好都合ですが、そういう硬直した姿勢が、意欲に満ちた人々の創造性を棄損する恐れがあります。また、大規模プロジェクトの多重請負構造と「IТ土方」と呼ばれる単純作業の現状を、個人と対話の尊重の哲学にどう調和させるかは難しい問題ですが、アジャイル開発の実をあげるには目を背けるわけにはいかないテーマです。

### ドキュメントを揃えるよりも動くソフトウェアを

「要件定義書」「詳細設計書」「運用マニュアル」などのドキュメントをプロセスに従って作成・提出するのはシステム開発の常道であり、「仕事が進捗している」アリバイでもあります。

しかし、プロジェクトの目的は「ちゃんと動作するソフトウェアを作ること」で、ドキュメントを揃えることではなく、まして炎上したときのためのアリバイ作りでもありません。「宣言の背景にある原則」で述べられているように*「動くソフトウェアこそが進捗の最も重要な尺度」なのです。*

プロセスに従ってドキュメントを作成することに注意を払うあまりに、**ドキュメントの作り直しが必要なアイディアを無視するようなことがあっては本末転倒になります。**

### プロジェクトには計画の変化、契約の見直しがつきものであることを了解しよう

「宣言」にある「契約交渉よりも顧客との協調を」と「計画に従うことよりも変化への対応を」は密接に関係している、というより同じことの言い換えです。*「開発」に未知数があるのは自明で、初めの契約や計画の絶対化や固執は、実り多い成果への障害というしかありません。*

しかし、一方でシステム開発も企業の論理の外にあるものではなく、お金が絡む問題なので、契約・計画・管理を軽視することはできません。**「契約」「計画」「柔軟な対応」のトレードオフ関係を解決する簡単な処方箋はありませんが、アジャイル開発の原則が述べている次の言葉が解決への道を示唆しているのではないでしょうか。**

・ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
・要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。

## アジャイル開発のメリット・デメリット

ここでは、アジャイル開発のメリットとデメリットについて解説します。プロジェクトによってはアジャイル開発に向いていない場合があるため、すべてにアジャイル開発を取り入れるのは危険です。*メリットとデメリットを理解し、担当するプロジェクトに合わせて計画を立ててください。*

**アジャイル開発のメリットは、開発のスピードが早いことと臨機応変な対応が可能なことです。**従来の開発方法であるウォーターフォール開発の場合、あらかじめ決まっている計画や設計に沿って開発を進めます。そのため、スケジュールの後半で発生したトラブルが開発の前半での不備が原因の場合、大きな後戻りが発生します。

一方アジャイル開発の場合、機能単位で細かいスケジュールを組んでいるためトラブルが発生しても後戻りが少なく、すぐに修正が可能です。また、開発の途中で要件や仕様の変更があっても柔軟に対応できるため、顧客の要望に沿った開発ができます。

*さらに、アジャイル開発は最近注目されているDX（デジタルトランスフォーメーション）との相性も良いです。*DXとは日々変化するテクノロジーや人々の生活が変化するのに合わせて、ビジネスの形を変えていくこと。アジャイル開発では開発の途中での仕様・要求の変更を受け入れることができるため、顧客のニーズに合った開発方法とDXの組み合わせは最適だといえます。

**アジャイル開発は臨機応変な対応ができることがメリットですが、その分進捗状況の管理やリスケジュールの対応が困難な場合があります。**顧客の要望や開発途中で出てきた課題に細かく対応し過ぎて、納期に間に合わないといったことになっては本末転倒です。

*全体のスケジュールや納期も意識しつつ、その都度出てくる要望や課題に対応することが大事です。*また、顧客ニーズを何でも取り入れようとすると開発の方向性がブレてしまうこともあります。最終的な完成物のイメージを開発者や関係者と共有し、全員が同じ目標に向かって開発することを意識しましょう。

アジャイル開発には2つの手法があります。ここでは、アジャイル開発の手法である「スクラム」と「エクストリーム・プログラミング（XP）」について解説します。

アジャイル開発の記事（1ページ目）