一志 達也（ichishi@pochi.tis.co.jp）
TIS株式会社
2001/6/27

少しでも高く売ろうとする売り手と、少しでも安く買おうとする買い手。システムに限らず、売り手と買い手がいれば必ずその価値に対する駆け引きが起きる。われわれSEが日常的にかかわっているシステム構築の値段決定に関しても、例に漏れず複雑な駆け引きが繰り広げられている。

今回は、システム構築の価格決定について筆者なりの考えを述べたいと思う。本稿の読者には、SE（SI）の立場から価格検討に携わる方と、逆に顧客として価格検討に携わる方がいると思うが、そのどちらにもぜひ一読いただきたい。

システム構築費用の内訳

　一般に、「システム構築費用」にはハードウェアやソフトウェアの費用を含める場合と、それらを含めない場合がある。SI企業にとって、ハードウェアやソフトウェアはあくまでも仕入れて売るだけのものだから問題はない。筆者も、それらを取り上げるつもりはないから、ここでいう「システム構築費用」とは、ハードウェアとソフトウェアの費用は含めないものと考えていただきたい。

　SI企業にとっての本業、すなわち純粋なシステム構築費用だけを取り上げようというわけだが、その費用は一体どういったものから構成されているのだろうか。これは、システム規模の大小やその種類によっても違うから、一概には決めにくい。しかし、どんなシステムであっても、大きく4つの作業に分類することはできる。それは、設計・構築・テスト、そしてドキュメント作成だ。システムの規模が大きくなれば、業務や機能別に費用を算出することもある。さらには、アプリケーションとデータベース、インフラと運用などと細かく分類していくこともある。しかし、それぞれ4つの作業が1セットであることに違いはない。

だれが値段を決めるのか

　現在のシステム構築費用の見積もりにおいて、その価格決定に用いられるのは構築時間を基準とした「工数清算」が大半を占める。この方式では、1人のSEが1カ月かかる仕事をした場合の単価を設定する。通常、1カ月は20日で1日8時間の計算だから、1人月が決まれば1人日を算出するのも時給を算出するのも簡単な話である。1人月が120万円と決まれば、1人日は6万円、1時間当たり7500円という計算になる（補足1）。

　あとは、各作業に必要な時間を算出してこの単価と掛け合わせる。そうすれば、そのシステムの構築費用がいくらになるのか、だれの目にもはっきりと分かる公平な計算方式ではじき出されるわけだ。しかし、一見公平なこの算出方式には、実にさまざまな問題が隠されている。それはこれから明らかにしていくが、最初の問題はだれが作業に必要な時間を算出できるのかである。

　筆者の知る限り、営業マンが作業時間を算出することはほとんどない。作業時間を算出するのは、あくまでも現場のSEで、部門長や営業マンと相談しながら決定されていくのが通例である。読者諸氏がどう感じられるかは分からないが、これはこれで理にかなったやり方である。

　なぜなら、算出した見積もりどおりの作業を求められるのは現場のSEであって、営業マンではないからだ。実際にシステム構築を担当するSEを抜きにして工数を算出してしまうと、「何でこんな見積もりになるんだ」とか「できるわけない」といった、余計なもめ事を招くだけである。従って、顧客から見積もり依頼があればそれに適切なSEを見つけるところから話は始まる。

補足1： 　余談になるが、SEの1人月当たり単価というのも、実にさまざまなのが実情である。企業の規模や地方によっても変わってくるし、場合によっては顧客によって単価を使い分けることもある。同じSEでも、設計作業と構築作業では単価が違う、といったことだって珍しくはない。 　想像に難くないと思うが、これは大企業ほど高くなり、中小企業ほど安くなる。最も高価なのは、有名コンサルティングファームや製品ベンダのコンサルタントであるといわれ、その単価は400万円を超えることもあると聞く。逆に安価なのは、プログラミング専門のソフトハウスといわれ、最も安いところでは50万円程度と聞く。 　大手SI企業の場合は、おおむね100万〜150万円前後の単価が設定されていて、ベテランであっても新人であっても、単価を変動させることはほとんどない。筆者は、「プログラマは安くコンサルは高い」という論理には反対なのだが、この話は長くなるので別の機会に譲ろう。

卵が先かニワトリが先か

　さて、見積もりにかかわることになったSEは、それこそ責任重大な仕事を任されてしまったことになる。何しろ、見積もりどおりの時間で作業が完了しなかった場合、会社はどんどん赤字を抱えることになるからだ。従って、できるだけ正確に構築時間を算出したいところなのだが、はっきりいってそれは不可能に近い。長い付き合いの顧客で、いつもと似たような作業というのならともかく、初めての顧客で新規のシステムともなれば難易度は最高だ。

