今週は全国的に素晴らしい天気でスタートしたようです。ここ南関東も晴天で、ポカポカ陽気となっています。年の瀬も押し詰まって何かと気ぜわしい中ですが、気持ちがいい一日となりそうなのが幸いです。
夕刻の梅田スカイビル
さて、パッケージ導入プロジェクトにおける要件定義と、アジャイル開発スタイルの関係について考えています。
前回このようなプロジェクトの場合、2つのアプローチ方法があると考えました。一つは、現状業務からより改善された時期業務を導き出し、それとパッケージ機能と対比させギャップを見つけ、解消するやり方です。もう一つは、パッケージ機能を使って必要な業務を実現する方法を探すやり方です。
お分かりのように、この二つは全く正反対のアプローチで目的を達成しようというものです。そのため本来であれば、いずれかの手法を基本方針として選択し、それに適したプロセスを実行することになります。もちろん場合によっては、二つの方法を融合したアプローチもあり得るでしょう。
パッケージ導入プロジェクトに限らず、どんなプロジェクトでもそうですが、目的とそれを達成するための方法論(方針)に加え、プロセスのイメージを明確にしステークホルダーホルダーが共有することが重要です。
現実のプロジェクトでは、開始前に必要なこの作業が不充分なため、要件定義作業の途中で様々な問題を引き起こすことがあります。
閑話休題
では先ほどあげた二つのアプローチと、アジャイル開発スタイルとの関係はどうなるのでしょう。
もちろん後者のパッケージ機能を中心とした取り組みが、アジャイルスタイルと親和性が高いのは言うまでもありません。なぜなら、動くシステムをユーザーが評価しながら、自分の仕事と対比して必要な機能を決定していくことができるからです。
しかしこの方法にも幾つかのデメリットが存在します。最も大きなものは、ユーザーの負荷が大きくなることです。
ユーザーはパッケージの評価を始める前に、パッケージに必要な業務データを入れる必要があります。必要な機能をちゃんと評価しようとすると、できるだけ多くの実データを投入する必要があるので、結構大変な作業となります。
準備にも時間が必要ですし、実際にシステムを動かして実業務へ適用していく作業も手間暇が必要となります。なによりパッケージソフトの機能を理解することにも相当のエネルギーが必要となります。
またユーザー側で、日ごろから業務構造の整理や部署間の業務の繫がりを理解するなど、システマチックな業務理解を行う仕組みを持っていることも条件の一つとなります。これができていないと、業務の棚卸からプロジェクトはスタートするので、さらに時間がかかってしまうことになります。
デメリットを並べたてましたが、業務を中心に要件をまとめるよりは効率がいいのではないかと、キットＰＭは考えています。
次回は、その辺りについて突っ込んで行くことにします。