プロジェクト推進の費用の公平性と透明性を確保するためには入札が必要だ。
入札のためにはシステムがほしいか明確にし、RFPをまとめあげる必用がある。RFPに対しての回答は、対応項目に×のある提案は論外。RFP記載のとおりに提案したベンダーの中で最も安いベンダーを、採用べきだ。
さて、RFPを参照して入札するベンダー側はと言うと、お得意様のRFPには、必ず回答しなければならない。記載の内容はすべて○にしなければならない。費用は最大限切り詰めなけらばならない。さもなければ、あそこはやる気がないと思われ、今後の声がかからなくなってしまうかもしれない。そして、見積の不確定要素のリスクを低減するため、できる限りの手弁当である程度の設計を進める。
そんな努力のかいがあって、ユーザ企業は特注のシステムを割安で手に入れることができるベンダーを決定。
そうして、システムの完成に向けてユーザ企業とベンダーでタッグ組んで走り出す準備ができた。しかし、システム開発の契約ができた途端にユーザ企業とベンダーの敵対的関係が始まる。
ユーザ企業は、契約した金額の中で設計が具体化するにつれて明確になってきた課題の取り込みを要求する。コスト増やスケジュール遅延を防止しなければならない。
一方、ベンダーは契約時に確定した限られたリソースで利益を確保しなければならない。そのため、実施内容は極力最小限にしたい。RFPに記載の項目のみにスコープを絞って、プロジェクトの損益悪化を防止しなければ会社がつぶれてしまう。
こんなそれぞれの思いからプロジェクトの完了までユーザ企業とベンダーの言った言わないの敵対関係が続くことになる。
真面目な取り組めば取り組むほど対立は明確になる。
結果として出来上がるのは何でも押し込もうとするユーザとユーザが予め言ったことしかやらない奴隷のようなベンダーの関係性だ。
真面目に仕事に取り組んでいるのに不幸なものだと思う。
そして、奴隷のようなベンダーが作り上げたシステムは必要最小限にしぼった気の効かないシステムとなる。
ユーザ企業は、気の効かないベンダーに動いてもらうのと、気の効かないシステムを扱うのにヘトヘトだ。
ベンダーは、わがままなユーザ企業の要求を実現するために、手弁当の入札対応の設計と、ほとんどの利益の出せない特注品のシステム開発でヘトヘトだ。
結局、ユーザ企業もベンダーも余力はほとんどなく、疲弊する日々を毎日ただ過ごすのみとなる。
では、疲弊しないためにはどうするか。
ユーザ企業は入札結果×の部分を認め、自身で○とする為の体制の確保してまで対応が必用か考える。そして値段のみではく、担当者自身が一緒にシステムを作っていきたいと思えるベンダーを採用するべきだ。こうすることで、担当者自身のシステムに対する思いが強くなり、自発的にシステムの改善を検討できるようになると思う。
一方、ベンダーはRFPのやりたくない項目を×のまま回答する勇気をもつこと。自身のソリューションパッケージやSaaSの長所を全面的に押し出した提案とし、×となる項目への対応は顧客自身で考えてもらう。REP通りの特注品の開発をやめることで、ユーザ企業と体力の削りあいをやめることだ。特注品は一見売り上げは大きいように見えるかもしれないが、案件を通して組織内部に残る価値はあまりなく、ただ主担当のメンバーが疲弊するだけだ。特注品作るリソースで、しっかり得意なものを強化し、実績を増やすことに、注力するべきだ。そうすることで自身のサービスをしっかり成長させられると思う。自身のサービスの強化と思えば、少しは気の効いたシステムを作る気になるのではないかと思う。
では、自身のサービスな強みはなく、特注品を作るしか無い場合はどうするか。それは、RFPの回答(請け負いの案件)ではなく、単に技術者の派遣の提案なのではないかと思う。名ばかり請け負いが行き着く先は結局は双方の疲弊だと思う。