おもちゃのトラブルシューティング

トラブルシューティングと問題解決は、似て非なるもの。

 

 トラブルシューティング

  ・問題が明確(目に見えている)

  ・解決方法も明確であることが多い

  ・一人(または自部門だけ)で解決できることが多い。

  ・それを解決しても根本的に何かが良くなることはない

 

 問題解決・問題は顕在化していない。考えないと問題が見えてこない。

  ・どうすれば解決できるか、分からないような難問が多い。

  ・多くの人の協力を得ないと解決できないことが多い。(根本的な仕

        組みに問題があることが多く、多くの人が問題の当事者となるため)

  ・それを解決できると、他にも多くの小さな課題は解決されること

         が多い。(問題の根本解決)

 

 トラブルシューティングとは、その名の通り、トラブルを解消して正常な状態にするための方法のこと、またはあらかじめ想定された事についての解決方法を記したマニュアルのことをいいます。

 

 トラブルシューティングには、「最も単純で確率の高い原因から検討開始する」という基本原則があり、問題の根源を体系的に探索し、解決していきます。

 

トラブルシューティングの手順

 

■ 手順

  トラブルが発生した場合には、まずトラブルの原因を分析します。

  これに反した行動が、経験則による対処です。経験則に頼って「前回はここをいじっているうちに治った」式の対処は厳禁です。見た目の現象が同じでも、原因が同じであるとは限りません。むしろ原因が異なっていることがあります。このような場合には、経験則に頼った対処は無意味であるばかりでなく、さらに状況を悪化させることがあります。

 

トラブル発生時の手順の概要を次に示します。

     

1. 状況の把握

 トラブルが発生した場合には、まず状況を正確に把握します。そして再現性のある条件を特定します。

 状況把握では、どこまでが正常で、どこからが異常なのか、その範囲を明確にします。

 そして原因分析にも対処にも、正常と確認された範囲を広げていく考え方で臨みます。異常の発生している箇所だけを調べて、原因分析をすべきではありません。

 

その理由は 2 点あります。

 1 点目は、原因特定の漏れをなくすためです。

  異常の原因の見当をつけて調べる方法では、漏れが生じやすくなり

      ます。正常と確認された範囲を広げる方法ならば、原因分析の漏れが

      発生する危険性を抑えられます。

 

 2 点目は、部分的復旧の可能性を残すためです。

  正常な部分がはっきりしていれば、正常と確認されていない部分を

      切り離して、部分的に復旧できます。トラブルシューティングの目  

      的が、その被害を最小限に抑えることであることを考えれば、部分的

      復旧は全体的復旧が困難な場合の次善策として有効です。

  状況の把握で是非行ってほしいことがあります。それは、トラブル

      を起こしたおもちゃがどのような機能が関係しあって全体を成してい      るかを知ることです。これが出来ると大まかですが正常に動いている

      時の状態がわかってきます。そう云う点からも「問診」で「機能ブロ

      ック図」が描けるようにしましょう。機能ブロック図は状況把握と原

      因把握の強力な手段です。現状把握をしないで仮説を立てているド

     クターを見掛けますが、多くの時間を費やして治らなかったり、更に

      悪化させてしまいます。お客様の期待に応える事よりもドクターの楽

      しみを優先することに繋がってしまいます。

 

  状況の把握で是非行ってほしいことがあります。それは、トラブルを起こしたおもちゃがどのような機能が関係しあって全体を成しているかを知ることです。これが出来ると大まかですが正常に動いている時の状態がわかってきます。

 そう云う点からも「問診」で「機能ブロック図」が描けるようにしましょう。機能ブロック図は状況把握と原因把握の強力な手段です。

 現状把握をしないで仮説を立てているドクターを見掛けますが、多くの時間を費やして治らなかったり、更に悪化させてしまいます。

 お客様の期待に応える事よりもドクターの楽しみを優先することに繋がってしまいます。

 

2. 原因の切り分け

  原因の切り分けの基本的な考え方は、状況把握の場合と同じく、正常と確認された範囲を広げていくことです。そして、原因を切り分けて対処する際には、次の原則に従います。

 

■ 両端から内側 おもちゃの場合は特に分解しないで済む箇所から対処することは大事です。両端とは最初の入力側と最後の出力側です。これはおもちゃのトラブルシューティングにおける原則です。 

 原因分析の基本は、正常と確認できた範囲を広げていくことですが、この原則を機能のブロック図(化)に適用します。機能は階層構造で整理できます。階層では、ハードウェア的な機能を基盤として、人間に近づく方向で機能を重ねています。通常は、3階層で考えると効率的です。

巻末の例を参考に理解して下さい。

 

機能ブロックは、入力→処理(機能ブロック)→出力で関係づけられていますからブロックひとつひとつ動作確認をして、正常な範囲を広げていきます。

■ 一つ一つ結果で確認

   ひとつひとつ結果で確認これは動作確認についての原則です。

まず、対処は「ひとつひとつ」行います。複数の原因がある場合は、まとめて確認してはいけません。この方法は、うまくいけば時間を短縮できます。 しかし、失敗すると、どの原因の仮説が誤っていたのか、知る手段がありません。そのため、すべてやり直しになり、大きな時間のロスが発生します。ひとつひとつ確認すれば、たとえ原因の仮説が誤っていても、それが誤りであることが判明し、一歩前進します。

  まとめて確認する方法は、トータルで見ると時間的ロスが大きくなります。そして、確認は「結果」で行います。できる限り実際に動作させ、その結果で確認します。

 

3.~5. 原因の仮説、対処と検証

 原因分析は、できる限り理論的に進めます。しかし、理論的な分析だけでは原因が特定できない場合があります。そのような場合には、原因の仮説を立てます。そして、ひとつひとつ対処を兼ねて検証していきます。

  ここで注意しなくてはならないのは、仮説は誤っている可能性がある点です。そのため、対処を行っても改善しないこともあります。また、さらに状況が悪化しうることもあります。

 

我孫子おもちゃの病院( Dr. T. Fukuoka)

上の図は此処からダウンロードしてください。

トラブルシューティング.プラレール.jpg
JPEGファイル 168.2 KB