問題に遭遇した時、自分一人でやること、質問する前にやること
新人さん向け。エラーメッセージやバグに遭遇して、どうしたらいいか分からない時、まず自分一人でやるべきことと、先輩上司に質問する際にやっておく必要があることをまとめておく。コレができないといつまでも迷惑な存在のまま燻るので、一刻も早く身に付けたい。
目次
問題に対して一人でやること
まずはエラーメッセージをきちんと読む・英語でも読む
エラーメッセージに遭遇したら、まずエラーメッセージをきちんと読もう。エラーメッセージが英語だろうと、まずは自分で読むこと。「英語が読めない」なんて小学生までしか言えないセリフなので、死ぬ気で勉強して読めるようになれ。
よくあるのが、エラーメッセージを読みながら自分の勝手な推測が混じってしまい、意味を誤解してしまうこと。あまり自分の頭の中でストーリーを広げず、目の前に表示されているメッセージ・事実だけを拾い集めること。
英語が分からない人はついつい機械翻訳に放り投げるだけで何か分かった気になることが多いが、今のところ機械翻訳の精度はまだイマイチで、プログラミングの文脈を理解して翻訳してくれはしないので、翻訳ツールなどは分からない単語や熟語の意味を調べる程度に留めること。翻訳した文章は原文ではないので、何の価値もない。鵜呑みにしないこと
問題・原因を切り分ける
例えば「PC に USB 接続した端末が認識されない」時に、どこに問題があるのか、色々なポイントが推測できる。
- 接続しようとしている端末のソフトウェアに問題があり、USB を認識していない
- 接続しようとしている端末の端子が接点不良を起こしていたりする
- 接続に使用しているケーブルが故障している
- 接続に仕様しているケーブルが端末もしくは PC と相性が悪く、認識してもらえていない
- 接続する PC の端子が接点不良を起こしていたりする
- 接続する PC のドライバやソフトウェア、OS に問題があり、接続されている端末を認識できない
つまりコレだけ原因となりうる要素があるワケで、これらの問題を切り分けないと、何が問題なのか理解したことにはならない。
- 同じ端末・同じケーブルで、別の PC に挿すと認識する → PC に問題がある可能性が高い
- 端末やケーブルには問題がないことが明らかにできる。これを推測だけで正常なものと決めつけないこと。必ず実際に試すまでは勝手に答えを出さない。
- PC の端子が悪いのか、ドライバが悪いのかはまだ分からない。分からない部分も正確に区別して認識しておく。勝手に問題箇所を特定しようとしない。
- 同じ PC の別の USB 端子に挿すと認識する → PC の特定の端子に問題がある
- この場合もまだ、単なる接点不良だけでなく、USB 2.0 端子に USB 3.0 のケーブルを挿していることで誤認識していたりする可能性もなくはない。
- 同じ PC のどの端子も認識しない
- まずハードウェア的な問題がないか確認するため、端子を掃除したり、別のケーブルを使って試してみたりする。
- ハードウェアに問題がないことを (ある程度でも) 明らかにしたら、ソフトウェアの問題を疑い、ドライバをアップデートしたりしてみる。
例えばこうした試行錯誤を行い、原因箇所を切り分ける必要がある。
同様のことはコーディング時のエラーにもいえる。あるメソッドを使ったことで計算結果がズレている、と勝手に思い込んでいたが、よくよく調べたら違う箇所が原因になっていた、といったことはよくある。プログラミングの場合は「Print デバッグ」など原始的な方法を使っても良いので、「この行までは正常」「この行の処理でおかしくなる」といった原因箇所をきちんと切り分けよう。できれば、同じ問題が発生する最小構成のコードを別途作ってみたりしても良いかも知れない。
エラーメッセージでググる
まず自分の手元で発生した問題が何を訴えているのか理解したら、その文言をそのまま Google 検索窓に入れてググろう。
プログラム関係のたいていの悩みは、過去に他の誰かが悩んでいて、すでに解決してます。
そうすると、大抵は GitHub Issues や StackOverflow の質問ページなどがヒットする。
特定のメッセージがない事象のググり方
特にエラーメッセージが出ないけど、なぜかこのライブラリが思った動作をしていない、といった場合は、検索キーワードを自分で考える。そのポイントは、筆者の視点で文言を考えること。
- ライブラリの概要を説明してくれている記事であれば、「○○とは」といった単語で執筆するだろうから、「○○とは」というキーワードで検索してみる。
- 問題の解決策を解説してくれている記事なら、「○○が動かない場合の原因と対処法」などという記事タイトルにすることが多いと思われるので、「○○ 動かない」「○○ 異常終了 原因」といったキーワードを組み合わせてみる。
検索結果がイマイチ広すぎる場合は、「言語名 キーワード」とか「ライブラリ名 キーワード」といった形で AND 検索する。JavaScript の forEach に関する問題を調べたいのに、PHP の話が混じったりするなら、「JavaScript forEach -PHP」のように、除外検索を利用する。
まずは日本語で調べても良いが、分野によってはイマイチ日本語の文献が出てこない場合もある。そういう時は英語で検索する。
何かが動かない時は「not working」、何かが不正な状態なら「invalid」、設定を書いたのに無視されていそうな時は「ignore」など、その状況を表す、よく使われる英語表現を交えて検索すると良いだろう。
ググり方に関しては、以下のような知識も事前に入れておくと良いだろう。
検索結果の最初の10件は全部読む
キーワードで検索したら、検索結果の最初の10件は何も考えずに全て別タブで開き、全てを熟読する、というのを習慣づけて欲しい。
「英語のページだから読みたくない」なんて論外。自分で解決できるスキルもないのに、「タイトルからするとあんまり関係なさそう？」なんて勝手な判断で検索結果を除外しないこと。
開いて全部きちんと読んでみてから、明らかに違うページは無視すれば良い。
文献を読む際は、そのページでターゲットとしているライブラリのバージョンや OS などの環境が、自分と同じかどうか確認すること。Mac 環境でのみ有効な対処法を Windows で試していたり、古いバージョンの文献で今となっては解決策にならない情報など、珠玉混在していることを念頭に置いて、いきなり鵜呑みにしないようにすること。その記事と自分の環境との差異を押さえておこう。
- 読み飛ばさない
- メモする
漏らさず読みながら、情報を整理していくのを忘れずに。
見つけた対処法はいきなり試さない
検索して何か対処法っぽいコードやコマンドが見つかっても、いきなり打ち込んで試さないこと。自分の環境に適さない誤った解決策だった場合、さらに余計な問題を生むことにもなりかねない。
解決策っぽい情報は、まずは検索結果の10件を読み終わるまで、メモ帳にでもキープしておく。全て読み終わったら、一番効果がありそうな手順から順に試してみる。その際、試した内容が間違っていた時に、元に戻せるようにしておくこと。元に戻せないような手順は試さないでおき、先輩上司に質問した方が良い。
公式サイトを読む
ググってそれっぽい答えが出てこなかった時も、出てきた時も、必ず公式サイトの API リファレンスやトラブルシューティングなどに目を通すことを忘れずに。
「機転を利かせる」とか、「応用して別の問題を解決する」とかいう能力は、インプット量が多くないとできない。まずはインプット量を増やそう。
それでもダメなら質問する準備を始める
こうした「発生事象 (エラーメッセージ) の内容把握」や「解決策の検索」は、5〜10分程度で終わるはずだし、終わらせる。それ以上は足りない自分の頭で考えても時間の無駄だ。それに、単に直接的な解法をググるだけでは解決できないような問題であることが多いので、総合的な知識力が乏しい人間には解決は難しいだろう。
新人エンジニアがこの記事の内容を意識しすぎてしまうと、自分で頑張りすぎて締め切りに間に合わないということもあり得えます。
そのため、新人エンジニアが自分で悩みすぎていないかを確認することも重要です。
そこで先輩や上司に質問しに行くワケだが、「何かエラーが出て〜、よく分かんないんですけど〜」なんて質問の仕方をした時にはカカト落としモンだ。相手が事象を把握し、解決策を導き出せるよう必要な情報をまとめて簡潔に共有するための準備をしよう。
人間ついつい 「このぐらいは言わなくてもわかるでしょ」と話を省いてしまいがちですが、それは相手と文脈を共有できてることが前提です。
残念ながら、これからあなたが質問しようとしている相手はあなたと文脈を共有していませんので、しっかり整理して説明する必要があります。
先輩上司に質問する前にやること
質問する内容を整理する
これはつまり、「質問された側が答えを考えるために必要なこと」の裏返しである。何を提供すれば求める情報が返ってきそうか考えよう。
- 目的 : 実現したいこと・期待値
- まず「○○を△△にしたい」という目的を再度明らかにすること。
- よくあるのが、その目的を果たすためには遭遇しているエラーや問題に向き合わなくても良い場合がある、ということ。例えば「while 文のループ処理を実装したらエラーが出た」という時に、「こういうエラーメッセージが出て、なんとかしたいんですけど…」と云われるが、よくよく実装しないといけない内容を聞いてみたら「そもそもループ必要なくね？」なんてことがあったりする。自分の現状が当初の目的からズレていないか、立ち位置をよくよく確認しよう。本当にその問題を解決する必要があるのか？
- 何をして、どうなっているのか
- 目的に対し、自分がしたことは何で、その結果どんなエラーメッセージが出たのか、ここを正確に伝える。
- 「コード書いてみたんですけど何かエラーが出て」なんて発言からは何の情報も読み取れないのだ。「○○にするために Hoge ライブラリの
fuga()メソッドを使ったんですけど、Invalid Type Exception というメッセージが出て、スタックトレースによると180行目の処理にエラーがある、と表示されています。でも原因が特定できないのです」と、必要な情報を正確に話さないといけない。「なんか」なんて絶対言うな。 - 「こうしたいのだけど、こうなってしまう」とか、期待値との対比で説明する。
- どんな対策を講じてみたか
- その問題に対して自分が試したアプローチを共有する。この場合も、中途半端に話さず、試した内容を正確に伝えきる。
- 書いたコードを見せて説明するのもいいが、それらは全て自分の口で説明できる状態にしておくこと。コードを見せたりするのはあくまで補足資料という位置づけ。自分が主体的に物事を把握して説明できる状態でないと、解決策を聞いても動けない。
これらをまとめたら、初めて席を立ち、先輩上司に質問しよう。
なお、先輩上司に質問する時は、以下のことに注意する。
- メモ帳を持っていく。
- こんな問題も解決できないヤツが、メモを取る用意もないまま質問しに行って、答えを暗記して自席に戻れるワケがない。メモできる道具を必ず用意しろ。
- メモは体言止めや単語だけで書かずに、「○○を△△にする」と必ず文章で書く。体言止めや単語だけで書いたメモは、後で読み返した時に意味が分からなくなっていて、自分で勘違いしたりしやすい。間違えやすい事柄は最初から間違いが起きにくいやり方をとって回避すること。
- 人の話を最後まで正確に聞く。
- 「こうしたらどう？」という答えを聞き間違えたり、誤認識しないようにする。一発で理解したつもりになっても、本当に誤認識がないか、自分の言葉で言い直して確認する。
- 「○○する、ということは、つまり
fuga()メソッドの第2引数にfalseを設定する、ということでしょうか？」というように、相手が省略したり、抽象的に表現したものを、省略せず、具体的に言い直すことで、初めてお互いの認識に相違がないか確認できる。
- これからやろうとすることを伝えてから自席に戻る。
- 「○○を試してこういうエラーメッセージが出たら原因は××にある可能性が高い。もしコッチのエラーメッセージになるようなら、××ではなく△△を修正しないといけない」というように、いくつかの回答や手法を教えてもらった場合は特に。
- 「では、初めに○○を試してみて、意図した結果が得られれば××を修正しようと思います。もしそれでダメだったら、次に△△を試してみようと思います。」「それでもうまくいかないときはまたご相談させてください」という風に、回答を聞いて自分がこれから起こそうとしているアクションを伝え直す。
- 場合によっては「あ、ちょっと待って、いきなり△△の対処に移るのはマズいから…」とか、補足やフォローをもらえたりするし、認識誤りがないかの確認にもなる。
- 試して上手くいった時は「○○の方法でうまくいきました」と一言報告する。
- 上司としても「あれから詰まり続けていないか」が気がかりだし、スケジュール遅延に響いたら困るので、報告はこまめに。問題がない時も、問題がないことを報告する必要がある。
全般的に共通する心構え
以上、問題に遭遇した時にどのようにアプローチし、どのように人に頼れば良いかを話してきた。こうしたことは、言われなくても最初から出来る人か、どれだけ言われても一生できない人に二分されると思う。両者で決定的に違うのは、この一つの心構えがあるかないか、だと思う。
それはすなわち、見たものや聞いたものに自分の勝手な判断や推測を混ぜていないこと。事実と主観を明確に区別し、「自分はこう思うが、実際こうなっている」ということを常に正確に分析できているかどうかだ。
我の強いヤツや、あまりモノを知らない人間に限って、「自分はちゃんとやっているのに何故かこうなる」とか、「自分のコードに間違いはないはずなのに」とか言う。でも、99% はそいつ自身のやっていることが間違っているから問題が起こっている。
以下は立川談志の有名な言葉だが、エンジニアの問題解決に対する心構えとしても適用できるのではないかと思っている。
「よく覚えとけ。現実は正解なんだ。
時代が悪いの、世の中がおかしいと云ったところで仕方ない。
現実は事実だ。
そして現状を理解、分析してみろ。
そこにはきっと、何故そうなったかという原因があるんだ。
現状を認識して把握したら処理すりゃいいんだ。
その行動を起こせない奴を俺の基準で馬鹿と云う」
すなわち、「僕は悪くない」「合っているはずだ」などと言っても、エラーが出力されているなら、何かを変えて、その問題を解決しなきゃいけないのだ。
現状に対して自分の思いや主観は必要ない。正しく事実を事実として把握し、適切に処理することが求められる。
そのために意識しないといけないこと、エンジニアとしてやれないといけないことを語ってきた。ぜひともスムーズに、スマートに問題解決し、自分で自分の仕事を進めていけるように願っている。
