開発会社が1社依存になっている状態からの脱却、チーム体制での進め方

創業以来、あるいはシステムを最初に導入した時期からずっと同じ開発会社に保守・改修を依頼し続けている――100-300人規模の会社では、こうした「1社依存」の状態がごく普通に存在します。長年の付き合いの中で信頼関係が築かれていること自体は、決して悪いことではありません。しかし、その開発会社が唯一の選択肢であり続けることには、見過ごせないリスクが伴います。担当者の高齢化・退職、保守費用の一方的な値上げ、対応スピードの低下、あるいは開発会社そのものの廃業といった事態が起きたとき、代替手段が存在しないという状況は、会社の事業継続にとって重大な脆弱性になります。

当メディアには開発会社を変えたいのに変えられない理由。ロックインの構造を分解するや開発会社の乗り換え判断フロー: いつ・どの手順で切り替えるかといったコラムがありますが、これらは主に「1人の担当者が、既存のベンダーから別のベンダーへ乗り換える」という単線的な意思決定を扱っています。本ガイドが焦点を当てるのは、それとは異なる論点です。すなわち、複数人体制になった情シスチームが、1社への完全依存から脱却し、複数のベンダーを使い分けられる体制へと移行していく際に、誰が何を検証し、どのようなプロセスで合意形成しながら進めていくべきかという、チームによる意思決定プロセスそのものです。

1社依存はなぜ静かに深刻化するのか

1社依存の状態は、多くの場合、ある日突然生まれるものではありません。長年にわたる自然な積み重ねの結果として、気づいたときには既に深刻な依存状態になっているというのが実情です。

最初のシステム導入時、限られた予算と時間の中で1社に発注するのは、むしろ合理的な選択です。複数社に分散発注するメリットよりも、コミュニケーションコストの低さや、責任の所在が明確であることのメリットの方が大きいためです。問題は、その後の改修・保守・追加開発が、検討することなく同じ1社に継続して発注され続けることにあります。既存のシステムを熟知しているという理由で、新しい依頼のたびに「今回もお願いします」という判断が繰り返され、その積み重ねが数年後には「他に選択肢がない」という状態を作り出します。

この積み重ねの過程には、心理的な要因も働いています。長年取引を続けてきたベンダーに対して、他社を検討すること自体が、まるで裏切り行為であるかのような後ろめたさを感じる担当者は少なくありません。特に、その担当者個人が既存ベンダーとの窓口を長年担当してきた場合、この心理的な抵抗はより強くなる傾向があります。しかし、事業を継続的に運営していく上で、特定の取引先への依存度を適切な水準に管理することは、経営判断として当然求められる姿勢です。1社依存からの脱却を検討することは、既存ベンダーへの不信任を意味するものではなく、会社としてのリスク管理の一環であるという認識を、まずチーム内で共有しておくことが出発点になります。

100-300人規模になると、この構造はさらに強化されやすくなります。事業が拡大し、システムに求められる機能や連携が複雑化するほど、既存の開発会社が持つ「これまでの経緯を知っている」という情報優位性は増していきます。新しい開発会社に依頼しようとしても、既存システムの仕様を一から説明するコストや、引き継ぎの手間を考えると、結局「今のところにお願いした方が早い」という判断に流れやすくなるのです。

さらに、ひとり情シスから複数人体制への移行期特有の事情もあります。担当者が1人だった頃は、既存ベンダーとの人間関係そのものが、業務を円滑に進めるための重要な資産でした。長年の付き合いの中で培われた「阿吽の呼吸」のようなコミュニケーションは、担当者個人にとって心強い一方、その関係性が担当者個人に紐づいている場合、担当者が異動・退職すれば、その資産ごと失われてしまいます。複数人体制に移行するタイミングは、この属人的な関係性を、個人の資産からチームの資産へと切り替える好機でもあります。1社依存からの脱却は、単にリスク分散という観点だけでなく、ベンダーとの関係性そのものを組織的な資産として再構築する取り組みとしても捉えることができます。

1社依存から脱却する動機を整理する

チームで1社依存からの脱却に取り組む前に、なぜそれをすべきなのかという動機を整理しておくことが重要です。動機が曖昧なまま進めると、途中で「今のままでもいいのではないか」という揺り戻しが起きやすくなります。典型的な動機には、次のようなものがあります。

