クラウドの失敗例, 代表的なクラウド移行例

Owned by Kohei Nishikawa
Last updated: Apr 24, 2024
4 min read

クラウドコンピューティングは成功例が多く公開されているものの、失敗例はほぼ公開されていないため、経験（やらかし）を踏まえて、ありがちの失敗例を見ていきましょう。

システム設計や開発の基本として、「何かを足したら、何かを引く、バランスを保つ」ことがあげられます。

目次

失敗例

システム設計が関係するもの

クラウド移行後に、想定以上のコストが生じた場合

自分たちでハードウェアを保有する「オンプレミス」から「パブリッククラウド型のIaaS」に移行した場合に生じやすいケース。

オンプレミス運用時の意識

リソースのうち、ネットワークI/Oを稼働中に計測することはほぼありません。
なせならば、オンプレミス型では、自社内で動いており、ネットワーク関係を気にする必要がないこと、CPUやメモリなども想定するリソースよりも多めに見積もり、サーバー等のハードウェアを調達（購入）するため、想定範囲に収まっていれば良いためです。

パブリッククラウド型のIaaSの場合

見落としがちの要素として、ネットワークI/Oコストがあります。

IaaS上でVM（仮想マシン）を用いた構成で見ていく。シンプルな構成として、AWS上で２つのアプリケーションがそれぞれのサーバーで稼働しており、ロードバランサーを用いて２つのアプリケーションへのアクセスを振り分けている構成とする。

この時、点線の矢印をInbound（エンドユーザーからAWS上のVMへのアクセス）、実線の矢印をOutbound（Inboundへのレスポンスとして、AWS上のVMからエンドユーザーにデータ表示などの処理結果を返す通信）としている。
AWSのVMであるEC2には、ストレージがないので、EBSと呼ばれるストレージをEC2に接続して利用する。EC2上で使用データはEBSに格納される。S3は、EC2やEBSのバックアップを保管するストレージとして用いる。エンドユーザーから、アプリケーションへのアクセスは、ALB（ロードバランサー）を用いてどのEC2に接続するか制御している。Private subnetにあるEC2上のVMがインターネットに出るには、NAT Gatewayを経由する必要がある。この構成における課金は、次のようになる。

使用しているAWSの各機能

  • Internet Gateway x 1

  • AZ（Availability Zone）x 1

  • VPC x 1

  • Public Subnet x 1

  • Private Subnet x 1

  • ALB（Application Load Balancer） x 1

  • NAT Gateway x 1

  • EC2 x 2

  • EBS x 2

  • S3 x 1

EC2、EBS、S3は、使っていれば課金されるので、クラウドについて不慣れな人が見落としやすいネットワーク関係を中心に見ていこう。
ネットワーク関係で無料となるものは、Internet Gatewayにおけるインバウンド通信、VPC、サブネット（Public Subnet / Private Subnet）である。

Inbound（インバウンド）通信の課金要素

  • ALBの利用料

  • ALBを通過した際の転送受信料

Outbound（アウトバウンド）通信の課金要素

  • アウトバウンド通信時のインターネット転送料

  • NAT Gatewayの利用料

  • NAT Gatewayのデータ処理料

また、AZ（Availability Zone）は、複数のAZを使っている場合に、異なるAZ間またいだ通信で課金される。もし、VPN経由で接続したい場合も追加費用が生じる。
このように、ネットワークを立ち上げているだけでも課金されることがわかる。AWS以外、たとえばIBMやOracleのIaaSでは、このネットワーク関係は無料枠が設定されている。シェアが多い、事例が多いといったことでAWSを選んだ場合にAWSについて基礎知識を身に着けていれば、どのようなコストが生じるか想定することは簡単なことであるが、基礎知識がなければ想定外のコストが生じることになる。

SNS等でバズって急激なアクセスの結果、莫大な費用を請求される場合も、このケースである。

運用開始前の設計・構築に想定以上の時間がかかった場合

CPUアーキテクチャの不一致

汎用機（オフコン）で、AS/400を使って動かしている基幹システムを、クラウドに移行する際に、IBM Cloudではなく、AWSを採用しようとしたケース。AS/400は、10年や15年の規模で動かし続けてもエラーなしの実績がある。これをAWSに持っていく場合、CPUアーキテクチャが異なるため、クラウド環境の設計・構築に想定外の時間を要するといったことで失敗になることがある。

上記のケースでは、AS/400と同じCPUアーキテクチャを持つ、IBM Cloud Power Systems Virtual Server を選定すべきである。
異なるアーキテクチャに作り変える覚悟を持って取り組み、AWS等に移行した例も存在するが、在庫の照会画面が今までは２秒で出たのに、新システムにしたら20秒かかったとなり、クレームが起きるような事態になることもある。つまり、クラウド移行前のアーキテクチャを把握し、クラウド移行を行うのであれば、最適なクラウドサービスを選ぶことが必要で、CPUアーキテクチャが不一致になるケースでは、あえてクラウド移行を行わない提案をすべきである。

