2022
5/23
ベンダー提案書におけるプロジェクト計画の評価項目は、主に6点あります。
① スケジュール
② 開発手法
③ 移行計画
④ プロジェクトマネージャー
⑤ プロジェクト体制
⑥ ユーザー教育
そのうちの、「③ 移行計画」について解説します。
③ 移行計画の見どころ
移行は、各ベンダーによってスタンスが大きく変わってきます。
「一切、移行しません」
「マスタだけ移行します」
「マスタもトランザクションも全て移行します」
と、大きく3つに分かれます。
まず、移行については、評価する前に自社の方針を明確にしておく必要があります。
現行システムから全データを移行するのが望ましいですが、費用も期間もかかります。
例えば
・現行システムのデータが不整合だらけ
・任意入力のため信頼性が低い
・イレギュラーが多すぎる
などの場合は、そもそも移行する価値が低いといえます。後でその過去データに起因するトラブルが発生したり、集計値が大きくずれたりします。
新システムに「インポート機能」があるなら、ユーザー側でデータを準備することも有力な選択肢になります。いったんエクセルでデータをクリーニングしてから入れることで、移行データの品質を高めることもできます。
一方で、
・20年、30年と蓄積した大量のデータがある
・それらの過去データに価値がある
場合は、ベンダーに頼んで移行してもらうべきです。
移行を経験した人はわかると思いますが、データ移行はかなり大変です。ベンダー側も大変ですが、どちらかといえばユーザー側の方がもっと大変です。
なぜなら、ベンダーは現行システムのことを理解するため、ユーザーに対して「質問攻め」にしてくるからです。
「現行ベンダーと新しいベンダーで直接やりとりさせればいいのでは？」と思うかもしれません。
しかし、そもそも現行ベンダーはもうすぐ切られるのに、どうして積極的に協力してくれるのでしょうか。
さらに、システムに対して「どう入力しているか」「どう運用して使っているか」は、現場ユーザーに聞かないとわかりません。
そのため、大量の「質問攻め」に対して、プロジェクトメンバーが窓口になり、現場ユーザーに聞くものと現行ベンダーに聞くものを仕分けして、それぞれに投げることになります。
これが、データ項目の数だけ発生するので、それを1つ1つさばいていくだけで、気が狂いそうになります。
さらに、実際にデータを移行してみると、多くのエラーが発生します。調べてみると、仕様書にないコードが入っていたり、任意入力でほとんど値が入っていなかったりと、イレギュラーデータということがわかります。
それらの経緯について、さかのぼってベンダーや現場ユーザーに確認していき、発生した原因と対処方法を検討していく必要があります。
大量のイレギュラーデータを調べたら「移行データの移行データ」ということもあります。現行システムが20年前に稼働した当時の旧システムから移行したデータ、という意味です。だからデータ規則が守れていないイレギュラーデータばかりだったのかと後で腑に落ちました。
移行データが大量にあり、かつ歴史がある場合には、このようにデータの不備に振り回されることになります。その絶望的な件数の前に、ユーザーだけでは心が折れそうになります。そういったケースにおいては、ベンダーの「献身的」な協力が不可欠となります。
もし、ベンダー側の経験が浅いと、「移行仕様を提示してください」と下請け業者のセリフが出てきます。移行マッピングのテンプレートだけ提示され、マッピングの中身を埋めて返してください、と言われます。
一方で、経験があり親身に対応してくれるベンダーであれば、踏み込んで考えてくれます。現行の設計書やデータを渡したら、そこからマッピングを作成し、一緒に考えてくれます。イレギュラーデータがあった場合も、一緒に現行ベンダーに聞いてくれたり、対処法を積極的に提案してくれたりします。
つまり、移行の経験値が高いベンダーの場合は、同じプロジェクトメンバーとして、当事者意識をもって進めてもらえます。
データ移行が必須要件の場合は、遠慮せず細かく確認する
もし、現行システムがスクラッチ開発で長いこと稼働していて、データ移行が必須である場合は、ベンダーの移行提案を慎重に評価していく必要があります。言い換えれば、どこまで深く入り込んでくれるかを確認します。
全体の移行計画書、移行手順書、リハーサル計画、移行ツール開発、データマッピング作成、移行オペレーションの役割分担など、細かく提案内容をみていきます。
ただし、当たり前ですが、移行を手厚くやってもらうと、移行費用は高くなります。逆に、移行費用がほとんど積まれていない場合は、ベンダーは移行をほとんどやらない可能性が高いといえます。移行をお願いしているのに、移行費用が含まれていない場合は、細かく突っこんで確認していくと、ほとんどやってくれないことが判明します。
移行については、確認を怠ると後で苦労するのはユーザー側です。ベンダー側がどのような移行を想定しているのか、ここは遠慮せずに細かく確認していくべきです。
（プロジェクト計画の各項目解説）
【提案評価その4】プロジェクト計画「①スケジュール」をどう読み解くか？
【提案評価その4】プロジェクト計画「②開発手法」をどう読み解くか？
【提案評価その4】プロジェクト計画「③移行計画」をどう読み解くか？
【提案評価その4】プロジェクト計画「④プロジェクトマネージャー」をどう読み解くか？
【提案評価その4】プロジェクト計画「⑤プロジェクト体制」をどう読み解くか？
【提案評価その4】プロジェクト計画「⑥ユーザー教育」をどう読み解くか？
