ベンダーがデータ移行を拒否すると苦しい。でも、やるしかない

データ移行を拒否するベンダー

「人不足でして、我々では移行をお手伝いできません。他を当たってください」

ある基幹システムプロジェクトに途中からご支援しました。新システムの構築は進んでいるのですが、ベンダーに「データ移行」を拒否されたとのこと。

まさかの展開です。

要件定義の際に、データ移行は手伝ってもらう方向で進んでいました。しかし、そのベンダー担当者は「体調不良」という理由で、フェードアウトしてしまったようです。そのときの議事録を探しましたが、見つけることはできませんでした。

ユーザー企業は、基本的にシステムのプロではありません。だから、専門家であるITベンダーに頼んでいるのです。それは、「新システム構築」だけではなく、現行システムから新システムの「データ移行」も、専門家にお願いしたいからです。

新システムの構築も開発フェーズに入り、忙しくなってきました。その中で、ベンダーからまさかの拒否です。でも、プロジェクトが中途半端に進んでいるため、今さらベンダーを切り替えることはできません。事実上、この新しいベンダーに「ロックイン」されています。

どうすればいいのでしょうか？

ベンダー選定が分岐点

必ずしも、全てのシステムでデータ移行が必要というわけではありません。しかし、基幹システムにおいては、業務継続性の観点から、データ移行は必須要件といえます。

その場合、本来であれば、RFPを作成する段階で「データ移行は絶対条件」と明記しておけばよかったと思います。

移行に積極的に協力してくれるかどうかは、ベンダーによって差が出てくるところです。そのため、最初からデータ移行を「スコープ」に含めていれば、揉めることはありません。

しかし、今回はその段階での確認が不十分だったのかもしれません。ですが、今さら言っても始まりません。今、ここからどうするか、が問題です。

ベンダーが移行を拒否する理由も、理解はできました。現行システムはドキュメントが整備されておらず、かなりの「ブラックボックス」です。このあと、データ移行を進めるにあたって、かなりのリスクがあることを感じ取ったのでしょう。

彼らがリスクや採算を考え、勝算のない案件を避けるための判断だと思います。

だとしても、急に「スコープ外」と言われると困ってしまいます。

ですが、プロジェクトってそんなもんです。計算通りにいかないことばかり。大変だからこそ、プロジェクトなのです。

こういうときに、過去のプロジェクトで苦しんできた経験は役に立ちます。大変ですが、「これまでの大事件ワースト10位にも入らない」とか、「アレよりはマシ」と、開き直ることができます。

プロジェクト体制強化

というわけで、これからどうするか考えていきます。ユーザー企業はITの専門家が少ない上に、情シスメンバーも忙殺されており、余力がない。でも何とかしないといけない、という状況。

基本的には、プロジェクト体制を厚くしていく他ありません。

・現行の保守ベンダー側から人を出してもらう
・情シスからさらに人を出す
・ユーザー部門からさらに人を出してもらう
・中途採用でIT人材の即戦力を迎える
・外部のPMOコンサルと契約する

まず、現行の保守ベンダーに移行支援メンバーを出してもらうことを要請します。もちろん、追加費用は払うと伝えました。

しかし、拒否されました。もう新システムに乗り換えるのに、関係性は壊れていました。協力を得られません。

一方で、情シスからさらに人出せないか、聞いてみました。本来は、ここぞという時に、情シスが踏ん張るべきです。

ところが、最近になってエースだった人が離職してしまい、現在はその穴埋めで、情シス全体が大忙し。まったく余裕がないそうです。

なかなか、厳しい状況です。でも、可能性を1つずつ、当たっていく他ありません。

そこで、プロジェクトオーナーである事業部長に、相談します。無理を言って、ユーザー部門から若手2名を追加アサインしてもらいました。この若手2名で「移行の新旧データマッピング」を進める他はありません。

つまるところトップダウン

