「ソフテックだより」では、ソフトウェア開発に関する情報や開発現場における社員の取り組みなどを定期的にお知らせしています。
さまざまなテーマを取り上げていますので、他のソフテックだよりも、ぜひご覧下さい。
ソフテックだより(発行日順)のページへ
ソフテックだより 技術レポート(技術分野別)のページへ
ソフテックだより 現場の声(シーン別)のページへ
ソフテックではお客様の要望により、設計から保守まで一貫してソフトウェア開発を担当させていただくことがあります。この”ソフテックだより”でも過去に何度かご紹介しておりますが、現場におけるソフトのデバッグや保守も重要な作業の一つです。ソフトハウスというと、社内で黙々とパソコンに向かって作業しているイメージを持たれる方も多いかと思いますが、ソフテックの場合はお客様の工場や施設などで作業することも少なくありません。
今回は5年ほど前に私が保守作業の一環として、現場にソフトウェア入れ替え作業に伺った際の失敗談についてお話したいと思います。対象となるシステムは、当時すでに数年間稼動しておりましたが、リリース後の社内ヒートランテストなどでいくつかの不適合が報告されていました。お客様に相談した結果、対策として、修正を加えたバージョンのWindowsソフト入れ替えを行うことになりました。対象のシステムはスタンドアローンのシステムであるため、稼動中のPCを直接操作し、実行ファイルと各種データを更新する必要がありました。
私自身、このシステムには、主にテスト担当として数年関わっていましたが、現場での作業はこの時が初めてでした。しかも、ソフテックからは私一人で伺うことになり、社内からのサポートは電話で随時行う手はずとなっていました。”いきなり一人で現場にいかせるの?”と思われる方もいるかもしれません。ですが、この入れ替え作業自体は、過去にも何度か行われており、作業手順はマニュアル化されていたため、決して難しい作業ではありません。
出張作業は急遽決まったこともあり、少しバタバタしてしまいましたが、前日に必要な機材(連絡用のノートPC、データバックアップ用のフロッピーディスクなど[稼働PCにはUSBポートがなく、フロッピーディスクが現役で活躍していました])を揃え、作業手順書を熟読して作業に備えました。入れ替え作業は、エンドユーザーさんの管理する設備内で行われ、お客様担当者と私とで作業に当たりました。当時の入れ替え作業手順(概要)は、以下の通りとなっていました。
(作業は基本的にすべてエンドユーザーさんの施設内で行います。このときシステムは稼動している状況です。もちろん、オペレーションミスは許されません。エンドユーザーさんとお客様が見守る中、作業するので少し緊張します。)
図1. 作業手順1
(あくまでも念のための確認です。比較結果が間違っていることはまずありません。)
図2. 作業手順2
(システム停止時間は短いに越したことはありません。ここからが作業本番です。)
図3. 作業手順3
(この作業はとにかく早く、正確に!!)
図4. 作業手順4
(システムが正常に起動すれば、一安心です。)
図5. 作業手順5
(この作業もシステムが稼動している状況で行います。油断は禁物。オペレーションミスのないように。)
図6. 作業手順6
(これも念のための確認です。万が一、比較結果が間違っていたら、入れ替え作業に何か問題が・・・。)
図7. 作業手順7
システムは常時稼動を前提としているため、入れ替え時間は10分程度で、入れ替え後、すぐに再稼動しなければなりませんでした。また、上記手順にもあるようにシステム稼動の前後では、すばやくハッシュ値の算出・比較(各種データファイルが社内でバージョン管理しているものと一致することを確実に確認する)をする必要があります。私自身、”作業手順書どおりに、作業を進めれば問題ないだろう”という漠然とした考えしかありませんでしたが、何事もマニュアルどおりには行かないものです。現場でのプレッシャーも手伝って、以下のようなミスをしてしまいました。
“さぁ、入れ替えよう”という段階で、問題が起りました。現場稼働環境から吸い上げたデータのハッシュ値と社内から持ってきたハッシュ値が合いません・・・。比較用のハッシュ値は、前日の準備時に、社内管理しているデータベースから吸い上げたもので、これが現場稼働環境と同じでないということは、社内のバージョン管理が間違っていることを意味します。お客様はすぐにでも入れ替え作業に取り掛かろうと、私の作業が終わるのを待っています。
お客様からの”早くしてくれ”という見えないプレッシャーの中、私の気持ちは“どうしよう”と焦るばかりです。”なかったことにしようか”という考えが、一瞬頭をよぎります。でも、後々大きな問題になったら・・・。私がとるべき道は一つしかありません。お客様に状況を説明した上で、会社に電話をし、社内のデータベースを再度確認してもらいました。電話でハッシュ値の照合を行った結果、私が持参したデータが間違っていることが分かりました。いくらバタバタしていたとはいえ、あってはならないミスです。お客様に時間を取らせてしまったことを再度お詫びし、問題ないことを説明して作業に戻りました。
入れ替え作業は何とか滞りなく完了し、バージョンアップ後のデータをフロッピーディスクにバックアップしました。システムは既に起動しており、問題なく動き始めています。現場はすでに作業終了モードで、引き上げ準備が始まっていました。バックアップデータの確認で問題がなければ私の作業も完了です。もう問題はないだろうと思いながら、手順書の最終工程であるバックアップデータのハッシュ値比較を行いました。ところが、データを確認したところ、一部のデータがコピーされていないことがわかりました。
一部始終の作業を見ていたお客様から「なぜデータが足りないのか?」と質問を受けました。しかし、私にも原因が分からないため、答えに困り、とっさに、「すいません。わかりません。」と答えてしまいました。稼動中のPCはすでにエンドユーザーさんの手によって操作できない状態になっており、ファイルの存在を直接確認することはできません。もし、入れ替えたソフトの中に、コピーできていないファイルがあり、稼動後にトラブルが発生したら大問題です。
お客様から「わかりませんじゃ困るんだよ!」と怒られ、私は再びすぐに会社に電話をいれました。その結果、問題のファイルはヘルプキャッシュファイル(拡張子gid)で、コピーされていなくてもシステム動作には支障がないことがわかりました。すぐにお客様に事情を説明し、納得していただくことができました。後でわかったことですが、現場の環境ではこのファイルが”隠しファイル”に設定されていたため、圧縮時にコピーされなかったことがわかりました。
上に挙げた例ではいずれのミスも大きな問題にならず、事なきを得ましたが、いつ大きな問題になってもおかしくありません。労働災害の講習などではハインリッヒの法則の話がよく引き合いに出されますが、このような例でもハインリッヒの法則が当てはまるのだと思います。いかにして失敗の芽を摘んでいくかが大事で、その都度、原因を把握し、改善していく必要があります。ちなみに、このときの改善策としては、失敗結果を踏まえて後日、手順書の内容を修正しました。
また、現場の作業では、不測の事態が起った場合に正確な判断力と迅速な対応が求められます。常にそのような行動ができる技術力、判断力を備えていれば問題ないのかもしれませんが、なかなか難しいものだと感じます。ただ、”お客様に不安を与えない”、”満足していただく”ことを最優先に考えると、お客様に対する適切な報連相を行うことが、最も重要なことなのかもしれません。
最近では私も入れ替え作業に行くことはなくなりましたが、このときの事を思い出すと、「今の自分ならもう少しうまく立ち回れそうかなぁ」とは思います。少しは成長できているということでしょうか・・・。
(T.S.)
関連ページへのリンク
関連するソフテックだより