ノーツ移行に失敗するパターンとは？
この記事における「ノーツ」とは、すでにサポート終了製品である、IBM Lotus Notes/Domino V7.x 以前のバージョンを、クライアント・サーバー型で使用しているレガシーを指す。「失敗」とは予定外にノーツが残り、新旧共存から抜け出せない状態を指す。以下、失敗パターンを3つ例示する。
プロダクトアウト型
情シスは、移行先製品（プロダクト）を横に並べた比較表からプロダクトを選考し移行先をまず決める。次にプロダクトに合う移行方法やツールを決め、最後にユーザー調整を含む移行手順を決める。一見問題のない順序のように思えるが、現実はそうではない。プロダクトありきだと、プロダクトの制限で移行方法が限られ、さらに移行手順も限られる。結果として一部しか移行できず、ノーツが残る。
丸投げ型
経営からは「ノーツを止めろ」という指示。ノーツを止める理由の咀嚼が浅いままRFPを作成し、ノーツを止める理由づけまで各ベンダーに丸投げで提案させる。ベンダー選定が終わりユーザー調整を開始すると、ユーザーはノーツを止めてもノーツとまったく同じ機能を新システムに求める。情シス担当者は、ユーザー要求に押し切られる形でユーザー要求を100%のんで欲しいとベンダーに「無茶振り」する。ベンダーは、RFPと前提条件が違うとして再見積を提示するなど情シスとベンダー間で混乱と不信が生じ、要件定義フェーズでプロジェクトが打ち切られるか、プロダクトが一部サービスインしてノーツが残る。
開発保守予算を組んでいない
ユーザーは、開発権限移管後のアプリの開発保守を情シスに求める。それまでユーザーが支出していた開発保守費用を、情シスは一手に引き受ける予算を組めない。情シスは、予算超過を避けるため、移行の一部中断を決め移行費用を削り開発保守費用に分ける。こうして、解決の目処が立たないままノーツと新システムが併存する。
また、ノーツ移行を失敗しないためには会社方針を決める必要がある。次に会社方針が必要な理由を解説する。
