――知識の差ではなく「事実の観察」と「状況を好転させる仮説検証」のプロセス
はじめに：「頼られる側」が見ている景色
「パソコンが動かなくなっちゃって……ちょっと見てくれませんか？」
職場で、あるいは身の回りで、そう声をかけられることがよくあります。プリンターが反応しない、インターネットが繋がらない、画面に見慣れない警告が出た、新しく導入されたシステムの使い方がわからない――。
呼ばれてその人の席に行き、キーボードを数回叩き、配線を1本確認し、あるいはスマートフォンで画面を撮影して検索窓に短いキーワードを入れる。数分後、何事もなかったかのように動き出す画面を見て、相手はこう言います。
「すごい、やっぱりパソコン得意なんですね！ 助かりました」
そう感謝されるたびに、ありがたいなと思うと同時に、頭の片隅で小さな疑問が浮かびます。「自分は本当に、相手が思うような『パソコンが得意な人』なのだろうか？」
私自身、プログラミング言語を何十種類も完璧に扱える専門職というわけではありませんし、コンピュータの内部構造をハードウェアレベルで設計できる知識を持っているわけでもありません。
では、パソコンが苦手な人と、頼まれてサッと直してしまう自分の間には、一体どんな違いがあるのでしょうか。
結論から言えば、それは「知識の量の差」ではありません。目の前に起きた現象をどう観察し、どこで問題を切り分け、どうやって仮説を検証しているかという「頭の中のプロセスの違い」です。
そしてこの頭の中の動きは、パソコンのトラブルを解決するときだけでなく、仕事の段取り、人間関係の整理、さらには人材育成や組織運営といった「人を相手にする現場」でも、まったく同じように機能しています。
この記事(前編)では、パソコンが苦手な人に頼られたとき、私が頭の中で具体的に何を考え、どんな順番で手を動かしているのかを紐解いてみたいと思います。後編では、この考え方が機械の外側、つまり人間関係や組織運営でも同じように働いていることを書きます。
第1章：現場に入った瞬間の「観察」――なぜまず文字を読むのか
「読めない」のではなく「見るのを止めている」状態を理解する
トラブルが起きた現場に呼ばれたとき、まず最初に対峙するのは「壊れた機械」ではなく、「困り果てて思考が止まってしまった相手」です。
「急に変な画面になって……もうダメみたいです」 「何もしてないのに壊れました」
そう言われて画面を見てみると、実はそこに明確な答えが書いてあることが少なくありません。
「用紙トレイ1に用紙がありません。用紙をセットしてください」 「ログインの有効期限が切れました。再ログインしてください」
決して大げさではなく、日常的なトラブルの多くは、画面上に「何が起きているか」「次に何をすべきか」が日本語でそのまま表示されています。
では、なぜ苦手な人はそれに気づけないのか。それは相手の能力が足りないからではなく、「機械が思い通りに動かない＝自分には理解できない未知の事態が起きた」と感じた瞬間、脳が画面の文字を情報として処理するのを止めてしまうからです。
パニックや強い苦手意識があると、文字は視界に入っていても「意味のある文章」として頭に入ってきません。結果として、「途方に暮れる」というよりは、「自分には手が出せない」と諦めてしまう状態になります。
一方、頼まれた側の私はどうでしょうか。私はトラブルが起きた現場に「途中から」入っていきます。トラブルが起きた瞬間の焦りや不安を共有していないからこそ、感情を挟まず、客観的なフラットな状態で画面を見ることができます。
だからこそ、私が最初にやることは、特別な魔法を使うことではなく、ただ「画面に表示されている文字を落ち着いて読む」ことなのです。
英語のエラーメッセージを「ただの情報」として受け取る
画面に英語のメッセージが出ると、拒否感はさらに強くなります。アルファベットが並んでいるだけで「何か取り返しのつかない危険なエラーが起きたのではないか」と警戒し、ウィンドウを即座に閉じてしまったり、電源ボタンを長押しして強制終了してしまったりする人がいます。
しかし、英語のエラーメッセージは敵でも警告でもなく、開発者が残してくれた「最も正確なヒント（ログ）」です。
日本のソフトウェアであっても、根底にあるシステムやWebの仕組みは英語圏で作られているものが大半です。そのため、不自然に翻訳された日本語のメッセージよりも、英語のメッセージのほうが原因を正確に指し示しています。
英語が完璧に読めなくても何の問題もありません。今の時代、頭の中で翻訳する必要すらないからです。
- スマートフォンのカメラを向けて、その場で翻訳ツールにかける
- 表示されている英文やエラーコードをコピーして、そのまま検索窓に貼り付ける
これだけで、世界中の誰かが同じ現象に遭遇し、すでに解決した記録（ナレッジ）が数秒で手に入ります。周囲から見ると「英語のエラーを即座に解決した」ように見えるかもしれませんが、頭の中でやっていることは「文字を記号として取得し、検索ツールに渡した」だけに過ぎません。
第2章：頭の中で瞬時に引いている「境界線」――問題切り分けの型
文字を読み、現状の情報を取得したあとに頭の中で行っているのが、「問題の切り分け（境界線を引く作業）」です。
何かが動かないとき、「全体が壊れた」と考えてしまうとどこから手を付けていいかわからなくなります。しかし、システム全体が同時にすべて壊れることは基本的にありません。問題は必ず「境界線のどこか1箇所」で起きています。
外側と内側、ケーブルと本体、ハードとソフト
トラブルを前にしたとき、私の頭の中では以下のような二者択一の分岐（決定木）が自動的に立ち上がります。
［トラブル発生］
├─ 1. 物理的な要因（ハードウェア・配線・環境）
│ ├ 電源やランプはついているか？
│ ├ ケーブルが抜けかけていないか？ 断線していないか？
│ └ 別のポート、別の差し込み口に変えたら動くか？
│
└─ 2. 論理的な要因（ソフトウェア・設定・通信）
├ 再起動しても同じ状態が続くか？
├ 特定のアプリだけで起きているか、PC全体で起きているか？
└ 自分のPCだけの問題か、周囲全体（ネットワーク等）の問題か？例えば「インターネットが繋がらない」と相談されたとき、私は次のように順を追って境界線を狭めていきます。
- 周囲の状況を確認する：隣の人のPCは繋がっているか？（周囲もダメならルーターや回線の問題、自分だけならPC側の問題）
- 物理接続を確認する：LANケーブルはしっかり刺さっているか？ Wi-FiのスイッチがOFFになっていないか？
- 機器の状態を確認する：機内モードになっていないか？ 一度Wi-FiをOFFにしてONにし直したらどうか？
- ソフトの状態を確認する：特定のWebサイトだけが開かないのか、すべての通信が止まっているのか？
このように「外側か内側か」「ハードかソフトか」と境界線を引いていくだけで、原因の候補はあっという間に1〜2個に絞られます。
「そこは見ていなかった」「これから確認するつもりだった」と相手が言うのは、知識がないからではなく、「どこに境界線を引けば問題が小さくなるのか」という切り分けの地図を意識していないからです。
「直前に何をしたか？」という時間軸の差分を探す
空間的な切り分け（配線や本体）と並行して、もうひとつ必ず頭の中で走らせるのが「時間軸の切り分け」です。
機械が理由もなく突然挙動を変えることはありません。必ず「正常だった過去」と「異常が起きた現在」の間に、何らかの変化（差分）が存在します。
トラブル対応に入るとき、私が相手によく聞くのは次の質問です。
「動かなくなる直前に、何かいつもと違う操作をしたり、画面を触ったりしましたか？」
大抵の場合、最初は「何もしていません、普通に使っていただけです」という答えが返ってきます。しかし、過去の操作を一緒に丁寧に振り返っていくと、
- 「そういえば、さっき見慣れないポップアップが出たのでOKを押した」
- 「机の上の配置を変えたときに、足元のコードを少し引っ張った」
- 「新しい周辺機器をUSBに挿した」
といった「直前の変更点」が必ず浮き彫りになってきます。過去と現在の差分を見つけ、直前の変更を元に戻す。これだけで、多くのトラブルは解決に向かいます。
第3章：動機と面白さ――制約があるから知恵が動く
なぜ私は、投げ出さずに原因を切り分け、文字を読み続けることができるのか。そこには、現実的な理由と、試行錯誤そのものが持つ面白さがあります。
「買い替える予算はない」からこそ、あるもので処理する
根底にあるのは極めてシンプルな現実的動機です。「使えないと業務が進まなくて困る。けれど、壊れたからといって簡単に新品を買い替えるわけにはいかない」というコスト感覚です。
新しい機器を買うには予算の承認や手続きが必要ですし、専門のサポート業者を呼べば費用も日数もかかります。今目の前にある業務を止めるわけにはいかない以上、「すでにある機材の範囲で、どうにかして動く状態を作らなければならない」という切実な制約が生まれます。
「買い替えるという選択肢がない」からこそ、安易に投げ出す道が消え、「今ある環境の中で原因を突き止めて復旧させる」という方向へ自然と思考がドライブします。制約があるからこそ、知恵を絞るスイッチが入るのです。
自分の働きかけで「状況が良い方向に変わる」手応え
しかし、義務感やコスト意識だけでトラブルに向き合っていると、ただのストレス作業になってしまいます。私がこの作業を苦にせず続けられるのは、そこに「状況が好転する面白さ」があるからです。
- 画面のメッセージを読み、直前の差分から「おそらくここが原因だろう」と仮説を立てる
- 配線を挿し直す、設定を戻す、該当のプロセスを再起動するといったアクションを起こす
- 狙い通りに画面がパッと切り替わり、正常に動き出す
この瞬間、「自分の観察と試行錯誤によって、停滞していた現実が良い方向へとカチリと変化した」という確かな手応えが得られます。
機械は人間と違って、感情や気まぐれで動くことはありません。論理的に筋の通ったアプローチをすれば、必ず入力に応じた正確な結果を返してくれます。その因果関係の確かさと、自分の手で状態を改善できるプロセスの明快さが、純粋に面白いと感じるのです。
—
ここまでが、パソコンのトラブルそのものに対して私が頭の中でやっていることです。後編では、この「観察して、切り分けて、仮説を試す」という同じ思考が、人間関係や組織運営といった機械の外側でもそのまま機能している話を書きます。
コメント