「うちでしか直せません」と言われたときの対処法

見積もり交渉の場で、開発会社の担当者からこう言われたことはないでしょうか。「このシステムは、うちでないと直せません」。あるいは、機能追加の相談をしたら「弊社独自の作り込みが多いので、他社では対応が難しいと思います」と念を押されたこと。保守費の値上げに疑問を伝えたら、「他に頼める会社はなかなか見つからないと思いますよ」と、やんわり牽制されたこと。

こう言われた瞬間、多くの担当者は言葉を失います。反論する材料がないからです。事実として、その開発会社以外にシステムの中身を知っている人間はいない。ソースコードの構造も分からなければ、他社に見積もりを頼んでも「一から作り直すレベルの費用になる」と言われるかもしれない。結局、提示された金額をのむしかないのか、と諦めてしまう。

しかし、「うちでしか直せません」という言葉は、それ自体が交渉の一手段でもあります。事実として本当にそうである場合もあれば、実際には他社でも十分対応可能なのに、心理的な圧力として使われている場合もあります。どちらのケースであっても、担当者がその場でできることは共通しています。この記事では、この言葉を言われた直後にできる初動対応と、二度と同じ状況で立ち尽くさないための中長期的な対策を、順を追って解説します。

• 言われた直後にすべきこと: その場で契約を切らずにできる3つの確認
• 本当に「うちでしか直せない」のかを見極める方法: 技術的な根拠と心理的な圧力の切り分け方
• 今すぐ始められる交渉の材料集め: 契約書・データ・ドキュメントの3方向から
• 中長期的な対策: 二度と同じ立場に立たないための備え

先に断っておきたいのは、この記事は「今すぐ開発会社と縁を切れ」と煽る内容ではないということです。長年付き合ってきた開発会社との関係が悪いとは限りませんし、実際に技術的な事情から他社対応が難しいシステムも存在します。重要なのは、その状態を漠然とした恐怖のまま放置せず、事実に基づいて自社の立ち位置を把握することです。

なお、この記事の運営元である株式会社ゼットリンカーはシステムの受託開発を事業としており、開発会社を乗り換える際の受け皿になり得る立場でもあります。ただし、ここで書く内容は特定のベンダーや契約形態を推奨するものではなく、公正取引委員会の実態調査など公的な一次情報に基づいた中立的な整理であることを断っておきます。自社に不利な情報であっても、事実として重要であれば書きます。

この記事で分かること

「うちでしか直せません」と言われた担当者が、その場で感情的に反論したり、逆に諦めて言い値を受け入れたりする前に取るべき行動を整理します。まず、その言葉が出た直後の初動対応(契約を切らずにできる事実確認)を示し、次に、その主張が技術的に妥当なのか、心理的な圧力に近いのかを見極める観点を解説します。そのうえで、今日から始められる交渉材料の集め方と、二度と同じ状況に陥らないための中長期的な備えまでを扱います。

すでにこの言葉を言われて困っている方はもちろん、まだ言われてはいないが「もし言われたら断れないだろうな」と薄々感じている方にも読んでいただきたい内容です。この手の交渉力の格差は、平時に準備しているかどうかで大きく変わります。

「うちでしか直せません」と言われた直後にすべき3つのこと

まず、この言葉を言われた場でやってはいけないことから確認します。それは、感情的に反発することと、逆にその場で条件を全部のんでしまうことの両方です。どちらも、後から振り返って交渉の余地を狭める行動になります。

その場でやるべきことは、次の3つです。

1. 即答を避ける: 「持ち帰って検討します」と伝え、その場での契約や値上げの承諾を避ける
2. 発言の根拠を尋ねる: 「うちでしか直せない理由を、技術的な観点で教えてください」と質問し、回答を記録する(メールで確認する形が望ましい)
3. 代替案の有無を確認する: 「他社でも対応可能な範囲と、御社でなければ難しい範囲を分けて教えてください」と尋ねる

この3つに共通するのは、いずれも相手との関係を損なわずにできる、事実確認としての質問だという点です。感情的な対立を避けながら、「なぜそう言えるのか」の根拠を相手自身の言葉で残しておくことが、後の交渉の土台になります。

