PR

トラブルの要因

 慎重に設計してレビューしたはずなのに、ユーザーの変更要望がいつ果てるとも知れずどんどん積み上がる…。同じような体験をした人も多いでしょう。

 システムは、設計書やサンプル画面などで事前にチェックするのと、実際に操作してみるのとでは、感覚が違います。リリース時期が近づき、ユーザーが検証し始めてようやくあるべき仕様がはっきりしてくるというのは、ある程度やむを得ないかもしれません。

 要件定義や基本設計に参画する人数は限られていますから、多くのユーザーは、UATやシミュレーションのタイミングになって初めて、新しいシステムに触れることになります。そうすると、開発チームが考えてもいなかった要望が飛び出すことになります。

鎮火法

(1)危機を念頭に役割分担を設定する

 本来、プロジェクトのスコープは、開発チームと利用者が協力し合って定めていくべきです。しかし、開発のコストと期間の制約を強く意識する開発チームと、業務遂行を第一に考える利用部門という立場の違いから、議論が平行線をたどることがあります。この構図を壊さないと、前進することができません。

 制約条件のバランスがゆがんでプロジェクトが危機に陥っているという現実を受け入れた上で、プロジェクト遂行のために、開発チームと利用部門が果たすべき役割をはっきりさせましょう(図4)。通常の役割分担ではなく、危機管理としての役割です。

図4●制約条件を踏まえて改善策を合意
図4●制約条件を踏まえて改善策を合意
[画像のクリックで拡大表示]

 例えば、開発チームは迅速な情報提供と優先課題の対応に取り組む、利用部門は変更要求に優先順位をつけて絞り込み、ハンド事務などの運用でカバーする代替策・回避策を考える、といった、協力して緊急事態に対処する分担を決めるのです。

 ステアリングコミッティーなどの高次意思決定機関があれば、それを利用するといいでしょう。