創業時に依頼した開発会社としか付き合いがない状態から抜け出す準備

社員が30人を超えたあたりで、あなたは初めて「情シス」の看板を持たされました。引き継いだシステムの保守を依頼している開発会社は、創業した年から変わっていません。社長や古参社員に聞くと「昔からお世話になっている〇〇さん」という答えが返ってくるだけで、なぜその会社に頼み続けているのか、他に選択肢を検討したことがあるのかは誰も覚えていません。

この記事は、そうした「創業時からの一社依存」という状態そのものを、良い・悪いで即断せずに棚卸しするための準備ガイドです。結論を先に言うと、一社依存から抜け出す第一歩は「今すぐ他社に乗り換える」ことではありません。乗り換えるかどうかを判断できる材料を手元に揃え、いつでも動ける状態を作ることが最初の目標です。材料がないまま焦って動くと、かえって業務を止めるリスクが高まります。

なぜ「一社依存の履歴」を棚卸しする必要があるのか

創業から10年、20年と同じ開発会社に依頼し続けている状態そのものは、必ずしも問題ではありません。長期間の付き合いには、自社の業務を深く理解してもらえている、緊急時に融通が利く、といった利点もあります。ベンダーロックインという言葉は否定的に語られがちですが、意図的に一社へ集約し、その関係の質を高めてきた結果であれば、それは経営判断として合理的な選択でもあります。

問題になるのは、「選んだ結果として一社に依存している」のではなく、「他に選択肢があることすら認識しないまま、惰性で一社に依存し続けている」状態です。この2つは外見上は同じ「一社しか付き合いがない」状態に見えますが、内実はまったく異なります。前者はいつでも切り替えの検討ができる状態、後者は切り替えという選択肢自体が思考の外に置かれている状態です。

ひとり情シスとして最初に着任したあなたの役割は、まず自社がどちらの状態にあるのかを見極めることです。これは「今の開発会社を切るべきかどうか」を判断する話ではなく、「切るという選択肢を持てているかどうか」を確認する話だという点を、社内で説明する際にも強調してください。この違いを理解してもらえないと、「今の開発会社に不満でもあるのか」という誤解を招き、社内調整が難航しやすくなります。

30-100人規模特有の事情: 属人的な関係と組織の非対称

30-100人規模で一社依存が続く背景には、0-10人・10-30人規模とは異なる特有の事情があります。創業期は社長自身が開発会社の担当者と直接やり取りし、信頼関係を築いてきました。しかし会社が成長し、社長が現場を離れる一方で、開発会社とのやり取りは「昔からの窓口」である社長個人の人脈に依存したままになっているケースが多く見られます。

• 契約の主体と実態の窓口がずれている: 契約書上は法人対法人でも、実際の連絡・交渉は社長個人の携帯電話やメールで行われている
• 組織としての交渉力が育っていない: 開発会社側は担当者が複数人体制になっている一方、自社側は「社長が話せば何とかなる」という属人的な関係のまま
• 他社への相見積もりを取った経験がない: 創業以来、一度も競合に見積もりを依頼したことがなく、今の費用や対応品質が妥当かどうかの比較軸を持っていない

社長個人が窓口である限り、あなたがひとり情シスとして間に入ろうとしても、開発会社側からは「新しい担当者」としてしか認識されず、既存の関係の蓄積を引き継げないという壁にぶつかります。この「窓口の一極集中」自体は創業期からよく見られる構造で、その段階でのリスクと備え方は開発会社とのやり取り担当が社長ひとりという状態のリスクと備えで扱っていますが、30-100人規模では窓口を分散させるだけでなく、組織としての交渉力そのものを育てる視点が必要になります。

