HOME > ソフテックだより > 第94号(2009年7月15日発行) 現場の声編「トラブル対応をスムーズに進めるために」

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

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


ソフテックだより 第94号(2009年7月15日発行)
現場の声編

「トラブル対応をスムーズに進めるために」

1. はじめに

今回はPC関連ソフトウェアなどにおける、「納めてから発生するトラブル」の対応について取り上げます。
私が納めてきたシステムは主にPC関連ソフトウェア(プラントなどの監視システム)ですが、最近はPLC(Programmable LogicController)関連の制御ソフトウェアも増えてきています。
これらの納入済みのシステムで発生したトラブル経験を元に、どういう所に気をつけて対応しているか、今後どのようにしていきたいか?という事を本メルマガでご紹介したいと思います。

2. トラブル発生

トラブルが発生したとわかるのは主に、お客様からの電話連絡です。

[お客様]パソコンの調子が悪いのですが  [弊社担当]何がどの様に悪いのでしょうか?
図1. お客様からのトラブル電話連絡

このようにお客様からトラブルの連絡があった時に、下記のような状況が発生した事がありました。それぞれどのような対応を行ったのかまとめてみます。

2-1. システムを開発して納めた担当者が不在(退社済み、出張中など)

電話を受けた時に開発担当者が不在の場合が時々発生します。
もし開発担当者が不在の場合には、その社員が所属しているグループ内の別担当者や、もしくは弊社開発の監視システム(FAVIEW)案件では、システム構築を行った担当者ではなく、監視システムの基本ソフトウェア開発者の私がトラブル対応をする事があります。

このように私が関わった事の無い案件のトラブル対応が発生した時に、このトラブルを解決できるのか?と戸惑った時期もありました(その当時は開発担当者しか知らない情報や、データが多くあったためです)。

今では案件情報はNotesというグループウェアまたはVSS(Microsoft Visual Source Safe)などのソース管理ツールで一括管理しており、本社−八戸間でデータを共有しています。そのため開発担当者がいなくても決まった場所にデータがあるため、そこからデータを取得して動作確認が行える環境が整っています。

案件データをVSS、Notesから取得して次は環境を構築しないと・・・
図2. 社内データ管理概要

今では自分が担当した事の無い案件でも、お客様からのトラブルの連絡を受けて、症状などをお聞きして、社内のデータと照らし合わせていく事により、ほとんどの場合で原因にたどり着く事ができるようになりました。

2-2. 納入してから年数が経ちすぎて、システム内容を担当者が忘れている

弊社の納入しているソフトウェアは5年〜10年など長期間利用する事が前提で開発しているものがあります。そのため納入してから年数が経過してからのトラブル連絡だと、システム概要は覚えていても細かい部分は忘れてしまっています。

何年も経つと自分が担当した案件でもデータ管理がよほどしっかりしていないと、納入データは?仕様書は?プログラムは何処だ?という状態になってしまいます。そのときにも上記1−1で記述したように案件情報はNotesというグループウェアまたはVSS(Microsoft Visual Source Safe)などのソース管理ツールで一括管理している事が非常に力になります。

私は納めてから最大で13年経過した案件のトラブル対応を行った事があります。その時にはPCを準備して環境を作成したり、仕様書を読み直したりという作業が必ず発生します。しかしデータの管理がしっかりしているため、困った事はありません。
「案件のデータを自分で管理しろ!」と言われたら、自分流のやり方になってしまったり、データが何処にあるのかほかの人にはわからないという事になってしまったりするため、会社としての統一したデータ管理方法は必須だと実感しています。

2-3. 連絡をくださったお客様が、システムの詳細をご存じ無い

連絡をくださったお客様が以下のような場合もしばしばあります。

  • お客様内でシステム引き継ぎされた新しい担当者である
  • 導入した部署と保守を行っている部署が異なる
  • パソコンなどの操作に慣れていない

さらに連絡を受けた時に開発担当者が不在という場合は大変です。お客様とトラブル対応担当者の両方がシステムの詳細を知らない所からトラブル対応を行う事になります。そのような時には早急に、社内で動作確認できる状況を作成して再度お客様と連絡を取り対応を進めていきます。
このようなトラブル対応が自分に回ってきた事もあります。その時には仕様書を見ながらお客様と電話して、ソフトウェアを操作しながらひとつひとつ症状を確認して問題の切り分けを行っています。

[お客様]画面の操作ができなくて通信できていない様です [弊社担当]通信できていないと判断した理由は何でしょう?(ケーブルかな?パソコンの故障かな?それとも・・・)
図3. トラブル概要

この問題の切り分けが一番大事な部分です。
私は下記の点に注意してお客様から情報を聞き出します。

2-3-1. 状況の確認

現在どのような状況になっていますか?
PCアプリケーションであれば、画面にエラー表示していますか?
いつもと違った操作を行いましたか?
エラー発生時の画面ハードコピーなど残っていますか?
トラブルが起きる前に停電など発生していませんか?

2-3-2. ハードウェアの問題かどうか?

PC、PC関連機器が正常に動いていますか?
制御機器側(PLC側)が正常に動いていますか?
通信関係が正常に動いていますか?

2-3-3. ソフトウェアの問題かどうか?

特定条件で発生しますか?
特定条件の場合にはどのような操作、データを扱った時ですか?
制御側(PLCなど)のソフトウェアの問題ですか?
PC側で動作しているソフトウェアの問題ですか?

