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