　いずれにしても、見積もりを始める時点で、作業時間が明確になるような仕様が決まっていれば苦労はない。しかし、それも実際には簡単ではない。なぜなら、ほとんどの顧客はSI企業に声をかけるときに仕様など決まっていないからである。

　そこで、まずは「要件定義」と呼ばれる作業を行い、顧客と相談しながら仕様を決めていく。顧客側がシステム構築技術に詳しく、自分たちの必要とするシステムを見極めていれば、SEは顧客の要求を聞き取るだけで済む。そうでなければ、そこに至るまでには膨大な時間がかかってしまう。

　顧客の漠然としたニーズから、適当と思われるソリューションを提案して詳細を煮詰めていかなくてはならない。その間、何度も顧客とやりとりし、顧客内の社内調整なども待たなくてはならないのだ。そうなると、下手をすれば何カ月もの間、SEは無料で動くことになってしまう。何しろ契約がないのだから当然なのだが、その結果失注してはたまらない。それに対し、顧客側の方でもまずはSI企業の選定を済ませたいと望む。いつまでも複数の業者と話していられないし、予算（稟議）の都合などもあって、まずは業者の選定から、となるのだ。その結果、SEは仕様が確定できないままに、何回かのヒアリングだけで見積もりを作成することになってしまう（補足2）。

　ある程度の概要を理解しているとはいえ、まだ詳細な仕様も決まっていないのだから、正確な作業時間を算出しろという方に無理がある。画面数がいくつになるものやら、どれだけ複雑なプログラムになるのやらも分からぬまま、想像で見積もらなくてはならないのだ。これは、ある程度詳細な仕様を顧客から提示されていても、そう大きく変わるものではない。

　多くのSEが似た経験を持つと思うが、作り始めてから終わるまで、仕様に変更がないシステムなど皆無に等しい。たいていは、作っているうちに追加が発生したり、細かな変更が発生したりするものだ。さらにいえば、作り手の個人差による作業時間のブレや、何らかの原因ではまってしまう可能性まで考慮しなければならない。こうしたリスクまで見込み、多すぎもせず少なすぎもせず、顧客にも満足してもらえる見積もりを作ることは至難の業なのである。

　仕様がFixするのが先か、見積もりと契約がFixするのが先か。まさに、卵とニワトリの世界でシステム構築の見積もりは進んでいく。従って、多くのSI企業は契約条件に細心の注意を払う。作業範囲を明確にし、仕様が大幅に変化した場合に対処し、なるべくリスクを小さくするためだ。ここでは、SEでなく営業マンが活躍し、顧客と交渉しながら契約をまとめていくことが多い。

　それでも、やはりリスクは回避しきれない。多くのSI企業の営業マンは、構築中に表面化したさまざまな問題の解決のため、多大な苦労を強いられている。だからといって、筆者は決して顧客側を責めるわけではない。両者には、それぞれの事情があり、それぞれにもっともな主張をしている。まずは両者の言い分をもう一度考え、より確実な見積もりを算出するにはどうすればいいのかを考えていただきたいだけだ。機会があれば、筆者も再度この問題を取り上げたいと思う。

補足2： 　ERPなど、大規模な基幹システム導入の場合、まずは「要件定義」だけの契約をすることもある。これによって、見積もり不可能な状態を回避し、両方にとって適正な契約を行おうというわけだ。この場合、顧客側はSI企業に最終的に支払う金額を知ることはできない。 　しかし、社運をかけるような大規模システムだけに、金額だけでなく信頼できるパートナー選びを優先するといったところだろう。SEが提案するシステム導入後の業務の流れや実績などを基にSI企業を選定する。

筆者紹介

一志達也 1974年に三重県で生まれ、三重県で育つ。1度は地元で就職を果たしクライアント／サーバシステムの構築に携わるも、Oracleを極めたくて転職。名古屋のOracle代理店にてOracle公認インストラクターやサポートを経験。その後、大規模システムの開発を夢見て再び転職。都会嫌いのはずが、いつの間にやら都会の喧騒にもまれる毎日。TIS株式会社に在職中。Linux Squareでの連載をはじめ、月刊Database Magazineでもライターとして執筆するほか、Oracle-Master.orgアドバイザリー・ボードメンバー隊長など、さまざまな顔を持っている。無類の犬好きで、趣味は車に乗ること。

連載 一志達也のSE、魂の叫び

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）