はじめに
ほんの少し前まではひよっこエンジニアだった私ですが、最近では私よりも経験の少ないエンジニアと同じチームになることもあり、ライブラリの使い方がわからない・バグが出たけど原因がわからないなどの相談を受けることが多くなってきました。
もちろん、一人で悩まずに相談するのは良いことです。しかし、悩むからこそ得られる力というものもあります。安易に相談することで、貴重な成長機会を失っている可能性すらあるのです。
そこで、相談する前にやるべきことをまとめてみることにしました。多少時間はかかっても、ぜひこの程度の内容はチャレンジしてみてください。
エラーがでたとき
エラーメッセージを読もう
以下の C 言語のプログラムにはバグあります。
#include <studio.h>
int main(void)
{
printf("Hello World\n");
return 0;
}
gcc でコンパイルしようとすると、以下のようになりました。
$ gcc hello.c
hello.c:1:20: fatal error: studio.h: No such file or directory
compilation terminated
これをみて、先輩に「なんかエラーでたんですけどどうしたら良いですか」なんて聞いてはいけません。
エラーメッセージは人間が読むためにあります。英語なのでとっつきにくいかもしれませんが、必ず読みましょう。英語が苦手でも、google 翻訳を利用すればおおよその内容はわかるはずです。
また、エラーメッセージには独特のパターンがあり、それを覚えるだけでも理解が早まります。以下に幾つか挙げますが、そのようなパターンも普段からエラーメッセージを読んでおけば、自然に身につきます。
| エラーメッセージ | 和訳 | 考えられる原因 |
|---|---|---|
| No such file or directory | そのようなファイルやディレクトリは存在しません | 実際にファイルが存在しない、またはファイル名の typo |
| Unexpected EOF | 予期しないファイルの終端 | 括弧やクオートなどの閉じ忘れ |
| Permission denied | 許可の拒否 | sudo のつけ忘れ |
エラーメッセージでググろう
エラーメッセージを読んでもわからなかった。そんなときは、先輩に相談する前に google 先生に相談しましょう。同じようなエラーを経験した人がブログに書いていたり、質問サイトに同様の質問があることも多いです。
英語のサイトがヒットしても怖気づいてはいけません。キーワードを拾い読みしたり、コマンドやソースコードを読むだけでも問題が解決することはしばしばあります。
エラーメッセージをそのまま質問しよう
ここまでやっても解決しなければ、いよいよ先輩に相談しましょう。
ただし、「エラーがでたんですけどどうしたらいいですか」のような聞き方をは NG です。エラーについて質問するときは、エラーメッセージをそのままの形で省略せずにコピペ して質問しましょう。
絶対に省略してはいけません。関係ないと思っても、じつはそこに重要な情報が記載されていることもあります。エラーメッセージが長い場合は、ファイルに書き込んでファイルを送信するのも良いでしょう。
$ command > output.txt 2&>1
バグがでたとき
バグの状況を整理しよう
書いたプログラムが思った通りに動かない、いわゆる「バグった」ときですが、先輩に相談する前にバグの状況を整理しましょう。プログラムは間違っていなくて、仕様を誤解していただけということもあります。
最低限、以下の二点を確認して下さい。
- どうなってほしいのか(正しい動作)
- どうなっているのか(現在の動作)
これらは、可能な限り詳細に書きだして下さい。
例えば、割り算プログラムにバグがあったとします。
良くない例:
- 正しく計算できて欲しい
- たまに計算結果が間違っている
良い例:
- 実数の割り算を正しく計算し、表示して欲しい
- 計算結果が少数のとき、切り捨てられて整数になってしまう。
問題を切り分けよう
バグの状況を整理しても、そのまま先輩に質問してはいけません。状況を整理したら、次はどこが間違っているのかを確認します。
たとえば、以下のような整数の割り算プログラムがあったとします。このプログラムには、計算結果が少数になる時に出力が正しくないバグがあります。
#include <stdio.h>
int main(void)
{
int lhs, rhs, result;
scanf("%d%d", &lhs, &rhs);
result = lhs / rhs;
printf("result: %d\n", result);
return 0;
}
$ gcc calc.c
$ ./a.out
5
2
result: 2
現在わかっているのはバグの状況だけで、このプログラムのどこにバグがあるのかはわかっていません。入力した時点で数字がおかしくなっているかもしれませんし、計算が間違っているのかもしれません。もしかしたら、計算結果を result 変数に代入するときに値が変化している可能性もあります。
なので、どこでバグがあるのかを調べます。方法はいくつかありますが、今回は一番手軽な printf デバッグと呼ばれる手法を紹介します。
まず、先ほどのソースコードを以下のように書き換えます。
#include <stdio.h>
int main(void)
{
int lhs, rhs, result;
scanf("%d%d", &lhs, &rhs);
printf("lhs: %d\n", lhs);
printf("rhs: %d\n", rhs);
printf("lhs / rhs: %d\n", lhs / rhs);
result = lhs / rhs;
printf("result: %d\n", result);
return 0;
}
$ gcc calc.c
$ ./a.out
5
2
lhs: 5
rhs: 2
lhs / rhs: 2
result: 2
これをみれば、lhs / rhs という式の計算がおかしいことが一目瞭然ですね。このようにして、バグの原因となっている箇所を出来るだけ詳しく調べましょう。
情報を正しく伝えよう
バグの原因の箇所がわかったのにバグが修正できない場合は、いよいよ先輩に相談しましょう。このとき、整理した情報を伝えることを忘れてはいけません。
少しでも情報があるならば、相談された先輩はその情報を基に調査をすることができます。
ライブラリ・フレームワークの使い方がわからない
ググってみよう
プロジェクトで知らないライブラリを使うことになったとき、使い方を質問するのではなく、まずは自分で調べてみましょう。有名なライブラリであれば個人ブログや Qiita など、日本語の情報も豊富であることが多いです。
ただし、公式でない媒体から得た情報は必ず正しいかどうか確認しましょう。ブログ等には、間違った情報が自信満々に書かれていることもかなりあります。一度日本語で概要を把握すれば、その真偽を公式のドキュメントで確認するのも意外と簡単です。
公式ドキュメントを読もう
ライブラリを使用するときは、まず公式のドキュメントを読みましょう。良いフレームワークにはかならずドキュメントがあります。そして、(たまにバグや間違いはあるものの)ドキュメントは正確であり、ユーザーのブログなどよりはよほど信頼できます。
基本的に英語なので、苦手な方には難しいかもしれませんが、良いドキュメントならソースコードでの例も多く用意してあるはずです。
英語が読むのが苦手でない方は、最初から公式サイトを読んだほうが早いかもしれません。
なにを教えてほしいのかを明確にして、質問しよう
公式ドキュメントをしっかり読んでもよくわからないことがあった時は、必ず教えてほしいことを明確にしたうえで、質問しましょう。
なにがしたいのか、なんのためにしたいのか、どこまでわかっているのか、などを明確にすると良いでしょう。
まとめ
何を質問するときにも共通ですが、先輩に質問する前に、エラーメッセージやドキュメントなどの与えられた情報を活用しましょう。
また、先輩に質問したあとは、質問された先輩がどのようにして問題を解決するのかを研究するのも良いでしょう。エンジニアにとって問題解決能力は基礎体力のようなものです。1年もすれば、こんどは質問される側になるのですから。
おまけ: 先輩エンジニアの皆さんへ
新人エンジニアから質問されたとき、先輩エンジニアはどのように返答するべきか。これは難しい問題です。
「なんかエラーが出たんですけど」と相談されたら、「エラーメッセージを読んでみて」と返答するなど、直接答えだけを教えるのではなく、問題解決の方法を教えるのが良いでしょう。
しかし、スケジュールが逼迫しているなど、余裕が無い時には答えを教えてしまうことがベストなときもあります。
新人エンジニアがこの記事の内容を意識しすぎてしまうと、自分で頑張りすぎて締め切りに間に合わないということもあり得えます。そのため、新人エンジニアが自分で悩みすぎていないかを確認することも重要です。
どの程度自分で頑張るように指導するかは、難しいとは思います。
この記事が正解だとは思いませんが「この記事を読んでもらったうえで、悩みすぎていないかを気を配る」というのも１つの方法ではないでしょうか。