前書き
久しく振り返っていなかったので振り返る。
仕事
転職して半年弱が経った。 「技術リーダーシップのための14のヒント」という本に、
チームが何かを限界と感じているなら、その限界を作っているのは他ならぬリーダー自身であり、それを突破できるのもまたリーダーなのだ。
という文章がある。この文章の通りやっていきという感じ。
読んだ本
色々読んだような気もするが印象に残ったものを書いていく。
エンジニアリングが好きな私たちのためのエンジニアリングマネージャー入門
- タイトルに惹かれて購入し一気に読んだ本。エンジニアリングが自分も好きだし、マネジメントには向いていないと思っていたのでまさにドンピシャりという感じで購入した。内容としては、マネジメントで気をつけることが広く浅く書かれている。1on1が最も重要なミーティングというのはかなり同意。マネジメントで思うことがあれば今でもたまに読み返している。最近思うのは、マネジメントは人柄や性格に依存すると思われることが多いが、実際は技術も必要でありプログラミングと同様にインプットがなければアウトプットも無いものだと感じる。
マスタリングAPIアーキテクチャ
- モノリスを段階的にマイクロサービスにしていくというような本。実際にどうMSに切り出すか、トレードオフも考えながら書かれている。k8sやistioのことも書かれており、APIアーキテクチャというよりはアーキテクチャの本のように感じた。
Google Cloud認定資格教科書
- 急に資格の本だが、転職しGoogle Cloudを使用することになったので、Associateはとっておこうということで買った。内容は網羅的に書かれていて、あまり触ったことのないコンポーネントを触るときにたまに読み返す。
単体テストの考え方/使い方
- Xで話題になっていた本。レイヤーをどこまで切るかなども書かれていてデトロイト学派とロンドン学派も丁寧に説明されている。自分はモックは基本使わないなー。などと思った。
技術リーダーシップのための14のヒント
- 名だたるエンジニアの自説がまとめられた本。この本を読むまではいわゆるサーバントリーダーシップのようないかにメンバーの仕事の障害を取り除くかを考えていたが、自分でチームを引っ張るのも良いのだとハッとなった本。
リーダーであるあなたがこれまでと変わらず第一線でプロダクトや技術の問題解決をリードし続けることが、結果的に自己組織化したチームを作る見本になる。そして事業を伸ばすことになる。そういうことも往々にしてあるのですから。 技術リーダーシップのための14のヒント. oreilly-978-4-8144-0117-8e . Kindle 版.
この精神で来年もやっていこうかなと思います。 お疲れ様でした。
