はじめに
みなさんこんにちは!!株式会社LITALICOでエンジニアをしている福嶋です!この記事は『LITALICO Advent Calendar 2021』20日目の記事です!🔥
【記事のテーマ】
26歳で未経験からエンジニアになった自分がやってよかったと思うこと3選
【目次】
1.前提
2.WEBエンジニアとしての基礎知識を叩き込む
3.土台となる「考え方」に磨きをかける
4.とにかく開発量を増やしていく
5.まとめ
#1.前提
自分の経歴
自分の経歴としては、ざっくりこんな感じです。
- 大学 : 某文系大学
- 1社目 : 塾講師
- 2社目 : プログラミングの講師(テックキャンプという場所)
- 今 : エンジニア
元々文系な上に、就職した業界もITには全く縁がなく、「え?プログラミングって何?」という状態でした。しかし、テックキャンプのメンターを経験し、プログラミングの面白さに気づき、エンジニアになることを決意しました。
自分は不利だと思っていた
自分の場合、26歳で業界未経験で文系というかなりハンデがある状況でエンジニアになったと思います。僕より同年代やお若い方でも相当なスキルを持ち、劣等感を感じることも沢山ありました。
しかし、思い悩んでも仕方ありませんし、少しでもエンジニアとしてスキルを磨いて市場価値を高めたいと思いました。「周りの人が、なに言っているかわからない。。。😭」「コード全然書けない。。。」「え?設計するの??」という残念な毎日を脱するためにやったことをご紹介します。w
#2-WEBエンジニアとしての基礎知識を叩き込む
WEBエンジニアとしての基礎知識とは?
下記の3つを、「WEBエンジニアとしての基礎知識」として定義しました。
- WEB/アプリケーションの仕組み
- エンジニアとしての共通言語
- 理想とするコーディング手法/設計手法
それらを体系的に学ぶためには、本を読むのが一番手っ取り早いと感じました。しかし、私個人的な問題ですが読書は非常に苦手ですwそこで、5冊に焦点を絞って読みました。それらを紹介したいと思います。
イラスト図解式 この一冊で全部わかるWeb技術の基本
本の題名通り、WEB技術の基本が図解とセットで解説されています。この本の特徴は、見開きでシンプルな説明と図解で展開されており、頭でイメージしながら読み進められることです。ネットワーク/システムの基本設計/セキュリティに関して体系立てて学ベるので、必要最低限の知識をインプットするには最適だと考えています。
###リーダブルコード
どんなことを学べるかをざっくり説明すると下記の通りです。
- 読みやすいコードとは?
- 適切なコメントを書くこと
- 美しいコードを書くには?
- 読みやすい条件式
- 適切な変数名の付け方
- 長すぎるコードをどう短くするか?
などです。僕みたいに、独学だけでプログラミングを勉強した人は絶対読むべきだと思っています。「単一責任の原則」・「抽象度を揃える」などわかりやすいコードを書くためのいろはが説明されています。**自分のコードが他の人にとってわかりやすいものになっているか?**を振り返るために時々読み直すようにしています。
例えば、以下のように初めにガード節(returnで返す)でネストを浅く出来るよねといった、コードをわかりやすくするためのノウハウが詰まっています。
# わかりづらい
def judge_discounted_price(person, price)
if person[:member] == 1
price = if person[:times] == 1
price * 0.9 - 1000
else
price * 0.9
end
else
price
end
end
# わかりやすい
def judge_discounted_price(person, price)
return price if person[:member] != 1
if person[:times] == 1
price * 0.9 - 1000
else
price * 0.9
end
end
オブジェクト指向設計実践ガイド
この本はとても分厚いので、私は、通称鈍器と呼んでいますw
さて、オブジェクト指向とは、システム構成の考え方のことです。詳しいことを知りたい方は下記の記事をご参考ください。
>>初心者向けに徹底解説!オブジェクト指向とは?
この本を読んだ理由は、2つあります。
-
エンジニアとしての共通言語を学ぶため
- モジュール・依存・単一責任・ダックタイプ・インターフェイスなどそれらの概念をインプットする
- Rubyなどオブジェクト指向言語の理想的な設計手法を体系的に学びたいため
- 理想的な設計手法をいつ、どう言った場面で使うのが理想的なのか?
この本を読んだおかげで、エンジニア同士の話についていけるようになっただけでなく、自分でコーディング・設計する際に自然と意識出来る様になりました。
オブジェクト指向における再利用のためのデザインパターン
オブジェクト指向を学んだ後に読みました。オブジェクト指向言語において、設計書のカタログみたいなイメージを持っています。
ちょっとわかりづらいと思うので、Decoratorパターンというものを紹介してみます。
# Decoratorパターンを使用しない例
class User < ApplicationRecord
def name_with_prefix
prefix = gender == '男性' ? 'Mr.' : 'Ms.'
name + prefix
end
end
# Decoratorパターンを使用した例
class User < ApplicationRecord
end
class UserDecorator
attr_reader :user
def initialize(user)
@user = user
end
def name_with_prefix
prefix = @user.gender == '男性' ? 'Mr.' : 'Ms.'
name + prefix
end
end
Decoratorパターンを使用する事で、Userモデルが書き換えと保存どちらも実装してしまっている状態を切り離しました。その結果、後に様々な機能を追加できるよねという感じです。
一例ですが、こういったオブジェクト指向を使いこなすためのカタログのようなものが多数紹介されています。そのため、オブジェクト指向の感覚を磨くには最適の本でした。
アルゴリズム図鑑 絵で見てわかる26のアルゴリズム
簡単にいうと、アルゴリズムは「手順や計算方法」のことです。
>>アルゴリズムとは?
アルゴリズムという名前が結構、いかついですよね・・・w
しかし、この本では、配列・スタックなどのデータ構造などの話から始まり、ソートや探索の方法などを図解でわかりやすく説明されています。
例えば、下記の記述を見てください。
値を探す方法として、線形探索と二分探索があります。記述の仕方としては、線形探索の方がシンプルですが、1個1個マッチした数字を探すため計算量が多くなってしまいます。
しかし、二分探索のような探し方だと、全てを比較する必要がないため、計算量が線形探索より少なくなります。こう言った手順や計算方法を、基礎知識として持つのはエンジニアとして重要だと考えています。
# 線形探索
def linear_search(array, target)
array.each.with_index(1) do |num, index|
if num == target
puts "探している値は#{index}番目にあります"
return
end
end
puts "#{target}は見つかりませんでした"
end
array = [14, 32, 45, 67, 89, 122, 245, 367]
puts '探索したい値を以下から選んで、入力してください'
puts array.join(' , ')
target = gets.to_i
linear_search(array, target)
# 二分探索
def binary_search(array, target)
head = 0
tail = array.length - 1
while head <= tail
center = (head + tail) / 2
if array[center] == target
puts "#{target}は#{center + 1}番目にありました"
return
elsif array[center] < target
head = center + 1
else
tail = center - 1
end
end
end
array = [14, 32, 45, 67, 89, 122, 245, 367]
puts '探索したい値を以下から選んで、入力してください'
puts array.join(' , ')
target = gets.to_i
binary_search(array, target)
以上が、私が読んだ本になります。
#3-土台となる「考え方」に磨きをかける
目先の答えを求めても意味はない。
正解や最終的なアウトプットだけを安易に求めようとすることは、短期的には良くても長期的には良くないと思っています。。**土台となる「エンジニアとしての考え方」**の部分に磨きをかけることで、どんな場面でも自力で考え抜き、やり切る力が着くのではないかと考えました。長期的に見ると、こういった振る舞い方の方がメリットがあると考えました。
身につけるために意識してきたことは2つあります。
- 先輩エンジニアに物事を聞く際は必ず、自分の**「仮説」「試したこと」**を伝える。出来るだけ、テキストベースでまとめることで、自分の考えがまとまっていく。
- 理由 : 自分の考え方や行動に対してFBをもらえるようにするため
-
他のエンジニアの方の実装や設計の背景や理由を必ず聞く
- 理由 : 自分より経験を積んでいる方の思考回路を奪うことで、自分の考え方に磨きをかけるため。
#4-とにかく開発量を増やしていく
副業は自分のスキルを拡張し、経験を増やすツール
これは完全に持論ですが、結局は**「経験の量×FBの量」**が周りと差をつけるのではないかと考えています。自分は、26歳でエンジニアになり、さらに、特段エンジニアとしてのセンスはないと思っていますので、周りの数倍早いペースで経験を増やしたいと考えました。
そこで、私は副業でも開発することでとにかく量をこなすことを意識しました。
インプット << アウトプット
インプットが悪とは言いません。しかし、結局は現場での実戦の数が多いほど強いエンジニアになると思ってます。「実戦の場で知識が足りなかったら、そこでインプットすれば良いよね」という発想なので、私は如何にアウトプットする環境を増やすかに重点をおいております。
#5-まとめ
まとめに入ります。自分が未経験からエンジニアになってやってよかったと思うこと3選は下記の通りです。
- WEBエンジニアとしての基礎知識を叩き込んだこと
- 土台となる「考え方」に磨きをかけること
- 副業などを通して開発量を増やしていったこと
もし、少しでも参考になりましたらいいねお願いします!
明日は、@kazuisさんによる5段階モデルによるシステムデザインの進め方になります!