FAエンジニアからITへ。意外と変わらなかった「問題の解き方」

私はこれまで、FA分野のフィールドエンジニアとして現場対応を経験し、その後IT分野の仕事にも携わってきました。
FAとIT。
扱うものだけを見れば、かなり違うように感じます。
FAでは、設備や機器、センサー、画像検査装置など、実際に現場で動いているものを相手にします。
一方、ITではプログラムやシステム、データベースなど、画面の中で動いているものを扱うことが多くなります。
私自身も、最初はまったく違う仕事になるような感覚がありました。
しかし、実際にITの仕事を経験してみると、
「問題が起きたときの考え方は意外と変わらない」
と感じることが多くありました。
今回は、FAの現場経験とITの仕事を通じて感じた、共通する「問題の解き方」について書いてみたいと思います。

まずは「何が起きているのか」を確認する

FAの現場では、
「設備が止まった」
「検査がうまくいかない」
「センサーが反応しない」
といった問い合わせを受けることがあります。
しかし、「動かない」という情報だけでは、原因を判断することはできません。
いつから発生しているのか。
常に発生するのか。
特定の製品だけで発生するのか。
直前に設定変更をしていないか。
まずは現象をできるだけ具体的にしていきます。
これはITでも同じでした。
「システムが動かない」
と言われても、
ログインできないのか。
画面が表示されないのか。
データを保存できないのか。
特定の操作だけ失敗するのか。
内容によって確認する場所はまったく違います。
まず原因を考える前に、
「何が正常で、何が異常なのかを整理する」
という部分は、FAでもITでも変わらないと感じました。

「どこまでは正常か」を確認する

トラブルが発生したとき、いきなり原因そのものを探すのは難しいことがあります。
そのためFAの現場では、
「電源は入っている」
「PLCから信号は出ている」
「センサーまでは反応している」
「機器との通信はできている」
というように、一つずつ確認していきます。
正常な部分を確認しながら、異常が発生している範囲を狭めていく考え方です。
ITの障害調査でも同じような進め方をします。
たとえば、画面にデータが表示されない場合、
「データベースにはデータがある」
「APIからは正常に取得できている」
「画面まで値は渡っている」
と確認していけば、問題の範囲を徐々に絞ることができます。
扱っているものは違いますが、
問題を小さく切り分けていく
という基本的な考え方は共通していました。

正常なものと比較する

FAの現場でよく行っていたのが、正常に動いている状態との比較です。
たとえば、同じ設備が複数台ある場合、
「正常な設備ではこの設定がどうなっているか」
を確認します。
設定値や配線、信号の状態などを比較すると、違いが原因を見つけるヒントになることがあります。
ITでも、
「自分の環境では動かないが、別の環境では動く」
というケースがあります。
その場合、
・設定ファイル
・バージョン
・インストールされているソフトウェア
・接続先
・権限
などを比較していきます。
「正常なものと異常なものの違いを探す」
という方法は、非常にシンプルですが、今でもよく使う考え方です。

直前に変えたものを確認する

「昨日までは動いていたのに、今日から動かなくなった」
というトラブルもよくあります。
こうした場合は、
正常だった状態から何が変わったのか
を確認します。
FAであれば、
・機器を交換した
・設定値を変更した
・製品が変わった
・設備の調整を行った
といった変更があります。
ITであれば、
・プログラムを修正した
・ライブラリを更新した
・設定ファイルを変更した
・OSやミドルウェアを更新した
といったものが考えられます。
原因が分からないときほど、いろいろな場所を触りたくなります。
しかし、まず、
「問題が起きる直前に何を変更したのか」
を確認するだけで、調査範囲をかなり狭められることがあります。

一度にいろいろ変更しない

トラブルを早く解決したいときほど、
「ここも怪しい」
「これも変えてみよう」
と複数の場所を変更したくなることがあります。
ただ、一度にいろいろ変更すると、問題が解決したとしても、
何が原因だったのか分からなくなる
ことがあります。
FAの設備でも、複数の設定値を一度に変更してしまうと、どの変更によって挙動が変わったのか判断できなくなります。
ITでも同じで、複数のコードや設定を一気に変えてしまうと、原因の特定が難しくなります。
そのため、
「一つ変更する」
「確認する」
「結果を見る」
という流れを意識します。
遠回りに見えますが、結果的にはこの方が原因を正確に特定しやすいと感じています。