もう一つ、30-100人規模ならではの事情として見逃せないのが「システムの利用者が社内に広がっている」という点です。0-10人規模であれば社長自身がシステムのほぼ全機能を使い、10-30人規模でも数名程度の関係者に閉じていたのに対し、30-100人規模では営業・製造・経理など複数部署の日常業務がそのシステムに乗っています。つまり一社依存を見直す作業は、あなた個人と開発会社の関係の話ではなく、社内の複数部署の業務継続性に関わる話に格上げされています。この規模感の違いを自覚しておかないと、「情シス担当が個人的に開発会社との関係を気にしている」程度の温度感でしか社内に伝わらず、後述する社内調整の場面でつまずきやすくなります。

自社の依存度を測る簡易チェック

本格的な棚卸しに入る前に、自社が「思考停止的な一社依存」にどの程度当てはまるかを、次の項目でざっと自己診断してみてください。当てはまる項目が多いほど、この後のステップに時間をかける価値が高くなります。

• 現在の開発会社以外に、過去5年以内に見積もりを依頼したことがない
• 契約書・仕様書一式がどこにあるか、担当者であるあなた自身がまだ把握できていない
• 開発会社とのやり取りの窓口が、社長または特定の1人に集中している
• 「もしその開発会社が廃業したら」を具体的に想像したことがない
• 保守費用が毎年どのように改定されているか、根拠を説明できる人が社内にいない

これらはいずれも、実際に乗り換えるべきかどうかとは無関係に、単に「選択肢を持てているか」を測る項目です。3つ以上当てはまる場合は、この記事で示すステップを一通り実施することを推奨します。

ステップ1: 依存の履歴を時系列で書き出す

最初の作業は、判断や評価をせず、事実だけを時系列で書き出すことです。次の3つの問いに答える形で、簡単な年表を作ってください。

1. いつから、その開発会社に依頼しているか: 創業時からか、途中から切り替えたのか。切り替えた経緯があるなら誰が決めたか
2. 契約範囲は当初から変わっていないか: 最初は簡単なホームページ制作だけだったのが、いつの間にか基幹システムの保守まで任せるようになっていないか
3. 窓口となる担当者は何人いて、誰が社内の誰と連絡を取っているか: 社長個人か、特定の部署の担当者か、それとも複数の窓口が並立しているか

この年表を作る過程で、属人化の実態が見えてきます。多くの場合、「なぜこの会社に頼んでいるのか」という理由そのものが、特定の個人の記憶の中にしか残っていません。属人化した経緯を洗い出す作業自体が、そのまま最初の棚卸しになります。より広い範囲でシステム全体の属人化を調査する手順は、30-100人規模で複数部署から集まる野良システムの棚卸し優先順位で詳しく扱っているので、あわせて参照してください。

年表を作る際は、次のような簡単な表形式にまとめると、後から見返しやすくなります。

この表を埋めようとすると、多くの欄が「不明」「記録なし」で埋まることに気づくはずです。それ自体が問題ではなく、むしろ「今、何が分かっていないのか」を可視化できたという意味で、これがステップ1の成果です。分からない項目を無理にその場で埋めようとせず、まずは全体像の骨格を作ることを優先してください。

ステップ2: 契約範囲の「なし崩し的な拡大」を確認する

年表を作る中で特に注意して確認すべきなのが、契約範囲がなし崩し的に拡大していないかという点です。創業期に依頼した内容は簡単なウェブサイト制作だったのに、その後の口約束や単発の追加依頼が積み重なり、気づけば基幹業務のシステム全体をその一社に依存する状態になっている、というパターンは珍しくありません。

この拡大自体が悪いわけではありません。信頼できる相手に業務を集約すること自体は合理的な判断です。問題は、契約書やSOW（作業範囲記述書）（作業範囲記述書）がその実態に追いついておらず、「実際に何をどこまで任せているか」が文書化されていない状態です。文書がないまま関係が続くと、いざ他社への切り替えを検討したときに、何を、どこまで引き継ぐ必要があるのかの全体像すら把握できません。

契約範囲が口頭の積み重ねで拡大した状態は、開発会社側にとっても「どこまでが正式な契約範囲か」が曖昧になりやすく、トラブル時の責任の所在があいまいになるリスクを双方が抱えています。

