不具合の原因はプログラムではなかった

現場で見えた「確認工程」の大切さ

先日、友人からある装置について相談を受けました。

内容は、Raspberry Piを使って設備の異常信号を検出し、LINEへ通知する仕組みです。

最初は、プログラム側に問題があるのではないかというところから確認を始めました。

コードを受け取り、異常信号を受け取る処理、LINEへ通知する処理、入力条件などを順番に確認しました。

しかし、プログラムそのものに大きな問題は見つかりませんでした。

そこで実機側を確認していくと、原因はソフトウェアではなく、配線にありました。

GPIO17として使用する物理Pin 11を、基板の反対側から数えて接続してしまっていたのです。

今回の不具合は、Raspberry Piやリレーなどのハードウェア故障ではありませんでした。

また、プログラムの基本動作にも問題はありませんでした。

主な原因は、人為的な接続ミスです。

ただし、単純に「配線を間違えた」で終わらせてしまうと、同じことがまた起きる可能性があります。

なぜ間違えたのかを考えると、GPIO番号と物理Pinの位置を確認できる資料が不足していたことや、通電前に配線を照合する手順が明確になっていなかったことも見えてきました。

ここが、今回の大きなポイントでした。

現場では、不具合の原因が必ずしもプログラムや部品の故障とは限りません。

ソフトウェアなのか。

ハードウェアなのか。

人為的な問題なのか。

資料の問題なのか。

確認工程の問題なのか。

これらを分けて考えることで、原因が見えやすくなります。

今回も、単純にプログラムを修正するのではなく、システム全体を見ながら原因を切り分けることで、問題を特定することができました。

そして、原因を見つけるだけではなく、

「次に同じ問題を起こさないためには、何を残すべきか」

そこまで考えることが重要です。

今回であれば、GPIO番号と物理Pinを併記した資料を用意することや、通電前の配線確認を手順として残すことが改善につながります。

現場の不具合を見る時は、点だけを見るのではなく、線で見て、その先の仕組みまで見る。

今回の案件を通して、改めてそう感じました。