見積が倍違う。その理由を、発注側は説明できますか

三社から取った見積が、倍以上離れている。どれが高いのか、どれに作業が抜けているのか、比べる物差しが手元にない。「RFPを書いて」と言われても、社内の前例は雛形が一枚だけ。発注担当者がつまずくのは、たいてい開発が始まる前です。

要件を決めるのは、作る側ではなく使う側。IPA(情報処理推進機構)の「ユーザのための要件定義ガイド 第2版」(2019年公開)も、業務部門のユーザが主体的に関与するスタイルへの変革を求めています。とはいえ、要件を決めた経験のある担当者が社内にいるとは限りません。判断の責任は発注者に残したまま、判断の材料をそろえる役が要ります。

私たちはその役を、発注者の側に立って引き受けます。何を作るかより先に、何のために作るのかを言葉にする。構想そのものから描き直したい場合は、業務変革の構想から整理するDX支援を入口にする選択もあります。目的が定まれば、見積の差も読めるようになる。

発注者の判断材料をそろえる
ベンダー選定を絞り込む流れ

開発を請けない前提で、発注者の側に立つ

ベンダーの提案を、別の目で読み直したい。そう思っても、相談できる相手が提案している当のベンダーしかいない。発注側によくある構図です。

このサービスは、開発の受注を前提にしません。立ち位置は発注者の側。RFPの作成から提案の比較、見積の読み解き、要件定義の進行、発注後の進捗管理までを、御社の担当者と同じ机で進めます。契約は作業の遂行を引き受ける準委任が基本です。民法上、請負は仕事の完成に対して報酬を払う契約(第632条)、準委任は法律行為でない事務の委託(第656条)で、受任者は善良な管理者の注意をもって事務を処理する義務を負います(第644条)。成果物の完成を請け負う立場ではないからこそ、ベンダーの提案に遠慮なく疑問を出せる。

発注者の役割も曖昧にしません。IPAと経済産業省が2020年12月に公表した「情報システム・モデル取引・契約書」第二版の検討では、ベンダのプロジェクトマネジメント義務とユーザの協力義務が裁判例でよく問題になっていると整理されました。任せきりにせず、発注者が果たすべき確認と意思決定を段取りに組み込みます。現行システムの置き換えが対象なら、現行システムの調査から進めるリプレイスの進め方も持ち込めます。

ご提供する内容

目的と現状の棚卸し

何に困っていて、何が変われば成功か。ここが言葉になっていないRFPでは、提案の比べようがありません。

RFP(提案依頼書)の作成

背景・範囲・前提条件・評価方法までを書き起こします。そろえて聞けば、提案もそろって返ってくる。

ベンダー候補の選定と提案評価

評価項目と配点を先に決めてから提案を読みます。印象の良し悪しで選ばないための仕組みです。

見積の妥当性評価

「一式」の中身を工程と作業に分解して比べます。安い見積には、抜けている作業が隠れていることがある。

契約形態と責任分界の整理

請負か準委任か、工程ごとに分けるか。誰が何を決め、何を確認するかを契約前に書き出します。

要件定義の伴走

業務部門の要望を要件の言葉に直し、決めるべき論点を会議ごとに並べます。決めるのは御社、段取りは私たち。

PMO(進捗・課題・品質の管理)

進捗・課題・変更要求を一つの台帳で追います。遅れは、報告を待たずに数字で見える形に。

遅延・炎上プロジェクトの立て直し

止まっている原因が要件・体制・契約のどこにあるかを切り分けます。人手が足りないと分かれば、不足する開発体制の補強も選べます。

