HOME会社概況業務内容開発分野開発事例CANモジュールソフテックだよりお問い合わせ
HOME > ソフテックだより > 第108号(2010年2月17日発行) 現場の声編「ソフトウェア現場入れ替え作業での失敗談」

「ソフテックだより」では、ソフトウェア開発に関する情報や開発現場における社員の取り組みなどを定期的にお知らせしています。
さまざまなテーマを取り上げていますので、他のソフテックだよりも、ぜひご覧下さい。

ソフテックだより(発行日順)のページへ
ソフテックだより(技術分野別)のページへ
ソフテックだより(シーン別)のページへ


ソフテックだより 第108号(2010年2月17日発行)

現場の声編

「ソフトウェア現場入れ替え作業での失敗談」

ソフテックではお客様の要望により、設計から保守まで一貫してソフトウェア開発を担当させていただくことがあります。この”ソフテックだより”でも過去に何度かご紹介しておりますが、現場におけるソフトのデバッグや保守も重要な作業の一つです。ソフトハウスというと、社内で黙々とパソコンに向かって作業しているイメージを持たれる方も多いかと思いますが、ソフテックの場合はお客様の工場や施設などで作業することも少なくありません。

今回は5年ほど前に私が保守作業の一環として、現場にソフトウェア入れ替え作業に伺った際の失敗談についてお話したいと思います。対象となるシステムは、当時すでに数年間稼動しておりましたが、リリース後の社内ヒートランテストなどでいくつかの不適合が報告されていました。お客様に相談した結果、対策として、修正を加えたバージョンのWindowsソフト入れ替えを行うことになりました。対象のシステムはスタンドアローンのシステムであるため、稼動中のPCを直接操作し、実行ファイルと各種データを更新する必要がありました。

私自身、このシステムには、主にテスト担当として数年関わっていましたが、現場での作業はこの時が初めてでした。しかも、ソフテックからは私一人で伺うことになり、社内からのサポートは電話で随時行う手はずとなっていました。”いきなり一人で現場にいかせるの?”と思われる方もいるかもしれません。ですが、この入れ替え作業自体は、過去にも何度か行われており、作業手順はマニュアル化されていたため、決して難しい作業ではありません。

出張作業は急遽決まったこともあり、少しバタバタしてしまいましたが、前日に必要な機材(連絡用のノートPC、データバックアップ用のフロッピーディスクなど[稼働PCにはUSBポートがなく、フロッピーディスクが現役で活躍していました])を揃え、作業手順書を熟読して作業に備えました。入れ替え作業は、エンドユーザーさんの管理する設備内で行われ、お客様担当者と私とで作業に当たりました。当時の入れ替え作業手順(概要)は、以下の通りとなっていました。

  1. 稼動環境(exeソフト、各種データ)を圧縮・分割ソフトを使って、フロッピーディスクに保存する。

    (作業は基本的にすべてエンドユーザーさんの施設内で行います。このときシステムは稼動している状況です。もちろん、オペレーションミスは許されません。エンドユーザーさんとお客様が見守る中、作業するので少し緊張します。)

    作業は基本的にすべてエンドユーザーさんの施設内で行います。このときシステムは稼動している状況です。もちろん、オペレーションミスは許されません。エンドユーザーさんとお客様が見守る中、作業するので少し緊張します。
    図1. 作業手順1

  2. フロッピーディスクの内容をノートPCにコピーし、ファイル単位のハッシュ値(※1)を生成。バージョン管理情報と照合する。(念のため旧稼働環境のバージョンを確認する目的)

    (あくまでも念のための確認です。比較結果が間違っていることはまずありません。)

    あくまでも念のための確認です。比較結果が間違っていることはまずありません。
    図2. 作業手順2

  3. 現場の指示を仰ぎ、稼動中のシステムを停止する。

    (システム停止時間は短いに越したことはありません。ここからが作業本番です。)

    システム停止時間は短いに越したことはありません。ここからが作業本番です。
    図3. 作業手順3

  4. 稼動環境を新しいexeファイルとデータに更新し、スタートアップに登録する。

    (この作業はとにかく早く、正確に!!)

    この作業はとにかく早く、正確に!!
    図4. 作業手順4

  5. PCを再起動する。(システム自動起動)

    (システムが正常に起動すれば、一安心です。)

    システムが正常に起動すれば、一安心です。
    図5. 作業手順5

  6. バージョンアップ後の稼動環境を圧縮・分割ソフトを使って、フロッピーディスクにバックアップする。

    (この作業もシステムが稼動している状況で行います。油断は禁物。オペレーションミスのないように。)

    この作業もシステムが稼動している状況で行います。油断は禁物。オペレーションミスのないように。
    図6. 作業手順6

  7. フロッピーディスクの内容をノートPCにコピーし、ファイル単位のハッシュ値を生成。バージョン管理情報と照合する。(念のため更新後稼働環境のバージョンを確認する目的)

    (これも念のための確認です。万が一、比較結果が間違っていたら、入れ替え作業に何か問題が・・・。)

    これも念のための確認です。万が一、比較結果が間違っていたら、入れ替え作業に何か問題が・・・。
    図7. 作業手順7

