はじめに
の参加記事になります。
個別の技術ではなく、エンジニアの成長のステップで読むと良い本の紹介
エンジニアとして成長していくときに、個々の技術を深く理解し使いこなしていくことは必要ですが、個々の技術を選ぶときにもどんな成長ステップがあるかを理解することも重要です。
実装をするという範囲をエンジニアの中心なのはありますが、実装以外の部分を理解するとその技術が最大限に活きるのかを理解するには周辺についても理解していく必要があります。そこで、実装を始める前の構造のパターン、実装を進めるエンジニアの環境などを知ることで、もっと効率的な開発が出来るようになるのかを理解していきたいけると良いと考えています。
この記事では私が経験した中でより良いWebシステムを作るという観点に立ったときに、広く理解しておくと良いと感じた本を紹介します。
これからエンジニアリングでどのような勉強をすればよいかを考えている方の役に立てれば嬉しいです。
そもそもエンジニアの成長って何？
エンジニアとしてまずはシステムを動かすという所に着目しがちですが、動かし続けるとなると、実は必要な知識がガラッと変わって、広い知識必要になります。
技術的に広い知識を使いこなすための土台となるような知識と活用するために具体的な知識の部分があると考えます。
データサイエンス領域や研究開発領域は違いますが、SaaSや基幹業務システムを作るときには 動かすところまで を考える所が基礎部分だとすると、 動かし、成長し続ける ところまで考えて、その上で今何をどう作るべきかを決めることが出来るようになることが中級以上のエンジニアとして求められることと考えています。
おすすめの本一覧
今回の本の紹介は中級〜上級なエンジニアとして成長するために技術を効率的に使いこなすための 土台のような知識 を得るために、良いと思う本を紹介していきます。
目次 - カテゴリ -
- プログラミングする際にベースとなる知識
- システムを継続的に良い品質を維持する知識
- エンジニアが成長しやすい組織にする知識
- 変化し続ける世の中に対応する知識
- エンジニアのキャリアの知識
かなりボリューミーですが 合計20冊の本を紹介 します！
プログラミングする際にベースとなる知識
エンジニアが実装するときには、まずソースコードをどのような構造として管理していくかが重要になります。
端的に言うとアーキテクチャです。
アーキテクチャにはソフトウェアの特性を考慮した様々な原則やパターンが存在します。
それらのベストパターンを様々知ることによって、ソフトウェアは実装しやすさや変更への強さを手に入れていきます。
まさに実装の土台というべき知識を得るためのオススメの本たちになります。
プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則
エンジニアリングの構造に関わる会話をするときにはやり取りする事象についての共通の言葉が必要になります。その言葉について100個も紹介してくれているので、たくさん知るのに便利です。しかも、エキスパートなエンジニアは当たり前に知っているよね？という前提の原則ばかりかつ、使える原則が大多数なので、是非知っておいて欲しいです。
１つの原則について１-2ページでシンプルに概要が書かれていて、どこで読み止めてもいいし、摘み読みしてもいいし、サクサク読めるので全部読んでも良い。
１つの原則のキーワードを知ったあと、深い理解には他のドキュメントを読んだり、事例を検索したりして理解を深めると良いと思います。
キーワードすら知らないと、検索すら出来ないですが、まずはこの本によってざっくり概要を理解し、さらなる知識の扉の道標を開いてくれます。
オススメする対象者
- エンジニアが知るべき原則のキーワードを知りたい人
- オブジェクト指向、SOLID、DRY、ブルックスの法則、コンウェイの法則などに知らない言葉がある人、あるいはもっと知りたい人
Clean Architecture 達人に学ぶソフトウェアの構造と設計
言わずと知れたクリーンアーキテクチャについて解説する本
有名なオニオン型の図がクライマックスであることは確かですが、それより前の章に書かれている実装やシステム構成における考え方の観点を全て理解した上でのあの図だと思います。
更には有名なあの図そのものよりも、右下のクラス図の関係性の方が重要だと思ったりしてます。
現在であれば、バックエンド、フロントエンド問わずに一旦は検討してみるべきアーキテクチャなので、絶対に知っておきたいです。
オススメする対象者
- クリーンアーキテクチャについて理解したい人
- 上記解説であの図 が何のことか分からなかった人
マイクロサービスアーキテクチャ
大ブームのマイクロサービスアーキテクチャについて解説された本です。
しかし、マイクロサービスのの苦労については語られていないので注意です。
マイクロサービスが流行って分かった苦労が認知されてきて、最近はモジュラーモノリスが流行ってきていますね。
しかし、そもそもマイクロサービスを理解していなければ、なぜモジュラーモノリスがそこまで流行るのか、マイクロサービスにすることで達成したことは何だったのか？を理解しないといけません。
これからの流行を正しく理解するためにもマイクロサービスも理解しておきましょう。
モジュラーモノリスが流行ってきているとしても、大規模開発のときは選択肢の１つとなることはこれからも変わりません。是非知っておきましょう。
オススメする対象者
- マイクロサービスについて理解したい人
- 大規模開発のアーキテクチャの選択肢を増やしたい人
モノリスからマイクロサービスへ ―モノリスを進化させる実践移行ガイド
上で紹介したマイクロサービスを知っている前提の本です。
一応、この本でも１章でマイクロサービスについて紹介されていますが、上で紹介した本は1〜12章でマイクロサービスを解説しているので、この本でのマイクロサービスの解説はあくまで概要説明という感じです。
前提としてマイクロサービスをしっかり理解しましょう。
その上で、この本はモノリスなシステムからマイクロサービスへの移行の苦労の話や実践的な移行パターンの事例が解説されていて、とても参考になります！
自分も仕事の中でストラングラーパターンを考慮してアーキテクチャの設計をしたこともあります。
実践例が凄く書かれているので良いですが、ここで紹介している他の本と比べると利用ターゲットが狭いので、マイクロサービスに移行するぞ！という方以外は他の紹介している本を読んで頂く方がオススメです。
オススメする対象者
- 自社のモノリスシステムをマイクロサービスに移行したいとき
- マイクロサービスを使おうとした時に、どのように移行すれば良いか知っておきたい
進化的アーキテクチャ ―絶え間ない変化を支える
現代のソフトウェアは完成を迎えて終わりということはなく、世の中の変化に適応しながら開発を継続し機能を追加し続けるケースが非常に多くなっていると思います。
単にシステムを作る視点から、システムが進化し続ける前提で作る視点に目線を広げてくれる本です。
全てが変わり続ける世の中で、アーキテクチャは変わっていかなければならない。単純に変わるのではなく進化しなければならない。全てがその前提で、そのために必要な観点を様々得ることが出来ます。
「泥団子では進化できない」という言葉は辛辣でありながら納得してしまい、楽しくなる一節もありました。
オススメする対象者
- 進化し続けるソフトウェアを前提としてシステムを作るときに気をつける観点を得たい
- 進化的アーキテクチャを阻害するアンチパターンの事例を知りたい
ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本
DDD (Domain Driven Design)の本は色々と出ていますが、まずこの本を読むことがオススメです！
DDDを分かりやすく解説されており、まだ何も知らない状態からDDD理解するにはピッタリの本です！
この本はあくまで入門のため、これを読んだ前提で、本格的により深く理解して使いこなしたいときには更にもう１冊DDDの本を読むことをオススメします。
ただ、いきなりDDDを網羅している実践本を読むと、その「ボリューム」と「抽象的な考え」と「仕組みの深さ」を理解するのにかなりパワーを使うため、挫折する可能性が高いです。(実践版は自分も読みきるまでに何回か挫折しました)
なので、今回はこのDDD入門の本をオススメさせてもらいました！
実装するエンジニアであれば、少なくともDDDがどんなものであるかはキャッチアップしておくべきだと思いますので、DDDがよく分からないという方はオススメというよりは必読かと思います。
オススメする対象者
- DDDがどういうものであるか実装出来るレベルまで概要を知りたい
- 最新のアーキテクチャーのパターンの１つをキャッチアップをしたい
システムを継続的に良い品質を維持する知識
上記での進化的アーキテクチャの紹介でもありましたが、ソフトウェアは作るだけでは終わりません。
ソフトウェアの品質はしっかりと管理していかなければ下がり続けるものです。
先程の土台が作るまでの話であれば、ここでオススメする本は作ったあとも継続的にソフトウェアの品質を高めるためのヒントとなるような本になります。
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック
誰もが読んでいるであろう名著
中級エンジニア以上であれば
むしろ読んでいない人は初級エンジニアから抜け出せていない可能性が高いのではと思うほどの知名度
コードを綺麗に維持するための様々な観点や事例が載っています。
品質というものはシステムの内部から作られるのです。
ずっと手元に置いておきたい１冊。
圧倒的知名度と実績が示しているので多くの解説は不要だと思います。読んでない方は是非読んで下さい！
オススメする対象者
- とりあえずエンジニアなら読むべし
- 理由など読んでから知っても良い。読むべし
良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方
最近発売されたばかりで話題になっています！
リーダブルコードの発展版とも言えるかも知れません。
他のデザインパターン本との間を埋める本というか、シンプルな設計みたいなものを考えるというか。
よくあるコードに見かける悪い対処をしている構造やハンドリング方法について、良い対処の仕方なども解説されています。
実装と設計について実践的に実際のコードを示しながら解説されていて、非常に分かりやすいです！
実装をしているエンジニアであれば、読んだ次の日から実装の観点が変わることも期待できる、即効性のある１冊です！
今回の「Qiita Engineer Festa 2022」にも参加されています。
良いコードを書くためにこちらのQiitaの投稿も見てもらうと良いかも知れません。
オススメする対象者
- 実装的な設計についての知識を得たい
- リーダブルコードが良い感じだったので、似た感じのやつをもっと読みたい
LeanとDevOpsの科学［Accelerate］ テクノロジーの戦略的活用が組織変革を加速する
ハイパフォーマンスな組織になるために、継続的な活動をどのようにモニタリングすればよいか具体的に解説したり、データを取り統計的に解説してアプローチしています。
この本で有名なのは4 Key Metrics (あるいは Four Keys)ですね！
開発組織のパフォーマンスを可視化するための４つ指標を挙げています。
- リードタイム
- デプロイ頻度
- MTTR
- 変更失敗率
の４つです。
それぞれを少し解説します。
- リードタイム
- 機能を開発してから機能をリリースしてユーザーに価値を届けられるまでの時間。
- デプロイ頻度
- サービスがデプロイされる頻度。デプロイ頻度 = デプロイ回数 ÷ 開発者 ÷ 日数。
- デプロイ頻度は高い方がよい。パフォーマンスが高い組織では人数が増加するとデプロイ頻度が高まるが、パフォーマンスが低い組織はデプロイ頻度が増えない事がある。
- MTTR
- Mean Time To Repairの頭文字で「平均修復時間」。
- 障害発生から修復して障害が解消するまでの時間。
- 変更失敗率
- システムへの変更(デプロイなど)をきっかけに障害が発生した割合
それぞれが綱引きのような関係になっており、数が増えても質が下がらないようになっている。
あまりにこの話が有名だが、それ以外にもCI/CDの価値や進め方、様々データでの客観的な解説、ハイパフォーマンスな組織とは？と言ったものを色々と解説しています！
残念なのは全体的に雑多な印象で、若干読みにくいです。
ただ、観点は非常に勉強になるので、１度は読んでみても良いと思います。
オススメする対象者
- 4 Key Metricsをちゃんと理解したい
- 継続リリースの組織のパフォーマンスを計測できるようになりたい
- ハイパフォーマンスな組織とはどういうことか？という観点を増やしたい
Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス
分厚い！
ですが、継続的に良いシステムを作り続けるのに開発実装の話からテストやドキュメント、必要な文化、プロセスの話まで、かなり網羅的にシステム開発に本当に必要な知識が溢れています！
さすがグーグル！強いぞグーグル！
ちょっとそれグーグルじゃないと無理なんじゃないの？みたいなこともあったりしますが、基本的にその観点は正しいと感じるものなので、非常に勉強になります。
分厚くて心折れそうな気持ちになりますが、その分エンジニアに必要な情報が網羅されているため、おすすめ本の中でも必読の1冊です！
オススメする対象者
- リーダブルコードは一旦読んだ
- 継続的な良いシステムを作るために必要なことを全体的に知りたい
オブジェクト指向UIデザイン──使いやすいソフトウェアの原理
オブジェクト指向って書いてあるけど、実はデザイナー向けの本です。
でも、フロントエンドエンジニアの方には勉強になるかなと思うので紹介させてもらいました！
この本を読むと、今までの画面設計の仕方がガラッと変わってしまうこともあるほどの重要な観点が書かれていると思います！
デザイナーの人は読んでて当然の本になっています。エンジニアのあなたも読んでもらって、デザイナーさんに話を振ってみてください。楽しいと思いますよ！
他の本とは異色な本の紹介ですが、プロダクトづくりが好きな人にはとても楽しい本だと思います。
この本の手法はデザインパターンの１つを解説しているようなものなので、全てをこの方法で作ればうまくいくというものではないですが、確実に自分の引き出しが１つ増えるでしょう。
オブジェクト指向というタイトルの通り、オブジェクト指向を知っているエンジニアにとってはスッと理解が出来るデザインの情報設計の知識を得ることが出来ます！
オススメする対象者
- フロントエンドエンジニアの方
- プロダクトデザインについて興味がある方
- ユーザーの体験を良くするためのデザインの方法論を知りたい方
エンジニアが成長しやすい組織にする知識
エンジニアが成長し、良いソフトウェアを作ることに集中するためには良い環境が必要です。
環境は想像以上に大きな影響を与えます。
直接的な技術の話ではないためすぐに効果が出るものではありませんが、より良い成果を出す環境を作るためにどのような組織が必要であるかを理解しておくことに損はないでしょう。
本来であればマネージャが理解していて欲しい内容ですが、全ての環境がエンジニアリングについて理解がある環境というわけではありません。ひとりのエンジニアとして出来る手段として知っておくとより良いエンジニアリング活動が出来るようになると思います。
エラスティックリーダーシップ ―自己組織化チームの育て方
リーダーシップは場面によって発揮の仕方を変えなければならないという話が解説されています。
マネージャでなくとも、システムを開発中は自分の作っているタスクは一番詳しいのは自分になるはずです。
小さな領域であってもリーダーシップを発揮する場面があるはずです。
そんな時にリーダーシップの発揮仕方を知っていると、チームにより良い効果を与えることができます。
リーダーシップの発揮の仕方として
非常に忙しい時のサバイバルモードを突破するとき
チームがただのタスク消化マシーンにならないように学習するチームに進化させるとき
そして、自分自身のチームの行く先をチーム自身が決めれる自己組織化に導くリーダーシップ
３つのチーム状態とそれに合わせたリーダーシップについて解説されています。
昨今ではサーバントリーダーシップが当たり前のように語られますが、全ての場面でサーバントリーダーシップだけでは難しいと感じます。普段はサーバントリーダーシップを意識しつつ、場面によってチーム全員を引っ張るリーダーシップが必要な場面では上手くリーダーシップを使い分けるとより良いと感じます。そのような使い分けがイメージしやすくなることが間違いないです！
エンジニアリングマネージャの方は必読！ エンジニアの方はチーム状態に合わせて自分の行動を上手く変化させる必要があることを知るために、時間がある時に読んでおくと良いオススメの一冊です！
オススメする対象者
- エンジニアリングマネージャの方、もしくはエンジニアリングマネージャを目指す方
- 色々なチーム状況に合わせて動きを変えることが出来るエンジニアになりたい方
エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング
思考・メンタリング・チーム・組織の力学など、システムに影響する変数を広く捉えつつも、細かく説明がされています。
特に計画の見積もりの難しさや不確実性に立ち向かうにはどのように捉えながら開発計画を推進していけば良いのかという章はとても好きで、数値やグラフで表現しながら、データとロジックで解説されており、計画へのアプローチ方法が変わると思います。
エンジニアリングを行う上では是非読んでもらいたい１冊です！
オススメする対象者
- 開発の計画を推進する役割を持つ方
- エンジニアリングの組織に関係する方
心理的安全性のつくりかた
より良い開発のために大前提となっている必要がある知識、「心理的安全性」について非常に分かりやすく書かれている本です。
心理的安全性が高いチームとは、ただの仲良しグループではないです。 建設的で良いディスカッションが出来るチームになっています。
エンジニアも日々レビューでのコミュニケーションやスケジュールと品質のトレードオフなど、多くの場面で率直なやり取りと建設的なやり取りが出来るかどうかでシステムの品質が変わります。
また、たくさんの良いソフトウェアを作るためのディスカッションが出来る環境はエンジニアとして大きな成長をさせて貰える機会を多く発生させます。
心理的安全性の無いチームで成長することは非常に難しいのです。
ぜひ、この本で心理的安全性に理解し、心理的安全性の高い仕事場で働いてください。
オススメする対象者
- エンジニアのコードレビューで率直に気持ちよく意見が言える環境を作る方法を知りたい
- より良い設計、技術的なディスカッション、開発プロセスを推進できるチームを理解したい
- エンジニアが成長する環境を知る
カルチャーモデル 最高の組織文化のつくり方
会社の文化定義の仕方の本 になります。
最近の世の中ではテックドリブンな組織という言葉を使う会社も増えてきました。
それに対して、昔ながらで変わらない会社では社内であってもエンジニアを外注先のようにシステムの開発を発注するように進める組織もあります。
この差は何でしょうか？どちらの組織の方がエンジニアとして成長できるでしょうか？
本で書かれているのはエンジニア向けではなく、会社の文化について語られているだけなので、特にテックドリブンということではありません。
しかし、会社が目指す方向がエンジニアに大きな影響を与えるということを理解してもらいたくて紹介しました。
今の会社のカルチャーはどのようなカルチャーでしょうか。
自分自身で今の会社のカルチャーを変えることはなかなか難しいかも知れませんが、会社を選ぶ際にカルチャーに注目しながら選ぶことは出来るようになることでしょう。
オススメする対象者
- 会社のカルチャーはどのように作られると良いのか知りたい方
- 自分の今の会社のカルチャーと理想の会社カルチャーの違いを知りたい方
- 転職などを考える時に会社のカルチャーというものについてどう考えたり、捉えるとよいかを理解しておきたい方
変化し続ける世の中に対応する知識
世の中の変化のスピードは上がっていっています。
ソフトウェアは特別なものから当たり前のものになっています。
そのため、開発する方法も大きな変化を迎えています。
大きなソフトウェアの設計をやりきってからまとめて作るという形ではなく、価値を提供できる機能を小さく定義して小さく作り早く使ってもらうことでソフトウェアの価値をなるべく早く発揮する開発の仕方に変わっています。
この開発の進め方は実装の進め方にも大きな影響を与えています。
例えば自動テストが当たり前にならなければ、この開発の仕方で進めることが出来ません。
逆を言うと、この開発の進め方が出来るチームや会社は新しい実装の進め方に適応している組織となっているはずです。
そのような知識をまずは自分で理解しておくことが必須になってきているため、ぜひここに紹介した本で知ってもらえると嬉しいです。
SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発
アジャイル開発のスクラムが非常に易しく書かれていて、まだスクラムについて全然知らないけど、どれを読んだら良いのだろうという人にオススメの1冊です！
漫画の挿絵多く、とても楽しい雰囲気で読むことが出来ます。
しっかりスクラムを理解するには、本格的な本を別でもう１つ読んだ方が良いですが、普通のエンジニアであっても最低限知っておくと良いスクラムについて知ることが出来ると思います。
オススメする対象者
- アジャイル開発の中でもスクラムの方法を知りたい
- ガッツリ読む本ではなく、なるべく楽しく読みたい
カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで
本としてはアジャイル導入のエピソードがわかりやすく書かれていて、チームにアジャイル開発を導入するときのポイントとアジャイル開発の知識が同時に理解できる、分かりやすい本になっています。
自分が組織を変えようと思った時に、自分はリーダーでもマネージャでもないし、どうすれば変えることが出来るんだと思うこともあるでしょう。
そんな時に自分1人から組織を変えていく、という話が非常に参考になる本だと思いました。
現実ではそんなに上手く行かないよ！と思うところもありますが、全くヒントがないままにチームなどの組織を変えていくのは相当ハードモードです。そういう意味では、チームを変えて働きやすい環境や成長できる環境にしていきたいと考えた時に、是非読んで欲しいです。
オススメする対象者
- アジャイル開発の基本と導入する方法を知りたい
- 自分がチームに変化を起こし始める方法を知りたい
誰も教えてくれなかったアジャイル開発
カイゼンジャーニーはアジャイルを理解しながら、導入するエピソードも合わせて書かれていましたが、こちらはアジャイル開発の基本の知識は分かっている前提で、それでも導入の時に苦労する話をどのように対応すれば良いのかが詳しく書かれています。
現実のあるあるパターンが書かれているので、アジャイル開発の導入って難しいなと思っている人やアジャイル開発を導入するのは心配だと思っている人にはおすすめです。
逆にちょっとそれはスクラムの意図とは違うのでは？という記述もあります。
スクラムで上手く行かなくて妥協した表現、具体的な例がなくてどうやったらよいかわからない場面で具体的な個数や制限を追加している例などがありますが、これは詳しい人から見ると違和感のあるものだと思います。
あくまで１つの例という前提で読めるといいかなと思います。
スクラムガイドにはそう書いてあるけど、現実にやろうとするとこうなるし、無理じゃん？みたいな場面が色々と出てくると思います。
現実には理想状態にワープすることはなくて、現状から目指した組織のプロセスへの一歩ずつの変化があります。アジャイル開発の組織に変わるときの時系列の変化するときに起きる事象を見ることが出来る、今までにない1冊だと思いました。
オススメする対象者
- アジャイル開発を導入したい
- 導入しようとしたけどぎこちない。上手い対処方法を知りたい
エンジニアのキャリアの知識
毎日の実装やシステムづくりはとても楽しいです。
それを繰り返した先にどのような世界が待っているのでしょうか？
様々な知識を得ることで出来ることも増えます。すると、あなたの肩書きも変わることもあります。
新しい環境でチャレンジしたい事もあると思います。
会社での部署異動、新しいチーム、転職、さまざまなエンジニアの道のキャリアの知識を知っておくと、いざその時に役に立つでしょう。
エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド
マネジメントというタイトルがついている通り、マネージャ向けの本かとは思います。
しかし、力をつけたエンジニアはテックリードやCTOなどのポジションにもチャレンジがしたい時期が来るかも知れません。
メンバーであってもテックリードやマネージャがどのようなことを考えながら仕事をしているかを知ることで、より良い働きが出来ることは間違いないでしょう。
そんなときに、テックリードってどんなことが出来る必要があるの？CTOってどんなことが出来る必要があるの？ということを理解しながら日々を過ごしていれば、技術に関してより広い視野で理解できるようになることは間違いないです。
日々の技術に対する理解度を深くするためにも、ぜひハイレベルなエンジニアがどのような視点で技術を見て、使いこなしているかを理解しましょう。
オススメする対象者
- 中級のエンジニア全員
- 将来、テックリードやエンジニアリングマネージャやCTOなどになりたい方
まとめ
記事を書いてみたらかなりボリューミーになってしまいました。
色々な本を紹介させてもらっていますが、エンジニアを続けていくのであれば全部読んでもらえると良いと思っている超絶オススメ本なので、この記事を是非ストックして頂いて、時々見に来てもらえると良いかなと思っていますー！
最初に 合計20冊の本を紹介 と書いていたのですが、オススメしたい本が19冊になっています 🙇
もう１つ入れてもいいかなと思うものは実はいくらでも出来るのですが、自分的にはここで紹介したものと比べるともう１歩決めきれていません。
候補としては
- CODE COMPLETE
- 闘うプログラマー
- ドメイン駆動設計
- テスト駆動開発
- SQLアンチパターン
- アジャイルな見積もりと計画づくり
- アジャイルサムライ
- ピープルウエア
- Joy.inc
- プロダクト・レッド・オーガニゼーション
- ユーザー中心組織論
- いちばんやさしいアジャイル開発の教本
などなど
他の本と内容が重複していると感じたり、エンジニアリングと近いけれどエンジニアにとって必読かというとちょっと違うかなと思ったりして、今回の候補から外しました。
でも19冊って区切りが悪いですよね。。
そこで、この記事を読んだ方々にお願いです🙏
あなたのオススメの本をあと１冊をコメント欄に貰えると嬉しいです！
みんなのオススメ本を見て、私も新しい本に出会えると嬉しいですー
LGTMやコメントよろしくお願いします！！
おまけ
ここで紹介している本を読むと技術土台の実力が高まるのはもちろんですが、転職する時に外のエンジニアと共通言語で深い技術の話が出来るようになります。
よくあるのが「XX言語使えます」「設計出来ます」という職務経歴書を見るのですが、残念ながら技術について深く表現出来ていないんですね。
デザイナーで言うと絵が描けますって言っているのと同じです。それって誰でも出来ますよね？
求められるのは、その先にある質になるんです。
その質を表現する語彙だったり実力だったりが、今回紹介している本では身に付けられる一歩になると思います。是非！
さらにそういう表現が出来るようになることは転職する時にもすごく有効です。
自分が採用担当として期待する職務経歴書についての書き方もこちらに紹介しているのでこちらで興味があればどうぞー