複数の開発会社・SIerが混在する体制をチームで統制する方法

社員数が100人を超えるあたりから、情シスが向き合う開発会社の数は静かに増えていきます。基幹システムを担当するSIer、勤怠管理SaaSのベンダー、社内ポータルを作った受託開発会社、営業部が独自に契約したCRMの導入支援会社。ひとり情シスの時代は「全部自分が把握している」という前提でなんとか回っていたものが、担当者が2〜3人に増えると、この前提そのものが崩れます。Aさんが窓口をしているベンダーをBさんが知らない、Bさんが交渉中の契約更新をAさんが把握していない、という状態は珍しくありません。このガイドでは、100〜300人規模の会社で複数の開発会社・SIerが混在する体制を、チームとしてどう統制するかを具体的な手順で解説します。個人の頑張りに依存しない、仕組みとしてのベンダー管理です。

なぜ複数人体制になるとベンダー管理が崩れるのか

ひとり情シスの時代、ベンダーとの関係は基本的に「担当者の頭の中」で完結していました。どの会社にどの案件を頼んでいて、誰が窓口で、契約更新がいつで、過去にどんなトラブルがあったか。すべてが一人の記憶と経験の中にあり、それで実務は回っていました。台帳がなくても、聞けば本人が答えられたからです。

ところが増員が決まり、担当が2〜3人に分かれた瞬間、この「聞けば分かる」は機能しなくなります。理由は3つあります。

1つ目は、ベンダーごとに窓口担当が分かれることです。Aさんが基幹システムのSIerを、Bさんが勤怠SaaSのベンダーを、それぞれ独立して担当するようになると、互いの担当ベンダーの状況は「聞かないと分からない」に変わります。2つ目は、部署をまたいだ発注が見えなくなることです。営業部やマーケティング部が独自にツール導入を進め、情シスに事後報告だけが来るケースでは、そもそも情シス内の誰も全体像を持っていません。3つ目は、担当者の異動・退職です。ひとり情シスなら「自分がいなくなったら終わり」というリスクを本人が自覚していますが、複数人体制になると「誰かが知っているはず」という油断が生まれ、実際には誰も全体を把握していないという事態が起こります。

この崩れ方は緩やかで気づきにくいのが厄介なところです。台帳を整備した直後は問題が表面化しませんが、半年、1年と経つうちに「このベンダーの契約、誰が窓口だっけ」という会話が増えていきます。

ベンダー統制の3つの柱

チームでベンダーを統制するために必要な仕組みは、大きく3つに分解できます。

• 一覧化: どのベンダーと、どんな契約で、誰が窓口かを一箇所に集約する
• 窓口の一本化: ベンダーごとに「対外的な窓口は誰か」を明確にし、勝手な個別交渉を防ぐ
• 定期レビュー: 一覧を作って終わりにせず、四半期〜半期ごとに実態と照合する

このうち多くのチームが最初につまずくのは一覧化ではなく、一覧を作った後の「維持」です。作成時点では正確でも、新規契約や担当交代のたびに更新が漏れ、半年後には実態と乖離した「古い一覧」になっているケースをよく見かけます。統制の本質は一覧化そのものより、更新が自然に続く仕組みを作ることにあります。

ベンダー一覧の作り方とチームでの管理方法

まず着手すべきは、社内で契約しているすべてのベンダーを一覧化することです。この作業自体はひとり情シスの時期からやっていたチームも多いはずですが、複数人体制向けに見直すべき点がいくつかあります。

一覧に最低限含めるべき項目は次の通りです。

重要なのは「社内窓口担当者」を必ず1名に絞ることです。ひとつのベンダーに対して複数の担当者がそれぞれ別々に連絡を取ると、ベンダー側から見て「この会社は誰の言うことを聞けばいいのか分からない」という状態になり、要望の食い違いや二重発注のリスクが生まれます。窓口を一本化した上で、他のメンバーは一覧を見れば状況を把握できる、という形が理想です。

一覧の置き場所については、Excelやスプレッドシートでも構いませんが、更新履歴が追える形式にしておくことをお勧めします。誰がいつ何を更新したかが分からないと、情報の鮮度に対する信頼が薄れ、結局「念のため本人に聞く」という非効率な確認作業に逆戻りしてしまうためです。

窓口の一本化が崩れるパターンと対策

窓口を一本化するというルールは、決めた瞬間は機能しても、時間が経つと形骸化しやすい部分です。実際によくある崩れ方を見てみましょう。