これらの動機は互いに排他的ではなく、複数が同時並行で存在することも珍しくありません。むしろ実務上は、「対応スピードへの不満をきっかけに調べ始めたら、価格面でも見直しの余地があることに気づいた」というように、1つの動機の検討が別の動機の発見につながるケースの方が多いくらいです。動機の整理は、最初から完璧な一覧を作ろうとするのではなく、検討を進める中で随時アップデートしていく前提で臨むことをお勧めします。

これらの動機は、必ずしもすべてが同時に当てはまるわけではありません。自社にとって最も切実な動機がどれかをチーム内で明確にしておくことで、後の検証作業やベンダー選定の基準がぶれにくくなります。特に「継続性リスクの回避」が主な動機である場合と、「価格交渉力の確保」が主な動機である場合とでは、次のステップで検証すべき内容が変わってきます。

動機を整理する際は、チームメンバー全員でブレインストーミング的に懸念点を出し合う場を設けることをお勧めします。1人だけの視点で動機を整理すると、その人が普段接している業務領域に偏った懸念しか出てこないことがあります。ヘルプデスク対応を主に担当しているメンバーは対応スピードの懸念を強く感じているかもしれませんし、契約・予算管理を担当しているメンバーは価格交渉力の懸念をより切実に感じているかもしれません。複数の立場からの懸念を集約することで、より説得力のある動機の整理につながります。

また、動機を整理する過程で、経営層や他部署からの視点も取り入れることを検討してください。情シスチームだけでは気づきにくい経営的なリスク認識（例えば、特定のベンダーへの支払いが集中することによる財務上のリスクや、取引先としての与信管理上の懸念など）が、経営層や経理部門から提起されることもあります。1社依存脱却の検討を、情シスチーム内で閉じた議論にせず、必要に応じて他部署の視点も取り込むことで、より多面的な動機の整理ができます。

チームで進める意思決定プロセスの全体像

1社依存からの脱却は、ひとり情シスの時代であれば、個人の判断で緩やかに進めることもできたかもしれません。しかし複数人体制になった今、この意思決定はチームとして計画的に進めるべき性質のものです。全体像を先に示します。

1. 現状の依存度を可視化する: どのシステムが、どの程度既存ベンダーに依存しているかを整理する
2. リスクの優先順位をつける: 依存しているシステムのうち、どれが最もリスクが高いかを判断する
3. 分散候補の調査を分担する: チームメンバーで手分けし、代替となりうる開発会社の候補を調査する
4. 小さな案件で試験的に発注する: いきなり大きな案件を任せるのではなく、リスクの低い小規模な案件で新しいベンダーとの相性を確認する
5. 既存ベンダーとの関係を再構築する: 分散化の動きを既存ベンダーにどう伝えるか、関係性を損なわない形で調整する
6. 中長期の発注方針を明文化する: どの領域を既存ベンダーに任せ続け、どの領域を新しいベンダーに分散させるかの方針をチーム内で共有する

この6つのステップは、いずれか1人が単独で完結できるものではなく、複数のメンバーがそれぞれ異なる役割を担うことで初めて実行可能になります。次の項目から、各ステップの具体的な進め方を見ていきます。

ステップ1〜2: 依存度の可視化とリスクの優先順位付け

最初のステップは、感覚的に「1社に依存している」と捉えるのではなく、具体的にどのシステム・業務がどの程度依存しているかを可視化することです。次のような観点で、既存システムを一覧化してください。

• そのシステムは既存ベンダーの独自技術・独自パッケージに基づいているか、それとも汎用的な技術で作られているか
• 仕様書やソースコードは自社が保有しているか、それとも実質的にベンダー側にしかないか
• 過去1年間の改修・保守依頼のうち、何割がそのベンダーへの発注か
• そのベンダーの主担当者は誰で、代わりに対応できる人員が社内にいるか

これらの情報を整理すると、依存度の高いシステムと、それほどでもないシステムが見えてきます。すべてのシステムを一度に分散化しようとするのではなく、依存度が高く、かつ事業継続へのインパクトが大きいシステムから優先的に着手することをお勧めします。優先順位付けの際は、100人を超えたら属人化台帳をどう運用に乗せるかで扱っているシステム管理台帳の情報を活用すると、既に整理されたデータをそのまま流用できます。

