かの報告書から何を学ぶか
みずほ銀行さんの報告書を読みました。考えたことをメモします。
（特定の会社の話題に関するチラ裏なので、続きは折りたたんでみる）
・・・
これほど胸が詰まる資料もありません。いったいどうすれば、止めるべきでないシステムを動かし続けることができるのだろうと思います。報告書を読んでいると、その日が来るのは遠く思えて、悲しくなってきます。
やるべきだと分かっていても手をつけていないこと、緊急度の高いタスクにおされてプライオリティを下げた重要度の高いタスク。そんなものは日常業務で山ほどあります。その積み重ねの延長線上で今回の障害が起きたと考えると、他人事とは思えません。
地続きのITの世界で働く身としては、やはり何か教訓を拾い上げなければならないと思います。たとえ、ミッションクリティカルなシステムに関わることが、後にも先にもなくてもです。
というわけで、システム屋の末端で自分にできることを3つ書いてみます。
障害時を想定した運用テストを計画・実施する
報告書の中で「訓練」という用語が使われています。必要なのはまさにそれなのでしょう。
最悪の事態から目を逸らさない勇気と、現実的な訓練が必要です。
- 現実的な所要時間の計測
- 通常時に機械化している作業を手動で実施したときの困難さの把握
- 並行、後続の関連タスクへの影響の把握と、対策
- （それらを実施している間のお詫びを含む）BCPの確認
毎日バックアップは取っているけれども、実際にリカバリ可能かを試したことがないシステムはないか？ 最後に訓練を実施してから、システム構成が変更になっていないか？ リカバリ手順書が存在するが、当時の担当者がすでに辞めていて、万一の時のトラブル対応が不安なシステムはないか？ ・・・そういったことを確認し、アウトなら訓練を実施します。
点検項目の改訂プロセスを軽量化する
何かプロセスを策定したら、改訂のアクティビティを盛り込むことは当然です。しかし、改訂プロセスが機能するには前提があります。実施者に「改訂すべき項目を発見する能力」と、「改訂プロセスの手間を乗り越える能力」が備わっていることです。前者は経験とスキルに依存する部分が大きいので、せめて後者を何とかしたいです。
報告書に書かれているとおりに点検項目の見直しが行われたとして、おそらくは金融機関ならではの重量級のプロセスを乗り越え、厳格な手順化を経て、ようやく点検項目として追加されると思われます。その過程は、実施しやすいものなのでしょうか。作業者が自らやろうと思えるものでしょうか。
ただでさえ、「点検項目を増やす」作業は、運用にとってしんどいものです。必要性を頭で理解していても、仕事が増えることへの心理的抵抗は多かれ少なかれあります。また、自分一人で完結する作業ならまだしも、項目を増やす者と実施者が別であるケースも多いでしょう。こうなると、関係者間での摩擦のストレスも発生します。
新たに改訂プロセスを定める場合は、少しでも負担のない方法を選びます。
金融系大規模システムの開発運用に対する悪口を広めない
自分より若い人、とりわけ学生の方の前では気をつけることにします。（もちろん、すべての学生の方が、社会人のネガキャンを鵜呑みにするなどとは思っていません）
重厚長大でミッションクリティカルなシステムを背負いたいと考える若い人が、今の日本にどれくらいいるでしょうか。大銀行のシステム部員は、全員が全員、使命感に燃えているのでしょうか。報告書ではそういった人材を育成するといっていますが、精神論だけでは育つ側のモチベーションを維持できません。だからこそ、役割に応じた報酬や名誉が必要です。
金融系大規模システムは、メーカやSIerが作っています。しかし、世の中の勉強会に行くと感じるのは、SIerとはいまや「足を洗う」べき場所と多くの人に思われていて、「SIerを卒業しました」と宣言すれば仲間内で祝福される状況だということです。当のSIerに勤める人たちは、自分の仕事を卑下して話し、外の世界の人たちは、大規模システムに支えられて生活していながら、そのシステムを開発した人たちや運用している人たちを蔑視しています。
そうなったのには事情があるでしょう。SIerについて、技術力や開発プロセス、職場環境について、良い話を聞くことは少ないです。しかし、だからといって、彼らが担うシステムが果たす役割や、社会的重要性が目減りするわけではありません。
感情に走った批判は、すべてをごっちゃにしてしまいます。そのことによる悪影響を想像しようと思います。社会の根幹を支えるシステムを担おうと思ってくれる人が減ったら、困るのは自分です。
・・・
# 悲しく痛ましい話題なので、ネコを挟みつつお送りしました。（http://www.linkstyle.co.jp/）
