ERPの落とし穴part4～システム移行という名のデスマーチ

業務システムの開発案件では、最後にシステム移行と言う名のデスマーチがある。
ラフなメモ書き。

【1】業務システムの開発ではリプレース案件が非常に多い。
例えば、リプレース案件の発端は色々ある。
今までのCobolやVBのシステムをWeb化したい。
年々性能が悪くなった旧式のWebシステムを、Ruby on Railsのような最新のフレームワークのシステムへ変えたい。
iframeを使いまくった古いWebデザインを捨てて、アクセシビリティに配慮した最新のUIを持つWebシステムに変えたい。

すると、現行システムを廃棄して、新システムへ移行する開発プロジェクトもすごく多い。
いわゆるリプレース案件なのだが、普通はデスマーチになるパターンが経験的に多い。

システムのリプレース案件が最も危険な理由: プログラマの思索

リプレース案件が大変なのは、現行システムの機能は満たした上で更に機能追加してくるために、ひどいパッチ当てが発生しやすい点にあると思う。
保守性、移植性という品質特性がボトルネックになってしまうのだ。

アジャイル開発が重視する品質特性～保守性と移植性: プログラマの思索

また、リプレース案件では、現行ステムから新システムへ移行する作業が必要になる。
このシステム移行作業は、非常にリスキーな作業で、デスマーチになりやすい。
システムが変わったとしても、ユーザの業務に影響ないように、システムを入れ替えるのはすごく大変な作業だ。
サーバーの入れ替え、モジュールの配置タイミング、本番データの移行作業など、作業の大変さを考えるとキリがない。

【2】システム移行の方針はいくつかのパターンがある。
以下、説明してみる。

単純移行は、現行システムから新システムへ切り替えて稼働する手法。
ウォーターフォール型開発では、本番リリース日に新システムへ一斉に切り替わるために、前準備に相当の作業負荷がかかる。
直前まで修正していたモジュールをリリースの1週間前にはコードフリーズしておき、稼働確認する作業もある。

特に本番データ移行作業では、ユーザが直前まで使っていた本番データを新サーバーにインポートしないといけないから、作業時間をあらかじめ見積り、手順を十分にレビューして置かなければならない。

また、単にそのままデータを移すだけではなく、新しいコード値に採番し直してインポートする時もある。
その場合、採番し直すプログラム(移行ツール)を新規に作る必要があり、テストによる事前動作確認や、データ量によってどれだけの変換の時間がかかるかも計測するとなると、その分だけ工数が増える。
しかも、実際の本番データにクレジットカード番号などの個人情報が含まれていれば、本番データを使うこともできないために、単体テストではうまく動いても、実際の本番データ移行作業で障害が発生する時もある。
だから、とても気を使うものだ。

実際の移行作業では、全ての機能をすぐに本番稼動できない時もある。
その場合は、一部の機能を制限して、部分稼動させる手法もある。
例えば、新システムでは、データ量が増えた場合は画面操作を受け付けなくなる場合があるため、その場合は、あらかじめ開発者が本番環境からデータを抽出しておき、ユーザに届けて、手運用でカバーするやり方などがある。
その場合、システムの機能が全て使えない状況であることをユーザにも承諾してもらい、時間の猶予をもらって、その間に機能を改善する手法が取られるだろう。
つまり、顧客調整というプロジェクトマネジメント能力がかなり要求される。

単純移行は、移行手順は簡単だが、他の方式に比べてリスクが大きく、高い信頼性が要求される時が多い。

【3】並行稼動は、現行システムと新システムをある一定期間中は両方稼動させて、本番稼働日に新システムへ切り替える手法。
普通、並行稼動の期間は、ユーザが現行システムと新システムを両方使いながら、受け入れ検証を行ったり、新システムの使い方に慣れる期間になる。

