システム開発の見積が高いと感じたら、契約前に確かめたいこと

システム開発の見積を受け取ったものの、金額が高いのか妥当なのか判断できない。中小企業のIT導入のご相談で、よくいただく困りごとのひとつです。かといって、相場が分からないまま値引きを求めても、たいてい話は進みません。この記事では、見積書を受け取ってから契約するまでに確かめておきたいことを、発注する側の立場から整理します。

見積が妥当かどうかは、見ただけでは分かりません

はじめに、身も蓋もないことを書きます。受け取った見積が妥当かどうかは、システム開発に慣れていなければ判断できません。

よく「内訳を出してもらいましょう」と言われます。それ自体は正しいのですが、内訳が出てきたところで「設計に40人日」が多いのか少ないのかは分かりません。単価にしても、同じ機能で会社によって倍近く違うことがあります。安いほうがよいとも限りません。誰が実際に作るのか、再委託が入るのかどうかで、品質も対応の速さも変わるからです。

「どこからどこまでが範囲か」も同じです。そもそも、システム開発の作業がどんな工程に分かれていて、そこに何が含まれるべきなのかという感覚は、何度か経験しないと持てません。何が抜けているかは、抜けているものを知っている人にしか見えないからです。

ですから、見積書の読み方を覚えて自分で見抜こうとしても、あまり遠くまではいけません。この記事も含めて、「これさえ確かめれば大丈夫」という話ではないと思っておいてください。

それでも、範囲が曖昧なまま進むのがいちばん危ない

判断はできない。それでも、危ないところは決まっています。範囲が曖昧なまま契約に進むことです。

ご相談を受けて見積書を拝見すると、金額の水準そのものは相場から外れていないのに、範囲が曖昧なまま話が進みそうになっている、という場面によく出会います。「システム開発一式」と書かれた1行だけの見積書も、珍しくありません。

この状態で始まると、後から必ず「それは範囲外です」というやり取りが起きます。そのときにはもう、金額を交渉する余地はほとんど残っていません。

見積が工程で分かれているか（要件定義・設計・開発・テスト・データ移行・導入支援）、あるいは機能で分かれているか。分かれていなければ、分けて出してもらえないか聞いてみてください。分かれたところで妥当性を判断できるわけではありませんが、話し合う土台ができます。何が高いのかを一緒に見られるようになる、という意味です。

ここで嫌がられたなら、その反応自体が判断材料になります。

全部は洗い出せなくても、よく抜けるところは決まっています

抜けているものを自力で全部見つけるのは、経験がなければ無理です。ただ、よく抜けるものは決まっています。次の5つだけは、専門知識がなくても聞けます。

「これは入っていますか」と聞くだけです。聞かずに進めて、稼働の直前に追加費用が出てくるほうが、はるかに厄介です。

運用が始まってからの費用も足して考える

システムは作って終わりではありません。保守費用、サーバー費用、ライセンス費用が毎年かかります。

保守費用は初期費用の1〜2割程度を年額として見込む例が多く、5年ほど使うと初期費用と同じくらいの金額が運用側にかかることも珍しくありません。

初期費用の数十万円を値切ることに時間を使うより、5年間の合計でいくらになるのかを出してもらったほうが、判断としては確かです。この数字をすぐ出せる会社は、その後の付き合いも安心できることが多いと感じています。

要件は、お互いに最初から伝わらないものだと考える

ここからは、見積書の読み方よりも大事だと思っていることです。

システム開発では、発注する側は自分たちの要件を上手く言葉にできず、受ける側もそれを上手く受け取れません。どちらかの能力が足りないのではなく、この仕事がそういう性質のものだからです。毎日やっている業務ほど、当たり前すぎて説明が抜けます。受ける側も、聞いた言葉を自分の経験に引き寄せて理解します。

だから、要件が固まっていない段階の見積が高くなるのは、不誠実なのではなく、まっとうな仕事の仕方です。相手は分からない部分のリスクを見込んで、余裕をもった数字を出しています。

そこで最近は、一度にまとめて発注せず、分けて発注する進め方が増えています。まず要件定義だけを契約し、何を作るかが見えた段階で、開発の見積をあらためて取る。あるいは開発そのものも、機能のまとまりごとに区切って進める。

分けると手続きは増えますが、得られるものは大きいです。要件が見えてから金額を決めるので、見積の精度が上がります。相手の仕事ぶりを小さく試してから、続けるかどうかを判断することもできます。途中で「思っていたものと違う」と気づいたときに、引き返せる場所があるという意味でもあります。

もうひとつの方法は、分からない部分があることを認めたうえで、幅のある見積で進めるやり方です。この場合は、追加費用が発生する条件をあらかじめ文書にしておきます。

避けたいのは、要件が曖昧なまま、全部まとめて固定金額で契約することです。伝わっていない前提を、伝わったことにして進めてしまうからです。

見積を評価できないなら、相手を見る

金額も範囲も判断できないとすれば、発注する側には何ができるのか。ひとつあります。相手を見ることです。

これは専門知識がなくてもできます。むしろ、人を見る目に関しては経営者のほうが確かなことが多いと感じています。

• 専門用語のまま押し切ろうとするか、こちらの分かる言葉に置き換えて話すか
• 質問を面倒がるか、一緒に考えるか
• 「できます」しか言わないか、できないことや危ないところもはっきり言うか
• 5年間の総額のような、その場で答えにくい数字を出そうとするか

システム開発は、契約書を交わした時点で終わる買い物ではありません。分からないまま始まり、話しながら形にしていく仕事です。そうであるなら、選ぶ基準は「安いかどうか」より「この人たちと1年やっていけるか」になります。

プロジェクトが揉めているとき、たいていは片方が悪者になっています。しかし実際に間に入ってみると、どちらにも言い分があり、どちらにも足りない部分があるというのが正直なところです。受ける側には進め方を組み立てて危ないところを先に見つける責任があり、発注した側にも、決めるべきことを決め、必要な情報を出し、動くものを見て意見を返す責任があります。

参考までに、システム開発をめぐって裁判になった事例では、発注した側の主張が認められないことも少なくありません。求めるものを明確に伝えていたか、決めるべきときに決めていたかが問われるためです。「お金を払って頼んだのだから、うまくやってくれるはず」だけでは通らない、ということでもあります。

だからこそ、値切って相手の利益を削るより、長く付き合える関係をつくるほうが、結果としては安く済みます。値引きは相手の取り分を減らすだけで、作られるものは変わりません。むしろ体制が薄くなって品質が落ちることもあります。予算が合わないときは、値引きを求めるより「何を削るか」「何を後回しにするか」を一緒に決めてください。

判断がつかないときは、発注する前にご相談ください

ここまで書いたとおり、見積の妥当性そのものは、経験がなければ判断できません。それを自力で何とかしようとするより、判断できる人を自分の側に置くほうが確実です。

グレジャーでは岡山を中心に、発注する前の見積チェックや要件の整理、そして契約が決まったあとにベンダーとの打ち合わせへ御社の側の一員として同席する支援をしています。開発を請け負う立場ではないので、御社の側に立って「その投資は必要ありません」もお伝えできます。契約書に判を押す前の段階で、一度ご相談ください。