社内システムのクラウド化 〜 皆でクラウドにすれば怖いくないのか ? - その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:事前準備

このフェーズは、実際に、プロジェクトを開始する前段階の作業になります。このため、場合によっては、作業フェーズに組み込まないケースもあるかもしれません。


何らかのプロジェクトを開始する際は、誰かが発起人(オーナー)になり、次の様な事を決める必要があります。


・誰をリーダーにするのか :Who
・誰をプロジェクトに参画させるのか :Who
・プロジェクトの目標(ゴール)は何か :What
・いつ頃までに結論を出すのか :When
・当初の予算は、どの位必要なのか :How much


「5W2H」だと、あと「Where」と「Why」が必要ですが、「Where」は社内、もしくは業者ですし、そもそも、当初は「How(どうやって)」を決める事が作業内容になります。


また、この段階では、全ての予算や期間も明確にする事は出来ません。


この「クラウド化」のプロジェクトは、前述の通り、大きくは次の2つのフェーズに分かれています。


(1)調査検討フェーズ:既存システムの調査分析を行い、クラウド化を推進するか否かを決定する
(2)移行導入フェーズ:クラウド化を推進する事が決定した場合に、実際に移行作業を行う


当初は「調査検討フェーズ」だけを行い、その結果を踏まえて、「クラウド化を推進するか否か」を決める事になりますので、(2)のプロジェクト・フェーズは、上記(1)の結果次第と言う事になります。


このため、予算や期間は、(1)のプロジェクトのみを、本フェーズ以降で決める事になります。

--------------------------------------------------------------------------------------------------------

●フェーズ2:計画立案

このフェーズも、まだ計画段階の作業です。


フェーズ2は、フェーズ1の事前準備を受け、フェーズ1で選ばれたプロジェクト・オーナー、あるいはプロジェクト・リーダーが、次のような作業を行います。


1.プロジェクトに参加人員の決定 :Who
2.プロジェクト参加者の役割分担決定 :Why、How
3.プロジェクトの組織図決定 :Where
4.プロジェクトの期間と予算の決定 :When、How much
5.プロジェクト遂行に必要なりソース確保 :How、How much


つまり、このフェーズ2では、フェーズ1の内容を、より具体的に詰めて、プロジェクトを開始する事が出来る状態まで持って行く事を目的にしたフェーズとなります。


このため、フェーズ2の目標は、次の3つになります。


目標1 : プロジェクト実行計画書の作成(上記①〜⑤の整理)
目標2 : プロジェクト・メンバーの顔合わせと各種合意形成(ゴール共有)
目標3 :プロジェクトのキックオフ


フェーズ2の最終目的は、キックオフを開催してプロジェクトを始動させることです。


そして、キックオフにおいては、プロジェクトのゴール、およびメンバー各自の役割を認識共有する必要ありますので、そのために必要な各種資料を作成する必要があります。


なお、この段階では、社内に複数存在するシステムの内、どのシステムをクラウド化するのかは決定していないので、参加させるメンバーとしては、社内全部署の部長クラスを招集し、今後に行われる調査作業への協力を取り付ける必要があります。


このような下準備、いわゆる「根回し」をしておかないと、後々、「そんな事は聞いていない !」と反対勢力になってしまいますので、最初から各部署の「長」を、プロジェクトに参画させる必要があります。

--------------------------------------------------------------------------------------------------------

●フェーズ3:導入検討


フェーズ3からが、実際の作業になります。


このフェーズ3において、フェーズ4以降に行う、「システムのクラウド化」を行うか、あるいは中止するかの判断を下す事になります。


このフェーズ3で、「社内システムのクラウド化は行う必要が無い。」と言う結論になれば、フェーズ4以降の作業は行う必要は無くなります。


このため、このフェーズ3は、会社の今後を決定する一番重要な作業フェーズになります。


このフェーズで、誤った決断を下してしまうと、会社に莫大な損害を与えてしまいますので、慎重に作業を進め、最後に下す判断も、偏った判断ではなく、中立公平な判断が必要になります。


そして、このフェーズ3では、主に次のような作業を行う事になります。


(1)クラウド対象とする業務の候補選定