契約書や仕様書そのものが見当たらない場合は、まずそちらの復元を優先してください。復元の具体的な手順は30-100人規模で基幹システムの契約書・仕様書が見当たらないときの復元手順にまとめています。

契約範囲の拡大を確認する際、あわせて見ておきたいのが「口頭合意の積み重ね」がどのくらいあるかです。メールやチャットのやり取りの中に「じゃあ、そのままお願いします」といった簡潔な合意だけが残っていて、正式な発注書や見積書に反映されていない作業が、想像以上に多く見つかることがあります。これらは金額的には小さくても、積み重なると契約の全体像を歪める要因になるため、可能な範囲でリストアップしておくと、後の交渉や引き継ぎの場面で役立ちます。

ステップ3: 「なぜ変えられないか」を技術要因と心理要因に分ける

一社依存から抜け出す準備を進める中で、多くの担当者が「変えたくても変えられない」という感覚にぶつかります。この感覚を放置すると、選択肢を持つための準備そのものが止まってしまうため、「変えられない理由」を技術要因と心理要因に分けて整理することが有効です。

技術要因については、開発会社を変えたいのに変えられない理由。ロックインの構造を分解するで5つの構造要因(技術・データ・契約・費用感・心理)に分解した解説をしています。自社がどの要因で止まっているのかを特定すると、次に何を調べればよいかが具体的になります。

心理要因については、「一社依存からの脱却=乗り換え」という誤解を解くことが最も効果的です。この記事で一貫して強調している通り、目指すのは選択肢を持つ準備であり、実際に乗り換えるかどうかは別の判断です。準備を進めること自体は、既存の開発会社との関係を損なう行為ではありません。

ステップ4: 選択肢を持つための最低限のデータを揃える

技術要因を解消する具体的な作業として、以下の3点を優先的に確認してください。いずれも「今すぐ乗り換える」ためではなく、「乗り換えるという選択肢が実際に存在するか」を確認するための調査です。

• ソースコードの権利の所在: 契約書に著作権の譲渡条項があるかどうかを確認します。譲渡条項がなければ、著作権法上、原則として著作権は開発会社側に残ります。確認方法はソースコードの著作権は誰のもの？契約書の確認ポイントを参照してください
• データのエクスポート可否: 業務データを汎用的な形式(CSV等)で取り出せるかどうかを確認します。自社システムのデータを吸い出せるか確認する方法に具体的な確認手順があります
• 現在の費用が相場から見てどうか: 一度も相見積もりを取ったことがない場合、今の保守費が高いのか妥当なのかの判断軸自体がありません。月額保守費の相場と見直し方を読み、まずは自社の支払い構造を可視化するところから始めてください

この3点が揃えば、「今の開発会社と関係を続ける」「一部の業務だけ他社に分散する」「将来的に全面的に切り替える」のいずれを選ぶにしても、判断材料としては十分です。逆に、この3点が揃っていない状態で乗り換えの検討に踏み切ると、想定外のコストやトラブルに直面するリスクが高くなります。

3点の調査には、それぞれ想定しておくべき所要期間の目安があります。契約書の確認だけであれば数日から1週間程度で済むことが多い一方、データのエクスポート可否の確認は、実際に開発会社へ依頼して試験的にエクスポートしてもらう必要がある場合、数週間かかることもあります。相見積もりの取得はさらに時間がかかり、候補となる開発会社を探し、要件を伝え、見積もりを受け取るまでに1〜2ヶ月を見込んでおくと現実的です。本業と兼任しながら進める以上、この3点をすべて同時並行で進めるのではなく、契約書の確認から着手し、時間のかかる調査ほど早めに依頼だけは出しておく、という順序を意識してください。

一社依存は「マルチベンダー化」だけが解ではない

一社依存の解消というと、複数の開発会社に分散して発注するマルチベンダー体制を思い浮かべる人も多いですが、これは唯一の解決策ではありません。マルチベンダー体制には、責任の所在が曖昧になる、会社間の連携コストがかかるといったデメリットもあります。自社の規模や体制によっては、一社に集約したまま、その関係の透明性と交渉力を高める方が現実的な場合もあります。

