はじめに
業務では問題がつきものです。エラーが発生する、そもそも動かない、想定外の挙動になるなど、問題の解決に多くの時間を取られてる人も多いはずです。
そんなとき、とりあえず調べる・とりあえず聞く、になっていませんか？
自分も最初はそうだったのですが、時間だけかかって解決できない、状況説明がうまくできないことが多くありました。
ですが、「問題の切り分け」を意識してからは、格段に問題解決が早く正確に低負荷でできるようになりました。
この問題の切り分けは日常でも使える考え方です。
この記事では、自分が実務で意識している切り分けの考え方と、実際の使い方を紹介します。
目次
背景・課題
私は業務で産業用ロボットの組み込み開発をしています。
ロボットは「機械」「電気」「ソフト」の3つの要素で構成されており、どれか一つでも問題があると、期待通りに動作しません。
その中で私はソフトを担当していますが、実際にロボットを動かす際にトラブルが発生すると、その原因が自分の作成したソフトなのか、ほかの電気や機械なのかわからない状態から調査が始まります。
最初の頃は、自分のコードに問題があるのではと考えてコードとにらめっこをして、それでもわからない場合はロボットが動かないという状況だけをほかの担当者に伝えるだけでした。
当然、時間はかかる上に状況を伝えられた担当者も情報がほとんど増えていないため、さらに調査の時間がかかってしまいました。
このような状況で重要になるのが「問題の切り分け」です。
問題の切り分けの考え方
問題の切り分けの考え方として参考になるのが「対照実験」です。
一言で表すと「調べたい要素以外は固定する」という考え方です。
たとえば、光合成をするための条件を調べるときに以下のパターンで実験したとします。
Aは「日光あり」「空気あり」「葉緑体あり」
Bは「日光なし」「空気あり」「葉緑体あり」
この条件でAのみが光合成を行った場合、光合成には日光が必要ということがわかります。
この考え方は業務でも同じです。私の場合はまず以下のパターンで調査をします。
Aは「同じ機械」「同じ電気」「自分が変更したソフト」
Bは「同じ機械」「同じ電気」「動作実績のあるソフト」
この条件でBのみが動いた場合、自分の変更したソフトに問題があると推測できます。
また、ソフトに問題があると分かった場合でも、さらにその中で切り分けが必要になります。
・どの変更が影響しているのか
・特定の条件でのみ発生するのか
・再現性があるのか
といったように、同じ考え方で範囲をさらに絞っていきます。
ここで大事なのは「一度に一つだけ変える」ということです。
複数の要素を同時に変えてしまうと、どれが原因なのか分からなくなるためです。
遠回りに見えても、一つずつ確認した方が結果的に早く解決できます。
思考プロセス
問題の切り分けを行う際に私が考えていることをお話しします。
全体を通して「ほかの人に説明できるか」という意識をしながら調査を行います。
1. 現象を正しく把握する（事実と推測を分ける）
最初に行うのは、目の前で起きている現象を事実ベースで整理することです。
・どのタイミングで発生したのか
・どの操作をすると再現するのか
・どんなログやエラーが出ているのか
ここでは「たぶん○○が悪い」「おそらく××が壊れている」といった推測は一切入れません。
正常系がAであるべきだが、実際はBになってしまっているというように、あるべき姿とその乖離について事実のみを洗い出します。
2. 原因候補を広く洗い出す
次に原因を考えますが、最初から絞り込まないことが重要です。
・機械的な問題
・電気的な問題
・ソフトウェアの問題
・外部環境の影響
・設定ミス、手順ミス
この段階では「自分の担当だからソフトが怪しいはず」といった思い込みは禁物です。
あくまで可能性のリストアップに徹します。
漏れなくリストアップするには「レイヤーを合わせる」ことが大切です。
機械的な問題は「センサの問題」「信号の問題」のように細分化できますが、これは「電気的な問題」とはレイヤー(問題の分解のレベル)が違います。
なるべく問題のレイヤーを合わせることでリストアップの漏れを減らすことができます。
3. 優先順位をつける（原因確率 × 調査速度）
原因候補が出そろったら、次は優先順位をつけます。
・直近の変更箇所はどこか
・過去に似たトラブルはあったか
・影響関係が強い部分はどこか
・すぐに検証できる内容か
などの情報を組み合わせて調査の優先順位をつけます。
優先順位のつけ方として原因の確率が高いものから調べるのがセオリーですが、それと同じくらい調査にかかる速度も重要だと考えています。
可能性が低くても数分で調べられる内容であれば、そちらを優先するのも合理的です。
4. 対照実験を行う
ここで初めて手を動かして調査を行います。
優先順位に沿って、一度に一つだけ変える対照実験を組みます。
・ソフトだけを差し替える
・センサだけを交換する
・条件を変えて再現性を確認する
・設定値を一つだけ戻す
可能であれば正常な状態を作成してから、対照実験を行うと調査がスムーズに行えます。
「変えた結果、何が分かるか」を明確にしたうえで実験を行うことを意識しましょう。
5. さらに調査する
実験の結果を見て、原因候補を更新します。
・予想通りなら、原因候補をさらに絞る
・予想外なら、原因候補を修正する
・わからない場合は相談する
予想通りであれば、原因候補を細分化してさらに調査を行います。
このサイクルを繰り返して原因究明に努めます。
また、思った通りの結果にならなければ、ほかの人に相談するのも手です。
これまでの過程で、事実に基づいた判断材料は集まっているので、有識者が見ればすぐに解決できるかもしれません。どんな調査を行って、どんな結果になったかという事実を伝えましょう。
実例
ここでは、実際に私が経験したトラブルをもとに、前章で紹介した思考プロセスがどのように役立ったのかを紹介します。
1. 現象を正しく把握する
従来は専用ツールで確認してたセンサの状態ですが、新しく「Webからセンサ状態を確認できる機能」を追加しました。
その機能のテストしていたところ、どれだけ操作してもセンサ値が表示されないという問題が発生しました。
・Web画面は正常に表示される
・センサ自体はロボット側の専用ツールでは正常に読めている
・エラー自体は発生していない
・再現性は100%（毎回表示されない）
状況は上記のとおりです。とにかく手を動かして調べたい気持ちもありましたが、
最初は情報集めに徹しました。
2. 原因候補を広く洗い出す
現象を整理したうえで、原因になり得るものをレイヤーを揃えて列挙しました。
・機械的な問題：センサ自体の故障
・電気的な問題：配線不良、信号が届いていない
・ソフトウェアの問題（パラメータ設定）：パラメータ設定のミス
・ソフトウェアの問題（内部処理）：内部処理の実装ミス
・設定・手順の問題：初期化手順の抜け、必要なモード設定漏れ
この段階では「自分の担当だからWebが怪しい」と決めつけず、
あくまで“可能性の棚卸し”に徹しました。
3. 優先順位をつける（原因確率 × 調査速度）
次に、どこから調べるのかを決めました。
①ソフトウェアの問題（パラメータ設定）
⇒ 可能性が高く、検証比較的容易
②機械的な問題
⇒ こちらも可能性が高く、直前にセンサを変更していた
③電気的な問題
⇒ 可能性は低いが、スペアがあるため検証が容易
④設定・手順の問題
⇒ 可能性は低いが、検証は容易
⑤ソフトウェアの問題（内部処理)
⇒ 可能性が高いが、新規案件かつ変更規模が大きく、検証に時間がかかる
「原因確率 × 調査速度」で考えると上記の順番で調べるのが効率的だと判断しました。
4. 対照実験を行う
優先順位に沿って、一つずつ検証しました。
①ソフトウェアの問題（パラメータ設定）
⇒ 複数のロボット、パラメータで検証し、すべて動作しないため原因ではない
②機械的な問題
⇒ 専用ツールではセンサの値を取得可能のため、原因ではない
③電気的な問題
⇒ スペアでも動作しないため原因の可能性は低い
④設定・手順の問題
⇒ 仕様書を改めて確認すると、自分の見ていた仕様書は最新版ではなかった
このことから、モノに問題があるのではなく、手順に問題があるのではという仮説が強まりました。
5. さらに調査する（仮説の更新）
最新の仕様書を確認すると、センサ値をWebで取得するには、ロボット側で“あるモードを有効化する必要がある” ということがわかりました。
専用ツールでは自動でモードが切り替わるため気づいていませんでしたが、
Web経由では手動で設定する必要があったのです。
設定を有効化して再度アクセスすると、
問題なくセンサ値が表示されました。
6. 最終的な原因
今回の問題は、実装やモノの不具合ではなく、私の確認手順の抜けが原因でした。
ただし、思考プロセスに沿って
・事実を整理し
・原因候補を広く洗い出し
・優先順位をつけて調査
を行ったことで、短時間で原因にたどり着くことができました。
仮に上記の手順を踏まなかった場合は、いきなり原因の可能性の最も高いソフトの実装の調査に時間を費やしていたかもしれません。
しかし、今回のように思考プロセスに沿って調査を進めたことで、「実装が悪いはずだ」という思い込みに引きずられず、事実ベースで原因を切り分けることができました。
また、この一連の流れは、ソフトウェア開発に限らず、様々な場面で活かすことができます。
そして何より、「他の人に説明できる状態で調査する」という意識が、
思考の整理と判断の精度を大きく高めてくれます。
おわりに
問題が発生したとき、私たちはつい「原因を当てにいく」行動を取りがちです。
しかし、今回紹介したように、事実を整理し、原因候補を広く洗い出し、
優先順位をつけて一つずつ検証していくというプロセスを踏むことで、
問題解決は驚くほどスムーズになります。
この考え方は、ロボット開発のように複数の要素が絡み合う領域だけでなく、
日常のちょっとしたトラブルにも応用できます。
私は少し前にswitch2を購入しましたが、
モニタに画面が映らないという問題が発生しました。
ですが、ドッグやHDMIの配線周りや通信周りなど、問題の切り分けによって
すぐに解決できました。
問題解決はセンスではなく、再現性のあるスキルです。
今日紹介したプロセスを意識するだけで、明日からの調査効率は確実に変わります。
この記事が、あなたの業務や開発の一助になれば幸いです。
そして、あなた自身の“問題の切り分け力”が、これからさらに磨かれていくことを願っています。