先日、ライフネット生命保険 取締役会長の岩瀬大輔さんが執筆された、
ダイヤモンド社が出版する「入社1年目の教科書」を読んでみました。
私は社会人として働くのは今年で初めてのため、
「エンジニアでも読んだほうがいい」とネットで評される当本を勉強がてら読んでみました。
読んでみた結果、やはりエンジニアの仕事においても多く当てはめることのできる有意義な内容だったため、
私の経験も踏まえ、５つのポイントに絞って共有します。
共有対象はまだエンジニア経験の浅い初学者を想定した内容です。
初投稿のためお見苦しい所あるとは思いますが、ご容赦くださいませ。
- 筆者の前提スペック(投稿現在)
- 2018年6月にSES会社に中途入社。
- 社会人経験は初。
- プログラミングはズブの素人からスタート。ガチガチの文系出身。
- 右も左も分からないまま2ヶ月の研修を受ける。
- 2018年8月より現場デビュー。
- 現場の方々が何語を喋ってるのかすら分からないままスタート。「えびでんす」って何？
- 投稿現在で現場経験4ヶ月目。JavaでWebアプリケーションを開発しています。
そんな感じのペーペーです。
あじぇんだ
覚えたての言葉を使わせてください、「あじぇんだ」。
あぁ、いい響きですね。使った途端に急にそれっぽくなる言葉、あじぇんだ。
この記事のあじぇんだは大きく分けて５つです。
本書より、エンジニアの仕事に特に活用できると思った内容だけを切り抜きました。
- 50点で構わないから早く出せ
- 「何のために」で世界が変わる
- 仕事の効率は「最後の5分」で決まる
- 質問はメモを見せながら
- ペースメーカーとして、資格を申し込む
です。
では、本題に入ります。
１． 50点で構わないから早く出せ
まず、新人が特に意識すべきことは、
経験１年そこらの素人が100点満点のシステムを開発することはまず不可能
という点です。
私の経験ですが、自分が完璧だと思えるまで丸３日かけて作り込んだコードを上司に提出すると、
ものすごい数の指摘を受けました。
そんなふうに、長い時間をかけて一生懸命コードを書いても「全然ダメ」との評価を受けることなんて多々あります。
どんなにセンスのある人でも、経験不足から来る至らなさは沢山あると思います。
長い時間をかけて、自分の思う100点満点の成果物を出すくらいなら、
50点のところまで出来たらまずはレビューしてもらいましょう。
面白いことに、優秀な人ほど成果物に赤ペンを入れられるのを嫌がる傾向があるようです。
しかし、その赤ペンこそ経験となり、後の財産となりうるのです。
50点の段階で提出する＝怠慢ではありません。
最初のフィードバックを頂く機会だと考えましょう。
新人が初めから完璧なものを作ることなど不可能なのですから。
２． 「何のために」で世界が変わる
現場で仕事をしていると、特に新人のうちは、大きなプロジェクトの中の、
とても小さな機能を実装するような指示を受けることが多々あります。
それを、「何のために」作るのかを把握しているか否かでは、得られる経験値が桁違いです。
大きな家を建築する際に、新人でもできる仕事として「ドアノブ」を作る作業を指示された場面を想像してみてください。
今作っているモノが
「指示を受けた通りによくわかんない金属製の部品を作る」意識なのか、
「ドアを開閉するための重要な部品を作る」意識なのかでは、
完成度に大きな違いが出てくると思いませんか？
新人のころは、「いったい俺は何を作ってるんだ？」と思うような作業が振られることがあります。
指示をそのまま受け取って、言われるがまま作業をするのは前者と同義です。
なので、指示を受けた際にまず聞くべきことは、「何のためにですか？」です。
もちろん質問の仕方に気を配って質問してくださいね。
相手の捉えようによってはマイナスの意味に取られてしまいますからね。
新機能を実装するには、必ず背景があります。
たとえば、あなたはある企業が使用する商品発注用の顧客管理システムを作っているとして、
お客さんがアプリケーション内に「住所検索機能を追加する機能を追加してほしい」と言っているとしましょう。
同じ「住所検索機能」だとしても、
「住所検索機能がないために、単純に顧客リストが見にくいから追加してほしい」のか、
「ざっくりした住所で分類して表示させたいから追加してほしい」のか、
「顧客は都内在住の人だけだから、区ごとに検索するselectボックスを追加してほしい」のか、
「特定の市区村の住所の顧客登録数が増えすぎて、誤発注を起こしてしまう事例が出たから、防止のために細かく検索できる機能を追加したい」のか、
「海外へ発送するプロジェクトを始めるにあたって、国別で住所を検索できるようにしてほしい」のかでは、
作業イメージが全く変わってきませんか？
こういった背景を把握することが大切なのです。
実装するに当たってプロジェクト担当者と実際に実装するプログラマに認識の誤差があれば、
せっかく作り込んだ時間が無駄になってしまうこともあります。
何のために作るのか、そしてどんな背景があって実装に至ったのかを把握した上で取り組みましょう。
３． 仕事の効率は「最後の5分」で決まる
２．の内容とつながるのですが、
エンジニアたるもの、開発の際に双方の認識の誤差があると、結果的に大きな時間の無駄を生んでしまいます。
人間のコミュニケーションでは、ただ相手の話をうんうんと聞き、はい分かりましたで作業を始めてしまうと、
必ず認識の差異が出てきます。
聞いた内容を忘れてしまったりもします。
その認識の差異は、のちに大きなロスを生みます。
上司「メロンパンを作れ」
新人「はい、分かりました！」
〜３日後〜
上司「まだ？」
新人「すみません…まだまだかかると思います…」
上司「そんなに時間かかることかなぁ…」
〜１年後〜
新人「ついに収穫出来ました！汗水垂らして作った新鮮なメロンです！どうぞ！」
上司「」
今思いついた極論ですが、エンジニアの世界ではそういうことがよくあるそうです。
指示を受けた際は、必ずメモを取り、最後に５分間だけもらってこう質問しましょう。
「かしこまりました。いただいた指示にしたがって、これから３つの作業に取り掛かります。
方法はこうです。もし、なにか認識に違いなどがあれば、ご指摘ください。」
最後に５分貰って、認識のズレがないかをしっかりと把握することで、正確なモノを作ることができます。
誤ってメロンを作ってしまうトンデモ勘違いも起こりませんね。
４． 質問はメモを見せながら
新人のうちは、実装の過程でつまずくことが必ず出てきます。
そんなときに、頼れる先輩に質問することも多いでしょう。
質問する際には、必ずメモを見せながら質問しましょう。
エクセルやメモ帳にまとめたものを見せながらでも構いません。
何の資料もなしに「ここがわかりません」とだけ言っても、
機能を実現する手段が分からないのか？
実現手段は分かっているが書き方が分からないのか？
コードを書いたが期待する結果が得られないのか？
ググるワードが分からないのか？
を正確に伝えることが出来ません。
優しい先輩であれば、手とり足とり教えてくれるかもしれませんが、
何が分かっていないのかが正確に伝わらなければ、「質問の意味が分からない」と一蹴されるでしょう。
先輩は経験豊富です。
あなたの何千倍も「分からない」を経験していますし、
あなたの「分からない」は過去に当然乗り越えてきています。
新人のうちは、知りたいことをうまく言語化することさえ難しいです。
だから、つまずいているポイントは箇条書きしてメモにまとめましょう。
そうすれば、何につまずいているか、何が知りたいのかを察した上で適切なアドバイスをくれるでしょう。
５． ペースメーカーとして、資格を申し込む
私が尊敬している技術力の高い先輩は、
「沢山資格を持っているからといって、その人が技術力があるとは限らない」
と言います。
「資格が仕事をするわけでなく、経験が仕事をする」そうです。
たしかに、高度な資格を持ってドヤっている人がいるからといって、「資格に受かるための勉強」をしただけで、
経験豊富で技術力があるとは言えないのかもしれません。
が、それでも私は資格を受けることには大きな意味があると思います。
（と言いつつ当の先輩はめっちゃ資格持ってるし経験も豊富だから尊敬してるんですが…）
私は、開発経験2ヶ月目にオラクル社のJava Silverを取得し、3ヶ月目にオラクルマスターのBronzeを取得しました。
参考書を読み漁り、模擬問題を解きまくりました。
資格を取った理由は、モチベーションアップです。
（個人的にモチベーションというふわふわした言葉を使うのは嫌いなのですが…あえて使います。）
仕事に対する意欲が上がるのです。
同時期に研修を受けた同僚にそれを話すと、祝福してくれると同時に「意識たけぇな〜ｗ」と言われました。
いや、そうじゃないのです。別に意識が高いからそう感じているわけではありません。
どちらかというと、私は学生時代は勉強もせず遊び呆けていたほうです。
小学校入学から最後まで、本を読んだ事なんて無かったです。
活字が嫌いで、「かいけつゾロリ」ですら読むことのできなかったタチです。
「デルトラクエスト」なんて３ページでギブアップですよ。あれは賢人の読む本。
読めてせいぜい「ミッケ！」か「ウォーリーをさがせ！」ですかね。っておいおい、そりゃ絵本やないか〜い！ｗ
・・・。
そんな私が、資格取得の勉強をするに至った理由はなぜか？
理由はたったひとつです。
分からないことが多すぎて、つまらなかったからです。
現場デビュー１日目で、プロジェクトの概要を掴むためにまずコードを読むことから始まったのですが、
簡単なコードことさえ読めず、挫折しました。めちゃくちゃ悔しい思いをしました。
どうすれば仕事が面白くなるか？
考えた末、私は思い立ちました。「そうだ、資格、取ろう。」
そうして勉強を始めたのでした。
資格を取得した結果、取得する前と比べても面白いぐらいコードが読めるようになりました。
「読める、読めるぞ！」
気分はム○カ大佐。最高の気分です。
エンジニアって、楽しい！ヒャッホ〜！！！
（まだまだ全然未熟者ですが…。）
・・・何が言いたいかというと、資格を取ることでモチベーションが上がり、
仕事がより面白くなるのです。
業務に当たり、「あのAPIを組み合わせてこんな機能も追加すればもっと便利になるな？」
そんな発想も生まれるようになりました。
勉強、という堅苦しいものではなく、仕事を面白くするために取るべきだと私は思うのです。
もし今、仕事がつまらないと感じているのであれば、資格を取ってみましょう。
どうせ仕事するなら面白いほうがいいじゃないですか。
プログラミング、分かったら面白いですよ。
会社で金銭面の補助を受けられるならなおさらです。
ただ、資格マニアにだけはならないように気をつけましょうね。
やっぱり経験に勝るものはないです。
まとめ
- 新人が完璧なコード書くなんてまず不可能。50点の段階でまず上司に見せてフィードバックをもらおう。
- どんな背景があって、何のためにこの機能を実装するのか？を把握することで仕事の出来が向上する。
- 指示を受けた際は必ず最後に５分だけもらい認識の誤差がないか確認しよう。
- メモを見せながら質問したほうが、より適切なアドバイスをもらえる。
- 資格はいいぞ。
以上、著書「入社１年目の教科書」を読んで、エンジニア向けに５つにまとめた記事でした。
ぺーぺーが偉そうに失礼しました。
私と同じ立場の新人の方。共にこの厳しい技術社会で切磋琢磨して生き残りましょう。