未経験からのエンジニア転職者向け！複数内定を獲得する人の4つの共通点
未経験からエンジニアへの転職を目指す際、最後の関門となるのが選考活動です。
今回は、複数の内定を獲得している人たちの共通点を4つ紹介したいと思います。
これらの方々は、SESだけでなく、自社で受託開発を行っているSIerや自社開発企業からもオファーを受けています。
数年前、私は自社サービスを開発しているIT企業で人事部として採用担当を務めていました。そして、半年前から未経験者を対象としたエンジニア転職のサポートを開始し、大変ありがたいことに、何度かご相談を頂いております。
その中で、いくつかの共通点が浮かび上がってきました。今後もこのサポートを継続することで、さらに多くの気づきが得られると思いますが、現段階での共通点を、記録としても残す意味でまとめてみたいと思います。
主なポイントは以下の通りです：
①学習期間の長さ・密度
②応募数の多さ・応募する場所
③選考対策
④企業との対話の質
以下、これらのポイントについて詳しく解説していきます。
①学習期間の長さ・密度
多くの方が本業の傍ら学習をされていると思いますが、内定を獲得する多くの方は、大体9か月～1年程度学習を継続しています。
内定を複数獲得する方の特徴として、色々な技術に手を出すのではなく、一つの技術に集中して取り組む傾向があります。
プログラミング言語は多岐に渡りますが、HTML/CSSを基本として、その後は一つの言語に専念しています。JavaやPHPなど、選択する言語は人それぞれですが、学習期間中に複数の言語に手を出すことは少ないです。
重要なのは、習得すると決めた技術に対して、インプットとアウトプットを繰り返しながら集中して取り組むことです。
一つの言語をしっかりと習得すれば、他の言語の習得スピードは格段に速くなります。そのため、企業が複数の言語を求めていても、すぐにキャッチアップしてくれるだろうと判断できます。
また、前述の通り、インプットだけでなく、アウトプットも重要です。ブログやSNSはアウトプットの一つですが、学習過程で自分でシステムを開発することに重点を置き、アウトプットの量を増やしています。
多くのアウトプットがあると、ポートフォリオの質も向上します。実務経験とは言えないまでも、疑似的に実務経験に近しい練習を繰り返しているので、現場で活躍してもらえるイメージが湧きやすくなります。
学習期間だけでなく、アウトプットを繰り返しながら、その密度を高めることが大切です。
ポイント：
・一つの技術に集中して学習を進める
・インプットだけでなく、アウトプットの量と質にも注意を払う
②応募数の多さ・場所
複数の内定を獲得している人たちは、多くの企業に応募しています。練習を含め、2～30社に応募する人が多く、さらに多くの企業に応募する人もいます。
また、それを多いとは思っていません。当然のこととして取り組んでいます。そもそも、簡単に内定がもらえるとは考えておらず、不採用になってもモチベーションは低下しません。
実際、企業の都合や文化、選考のタイミングなど、様々な理由で見送りになることがあります。その理由は、必ずしも応募者の実力だけではありません。多くの場合、その理由は明かされません。
一つ一つの不採用の結果を過度に気にするのではなく、次の選考に向けて気持ちを切り替えることが大切です。面接では、そのような前向きな姿勢も評価されます。
今までしっかりと学習を積み上げたという自信を持って、選考に臨んでください。
もし、技術的な質問に答えられない場面が多い、ポートフォリオに対する反応が良くない、または質問が少ない場合は、学習が不足している可能性が高いです。コミュニティやメンター等を利用して第三者に見てもらう事も含めて、再度学習をしてから臨むようにしてください。
次に、場所についてです。
色々な理由でエリアを限定するしかない方もいらっしゃると思いますので、必ずしもという訳ではありません。
しかし、東京や関東だけでなく、さまざまなエリアに目を向けることで、選択肢が広がります。
地域によっては、人材が不足している場合もあり、そのような地域の企業は、新しい人材をしっかりと育てたいと考えている企業もあります。
実際に内定先の選定をサポートさせて頂いた際に、前職迄の経験が魅力的で、そういった経験を持つ人とは中々出会えないということで、高い給与の提案を受けた方もいました。
未経験では、現実的にどんな企業でも受けられる訳では無いので、可能な限り選択肢を増やせる方法で取り組んで頂くとより内定獲得に近づけます。
ポイント
・とにかく応募数を増やす
・見送りには企業都合の理由もあるので、気にしすぎず、前向きに取り組む
・地域を限定せず、多くの企業との接触を試みる
③選考対策
まず、選考を突破するためには、可能な限りの手段を活用することが重要です。転職サイトや直接の企業への応募、エージェントの利用、ココナラやSNSのコミュニティでのアドバイスの求め方など、様々な方法を駆使して成功に近づけようとしています。
転職サイトはもちろん、直接企業への応募も、エージェントも、ココナラやSNSのコミュニティでのアドバイスを求めることも含めて、あらゆる手段を使って成功を掴み取ろうとしています。
そして、一人での取り組みには限界があると認識しています。
私がココナラで転職相談を開始した際、何度か内定先の選定に関する相談を受けました。内定を複数獲得しても、知らないことや不安な点を解消するために、専門家のアドバイスを求める姿勢を持っています。
そういった姿勢や考え方、行動力が結果にも自然と表れていると感じました。
迷った時に、一人も悶々としながら、何となく決めるというような方は少なく、転職を成功させるという意識が強いのでアドバイスも積極的に求めている方が多いです。
次に、自己PRの重要性についてです。
人事部時代に感じていたことですが、エンジニアという職種のイメージからか、しっかりと伝えきれていない方が一定数いらっしゃいました。
やはり、未経験からエンジニアに転職となれば、技術力だけでは会社に貢献できると思わせることは難しいです。
なので、それ以外の部分で貢献できる経験・能力を伝えることは重要です。
マネジメントなのか、営業力なのか、外部折衝なのか、ドキュメントの作成スキルなのか、何かしら前職での経験や培ってきたことが少なからずあると思います。
それらをしっかりと棚卸して、伝えらえるように練習・準備をしてください。
しっかりと前職含めこれまでの経験やスキルを伝えるべきです。
その内容が、選考を受けている企業にとって、求めている能力であるならば、そのアピールによって、結果を好転させられる可能性があります。
ポイント
・さまざまな手段を駆使して選考に臨むこと。
・自己PRをしっかりと行い、これまでの経験やスキルを伝えること。
④企業との対話の質
複数内定を得る方の多くは、転職がゴールではなく、その先のビジョンを持ち、それを実現できるのかという視点でしっかりと企業を見極めようとされている方が多いです。
なので、企業側に対して、どういう経験が積めるのか、どういうキャリアパスがあるのか、技術力の向上に対して企業としてどういう補助があるのか、色々なことを企業に問いかけています。
私が人事部時代に内定フォローまでやっておりましたが、面接中のみならず、最後の最後まで気になることがあれば質問をされていましたし、迷っていれば直接面談を依頼されることもありました。
未経験だからといって、受け身な姿勢で選考には臨んでいません。
可能な限り納得のいく結果を得るために企業としっかりと対話をして、判断するように意識している方がほとんどです。
企業側としっかりと対話せずに、未経験なのに採用してくれるからと二つ返事で内定を承諾してしまった場合、蓋を挙けてみれば、開発現場に半年間も入れなかった、全然違う業務をさせられた、ということになりかねません。
企業が募集を出しているという事は、人材を欲しているということです。
未経験だからと立場云々を気にするのではなく、面接や面談、その後内定を承諾するに至るまでに、聞いておくべきことはしっかりと聞くようにしてください。
そのような積極的でミスマッチを減らそうとする姿勢が、企業側へのアピールにも繋がります。
企業側も採用するのであれば、ミスマッチを防ぎたいのは当然ですので、企業側もしっかりとすり合わせが出来れば安心材料となります。
人生においても非常に大きな転機となる転職です。
望む未来を実現するために取り組んでいると思います。
後悔しないためにも、しっかりと企業を対話をし、見定める意識を持って取り組んでください。
ポイント
・転職をゴールにせず、その先のビジョンをしっかりと持つ
・そのビジョンに近づけるのかを企業に確認する
・立場云々考えず、ミスマッチを減らす努力を怠らない
まとめ
複数の内定を獲得する人たちの共通点を4つ紹介しました。
①学習期間の長さ・密度
②応募数の多さ・場所
③選考対策
④企業との対話
もちろん、これら以外にも多くの要因が考えられますが、今回取り上げたポイントは特別なテクニックを使っているわけではありません。
一部の方には「これは当たり前のことだ」と感じられるかもしれません。
とにかく、大切なのは、自分のビジョンを持ち、それを実現するためにどれだけ努力と行動ができるかです。
実際のところ、そういった行動がとれる人は多くありません。
学習だけでも相当時間と労力と人によっては費用を掛けていますし、その後は選考の対策、企業選びまでと本当に大変です。
だからこそ、最後の最後まで妥協せずに、諦めずにやり切れる人が納得のいく結果に辿り着けます。
未経験からのエンジニア転職というのは、本当に険しい道のりです。
簡単では無いと分かっていても、目指したいと思う理由があるから取り組まれていると思います。
最後の1社を決めるその時まで、納得のいく結果で終えられるように行動してみて欲しいと思います。
また、もし一人では解消できない悩みがあったり、不安があるようであれば、私のサービスに限らず、色々なプラットフォームやコミュニティ、SNS上で相談できる場所があるので積極的に活用してみてください。
やはり未知の業界の実情を知ることは中々難しいので、解決するためには、直接聞くことが一番の近道だと思っています。
私もTwitterではDMを開放しているので何か気になることがあればご連絡頂ければ答えますし、メンターやスクールに通っていて、相談できる先があるなら、遠慮なく使い倒して欲しいと思います。
この記事が、あなたの転職活動の助けとなることを心から願っています。
未経験からのエンジニア転職：ポートフォリオの重要性
はじめに
※未経験から独学でエンジニア転職を検討されている方向けの記事です。
転職支援のあるスクールやコミュニティに参加していらっしゃる場合は、既知である可能性がありますので、ご了承ください。
未経験からエンジニアに転職する為には、現状の自分のスキルや学習成果をアピールすることが必要です。
その為に、ポートフォリオを用意する必要があります。
ポートフォリオという言葉で括っておりますが、要はこれまでの取り組みを示せるものという意味合いです。
最近は転職活動における記事もたくさんあるため、用意しないということはあまり無いと思いますが、仮に何も用意しないで選考を始めようとしている場合は、ほぼ確実に内定には至りません。
稀に見せられるものが無かったり、書籍のサンプルプログラムを動かした程度で、それを見せる前提で転職活動を始めてしまう方がいらっしゃいます。
企業側の立場に立って考えてみて欲しいのですが、
「未経験ですが、エンジニアを目指して半年間勉強をしましたし、スクールにも通っていました！」
と話をされたところで、実際に作ったものを見れなければ、応募者が現状どの程度のレベルで、一体何が出来るのかを判断することが出来ません。
（スクールでポートフォリオを用意しないということはあり得ないと思いますが、、、）
何時間勉強した、どの程度の期間勉強したという話をするよりも、実際に自分で考えたものを開発し、それを実際に見せる方が何倍もアピールになりますし、採用側も判断しやすいです。
また、学習においてもアウトプットすることは非常に大切です。
アウトプットして初めて遭遇する事象や、もっと勉強すべきことを把握できます。
なので、勉強を進めながら、頭の中で、こういうサイトやサービスを作ってみようかなとイメージしながら進めることをお勧めします。
具体的にアピールする方法として、ポートフォリオと共に GitHub などでコードを提示するとよりアピールしやすいと思います。
ポートフォリオは確実に必要です。
個人作品だけでなく、コミュニティや勉強会に参加して、チーム開発の経験を積みながら、提示できるものを開発するというのも良いと思います。
GitHub とは、プログラミングのコードを管理するためのサービスで、Web上で他者にコードを見てもらう事が出来ます。
（詳しくは検索してみてください）
GitHubまで用意出来れば、コードの共有が簡単なので、双方に取ってより良いと思います。
また、遭遇したエラーについて、解消するプロセスなどをまとめたブログ等も有用です。
アウトプットする姿勢があるとアピール出来ますし、これまで積み重ねてきた取り組みを見せることが出来ます。
これらを用意することで、自分の現状を適切に伝えることが出来ますので、しっかりと用意して転職活動を始めてください。
エンジニアへの転職で重要なポートフォリオを用意する上で大事な事
ポートフォリオで重要な事は、当然ながら自身のスキル・能力をアピール出来ているか、ビジネス視点が含まれているかということす。
インフラ、デザイナーなど、職種によって学んだ内容は異なりますので、アピールすべき内容はそれぞれの職種によって選択してください。
作品数は、特に決まりはないと考えています。
大事なポイントは、作品数ではありませんので、複数の作品を用意したとしても、似たような内容であったり、同じ機能・技術を使っているだけではあまり意味はありません。
例えば、Webエンジニアであれば、一つの作品でもフロントエンド・バックエンド・DB操作・外部連携など、多面的な能力をしっかりとアピールできる作品にすべきです。
私が採用担当者時代に、凄いなと思った作品というのは、しっかりとWebサービスとして稼働させ、それなりに売り上げやアクセス数などの実績を作っている作品です。
自分でサーバを構築し、ドメインを用意し、SSL化し、課金システムを導入し、等々、一つのサービスとして稼働させるために必要な内容を一通り実装し、そして、多少なりとも顧客がいるという状態です。
こういう方は、本当に一握りです。
本当に一握りですが、欲しい人材となる可能性が非常に高いです。
そこまで時間を掛けて未知なる領域にチャレンジし、努力し、取り組んでいるからこそ出来ることです。
個人で、プログラミング学習を始めて、ビジネス視点も持ちながらそこまで取り組んでいるのであれば、入社後にベテランエンジニアに囲まれながら様々な業務を行う事によって、一気に成長するのではと可能性を感じます。
企業は、ボランティアで未経験も含めてエンジニアを募集している訳ではありません。
ビジネスです。
ビジネスとして貢献できる人材と感じさせなければ、当然採用されません。
会社の成長に繋がらなければ意味が無いのです。
入社した後に、成長しない、やっぱりエンジニア向いてなかったと言ってすぐ退職する、そういう人材を採用したくないと思うのは当然です。
今のスキルだけを見せて、気に入ったら採用してくれないかなという思考では、まともな企業に入るチャンスは限りなく低いと思います。
ここまでの内容として、特に未経験の人は、ハードルが高いように感じますよね。
しかし、私はそこまでする必要があると思っています。
特に未経験なら尚更です。
有象無象のペライチのデモサイトを見ても、企業側が採用したい！となる可能性は限りなく低いです。
Webエンジニアを例にしましたが、デザイナーやインフラエンジニアなどの他の職種でも考え方は同じです。
知識が必要な職種であれば難易度の高い資格を取って貢献できることを示せます。
本当に自分の現状の知識、経験が、そういうアピールに繋がるのかを今一度考えてみて欲しいと思います。
もしポートフォリオが通用するか不安になったら
どの程度まで作りこめば良いか、選考に出せるレベル感なのかが分からない方も多いと思います。
ポートフォリオをどこまでやれば良いかについて、具体的な何か数字であったり、基準というものはありません。
企業によって求められているレベル感も違いますし、技術も違います。
そういった時は、あまり悩むことに時間を掛けず、第三者に見てもらうことがお勧めです。
上記で例に挙げたような内容は、ともて難易度が高いです。
それを一人で全てやり切る必要はないと思います。
色々な人に助けを借り、学びを得ることも大事な事だと思います。
結果的に、自分の作品となれば良いのです。
迷っているようであれば、SNSでもココナラでもコミュニティに参加している経験者でも構いませんので、現役エンジニアや採用する側の経験がある人に一度見てもらった方が間違いなく良いと思います。
企業側の採用基準は、企業側によって変わりますので、○か×かを聞くことは難しいですが、率直な感想やアドバイスを貰えるだけでも、どう動くべきか考えられると思います。
ポートフォリオを用意することはとても大事ですが、目的は転職です。
ポートフォリオ以外にも企業研究や書類の作成など、他にも色々な準備が必要です。
どこまでやるべきかという悩みを延々考えても解決することは出来ませんし、時間を浪費しているだけになりますので、迷ったり不安であれば、相談したほうがメリットが大きいと思います。
私も相談を受け付けておりますし、同様の相談サービスであったり学習系のコミュニティ等があると思いますので、迷われているようであれば、是非一度どなたかに相談してみて欲しいと思います。
文系・未経験からエンジニア転職、悩み相談のります 文系・未経験からエンジニアになった私があなたの力になります！
何か不明点等があれば、上記サービス内のメッセージやコメント、DMにてご連絡下さい。
ありがとうございました。
プログラミング初心者にオススメ！学習を加速させる1冊の本を紹介
プログラミングの学習を初めて、少しコードを書くことに慣れてきた方向けて、その後の学習において更に成長を加速させるための考え方を知ることが出来る本を紹介したいと思います。
対象者
・プログラミングを初めて数か月の方（コードに書くこと自体は慣れてきた）からエンジニア歴１～３年程度の方で未読の方
読むことをお勧めしない人
・プログラミングの学習をこれから始める方
・プログラミング学習を始めて間もない方
当然いずれは読んで欲しいので、読んで頂いても全く問題はありません。
しかし、学習を始めたての方は、そもそもコードを書くこと自体に慣れていない、基礎もほぼ身に付いていない状態です。
専門用語も出てきますので、まずはこの本を読む前に、基礎固めやコードを書くことに慣れる方が重要だと思います。
また、実感という部分で中々イメージが出来ないと思います。
多少なりともコードを書いて、イメージできる状態で読んで頂いた方が、実感が湧くと思います。
本の紹介
今回紹介する本は下記の本です。
|
|
![[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]](https://hbb.afl.rakuten.co.jp/hgb/34d33617.357dcc81.34d33618.dad41b60/?me_id=1213310&item_id=15934325&pc=https%3A%2F%2Fthumbnail.image.rakuten.co.jp%2F%400_mall%2Fbook%2Fcabinet%2F5658%2F9784873115658_1_2.jpg%3F_ex%3D300x300&s=300x300&t=picttext "[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]")
本の内容
美しいコードを見ると感動する。優れたコードは見た瞬間に何をしているかが伝わってくる。そういうコードは使うのが楽しいし、自分のコードもそうあるべきだと思わせてくれる。本書の目的は、君のコードを良くすることだ。（本書「はじめに」より）
コードは理解しやすくなければならない。本書はこの原則を日々のコーディングの様々な場面に当てはめる方法を紹介します。名前の付け方、コメントの書き方など表面上の改善について。コードを動かすための制御フロー、論理式、変数などループとロジックについて。またコードを再構成するための方法。さらにテストの書き方などについて、楽しいイラストと共に説明しています。日本語版ではRubyやgroongaのコミッタとしても著名な須藤功平氏による解説を収録。
上記の説明に書いてある通り、より良いプログラムの書き方について解説されている書籍です。
この本は、色々な方が紹介されている有名な本でして、感想記事なども沢山あります。
ですので、私なりに、未経験から学習を初めて1年が経った時に読んだ時のことも含めて、オススメする理由をお伝えします。
お勧めする理由
コードを書く上でベースとなる考え方が身に付く
この本は、特定の言語にフォーカスされた本ではありません。
文中にも色々な言語で例が書かれています。
この本を読むことで得られる最大のメリットは、
これからコードを書く上で基準となる考え方を知ることが出来る
だと思っています。
特に初心者の方は、書籍の中に出てくる複数のプログラミング言語を網羅している訳ではないので、具体的なコードを見ても、中々理解できないかと思います。
しかし、重要なポイントはそこではありません。
誰しもが理解しやすいコードの書き方や、バグを未然に防ぐ書き方、変数や関数の命名について、コメントの本質についてなど、どうあるべきかということを知ることができるという点が本当に大事なポイントです。
何故そのようにすべきかについても、分かりやすく書かれています。
- 変数名を適当に付けていたりしていませんか？
- とりあえず動けば良いで終わらせていませんか？
- 後日コードを読んだら意味不明だったりしませんか？
- その関数名は他人が見てもどういう役割かすぐ伝わりますか？
- 別にあっても無くても構わないようなコメント付けていませんか？
等々、言語問わず、必ず考えなければならないポイントが書かれています。
一度でもこの本を読んでいれば、どういうルールで考えるべきかが見えてきます。
特に初心者の方は、書籍であったり教材であったりと、サンプルがあってそれを模写したり、利用して学習を進めると思います。
その期間は、見本があったり教えてもらいながらになると思いますので、割とスムーズに進められると思います。
しかし、いざポートフォリオを作る、何か個人製作をする、というタイミングが来た時に、あまり意識していなかった部分で詰まる可能性があります。
一つ一つ、どうやって命名するか、条件式はどう書くべきか等、色々な事を決めなければなりません。
道筋がある状態で考えてコードを書くか、闇雲に基準も無く何となくコードを書くか、どちらが効率的且つ正確でしょうか。
当然、前者ですよね。
どう考えるべきか分かっている状態であれば、それに則り書くことが出来ます。
そういった基準を知ることができるというのが、この本を読むことで得られる最大のメリットだと思います。
※一点だけ注意点として、全てのプロジェクトで当てはまるという訳ではありません。
書籍ですので、基本的には則っておくべきことという位置づけと認識してもらえればと思います。
但し、私の経験からも、どういった環境で仕事をするにしても、この本の内容が活かされていると感じているので、メリットは大きいと思っています。
他人のコードを読むときにも非常に役に立つ知識
他人のコードを読む機会というのは、これまでもこれからも続きます。
わからなことがあった場合に、ネット上で色々な記事で読みます。
企業に入った場合、コミット時やコードレビューやペアプログラミングなど、自分の書いたコードを読んでもらいますし、読むこともあります。
改修案件であれば、既存のコードを解析して改修をします。
もし学習を終えて、現場に入ったり、フリーランスになればそういう機会が日常的にあります。
そういった時に、この本の内容がとても活かされます。
この本を読み、コードを沢山書いていると、他人のコードを読んだときに、こうやってコードを組んだ方が良い、命名した方が良い、この書き方だと後でバグを生む、そういったことが段々と見えるようになります。
何かのプロジェクトで誰かのコードを読んだ際に、危険な部分や、実はバグになっている部分、もっと理解しやすく書くことが出来る部分、それらを指摘することが出来ます。
その結果、バグが起きず、システムが健全に動作し、プロジェクトを円滑に進めることが出来るようになります。
徹夜での無駄なバグ調査や、改修対応、不要なリリース、そういったことを減らすことが出来ます。
※また、あなたの評価にも繋がるかもしれません
私がどうやって勉強したか
少し余談ですが、私が当時学習した時の状況やどうやって学習したかも残しておきたいと思います。（興味が無ければ飛ばして頂いて問題ありません）
私がこの本を読んだタイミングは、ちょうどプログラミングに触れてから1年後でした。
最初の半年間程度は、とにかく言語に関する直接的な学習を行っていました。
その後、段々と手が慣れてきて、ちょうど1年経過した時に、当時何かの記事でこの本の情報を知りました。
半年を過ぎた辺りから、多少余裕が出てきたので、IT業界であったり、新技術であったり、そういった情報を色々なサイトをブックマークして毎日通勤中や始業前に見るようにしていた中で見つけた本です。
ちょうどその時期に、私自身文系で何の経験も無かったですし、体系的に継続して教えてもらえるような環境でも無く、目の前の事をこなすために場当たり的な学習になっていた気がしていて、もう少し俯瞰した視点でプログラミングというものを理解したいと考えていました。
一旦落ちついて、より良いプログラムを書くというのはどういうことかを理解する期間を作り、いくつか本を調査して、この本も候補に入れて読みました。
その時に取り組んでいたことは、当時多くの人が使っていたEvernoteに記事のまとめをひたすら書くという方法でした。
この方法が良いか悪いかは、何とも言えませんが、とにかく手を動かして頭に擦り付けるような感覚でやっていました。
各章毎に大事だと思うポイントを整理して書き出すという方法で取り組んでいました。
読んで全てを記憶し理解できればこんな作業は必要ないと思いますが、如何せん私自身そこまで記憶力が良い訳ではないので、体に覚えさせるという意識で学習をしていたので、その延長線上でこういった方法を取りました。
かなりの文量にはなりますが、当時学習に関わるメモは全てEvernoteに書いていたので、デバイス問わず見返せますし、いつでも振り返れるので、助かりました。
学習の記録にもなりますし、ちょっとした達成感も得られて、また次の本を読みだすことにも繋がったと思っています。
そして、これを読了した際に、もう少し早くこの本を読めばよかったと思った経緯があり、対象者に記載した内容に繋がります。
特にこの学習方法をトレースする必要も無いですし、各々で合っている学習方法で取り組んで頂ければと思います。
今の時代は、色々と学習において便利なツールやシステムが沢山あると思うので、それらを色々と試して、自分に合った学習方法でやってみて下さい。
何か少しでも参考になれば幸いです。
まとめ
「リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック」
について、お勧めする理由について述べました。
もう一度言いますが、私が思うこの本で重要なポイントは、
これからコードを書く上で基準となる考え方を知ることが出来る
です。
やはり、何かしらの基準が無いと、意思決定というのは難しいです。
こう書くべきなのか、こう考えるべきなのか、ということを知っていると知らないでは、雲泥の差だと思います。
そのような基礎的な内容を把握した上で、各プロジェクトや案件で学んだことを応用しながら開発した結果、システムやサービスを安定して稼働させるという事に繋がると思っています。
もし何か疑問等があれば、コメントやTwitter等でメッセージ頂ければお答えできる範囲でお答えします！
ありがとうございました。
