アジャイル開発の概要
主要なプロセスモデルの一つとして、これまで述べてきた伝統的な「ウォーターフォール」の他に、後発の「アジャイル開発」というものが存在する。
「アジャイル（agile）」を日本語に翻訳すると「迅速」という意味になるが、「アジャイル開発」はその名の通り迅速に開発を行うことに特徴があるプロセスモデルであり、短い期間（数週間～1ヶ月程度）毎にユーザにとって重要な機能から順番にリリースを行う、というものである。
一つの開発期間は「スプリント」や「イテレーション」と呼ばれ、計画・設計・実装・テストがこの期間の間に行われる。
このように開発を行うことで、ユーザは少ない期間・コストで重要な機能を使用することができるようになる。また、ユーザの要求の変更にもいち早く対応することができるようになる。
仮に、リリースした機能がユーザに響くものでなかったとしても、その問題に少ない期間・コストで気付き、軌道修正することができます。
上記の利点により、重厚長大なウォーターフォールモデルを採用した場合に比べて、ビジネス上で優位に立つことができるようになる、とされている。
しかし、アジャイル開発はユーザの要望が頻繁に変わる小規模システムの開発には向くものの、要望が固定されているミッションクリティカルな大規模システムの開発には向かないとされている。アジャイル開発ではシステムを小出しで開発するため、システム全体の整合性や最終的なプロダクトの品質を上手く管理することができないと、システムの品質が低下する問題や、システムのスケーラビリティが損なわれる問題が発生する可能性がある。
そのため、教科書的には、要望が固定されているミッションクリティカルな大規模システムの開発はウォーターフォールモデルの方が向いているとされている。
この記事では、アジャイル開発にて用いられている手法について、その概要を説明する。
現在では、ウォーターフォールのプロジェクトにおいても、部分的にアジャイル開発の手法が取り入れられることがある。アジャイル開発のプロジェクトに携わる機会がなかったとしても、その手法は参考になるはずだ。
(1)スクラムによる作業プロセス定義
「スクラム」とは、アジャイル開発で用いられる主要な手法の一つである。
ラグビーで「スクラムを組む」と言われると円陣を組んでお互いに結束するイメージがあるが、ここで言う「スクラム」もそのイメージであり、チーム一体となってプロジェクトを遂行して行くことに重点を置く手法である。
スクラムで定義されるプロセスについて、イメージとしては以下の画像の通りである。
スクラムで開発に携わる人物について、その役割を大きく分類すると以下の３つである。
プロダクトオーナー
プロダクトの市場価値について責任を持つ役割。プロダクトに搭載する機能の案を作り管理すること、各々の案について優先順位付けをしリリース日を決めること、実装された機能の受け入れを行うことが主なタスクとなる。開発チーム
リリース予定が立った機能案について、順次実装を行う役割。スクラムマスター
プロセスの管理を行う役割。スクラムに基づいたプロセスが実際に機能しているかを確認し、プロセスが上手く機能するように指導やプロセス改善を行うことが主なタスクとなる。
スクラムにおいては、以下のドキュメントやプロセスを経てリリースを行う。
プロダクトバックログ
プロダクトに搭載する機能の案に相当する。プロダクトオーナーが作成する。スプリントバックログ
プロダクトバックログで定義された機能案の中から、リリース予定が立った機能案を指す。プロダクトオーナーと開発チーム・スクラムマスターが協議し、機能案の優先順位、及び開発チームの開発能力を鑑みて作成される。スプリント
ある機能を実装するための期間を指す。一般的に数週間～１ヶ月程度となる。デイリースクラム
日本の企業でいう所の「朝会」に相当する。開発チーム内で1日15分程度の会議を毎日設け、予実の報告や問題点の共有を行う。プロダクトの増加分
スプリント期間で実際にプロダクトに実装された機能である。この機能は、ユーザにとって何かしら便益をもたらす必要がある（何の便益ももたらさない、機能とは呼べない中途半端な状態のリリースは不可）。実際にリリースするかどうかは、プロダクトオーナーによる受け入れによって行う。ふりかえり
イメージ図からは省略したが、スクラムでは、スプリント期間終了後に「ふりかえり」と呼ばれる会議を行う。この会議では、スプリント期間中に発見したプロセスの改善点の共有を行う。
(2)エクストリームプログラミングによる開発
エクストリームプログラミング（extreme programming, XP）とは、アジャイル開発で用いられる主要な手法の一つである。
生産性や品質を高めることで、顧客の要望に迅速に答えらえるようにするものである。
ビルド（コンパイル）やテスト、デプロイ（実行環境への資材の配置）といったものを自動化するツールが発展・導入されることにより、実現可能となった手法である。
具体的には、以下のような手法が挙げられる。
ペアプログラミング
一人がコーディング、もう一人がリアルタイムにコーディングを見る、という手法である。生産性が悪そうに見える手法であるが、即座にレビューや知識共有が行われることで、生産性や品質の向上を図ることができる。テスト駆動開発
テストケース・テストコードを先に記述してから、実際にプロダクトに埋め込まれるソースコード（プロダクトコード）を記述する、という手法である。テストコードを意識したプロダクトコードは簡潔に書かれる傾向があることから、品質や生産性を高めることができる。リファクタリング
ソースコードの保守性を高めるために、継続的にリファクタリングを行う。リファクタリングという作業には新たなバグを埋め込むリスクがあるが、バグが埋め込まれたとしても自動テストによって即座に発見できるため、そのリスクよりも保守性が高まることによるリターンの方が大きい。
(3)チケットやバーンダウンチャートによる作業管理
アジャイル開発には作業管理のドキュメントにも特徴がある。
ウォーターフォールではWBSによる管理が行われることが多いが、アジャイル開発ではより直感的なチケットやバーンダウンチャートのようなドキュメントで管理されることが多い。
それぞれのドキュメントについて簡単に述べると、いかのようなものである。
【チケット】
スプリントバックログを約２～３時間のタスクに分割したものを「チケット」と呼ぶ。
チケットを管理することで、開発チーム内での作業割り振りや予実把握を容易にする。
バージョン管理システムと連携することも多く、その場合は、成果物の更新理由の把握も容易になる。
【バーンダウンチャート】
特定のスプリントを対象に、縦軸を残タスク、横軸を期間として描いた折れ線グラフを「バーンダウンチャート」と呼ぶ。
バーンダウンチャートを見ることで、スプリント全体の進捗状況を直感的に把握することができる。
メンバーの目に留まる所にバーンダウンチャートを公開しておくことで、進捗状況の共有も容易になる。
具体的には以下のようなものである。
総タスクから最終週までを直線で描いたものを「理想線」、実態に照らし合わせて計画した作業予定を「計画線」、実績を描いたものを「実績線」としている。
なお、この例は、「week2まではタスク消化に時間がかかるが、それ以降はコツを掴みタスク消化が早まる」としていた計画に対して、week2終了時点で元々の計画以上にタスク消化に時間がかかっている、という状況を示唆している例である。
この記事が気に入ったらサポートをしてみませんか？