毎週週始めは伊丹空港から羽田空港へ飛ぶのですが、今日はいつもの如く空港についてセキュリティを通ろうとすると、チケット確認機で拒否されてしまいました。
？？のままカウンターに行くと、搭乗予定便が欠航になってました。それまで、機械的に何も考えず、いつものように半ば自動的に行動していて、イレギュラーな状況が自分の身に降りかかって来るとは想像も出来ていませんでした。危機管理的には失格ですね。ちょっと気を引き締めないといけないと反省しきりです。
さてこの今回のテーマ、随分考えが煮詰まってきたようです。そこで結論に向かう前に、これまで検討したことを軽く振り返ってみます。
世の中のITシステム開発プロジェクトで、なかなか浸透していかないアジャイルスタイルの開発手法ですが、現代の複雑化するビジネス環境を考えるとき、昔ながらのウォーターフォール一辺倒ではユーザーの要求に応えられないことは明白です。
しかしながら、アジャイルスタイルを積極的に取り入れるためには、その有用性を訴えるだけでは不十分なのもまた、明らかです。
それは、数十年続いて来たウォーターフォールスタイルによる開発により、そのために必要な組織の環境や制度、それにSIerなどのビジネスモデルが整えられているために、それ以外のスタイルを持ち込もうとしても、現実にそぐわないことが原因のひとつとして上げることができます。
「新しい酒は新しい皮袋に盛れ」という諺どおり、新しい手法はそれを実行するための環境が必要になるということです。まあそれを声高に言ったとしても、世の中が簡単に受け入れてくれるわけでもなく、アジャイルスタイルでプロジェクトを実施したいと考える側がなんらかの工夫をすることが必要だと考えます。
そこでキットＰＭが考えたのが、プロジェクトのライフサイクルの中でも恐らく最も難しいと思われる「要件定義フェーズ」に限定してアジャイルを実施しててはどうかということです。
こうすることで、要件定義フェーズでの要件を具体的にユーザーにイメージしてもらい、要件定義の精度を上げることを可能とし、開発フェーズの期間、工数、費用を確定することができるはずです。もちろん状況によっては、ウォーターフォールスタイルが適している場合もありますので、何が何でもアジャイルでと言っているのではありません。
プロト作成と評価、再作成というプロセスを繰り替えすことで、最終的な要件を固めるわのがプロトタイピングだとすると、これはアジャイルスタイルとすごく親和性の高いもののように思えます。
とここまでがこれまでの振り返りでした。
ここでの要件定義のイメージは、スクラッチ開発という新たに一からシステムを構築するというプロジェクトとなります。ただ、最近ではオリジナルのシステムを一から構築することは少なく、長大な基幹システムはＥＲＰなどのパッケージシステムを基に構築されることがほとんどです。
次回は、このパッケージを使った開発での要件定義とアジャイルスタイルの関係を考えることにします。