1.全ての業務を、一括してクラウド化する事は出来ません。
2.次のような観点で、クラウド化出来る業務を選定します。
クラウド化する事で費用対効果が上がる業務
クラウド化する事で、現在抱えている問題を解決する事が出来る業務
クラウド化に際し、カスタマイズの観点から、移行が容易に出来る業務
クラウド化で業務運用に問題が起きない業務(長時間の業務停止にも耐えられる業務)
クラウドに移行してもセキュリティ上、問題のない業務


(2)クラウド化候補となった業務の棚卸し

1.選定業務に関して、該当システムを管掌している部署に対してヒアリングを実施する。
2.下記のような内容をヒアリングする。
・業務の作業手順や作業内容
・使用しているデータの種類や量
・カスタマイズ状況
・現状の問題点
・該当業務システムで使っているソフトウェアのライセンス、費用、期限、および調達先、等
・該当システムで使っているハードウェアの洗い出し(種類/数/費用/リース期限/調達先、等)
・該当システムで出力している帳票の種類
・該当システムを維持するために必要な経費
・最低限必要な処理パフォーマンス
・他システムとの連携状況
3.ヒアリング内容を、全て同じフォーマットの調査用紙に書き込み、後日、比較出来る様にする。
4.本作業では、既存システムに関しては、下記の様な資料を作成する。
1)業務一覧 :業務名、業務カテゴリー、業務内容、管掌部署
2)業務フロー図 :業務の流れ、作業時間、他システムとの連携の有無
3)機能一覧 :機能名称、機能概要
4)画面一覧 :画面名称、表示項目、項目説明、画面フロー
5)帳票一覧 :帳票名称、出力項目、項目説明、帳票利用者、出力タイミング、出力枚数
6)データ一覧 :ファイル名、項目一覧、項目説明、型、桁数、件数、量
7)連携システム一覧 :連携システム名称、連携方法、連携タイミング
8)保守作業一覧 :保守内容、担当者、保守タイミング
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.本プロジェクト終了後、別プロジェクトを立ち上げて、業務改善を行った方が良いと思います。

--------------------------------------------------------------------------------------------------------

●フェーズ4:移行設計


本フェーズは、業務をクラウド化するための方法を検討し、実際に移行作業を行う方法を設計するフェーズになります。。


フェーズ3で、クラウド化する業務が決定しますので、フェーズ4以降で、該当業務をクラウドに移行するための作業設計を行います。業務をクラウドに移行するための設計作業としては、次のような作業があります。


なお、作成した各種設計書は、単に、作成すれば良い、と言う訳には行きません。必ず、関係者全員に承認してもらう必要があります。


本プロジェクトに関わらず、全てのプロジェクトにおいては、何かを行った、あるいは何かを作成した場合、必ず、関係者全員に承認させる必要があります。


関係者の承認を得ないと、万が一、プロジェクトが失敗した場合、「逃げを打つ」人間が現れますし、自身が承認行為をすることで、プロジェクトへの参加意識も高まります。


(1)新規プロジェクトの立ち上げ

プロジェクト・メンバーが入れ替わりますので、再度、フェーズ2と同様の作業を行う。
目標1 : 基本方針作成
目標2 :プロジェクト実行計画書の作成
目標3 : プロジェクト・メンバーの顔合わせと各種合意形成(ゴール共有)
目標4 :プロジェクトのキックオフ


(2)基本方針作成

