プログラム不具合に対する向き合い方

<はじめに>
私は機械装置を制御するPLCプログラム設計を行っている者です。

工場あります、機械設備の制御部分の大半はPLCというコントローラで行われており、そのコントローラは記述されているプログラム通りに機械を動かします。

機械設備を動かすにあたり、当然、複雑な動作を要求されることもしばしばあります。

複雑な動作を行うということは、複雑なプログラムを要求されているのと同義であり、プログラムを色々な角度でチェックする必要が出てきます。

チェックを行えばより良くプログラムは完成することができますが、なかなか複雑な装置に色々な角度からチェック動作を行うのは至難の技です。

そして、プログラムは必ず不具合が発生します。

不具合もあればお客様要望で追加したものもありますので、対応がすごい難しいです。

今回はそんな不具合と、どう対応するかの姿勢を紹介します。

<不具合発生時の正しい対応姿勢>
基本的にプログラムは不具合と隣り合わせということを理解する必要があります。

不具合の定義は、
「お客様の要望通りに動かない。」
「このタイミングだとうまく動かない。」

などなど、定義は幅広いですが、基本的にはプログラムの記述が上手くない、そもそも、想定されていない動き。が発覚し、不具合となります。

ここで定義されたのは、プログラム作成者側の不具合となります。

このような不具合となれば、真摯に、即対応するのが好ましいでしょう。

言い訳などせず、誠心誠意謝り、対応するのが良いです。

ただ、これは違うという場合もあります。

例えば、そもそも仕様外の動作や、このチェック機能を追加してほしい。という要望に近いもの。

そう、なぜ要望を挙げたかというと、かなり高い傾向として、要望すらも不具合と認定されることがあるからです。

「えっ？」と思った方、正しいです。

本来、要望は追加です。

なぜ、こうなるかと言うと、「すべての人は、人に任せた仕事の大半を把握していない」からです。

「えっ？！そんなことある？？」と思うでしょう。

世の中そんなもんです。

仕事というのは、だいたいその道のプロに作業してもらいます。

自分が他人に仕事を出す場合、他分野の仕事をお願いする場合が多くなるわけです。

例えば家。

外壁塗装はどこにお願いしますか？
そう、塗装屋さん。ただ、塗装についてあなたは詳しいですか？

そうなんです、詳しくないんです。

これが、プログラムでも起こります。

詳しくない相手が中間に入るお陰で、本来仕様外の話が不具合と認定されることが起きてしまうのです。

そのような場合は、「仕様外なので追加です」と言った方がよいでしょう。

中間に入る人は何が追加かもよくわかっていないことが多いので、このような対応がよいです。

<不具合は悪ではない>
そもそも不具合を悪と認識するから良くないのです。

考え方を改めましょう。

あるおもしろい事例をお話しします。

正直、お世辞にもできる人ではないAさんがいました。Aさんはだいたい何をやってもミスが多く、ただ、現場にはよく行くタイプでした。

一方、Bさんはある程度仕事ができ、大きいトラブルも少ないです。

そんな二人が一緒に仕事をしたとき、AさんよりさきにBさんの仕事が終わりました。

Bさんが行った作業範囲はトラブルも少なく、大きな問題にはなりませんでした。

一方、Aさん、作業の手も遅く、作業漏れも多く、さらに現場ではしてはいけないことをしてお客様からクレームが入るほどでした。

クレームが入る前に、現場ではお客様からお叱りを頂き、工場中に響き渡るほどの声量でした。

ですので、Aさんは現場にずっといました。怒られても作業を完遂させるまでずっと。

ここまで聞いたらどうでしょうか？

Aさんヤバイ。Bさんに仕事を任せたい。そう思うのではないでしょうか？

そりゃミスなくやってくれた方が良いですよね？

それはそうです。たしかにミスなくやった方がお客様も喜びます。ただ、実はここに落とし穴があります。

実は、Bさんのミスも、Aさんが対応していたのです。Bさんはなまじ頭が良く、効率を考えるタイプで、Aさんが現場にいるならミスを直しておいてよと。

また、他の部署のミスもAさんが現場で対応していたのです。

そう、お客様はのちにAさんが色々対応しているのを知り、また、お客様が怒ろうが最後まで作業をしてくれたことに感謝していました。

そして、再度、Bさんが現場へ行ったときには、お客様はBさんのことは覚えておらず、Aさんとは仲良さげに話をしていたのです。

どうですか？

最初はBさんの方がよいと思った方も、最後だけ切り取ればAさんの方がよいと思いますよね？

これが、現場と本社(会社にいる人たち)との認識の誤差です。

ミスしてずっと現場に行っているよ、大変だね

これが実は、社内的な評価は落ちますが、現場での評価は上がります。

つまり、社内と現場の評価は結構相反することが多く、また、不具合にも真摯に対応していると、逆にお客様から好かれるということになるのです。

社内的な評価はBさんの方が高いです。

ただ、その現場にいけば確実にAさんの評価が高いです。

ですので、不具合というのはあくまでもコミュニケーションツールと思わないといけないです。

相手に顔を覚えてもらう、貸しを作る作業と思えば非常に楽しくなります。

不具合だからやばい！
たしかにそれもありますが、不具合が発生したときこそ、営業チャンスなのです。

自分の名前や顔を覚えてもらえる絶好の機会なのです。

これを利用できるかできないかで、すべて変わってきます。

不具合は悪ではなく、営業チャンスだと思いましょう！

<終わりに>
プログラムには不具合が付き物。

付き物を敬遠したところで良いことはなく、付き物とどう接するか、が大切です。

長い付き合いをする相手に、邪険にあしらうと痛い目を見ます。

私も痛い目をみました。

そのおかげで、今、不具合と正しく向き合うことができています。

どうやって回避するかも大切ですが、どうやって付き合うかも大切にしてみると、相手からの信頼度が格段に上がります。

責任を持って対応してくれる、そんな評価を受けられるようになると、どんどん仕事が来るでしょう。

自分なりの不具合との向き合い方を考えてみてください！