ユアマイスターアドベントカレンダー2018 の22日目の記事です。
はじめに
私は現在、ユアマイスター株式会社でインターンシップ生として働いています。
現在はインターンを始めて1年になります。平均で週3回ほどの出勤をしており、計算上1年の1/3ほどをインターンをするということに費やしていると思います。日数にすると120日ほどが経過しています。
先日PHPの効率的な学習法: YYPHP60回開催を通じて、先輩PHPerから得られた35の知見を読ませていただき、その話を社内で書いたところ、弊社CTOから**「インターンとして出勤100日を超えて先輩エンジニアから学んだ〇〇個の知見」というので記事書いてみたらという話になったので今回書いてみました。
今回はアドベントカレンダーの25日間にちなんで、25個の知見**をまとめたいと思います。
現在ユアマイスター株式会社では、社員エンジニア及びエンジニアインターンが多数在籍しており、今回はその中でも先輩エンジニアから学んだことを今年の終わりに残しておきたいと思います。
インターンを行う環境
まず最初にどんな環境でインターンをしているかというのを書いておきます。
ユアマイスター株式会社では「あなたのマイスター」というユーザーとハウスクリーニングプロや靴やカバン修理を行う職人さんを繋ぐサイト、大切なものを大切にしたい人のためのメディアサイト「RELIVERS」を運営しており、私はその2つのサイトに携わっています。
あなたのマイスタートップページ
今回記事を書くにあたって
この1年を通して、インターンという立場を最大限生かして、先輩エンジニアから多くのことを学びました。それは間違いなく、私自身を成長させるきっかけになり、また今後のエンジニアとしてのキャリアの形成やエンジニアとしての人生に置ける価値観の基準を作っていく上で重要なものになると思います。
ここで1度、ほとんどプログラミング初心者の大学生がこの1年を通して学んだことをまとめたいと思います。
先輩エンジニアとしてという部分と先輩社会人という部分から学んだことの両方の観点でまとめたいと思います。
この記事は、未来のユアマイスターでインターンをするエンジニアインターンや、エンジニアを志す人に読んでもらえればと思います。
先輩エンジニアから学んだ知見(エンジニアとしての心構え編)
1.英語を避けない
自分が調べたい情報が日本語にはなくStack Overflowなどの英語のサイトや、ドキュメントが日本語されていない場合も多々あります。自分の経験則ですが、英語のサイトには日本語のドキュメントにはない有用な情報もあったりするので、英語を読むことが自分のやりたいことの近道になる場合も多々ありました。
2.自分の知らないことに積極的に挑戦する
エンジニアをやる以上、常に学び続けなければなりません。言語のトレンドや、アップデートによる機能の追加により今までの知識が役に立たなくなることも多々あります。
新規に学ぶ知識によって、未来に役に立つことや自分の成功体験に繋がり、あの時これができたのだからこれもできるという自信に繋がります。未熟者の私でも新規に挑戦して成功した際の経験は、何か新しいことをやる際の自信に繋がっています。
3.期限を守る
仕事の期限を守ることは当たり前ですが、なかなか当たり前にできることではありません。期限を守ることで信頼が生まれ、次の仕事をもらい、信頼を積み重ねることで大きな仕事やチャンスをもらいエンジニアとして成長するきっかけができます。
4.話の中でわからないことはメモを取って後から調べる
他のエンジニアと話をする時にわからない単語の１つや２つはあると思います。会話をしたその場ではわからないのは仕方がないので、後からでも必ず調べるということが重要になると思います。ここで重要になるのは、わからないことをわからないままにしないということであり、自分の知識を増やすことが成長への第一歩になると思います。
5.人と話をする際は結論から話す
何が起きているかの現象を話すのではなく、何の話をしたいのかという結論から話すことで相手は聞き取りやすいということです。一般的にPREP法と呼ばれる方法Point(結論)=>Reason(理由)=>Example(事例、具体例)=>Point(結論)という順番で話をすることで、自分の伝えたいことが相手に伝わりやすくなりました。状況の確認や、相談、質問をする際には心がけています。
以下の記事を参考に質問の仕方を工夫するようにしました。
質問は恥ではないし役に立つ
6.レスポンスは早い方が良いということ
何か、言われた際にレスポンスが早いということは強みになるということを学びました。コミュニケーションをとる際には時間がかかります。誰かに何かをお願いしたり、自分が質問をする際には、レスポンスを早くすることで円滑にコミュニケーションを取れると思います。
7.効果のあるコミュニケーションをとる
何か仕事を任された際に、事前に意思決定を行える立場の人と、「こういう風に実装をしようと思いますが、この方針で良いですか？」という確認を行えばそれだけ手戻りが減って効率が良くなると思います。エンジニアはただパソコンに向かってコードを書けば良いだけではなく、効果的なコミュニケーションをとることが仕事の質を上げることにつながると思います。
8.扱う言語や環境が異なっても戦えるエンジニアを目指すこと
ユアマイスターでは、元SIer出身のエンジニアの方が多いです。SIer時代では、Javaをメインで書いていて、今ユアマイスターではPHPやRubyだったり、そもそものシステムの設計や環境が異なる現場で働いています。今やっている仕事から学んだことから、次の仕事をやる必要があり、言語や環境が異なるから戦えないではなく、どこに行ってもどんな環境でも戦えるように汎用的な知識や経験を積む必要があるということを学びました。自分の手持ちのカードを増やしつつ、それをデータ化することで、「この時はこうだったから、今回もこんな感じでできるだろう」という予想ができると思います。
9.ユーザーが本当に欲しいものは何だったのかを一番に考えること
自分がどう実装したいのか考えるのも必要だが、何がユーザーにとって一番必要なことなのかを考えることを学びました。実装が簡単・難しいということが判断基準ではなく、「どうやるか？よりもなぜやるのか？」を大事にしなければならないと思いました。
10.インプットをしたら必ずアウトプットをすること
インプットをした際には、わかった気になってそれで完結してしまうことがあります。できるエンジニアや先輩エンジニアは何かを学ぶとなった時に必ず、インプットとアウトプットを行います。たとえうまく説明ができなくても、自分がわかったからわかるではなく、他人に説明ができることがインプットが定着するということなので、必ずこの２つはセットにすべきだと思いました。
11.ROIを意識すること
時間は有限で例えば、クリック率を0.0001%上げるために5時間実装をするというのは現実的ではありません。掛けた時間に対して自分や他のエンジニアが適切だと感じるリターンがあるかということを考えて仕事をしていかなければならないと思います。
12.他人のコードは読んだ方が良い
他人のコードには自分には発想できなかったユニークなものや、自分が実装するよりもシンプルなコードがたくさんあります。他人のコードを読むことで、「こういう書き方あったのか」学んで良いものを取り入れていくという姿勢が成長につながると感じました。
13.優先順位を明らかにすること
仕事だけでの話ではないですが、多くのやるべき仕事をあれもこれもやろうとなった時に中途半端になります。そこで、何を一番最初にやらないといけないのか優先順位をつけてやっていく必要があると感じました。
14.コードに対してなぜ動くのかという疑問を持つ感度を高くする
できたなら良いかと適当な気持ちがあるままではエンジニアとして低いレベルにいるままなのではないかと思います。そのままでは、仕事はできたとしても、何か問題に当たった時にその問題を乗り越えるのが困難になります。色々な物事に疑問を持つことができる人間、エンジニアになることが活躍できるかに関わる気がします。
15.技術的負債になりそうな部分は早々に取り除く
規模が大きなシステムになればなるほど、小さなひずみが大きな亀裂につながります。一番は技術的負債を作らないことですが、小さなうちに潰すことが大事だと思います。
先輩エンジニアから学んだ知見(効率化編)
16. 自分が一番やりやすいと思える入力機器(キーボードやマウス)を使う
エンジニアにとって、マウスやキーボードは勤務時間のほとんどを共に過ごす親友のようなものです。腕が疲れにくいものやキーのストローク、打鍵感の違いで生産性がUPするのを実感しました。
17.面倒な単純作業はスクリプトを書く
以前、業務改善のためにPHPでWEBスクレイピングをやってみたという記事を書きました。この記事にあるようにちょっとしたスクリプトを書くことで、大幅に時間を節約することができました。エンジニアリングで解決できることはエンジニアなのだから解決できないのかという考える姿勢を学びました。
18.便利なツールはどんどん使う
私が先輩エンジニアから教えてもらったツールでよく使うのは、クリップボード拡張アプリClipyやスクリーンショットSkitch、Google Chromeの拡張ツールで全画面スクリーンショットができるFireShotです。このようなツールを使うことで効率良く仕事ができて、仕事を早くできます。
クリップボード拡張Macアプリ「Clipy」を公開しました
Skitch
FireShot
19.ショートカットを使う
例えば、インスタンスであるthisを入力するだけでPHPの$this->までを自動で補完するといったショートカットを登録し、利用するだけで時間が短縮できます。1回1秒短縮できるとして、100回やれば100秒、1000回やれば1000秒、短縮できた分の時間で、より良い実装を検討したり、新しい知識をインプットしたり、他人より多くの仕事ができたりする。使える時間を増やすことができます。
先輩エンジニアから学んだ知見(エンジニアリング編)
20. エラーが発生した際には何が原因なのか問題点を洗い出す
エラーが発生した際に、「エラーが発生した！」というのではなく、ハードウェアの部分なのか？ネットワークの問題なのか？それともミドルウェアか？ソフトウェアの問題なのか？それとも自分が何か変更したことによるエラーなのか？ということをきりだせるようした方が良いです。エラーの原因、箇所によって解消法が異なるので、具体的にエラーの内容・原因を言語化できるようになるとエラーが早く解消できるようになると思います。
21.自分が苦労したコードでも容赦なく捨てる
自分で1から数時間かけて、書いたコードであってもそれが悪いものであれば捨てる勇気を持つべきだということを感じました。コードを書く上で必要なことは、可読性の高い美しいコードを書くことやメンテナンス生が高いコードを書くこと、実現したい要件を最短距離で実装できているものだと思います。自分よりも良い実装を見た際には素直に受け入れる、そこから学ぶべきことは何かということを考えることが、次の成長に繋がると感じました。
22.動くものを早く出す
実現したい機能のソースコードをできるだけ早くだすことが重要だと感じました。例えば、2週間でリリースまで持っていく仕事があった際に、1週間で必要最低限の実装を終わらせ、レビュワーや意思決定を行う立場の人に見せることができれば、残り１週間はどのように今よりもよくするか？という議論に時間を当てることができます。
23.無理に一行で書かない
PHPで言えば、三項演算子を使って長いコードを一行で書く場合がありますが、可読性を求めるのであれば無理に一行で書かないというのもありだと知りました。SQLだったり、可読性をあげるコードを書く工夫をすべきということを感じました
以下のような例です。
<?php
empty($showText) ? echo '何かしらの文章が入るのでものすごく長くなる文字列' : echo 'こちらもものすごく長くなりそうな文字列が入ります'
if (empty($showText)) {
echo '何かしらの文章が入るのでものすごく長くなる文字列';
} else {
echo 'こちらもものすごく長くなりそうな文字列が入ります';
}
<?php
$dbh->prepare("UPDATE messages set read_flg = :read_flg where messages.send_by = 0 AND message_from = :message_from");
$dbh->prepare(
"
UPDATE messages set read_flg = :read_flg where messages.send_by = 0 AND message_from = :message_from
"
);
24.変数名の命名は命
以前、CakePHP自体のソースコードを読む機会がありましたが、フレームワークの実装を見ていると、$messageや$textのように抽象的な変数名が記述されており、コードを読み解くのに苦労しました。中にどんなメッセージが入っているのか？が一目で分からず、苦労するという経験がありました。
タイトルの通りで、名は体を表すというようにその名前が「変数の何を表しているのか？」をコードを読んでいる人が直感的に理解できる命名をしなければならないと思いました。
25.テストケースを細かく考慮する
私も含め新人エンジニアは先輩エンジニアに比べ、テストケースを考慮しきれないことがあります。違いは何だろうと考えた時に、2つあり、1つめは経験の差2つめは明確なリストを作るということです。リスト化することで抜け漏れが発生しにくくなると思います。
#おわりに
この1年非常に多くのことを学びました。
ただ、私の力不足で自分が学んだことをうまく言語化できていない部分も多くあります。
来年の春からは1人の社会人・エンジニアとして働き、いつかは先輩になり後輩に背中で語れるエンジニアになりつつ真正面から向かい合えるようなエンジニアになることを目標にしています。
その際に自分が先輩エンジニアから何を学んだのか？というのを言語化できるように今後一層知見を貯めて、言語化していきたいと思います。
自分は先輩エンジニアにこんなことを学んだというものがあればコメントいただけると幸いです。