アジャイル開発というシステム開発の方法論がある。システム開発、とりわけ要件定義の難しさは「見えない」ことから来るという問題意識のもとで生まれた手法である。
「スクラム」と呼ばれたりする少人数のチームをつくって、対話を繰り返しながら小さな範囲で要件を固め、それをもとにソフトウエアをつくって要件を見える化する。見える化した要件を確認し、さらにその要件を深掘りし、次の範囲の要件を検討する。これを繰り返しながら、段々大きなシステムをつくり上げていくというやり方である。
従来のウオーターフォール方式は、最初に全ての要件をしっかり固め、そこから後戻りすることなく、プログラム開発・テストといった具合に、その名の通り「滝」のように上から下へとプロセスが流れていく手法である。検討が進むにつれて要件が変わることもあるため、「見えない」システムを全て工場生産のようにつくるのは難しい。したがって、アジャイル開発には「行きつ戻りつ」を内包した方法が必要だとの認識がある。
アジャイル開発を生み出すに至った問題意識も、その解決策としての漸進的なアプローチも、正鵠（せいこく）を射たものだと思う。
しかしながら、アジャイル開発を巡って、システム開発の現場ではとても困った問題が起こりがちである。これは日本だけの話ではない。アジャイル開発が主流だと言われている欧米の現場でも同じである。今回はそのことについて論じたい。
システム開発を知識創造の場とせよ
第1の問題は、このやり方が的確に機能するためには、よりビジネスサイドの強い関わりが必要になることから生じる。「小さなチームでつくりながら考え続ける」という手法であるだけに「丸投げ」が入る余地がない。ビジネスサイドもITサイドも共につくりながら考える態勢ができて初めて、スクラムは機能するのである。
しかしながら、世界中の経営者やビジネスサイドの役員が「システム開発はIT部門やITベンダーの仕事だ」として丸投げする傾向にある。そのような状況では、本気で長い間スクラムの一員として加わろうとするビジネスサイドが、果たしてどれくらいいるだろうか。
そこを確かめずに安直にアジャイル開発に着手すると、ウオーターフォールよりもさらに手ひどい失敗につながる。ウオーターフォールは伝統的に練られてきた手法であるだけに、ある意味で役割の線引きがはっきりしており、ITサイドだけでも一定の形はつくりやすい面があるのだ。
