ＩＴシステムの移行とは
移行とは、新ＩＴシステムを本番として移行することを示します。
広義では、稼働させることを示していますが、狭義では必要な個々のＩＴ資産を移行することを指すこともあります。
移行と似たような言葉で切り替えがありますが、切り替えはピンポイントを示しているのに対して、移行は全体としての移行が完了し、新しい日常が安定するまでを捉えます。
全体として、と言ったのは、ITシステム面に限らず、事業・業務の変更や、かなり前から行われる準備段階も含めて言及しているという意味となります。
移行の方式にどのようなものがあるか？
移行には多くの危険が伴います。
移行したはいいが、うまくいかないところがあり、事業が一部機能しなくなることさえあります。
よって、リスク度合に応じて、より安全な移行方式がないか検討をすべきです。
一度に移行せざるを得ないものは一斉移行となります。この場合、移行前の状態にすぐ戻せるか、変化が少ないなど、リスクが少ない時の選択となります。
並行稼働後の移行という方式があります。新旧どちらの運用もＯＫとしておいて、古い運用を一定期間後に無くすという方式です。この方式は不具合があった時に、新旧どちらかに運用を切り替えられるので、安全な方式です。
ただし、2重運用によりコストがかかる部分もありますので、総合的な判断となります。
その他、段階移行というものがあります。いくつかの切り替えポイントに分けられる場合、部分的に移行していき、最終的にすべて移行させるというものです。この方式もリスク低減のための策です。
段階移行と似ていますが、パイロット展開という方式もあります。地域などで先行して展開できる場合は、まずはどこかで先行移行させ、問題を潰したうえで、全体を展開させるというものです。この方式は、先行して移行させるために、内部的には並行稼働になっている部分もでてくるのと、地域などの一定単位に展開できることが条件となるため、それに適したものが採用される方式となります。
ＩＴシステムの稼働とは
ＩＴシステムの稼働とは、ＩＴシステムの開発が完了し稼働した状態を指します。
移行は前段階からの一連の過程を示しているのに対して、稼働は新ITシステムが本番運用されている状態を示しています。
移行で説明した段階移行においては、一部稼働しているということになります。
稼働したら新ＩＴシステムが日常となるので、プロジェクトは完了したということに表面上はなりますが、稼働後も実際は、残課題案件等があり、フォロー期間が必要なのが通常です。稼働後に完全に日常になるまでの間をここではプロジェクトとしての稼働とします。
移行と稼働のタスク
移行と稼働の計画タスク
実際に移行・切り替えを実行するかなり前から計画は実行される必要があります。
移行の計画
移行にあたっての、資産やデータ、事業・業務の変化を踏まえて、どのように移行していくかを決めていきます。
どのように移行するかを決めるにあたり、実施すべきことが多く発生しますので、どのように準備するかを計画します。
移行の難易度やリスクなどを踏まえて、リハーサルを計画します。
また稼働後にどういう体制でどのようなことをするのかを、稼働後の状態予測を踏まえて計画します。
本番切替はうまくいくとは限りません。そのリスクを踏まえて、方式を選びますが、さらに当日うまくいかなかった時の保険の計画も用意します。
稼働の計画
稼働は切り替え後の本番稼働された状態ですので、新しい運用に入った状態と言えます。
新しい状態は完了後の状態ですので、計画することは何もないように思えますが、何か起きるのが通例ですので、備えを含めた計画となります。
まずは稼働後のフォロー体制を取り決めていく必要があります。
初期段階では、運用の移行や新ITシステムの利用面でスムーズにいかないことが多いため、なんらかフォローしていく体制が必要です。
また、ITシステムが安定しない段階では、不具合も発生する可能性があります。
不具合は、システムの不具合を直せばすぐに完了するものではなく、不具合により発生してしまったシステム内のデータの状態などにも影響を及ぼします。
よって、リカバリーに慎重を期すために、調査と復旧を可能とする体制を整えておく必要があります。
移行準備
準備において重要となってくるものはデータ移行です。こちらは別途説明してきました。
その他ＩＴシステムを移行するために、各種資産を最新化するなどの準備を計画します。
また事業への変化に対応するための、対外調整や内部調整の準備を行います。
特に対外調整は、取引先の準備期間が必要であるため、十分な期間をとって対応する必要があります。
内部調整のメンバと同一だと対応しきれない可能性もあるため、体制もよく検討します。
移行リハーサル
移行・切り替えを確実に行うために、リハーサルを行います。
切り替え前後の変化を踏まえ、対応できるよう準備した内容を実際に事前に実行します。
そして、当日ピンポイントでの作業を事前にリハーサルします。
その日でしかできないことは大抵存在するため、時間が限られていることが多いです。
時間内に想定作業が終わるかどうかを検証するために、場合により複数回リハーサルを実施します。
当日作業に失敗が発生した場合、いつまでであれば続行できるかという、切り戻し判断ポイントを決めておきます。
時刻だけでなく、内容においても、ＮＧ項目がないことをリハーサルで確認します。
また、時間が限られている中で、連絡体制も重要です。予め決めておかないと、動きが非効率となります。
移行の判断
移行準備とリハーサルを実施してきた段階で、予定していた移行作業の実行可否を判断します。
判断がなされると、その後計画どおり実行されることになりますので、取り返しがつかないよう、慎重に検討します。
まずは、これまでの一連のテストにて十分な品質が確保されているかという観点で振り返ります。
テスト中発生した問題の解決も含めて完了し、品質が確保されていることを判断材料とします。
準備は、切り替え前・切り替え中・切り替え後を含めた一連の準備がすべて整っていることを意味します。
事業面とＩＴシステム面の両面の切り替えが必要となります。
事業面では、内外調整や業務切り替え準備、移行過渡期の一時作業などが準備されているか、ITシステム面では、データ移行、ＩＴ資産移行、過渡期の対応、連絡体制、万が一のための計画が整っているか、といったことを判断材料とします。
移行・切り替え当日の実行タスク
当日というとある一日を示しているようにも思えますが、一日とは限りません。
数日にわたるケースもありますし、作業日が複数日に分かれるケースもあります。
それら一連の作業日が当日となります。
当日は、計画・準備された手順に基づいて作業を実行します。
仮に計画されていない作業があれば、基本的には実行しません。その際は再度計画から見直すことになります。
ITシステムの切り替えは、そのくらいに厳しく考えていたほうがいいです。
ちょっと漏れていた作業があったため、その場で作業者が実施したものの、思わぬところに影響が及んでしまうということさえあり得ます。
また、切り戻し判断を意識し作業を実行していくことになります。
切り戻すにしても、そこまでの作業をすべて戻してしまうため、なかなか決断しづらいものです。
しかし、所定の基準を満たさなければ、切り戻すしかありません。
稼働の判断
稼働の判断タイミングは、いよいよ本番として稼働するということが、引き返せない状況で行われます。
切り戻しポイントを通過するタイミングとなります。
もう引き返せないわけですから、十分に整った条件下で判断を下したいものです。
判断すべき材料は、その場で考えていてはとても間に合いませんので、当然事前に計画・準備なされているものです。
そころが、当日想定外の事象が発生しないこともありません。想定外であっても、前に進める材料があれば、進む判断をするでしょう。
そのように、できる限り考えうる判断観点と計測時点の実績結果により、しかるべき判断がなされるべきです。よって、判断から逆算し当日タスクを進めるべきですし、さらに逆算すれば、スムーズな稼働判断に繋げられるよう事前に計画すべきということになります。
稼働後のフォロー対応
稼働後は、何もなければ一番いいですが、大抵何かはあります。
準備段階においてマニュアルを用意していたとしても、マニュアルにない事象は発生します。また、不具合が発生してしまうケースもあります。
フォロー対応として、準備していくことは、マネジメント方法と体制を決めて備えるということです。
マネジメント方法が決まっていれば、臨機応変に対応することが可能です。
では、マネジメントはどのようにしていけばいいでしょうか。
移行・稼働のマネジメント
移行準備の進捗
移行の計画に基づいて、準備を順次進めていきます。
準備段階では、テスト期間とも重なっている可能性が高いので、スケジュールは余裕をもって、稼働リソースも考えつつ実行計画を立てる必要があります。
移行する領域としては、事業・業務の移行、ITシステム資産の移行、データの移行があり、それぞれの観点で準備タスクを実行されていると思います。
タスク毎の進捗を測ることが、マネジメント面の基本です。
移行準備は様々なタスクが存在しますが、移行・切り替えに向けて、１点に収束していきます。つまり、どのタスクもイベントに向かって収束していかないといけないということになります。
一つのタスクだけ見ているのではなく、関連するタスクも含めて影響を見ます。そうしないと、結果的に移行・切り替えそのものが遅れてしまうことになり兼ねないからです。
移行リハーサルのマネジメント
移行リハーサルは、計画、準備、リハーサル当日作業、結果評価というタスクになります。
リハーサルは本番での実施内容と同等であるべきですが、データ等が本番同等にできない可能性があります。
よって、準備と評価に対し、本番との差異や制約を加味し、計画しなければならないことになります。
計画に基づいて実行する段階では、計画どおりのレベルでリハーサルが準備できているかという出来高を加味した進捗を見ていきます。
出来高は一見わかりにくいものかもしれません。しかしそれを分かるようにマネジメントしないと、リハーサルの意味が半減してしまいます。
移行時のデータ変換率や初期データ登録率など定量化されたものを評価していきます。
リハーサルでは失敗に関するシミュレーションと評価も行います。
また、作業系ばかりでなく、連絡や報告のコミュニケーション系も正しく動くかを確認します。
本番との差異を踏まえて、リハーサル結果を評価し、もし本番前に何かやるべきことを見つかったら、再度実行することも視野に入れます。
移行当日のマネジメント
当日は時間単位でのマネジメントとなります。
当日は役割を明確にした体制を組んで臨みます。
作業予定時間と実測値につき、計測していきます。
発生した想定外事象は、 課題としてリアルタイムに共有していきます。
少しの時間ロスが、全体に影響しないとも限らないため、管理者のコントロールが必要となってきます。
切り戻し判断ポイント通過し、諸々の作業が基準を満足していれば、稼働判断がクリアとなります。
その場その場での判断が重要となってくるため、判断材料を事前に計画することと、関係するメンバをできる限り待機させる必要があるでしょう。
稼働のマネジメント
移行・切り替えの後はすぐに稼働状態となります。
ということは、稼働直後から稼働のマネジメントに切り替えないといけないということです。よって、マネジメント方法は予め決めておく必要があります。
仮にITシステムが夜中もサービスしているのであれば、稼働直後からフォロー体制に入り、24時間連続勤務の人が出てきてしまうかもしれません。そのようなことがないように、予めローテーションを決めておく必要があります。
稼働したら開発は終わっているはずですので、やることはそれほどないと思いたいところですが、何もないということはあまりありません。
少なくとも以下の点を考慮して、稼働をフォローすることを前提にマネジメントしていきます。
本番初回イベントフォロー
切り替えから初回となるイベントがあれば、正しく動作することの確認を行います。
動作だけでなく、処理されるべきことがなされているか、例えば締め切りまでに入力がなされ、正しく請求書が出ているか等の確認を行います。
各イベントが正しく完了していることを定量的に把握し、品質が保たれているかをフォローします。
残案件フォロー
稼働はさせたものの、残案件がある可能性があります。
稼働3日目にリリースする等の機能面のこともありますし、監視方法を確立するといったシステム運用面もあります。
残案件は、稼働中ということも考慮して対処していかないといけないため、難易度が上がっています。よって、何等か本番に手を加えるのであれば、１件ごとに計画を立て実行するというマネジメントを継続的に行います。
インシデントフォロー
インシデントとは、何等か発生した場合インシデントと扱いますが、 障害であることが多いでしょう。
テストや移行のリハーサルを繰り返してきたものの、障害は発生してしまうものです。
規模当たりの本番障害発生数はある程度予想できるかもしれませんが、予測ができませんので、発生することを前提にマネジメントします。
発生事象を捉えるとともに、発生原因、対処方法と対応状況、根本原因と対策について、マネジメントし、着実に進んでいることを確認できるようにします。
発生件数は時系列に捉え、収束状況を確認します。各事象の対応状況により、案件が積みあがっていないと確認し、もし積み上がっていれば、対応の強化を行う等にてマネジメントを行います。
事象の解決に留まらず、本番まできて発生している事象は、これまでの過程で見落としであったので、どこかに穴があったことを前提に、根本原因分析を行い、類似事象の穴を埋めるべく、対策を講じます。
分析状況や対策立案状況について、途中経過を見えるようにし、監視します。完了状況はもちろんマネジメントし、全体の収束見込みを立てます。
終了が見えてきたら、最終評価を行います。事象の原因や根本原因を全体的に分析し、今後に生かします。
移行・稼働でのありがちな問題
移行計画が不十分で後から慌てる
移行計画は綿密に立てる必要があります。説明してきましたが、各移行作業が移行切り替えというピンポイントのイベントに向かっています。ピンポイントのタイミングとなった時点では、検討する暇はありません。
よって、移行するまでのすべてのことを考慮してタスクが網羅できるよう計画することになります。
ところが、未来のことをすべて網羅的に考えるのは、普通の人は困難です。
よって、不十分な点が出てくることもあります。
そうなってくると慌ててしまうことになりますが、既に遅しです。
些細なものだと思い、突き進んでしまう
移行データに１件不適切な文字が含まれていたとして、それを直さずに進めたとします。案の定、その１件が元で、ＩＴシステムが動かなくなってしまいました。それは新システムでは発生しえないデータであったからです。
些細なものであったとしても、全体に影響を及ぼす可能性はあります。
このようなわかりやすい事象ばかりではありません。ミドルウェアやOSの問題で不具合が発生することもあります。原因が解明していなくても、たまにしか起きないということで、軽視してしまうこともあるでしょう。
移行するものを誤る
移行手順が正しく、正しく作業が行われたとしても、不具合が発生していることがあります。
それは、手順は正しくても、移行するものがそもそも誤っていたということです。
これは移行資産のマネジメントが適切になされていなかったためです。正しく行われることは当然のことですが、よく誤っていることがあります。
それは、修正が入った場合に正しいものに対して修正し、最新を管理するといった、変更管理が正しく行われていないことによります。
簡単なことと思いきや、イレギュラーは発生するため、正しくない状態は起こりえます。
変化が徹底されておらず、仕事が増える
ＩＴシステムの変更は、事業や業務を変更させることになります。
当初予定していたとおりに変更されたとしても、業務の変化が徹底されておらず、多数の問い合わせが発生してしまうことがあります。
予定どおりとはいえ、時間がたっていると忘れてしまいます。忘れることに対する対策は打っておいたほうがよいでしょう。
また、行き渡っていないこともあります。行き渡らせるための準備と経過観測についても計画し、監視しましょう。
そうしないと、結果的に仕事が増えることになります。
移行・稼働で本当にやるべきこと
新ＩＴシステムの本番への移行・切り替えはこれまで行ってきたことの集大成であり、１点に集約されるイベントです。
ここでうまくいかせるためには、かなり前から準備を綿密に計画して、確実に実行を積み上げることが大切です。
かなり前の段階から計画するようにしたとしても、他の設計、開発などのタスクも進んでいる最中であることが多く、仕様が未確定であったり、検討リソースが不足していたりして、不十分になりがちです。
時間が許されるのであれば、全体スケジュールに余裕を持ったほうが無難ですが、そういかないのが常です。
したがって、やはり確実に計画を立てていくことが肝要です。
先のことを明確に描くことは易しいことではありませんが、ゴールイメージを描くこと、そこまでの道のりを描くことの両方で、未来をリアルに感じられることでしょう。
コメント