本番稼働の舞台裏 ....... p.36 Part 2 現場の知恵と工夫 ........ p.4 0 Part 3 移行フェーズのリスク....... p.49 ＜写真：Getty Images ＞ NIKKEI SYSTEMS 2010.6 35 1 システム稼働、その瞬間 Part 1 特集 つの鉄則 システム稼働の瞬間、現場は緊張と不安に包まれる。 ちょっとした不備が大きなトラブルを招くからだ。 最後の局面である移行作業が成否の鍵を握る。 成功をつかむための 7 つの鉄則を明らかにする。 （池上 俊也 [email protected] ） システム稼働 、 成功をつかむ 7 その瞬間 特集 本番稼働の舞台裏 順風満帆のプロジェクト 最大の試練は最後に訪れる 問題のないプロジェクトはない。そのしわ寄せは最後に来る。 この試練を、最終局面の移行作業で乗り越えなければならない。 稼働直前、プロジェクトの現場で何が起こっているのか。舞台裏を追った。 2010年1月4日午前8時。東京証券取 けたプロジェクトは稼働直前の1月2 アは1000人を超えた模様である。 引所（以下東証）の新株式売買システ 日、大きな山場を迎えていた。 運命の本番移行は12月31日から1月 ム「arrowhead」は動き出した。とか く超高速性能に目を奪われがちな 特集 1 2日に実施した。正月休み返上で作業 運命の1月2日、失敗は許されず し、最終日の1月2日が最大の山場と システム稼働、その瞬間 arrowheadだが、実はシステム移行作 図1が、arrowheadの移行スケジュー なった。その日は早朝から新システム 業にこそ力を注いでいた。 ルである。移行作業のリハーサルは3 に切り替え、午前9時から午後3時まで システムテスト後に行った運用テス 回実施。リハーサルでは、旧システム は、実際に証券会社からの売買注文を ト25回、移行にかかわった証券会社と から新システムへの切り替え、マス 受け付けた。その間、システム部門と 情報提供会社162社、ITエンジニアの ターデータの抽出や取り込みなどを 業務部門の各担当者は、詳細なチェッ 数、実に1000人以上――。移行作業を 行った。そのほか、正常時、障害時、 クリストを片手に問題がないことを一 表す数字である。それはまさに一大イ 高負荷時、災害対応時などの動作を検 つずつ確認していった。本社ビル15階 ベントと呼べるもので、期間は半年に 証する運用テストは25回。業務部門に には、移行状況を集約する作戦本部を 及んだ。 「 （arrowheadは）日本経済を よる移行作業の確認項目は全部で331 設置。社長以下、幹部、関係者ら約50 支える基盤システム。本番稼働を何が 項目を数え、9度の全体会議で達成状 人が集結し、移行の成功を見守った。 何でも成功させなければならない」 。 況を確認した。これらはすべて、シス そして午後9時過ぎ、本番移行確認 移行作業を取りまとめた田倉聡史氏 テムテストの終了後に実施したもので 会議にて移行の完了を宣言。新システ （IT開発部 マネージャー arrowhead ある。移行作業に参加した企業数はベ ムの稼働にこぎ着けた。一般には順風 担当）は振り返る（写真1） 。威信をか ンダーを含めて百数十社、ITエンジニ 満帆に見えるarrowheadの稼働だが、 2009 年 7月 システム、データの 模擬移行の実施 移行 リハーサル① （9月19 ∼ 21日） 利用会社 アンケート （10月7日） 接続数の 確認 稼働準備確認会議 11月13日 稼働判定会議 12月2日 移行準備完了 移行 リハーサル② （10月24 ∼ 25日） 利用会社 アンケート （10月31日） 1月4日の 稼働決定 移行 リハーサル③ （11月19 ∼ 23日） 対応状況 の確認 全体移行統括本部ミーティング （9月16日∼12月25日の間に全 9 回実施） 稼働テスト （7月11日∼12月27日の間に全 25 回実施） 写真撮影：柳生 貴也 写真 1 失敗の許されない移行に挑んだ東京証券取引所 東京証券取引所の新株式売買システム「arrowhead」は、日本経済を支 える基盤なだけに失敗が許されなかった。移行を仕切った田倉聡史氏は 強いプレッシャーの中で作業を進めた 36 NIKKEI SYSTEMS 2010.6 1 arrowheadの移行スケジュール 図 2010年1月4日の稼働まで約半年をかけた。この間にすべての動作確認、業務部門 の移行作業、利用会社の対応、移行リハーサルを終わらせなければならなかった システム稼働 その瞬間 と、メンバーの拡充を懇願。メンバー 業に追われていた。 かった。しかも、東証から正式な稼働 の数を倍増させ、スケジュールを引き 日がなかなかアナウンスされなかっ 直した。テスト項目も追加して約300 た。2009年10月を過ぎても発表され から407項目へ。年末に向かって、プ 一方、arrowheadと接続する証券会 ず、澁谷氏は眠れない日々が続いた。 ログラムの修正とテストを急いだ。 社側のシステム担当者も苦労の連続 東証から正式に稼働日がアナウンス システムの移行は、12月31日の午前 だった。野村総合研究所の澁谷亜樹氏 されたのは12月2日のことだった。稼 3時から始まった。仮眠室で待機して （証券ITサービス事業本部 証券システ 働開始は「2010年1月4日」とあった。 いたメンバーはプロジェクトルームに ムサービス開発二部 主任システムエン わずか1カ月あまりしかない。まだ修 集結。通常運用の日次バッチの終了を ジニア）が率いた移行プロジェクトが 正途中のプログラムも多く、運用テス 待ち、マスターデータの移行を始めた。 その一つだ。 トも完全に終わっていない。 修正版プログラムの適用は元日の早朝 澁 谷 氏 ら が 担 当 し た の は、 そんな中、東証から示された電文の 6時から。そして1月2日、arrowhead arrowheadに接続する証券会社約20 仕様ミスが判明する。稼働を控えてト の最終確認の当日は、数十社の証券会 社の株式売買システムの移行である。 ラブルが続出し、澁谷氏らの緊張や不 社の関係者と共に、株式売買の注文を 東証から提示された仕様に基づいてシ 安は一気に高まった。そのときの緊張 送り続けた。 ステムを修正し、arrowheadの本番稼 と不安のレベルを澁谷氏はグラフに示 「問題なし」 。1月2日午後6時過ぎ。 働に合わせて修正版プログラムを適用 してくれた（図2） 。稼働開始が近づく すべての稼働判定基準を満たし、移行 しなければならない。 ほど上昇しているのが分かる。 が完了した。最後の最後で帳尻を合わ スケジュール調整が難問だった。と 危機感を募らせた澁谷氏は上司のも せた澁谷氏らは、ようやく正月を迎え いうのも、arrowhead対応とは別に、 とを訪れ 「このままでは間に合わない」 ることができた。 稼働日が決まらない、仕様が違う 1 システム稼働、その瞬間 映すべきかを判断しなければならな 特集 その裏では現場の担当者がこうした作 利用者からは機能追加の要望が寄せら れていた。arrowhead対応前にでき るのかできないのか、そうした要望を いつ、どのタイミングでシステムに反 2009 年 1 2 初の開発会議を開催。 資料やプレゼンテーショ ンの準備に追われる 3 4 5 つかの間の休息。 これから迎える数多 くの作業に備える 6 7 8 9 仕様ミスや進捗遅れの 対応に追われる。緊張 や不安が一気に爆発 10 11 12 2010 年 1（月） 12月31日午前 3 時から本 番 移 行 開 始。3日間かけ て無事に完了。ほっとする 2010 年 1月 本番移行確認会議 1月2日 本番稼働 1月4日 提案書、見積書の 作成を開始。落ち着 かない日々が始まる 高 稼働 移行完了 稼働開始 本番移行 （12月31日∼ 1月2日） 澁谷氏が 現場で感じた 緊張や不安 のレベル 概要設計 基本設計 業務部門の移行作業の 確認（全 331 項目） 2 回目の開発会 議を開催。いよ いよ本格化する 移 行 作 業に気 を引き締める テストの実施漏れ が 判 明。課 題が 次々に明らかにな り、追 加テストを 実 施。緊 張 や 不 安はピークに 低 開発 総合テスト 取引所接続テスト、運用訓練 正常運用、障害運用、高負 荷、災害対応などを確認 図 2 緊張と不安がピークに達したarrowheadの稼働直前 arrowheadと接続する証券会社約20社のシステム移行を担当した野村総合研究所の澁谷亜樹氏。移行期間 の短さの中で、緊張や不安は高まっていった NIKKEI SYSTEMS 2010.6 37 本番稼働の舞台裏 するしかなかった。とはいえ、 マスター データは50万件に上り、データの不備 を確認するのは不可能だった。旧シス テムに戻す準備もしていない。現場を 仕切った成瀬弘一氏（情報システム） らは勘を頼りにプログラムを探った。 そして稼働当日の午前6時。バグを発 見して修正を終えた。稼働の3時間前 で、ギリギリ間に合った（写真2） 。 マニュアル作成に手がつけられない 特集 次に、第一三共が2009年12月に稼 働を始めた文書管理システム。研究開 1 システム稼働、その瞬間 写真 2 稼働3時間前にプログラムの修正を終えた三城 販売・在庫管理システムのオープン化に当たって、最後までプログラムのバグに苦しんだ三城の開発メンバーの 3人（成瀬弘一氏は写真右） 。徹夜でプログラムのチェックに当たり、稼働日早朝に修正を終えた 発やサプライチェーン、マーケティン グといった業務のドキュメントを社内 外で共有・配信するのが目的だ。プロ ジェクト期間はわずか2カ月。文書管 に追われた。だが、すべてのエラーを 理機能を提供するクラウドサービスを 稼働前に修正するのは難しかった。 利用するのでシステム開発にはそれほ 順調なプロジェクトの雲行きが稼働 「もう間に合いません」 。システム稼 ど工数はかからなかった。だが、開発 直前に怪しくなるのは珍しくない。プ 働予定を前日に控えた2009年11月16 以外の作業が試練となった。運用マ ロジェクトのしわ寄せは、最後に来るも 日、メンバーの1人が白旗を揚げた。 ニュアルと利用マニュアルの作成に時 のだ。稼働前の試練を力業で乗り切っ やむなく稼働開始を1週間後の11月24 間を要し、稼働当日までに間に合わな た、眼鏡専門店を展開する三城と製薬 日に遅らせた。 い。そんな状況に陥っていた。 大手の第一三共の事例を紹介する。 そして、延期した稼働日の前日。午 このシステムは管理と運用を利用部 まず三城の舞台は姫路市。メインフ 後7時からマスターデータを新システ 門に一任するので、作成するマニュア レームで動いていた販売・在庫管理シ ムに取り込み、最後の運用テストを実 ルは管理者向けと閲覧者向けの利用ガ ステムをLinuxによるオープンシステ 施した。すべてのプログラムの修正を イドのほか、利用上の注意点、アクセ ムに移行するプロジェクトだ。コスト 終えたはずだった。だが、データの集 ス権の設定、ユーザーおよびデータの を抑えるためにプログラムは新規開発 計結果が一部で合わないことが判明し 管理方法など多岐にわたっていた。 せず、 （協力ベンダーの）NECから提 た。時計の針は午前3時を指していた。 マニュアル作成が遅れた理由の一つ 供された移行ツールを使って既存の Linux版COBOLの技術支援などでプ は、クラウドサービスを利用したこと COBOLプログラムをコンバートした。 ロジェクトに加わっていた協力ベン にあった。 「新たな形態のサービス マスターデータも同様の方法を取った。 ダーの担当者は既に帰宅している。自 だったので、運用ルールの整備に手間 ところが、この方法がシステムのブ 分たちだけで修正しなければならな 取った」と同社の上野哲広氏（管理本 ラックボックス化を招き、システム移 い。午前9時にはユーザーが新システ 部 IT企画部 企画グループ 主任）は説 行を難しくした。コンバートがきちん ムを利用する。現場はまさに、 背水 明する。業務ルールの整備の遅れに とできない個所がところどころで見つ の陣 の様相を呈した。 よって、マニュアルの作成に手がつけ かり、エラーが頻発。三城の開発チー データに不備があるのか、それとも られない状態だったのだ。 ムの3人はプログラムやデータの修正 プログラムのバグなのか。地道に調査 運用ルールが決定し、マニュアル作 コンバートしたプログラムにバグ 38 NIKKEI SYSTEMS 2010.6
© Copyright 2024 Paperzz
