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

2017-11-10

2001年にアジャイルソフトウェア開発の手法を提唱していたアメリカ合衆国の17人のメンバーにより「アジャイルソフトウェア開発宣言」(英語版)が発せられ、その日本語版が2010年に公開されてから、日本の開発現場でもアジャイル型開発を採用する企業がみられるようになってきました。

近年クラウドサービスの拡充により、従来のオンプレミス環境で必要なサーバーやネットワークの構築などで発生するリードタイムを考慮せずに開発着手ができようになったことから、スピーディなサービスリリースを実現できるアジャイル型開発への注目が加速度的に高まっている状況にあります。

筆者は13年間、開発現場のエンジニア、プロジェクトマネージャーとして、従来のウォーターフォール型の開発だけでなく、アジャイル型開発の検討や実践に携わり、当法人入所後には、アジャイル型開発を導入した企業に対するプロジェクト評価や改善のアドバイスなど、現場と第三者の二つの立場でアジャイル型開発を経験してきました。

これら経験の中、アジャイルの特徴である反復型開発の手法が機能し、段階的なリリースに成功している一方、計画通りに段階的リリースが行えず、品質問題や大幅なリリース遅延に陥っているケースもあり、失敗している多くのケースでは開発の準備段階に問題が潜在していることが見えてきました。本コラムでは、それら失敗事例を交えながらアジャイル導入時の注意ポイントを紹介します。

なお、本コラムにおける意見・判断に関する記述は筆者の私見であり、所属組織の見解とは関係のない点を予めお断りしておきます

アジャイル型開発とは

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

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

 

ウォーターフォール型

アジャイル型

要求仕様の扱い

基本的に開発期間中の変更はない

当初の要求仕様に固執せず、柔軟に変更できる

組織体制

クライアント、仕様作成、プログラマー、テストなど役割別

クライアントもチームの一員として製品の価値が最大になるよう全員で行動

ソフトウェアの提供

長期(数カ月~数年)

短期(2週間~1カ月)

手法

綿密に開発計画を策定し、計画に従って着実に進める

試作的なところから着手し、その結果を基に、次のステップを進める。

テスト

実装後、単体→結合→システムテストと工程ごとに実施

短期(2週間~1カ月)サイクルの中で何度もテストを実施

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

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

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

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

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

1.経営層・ユーザーの理解について

2週間~1カ月の短いサイクルでユーザーが求めるソフトウェアのリリースを実現するためには、開発側への正確な要件のインプットや、適宜要求内容を見直すなど、ユーザーと開発の密接なコミュニケーション環境やタイムリーな意思決定が行える、ユーザー側の態勢整備が必要です。しかしながら、失敗するケースでは、スプリントの開始段階と終了段階(受け入れ)のみのコミュニケーションが中心となるため、開発側は要件理解に十分な機会を得られないまま設計に着手(スプリントの終了日が決められているため、開発側としては着手せざるを得ない状況に追い込まれる)し、スプリント終了時のユーザー受け入れで、実装内容が要望と異なるなど、クリティカルな指摘が多数挙げられる状態になります。

この状況が後続のスプリントでも継続すると、前スプリントまでの実装未達分や指摘の修正分など、想定していない作業に時間を費やし、後続のスプリントで予定していた機能実装に手が回らず、計画通りにリリースができないという悪循環が発生します。

この事象に陥る直接的な原因は、ユーザーとのコミュニケーションや要件検討の不足などが考えられますが、引き起こされる背景には、ユーザー側の態勢整備とアジャイル型開発に対する理解に根本の問題があります。

短い周期で次スプリントに実装する要件を整理し、それらを開発側に理解させるためには、ユーザーはスプリント開始時だけでなく、スプリント期間中も後続で実装する要件の検討を開発部門と実施する必要があります。

加えて、ユーザーは要件の検討や見直しをするにあたって、製造されているソフトウェアの仕組みや特徴を理解する必要があり、リリースごとにソフトウェアに触り、理解する時間を確保しなければなりません。(図表2参照)

この点が工程ごとに役割を定義するウォーターフォール型との大きく異なる点です。しかし、一般的にユーザーは通常業務を持っており、頻繁に開発のための時間を確保することが難しい状況にあるため、何の対策も取られていない場合は、前述のような関与度合いとなってしまうことは自明のことだと思います。

図表2 スプリントにおけるユーザーの関与例

これを解決するためには、会社組織としての体制の見直しが必要であり、経営層はアジャイル開発の採用を決断した時点で、ユーザーが開発チームの一員として参画し、進捗や品質の把握など主体的に開発に関わらざるを得ないことを理解し、それを実現するための体制や環境を構築しなければなりません。多くの場合この点が理解されず、ユーザーの体制が構築できていません。

なお、理解を深める手段としては、経営層やユーザーに対してアジャイル型開発の教育や研修の実施が代表的ですが、これらは一度だけではなく、理解が定着するまで継続して行うことが必要です。

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

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

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

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

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

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

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

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

図表3 リスクに応じたプラクティスの選定例

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

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

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

最後に

以上、アジャイル型開発の導入にあたり、共通の失敗事例から見られる注意すべきポイントを紹介してきました。

加速度的にクラウドサービスの採用が拡大している中、他社に先駆けた新規サービスの市場投入など、アジャイル型開発が求められる機会は確実に広がってきています。本コラムで説明した事例が失敗に繫がる要因の全てではありませんが、経営層・ユーザーの理解とリスクに応じたプラクティスの利活用は、アジャイル型開発では欠かせない要素となります。これからアジャイル型開発を採用する組織の方々においては、導入に向けて、ガイドラインの策定や体制の構築などの準備を進めていくことになると思いますが、本コラムが少しでも導入をする上での参考になれば幸いです。

なお、本コラムの執筆に当たってはIPAのホームページの以下の文献を参考にしています。

主要メンバー

小野 真利

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

Email

最新のシステムプロセスアシュアランス部コラム

関連情報

Contact us

Follow us