マイグレーションプロジェクトはデスマーチ化しやすい

　企業におけるIT化が始まってもう数十年が経過している。数多くの業務がシステム化されて社員の日々の仕事の中で使われている。したがって、最近のSI案件の多くがシステム更改やシステム再構築である。

　ところが最近システム開発プロジェクトの名称に、「○○システム更改」や「××システム再構築」でなく「△△システムマイグレーション」などという名称を用いる例を見るようになった。プロジェクト名称でなくとも、システム計画やシステム概要の説明文にマイグレーションというキーワードを見ることが増えた。そしてこの「マイグレーション」という単語を見たら要注意だ！

　マイグレーションプロジェクトは、トラブルになりやすい。プロジェクト開始当初に比べ要件が膨らみ、開発コストが増え、終了期限が伸びて炎上してデスマーチ化しやすいのだ。それはなぜか。マイグレーションはシステム業界では「移行」を示すが、「移行」と言われると多くの人が、機能はそのままで作り変えるだけと捉える。これがトラブルの元になる。

　マイグレーションプロジェクトでも、たいていの場合は新システムや新環境、あるいは現在の業務環境にあわせて要件を再定義する「要件定義プロセス」を経る。この要件定義プロセスが曲者なのだ。マイグレーションプロジェクトの場合に「現行システムの要件＋α」という考え方で要件定義を行ってしまい以下のいくつかの罠に嵌る例が多い。。

　一つ目の罠は、「現行システムの要件がそのまま残ってしまう」罠である。「機能は現行と同じ」ということで、使っていない不要な要件がそのまま残るリスクだけでなく、今の機能の再現ということで要件の細部の検討が省かれる事がある。こうして細部の検討を省いた要件が、いざ開発・実装という段になって実は思いのほか大きな開発が必要だったという事が時たま起きる。そして、その段になって「その機能は不要でしょう」とは事前になぜその機能があるのか等の細部を調べていないので言えないし、下の三つ目の罠にあるように「言えない」のだ。

　二つ目の罠として、「追加する要件にばかり目を取られて既存機能への影響を考慮し忘れる」罠がある。マイグレーションなので既存システムを一つの箱の塊のようにとらえて、外部仕様だけから新しい機能はこれに追加すれば良いだけと判断してしまい、こちらも開発段階になって機能追加の影響がデータの細かい仕様や例外処理に影響を与えることがわかってあわてて手戻りすることになったりする。

　そして三つ目の罠、「単純移行なのでユーザはあまり巻き込まなくて良い」と考えてしまう罠。単なる作り変え、置き換えなのでユーザには「"機能はそのままです"とだけ説明すれば良い」とか「新システムが出来てから、ユーザインターフェース部分だけ説明すれば良い」と考えてしまうともう大惨事だ。リリース直前になって、「その業務は新しいやり方になっていて別のやり方になっている」だとか「実は今までのこの機能では足りなかったのでこう変えてほしい」だとか言われてもどうしようも無い。
　それだけでない「マイグレーション（移行）」と聞く、多くのユーザ部門は「ああ、機械が老朽化したとか、ソフトウェアのサポートが切れるとかで、システム部門の都合でシステム替えるのね」と他人事だと受け止めてしまう。その結果

・システム部門の都合でシステム取り替えるのだから、そっちでやってよ
・単なる取替だから、今の機能は全部そのまま残してね

なんてスタンスになりやすい。かくしてマイグレーションプロジェクトはデスマーチ化する。

これを防ぐには、早期からユーザ部門を巻き込んで、単なる機能再現ではなく今の働き方にあわせた最適な機能を要件化するしかない。「マイグレーション（移行）」という言葉はあまり前面に出さず、新しくシステムを作るようにユーザ側にも当事者意識を持って貰うような工夫をしないと。

システムのマイグレーションには、こうしたちょっとした工夫が必要なのだけど、情報システム担当者も請け負う側のSIerの担当者も気づいていない事が多い。冒頭で書いたように世の中ではマイグレーション案件が増えてきている。先行ユーザや経験者、あるいは我々みたいなマイグレーションに詳しいコンサルタントなどから、ちょっと話を聞くだけでも罠に落ち難くなるのに。

デスマーチ案件が少しでも減ることを祈っている。