トップ ／ コラム ／ 開発会社の提案の比べ方

複数の開発会社から提案をもらうときの比べ方｜条件を揃えてから比べる

3社に声をかけて提案書が出てきた。金額も期間も、書かれている機能の数も違う。どれが妥当なのか判断できない——システムの発注でよくいただくご相談です。

比べられないのは、読み方が足りないからではありません。3社が同じものを見積もっていないからです。渡した資料が同じでも、どこまでを範囲に入れるか、データの整理を誰がやるか、テストを誰がどれだけやるか。その前提が各社で違えば、出てくる数字は揃いません。

このページでは、提案がばらつく場所、比べられる形に揃えるために発注側で先に決めておくこと、提案書を読む順番を整理します。費用そのものの目安は業務システムの開発費用はいくらかかるのかに分けています。

金額を並べても比べられないのは、同じものを見積もっていないから

相見積もりは「同じ条件で各社に出してもらう」ことが前提になっています。ところが業務システムの発注では、その同じ条件を書いたものを渡していないことが多くあります。

口頭の説明と、いま使っている画面のスクリーンショットだけで提案を依頼すると、各社は足りない部分を自分の経験で補って提案書を作ります。補い方は会社ごとに違います。会員管理の仕組みと言われて名簿の管理までを想像する会社と、請求と入金の照合まで含めて想像する会社がある。それだけで提案の中身は変わります。

ですから金額の差の多くは「どちらが高いか」ではなく「どこまで入っているか」の差です。最初にやることは価格の比較ではなく、何が入っていて何が入っていないかの突き合わせになります。

1社ごとの読み方はシステム開発の見積もりの読み方｜発注前に確認したい10項目に書いています。この記事は、複数社を並べたときの話です。

提案がばらつくのは、だいたいこの5か所

提案書を何社も見てきて、差が出る場所はほぼ決まっています。次の5か所です。

5か所とも、高いか安いかの話ではなく「入っているか」の話です。入っていないものは、あとで必要になったときに別の見積もりになります。

それぞれの中身はデータ移行が詰まる5つのこと、保守・運用は誰がやるのか、引き継ぎチェックリスト（25項目）にまとめています。

条件を揃えられるのは発注側だけ｜先に決めておく5項目

各社に「条件を揃えて出してください」と頼んでも揃いません。各社はそれぞれの見積もり方で出してくるからです。揃えるには、発注側が同じ前提を書いたものを全社に渡すしかありません。

とはいえ仕様書は必要ありません。決めておくのは次の5つだけです。どれも、いまやっている業務の話です。

1. 対象の業務を名前で並べる。機能の名前ではなく、いま事務所でやっている業務の名前で書きます。「入会の受付」「会費の請求」「名簿の更新」「修了者への証明書の発行」のように並べ、範囲に入れるものと入れないものを分けます。
2. 使う人の数と種類。職員だけが使うのか、会員や受講者も自分で使うのか。人数の目安と、外から使う人がいるかどうかで作りが変わります。
3. 移行するデータの種類と件数、整理の担当。名簿が何件あるか、過去年度をどこまで持っていくか、表記ゆれや重複の整理を自社でやるか開発会社に任せるか。
4. いつまでに動かす必要があるか、その理由。制度が変わる、サポートが切れる、総会に間に合わせたい。期限の理由まで書くと、各社が無理のない工程を組めます。
5. テストと検収を誰がどれくらいやれるか。実務の担当者が何人、何日ぶんの時間を出せるか。ここを空欄にすると、各社が勝手に前提を置きます。

この5つが埋まっていれば、各社の提案は同じ土俵に乗ります。書く形式は提案依頼書（RFP）テンプレートをそのまま使えます。業務の棚卸しから手をつけたい場合はヒアリングシートとシステムを作る前に業務をどこまで整理するかが近い話です。

安い提案には4つの種類がある

金額に差があったとき、安い側が手を抜いているとは限りません。安くなる理由は4つに分かれ、そのうち3つは問題のない理由です。

上の3つは、条件が合えば合理的な安さです。とくに3つめは、作り込みを減らせる業務なら最もよい選択になります。注意したいのは4つめで、これは金額の欄ではなく期間と体制の欄を見れば分かります。何人が何か月担当するのか、担当者が1名だけになっていないか。

pegの考え方は、予算に対して機能を削るのではなく、データの整理やテストといった作業を発注側に担っていただいて人工を減らす、というものです。それでも足りなければ、予算の追加をお願いするか、辞退します。安く見せるために期間や人数を短く書くことはしません。この考え方は予算500万円以内で業務管理システムを作る方法に詳しく書いています。