1つ目は、緊急時の抜け道です。窓口担当者が不在のときに障害が発生し、他のメンバーが直接ベンダーに連絡してしまうケースです。これ自体は緊急対応として妥当な判断ですが、事後に窓口担当者への共有が漏れると、ベンダー側とのやり取りの履歴が分断されます。対策としては、緊急連絡をした場合は当日中に窓口担当者と情報共有するというルールをセットで決めておくことです。

2つ目は、他部署からの直接発注です。営業部やバックオフィス部門が、情シスを通さずに開発会社と直接契約を結んでしまうパターンです。これは統制が及ばない範囲で起きるため、一覧からも漏れ落ちます。完全に防ぐことは難しいものの、新規のシステム導入・開発発注は情シスへの事前相談を必須とする社内ルールを、経営層の後ろ盾を得て周知することが有効です。

3つ目は、担当者の個人的な信頼関係への依存です。長年付き合いのあるベンダーの営業担当と、情シスの特定の社員が個人的に親しくなり、他のメンバーを介さずに話が進んでしまうケースです。これ自体は関係構築として悪いことではありませんが、その社員が異動・退職した瞬間に関係性ごと失われるリスクがあります。重要な意思決定や合意事項は、口頭やチャットの個人的なやり取りだけで完結させず、必ずチームで共有できる形（議事録・一覧への反映）に残すことを徹底する必要があります。

複数ベンダーが絡む案件での責任範囲の線引き

100〜300人規模になると、1つのシステム改修に複数のベンダーが同時に関わる場面が増えてきます。例えば基幹システムのSIerとデータ連携先のSaaSベンダーが、それぞれ別々の窓口担当者を情シス側に持っているようなケースです。このとき問題になりやすいのが、不具合発生時の「どちらの責任か」という切り分けです。

責任範囲があいまいなままだと、障害発生時に両ベンダーが「自社の担当範囲外」と主張し合い、対応が停滞するリスクがあります。これを防ぐには、契約時点、あるいは複数ベンダーが関わるプロジェクトの開始時点で、次のような線引きを明文化しておくことが有効です。

• システム間の責任分界点: データ連携のどちら側までが各ベンダーの担当範囲か
• 障害発生時の一次切り分け窓口: 原因不明の障害が起きたとき、最初にどちらへ連絡するか
• 合同確認の実施タイミング: 両ベンダーが同席して原因を切り分ける場をいつ設定するか

この線引きをチーム内の複数人で共有しておくことも重要です。責任分界点を知っているのが特定の1人だけだと、その人が不在のときに障害が起きた場合、初動が遅れてしまいます。エスカレーションフローそのものの設計については、対応の一次窓口と最終判断者を分けて考える必要があり、その詳細は別のガイドで扱っています。

ベンダー統制を定着させる定期レビューの設計

一覧を作り、窓口を一本化しても、時間が経てば実態は変化していきます。契約が終了したベンダーが一覧に残り続けたり、逆に新しく契約したベンダーの登録が漏れたりすることは避けられません。これを防ぐのが定期レビューです。

レビューの頻度は、四半期に1回程度が現実的なバランスです。月次では負荷が高すぎて形骸化しやすく、年次では変化を追いきれません。レビューで確認すべき項目は次の通りです。

• 一覧に載っているベンダーとの契約が実際に継続しているか
• 窓口担当者に変更がないか（担当者本人の異動予定も含めて）
• 直近3ヶ月でトラブルや懸念があったベンダーはないか
• 契約更新が近いベンダーの準備状況

レビューの実施責任者は、持ち回りではなく固定の担当者を置くことをお勧めします。持ち回りにすると「今回は誰の番だったか」自体があいまいになり、実施そのものが立ち消えになるリスクがあるためです。ただし固定担当者が異動・退職した場合の引き継ぎ手順は、あらかじめ文書化しておく必要があります。

新規ベンダー選定時にチームで確認すべきこと

統制の仕組みは、既存ベンダーの管理だけでなく、新規にベンダーを選定する段階から始まっています。100〜300人規模になると、新しいシステム導入や開発案件が複数同時に走ることも珍しくなく、選定の判断を特定の1人に委ねてしまうと、後になって「なぜこのベンダーを選んだのか」という経緯が分からなくなるリスクがあります。

新規ベンダー選定の際にチームで最低限すり合わせておきたい観点は次の通りです。