優先順位をつける際に有効なのが、縦軸に「依存度の高さ」、横軸に「事業継続へのインパクトの大きさ」を取った簡易的なマトリクスです。両方が高い象限に位置するシステムが、最優先で分散化に着手すべき対象になります。逆に、依存度は高いもののインパクトが小さいシステム（例えば、社内向けの補助的なツールなど）は、優先順位を下げて後回しにしても大きな問題は生じません。限られたチームのリソースをどこに集中させるかを判断する上で、このマトリクスによる可視化は有効な手段です。

このステップの過程では、既存ベンダーとの契約書や過去のやり取りの記録も、あわせて見直しておくことをお勧めします。特に、ソースコードの著作権の所在や、SOW（作業範囲記述書）の内容が曖昧なまま長年取引が続いているケースは少なくありません。契約面での確認事項が多い場合は、この段階でリスト化しておき、後のステップで既存ベンダーとの対話材料として活用してください。

ステップ3: 分散候補の調査をチームで分担する

依存度の高いシステムが特定できたら、代替となりうる開発会社の候補を調査する段階に入ります。この調査は、複数人体制だからこそ効率的に進められる作業です。1人がすべての候補を調べるのではなく、次のように分担することをお勧めします。

• 技術領域別の分担: Webシステム系、業務パッケージ系、インフラ系など、技術領域ごとに担当を割り振り、それぞれの領域に強い開発会社を調査する
• 情報源別の分担: 業界の紹介・口コミ経由の候補、Web検索・比較サイト経由の候補、過去に接点のあった候補など、情報源ごとに担当を分ける

候補の調査では、単に「対応できるかどうか」だけでなく、次のような観点も確認しておくと、後の選定がスムーズになります。

1. 得意とする技術領域・業界: 自社のシステムと親和性の高い実績を持っているか
2. 対応可能な規模感: 大規模なプロジェクトを主戦場とする会社か、小回りの利く小規模案件を得意とする会社か
3. 契約形態の柔軟性: 準委任契約・請負契約など、自社が求める契約形態に対応できるか
4. 既存システムとの技術的な親和性: 既存システムが使っている技術スタックを、新しい候補が理解・対応できるか

調査結果は、チーム内で共有できる一覧表にまとめておきます。この段階ではまだ本格的な問い合わせは行わず、候補のロングリストを作ることを目的にしてください。

候補の調査を分担する際、注意しておきたいのが、調査の質にばらつきが出やすいという点です。メンバーによって、Webサイトの情報だけで判断してしまう人もいれば、実際に知人のネットワークを通じて評判を確認する人もいます。調査の粒度がバラバラだと、後で候補同士を公平に比較することが難しくなります。調査を始める前に、最低限確認すべき項目（対応実績、対応可能な規模、契約形態、料金の目安など）をチェックリストとして共有し、全員が同じ基準で情報を集められるようにしておくことをお勧めします。

また、候補探しの情報源として、既に他部署や過去に接点のあった会社を軽視しないことも重要です。過去に別の案件で相談したことがある開発会社や、他部署が個別に利用している開発会社が、実は自社が求めている技術領域に強みを持っているというケースは珍しくありません。社内に眠っている過去の接点を掘り起こす作業も、候補調査の一環として組み込んでおくとよいでしょう。

ステップ4: 小さな案件で試験的に発注する

候補が絞り込めたら、いきなり基幹的な案件を任せるのではなく、リスクの低い小規模な案件で試験的に発注することをお勧めします。この試験発注には、複数の目的があります。

• 技術力・対応品質の実地確認: 提案書や打ち合わせだけでは分からない、実際の開発品質やコミュニケーションの質を確認する
• 既存ベンダーとの相性比較: 同じような規模の案件を既存ベンダーに依頼した場合と比較し、対応スピードや費用感の違いを把握する
• 社内の受け入れ体制の検証: 新しいベンダーとのやり取りに、社内のどのメンバーがどの程度の負荷で対応できるかを確認する

試験発注する案件は、失敗しても事業への影響が限定的なものを選ぶのが基本です。例えば、社内向けの小規模ツールの改修や、既存システムに影響を与えない範囲の新規機能追加などが適しています。この段階で得られた評価は、チーム内で言語化して共有し、次のステップである既存ベンダーとの関係再構築や、中長期の発注方針の判断材料として蓄積してください。

