その2今回の「IT系お役立ち情報」は、前回お届けした「社内システムのクラウド化」の後編となります。前回のブログでは、次の様な内容を紹介しました。その1最初に、未だに、あいまいな「クラウド」と言う言葉の定義から始めて、従来の社内システム運用(オンプレミス)とクラウドの相違点を説明しました。このクラウドに関する、代表的なメリットとデメリットを紹介し、さらには、「非機能要件」と呼ばれている評価基準の視点から、クラウド運用が提供する要件をチェックして見ました。システムに対する「非機能要件」とは、システム品質を評価する基準なのですが、クラウド運用に関しては、ある程度、品質要件は満たしている事が解りました。「クラウド」と呼ばれる言葉とサービスが展開され始めて、はや7年ほど経過していますが、クラウドも進化しており、新たしいサービス形態が生まれているようです。--------------------------------------------------------------------------------------------------------そして今回は、実際にクラウドを導入する場合に、どのような作業が必要になるのかと言う点に関する概要説明から始め、次のような情報を提供しようと思います。●クラウド導入までの全体の流れ●クラウドに適さない業務それでは今回も宜しくお願いします。--------------------------------------------------------------------------------------------------------■クラウド導入までの全体の流れそれでは、クラウドに移行する場合に必要な、作業の流れを紹介したいと思います。クラウド移行、つまりシステムの移行は、会社毎に異なります。このため、今回は、「大体こんなもんだ」と言う流れを紹介します。今回紹介する作業フローを参考に、「ウチの会社には、この作業はいらない。」とか、「ここには無いが、こんな事も必要だ。--------------------------------------------------------------------------------------------------------正直な所、クライドへの移行も、普通のシステム開発やシステム移行と、なんら変わりありません。」と言う4段階を踏み、最終的に、システムを本番稼働に切り替える事だけです。実際のプロジェクトとなると、上記作業の前に準備作業が必要になりますし、そもそも、既存システムの調査/検討を行わず、最初から「クラウドありき」でプロジェクトを開始すると、そのプロジェットは、必ず失敗します。既存システムに対する調査/検討を行い、その上で、クラウドに切り替えるメリット/デメリットを明らかにし、メリットが多い場合は、引き続き、クラウド化プロジェクトを進めれば良いと思います。クラウドに移行するメリットが少ないにも関わらず、「クラウドありき」で、無理やりプロジェクトを進めると、その結果は、言わずもがなです。このため、本ブログでは、「クラウド化プロジェクト」を、大きくは2つ、細かくは次の8つのフェーズに分類しました。1.調査検討フェーズ:既存システムの調査分析を行い、クラウド化を推進するか否かを決定する(1)フェーズ1:事前準備(2)フェーズ2:計画立案(3)フェーズ3:導入検討2.移行導入フェーズ:クラウド化を推進する事が決定した場合に、実際に移行作業を行う(4)フェーズ4:移行設計(5)フェーズ5:移行作業(6)フェーズ6:試験稼働(7)フェーズ7:結果評価(8)フェーズ8:本番開始それでは、クラウド化を行う場合の、作業フェーズを紹介します。--------------------------------------------------------------------------------------------------------●フェーズ1:事前準備このフェーズは、実際に、プロジェクトを開始する前段階の作業になります。このため、場合によっては、作業フェーズに組み込まないケースもあるかもしれません。何らかのプロジェクトを開始する際は、誰かが発起人(オーナー)になり、次の様な事を決める必要があります。much「5W2H」だと、あと「Where」と「Why」が必要ですが、「Where」は社内、もしくは業者ですし、そもそも、当初は「How(どうやって)」を決める事が作業内容になります。この段階では、全ての予算や期間も明確にする事は出来ません。この「クラウド化」のプロジェクトは、前述の通り、大きくは次の2つのフェーズに分かれています。(1)調査検討フェーズ:既存システムの調査分析を行い、クラウド化を推進するか否かを決定する(2)移行導入フェーズ:クラウド化を推進する事が決定した場合に、実際に移行作業を行う当初は「調査検討フェーズ」だけを行い、その結果を踏まえて、「クラウド化を推進するか否か」を決める事になりますので、(2)のプロジェクト・フェーズは、上記(1)の結果次第と言う事になります。このため、予算や期間は、(1)のプロジェクトのみを、本フェーズ以降で決める事になります。--------------------------------------------------------------------------------------------------------●フェーズ2:計画立案このフェーズも、まだ計画段階の作業です。フェーズ2は、フェーズ1の事前準備を受け、フェーズ1で選ばれたプロジェクト・オーナー、あるいはプロジェクト・リーダーが、次のような作業を行います。muchつまり、このフェーズ2では、フェーズ1の内容を、より具体的に詰めて、プロジェクトを開始する事が出来る状態まで持って行く事を目的にしたフェーズとなります。このため、フェーズ2の目標は、次の3つになります。プロジェクト・メンバーの顔合わせと各種合意形成(ゴール共有)目標3:プロジェクトのキックオフフェーズ2の最終目的は、キックオフを開催してプロジェクトを始動させることです。キックオフにおいては、プロジェクトのゴール、およびメンバー各自の役割を認識共有する必要ありますので、そのために必要な各種資料を作成する必要があります。この段階では、社内に複数存在するシステムの内、どのシステムをクラウド化するのかは決定していないので、参加させるメンバーとしては、社内全部署の部長クラスを招集し、今後に行われる調査作業への協力を取り付ける必要があります。!」と反対勢力になってしまいますので、最初から各部署の「長」を、プロジェクトに参画させる必要があります。--------------------------------------------------------------------------------------------------------●フェーズ3:導入検討フェーズ3からが、実際の作業になります。このフェーズ3において、フェーズ4以降に行う、「システムのクラウド化」を行うか、あるいは中止するかの判断を下す事になります。このフェーズ3で、「社内システムのクラウド化は行う必要が無い。」と言う結論になれば、フェーズ4以降の作業は行う必要は無くなります。このため、このフェーズ3は、会社の今後を決定する一番重要な作業フェーズになります。このフェーズで、誤った決断を下してしまうと、会社に莫大な損害を与えてしまいますので、慎重に作業を進め、最後に下す判断も、偏った判断ではなく、中立公平な判断が必要になります。このフェーズ3では、主に次のような作業を行う事になります。(1)クラウド対象とする業務の候補選定1.全ての業務を、一括してクラウド化する事は出来ません。2.次のような観点で、クラウド化出来る業務を選定します。・クラウド化で業務運用に問題が起きない業務(長時間の業務停止にも耐えられる業務)・クラウドに移行してもセキュリティ上、問題のない業務(2)クラウド化候補となった業務の棚卸し1.選定業務に関して、該当システムを管掌している部署に対してヒアリングを実施する。2.下記のような内容をヒアリングする。・最低限必要な処理パフォーマンス・他システムとの連携状況3.ヒアリング内容を、全て同じフォーマットの調査用紙に書き込み、後日、比較出来る様にする。4.本作業では、既存システムに関しては、下記の様な資料を作成する。タイミング9)課題一覧:下記アンケート結果記載5.各種マニュアルの有無(操作マニュアル、管理者用マニュアル、等)6.さらに、管掌部署の社員に対して、下記の項目などに関するアンケートも実施する。1)問題点2)要望3)その他(3)クラウド化する業務の絞り込み/決定1.全てのヒアリング結果を検討し、クラウド化出来る業務の絞り込みを行う。2.絞り込んだ結果、複数件がクラウド化の対象となった場合は優先順位を付ける。3.優先順位を付けた順に、クラウド化のメリット/デメリットを洗い出す。4.業務をクラウド化する場合、どのサービス形態のクラウドに移行するのかを検討する。5.該当クラウドに移行する場合の概算費用を算出し、現行運用を続けた場合と比較する。6.また、単にクラウド化の是非を問うだけでなく、社内における地政学的リスクの洗い出しも行う。(4)クラウド化の可否決定1.調査結果を報告書に整理する。2.まずは、プロジェクト・メンバー全員で調査結果の検証を行う。3.最後に、プロジェクト・オーナーを含む全員で検討後、クラウド化を推進するか否かを決定する。4.クラウド化に関して、経営層に報告し、その指示を仰ぐ。続行の場合:該当部署の長に、経営層からクラウド化を進める旨を通達してもらう(5)(クラウド化続行の場合)プロジェクトの見直しを行う1.現行メンバーを一旦解散し、新たにメンバーの見直しを行う。2.クラウド化対象業務部署から、最低2名程度メンバーを出してもらう。(課長クラスと一般社員)3.組織を改変し、該当部署の長をプロジェクト・スポンサー等の責任ある地位に付ける。(6)その他1.今回の業務の棚卸しは、滅多にない良い機会です。2.本来は、クラウド化のための調査ですが、他部署の視点を入れることで業務改善が行える可能性があります。3.本プロジェクト終了後、別プロジェクトを立ち上げて、業務改善を行った方が良いと思います。本フェーズは、業務をクラウド化するための方法を検討し、実際に移行作業を行う方法を設計するフェーズになります。フェーズ3で、クラウド化する業務が決定しますので、フェーズ4以降で、該当業務をクラウドに移行するための作業設計を行います。業務をクラウドに移行するための設計作業としては、次のような作業があります。作成した各種設計書は、単に、作成すれば良い、と言う訳には行きません。関係者全員に承認してもらう必要があります。本プロジェクトに関わらず、全てのプロジェクトにおいては、何かを行った、あるいは何かを作成した場合、必ず、関係者全員に承認させる必要があります。関係者の承認を得ないと、万が一、プロジェクトが失敗した場合、「逃げを打つ」人間が現れますし、自身が承認行為をすることで、プロジェクトへの参加意識も高まります。(1)新規プロジェクトの立ち上げプロジェクト・メンバーが入れ替わりますので、再度、フェーズ2と同様の作業を行う。プロジェクト・メンバーの顔合わせと各種合意形成(ゴール共有)目標4:プロジェクトのキックオフ(2)基本方針作成1.業務のクラウド化で何を実現し、どの様な効果を上げるのかを明確にする。Agreement/サービス品質保証)3.各項目について、例えば「n%削減」とか「n時間で復旧」等と具体的な数値目標を上げる。(3)プロジェクト実行計画書作成プロジェクト実行計画書では、下記項目を明確にする。1.期間やプロジェクト・メンバーの構成と役割2.業務クラウド化の背景と目的3.業務クラウド化の基本的な考え方4.セキュリティ・ポリシー作成5.クラウド化対象業務6.業務をクラウド化した場合の実現イメージ(サービス形態)7.検証設計8.プロジェクト・メンバー、組織図、および役割分担9.クラウド化の工数と費用10.業務クラウド化のスケジュール(4)棚卸し結果の精査1.フェーズ3で実施した「業務の棚卸し結果」を再調査し、細部の漏れを確認する。2.リース期限やライセンス期限の確認を行い、クラウドに移行するタイミングも確定する。(5)クラウド候補選定と非互換調査1.先の「業務の棚卸し」結果を受け、クラウド業者の選択を行う。2.今回の業務システムに、一番相応しいサービス形態を提供している業者を候補として抽出する。3.抽出した業者が提供するサービスと、現行システムとの各種非互換を洗い出す。4.業者を決定し、非互換への対応方法を検討する。(6)調達先決定/仕様調整1.業務委託先を決定する。2.業務委託先を決定した後、後述する作業を、業者と一緒に行う事になる。3.社内と社外の役割分担を決定する。(7)対象業務の再構築/再設計1.現行業務の見直しを行い、非互換への対応を含めクラウド化のための再設計を行う。2.またアンケート結果で不備/要望が上げられた場合、要求事項をクラウド化に取り込む。3.カスタマイズが必要な場合、カスタマイズの関する機能要件を整理する。4.再構築した業務に関して、再度「棚卸し」を行い、フェーズ3と同様の成果物を作成する。5.業務再構築作業に関するスケジュールも確定する。(8)クラウド環境に必要な各種リソース設計1.必要ソフトウェアの選定と決定。2.必要ハードウェアの選定を決定。3.システム構成図の作成。4.セキュリティ・ポリシー5.上記を踏まえたサービスレベルの調査/決定。ネットワークの速度は要注意。(9)システム変更仕様書の作成1.クラウド化に伴い、下記のような変更が入る可能性がある。1)カスタマイズ部分の修正2)既存、あるいは潜在的バグの修正3)アンケート結果の反映(要望対応)2.上記修正部分に関する修正/要望対応設計書を作成する。(10)試験設計書の作成1.システム移行後に実施する、検証試験の試験方法を設計する必要がある。2.該当業務システムに関わる、全ての処理を確認できれば安心だが、期間的に、全処理の確認を行うのは、当然無理である。3.このため、処理サイクルを含め、ある程度、代表的な処理をサンプリング対象として抽出し、この抽出した処理を中心に試験を行う事になると思われる。4.試験対象となる処理を決定したら、次は、該当処理を行うためのデータも準備する必要がある。5.つまり、何を、どうやって、どの位、どのタイミングで、そして、何をもって良しとするのかを試験設計書として整理する必要がある。(11)切り替え手順の設計1.システム移行においては、新システムへの切り替えが必要になります。2.システムの切り替えには、様々な準備が必要になるので、新システム、つまりクラウド側に構築したシステムに切り替える方法を設計します。(12)各種手順書の作成1.環境構築手順書:クラウド側に新たな環境を構築するための手順書を作成する。2.システム移行手順書:社内システムをクラウド環境に移行するための作業手順書を作成する。3.データ移行手順書:システム使用データを移行するための作業手順書を作成する。4.試験手順書:下記2種類の試験手順書を作成し、総合試験の手戻りを減少させる。1)システム/データ移行時に行う簡易的な動作確認試験2)移行作業終了後に行う総合試験5.切り替え手順書:上記で設計したクラウド側システムへの切り替え手順書を作成する。6.スケジュール作成:移行作業のスケジュールを作成する。本フェーズが、実際の移行フェーズになります。移行フェーズでは、次のような作業を行います。(1)契約行為の実施1.クラウドに業務システムを移行するための作業を、一緒に行う業者は既に選定済である。2.ここでは、クラウド環境や各種リソースを提供する業者との契約行為を行う。3.通常の場合、上記1の業者と同一業者である可能性が高い。(2)クラウド環境構築1.業者提供のクラウド環境に業務システムを構築する。2.前フェーズで作成済の環境構築手順書に従い、業務システムが稼働出来る環境を、クラウド環境に移行する。(3)システム改修1.クラウド化に対応するために、既存システムを改修する場合、このタイミング、あるいは上記(2)のタイミングで同時に行う事になる。2.システム改修には、当然、時間が掛かるので、前述の計画段階で、改修に必要な工数を計上する必要がある。(4)システム移行/構築1.前フェーズで作成済のシステム移行手順書に従い、業務システムをクラウド環境に移行する。2.システム改修が必要な場合、上記(3)で改修しておく。3.システム移行が完了した時点で軽い試験を行い、業務システムが、総合試験が行える状況になっている事を確認する。4.何の確認も行わず、そのまま総合試験フェーズに移行すると、手戻りが多発し、総合試験フェーズが破綻する。(5)データ移行1.前フェーズで作成済のデータ移行手順書に従い、業務システムが使うデータをクラウド環境に移行する。2.システム同様、データ移行が完了した時点で軽い試験を行い、業務システムが、総合試験が行える状況になっている事を確認する。3.これもシステム同様、何の確認も行わず、そのまま総合試験フェーズに移行すると、手戻りが多発し、総合試験フェーズが破綻する。4.なお、データ移行はネットワークの速度に依存するので、事前に、どの程度の期間が必要なのかを調査する必要がある。(※数日掛かるケースも存在する。)--------------------------------------------------------------------------------------------------------●フェーズ6:試験稼働システム、およびデータの移行が完了すれば、試験を行う環境が揃いますので、この時点で、総合試験を実施する事になります。試験は、各企業、および業務毎に異なると思いますが、基本的には、下記の内容を確認する事になると思われます。処理サイクルも、前述の様に、企業、および業務の書類により異なるので、前章の「手順書作成」において、自社の業務に相応しい試験手順書(試験設計書)を作成する必要があります。何が、どうなれば想定した処理結果なのか。』を、予め決めておく必要があります。可能であれば、処理結果の判定は、出来る限り、数値を元に「OK/NG」を判定出来るようにする事が望ましいと思います。感覚的に「こんな感じでOK」と判定してしまうと、後日、問題を引き起こす可能性があります。判定結果は、社員全員とまでは行かなくても、大方の社員が、妥当と認める内容にする必要があります。客観的に「OK」なるように評価しないと、次のシステムをクラウドに移行する事が困難になってしまいます。一度、「失敗プロジェクト」の烙印を押されたら、もう次は無いと思った方が良いと思います。試験結果が「OK」となれば、後は、業務をクラウド側に切り替えて、いよいよ本番業務を行う事になります。「試験OK」となったからと言って、そのまま、直ぐにシステム切り替えとはなりません。次の点を確認して下さい。?また、とにかく、人間、特に日本人は、新しい仕組みに抵抗します。何らかの既得権を持っている社員や、既存システムに関する知識を有している社員が居る場合、これらの社員が、必ず「抵抗勢力」となって、システムの切り替えに反発します。日本人は、「総論OK、各論NG」ですので、注意する必要があります。「各論NG」を、言葉巧みに言い換えて「物事は慎重に進めた方が・・・」とか言う人が必ず出てきますので、本ブログに記載したように、ちゃんとプロセスを踏んで作業を行い、結果もOKなら、「今更何を」と言う事になります。プロセスを踏み、その都度、関係者の承認を得て、システムの切り替えに臨むようにして下さい。次に、参考までに、クラウドに適さないと思われる業務を、数ケース紹介しておきます。業務の中断が絶対に許されないシステムは、クラウドの移行対象業務からは、最初から除外した方が良いと思われます。簡単に考えても、下記のような業務システムは、クラウドには適しません。工場等で使われている特殊デバイスと連携しているシステムのクラウド化は難しいと思います。特殊デバイスとしては、次のようなデバイスがあります。XP」をベースとした特殊デバイスを使っていますので、このような特殊環境で稼働するシステムに関しては、クラウド化は難しいと思います。・シーケンサー--------------------------------------------------------------------------------------------------------●ケース3:特殊なプラットフォームを使用しているシステムクラウド環境は、一般的なハードウェアしか想定していません。このため、下記の様な特殊なハードウェアで構成されたプラットフォームで稼働している業務システムは、クラウドには移行出来ないと思われます。・リアルタイムOS--------------------------------------------------------------------------------------------------------●ケース4:機密データを使用しているシステム言わずもがなですが、機密データを取り扱う業務は、クラウドに移行してはいけません。機密データを取り扱い、かつデータ漏洩の可能性が僅かでもあるならば、もうクラウド化は無理だと思った方が良いと思います。機密データが外部に漏洩した場合、会社の継続が難しくなってしまいます。クラウドにしたいのであれば、データを細分化し、機密データの内容が解らなくするとか、あるいは全てを暗号化したデータのみをクラウド環境に移行するか等、細心の注意を払った上で、クラウド化する必要があります。!」等と宣伝しているホームページがありますが、私は、信用出来ません。最初から、業務を決め打ちでクラウド化を進めれば、ある程度、移行工数を減らす事は可能だと思います。常日頃から、「業務の棚卸し」を行っている企業も、比較的、移行には手間は掛からないと思います。・・・上記のような事前準備が何も出来ていない企業で、「さあ、ウチもクラウドだ!」等とホザイている企業は要注意です。経営層がIT系に疎く、コスト削減ばかりに血眼になっている企業は、恐らく、クラウド化プロジェクトは失敗する可能性が高いと思います。「簡単だから」と言うのが口癖の経営者は要注意です。何事も、そんなに簡単には行きません。!」と言いたくなってしまいます。全てが簡単なら、クラウド移行サービスを行う企業は存在出来ません。クラウド移行が複雑で、面倒だからこそ、このようなサービスが成立していることを意識して下さい。次回は、クラウド移行に関して、次のような内容を紹介する予定です。?月別アーカイブはてなブログをはじめよう!msystemさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。