現場では「想定外」が起きる

仕様書や設計上では問題がなくても、実際の現場では想定していなかったことが起きます。
FAでは特に、
温度や照明、製品の個体差、設置状態など、机上では分かりにくい要素があります。
たとえば画像検査では、プログラム上は問題がなくても、実際の製品や照明条件によって判定が安定しないことがあります。
そのような場合は、現場を見ながら、
「なぜこの条件だけ失敗するのか」
を一つずつ確認していきます。
ITでも、
「仕様上は問題ないはずなのに、実際に使うとうまくいかない」
ということがあります。
実際のデータ、ユーザーの操作、通信環境など、作った側が想定していなかった条件が原因になることもあります。
そのため、
仕様だけを見るのではなく、実際に何が起きているのかを見る
という考え方は、今でも大切にしています。

「原因」と「現象」を分けて考える

トラブル対応をしていると、
「ここが原因だと思います」
と早い段階で決めつけてしまうことがあります。
しかし、最初に見えているものはあくまで「現象」であり、本当の原因とは限りません。
たとえば、
「センサーが反応しない」
という現象があったとしても、
原因はセンサー本体ではなく、配線や設定、別の機器側にある可能性があります。
ITでも、
「データベースエラーが出ている」
からといって、必ずしもデータベース自体に問題があるとは限りません。
接続設定やプログラムから渡している値が原因かもしれません。
目の前に出ているエラーだけで判断せず、
「なぜこの現象が起きているのか」
を考えることが重要です。

分からなければ情報を集める

現場に出ていると、その場で答えを求められることがあります。
しかし、すべてのトラブルをその場で即答できるわけではありません。
分からないときには、
・マニュアルを見る
・過去の事例を確認する
・ログを確認する
・詳しい人に相談する
・メーカーに問い合わせる
など、必要な情報を集めます。
ITでも同じです。
公式ドキュメントやログ、GitHubのIssue、過去の対応履歴、生成AIなど、調査に使えるものは多くあります。
重要なのは、すべてを覚えていることよりも、
必要な情報を探して、問題解決につなげられること
なのではないかと思います。

お客様の言葉を、そのまま原因だと思わない

フィールドエンジニアとして仕事をしていたとき、
「この機械がおかしい」
「この機能が壊れている」
と説明を受けることもありました。
もちろん重要な情報ですが、それは実際に起きている現象を利用者側の視点で表現したものです。
そのため、そのまま原因として判断するのではなく、
「具体的に何をすると、どうなるのか」
を確認していきます。
ITでも、
「ネットが遅い」
「システムが重い」
「ログインがおかしい」
という言葉だけでは、原因は分かりません。
相手から聞いた情報をもとに、技術的に確認できる形へ整理する必要があります。
これは技術力とは少し違いますが、問題を解決するうえで非常に重要な力だと感じています。

FAで学んだ経験はITでも無駄にならなかった

FAからITへ分野が変わったとき、
「これまでの経験はどこまで活かせるのだろう」
と考えることがありました。
もちろん、扱う技術は大きく違います。
新しく覚えなければならないことも多くありました。
しかし、
・現象を整理する
・正常な範囲を確認する
・問題を切り分ける
・正常なものと比較する
・変更箇所を確認する
・一つずつ検証する
・必要な情報を集める
という問題解決の流れは、ほとんど変わりませんでした。
技術そのものは変わっても、
「分からない問題を、分かる状態にしていく」
という仕事の本質は似ているのかもしれません。

まとめ

FAとITでは、扱う機器や技術、仕事をする環境は大きく異なります。
しかし、問題が起きたときの考え方には多くの共通点があります。
いきなり答えを探すのではなく、
「何が起きているのか」
「どこまでは正常なのか」
「何が変わったのか」
「正常な状態との違いは何か」
を一つずつ確認していく。
これはFAでもITでも変わりませんでした。
新しい分野に進むと、それまでの経験がすべてリセットされるように感じることもあります。
しかし、技術だけではなく、
これまで仕事の中で身につけてきた「問題の考え方」も立派な経験の一つ
だと思います。
私自身も、FAの現場で身につけた問題の切り分け方や調査の進め方を活かしながら、これからも新しい技術を学び、対応できる範囲を広げていきたいと思います。