マルチベンダー体制のメリット・デメリットを整理したマルチベンダー体制のメリット・デメリットを読んだ上で、自社にとって「選択肢を持つ」ことの具体的な意味が、完全な乗り換えなのか、一部業務の分散なのか、それとも今の関係の透明化なのかを見極めてください。

社長・経営層への伝え方

ひとり情シスとしてこの準備を進める際、最も気を使うべきは経営層、特に長年その開発会社と付き合ってきた社長への伝え方です。いきなり「今の開発会社を見直すべきです」と切り出すと、社長個人の人間関係への批判と受け取られかねません。

伝え方のポイントは、次の3つを意識することです。

1. 「乗り換えの提案」ではなく「リスク管理の一環」として説明する: 契約書の所在確認やデータのエクスポート可否の調査は、一社依存の是非を問うものではなく、不測の事態(開発会社の廃業・災害・担当者の退職など)に備えるための一般的なリスク管理だと位置づけます
2. 既存の関係を否定しない: 「今の開発会社が悪い」という文脈にせず、「長年お世話になっているからこそ、万一に備えて自社側でも把握しておきたい」という姿勢で臨みます
3. 具体的な作業から着手し、結論を急がない: 「乗り換えるべきかどうか」の結論を先に求めず、まずは契約書の確認やデータのエクスポート方法の調査といった、具体的で反論の余地が少ない作業から着手します

状況別: どこまでのステップを優先すべきか

一社依存の実態は会社ごとに濃淡があります。すべてのステップを同じ濃度で進める必要はなく、自社の状況に応じて優先順位を調整してください。以下は代表的な3つの状況とその優先順位の例です。

状況A: 開発会社との関係自体は良好で、特に不満はない場合

このケースでは、ステップ4の「選択肢を持つための最低限のデータを揃える」を最優先にしてください。関係が良好であるほど、いざというときの備えが後回しにされがちです。契約書・データ・費用の3点だけでも確認しておけば、関係を変えずとも「選べる状態」は作れます。ステップ3の心理要因の整理は、この状況では必要度が低めです。

状況B: 費用や対応スピードに漠然とした不満があるが、具体的な根拠がない場合

このケースでは、ステップ4の「現在の費用が相場から見てどうか」の確認を最優先にしてください。漠然とした不満のまま社内で声を上げても、「感情的な不満では」と受け取られやすく、建設的な議論になりません。相場感という客観的な材料を先に手に入れることで、不満を具体的な検討材料に変換できます。

状況C: すでに一部の業務で「うちでしか直せません」と言われた経験がある場合

このケースは技術要因(ロックイン)がすでに顕在化している状態です。ステップ3で技術要因と心理要因を分けた上で、技術要因の解消を急いでください。具体的な初動対応は「うちでしか直せません」と言われたときの対処法にまとめられているので、この記事のステップ4と並行して参照することをおすすめします。

よくある失敗パターン

一社依存の見直し準備を進める過程で、実際に起きがちな失敗パターンを3つ紹介します。自分が同じ轍を踏んでいないか、進めながら適宜見返してください。

• 調査の途中で開発会社に警戒される: データのエクスポート可否や契約範囲について立て続けに質問すると、開発会社側が「乗り換えを検討しているのでは」と警戒し、以後の対応が硬くなることがあります。質問する際は、「業務継続計画の一環で、社内資料を整理している」という文脈を添えるだけでも印象が変わります
• 社長を通さずに直接開発会社へ照会してしまう: 窓口が社長に集中している状態のまま、ひとり情シスが独断で開発会社に契約内容を問い合わせると、開発会社側が困惑し、結果的に社長への確認が入り、話がこじれることがあります。着手前に「今後、契約関連の確認は自分が窓口になる」と社内外に一言断りを入れておくと、この種の混乱を避けられます
• 調査が目的化し、いつまでも結論を出さない: 材料集めに時間をかけすぎるあまり、いつまでも「準備中」の状態から抜け出せず、実際の判断がずるずると先延ばしになるケースもあります。ステップ4までの調査に区切りをつける期限をあらかじめ自分の中で決めておくことをおすすめします