• 既存の戦略ベンダーとの役割が重複しないか、あるいは意図的な代替候補として検討しているか
• 選定理由（価格・技術力・実績・対応スピードなど）を後から追跡できる形で記録しているか
• 契約形態が自社の求める関わり方(成果物重視か、継続的な伴走か)と合っているか
• 選定プロセスに複数人が関与し、1人の主観だけで決定していないか

選定理由の記録は、前述のベンダー一覧の初期エントリとしてそのまま活用できます。選定時点の情報を残しておくことで、契約更新のタイミングや、他ベンダーへの乗り換えを検討する際にも、当初の判断基準に立ち返って比較検討がしやすくなります。評価基準そのものをチームで標準化する取り組みについては、別のガイドで詳しく扱っています。

なお、選定段階でのすり合わせを丁寧に行っておくと、契約後のトラブル対応もスムーズになります。選定理由が明確であれば、期待値のズレが生じたときに「そもそもなぜこのベンダーを選んだのか」に立ち返って議論できるためです。逆に選定の経緯が曖昧なまま契約を進めてしまうと、トラブル発生時に「誰が、何を基準にこのベンダーを選んだのか」という不毛な原因探しから始めることになりかねません。

よくある失敗パターンと回避策

複数ベンダー体制の統制でチームがつまずきやすいパターンを、実際に起こりやすい順に整理します。

一覧は作ったが、更新するタイミングのルールがなく、3ヶ月後には誰も更新しなくなっていた。

これは最も多い失敗です。「気づいたら更新する」という運用は、ひとり情シスの時代には機能しても、複数人体制では「誰かがやるだろう」という空白を生みます。新規契約・契約終了・担当交代が発生した際に、一覧を更新することを承認フローの一部に組み込む（契約書にサインする前に一覧への追記を必須にする、など）ことで、更新漏れを構造的に防げます。

窓口を一本化したはずが、実際には各自が個別に連絡を取り続けていた。

ルールを決めただけでは行動は変わりません。窓口担当者以外がベンダーと直接やり取りした場合に、それが分かるようにする仕組み（メールのCCルール、チャットのチャンネル参加ルールなど）を併用することで、逸脱に気づきやすくなります。

責任範囲の線引きをしていたが、文書化されておらず、担当者の異動で失われた。

口頭やその場限りの合意は、担当者が変わると簡単に失われます。責任分界点や連絡フローは、必ず文書として残し、チームメンバー全員がアクセスできる場所に保管することが最低限の防御策です。

ベンダーの類型で管理の濃淡を変える

すべてのベンダーを同じ密度で管理しようとすると、チームの工数がすぐに限界を迎えます。100〜300人規模の会社が抱えるベンダーは、実際には重要度も関わり方も大きく異なるため、管理の濃淡を意図的に変えることが現実的です。

例えば、基幹システムを開発したSIerのように、事業継続に直結するベンダーロックインの度合いが高いベンダーと、汎用的なSaaSツールを単純利用しているだけのベンダーでは、統制のかけ方がまったく違って然るべきです。次のような区分で考えると整理しやすくなります。

• 戦略ベンダー: 基幹システム・独自開発のコアシステムを担当し、代替が難しい。窓口担当者を固定し、四半期レビューの対象に必ず含める
• 標準ベンダー: 業務効率化のためのSaaSやツール導入支援。半期レビューで十分だが、契約更新月だけは必ず一覧で追跡する
• 軽微ベンダー: 単発の小規模開発やスポット対応。一覧には載せるが、個別レビューの対象からは外し、契約終了時に一覧から削除するだけでよい

この区分を最初に決めておくと、「このベンダーにどこまで手間をかけるべきか」という判断がチーム全体で揃います。逆に区分がないと、声の大きいベンダーや直近でトラブルがあったベンダーにだけ注意が向き、本来重要度の高い戦略ベンダーの管理が手薄になるということが起こりがちです。

区分の見直し自体も、定期レビューのタイミングで行うとよいでしょう。当初は軽微ベンダーとして扱っていたSaaSが、事業の中核業務に組み込まれて戦略ベンダー相当になっている、というケースは珍しくありません。ベンダーとの関係は固定的なものではなく、事業の変化に伴って重要度も変わっていくという前提を持つことが大切です。

情報共有ツールの選び方と運用ルール

ベンダー一覧をどこに置くかという選択は、複数人体制の統制を左右する地味に重要な論点です。ここではExcel・スプレッドシート・専用ツールという3つの選択肢を比較します。