「うちでしか直せません」という発言そのものよりも重要なのは、その根拠を担当者本人がどれだけ具体的に説明できるかです。技術的に妥当な説明ができる場合と、曖昧なまま「長年の経緯があるので」としか言えない場合とでは、状況はまったく違います。

この段階では、開発会社を疑ってかかる必要はありません。事実として本当に技術的な制約がある可能性は十分にあります。目的は対立ではなく、状況を正確に把握することです。

その主張は本当に技術的な制約なのか、心理的な圧力なのか

「うちでしか直せません」という主張には、大きく分けて2つの背景があります。1つは、技術的に本当に他社対応が困難な状態、もう一つは、技術的には対応可能でも心理的な依存関係を利用した交渉上の主張です。この2つを切り分けることが、次に取るべき行動を決めるうえで欠かせません。

技術的な制約が本当に存在する場合、多くは次のような具体的な理由が伴います。

• ソースコードの著作権や利用許諾が開発会社側にあり、他社が中身を確認する権利自体がない
• 開発会社独自のフレームワークやライブラリを使っており、一般的な技術者では読み解けない
• システムのオンプレミスサーバーやネットワーク構成が特殊で、現地作業を伴う調査が必要
• データベースの設計やAPI連携が複雑で、仕様書なしでは全体像の把握に相応の期間がかかる

一方、心理的な圧力に近いケースでは、具体的な技術的根拠が示されず、次のような言い回しにとどまることが多くなります。

この表はあくまで傾向であり、実際にどちらに当てはまるかは、個別の事情によって変わります。重要なのは、発言を鵜呑みにせず、次の章で示す方法で実際に裏取りをすることです。

今すぐ始められる交渉材料の集め方(契約書編)

技術的な妥当性を判断する材料は、多くの場合、契約書の中にすでに存在しています。まず確認すべきは、次の3点です。

第一に、システムの著作権・利用許諾がどちらに帰属しているかです。フルスクラッチ開発で開発されたシステムの場合、契約書に「著作権は甲(発注者)に帰属する」と明記されていれば、少なくとも権利上は他社に見せる・改修を依頼することに問題はありません。逆に「著作権は乙(開発会社)に留保する」となっている場合、法的にはソースコードの開示や改変を求める根拠が弱くなります。

第二に、保守契約の内容です。対応範囲(無償/有償の境界)、対応時間の目安、契約解除の条件が明記されているかを確認します。対応時間の目安、いわゆるSLA（サービス品質保証）が契約書に存在しない場合、「対応が遅い」「値上げされた」という不満があっても、契約違反として指摘する根拠が弱くなります。

第三に、契約の解除条項です。多くの保守契約は自動更新の条項を含んでいますが、解除の申し出期限(「契約満了の何ヶ月前までに書面で通知」など)が定められていることが一般的です。この期限を過ぎると、望まない形で1年間の契約継続が確定してしまうことがあります。

• 著作権・利用許諾の帰属条項を確認する
• 保守契約の対応範囲とSLAの有無を確認する
• 解除条項と通知期限を確認する
• 契約書自体が見当たらない場合は、開発会社に控えの提供を依頼する(この依頼自体を断られることは通常ない)

契約書が全く見つからない、あるいは口頭契約のまま何年も更新され続けているという状態も、中小企業では珍しくありません。その場合は、次の章で扱うデータ・ドキュメント面での確認を先に進め、契約書は開発会社に開示を依頼するところから始めます。

今すぐ始められる交渉材料の集め方(データ・ドキュメント編)

契約書と並行して確認したいのが、システムそのものに関する情報です。ここでの目的は、「本当に他社では対応できないシステムなのか」を、自社の目で確かめる材料を集めることです。

まず、業務データを自社で保持できているかを確認します。基幹システムやSaaSに保存されているデータを、CSVなど汎用的な形式でエクスポートできるかどうかは、データポータビリティと呼ばれる概念で説明されます。データポータビリティが確保されていれば、たとえシステム本体を他社に移管できなくても、少なくとも業務データを失わずに次のシステムへ引き継ぐ選択肢が残ります。

次に、仕様書・設計書の有無を確認します。仕様書が存在すれば、他社の技術者に見せることで「対応可能かどうか」の一次的な判断材料になります。仕様書がない場合でも、次のような周辺情報だけで概算の相談ができることは多くあります。

