先が見えない暗闇プロジェクトでは絶えず新たな問題が発生する。前回は、プロジェクトの遅延をどう挽回するかを中心に説明した。

 今回は問題解決への備えに関わる三つのセオリーを取り上げる。

セオリー1
「それは無理」と言われる案が本当の解決策

 システム開発案件をコンペではなく、ベンダーがトップセールスで勝ち取る。相手が一般企業の場合、こうしたケースが珍しくない。

 システムインテグレータであり、パッケージソフトも開発・販売しているC社は、ユーザー企業のD社に製品を売り込むことに成功した。C社の役員がパッケージソフトの売り物である機能をD社の役員に見せたところ、役員がすっかり気に入り、受注につながった。

 ところがパッケージの機能と業務との差を調べるフィットギャップ分析の段階で、問題が持ち上がった。売り物にしていたはずの機能は確かに便利だが、現場で利用しようとすると入力の手間が馬鹿にならないことが判明したのだ。

 D社の役員は機能の良さだけを見て、活用するためにどれだけ手間が必要になるかは考えなかったようだ。現場が本当に何を必要としているのかを理解してなかった可能性もある。現場はこの機能に関して「ただでさえ忙しいのに、さらに負担をかけてまで使いたくはない」との評価を下した。

現場が推す機能を採用せず

 フィットギャップの作業が進み、機能の取捨選択が議論に上るようになった。C社のパッケージはモジュール型で、どの機能を使うかに応じて料金が変わる。要件定義ではよくある話だが、現場が出してきた要望全てに対応すると予算を軽くオーバーすることが判明した。

 どの機能をはずすべきか。真っ先に挙がったのはD社の役員が気に入っている、売り物の機能だ。IT部門や業務部門の担当者の間では「この機能は不要」と意見が一致した。

 しかし、各部門のマネジャーはこの意見に同意しようとしない。どのような経緯でこのパッケージが選ばれたのかを知っているからだ。マネジャーはチーム内のミーティングで、売り物の機能をはずさないよう話を持っていき、この案はいつしか立ち消えになった。

 マネジャーたちは結局、売り物の機能を採用し、別の機能を削ってコストを抑える案を経営層に提案、承諾を得た。