100〜300人規模で、かつ情シス担当が2〜3人という体制では、専用ツールの導入までは必要ないケースが多く、クラウド型スプレッドシートで運用しつつ、更新ルールを明確に決めておくというのが現実的な落としどころです。重要なのはツールの種類そのものよりも、「誰が」「いつ」「何をきっかけに」更新するかというルールが明文化されているかどうかです。

また、ベンダー一覧とは別に、個別のやり取りの記録（議事録・メールの要約）をどこに残すかも決めておく必要があります。一覧はあくまで「現在の状態のスナップショット」であり、経緯や背景までは追えません。契約交渉の経緯や過去のトラブル対応の詳細は、別途ログとして残し、一覧からリンクできる形にしておくと、後任者や他のメンバーが状況を素早く理解できます。

経営層・他部署への報告の設計

ベンダー統制は情シスチーム内で完結する話ではなく、経営層や他部署への説明責任も伴います。特に100〜300人規模になると、システム関連のコストが経営層の目に留まりやすくなり、「なぜこんなに多くのベンダーと契約しているのか」という質問を受ける場面が増えてきます。

このときに備え、ベンダー一覧をベースにした簡易な報告資料を、半期に1回程度は作成しておくことをお勧めします。報告資料に含めるとよい要素は次の通りです。

• 契約中のベンダー数と、前回報告からの増減
• 各ベンダーへの年間支払額の概算（詳細な金額管理は経理部門と連携）
• 戦略ベンダー・標準ベンダー・軽微ベンダーの内訳
• 直近で発生した主要なトラブルとその対応状況
• 契約更新が近いベンダーとその対応方針

こうした報告を定期的に行っておくと、経営層が「情シスはベンダーを把握し、統制できている」という信頼を持ちやすくなり、増員や予算確保の交渉においても説得材料になります。逆に、ベンダーとのやり取りがブラックボックス化していると、トラブルが起きたときに初めて経営層の目に触れ、後手に回った印象を与えてしまいます。

他部署との連携という観点では、経理部門・法務部門（あるいは法務機能を持つ総務部門）との情報共有も欠かせません。特に契約書の内容や支払い条件については、情シスだけで抱え込まず、契約書の保管・支払いスケジュールの管理を経理・法務と分担する体制を組んでおくことで、属人化のリスクをさらに下げられます。

増員フェーズで統制の仕組みを作るタイミング

ベンダー統制の仕組みは、理想を言えば増員が決まる前から準備しておくのが望ましいですが、現実には増員後に慌てて整備し始めるケースが大半です。ここでは、増員のタイミングに応じてどう仕組みを作っていけばよいかを整理します。

増員がまだ1人の段階では、まずは一覧化だけでも着手しておくことが重要です。この段階ではまだ「窓口の一本化」を厳密に運用する必要性は薄いかもしれませんが、一覧という土台がないと、後から人数が増えたときに整備コストが跳ね上がります。

2人目・3人目が加わるタイミングでは、窓口の一本化と責任範囲の線引きを本格的に始める必要があります。このタイミングを逃すと、新しく入ったメンバーが「誰がどのベンダーを担当しているか分からないまま独自に動き始める」という事態になりやすく、後から統制をかけ直すのは最初から作るよりも労力がかかります。

チームが4〜5人規模に育ってきた段階では、定期レビューの仕組みを本格稼働させ、経営層への報告フローも定着させておくとよいでしょう。この規模になると、情シスチーム内でもベンダー統制の専任に近い役割を置けるようになるため、担当を明確に割り振ることも検討に値します。

ベンダー統制と契約形態・法的な位置づけの整理

ベンダーを一覧化する際、契約形態を正しく区別しておくことも統制の一部です。開発会社との契約は、成果物の完成を約束する請負契約なのか、業務の遂行そのものを目的とする準委任契約なのかによって、進捗管理の関わり方や、トラブル発生時に主張できる権利が変わってきます。チームメンバーの誰もがこの違いを正確に理解していないと、契約形態にそぐわない期待をベンダーに対して抱いてしまい、無用な摩擦を生む原因になります。

例えば、準委任契約で契約しているベンダーに対して「成果物が完成するまで支払わない」という請負契約的な対応を求めてしまうと、契約内容と実際の運用がずれてしまいます。逆に請負契約のベンダーに対して、進捗のプロセスばかりを細かく管理しようとすると、契約の趣旨に合わない過干渉になりかねません。一覧の「契約形態」欄は単なる分類ラベルではなく、そのベンダーとどう向き合うべきかという実務上の指針でもあります。

