Comments
Description
Transcript
移行の軽視は自殺行為 計画の不備が失敗を招く
NIKKEI COMPUTER 2003.3.10 異なる」 （NEC の本田美奈 子システム技術計画本部シニアマネ ージャー）ことがその一因だろう。 全貌を把握しづらいからといって、 「移 た。データ変換アプリ 行では何をすべきか」の理解を怠ると痛 ケーションの開発に必要な作業 い目に遭う。移行を軽視するのは問題外 量も見積もった。しかし、この見積もり だ。 「旧システムで利用・蓄積していたデ にどうしても自信が持てなかった。結果 ータを抽出し、新システムに移せばおし として不安が的中してしまった」 。担当者 まい」と考えているようでは、高い確率 は悔やむ――。 で移行に失敗する。 移行の軽視は自殺行為 システム構築プロジェクトにとって、 システム移行にかかわるトラブルの原 因は、突き詰めると作業の漏れや見落と しに行き着く。冒頭の例では、 「データ変 「最後にして最大の難関」 、それがシステ 換アプリケーションの開発規模の見積も システムから新システムへの移行 旧 ム移行である。システム移行の目的自体 りが甘かった」としか言いようがない。 にかかる作業量を読み間違えた。 は、非常にシンプルだ。 「旧システムのな 新システムの開発が順調に進んでいただ かから必要なものを取り出し、新システ けに、残念でならない」 。ある大手製造業 ムに組み込む」と要約できる。 計画の不備が失敗を招く もちろんユーザー企業は、移行の成功 だが、そのためには膨大かつ複雑な作 を目指して準備を進めている。限られた 同社は生産管理から販売管理に至る基幹 業が必要になる。 「新システムに移すデ 時間のなかで膨大な作業を確実にこなす 系システムの大規模な刷新に挑んでいた。 ータを選ぶ」 、 「データ変換アプリケーシ ため、作業スケジュールを立てる。机上 昨年1 月の稼働を目指して新システムの ョンを作る」といった事前準備はもちろ の空論にならないよう、リハーサルを繰 開発を進めていた。 ん、切り替え当日には「限られた時間内 り返す。作業ミスやハードウエアのトラ 問題は、新システムのテストにこぎ着 にすべてのデータを旧システムから新シ ブルに備えた対策も講じておく。 けた段階で発覚した。データ変換アプリ ステムに移し替える」という失敗の許さ ケーションがほとんど完成していないこ れない作業が待っている。 のシステム担当者は、こうため息をつく。 ところが、現実は厳しい（次ページの 図 1） 。当事者はきちんと準備をしたつ とが判明したのだ。これでは、切り替え 一つひとつ作業を列挙しても、システ もりでも、完ぺきな移行計画はなかなか どころかテストも十分にできない。最終 ム移行の全体像はいまひとつつかみにく できない。リハーサル不足や作業手順書 的にこの企業は、新システムへの移行を い。 「旧システムの規模や新システムの構 の不備が原因で、思わぬトラブルを招く 5 カ月延期する羽目になった。 成、毎日の稼働時間、接続端末数などに こともある。例えば、旧システムからデ 「移行の重要性は当初から認識してい よって、移行の手順や作業内容は大きく ータを吸い上げるのに手間取ったり、デ 41 特集 システム移行は危険がいっぱい ータ形式の変換作業に失敗すれば、移行 移行の担当者が新旧両方のシステム 作業は予定していた立ち上げ時間までに の内容を熟知するのは簡単ではない。長 終わらない。当然、新システムでサービ 年変更が加えられてきた旧システムの仕 スを開始できない。 様やデータ構造全体をいきなり理解しろ トラブルの種類によっては、移行に完 全に失敗し新システムの稼働を延期する ドキュメントは不完全だし、当時の担当 ケースもある。厳しい言い方をすれば、 者もいない。 稼働延期は「移行の計画に不備があった 切り替え日が近づくまで、新システムの ンテグレーション事業本部SI プロフェッ 設計が完全に固まらないケースは珍しく ショナル室の梅村良氏） 。 ないからだ。要件定義や詳細設計の作業 はたいてい予定より遅れる。いったん決 とも多い。最悪の場合、設計変更が移行 しい作業だ。まず新旧両方のシステムを 担当者に伝わっていないことさえある。 熟知していなければならない。それぞれ 一般にユーザー企業は移行計画作りの → 新システムの要件が 決まらず、 移行計画作りに 着手できない 旧システムの理解に てこずる まった設計が開発の過程で変更されるこ そもそも移行の計画作りは、非常に難 図1'システム移行には危険がいっぱい潜んでいる 移行設計 新システムの理解は別の意味で難しい。 ことにほかならない」 （富士通システムイ 一筋縄ではいかない計画作り 移行計画 と言われてもムリがある。多くの場合、 データ変換 アプリケーション開発 仕様変更の反映に苦労 切り替え準備 リハーサルが 不足 切り替え当日 想定外のエラーが 発生 新システムの 稼働延期 移行の責任者が不在 42 新たに導入する機器の 手配が間に合わない 切り替え手順書が 未完成 切り替え作業の 時間が足りない のシステムの仕様やデータ構造を理解し ノウハウを社内に蓄積しにくい。ほとん ていなければ、 「旧システムから新システ どのユーザー企業にとって、大規模なシ ムにどのぐらいの量のデータを移すべき ステム移行は何年かに一度の大イベント。 か」や「データを移すのに、どのぐらいの 経験を積もうにも機会がない。このこと 工数がかかるか」が 判断できないから も移行計画作りを難しくしている。 だ。データ移行の所要時間がわからなけ さらにプロジェクト・チームの関心は、 れば、切り替え日が決められず、作業の どうしても新システムに向かいがちだ。 具体的な準備に取りかかれない。切り替 「新システムの設計や開発を優先して、移 え日が最初に決まっている場合でも、そ 行作業を軽視する傾向がないとはいえな の可否を判断できない。 い」 （日本IBM 金融第二ソリューション・ NIKKEI COMPUTER 2003.3.10 表1'先進ユーザー企業のシステム移行に対する取り組み 企業名 プロジェクトの概要 移行に関する特徴的な取り組み 移行完了時期 イズミ 受発注業務を支援する基幹系システムの刷新 データ変換アプリケーションの開発をはじめ、移行に関するほとんどの作 業を新システムの開発担当者が主体となって実施。旧システムの担当者 に負担をかけずに移行を実行 NTTグループ ERPパッケージによる人事・給与システムの刷新 現行システムのテストをあらかじめ実施し、 データ変換アプリケーションの 開発効率を上げる カネボウ POSレジスタ2000台の刷新 POSレジの利用拠点や関連会社のスタッフに作業指示を詳細に伝達。切 り替え作業の手順にかかわる誤解を徹底的に排除した 2002年2月 川崎汽船 海運業務を支援する基幹系システムの刷新 世界各地の拠点ごとにサブシステム単位で段階移行。切り替え後の問い 合わせの量を平均化 2002年6月 KDDI 携帯電話会社の合併に伴う 基幹系システムの統合 合計九つある旧システムの開発担当者に、中間ファイルのデータ形式を 開示。旧システム側でデータ変換作業を実施してもらう 2003年1月 新日軽 ビル向け建材の商談を支援するシステムの刷新 全国約60拠点でそれぞれ移行責任者を選出。システム部門と拠点の責 任者が密接に連携しながら移行準備を進めることで、切り替え当日のトラ ブル発生を防いだ 2001年9月 住友生命保険など 生保7社＊ 生保7社による企業向け適格退職年金 契約管理システムの共同化 システム移行をプロジェクトの最重要課題と位置付け、 プロジェクトの開 始時から移行の検討に着手 2002年8月 ダイハツ工業 池田工場の生産ライン制御システムの統合 データベースの統合とアプリケーションの機能強化を2回に分けて実施 2002年10月 太平洋セメント 販売・物流システムの刷新 段階移行の実施スケジュールで、 1回目と2回目の切り替え時期を2カ月あ けることで、 余裕を持ったスケジュールを組む 2002年3月 東京海上火災保険 保険データの分析・調査システムの刷新 旧システムに詳しい運用担当者の力を借りて、20カ月に及ぶデータ移行 を実施 2002年2月 トマト銀行 岡山県信用組合の店舗譲り受けに伴うデータ移行 既存のバッチ処理アプリケーションを活用して、 データ変換作業を実施。 移行データの信頼性を確保 2002年7月 ニッセイ同和損害保険 代理店業務支援システムのデータベース構成変更 あらかじめデータベースを二重化しておき、 オンライン処理を停止すること なくインデックスの張り替えを実行 2003年2月 パスコ ERPパッケージによる会計システムの刷新 業務の特性を考慮して移行手順を設計。段階移行や月次処理の稼働延 期などにより移行にかかる工数を9割以上削減 2000年5月 広島銀行、 福岡銀行 銀行業務全般にかかわる基幹系システムの共同化 移行リスクを分散するために、 切り替えに先がけアプリケーションを先行し て刷新。切り替え当日はシステムの移転やデータ移行を中心に実施 2003年1月 三井住友銀行 勘定系システムの統合に伴う店舗システムの移行 旧さくら銀行の全336店について、営業店システムの切り替えを7段階に 分けて実施。営業店の特性を考慮してグループ分けを決定 2002年7月 武蔵野銀行 北埼信用組合との合併に伴うデータ移行 複雑な移行作業を手作業で実施。データ変換アプリケーションの開発工 数を9割削減 2003年1月 ムーンバット 商品の在庫管理・販売などを支援する 基幹系システムの刷新 新システムの設計が固まってからデータ変換アプリケーションや移行手順 を作成しようとしたベンダーに反対。設計途中にいち早く移行設計に着手 2003年2月 郵政事業庁 郵便貯金業務をこなす基幹系システムの刷新 1年以上前に手順書を作成し、1年間かけてリハーサルを5回実施。リハ ーサルは、切り替え当日とまったく同じ担当者が決められた持ち場で実 施 2003年1月 2002年6月 2002年6月 （給与システム部分） ERPパッケージ：統合業務パッケージ 朝日生命保険、住友生命保険、大同生命保険、富国生命保険、三井生命保険、明治生命保険、安田生命保険の7社 ＊ ム全体の協力が不可欠だからだ。 センターの勝又 彰カード第一システム部 ない」 （東京海上システム開発の石津義秀 部長） 。 業務推進サービス本部会計サービス開発 本特集では、システム移行の必勝法を 部アシスタントマネジャー） 。システム移 探る。まず日本最大のオンライン・シス 行を着実にこなす担当者たちは異口同音 テムの切り替え現場に迫る。今年の正月 にこう訴える（表 1） 。 休みを利用して新システムに移行した郵 重要性はシステム開発と並ぶ 限られたコストと時間のなかで移行を 成功させるには、計画作りや準備をしっ システム移行の勘どころを押さえてお 便貯金のオンライン・システムだ。その かりするしかない。新システムの開発だ くことは、新システムの設計や開発を担 緻密な作業ぶりからは、事前準備の大切 けに気を取られていてはダメだ。 当するエンジニアにとっても必要である。 さが伝わってくる。 ち み つ 「システム移行は、新システムの開発と システム移行の成功には、設計担当者や 同じぐらい重要と肝に銘じなければなら 開発担当者を含めたプロジェクト・チー さらに先進企業の取り組みを基に、移 行成功の5 大原則を紹介する。 43