システムは常時稼動を前提としているため、入れ替え時間は10分程度で、入れ替え後、すぐに再稼動しなければなりませんでした。また、上記手順にもあるようにシステム稼動の前後では、すばやくハッシュ値の算出・比較(各種データファイルが社内でバージョン管理しているものと一致することを確実に確認する)をする必要があります。私自身、”作業手順書どおりに、作業を進めれば問題ないだろう”という漠然とした考えしかありませんでしたが、何事もマニュアルどおりには行かないものです。現場でのプレッシャーも手伝って、以下のようなミスをしてしまいました。

○稼働環境のハッシュ値が違う

“さぁ、入れ替えよう”という段階で、問題が起りました。現場稼働環境から吸い上げたデータのハッシュ値と社内から持ってきたハッシュ値が合いません・・・。比較用のハッシュ値は、前日の準備時に、社内管理しているデータベースから吸い上げたもので、これが現場稼働環境と同じでないということは、社内のバージョン管理が間違っていることを意味します。お客様はすぐにでも入れ替え作業に取り掛かろうと、私の作業が終わるのを待っています。

お客様からの”早くしてくれ”という見えないプレッシャーの中、私の気持ちは“どうしよう”と焦るばかりです。”なかったことにしようか”という考えが、一瞬頭をよぎります。でも、後々大きな問題になったら・・・。私がとるべき道は一つしかありません。お客様に状況を説明した上で、会社に電話をし、社内のデータベースを再度確認してもらいました。電話でハッシュ値の照合を行った結果、私が持参したデータが間違っていることが分かりました。いくらバタバタしていたとはいえ、あってはならないミスです。お客様に時間を取らせてしまったことを再度お詫びし、問題ないことを説明して作業に戻りました。

○フロッピーディスクに吸い上げたバックアップデータが足りない

入れ替え作業は何とか滞りなく完了し、バージョンアップ後のデータをフロッピーディスクにバックアップしました。システムは既に起動しており、問題なく動き始めています。現場はすでに作業終了モードで、引き上げ準備が始まっていました。バックアップデータの確認で問題がなければ私の作業も完了です。もう問題はないだろうと思いながら、手順書の最終工程であるバックアップデータのハッシュ値比較を行いました。ところが、データを確認したところ、一部のデータがコピーされていないことがわかりました。

一部始終の作業を見ていたお客様から「なぜデータが足りないのか?」と質問を受けました。しかし、私にも原因が分からないため、答えに困り、とっさに、「すいません。わかりません。」と答えてしまいました。稼動中のPCはすでにエンドユーザーさんの手によって操作できない状態になっており、ファイルの存在を直接確認することはできません。もし、入れ替えたソフトの中に、コピーできていないファイルがあり、稼動後にトラブルが発生したら大問題です。

お客様から「わかりませんじゃ困るんだよ!」と怒られ、私は再びすぐに会社に電話をいれました。その結果、問題のファイルはヘルプキャッシュファイル(拡張子gid)で、コピーされていなくてもシステム動作には支障がないことがわかりました。すぐにお客様に事情を説明し、納得していただくことができました。後でわかったことですが、現場の環境ではこのファイルが”隠しファイル”に設定されていたため、圧縮時にコピーされなかったことがわかりました。

上に挙げた例ではいずれのミスも大きな問題にならず、事なきを得ましたが、いつ大きな問題になってもおかしくありません。労働災害の講習などではハインリッヒの法則の話がよく引き合いに出されますが、このような例でもハインリッヒの法則が当てはまるのだと思います。いかにして失敗の芽を摘んでいくかが大事で、その都度、原因を把握し、改善していく必要があります。ちなみに、このときの改善策としては、失敗結果を踏まえて後日、手順書の内容を修正しました。
また、現場の作業では、不測の事態が起った場合に正確な判断力と迅速な対応が求められます。常にそのような行動ができる技術力、判断力を備えていれば問題ないのかもしれませんが、なかなか難しいものだと感じます。ただ、”お客様に不安を与えない”、”満足していただく”ことを最優先に考えると、お客様に対する適切な報連相を行うことが、最も重要なことなのかもしれません。
最近では私も入れ替え作業に行くことはなくなりましたが、このときの事を思い出すと、「今の自分ならもう少しうまく立ち回れそうかなぁ」とは思います。少しは成長できているということでしょうか・・・。

(T.S.)

[注釈]
※1
ハッシュ値(hash value)について
ハッシュ値とは、任意のデータ(キーと呼びます)をハッシュ関数と呼ばれる関数で演算して得られる値のことを言います。ハッシュ関数には様々な種類(アルゴリズム)のものが存在しますが、決まりごととして、キーのサイズに関わらず結果として得られるハッシュ値の長さは一定(固定長)であることが挙げられます。異なるキーから同じハッシュ値が得られる確率はゼロではありませんが、ほとんどないため、キーの同一性を確認する目的で使用することができます。例えば、数Mバイトある2つのデータを比較しようとした場合、1バイトずつすべてを比較しようとすると非常に時間がかかりますが、ハッシュ値を使えば、16バイトや32バイト程度の比較ですみます。
すばやく、そして簡単にデータファイルの同一性(バージョン)を確認する手段としては、タイムスタンプを利用するのも一つの手です。しかし、タイムスタンプはファイルコピーの過程で、今回の事例のように圧縮・分割ソフトを使ったりすると容易に書き換わってしまいます。ソフテックでは過去の経験から、ファイルの簡易的な同一性確認にはハッシュ値を使用していました。

関連ページへのリンク

関連するソフテックだより