企業のビジネスの前線に直結したシステムを開発する案件が増えてきた。こうした案件では、当初の計画通りに品質やコスト、納期を守って作っても、利用部門に評価されるとは限らない。

　この変化を意識せず、マネジメント方法を変えないプロジェクトマネジャーは、痛い目に遭いかねない。流通業のユーザー企業のシステム開発案件でプロジェクトマネジャーを務める池田慎司氏（仮名）も、直近のプロジェクトで苦い失敗を味わった。

　池田氏はこれまで主に基幹系システムを担当してきたが、新たな案件ではエンドユーザー向けの会員制サービスのシステムの構築を担当することになった。早速、利用部門のキーパーソンである佐藤昭夫氏（仮名）が描くサービスのイメージを具体的な要件に落とし込み、開発の方向性を整理。その方向性を踏まえてQCD（品質・コスト・納期）などの目標を設定した計画書を作成し、佐藤氏の合意を取り付けた。いよいよ開発である。

　プロジェクトは当初、比較的順調に進んだ。中盤の佳境に差し掛かってきた時期、池田氏は佐藤氏の呼び出しを受けた。「2週間前に競合他社のサービスが新機能を追加した。その機能がネットユーザーの間でかなり評判がいいらしい。今作っているシステムに何とか入れてほしい」。

　今になって追加要求か。池田氏は腕を組み、状況を整理した。現状の作業だけでも納期がギリギリだし、増員も期待できない。ここで追加要求に応じるとプロジェクトが混乱しかねない。「今、この機能を作業に追加するとコスト、納期を守れません。次期に回しましょう」。

　佐藤氏はなお食い下がってきたが、池田氏は首を縦に振らなかった。最後には佐藤氏も「分かったよ」と引き下がった。

　6カ月後。池田氏のチームは当初の計画通りに納期、品質、コストを順守して、システムを完成させた。ところが佐藤氏は不満顔だ。くだんの機能が好評な競合のサービスが、ユーザーを大幅に増やしたという。「今から同じ機能を開発しても使えるのは早くて半年先だろう？こんなシステムじゃ使い物にならない！」

[画像のクリックで拡大表示]

　計画段階で合意した品質やコスト、納期を守ってシステムを作った池田氏。にもかかわらず、利用部門から不満をぶつけられてしまった。理不尽に思えるかもしれないが、池田氏のようなケースは最近増えている。利用部門にとっての顧客や取引先も関わる、ビジネスとの結び付きが強いシステムが増えてきたからだ。典型例は、デジタルビジネスのシステムである。

　こうしたシステムにおける利用部門の要求は、従来以上にビジネスの動向次第で変わりやすい。「競合他社の新サービスにすぐ追随したい」といった具合である。ビジネスの目的を達成するうえで、以前の計画にこだわっていられないわけだ。