はじめに

数年前から耳にするようになった「アジャイル開発」という言葉。

短いサイクルを何度も繰り返す開発手法だというのは知っているけれど、具体的にはどんな特徴があるのか？それに、どんなメリットがあるんだろう？

それに、他の開発手法とはどう違うのか。

ここでは、そんな疑問にお答えすべく、アジャイル開発の詳細やその他の開発手法との違いを徹底解説します。

また、アジャイル開発で陥りやすい失敗とその対策についても見てみましょう。


アジャイル開発とは？

アジャイル開発では、ソフトウェアの全体開発工程を1週間から1ヶ月程度の短い開発期間に区切り、その期間に1つの機能を開発します。

この区切られた開発期間を「イテレーション」と呼び、これを反復して機能を追加していくのがアジャイル開発の最大の特徴です。

機能をどの順番で開発していくかの優先順位付けが重要となるため、開発側とプロジェクト側が常に綿密なコミュニケーションを取る必要があります。


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

次に、アジャイル開発では具体的にどのようなメリットがあるのかを見ていきましょう。


開発工数が削減できる

従来の開発手法は、極端に言えば最初に1回だけ打ち合わせをし、決定した機能をひたすら最後まで開発して納品するような形態です。

アジャイル開発ではこれを何回かに分けるだけの違いなのですが、開発工数が削減されます。

打ち合わせの回数が増える分、工数が増えそうなところですが、これは何故でしょうか。

最初に決めた機能や仕様が、全くそのままユーザの希望通りのものとなっていれば従来手法の方が工数は少なくなるでしょう。

しかし、実際にそのようなことはあり得ず、必ず手戻りが発生します。そしてこの手戻りの量は開発済みのソフトの規模が大きいほど膨大になるのです。

中には、致命的な修正点があり計り知れない設計変更が必要になるケースもあります。実は、この苦労を取り除こうと考え出されたのがアジャイル開発なのです。

重大な変更や手戻りが発生しないよう、こまめに打ち合わせし顧客と認識合わせをしていくことで最終的な工数が圧倒的に少なくなります。


顧客ニーズに合致しやすい

イテレーションのメリットは、開発工程削減だけではありません。

短いスパンで打ち合わせを行うことで、完成品の仕様に顧客側の想定からズレがあれば、修正を入れて顧客ニーズに最大限応じられます。

また、早い段階から具体的なモノを見ることで顧客側でも希望仕様の再確認がしやすくなるので、具体的な注文をしやすくなるのです。

これにより、具現化されていなかった顧客のニーズまで引き出して実現することができます。


コストが予算内に着地しやすい

従来の開発手法では打ち合わせから納品までに長い時間が開いてしまうため、完成品の仕様に関して大きな認識のズレが発生する可能性がありました。

いざ納品してみると、顧客が思い描いていたものと全く違っていて、大規模な修正が必要となることもあります。

この修正は開発側からしても想定外のため、追加請求を行わざるを得ず、当初予算からコストが大幅アップということもあったようです。

アジャイル開発では何度も打ち合わせと軌道修正を重ねるため、このような手戻りが発生せず、予算内に収めやすいというメリットがあります。


文書作成量が削減できる

先述のように、従来手法では後から仕様やコストについて認識のズレが発生しやすいため、必ず「言った」「言わない」のトラブルが起こります。

これを防ぐため、打ち合わせでは必ず膨大な資料を残しておく必要がありました。

アジャイル開発では、1度の打ち合わせで検討するのは1つの機能だけなので、内容がシンプル化され、残すべき文書も少なく済みます。


アジャイル開発に分類される開発手段

アジャイル開発の具体的な手法はさらにいくつかに分類されます。

一般的なのは下記の開発手法です。次項からは各手法について詳細に説明します。

  • スクラム開発
  • ユーザー機能駆動開発(FDD)
  • エクストリーム・プログラミング開発(XP)


スクラム開発

アジャイル開発の中で最も一般的に採用されている手法です。

プロジェクトに参画するメンバー全員が一丸となって、計画立案から進捗確認、最後の動作確認までを行うためスクラム開発と呼ばれます。

