提案書・見積もりの矛盾をチェックするには、何から始めればよいか
複数社の提案書・見積もりをチェックするには、まずRFP(提案依頼書)で前提条件を統一したうえで、各社の回答を同じ項目で並べて比較することから始めます。
手順は次の2ステップです。
- RFPで前提条件を統一する: 実現したい機能、対応範囲、契約形態の希望などをRFPに明記し、全社に同じ条件で提案を依頼します。つまずきやすい点は、RFPを送らずに個別の打ち合わせだけで進めてしまい、会社ごとに前提の説明がぶれることです。
- 回答を同じ項目で並べて比較表を作る: 各社の提案書・見積もりから、対応範囲・稼働体制・契約形態・金額の算出根拠を抜き出し、1枚の表にまとめます。つまずきやすい点は、金額の総額だけを比較し、算出根拠(何を基準に見積もっているか)の違いを見落とすことです。
RFPが無い場合に生じる比較のずれ
RFPが無いまま個別に相談すると、会社ごとに前提条件の説明がぶれてしまいます。提案書同士を並べても、そもそも何を前提に見積もったのかが揃っていないため、矛盾や抜け漏れに気づきにくくなります。
なお、システム開発の契約には請負と準委任という異なる形態があり、独立行政法人情報処理推進機構(IPA)は2020年3月31日に準委任を前提とした「情報システム・モデル取引・契約書(アジャイル開発版)」を公開しています(出典: 情報システム・モデル取引・契約書(アジャイル開発版)、IPA、2020年3月31日)。契約形態によって見積もりの算出根拠そのものが変わる点は、後述します。
提案書・見積もりの矛盾はどこに現れやすいか
矛盾は、前提条件(対応範囲・稼働体制・契約形態)の食い違いと、見積金額の算出根拠の不一致という2箇所に現れやすくなります。
複数社の提案書を並べると、金額の総額はすぐに目に入ります。しかし総額の差が何に由来するのかは、前提条件まで遡らないと分かりません。
| 確認観点 | 見落とすとどうなるか |
|---|---|
| 対応範囲 | ある社は保守運用を含み、別の社は含まないなど、範囲が揃わないまま金額だけ比較してしまう |
| 稼働体制 | 専任チームか兼任かで、稼働状況の報告頻度や対応スピードの前提が変わる |
| 契約形態 | 請負か準委任かで、検収の有無や契約不適合責任の扱いが変わる(詳しくは後述します) |
| 金額の算出根拠 | 工数単価×人数×期間なのか、成果物単位の一括見積もりなのかが会社ごとに異なる |
これらの観点を項目化して比較表に落とし込まないと、金額の高低だけで判断してしまい、実際には対応範囲が違うだけの提案を同列に扱ってしまう恐れがあります。
AIを使って提案書・見積もりの矛盾をチェックする方法は
複数社の提案書をAIに読み込ませ、前提条件や記載内容の矛盾点を横断的に指摘させることで、人手では見落としやすい食い違いを洗い出せます。
チェックの手順(つまずきやすい点つき)
- 各社の提案書・見積もりをテキスト化してAIに読み込ませます。つまずきやすい点は、機密情報や見積金額の詳細を含む文書を外部サービスに渡す際、取り扱いに注意が必要なことです。
- 対応範囲・稼働体制・契約形態・算出根拠という比較観点を指定し、社ごとの記載の矛盾点や抜け漏れを指摘させます。つまずきやすい点は、観点を指定せずに漠然と「変な点を教えて」と聞くと、表面的な誤字脱字の指摘に終始してしまうことです。
- 指摘が出なくなるまで、複数回に分けてチェックを繰り返します。つまずきやすい点は、1回のチェックで終わらせてしまい、粒度の細かい矛盾を見逃すことです。
当社では別の内製ツール開発において、設計書をAIに繰り返し反証させてから実装に入る進め方を試したことがあります。4巡させたところ、1巡目は前提レベルの大きな破綻が指摘され、巡を重ねるごとに指摘の粒度が細かくなり、最終的には細部の食い違いに収束しました(出典: 当社の内製ツール開発での実施記録)。指摘が大きな穴から細部に移ったら、それ以上チェックを重ねても得られるものは減っていきます。提案書・見積もりのチェックでも、同じ収束のパターンが目安になります。
AIチェックがつまずきやすい点
実装者の視点で特につまずきやすいのは、比較する側が無意識に置いている前提を、AIも同じように見過ごしてしまうことです。前述の内製ツール開発では、識別子の持ち方や画面差分の見方について、人が当たり前だと思っていた前提をAIに明示的に否定させたことで、実装前に設計変更ができました。提案書・見積もりのチェックでも、AIレビューの価値は正解を出させることではなく、発注側が暗黙に置いている前提を洗い出させることにあります。
見積もりの算出根拠、請負と準委任(アジャイル)で何が違うか
請負は成果物の完成に対して価格が決まるのに対し、準委任(アジャイル開発)は稼働コスト×期間で見積もる考え方が基本になるため、算出根拠の妥当性を同じ基準で比較できません。
独立行政法人情報処理推進機構(IPA)は2020年3月31日に、準委任契約を前提としたアジャイル開発の外部委託向けモデル契約「情報システム・モデル取引・契約書(アジャイル開発版)」を公開しています(出典: 情報システム・モデル取引・契約書(アジャイル開発版)、IPA、2020年3月31日)。このモデル契約が前提とする準委任契約では、成果物の完成そのものではなく、チームの稼働コストと期間の掛け算で費用を見積もる方式が採られます。
| 契約形態 | 見積もりの算出根拠 | 比較する際の着眼点 |
|---|---|---|
| 請負 | 成果物の完成に対する対価 | 対応範囲・仕様の網羅性と金額が見合っているか |
| 準委任(アジャイル開発等) | チームの稼働コスト×期間 | 稼働体制(人数・単価・期間)の前提が各社で揃っているか |
複数社の提案が請負と準委任の混在で出てくることもあります。その場合、金額の総額だけを並べても算出の起点が違うため、比較になりません。
見積書自体の内訳を見る際は、開発費用・PM費・インフラ費・ライセンス費・保守費という5つの要素で構成されているのが一般的とされています。初期費用の金額だけでなく、運用期間を通じたTCO(総保有コスト)の視点で内訳を比較することが実務上推奨されています。あわせて、見積書の備考欄に記載された前提条件、たとえば対応OSやブラウザのバージョン、開発体制、役割分担などを必ず確認することが、提案書・見積もり間の矛盾や契約後の想定外の追加費用を防ぐうえで重要になります。