見積書を受け取った発注側がまず見るのは、いちばん下の合計金額だ。次に人月単価と総工数を見て、他社の提案と並べる。その比較で選んだベンダーと契約を交わし、要件定義が始まる。そして三か月後、「その要件は当初のスコープに含まれておりません」という一文が議事録に載る。SAP導入で追加費用が生まれるのは、ベンダーが後から吹っかけるからではなく、見積書の前提条件欄に書かれた数量と、契約書のスコープの書きぶりが、最初から追加を許す形になっているからだ。 金額欄を何度見てもこの境目は見えない。読むべきは前提条件欄、成果物の受領条件、変更管理条項、そして体制表である。
追加費用は交渉で生まれるのではなく、見積りの前提条件欄で決まっている
見積書の構成はどのベンダーでも似ている。工程別の工数と単価、要員ランク別の内訳、想定期間。そして最後のページか欄外に、小さな文字で「前提条件」が並ぶ。金額の議論は前半のページで行われ、この欄はほとんど読まれない。だが追加費用の発生源は、ほぼ全部がここに書いてある。
前提条件欄に載っているのは、その金額を成立させた数量である。会社コードがいくつあり、拠点がいくつで、移行するデータが何年分で、帳票が何本で、外部システムとの接続が何本か。ベンダーはこの数量を置いて工数を積んでいる。数量が動けば工数が動くのは当然で、そこに交渉の余地はない。厄介なのは、この数量が「◯◯を前提とする」でなく「別途協議のうえ決定する」と書かれている場合だ。別途協議という四文字は、要件定義が終わる頃に必ず金額の話として戻ってくる。
発注側がやることは単純だ。前提条件欄の項目を一つずつ数に置き換える。数が出せない項目は、締結前に数えるか、上限を決めるかしかない。数えないまま契約すると、数え終わった瞬間が追加見積りの起点になる。
| 前提条件の項目 | 数量が曖昧なまま契約したときに起きること | 締結前に確定させる形 |
|---|---|---|
| 会社コード・拠点の数 | 対象法人が一社増えるだけで、設定・テスト・移行・研修が丸ごと一式増える | 「会社コード◯社、事業所◯拠点、通貨◯種」と数で書く |
| 移行対象データの年数と件数 | 「過去三年」の解釈が伝票日付か会計期間かでずれ、移行リハーサルが一巡増える | 対象年度、伝票件数のレンジ、マスタ件数を明記する |
| 帳票・様式の本数 | 現行帳票を棚卸ししたら見積りの倍あった、が最も多い追加要因 | 現行棚卸しを締結前に発注側が終え、本数で書く |
| 外部システム連携の本数 | 「主要な連携」の主要が定義されず、周辺の小さな連携が全部落ちる | インタフェース一覧を添付し、本数と方向で書く |
| 標準機能で実現する前提の範囲 | Fit-to-Standardの議論が、そのまま追加開発の見積り交渉に化ける | 「追加開発◯本まで、超過分は変更管理」と上限本数で書く |
| レビューと修正の回数 | 成果物のレビューが際限なく往復し、工程が終わらない | 「レビュー二回、指摘反映一回」と回数で書く |
| 発注側の要員体制 | ベンダー側の前提に「キーユーザ常駐」とあり、出せないと遅延の責任が発注側へ寄る | 供出できる稼働率と人数で握り直す |
この表のうち発注側が自力で先に潰せるのは、帳票本数とインタフェース本数だ。どちらも現行システムを数えれば出る。数週間を惜しんで契約すると、要件定義の中盤で「帳票が想定の二倍」という事実が出てきて、そこから追加見積りと予算の再申請が始まる。投資判断の説明を一度終えた後に金額が動くのは、経営に対する説明のやり直しでもある。
スコープは「やること」でなく「やらないこと」を書いて初めて閉じる
契約書のスコープ記載は、たいてい「本プロジェクトは、SAP S/4HANAの財務会計・管理会計領域の導入を対象とする」のような一文だ。範囲を示しているように見えて、何も閉じていない。財務会計に固定資産が入るのか、入金消込の自動化まで含むのか、税務の申告調整に使う情報の設計が入るのか、この一文からは決まらない。
範囲を閉じるのは、対象の記載でなく除外の記載である。契約書に「範囲外」の列があり、具体的な業務名・モジュール名・システム名が並んでいれば、スコープは閉じている。何も書かれていなければ、境目は全部グレーのまま工程に入る。グレーの領域は要件定義で「当然入っていると思っていた」と「入っていない」がぶつかる場所になり、その衝突は毎回スケジュールを削る。
除外を書くときに効くのは、業務名でなく作業の分解単位で書くやり方だ。「マスタ整備は範囲外」と書くだけでは、どこまでがベンダーの支援でどこからが発注側の作業か決まらない。「項目定義とテンプレート提供はベンダー、データの記入・名寄せ・承認は発注側、投入ツールの提供はベンダー、投入後の内容確認は発注側」と割れば、境目に人が立つ。データ移行は境目が最も多い工程で、ここを曖昧にしたまま進むと、移行リハーサルのたびに「これは誰の作業か」の会議が挟まる（SAP移行のデータ移行で失敗しない｜マスタ品質を上げる進め方）。
もう一つ、除外に必ず書くのが組織構造の再編だ。会社コードや管理領域の設計は稼働後に事実上作り直せないのに、契約時点では「現行組織を踏襲する」の一行で流される。将来の分社やM&Aを見越した設計まで含むのか、現行の写しでよいのかは、金額にも工期にも直結する（SAPの組織構造設計（会社コード・管理領域・利益センタ）｜アドオンで直せない唯一の領域）。
- 対象外のモジュールと業務（例：固定資産の物件管理、原価計算の一部、給与計算）
- 対象外の法人・拠点・国（第二次展開に回す範囲を法人名でなく数と条件で）
- 現行システムの停止・撤去作業と、そのデータ保管の責任
- マスタデータの記入・名寄せ・承認（作業の分解単位で）
- 現行帳票のうち、移行せず廃止する本数と、その選定を誰が行うか
- 業務プロセスそのものの再設計（システム設定と業務改革の線引き）
- 稼働後の運用支援（何か月・何名・どの時間帯まで契約に含むか）
- 教育研修の対象人数、回数、資料の作成主体
成果物定義に合格条件がなければ、その工程は終われない
契約書の別紙に成果物一覧が付いているのは普通だ。要件定義書、基本設計書、詳細設計書、テスト計画書、テスト結果報告書、運用手順書。名前は並んでいる。だが工程が終わらない理由は、成果物が出てこないことではなく、出てきた成果物を「終わり」と判定する条件が書かれていないことにある。
判定条件として最低限必要なのは三つ。提出物の形式と粒度、レビューの回数と期間、そして受領の意思表示の方法だ。粒度が書かれていなければ、要件定義書が箇条書きの一覧で出てきても成果物名は満たされる。レビュー回数が無ければ、発注側は納得するまで指摘を出し続け、ベンダーは修正のたびに工数を積む。受領の意思表示が定義されていなければ、「レビュー会で説明した」だけで工程が終わったことにされるか、逆に半年前の成果物へ今さら指摘が入る。
実装側から見て怖いのは三つ目だ。受領の線が引かれていない成果物は、後工程で仕様が揺れたときに必ず蒸し返される。基本設計を受領しないまま開発に入ったプロジェクトは、テストの段階で設計の議論に戻る。財務領域の受入テストは締めを実際に一巡させて初めて意味を持つので、期間が削られると操作確認だけの形骸化したテストになる（SAPの受入テスト（UAT）で経理は何を見るか｜シナリオの粒度とテストデータの決め方）。
合格条件を書くとき、発注側が一つだけ譲ってはいけないのが要件定義書の書式だ。「機能一覧＋画面イメージ」で受領してしまうと、稼働後に「この帳票にこの項目が出ない」と言われたとき、根拠になる文書が存在しない。要件は業務の出口、つまり最終的に出したい資料と数字から逆算して書式を決める。ここを詰めておくと、後の要件追加の可否判断も機械的に処理できる（SAPの帳票・レポート要件の絞り方｜標準で出す・作る・廃止するの3分類）。
変更管理条項は、判断の期限と決裁者まで書いて初めて効く
変更管理条項はどの契約書にもある。だいたいこう書いてある。「本契約の範囲に変更が生じる場合、甲乙協議のうえ、書面により合意するものとする」。この一文だけで変更管理が回ったプロジェクトは、まず無い。書面の様式も、提出先も、判断の期限も、判断する人も決まっていないからだ。
現場で機能する変更管理の条項には四点が入っている。変更要求票の様式と必須項目、提出から一次回答までの営業日数、金額と工期のしきい値ごとの決裁者、そして期限までに判断されなかった場合の既定の扱い。四つ目が特に効く。判断が出ないまま止まった要求は実装側で「保留」の箱に入り、そのまま設計が進む。後から承認が出ても前提の設計は固まっており、実装のやり直しになる。だから「提出から十営業日以内に判断がない場合、当該変更は不採用として設計を確定させる」と書く。不採用が嫌なら期限内に判断が出る。
変更管理の議論で必ず出るのが、標準機能で足りない部分をどこまで作るかだ。この判断を変更要求の一件ずつでやると、毎回同じ議論を繰り返すことになる。契約時に判断軸と上限本数を決めておけば、個別の要求は軸に当てるだけで処理できる。
体制表は氏名でなく、稼働率と交代条件を読む
提案書の体制表には、プロジェクトマネージャ、アーキテクト、モジュールリード、コンサルタントの名前が並ぶ。発注側はこれを「この人たちが来る」と読む。書いてあるのは役割であって、稼働率ではない。
確認すべきは三点だ。まず各要員の稼働率。「プロジェクトマネージャ 0.3人月／月」と書かれていれば、その人は週に一日半しかこのプロジェクトにいない。次に常駐と遠隔の内訳。要件定義の期間だけ常駐で以降は遠隔という体制は珍しくないが、それを前提に発注側の会議を組む必要がある。最後にキーパーソンの交代条件で、「要員の変更は事前に通知する」としか書かれていなければ、設計の中核を理解している人が翌月に別案件へ移っても通知一本で済む。
導入プロジェクトの品質を最も大きく動かすのは、ツールでも方法論でもなく、財務会計と管理会計の両方を分かっている要員が何割の稼働で何か月いるかだ。ここが薄い体制は、設計書は出てくるが締めが回らない設計になる。だから体制表では、FI／CO領域のリードの稼働率と在籍期間を名指しで固定し、離任時の予告期間と引継ぎ期間を契約に書き込む。二週間の並走を義務づけるだけで、交代のたびに設計が振り出しへ戻る事故はかなり減る。
発注側の体制も同じ精度で書く。ベンダーの前提条件欄に「発注側キーユーザは常駐」と一行あるのに、実際に出せるのは兼務で週二日、というずれは頻発する。このずれは遅延の原因になるうえ、責任の所在も曖昧にする。誰を何割で何か月出すかは、契約の交渉と同時に社内で決着させておく（SAP導入に現場のエースを何ヶ月出すか｜要員供出の判断と抜けた席の埋め方）。
締結前に潰す順番
五つの箇所を同時に見ようとすると、どれも中途半端になる。読む順番がある。
順番に意味があるのは、前の工程の結果が後の工程の入力になるからだ。数量を数えていなければ範囲外は書けず、範囲外が書けていなければ受領条件も書けない。受領条件がなければ変更要求の判断基準が定まらず、判断基準がなければ体制の厚みが足りているかも評価できない。
契約形態の選択も、この順番の中で自然に決まる。数量まで確定している範囲は請負で切れる。確定していない範囲を無理に請負へ押し込むと、ベンダーは見えないリスクを工数に乗せるので単価が上がり、しかも範囲の解釈で揉める。数量が固まらない領域は準委任で進め、固まった時点で請負へ切り替える二段構えのほうが総額は抑えやすい。基盤の持ち方によって契約の対象範囲そのものが変わるため、クラウドか自社運用かの選択も契約の設計と切り離さない（RISE with SAPとオンプレ・自社運用の選択｜クラウド移行をどう決めるか）。
発注側にとって、契約締結の日は交渉力が最も高い日であり、その後は下がり続ける。締結後に発見した抜けは、すべて相手の見積りを通ることになる。だから交渉のエネルギーは、単価の値切りではなく、数量と終わり方の定義に配分する。
