アジャイル開発でシステム開発プロジェクトは成功するのか

1980年代くらいまで、システムは汎用機（ホストコンピュータ）が中心でした。その当時、大企業の多くは、プログラミングができるシステム専門要員を社員として抱え、社員で工数的または技術的に賄えない部分を外部委託していました。一方、中小企業が自社システムを持てる時代ではありませんでした。

1990年代になるとオープン化が進みました。それと並行して、大企業のシステム部門の外注化が進みました。背景として、新しい技術を取り入れるには外注化するのが手っ取り早いこと、一方で力のあるSIerが育ってきたことがあると思われます。また、オープン化により中小企業も自社システムを構築できるようになりましたが、中小企業にシステム要員はいないため、当然の如く外注によりシステムを構築します。

その結果、発注側企業（ユーザー企業）のシステム知識の空洞化が進みました。1980年代くらいまでは、自社の社員がプログラムも読めたので、肌で感じて品質管理ができましたが、だんだんそれができる企業が少なりなりました。

一方で、従前以上にシステムの品質に対する世間の目は厳しくなったので、定量的な管理がどんどん重くなりました。従前の開発手法は、ウオーターフォールという要件定義から企画、設計、実装、テスト、運用までを計画通りに進めていく手法がメインですが、管理負担が重くなればなるほど、開発コストは高くなり、開発期間は長くなります。

そこで、アジャイル開発に目を向ける企業が増えています。アジャイル開発とは『計画→設計→実装→テスト』といった開発工程を機能単位の小さいサイクルで繰り返す開発手法です。一つのサイクル毎に結果をみることができるので、その結果をみながら次のサイクルは何を作るかを決められます。「プロジェクトに変化はつきもの」という前提で進められるので仕様変更に強く、プロダクトの価値を最大化することに重点を置いた開発手法です。

しかし、アジャイルは変化に対応しやすい反面、プロジェクトの最初に、“何を作るのにいくら支払か”という取り決めをユーザーとシステム開発会社間でできません。ユーザーからみれば、お金を払ったのに、役に立つシステムが作られない、というリスクがあります。

1980年代のようにユーザー企業にプログラムがわかる人材がおり、かつ、ユーザー企業とシステム開発会社のコアメンバーとの信頼関係があれば、そのようなリスクを心配する必要もなく、アジャイルは素晴らしい開発手法（の一つ）だといえます。しかし、長年の外注化で、システム開発に関するスキルが空洞化した企業にアジャイル開発をできるのかというと私は疑問をもっています。ちなみに、アジャイル開発は、ユーザーとシステム開発会社が共同して開発をするものであり、“アジャイルで開発を発注する”という意識を持っていたら、そもそも上手くいくはずがありません。

システム開発に関するスキルが空洞化した企業が、アジャイルを前提としたシステム開発契約をシステム開発会社と締結したが、開発がうまくいかなかった場合、それが、ユーザー、システム開発会社、どちらの責任なのかは、それぞれがやるべきことをやったのかで決まります。もっとも、ユーザーの参画の仕方が不十分である場合、それを正すのもシステム開発会社の役割です。