• システムの利用人数・データ量の目安
• 使用している主要な技術(言語・フレームワーク・データベースの名称程度でよい)
• 現在困っている具体的な症状(動作が遅い、特定の処理でエラーが出る等)
• サーバーが自社所有かクラウドか、オンプレミスであれば設置場所

これらの情報を1枚にまとめておくと、複数の開発会社に同時に相談する際の説明コストを大きく下げられます。この整理作業自体がシステム管理台帳の第一歩にもなります。台帳が既にある場合は、対象システムの記載を最新化するところから始めてください。

相見積もりを取る際によく聞かれる質問への準備として、以下の表も参考にしてください。

相見積もりを取ることは「裏切り」ではない

多くの担当者が相見積もりをためらう理由は、今の開発会社との関係が悪化することへの不安です。しかし、相見積もりを取ること自体は、契約解除を意味しません。市場価格や技術的な選択肢を把握する目的で他社に相談することは、健全な経営判断の一部です。

相見積もりを取る際に気をつけたいのは、タイミングと伝え方です。

• 今の開発会社に契約解除の意思を伝える前に、相見積もりを済ませておく
• 相見積もり先には、現在の開発会社名を明かす必要はない(「既存システムがあり、保守・改修先を検討している」で十分)
• 複数社から見積もりを取る際は、同じ条件(現状のシステム概要・依頼したい範囲)を揃えて提示する
• 見積もりの単価だけでなく、SOW（作業範囲記述書）に相当する作業範囲の記載があるかも比較する

相見積もりの結果、「今の開発会社の金額が妥当だった」と分かることもあります。それでも、この確認作業には意味があります。漠然とした不安のまま言い値を受け入れるのと、他社と比較したうえで妥当と判断するのとでは、次に同じ交渉が発生したときの心理的な立ち位置がまったく違うからです。

相見積もりの目的は「安い会社を探すこと」だけではありません。「今の契約が市場相場から外れていないか」「他に選択肢があるという事実そのもの」を確認することにも価値があります。

開発会社側の事情も理解しておく

ここまで発注者側の対処法を中心に解説してきましたが、開発会社側の事情も理解しておくと、交渉の進め方がより現実的になります。

「うちでしか直せません」という発言の背景には、開発会社側の合理的な事情が存在することも少なくありません。長年保守を担当してきたシステムは、担当者の頭の中に蓄積された業務知識(なぜこの仕様になっているか、過去にどんな障害があったか)が多く、それをドキュメント化するコストを開発会社側が負担していないケースがほとんどです。他社が同じ水準で対応するには、相応の調査期間と費用がかかるのは事実です。

また、中小企業向けのシステム開発を担う会社の多くは、決して大きくない組織で、少人数の技術者が複数の顧客システムを掛け持ちしています。新規の相談を受けても、既存の保守業務で手一杯という事情から、結果として「対応できるのはうちだけ」という状態が固定化してしまうこともあります。

このような背景を理解したうえで交渉に臨むと、一方的に相手を「悪者」として扱うのではなく、「双方にとって持続可能な形にするには何が必要か」という建設的な話し合いに持ち込みやすくなります。たとえば、ドキュメント化の費用を発注者側が一部負担する代わりに、著作権や仕様書の開示について合意するといった折衷案も現実的な選択肢です。

交渉がうまくいかない場合のエスカレーション

契約書の確認、データの整理、相見積もりを経てもなお、開発会社が著作権や仕様の開示に一切応じない、あるいは高圧的な態度を崩さない場合は、担当者個人での交渉に限界が来ている状態です。この段階では、社内でのエスカレーションを検討します。

具体的には、次のような選択肢があります。

• 上長・経営層に状況を報告し、組織としての交渉に切り替える
• 弁護士に契約書の確認を依頼する(特に著作権の帰属条項が曖昧な場合)
• 中小企業向けの相談窓口(商工会議所・よろず支援拠点など)に相談する
• 契約不適合責任に該当する不具合がある場合は、その根拠を整理して主張する

一人の担当者が「言われるがまま」の状態から抜け出すには、組織としての後ろ盾が必要になる場面があります。ひとりで抱え込まず、早い段階で上長を巻き込むことも、有効な交渉戦略の一つです。

相談先をどう選ぶか。社内で判断がつかないときの選択肢