コミュニケーションを重視し、メンバー1人1人が進捗状況やビジネスへの影響を考えながら作業を進めるので、全体マネジメントが容易です。

また、一気通貫でプロジェクトを見渡せるので、視野が広がりやすく全員の成長にもつながります。

なお、スクラム開発では区切られた開発期間のことを「イテレーション」ではなく「スプリント」と呼ぶので、覚えておきましょう。

＜関連記事＞
スクラム開発とは？従来のアジャイル開発との違いを解説！失敗しないためのポイントやスクラム開発向けの管理ツールも紹介


ユーザー機能駆動開発(FDD)

英語では「Feature Driven Development」といい、頭文字を取ってFDDとも呼ばれます。

通常のアジャイル開発では主に開発側視点で機能を区切りますが、FDDでは顧客にとっての機能価値(Feature)を観点として区切ります。

これにより、実際に顧客側が機能の挙動を確認できる単位で開発が進められるため、そのビジネス価値を判断しやすくなるのがメリットです。


エクストリーム・プログラミング開発(XP)

エクストリーム・プログラミング(Extreme Programming)の頭文字を取って「XP」とも呼ばれます。

当初計画の遵守よりも、途中で発生した仕様変更やアイディアを最重要視する開発手法です。

ビジネス意義や後々のソフトウェア品質向上に重きを置いて、仕様変更に躊躇をしない「勇気」を持った各個人の姿勢が重視されます。

このため、比較的少人数の開発チームで、ビジネス要求が刻一刻変化しやすい案件に最適です。


アジャイル開発に分類されない他の開発手段

ここで、アジャイル開発ではないが有名な他の開発手法を紹介します。アジャイル開発との違いを確認しましょう。


ウォーターフォール開発

ウォーターフォール開発は、一般的な従来手法のことをを指していると考えて問題ありません。

つまり、大きな要件定義やゴールを定め、そこに向かって開発を進めます。また、各工程のタスクが完了するまで次の工程には進みません。

マイルストンがはっきりしているためスケジュールを引きやすいというメリットがありますが、大きな仕様変更に弱いというのがデメリットです。

水がいったん上から下へ流れてしまったら元に戻せないのと同じように、一度進むと後戻りができないことからこう名付けられました。

＜関連記事＞
ウォーターフォール・モデルを徹底解説！メリットと好まれるケース、アジャイル・モデルとの違いとは？時代遅れといわれる理由も紹介


プロトタイプ開発

プロトタイプは試作品を意味します。

その名の通り、顧客からある程度の要望を吸い出してから開発者が一定の試作品を作り、そこから細かい要件定義に進む開発手法です。

顧客の希望仕様がはっきりしていない場合に、動くものを見せられるためそれを通してニーズを具現化しやすいというメリットがあります。

動くものを見せるという点で、アジャイル開発のユーザー機能駆動開発(FDD)に似ていますが、FDDは機能ごと、プロトタイプ開発は全体試作なのが違いです。


スパイラル開発

要件定義・設計・コーディング・テスト・評価を1サイクルとして、1サイクルごとに顧客フィードバックを受けて再度サイクルを回していく開発手法です。

低レベルな完成品からスタートし、次のサイクルで一段上の完成品に近づけていくことから螺旋階段に例えられ、スパイラル開発と呼ばれます。

フィードバックの機会を多く持ち、顧客との認識ズレや手戻りを減らすという点ではアジャイル開発に似ていますが、区切り方が相違点です。

アジャイル開発の区切りは小さな機能ごとなのに対し、スパイラル開発では全体を開発してしまいます。

完成レベルを落として開発するとはいえ、全体開発ではどうしても開発期間が長くなり、手戻りはアジャイル開発よりも多いです。

＜関連記事＞
スパイラルモデルとは？アジャイル開発など他のモデルとの違いを確認し解説します！導入におけるメリットとは？


アジャイル開発の失敗事例

他の開発手法と比較しても万能のように見えるアジャイル開発ですが、失敗事例もあります。


納期の遅延

先述の通り、アジャイル開発のメリットの1つは「顧客ニーズに最大限寄り添えること」です。

