なぜアジャイルが失敗するのか？アジャイルプロジェクトの典型的な課題とは

ビジネススピードが加速し、DX対応が求められる時代において、アジャイル開発に取り組もうとする動きが加速している。国際的な潮流においてもアジャイル開発はメジャーな手法として既に認知されており、案件の提案条件としてアジャイル開発を指定しているケースも珍しくない。

そのため日本の企業においても、アジャイル開発手法を採用するプロジェクトは増えているが、いざアジャイル開発を始めてみると様々な課題や疑問が噴出し、答えが見つからないまま、旧来の手法に戻してしまうケースもよく聞く所である。結局、アジャイル開発は難しいと感じてしまい、効果がわからないといった評価になっていないだろうか？

これまで日本ではウォーターフォール型がスタンダードな開発手法であり、IT企業が受託型のビジネスを展開してきたこともあり、アジャイルの取り組みは他国と比べると遅れている。しかし、ウォーターフォール型の手法のみに頼っていては、ビジネスに寄与するシステム構築は難しくなるばかりで、将来的に企業の成長に悪影響をもたらしかねない。

すべてのシステム開発にアジャイル型の手法が適しているわけではないが、マーケットの動向にすばやく対応していくビジネスや、新規性の高い事業には、柔軟かつ迅速なシステム開発が必要となるし、その実現にはアジャイル開発手法が最適である。

本章では、アジャイル開発の取り組みを始めた際に直面するであろう典型的な課題について、その原因と対策を探っていく。

アジャイル開発手法を採用したプロジェクトにて、まず直面することは、社内ルールとの整合性である。これまでITガバナンス実現のため、企業は社内のプロジェクトルールを整備してきた。それは会社の重要な資産であるが、多くの場合、開発手法はウォーターフォールモデルを前提として考えられている。

つまり、事前に詳細な計画を作り、インプットとアウトプット、タスクとスケジュール、体制やマネジメント方法などを決定したうえで、実行に移すという流れである。そして、それをルールとして遵守させるため、多量のドキュメント作成が必要であったり、各種手続きの抜け漏れが発生しないように何重もの承認プロセスが設けられていたりする。

これは、信頼性を求められるシステムに対しては有効な考え方である一方、変化に対応することを求められるシステムにおいては、うまく機能しない。アジャイル開発は、変化に柔軟に対応するイノベーティブなシステム開発手法であり、そのままの社内ルールには適合しない可能性が高い。

そのため、実験的なアジャイルプロジェクトにおいては、例外ケースとしてルールの適用外とされる場合もあるが、本格的に採用しようとした場合、アジャイル開発手法を採用した場合の社内ルールが必要となる。

また、全社的にアジャイルを積極採用する場合は、組織的な見直しも必要になるだろうが、初期の段階では、開発現場が円滑に行動できることを第一として取り組むべきである。

ルールの見直しポイント

アジャイル開発を行うにあたり、要員や環境の準備もこれまでとは異なる。

変更を柔軟かつ迅速に対応し具現化するためには、継続的な開発ができる環境や自動化の仕組みが必要であり、開発者に求めるスキルもこれまでとは異なるためである。

アジャイルチームの要員アサインについては、要求スキルを具体的に洗い出す必要がある。ウォーターフォールモデルとの違いは、一人で複数の作業をこなす多能工としてのスキルが求められる点であり、その期待値が明確でないと要員ごとのスキル評価があいまいになり、チームの総合力を見誤る可能性がでてくるためである。

アジャイル開発に限ったことではないが、多くの場合クラウド環境上にシステムを構築することが予想される。特にマイクロサービスやサーバレスといったアーキテクチャを採用する場合は、利用する環境の仕様や信頼性、事業継続性など総合的な評価を行う必要がある。

例えばバックログの管理やタスクの進捗管理、品質管理やコミュニケーションなどアジャイルプロジェクトではツールを導入することが多い。付箋やホワイトボードを使って行う方法もあるが、デジタルに行うほうがデータの蓄積や情報共有の面で、容易である。とはいえ、使い勝手が悪かったり、慣れないツールは効率性を落としてしまうため、どのツールを利用するか吟味しておく必要がある。

サービス提供の検討については、アジャイル開発手法の解説で語られていない場合も多い。

当然の事項であるためだが、アジャイルのイテレーティブな開発において、だれが・いつ・どのようなタスクを行うのか、そしてそのタスクをどのように管理するのか、検討しておく必要がある。

キーマンとなるのはプロダクトオーナーであるが、サービス提供の重要な判断は、そのビジネスの主管部門が行うべきである。そのため、プロダクトオーナーと主管部門は、常にサービス検討の打ち合わせをすべきであり、その結果をシステムに反映させる流れとなる。このような社内ルールやガイド、取り決めが必要となる。

アジャイル開発宣言にある通り、アジャイル開発ではソフトウェアが動くことに重点を置くので、ドキュメント作成がおろそかになりやすい。しかし、例えばシステムの運用・保守を他のチームが行う場合は、引継ぎ用のドキュメントが必要となるし、資産としてシステムの詳細仕様書作成を義務付けている場合もあるかもしれない。DevOpsとして開発チームがリリース後も継続的に運用・保守を行いながら開発を続ける場合は、それほど多くのドキュメントは必要とならないかもしれないが、そうでない場合は、あらかじめ、どのようなドキュメントを作成するか決定しておく必要がある。また、作成する工数を確保しておかなければならない。

下図は、ウォーターフォールとアジャイルの違いを説明したものである。ウォーターフォールでは、実現すべきスコープを最初に定義し、そのために必要な期間（納期）と体制（コスト）を見積もる。一方でアジャイルの場合は、期間（納期）と体制（コスト）を決定し、スコープを見積もる。つまり、予算とスケジュールに応じてできることを見積もろうという考え方である。これまでウォーターフォールの考え方でプロジェクトを進めてきたため、どうしてもスコープが揺らぐと、納期とコストに跳ね返ってくると考えがちである。アジャイルは、納期とコストを最初に決定するので、そこに揺らぎはなく、むしろ納期とコストを守るためにスコープを調整するのである。

スコープの調整次第で納期とコストは簡単に守れてしまうため、そのような評価軸でプロジェクトを評価するのではなく、期待どおりのビジネス価値を生み出せたかという観点で評価しなければならない。

企業がガバナンスを効かせつつ、柔軟なアジャイル開発を行うために必要なものは、アジャイルに適した社内の開発ルールである。これは、単純にアジャイルプラクティスを採用しただけでは足りないし、すでにある社内のウォーターフォール向け開発ルールをそのまま適用することも恐らく難しいだろう。

アジャイルに適した開発ルールとは、ドキュメント作成や社内手続きを極力軽量化し、現場の機動力を高めつつ、同時にマネジメントによって正しく管理され、ビジネス判断や経営判断が可能なものでなければならない。そのような開発ルールを整備するためには、アジャイルプロジェクトを正しく定義し、既存ルールとの平仄をどのようにあわせればよいか議論していく必要がある。