開発ベンダーはお客様のことを真剣に考えているのか？

お客様が実現したいことを妨げる要因の１つに、開発ベンダーの存在があります。システム開発によってお客様の業務を助けてくれるはずなのに、かえってお客様の負担を増大させてしまうのです。ここでは代表的な３つの負担を明らかにし、正しい開発ベンダーのあり方を考えていきたいと思います。

１．仕様を決めさせる負担

業務プロセスの改革とシステムの仕様策定は一体で検討すべきです。目標業務プロセスを策定する段階から開発ベンダーに相談したいところですが、業務プロセス改革に精通した開発ベンダーはなかなかいないので、業務プロセスに適合するシステムの仕様をお客様自身が決めざるを得ません。

仕様を決めた後は、それを開発ベンダーに伝えて開発してもらうわけですが、技術的に不可能だと言われたり、この仕様だとかなりコストがかかると言われたり、散々仕様を妥協させられた挙句、当初の要求を満たさない使い勝手の悪いシステムができあがるというわけです。

お客様が日々変化していく業務に対応できるシステムを実現できるようにするには、開発ベンダーにも頭脳を使ってもらい、機動的に動いてほしいものです。

２．従来型の開発コスト負担

ほとんどのベンダーは、システム開発費用を人月（開発工数）ベースで見積もります。それ自体が悪いことではありませんが、問題はお客様がペイできるかどうかです。お客様が実現したいことは例えば、業績を向上させること（売上向上、利益率向上）、人件費を削減すること、生産性を向上させることなどが挙げられると思います。システム導入コストを払うのなら、それ以上の効果を得なければいけません。

しかし開発ベンダーにとってはお客様が導入コストを上回る価値を得られるかどうかなんてことはどうでもよいことです。人月ベースで見積もるだけ。言われたとおりのシステムを作るだけ。お客様にとっては、「目標コスト削減額を上回るから、費用対効果の見合わないこの機能は削ったほうがよいのでは？」と助言してくれる開発ベンダーがいると心強いですよね。

３．ネゴシエーション負担

システム開発の現場では何かと敵対関係を生みがちな発注者と受注者。最初の対立は価格交渉から始まります。これくらいの仕様なのに、こんなに時間がかかるのか、なぜそんなに金がかかるのか、といった胃の痛い話をしなければいけません。

開発が始まってから生じる対立は、仕様を変えたいお客様 vs 仕様は意地でも変えないベンダー。多少仕様変更したいと思っても、開発ベンダーに「一度合意していただいたのに仕様変更はできません」とか「仕様変更するにはかなりの料金がかかります」と言われて渋られてしまうと、取り付く島もありません。

最後に発生するのは、不具合なのか仕様なのかを議論する瑕疵担保の対立。これは不具合ではないのかと主張するお客様と、それは仕様ですと突っぱねる開発ベンダー。言った言わないの不毛な議論を巻き起こし、認識のズレを主張し合い、最終的に仲違いすることも多々あると思います。

まとめ

お客様のシステム導入目的を、開発ベンダーと共有できることが最も重要です。そして、開発ベンダーがお客様のことを第一に考えた提案ができるのかも重要です。業務サイドと開発サイドが手を取り合って同じ目的に向かって進むことができると、最適なシステムを実現することができるのだと考えます。