会社の規模による違いそのものは大手のシステム会社と小さな会社は何が違うのかにまとめています。

提案書を読む順番｜金額は最後に見る

提案書が届くと、どうしても先に金額を見ます。ただ、金額から読むとその数字が頭に残り、ほかの欄がその数字の説明として見えてしまいます。順番を変えるだけで読みやすくなります。

1. 対象の範囲。自社で並べた業務の一覧と突き合わせて、入っているもの・入っていないものに印をつけます。
2. 体制。誰が何人、何か月担当するのか。担当者が1名だけになっていないか。その人が抜けたときに誰が続けるのか。
3. 進め方。仕様をいつ、どうやって確定するのか。文書のやり取りだけで決めるのか、画面の試作を見ながら決めるのか。
4. 納品物。プログラム・設計資料・管理者権限が渡るか。ここが書かれていない提案は、あとで引き継げなくなります。
5. 納品後。無償で直す期間があるか。保守の中身と頼み方。
6. 金額と支払い条件。段階払いか、完成後の一括か。段階ごとに何を確認してから払うのか。

1から5を読んでから金額を見ると、差の理由がだいたい説明できます。説明できない差が残ったら、そこが各社に聞くべき質問です。

範囲を先に決めることで期間が変わった例があります。日本眼科医会の会員管理システムでは、大手ベンダーから前のシステムと同じ規模の刷新提案が出ていました。pegは機能一覧の比較から入らず、事務局の業務のヒアリングから始めて、必要な範囲を先に決めました。そのうえで試作した画面を見ていただきながら仕様を固め、中身の開発に入りました。他社の提案が実装9か月＋テスト3か月だったところを、実装5か月＋テスト2か月の計7か月で作り直しています。期間の差は腕の差ではなく、作るものを決める順番の差でした。

経緯は会員管理システムを7か月で作り直すまでと導入事例に書いています。

相見積もりの進め方6ステップ

1. 対象業務と前提を1枚にまとめる。前の章の5項目です。RFPテンプレートを埋めれば足ります。
2. 3社前後に、同じ1枚を渡す。各社からの質問には、全社に同じ内容を返します。1社だけに追加で説明すると、その時点で条件が揃わなくなります。
3. 提案書が届いたら、まず範囲の突き合わせ表を作る。自社の業務一覧を縦に、会社を横に並べて、入っている・入っていない・不明の3つで埋めます。
4. 不明の欄を各社に確認する。ここでは金額の話はしません。「この業務は範囲に入っていますか」「移行データの整理はどちらがやる前提ですか」と、範囲と分担だけを聞きます。
5. 範囲が揃ったところで、金額と期間を比べる。この段階で初めて、同じものの比較になります。
6. 選んだ1社と、契約書の文面で確認する。納品物（プログラム・設計資料・管理者権限）、段階払いの区切り、無償で直す期間。提案書に書いてあっても、契約書に書かれていなければ残りません。

発注してからの連絡が途絶える不安については開発会社と連絡が取れなくなったときの対処法に、いまの状況から何を先にやるか迷う場合は3つの質問でわかる簡易診断をご用意しています。

pegのやり方

pegは、他社と並べて比べていただく前提で提案を出しています。次の6つは、比べたときに差が出るところだと考えているので、必ず書くようにしています。

• プログラム・設計資料・管理者権限を納品物として契約書に明記します。あとで別の会社に引き継げる状態にしておくためです。
• 支払いは段階払いにします（着手・画面の確定・納品）。区切りごとに、何を確認してから次に進むかを決めます。
• 全ての案件を必ず2名以上で担当し、引き継ぎ資料を常に最新に保ちます。1名体制にはしません。
• 定期的に報告し、試作した画面はいつでも見られる状態にします。できあがってから初めて見る、という進め方はしません。
• 納品後3か月の無償での不具合対応を契約書に明記します。
• 確立された技術と標準の型で作ります。未知の技術が必要な案件は受託しません。

提案の前には、まず業務の話を伺います。機能の一覧から入らず、いまどの業務にどれだけ時間がかかっているかを聞いたうえで、範囲を決めます。範囲が決まる前に金額は出しません。

予算が合わないときは、機能を削るのではなく作業の分担を変えます。データの整理やテストを発注側に担っていただくことで、必要な人工を減らします。それでも足りない場合は、予算の追加をお願いするか、辞退します。

納品後のことは業務システムの保守・運用は誰がやるのかに、規模の違いによる考え方の差は大手のシステム会社と小さな会社は何が違うのかにまとめています。範囲の当たりをつけたい場合は見積シミュレーターで機能と画面の案を出すこともできます。

よくあるご質問