トラブルが発生したとわかるのは主に、お客様からの電話連絡です。
|
| 図1. お客様からのトラブル電話連絡 |
このようにお客様からトラブルの連絡があった時に、下記のような状況が発生した事がありました。それぞれどのような対応を行ったのかまとめてみます。
2-1 システムを開発して納めた担当者が不在（退社済み、出張中など）
電話を受けた時に開発担当者が不在の場合が時々発生します。
もし開発担当者が不在の場合には、その社員が所属しているグループ内の別担当者や、もしくは弊社開発の監視システム（ＦＡＶＩＥＷ）案件では、システム構築を行った担当者ではなく、監視システムの基本ソフトウェア開発者の私がトラブル対応をする事があります。
このように私が関わった事の無い案件のトラブル対応が発生した時に、このトラブルを解決できるのか？と戸惑った時期もありました（その当時は開発担当者しか知らない情報や、データが多くあったためです）。
今では案件情報はNotesというグループウェアまたはVSS（Microsoft Visual Source Safe）などのソース管理ツールで一括管理しており、本社−八戸間でデータを共有しています。そのため開発担当者がいなくても決まった場所にデータがあるため、そこからデータを取得して動作確認が行える環境が整っています。
 |
| 図2. 社内データ管理概要 |
今では自分が担当した事の無い案件でも、お客様からのトラブルの連絡を受けて、症状などをお聞きして、社内のデータと照らし合わせていく事により、ほとんどの場合で原因にたどり着く事ができるようになりました。
2-2 納入してから年数が経ちすぎて、システム内容を担当者が忘れている
弊社の納入しているソフトウェアは５年〜１０年など長期間利用する事が前提で開発しているものがあります。そのため納入してから年数が経過してからのトラブル連絡だと、システム概要は覚えていても細かい部分は忘れてしまっています。
何年も経つと自分が担当した案件でもデータ管理がよほどしっかりしていないと、納入データは？仕様書は？プログラムは何処だ？という状態になってしまいます。そのときにも上記１−１で記述したように案件情報はNotesというグループウェアまたはVSS（Microsoft
Visual Source Safe）などのソース管理ツールで一括管理している事が非常に力になります。
私は納めてから最大で１３年経過した案件のトラブル対応を行った事があります。その時にはＰＣを準備して環境を作成したり、仕様書を読み直したりという作業が必ず発生します。しかしデータの管理がしっかりしているため、困った事はありません。
「案件のデータを自分で管理しろ！」と言われたら、自分流のやり方になってしまったり、データが何処にあるのかほかの人にはわからないという事になってしまったりするため、会社としての統一したデータ管理方法は必須だと実感しています。
2-3 連絡をくださったお客様が、システムの詳細をご存じ無い
連絡をくださったお客様が以下のような場合もしばしばあります。
・お客様内でシステム引き継ぎされた新しい担当者である
・導入した部署と保守を行っている部署が異なる
・パソコンなどの操作に慣れていない
さらに連絡を受けた時に開発担当者が不在という場合は大変です。お客様とトラブル対応担当者の両方がシステムの詳細を知らない所からトラブル対応を行う事になります。そのような時には早急に、社内で動作確認できる状況を作成して再度お客様と連絡を取り対応を進めていきます。
このようなトラブル対応が自分に回ってきた事もあります。その時には仕様書を見ながらお客様と電話して、ソフトウェアを操作しながらひとつひとつ症状を確認して問題の切り分けを行っています。
 |
