クイックリファレンス
ベンダーとの契約で
失敗しない３分ガイド
請負・準委任・SLA・見積書・追加費用・保守契約・トラブル対処まで一枚まとめ
契約の種類を知る
ベンダーから「請負契約にするか準委任にするか決めてください」って言われたんですけど、何が違うんですか？
ざっくり言うと、「完成物に責任を持つか」「作業時間に責任を持つか」の違いだよ。
| 契約の種類 | ベンダーが負う責任 | 費用の決まり方 | 向いているケース |
|---|---|---|---|
| 請負契約 | 成果物の完成（瑕疵担保責任あり） | 固定額が多い | 要件が固まっている開発・制作 |
| 準委任契約 | 善管注意義務（作業そのもの） | 時間単価×工数 | 要件が曖昧・継続的なサポート・調査 |
| SLA付き保守契約 | 定められたサービス水準（応答時間・稼働率など） | 月額固定が多い | システム運用・障害対応の継続委託 |
じゃあ、請負のほうが「完成まで責任持ってくれる」から安心ってこと？
そう思いがちだけど、落とし穴がある。請負は「契約時に決めた仕様の完成」に責任を持つだけ。あとから「やっぱりここ変えたい」となった瞬間、追加費用が発生する。仕様が変わりやすいプロジェクトで請負を選ぶと、変更のたびに見積もりが積み上がっていく。
逆に準委任は変更に柔軟だけど、「完成しなくても時間分は払う」という構造。どちらが有利かはプロジェクト次第で、一概には言えないよ。
SLAってよく聞くんですけど、どういう意味ですか？
SLA（Service Level Agreement）は「サービス品質の約束事を文書化したもの」だよ。例えば「障害発生から2時間以内に一次回答します」「稼働率99.5%を保証します」といった具体的な数値が書かれる。SLAを満たせなかった場合のペナルティ（返金や割引）が設定されていることも多い。保守契約を結ぶときは必ずSLAの内容を確認することが大事だからね。
見積書の読み方
見積書をもらったんですけど、「工数：50人日」とか「単価：70,000円」とか書いてあって、何が何だかわからなくて……
見積書の主な構成要素を整理するね。
| 項目 | 意味 | 確認するポイント |
|---|---|---|
| 工数（人日・人月） | 作業量の単位。1人日＝1人が1日かける作業量 | 根拠の説明を求める。なぜその工数か聞いてOK |
| 単価（人日単価） | エンジニア1人が1日働く費用 | スキルレベルと単価が対応しているか確認 |
| 外部費用（実費） | クラウド・ライセンス・外注費など | 毎月発生するものか一回限りかを区別する |
| 保守・運用費 | リリース後の継続費用 | 初期開発費とは別で計上されているか確認 |
| 消費税・諸経費 | 税抜き表示が多いので注意 | 税込み総額でも比較する |
「工数50人日×単価7万円＝350万円」みたいな計算はわかりました。でも、その50人日って妥当なの？って判断できないんですよね。
正直、専門家でないと完全には判断しにくい。でも聞けることはある。「工程ごとの内訳を出してもらう」のが一番効果的だよ。「要件定義：10人日、設計：8人日、開発：20人日、テスト：12人日」みたいに分解してもらうと、どこにボリュームがあるか見えてくる。
あとは複数社に相見積もりを取ること。3社並べると「1社だけ極端に安い・高い」がわかって、感覚がつかめるよ。
見積書に「別途協議」って書いてある項目があるんですけど、これって何ですか？
「別途協議」は要注意ワードだよ。後から費用が膨らむ可能性がある箇所に使われることが多い。必ず「いくらになる可能性があるか、上限の目安を教えてください」と確認しておくこと。「わからない」と言われたら、概算でもよいので最大値を文書で残してもらうのが安全だからね。
追加費用が発生しやすいパターン
最初に350万円って言われてたのに、最終的に500万円になったって聞いたことがあって……どういうときに増えるんですか？
追加費用が発生しやすいパターンは主に6つある。
| パターン | 具体的な状況 | 防ぎ方 |
|---|---|---|
| 仕様変更・追加 | 開発中に「やっぱりこの機能も欲しい」と追加する | 要件定義を丁寧に固める。変更時は必ず見積もりを取る |
| テスト工数の増大 | バグが多い・仕様変更で再テストが必要になる | テスト工数を初期見積もりに含めてもらう |
| 環境・インフラ費用 | クラウド利用料・SSL証明書・ドメインなど | 初期費用と月額費用を分けて確認する |
| データ移行 | 既存システムからのデータ移行が複雑になる | 移行対象データの量・形式を事前に共有する |
| 外部連携 | 決済・地図・外部APIとの接続で予想外の工数がかかる | 連携先のAPIドキュメントをベンダーに確認させる |
| 承認・レビュー遅延 | 発注者側の確認が遅れてスケジュールが伸びる | レビュー期限を契約に明記。遅延時の費用負担も確認 |
仕様変更って、どうしても出てきますよね。それを全部止めることもできないし……
そう、仕様変更を完全にゼロにするのは難しい。だから大事なのは「変更管理のルールを最初に決めておくこと」だよ。「変更が生じた場合は○営業日以内に変更指示書を発行し、費用・スケジュールへの影響を書面で合意してから着手する」というプロセスを契約書か仕様書に入れておくだけで、後からのトラブルがぐっと減る。
口頭での変更依頼は厳禁。すべてメールやチケットで記録を残す習慣をつけよう。
保守契約で確認すること
システムが完成したあとも保守契約を結ぶって言われたんですが、毎月お金かかるんですか？何をやってもらえるのかも正直よくわからなくて。
保守契約で確認すべきポイントはこの4つだよ。
| 確認項目 | 詳細 | よくある落とし穴 |
|---|---|---|
| 対応範囲 | バグ修正・サーバー監視・ライセンス更新・問い合わせ対応など | 「何でも対応」に見えて、実は範囲外のことが多い |
| 応答時間（SLA） | 障害発生から何時間以内に一次回答するか | 「営業時間内のみ」「翌営業日以内」の場合、夜間障害は翌朝まで放置される |
| 対応時間帯 | 平日9〜18時のみ？24時間365日対応？ | 夜間・土日の障害対応が必要なら別料金になることが多い |
| 費用の内訳 | 月額固定費用に何が含まれるか | 月額に含まれる作業時間の上限を超えると追加請求される |
保守契約って、結ばないとどうなりますか？
バグが出たり、OSやライブラリのセキュリティアップデートが必要になったとき、毎回スポット対応で発注することになる。スポット対応は「優先してもらえない」「単価が割高になる」ことが多いから、結果的に保守契約を結ぶより高くつくケースもある。
ただし「月額を払っているのに何もしてもらっていない」保守契約も存在するので、年に一度は「この1年間何をやってもらいましたか？」と実績を確認するといいよ。
保守契約を途中でやめることはできますか？
できるけど、解約条件を必ず契約書で確認しておいて。「3ヶ月前通知が必要」「年間契約で中途解約不可」という条件が設定されていることがある。また、ベンダーが保守を担当しているうちはシステムの詳細情報（ソースコード・設計書・パスワード類）をきちんと管理・引継ぎできる状態にしておくことも大事だよ。保守会社を変えたくても、情報が渡されていないと身動きが取れなくなるからね。
トラブル時の対処法
納期を過ぎても完成しないとか、品質がひどいとか、そういうときはどうすればいいですか？
まず基本姿勢として、感情的にならず、すべてを記録することが最優先。その上でステップを踏んで対応しよう。
| ステップ | やること | ポイント |
|---|---|---|
| ① 現状を文書化する | 何が問題か・いつ発生したか・影響範囲を整理 | スクリーンショット・ログ・メール履歴をすべて保存 |
| ② 担当者に書面で連絡する | メールで問題点・期待する対応・期限を明示 | 口頭でなくメールで残す。「電話で話した内容」もメールで確認を送る |
| ③ エスカレーションする | 担当者で解決しない場合は先方の上長・プロジェクト責任者へ | 「担当者ではなく、責任者と話したい」と明確に伝える |
| ④ 契約書を確認する | 違約金・損害賠償・解除条件を確認する | 法律の専門家（弁護士・行政書士）への相談も視野に入れる |
| ⑤ 第三者機関を活用する | IPA（情報処理推進機構）のIT紛争解決支援など | 最終手段として訴訟・仲裁も選択肢に入る |
「記録を残す」ってよく言いますが、具体的にどんなことを記録すればいいですか？
最低限これを記録しておこう。
- いつ：日時（年月日・時刻まで）
- 誰が：ベンダーの担当者名・自社の担当者名
- 何を言った／決めた：会議・電話の内容を議事録化してメールで送り、先方に確認させる
- エビデンス：エラー画面のスクリーンショット、受け取ったファイルのバージョン、メールの送受信履歴
もし最終的に訴訟になったりしたら、会社として相当大変ですよね……そうなる前にできることってありますか？
訴訟は時間もお金もかかるから、できれば避けたい。そのためにトラブルが起きる前からできることをやっておくのが一番効果的だよ。
- 契約書に解除・損害賠償の条件を明記する：あいまいなままにしない
- 検収基準を最初に決める：「何をもって完成とするか」を書面で合意しておく
- 定期的な進捗確認をする：週次・月次でレポートをもらい、問題の早期発見につなげる
- 複数の連絡手段を持つ：担当者一人に依存しない。会社の窓口も確認しておく
まとめ
- 契約の種類を理解する——請負は完成責任・固定額、準委任は作業責任・時間単価、SLAは品質保証。プロジェクトの性質で選ぶ
- 見積書は工程別の内訳を求める——「なぜこの工数か」を聞き、別途協議の項目は上限を文書で確認する
- 追加費用の発生パターンを把握する——仕様変更・テスト・環境費・データ移行が主な要因。変更は必ず書面で合意してから着手させる
- 保守契約は対応範囲・応答時間・費用内訳を確認する——SLAの数値と夜間・休日対応の有無は必ずチェック
- トラブルはすべて記録する——口頭の約束はメールで証拠化。エスカレーションは担当者→責任者の順で
- 問題が起きる前に設計する——検収基準・変更管理ルール・解除条件を最初の契約書に入れておく
「なんで私がベンダー担当に……」ってなっても大丈夫。契約書や見積書は専門家でなくても「聞いてよい」ものだよ。わからないことを「わからない」と言えるのも大事なスキルだからね。このガイドを手元に置きながら、ベンダーとの打ち合わせに臨んでみて。