NTT DATA TECH
😱

非機能要求グレードの歩き方 Vol.18 D移行性

Junichiroh Hirose
に公開
金融
移行
非機能
基幹システム
tech

はじめに - Vol.18

本記事では、IPA[1] が公開する 非機能要求グレード[2] の「D 移行性」を対象に、
金融 IT 基盤に 30 年以上携わって得た知見をもとに “やらかしがちな” 技術課題と対策を解説します。

筆者は非機能要求グレード初版の執筆に関わった経験があり、行間を含めて解説します。

Vol.18 マイグレーションパターン

シリーズ全体の構成は 👉 非機能要求グレードの歩き方 Index をご覧ください。

D 移行性

大項目「D 移行性」には、現行システムからのシステム移行方針を記載します。

下表は、非機能要求グレード 大項目「D 移行性」を抜粋したものです。

表: 「D 移行性」の小項目とメトリクス（折りたたんでいます）
大項目 中項目 小項目 メトリクス(〇: 重要項目)
D 移行性 D.1 移行時期 D.1.1 移行のスケジュール D.1.1.1 ○ システム移行期間
D.1.1.2 ○ システム停止可能日時
D.1.1.3 ○ 並行稼働の有無
〃 D.2 移行方式 D.2.1 システム展開方式 D.2.1.1 ○ 拠点展開ステップ数
D.2.1.2 ○ 業務展開ステップ数
〃 D.3 移行対象（機器） D.3.1 移行設備 D.3.1.1 ○ 設備・機器の移行内容
〃 D.4 移行対象（データ） D.4.1 移行データ量 D.4.1.1 ○ 移行データ量
D.4.1.2 ○ 移行データ形式
〃 〃 D.4.2 移行媒体 D.4.2.1 　 移行媒体量
D.4.2.2 　 移行媒体種類数
〃 〃 D.4.3 変換対象（DBなど） D.4.3.1 　 変換データ量
D.4.3.2 　 移行ツールの複雑度（変換ルール数）
〃 D.5 移行計画 D.5.1 移行作業分担 D.5.1.1 　 移行のユーザ/ベンダ作業分担
〃 〃 D.5.2 リハーサル D.5.2.1 　 リハーサル範囲
D.5.2.2 　 リハーサル環境
D.5.2.3 　 リハーサル回数
D.5.2.4 　 外部連携リハーサルの有無
〃 〃 D.5.3 トラブル対処 D.5.3.1 　 トラブル対処の規定有無

大項目「D 移行性」は他の大項目と比べて小項目の粒度が細かく定義されているため、
以降、中項目ごとに解説します。

D.1 移行時期

小項目 メトリクス(〇: 重要項目)
D.1.1 移行のスケジュール
移行作業計画から本稼働までのシステム移行期間、システム停止可能日時、並行稼働の有無。（例外発生時の切り戻し時間や事前バックアップの時間等も含むこと。）
 D.1.1.1 ○ システム移行期間
D.1.1.2 ○ システム停止可能日時
D.1.1.3 ○ 並行稼働の有無
メトリクス内容（折りたたんでいます）
項番
メトリクス		 レベル0/1/2/3/4/5
備考
D.1.1.1
○
システム移行期間		 0: システム移行無し
1: 3ヶ月未満
2: 半年未満
3: 1年未満
4: 2年未満
5: 2年以上
D.1.1.2
○
システム停止可能日時		 0: 制約無し （必要な期間の停止が可能）
1: 5日以上
2: 5日未満
3: 1日 （計画停止日を利用）
4: 利用の少ない時間帯（夜間など）
5: 移行のためのシステム停止不可

【メトリクス】
システムによっては、システム停止可能な日や時間帯が連続して確保できない場合がある。（例えば、この日は1日、次の日は夜間のみ、その次の日は計画停止日で1日、などの場合。） その場合には、システム停止可能日とその時間帯を、それぞれ確認すること。
【レベル】
レベル0はシステムの制約によらず、移行に必要な期間のシステム停止が可能なことを示す。レベル1以上は、システム停止に関わる（業務などの）制約が存在する上での、システム停止可能日時を示す。レベルが高くなるほど、移行によるシステム停止可能な日や時間帯など、移行計画に影響範囲が大きい制約が存在することを示している。
D.1.1.3
○
並行稼働の有無		 0: 無し
1: 有り

