見出し画像

残業100時間を0にするために読んだ本7選

直近2-3年ほど、基本的に定時ダッシュをキメている田畑(@nerd0geek1)です。

ここ最近、Web系の会社でエンジニアをしている20-26歳あたりの方と飲む機会が多かったのですが、スキルであったり、会社であったり、長時間労働に悩んでいる方が多かったので、自分が残業時間を100時間から0時間にするために読んだ本を共有することで、そういった人のためになればと思い、書いてみました。

なお、時期ごとにどういった問題に直面し、それをどういった本から得た知識で解決したか書いたほうがわかりやすいと思うので、時系列に沿って書いてあります。

ちなみに、就職時点でのスキルレベルは「経済学部出身、大学在学中からVBAやFlash/HTMLを書いていた」「バックグラウンドの知識は全然ないが、プログラムは少し書ける」というレベルでした。

24歳〜26歳(ベンチャー企業、残業60〜160時間)

新卒では20-40人ほどのベンチャー企業に就職しました。
この会社、受託案件の炎上が多く、自分も恒常的に60時間、ひどい時には3ヶ月連続で160時間残業するという状態でした。

そういった環境だったので、スキルアップしないといつまでたっても残業時間の短縮ができないと考え、炎上が一段落したタイミングの休日に、自分の理解が浅くスケジュール遅延の一因となった要素技術(UIの描画ロジックやiOSのローカルDBなど)の詳細を復習する、要素技術の概念を深掘りする、などしていました。
(テストで間違ったところを復習するようなノリで)。
これらは、そんな環境の中で読んだ3冊の本です。

すぐに始められるアドバイスを求めて

ジャズミュージシャンから世界的な開発者になったChad Fowlerによる本で、今でも自分の行動の指針になっている大切な本です。

サブタイトルが「ソフトウェア開発者の幸せな生き方」となっていることからもわかるように「どうスキルを上げるか」ということだけでなく、「どのように現状を捉えるか」「どのように自分を売り込むか」といったことにも踏み込んでいる、『SOFT SKILLS ソフトウェア開発者の人生マニュアル』のコンパクト版とも言える内容でした。

・一番の下手くそでいよう

=君の周りにいる人達が君のパフォーマンスに影響する。仲間は慎重に選べ
自分の知性に投資しよう
=主流でないテクノロジーと方法論に親しむことで自分自身を高めよう
愛せよ、さもなくば捨てよ
=自分が本当に情熱を持てる・熱中できる仕事をしよう
デイリーヒット
=上司や同僚に報告できる成果を毎日あげよう
・スーツ語
=自分の業績は、自分のビジネスの言葉で売り込め

など、いくつものアドバイスがなされており、上手に立ち回ったり、何に時間を投資するかを決める際には大いに役立ちました。

こちらは、第一線で活躍する一流のプログラマによる実践的なアドバイスを集めたものです。

コーディング規約を自動化する
他人よりまず自分を疑う
余分なコードは決して書かない
名前重要
・...

などの実践的なアドバイスと、なぜそうすべきなのかという合理的な理由が書かれており、目の前の業務で手一杯だった時期にもチャレンジしやすく、良い本でした。

『情熱プログラマー』は生き方を含めて1人の開発者としてどう振る舞うべきか、『プログラマが知るべき97のこと』は開発においてどのようなことに気をつけるべきか、といった点に焦点を当てていましたが、『リーダブルコード』はそれらより小さなスコープで、「どのようなコードを書くべきか」という点に焦点を当てた本です。

文字数が短ければ短いほど良いのではない。他の人が最短時間で理解できるのが良いコードだ。
動作をより明確に説明できる単語を選ぶべき(getよりDownloadなど)
コメントはコードを読んですぐにわかることを書くのではなく、書き手の意図を
伝える内容を書くべき。(なぜこの実装方法を選んだのか、何を参照したかなど)

など、すぐに始められそうな内容に満ちており、このタイミングで読むには最高の本でした。

26〜28歳(スタートアップ、残業60〜80時間?)

最初の会社でiOSエンジニアとして学ぶことがなくなったので、26歳の時に知人に誘われてCtoC系スタートアップに転職しました。