並行稼動の利点は、新システムで本番障害が発生したとしても、並行稼働中は現行業務の影響を小さくできることだ。
だが、新旧のシステムを稼動させるために、サーバーが少なくとも2台は必要だし、リソースをかなり消費する。
そして、本番リリース日には現行システムから新システムに切り替わるために、単純移行時の問題点が必ず発生する。
しかも、並行稼動が終わる直前までの最新データを移行しなければならないので、単純移行の時よりも、作業時間もデータ量も制約が厳しくなる。
単純移行の作業よりももっと大変なのが普通だと思う。

【4】部分移行は、旧システムをサブシステムに分割しておき、旧サブシステムを新サブシステムへ順次移行する手法。
例えば、サブシステム単位に新規システムをリリースする手法は、段階リリースとも呼ばれる。
この手法は、アジャイル開発の手法に近いが、ウォーターフォール型開発を複数回繰り返してはリリースしていく開発スタイルなので、アジャイル開発とは厳密には違う。

いきなり全ての機能を稼動させるわけではなく、徐々に稼動するシステムを増やしていくので、システム障害が発生した時の影響が小さい利点がある。
また、先行リリースしたシステムの機能をユーザに使ってもらい、そのフィードバックを早めにもらうことができるので、その次のシステムのリリースにその内容を反映させる利点がある。

しかし、部分移行の弱点は、先行リリースしたサブシステムを保守しながら、裏では新規サブシステムを2次開発していくという並行開発にならざるを得ない点だ。
障害修正しながら、新しい機能を追加していくには、複数のブランチ間で簡単にマージできる強力な構成管理が必須だが、普通の開発ではデスマーチになりやすい。
せっかく障害修正したのに、新機能を追加したら、影響範囲の調査が不十分のためにデグレードしてしまう現象が多発しがちだからだ。

アジャイル開発が難しい理由の一つは、並行開発という構成管理のインフラが不十分な点があるからだろうと思っている。

【5】パイロット方式は、限定した部門で新システムを導入し、その後の運用を観察した後で部門全体を移行する手法。
パイロット方式の利点は、新システムを運用している部門が限定されているために、移行時に発生する問題による影響範囲を局所化できる点がある。
さらに、その運用ノウハウがたまった後に、部門全体へ展開すれば、運用のトラブルを未然に対応できる余地がある。

パイロット方式を使う状況は、ERPのような業務パッケージ製品を社内へ導入する場合が多いだろう。
つまり、一部の部門が先行して、新システムで業務を運用してみて、今までの業務の違いをユーザが確認したり、新システムでどんな効果が出たのかを調査することで、運用ノウハウを蓄積できる。
普通は、運用ノウハウは業務マニュアルとしてまとめられて、全部門へ展開される。

とは言え、実際はそんなにうまくいくこともない。
初めてのシステムなので、ユーザも慣れないし、実際に導入してみて、不足した機能が発覚したりする。
それら障害修正や機能改善のたくさんのパッチが先行システムに当てられて、まともに使えるようになって、ようやく全部門に展開される。
しかし、部門ごとに人の性格も違うし、業務も違うから、使ってみて初めて、不足した機能が分かる時も多い。

また、パイロット方式を行う場合、ユーザ企業の情報システム部門がどれだけの力量を持っているのか、という点も重要だ。
先行リリースする部門とSIの間で仲介役として振舞わなければならないし、全部門に展開する場合は、他の部門にも配慮しないといけない。
SIは情報システム部門と一体化して、新システムをアピールしながら、ユーザの現場の業務を改善していくミッションを進めないといけない。

【6】システム移行作業が難しい理由をまとめると、以下の点があげられる。
一つ目は、移行作業に試行錯誤しながら試す方法が許されていないために事前の準備や計画作りに手間がかかること。
二つ目は、情報システム部門など数多くのステークホルダーと利害調整するマネジメント能力が必要とされていること。
三つ目は、データ移行や並行開発で技術力が要求されること。
このような理由があるからだろうと思う。