システム開発プロジェクトで協力企業と見積もり交渉をする際に,安易に値切ろうとするプロジェクト・マネージャ(PM)がいる。気持ちは分からないではないが,システム開発プロジェクトである。スーパーマーケットで野菜の値段を値切るのとは訳が違う。このことを正しく認識し理解しておかないと,安くはなったが結果として大きな損失を被る可能性を秘めている。
見積もりのミスがテストで表面化
Aさんは大手関西系電器メーカーからシステム子会社のZ社へ出向してきた。若手社員の多いZ社の中では,ベテランの部類に属していた。今回,AさんはZ社の社内販売管理システムのリプレイスに関するPMとして任命された。AさんはPMとしての実績は少なかったが,出向元で購買部門の経験があり,業務に精通しているという理由からであった。
Aさんの働きは期待以上のものであった。これまでZ社の販売管理系システムはすべてY社が担当しており,Y社の技術者1人が常駐している。今回もY社への特命発注だと思われていた。しかし,Aさんは作成したRFPをベースに今回の発注について競争入札を行った。
この入札には,Y社を含めX社とW社が参加した。この結果,X社が最も安く,ついでW社の金額がほぼ横並びで,Y社が若干高めに出てきたのだった。理由としては,RFPに表現しきれていないZ社独自業務部分をフォローする仕様が盛り込まれていたからだ。Aさんは最も安いX社にすべきだと主張したが,社内担当者から強い反対があり,最終的には現在担当しているY社に決定した。
提案書に関する内容について詳細な詰めと確認が終わり,いよいよ契約締結の段となった。Y社からは,当初入札した金額で契約を締結させてほしいという申し入れがあった。ここで,Aさんは待ったを掛けた。Y社に価格交渉を持ちかけたのである。Y社としては,Z社側は金額の大枠について合意しているので,価格交渉と言っても端数調整程度にしか考えていなかった。また,PMのAさんは,Z社の親会社からの出向社員であり,これを機会に親会社とパイプをつなぎたいという思いから,価格交渉の席に応じることとした。
価格交渉が始まって,Y社は自身の考えの甘さを実感することとなった。Aさんの提示してきた金額は,Y社提示額の約半額だった。Aさんは,まず低い額を提示し,徐々に相手に譲歩する形で値段を上げて最終的に2割引(俗に言う八掛け)程度にまとめるつもりだった。
協議の末,Y社はどうしても入札金額の5%以上は引けないと申し出た。また,この理由についても詳細に説明した。しかし,Aさんは頑として受け入れない。それどころか,入札価格から15%引きの価格を指値として指示したのだった。指値になると,従うか降りるかの2択しかない。Y社は泣く泣くAさんの指示に従うこととした。
その後,プロジェクトは順調に進み,利用部門を対象にした運用テスト・フェーズに入った。Aさんは自分のおかげで当初予算より15%も安くできたことを自慢していた。問題はここで発覚した。
ユーザーからいくつかの画面で使い勝手が悪いと指摘されたのだった。基本設計フェーズで図面ベースでは確認していたが,実際に動かすと動作が遅く使いづらいというものであった。そこで,Aさんはこの状況についてY社側のPMを問いただした。すると次のような回答が帰ってきた。
「今回,画面の応答速度については要件定義書で指示されていませんし,基本設計書にも記載がありません。応答速度に関する協議には応じかねます。指摘された画面についても,仕様書通りの作りです。変更するのであれば,別途変更要求として有償で対応させていただきます」。
実は,Y社は契約金額が15%も低くなったことから,サーバーとして導入した機器のグレードを当初想定していたものから1ランク落としていた。また,SEについても初級者の割合を増やし,社内原価削減を行っていたのだった。価格が安くなったとはいえ,結果的に利用部門から使えないと言われてはどうしようもない。Kさんはここでも価格交渉をしようとした。しかし,今回の経緯を知り,かつ今後のY社との関係を憂慮したAさんの上司が追加投資することを決定し,なんとかカットオーバーにこぎつけたのだった。
「値切る」と「価格交渉」は異なる
「価格交渉」とは,お互いに自分の考える根拠を戦わせ,合意点に向かって協議し,双方が妥協できる点を見つけることである。一方「値切る」とは,理由も無く単に価格だけを一方的に下げるということだ。価格交渉においては,受注側は交渉内容に併せて条件を提示できるが,値切りでは新しい条件を提示できない。なぜならば,値切りに応じて条件を変更すると,それに併せてさらに値切られる危険性があるからだ。Aさんは,まさに値切りを行ったのである。
筆者も前職で「価格交渉は,半値八掛五割引からスタートせよ」と言われたことがある。これは大げさな例であるが,一般に価格を決定するプロセスにおいて,価格交渉ではなく値切りを行うケースは少なくない。Aさんは以前購買部門にいた経験もあり,何としても契約金額を下げたいという強い思いがあった。購買部門にいるときには正しく価格交渉を行っていたかもしれない。しかし,今回は功を焦るあまりに値切りを行ってしまったのだ。
「値切り」に正直に応じる会社は無い
理由無く値切られた結果に対して,そのままを受け入れて黙って言うことを聞くベンダーは無いと考えた方がよい。なぜならば,会社が仕事を請け負う第一の目的は,その仕事から適切な利益を出すことであり,利益を度外視してまで仕事を行う必要はないからだ。
そうであるにもかかわらず,値切られたらどうするか。値切りに対しては表だって条件を変更しにくい。そこで,発注者に分からない(分かりにくい)形で価格を下げるケースがある(表)。受注側が企業努力などにより原価削減するのであればよいが,そうでない場合には後々プロジェクトに影響がでてくる部分を削減する傾向にある。
「値切り」対策の一例 | 内容 |
---|---|
ランクの低い技術者を使う | 本来はプログラマ・クラスの技術者をSEとして投入する |
テスト項目を減らす | テスト項目数を減らし全体工数を削減する |
ハードウエアの質を落とす | ハードウエアを1ランク低いスペックのものに変更する |
設計書の質を落とす | 従来,ユーザーが要求仕様を書く際に気づかず,SEが気を利かせて設計していたようなもの(例えばドロップダウン・リスト表示内容のソートなど)について仕様書に書かれていないものは設計しない |
保守性を無視する | 要求仕様書に明記されていなければ,保守性を無視した実装を行う(動けばよいという観点からのスパゲッティ・コード化) |
保守契約を受けない | 作るだけ作って保守はしない |
受注者側が値切りに応じる形でこれらのことを行うと,必ず後で「しっぺ返し」をくらうことになる。これは発注者にとっても受注者にとっても不幸なことである。
PMは値切ってはいけない
PMたるもの,何の理由もなく値切ってはいけない。相手の言い値で買えとは言わないが,値切るのではなく価格交渉を持って適正価格を模索すべきである。Aさんが行ったような指値などもってのほかである。
確かに,プロジェクトには予算が決められており,その予算の枠内でやり遂げる必要がある。どうしても予算と見積もり金額が合わない場合には,入念に価格交渉を行い,発注者と受注者の双方が金額の妥当性について合意した上で確定させるべきなのだ。
そのためには,PMは出てきた見積もりを査定する能力が必要であり,かつ高い折衝能力が必要である。PMは常日頃から,査定能力を向上させるための勉強を行うだけでなく,市場動向にアンテナを張り,何が適正価格なのかを常に考える必要がある。その上で,自身の論理と確信を持って価格交渉の席に挑むべきなのだ。
|