システムトラブルは「人」が引き起こす

システムを開発し、運用するに当たって、最も頭を悩ますことの一つにシステムトラブルに対する対応があります。
システムトラブルの原因は、機器の故障から、オペレーションのミスまで様々ですが、システム変更のリリース時の問題はその影響度合い、トラブルの可能性において最も大きいといえるでしょう。
つい最近も全日空がサーバーを更新した際にトラブルに見舞われました。

日経ITProの記事より
5月27日未明から、全日本空輸の国内線において、予約搭乗手続きや手荷物管理を担当するチェックイン・システムに障害が起きていた問題は、「ホスト接続システム」の入れ替えが原因だった。ホスト接続システムは、チェックイン・システムが稼働するメインフレームと約1万台の操作端末を接続するためのものである。
　同社は24日までの約2週間で、合計6系統あるホスト接続システムのうち、3系統のハードウエアを更新していた。その更新した3系統が今日の始発便から性能劣化し、「情報が詰まった状態になった」（広報室）という。原因を調査する一方、同社は午後3時半、更新した3系統を古いシステムに戻すことでシステムを復旧させた。

特に自社内で開発を行い、マーケットの要求に対応するための変更を、現行システムに対して継続的に実施している場合、システム部門は常にトラブルを引き起こす危険性と向き合っているといえるでしょう。私も開発者として、そんな状況で仕事をしています。
私の会社ではシステムトラブルに対する取り組みとして、ISMS(情報セキュリティマネジメントシステム)の管理の仕組みを導入し、開発及びリリースプロセスの管理や、システム障害の報告・管理をおこなっていますが、必ずしも効果的に障害を防止できているか疑問です。結果としてのトラブル件数を減らすことができていません。
なぜ、変更時のシステムトラブルは減らないのでしょうか。
私が考えるポイントは次の2点です。

システムはその構成要素が非常に複雑で、その度合いは日に日に増大する
技術の変遷が非常に早く、新たなトラブルの因子が増え続ける

それに対してシステム障害への対策は、上記のポイントにフォーカスしていないし、それ故トラブルの本質に迫れていない。従って管理策は形骸化しがちで、結果に結びついていないと私は思います。
システム更新時のトラブルは「人」がその引き金になっている以上、もっとヒトを中心に対策や管理策を考えてゆく必要があると認識しています。トラブルの少ないシステムは、トラブルを引き起こしにくい人、組織からのみ生まれ得ると考えます。
まあ、別の次元での話としては、システムを変更しなければいい、という議論もありますが。
続きは別の日に......