昨日のブログ更新をすっかり忘れていました。言い訳ですが、朝一で定期検査のため行った病院の待合室でブログを書き上げていたのですが、その後バタバタとアポイントがあり、事務所に帰ってから事務仕事をしていて、そちらに集中してしまいました。
昨日期待を持ってアクセスしていただいた方、本当に申し訳ありません。
さて、要件定義におけるアジャイルスタイルの活用の可能性について考えています。
最近では、パッケージアプリケーションシステムの導入によるITシステムの構築プロジェクトが、基幹システムの置き換えでは普通になってきました。
これには様々な原因を上げることができますが、その基本は導入にかかる期間を短くしコストを押さえる（期待通りになるかは別にして）ことと、企業やグループ内でのオペレーションの統一による業務効率化と柔軟性の確保が大きな動機になっています。
そのため今後パッケージシステムの導入プロジェクトはますます増えて行くことは間違いありません。そこで今回から、パッケージ導入における要件定義と、アジャイルの関係について考えていくことにします。
パッケージ導入プロジェクトでは、一から必要な機能を積み上げて行くスクラッチ開発とは異なり、パッケージの機能を業務にどうフィットさせるか、あるいはパッケージ機能に業務をどこまで合わせるかを考えることを第一に考えます。そうしないと効率化の目的が果たせないからです。
ただ、多くのプロジェクトがこの考え方から外れて、パッケージ機能に追加で開発をするため、当初の目的を十分果たせなくなることが多いのは、このようなプロジェクトに携わったことがある方であれば、よくご承知のことと思います。
ではパッケージ導入プロジェクトの場合、一からシステムを組み上げるスクラッチ開発と要件定義の手法にどのような違いがあるのでしょうか。
一番の違いは、ユーザーの目の前に動くシステムがすでに存在していることです。スクラッチ開発の場合だと、出来上がりのシステムのイメージを正確にユーザーが把握できるのは、最終のテスト（運用、受入など）のタイミングとなります。
この動くシステムをユーザーが評価し、受け入れることができると判断したらそこで要件定義は終了します。まあ現実にはそんなことはほぼないのでいろいろと知恵を絞ることになるのですが。
このように、パッケージ機能を中心にシステムの姿を考えることには、あまり異論はでないと思いますが、実際の要件定義作業では２つの異なるアプローチが存在します。
一つは、開発ベンダー側がまずユーザーの業務の詳細を理解し、その上でパッケージ機能との適合性（Fit&Gap)を考えるというものです。もう一つはその逆で、ユーザーがパッケージ機能を十分に学習し、自社の業務にどうフィットできるかを考えるものです。
多くのプロジェクトは発注者（支払側）と受注者の関係から、前者のパターンで進むことになります。後者はユーザー側の作業負担が大きくなるからです。
次回、パッケージ導入プロジェクトでは、どのような要件定義手法が本当に効果があるのかについて考えを進めていくことにします。