要件定義RFP作成PMO支援のご提供内容
FAQ よくある質問
Q 開発を依頼しない前提でも相談できますか?
A できます。このサービスは開発の受注を前提にしていません。RFPの作成、ベンダーの提案評価、見積の読み解き、要件定義の進行、発注後の進捗管理までを発注者の側で進めます。開発を別の会社に発注する場合でも、その会社の提案に疑問を出す立場としてお手伝いできます。
Q RFP(提案依頼書)には何を書けばよいですか?
A 背景と目的、対象範囲、前提条件、求める提案内容、スケジュール、評価方法の6点が骨格です。とくに評価方法を先に書いておくと、各社の提案が同じ観点で返ってきて比べやすくなります。機能の一覧だけを並べたRFPでは、提案の前提が各社でばらつき、見積の差の理由が読めなくなります。
Q 見積金額が会社によって大きく違うのはなぜですか?
A 多くは、各社が想定している作業範囲と前提が違うためです。要件定義や移行、テスト、運用引き継ぎを含めるかどうかで金額は大きく変わります。「一式」と書かれた項目を工程と作業に分解して並べると、安い見積に抜けている作業や、高い見積に含まれている安全側の見込みが見えてきます。
Q 要件定義はベンダーに任せてもよいのですか?
A 進め方の支援は任せられますが、何を要件とするかの決定は発注者に残ります。IPAの「ユーザのための要件定義ガイド 第2版」も、業務部門のユーザが主体的に関与するスタイルへの変革を求めています。決めるべき論点を会議ごとに整理し、御社が判断できる材料をそろえる形で伴走します。
Q 請負と準委任はどう使い分ければよいですか?
A 成果物の完成を約束させたいなら請負、検討や管理の作業そのものを依頼するなら準委任が基本です。民法上、請負は仕事の完成に対して報酬を払う契約(第632条)、準委任は事務の委託で、受任者は善良な管理者の注意義務を負います(第656条・第644条)。要件が固まる前の工程を請負にすると、範囲の争いが起きやすくなります。
Q PMO支援では具体的に何をしてもらえますか?
A 進捗・課題・リスク・変更要求を一つの台帳で管理し、定例会の運営と報告資料の整備を行います。ベンダーからの報告をそのまま受け取るのではなく、計画との差を数字で確認し、遅れの兆しを早い段階で共有します。株式会社一創では、発注者が意思決定すべき事項を会議のたびに明示する形でPMOを運営します。
Q すでに遅延しているプロジェクトの立て直しも頼めますか?
A 承ります。まず、止まっている原因が要件の未確定、体制の不足、契約の範囲のどこにあるかを切り分けます。原因によって打ち手は変わり、要件の再整理で済む場合もあれば、範囲の見直しや体制の補強が必要な場合もあります。現状の資料と関係者へのヒアリングから着手します。
Q 費用はどのように決まりますか?
A 支援する工程の範囲と、関与の頻度で決まります。RFP作成だけの短期支援と、要件定義から稼働まで定例会に参加し続ける支援とでは工数が大きく異なります。対象システムの規模、関係するベンダーの数、社内の関係部門の数も変動要因です。初回のご相談で範囲を絞ってからお見積りします。
Q どの段階から相談するのがよいですか?
A RFPを書き始める前、できれば予算を固める前が望ましい段階です。この時点で目的と範囲を整理しておくと、見積の比較や契約形態の判断がしやすくなります。ただし、提案を受け取った後や開発の途中からでも支援は可能で、その時点の資料を読み解くところから始めます。
Q 社内に情報システム部門がなくても依頼できますか?
A 依頼できます。事業部門の担当者が発注を任されている場合こそ、判断の材料をそろえる支援が役に立ちます。株式会社一創では、専門用語を業務の言葉に置き換えながら、社内の稟議や説明に使える形で比較資料を整えます。技術の詳細を覚えていただく必要はありません。

ご発注は請負・準委任・労働者派遣・ラボ型のいずれにも対応しています。
費用の考え方 | 開発の流れ | 契約形態の選び方 | 対応技術 | 対応パッケージ・ツール

開発会社・SIer の方はこちらのご案内もご覧ください。

OTHER SERVICE その他のWebシステム開発サービス一覧