データ移行、運用切替について<移行性> | システム導入検討のエッセンス（８）

イントロダクション

RFI・RFPについての第８回、非機能要件詳細についての第５回目になります。
非機能要件の６つの要素のうち、今回からは「移行性」についてお話をしたいと思います。

システム導入によって移行しなければいけないものはデータだけではありません。
今回「移行性」として定義するのは以下の３点です。

それぞれ非機能要件という観点ではなくても要求仕様から漏れることはあまりない要素かもしれません。
既存システムがある場合、旧システムからのデータ移行は必ずといっていいくらいに発生します。運用切替はワンポイント切替、部分切替、並行稼働など色々なパターンが考えられます。システム切替により運用が変わるため研修も必要になります。

ユーザー側だと大規模なシステム導入自体を経験することも稀ですから、切り替えとなるとさらに経験する機会は少なくなります。
ベンダー側だった立場で立ち会ってきた経験も踏まえて、これらの要件について検討すべき内容をお話していきたいと思います。

データ移行について

マスタデータとトランザクションデータ

同じ業務を行っていたシステムを更新する場合、旧システムのデータを完全に捨てることは難しいことかもしれません。
しかしベンダーにとって旧システムからのデータ移行は見積もりが困難な作業の一つであり、本音を言えばできるだけやりたくありません。

データ移行ツールも発達してきており、作業レベルでの難しさは多少緩和されてきているとはいえ、移行対象のスコープが見えづらいからです。

システム内のデータを一般化した時に、概ね以下のような区分になります。

マスタデータはシステムが変わっても業務上は継続して利用しなければいけないものが多いため、移行の対象になりやすいです。また件数や項目、データサイズが比較的固定的で変動が少ないため、移行自体が容易になります。

トランザクションデータは移行の目的が過去履歴の閲覧であることが多いです。もちろん一か所から全ての履歴を確認できるほうが利便性は高いですが、費用対効果を考えなければいけません。
トランザクションデータは件数が日々変化し、項目が必ずしもシステム間で一致しているとは限らず、データサイズも一定では無いため、マスタデータと比較するとどうしても移行が難しく、それだけ作業費が上がりやすい傾向があります。
日々の変動を吸収するためにワンポイントでの移行ではなく、数回に分けての差分移行やそのためのリハーサル回数が増えるのも費用が上がる一因です。

トランザクションデータを移行する場合、どの業務の、いつからのデータのどの内容を、どのタイミングで移行すべきか検討しておくことが必要です。

旧データをシステム外で保管することも検討する

業務上過去データの履歴も管理しなければならない場合もありますが、必ずしも新システムから見えないといけないかというと、別の仕組みで保存しておくこともできます。

一番安価な方法は、旧システムからデータをCSVやEXCEL等の形式で抜き出しておいて、必要な時にファイルを開いて検索する方法です。
旧システム側の仕様にもよりますが、概ねこういった機能は有しているので、ユーザー側で作業すれば費用はかかりません。

最近はCSVやEXCELをデータベースとして読み込んで抽出・閲覧するようなBIツールもあるので、一概に不便な方法とは言い切れません。データの管理が分断されることをよしとするかどうかの判断次第かもしれません。

他には新システムのアドオンとして閲覧専用機能を別途設けたり、別システムとして簡易的な閲覧機能だけ構築する等の方法もあります。ただし個別開発で費用が発生するので、そこまで細かい費用の幅を気にするよりは新システムへの移行を選択する、という結論になることも考えられます。

運用切替

スムーズな移行には切替タイミングが重要

旧システムの有無に関わらず、新システムが導入されるということは業務運用が変わります。一気に切り替えることができれば良いのですが、規模が大きかったり外部要因の影響を受けることで一度に全ての業務を切り替えることが困難な場合があります。

経費精算を例に説明します。

経費精算で最初に気を付けなければいけないのが会計年度の問題です。
会計年度が4月で切り替わるとして、新システムが2019年4月に稼働するとします。
4月1日時点で発生する経費には、発生日が前日以前、つまり前年度の費用として計上しなければいけないものが多数あります。
その場合、前年度の費用は新システムで処理すべきか、切替前の方法（紙運用や旧システム）で処理すべきかという問題があります。

新システムで処理しようとすれば、新システム側に2018年度の予算と執行状況を持っておく必要がありますが、執行データはトランザクションデータであり、どの時点を持って確定として移行させるか非常に難しいです。
4月1日以降に遡りで登録されるデータ以外に、3月31日に旧システムに登録はしているけど決裁されていないものもあり、4月1日にいきなり全部を新システムが引き継ぐのは非常に困難です。

2018年度中に2019年度の経費として処理しなければいけないものも考慮しなければいけません。例えば4月以降の出張旅費の仮払いを3月中に申請する場合等です。
切替前に2019年度の経費処理を行ったものは、新システムに自動的には反映できません。

システム切替時にはトランザクションデータの取り扱いに注意が必要です。
ステータスが確定しておらず、今後の処理はそのまま進むのか取り下げられるのかが決まっていないため、確定を待ってしか対応を行うことができません。

旧システムの面倒を新システムは見てくれない

システム切替による運用混乱をできるだけ回避するためにには、これらの考慮が必要です。
しかし調達時点でこれらの細かい要件まで決定することはできません。
しかし運用方法によっては、いつまで旧システムを動かす必要があるか等にも影響してきます。

RFPではシステム切替についての計画作成フェーズを設けることや、それをどのタイミング決めるのか、考慮すべき事項としてどのようなことがあるのかを記載するようにしましょう。

新旧のシステムが同一ベンダーであっても、これらの移行について新システム側が主体的に動くことは難しい面があります。運用についてはどうしてもユーザー主体での切り分けを必要とします。
切替を行う時にどのような影響があり、どのような方法で回避できるかという観点で現行運用をヒアリングするようにしましょう。

あとがき

移行性を検討する具体例

大規模システム導入でなくても、新たにシステムを導入する＝運用が変わる場合、移行性の考慮は必要不可欠です。

例えば以前お話をしたことがあるファイル転送サービス導入について、セキュアなサービスの利用開始にあたって、無料サービスの閲覧規制をセットで検討しました。
新サービスの移行と同時に閲覧規制を開始した場合、例えば切替直前に無料サービスでファイルを送付もしくは受信したものについていきなり見ることができなくなります。

セキュリティのために止む無しとして新サービスでの再送を依頼するか、運用が定着するまで並行運用期間として閲覧規制のタイミングを後にするか。
どちらが正解というわけでは無く、どちらにするか決めた上でそれによって発生しうるリスクに対して対策を考慮しておくことが必要です。

私の場合後者の並行運用とした上で、無料サービス利用者をWebフィルタリングで抽出して、切替を促したり移行状況をトレースして、運用影響を最小限にした上で規制を開始しました。

たかだかファイル転送サービスの導入ですが、移行性の考慮が利用者だけではなく情シス自身の負荷をコントロールすることにも繋がります。
一気に規制して一時的に発生する運用混乱を終息させることに力を注ぐか、並行運用にして運用周知やWeb監視に力を注ぐか。
ひとり情シスだと一人で処理できる業務量に限界があり、突発的な問い合わせより計画作業化を選ばざるを得ないということもあり、私は後者を選びましたが、全ての企業・団体で同じ方法が適しているわけではありません。

あるべき姿はもちろんありますが、現実的な着地点も持ち合わせておくようにしなければ、実現不可能な計画は絵に描いた餅にしかなりません。

RFI・RFP／プロジェクト管理関連の記事を纏めています。