データ移行を自分でやりたがる情シスと逃げるベンダー

自ら手を挙げる情シス

「現行システムを知っているし、ユーザーとの連携も必要だから、ウチでやった方が早いですよ」
「それに、移行費用が高すぎます」

ある基幹システム再構築プロジェクトでのことです。要件定義が終わり「データ移行」の見積もりを取得したところ、想像以上に高額な金額が提示されました。

そこで、情報システム部門（情シス）の中心メンバーであるAさんが、自ら手を挙げました。「自分がやります」と。

すると、ベンダーの営業担当者も便乗するように言いました。

「私もAさんのご意見に賛成です。Aさんはスキルも高いですし、十分に対応できると思います。もちろん弊社でやることも可能ですが、その分費用がかかってしまいます。御社で対応できるのであれば、それが理想的ですし、費用も抑えられますよね」

この状況を受けて、情シス部長はデータ移行の依頼を取り下げる方向に傾いていきました。

そこに私が待ったをかけます。

「データ移行は、お金を払ってでもベンダーにやってもらうべきです！」

困惑した表情を浮かべる情シス部長。

なぜ私は反対するのか？そして情シス部長として、どう判断すべきなのでしょうか？

何度も見てきた失敗パターン

私が反対するのには、明確な理由があります。このケースの失敗を、これまで何度も目にしてきたからです。

私は職業柄、プロジェクトがトラブルに陥り、自力での解決が困難になったタイミングで相談を受けることが多くあります。話を詳しく聞いていくと、「データ移行」が問題の核心であるケースが非常に多いのです。

さらに詳しく状況を確認すると、データ移行でスケジュールが大幅に遅延しています。嫌な予感を抱きながら「誰が担当しているんですか？」と尋ねると、やはり情シスが自らやっているのです。

スキルの高い情シスメンバーは積極的

最近は情シスの転職も当たり前になっており、ベンダーから転職してくるケースも増えています。元システムエンジニアの情シスメンバーは、当然ながら技術スキルが高い人材です。

自分でプログラムを書けますし、SQLを駆使してデータベースの中身を直接操作することもできます。Excelマクロやノーコードツールによる実装は、得意中の得意です。

ユーザー部門から相談を受けると、サクッと便利ツールを作ってしまいます。ユーザーの手作業が自動化され、ユーザーは大喜び。そんな情シスメンバーは、ユーザー部門から絶大な人気と信頼を得ています。

毎日のようにユーザーから相談があり、それに楽しそうに応えている姿が見られます。業務の理解が進み、ユーザーとの良好な関係性が形成されると、自然と自信が湧いてきます。

つまり「システム開発」にまったく抵抗がありません。それどころか、積極的に自ら手を動かしていきます。「自分にしかできない」「大丈夫だ」と、情シスメンバーは思ってしまうのです。

規模の問題

しかし、基幹システムにおけるデータ移行は、まったく次元が異なります。

まず「規模」が違います。現行システムに50のテーブルがあるとすれば、感覚的にはテーブル数の2倍、つまり100個もの移行処理を作成しなければなりません。

「1対1」で移行できるなら楽ですが、実際には「多対多」の移行や、段階的な「パッチ処理」を重ねていく移行、複雑な「コード変換」や「ステータス更新」なども必要となります。移行処理は、膨大に膨れ上がっていくのです。

しかも、日常的に作る便利ツールとは異なり、しっかりとした「テスト」が不可欠です。単体テストはもちろんのこと、結合テストも実施し、最後は移行リハーサルで「通し」の確認も必須となります。

これを一人でやろうとするのは、現実的ではありません。Aさんは確かにスペシャルな人材ですが、対応できるのはAさんだけです。正義感の強いAさんは「大丈夫、できますよ」と言ってくれますが、気持ちが高ぶって冷静な判断が難しくなっています。

プログラマーは、手を動かす実装が大好きです。だから、やりたがるのは理解できます。技術的にはそこまで難しくないかもしれません。しかし、一人では「規模の問題」に太刀打ちできないのです。

マネジメントリスク

さらに、別の問題もあります。何でしょうか？

それは、マネジメント的にリスクが高すぎるということです。

Aさん自らが実装しても、情シスの他のメンバーは誰もレビューできません。バグやトラブルが発生した場合、Aさんしか対応できず、問題が立て込むと必ず「ボトルネック」となります。

ましてや、Aさんが体調不良などで動けなくなると、プロジェクトはなすすべもなく停止してしまいます。プロジェクト全体の遅延の原因が、移行になりかねないのです。

するとどうなるのか？

ベンダーは体制維持のために「追加費用」を要求してきます。仮に数カ月の延期となっただけで、膨大な費用が発生します。

この遅れはベンダーの責任ではなく、ユーザー側の責任です。そのため、追加費用を断るのは至難の業となります。

そして皮肉なことに、その追加費用は「高すぎる」と言っていたベンダーの移行費用見積もりよりも高くなってしまうのです。

もともとは移行費用を浮かせるために情シスが巻き取ったのに、結局は情シスに大幅な労力がかかり、費用も余計にかかってしまう。これほど皮肉なことはありません。

徐々に焦りが募ってくると、スケジュールを遅らせないよう、情シス側は「品質」を犠牲にして「スピード」を優先するようになります。

