前回までは、ウォーターフォール型開発モデルを中心に学習してきました。今回は、アジャイル型開発モデルを学習しましょう。
▼ウォーターフォール型の解説は以下の記事へ↓↓
1.ウォーターフォール型モデルの開発の難しさ
アジャイル型の説明に入る前に、ウォーターフォール型モデルの開発の難しさについて復習します。ウォーターフォール型の開発の難しさの代表的なものに、以下の4つが挙げられます。
①開発初期に仕様を確定させなければならい
②開発途中の仕様変更にめっぽう弱い
③顧客の真の要求を把握することが難しい
④正確な見積もりが難しい
順番に解説します。
①開発初期に仕様を確定させなければならい
ウォーターフォール型の開発の特徴として、基本的に開発初期の要件定義の段階で、システムで実現するすべての機能について決めればなりません。システム開発は通常1年以上の長期の開発期間になることが多いです。そのため、現代の目まぐるしく変わるニーズ、製品、トレンド、また法律等を考えると、開発初期に決めた要求に沿った機能を数年後にリリースすると、時代遅れのソフトウェアとなる可能性があります。開発初期からリリースまでの間に要求事項がズレてくる。これは、ウォーターフォール型の欠点の1つといえます。
②開発途中の仕様変更にめっぽう弱い
ウォーターフォール型は、開発途中の仕様変更にめっぽう弱いです。例えば、開発が順調に進んだのちに下流工程で仕様変更の要望があった場合、上流工程である要件定義からやり直さなければなりません。その結果、これまで作成した設計書やプログラム、テスト実装などをもう一度やり直す必要があります。工程が進めば進むほど、多くの手戻り工数が発生し、予算オーバーや納期遅延のリスクが高まります。ウォーターフォール型ではこの点を注意したうえで、慎重に工程を進めていかなければなりません。
③顧客の真の要求を把握することが難しい
「顧客が本当に必要だったもの」という風刺画をご存知でしょうか。この図ではシステム開発の実態をよく表しています。「➊顧客が説明した要件」に対して、「❷顧客が本当に必要だったもの」はズレることはシステム開発の業界ではあるあるなことです。どうしてそのようなことが発生するのか。顧客は要件定義の際に、自分の頭の中のイメージで物事を要求しており、実際に動くソフトウェアを体験してみなければ、本当に必要だったものを見極めることは非常に難しいためです。真の要求はシステム完成後に実際に使ってみて初めて判明します。
出典:https://dic.nicovideo.jp/a/顧客が本当に必要だったもの
④正確な見積もりが難しい
基本的にシステム開発は1年以上の長期間で開発が行われます。開発期間が長い、開発規模も大きい、顧客の要求も曖昧、開発中にどのような問題が発生するのか見当もつかない。このような状態で工数・予算・リスクを正確に見積もることはかなり難しいです。その結果、当初の予定通りに進まないことが多く、納期遅延・予算オーバー・残業過多・低品質はよく見られる現象です。
2.QCDを考える
ところで、システム開発におけるQCDという考えはご存知でしょうか?QCDの「Q」は「Quality(品質)」、「C」は「Cost(費用)」、「D」は「Delivery(納期)」のことを指します。システム開発においては、このQCDを守ることが基本です。高品質な製品を、無駄な費用を発生させず、約束した期日までに、仕上げて納品する。これが、システム開発で求められる3要素です。
システム開発をQCDで考える際は、以下の式が成り立ちます。
実現範囲 = 品質(Q) × 費用(C) × 納期(D)
システム開発において何か問題が発生した場合、当初の予定と同じ実現範囲(仕様)を達成させるためには、品質(Q)を落とすか、費用(C)を上げるか、納期(D)を遅らせるか、の3択になるということが表現されます。
ウォーターフォール型のQCDを考えてみましょう。ウォーターフォール型は、開発初期に仕様をすべて確定することから、実現範囲が固定(決まった)された開発手法となります。「実現範囲」を固定するということは、残りの「品質(Q)」と「費用(C)」と「納期(D)」がブレる(変動する)こととなります。その結果、「1.ウォーターフォール型モデルの開発の難しさ」で説明したような事象が発生してしまいます。
アジャイル型では、ウォーターフォール型の反対の考え方となります。アジャイル型のQCDは、「品質(Q)」と「費用(C)」と「納期(D)」の方を固定(決める)します。あらかじめ決めておいてた「品質(Q)」と「費用(C)」と「納期(D)」の範囲内で「実現範囲」を調整することで開発を進めていきます。
例えば、上記の図のように、1サイクルにつき、「品質(Q)」=「中程度」、「費用(C)」=「1千万」、「納期(D)」=「1カ月」と決めたとします。その範囲内で実現できる仕様を「実現範囲」と定めます。アジャイル型では、その決められた実現範囲を1サイクルごとに開発・リリースしていくことで、システムを完成に近づけていきます。
この考え方により、アジャイル型はウォーターフォール型の弱点を補うことができます。「①開発初期に仕様を確定させなければならい」という点については、サイクルごとに実現範囲(仕様)を決めていくので問題ありません。「②開発途中の仕様変更にめっぽう弱い」については、そもそも短期間のサイクルで開発・リリースを繰り返すため仕様変更にも強いです。「③顧客の真の要求を把握することが難しい」についても、段階的にリリースしながら顧客の要求を見定めることができ、「④正確な見積もりが難しい」点についても、ウォーターフォール型に比べて、見積対象が開発規模も期間も小さいため、比較的見積りやすいです。
3.アジャイル型開発モデル
ここで一度アジャイル型開発モデルを整理します。アジャイル型は、1ヶ月以内の反復期間(スプリント)を定義し、その期間内で、製造・リリースできる機能を選定し、開発を繰り返します。機能を段階的にリリースするため、開発初期には、顧客ニーズが最も高い機能からを選定して開発します。このように、アジャイル型では、開発初期時点で、全ての仕様を決める必要がなく、開発を進めながら、顧客の意見を取り入れ、作りたい機能を調整することができるというメリットがあります。まさに、顧客ニーズが目まぐるしく変わる現代に適した開発手法といえます。
4.スクラム
アジャイル型開発モデルの代表的なものとして、「スクラム」があります。今回は、「スクラム」について解説します。まずは、「スクラム」の全体像を見ていきましょう。
①プロジェクトビジョンの共有(インセプションデッキの作成)
プロジェクトビジョンを共有するために、インセプションデッキというものを作成します。インセプションとは、これから進めようとするプロジェクトの背景や目的、方向性、価値観の認識を合わせることです。インセプションデッキはその認識合わせをした内容を端的にドキュメントに纏めたものです。
②業務全体像の理解(ユーザーストーリーマッピング)
ウォーターフォール型開発モデルの要求・要件定義に対応する工程です。ユーザーストーリーマッピングで業務の全体像を表します。ユーザーストーリーマッピングとは、システムの全体像を整理し、実現したい項目に優先順位をつけたプロダクトバックログを作成するための方法です。プロダクトバックログとは、ウォーターフォール型開発モデルの要件一覧のようなものです。アジャイル型では、開発初期から完璧な要件一覧(プロダクトバックログ)をつくるのではなく、開発を進めながら、必要となった(となりそうな)要件を柔軟に追加しながら対応します。プロダクトバックログの要件には、優先順位をつけます。アジャイル型ではプロダクトバックログで定めた、優先度の高い要件から開発を進めます。
③スプリント計画
スプリント計画は、プロダクトバックログから、今回のスプリントで実現したいこと(ストーリ)を選び、発注者および開発者内で合意します。そして、そのストーリをスプリントで実装できるレベルの作業(タスク)に落とし込みます。このプロダクトバックログから、タスクレベルに落とし込んだ一覧のことを、スプリントバックログと呼びます。
④スプリント
スプリントでは、スプリントで合意したストーリについて、設計・製造・テストを行います。スプリントの期間は主に1週間~4週間(1カ月)です。
⑤デイリースクラム
デイリースクラムは、開発者全員で行う簡単なミーテイングです。毎朝15分以内で、「昨日やったこと」、「今日やること」、「困っていること」などを全体で共有します。
⑥スプリントレビュー
スプリントで作成した成果物を、発注者側と確認し、スプリント計画で計画したストーリについての完了確認を行います。成果物は実際に動作するものであるため、このレビューにより改善点などが見えてきます。
⑦ふりかえり
今回のスプリントでよかった点や課題点を開発者全員でふりかえります。
5.さいごに
概要レベルでありますが、アジャイル型開発モデルの説明は以上です。開発モデルをきちんと理解したうえで業務に臨むと、視野がぐっと広がります。本記事があなたに業務に活かせていただければ幸いです。
参考書籍
書籍名:ずっと受けたかったソフトウェアエンジニアリングの新人研修 第3版 エンジニアになったら押さえておきたい基礎知識
著者名:飯村 結香子 (著), 大森 久美子 (著), 西原 琢夫 (著),川添雄彦 (監修)出版社:翔泳社; 第1版 (2018/12/12)
https://www.amazon.co.jp/dp/4798157562/ref=cm_sw_r_tw_dp_ZDEE6BZMHRYYVJNWPFSZ @amazonJPより