数多くのデータ移行に携わってきたのですが、ユーザ部門の担当として社内サイトの移行方針を聞いたので、その感想を共有します。

プロジェクトからの説明を聞きながら私は、以下のようなことを考えていました。

本記事では、データ移行でユーザ部門（業務部門）に伝えるとよい内容を紹介します。

以前、CRMアプリを導入する際にユーザに伝えるとよい点を別記事で紹介しました。

CRMアプリのユーザートレーニング時に伝えたい4つのポイント

こちらの記事では、現行担保の言い訳説明はあまりいらなくて、むしろ新しいツールでよくなる点をちゃんと知りたい、という点を強調しました。

しかし、こと移行に関しては、移行先の新しい話だけだと不十分です。移行元のデータとか機能の移行先が適切に用意されていることの担保が大切になります。

移行するのかしないのかの判断基準

移行先の中には、もう使わないから「データや機能を廃止すること」も含まれます。使わないデータや機能は、だんだんその内容自体を知る人も少なくなるので、廃止していいかの判断もしづらくなります。なんでも移行するのではなく、移行するかどうかを判断することをおすすめします。

移行するのが技術的に大変とかとか、移行するのにかかる業務工数はいったん置いておき、まずは今後も業務としてそのデータや機能を使うのか、使って生み出される価値はあるのかを評価するのが大事です。

ユーザ部門にその判断材料をプロジェクトとして提供してくれるとうれしいです。

移行オプション

移行方針書に記載される項目は以下のようなものです。

• 移行対象
• 移行スケジュール
• 移行アプローチやオプション
• 移行体制

自分たちが業務で作成していたデータや機能は移行対象になっているのか、まずは対象スコープを知りたいですね（上の移行するしないの判断も含め）。

それをいつ移行するのかスケジュールが知りたいです。移行には期間があるため、移行先への移行作業が開始できるタイミングや、移行元自体が業務で使えなくなるのがいつなのかを把握することが必要です。

さらにデータや機能ごとに移行するオプションがいくつかある場合は、それぞれのメリット・デメリットを知りたいです。技術的な制約はどういうものがあるのか、協力会社や専門部隊への業務委託する全体方針があるのか、部門ごとに対応するとしてどういうサポート体制になっているのか、など。

オプションで少し触れましたが、移行全体を統括するプロジェクトと我々のように実施する部門との関係も含めて移行に関わる体制も共有してほしいです。

方針に沿って具体的な移行手順

ユーザ部門は、それぞれが持つ移行対象ごとに移行オプションを選定し、各自のスケジュールで対応をしていく必要があります。

それは全体的なシステム停止に影響されるものもありますし、事前に部門ごとにデータを整備したり、移行ツールを使って移行先で構築するものもあります。

プロジェクト開始時点で具体的な作業の詳細まで知ることはできませんし、その必要もないので、今後どのタイミングでどういった手順が提供され、部門でどう計画し対応していけばよいのか、また移行統括側で何を把握しておきたいのかがわかるとよいです。

終わりに

移行プロジェクトで統括する側に立つと、全体像が見えている中で個別部門にやってほしいことを総論で語ってしまい、部門ごとに自分たちはどうなるのか？どうすればいいのか？といった疑問にまで行き届かないことがあります。

これは一発で完璧な計画や方針を立ててほしいという意味ではありません。同じプロジェクトとして双方の事情を理解し合いながら進めていければと思います。