選定したクラウドサービスに不慣れな場合

この例は、「SaaS」「PaaS」「IaaS」のどれを選んでも生じます。クラウドサービスごとに異なる制限値が設けられています。オンプレミス型の業務システムでは、大量のデータ処理のために毎朝バッチ処理を行っていたが、選定したクラウドサービスでは、バッチ処理ができないといったケースです。選定したクラウドサービスについて不慣れであるために生じると言えます。

セキュリティ対策の不備

LACが発行している「サイバー救急センターレポート第8号」で取り上げられていた例では、AWSへのアクセスキーが漏洩したていたことで、攻撃者がアクセスキーを使い、大量のサーバーを起動し、高額請求となったものがあります。毎月数万円の請求が、数百万円の請求になるケースになります。

アクセスキーを複数人で広範囲に使い回している場合、特に１つの会社だけでなく、協力会社等含めた広範囲となる場合は、情報漏洩が起きやすく注意が必要です。SSH踏み台サーバーを用いた構成にしておくことで、防げた可能性があります。

システム移行に時間がかかった場合

旧システムからの完全移行が終わらず、長期に渡って、旧システムと新システムが同時運用し続けている場合

クラウド上で稼働する新システムが完成したにも関わらず、組織内での周知不足や対象利用者向けのトレーニング不足により、旧システムにもデータを入れ続けている場合に生じます。

この結果、いつまで経っても旧システムと新システムの２つを動かす必要があり、想定以上の期間が生じるため人件費が重なり、新システムへの移行を断念し、骨折り損のくたびれ儲けに終わることがあります。たとえば、取り扱うデータ量が多く、新システムの移行期間終了後に、旧システムの利用を止めにくい場合に生じやすい。見た目や使い勝手が変わる場合は、特に。

  • メールサーバー

    • 1GB程度の転送(旧システム >> 新システム）の移行時間は、1時間程度

  • スケジュール管理

    • 過去の予定も移行するように求めてくることがある。

  • 業務用データベースなど

システム構築の際には、必ず旧システムからのデータ移行計画を立て、上記のようにならないことをコントロールすることもシステムエンジニアやクラウドエンジニアの仕事です。

運用開始後、しばらくしてクラウドサービスが終了してしまい、結果として移行が完了できなかった場合

基本機能を徹底的に活用していない場合

こちらは、「SaaS」や「PaaS」で生じることが多いケースです。
例えば、Salesforceには、見積もり機能や取引先の企業情報、クレーム等を管理するテーブル（Salesforceではオブジェクトと言う）が用意されています。こうした基本機能が用意されているにも関わらず、同様の機能を一から作る行為、いわゆる「車輪の再発明」を行う場合、クラウドサービスの本来の性能を発揮できずに、追加のオプション費用を多数支払うことになり、コスト削減は達成できませんし、業績アップのための機能として期待していたものも利用できなくなります。

https://www.salesforce.com/jp/resources/articles/crm/how-to-use-salesforce/

本来の目的にそぐわない設計をした場合

データ処理の要求があった時のみコンピュータを動かすイベントドリブンで、サーバーレスを適用すればコスト削減かつ低コストで済むところを、過去の成功体験から仮想マシンでの運用にこだわった結果、高コストになってしまったケース。経験のない技術だからといって忌避すると、目的は達成できても、想定外のコスト増を招くことになる。

クラウドエンジニアは、数多あるクラウドサービスから、利用者に最適なクラウドサービスの組み合わせや、既存システムの連携を導き出し、ガイドしていく、シェルパ（登山ガイド）のような役割を担うことになります。シェルパであることを求められるがゆえに、クラウドエンジニアは、日々の情報収集や手を動かして実際に確認するといった行動が必要不可欠である。

人が関係するもの

今までのやり方を新システムにあわせて最適化していない場合

システムを新しくすることで、今までのやり方を100%踏襲(とうしゅう)することは難しく、仕事のやり方を変更することが求められる。

例えば、

この場合、役職者が接待ゴルフであろうと、会食で高級ディナーを食べていようと、有給休暇でバカンス中であろうと社内の承認申請に対応する必要がある。新システムでクラウドサービスを採用する場合、こうした従来のやり方を受け入れる必要があり、新システムの構築にあたっては、仕事のやり方を変えることについて、事前調整が必要である。

上記を実際に構築し、導入した際には、部下を多数持つ役職者からは、「仕事のためとはいえバカンス中でも承認しなければならないことは気が滅入る。」との声があり、年末年始大晦日元日出勤の一般社員からは、「大晦日や元日であっても承認申請ができるので、業務生産性が向上した。」といった正反対の声を得ることができた。病院や運送業、小売業のように、大晦日や元日であっても働かないといけない現代社会の問題点については、別の機会に触れていただきたい。

定着に向けたサポート体制が、組織内にない場合

従来と異なる仕組みを導入する場合、利用者からの問い合わせが、新システム担当に集中しがちです。ノンフィクションで申し上げれば、筆者が導入を担当したプロジェクトにおいて、とある山陰地方のお客様からの問い合わせ電話で、朝出勤してから5時間ひっきりなしに拘束されたことがあります。

このように、クラウドサービスに限らず、システム定着のために、システムを利用する組織内にサポート体制を整えることが失敗した場合、利用企業内にサポート体制が整うまでの間、長時間の電話や飛行機で長距離出張などによるサポートが必要となることから、多くのクラウドサービスでは、利用組織内に定着化のためのサポート組織を事前に設置することを推奨しています。従って、利用組織内におけるサポート組織を作り、育成することも、クラウドエンジニアの仕事の１つです。クラウドエンジニアには、プログラミングを行う仕事以外に、こうしたカスタマーサポート・カスタマーサクセスの仕事も求められます。

<< 著名な女性エンジニアの１人である戸倉さん。

導入さえすれば、業績が伸びると思っている場合

システムはあくまで、ビジネスの情報共有と可視化、ノウハウの共有に使われます。従って、IT(情報技術)やDT(デジタル技術)に不慣れな人であっても積極的に使っていくことが非常に重要です。一部の人が使うだけでは効果が出ず、結果としてクラウド導入は失敗となり、主導したクラウドエンジニアは失敗の責任を負うことになります。

こうした事態を防ぐためにも、定着に向けたサポート体制の充実が必要になります。

成功例

成功例については、クラウドサービスを提供する各社で公開されている事例があります。

クラウド移行例：表計算ソフト >> Salesforce（セールスフォース）

表計算ソフトウェア（Excelなど)や、パソコン上で動くデータベースソフトウェア（Accessなど)を使っている場合、間違った情報があると誰が変更したか分からず、組織内で情報共有すると、いったいどれが最新の情報であるか混乱しがちです。誰が変更したか追跡できないということは、間違った情報を修正し難いため、リモートワークにも向いていません。
表計算ソフトウェアには、顧客情報、商談情報、お客様からのクレーム情報、将来的に契約してくれそうなリード(見込み)顧客情報など、さまざまな情報が蓄積されています。

