今回はプロジェクトの終結付近の課題について提起する。システムの稼働開始近辺での修正変更の怖さを認識するとともに、事故発生時の連絡体制をしっかり確立しておきたい
 |
事故の中でも、新システム立ち上げの失敗や稼働直後の事故ほど困るものはない。準備万端余裕を持って稼働日を迎え、関係幹部も参加して盛大な稼働開始式典を開いたのに、いきなりおかしくなるという事件に遭遇した経験がある。まさに「九仞の功一簣に欠く」残念な事件である。巨大なシステムは、かなり丁寧に準備しても、事故を完全には回避できないということだ。
以前は稼働前に全システムを準備し、エンドユーザーにも全端末に張り付いてもらって、本番さながらの最終確認をするのが常識だった。それが今は、システムへの信頼感が増えた代わりに、本番構成で愚直に確認することが現実的には困難になり、昔以上にリスクが増えている。いったん事故が起きると、社会的信用も失いかねない危うさがあるだけに、実施困難な状況下でも何とか本番に近い構成で最終確認をやるべく顧客とよく相談しておきたい。
 |
稼働直前になってバグや不具合点に気がつくと、「何とか直してしまい、気がかりなことを一切なくして稼働開始日を迎えたい」と誰もが思う。だが、仮にその不良に遭遇したとしても致命的な事故にはならないと想定されるなら、むしろあわてて対策を打たないほうが事故の確率は減るだろう。
少なくとも担当者が勝手に修正に走るようなことは絶対に避け、プロジェクト・マネジャーを中心に要修正案件を審議し、あえて稼働日直前に対策するかどうかを判断すべきである。
修正を保留したバグや問題点については、顧客責任者にもよく説明し、いつ対策を取るのがよいか相談しておきたい。そしてお互いが、起こるかもしれないリスクに備えた体制や心構えで本番を迎えるべきであろう。
 |
事故が起きれば、できるだけ早く、的確な状況把握と報告、適切な対策が求められる。だが、たまたま顧客サイトにいるSEだけですべてを解決するのは無理なことが多いので、顧客サイトからベンダー社内、および関連各社への連絡ルートをしっかり定めておく必要がある。
最初から連絡ルートを何も決めていないようなプロジェクトは、今やほとんどないであろうが、少し時間がたつと職制が変わったり、担当者が転属したりするので、だんだんルートの確かさが怪しくなってくるだけに、連絡ルートの定期的メンテナンスが必要だ。
また、オープンかつマルチベンダーの時代でもあるので、ベンダー1社だけで解決できないことも多い。関係各社でよく調整し、いざというときに困らないようにしておく必要がある。
 |
本番稼働直後に万一事故が起きたときに備え、顧客サイトにバックアップ体制をとるのは当然のことであるが、ベンダー社内の各関係者との連絡ルートについてもしっかり定めておく必要がある。でなければ情報が錯綜し、混乱がますますひどくなってしまう危険性がある。
事故が発生したとき、現地の責任者が速やかに情報発信する必要があるのは当然だが、ベンダー社内から現地への問い合わせ窓口も一本化すべきである。事故の第一報を受けた各担当部門が色々と心配になって現地状況を知りたくなる気持ちはよく理解できるが、ベンダー内の各関連部署から勝手な問い合わせが殺到すると、現地責任者は社内対応に追われ、肝心の顧客対応に齟齬をきたしかねないからだ。
逆に言えば、現地からは適切な間隔で次々報告を入れるよう留意する必要がある。
