開発会社の変更は、専任のプロジェクトチームがある大企業でも簡単な仕事ではありません。ましてや、本業と兼任しながら1人でこれを進めなければならないひとり情シスにとっては、負荷とリスクの両方が跳ね上がる作業です。旧ベンダーとの交渉、新ベンダーの選定、データとシステムの移行、社内の業務が止まらないようにする調整。これらすべてを、他の業務と並行しながら、相談できる同僚もいない状態でこなす必要があります。

この記事は、そうした状況にあるひとり情シストが、ベンダー変更というプロジェクトを1人で完走するために、負荷を時間軸で分散し、失敗しやすいポイントを事前に潰しておくための段階的な進め方を示すガイドです。結論から言うと、1人で進める場合に最も避けるべきなのは「一度にすべてを進めようとすること」です。段階を区切り、各段階で「今はここまでで十分」というラインを引くことが、兼任者が最後まで走り切るための鍵になります。

なぜ「1人で進める」ことがリスクを高めるのか

複数人のチームでベンダー変更を進める場合、交渉担当・技術検証担当・社内調整担当のように役割を分担できます。しかし1人で進める場合、これらすべての役割を同一人物が兼ねることになり、次のようなリスクが生じます。

  • 視点の偏りに気づけない: 交渉に集中していると技術的な見落としに気づきにくく、技術検証に集中していると交渉条件の不利に気づきにくい。役割を分担していれば互いにチェックできる部分が、1人ではノーチェックのまま進んでしまう
  • 本業とのタスク競合で判断が遅れる: 本業の繁忙期と、ベンダー変更の重要な意思決定タイミングが重なると、どちらかを後回しにせざるを得ず、全体のスケジュールが押す
  • 相談相手がいないまま重大な判断を下すことになる: 契約解除の伝え方、移行スケジュールの妥当性など、経験がなければ判断に迷う場面で、社内に相談できる相手がいない

これらのリスクを完全になくすことはできませんが、進め方の段階を明確に区切り、各段階でやるべきことを絞り込むことで、負荷を分散し、見落としのリスクを下げることは可能です。

また、30-100人規模特有の事情として、ベンダー変更の影響範囲が0-10人・10-30人規模とは比較にならないほど広いという点も見逃せません。営業・製造・経理など複数部署が日常的に依存しているシステムの切り替えともなれば、移行の失敗が即座に全社の業務停止につながりかねません。専任チームがいれば、この規模のプロジェクトに複数人月の工数を投じるのが一般的ですが、ひとり情シスは本業と兼任しながら、実質的にはその何分の一かの工数でこなさなければなりません。だからこそ、闇雲に急がず、リスクの高い作業から優先的に負荷を分散させる設計が欠かせません。

着手前の自己診断: 今の自分はどの段階にいるか

具体的な進め方に入る前に、まず自分が今どの段階にいるのかを確認してください。段階を飛ばして先に進んでしまうと、後から前提が崩れて手戻りが発生しやすくなります。

  • 「本当に変更すべきか」の材料(契約範囲・費用・技術要因)がまだ揃っていない → 見極め期
  • 変更する方針は固まったが、契約書・データ・仕様書がまだ手元に揃っていない → 準備期
  • 資料は揃ったが、まだ新しい依頼先の候補を探していない → 候補選定期
  • 候補は決まったが、まだ旧ベンダーとの契約が続いている → 契約切替期
  • 新ベンダーとの契約は締結したが、移行して数ヶ月以内である → 定着期

現在地を正確に把握することが、次に何にどれだけの時間を割くべきかを判断する土台になります。

全体像: 5段階に区切って負荷を分散する

ベンダー変更のプロセスを、次の5段階に区切って進めてください。段階を区切る目的は、各段階で「今はこれだけに集中すればよい」という状態を作り、同時並行で複数のタスクに追われる状況を避けることです。

ベンダー変更の確認手順を3つの確認項目で整理した図

  1. 見極め期: 本当に変更すべきかを判断する
  2. 準備期: 契約書・データ・仕様書など、変更に必要な材料を揃える
  3. 候補選定期: 新しいベンダーの候補を探し、比較する
  4. 契約切替期: 旧ベンダーとの契約終了と、新ベンダーとの契約締結を進める
  5. 定着期: 移行後の運用が安定するまでフォローする

5段階の時系列とそれぞれの主な作業内容の詳細は開発会社の乗り換え判断フロー: いつ・どの手順で切り替えるかにまとめられています。この記事では、その5段階を「1人で進める場合にどう負荷を減らすか」という観点から掘り下げます。

