ベンダーから「仕様確認」を求められたら？経営者・IT担当者がその場でできる4つの対応ステップ
アカンパニー・パートナーズ
システム開発やITツール導入の途中で、ベンダーから「この仕様で進めていいですか？」と確認を求められ、戸惑ったことはありませんか？「専門用語が多くて判断できない」「今すぐYESと言わないと開発が止まってしまうかも……」と焦る必要はありません。
仕様確認とは、開発に着手する前にベンダーが発注者へ「私たちの理解は合っていますか？」と確認する最終チェックのプロセスです。求められたときは「即答できる項目」「社内確認が必要な項目」「ITコーディネーターを挟むべき項目」の3つに分けて対応することが重要です。この記事では、10年以上の開発・社内SE経験を持つITのプロが、仕様確認の定義・典型的な確認項目・答え方・注意点を専門用語なしで解説します。ベンダーの言葉を翻訳し、自社主導でプロジェクトを進めるための武器にしてください。
「仕様確認」とは何か？発注者が知っておくべき定義
仕様確認とは何ですか？ システムを実際に作り始める前に、ベンダーが発注者に対して「私たちの理解は合っていますか？」と確認する最終チェックのプロセスです。ここで双方の認識を揃えることで、完成間近になってからの「言った・言わない」トラブルを防げます。
仕様確認の定義（発注者向けにわかりやすく）
【仕様確認とは】
仕様確認とは、システムを実際に作り始める前に、ベンダーが発注者に対して「あなたの要望を、私たちはこういう形で形にしようとしていますが、間違いありませんか？」と最終確認するプロセスのことです。
仕様確認は「詰問」ではありません。ベンダーが「あなたの意図をちゃんと理解しているか確認させてください」というプロセスです。ここで双方の認識を揃えることで、後からの「言った・言わない」トラブルを防ぐことができます。
なぜベンダーは仕様確認を求めるのか
ベンダーが仕様確認を求める理由は「要件定義書や指示書の内容だけでは判断できない部分がある」からです。具体的には以下の3つのケースで仕様確認が発生します。
① 要件定義書に記載がない細部の動作：「エラーが発生した場合にどのメッセージを表示するか」など、要件定義書に書かれていない細かい動作仕様。
② 複数の解釈ができる要件：「顧客情報を管理する」という要件が、「新規登録のみ」なのか「更新・削除も含む」のかが不明確な場合。
③ 既存システムとの連携方法：既存の会計ソフトや販売管理システムとのデータ連携方法が明確でない場合。
仕様確認と「要件定義」「仕様変更」の違い
| 用語 | タイミング | 内容 | 費用への影響 |
|---|---|---|---|
| 要件定義 | 発注前 | 「何を作るか」を決める | なし（前提条件） |
| 仕様確認 | 開発中 | 「この理解で正しいか」を確認する | 回答変更で追加費用の可能性 |
| 仕様変更 | 開発中〜後 | 「やっぱり変えたい」という変更 | 追加費用が発生する |
要件定義書なし発注のリスクについては「要件定義書なしで発注すると何が起きるか」もご参照ください。
仕様確認で聞かれる典型的な5項目
仕様確認では具体的に何を聞かれますか？ 主に「①画面の見た目・操作」「②データの保存ルール」「③エラー時の動き」「④他ツールとの連携」「⑤開発の優先順位」の5つです。自社の実際の業務に当てはめて判断する必要があります。
ベンダーから仕様確認を求められる内容は、ほぼ以下の5項目に集約されます。あらかじめ「こういうことを聞かれるんだ」と知っておくだけで、打ち合わせでの焦りは激減します。
【典型的な5項目・まとめリスト】
① 機能・画面の動作確認（どのボタンを押したらどう動くか）
② データの持ち方・連携方法（どのデータをどこに保存するか）
③ 例外処理・エラー時の動作（問題が起きたときどう表示するか）
④ 既存システムとの連携仕様（既存ツールとどう繋ぐか）
⑤ 優先順位・スコープの確認（どこまでが今回の対象か）
① 機能・画面の動作確認
「この画面でボタンを押したときに、何を表示するか」「一覧画面の並び順はどうするか」といった、UI（画面操作）に関する確認です。要件定義書に「顧客一覧を表示する」と書いてあっても、「どの順番で並べるか」「何件まで表示するか」は指定されていないことが多いです。
② データの持ち方・連携方法
「顧客情報の中に複数の連絡先を持てるか」「売上データを月次で集計するか日次で集計するか」といった、データ構造・保存方法に関する確認です。後から変更すると大規模な修正が必要になるため、ベンダーが最優先で確認します。
③ 例外処理・エラー時の動作
「必須入力の欄を空欄のまま保存ボタンを押したら、どういう警告メッセージを出すか」「通信エラーが起きたら入力をやり直させるか」など、スムーズにいかなかった場合の処理の確認です。要件定義書には正常な使い方しか書かれていないことが多く、例外処理は仕様確認で補完されます。
④ 既存システムとの連携仕様
「売上データをfreeeやマネーフォワードに自動で取り込むか」「ボタン一つでExcelファイルとして出力できるようにするか」など、今あるツールとどう繋ぐかの確認です。連携方法によって開発工数が大きく変わるため、早期に確認が必要です。
⑤ 優先順位・スコープ（範囲）の確認
「今回の開発にスマホ対応は含まれるか」「英語対応は必要か」など、開発範囲に関する確認です。スコープが明確でないと、ベンダーが「含まれると思っていた」「含まれないと思っていた」という認識の相違が生まれます。
仕様確認への対応4ステップ
仕様確認の依頼が来たときの対応を4ステップで整理します。
STEP 1：確認内容を「3種類」に仕分けする
仕様確認の依頼内容をリストアップし、「①即答できる」「②社内確認が必要」「③ITコーディネーターに相談すべき」の3種類に仕分けします。この仕分けが正確にできれば、対応の8割は完了したと言えます。
STEP 2：即答できる項目はその場で回答し、必ず議事録に残す
その場で答えられる項目は明確に回答します。ただし「口頭だけの回答」は絶対に避けます。会議後に必ずメールや議事録で「◯◯については△△と決定しました」と文字で確認します。口頭の回答は「言った・言わない」の原因になります。
STEP 3：確認が必要な項目は「回答期限」を明示して持ち帰る
社内で確認が必要な項目は「1週間以内に回答します」と期限を明確に伝えます。「確認します」だけでは、ベンダー側が開発を止めて待ち続けるリスクがあります。回答期限を伝えることで、プロジェクトの停滞を防げます。
STEP 4：判断できない項目はITコーディネーターに相談する
技術的な判断が必要な項目・費用や工数への影響が不明な項目は、ITコーディネーターに相談してから回答します。「わからないまま答える」ことが最大のリスクです。詳細は「ITコーディネーターとは？何をしてくれるのか」をご参照ください。
仕様確認の3分類表（即答・確認・ITC相談）
仕様確認の内容を3種類に分類する際の判断基準を以下の表で確認してください。
| 分類 | 具体例 | 対応方法 |
|---|---|---|
| ①即答できる | 「表示する項目はこれで合ってますか？」「この画面のタイトル名は？」 | その場で回答→メール・議事録で記録 |
| ②社内確認が必要 | 「既存の顧客データをどのシステムから移行するか？」「承認フローは誰が決裁者か？」 | 期限（1週間以内）を伝えて持ち帰る |
| ③ITCに相談すべき | 「この連携方法だと工数が2倍になりますが変更しますか？」「この設計だと将来の拡張が困難です」 | ITコーディネーターを挟んで回答する |
仕様確認で「やってはいけない」3つのこと
❌ 1. 口頭だけで回答してしまう
「口頭で答えたから伝わった」は危険な思い込みです。ベンダーとの会議後は必ずメールで「本日の仕様確認について、以下の通り確認しました」と記録を残します。口頭回答は後から「そんなことは聞いていない」という主張を招きます。
❌ 2. 「大体こんな感じで」と曖昧に答えてしまう
「なんとなく動けばいい」「よきに計らって」という回答は最悪の結果を招きます。ベンダーは「発注者からお任せで承認をもらった」と記録し、後から「イメージと違う」と伝えても「指示通りに作りました」と突っぱねられる原因になります。答えるならば「◯◯の場合は△△を表示する」という具体的な回答を心がけます。
❌ 3. 「よくわからないからベンダーに任せます」と全部委ねてしまう
自社の業務ルールや使いやすさを一番知っているのは、ベンダーではなくあなた自身です。丸投げしてしまうと、自社の業務に全く合わない「使われないシステム」が出来上がってしまいます。わからない場合はSTEP 3・4で対応します。
【実務コメント】
私はかつて、受注側のSE（システムエンジニア）として、多くの仕様確認の場に立ち会ってきました。そこで何度も目にしたのが、発注者様が「早く答えなければベンダーを困らせてしまう」「よくわからないけれど、ここで話を止めたら気まずい」というプレッシャーから、その場の雰囲気で「それで合っています」と答えてしまう姿です。
発注者様に悪意は一切ありません。しかし、この「優しい妥協」が、後になって「そんなつもりじゃなかった」という大きなしこりを生んでしまうのです。
ぜひ覚えておいてください。仕様確認は、その場で100点満点の答えを出さなければいけない場所ではありません。「持ち帰って確認します」「専門家に相談して◯日までに答えます」と言う権利が、発注者である皆様には堂々とあります。
仕様確認の対応について、中立的な立場でサポートします。
新潟を拠点に、オンラインで全国対応しています。初回相談無料です。
仕様確認への回答が追加費用につながる場合の対処法
「仕様確認の回答変更 = 追加費用」という構造を理解する
一度「◯◯の仕様でOKです」と回答した後に「やっぱり△△に変えたい」となると、仕様変更として追加費用が発生します。これは正当な請求です。しかし「最初から正しい仕様を確認していれば不要だった費用」でもあります。仕様確認の回答を慎重に行うことが、追加費用を防ぐ最大の方法です。
変更管理シートで合意を取る方法
仕様確認の回答変更が発生した場合は、「何が変わるか・追加費用はいくらか・納期への影響は何日か」を変更管理シートで確認・合意してから作業を進めさせます。「口頭でお願いしたら追加費用を請求された」という状況を防ぐための仕組みです。ベンダーコントロールの詳細は「ベンダーコントロールを外注する方法」をご参照ください。
よくある質問
-
仕様確認と仕様変更は何が違いますか？
-
仕様確認は「元の要件の理解を確認する」プロセスで、回答内容が変わらなければ費用は発生しません。仕様変更は「要件そのものを変える」ことで、追加費用が発生します。
-
仕様確認に答えられない場合はどうすればいいですか？
-
「社内の実際の業務フローを確認したいので、一度持ち帰ります。◯営業日後の◯日までにメールで回答します」と、具体的な期日を添えて伝えてください。ベンダー側も安心して開発を調整できます。
-
仕様確認への回答を断ることはできますか？
-
全て断ることはできません。ただし「◯日後に回答します」と期限を設けること、「ITCに相談してから回答します」と伝えることは可能です。
-
仕様確認の回答期限はどのくらいが妥当ですか？
-
内容の複雑さにより異なりますが、3〜5営業日が一般的です。社内確認が必要な場合でも2週間を超えると、プロジェクトの進行が止まるリスクが高まります。
-
仕様確認の回答が原因で追加費用が発生した場合の対処法は？
-
まず「何が変わったのか・それが当初の要件定義書と矛盾するか」を確認します。要件定義書に記載があった内容なら追加費用を断れる場合があります。判断が難しい場合はITコーディネーターに相談することを推奨します。
-
仕様確認の対応をITコーディネーターに代理でお願いできますか？
-
可能です。ITコーディネーターがベンダーとの仕様確認の場に同席・代理対応します。費用の目安は「ITコーディネーターの費用・料金相場」をご参照ください。
参考：qualitycube.jp「ベンダーコントロール（ベンダー管理）とは？」https://qualitycube.jp/2024/11/12/vendor-control/（2024年11月）／ stelaq.co.jp「ソフトウェア要件定義とは？」https://stelaq.co.jp/column/1025（2025年7月）
投稿者プロフィール
- 代表
-
プログラマーとしてキャリアをスタートし、製造業の社内SEとして「工場」の論理を、士業事務所の社内SEとして「先生」の論理を肌で学んできました。異なる文化を持つ組織の中でITを推進するには、技術力以上に「聴く力」と「翻訳力」が必要です。
現在はその経験を活かし、新潟の中小企業のDXを支援しています。
ITコーディネーター／上級ウェブ解析士／上級SNSマネージャー
