レガシーシステムとどう向き合うか

今回はレガシーシステムについてです、ユーザーによっては重いテーマですね。
まず「レガシーシステム」の定義としては
・書かれている言語のサポートが切れている
・メンテナンスできる技術者の確保が困難
・接続している外部システムの仕様に合わなくなる
が挙げられ。
その定義を踏まえて具体的に何が該当するかと言うと
1.COBOL言語で書かれたオフコンのシステム
2.VisualBasic Ver6.0以前のもので書かれたシステム
3.社内で内製されたExcelやAccessで2007以前のもの
が該当するかと思います。

さていざレガシーシステムをどうするかという問題に直面した場合、結論から言うと二択です。
・システムを刷新するか。
・システムを止めるか。
私の立場でこの言い方は若干脅し文句に聞こえなくもないですが現実的にはこの二択になり大抵の場合止める決断が難しいので刷新になります。
しかしその「刷新」もコストさえかければ実現する訳ではなくベンダー選定から相当な苦労をされるはずです。
・元となる言語を解析できること。
・不要な機能を判断できること。
・現在の業務にフィットする機能を提案できること。
・刷新後のシステムがユーザー様の規模感に合ったものを構築できること。

最近ではこのマイグレーションを専門に請け負うベンダー様も多いのでネットで検索すればヒットすると思います。
ベンダー選定の際は以下のポイントを抑えておくと良いマイグレーションができると思います。
・レガシーシステムのうち本当に必要な機能と不要な機能の洗い出し
　→これをちゃんと行わないと全てお任せで不要なものまで移管されてしまい余計なコストがかかります
・マイグレーションツールに頼っていないか
　→ツールを使う事自体は悪ではありません、ただしツール「だけ」を使ってマイグレーションを行うベンダー様は要注意だと思います、その場合不要な機能の削減やシステム改善に伴う機能追加はあまり期待できなくなり満足度はあまり高くならないと思います。
・契約は「請負契約」か
　→以前も触れましたがここを準委任契約でしようとするベンダーは少し警戒した方が良いかも知れません、完成後双方合意したものと違う場合に契約を盾にして瑕疵担保を認めないというケースが考えられます。

ベンダーが決まったら次は仕様の検討です。
せっかく高額な構築費をかけて改修するのですから今のまま移行するのではなく
・無駄な機能の削減
・足らない機能の追加
も併せて検討すべきかと思います。
もちろん「現状が100点」というシステムもあると思いますが往々にして「使いづらい部分はあるが運用でカバーしている」部分というのはしっかり深堀してみないとユーザー様自身も気が付かないものです。
ちゃんとしたエンジニアであれば無駄な機能の提案は行わず、ユーザー様が気が付かなかった改善点も洗い出してくれる事でしょう。

仕様が決まればベンダー側の開発フェーズを経てユーザー様側で納品確認を行う事になります。
実はこのフェーズにおいてちゃんと確認せず、本運用が始まってから「ここが悪い」「ここが違う」と言って来られるユーザー様が非常に多くトラブルのほとんどはこのフェーズにおいて発生します。
瑕疵担保期間は契約によってまちまちですが大体半年～1年程度ですが「その間に不具合や仕様違いは見つかるだろう」というのは間違ってはいません。
ただ人の記憶は時間とともに曖昧になってゆくものなので、きちんと文書として遺しておかなかったものは「言った言わない」という事になりますので是非納品時チェックはしっかり行って頂く事をお勧め致します。

最後に、ここまで書いておいてちゃぶ台ひっくり返すつもりはありませんが、決してレガシーシステムイコール悪いものという事ではありません、あくまで「今後の事を考えた場合運用継続の面で不安が残る」という意味から検討を迫られるという事です。
レガシーというだけで拙速に刷新を進めるのではなく、じっくり検討の上決断して頂きたく思います。

【今回の補足説明】
・オフコン : オフィスコンピューターの略、パソコン(個人、ホビー向け)の対義語(?)で業務用に使われていたコンピューター(サーバー)群を指します、具体的にはNEC Expressシリーズなどがあります
・マイグレーション : レガシーシステムを最新の言語で構築し直す業務の事、家に例えるとフルリフォームといったところでしょうか