このようなケースで、クラウドコンピューティングに移行する例として、Salesforce の導入があります。たとえば、表計算ソフトウェアで行っていた業務を、Salesforceに移行した結果、毎月200～300時間の削減に成功したような事例があります。
は、クラウドコンピューティングにおける、SaaSおよびPaaSに該当し、クラウドコンピューティングにおいて著名なサービスの1つです。学習や開発環境として、Developer Editionがあります。

Salesforce Developer Edition のアカウント登録

<< こちらにアクセスし、Developer Editionのアカウント登録を行います。

表計算ソフトウェアでありがちな、顧客情報やトラブル情報をSalesforceに登録してみよう

この章では、顧客情報の登録と、トラブルやクレーム情報を登録するところまでを実施してみましょう。

トラブルやクレーム情報を管理する「ケース」機能で、自分で対応を終了（クローズ）できる設定に変更

Salesforceにログイン後、画面右上の歯車のアイコンをクリックした後、「設定」をクリックします。

下図のように、クイック検索の欄に「サポート設定」と入力し、自動で検索されます。表示される「サポート設定」をクリックします。

「サポート設定」画面が表示されます。「編集」をクリックします。

「クローズケースの状況項目を表示」と「ケースフィードアクションおよびフィード項目を有効化」の２つにチェックが入った状態にします。

「保存」をクリックします。

サービスクラウドにアクセス

画面左上の「アプリケーションランチャー（点が9つ固まってるアイコン）」をクリックし、次に「サービス」をクリックします。

顧客情報やケースと呼ばれる、トラブルやクレームを管理する画面が表示されます。

顧客情報の登録

「取引先（企業情報）」の登録

画面上部の「取引先」をクリックします。「取引先」は、顧客が所属している組織情報のことです。企業名、自治体名、学校名などのことです。

画面右端の「新規」をクリックします。

企業情報を入力します。最低限、企業名を入れる必要があります。今回は、東亜重工株式会社としました。従業員数や住所情報も入力し、「保存」をクリックします。

「取引先」情報として、東亜重工株式会社という企業データが作成されました。

「取引先責任者（担当者情報）」の登録

次は企業内の担当者情報を作成するため、「新規取引先責任者」をクリックします。Salesforceでは、顧客情報は、「取引先」と「取引先責任者」という２つのオブジェクト（※1）で構成されています。
※1 Salesforceでは、データベースで言うところのテーブルを「オブジェクト」と言います。