このような情報をお客様から聞き出し、ある程度トラブルの目星を付けます。その後緊急度に応じてすぐに出張対応するか、社内調査したあと後日対応するか相談させて頂いています。

3. トラブル出張対応

トラブル内容によっては緊急度が高く、出張対応が必要となる場合があります。この時にお客様から聞き出した情報を元に、様々な事を想定して準備する必要があります。
先日私が対応したトラブル事例を取り上げてみました。

3-1. 原因推測・社内準備

つい先日も24時間稼働の監視ラインで通信ができないというトラブル連絡があり対応させて頂きました。
症状としては、PCで動作させている監視システムにPLCからデータが上がってこないという状況でした。そのため帳票やグラフデータがまったく変化しておりませんでした。詳しく話しを聞いていった結果、私は「PCとPLCが通信できていない状態」だと判断しました。

PCとPLCの通信が出来ていない。原因は通信ハードウェアの故障だろう・・・
図4. トラブル対応したシステム構成(社内で想定したトラブル状況)

現地で動作しているPCは13年以上稼働しているNECC製のFC−9801という機種でPCとPLCとの通信も専用のハードウェアを使っており、すでに販売中止になっています。
もしハードに問題があった場合、現地出張しても何も対応できないという状況になるため、私は社内に保管してある予備品を準備して動作確認まで済ませて、通信に関連するハードウェア、納入時のデータ一式、調査用のパソコンなどを持参して現地に伺いました。

3-2. 現地出張、調査対応

調査日をお客様と調整し、現地に伺って症状を確認した所、電話で聞いた通りの症状なのですがPCとPLCは正常に通信できておりました。
この時点で予想してきた原因ではないという事がわかります。

予想が外れた時点で原因追及までに時間がかかるかもしれない・・・という事が頭をよぎりましたが調査を進めていくと、PLC間の通信がまったく行えていない状態である事がわかりました(PLCは複数台あり、それらはMELSECNET接続して通信しています)。

PLC間の通信部分については弊社の開発責任範囲ではありませんでしたが、お客様が困っている事と、せっかく出張して調査に来ているのだからと原因調査を続けました。PLCに接続するケーブルも持参していたため、PLCに接続して状況を確認していくと、ある1台のPLCの通信カードが故障しているようだという所まで原因を絞り込みする事ができました。
お客様に相談して、PLCの電源を切らせて頂いて予備の通信カードと交換した結果通信が全て正常に復帰いたしました。

原因はこのPLCの通信カード故障が原因で、全てのPLC間通信が止まっていた
図5. トラブル対応したシステム構成(実際のトラブル状況)

お客様から、「これで運転状況が確認できる。助かったよ!」という言葉を頂き気持ちよくトラブル対応を終える事ができました。
今回の場合には、あらかじめお客様からお聞きした情報を元に原因を絞り込みしましたが、原因はまったく別な所にありました。
そのような場合もできるだけ対処できるように様々な準備をして出張に出かけるように心がけております。
今回は無事にトラブル対応を完了できましたが、まったく想定外の原因でした。このような事例を経験する事でトラブル対応時に想定すべき事を勉強させて頂いています。

4. トラブル対応を減らす、迅速に対応するために

これまでに経験してきたトラブルの中には、すでに退社した担当者から引き継いだ案件も数多く存在します。年数を重ねれば、重ねるほど納めてきたシステムは増え、さらにハードウェアの劣化なども重なりトラブル対応件数も年々増えてきています。

そのようなトラブルをどのように減らしていくか?対応を簡単にするか?という点が今後の課題だと思っております。
私はPC関連のトラブルではハードディスク故障を一番多く経験しています。

弊社ではハードウェア更新時にはRAID(Redundant Arrays of Inexpensive Disk)構成の提案、産業用コンピュータなどであれば定期的なメンテナンスによるパーツ交換などを実施して、ハードウェア寿命による故障が発生しないように提案するようにしております。
その他に、大規模システムなどで生産に影響があると致命的な案件などは、遠隔からのメンテナンスが可能なシステム構成にする場合もあります。
最近ではノートPCを現地(遠隔地)に送り、お客様にそのノートPCをPLCなどの制御機器に接続して頂く事により、インターネット経由(携帯通信カードを使用)でPLCプログラムなどをメンテナンスできるようにした事例もございます。

無線・有線での通信環境の充実、VPN(Virtual Private Network)やOSのセキュリティ面の充実を背景に今後はこのような遠隔地とインターネットを使ったメンテナンス事例も確実に増えていくと考えます。

正常に動かない原因はなんだろう?現地のPLCを調べてみよう
図6. 遠距離でのメンテナンス概要

5. まとめ

これまでに大小様々なトラブル対応を実施してまいりましたが、トラブルの内容から原因推測までを完璧に行う事は難しい事だと実感しております。
トラブル対応を完了させた時にお客様から「ありがとう。助かりました。」という言葉をお聞きできた時には、大事になる前に対応できて本当によかったなと実感する事があります。
これからもトラブル発生時にはお客様からの情報をうまく聞き出して、原因推測と対応を素早く行えるように努める事、トラブルが発生しにくいシステム・ハードウェア構成、メンテナンスまでを含めて素早く対応できるように様々な取り組みを行っていきたいと考えております。

(S.N.)


関連ページへのリンク

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

ページTOPへ