日本ではシステム開発の手法に、ウォータフォール型が用いられるのが一般的でしたが、計画から〜リリースまでの時間が長いため、激しく変化するビジネスに素早く対応できる開発手法が求められています。
そこで、ソフトウェアの開発手法として注目を浴びるのが「アジャイルソフトウェア開発」です。導入方法を誤れば、改善どころか改悪となってしまう危険性もある手法ですが、敵を知れば怖いものなし、「アジャイルソフトウェア開発」の全容を解説します。
- 仕様変更がある前提で、小さな開発を繰り返す開発手法
- 従来の開発手法では変化の激しいビジネスに対応できなくなっている
- 100%ではなく、リリースごとに最善を目指すのがアジャイル開発
- アジャイル型開発への理解が浅いと失敗するリスクが高い
目次
アジャイルソフトウェア開発とは
「アジャイルソフトウェア開発」は、近年導入が進むソフトウェア開発手法のひとつです。
アジャイル（agile）とは「迅速な」という意味です。アジャイルソフトウェア開発は、素早くそして軽快にソフトウェアを開発するために生まれ、後述する従来の計画駆動型のウォーターフォール開発手法などとは根底から異なる手法です。
アジャイルソフトウェア開発は、開発の途中で仕様や設計変更があることを前提としており、最初から綿密な計画は行いません。概要のみの計画に則り、小さな単位で開発を進めていくというやり方です。
アジャイルソフトウェア開発宣言とは
もともと、「軽量ソフトウェア開発手法」と呼ばれていたアジャイルソフトウェア開発の分野の専門家らは、「開発手法における重要な部分」をそれぞれが提唱していました。
2001年、アジャイルソフトウェア開発の分野で名高い17人が、「開発手法の核となる部分」を統合すべく、アメリカ合衆国のユタ州に一同に会し、議論しました。
このとき、統一見解として彼らがまとめた文書が「アジャイルソフトウェア開発宣言」(Manifesto for Agile Software Development) です。 このアジャイルソフトウェア開発宣言は、アジャイルソフトウェア開発とその原則を公式に定義した文書として、広く認められています。
現役エンジニアが現場のスキルを教えるスクールはこちら
アジャイルソフトウェア開発はなぜ生まれたのか、その歴史は
古くから、ウォーターフォール型開発が広く使われてきました。一方、ウォーターフォール型開発は、近年の変化の早いソフトウェア開発には適さない手法でもありました。前工程への後戻りが少ない手法がより求められるようになったためです。
そこで、変化に対応できる開発手法として、アジャイルソフトウェア開発が提唱されました。アジャイル型では、ソフトウェアの機能を細かく分割し、開発とテストというループを何度もすばやく繰り返すことにより、ソフトウェアを構築していきます。
このため、仕様変更やバグなどが発生したとしても、方向転換や修正もすばやく対応できるため、手戻りが少なく抑えられるようになりました。
他の開発手法との違いは
ウォーターフォール型開発
ウォーターフォール型開発は、アジャイルソフトウェア開発が提唱される前から、主流として用いられてきた開発手法です。
ウォーターフォールという手法は、その名のとおり「上から下に向けて一直線に落ちる」ように開発を進行させる手法で、あらかじめ配信日やプロジェクト完了期日を決定してから開発に着手します。
さらに、製品の最終仕様を開発の途中で変更することは想定しない手法であるため、緻密な事前計画ありきの開発手法です。
ウォーターフォール型開発は、ソフトウェア開発に限らず、機械製造業や宇宙産業などさまざまな種類の開発にも応用が効く開発手法でもあります。綿密な計画が立てられた長期のプロジェクトなどに向いています。
スクラム
スクラム開発は、アジャイル開発の手法のうちのひとつで、最も有名な手法として浸透しています。
スクラム開発は、開発を進めるためのフレームワークを指しており、ラグビーで肩を組んでチーム一丸となって前へと進むフォーメーション「スクラム」から命名されています。スクラムの名のとおり、チーム間のコミュニケーションを重視している点が特長です。
開発メンバーが自ら計画を立案し、工程ごとに開発の進捗に問題がないか、成果物の挙動が正しいか精査します。
そのため、メンバー間でのコミュニケーションが重要で、コミュニケーションが不足すると、各工程後のリリースが遅延したり、リリースしても機能に不備があったりといった問題が生じる可能性があります。
現役エンジニアが現場のスキルを教えるスクールはこちら
アジャイルソフトウェア開発を採用すべきタイミング
従来のウォーターフォール開発の場合には、最初に決定した設計や計画を重視し、計画どおりに開発を進行させるため、不具合が発生した場合、修正に要する手戻り工数が大きく、時間やコストが膨大に膨れ上がる恐れがありました。
一方、アジャイル開発のメリットは、不具合が発覚した際の、手戻りの工数が少ないことです。また、計画段階で綿密な仕様を決めないため、開発途中でユーザーとコミュニケーションを取りながらフィードバックを行い、確認をしながら進められます。
仕様変更や追加に対応可能なので、クライアントのニーズに最大限応えることができる点もメリットでしょう。
計画の段階で仕様変更が発生する可能性を想定できる場合や、開発途中でもクライアントのニーズに対応する必要がある場合、アジャイルソフトウェア開発を採用すると、そのメリットが最大化すると言えそうです。
アジャイルソフトウェア開発をチームに導入する場合の注意点
ウォーターフォール型は「当初の要求仕様は変更せず100％満たす」ことが前提であることに対し、アジャイル型では「必ずしも当初の要求仕様を100％満たす必要はなく、リリースごとに最善を目指す」という思想の違いがあります。
アジャイルソフトウェア開発を組織へ浸透させようとする場合、組織体制面での思考まで根本的に変えていく必要があります。
アジャイルソフトウェア開発モデルを組織に導入しようとする場合、ありがちな誤りとして、単純にウォーターフォール型開発から反復型開発などの手法に置き換えているだけで、アジャイルソフトウェア開発「らしき」ものに終始してしまっている事例が見受けられます。
この中途半端なアジャイルソフトウェア開発の導入では、組織体制や考え方は従来のウォーターフォール型を踏襲しているため、品質や納期が達成できなくなっているケースが発生しています。
問題の要因として以下の2つが挙げられます。
- クライアント側の経営層とユーザーのアジャイル型開発への理解が浅い
- 前スプリントで得られた課題や気づきを次のスプリントへフィードバックできていない
クライアント側の経営層とユーザーの理解について
短いサイクルで、クライアントに求められるソフトウェアのリリースを実現するためには、開発チームへの正確な要件のインプットや、必要なタイミングでの要求の見直しなど、クライアント側と開発チームとの密接なコミュニケーションやタイムリーな意思決定が行える態勢が必要です。
一方、失敗するケースでは、開発開始段階と終了段階（受け入れ）のみのコミュニケーションとなってしまい、開発側は要件の理解に十分な機会を得られないまま設計に着手せざるを得ない状況に追い込まれ、開発終了時に実装内容が要望と異なるなどの指摘が多数挙げられてしまうという事態が発生しています。
直接的な原因は、クライアントとのコミュニケーション不足などが考えられますが、クライアント側の態勢整備とアジャイル型開発に対する理解不足に根本の問題があります。
前スプリントで得られた課題や気づきのフィードバックについて
失敗する導入ケースでは、短い周期でウォーターフォール型プロセス（要求→開発→テスト）を繰り返すのみで、各スプリントで得られた課題や気づきを次のスプリントで改善するような、反復の改善活動は一切行われていませんでした。
アジャイルソフトウェア開発では反復して開発を回すだけではなく、タイムリーにリスクや課題を発見して解決することで、開発リスクを最小化するサイクルを実践することが重要となります。
「ポテパンキャンプ」では、最短 5ヶ月でエンジニアを目指せるカリュキュラムがあります。卒業後は、アジャイル開発を実践しているスタートアップ企業への求人もサポートしています。
まとめ
アジャイルソフトウェア開発は、スピーディーな開発かつ仕様変更に強い開発が実現しうる手法でありながら、その導入を誤ると改善どころか逆戻りしてしまう危険もはらむ開発手法です。リーダーや管理職のみでその導入を決定するのではなく、「チーム一丸」となってその導入の是非も検討する必要がありそうです。
また、すべてのソフトウェア開発がアジャイル開発に適しているわけではなく、従来のウォータフォール型が適しているケースもあるため、計画時に検討しておきましょう。
