前回に続き、終結付近の課題を取り上げる。プロジェクトの過程で体験した多くの失敗や成功を、貴重な記録として残したい。各種ドキュメントを整理して後の人に引き継ぐ努力も欠かせない。
 |
システム稼働後、不幸にして事故が続く場合があるが、本来は稼働開始前に発見し対策しておくべき不良を見逃したことに大きな問題がある。顧客に多大の迷惑をかけた以上は、同様に見逃した不良が残っていないか十分にレビューして対策するとともに、しっかりと反省し再発防止に努めなければならない。
しかし、単に見逃しを反省するだけでなく、見逃しやすいテストのやり方ではなかったかをぜひ反省したいものだ。そして、そういう見逃しを減らすためのテストの観点やテストのやり方をよく検討しておきたい。
さらに重要なことは、そもそも事故を起こすようなバグが発生しないような設計や設計方式はどうあるべきかを考えることである。その反省から得られた知識や知恵を、次期システムや他のシステムの設計に反映することが大事なのだ。
 |
昨日まで順調に動いていたシステムが、呼がある値を超すと突然パンクしたり、待ち行列が異常に増えて混乱したりすることは起こり得ることだけに、トラフィックのトレンドをよく見ておく必要がある。ビジネスの進展とともに、扱い量が次第に増えていくシステムでは、いつ処理限界に達しそうかの予想とモニターによって、十分な余裕を持ってシステム処理能力対策を実施できるようにしておきたい。
個人のネット取引の普及で取引所システムのトラフィックが急増したり、番号ポータビリティ制への移行にからんで携帯電話活用が急増し各社のシステムが処理能力不足で混乱するなど、社会情勢の変化で急拡大するトラフィックは、過去の延長線上では予測しきれない面もある。関係者は定期的に情勢変化をよく議論するなど、早めの対策が必要であろう。
 |
システムには必ず障害が起こるという前提で、システムごとに回復手順をしっかり決めて、文書化しておくことが必要だ。同時に、書いただけ・読むだけでは緊急事態に対応できないので、事前に回復の訓練を実施しておく必要がある。消防署の消防訓練に倣い、システムの回復訓練を定期的に実施するように計画しておきたい。
特に社会的に重要なシステムは、十分なテストが行われるなど、大事故防止策がとられる半面、結果的に障害回復の実施機会も少なくなり、当初決めた回復手続きが忘れられやすいというパラドックスがある。それだけに意識的に定期的訓練を実施しておかないと、運用者が操作や運用方法を忘れたころに障害が発生し大混乱を起こしかねない。「災害は忘れたころにやってくる」のである。
 |
システムが顧客によって検収され安定稼働に入れば、ベンダーの開発要員やSEは顧客サイトから引き上げることになる。だが、顧客への運用支援や指導、事故への備え、さらにはその後に時々要求される小さなシステム改修対応などのために、検収後も一定数のSEを顧客サイトに滞在させる契約が交わされることもよくある。この際、どういうメンバー構成でこの契約に対応するかはベンダーとして大事な課題である。特にSE派遣がかなり長期にわたる場合は、戦略的な要員配置計画を立てる必要がある。
顧客満足第一ではあるが、次のプロジェクトのことも考えなければならないし、何よりも選ばれたSE本人の育成を真剣に考えなければならない。よく見られるのはSEを単純に塩漬けにしてしまうケースだ。これでは本人の成長にとって心配なだけでなく、モラルダウンを起こし、結果的に顧客の不満につながってしまう心配がある。
