エンジニアな私が社会人1年目に読んでおきたかった・読んでよかった本たち
はじめに
入社当時、先輩におすすめの本を聞くと技術本ばかりすすめられた。
理系学部出身でもなく、プログラミング経験もお遊び程度しかなかった自分には、難しくて読みきれないことが多かった。
読みきれないとなんだか自信がなくなって、自分ってエンジニアとしてだめなんじゃないかって思うことが何度もあった。
本から学ぶ派の人もいればそうでない人もいると思うけど、少なくとも10年前の働き始めた自分に向けてこのコンテンツを書いてみる。
この記事でおすすめする本を書くにあたって気をつけたこと
1. 読み切れそうな本を選ぶ
私は比較的活字が好きで小さい頃からよく本を読む方ではあったけど、それでも前述したとおり、勧められる本やいわゆる良書といわれる技術書を手にとっては読みきれなくて、自分ってエンジニアにむいてないんだなーとさえ思ってしまったことがあった。読み切ることができる、ってそれだけで達成感がある。
2. 読み方を書く
小説ばかり読んでたせいで、一文一文おって、文章を楽しむことになれてしまっていたが、ジャンルごとに読み方ってあるなーって最近やっと気づいた。ビジネス書は文字が大きめなことが多いから流し見してもいいし、目次や索引がしっかりしている本であれば気になるとこだけ拾えばいい。必ずしも読み切る必要はないと思ってる。
では紹介。
ものづくり
自分がものづくりをしたいと思ったきっかけになった本（実は早速読みきれない本ではあるけどｗ）
大学時代心理学を学んでいた際に、参考図書として紹介されて読んでみた。当時はなんとなく形になるものを自分の手で作るのが好きだなーと思い始めたものの、アイデアや最先端技術がない自分にはむりかなーと思っていた。特に、デザインに関しては、クリエイティブなもので凡庸な自分には無縁の世界だと思っていた。
デザインとはそういう狭いことじゃなくて、使う人がいて、そうなるような仕組みを作ることで、それが例とともに体系的に記述されている。この本読んでから、世の中のものの見方がかわった気がする。ものづくりにかかわる人はもちろん、そうでない人もぜひ読んでみてほしい。
最近話題になってますね。元任天堂の開発者がマリオやドラクエを題材に、ついやってしまう、できてしまう、つづけてしまう仕組みづくりを解説。目新しいことはそれほど書いてないけど、ゲームほぼやらない自分でもやったことがあるマリオを題材になるほど、やられてたわーって思いながら仕組みをデザインすることを知れる一冊。この本自体、行間や挿絵のバランスやテンポがよくてつい読み進めてしまってあっという間に読み切ってしまった。最初に挙げた「誰のためのデザイン」興味あるけどちょっと、、、みたいな人はいったんこっち読んでみてみるとよいかも。
技術系
実は技術本は読まない主義ｗ最初に挫折しちゃったのもあるし、高いし、重いし、すぐ古くなってしまうし。。。。
ここにあげたのも、あくまで入社時に持っててよかったなー（読んでよかったとは書かないｗ）と思った本。当時は社内のほぼ全部のプロダクトがjavaで書かれていたのでjava一色。今自信をもっておすすめ！とはいえないものもあるけど、最初の段階でjavaに軸足おいて実務と一緒に学べたことで、javaだけは得意！って言えるようになってたのは自信になった。（もう何年も触ってないし8系以降触ってないので今じゃ口が裂けても言えませんｗ）
javaやるんなら読んでないと！どんな言語でもeffective〇〇的なのは読んだ方がいいと思う。たいていの言語は、なんとなく書けばなんとなく動いて別にそれでもいいっちゃいいんだけど、effective本にはセオリーやテクニック的なのが書かれていて、それに添うことは言語の特徴や思想を理解して、その後の更新に対応した設計をするために必要だと思う。
最初から読み切る必要はないと思う。最初に出会った技術本が実はこれで？？？？？？？状態だった。ただ、目次や索引がしっかりしてて、コーディングしながらちょっと気になったときにこの本の該当箇所を読んで見るとハラオチできることが多かった。あと、後輩のPRに対して、「この本のここいったん読んでみて」って書けるの便利だったわｗ
有名どころのjavaライブラリから、ソースコードの設計について解説してある本。良いコードを書く始めの一歩でいいものを真似るのは大事だとよく言われるけど、世の中には大量にライブラリが公開されててその一つ一つが大量のソースコードから成り立ってて、それをどれがいいかとかそのどこがいいかとか、はじめはよくわからないし労力がいる。この本では、当時よく使われていたライブラリをいくつかを題材に、その一部をとりあげて解説することで、こうやって実装していけばいいのね、って実感できた。
正直、入社当時設計って概念がそんなになかったし、これでわかるようになった！って言えるわけでもない。でも、設計ってこういうことかーの入り口になった本。当時はソースコードリーディングはやっててspringとかstrutsとかcommonsとかめちゃくちゃ読んでたなｗ
読むというより、辞書がわりに常に机において実装するヒントにしてた。パターンや手法は先人たちの知恵だよ。知らなきゃ損損。
入社してから、新規でやることが多かったのであまりリファクタリングって概念がなかった。メンテナンス性とか拡張性とかいうけど、正直すぐ作って捨てるサービスを作ってる気がしていたのでリファクタリングの必要性もそれほど感じることはなかったし、とにかく早く出すことを要求されていたのでリファクタリングという言葉はあまり読んでみようと思えるキーワードではなかった。
これを読んでよかったなーと思うのは、結局課題をみつけてそれに対応していくことで、あら不思議、どこかでみたパターン！となることで、パターンの有用性や設計の大切さが実感できたこと。
マネージメント・チーム開発
正直、おすすめ本なんてないｗ本ばかりで頭でっかちになるより、対人なんでその場その場で荒波に揉まれた方がいいと思う。
みんなおれについてこい！！=リーダーじゃないよってお話。
宇宙兄弟をベースに描かれているので宇宙兄弟好きにはたまらない。文字大きい、宇宙兄弟のコマ多用、薄い、短い、で読み切れる本の筆頭かもしれない！
ただ、誰でもリーダーとかいいつつ、ムッタ的リーダーをべた褒め感が気になる。最近続編がでたやつはもう少しリーダーの多様性を描きつつチーム運営に主眼をおいて描かれていて、そっちの方が好きではある。
「ふりかえり」のフレームワーク紹介集。
エンジニアあるあるかもしれないけど、一時期アジャイルって言葉が流行りすぎてアジャイルって言葉出すだけで嫌悪感示す人いませんでした？ｗ私のまわりにはたくさんいて、私もその中のひとりではあったけど、言葉に出さなくても自然とアジャイルであるようなチームに恵まれることが多くて、本より環境かなーと思う部分が大きい。
ただ、一冊あげるならこれかな。「ふりかえり」ってやってます？（やってなかったらやってくださいｗ）わたしのまわりではやったりやらなかったりではあったけど、やるときには絶対KPT！！みたいな流れがあって。むしろふりかえり=KPTみたいな。時間がかかる割に特に得ることも少なくていらないんじゃない？って声も多かった。そんなときはいったんこの本参考にしてみるといいかも。
マネージメントって書いたけど、これだ！って一冊をあげれなかった。。。。今は多少違いそうだけど、エンジニアってマネージメントってキャリアパスを描きたがらない人多い印象ない？そんなキャリアパスを描かなくても「扱いやすい人になる」って自分のためにもまわりのためにも大事だと思う。私自身、別にマネージャーでもないけどマネージメント関連の本はよく読む。だけど、１年目に読んでおきたかった本っていうとちょっとないかもしれない。
働き方
社会人として必要なスキルを身につけるための習慣の紹介。
IT技術者っていっても特殊な職業でもなんでもなく、一社会人なので
一社会人としてこういう習慣は必要ですよ、って本。
方法や具体例として、IT技術者がわかりやすいことが取り上げられてる感じ。
エッセンシャル思考とか流行ってるけどまずこれ読む。仕事のスキルや強みを身につけていく仕事の仕方や生き方を著者の経験を元に四則演算にたとえて書かれている。
エッセンシャル思考を取り入れるタイミング間違うと大変。
スキルの身につけ方、とか書いてあるかと思えば面接とか上司との付き合い方について書かれていたり、デバッグとかCIについてかかれているかと思えば、ドレスコードとか講演と書かれてたり！
どんなキャリアフェーズの人でもいったん読んで見るとなにかの参考になると思う。非エンジニアだけどなにか書いてみたいなーという人にもおすすめ。
やればできるよｗマインドセット次第でその後の成長やアウトプットがこんなにかわるんだよ、という研究に関して研究結果やスポーツやビジネス界の具体例を取り上げて解説してる本。・・・・耳が痛い＞＜
おまけ
1年目で読むにはちょっとあれだったり、読みにくかったりするけど、ちょっと↑におもしろみなかったのでおまけ
エンジニアリングってなに？って思ったときに。
最近設計してないなーとかソース書いてないなーとか、これってエンジニアの仕事・スキルなの？って思ったときに。
こういうことってあるよね、それってこういうことだと思うんだよねーということが一般化されて記載されてる。
課題解決策がのってるわけではないけど、私は招待されちゃったひとりで、おかげで課題に向き合う心構えができた気がしている。
10人前後の小さいチームで一つのプロダクトをやってた自分が、一つのプロダクトを100人規模でつくるような開発チームに異動して、うまくいかないなーとか思うことが多くなった。そんなとき読んで、なんとなくうまくいかなかったのがハラオチできた本。ステークホルダーとか業務設計って言葉の重みに気付かされた本。
鍵とか認証とか乱数とか、暗号技術に関して一通り記載されているのでセキュリティ関連の入門書としてどうぞ。
言葉だけみるとなんだか難しそう、、、と思いがちな世界を結城さんが書かれているのでおもしろい！！
私が最初に読んだのは第１版だったｗ
最新版でブロックチェーンとか追加されてて、本の厚さが倍くらいになってたので再購入してしまった。
kindleはブックマークしか対応していないので注意。目次は充実してる。
メッセージ集というか絵本というか。
公園に集まる３人の子どもたちが一緒になにかやるお話。
指南書としてはシンプルすぎて逆に難しいし、絵本として読むにはストーリー性に乏しい。
部下が〜って言葉があってちょっとあれだけど、こうでありたいねって姪っ子ちゃんと話したい気持ちになった。
最後にそれぞれのメッセージに対して短い解説があって、それが解説になってなかったりぐちだったりゆるくてじわる。
1989年にVRについて描かれた小説。
一般的なPCの説明としてメモリが1MBと記載されている。
そんな時代にVRをここまで創作できていることがすごいし、小説としておもしろい！
2部構成になっていて、前半が悩みに応じた休息法の説明、後半はとある疲れた研究者がマインドフルネスを取り入れていく話。
マインドフルネス=スピリチュアルだと思ってたが、脳科学的な引用が多用されている。
また、架空の（でもいそうな）研究者の物語として記載されていて読みやすい。
休息法だし、読むのに時間かかったりつかれるのもなーと、まんがでわかる系を読んで嫌悪感抱いていた自分をしかりとばしたいｗ
おわりに
社会人になって10年以上経過してしまいました(´・ω・｀)社会人歴=エンジニア歴なのでそんだけエンジニアやってるけど、いまだにエンジニアとしてやれているか、やっていけるか自信ない。ここであげた本はあくまで私のこれまでのを振り返って、読んでてよかったとか出会っておきたかったと思った本たち。本の内容はかわらないけど、感じること・得ることはそのときの経験やマインドによってかわってくる。
きっと3年後とかには違う本を社会人1年目の自分におすすめしたくなっていることでしょうｗ
アウトプットが下手で苦手意識が高すぎてますます下手になってる気がするので数打ってみることにする