再生請負人が見た インフラ更改が炎上する会社の共通点
- 11 時間前
- 読了時間: 7分
はじめに
インフラ更改と聞くと、多くの人はこう考えます。
サーバを入れ替える
OSを更新する
ストレージを更改する
ネットワーク機器を更改する
利用者から見れば、「今まで通り使えればいい」それだけです。
だからこそ危険です。
私がこれまで携わってきた自動車業界や電力業界の案件でも、インフラ更改を軽視した結果として炎上したプロジェクトを数多く見てきました。
そしてそこで分かったことがあります。インフラ更改を炎上させるのは技術ではありません。組織です。
インフラ更改の炎上案件は突然起きない
以前の記事でもお伝えしました。炎上案件は突然発生しません。
インフラ更改も同じです。必ず前兆があります。
例えば、
レビュー待ちが増える
課題が放置される
会議ばかり増える
判断保留が増える
ベンダー間の調整が止まる
こうした小さな変化です。
しかし多くの会社は、切替直前になって初めて焦ります。
その頃には手遅れになっていることも少なくありません。
私がこれまで見てきた炎上案件も、突然炎上したわけではありません。
問題は見えていました。課題も見えていました。誰も決めなかっただけです。
関連記事
▶ 再生請負人とは
関連動画
▶ 再生請負人の流儀 #2 炎上案件は突然起きない
インフラ更改は見えない変更の集合体
システム開発は成果物が見えます。画面が変わる。機能が増える。
利用者も変化に気付きます。
しかしインフラ更改は違います。利用者から見ると、何も変わらないことが成功です。
しかし裏側では、
OS変更
ミドルウェア変更
仮想基盤変更
ネットワーク変更
セキュリティ変更
監視基盤変更
バックアップ構成変更
運用方式変更
が同時に発生しています。
つまり、利用者に見えない場所で巨大なリスクを抱えているのです。
見えない仕事ほど軽視される。これがインフラ更改の難しさです。
インフラ更改で現行調査を軽視する会社
インフラ更改で最も危険なのが現行調査不足です。現場ではよくあります。
古くなったから更改しましょう。しかし、
何のシステムが動いているのか
どこと連携しているのか
誰が使っているのか
どの運用が残っているのか
が把握できていない。
その状態で更改を始める。結果として切替直前に、そんな連携があったのか、
そのジョブは必要だったのか、そのサーバまだ使っていたのか、が始まります。
クラウド移行案件でも同じでした。システム移行案件でも同じでした。 炎上の原因は技術ではなく、現状を理解していないことです。
関連記事
ベンダーが増えるほど危険になる
大型更改案件では、
サーバベンダー
ネットワークベンダー
セキュリティベンダー
監視ベンダー
クラウドベンダー
アプリベンダー
が関与します。
すると何が起きるでしょうか。誰も全体を見なくなります。全員が自分の担当範囲だけを見る。
そして障害が発生した瞬間、「それは弊社の担当外です」が始まります。
再生請負人として現場へ入ると、この状態は非常に危険です。
責任の空白地帯で問題は発生するからです。インフラ障害の多くは技術の問題ではありません。
担当境界の問題です。
関連記事
▶ ベンダーが増えるほど炎上する理由
PMOを入れても炎上する会社
よく言われます。PMOを入れたので安心です。
しかし私はそう思いません。PMOは万能ではありません。
PMOは、
進捗を管理する
課題を整理する
リスクを可視化する
会議を運営する
ことはできます。
しかし、決断することはできません。決断するのは組織です。
炎上案件では、PMOの資料だけが増えていきます。
会議体だけが立派になります。しかし誰も決めない。
だから更改は止まります。
関連記事
関連動画
▶ PMOは魔法使いではない
運用設計を後回しにする会社
インフラ更改で本当に苦労するのは、構築ではありません。運用です。
例えば、
誰が監視するのか
障害時の連絡先は誰か
バックアップ運用はどうするのか
アカウント管理はどうするのか
セキュリティパッチは誰が適用するのか
ここが決まっていない。
しかし多くの会社は、「稼働後に考えればいい」と言います。
本番稼働後にそれを考える案件ほど苦労します。
インフラ更改は稼働日がゴールではありません。運用が安定して初めて成功です。
切替判定会議で見える危険信号
再生請負人として最も警戒する瞬間があります。
切替判定会議です。そこで出る言葉があります。
大丈夫だと思います。たぶん問題ありません
やってみないと分かりません。
私はこの発言が出た瞬間、危険信号だと判断します。
なぜなら、根拠ではなく希望だからです。
本来必要なのは、確認済みです。検証済みです。
希望ではプロジェクトは成功しません。根拠が必要です。
課題管理表を見るだけで危険度は分かる
私は更改案件に入ると、まず課題管理表を見ます。
なぜなら課題管理表には組織の状態が現れるからです。
例えば、
対応中
確認中
保留
関係者調整中
ばかり並んでいる。
解決日が空欄。責任者が曖昧。期限が未設定。
こうした案件は高確率で炎上します。
課題が多いことは問題ではありません。解決できないことが問題なのです。
自動車・電力案件で共通していたこと
私が関わってきた大型案件は毎回技術が違いました。
Windows更改
Linux更改
VMware更改
ネットワーク更改
クラウド移行
監視基盤更改
しかし失敗パターンは同じでした。
課題が放置される
責任が曖昧
判断が遅い
リスクを共有しない
問題を隠す
つまり、技術の問題ではありません。組織の問題です。
再生請負人が最初に見るもの
私が更改案件へ入った時、最初に見るのは構成図ではありません。
確認するのは、
課題管理表
責任分界点
ベンダー体制
承認ルート
意思決定者
です。
そして必ず確認することがあります。誰が決めるのかです。
なぜなら、インフラ更改を止めるのはサーバではなく、決められない組織だからです。
まとめ
インフラ更改が炎上する会社には共通点があります。
現行調査不足
ベンダーコントロール不足
運用設計不足
意思決定の遅れ
責任分界点の曖昧さ
問題は技術ではありません。問題は組織です。
再生請負人は問題を見ません。原因を見ます。
そして多くの更改案件で本当の原因は、技術ではなく、組織に存在しているのです。
もし現在のプロジェクトに不安を感じているのであれば、一度危険度診断をご活用ください。
また、軽度の課題についてはPMO講座もご活用いただけます。
▶ PMO講座
関連記事
▶ 再生請負人とは
関連動画
▶ 再生請負人の流儀#2 炎上案件は突然起きない
再生請負人｜炎上プロジェクト再建専門｜SBC株式会社
#プロジェクト再建, #プロジェクト再生, #プロジェクト立て直し, #炎上プロジェクト再建, #炎上案件, #再生請負人, #再生請負人の流儀, #PMO, #PMO支援, #プロジェクト管理, #組織改革, #自走する組織,
コメント