アジャイル型開発における注意すべきポイント

アジャイル型開発とは

アジャイル型開発モデルは、従来のウォーターフォール型開発モデルにある「要求→開発→テスト」といった大きな工程（プロセス）を長期間（数カ月～数年）にわたって順番に実施する手法とは異なり、「要求→開発→テスト」を短期間（2週間～1カ月）のサイクル（以降「スプリント」と記載）で繰り返し、優先度の高いソフトウェアを段階的にリリースする開発手法として広く知られています。また、この二つの開発モデルは、開発プロセスの違いだけでなく、開始当初の要求仕様に対する製品の考え方についても、ウォーターフォール型は「基本的に当初の要求仕様を100％満たす（変更はしない）」ことが根底にあることに対し、アジャイル型では「必ずしも当初の要求仕様を100％満たす必要はなく、リリースごとに最良の物を目指す」という思想の違いがあり、その違いは組織体制面にも表れています。（図表1参照）

図表1 ウォーターフォール型開発モデルとアジャイル型開発モデル

上記のような特性の違いから、アジャイル型開発モデルの導入にあたって、単純にウォーターフォール型の開発手法から反復型開発などの手法に置き換えるだけでは、施策が十分ではありません。アジャイル型開発にて生み出される製品の特性を理解し、それを実現する組織体制の構築や文化の醸成までを検討する必要があります。

これら特性の違いを正しく理解せず、アジャイル型開発の導入を行うと、開始当初は一見アジャイルっぽい開発ができているように見えるものの、組織体制や考え方は従来のウォーターフォール型を踏襲していることで、反復型開発といった開発手法が適切に機能されず、品質や納期が達成できないケースや、問題が収束できずウォーターフォール型に開発手法を戻すというような本末転倒な事態に陥るケースにも繫がります。

このような失敗は主に組織体制の問題ではありますが、問題を引き起こしている具体的な要因は以下の2つが共通課題として見られました。

1. （クライアント側の）経営層およびユーザーのアジャイル型開発への理解が浅い
   
2.  組織の特性やリスクに応じたアジャイル型開発の手法（プラクティス）が取り入れられていない

以降のパラグラフでは、上記2点についての事例と留意すべきポイントを解説します。

2．組織の特性・リスクに応じたプラクティスの活用について

アジャイル型開発の代表的な手法は、反復型開発（「イテレーション」）であることはよく知られていますが、アジャイルにはこの他にもプラクティスと呼ばれる多数の手法が用意されており、それらは独立行政法人 情報処理推進機構（以降、「IPA」と記載」）より公開されている「アジャイル型開発プラクティス・リファレンスガイド」や書籍などで確認ができます。

これらのプラクティスはいずれも効率や品質向上の観点で有効な手法ですが、必ずしも全てを採用する必要はありません。ここで重要なのは、アジャイルの実践にあたって、組織の実態を理解し、想定されるリスクに対して合理的に対応するためのプラクティスを選択することです。

失敗している多くのケースで採用されているプラクティスは、書籍などで説明されている代表的な「イテレーション」とユーザーからの要求に優先順位をつけて管理する「プロダクトバックログ」のみに留まっていました。もちろん、これら2つのプラクティスだけでもアジャイル型開発は実践できますし、必ずしも失敗するわけではありません。ただし、失敗ケースでは、短い周期でウォーターフォール型プロセス（「要求→開発→テスト」）を繰り返すのみで、スプリントを通して得られた課題や気づきを次のスプリントで改善するような、反復による改善活動は一切行われていませんでした。

アジャイルは単に反復で開発を回すだけではなく、短い開発期間で得た体験を有効に活用し、タイムリーにリスクや課題を検知し、それらを適宜解決していくといった、開発リスクを最小化するサイクルを実践することで、最終的にユーザーの要望にかなった製品の迅速なリリースが実現できます。

逆にいうと、反復開発を実施していても、リスクを最小化する活動ができていない場合には、プロジェクトの中盤以降でその時々のリスクが顕在化し、品質や計画遅延などの問題に繫がっていくことになります。

アジャイルのプラクティスは、効率や品質の向上を目的として考案された手法ですが、その背後には「アジャイル型開発として起こりうるリスクの最小化を実現する有効な手法」としての役割も担っています。このことを理解した上で、プロジェクトを円滑に進めるためのツールとしてプラクティスを活用することがポイントとなります。

下図は、「短納期、開発期間が短い」「チームメンバーのスキルが未成熟」といった、開発現場ではよくあるリスクに適したプラクティスの選定例です。

上記のようなリスクに応じたプラクティス例は前述の「アジャイル型開発プラクティス・リファレンスガイド」でも紹介されていますが、実際の現場ではここで挙げられている事例以外にもさまざまなリスクが存在します。

特にアジャイル型開発においてリスクを識別する際には、経営層やユーザー、開発側といった個別のリスクだけではなく、俯瞰的な視点から組織全体としてのリスクに目を向け、それらのリスクに対して実質的かつ効果的なプラクティスを選定することが望まれます。

また、開発を開始した後は、開始時点で採用したプラクティスに固執することなく、プロジェクトの状態やチームの状況に応じて、適宜プラクティスを見直し、より効果的な手法を採用することも重要です。私が担当したプロジェクトの中には、開発中盤でプラクティスを一新した例や直面した課題に対して効果的なプラクティスが存在していなかったため、新たに独自のプラクティスを考案し、解決した例もあります。アジャイル型開発はユーザー要求の変更に強いとされていますが、究極的には開発手法をその時々でベストな方法に変化させていくという、高い柔軟性の考え方がベースの思想としてあるということを認識しておくべきでしょう。

執筆者

小野 真利

シニアアソシエイト, PwCあらた有限責任監査法人

※法人名・役職などは掲載当時のものです。