また、複数ベンダーが混在する体制では、契約書の保管場所もばらつきがちです。ある契約は情シスの担当者のPCに、別の契約は法務部門のキャビネットに、というように分散していると、いざというときに契約書を参照できません。少なくとも契約書の保管場所（物理・電子いずれか、あるいは両方)を一覧に記載し、誰でもアクセスできる状態にしておくことが望ましいです。特に契約の解除条件や損害賠償の上限といった、トラブル時に重要になる条項は、あらかじめ確認しておくと、実際にトラブルが起きたときの初動が早まります。

複数ベンダーが同一プロジェクトに関わる場合、契約形態が異なるベンダー同士で足並みが揃わないという問題も起こり得ます。例えば、請負契約のSIerが完成責任を負う一方、準委任契約で参画しているフリーランスのエンジニアには同様の責任を求められない、といった非対称性です。こうした非対称性を事前に理解し、プロジェクト全体の進行管理は情シスチーム側が主体的に担うという前提を、チーム内で共有しておくことが重要です。

チーム内での情報格差をなくすための仕組み

複数人体制でベンダー統制を進める上で、見落とされがちなのが「チーム内の情報格差」です。窓口担当者は日々のやり取りを通じて自然と情報が蓄積されますが、他のメンバーは意識的に共有されない限り、その情報にアクセスできません。この格差が広がると、窓口担当者が休暇や急な離脱をした際に、他のメンバーが即座に代役を務めることが難しくなります。

情報格差を埋めるための実務的な方法として、次のようなものが挙げられます。

• 週次・隔週の短い共有タイム: 各ベンダーとのやり取りで大きな動きがあった場合のみ、5〜10分程度で簡潔に共有する場を設ける。毎回時間をかけすぎると形骸化しやすいため、動きがなければ「特になし」で済ませる軽さを保つ
• 重要な合意事項はチャットの個別DMではなく共有チャンネルで行う: 窓口担当者とベンダーとのやり取り自体は個別で構わないが、社内で合意した方針や重要な決定事項は、チーム全員が見られるチャンネルに要約を残す
• 一覧の「直近のやり取りの要約」欄をこまめに更新する: 前述のベンダー一覧の該当欄を、大きな進展があるたびに1〜2行で更新するだけでも、格差はかなり縮まる

これらはいずれも大掛かりな仕組みではなく、日々の習慣として根付かせることが目的です。習慣化のコツは、共有すること自体を「追加業務」ではなく「本来の業務の一部」として位置づけることです。窓口担当者がベンダーとのやり取りを終えた後、一覧を更新する、あるいは一言チームに共有するという行動を、対応完了の一部として組み込んでおくと、負担感なく続けやすくなります。

情報格差をなくす取り組みは、単に業務の属人化を防ぐだけでなく、チームメンバー同士の信頼関係の構築にもつながります。「自分だけがベンダー対応の全体像を知っている」という状態は、担当者本人にとっても心理的な負担になりがちです。チームで情報を共有し合う文化を作ることは、ベンダー統制の仕組みを長期的に維持するための土台でもあります。

まとめ

複数の開発会社・SIerが混在する体制を統制する作業は、一度仕組みを作れば終わりというものではありません。一覧化・窓口の一本化・定期レビューという3つの柱を組み合わせ、それぞれが「特定の個人の頑張り」ではなく「チームとして続く仕組み」になっているかを、定期的に点検し続けることが求められます。さらに、ベンダーの重要度に応じて管理の濃淡を変え、情報共有ツールと報告の仕組みを整えることで、増員のたびに崩れがちな統制を安定させられます。

振り返ると、統制の要点は次の4つに集約できます。

1. すべてのベンダーを一箇所に一覧化し、更新が自然に続く仕組みを組み込む
2. ベンダーごとに窓口担当を1名に絞り、逸脱に気づける仕組みを併用する
3. 複数ベンダーが絡む場面では責任分界点を事前に文書化しておく
4. 定期レビューと経営層への報告を通じて、統制状態を可視化し続ける

100〜300人規模という、まだ専任のベンダーマネジメント担当を置くほどの規模ではないフェーズだからこそ、情シスチーム自身がこの統制の仕組みを設計し、運用する必要があります。仕組みが定着すれば、担当者の異動や退職があっても、ベンダーとの関係が個人の記憶とともに失われることはなくなり、チーム全体としての対応力が確実に底上げされていきます。