【レベル1】
並行稼働有りの場合には、その期間、場所等を規定すること。関係項目にF.4.2.3、F.4.4.3がある。

計画停止期間のフィージビリティ

  • 中項目「D.1 移行時期」の小項目は「D.1.1 移行のスケジュール」一つだけです。
    本項目に含まれる全てのメトリクスは「〇：重要項目」とされており、要件定義の初期段階から検討する必要があります。
  • 本項目では、以下のような移行時期(D.1)に関する方針を定めます。
    • 検討期間 (D.1.1.1 システム移行期間) ：
      メトリクスにある、移行作業計画から本稼働までの期間を示します。
      通常は開発期間と同じとなりますが、半年以上に及ぶ場合、工程を明示したマスタースケジュールとして示すことが望まれます。
    • 停止期間 (D.1.1.2 システム停止可能日時) ：
      システム移行時のサービス停止期間を定めます。
      これをもとに移行設計で、システム移行作業期間、切り戻した際の予備(予備日)などを定めていくことになります。
    • 並行稼働の有無 (D.1.1.3 並行稼働の有無) ：
      メトリクスに示されている並行稼働が「有り」の場合、
      並行稼働の目的・実施方法・確認事項と、メトリクス説明にある並行稼働期間を定めます。

D.2 移行方式

小項目 メトリクス(〇: 重要項目)
D.2.1 システム展開方式
システムの移行および新規展開時に多段階による展開方式をどの程度採用するかの程度。
 D.2.1.1 ○ 拠点展開ステップ数
D.2.1.2 ○ 業務展開ステップ数
メトリクス内容（折りたたんでいます）
項番
メトリクス		 レベル0/1/2/3/4/5
備考
D.2.1.1
○
拠点展開ステップ数		 0: 単一拠点のため 規定無し
1: 一斉展開
2: 5段階未満
3: 10段階未満
4: 20段階未満
5: 20段階以上

【レベル】
拠点展開時のリスクによっては難易度が逆転し、一斉展開の難易度が高くなる場合もある。対象システムについて、拠点毎に展開時のリスクを考慮して拠点展開ステップ数を判断すること。
D.2.1.2
○
業務展開ステップ数		 0: 単一業務のため 規定無し
1: 全業務一斉切り替え
2: 4段階未満
3: 6段階未満
4: 10段階未満
5: 10段階以上

【レベル】
業務展開時のリスクによっては難易度が逆転し、全業務一斉切り替えの難易度が高くなる場合もある。対象システムについて、業務毎に展開時のリスクを考慮して業務展開ステップ数を判断すること。

段階移行によるリスク局所化

  • 中項目「D.2 移行方式」の小項目は「D.2.1 システム展開方式」一つだけです。
    本項目では、段階移行に関する方針を定めます。
  • 以下のような段階移行手法により、システム移行に伴い発生する問題の影響を先行リリース先に局所化し、全体の移行リスクを低減できます。
    • 拠点ごとに段階移行：システムが複数拠点に分かれている場合
    • 機能ごとに段階移行：非常に大量の機能を持つシステムの場合
    • カナリアリリース　：一部のユーザに新システムを先行解放できる場合

D.3 移行対象（機器）

小項目 メトリクス(〇: 重要項目)
D.3.1 移行設備
移行前のシステムで使用していた設備において、新システムで新たな設備に入れ替え対象となる移行対象設備の内容。
 D.3.1.1 ○ 設備・機器の移行内容
メトリクス内容（折りたたんでいます）
項番
メトリクス		 レベル0/1/2/3/4/5
備考
D.3.1.1
○
設備・機器の移行内容		 0: 移行対象無し
1: 移行対象設備・機器のハードウェアを入れ替える
2: 移行対象設備・機器のハードウェア、OS、ミドルウェアを入れ替える
3: 移行対象設備・機器のシステム全部を入れ替える
4: 移行対象設備・機器のシステム全部を入れ替えて、さらに統合化する

