システム開発費用が高くなる本当の理由
お客さまの中にＩＴ担当の部署がない場合、私たちSIerやベンダーの作成するシステム開発費用が高いか、安いかの判断をするのは一般的に困難と言われています。
それは、同じ製品を作るとしても、それを作るベンダーごとに全く異なる数値が提示されるほどに、見積り手法や根拠が統一されていないからです。特にＢ２Ｂの受注生産系システムはいわゆる「オーダーメイド」になるため、既製品（パッケージ製品）のように大量生産できる代物ではありませんから高くなってしまうのは仕方がありません。言ってみれば、お客さまは"言い値"で買わされているということになります。
また、自社内にＩＴ担当を持たない企業では、製品製造や建設と異なり、そもそもＩＴ業界の開発手法や事情、技術動向などに詳しいわけでもないため精度の高い見積依頼資料（ＲＦＰ：提案依頼書）をつくることが非常に難しく、複数業者に見積依頼をしてもばらついてしまうのが一般的です。
なかには最初にわざと安い見積りを提示して受注しやすくしておいて、後で多額な追加費用を要求するやや悪徳系の業者もいたりします。
そんな高額商品となりがちな「システム開発」ですが、その中でも特に見積った額が高くなる主な原因は次のようなことが考えられます。
・開発内容が複雑で規模が大きすぎる
（夢が詰め込まれ過ぎてる）
・開発業者の開発生産性が低い
（見積り根拠として明示している企業も少ない）
・多段階下請け構造になっている
（実際に開発するメンバーの単価が50万でも
多重構造になれば１次請けの企業単価は100万以上になることも）
・開発業者がリスクを金額に盛り込んでいる
（リスクは本来対策活動でカバーするのが基本ですが
対策できる力量が無い場合に人海戦術しか取れない企業は
赤字とならないよう、最初から多めに見積もります）
ＩＴの仕組みを知らずになんとなくシステムを利用している人たちは、その裏で「どの程度複雑で、どの程度の規模のプログラムが動いているのか」さっぱりわかりません。ですから見積り内容が妥当であっても冗長であっても、お客さまにはなかなか伝わりにくくできています。
それを解消する最も古典的な手法が
『kstep当たりの生産性換算で見積もる』
手法です。たとえば、エンジニア１人当たりの生産性を2.5kstep/月とした場合、100kstepのシステムを開発するのに、プログラミングだけで40人月。そのプログラムを作成するための仕様決定や設計を行い、プログラムができた後は、その製品の品質を保証するためのテストを行うことを考えると、倍以上の工数が必要になる…と言う考え方です。
工数 ＝ 規模 ÷ 生産性（ × 難易度係数）
予算 ＝ 単価 × 工数（＋ 特殊な見積り都合）
また難易度係数をかけあわせて、さらに生産性が落ち込むことを想定した見積りを行うこともあります。
定量的で、論理的に説明されるとお客さまも納得しやすいのですが、そもそも自分たちの普段の『生産性』をデータとして蓄積していない企業では、何の信憑性も無いため、あまり上手くはいきません。
多めに見積もれるのであれば、ＩＴ企業にとって利益に反映されるだけですからまだマシですが、少なく見積もってしまった場合に追加請求するのは、プロの行う仕事ではありません。これは言い換えれば
「1000万あればいけるかなー？とおもったんだけど
ぜんぜん足りなかった！ﾃﾍｯ」
と言った、超テキトーな仕事ぶりをしているのと同じです。
このような対応は、お客さまの経営陣の立場になればもっと困ることがわかります。企業は期首に予算（資金の使い方、事業活動方針、売上予測、利益予測、etc.）を決定します。予備費も用意はしているでしょうが、何が起こるかわからないのですから、できるだけ使いたくないと言うのが心情でしょう。
そしてその企業の従業員はその目標達成のために動くことになります。上場した企業の場合は、その予算がＩＲ情報として公開されることになりますが、その情報を元に、投資家が株の売買を行うことになるため、この予算を大幅に乖離した実績になってしまうのは、非常に問題となるのです。
計画より多すぎれば
「なんでもっと先に言っておかなかったんだ！？」
と言われ、計画より少なすぎれば
「なんで適当な計画をしてるんだ！信用できない！」
と責任を追及されます。原則として、計画を立てた以上は計画通りに遂行することが求められます。
そのため、仮にＩＴ企業から「開発予定で見積もった額だと少なかったんで、もっと頂戴」なんて言われると、非常に困ったことになるわけです。だって、そんな追加請求は計画のうえで予定していなかったわけですから。
お客さま側の中でそのシステム開発の責任者である担当者（おそらくは部長クラス？）は計画にない予算…つまり"稟議"と言う形で経営層にお伺いを立てて、会社の資金を期首に立てた計画以上に消費することはとても危険な行為となるのです。
お客さま側の都合で機能の追加や変更を行う場合（仕様変更）は、そもそも計画通りなのか、計画外予算を自らの意志で使うつもりだから問題にはなりません。ですが、ＩＴ企業側の見積もり精度の甘さが原因で追加請求するのは色々とハードルの高い行為である、ということを肝に銘じておきましょう。
ちなみに、大手企業などではよほど勝算がある稟議、回収見込みの立つ稟議でない限り、期首の時点で計画した内容通りに資金運用できず、何の責任も感じずに稟議を出すような管理職は、
「こいつは計画（実現）性のかけらもない人材だ」
と判断され、大きく評価を落とします。場合によっては出世などにも悪影響が出ることでしょう。それくらい他人の人生を左右しかねないことなのだ、という自覚が必要です。
ですから、お客さまが想定していない追加請求は、必ず揉めます。
揉めずにすんなり通る場合と言うのは、あらかじめその分も想定してお客さまのなかで予算を確保してくださっている場合のみです。自身の"生産性根拠"を持たない企業が規模換算の見積りを行うのは『無計画』であることと大差がないのです。
一方で、優秀なエンジニアが開発した方が生産性は高いにもかかわらず、あえて生産性の低いエンジニアを投入して工数を稼ぐベンダーもいます。
「利益は出にくいけど、売上は稼ぎやすい」
方法で、他のチームで利益が潤沢に出ている場合にあえて売上を高めるために予算的な縛りのゆるいお客さま向けのプロジェクトに対し、こうした行いをする管理職…と言うのも残念ながらいます。
狙ったように生産性の低い人員で構成されるため、当然工数は大きくなり、見積金額も跳ね上がることになります。
しかし、この手法は、最終的に出来上がった製品を見れば、すぐに「費用対効果と釣り合いが取れない」とバレるため、よほど悪質なSIer／ベンダーでもない限りまず選択しません。実施するなら、もう二度と発注されない覚悟をもっておかなければならないでしょう。
最近は従来開発の倍以上の生産性が上がる「超高速開発ツール」の活用も進んでいます。
プログラム言語や、顧客の要求事項によっては、通常の開発工数の半分以下で開発できるケースも珍しくありません。なんでもかんでも、フルスクラッチ（すべて手作り）で開発したいと言うのは、完全にエンジニアのエゴです。顧客目線で物事を見れない人である証拠と言えるでしょう。
そして、システム開発業界の費用が膨れ上がる最大の問題がこの
『多重下請け構造』
です。
昔から、建設業界（大手ゼネコン）とＩＴ業界に蔓延している悪習の１つです。そもそも"派遣法"によって二重派遣が禁止されるようになったのは、この下請け構造が際限なく続き、10次請け、20次請けと続いた先に、何次請けかわからない企業が夜逃げして、どこに何を連絡して良いかわからずエンドユーザーも途方に暮れるような実例が後を絶たなくなってしまったせいです。
私が知っているだけでも13次請けというプロジェクトがあって、ある現場担当の子が問題を起こした時に、何次請けの企業に責任を取らせるか裏でコソコソとあちこちの営業が密約しているのを聞いたことがあります。
大抵の場合は請負契約であっても「二次請けまで」と言った制限をかけられることも多く、当然段階を経るごとにマージンが加算され単価が高くなっていきます。
最下層の企業で開発し、500万の原価で作成できたとしても、一次請けから続くベンダーは何もしないでマージンだけ乗せていくので、エンドユーザーに提示された見積金額は倍以上になっていることも珍しくありません。
責任の所在も不明瞭になりますし、少なくともお客さまにとっては何も嬉しくない手法です。
それでも大手SIerに仕事が集中するのは、もし大トラブルに発展してもその殆どは逃げない体制と資本があって、仮に撤退したとしても損害賠償を完済できる資金的体力があるからです。
実際には、大手と言えどトラブル率１０％を超えているSIerが多いため、大手SIerに仕事を集めても、お客さまにとって恩恵はあまりありません。
そして最後に、
『リスクの上乗せ』
です。
システム開発では、仕様変更や開発納期遅延などで当初に想定した工数では開発できないことがあります。SIerやベンダーはこの工数増加リスクをあらかじめ加味して見積もりがちです。
しかし、リスクは顕在化して初めてその費用が消費されます。
潜在的なままでは何も起こっていないわけですから、費用は消費されません。これをお客さまの予算ではなく、開発チームの予算としよう…というのがこの手段です。
仮に、お客さまが計画していた予算が1000万だったとします。
SIerが見積った金額は500万だったとしましょう。
そこに「何が起こるかわからないので」と言って、リスクが顕在化した時のことも想定して+500万見積りに上乗せしたとします。
しかし、結局リスクは発生せず無事に納品できました。
当然、リスク分の見積り額500万は消費されません。
こうしてSIerは、何かしたわけでもないのに500万の利益を得ることになります。お客さまにとっては、何かしてもらったわけでもないのに500万余分に支払わなくてはなりません。実際にはリスクさえ起きなければ製品自体の価値は当初に見積った500万だけのはずなのに…です。しかし、何も起きなかったからと言って、余計にもらっていた500万を返すことはありません。契約上では、1000万支払うとしてしまっているからです。
それに仮に500万の製品をリスク込みで1000万で見積りが通ったとしても、純粋に500万の利益になることはまずありません。余裕があるからと言って、必ず想定よりも使い込んでしまうはずです。
そういう仕事の仕方しかできなくなってしまうと、ますます他社との生産性レベルの差が開くだけになってしまいます。
これは一見するととてもぼろ儲けできる仕組みのように見えますが、中長期的に見るととてもリスクの高い見積り方です。
(A)相みつをとられた時、価格点で負けやすい（失注率が増大する）
→それで安く完成させたベンダーが出てくると、
当社の見積り方に対する信用を落とす
(B)リスクは正確に測定することが困難なため、問題が起きると、
余剰にもらった金額以上に経費が掛かってしまう可能性がある
→あらかじめリスク分を見積ってしまってる以上、追加請求で絶対揉める
(リスクの対策費として最初に支払っているはずだろ！と言われる)
(C)この手法しか知らず、この手法の成功例だけしか経験していない
リーダーやマネージャーは、景気が悪くなったときに生き残れない
→リスクを「事前に潰す」方策より、「起きたら対処する」方策に
重きを置いているため
(D)リスクを予算に積ませてもらえない相手とまともなビジネスができない
→小さな企業や景気が悪くなったときのメーカーなどは
まずＩＴ投資から予算を絞る
リスク分をあらかじめ開発予算に加えると、たしかに高収益となる可能性が出てくるかもしれません。
しかし、上記のような別のリスクを抱えますし、なによりお客さまの予算を冗長的に消費しますから次のＩＴ投資に結び付かない可能性も高くなります。いろんな意味でハイリスクハイリターンな方法と言えます。
末永く連続して引合いをもらい、良好な関係が構築できて、且つ他社に奪われないようにするためには、必要経費以上の搾取をもくろむことは決して良い選択とは言えません。
中長期的に見た場合、企業を先細らせる手法と言えるのです。
本来、リスクと言うのはお客さまの予算として積んでおいてもらうものです。リスクは別に見積もっておいて「何か起きた時」に別発注で請求できる準備だけ『お客さまの予算計画内で』整えてもらっておいて、何も起きなければ、必要経費以上に請求しない…とするのが理想なのです。
こうすることによって、等身大の生産性や能力水準が図れるようになります。そのことが身をもって把握できるようになると、より精度の高い見積りができるようになるでしょう。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。