はじめに
ベンダーリプレイスを検討すべき3つのタイミングと進め方では、ベンダーを乗り換えるべきタイミングについて解説しました。実際にベンダーを変更すると決めた後、発注側にとって最大の難所になるのが、旧ベンダーから新ベンダーへのデータ・ノウハウの引き継ぎです。この引き継ぎに失敗すると、せっかくベンダーを変えても同じ問題が再発してしまいます。
ベンダー変更時の引き継ぎが、通常の担当者交代より難しい理由
ベンダーのキーマンが離任・退職したときに発注側がすべきことで触れた担当者交代の引き継ぎも難しいものですが、ベンダー自体の変更は、それ以上に難易度が高くなります。旧ベンダーからすると、契約を失う相手であるため、引き継ぎに対するモチベーションが低くなりがちだからです。
契約上、引き継ぎ義務が明記されていたとしても、「最低限の対応」で済まされてしまうことは珍しくありません。発注側としては、この構造的な問題を前提に、引き継ぎのプロセスを主体的にマネジメントする必要があります。
引き継ぎで確認すべき3つの要素
ベンダー変更時の引き継ぎでは、少なくとも次の3つの要素を漏れなく引き継ぐ必要があります。
① データ
システムが保持しているデータそのもの（データベースの内容、過去の設定変更履歴など）を、利用可能な形式で確実に受け取ります。データの形式や、旧システム固有の仕様（独自のコード体系など）についても、合わせてドキュメント化してもらう必要があります。
② ドキュメント
設計書、運用手順書、過去の障害対応履歴など、プロジェクトに関する文書類を網羅的に受け取ります。「最新版と言われていたが実は古かった」ということがないよう、ドキュメントが実際のシステムの状態と一致しているかの確認も必要です。
③ 暗黙知
最も引き継がれにくいのが、文書化されていない暗黙知です。「なぜこの仕様になっているのか」「この設定を変更すると何が起きるか」といった背景情報は、旧ベンダーの担当者へのヒアリングでしか得られません。引き継ぎ期間中に、新ベンダーと旧ベンダーが直接対話できる場を、発注側が主導して設定することが重要です。
引き継ぎ期間を契約・スケジュールに明確に組み込む
引き継ぎを確実に行うためには、ベンダー変更の契約段階で、引き継ぎ期間とその対応範囲を明確に契約・スケジュールに組み込んでおく必要があります。旧ベンダーとの契約終了ギリギリまで本来の業務が続き、引き継ぎが駆け込みで行われるような計画では、十分な引き継ぎは期待できません。
新ベンダーとの契約開始時期と、旧ベンダーとの契約終了時期の間に、ある程度の重複期間を設け、その期間を引き継ぎに充てる計画を立てることをおすすめします。
まとめ
ベンダー変更時の引き継ぎは、旧ベンダー側のモチベーションが下がりやすいという構造的な難しさがあります。データ・ドキュメント・暗黙知の3つを漏れなく引き継ぐこと、そして引き継ぎ期間を契約・スケジュールに明確に組み込んでおくことが、ベンダー変更を成功させるための実務上のポイントです。
執筆者プロフィール：SIer（元請け）とITコンサルファーム（発注側支援）、両方の立場でプロジェクトに従事（通算9年）。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。
コメント