【レベル】
移行対象設備・機器が複数あり、移行内容が異なる場合には、それぞれ合意すること。

リホスト・リライト・リビルド

  • 中項目「D.3 移行対象（機器）」の小項目は「D.2.1 システム展開方式」一つだけです。
    機器とは、ハードウェアだけでなく、設備、ソフトウェア、アプリケーション、利用サービスなど、システムを構成する要素を指します。
  • 本項目では、機器の移行方針としてレイヤごとの移行方針を定めます。
    機器をレイヤに分類し、変更するレイヤだけでなく変更しないレイヤと、その方針を採用する理由を示して移行の全体像を明らかにする必要があります。
    （個々の機器の扱いは設計事項となります。）
    以下に代表的パターンを示します。
    HW更改 リホスト リライト リビルド BPR AP改修
    業務仕様 変更なし※ 変更なし 変更なし 変更なし 再設計 一部変更
    AP仕様 変更なし※ 変更なし 変更なし 再設計 再設計 一部変更
    業務AP 変更なし※ 変更なし 更改 更改 更改 一部変更
    基盤 同種(VerUP) 変更 変更 変更問わず 変更問わず 変更なし

Vol.18 マイグレーションパターン
主なレガシーマイグレーション手法

  • HW 更改：バージョンアップ (VerUP) とも言う。
    ハードウェア (HW) を交換し、OS・ミドルウェア・パッケージソフトなどのソフトウェアのバージョンアップを行う移行形態。
    ※　同時に大幅AP改修を行うことがある。
  • リホスト：APのソースコードを変更せずAP資産を利活用しながら、基盤のみを変更する移行形態
  • リライト：AP仕様を変更せずに、APの開発言語を変更する移行形態
  • リビルド：AP仕様から設計しなおしてシステム開発する移行形態
  • BPR (Business Process Re-engineering) ：業務プロセスを再設計する。通常、システムも根本から見直す。
  • AP改修：基盤を変更せずに、APのみを改修する移行形態。
    システム移行とみなさなずAP保守と位置付けて実施することも多い。

D.4 移行対象（データ）

小項目 メトリクス(〇: 重要項目)
D.4.1 移行データ量
旧システム上で移行の必要がある業務データの量（プログラムを含む）。
 D.4.1.1 ○ 移行データ量
D.4.1.2 ○ 移行データ形式
D.4.2 移行媒体
移行対象となる媒体の量と移行時に必要となる媒体種類数。
 D.4.2.1 　 移行媒体量
D.4.2.2 　 移行媒体種類数
D.4.3 変換対象（DBなど）
変換対象となるデータの量とツールの複雑度（変換ルール数）。
 D.4.3.1 　 変換データ量
D.4.3.2 　 移行ツールの複雑度（変換ルール数）
メトリクス内容（折りたたんでいます）
項番
メトリクス		 レベル0/1/2/3/4/5
備考
D.4.1.1
○
移行データ量		 0: 移行対象無し
1: 1TB未満
2: 1PB未満
3: 1PB以上
D.4.1.2
○
移行データ形式		 0: 移行対象無し
1: 移行先と形式が同一
2: 移行先と形式が異なる

【メトリクス】
データ形式は、アプリケーションに依存したフォーマット、テーブル形式や文字コードなど、新システムに移行するために考慮すべきデータ形式のパターンを指す。
【レベル】
移行データ形式のパターンが複数ある場合には、それぞれについてデータ形式を確認すること。
D.4.2.1
　
移行媒体量		 0: 移行対象無し
1: 10本未満 （1TB未満）
2: 1000本未満 （1PB未満）
3: 1000本以上 （1PB以上）
D.4.2.2
　
移行媒体種類数		 0: 移行対象無し
1: 1種類
2: 2種類
3: 3種類
4: 4種類
5: 5種類以上