契約書の文言解釈や、著作権の帰属が曖昧なケースでは、担当者ひとりで判断しきれない場面が出てきます。そのようなときに、どこに相談すればよいかを整理しておきます。

まず、契約書の解釈に法的な疑義がある場合は、弁護士への相談が最も確実です。顧問弁護士がいない中小企業でも、都道府県の弁護士会が実施している法律相談や、商工会議所・商工会が窓口となっている専門家派遣制度を利用できることがあります。相談費用が発生する場合が一般的ですが、契約更新のタイミングで数万円の相談費用をかけて条項を確認しておくことは、その後何年も続く保守費用の総額から見れば小さな投資です。

次に、技術的な妥当性(本当に他社対応が困難なシステムなのか)を確認したい場合は、複数の開発会社に相談すること自体が最も実践的な手段になります。多くの開発会社は、初回の相談・概算見積もりの提示を無料で受けています。ここで気をつけたいのは、1社だけの意見を鵜呑みにしないことです。ある会社が「対応可能」と答え、別の会社が「難しい」と答えることは珍しくなく、技術者によって得意分野や経験が異なるためです。3社程度に相談し、共通する見解と分かれる見解を比較することで、より客観的な判断に近づけます。

また、公的な相談窓口として、独立行政法人中小企業基盤整備機構が運営する「よろず支援拠点」のように、経営全般の相談を無料で受け付けている機関もあります。IT分野に特化した相談ではありませんが、契約や取引に関するトラブルの相談先として、まず話を聞いてもらう入口として活用できます。

• 契約書の法的解釈: 弁護士会の法律相談・商工会議所の専門家派遣制度
• 技術的な妥当性の確認: 複数の開発会社への相談(3社程度を目安に)
• 経営判断としての整理: よろず支援拠点などの公的相談窓口
• 社内の意思決定: 上長・経営層への早期の状況共有

相談先を使い分けることで、担当者ひとりが抱え込む負担を減らしながら、判断の精度を上げていくことができます。

ケース別に見る対処のシミュレーション

ここまでの原則を踏まえて、実際によくある3つの場面ごとに、どう対応するかを具体的に見ていきます。状況によって優先すべき行動が変わるため、自社の状況に近いものを参考にしてください。

ケース1: 保守費の値上げを一方的に打診された場合

まず、値上げの理由を書面で説明してもらうよう依頼します。物価上昇や人件費の高騰など、業界全体の事情であれば、ある程度は受け入れざるを得ない場合もあります。しかし、理由が曖昧なまま「今後もお付き合いいただくなら」といった言い回しにとどまる場合は、心理的な圧力の可能性を疑います。このケースでは、値上げの回答を保留しつつ、並行して相見積もりを進めるのが現実的な進め方です。相見積もりの結果が出るまでの間、値上げへの回答を急がされても、「他社の状況も踏まえて総合的に判断したい」と伝えれば、通常は数週間の猶予を確保できます。

ケース2: 新機能の追加を「対応できない」と断られた場合

この場合は、断られた理由が技術的な制約なのか、リソース(人手・スケジュール)の制約なのかを切り分けます。前者であれば、他社に相談する価値があります。後者であれば、開発会社は「対応したいができない」状態である可能性が高く、納期の調整や優先順位の相談によって解決できることもあります。いずれにしても、「対応できない」という回答をそのまま受け取るのではなく、理由を具体的に確認する一手間が、次の判断材料になります。

ケース3: 開発会社の担当者が退職し、急に対応が悪くなった場合

このケースは、これまで見えていなかった属人化が表面化した状態です。開発会社側の組織内でも引き継ぎが不十分だった可能性があり、開発会社自身も本来の対応品質を出せていない場合があります。まずは新しい担当者とのコミュニケーションを密にし、過去の経緯を共有する時間を意図的に確保することが有効です。同時に、この機会に自社側のシステム管理台帳を整備し、開発会社の担当者が誰であっても業務が回る状態を作る好機と捉えることもできます。

よくある失敗パターンと避け方

最後に、この種の交渉で担当者が陥りやすい失敗パターンを整理します。あらかじめ知っておくことで、同じ轍を踏まずに済みます。