このイメージが先行し、中には「なんでも要望を聞いてもらえる」と勘違いしている顧客も大勢います。

想定以上の仕様変更や機能追加を受けてしまい、当初の納期に間に合わなくなってしまうことがあるようです。


予算の大幅オーバー

同じように顧客からの無理な要望を飲んでしまったばかりに、当初の予算では賄いきれず、コストアップとなることがあります。

多少ならば顧客の想定内で収まり了承してもらえるケースもあるようですが、大抵の場合予算オーバーは受け入れ難いものです。

顧客側の無理な要望が原因であるにも関わらず、何度も打ち合わせをしていたのに突然コストアップとはどういうことか、と説明を求められかねません。


終わらない要件定義

「要件定義をまとめたいのに、なかなか顧客が意見を言ってくれない…」という経験はありませんか？

実際に、顧客の中には「ざっくりとした要望を伝えれば、あとはエンジニアがなんとかしてくれるだろう」と過度な期待をしている方もいらっしゃいます。

期待してもらえるのはありがたいことですが、明確に言語化されない事柄を具現化するのは不可能ですし、後々のトラブルにもつながりかねません。

特にアジャイル開発の場合は「後から言ってもなんとかなるでしょう？」と思われがちで、なかなか進まないことが多いようです。


失敗しないための対策方法

それでは、このような失敗をしないためには、どのような対策を取るべきでしょうか。


進捗確認会議を定期開催

納期遅延を防ぐためには、顧客と開発チーム双方を含めた進捗確認会議を定期的に開催しましょう。

顧客が無理な要望を出すのも、それを受け入れてしまうのも、互いが最新の正確な進捗状況を把握していないからです。

進捗確認を定期的に行えば、顧客側も「こんな要望を出してしまったら、遅れ気味のプロジェクトをさらに遅らせてしまう」と理解できます。

もしくは「遅れてしまうのは目に見えているが、それを飲んででもこの変更は入れて欲しい」と考えた上で要望を出すでしょう。

こうすることで、早い段階で納期遅延を防いだり、あるいは納期が遅延することに対してのコンセンサスを取ることができます。


工数規模の認識合わせをこまめに行う

予算オーバーの原因は基本的に想定外の工数追加であるため、先ほどの納期遅延対策と同様の対策で解消することができます。

しかし、顧客と開発側の間で「この機能を実装するのにかかる工数はどのくらいなのか？」の認識がズレているとうまくいきません。

顧客が「ちょっとここを変えるだけなんだから、すぐできるでしょう？」と思っても実際は膨大な変更量となる可能性もあります。

逆に、「これも追加して欲しいけど、大変そうだな…」と諦められてしまいそうな機能が、意外とすぐできることもありますね。

予め、顧客が要望を出してきそうな追加機能や変更内容についてはかかる工数の説明ができるように準備しておくと良いでしょう。


提案力を持つ

打ち合わせの機会をたくさん持っても要件定義がなかなか進まないのは、顧客がなかなか要望を言わないからだと決めつけていませんか？

もちろん、顧客がスラスラと必要な要件を述べてくださるに越したことはありません。しかし、最初に全ての機能を決定し言語化するのは非常に難しいのです。

なるべくこちらからも顧客が答えやすい質問を用意し、このプロジェクトで解決したい問題は何なのか、何を成し遂げたいのか、早期に理解しましょう。

そして「この問題を解決するために、この機能を持たせるのはどうでしょうか？」と具体的な提案をするのです。

人は何もないところから議論を開始するよりも、何か具体的な事象があった方が話しやすいといいます。

顧客が要件を具現化する手助けができるよう、こちらからも寄り添う姿勢が必要です。


まとめ

アジャイル開発について、具体的な開発手法やそのメリット、他の開発手法との違いについて説明しました。

失敗事例もありますが、基本的にはコミュニケーションを綿密に行っていけば十分に対策できます。

開発期間を細かく区切って顧客やチームとの打ち合わせを綿密に行えるのがアジャイル開発の最大のメリットです。

せっかくの機会を無駄にしないよう、コミュニケーションの質も大切にしていきましょう。