見積りの金額は「人 × 時間」でできている
システム開発には、工場で作る製品のような原価がありません。金額のほとんどは、何人が、どれだけの時間をかけて作るかで決まります。
つまり、金額を下げる方法は2つしかありません。作業量を減らすか、単価を下げるかです。
単価を下げる交渉は、経験の浅い人が担当する、確認の手間を省く、といった形で品質に跳ね返りがちです。本筋は作業量を減らすこと。そして作業量は、何をどこまで作るかで決まります。見積りが高いと感じたら、値引きの前に「何に、どれだけの作業が見込まれているか」を見るのが近道です。
見積書の項目と、その意味
見積書には、たいてい次のような項目が並びます。名前は会社によって違いますが、中身はおおむね同じです。
| 項目 | 何をするか | 削れるか |
|---|---|---|
| 要件定義 | 何を作るか、何を作らないかを決める | 削らない。ここが曖昧だと、後の工程すべてが膨らみます |
| 設計 | 画面・データの持ち方・処理の流れを決める | 機能を減らせば、連動して減ります |
| 開発（実装） | 実際にプログラムを作る | いちばん大きな項目。機能の数と複雑さで決まります |
| テスト | 正しく動くかを確かめる | 削らない。削った分は、公開後の不具合として返ってきます |
| データ移行 | 今のExcelやAccessのデータを移す | データを事前に整理しておくと減ります |
| 導入・操作説明 | 公開作業と、使う方への説明 | 説明の回数や資料の作り込みで調整できます |
| プロジェクト管理 | 進行・連絡・調整 | 関わる人や会社が多いほど増えます |
| 保守・運用 | 公開後の修正、サーバーの管理 | 開発費とは別に毎月かかることが多い費用。必ず確認を |
見落としやすいのが、いちばん下の保守・運用です。開発費だけを比べて決めたら、毎月の保守費が思ったより高かった、という話は珍しくありません。数年使う前提で、合計いくらになるかで比べてください。
高く感じる見積りに多い理由
やりたいことが曖昧なまま見積もっている
何を作るかがはっきりしないと、開発会社は「あとで増えるかもしれない分」を上乗せして見積もるしかありません。曖昧さは、そのまま金額になります。
「あったら便利」まで全部入っている
打ち合わせで出た要望をすべて盛り込むと、使う頻度の低い機能にも同じだけ費用がかかります。最初から完成形を目指すほど、金額は膨らみます。
既製品で済む部分まで作ろうとしている
ログインやメール送信、カレンダー、帳票の出力などは、既にある部品やサービスを使えば一から作らずに済むことがあります。
関わる人や会社が多い
営業、進行管理、設計、開発がそれぞれ別の人や会社だと、そのあいだの連絡や確認にも費用がかかります。大きな案件では必要な体制ですが、小さな仕組みには重すぎることもあります。
削れる場所、削ってはいけない場所
削れる場所
- 使う頻度の低い機能（あとから足す前提に）
- 画面の見た目の作り込み
- 帳票や集計表の種類
- 既製の部品・サービスで足りる部分
- 最初から全員・全部署で使う前提
削ってはいけない場所
- 何を作るかを決める工程（要件定義）
- テスト
- データ移行の確認
- バックアップとセキュリティ
- 公開後に直してもらえる体制
いちばん効くのは、小さく作って、使いながら足していく進め方です。毎日いちばん困っている業務だけを最初に仕組みにし、残りは実際に使ってみてから決める。最初の金額が下がるだけでなく、使わない機能にお金を払うことも避けられます。
反対に、テストやバックアップを削って安くしても、その分は公開後の不具合やデータの消失という形で返ってきます。ここは値切る場所ではありません。
頼む前に用意すると、金額が下がるもの
特別な資料は要りません。次のものがあるだけで、開発会社は見込みの上乗せを減らせます。
- 今使っているExcel、Access、紙の帳票（中身が分かれば、項目の数や流れが読めます）
- 困っている場面（「月末の集計に丸2日かかる」のように、具体的なほど伝わります）
- 「絶対に必要」と「あればうれしい」の区別
- 予算の上限（伝えたほうが、その範囲でできることを提案してもらえます）
- 使う人数と、使う場所（事務所だけか、外出先やスマートフォンでも使うか）
見積りを受け取ったら確認したいこと
金額の大小だけで判断せず、次の点を確認してください。答えをはぐらかされるなら、それ自体がひとつの判断材料です。
- 作る範囲と、作らないものが書かれているか
- 「一式」ではなく、工程ごとの内訳があるか
- 前提条件（利用人数、対応する端末、データ量など）が書かれているか
- テストとデータ移行が含まれているか
- 公開後の保守費用は、いくらで何が含まれるか
- 仕様が変わったとき、金額がどう変わるか
- 作ったシステムのソースコードは受け取れるか
- 窓口の人と、実際に作る人は同じか（違うなら、誰に何を聞けばよいか）
どれも、聞くこと自体は失礼ではありません。説明を求めて嫌な顔をする相手とは、作ったあとも話がしにくいものです。