開発現場は日々の仕事の場であるとともに、学びの場でもある。先輩エンジニアが過去に直面した困難の数々、そこから学んだスキルや考え方を紹介する。
こんにちは。アクセンチュア・テクノロジー・ソリューションズの新楽です。前々回「オフショアなんて、怖くない」、前回「障害対応とチューニングの危うい関係」に引き続き、ある大規模基幹システム構築プロジェクトで経験したことをお話しします。今回はデータの移行と、それに取り組んだ「最強チーム」についてです。
アプリケーションの開発もほぼ完了し、結合テストを開始したころのことです。そろそろ移行についてきちんと考えないといけない時期に差し掛かっていました。前々回でも触れましたが、私はそのとき開発を担当していました。
データ移行のスコープは、「ホストで稼働している現行システムのすべてのデータを、新システムのアプリケーションで動作するように移す」というものです。
口でいうのは簡単ですが、移行対象は10以上のサブシステムにまたがり、テーブル数は200を超えます。件数も、多いテーブルでは数百万件です。
業務もとても複雑でイレギュラーケースが多いうえ、新システムで恐ろしいほど機能追加されていました。さらに移行元がホストだったため、新システムのリレーショナルデータベースでは、正規化して子テーブルに持っているような情報はほとんどすべてOccurs句で、1レコード内に繰り返し項目として保持されていました。
そのほかにも、数え切れないほどの複雑な要素がありました。右から左にデータを移せばよい……などということは絶対にないことが、簡単に想像できました。
当時の私はまだ、第三者として「大変だな……」と思っていただけでした。しかし、検討が進むにつれて打ち合わせなどに参加するようになり、何となく嫌な予感(?)がしていました。具体的な計画や移行ツールもほぼ決定し、いよいよ移行スタート。
「誰がやるの?」「あ、やっぱり私?」ということで、移行チームの責任者が誕生しました。うれしさ半分、不安半分といったところでしょうか。移行で使用するツールが、私が過去に利用したことのあるInformatica PowerCenterというデータ統合ツールに決定したあたりから、こうなるかとは思っていましたが……。
移行用のプログラムを作成して実際に本番移行を実施するのには、約100人/月の工数が必要でした。最初の山場はスタートから約6カ月後の第1回移行リハーサル。このリハーサルは、主に以下の3点を検証することを目的としていました。
中でも特に重要だったのが、1の「与えられた時間内にデータ移行を完了できること」でした。
本番稼働開始は、月曜日午前8時の予定でした。今回のデータ移行に与えられていた時間は、金曜日午後10時の現行システムオンライン閉塞(へいそく)後から本番稼働日である月曜日の午前6時までの56時間です。しかしこの中には、現行システムのバックアップ、ホストからテープデバイスへのデータの吸い上げという現行システム担当者の作業時間が十数時間含まれていました。私たちはテープデバイスを受け取ってから、データ移行、検証作業、お客さまの最終確認・承認までを、40時間ほどで終わらせる必要があったのです。
それを目標に移行の仕様をすべて決定し、移行プログラムを完成させる必要がありました。私の見積もりと経験からくる勘(?)では絶対に終わるはずなのですが、「本当にその時間でできるのか」という不安からくるプレッシャーもありました。もし時間どおりに終わらなければ、本稼働できないということになってしまいますからね。
そのための最初にして最大の関門である第1回移行リハーサルに向け、6カ月という期間で、クライアント調整を行い、データ移行の仕様を詳細まで決定し、移行プログラムを完成させ、テストを完ぺきに終わらせる必要があります。体制は、サブリーダー4人、開発者10人でした。
特にサブリーダーの人たちには、1人当たり3サブシステム、内容はクライアント調整・設計・開発および品質管理という、かなりハードかつ責任重大な役割を担当してもらっていました。しかし実際にこの体制でスタートしてからは、大きな問題もなく、必要なすべてのタスクを期限どおりに完了し、無事に第1回移行リハーサルを迎えることができました。
ただ、「大きな問題なく」というのには、少し語弊があるかもしれません。問題は発生していましたが、私たちは皆、先手を打ってそれに対応してきたのです。テストもツール化し、それを各サブリーダーで共有して進めるという具合に、常に先回りして問題を潰し、全体の効率化を考えて実行に移していました。私たちは、まさに「最強チーム」だったのです!
Copyright © ITmedia, Inc. All Rights Reserved.