13
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

エラーについて質問するときに心がけていること

Posted at

はじめに

開発を行っていると必ずエラーに遭遇する。エラーに遭遇したことのないエンジニアはこの世に存在しないだろう。
にもかかわらず、エラーが遭遇してから解決するまでの手引書のようなものは(少なくとも私は)見かけたことが無い。
そのためか、エラーに出会ったとき初心者はすぐに「エラーが出ました!助けて!」と警告を発するように思う。
しかし、警告を発したところでスーパーエンジニアだろうがなんだろうが、やることは決まっているのだ。
エラーに遭遇しても、冷静に、かつ順序だてて解消する。決して怖いものではない。

意図

この記事の意図としては、初心者がエラーに遭遇した時に**どのようにして先輩エンジニアに聞けばいいのか。**の一つの指標になればいいと思う。
また、エラー解消までのフローを確認していただければと思う。
ただし、ここに載っているのはあくまで私自身の思いを書き連ねてるだけであることには注意していただきたい。

今どのフェーズにいるのか

エラーの解決までには以下の図のようなフローで進むことが多い。
**特にこの図は覚えておいてほしい。**この図だけ覚えてLGTMを押してブラウザを閉じても構わないくらい大切だ。

image.png

ここで大事なのは、エラーに遭遇し、エラー解決までの道のりを進む中で、自信がいまどこにいるのか明確にすることである。
収集先が分からないのか、原因が特定できないのか、修正方法がわからないのか。
これがわからないということは、自分がエラー解決に向ける道のりの中でどこにいるのかわからない。いわば迷子状態である。
それを相談相手に伝える必要はない。が、立ち位置を明確にしておくことが大切だ。

全て教えてください

「バグがでました。教えてください。」ではわからない。
私自身、まだ経験が浅いためすべてのバグを知り尽くしているわけではない。
まずはそのバグは何なのか知る必要がある。そのため、知りうるすべてを教えていただきたい。
具体的には、

  • 何をしようとしたのか
  • なにが起きたのか
  • どうなってほしかったのか
  • "どこまで何をしたのか"

もしもこれを伝えない場合、相談された側が同じことをもう一度行うことになる。
相談する人はスーパーマンに見えるかもしれない。しかし、本質的にはあなたとやることは変わらないのだ。
そして、相談される方も時間と頭を使う。相談した人の負担を軽減させるように伝えてあげるのが理想的だ。
先輩エンジニアはなんでも相談窓口ではない。

「どこまでしたのか」の補足

上記フロー(今どのフェーズにいるのか)の中で、どこまで、何をしたのか教えていただきたい。
例えば、

「APIがステータス200を返す想定でしたが、500が返ってきます。
CloudWatchLogにはERRORが1件出ていました。
エラー文にはAccess Deniedと出ていて、権限系のエラーではないかと思うのですがどの権限を足せばよいのかわかりません。
ログのURLは http://hogehoge です。スクショはこちらです。[画像]」

これだけで

  • 情報収集先はあっているのか?
  • 原因は本当にあっているのか?
  • 修正対象はどこなのか?

とアタリをつけることができる。その他、

「Eventから起動するLambdaの動作を確認しようとしたらログが出ていませんでした。他に調査するべきところはありますか?」

ならば調査対象が分からないのだとすぐにわかります。

何をしてほしいのか明確にする

上記の聞き方で大方見当は付くのだが、要求している情報を明確にしていただけるとなおのこと有難い。
原因が特定できていないのか、修正方法がわからないのか、情報源が分からないのか。。。

それによって相談された人は何を伝えればいいのかわかるので気が楽になる。相談される方も人間なのだ。

情報は共有すること

ここから先はチームとしての立ち振る舞いになる。

エラーというのは資産だ。エラーに出会えば出会う程、エンジニアのスキルは向上すると私は思う。
しかし、この資産を共有しない人が多いのもまた事実だ。

あなたが出会うことのできたエラーは、世界中のエンジニアが遭遇する可能性のあるエラーである。
それを共有しないのは非常にもったいない。
ましてや、チーム内の出来事であれば尚更だ。
あなたの遭遇したエラーはすでにチーム内で発生し、解決方法を知っている人がいるにも関わらず、丸1日時間を使ってしまった。そんなことがありえるだろう。
slackなどの共有ツールがあるならば、周知しないのは宝の持ち腐れだ。

エラーは資産だ。恥ずかしいことではない。

宝を共有せず、独り占めしてる方がよっぽど恥ずかしい。

明日は我が身

エラーに関心を持とう。ある程度チーム内で開発が進むと、エラー専門部隊のようなものが発足することがよくある。
エラーが発生するや否や、どこからともなく飛び出てきてエラーを解消してくれるスーパーヒーローだ。
しかし、それは非常に危険な状態である。

そのスーパーヒーローが居なくなることは決してないのだろうか?
ヒーローがいなくなった時、あなたは代わりになることはできるだろうか?

エラーの改修は専売特許ではない。共通資産である。
彼らはエラーを直さないと次に進めないからエラーを直しているに過ぎない。

そのような状態になったら一度チーム内で相談してみるのをお勧めする。

誰がいつ居なくなるかなんてわからない。でも、仕事は止まらない。

最後に

ここまで読んでいただいてありがとう。

具体的なエラーの解消方法はここには記述していないけれど、エラー解消のためにはどのようなフローを踏み、どのように質問すればいいのかわかっていただけたならうれしい。

この記事が少しでもエラーの解消、並びに良いチームへ進むためのヒントになれば幸いです。

13
5
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
13
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?