はじめに
私は未経験からWeb系エンジニアに転職しました。
Web系エンジニアとして8ヶ月ほどの勤務を通して痛感した、身につけるべきマインドを紹介したいと思い、本記事を執筆しました。
本記事で話す内容は万人受け・全ての企業に当てはまるとは思いませんが、
Web系エンジニアとして働く上で本当に大事だと感じたことを5つにまとめましたので、誰かのお役に立てれば幸いです。
目次
本記事の対象者
- Web系エンジニア就職直後の人
- Web系エンジニア転職活動中の人
話すこと
- 自身の経験に基づいた、Web系エンジニアとして入社後に働く上でのマインド的な指南
話さないこと
- 技術的なエッセンス
- 万人・全ての企業に通づるようなこと
何者か
私は新卒後病院で看護師として従事しておりました。
その後、スーツを着て働いてみたいと感じ、思い切って会社員に転職。
医療機器商社にてサービスエンジニアとして、レーザー脱毛機などの高度医療機器の修理・保守メンテナンスなどに従事しておりました。
かねてよりIT分野に興味があり、プログラミングにハマり、これを仕事にしたいと感じ半年間プログラミングスクールに通ったのち、東京都内のWeb系企業に内定をいただきました。
現在はエンジニアとして入社後8ヶ月が経過しており、これまでECサイトリニューアルプロジェクトや、システム構築などに携わっております。
要件定義から携わり、これまで主要言語としてPHP、Java、Python、Go、Kotlinなど、フレームワークはSpringBoot、Laravel、Ginなど、その他AWS、GraphQL、NoSQLなど様々なサービス・技術に触れてきました。
また、最近は採用面接官の仕事なども担っております。
次々と学ぶことが増え、目まぐるしい日々を過ごしておりますが、なんとか食らいつきながら奮闘しております。
入社してから絶対にやるべき５つのこと
技術を目的でなく方法と考えよう
メリット
- 成長スピードが速くなる
- 自分がどんなエンジニアになりたいかを見極められる
- 任されるタスクが広くなる
なぜそう思ったか
確かに入社直前、直後は「PHPを極めたい！Kotlinを極めたい！JAVAシルバーを取得する！」みたいなことを考えて、分厚い技術書を買って1ページ目からじっくりゆっくり勉強していました。
そんな中でこのような教えを受けました。
エンジニアとしてそこを目的とするのは良くない。一つの技術に依存しない方がいい。
あくまで技術は方法として捉えるべきだ。
目から鱗でした。
確かに働いている中で、次から次へと新しい技術に触れる場面が多々あり、1つの技術に固執していると間に合わないなと感じます。
エンジニア転職活動中、あるいは転職後早期に1つの言語に固執する学習は避けた方がいいと思います。
まずは業務で必要な技術・知識から派生するように学習し、ナレッジをためていくことがベターです。
その上で、長期的な目線で何か極めたい技術・言語があればそこを目指すのが良いかと思います。
逆に未経験でありがちですが、フルスタックエンジニアを最初の目標とするのも良くないです。
これは自分も痛感しましたが、まず無理です。
バックエンド、フロントエンド、インフラ、と社内にはそれぞれのエキスパートが少なからず在籍していますし、自分があれこれ手を出すより、得意分野を発揮してチームでプロジェクトを進める方がよっぽど生産性が高いです。
採用面接をしていると、「どんなエンジニアになりたいですか？」の問いに対して「フルスタックエンジニア」と答える方が存外多いです。
明確な理由があれば別ですが、まずフルスタックという表現だけで技術に固執している感じがしますし、技術に固執しているとそれはうちの会社に合わないなと落ちやすくなると思います。
未経験は特に、現場経験を重ねて、スコープを固めた方が成長スピードが圧倒的に早くなると思います。
私はもっぱらバックエンドですが、同時進行でフロントやインフラ知識を蓄えようとすると今の状態まで成長できていなかったと思います。
それだけスコープを定めておくとできるタスクが広くなると思いますし、チームの中での自分の役割も見えやすくなると思います。
ググる力を身につけよう
メリット
- 作業スピードが向上する
- ミーティング中の貢献度が高まる
なぜそう思ったか
入社してから エンジニアは調べる時間が圧倒的に多い ということを強く感じました。
エンジニアになる前のイメージでは、エンジニアはプログラミングをずっとしているものかと思っていました。
実際には
- 条件文ってどうやって書くんだっけ？
- クラスの書き方忘れた・・・
といった基本的なことから
- バグの原因はパフォーマンスの悪いコードの書き方にあるのかも？この書き方を直すことでどれだけ計算量が改善されるのだろう・・・
といった、言語の仕様に少し入り込んだことまで
ググる -> 記事を見る -> わからない・・ -> ググる -> ちょっとわかってくる -> ・・・ -> 解決！
といった流れでググりまくって解決に近づいていきます。
ミーティングを行なっている最中でもその場でググって設計の方針を決めていくといったことも多くあり、検索のコツを覚えるのは非常に大事だと感じました。
検索にはオプションがあり、細かく検索オプションを指定することもできます。
私の場合、以下のコマンドを特に多用しているので是非活用してください。
| コマンド | 説明 |
|---|---|
| ""（ダブルクォテーション） | そのキーワードが完全に一致するサイトだけを検索できる。 |
| -（ハイフン） | 指定のキーワードを検索対象から除外できる。 キーワード -除外したいキーワード のように書きます。 |
また、ドキュメントや技術的な記事は英語のものが多いので、英語版Googleを使うことも非常に良いです。
英語版Google : https://www.google.co.jp/?hl=en&gws_rd=cr
自分の所属するチームの枠を超えて多岐にわたるメンバーとの接点を持とう
メリット
- 得られる情報量が圧倒的に増える
- 人脈形成につながる
- 仕事が楽しくなる
なぜそう思ったか
私のように受託で開発していると(あるいは自社開発としても)少なからずプロジェクトごとにチームで勤務する事になります。
当然ながら日々のコミュニケーションは自分の所属するチームメンバーと行うのがほとんどです。
それだけではもったいない。
多岐にわたる人と会話することは得られる情報量が圧倒的に増えます。
何気ない会話も自分の糧となる事があります。
私は仕事の中ではバックエンドチームの枠を超えて積極的にコミュニケーションを図り、最大限情報を得ようとしています。
- フロントエンドメンバー
- インフラメンバー
- PMO
- 同じプロジェクトでも別スクラムのメンバー
- これまで携わったプロジェクトに所属していたメンバー
- 部活動といったコミュニティメンバー
などなど
例えば別のプロジェクトでAWSでこれこれこういった構成でシステムを作っているとあれば、自分のプロジェクトでも少し参考になる部分があったりして、詳しくヒアリングしてみる、といったように何気ない会話の中でも自分のチームの発展につながるようなヒントが見つかるものです。
社内で顔見知りが増えると、すれ違いに挨拶したり、会話したり、食事に行ったり、休日に遊びに出かけたりとより交流の機会が増えます。
すると自然と仕事も楽しくなるものです。
チームで働く以上コミュニケーション能力があまりに低いと全体として仕事の生産性も落ちていきます。
（コミュニケーションエラーでプロジェクトの進行が大幅に出戻り、なんてことも稀にあります。）
技術さえ備わっていれば素晴らしいエンジニアになるということなんてないと思います。
ぜひ入社したら、まずは同僚から徐々にコミュニケーションの輪を広げてみてください。
ちなみにですが、社外でも勉強会といったコミュニティに参加してみるのもありです。
- connpass : https://connpass.com/
- TECH PLAY :https://techplay.jp/
あたりがおすすめです。無料参加できるものも豊富で、質も高めです。
タスクを自ら取りに行こう
メリット
- 評価につながる
- 成長スピードが速くなる
- 工数見積力が身に付く
なぜそう思ったか
特に未経験者は実際に業務に入っても最初のタスクは「資料見といて」的なことが多いです。
その後もコンスタントにタスクが舞い降りてくると思い待ちの姿勢でいるよりも、自らタスクを取りに行くような姿勢を見せることが間違いなく評価につながります。
そのためにも、プロジェクトに参画したらまずは早いうちに要件を把握しておくことがいいと思います。
要件把握は仮に下流工程担当だったとしても重要なタスクだと思います。
- Slackなどのチームのコミュニケーションツールに参画するのであれば、常にプロジェクトの動向をチェックする
- メンションに自分がついてなくても見る。
- 結構同じプロジェクトでも複数チャンネルがあったりするので、極力全てに参画するよう働きかける。
- コミュニケーションで不明な点があれば逐一解消する。
- 疑問でも意見でもなんでも積極的に会話に参加していく。（正直仕様書読み込むよりも会話する方が圧倒的に情報の吸収性が高いと思います。）
- もし WBS（作業分解構成図） が引かれてればタスクが一覧化できるので小まめにチェックする
こんな感じで早々に要件把握を進めながら、
日々のコミュニケーションの中で自分ができそうなタスクがあれば積極的に取りに行きましょう。
その際にはまずは自分なりに工数を見積もって見るのも大事です。（2日くらいでできると思います！みたいな）
この経験を重ねてくると自ずと
自分の今の技量ならこれくらいのタスクならこれくらいでできそう。
逆にこのタスクは難しいから誰かに協力も得ないといけない。
と言ったように工数を見積もる力が身についていきます。（これが結構大事）
ただ、積極的にタスクを取りに行くと言っても、できなければ意味がないので、
適切なタイミングでアラートを出すことも非常に重要です。
自分なりに見積もった工数内でできなければ延期してもらう、
あるいは別の人に手伝ってもらうなど、「できませんでした」と報告することがないようにしたいですね。
このサイクルをできるだけスピーディに回すことで、自分の成長スピードも速くなりますし、評価にもつながります。
実際の現場は個人ではなく、チームで働きますので、積極的にタスクを取りに行きチーム内でバリューを発揮できるように頑張っていきましょう。
アウトプットを積極的にしよう
メリット
- 自身の理解の整理になる
- チームの生産性向上につながる
- アウトプットの品質向上につながる
なぜそう思ったか
特にプログラミング初学者は最初に下記のようなことをやりがちだと思います。
- いくつもの参考書を読み切る
- 資格の勉強をする
どちらもスキルを高めるために重要なことですが、先にやるのは悪手で、プログラミングでは インプットよりもアウトプットが重要 だと感じました。
その理由として、インプットに力を入れすぎると
- プログラミングの目的を見失い、モチベーションが下がる
- 一番大事なスキルであるアウトプット力が身につかない
といった状態になってしまいます。
- そこそこ参考書を読んでインプットをする
- ある程度開発できそうだし、アウトプットしてみる
- 分からなくなったら参考書を読んでみる
1を行った後、2, 3を何度も繰り返してスキルを付けてくのが理想です。
私の周りでも参考書を読んで最初は楽しいけど、何故読んでいるのか分からなくなって途中で挫折した といった話をよく聞きます。
アウトプットとしては色々な形がありますが、私が 今まで行ってきて力がついたな と思うものとしては下記があります。
| アウトプット方法 | メリット |
|---|---|
| Qiitaなどに投稿してみる（この記事のように！） | ・LGTMを多くもらうにはどうすれば良いか考えるようになる（＝需要のある内容ってなんだろう、と考えるスキルが付く） ・文書化することで自身の考えを整理することができる |
| アプリ・サービスを作ってみる | ・参考書からなどでは得られない、開発のつまづきポイントがわかる。 ・一から開発する能力がつく ・目的が決まってモチベーションになる |
| 会社で勉強会を開催する | ・プレゼン能力がつく ・質疑応答で要点を摘んで説明するスキルが付く ・文書化することで自身の考えを整理することができる ・チームへの貢献度が高まる |
他にも色々あると思いますが、プログラミングのスキルを伸ばしたいけど何をしようかな・・という方はぜひこれらを試してみてください。
おわりに
ここまで長文をお読みいただきありがとうございました。
思ったより熱が入り、情報量が増えすぎたかもしれません。
冒頭でもお話ししましたが、私の経験則に基づくものなので全ての企業に当てはまるとは思いませんが、少なからず重要であることは間違いありません。
どなたかのお役に少しでも貢献できれば幸いです。