| 図3. トラブル概要 |
この問題の切り分けが一番大事な部分です。
私は下記の点に注意してお客様から情報を聞き出します。
2-3-1 状況の確認
現在どのような状況になっていますか？
ＰＣアプリケーションであれば、画面にエラー表示していますか？
いつもと違った操作を行いましたか？
エラー発生時の画面ハードコピーなど残っていますか？
トラブルが起きる前に停電など発生していませんか？
2-3-2 ハードウェアの問題かどうか？
ＰＣ、ＰＣ関連機器が正常に動いていますか？
制御機器側(ＰＬＣ側)が正常に動いていますか？
通信関係が正常に動いていますか？
2-3-3 ソフトウェアの問題かどうか？
特定条件で発生しますか？
特定条件の場合にはどのような操作、データを扱った時ですか？
制御側（ＰＬＣなど）のソフトウェアの問題ですか？
ＰＣ側で動作しているソフトウェアの問題ですか？
このような情報をお客様から聞き出し、ある程度トラブルの目星を付けます。その後緊急度に応じてすぐに出張対応するか、社内調査したあと後日対応するか相談させて頂いています。
トラブル内容によっては緊急度が高く、出張対応が必要となる場合があります。この時にお客様から聞き出した情報を元に、様々な事を想定して準備する必要があります。
先日私が対応したトラブル事例を取り上げてみました。
3-1 原因推測・社内準備
つい先日も２４時間稼働の監視ラインで通信ができないというトラブル連絡があり対応させて頂きました。
症状としては、ＰＣで動作させている監視システムにＰＬＣからデータが上がってこないという状況でした。そのため帳票やグラフデータがまったく変化しておりませんでした。詳しく話しを聞いていった結果、私は「ＰＣとＰＬＣが通信できていない状態」だと判断しました。
|
|
|
図4. トラブル対応したシステム構成（社内で想定したトラブル状況）
|
現地で動作しているＰＣは１３年以上稼働しているＮＥＣ製のＦＣ−９８０１という機種でＰＣとＰＬＣとの通信も専用のハードウェアを使っており、すでに販売中止になっています。
もしハードに問題があった場合、現地出張しても何も対応できないという状況になるため、私は社内に保管してある予備品を準備して動作確認まで済ませて、通信に関連するハードウェア、納入時のデータ一式、調査用のパソコンなどを持参して現地に伺いました。
3-2 現地出張、調査対応
調査日をお客様と調整し、現地に伺って症状を確認した所、電話で聞いた通りの症状なのですがＰＣとＰＬＣは正常に通信できておりました。
この時点で予想してきた原因ではないという事がわかります。
予想が外れた時点で原因追及までに時間がかかるかもしれない・・・という事が頭をよぎりましたが調査を進めていくと、ＰＬＣ間の通信がまったく行えていない状態である事がわかりました（ＰＬＣは複数台あり、それらはＭＥＬＳＥＣＮＥＴ接続して通信しています）。
ＰＬＣ間の通信部分については弊社の開発責任範囲ではありませんでしたが、お客様が困っている事と、せっかく出張して調査に来ているのだからと原因調査を続けました。ＰＬＣに接続するケーブルも持参していたため、ＰＬＣに接続して状況を確認していくと、ある１台のＰＬＣの通信カードが故障しているようだという所まで原因を絞り込みする事ができました。
お客様に相談して、ＰＬＣの電源を切らせて頂いて予備の通信カードと交換した結果通信が全て正常に復帰いたしました。
|
|
|
図5. トラブル対応したシステム構成（実際のトラブル状況）
|
お客様から、「これで運転状況が確認できる。助かったよ！」という言葉を頂き気持ちよくトラブル対応を終える事ができました。
今回の場合には、あらかじめお客様からお聞きした情報を元に原因を絞り込みしましたが、原因はまったく別な所にありました。
そのような場合もできるだけ対処できるように様々な準備をして出張に出かけるように心がけております。
今回は無事にトラブル対応を完了できましたが、まったく想定外の原因でした。このような事例を経験する事でトラブル対応時に想定すべき事を勉強させて頂いています。
これまでに経験してきたトラブルの中には、すでに退社した担当者から引き継いだ案件も数多く存在します。年数を重ねれば、重ねるほど納めてきたシステムは増え、さらにハードウェアの劣化なども重なりトラブル対応件数も年々増えてきています。
そのようなトラブルをどのように減らしていくか？対応を簡単にするか？という点が今後の課題だと思っております。
私はＰＣ関連のトラブルではハードディスク故障を一番多く経験しています。
弊社ではハードウェア更新時にはＲＡＩＤ（Redundant Arrays of Inexpensive Disk）構成の提案、産業用コンピュータなどであれば定期的なメンテナンスによるパーツ交換などを実施して、ハードウェア寿命による故障が発生しないように提案するようにしております。
その他に、大規模システムなどで生産に影響があると致命的な案件などは、遠隔からのメンテナンスが可能なシステム構成にする場合もあります。
最近ではノートＰＣを現地（遠隔地）に送り、お客様にそのノートＰＣをＰＬＣなどの制御機器に接続して頂く事により、インターネット経由（携帯通信カードを使用）でＰＬＣプログラムなどをメンテナンスできるようにした事例もございます。
無線・有線での通信環境の充実、ＶＰＮ(Virtual Private Network)やＯＳのセキュリティ面の充実を背景に今後はこのような遠隔地とインターネットを使ったメンテナンス事例も確実に増えていくと考えます。
 |
| 図6. 遠距離でのメンテナンス概要 |