試験発注の評価は、感覚的な「良かった・悪かった」だけで終わらせず、可能な範囲で項目ごとに整理しておくことをお勧めします。例えば、初回問い合わせから提案までのスピード、見積もりの分かりやすさ、実際の開発品質、納品後の対応、コミュニケーションの取りやすさといった項目ごとに簡単な評価をつけておくと、複数の候補を比較する際の材料として活用しやすくなります。この評価記録は、1回の試験発注だけでなく、今後別の案件で再び同じベンダーを検討する際にも参照できる、チームの資産になります。

評価を担当したメンバーだけでなく、実際にそのシステムを利用する現場のメンバーからのフィードバックも、可能であれば集めておくとよいでしょう。情シス側の評価と、実際の利用者側の評価が食い違うことは珍しくなく、両方の視点を踏まえることで、より実態に即したベンダー評価ができます。

「最初に試験発注したときは、正直『既存のベンダーの方がやっぱり早いな』という結果になりました。ただ、2社目に試験発注した会社は、既存ベンダーが不得意としていたクラウドインフラの領域で、想像以上にスムーズな対応をしてくれました。1回の試験だけで判断せず、複数の候補で試してみたことで、『この領域はA社、この領域はB社』という自社なりの使い分けの土台が見えてきました」

ステップ5: 既存ベンダーとの関係を壊さずに進める

1社依存からの脱却を進める際、最も繊細な配慮が必要になるのが、既存ベンダーとの関係性です。長年付き合ってきたベンダーからすれば、他社への発注が始まることは、決して気持ちの良い話ではありません。関係性を損なうと、既存システムの保守対応の質が低下したり、必要な情報提供に非協力的になったりするリスクもあります。

進め方としては、次のような配慮が有効です。

• 隠さず、しかし対立的にならない伝え方をする: 「別のベンダーにも一部の業務を依頼することにした」という事実は、隠すのではなく、適切なタイミングで誠実に伝える。ただし「今のベンダーに不満がある」という伝え方ではなく、「事業継続の観点から、複数の選択肢を持つ方針にした」という中立的な説明を心がける
• 既存ベンダーの強みを活かせる領域を明確に残す: すべての業務を分散させるのではなく、既存ベンダーが最も強みを発揮できる領域は、引き続き主軸として任せ続ける姿勢を示す
• 契約・費用面での急激な変化を避ける: 分散化に伴って既存ベンダーへの発注額が急減すると、相手側の事業計画にも影響が及ぶ。段階的な移行を心がける

この配慮は、単に既存ベンダーへの礼儀という以上の意味を持ちます。既存システムの深い知見は、依然として既存ベンダーが最も豊富に持っています。関係性が悪化すれば、その知見へのアクセスそのものが失われかねません。分散化は「既存ベンダーを切り捨てる」ことではなく、「選択肢を増やす」ことだという位置づけを、社内外双方に一貫して伝え続けることが重要です。

この関係再構築のプロセスは、誰がどのタイミングで既存ベンダーに伝えるかという点も、チームで事前にすり合わせておくべきです。長年の窓口担当者が個人的な信頼関係を築いている場合、その担当者から伝えるのが最も角が立たない方法であることが多いですが、伝える内容そのものはチーム全体で合意した方針に沿ったものである必要があります。窓口担当者が独断で方針を伝えてしまうと、後になってチーム内の認識とズレが生じ、既存ベンダーに対して一貫性のない対応をしてしまうリスクがあります。事前に伝える内容を文書化し、窓口担当者とチーム全体で認識を合わせてから対話に臨むことをお勧めします。

また、既存ベンダー側からの反応も一様ではないことを想定しておいてください。分散化の方針を好意的に受け止め、むしろ自社の強みをより明確に提案してくるベンダーもいれば、態度を硬化させ、対応の質が目に見えて落ちるベンダーも中にはあります。後者のような反応が見られた場合は、それ自体が「このベンダーへの依存を早期に解消すべきだった」ことの裏付けとも言えます。関係性の変化そのものを、今後の発注方針を判断する材料の一つとして観察しておくとよいでしょう。

ステップ6: 中長期の発注方針をチームで明文化する

試験発注や既存ベンダーとの関係調整を経て、実際にどう発注を使い分けていくかの方針が見えてきたら、その内容をチーム内で明文化しておきます。口頭やその場限りの判断に頼っていると、担当者が変わるたびに方針が揺らぎ、せっかく進めてきた分散化が元に戻ってしまうリスクがあります。