5段階それぞれにかかる期間の目安も持っておくと、本業とのスケジュール調整がしやすくなります。会社の状況や対象システムの規模によって幅はありますが、見極め期に1〜2ヶ月、準備期に1〜2ヶ月、候補選定期に1〜2ヶ月、契約切替期に2週間〜1ヶ月、定着期に2〜3ヶ月というのが、1人で兼任しながら進める場合の目安です。合計すると、全体で半年から1年程度のプロジェクトになることを見込んでおいてください。この期間感を最初に社内で共有しておくことで、「なぜそんなに時間がかかるのか」という誤解を防げます。

見極め期: 判断を焦らず、材料を先に揃える

見極め期で最も陥りやすい失敗は、感情的な不満(対応が遅い、態度が悪いなど)だけを理由に、材料が揃わないまま変更を決めてしまうことです。1人で進める場合、この段階でこそ時間をかけて材料を揃えるべきです。なぜなら、後の段階に進んでから「実は必要な情報が足りなかった」と気づくと、1人では取り返しがつきにくいからです。

見極め期で確認すべき最低限の材料は次の3つです。

  • 契約範囲と権利関係: 今の契約で何を、どこまで任せているか。ソースコードやデータの権利がどちらにあるか
  • 費用の妥当性: 今の費用が相場から見て高いのか、妥当なのか
  • 変更を妨げている技術的・心理的な要因: 何が「変えられない理由」になっているか

これらの材料が揃っていない場合は、先に創業時に依頼した開発会社としか付き合いがない状態から抜け出す準備の手順で整理してから、この段階に戻ってきてください。

見極め期のもう一つの重要なタスクは、「変更しない」という選択肢も正当な結論としてあり得ることを、自分自身が受け入れておくことです。1人で長期間かけて調査した末に「今回は見送る」という結論を出すのは、心理的に難しく感じられるかもしれません。しかし、材料を揃えた結果として「今の関係を続けた方が合理的」という判断に至ったのであれば、それもこの段階の立派な成果です。変更すること自体を目的化せず、あくまで会社にとって合理的な選択をするための判断材料集めだと捉えてください。

準備期: 「棚卸し担当」に徹する期間と割り切る

準備期は、旧ベンダーとの契約終了、新ベンダーとの契約締結に必要な資料(契約書・仕様書・データ)を揃える期間です。この段階を1人で進める上でのコツは、「交渉」や「選定」の判断を一切持ち込まず、ひたすら資料の棚卸しに徹すると割り切ることです。

必要な資料は、次の5つのカテゴリで整理してください。

カテゴリ具体例
ソースコード開発済みのプログラム一式、リポジトリへのアクセス権
データ業務データのエクスポートファイル、データベースのバックアップ
契約書現行の開発契約書、保守契約書、覚書
アカウントサーバー・ドメイン・各種管理画面のログイン情報
仕様書設計書、機能一覧、運用マニュアル

この5カテゴリの詳しい確認方法・依頼のコツは開発会社の乗り換え手順: 引き継ぎに必要な資料一覧にまとめています。契約書や仕様書がそもそも社内で見当たらない場合は、30-100人規模で基幹システムの契約書・仕様書が見当たらないときの復元手順を先に進めてください。

準備期は本業と最も両立しやすい段階でもあります。資料集めは相手のペースに完全に依存する交渉と違い、自分のペースで少しずつ進められる作業が多いためです。忙しい週は資料集めだけに専念し、時間が取れる週にまとめて確認作業を進める、というように波を作って進めてください。

準備期に集めた資料は、この段階では「使う」のではなく「揃える」ことに徹してください。集めた契約書を読み込んで交渉材料に転用しようとしたり、集めたデータを見て新ベンダーの候補を思い浮かべたりし始めると、本来この段階でやるべき網羅的な棚卸し作業がおろそかになります。役割を厳密に分けることが、1人で進める場合の集中力の使い方として効果的です。

候補選定期: 「比較する軸」を先に決めてから探す

候補選定期でありがちな失敗は、複数の候補から相見積もりを取ったものの、比較する軸が定まっておらず、結局「なんとなく感じが良かった方」で決めてしまうことです。1人で進める場合、この曖昧な判断がそのまま契約後のミスマッチにつながりやすくなります。

候補を探す前に、次の軸で自社の優先順位を書き出しておいてください。

  • 費用: いくらまでなら許容できるか
  • 対応スピード: 障害発生時にどのくらいの時間で対応してほしいか(SLA(サービス品質保証)の水準)
  • 専門領域との一致: 今使っている技術・業界特有の要件への理解度
  • 契約形態の柔軟性: 準委任契約請負契約か、途中での契約形態の変更が可能か

軸を先に決めておくことで、複数社との商談で聞くべき質問が明確になり、1人で対応していても比較検討の精度を保てます。

