発注前に握る——要件と見積もりで炎上の芽を摘む【ベンダーコントロール 第1回】

この連載について

システム開発の発注でトラブルになる案件には、共通の「型」があります。発注側が「あとはお任せします」と丸投げし、出てきたものを見て「思っていたのと違う」となる——この流れです。

ベンダーコントロールとは、相手を管理し追い立てることではありません。プロジェクトが迷子にならないよう、発注側が当事者として舵取りに加わることです。この連載では、その進め方を3回に分けて整理します。

• 第1回（本記事）発注前の準備：要件と見積もりを握る
• 第2回 進行中の管理：プロジェクトを止めない日々の習慣
• 第3回 トラブル回避と総括：品質・見積もり・クロージング

炎上の半分は、実は発注前に決まっています。まずは「契約する前」にやるべきことから始めます。

そもそも「作る」前に立ち止まる

新しくシステムを開発するのは、選択肢のなかで最もお金と時間がかかる手段です。発注を考える前に、もっと軽い手段で目的を達成できないかを一段階だけ検討します。

機能ごとに、次の3つを自問します。「その機能の現状の工数は月に何分か」「削減のためにいくら投資するのか」「本当に効果は出るのか」。 ここで作らずに済む部分を切り分けてから、残りの作り方を考えます。

たとえば、受発注をExcelで回している業務をシステム化する場面なら、こう切り分けます。

• 定型の受発注（全体の8割）→ 既存ツールやパッケージの標準機能で回せないか
• 自社独自の在庫引当ルール（強み）→ ここだけ作り込む価値がある
• 取引先ごとに違う帳票 → 標準で吸収できる分はそのまま、どうしても必要な分だけ個別対応

「作らない／既製で固める／作り込む」を分けるだけで、全体を専用開発するより費用も期間も抑えられます。

「現場で本当に使うか」を確かめる

要件を固める前に、実際に使う現場の声を一度は聞いておきます。上層部だけで決めたシステムが、現場の業務に合わず使われない——これは典型的な失敗です。

• 現場の代表（キーパーソン）に、今の業務の流れと困りごとを聞く
• 「この機能で、現場の何が楽になるか」を一言で言えるか確かめる
• 作る前に、紙やExcelで業務の流れを一度なぞってみる

発注書に並ぶ機能が、現場の1日の動きにどう収まるか。ここを想像できていれば、要件の精度は大きく上がります。

完了の定義を握る——あいまいさを数値に直す

着手前に決めるべきは「何ができたら完成なのか」です。要件は次の型で1行ずつ書き出すと、抜けが減ります。

［誰が］は［どんな条件のとき］、［何を］［どうする］

例：システムは在庫数が発注点を下回ったとき、対象商品の発注書を自動で作成する

最大の敵は「あいまい表現」です。「使いやすく」「早く」「柔軟に」は人によって解釈が違います。発注側からあらかじめ数値に直しておきます。

要件は「1行ずつ」点検する

要件を1行書くたびに、次の6点を確認すると抜けが減ります。

• 主語：誰が（ユーザー種別、またはシステム）操作・処理するか
• 動詞：システムが何をするか（生成する・送信する・検知する）が明確か
• 目的語：何に対して操作するか（発注書・在庫データ・メール）
• 条件：いつ・どんな場合に動くか（在庫が発注点を下回ったとき・承認後）
• あいまい表現がないか：先の変換表のように、残っていたら数値化する
• 否定形で確認：「これができない状態」を想像し、それが問題になるか確かめる

あわせて、データの操作権限（誰が作成・参照・更新・削除できるか）と、状態の移り変わり（下書き→承認待ち→承認済→送信済…）も、表にして握っておきます。「読めるが書けない」項目を明示しておくと、後から権限まわりで揉めません。

非機能要件も、発注側が握る

「何ができるか（機能要件）」だけでなく、「どれくらいの品質で動くか（非機能要件）」も発注側が言葉にしておきます。ここが空白だと、後から「遅い」「落ちる」「権限管理が甘い」で揉めます。最低限、次の6つを確認します。

• 性能：応答時間・同時アクセス数の上限
• 可用性：稼働率、対象の時間帯、障害時の復旧目標
• セキュリティ：アクセス制御の方式、操作ログの保存期間、暗号化
• 保守性：設定変更を誰がどの手順で行うか（管理者がGUIだけで直せるか）
• 拡張性：将来の機能追加・データ量増加・利用人数の上限
• 移行性：既存データの取り込み、切り替え期間の並行稼働

異常時と例外を、最初に詰める

炎上の火種は「うまくいかないとき」に潜んでいます。発注前に、次のような異常系を一緒に洗い出します。

• 連携先（他システム・メールサーバー）が応答しないとき、どうするか
• 承認者が期限内に動かないとき、リマインドや代理承認はあるか
• 入力が不正・必須漏れのとき、どんな挙動になるか
• 権限のない人が操作しようとしたとき、どう止めるか

あわせて「いつまで操作できて、締切後はどう例外対応するか」も決めておくと、画面数の割に複雑になりがちな承認まわりで揉めにくくなります。

「いつまでに・いくらで」も要件のうち

機能や品質だけでなく、納期と予算の制約も、最初に共有すべき「要件」です。

• 予算の上限を税込で明示する
• 本番稼働の希望時期を、理由とともに伝える（「決算前に」など）
• 連携する既存システムや、使える技術の制約を伝える

制約を隠して提案を受けても、後で「その条件なら最初から言ってほしかった」となります。制約は、良い提案を引き出すための前提条件です。

「一式」見積もりを受け取らない

