Shoeisha Technology Media

EnterpriseZine(エンタープライズジン)

EnterpriseZine(エンタープライズジン)

テーマ別に探す

第1回 なぜノーツ移行は困難なのか?

  2012/04/25 07:00

ノーツ移行プロジェクトを完全に成功させた事例は極めて少ない。”成功事例”と紹介された企業でも、実は新システムとノーツが共存している場合が多い。なぜノーツは残ってしまうのか?その答えは、失敗から学ぶことができる。本連載の中で詳しく解説していくが、今回はノーツ移行における問題点の概要を紹介する。当プロジェクトにアサインされた情シスの担当者にぜひ読んでいただきたい。

ノーツ移行に失敗するパターンとは?

 この記事における「ノーツ」とは、すでにサポート終了製品である、IBM Lotus Notes/Domino V7.x 以前のバージョンを、クライアント・サーバー型で使用しているレガシーを指す。「失敗」とは予定外にノーツが残り、新旧共存から抜け出せない状態を指す。以下、失敗パターンを3つ例示する。 

プロダクトアウト型

 情シスは、移行先製品(プロダクト)を横に並べた比較表からプロダクトを選考し移行先をまず決める。次にプロダクトに合う移行方法やツールを決め、最後にユーザー調整を含む移行手順を決める。一見問題のない順序のように思えるが、現実はそうではない。プロダクトありきだと、プロダクトの制限で移行方法が限られ、さらに移行手順も限られる。結果として一部しか移行できず、ノーツが残る。

丸投げ型

 経営からは「ノーツを止めろ」という指示。ノーツを止める理由の咀嚼が浅いままRFPを作成し、ノーツを止める理由づけまで各ベンダーに丸投げで提案させる。ベンダー選定が終わりユーザー調整を開始すると、ユーザーはノーツを止めてもノーツとまったく同じ機能を新システムに求める。情シス担当者は、ユーザー要求に押し切られる形でユーザー要求を100%のんで欲しいとベンダーに「無茶振り」する。ベンダーは、RFPと前提条件が違うとして再見積を提示するなど情シスとベンダー間で混乱と不信が生じ、要件定義フェーズでプロジェクトが打ち切られるか、プロダクトが一部サービスインしてノーツが残る。

開発保守予算を組んでいない

 ユーザーは、開発権限移管後のアプリの開発保守を情シスに求める。それまでユーザーが支出していた開発保守費用を、情シスは一手に引き受ける予算を組めない。情シスは、予算超過を避けるため、移行の一部中断を決め移行費用を削り開発保守費用に分ける。こうして、解決の目処が立たないままノーツと新システムが併存する。

 また、ノーツ移行を失敗しないためには会社方針を決める必要がある。次に会社方針が必要な理由を解説する。

※この続きは、会員の方のみお読みいただけます(登録無料)。


※この続きは、会員の方のみお読みいただけます(登録無料)。


著者プロフィール

  • 茉璃 美昌(マリ ヨシアキ)

    1993年初夏、発売前の日本語版ロータス・ノーツ R3J のベータ版を IBM PS/55 note C23V (OS/2)に IBM 社員 として初めて導入しデモ環境を作成。ノーツでは初のIBM 認定スペシャリスト。エグゼクティブ・セミナー講師や提案活動を通じノーツ普及に努める。IBM 退職後もバ...

バックナンバー

連載:ノーツ移行プロジェクトの落とし穴
All contents copyright © 2007-2019 Shoeisha Co., Ltd. All rights reserved. ver.1.5