【メトリクス】
移行する際に使用しなければならない媒体の種類を計数する（例えば、テープ、ディスク、紙の伝票類、など）。 また、ネットワーク接続によるデータ転送も媒体種類として含む。
D.4.3.1
　
変換データ量		 0: 変換対象無し
1: 1TB未満
2: 1PB未満
3: 1PB以上
D.4.3.2
　
移行ツールの複雑度（変換ルール数）		 0: 移行ツール不要 または 既存移行ツールで対応可能
1: 変換ルール数が 10未満 の移行ツールの複雑度
2: 変換ルール数が 50未満 の移行ツールの複雑度
3: 変換ルール数が 100未満 の移行ツールの複雑度
4: 変換ルール数が 100以上 の移行ツールの複雑度

量と変換パターン

  • 中項目「D.4 移行対象（データ）」は、3つの小項目から成ります。
    データに関する移行方針を定めます。

  • まず、「〇：重要項目」からなる小項目「D.4.1 移行データ量」に以下をまとめます。

    • 業務データ量　：移行対象データの総量、1日あたりの更新量などを整理する。「D.4.1.1 移行データ量」
    • 変換パターン　：ファイルやDBについて、フォーマットや文字コードなどの変換パターンを整理する。「D.4.1.2 移行データ形式」
    • プログラム規模：プログラム種類毎に、現行規模、更改に伴う変更方針を整理する。Java, COBOLなどの主処理だけでなく、定義体(XML, YAML、HTML, JavaScript, 帳票ツール定義 など)、シェル・JCLなども含む

  • 続いて、「〇：重要項目」となっていない、以下の小項目を整理します。

    • 「D.4.2 移行媒体」
    • 「D.4.3 変換対象（DBなど）」

D.5 移行計画

小項目 メトリクス(〇: 重要項目)
D.5.1 移行作業分担
移行作業の作業分担。
 D.5.1.1 　 移行のユーザ/ベンダ作業分担
D.5.2 リハーサル
移行のリハーサル（移行中の障害を想定したリハーサルを含む）。
 D.5.2.1 　 リハーサル範囲
D.5.2.2 　 リハーサル環境
D.5.2.3 　 リハーサル回数
D.5.2.4 　 外部連携リハーサルの有無
D.5.3 トラブル対処
移行中のトラブル時の対応体制や対応プラン等の内容。
 D.5.3.1 　 トラブル対処の規定有無
メトリクス内容（折りたたんでいます）
項番
メトリクス		 レベル0/1/2/3/4/5
備考
D.5.1.1
　
移行のユーザ/ベンダ作業分担		 0: 全てユーザ
1: ユーザとベンダと共同で実施
2: 全てベンダ

【メトリクス】
最終的な移行結果の確認は、レベルに関係なくユーザが実施する。なお、ユーザデータを取り扱う際のセキュリティに関しては、ユーザとベンダで取り交わしを行うことが望ましい。具体的内容については、「F.1.1.1 構築時の制約条件」にて確認する。
【レベル1】
共同で移行作業を実施する場合、ユーザ/ベンダの作業分担を規定すること。特に移行対象データに関しては、旧システムの移行対象データの調査、移行データの抽出/変換、本番システムへの導入/確認、等について、その作業分担を規定しておくこと。
D.5.2.1
　
リハーサル範囲		 0: リハーサル無し
1: 主要な正常ケースのみ
2: 全ての正常ケース
3: 正常ケース＋移行前の状態に切り戻す異常ケース
4: 正常ケース＋システム故障から回復させる異常ケース
D.5.2.2
　
リハーサル環境		 0: リハーサル無し
1: 本番データ使用可能
2: 本番データ使用不可

【レベル】
本番データを使用することによる情報漏えい等のセキュリティリスクは、「F.1.1.1 構築時の制約条件」にて判断し、ここではリハーサル環境に限定して判断する。
D.5.2.3
　
リハーサル回数		 0: リハーサル無し
1: 1回
2: 2回
3: 3回
4: 4回
5: 5回以上
D.5.2.4
　
外部連携リハーサルの有無		 0: 無し
1: 有り （外部接続仕様の変更無し）
2: 有り （外部接続仕様の変更有り）

