はじめに
春ですね。
全国各地で数多の新人プログラマが生まれたことでしょう。
新人のうちはわからないことだらけですし、真っ当な労働環境でしたら先輩方が「わからないことがあったら何でも聞いてやー」と言ってくれます。
ですので、プログラムが謎のエラーメッセージを吐き出したりしたらすぐに質問したくなるかと思います。
しかし、個人的な見解ではプログラマのスキルが最も鍛えられるのは、わからないことを前にして自分なりに色々と調べて試行錯誤する時です。
多分、世の中の凄い人たちの中には身近に質問できる相手がいなくてひたすら自分で頑張った結果、超進化を遂げたという人も少なからずいるのではないかと...
というわけで、人に頼る前に自分にできることをしっかりやることで同期に差をつけちゃいましょう!
もちろん新人じゃなくても、「すぐに人に頼っちゃうなぁ、どげんかせんとなぁ」という方々にも参考にしていただけると幸いです。
自分がやられてイラっとしたことなんかじゃないんだからね!
実践編
想定しているケースは、プログラムを書いて実行してみたら何か謎のエラーが発生したというよくある状況です。
えらくざっくりした想定ケースですが、ほとんど一般論な話をしようとしたらこんな感じになっちゃいました。
1. まずはメッセージを読もうか
ここから全ては始まります。
新人の時はプログラムが謎のメッセージを吐き出した時点で先輩に聞きたくなるかと思いますが、「何か変なメッセージが出たんすけど」と聞こうものなら、まず間違いなく「どんなメッセージ?」と聞き返されます。
なので先回りしてまずは自分でメッセージを一通り自分で読んでおきましょう。
初めはまるで意味がわからないかもしれませんが、大事なのは「お前は何を言ってるんだ?」という気持ちを抱くことです。
2. 英語に怯まない
「英語だからわからない」が許されるのは小学生までだよね
プログラムが発するエラーメッセージのおそらく90%以上は英語です。
あまり英語を読まない学生生活を送ってたりすると英語を見ただけで怯むかもしれませんが、恐れることはありません。
落ち着いてゆっくり読んで、わからない単語があったら都度調べればいいのです。
別にスラスラと綺麗な日本語に訳す必要はないのです。
いざとなったらGoogle翻訳にぶち込めば、何となく言わんとしてることはわからんでもないぐらいの日本語にはなります。
3. ググる
「メッセージは読んだ、何となく意味はわかった、しかし原因も対策もわからん」となったら、人に聞く前にGoogle先生に聞きます。
プログラム関係のたいていの悩みは、過去に他の誰かが悩んでいて、すでに解決してます。
「言語名 エラーメッセージ (その他ライブラリ名やサービス名など)」みたいなキーワードでググれば大体何らかの情報が見つかります。
ex.)JavaScriptでAWSのDynamoDBにアクセスしたら「InvalidParameterType」とか言われたら、「js aws dynamodb InvalidParameterType」とググれば何かしら情報はあります。
ググった先にたどり着くのは大体英語ですけど、怯まずに目を通しましょう。
プログラマのスキルとググり力は比例関係です。多分。
4. 全ての道は「公式」に通ず
ググれば色々と情報が出てきて、中には「こうすれば解決するぜ」と言ってくれることもあります。
stack overflowとかteratailとか、そしてもちろんQiitaはそう言った情報の宝庫です。
しかし、それらに掲載されている情報は特定の環境であることが前提だったり、かなり限定された状況でのケーススタディ的な内容だったりするので、 自分の環境で同じようにやって上手くいくとは限りません。
この辺りに関しては新人エンジニアこそちゃんと調べてちゃんと知りちゃんと考えるという記事がとても参考になります。
そうなると「調べてもわからんかったし、先輩に聞こう」となりそうですが、この時点で先輩に聞きに行こうものならまず間違いなく「公式のドキュメントは見たか?」と返されるでしょう。
各言語の標準機能に関しては「(言語名) document」みたいにググれば各言語の標準リファレンスにたどり着けるかと思います。
ex.) python2.7のドキュメントをご所望なら「python2.7 document」とググれば先頭にすごく信頼できそうなURLを持ったWebサイトが現れます。ドメインが(言語名).orgという安心感。
ライブラリとかのことを調べたいなら「(ライブラリ名) (言語名) document」でほぼ確実に公式リファレンスにたどり着けると思います。「(ライブラリ名) document」だと、ライブラリ名が一般名詞だったりすると余計なものが検索結果に入り込むでしょう。
そして、よく使う言語やライブラリのリファレンスはブックマークして、困ったらすぐに見られるようにしときましょう。
なんか変なことになった時は、公式ドキュメントを見てメソッドの使い方とかオプションの設定の仕方が間違ってないか確かめるのはとても大事なことです。
あと、公式ドキュメントをちゃんと読んで理解しておくと、応用力もつきます。
注意「JavaScript document」はアカン
大体の言語は「(言語名) document」ですぐに公式リファレンスに辿り着けますが、JavaScriptには標準でdocumentオブジェクトがいらっしゃるため、「JavaScript document」でググるとそいつの解説のところに行ってしまいます。
大人しくMDN(Mozilla Developer Network)を見に行きましょう。
2017-04-12 追記
はてブコメントに
JavaScriptの場合、MDNいいけど微妙な点もあるので、素直にECMA-262見に行った方がいい
とありましたので、そちらのリンクも貼っておきます
あと、MDNは日本語版だと情報が古いことがありますのでご注意下さい。
5. 一度整理する
ここまでやってわからなかったら大人しく人に頼りましょう。
しかし、まだやるべきことがあります。
それはここに至るまでの流れを整理することです。
人間ついつい「このぐらいは言わなくてもわかるでしょ」と話を省いてしまいがちですが、それは相手と文脈を共有できてることが前提です。残念ながら、これからあなたが質問しようとしている相手はあなたと文脈を共有していませんので、しっかり整理して説明する必要があります。
個人的には以下のことを意識して話を整理するのがいいかと思います。
- 目的(何をしたいのか、どうなって欲しいのか)
- ゴールのイメージを共有するのは大事なことです。
- ここがはっきりしないと質問された側も「で、俺は何を答えればいいの?」と困惑します。
- どんな処理を組んだのか
- 自分で書いたプログラムが何をしているのかちゃんと説明できるようにしましょう。
- コードをパッと見てすぐに意図を理解するって難しいんです...(少なくとも私には)
- どこにつまずいているのか
- 「〇〇というエラーが発生するけど、解消できない」とか「こうなって欲しいのに、こうなってしまう」みたいな
- これまでどんなアプローチを取ったか
- できるだけ詳細に説明しましょう。できればその過程で書いたコードも見せるのがいいかと思います。
- アプローチの方向は正しかったけど、コードの書き方がまずかったということはよくあります。そんな時に「こういう方向で試したけど上手くいかなかった」と言うだけにしてしまうと、解決までに遠回りしてしまうことになります。
質問するにしても、一度整理して要点をまとめてる方が話が早いですし、整理している過程で「あれ、ここおかしくね?」と自分で気づいて解決することもあります。
プログラミングの世界にはゴム製のアヒルのおもちゃに向かって自分のやっていることを 声に出して 説明することで思考を整理する、ラバーダッキングという由緒ただしき手法があります。
別にゴム製のアヒルのおもちゃである必要はありませんが、言語化して説明するというのは大事なことです。声に出す場合は前もって同僚にことわっておきましょう。
突然アヒルのおもちゃに話しかけたら、周囲の人たちに「ついに壊れたか...」と思われかねません。
おわりに
わからないことを人に質問するというのは基本的に避けられないことですし、一人でずっと悩むぐらいなら人に聞いてサクッと解決した方がみんな幸せです。
しかし、その時に丸投げしちゃうと自分のスキルが磨かれませんし、何より「困ったら誰かにやってもらう」みたいな感じだと楽しくないと思います。
わからないことを自分で調べる過程を楽しめるようになれば、もうほとんど勝ち組です。
謎のエラーやバグが発生しても「また出てきたな、コイツぅ☆よーし、これからお前を丸裸にしちゃうZO☆」という気持ちで臨めば楽しいものですよ。