IT業界のシステム開発にはいくつかの開発手法が存在します。その中でここ数年注目を集めているのが、「アジャイル開発」。素早く、機敏にという意味をもつアジャイルという言葉ですが、文字通り従来のウォーターフォール開発では考えられないような短納期でシステムやサービスを構築することが特徴です。そこでこれまで国内の開発案件で主流であったウォーターフォール開発とアジャイル開発の関係に迫ってみたいと思います。
アジャイル開発とは
アジャイル開発は、開発者とプロダクトオーナーがチームを組み、短期間で最低限の機能をリリース。このリリースを、開発者とプロダクトオーナーが議論を行い、仕様変更や追加機能を決定し、再び開発をするという手法です。この短期間のサイクルを何度も繰り返し、プロダクトの完成度を高めていきます。最低限の機能を繰り返しリリースするため、仕様変更にも対応しやすいとされています。
ウォーターフォール開発との違い
従来の開発手法、ウォーターフォール開発では、当初に要件を100％定義し、途中の仕様変更は別途という考え方でした。チーム内の役割も、顧客やプログラマーテスター、要件定義者などと別れており、それぞれの役割分担がはっきりしています。この手法では、当初から要件が固まっている場合、また変更がない場合には問題はありませんが、開発途中で要件が変更になったり、変更になった場合に追加開発となり、費用がかさむうえ、工数が大幅に膨らむというデメリットがありました。
一方、アジャイル開発では、最低限の機能リリースを繰り返すため、途中の仕様変更に対応しやすく、チーム一体となり全員でリリースを目指すため、属人化しづらく、チームワークの向上にもつながります。
アジャイル開発で耳にする「スクラム」とは
スクラムとはアジャイルの中でもさらにいくつかに分類された開発手法のひとつです。
アジャイル開発の代表的な手法として知られています。一言でいうならばアジャイル開発におけるフレームワークですね。
スクラムという言葉から連想される通り、主にチーム単位での動きについて定めている方法論です。
プロダクトオーナーがプロジェクトを管理し、スクラムマスターがスクラム内の調整やインシデント管理を、チームメンバーが実際の開発を行うという名目が存在し、このあたりはウォーターフォール開発と似ている点かもしれませんね。
しかしスクラムは役割を決めるものの、役割に従って明確にタスクや工程が分割されるわけではありません。
開発で発生するタスクは、チームメンバー全てが関与し、全員で取り組みます。
集団で行われる球技のように、ポジションは決まっているが全員でひとつのボールを追いかけ、ゴールへ運ぶというイメージが近いでしょう。
エンジニア・コンサルタントの高単価案件は、アサインナビがご紹介しています。
どんな開発プロジェクトがアジャイルに向いているのか？
ウォーターフォール開発のように上流、下流といった明確な工程の区別がないアジャイルですが、どんなタイプのプロジェクトがアジャイルにマッチしやすいのかを考えると、主に3つのタイプが浮かび上がります。
１．要件の全体像がはっきりしていないプロジェクト
要件が完全に固まっていないのにプロジェクトが発進するのはおかしいのではないかと感じるかもしれませんが、開発現場では良くあることですよね。
要件定義でとりあえず7割程度が固まってしまえば、実際の設計フェーズにGOサインが出るといったイメージです。
残り3割の要件はプロジェクトの状況を見ながら並行して固めていくので、短納期での納品やレビューを繰り返すアジャイルにマッチしています。
クライアントは出来上がった部分を確認しつつ、それらと整合性をとりながら残りの要件を決めていき、最終的な完成の形へと持っていくことができるからです。
２．顧客ビジネスの状況によって開発の優先度が変わる可能性のあるプロジェクト
クライアント自身もビジネスを取り巻く状況を予想しきれず、しかしシステムはどうしても近いうちに欲しいという場合、とりあえず開発に着手して部分的な納品を繰り返しながら、その境目で優先度を柔軟に変更することができます。
アジャイルでは2～3週間をひとつのサイクルとして考えており、その間隔で完成した部分から顧客へ届けられるので、顧客もビジネスの状況によって優先度を変更しやすいのです。
現代社会のように刻一刻とビジネスを取り巻く環境が変わる時代では、このように迅速でフレキシブルな開発手法が求められることがあります。
３．クライアントがチームの一員として参画してくれるプロジェクト
ウォーターフォール開発でも、顧客側の情報システム担当者がプロジェクトに参画し、重要な役割を負うことがありますよね。
ウォーターフォール開発ではマネジメント層とともにシステムの最終チェックを行い、経営層への橋渡しといった役割を果たすことが大半でしが、アジャイルではよりチームの一員としての色合いが強まります。
スクラムの役割でいえば「プロダクトオーナー」にあたる役割をクライアントが担うことにより、可視化が難しかったシステム開発の現状が手に取るようにわかるのです。
実際に手を動かすスクラムメンバーにとっても、チームの一員がすぐに要件を伝えてくれるために、より迅速で柔軟な開発ができるようになります。
エンジニア・コンサルタントの高単価案件は、アサインナビがご紹介しています。
アジャイル開発の問題点
アジャイル開発は、柔軟に対応できるメリットがある反面、デメリットももちろんあります。柔軟に対応できるからといって、何でも変更できるわけではありません。そのため、必ず前提条件を話し合っておく必要があります。根幹にかかわる部分に修正な要件が途中で出てきた場合、いくらアジャイル開発とはいえ対応できない場合も多いはず。これを回避するためには、発注側にもある程度のプログラミング等の知識が必要とされます。
また、契約や見積もりについても注意が必要です。
ウォーターフォール開発では、請負契約で納品をするため、リスク対応の為のバッファをとることが可能です。しかしアジャイルでは、当初に要件がすべて固まっていないので、バッファを見積もりに盛り込むとコスト高になる可能性があります。
アジャイル開発では、請負契約ではなく、時間生産の準委任契約などの方が向いていると言えそうです。
エンジニア・コンサルタントの高単価案件は、アサインナビがご紹介しています。