• 感情的な対立に発展させてしまう: 「うちでしか直せません」という発言に腹を立て、強い言葉で反論してしまうと、その後の建設的な話し合いが難しくなります。事実確認に徹する姿勢を保つことが重要です
• 相見積もりの結果を交渉の材料として使わない: せっかく他社から見積もりを取っても、それを今の開発会社との交渉に活用しないまま終わってしまうケースがあります。相見積もりの結果は、条件交渉の具体的な根拠として提示することで初めて意味を持ちます
• 契約解除を先に伝えてしまう: 移行先が決まっていない段階で契約解除の意思を伝えると、残りの保守期間で開発会社の対応の質が下がるリスクがあります。移行の見通しが立ってから伝えるのが基本です
• すべてを一度に変えようとする: 著作権の帰属、SLA、データエクスポート、契約解除条項など、見直したい項目が複数ある場合、一度にすべてを要求すると開発会社側も強い警戒感を持ちます。優先度の高いものから段階的に交渉するほうが、実際には合意に至りやすくなります
• 社内の合意形成を後回しにする: 担当者個人の判断で交渉を進めた結果、経営層への説明が後手に回り、いざというときに組織としての意思決定が間に合わないことがあります。相見積もりの段階から、上長への簡単な状況共有を並行して進めておくことをおすすめします

これらはいずれも、技術力や交渉力の問題というより、進め方の順序やタイミングの問題です。順序さえ間違えなければ、ひとり情シスや総務兼任の担当者であっても、この種の交渉を十分に乗り切ることができます。

中長期的な対策: 二度と同じ状況に立たないために

その場しのぎの交渉が一段落したら、次に取り組みたいのが、同じ状況を繰り返さないための構造的な対策です。これは一朝一夕にはできませんが、次の3つを少しずつ進めることで、数年単位で交渉力を取り戻していくことができます。

第一に、システム管理台帳の整備です。稼働しているシステムの名称、開発・保守を担う会社、契約内容、著作権の帰属、データの保存場所を一覧化しておくことで、次に同じような発言をされたときに、その場で契約書を探し回る必要がなくなります。

第二に、契約更新のタイミングでの条項見直しです。次回の契約更新時には、著作権の帰属、SLA、データエクスポートの可否について、明文化されていない項目があれば追記を交渉します。すべてを一度に変更しようとすると開発会社側も身構えてしまうため、優先度の高い1〜2項目から着手するのが現実的です。

第三に、マルチベンダーの可能性を検討することです。すべての領域を1社に集約するのではなく、領域ごとに複数の開発会社と付き合う体制に少しずつ移行することで、1社への依存度を構造的に下げられます。ただし、これは会社間の連携不足や責任の所在の曖昧化という別のリスクも伴うため、段階的に進めることをおすすめします。

• システム管理台帳を作り、依存度の高いシステムから優先的に記載する
• 次回の契約更新時に、著作権・SLA・データエクスポートの条項を見直す
• 新規の発注案件から、複数社に相談する習慣をつける
• 社内でシステムの概要を説明できる担当者を、自分以外にも増やしておく(属人化の防止)

これらの対策は、どれもすぐに成果が出るものではありません。しかし、「うちでしか直せません」という言葉に対して、今日は沈黙するしかなくても、1年後、2年後には「では、この条件で他社にも相談してみます」と自然に返せる状態を作ることができます。ロックインからの脱出は、一度の交渉で決着するものではなく、平時の備えの積み重ねによって少しずつ実現するものです。

まとめ: 今すぐできることから始める

「うちでしか直せません」と言われたとき、その場でできることは限られています。しかし、限られているからといって何もできないわけではありません。即答を避け、根拠を尋ね、契約書とデータを確認し、相見積もりを取る。この一連の行動は、どれも今の開発会社との関係を壊さずに実行できます。

そして、その経験を次に活かすために、システム管理台帳の整備や契約条項の見直しといった中長期的な備えに着手することで、同じ状況に二度と立ち尽くさないための土台ができていきます。今日からできる最初の一歩は、まず自社が使っているシステムの契約書を、もう一度読み返してみることです。

次の記事では、開発会社を実際に乗り換える際に必要な引き継ぎ資料の具体的な一覧を解説しています。相見積もりの結果、乗り換えを検討する段階に進んだ場合は、あわせて確認してください。