前世からの因果なのか問題が起こると必ず呼ばれる。時々私自身が原因だったりすることはあるが、それは初期の頃の話。駆け出しに完璧を求めてはいけません！それが続いて挙げ句の果てに何かの会議に呼ばれて移動していると、見かけられた先輩や上司に「また、お前か！」と云われる始末。そして貧乏神化するのである。いや貧乏神ならまだましかも知れない。
さて一言でトラブルシューティングといっても、色々なアプローチがある。当時はそんなに意識していたわけではないし、今も整理できているわけではないが、こんな感じだろうか。
１：顕在化した現象から丁寧に 1 step づつ理論的に追っていく
いわゆる問題分析の王道ってやつだ。「ここでこういう現象が出ているのだから、その手前はこうなっているはずで」というのを繰り返していくのである。王道と云えばまさにそうだが、初心者向けではない。各ステップの繋がりをかなりの精度で理解していないと現象を追えないのである。波形を見ても異常と気づかなかったら解決には至らない。この方法は少なくともアナログ的要素を含むシステムではある程度のベテラン技術者と若手が一緒に現象を追いながらあれこれとやっていくとノウハウがたまる。
その一例がこれ。
SCSI 三部作完結編。インターフェースとメカコンの不思議な関係！
http://blogs.yahoo.co.jp/susanoo2001_hero/6914127.html
このときは私もそんなにベテランというわけでもなく、一緒にやった F 君も優秀な人だったので二人で取り組んだのが良かったのだが。
２：関連するパラメータを総当たりに変化させて、解決しそうな方向を探し出す
問題分析の邪道と云われてしまうかも知れない。実際にはこれで解決してしまうことも多いだろう。エンジニアではなくチェンジニアなどと云われる手法である。確かにそこで解決してそのままにしてしまえば、エンジニアとしてのスキルアップにはほとんどなっていない。しかし「なぜこのパラメータで変化したのだろうか」まで深堀すれば、１．に近づく、知識も増える、ということでそんなに馬鹿にしたものではない。そこで得た知識を博学な人に見せて議論すればさらに有用である。
さらに各要素の入出力関係が数式で表すことが出来ない、他の要素の影響を受けやすい物であるならば実験計画法を用いて効率化することも可能である。
３：どうやったらそういう問題を意図的に起こすことができるか考える
私が多用した方法が実はこれ。特に人が設計した物のトラブル分析する場合は設計の詳細が分かっていないので、この不具合現象を起こすにはどう設計すればいいか、という発想でアプローチする。元の設計を否定するような内容に聞こえるが、実際には設計者の意図通りに物が作られていないことの方が多い。前回紹介したモータのトラブシューティングなどもこれに近い。このアプローチは設計力が必要なので、中級者以上向け。
４：考えられる原因を出来るだけたくさん挙げて一つ一つ検証する
これは知識とセンスが必要とされるアプローチである。ひと目十項目、ちょっと考えて百項目挙げられれば上級者である。もちろんその中には「元々動く設計になっていない」「配線が間違っている」「電源が入っていない」「間違った部品が使われている」などの即座に否定できる内容も含んでいて良い。とにかく数を挙げることが重要である。推理が好きな人向けだが、検証には知識が必要なのでトレーニングにも良い。
５：心を透明にして現象を見つめ閃くのを待つ
「画蔵はオカルト主義だったのか！」と云われそうだが、そうではない。古いネタで恐縮だが昔のアメリカの人気刑事ドラマ「刑事コロンボ」でコロンボ刑事の台詞に「あたしゃ～ね。、現場で耳を澄ましてみるんですよ。そうするとね回りから色んな声が聞こえてくるような気がするんです。あいつが犯人だ、証拠はこれだってね」というのがあった（正確ではないが）。
まあそういうことだ。直感というのは高速の無意識論理的思考という説もある。
ちょっと話はそれるが 30 年ほど前にドリップ式珈琲の自動販売機が私のいた工場に配置されたとき、インスタントよりやはり美味しいといことで人気だったのだが、しょっちゅうトラブっていた。そこで伝説の K 主幹というメカの神様みたいな方が、サービスマンが来たときに「私にも見せてくれ」といって、中の動きをずっと見ていて「う～ん、これだ！」といって何かが閃いて、その場で追加部品を設計して工作課に発注し部品を入手して（こんなことが出来てしまうのどかな時代でした）直してしまった、ということがあった。見るべき人が見ればひと目なんだな～。
ということで、直感も馬鹿にしたものではない。考えすぎて混乱してきた場合はこういう手もある。
場外乱闘編：誰が設計したかを考えるて、それを起点に推理する
設計した人物のキャラを考えて、あいつならこういうチョンボをやりそうだと推理して原因を突き止めるやり方だ。割と解決に至る確率は高い。が、当たっても決してそのことを口外してはいけない。今度は人間関係が悪くなる。私も後輩に思いっきり嫌われたことがある。
ま、概ねこんなところだろうか。が、これらのアプローチは本質的には同じことをやっているのだと思う。人それぞれ思考回路が違うから自分と状況に合った方法を選べばよいし、他にも色々考えられるだろう。いずれにせよトラブルシューティングは最終的には幅広い知識と深さが必要なので、トラブルに遭遇しても逃げずに立ち向かっていけばエンジニアとしてのポテンシャルは確実にアップする。
参考になれば幸いである。
← にほんブログ村「科学」－「技術・工学」へ
↑ クリックをお願いします。
さて一言でトラブルシューティングといっても、色々なアプローチがある。当時はそんなに意識していたわけではないし、今も整理できているわけではないが、こんな感じだろうか。
１：顕在化した現象から丁寧に 1 step づつ理論的に追っていく
いわゆる問題分析の王道ってやつだ。「ここでこういう現象が出ているのだから、その手前はこうなっているはずで」というのを繰り返していくのである。王道と云えばまさにそうだが、初心者向けではない。各ステップの繋がりをかなりの精度で理解していないと現象を追えないのである。波形を見ても異常と気づかなかったら解決には至らない。この方法は少なくともアナログ的要素を含むシステムではある程度のベテラン技術者と若手が一緒に現象を追いながらあれこれとやっていくとノウハウがたまる。
その一例がこれ。
SCSI 三部作完結編。インターフェースとメカコンの不思議な関係！
http://blogs.yahoo.co.jp/susanoo2001_hero/6914127.html
このときは私もそんなにベテランというわけでもなく、一緒にやった F 君も優秀な人だったので二人で取り組んだのが良かったのだが。
２：関連するパラメータを総当たりに変化させて、解決しそうな方向を探し出す
問題分析の邪道と云われてしまうかも知れない。実際にはこれで解決してしまうことも多いだろう。エンジニアではなくチェンジニアなどと云われる手法である。確かにそこで解決してそのままにしてしまえば、エンジニアとしてのスキルアップにはほとんどなっていない。しかし「なぜこのパラメータで変化したのだろうか」まで深堀すれば、１．に近づく、知識も増える、ということでそんなに馬鹿にしたものではない。そこで得た知識を博学な人に見せて議論すればさらに有用である。
さらに各要素の入出力関係が数式で表すことが出来ない、他の要素の影響を受けやすい物であるならば実験計画法を用いて効率化することも可能である。
３：どうやったらそういう問題を意図的に起こすことができるか考える
私が多用した方法が実はこれ。特に人が設計した物のトラブル分析する場合は設計の詳細が分かっていないので、この不具合現象を起こすにはどう設計すればいいか、という発想でアプローチする。元の設計を否定するような内容に聞こえるが、実際には設計者の意図通りに物が作られていないことの方が多い。前回紹介したモータのトラブシューティングなどもこれに近い。このアプローチは設計力が必要なので、中級者以上向け。
４：考えられる原因を出来るだけたくさん挙げて一つ一つ検証する
これは知識とセンスが必要とされるアプローチである。ひと目十項目、ちょっと考えて百項目挙げられれば上級者である。もちろんその中には「元々動く設計になっていない」「配線が間違っている」「電源が入っていない」「間違った部品が使われている」などの即座に否定できる内容も含んでいて良い。とにかく数を挙げることが重要である。推理が好きな人向けだが、検証には知識が必要なのでトレーニングにも良い。
５：心を透明にして現象を見つめ閃くのを待つ
「画蔵はオカルト主義だったのか！」と云われそうだが、そうではない。古いネタで恐縮だが昔のアメリカの人気刑事ドラマ「刑事コロンボ」でコロンボ刑事の台詞に「あたしゃ～ね。、現場で耳を澄ましてみるんですよ。そうするとね回りから色んな声が聞こえてくるような気がするんです。あいつが犯人だ、証拠はこれだってね」というのがあった（正確ではないが）。
まあそういうことだ。直感というのは高速の無意識論理的思考という説もある。
ちょっと話はそれるが 30 年ほど前にドリップ式珈琲の自動販売機が私のいた工場に配置されたとき、インスタントよりやはり美味しいといことで人気だったのだが、しょっちゅうトラブっていた。そこで伝説の K 主幹というメカの神様みたいな方が、サービスマンが来たときに「私にも見せてくれ」といって、中の動きをずっと見ていて「う～ん、これだ！」といって何かが閃いて、その場で追加部品を設計して工作課に発注し部品を入手して（こんなことが出来てしまうのどかな時代でした）直してしまった、ということがあった。見るべき人が見ればひと目なんだな～。
ということで、直感も馬鹿にしたものではない。考えすぎて混乱してきた場合はこういう手もある。
場外乱闘編：誰が設計したかを考えるて、それを起点に推理する
設計した人物のキャラを考えて、あいつならこういうチョンボをやりそうだと推理して原因を突き止めるやり方だ。割と解決に至る確率は高い。が、当たっても決してそのことを口外してはいけない。今度は人間関係が悪くなる。私も後輩に思いっきり嫌われたことがある。
ま、概ねこんなところだろうか。が、これらのアプローチは本質的には同じことをやっているのだと思う。人それぞれ思考回路が違うから自分と状況に合った方法を選べばよいし、他にも色々考えられるだろう。いずれにせよトラブルシューティングは最終的には幅広い知識と深さが必要なので、トラブルに遭遇しても逃げずに立ち向かっていけばエンジニアとしてのポテンシャルは確実にアップする。
参考になれば幸いである。
← にほんブログ村「科学」－「技術・工学」へ↑ クリックをお願いします。