【メトリクス】
外部システムとの接続仕様が変更になる場合、システム移行リスクを軽減するために新システムでは新旧両接続仕様をサポートすることがある。その場合には、両接続仕様を確認するための外部連携リハーサルを計画すること。
【レベル】
外部連携リハーサル有りの場合、そのリハーサル対象の外部システムとリハーサル範囲、環境、回数について規定すること。
D.5.3.1
　
トラブル対処の規定有無		 0: 規定無し
1: 対応体制のみ規定有り
2: 対応体制と対応プランの規定有り

【レベル】
トラブル対処の規定有りの場合、その対応体制や対応プランの規定内容について確認すること。

移行リハーサルと体制

  • 中項目「D.5 移行計画」は、以下の3つの小項目から成ります。
    本項目では、移行リハーサルと体制に関する方針を定めます。
    なお、本項目には「〇：重要項目」はありません。
    • 「D.5.1 移行作業分担」
    • 「D.5.2 リハーサル」
    • 「D.5.3 トラブル対処」
  • 特に、他システムとの接続インタフェースに変更がある場合、
    片方のシステム移行に問題（移行切戻しやリスケジュールなど）があると、相手方システム移行にも影響します。
    このため、両システム間で密に連携してシステム移行（リハーサル (D.5.2.4) だけでなく、計画や試験も）を実施することが望まれます。

あったら怖い本当の話

※　実際に起きたことを、脱色デフォルメしたフィクションにして紹介します。

😱移行作業のゴミ

性能試験・障害試験・移行リハーサルを経て、品質には問題なし。
移行作業を完了し、移行後のユーザ打鍵確認・切戻しチェックポイントも通過

新システムは、翌朝のオンラインから、問題なく稼働していました

障害の構造

  • 移行作業により、DBにゴミコネクションが大量に残っていたのが原因でした。
    ※ゴミコネクション：クライアントの存在しないDB上のコネクション
    1. DBのゴミコネクションにより、DBコネクションが上限に達し、APサーバが必要なコネクションプールを取得できず
    2. APサーバのスレッドが、コネクションプール割当待ちによりレスポンス劣化
    3. 高負荷により、レスポンス劣化とスレッド増の悪循環に陥り、
      APサーバのスレッド数上限に至りタイムアウト多発

敗因

  • 移行作業の後、システム全体をベーシックリカバリ手順にそって再起動することにより、異例作業などに伴う不測のゴミを掃除し、性能試験・障害試験など各種試験をした状態とする必要がありました。
  • なお、移行リハーサルの直後に負荷試験を行っていれば、問題を検知できました。
    しかし、環境繰り上、現実的な方針ではありません。
    また、緊急対応などで発生したゴミには対応できないため、十分な対策とは言えません。

再発防止

  • ガイドラインに以下を追加しました。
    「移行作業完了後、不測のゴミを掃除するため、再起動を行うこと。
    　再起動は、ベーシックリカバリ手順を適用すること。
    　最終打鍵確認、および切戻し最終判定は、再起動後の状態に対して行うこと」

まとめ

本記事では、現行システムがある場合、計画停止期間、段階移行、レイヤ毎の更改有無、移行データ量と変換パターン、体制について、要件として示す必要があることを説明しました。

最後に、NTTデータの金融高度技術本部では、ともに金融ITの未来を切り拓く仲間を募集しています。

[募集要領]
https://nttdata-career.jposting.net/u/job.phtml?job_code=1172
[NTTデータ 金融分野の取り組み]
https://www.nttdata.com/jp/ja/industries/finance/

脚注

  1. IPA（独立行政法人 情報処理推進機構, Information-technology Promotion Agency, Japan） ↩︎

  2. 非機能要求グレード:
    参照用pdf: 非機能要求グレード2018 改訂情報(PDF:897 KB)
    活用用xls: 非機能要求グレード本体（日本語版）、利用ガイド［活用編］一括ダウンロード(ZIP:9.7 MB)の　06‗活用シート.xls ↩︎

NTT DATA TECH
NTT DATA TECH

NTT DATA公式アカウントです。 技術を愛するNTT DATAの技術者が、気軽に楽しく発信していきます。 当社のサービスなどについてのお問い合わせは、 お問い合わせフォーム nttdata.com/jp/ja/contact-us/ へお願いします。

設定によりコメント欄が無効化されています