担当者情報を入力します。名刺で言えば、組織名を除いた人物情報になります。例として、次のように入力します。入力後、「保存」をクリックします。

「取引先責任者」情報として、竹内健一 氏 が登録されました。下図のように「取引先」に登録されている「東亜重工株式会社」の画面に表示されます。

画面に表示されている名前（竹内健一）をクリックします。「取引先責任者」に作成された、担当者情報の画面が表示されます。

トラブルやクレーム情報の管理

トラブルやクレーム情報は、Salesforceでは「ケース」に登録し、対応状況を管理します。

「ケース」の登録

「ケース」では、トラブルやクレーム情報を扱います。次は、「新規ケース」をクリックします。

別の方法としては、画面上部で「ケース」タブをクリックし、その後、画面右端の「新規」をクリックする方法もあります。トラブルやクレーム情報には必ず、トラブルやクレーム情報を連絡してきた人物や、起きている企業名が入りますので、「取引先」や「取引先責任者」の画面から作成するとわかりやすいでしょう。

下図のように入力します。「取引先責任者名」の欄は、クリックすると、候補が表示されます。「状況」はNewのまま、あとは「件名」と「説明」を入力した後、「保存」をクリックします。

「取引先責任者」内の担当者情報（竹内健一）の画面に、作成したケース情報が表示されます。下図では、「ケース(1)」に表示されています。

ケース番号 として、00001026 が表示されています。ケース番号 は、各自で異なることがあります。ケース番号 をクリックします。作成したケース情報が表示されます。

新規ToDoの登録

画面内の「関連」タブをクリックします。「新規ToDo」をクリックします。

下図のように、「ケース」に登録したトラブル情報に対する、ToDo を作成します。入力後、「保存」をクリックします。

活動予定として、登録したToDoが表示されています。

「ケース」の「状況」を変更

画面右側の「詳細」にて、「状況」の項目に表示されている「ペン型アイコン」をクリックします。

「状況」の値を「Working」に変更、また「発生源」の値を「Phone」に変更し、「保存」をクリックします。

これで、ケースの画面に、「状況」に「Working」と表示され、トラブルに対応中となります。

「ToDo」を変更

「活動予定」に登録してあるToDoの件名をクリックしましょう。ここでは、「客先にて現状確認」をクリックします。ToDoが表示されます。

ToDoの画面内で、「状況」の項目に表示されている「ペン型アイコン」をクリックします。作業が終わったとして、「状況」を「Completed」にしましょう。「保存」をクリックします。

「ToDo」が変更されました。「関連先」に表示されているケース番号をクリックすることで、ケース画面に戻ります。

「ケース」の「状況」をクローズ

画面右側の「詳細」にて、「状況」の項目に表示されている「ペン型アイコン」をクリックし、「状況」を「Closed」に変更し、「保存」をクリックします。

状況が「Closed」になれば、トラブルやクレームが終了したという意味になります。

「ケース」の一覧を表示

画面上部のタブで「ケース」をクリックします。「▼」をクリックし、「最近参照したデータ」を選びます。

自分がアクセスした「ケース」の一覧が表示されています。ケース番号をクリックすることで、登録済みのケース情報が表示されます。

レポートの確認

「レポート」は、Salesforce内に登録されている各データを表形式で表示することができます。画面上部の「レポート」タブをクリックします。

レポートの作成

画面右端の「新規レポート」をクリックします。

「カテゴリ」に「カスタマーサポートレポート」を選択、「レポートタイプ」に「ケース」、詳細に「レポートを開始」をクリックします。

「保存&実行」をクリックします。

「レポート名」を入力し、「保存」をクリックします。

レポートが作成されました。表の中で、▼をクリックすることで、並び替えができます。「編集」をクリックすれば、レポートで表示する項目を変更したり、条件をつけて絞り込むこともできます。

レポートのエクスポート

レポートの画面右上、「編集」の隣の「▼」をクリックし、「エクスポート」をクリックします。

「エクスポートビュー」では、デフォルトで「フォーマット済みレポート」が選ばれています。「形式」は「Excel形式（xlsx）」とし、「エクスポート」をクリックします。

Excel形式でダウンロードが始まります。ダウンロードしたExcel形式のファイルを開いてみましょう。Excelが起動し、ダウンロードしたレポートが表示されます。

参考資料 : オンライン学習でSalesforceを学ぶ、独自アプリを作って収益を得る方法を学ぶ

  • Salesforce オンライン学習

    • ケースを含めたService Cloud について学ぶ >>

    • Salesforce 開発について学び、独自アプリ開発を始める >>

    • 独自アプリを公開し、収益を得る方法について学ぶ >>

表計算ソフトウェアからの移行で似たもの

Pleasanter ：