その会社には同年代の超優秀な人達が集まっていたため、最初の会社でしていたような「単純な実装を長時間繰り返す」といったことはありませんでしたが、キャッチアップのためであったり、仕事の密度を高めるための試行錯誤というところで、ある程度長時間働いていました。
これらはそういった環境で、時間あたりの密度を高めるために読んだ2冊です。

熟達するために

働き始めた当初はSubversionを、そこから1年経ったくらいでGitを使い始めたので、Gitの概念をそこまで深く理解せず、少しSubversion的な使い方をしてしまっていました。それでは余りに非効率だったため、Gitを概念から理解しようとこの本を購入しました。

その結果、gitコマンドの裏側でどういった操作が行われているかイメージできるようになり、git操作を腹落ちした状態でできるようになったので、良い投資でした。

以前、別の記事でも紹介しましたが、なぜそう設計するのか、という点に絞って書かれた良書です。

オブジェクト指向の解説本によくあるような「Animalクラスを継承したCatクラスがあり...」といったような説明ではなく、「Aというケースでは、Bという実装を行えるがその場合、Cという変更が入ると対応できない。それをDというデザインパターンを使うと解決できる。」というように、オブジェクト指向やあるデザインパターンをなぜ使うのかがそれぞれのケースについて解説されており、設計力を上げる上では非常に役に立ちました。

挫折した本

当時の超優秀な同僚から、彼が前職時代から何度も読み込んでいる良書ということでエリック・エヴァンズのDDD本をオススメされましたが、そもそもの難易度が高く、分量も大型本で合計1,200ページということであえなく挫折してしまいました。。。

番外編

これらは残業を減らすために読んだ本ではありませんが、自社サービスの開発を行っている人にとっては、施策の精度を高める役に立ち、結果として成果を出すための労働時間を減らすこともできるだろう、ということで紹介しておきます。

ユーザーがサービスを使い始めてから、それを日常の一部として習慣化するまで、どのようなプロセスを経るかを

トリガー(きっかけ)
アクション(行動)
リワード(報酬)
インベストメント(投資)

という4つの概念で説明した本です。
Amazonのレビューに書いてあるように、少し日本語が読みにくいですが、それ以上に価値のある知見を与えてくれる本です。
新しい機能や企画を実装する際に、それがこの4つの概念に沿っているか確認することにより、企画レベルでの確度を上げ、実装レベルでの試行錯誤を減らすことも可能ではないかと思います。

昨今イノベーションが持て囃されているが、優れたイノベーターと考えられているアップルなども実は卓越した模倣を行う会社であり、模倣こそが競争優位を築くために必須の行いなのだ、と説いた本です。

この中で
表層だけをなぞるエミュレーション(いわゆるパクリ)
vs.
リバースエンジニアリングして、自分の文脈に組み込み直す模倣
という対置がなされています(当然意味があるのは後者)。

新しい機能や企画が、競合の単なるエミュレーションではなく、自社プロダクトの文脈に沿ったものになっているかチェックすることで、確度の低い施策の実装を避けることができるようになり、結果として労働時間を減らすことも可能ではないでしょうか。

まとめ

いかがでしたでしょうか。

・時間がなくても始められる小手先の改善で時間を作る
・小手先の改善で時間を確保したら、より大きなスコープで役に立つ、より重めの本に挑戦する
・自分の関心に基づいて、エンジニアリング以外にも興味の範囲を広げる

という流れでスキルを伸ばしてきた個人として本を紹介してみました。

自分の経験に基づいて役立った本をオススメしたので万人に役立つものではないかもしれませんが、この中の1冊が現状を改善するきっかけになれば幸いです。

また、他にも良書がありましたら教えていただければと思います🙇🙇🙇

Amazonアソシエイト・プログラムに参加しています
Amazonのアソシエイトとして、株式会社creche studioは適格販売により収入を得ています。



この記事が参加している募集

推薦図書

サポートする代わりに個人開発はじめましょ! iOS👇 https://developer.apple.com/jp/support/enrollment/ Android👇 https://play.google.com/apps/publish/signup/