具体的には、テストを省略し、移行リハーサルで「ぶっつけ本番」となります。移行リハーサルはボロボロで、最後までたどり着かないことも頻繁に起きます。何度か「追試」を行いますが、最後は「見切り発車」で本番稼働に滑り込むのです。

しかし、テスト不十分なため、本番稼働後に移行データの不具合が発覚してしまいます。その場合、取引先への請求誤りや納品書の数量誤りなど、被害は「社外」にまで及んでしまうのです。

受け入れテストまでも⋯

これだけでも十分に目も当てられないほどの大惨事ですが、影響は他にもあります。何でしょうか？

それは「PMO機能」が崩壊するということです。

中心メンバーのAさんが、移行作業につきっきりになってしまうと、本来やるべき役割が宙に浮きます。情シスの重要な役割であるPMOが、手薄になるのです。

情シスに十分なリソースがあるならよいのですが、大抵の情シスはカツカツです。みんな多くの業務を掛け持ちしていて、余力など捻出できません。

この会社の情シスは5名しかおらず、3名は運用保守を担当しているため、PMO業務ができるのはAさんともう一人のBさんだけです。

今度は、このBさんがパンクしてしまうのです。

PMOが破綻すると、ユーザーのフォローが不十分となります。その結果、ある致命的な影響が発生してしまいます。

それは「受け入れテスト」です。

受け入れテストが大幅に遅延し始めるのです。「テスト項目書作成」「テスト環境準備」「テストデータ準備」など、PMOがフォローすべきタスクが後手に回るからです。

つまり、移行の遅れだけではなく、受け入れテストも大きく遅延していくことになります。

完全にベンダー側の責任ではなく、ユーザー側の責任でプロジェクトが遅れていく構図。結局は、ベンダーから「追加費用」を請求される状況を避けられません。

正しい役割分担とは

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

移行はベンダーに依頼し、Aさんの移行スキルは「レビュー」に充てるのです。

ベンダーが実装、情シスがレビューという役割分担です。これこそが、リスクを下げ、品質を高める唯一の体制です。

ベンダーに移行を依頼することで、ベンダーは体制を組み、分業して対応できます。並行して作業できるため期間も短縮できますし、ベンダー内のテストやレビュー体制で品質も高まります。

そこにさらに、情シスの視点でレビューを加えることで、品質はさらに向上します。情シスはユーザーへの移行仕様のヒアリングに専念すれば、移行スケジュールの短縮にもつながります。

つまり、情シスが移行を巻き取ることは「百害あって一利なし」なのです。計画段階では費用が浮くように見えても、現実はもっと高く付きます。

ユーザーとベンダーの双方で適切な役割分担・分業を行わないと、プロジェクトは乗り切れません。

逃げるベンダーの実態

ちなみに、それに便乗しようとするベンダーの姿勢にも疑問を感じます。最近、移行を拒否してくるベンダーが多いのも事実です。

ベンダーにとって、データ移行はリスクでしかありません。他社が作った現行システムの理解から始めなければならず、手間がかかります。現行の設計書が不十分というケースも珍しくありません。

格納されているデータの質の悪さにも振り回されます。一世代前の移行データが不整合だったり、ユーザーがルールを無視して入力しているケースもあります。データ品質が悪ければ、設計書通りに移行しても不具合が多発し、遅延が発生してしまいます。

ベンダーは経験上、データ移行が大変なことを誰よりも一番理解しています。プログラムを動かしてバグが見つかるのは日常茶飯事で、そのたびに移行のリカバリに追われます。移行の工数は、相次ぐリカバリで計画よりも大きくはみ出るのが常です。

だから、ベンダーは移行を嫌がります。移行体制もしっかりと組む必要がありますが、人材調達も大変です。だから、移行費用は高く吹っかけます。そして、断ってもらうよう誘導してくるのです。

ベンダーの責任とは

しかし、移行が困難だからこそ、ベンダーがユーザーと一体となって乗り切る体制にしないと、そもそもプロジェクトは成功しません。ベンダーの移行ノウハウこそ必要なのです。

それなのに、過度にリスクを嫌ってユーザー領域に踏み込まず、こうなることを分かっていながら静観しているベンダー。涼しい顔で安全地帯から、ユーザー側の遅れを心配するフリをするだけのベンダーには、正直怒りを覚えます。

本当にユーザーに寄り添っているのか、と。

それこそ、最初の「ベンダー選定」を間違えたとすら思います。RFPに移行要求をしっかり明記して、最初のプロジェクト計画書に盛り込んでおかないと、こうなってしまうのです。

こうして「移行をやりたがる情シス」と「逃げるベンダー」というパターンが、最近急増しています。そして、失敗後に相談がやってきます。これは単なる悲観論ではなく、実際に相談が増えている現実なのです。

ここからが勝負

「追加予算の調整が大変でしたよ〜」

情シス部長が言いました。ベンダーに改めて見積もりを依頼したところ、かなり大きな金額が提示されました。しかし、情シス部長が頑張って経営層を説得し、承認を得ます。Aさんも、ベンダーに依頼する意義を理解してくれました。

これは、プロジェクトの成功確率を高めるために必要な役割分担です。ベンダーも腹をくくって、移行のスペシャリストをアサインしてくれることになりました。プロジェクトの致命的なリスクを1つ回避した瞬間です。

ただし、これからも気を抜けません。プロジェクトはここからが勝負です。頑張っていきましょう！

貴社のIT部門・情報システム部門は、データ移行をあえてベンダーに依頼していますか？