候補の数についても、1人で進める場合は現実的な上限を設けることをおすすめします。複数人チームであれば5社、6社と幅広く比較検討する余力がありますが、1人で商談・資料確認・社内調整をすべてこなす場合、同時に比較検討する候補は2〜3社程度に絞るのが現実的です。候補を絞り込む際は、まず軸に照らして明らかに条件を満たさない候補を早期に除外し、本格的な商談・見積もり比較は最終候補の2〜3社に集中させてください。

比較検討の際には、次のような簡易な比較表を作ると、判断が視覚的に整理しやすくなります。

比較項目候補A候補B候補C
月額費用の目安
対応スピード(SLA)
契約形態の柔軟性
専門領域との一致度
総合的な印象

この表を埋めながら商談を進めると、複数社の情報が記憶の中で混ざってしまうことを防げます。

契約切替期: 「同時に2つの関係を維持する」負荷を見込む

契約切替期は、1人で進める上で最も精神的な負荷が高い段階です。旧ベンダーとの契約を丁寧に終わらせながら、同時に新ベンダーとの契約を進める必要があり、2つの異なる関係を同時に管理しなければなりません。

この段階での負荷を下げるための工夫は次の3点です。

  1. 旧ベンダーへの解約の伝え方を事前に整理しておく: 感情的なやり取りを避け、角を立てずに関係を終えるための伝え方は開発会社を解約するときの伝え方。角を立てずに関係を終える交渉マナーを参考にしてください
  2. 移行期間中は新規の依頼を旧ベンダーに増やさない: 切替が決まった時点から、旧ベンダーへの新規依頼は最小限に留め、引き継ぎ関連のやり取りに集中してもらう
  3. トラブル時の交渉は感情を切り離して臨む: 契約終了の交渉で意見の相違が生じた場合の対処法はトラブル時の交渉術: 感情的にならずに解決するを参照してください
旧ベンダーとの関係を終える際、感情的なしこりを残すと、移行後に想定外の質問が発生した際の協力が得られにくくなります。ビジネスライクに、しかし丁寧に終えることが、後々の自分自身を助けます。

契約切替期に1人で進める場合、特に注意したいのが「移行のタイムラインを、旧ベンダー・新ベンダーの両方に同じ内容で共有しておく」ことです。1人で調整していると、旧ベンダーには早めのスケジュールを、新ベンダーには余裕を持ったスケジュールを、というように無意識に異なる情報を伝えてしまい、両者の認識がずれることがあります。移行スケジュール表を1枚作成し、旧ベンダー・新ベンダーの両方に同じものを共有することで、この種の行き違いを防げます。

また、この時期はデータ移行の実務も並行して発生します。データの移行作業自体は新ベンダー側が担うことが多いですが、移行元となる旧システムのデータ構造を理解しているのは、実質的に旧ベンダーか、長年使ってきた社内の利用者しかいません。1人で両者の間に立って情報を橋渡しする必要があるため、移行に伴うデータの欠損や文字化けといったトラブルが起きやすい時期でもあります。この点はリプレイス時のデータ移行で失敗しないためにで具体的な失敗パターンと対策を扱っているので、この段階に入ったらあわせて参照してください。

定着期: 「移行して終わり」にしない

契約の切替が完了した時点で気を抜いてしまいがちですが、定着期こそ1人で進める場合に見落とされやすい段階です。新しいベンダーとの関係が実際に機能するかどうかは、契約後の数ヶ月間の運用で初めて分かります。

定着期にチェックすべき点は次の通りです。

  • 想定していた対応スピード・品質が実際に維持されているか: 契約時の約束と実態にズレがないかを、最初の数件の依頼で確認する
  • 社内の利用者からの評判に変化がないか: システムの使い勝手やサポートの質について、現場からのフィードバックを定期的に集める
  • 旧ベンダーから引き継いだ業務に漏れがないか: 移行時には気づかなかった細かい運用ルールが、後から発覚することがある

定着期がうまくいかない場合、無理に「変更は失敗だった」と結論づけず、新ベンダーとの関係を育てる期間と捉えて調整を続けてください。この時期の付き合い方は開発会社と長期的にうまく付き合う方法も参考になります。

定着期を1人で乗り切るコツは、モニタリングの頻度をあらかじめ決めておくことです。移行直後の1ヶ月は週1回、その後は月1回程度、上記のチェック項目を確認する時間をカレンダーに固定で確保してください。「何か問題が起きたら対応する」という受け身の姿勢だと、小さな違和感が積み重なって大きな問題になるまで気づけないことがあります。定期的に自分から確認しにいく姿勢が、1人で運用を安定させる鍵になります。

よくある失敗パターン

