3. 移行の観点それぞれで気を付けるポイント

3. 移行の観点それぞれで気を付けるポイント

これまでお伝えした4段階の対策は、4種類の移行の性格によって、それぞれ気を付けておくべきポイントが異なってきます。ここからは、4つの移行の観点ごとに、私たちの経験から特に気を付けておくべきポイントについてピックアップしてお伝えしていきます。

3.1システム移行は早期の検討着手と徹底した事前確認

システム移行の作業で気を付けるポイントとしては、本番相当環境で端末の動作確認をすること、研修のために機器の先行設置をするケースの2つです。

「本番相当環境での端末の動作確認」

端末の動作確認は、本来は端末、ネットワーク、サーバー、システム基盤、業務アプリケーションなどを一気通貫でテストする全体システムテストの中で確認することが望ましいですが、システムテストのなかで全端末の動作確認を行うためには、相当の時間を要してしまい現実的ではありません。また、端末機器の調達から納品までにも時間が必要となり、早期の調達は保管場所が無いといった問題が生じます。

そこで、全拠点での動作確認や全ての端末の動作確認は、システム移行作業の一部として実施します。札幌市では、最初のリリースである住民記録システムの際に、サーバー機器やネットワーク、端末環境のすべてが新しいものを利用することになりました。また、構築したシステム基盤も初めての利用でした。

そこで、システムで利用する約150台の端末、100台のプリンタについて、リリース前に各区役所などの会議室に場所を借りて機器を搬入し、そこにネットワークを引き、実際のIPアドレスやセキュリティ設定、プリンタの出力トレイの設定などを行ったうえで、テストを実施しました。

テストは、テスト手順書を作成した上で、情報化部門の職員が2週間程度の期間のなかで全ての端末について、(1)全ての設定が正しいか、(2)設定内容が確実に設定されているか、(3)現地からの接続で確実に接続できるかの3点について確認を行いました。  

これらの確認を行うことで、特定の拠点や機器に関する問題を発生させることなく本番を迎えることができました。

「研修のための機器の先行設置」

端末については、設置場所での新旧端末共存が物理的に難しいため、本稼働直前に端末の一斉切り替えを行うことになるケースが殆どだと思います。

一方、業務移行の検討のなかで、利用者研修のために新システムが利用できる端末を先行して設置する必要が出てくるケースがあります。機器類は機種選定から調達、配送から設置までに時間が必要で急な変更がしにくいことから、事前に研修計画と機器の設置計画との整合性を採っておき、どの時期にどこに何台の端末を配置する必要があるのかを計画化しておきます。

3.2データ移行

データ移行の作業で注意する点としては、移行データの早い段階での調査・整理と、徹底したデータ移行リハーサルの計画と実施です。

「移行データの早い段階での調査・整理」

移行が必要となる旧システムのデータには不要なデータや不整合なデータが含まれています。これらのデータは調査の上で整理する必要があり、私たちはこれを「データクレンジング」と呼んでいました。これには、業務的な視点での確認が必要となる場合が多く、多くの時間を要します。

ですから、早い段階で調査や整理に入らなければ間に合わなくなってしまい、新システムに整理されていないデータを流入させることに繋がってしまいます。

また、旧システムのデータを新システムのデータベースのどこへ格納するのかの検討は、新システムの設計がある程度固まる基本設計に入った頃から実施することが可能になるため、この時期から着手するように作業計画を立てておきます。

なお、こういった旧新データの対応付けの整理を早い段階で行うことは、設計・開発する画面や帳票とデータの関連や整合を早い段階で確認でき、基本設計工程での設計品質を向上させることにも繋がります。

「徹底したデータ移行リハーサルの計画と実施」

より本番に近いリハーサルは開発の最終段階でなければ実施できませんが、そこで最初のリハーサルをすると、何かあった時の影響が大きくなってしまいます。そこで、開発工程が始まってから段階的に複数回リハーサルを行います。

札幌市では移行リハーサルを4段階に分け、それぞれにゴールを設定して実施するようにしました。平成26年度に稼働した税システムの場合は平成26年1月から2ヶ月毎に各段階のリハーサルの準備と実施を行いました(図4)。

zu4

第1回の移行リハーサルは、移行手順や移行ツールの問題点・改善点の洗い出しを行うこと、プロジェクト間のデータ授受の手順を確認することの2つを目的としました。

第2回は、第1回で洗い出した移行手順や移行ツールの問題が改善されていることを確認すること、処理時間実績を計測することを目的にしました。

