tag:crieit.net,2005:https://crieit.net/tags/%E6%96%B0%E4%BA%BA%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9E%E5%BF%9C%E6%8F%B4/feed 「新人プログラマ応援」の記事 - Crieit Crieitでタグ「新人プログラマ応援」に投稿された最近の記事 2021-04-15T20:19:11+09:00 https://crieit.net/tags/%E6%96%B0%E4%BA%BA%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9E%E5%BF%9C%E6%8F%B4/feed tag:crieit.net,2005:PublicArticle/16848 2021-04-15T20:19:11+09:00 2021-04-15T20:19:11+09:00 https://crieit.net/posts/what-i-want-to-tell-to-new-graduate-it-employees 新卒IT社員に伝えたいこと <h1 id="はじめに"><a href="#%E3%81%AF%E3%81%98%E3%82%81%E3%81%AB">はじめに</a></h1> <p><a target="_blank" rel="nofollow noopener" href="https://togetter.com/li/1698737">プログラムを書いてエラーが出ると「自分が否定された」「尊厳を奪われた」と感じる人もいる、という話</a></p> <p>上記のまとめを読んで、何年か前にこういう新人さんがいたことを思い出しました。</p> <p>せっかくなので私も、IT新人さんへ向けてのTIPS的なものを書いてみようと思います。各所で言われていることかもしれないですが書いてみます。</p> <p>なお、あくまで私の個人的な考えなのであらゆる組織で通用する考えという訳ではないので注意してください。私自身はそんなに有名なサービスに関わっている訳でもない、ただの地方のエンジニアです。そんなに変なことは書いてないと思いますが、以下を鵜呑みにせず色々な人の「IT新人へのアドバイス」みたいな言葉を見て、必要な情報を取捨選択してください。また、分からない用語などが出てきたら都度ググってみてください。</p> <h1 id="エラーは怖くない"><a href="#%E3%82%A8%E3%83%A9%E3%83%BC%E3%81%AF%E6%80%96%E3%81%8F%E3%81%AA%E3%81%84">エラーは怖くない</a></h1> <p>上記のまとめでも言われていることですが、エラーを怖がる必要はありません。正確に言えば、本番で出たエラーは怖いんですが、開発中やテスト中はむしろどんどんエラーを出すべきだと個人的には思います。</p> <p>開発中やテスト中にエラーが発生すると、当然デバッグすることになります。すると本番ではそのエラーは発生しません。エラーは本番で発生すると、その調査や修正によりコストがかかります。</p> <p>それらは実際にリリースされて既に価値を生み出している製品なので、稼働を止めることによる機会損失や、ユーザーの信用を失うことに繋がるからです。</p> <p>一方、開発やテスト中にバグを見つけて修正することができれば、機会損失や信用の失墜を避けることができます。</p> <p>上記まとめにもありましたが、エラーや警告のメッセージはあなたを攻撃したりあなたを否定したりするものではありません。逆です。「こういうミスがあるよ」「ここの書き方がちょっとおかしいよ」「一応動くけどデータによってはエラーになるかもよ」と教えてくれるものです。</p> <p>動いているものが急に止まって、よくわからない英語がダラダラーっと出てくるので怖いかもしれませんが、一つ一つの文章はとても簡単な内容なので噛み砕いて理解するのは簡単だと思います。</p> <h1 id="使える機能やライブラリは積極的に使う"><a href="#%E4%BD%BF%E3%81%88%E3%82%8B%E6%A9%9F%E8%83%BD%E3%82%84%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA%E3%81%AF%E7%A9%8D%E6%A5%B5%E7%9A%84%E3%81%AB%E4%BD%BF%E3%81%86">使える機能やライブラリは積極的に使う</a></h1> <p>あなたが何かの機能を作ることになった時、その「何か」は既に他の人が似たようなものを作ったりしていることがあります。</p> <p>それを自分でやることは、それはそれで良い経験になったりはしますが、ITエンジニアは「面倒なことや難しいことを1と0で解決させる」ことです。要は、基本的に面倒くさがりな人が向いている気がします。誰かが既に作っているものを自分で新しく作るのこと(<a target="_blank" rel="nofollow noopener" href="https://ja.wikipedia.org/wiki/%E8%BB%8A%E8%BC%AA%E3%81%AE%E5%86%8D%E7%99%BA%E6%98%8E">車輪の再発明</a>と言ったりします)は基本的にはやめた方が良いでしょう。</p> <p>特にOSSなどで広く公開されているライブラリなどは積極的に導入を検討するのも良いでしょう。それらはあなたが個人で開発するよりも、より大勢の人の目によって使われて何度もバグが修正されていたり、最適化されていたりします。</p> <p>ただ一点勘違いしてほしくないのは、「自分で書かないだけで、書こうと思えば書ける」という状態にはなっておいた方が良い、ということです。</p> <p>たとえば配列のソートなんかは、だいたいどの言語でも<code>array.sort</code>的なメソッドがあります。ソートをするならそれを使えば良く、わざわざソート用のメソッドをあなたが0から実装する必要はありません。</p> <p>ただし、「じゃあソートってどういうアルゴリズムなの?<code>sort</code>っていうメソッドの中では何をやってるの?」という状態は好ましくないと個人的には思います。そういう状態であれば、ソートをするメソッドを書いてみるのも良いでしょう。それにより配列の特性を学んだり、なぜこの処理だと時間がかかるのか、なぜこの書き方が推奨されるのか、などを実体験として獲得できます。これは大きなアドバンテージで、この体験を積み上げていくことがとても大切です。後に同じような問題が発生した時も、これらの経験から「ここが怪しいんじゃない?」となんとなく分かるようになります。</p> <p>また、エディターによっては変数名やメソッド名の自動補完や、より良い方法を示したりする機能もありあます(EclipseのContent AssistやVisualStudioのIntelliSenseなど)。それらは便利な反面、「関数名などを中途半端にしか覚えなくなったりタイピングが上達しなくなったりするなどの理由から、新人さんには使わないように言っている」という人に一度だけ会ったことがありますが、個人的には使えるものはなんでも使って言った方が良いと思います。</p> <p>どうせ関数名は英語が分かればだいたい分かるし、何度も使ううちに覚えていきます。タイピングの上達は確かに大事なことですが、入力補完でtypoを減らせるのも充分なメリットです。毎日何時間もキーボードを叩いていれば自然にタイピングは上達すると思います。それにどうせ後から使う機能ならば最初から慣れておいた方が良いと思います。私だったら、気になったものはなんでも使ってみるように指導します。</p> <h1 id="ネットから拾ってそのまま使わない"><a href="#%E3%83%8D%E3%83%83%E3%83%88%E3%81%8B%E3%82%89%E6%8B%BE%E3%81%A3%E3%81%A6%E3%81%9D%E3%81%AE%E3%81%BE%E3%81%BE%E4%BD%BF%E3%82%8F%E3%81%AA%E3%81%84">ネットから拾ってそのまま使わない</a></h1> <p>上記と少し矛盾するかもですが、ネットからコードを適当に拾ってきてそのまま使うのは避けた方が良いでしょう。</p> <p>理由は以下の2つです。</p> <ol> <li>そのまま使うだけでは得るものがないから</li> <li>ライセンス的に問題があることがあるから</li> </ol> <p>まず1点目ですが、たとえば何かしらの関数をググってコピペして、それであなたがやりたかったことが実現できたとします。すると、あなたのコードを見た先輩や上司が「ここはなんでこの変数名なの?」「なんでこういう書き方をしているの?」などと疑問に思うかもしれません。</p> <p>そのような質問をされた時に、ネットから拾ってコピペしただけだとスムーズに答えることができません。これだと、先輩の疑問も解消されませんし、何一つ学べていないということになります。ググってコピペするというだけの簡単な作業ですが、せっかくなら何をしているか分かった方が良いですよね?</p> <p>特にITの世界は移り変わりが激しいので、その記事が書かれた当時ではモダンなコードだったとしても、1~2年経ったら古臭い書き方、懐かしい書き方になっていることもザラにあります。古臭い書き方が常に悪という訳ではないのですが、コードを見る人は「なんでわざわざこんな書き方してるんだろう?」と疑問に思う訳ですね。</p> <p>また、致命的なバグが含まれている可能性もあります。私が執筆している記事に関してもその可能性はあります。そして、仮にコピペしたコードがバグを引き起こして何かしらの損害を被っても、そのコードを書いてネットに載せた人は一切責任を取ってはくれません。</p> <p>2点目は、ライセンスの問題です。無償公開してあるものでも、MITライセンスなどは著作権表示が必要です。ライセンスポリシーによっては料金が発生するものもあるでしょう。当然不正使用となると重大な問題、コンプライアンス違反となります。</p> <h1 id="アウトプットするクセをつける"><a href="#%E3%82%A2%E3%82%A6%E3%83%88%E3%83%97%E3%83%83%E3%83%88%E3%81%99%E3%82%8B%E3%82%AF%E3%82%BB%E3%82%92%E3%81%A4%E3%81%91%E3%82%8B">アウトプットするクセをつける</a></h1> <p>得た情報は積極的にアウトプットした方が良いです。なぜなら、アウトプットして他の人の視点が入れば、「ここはこんな感じにも書けますよ」とか「他にもこんなに便利なツールがありますよ」など意見交換に繋がるからです。発信した内容(自分が事実だと思っていたこと)に誤りがあればそれを指摘してもらい、正しいことを知るきっかけになったりします。</p> <p>そしてアウトプットしておくことで、後から自分が見直すことができます。「久々に〇〇をやろうとしてググったら自分が書いたページがヒットした」みたいなのも、たまに見聞きします。</p> <p>アウトプットするのもいくつか方法はありますが、オススメなのは<a target="_blank" rel="nofollow noopener" href="https://qiita.com/">Qiita</a>です。アカウントを作っていなければ今すぐにでも作って良いと思います。他にも私が利用している<a href="https://crieit.net/">Crieit</a>や<sup id="fnref:1"><a href="#fn:1" class="footnote-ref" role="doc-noteref">1</a></sup>、ブログを書くというのもあります。QiitaもCrieitも、ブログではWordpressやはてなブログでもそうですが、Markdownで記事を書くことができます。Markdownに慣れておくのも良いと思うので、練習がてら書いてみると良いでしょう。</p> <p>また、「今から調べることは後からまとめてアウトプットするんや…!」というつもりで情報を集めると、不思議なことに集められる情報の質が上がります。自分の理解を越えて良いアウトプットをすることは出来ないので、良いアウトプットをするなら必然的に自分の理解度を上げることに繋がります。これは最終的に自分が得をします。</p> <p>また、アウトプットのクセを付ければ、他の人がわかりやすい表現をする練習にもなります。自分だけが分かる書き方ではなく、誰にとっても分かりやすい表現ができるようになります。信じられないかもしれませんが、人によっては「ボタンを押したらデータと日付を画面にオープンする」みたいなことを仕様書に書く人もいます<sup id="fnref:2"><a href="#fn:2" class="footnote-ref" role="doc-noteref">2</a></sup>。結局「どのデータか」「日付はどういうフォーマットか」「画面にオープンするとはどういう意味か」などといちいち質問する必要があり、それは双方にとって不必要なコミュニケーションコストです。初めから分かりやすく書かれているに越したことはありません。</p> <h1 id="道具にこだわる"><a href="#%E9%81%93%E5%85%B7%E3%81%AB%E3%81%93%E3%81%A0%E3%82%8F%E3%82%8B">道具にこだわる</a></h1> <p>あらゆる道具にこだわりましょう。キーボード、マウス、モニター、机、椅子、OS、エディター、その他ツール…挙げればキリがありません。</p> <p>キーボードなら日本語配列か英語は配列か、フルサイズかテンキーレスか、キーピッチはどうするか、直行配列にするか、セパレートキーボードにするか、トラックポイントは必要か、ワイヤレスか有線か、キースイッチは何方式か、メカニカルなら何軸か。モニターは何枚にするか、アームはつけるか、縦置きか横置きか、インチ数はどうするか、画面解像度はどうするか、デイジーチェーンにするか、など色々と拘こだわることができます。</p> <p>会社の都合などで、特にハードウェアは望み通りのものを使えないことがあるかもしれませんが、こだわることは大事だと思います。たとえばタイピングしやすいキーボードはそれ自体がモチベーションにもなりますし、見た目でも性能でも気に入れば愛着がわいて長く使いたくなります。職業柄PCに向き合う時間も長くなるので、せっかくなら徹底的にこだわって好きなもので固めた方が楽しいです。</p> <h1 id="便利なショートカットを覚える"><a href="#%E4%BE%BF%E5%88%A9%E3%81%AA%E3%82%B7%E3%83%A7%E3%83%BC%E3%83%88%E3%82%AB%E3%83%83%E3%83%88%E3%82%92%E8%A6%9A%E3%81%88%E3%82%8B">便利なショートカットを覚える</a></h1> <p>ショートカットはめちゃくちゃ便利です。使いこなせばキーボードからマウスに持ち替える動作が大幅に減り効率化できます。</p> <p>Windowsであれば</p> <ul> <li><code>Ctrl</code> + <code>C</code>(コピー)</li> <li><code>Ctrl</code> + <code>X</code>(切り取り)</li> <li><code>Ctrl</code> + <code>V</code>(貼り付け)</li> <li><code>Windows</code> + <code>E</code>(エクスプローラーを開く)</li> <li><code>Alt</code> + <code>D</code>(エクスプローラーやブラウザのアドレスバーにフォーカス移動する)</li> <li><code>Alt</code> + <code>Tab</code>(表示中のウィンドウを切り替える)</li> <li><code>Windows</code> + 数字(タスクバーにピン留めしているアプリを起動)</li> </ul> <p>あたりはマジでよく使うと思います。普段から慣れておくと良いでしょう。付箋などに書いて目に入る場所に貼っておくのも良いと思います。</p> <h1 id="タイピングに早く慣れる"><a href="#%E3%82%BF%E3%82%A4%E3%83%94%E3%83%B3%E3%82%B0%E3%81%AB%E6%97%A9%E3%81%8F%E6%85%A3%E3%82%8C%E3%82%8B">タイピングに早く慣れる</a></h1> <p>馬鹿にしている訳ではないですが、「最近の新人さんはスマホ世代なので、タイピングに慣れていないどころかローマ字もよく分からない人が結構いる」みたいな発言を見ました。その状態ではプログラミングはおろか、チャットやメールなども難しいと思うので、とりあえずさっさとタイピングに慣れましょう。</p> <p>上記にある通りアウトプット記事を書いてみたり、<a target="_blank" rel="nofollow noopener" href="http://typingx0.net/sushida/">寿司打</a>などのタイピングゲームをすれば慣れてくると思います。ホームポジションを覚えればかなりタイピングもスムーズになるでしょう。たまにタイピングが遅くてホームポジションもめちゃくちゃだけどめっちゃ優秀な人もいますが、まぁしっかりタイピングできるに越したことはないと思うのでしっかり慣れましょう。</p> <p>プログラミングはほとんどが英語の単語や文章なので、ローマ字のタイピングは得意でも英単語はスムーズにタイピングできないという人もいます。できれば練習の段階で英単語も挑戦するようにしましょう。</p> <p>タイピングに関してはキーボードとの相性も関わってきますので、自分にあったキーボードを見つけることも重要です。特にホームポジションは変な癖がつくとなかなか矯正できません。私も昔はずっと小さいキーボードを使っていて変な癖がついてしまっています。</p> <h1 id="わからないことをわからないまま放置しない"><a href="#%E3%82%8F%E3%81%8B%E3%82%89%E3%81%AA%E3%81%84%E3%81%93%E3%81%A8%E3%82%92%E3%82%8F%E3%81%8B%E3%82%89%E3%81%AA%E3%81%84%E3%81%BE%E3%81%BE%E6%94%BE%E7%BD%AE%E3%81%97%E3%81%AA%E3%81%84">わからないことをわからないまま放置しない</a></h1> <p>これが結構大事かもしれません。わからないことをわからないまま放置すると、後から調べるにも面倒になります。ググれば10秒もかからず調べることができるのですから、せめて概要だけでも知るようにしましょう。SiriやGoogleアシスタント、Alexaなどの音声アシスタントサービスを利用するのも良いでしょう。</p> <p>ミーティングにPCやタブレットなどを持ち込めるのであれば、ミーティング中に出てきたよく分からん単語をその場で調べたり、メモしておいて後でググったりすると良いでしょう。ミーティングがオンラインであればなおさら簡単にできますね。ちなみに弊社は絶賛オフラインです、本当にありがとうございました。</p> <p>一般的なことであればググれば分かることが多いですが、詳しい人に聞くのも効果的です。その人独自の視点や体験を交えて教えてくれるかもしれないですし、ググるだけではたどりつけない情報を知ることができるのも、人に質問することの大きなメリットです。人間は知識をひけらかしたい生き物なので、質問されて嫌な人はそんなにいないと思います。先輩だろうが上司だろうがガンガン質問していきましょう。</p> <h1 id="まとめ"><a href="#%E3%81%BE%E3%81%A8%E3%82%81">まとめ</a></h1> <p>色々と書きたいことはありましたが、まぁ概ねかけたと思います。他にも「ググる力を付ける」「情報取捨選択の力を付ける」「手段にこだわりすぎない」なども書こうと思ったのですが上手くまとめられなさそうなのでやめました。要望があったら書きますので、Twitterなどで反応いただければと思います。</p> <div class="footnotes" role="doc-endnotes"> <hr /> <ol> <li id="fn:1" role="doc-endnote"> <p>Qiitaに記事はほとんど書いていませんが、アカウントは作っています。Crieitを利用している理由は、メインでブログを書いており、カノニカルURLを設定がQiitaではできずCrieitではできるからです。 <a href="#fnref:1" class="footnote-backref" role="doc-backlink">↩︎</a></p> </li> <li id="fn:2" role="doc-endnote"> <p>組織やチーム内で、最終的なイメージや暗黙の仕様が充分に共有されていればこの粒度でも良いこともありますが…。 <a href="#fnref:2" class="footnote-backref" role="doc-backlink">↩︎</a></p> </li> </ol> </div> あぱしょに