ひとり情シスがベンダー変更を1人で進める際に、実際によく見られる失敗パターンを3つ紹介します。

  • 見極め期を省略し、いきなり候補探しから始めてしまう: 材料が揃わないまま候補探しに時間を使い、後から「そもそも変更する必要があったのか」という疑問に立ち返ることになる
  • 契約切替期に旧ベンダーとの関係が険悪になり、資料提供に協力してもらえなくなる: 感情的なやり取りをしてしまい、準備期に集めきれなかった追加資料の提供を拒まれる
  • 定着期のモニタリングを怠り、問題が表面化してから慌てて対応する: 「移行が完了した」ことに安心し、その後のフォローを疎かにしてしまう

いずれも、段階を意識せず勢いで進めてしまうことが根本原因です。この記事で示した5段階を、面倒に感じても一つずつ踏んでいくことが、結果的に最も早くプロジェクトを完走する道になります。

1人で進めるからこそ意識したい優先順位の付け方

5段階を通じて、本業との兼任の中でどうしても手が回らない場面は必ず出てきます。その際は、「今この瞬間に業務を止めるリスクがあるかどうか」を最優先の判断軸にしてください。交渉の細部や候補選定の比較検討に時間をかけすぎるより、既存システムが止まらないことを最優先に、スケジュールに余裕を持たせることが、1人で進める場合の現実的な優先順位です。

ひとり情シス全体としての優先順位の付け方はひとり情シスの優先順位のつけ方。全部はできない前提で回すでも扱っているので、ベンダー変更以外の業務との兼ね合いで迷ったときはあわせて参照してください。

よくある疑問

Q. 上司や経営層に「1人で進めるのは不安だ」と相談してもよいものでしょうか。

もちろんです。むしろ相談すべきです。1人で進めることを求められているからといって、すべての判断を1人で抱え込む必要はありません。重要な意思決定(新ベンダーの最終選定、契約解除の判断など)については、経営層に判断材料を提示した上で、最終承認を得る形にしておくと、責任の所在も明確になり、あなた自身の心理的な負担も軽減されます。実務の遂行者はあなた1人でも、意思決定の責任者は経営層である、という役割分担を意識してください。

Q. 途中で「やっぱり無理だ」と感じたら、途中で止めてもよいですか。

止めることも選択肢の一つです。特に見極め期や準備期の段階であれば、まだ旧ベンダーとの契約は継続しているため、中断してもリカバリーは比較的容易です。無理に完走することよりも、状況に応じて計画を見直す柔軟性を持つ方が、結果的にリスクを抑えられます。ただし、契約切替期に入ってから中断すると、旧ベンダーとの関係が中途半端な状態になりかねないため、この段階以降での中断は特に慎重な判断が必要です。

Q. 外部の専門家(コンサルタントなど)に一部を手伝ってもらうことは検討すべきですか。

予算が許すのであれば、検討する価値は十分にあります。特に契約書のレビューや、複雑な移行計画の技術的な妥当性の確認など、専門知識が必要な部分だけをスポットで依頼するという使い方であれば、費用対効果も見込みやすくなります。すべてを外部に任せる必要はなく、「1人では判断が難しい特定の局面だけ」に絞って活用するのが現実的です。

まとめ: 段階を区切ることが1人で完走する条件

ベンダー変更を1人で進めることは、決して楽な作業ではありません。しかし、見極め・準備・候補選定・契約切替・定着という5段階に区切り、各段階で「今はこれだけ」と集中する対象を絞り込めば、本業と兼任しながらでも現実的に完走できるプロジェクトになります。

この記事で扱った内容は、あくまで進め方の骨格です。見極め期の材料集めで行き詰まった場合は創業時に依頼した開発会社としか付き合いがない状態から抜け出す準備へ、準備期で契約書・仕様書が見当たらない場合は30-100人規模で基幹システムの契約書・仕様書が見当たらないときの復元手順へ、費用面の判断材料が必要な場合は社員数増加でSaaSライセンス費用が急増したときの見直しタイミングへ、それぞれ戻って読み進めてください。

最後に、1人でベンダー変更を成功させたひとり情シスに共通しているのは、特別な交渉力や技術力を持っていたことではなく、段階を区切り、各段階の完了条件を自分の中で明確にしてから次に進んでいたことです。「今日はここまでで十分」というラインを引きながら、本業とのバランスを取りつつ、着実に前進してください。焦って一足飛びに進めるより、時間はかかっても着実に段階を踏んだ方が、結果的に業務を止めるリスクを最小限に抑えながらプロジェクトを完走できます。

半年から1年という期間は、決して短くありません。途中で疲れを感じる場面も出てくるはずです。そのようなときは、いったんこのプロジェクトを止めてでも、自分自身のペース配分を優先してください。ベンダー変更は重要なプロジェクトですが、あなたが倒れてしまっては元も子もありません。無理のない範囲で、着実に一歩ずつ進めることを最優先にしてください。