エンジニアが何か問題にぶつかったときにあるといい力を5個

最近ちょこちょこ相談されることがあって、直接のスキルではないけど、こういうのもスキルだよなぁって思ったので、思いついた順に書いてみる。5個になった。

## 1. 問題を切り分ける力

「これがなぜか動かない」って相談されたときって、いくつかの要素が絡んでることが多い。

なので「ここは明らかに問題ないでしょう」という一番土台のところからチェックを始める。そうすると「え?そこは問題ないと思いますよ?」って言われるので「うん、それを『問題ないと思う』じゃなくて『問題ない』って断言できるようにしようと思って」みたいな会話をよくする。

可能性をひとつずつつぶしていくと「ここだなぁ」って場所が見つかって、そしたら、もうあとはそんなに難しくない。ひとつずつ確認していくのって遠回りに見えるけど、結局その方が確実ではやいと思う。

## 2. 想像と事実を切り分ける力

↑と絡んで、想像や思い込みなのに、「ここは問題ありません」って断言をする人もいる。ので「それは何かを確認してそう断言してるの?それとも想像?」って聞くと「( ゚д゚)ハッ!・・・確認はしてません」ってなる。「じゃ、そこ確認してみよう」。

自分の中の想像と事実を切り分ける力もそうだけど、誰かの中の想像と事実を切り分ける力も大切だね。

## 3. 探す力

問題にぶつかって、調べてみるかーってなるとして、ネットを探し回るのもスキルがいるよなぁって思う。だいたい英語のほうが情報が多い。

エラーメッセージの中からキーワードを選んだり。期間を指定したり、サイトを指定したり。Stack Overflowを見に行ったり。GithubのIssueを探してみたり。あと、うちの部署は全員Safaribooksを読めるので、そこで探したりもするなぁ。

こういうサイトにはたぶん載ってないとか。この翻訳は原文をあたったほうが良さそうとか。この人の記事なら信頼できるとか。もある。

それと、社内のドキュメントを探す力も重要。「ここにあったよ」って伝えると「え?そんなの知らなかった!」って言われることが多いんだけど「僕も知らなかったけど、探したら見つかったよ。ちょっとコツがいるよね」って感じ。このスキルは外では身につかないのが難しいところ。

## 4. 公式ドキュメントを読む力

公式ドキュメントに書いてある場合も多い。例えばSpringBootの設定を外部からどう与えるかとか。なので目を通しておいて、必要なときに「たしかあそこに書いてたなー」ってチェックできるようにしておく。読んでなくて想像で動かしてる人も多そう。

## 5. ソースコードを読む力

目の前にソースコードがあるのに「このスクリプトが動かないんですよね・・・」って言われるときも多い。「ソースコード読んでみたんだけど、こうやれば良さそうよ?」みたいな。「じゃあ、この場合はどんな風に動くんですか?」って聞かれて(ほほー。自分で読むってのは想像もしないのかー)って思いつつ「そうね。一緒にこのソースコード読もうか」ってなる。

Githubソースコードが公開されてるプロダクトなら見に行ったらいい。Vagrantの動きが気になったときとか、k8sのReadiness Probeが気になったときに、見に行ってほほーってなったりしてた。RubyとかGoとか分からなくても雰囲気で読む力がついてきたのかな。ちょっと前のバージョンを使ってる場合とかだと、ブランチの中を探してみたりもする。

コンテナの中身がどうなってるか分からない!って言う人もいるけど「それ、GithubにDockerfileあるからそれ読んだらだいたい分かりますよー」って話もしたりする。

## そんな感じ

エラーメッセージを読む力、はもういいよね。

とはいえ、書きながら自分自身も、Terraformの公式ドキュメントに目を通してないなぁとか思った。もっと頑張ろっと。