今回は所謂火消しについてです。
私は長くITプロジェクトに関わってきましたが、一番多かったのは「火消し」です。
代表的な火消しは以下のような内容でした。
1, プログラム（ソフトウェア製品）のバグによるもの
2, 運用のミスによるもの
3, ハードウェアの障害によるもの
4, プロジェクト管理の不備によるもの
5, 人的ミスによるもの（故意を含む）
6, コンピューターウィルス等サイバーアタックによるもの
7, 災害等によるもの
他にもありますが、多くの方は1,のバグをイメージされます。
プログラミングも人間が行うものですから、起こりうる確率は高いですが、私の経験から以下のケースが多いと思います。
1, 故意を含む人的ミス
これには単純ミスも含まれますが、故意が案外多かったと思います。
操作が分からなくなって電源を落としたり、消去コマンドを入れたり、データファイルを 潰したりです。これは有意味防ぐのは難しいと思いますし、品質管理やコンプライアンス を含む組織対応しかありません。
最近ではシステムの処理結果改ざんや、原因を隠ぺいするケースもありますので、対応が 急務です。
2, プロジェクト管理の不備
分かりやすいのは、プロジェクト計画時にデータ移行やトレーニングを忘れていたり、」 酷い例ではテストをしなかったりもあります。
これは開発導入に関して、人月すなわち工数でしかプロジェクトの評価を出来ない事に
起因します。
後は機能だけにフォーカスして処理するデータ兼巣の見積もりや評価をしないケースで、 これは横浜市を始めコロナのワクチン接種予約システムの障害等が記憶に新しいですね。
3, ハードウェアの問題
これは一年前の東証の障害等が記憶に新しいですが、東証のケースはこれに1,の人的ミス
が加わります。ハードウェア障害は技術的な問題とそもそもハードウェアメーカーが自社
では作れなくて、他社の製品を使用することや、OEMが増加している事に起因します。
ここまで見てきて分かる事は、原因が1つであることはまれであり、起きてからでは
出来る事は限られると言うことです。
火消しの役割は、火を消すことだけでは十分ではなく、原因を究明して事前に様々なリスク
に対応する準備やデータを集める事です。
最後に、グループと銀行のトップが辞任に追い込まれたみずほの件ですが、これは1,2,3全てが関連していますが、原因を究明したとは言えず、金融庁に類が及ぶのを避けるための「幕引き」に見えます。後任が金融庁の天下りでは、改善は望めないと思います。
Commentaires