方針を明文化する際は、チームメンバー全員が同じ認識を持てるよう、単なる文書化にとどまらず、実際に話し合いの場を設けて内容をすり合わせることをお勧めします。特に、部署ごとに異なるベンダーへの発注が重なっている場合は、方針の統一が複数の拠点・部署にまたがる調整を必要とすることもあります。この点については、拠点・部署ごとに異なるベンダーを使っている状態を整理する統合判断でさらに詳しく扱っています。

明文化した方針は、一度作って終わりにするのではなく、新しいメンバーがチームに加わった際のオンボーディング資料としても活用できます。なぜ複数のベンダーを使い分ける方針を取っているのか、その背景にある経緯や検討過程を知らないまま新しいメンバーが加わると、せっかく築いた分散化の方針が、悪気なく「なぜこんな面倒な使い分けをしているのか」と疑問視され、なし崩し的に元の1社依存に戻ってしまうことも起こり得ます。方針そのものだけでなく、その方針にたどり着いた経緯や検討の過程も、あわせて記録として残しておくことをお勧めします。

分散化を急ぎすぎることのリスクにも目を配る

ここまで1社依存からの脱却を段階的に進める手順を解説してきましたが、一方で、分散化を急ぎすぎることにもリスクがあることに触れておきます。複数のベンダーを並行して使うようになると、それぞれのベンダーとのコミュニケーションコストが単純に増加します。1社であれば1つの窓口で完結していたやり取りが、複数社になれば、それぞれの進捗管理、契約管理、請求処理が並行して発生し、情シスチームの管理負荷が増大します。

特に、まだチームの人数が2〜3人程度である場合、あまりに多くのベンダーと同時並行で関係を築こうとすると、どのベンダーとの関係も中途半端になり、結果的にどこにも深い信頼関係を築けないという事態に陥りかねません。分散化の目的は「できるだけ多くのベンダーと取引すること」ではなく、「重要な業務領域において、複数の選択肢を持てる状態を作ること」です。この目的を見失わないよう、分散化の規模は、チームが実際に管理できる範囲にとどめることを意識してください。

目安としては、最初の段階では2〜3社程度の候補ベンダーとの関係構築から始め、実際に運用してみた上での負荷を見ながら、必要に応じて徐々に拡大していくアプローチが現実的です。焦って一気に多くのベンダーへ分散させるのではなく、着実に運用できる範囲で、段階的に選択肢を増やしていく姿勢が、長期的にはチームにとって持続可能な体制につながります。

まとめ: 1社依存からの脱却は「チームの資産」として進める

1社依存からの脱却は、単発のベンダー切り替えとは異なり、時間をかけて段階的に進めるべきテーマです。依存度の可視化、リスクの優先順位付け、分散候補の調査、試験発注、既存ベンダーとの関係調整、方針の明文化――この一連のプロセスは、複数人体制の情シスチームだからこそ、それぞれの役割を分担しながら着実に進めることができます。

重要なのは、この取り組みを特定の1人の判断や人脈に依存させず、チームの共有資産として積み上げていくことです。試験発注で得られた評価、候補ベンダーの一覧、既存ベンダーとの関係性の経緯――これらすべてを記録として残し、チーム内で共有し続けることで、担当者が変わっても分散化の取り組みが後退しない体制を築くことができます。1社依存というリスクを、チームの力で少しずつ、しかし着実に解消していってください。

最後に、この取り組みには明確な終わりが存在しないことも理解しておく必要があります。1社依存から脱却し、複数の選択肢を持てる体制を一度築いたとしても、時間が経てば新たな依存関係が生まれる可能性は常にあります。新しく分散先として選んだベンダーが、今度は別の意味で依存度を高めていくということも起こり得ます。だからこそ、方針の明文化とセットで、定期的な見直しのサイクルを組み込んでおくことが欠かせません。半年や1年といった節目で、現在の発注状況を棚卸しし、依存度が再び高まっていないかを確認する。この継続的な点検の習慣こそが、1社依存という状態への逆戻りを防ぐ、最も確実な方法です。ひとりで担っていた頃には難しかったこの継続的な点検を、複数人体制になった今だからこそ、チームの当たり前の業務として根付かせていってください。