見積もりが「業務支援機能一式 ◯◯万円」のように1行でまとめられていると、どこにいくらかかっているか分からず、比較も削減もできません。ベンダー側がやりがちで発注側が損をするパターンを知り、受け取ったら次の観点で点検します。

• 一式でまとめられている → 機能・工程ごとの明細に分けてもらう（要件定義／認証／マスタ／各画面…）
• インフラが一括 → クラウド・サーバ・ライセンス・監視に分け、年間契約割引などの余地を残す
• 1案だけ → 梅・竹・松など、構成違いの複数案で比較できるようにしてもらう
• 松だけ豪華で竹梅が貧弱 → 「松を選ばせるための見せかけ」は見抜かれ、信頼を損なう
• 必須かオプションか不明 → 各明細に「必須／オプション」を明示してもらう

たとえば「受発注のWeb化 一式2400万円」と提示されたら、明細に分け、「今期は発注画面まで、在庫照会は次期」と切り分けられる状態にしてもらいます。明細に分けるのは値切りではなく、意思決定の材料を取り戻すことです。費用は初期費用だけでなく、保守・改修まで含めた5年程度の総額（TCO）で比べます。

投資に見合うか——ROIで判断する

機能を入れるか迷ったら、次の式に立ち返ります。

機能の価値 ＝ 業務工数の削減 ＋ 売上の増加（またはミス・在庫の削減）

「この機能で月に何時間減るか」を概算し、開発・運用費と比べます。目安として、投資の回収が12か月以内なら前向きに、24か月を超えるなら一度立ち止まると、判断がぶれません。

RFP（提案依頼書）をテンプレートで揃える

複数社に同じ条件で提案してもらうために、提案依頼書（RFP）を1枚用意します。価格だけで選ぶと後で品質や体制の問題が出るので、評価基準も先に決めておきます。次の項目を、そのままテンプレートとして使ってください。

• 背景・目的：現状の課題と、導入で実現したいこと
• スコープ：作るもの／作らないもの
• 機能要件：機能ごとに「Must／Should／Could」で優先度を付ける
• 非機能要件：性能・可用性・セキュリティ・保守・拡張・移行
• 制約：予算上限・納期・連携システム・使用技術
• 評価基準：下表の配点で各社を採点する
• 納品物：成果物として何を納めてもらうか（ここが抜けがち）

このRFPテンプレートは、お役立ち資料として自由にお使いいただけます。自社の項目を埋めていくだけで、各社の提案が同じ土俵で比較できるようになります。

納品物は「仕様書」だけにしない

RFPで最も見落とされがちなのが「納品物の定義」です。仕様書やソースコードだけでなく、次のものも納品物として明記しておくと、後の保守や検証が一気に楽になります。

• テーブル設計書（DB設計）：どんなテーブルが、どんな項目を持つか
• テーブル別の操作一覧（CRUD対応表）：設計書をもらった後、「どのテーブルに対して・どの処理が・どのタイミングで、作成／参照／更新／削除を行うか」を一覧化してもらう。ここまで揃うと、データの流れがブラックボックスになりません
• APIのテスト結果：API ごとのテスト項目と結果（正常系・異常系の両方）。「動くはず」ではなく、テストした証跡を残してもらう

納品物を最初に決めておくと、検収（第3回で扱います）の合否基準もはっきりします。「何が納品されれば完成か」を、RFP の段階で握っておきましょう。

スコープは「作らないもの」も書く

要件を固めるとき、「作るもの」だけでなく「今回は作らないもの（対象外）」も明記します。

• 今回のスコープに含む機能と、含まない機能を分けて書く
• 「将来やるかもしれないが今回はやらない」ものも、対象外として残す
• 対象外を書いておくと、開発中の「これも当然入っていますよね」を防げる

スコープの線引きは、揉めごとの大半を未然に防ぎます。「やらないことを決める」のも、立派な要件定義です。

決裁と予算の流れを確認する

発注をスムーズに進めるには、社内の意思決定の流れを最初に押さえておきます。

• 誰が最終的に予算を承認するのか（決裁者は誰か）
• どんな資料があれば稟議が通るのか
• 承認にどれくらいの期間がかかるのか

明細に分かれた見積もりと、削れる構成案がそろっていれば、決裁者は判断しやすくなります。発注は「ベンダーとの交渉」であると同時に、「社内を通す段取り」でもあります。

第1回チェックリスト

• そもそも、既存ツールや表計算で済ませられないか確認したか
• 「何ができたら完成か」を要件の型で具体的に書き出したか
• あいまいな言葉を数値に直したか
• 非機能要件（性能・可用性・セキュリティ・保守・拡張・移行）を握ったか
• 異常時・例外時の挙動を最初に決めたか
• 見積もりは明細に分かれ、複数案で比較できる形か

関連教材：要件定義や業務フロー設計の進め方は、無料公開のITコンサルティング・ガイドブック（現場導入のための要件定義・業務フローの講座）で体系的に学べます。

まとめと次回

発注前の準備が、炎上を防ぐ最大のレバーです。完了の定義を握り、あいまいさを数値に直し、非機能と異常系まで詰め、見積もりは明細で受け取る。ここまでやって初めて、発注は「賭け」ではなく「設計」になります。

次回（第2回）は、契約後の進行管理——会議体・報告・リスク対応など、プロジェクトを止めないための日々の習慣を扱います。

なお、こうした発注前の握りを社内だけで進めるのが不安なときは、開発会社出身の PMO が発注側に立って伴走することもできます。最初の握りこそ、プロジェクトの成否を最も大きく左右するからです。