第3回では、第2回の処理時間実績に基づきタイムテーブルを作成し、全プロジェクトの作業を通しで実施すること、PMOへの報告手順を確認することを目的にしました。

最終段階となる第4回のリハーサルでは、本番移行同様のタイムテーブルを作成し、24時間体制を組んで、確定した移行手順書に沿って本番さながらのリハーサルを行うこと、本番移行同様に、PMOへの報告を行うことを目的にしました。

途中で目的が達成できなければ、再度リハーサルを実施し、それぞれの段階を確実に達成していくようにします。

特に、第4回合同移行リハーサルは、本番移行に向けた最終確認となるため「本番さながら」に一気通貫でリハーサルを実施します。

時間帯を組み換えて、日中の時間帯に合同移行リハーサルを行うことも可能ですが、その場合、深夜時間帯のマシンリソースのバッティングや、体制構築上のミスなど、本番で発生しうる障害を発見できなくなるため、本番と同様に24時間体制を組み、深夜時間帯を問わずリハーサルを実施し、本番とほぼ同様の状況を作って実施するようにします。

3.3システム運用移行

システム運用移行は4つの移行のなかでも特に漏れやすいものです。

これは運用の検討が開発終盤になること、またシステム開発の作業全体からみると運用の検討は後回しにされることが多いことによります。

ですから、まずはシステム運用移行を忘れずに検討するよう意識することからがスタートになります。

新旧システムでは運用作業の種類や内容が大きく変わることが多いため、新しいシステムが稼働した際に、システム運用業者や情報化部門の運用担当者が運用手順に従って問題なく運用作業が実施できるようにすることが重要です。

そのためには、リハーサルや研修の実施が必要となります。

その場合は、そのことに起因するトラブルがシステム稼働後に長く尾を引くことになります。例えば、システムが新しくなっても外部機関との媒体でのデータのやり取りは残ることが多いです。

すると、媒体でデータを受領して、媒体からファイルを取り込み、取り込んで問題無いかを確認してシステムに投入するという様な作業(またはその反対の作業)が運用作業として定常的に発生します。

これらの作業を準備なしに行うと、媒体が読みこめなかった、実は何らかの変換が必要だったということが判明して、対応に手間取っているうちに、バッチ処理の時刻が到来して処理が自動的に走ってしまった・・といった事が起こってしまうなど、定常的な運用作業に支障が生じるようになります。

また、知識の習得だけでなく、例えば稼働後のオンライン時間は通常より長くするのか短くするのかといったことや、処理スケジュールはどの段階で確定させるのかといったことなど、稼働後の業務所管部門とのやりとりからその内容をシステムに反映するまでの作業など、実際の運用を行うための作業の検討も重要ですが、こういったことも漏れがちになりますので、忘れないようにしましょう。

3.4 業務移行

業務移行は、これまでの業務に大きな変更を伴う場合や、組織編成が大きく変わるような場合、法改正で大幅に業務が変更となるような場合に特に注意が必要です。

「研修計画は調整が大変」

操作研修については、場所の確保や忙しいユーザーをどうやって参加させるのかといったことで苦労することになります。

要件定義段階から、ユーザーの繁忙期を一覧化しておくといった検討を行うことで、繁忙期を避けた全員研修の計画とするのか、利用拠点に端末を先行設置し自習方式での研修を含めた計画とするのかといった検討を早い段階で行うことができ、場所や端末の確保がしやすくなります。

複数プロジェクトの場合は、研修に必要な機材やデータを用意するプロジェクトが分担されるため、プロジェクト全体での調整が必要となります。札幌市では、機器の導入スケジュールやテストデータの準備状況が見えてくる開発工
程のタイミングで、個別プロジェクトがそれまでに整理していた研修計画の全体調整を行いました。

「システム切り替えに付随する変更に気を付ける」

また、業務移行では新システムを使う研修やマニュアルの準備などは比較的計画されますが、新システムに切り替えるにあたって変更となる、プリンタで使用する専用紙の手配や窓口のレイアウト変更、申請書類のレイアウトの修正などを忘れてしまいがちとなります。

システムの切り替えは万全のつもりだったのに、本番当日になって印刷する紙が用意できていない・・という状況はあまりにも残念です。移行計画のなかで、これらの修正時期や発注時期などを含めて計画しておくことで漏れを防ぐことができます。

「おわりに」

 次回は予定していた全8回の連載の最終回となります。最終回は運用保守をテーマに、運用保守を入札で実施することや、開発したベンダー以外がシステムの維持管理を行うための工夫や気を付けるべきポイントについてお伝えしていく予定です。