データマッピングをするために、ベンダーに新システムのテーブル定義書を要求しました。すると、さらに驚きの返事がきます。

「パッケージシステムなので開示できません」

（は？何言ってるの？じゃあ、どう移行しろと？）

と、少し感情的になりかけましたが、この状況を打開することが優先です。

このベンダーPMとの話し合いでは解決が難しかったため、先方オフィスで経営層同席のもと、協議の場を設けました。こちら側はプロジェクトオーナーの事業部長（取締役）に同席してもらっています。

すると、ベンダー側も今回のプロジェクト責任者のさらの上の、取締役の方が出てこられました。

そこで、これまでの経緯を説明し「このままだとプロジェクトが頓挫するリスクが高い」と訴えました。取締役クラスになると、短期の採算よりも長期を見据えたような受け答えが感じられます。

その場で、例外的にテーブル定義書を開示することを即決してもらいました。さらに、追加費用なしで、移行専任者を1名出してもらうことまで約束してもらえました。

その様子をみて「今回のキーパーソンはこの人だ」と感じました。ダメ元で、「ご都合が合えばで構わないのですが、今後のステコミにも出席していただけないでしょうか」と相談したところ、快諾していただきました。

やはり、プロジェクトは「トップダウン」です。担当者レベルで解決できない問題はエスカレーションして、権限を持つ層に関与していただくことが重要となります。

データ移行は大変、でもやるしかない

さて、ユーザー部門の若手2名で移行データマッピングを進めることになりました。

「やったことがない」と抵抗されましたが、「これはパズルと考えてください。似たような名前を紐づけするだけです。そんなに難しくないです」と全力で説得しました。

最初の3テーブルぐらいは私と一緒にマッピングして、要領をお伝えします。その後は、さすが若手は飲み込みが早い。次々とテーブルマッピングを完成させました。

移行プログラムは、情シスが愛用していたノーコードツールで実装することにしました。最初に情シスからレクチャーを行い、その後はユーザー若手2名で実装を進めました。難しい部分は情シスも手伝いながら、次々と作っていきます。最初は苦労していたようですが、最後は完全なるスペシャリストになりました。

次に「リハーサルは失敗してもいい。走りながら修正するのが最短だから」と伝えます。そんな中、リハーサル1回目は予想通りボロボロでした（涙目）。半日で終わるはずの移行作業が、丸3日かかりました。そこから修正を重ねて、5回目のリハーサルでは、ほぼエラーはなくなります。

正直、移行は死ぬほど大変でした。めちゃくちゃ、時間を奪われます。1つ1つはさほど難しくなくても、とにかく量が多い。だから、他のプロジェクトメンバーも全員で検証作業に協力しました。

気付くと、あれだけ拒絶したベンダーも移行に協力的になっています。リハーサルのときも、一緒に立ち会っていただき、不具合はすぐに調査してもらえました。おそらく、裏で取締役の方が動いていただいたのだと思います。

このプロジェクトの成功への道筋が見えてきた瞬間でした。

ベンダー選びがすべて

「次はベンダー選定をきちんとやります」

情シス部長に言われました。

プロジェクトは予定よりも半年遅れました。かなりの追加費用も発生します。

でも、何とか稼働にこぎつけました。

その後もトラブルは何度もありましたが、お互いの取締役に相談し、トップダウンで鎮火させていきました。

こんなにも苦労したのは、やはり「データ移行」です。ここにユーザー側のパワーをすべて吸い取られてしまったからです。

基本的に、ベンダーは契約時に約束したことしかやりません。だからこそ「ベンダー選び」は重要です。プロジェクトメンバーの皆様は、今回の苦い経験から、ベンダー選定の重要性を痛感したと思います。

ベンダー選定に1ヶ月余計にかかるのと、あとで6ヶ月以上苦しむのと、どちらがいいでしょうか。

貴社のIT部門・情報システム部門は、ベンダー選定プロセスを慎重に進めていますか？