「Fit to Standard」という免罪符 ── 内製開発力を失ったユーザー企業を襲うIT業界の病理とAIの罠
近年、エンタープライズITや製造業向けシステム導入の現場で、「Fit to Standard（F2S：業務をシステムの標準機能に合わせる）」という言葉を耳にしない日はない。
「アドオンを減らし、クリーンコアを維持して、変化に強い組織を作る」
大義名分は美しい。確かに、他社と差別化する必要のない共通業務（経理や総務など）であれば、標準機能に合わせるのが投資対効果（ROI）の面でも正解だ。元が取れるなら独自開発すればいいし、他社と同じでいいなら合わせる。選ぶのはあくまで投資主であるユーザー企業のはずだ。
しかし、現在のIT導入の現場で起きている実態は、そんな高尚な話ではない。
現在の「F2S」は、ユーザーのDXを成功させるための手段ではなく、ベンダーが不完全なパッケージを無理やり使わせ、後から追加費用を合法的にぶったくるための「方便（トラップ）」に変質してしまっている。
牙を剥くF2S：後出しジャンケンと「実機ハレーション」の罠
実態はきわめて悪質だ。F2Sは単なる免罪符ではなく、最初から追加開発費用を発生させるための「マッチポンプの種」として機能しているケースが少なくない。
ベンダーはプロジェクト初期、現場に極力実機を見せない。見せれば「これでは現場が回らない」と拒絶され、契約前の見積もりが膨らんで失注するか、プロジェクトの開始が遅れるからだ。「標準機能でいきます」と美しい絵を描いて経営陣を丸め込み、プロジェクトが後戻りできない段階になって初めて現場にシステムを突きつける。
当然、現場は大ハレーションを起こす。ビジネスが止まる恐怖に直面したユーザー企業に対し、ベンダーは待ってましたとばかりに「追加要件（チェンジリクエスト）」の請求書を差し出すのだ。最初からこうして追加費用を毟り取るシナリオ（後出しジャンケン）が組まれているのである。
今のSEの致命的な能力不足と「言質取り」の免責ゲーム
なぜこんなことが起きるのか。理由は明白で、今のSEの圧倒的な「能力不足」に起因している。
顧客の複雑な業務の本質（なぜそのプロセスが必要なのか）を理解し、パッケージとのギャップを埋める提案ができる骨のある上流エンジニアは、今やIT業界で絶滅危惧種だ。マニュアル通りにパラメータを設定することしかできない彼らがやっているのは、仕様の「仕分け」と、後から責任追及されないための「証拠集め」だけである。
彼らは要件定義の場で、ユーザーの意図をわざと狭く解釈して、誘導尋問のようなミスリードを仕掛ける。無理のある代替案に対し「これで回せますよね？」とYESを言わせ、議事録にサインをさせる。 後から現場が「使えない」と騒ぎ出すと、彼らはこう言い放つのだ。 「あの時、情報システム部門の〇〇さんが合意しましたよね？ 言質は取っています。ひっくり返すなら追加費用です」
もはやこれはエンジニアリングでも何でもない。単なる「免責のための契約ゲーム」だ。
丸腰のユーザーが、いかにしてベンダーを「縛り付ける」か
現場が最も苦しいのは、長年のアウトソーシングによって「社内に開発能力（内製化の基盤）が残っていない」という構造的弱点がある点だ。手を動かせないユーザーは、どれだけ理不尽でもベンダーの言いなりになるか、プロジェクトを頓挫させるかの二択を迫られる「人質」の状態にある。
この状態で、ユーザー側はどう防衛すべきなのか。ベンダーの「後出しジャンケン」を封じるための現実的な解は、契約の「座組み」と「フェーズの切り離し」にある。
- 一括契約を拒否し、徹底的な「工程単位の分割契約」にする 要件定義、基本設計、開発・テストといった工程ごとに別契約（多段階契約）を結ぶ。「次の工程に進むかどうかは、前の工程の成否を見てユーザーが判断する」という主導権を握るのだ。これにより、要件定義の段階で「ポンコツなパッケージを押し付けようとしている」「SEがミスリードを連発している」と見限れば、そこでベンダーを「損切り（契約終了）」できるカードを握れる。
- 「完了要件」に、ユーザーの『判断支援』を義務付ける 各工程の「成果物」の定義と「完了要件」をガチガチに絞り込むのは基本だが、丸腰のユーザーは成果物（膨大な仕様書やパラメータシート）を見せられても、それが正しいかを自力で判断できない。 だからこそ、契約書やSOW（業務記述書）のベンダーの役務に、「ユーザーが仕様の適否を正しく理解し、判断できるようにするための支援業務（メリット・デメリットの提示、実機によるビジュアルなデモ、業務影響の解説など）を行うこと」を明記させる。これが不十分で現場が判断できなかった場合は「工程完了と認めない（次のお金は払わない）」という縛りをかける。
- 契約時点で「標準機能」の定義を厳密に握る： 「標準機能で対応可能」という言葉を絶対に鵜呑みにせず、「追加費用なし、設定（パラメータ変更）のみで、指定した主要業務シナリオが現場に耐えうる運用で回ること」を明記し、それを支払い条件と連動させる。
内製開発力のない企業がシステムを刷新するなら、最初の契約の時点で、相手の首にどれだけ強固な鎖を巻きつけておけるかが勝負のすべてだ。
AI・RAGの導入でも、全く同じ「悲劇」を繰り返してはならない
私は最近、ディープラーニング（深層学習）の理論や、現在執筆中であるRAG（外部知識検索によるAI拡張）に関する書籍を通じて、先端技術のビジネス実装について発信を続けている。その中で強く危機感を抱いているのは、この「F2Sの欺瞞」と全く同じ構造が、今まさにAI導入の現場でも起き始めているという点だ。
生成AIプラットフォームや既製のRAGパッケージを売るベンダーは、こう甘く囁く。「当社の標準的なRAGパッケージを導入すれば、明日から社内データを使った高度な業務効率化が可能です」と。
しかし、蓋を開けてみれば、ハルシネーション（もっともらしい嘘）の制御が甘かったり、自社特有の専門用語や複雑なドキュメント構造に全く適合せず、現場では使い物にならないケースが多発している。その時、技術力や業務理解の浅いAIベンダーは、またしてもあの言葉を「方便」として使うだろう。 「これは生成AIの仕様です。AIの回答精度に合わないのは、御社のドキュメントがレガシーだからです。業務の進め方やデータの形をAIに合わせて変えてください（Fit to AI）」
不完全なパッケージや、精度チューニングを泥臭くやりきる技術力のなさを、バズワードで隠蔽する──。これは、現在のERP導入で起きていることの完全な焼き直しだ。
AIやRAGは、企業のデータという「独自の強み（飯の種）」を最大化するための強力な手段だ。だからこそ、ここでも「元が取れるなら自社で泥臭く作り込み、他社と同じでいい汎用的な部分はパッケージに合わせる」というユーザー主導の冷徹な判断が求められる。
社内に技術の「目利き」ができる能力を残し、ベンダーの都合のいいバズワードに会社の大切な業務やデータをねじ曲げられないようにする。システム刷新であれ、AI導入であれ、私たちユーザー企業が戦うべき本質は、何一つ変わっていない。