よくある疑問

Q. 開発会社に「調査している」と正直に伝えるべきですか。

伝え方次第です。「業務継続計画の一環で、社内資料を整理している」「情シス担当として着任したので、既存の契約内容を把握しておきたい」という文脈であれば、多くの開発会社は自然な依頼として受け止めます。逆に「乗り換えを検討しています」と明言する必要はなく、むしろこの段階ではまだ乗り換えを決めたわけではないので、事実と異なる説明を避ける意味でも「把握しておきたい」という表現に留めるのが適切です。

Q. 社長が「今のままでいい」と言っている場合、それでも準備を進めるべきですか。

準備を進めること自体は、社長の意思決定を覆す行為ではありません。「今の開発会社を続ける」という意思決定と、「不測の事態に備えて資料を整理しておく」という実務作業は別の話です。この違いを社長に説明した上で、リスク管理の一環として進めることの了承を得るとよいでしょう。多くの場合、「今すぐ乗り換えを検討しているわけではない」と明確にすれば、反対されることは少ないはずです。

Q. どのくらいの頻度で、この棚卸しをやり直すべきですか。

一度きちんと棚卸しを終えれば、その後は年に1回程度、契約更新のタイミングに合わせて情報を更新する程度で十分です。毎回ゼロから調査し直す必要はなく、システム管理台帳に記録を残しておけば、更新作業自体は短時間で済みます。

まとめ: 目指すのは「乗り換え」ではなく「選べる状態」

創業時からの一社依存という状態は、それ自体が問題なのではありません。問題は、他に選択肢があることを認識できていない、あるいは選択肢を持つための材料が手元にない状態で、思考停止的に依存が続いていることです。

この記事で示したステップは、いずれも「今すぐ開発会社を変える」ためのものではなく、「変えるという選択肢を実際に持てる状態を作る」ための準備です。契約範囲の実態を年表で確認し、変えられない理由を技術要因と心理要因に分け、データと権利関係を確認する。この一連の作業を終えたとき、あなたは初めて「このまま関係を続ける」ことも「一部を見直す」ことも、自分の意思で選べる立場に立てます。

急いで結論を出す必要はありません。この記事のステップは、本業と兼任しながらでも数週間から数ヶ月かけて少しずつ進められる性質のものです。むしろ焦って一度にすべてを終わらせようとすると、社内外との調整が雑になり、かえって関係を損ねるリスクが高まります。年表作りは時間が取れる週にまとめて、データのエクスポート依頼は先に出しておいて回答を待つ間に別の作業を進める、というように、待ち時間を活用しながら並行して進めてください。

この記事のステップを終えた時点での「成果物」は、次の3点が手元に揃っている状態です。1つ目は依存の履歴をまとめた年表、2つ目は契約範囲の実態と口頭合意の一覧、3つ目はソースコードの権利・データのエクスポート可否・費用相場という3種類の調査結果です。この3点セットがあれば、経営層への説明資料としてもそのまま使えますし、万一開発会社に不測の事態が起きた場合の初動対応の土台にもなります。逆に言えば、この3点が揃うまでは、乗り換えの是非について結論を急ぐべきではありません。

準備が整い、実際に契約書・仕様書の所在確認や復元が必要になった場合は30-100人規模で基幹システムの契約書・仕様書が見当たらないときの復元手順へ、費用面での見直しを優先したい場合は社員数増加でSaaSライセンス費用が急増したときの見直しタイミングへ、実際に乗り換えの準備を単独で進める段階になったらひとり情シスが1人で進めるベンダー変更のリスク低減ステップへ進んでください。自社の依存度を客観的に把握したい場合は、ひとり情シス危険度診断もあわせて活用してください。ひとりで抱え込まず、進捗を都度チェックリスト化しておくことが、兼任の立場でこの準備をやり切るための一番の近道です。