以前に投稿した「99.価格交渉」の投稿とも関係あり、実際に他の業務で価格交渉に伺った時のことを書きたいと思います。

信頼関係の無い状態での交渉

今回は取引先への対応を行っている弊社担当者と、私で伺うことになりました。

行く前の感触について弊社担当者と話をしていたのですが、流石に今回は先方から価格交渉の案内も来ましたし、現在の日本の情勢を考えると、こちらの要望を汲んで頂ける可能性が高いと、移動中の車で話していました。

しかし、実際に誰と会うのかを確認すると、普段の担当者とは別のその部署のTOPの方と他２名で行うとのことで、３名とは面識が無いことを聞きました。

通常価格交渉は、普段から交流している担当者を交えて行うのが通例です。なぜなら、最も状況を把握しているのはその担当者だからです。この時点で「大丈夫かな・・・」と不安がよりぎりました。

今回こちらからは、売り上げが下がっている根拠となる情報を示してほしいと言われていましたので、毎月の経営状況報告書を持参しました。

受注案件なのに工数単価が決められる

昔から私が懸念している点ですが、受注案件であるにもかかわらず工数単価が決められます。つまり、時間〇〇〇〇円といった感じですね。

通常受注案件の場合、受注側企業の裁量で開発期間や関わる人数をベースに見積もりを作成します。

しかし、単価を決められてしまうと工数に対して金額が決まるため、例えば優秀なエンジニアが行うと短い工数で終わりますし、経験の浅い者が行うと長い工数が必要となり、矛盾が発生します。そのようなことから、工数単価の場合、優秀なエンジニアは利益をあげにくくなります。

とはいえ、他のパートナーについても同様に処理をされているため、弊社だけ特別は難しい状況で、弊社もその状況は理解していることから、担当者レベルでは工数で見積もり全体の額を調整することについて、了承頂く場合もあります。

とはいえ、この方法は透明性が無くなるので、工数単価を上げる方向、もしくはこちらの裁量で決める形で交渉すべきと感じています。

交渉

早速交渉を行うために、弊社担当者が現状の説明を行ったのですが、先方はその数値については理解をしめしますが、実際の賃金UPについては声を発しません。

そこで、今季どのような業務を行ったかの詳細を説明することになったところで、私の知らない情報も出てきました。

今期はリプレース案件ばかりで、新規案件が殆ど無い状況だったことを知りました。実際の利益を考えた場合、新規案件の場合はまとまった開発期間が十分に取られているため、JOB間に空きが出来ることは少ないです。

しかし、リプレース案件というのは既に稼働しているシステムが対象となることから、開発期間がイレギュラーになりがちです。これは、お客さんの稼働状況に合わせなければならないためです。

実際のテストや現地調整日程はこちらに裁量が無い場合が多く、JOB間に空きが出来たとしても、その穴埋めが難しい状況です。通常は複数のJOBを回して間を埋めるのですが、あまり大きなJOBを入れると負荷が高くなりすぎることから、コントロールが難しい問題があります。

結局今期は新規の案件が無く、効率的にJOBが回せなかったことが売り上げが低くなった原因の一つと分かりました。

とはいえ、案件発注は取引先のさじ加減で決まってしまうので、こちらに裁量がありません。そのため、受注側としては厳しい状況にならざる負えないと言えます。

また、リプレース案件は調整期間が短く、リスクが高い傾向なのですが、長らく同じ業務を行っていると、自然とリプレース案件が増えていくのは、当然の流れです。これは、新規開発した企業がリプレースを行うことで、工数を削減できるためです。

恐らくこれが一般的に言われている、発注側と下請けの関係であり、問題点の一つでもあります。なぜなら、利益につながりにくい仕事を割り振られる率が上がるため、徐々に下請け企業の負担が増す傾向があります。

粘ってみる

弊社担当者が一通り説明を行い、工数単価UPについて理解を求めましたが、可能なのは2%との回答でした。

この２%ですが、実際の金額にすると１日で数百円UPするイメージです。これが日本のエンジニアの報酬が低い原因であることを、改めて実感しました。

それを聞いて、弊社担当者が黙ってしまったので、私が食い下がります。先ほどの工数単価が決められている問題に言及して、以下を伝えました。

「それであるならば、工数を水増ししなければ受注額をあげることが出来ないと言えますが、それでは透明性が無いのではと感じます」

すると、取引先の方は

「確かにそれをすると透明性が無くなるので、工数単価を上げる方が良いと思います」

と言われました。その結果2%UPです。これ以上話をしても堂々巡りになりそうなので、ひとまず来期は新規の案件を頂き様子を見るということで、まとめることにしました。

機械制御ソフトウェアの難しさ

帰社してメールを確認すると、交渉を行った方から確認の連絡が入っていました。

そこで、以下の３つについて書いたメールを送りました

1. 来期は新規案件を増やす

2. 現在の工数単価では一般的なエンジニアの報酬とは開きがあり満足できない

3. 今後さらにコミュニケーションの機会を増やす必要がある

すると、早速先方から返信があり

「我々は機械メーカのソフトウエア部門ということで、一般的なソフトウエア会社とは、少し経路が違うのかなと思っています」

と返答がありました。

私の経験上ソフトウェアの質や難易度については、機械制御の方が敷居が高いと感じます。これにはいくつかの明確な理由があります。以下が主だったものです。

ミスが許されない

自動化システムでの機械制御は問題発生時に直接的な被害が発生し、工場システムが停止する恐れがあります。可能な限りSTOP時間を最小化させるため、ミスが許されないことや、復旧方法等も含め、管理しなければならないことが多くあります。

特殊なデバイスと環境を扱う

開発環境に対しての深い知識が必要なため、前提知識を学ぶための多くの時間が必要です。そのため、ソフトウェアを作れるだけでは業務に関わることができず、事前の知識が必要となります。

必ず最後を現地で確認

最後は現地で実稼働させて確認が必要となることから、時間と場所に対する制約があります。

高いコミュニケーション能力

現地でENDユーザーの対応を行う必要があり、特にトラブル発生時のコミュニケーションの取り方に豊富な経験が求められます。

Closedなシステム

トラブルが発生した場合、リモートで修正することが困難な環境です。これは、物を動かすため、物と情報の一致を確認しない状況で動かすと、２次災害に発展する恐れがあるためです。また、Closedなネットワークで管理される場合が多く、リモート接続が出来ない場合も多いです。

これらを考えると、コンピューター上で動くだけのソフトウェアとは異なる難しい点が多く存在します。もちろん、金融システム等は同様に難度の高いソフトウェアですが、通常のアプリケーションや昨今流行りのAIソフトウェアの場合、問題が発生しても、直接的な被害に直結する機会は少ないと感じますし、リモートで修正できる場面も多いです。

これが、機械制御ソフトウェアの難度が高い理由です。

まとめ

今回の出来事で感じたのは、大手と下請けの関係で中小企業の賃金UPがどれほど難しいことであるのか、改めて実感しました。

政府がメディア等を通じて賃金UPを訴えていますが、実際の国民が豊かさを感じれないのは、このような現実があるためです。

もちろん今回の企業も全体を見ると、多くの部署に分かれており、快く賃金UP頂けた部署もあります。

今回はそもそもコミュニケーションが少なすぎたのが問題だと感じておりますので、今後は弊社側の努力も必要と感じる所があります。

また、業務の質についてもさらに高めて行くことが重要ですね。質の高いアウトプットを行い、その中で信頼を構築していくことの大切さを忘れないようにしなければいけないですね。