再生請負人が見た クラウド移行で失敗する会社の共通点
- 7 時間前
- 読了時間: 6分
はじめに
「クラウド移行に失敗しました。」そう聞くと、多くの人は技術的な問題を想像します。
Azureの設定ミス
AWSの設計ミス
ネットワーク構成の不備
セキュリティ設定の漏れ
しかし、私がこれまで携わってきたクラウド移行案件では少し違いました。
自動車業界。電力業界。インフラ更改案件。システム移行案件。
そこで見てきた多くの失敗案件には、ある共通点があります。
それは、クラウド移行は技術で失敗していないということです。
本当に失敗しているのは、組織と意思決定です。
私はこれまで数多くの再建案件に関わってきましたが、クラウドそのものが原因で失敗した案件はほとんどありませんでした。
クラウドはすでに成熟している
現在のクラウドサービスは非常に成熟しています。
Microsoft Azure
Amazon Web Services（AWS）
Oracle Cloud Infrastructure（OCI）
Google Cloud Platform（GCP）
いずれも世界中で利用されています。
技術そのものに大きな問題があるのであれば、多くの企業が利用を継続できません。
もちろん障害はあります。設計ミスもあります。
しかし、それだけでプロジェクト全体が崩壊することは少ないのです。
本当に危険なのは、クラウドを導入する組織側の準備不足です。
クラウド移行で失敗する会社の共通点
私が再建案件の現場で見てきた失敗要因は、驚くほど似ています。
現行システムを理解していない
「クラウドへ移行しましょう。」話は簡単です。しかし、
どのサーバが何をしているのか
誰が利用しているのか
他システムとどう連携しているのか
これを正確に把握できていない会社は少なくありません。
結果として、移行後に「その連携が止まるとは思わなかった」という事態が発生します。
クラウドが悪いのではありません。現行調査が不足していたのです。
責任分界点が曖昧
クラウド移行では多くの関係者が登場します。
顧客
SIer
クラウドベンダー
ネットワーク担当
セキュリティ担当
運用担当
そして問題が起きると、「それは私たちの担当ではありません」が始まります。
誰が、決めるのか。責任を持つのか。最終判断するのか。
これが曖昧なまま進んだ案件は高確率で炎上します。
ベンダー間の調整不足
関連記事
以前の記事でもお話ししました。ベンダーが増えるほど、ベンダーコントロールは難しくなります。
クラウド移行案件も同じです。例えば、アプリ担当はアプリしか見ていない。
ネットワーク担当はネットワークしか見ていない。運用担当は運用しか見ていない。
すると、誰も全体を見なくなります。
クラウド移行に失敗する原因の多くは、技術ではなく全体最適の欠如です。
AzureでもAWSでも失敗パターンは同じ
よく「Azureだから難しい」「AWSだから失敗した」という話を聞きます。
私はそうは思いません。クラウドが変わっても失敗パターンは同じです。
成功する案件
現行調査ができている
責任分界点が明確
判断者が明確
課題を隠さない
早期にリスク共有する
失敗する案件
現状を把握していない
判断者がいない
問題を隠す
ベンダー間で責任転嫁する
なんとなく進める
失敗の原因はクラウドサービスではありません。組織運営です。
運用移行を軽視する会社
クラウド移行で特に多いのが、運用設計の軽視です。
多くの会社は、オンプレミス→クラウドへ環境を移せば完了だと思っています。
しかし本当の勝負は移行後です。例えば、
障害監視
バックアップ
アカウント管理
セキュリティ運用
問い合わせ対応
これを誰が行うのか。ここが決まっていない状態で移行すると、本番開始後に混乱が発生します。
システムは動いている。しかし運用が回らない。これも典型的な失敗パターンです。
移行判定会議で現れる危険信号
再生請負人として現場に入ると、移行判定会議で危険信号が見えます。
例えば、
「たぶん大丈夫です」
「問題ないと思います」
「移行してみないと分かりません」
こうした発言です。
一見すると普通に見えます。しかし危険です。
なぜなら、確認ではなく願望だからです。
本来必要なのは、「確認しました」「検証結果があります」「リスクと対策を整理しています」です。
移行直前の曖昧な発言は、重大な事故の前兆であることが少なくありません。
自動車・電力案件で特に感じること
私が関わってきた
自動車業界の大規模開発案件
電力業界のインフラ更改案件
では、クラウド移行が単独で存在することはほとんどありません。
その周囲には、
ネットワーク更改
サーバ更改
監視基盤更改
セキュリティ強化
業務システム移行
が存在します。
つまり、クラウド移行は単なる技術案件ではなく、大規模な組織変革案件なのです。
だからこそ、技術だけ見ていても成功しません。
再生請負人が最初に確認すること
私がクラウド移行案件へ入った時、最初に見るのはAzureでもAWSでもありません。
まず確認するのは、
現行構成図
責任分界点
移行判定基準
障害時の連絡経路
意思決定者
です。
なぜなら、システムを止めるのは技術ではなく、決められない組織だからです。
まとめ
クラウド移行で失敗した案件を振り返ると、本当の原因は技術ではありません。
現行調査不足
責任分界点の曖昧さ
ベンダー間調整不足
運用設計不足
意思決定の遅れ
これらが複雑に絡み合い、プロジェクトを崩壊させます。クラウドは成熟しています。
AzureもAWSも十分な機能を持っています。それでも失敗するのは、技術の問題ではなく組織の問題です。
再生請負人は問題を見ません。原因を見ます。
そしてクラウド移行案件においても、多くの場合その原因は技術ではなく、組織と意思決定に存在しているのです。
もし現在のプロジェクトに不安を感じているのであれば、一度危険度診断をご活用ください。
また、軽度の課題についてはPMO講座もご活用いただけます。
▶ PMO講座
次回予告
再生請負人が見た システム移行が遅延する本当の理由
再生請負人が見た インフラ更改が炎上する会社の共通点
再生請負人が見た 基盤更改失敗の共通パターン
再生請負人が見た クラウド移行失敗の前兆
再生請負人が見た 切替直前に崩壊する案件
再生請負人｜炎上プロジェクト再建専門｜SBC株式会社
コメント