1.業務のクラウド化で何を実現し、どの様な効果を上げるのかを明確にする。
2.実現目標の項目としては、次の項目が考えられる
1)運用コスト削減
2)災害対応実現
3)利用部門へのSLA項目/数値の提示(SLA:Service Level 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.スケジュール作成 :移行作業のスケジュールを作成する。

--------------------------------------------------------------------------------------------------------

●フェーズ5:移行作業


本フェーズが、実際の移行フェーズになります。移行フェーズでは、次のような作業を行います。


(1)契約行為の実施

1.クラウドに業務システムを移行するための作業を、一緒に行う業者は既に選定済である。
2.ここでは、クラウド環境や各種リソースを提供する業者との契約行為を行う。
3.通常の場合、上記①の業者と同一業者である可能性が高い。


(2)クラウド環境構築

1.業者提供のクラウド環境に業務システムを構築する。
2.前フェーズで作成済の環境構築手順書に従い、業務システムが稼働出来る環境を、クラウド環境に移行する。


(3)システム改修

1.クラウド化に対応するために、既存システムを改修する場合、このタイミング、あるいは上記(2)のタイミングで同時に行う事になる。
2.システム改修には、当然、時間が掛かるので、前述の計画段階で、改修に必要な工数を計上する必要がある。


(4)システム移行/構築

1.前フェーズで作成済のシステム移行手順書に従い、業務システムをクラウド環境に移行する。
2.システム改修が必要な場合、上記(3)で改修しておく。
3.システム移行が完了した時点で軽い試験を行い、業務システムが、総合試験が行える状況になっている事を確認する。
4.何の確認も行わず、そのまま総合試験フェーズに移行すると、手戻りが多発し、総合試験フェーズが破綻する。


(5)データ移行

1.前フェーズで作成済のデータ移行手順書に従い、業務システムが使うデータをクラウド環境に移行する。
2.システム同様、データ移行が完了した時点で軽い試験を行い、業務システムが、総合試験が行える状況になっている事を確認する。
3.これもシステム同様、何の確認も行わず、そのまま総合試験フェーズに移行すると、手戻りが多発し、総合試験フェーズが破綻する。
4.なお、データ移行はネットワークの速度に依存するので、事前に、どの程度の期間が必要なのかを調査する必要がある。(※数日掛かるケースも存在する。)

--------------------------------------------------------------------------------------------------------

●フェーズ6:試験稼働


システム、およびデータの移行が完了すれば、試験を行う環境が揃いますので、この時点で、総合試験を実施する事になります。


しかし、試験は、各企業、および業務毎に異なると思いますが、基本的には、下記の内容を確認する事になると思われます。


(1)業務処理結果の確認
(2)業務処理時間(処理速度)の確認
(3)障害発生時のリカバリー方法の確認
(4)ネットワーク接続/速度、およびIPアドレス重複の確認
(5)各種操作方法の確認


試験は、当然、1回実施すれば良い訳ではなく、次のような業務サイクルを意識して複数回実施する必要があります。


・日次処理
・月次処理
・年次処理
・決済処理、等


業務の処理サイクルも、前述の様に、企業、および業務の書類により異なるので、前章の「手順書作成」において、自社の業務に相応しい試験手順書(試験設計書)を作成する必要があります。

--------------------------------------------------------------------------------------------------------

●フェーズ7:結果評価


試験が終われば、次は、試験結果の評価となりますが、これも、前章の「移行設計」フェーズにおいて、『 何が、どうなれば想定した処理結果なのか。 』を、予め決めておく必要があります。


また、可能であれば、処理結果の判定は、出来る限り、数値を元に「OK/NG」を判定出来るようにする事が望ましいと思います。


感覚的に「こんな感じでOK」と判定してしまうと、後日、問題を引き起こす可能性があります。


判定結果は、社員全員とまでは行かなくても、大方の社員が、妥当と認める内容にする必要があります。


客観的に「OK」なるように評価しないと、次のシステムをクラウドに移行する事が困難になってしまいます。一度、「失敗プロジェクト」の烙印を押されたら、もう次は無いと思った方が良いと思います。

--------------------------------------------------------------------------------------------------------

●フェーズ8:本番開始


試験結果が「OK」となれば、後は、業務をクラウド側に切り替えて、いよいよ本番業務を行う事になります。


しかし、「試験OK」となったからと言って、そのまま、直ぐにシステム切り替えとはなりません。次の点を確認して下さい。


・試験結果OKの承認は、誰が出したのか ?
・経営層から、(口約束ではない)正式に承認を得ているのか ?
・管掌部署の承認は得ているのか ?
・管掌部署の社員は、切り替えを認めているのか ?
・システム切り替えタイミングは確認したのか ?


また、とにかく、人間、特に日本人は、新しい仕組みに抵抗します。


さらに、何らかの既得権を持っている社員や、既存システムに関する知識を有している社員が居る場合、これらの社員が、必ず「抵抗勢力」となって、システムの切り替えに反発します。


日本人は、「総論OK、各論NG」ですので、注意する必要があります。


「各論NG」を、言葉巧みに言い換えて「物事は慎重に進めた方が・・・」とか言う人が必ず出てきますので、本ブログに記載したように、ちゃんとプロセスを踏んで作業を行い、結果もOKなら、「今更何を」と言う事になります。


ちゃんとプロセスを踏み、その都度、関係者の承認を得て、システムの切り替えに臨むようにして下さい。

--------------------------------------------------------------------------------------------------------

クラウドに適さない業務


次に、参考までに、クラウドに適さないと思われる業務を、数ケース紹介しておきます。

--------------------------------------------------------------------------------------------------------


●ケース1:クリティカルミッション業務

業務の中断が絶対に許されないシステムは、クラウドの移行対象業務からは、最初から除外した方が良いと思われます。簡単に考えても、下記のような業務システムは、クラウドには適しません。


・インフラ制御用業務システム(電気/ガス/水道)
・金融機関のオンラインシステム
・交通制御用システム(信号/航空機管制/鉄道)

--------------------------------------------------------------------------------------------------------

●ケース2:特殊デバイス使用業務

工場等で使われている特殊デバイスと連携しているシステムのクラウド化は難しいと思います。特殊デバイスとしては、次のようなデバイスがあります。


そもそも、工場や倉庫などでは、未だに、「Windows XP」をベースとした特殊デバイスを使っていますので、このような特殊環境で稼働するシステムに関しては、クラウド化は難しいと思います。


・ハンディースキャナー
・温度/湿度制御装置
シーケンサー

--------------------------------------------------------------------------------------------------------

●ケース3:特殊なプラットフォームを使用しているシステム

クラウド環境は、一般的なハードウェアしか想定していません。


このため、下記の様な特殊なハードウェアで構成されたプラットフォームで稼働している業務システムは、クラウドには移行出来ないと思われます。


・無停止サーバー
クラスタリング・サーバー
リアルタイムOS

--------------------------------------------------------------------------------------------------------

●ケース4:機密データを使用しているシステム

言わずもがなですが、機密データを取り扱う業務は、クラウドに移行してはいけません。


機密データを取り扱い、かつデータ漏洩の可能性が僅かでもあるならば、もうクラウド化は無理だと思った方が良いと思います。


機密データが外部に漏洩した場合、会社の継続が難しくなってしまいます。


どうしもクラウドにしたいのであれば、データを細分化し、機密データの内容が解らなくするとか、あるいは全てを暗号化したデータのみをクラウド環境に移行するか等、細心の注意を払った上で、クラウド化する必要があります。

--------------------------------------------------------------------------------------------------------

今回、「クラウドサービス」に関して、次のような内容を紹介しましたが、如何でしたか ?


クラウド導入までの全体の流れ
クラウドに適さない業務


「社内システムをクラウドに !」と、言葉では簡単に言いますが、実際は、凄い作業があることは理解できましたか ?


よく、クラウドサービスを提供している業者のサイトで、「3ヶ月間でクラウド移行成功 !」等と宣伝しているホームページがありますが、私は、信用出来ません。


最初から、業務を決め打ちでクラウド化を進めれば、ある程度、移行工数を減らす事は可能だと思います。


さらに、常日頃から、「業務の棚卸し」を行っている企業も、比較的、移行には手間は掛からないと思います。


しかし・・・上記のような事前準備が何も出来ていない企業で、「さあ、ウチもクラウドだ!」等とホザイている企業は要注意です。


特に、経営層がIT系に疎く、コスト削減ばかりに血眼になっている企業は、恐らく、クラウド化プロジェクトは失敗する可能性が高いと思います。


「簡単だから」と言うのが口癖の経営者は要注意です。何事も、そんなに簡単には行きません。


システム開発も同様ですが、「簡単なら自分で作ってみろ !」と言いたくなってしまいます。


全てが簡単なら、クラウド移行サービスを行う企業は存在出来ません。クラウド移行が複雑で、面倒だからこそ、このようなサービスが成立していることを意識して下さい。


次回は、クラウド移行に関して、次のような内容を紹介する予定です。


●コスト削減手段としてのクラウド
●本番カットオーバーまでの時間短縮としてのクラウド
クラウドによる本番業務カットオーバー後の問題


それでは、次回も宜しくお願いします。

以上

【画像・情報提供先】
Wikipedia(http://ja.wikipedia.org/)
PC Watchhttps://pc.watch.impress.co.jp/
・ボクシルマガジン(https://boxil.jp/mag/)