題名の通り。この本は年末年始にXで「良本」という情報を複数見かけ、年明けに地元の書店で探していたところ見つけたので手に取った。
感想
マイクロソフトのAzure Functionsプロダクトチームで働く著者が感じた、エンジニアというお仕事をする上での「いわゆる日本企業」とのカルチャーの違い、「こうすると生き生きと仕事できるよね」がまとめられた一冊だった。
自分は日本でエンジニアとして働いていて、この本に書いてある内容は大半が共感できた。今の職場でも実践できていることが多かったからだ。もちろん、一部の内容については「これは知らなかった、時期が来たら取り入れてみよう」と思える内容もあったので、読む価値はあったと思う。
むしろエンジニア以外の職種の人に読んで欲しい一冊。所々エンジニア特有の用語が出てくるので読みづらいかもしれないが、「エンジニア達はそういうやり方で仕事をしているのか」「これはエンジニアじゃなくても取り入れられるかもしれない」というカルチャーが多く見つかるはずだ。
共感した点
手を動かす前に仮説検証をする
大事。宛もなくデバッガーを起動したり、ログを出力しても正解にはたどり着けない。
一方で、手を動かさないことも、必要な情報が得られないという意味で厳しい。
仮説検証→手を動かすというループを回すことが大事
最初の一個をピックアップしてやったら他はやらない
優先順位付けの話
準委任契約の受託開発ではこのやり方をお客さんと共有して進めることが多く、お客さんの理解が得られると上手く回っていると思う
「フィードバック」を歓迎するムードをつくる
これも準委任契約でよくやっている
フィードバックに対応することで本当に必要とされているシステムに近づけていく感覚を得ている
プロダクト開発でもこのループが作れると上手くいくのだろうか...？
クイックコールを頻繁に使うこと
弊社で言うところの「会話を求めます」
AIに食われないもの
ChatGPT以降、みんな同じ機器感を持っているよなーと共感。
我々が他の業種のお客様に言い続けてきたように「AIに仕事を奪われるのではなく、自分の仕事の抽象度が一段階上がる」という考え方が必要だと思う
これはコードを書けなくなるわけではなく、より抽象的なコードを書くとも取れると自分は思っている
「批判」の文化がすべてをぶち壊しにする
共感した、とだけ書いておく。これに細かく言及することも誰かに対しての批判になりかねないのでそれは避けたい。
今まで意識していなかった点
初歩の学習を「簡単だ」と馬鹿にせず、本当に一からやり直してみた
自分にとっての「青色申告」はまさにこの状態かもしれない。簿記をちゃんと勉強しようかな...
小さなドキュメントをコードを書く前に書く
「ちゃんとしたドキュメントをコードを書く前に書く」or「先にコードを書いて必要なドキュメントを後から書く」しかやったことがないことに気づいた
後輩にコードを渡す機会も増えてきているので実践してみよう
相手のことを理解して認める力
コードレビューにおいては慣れのおかげか割り切りができていて、意見が対立しても動揺せずに議論・対処ができていると思う
一方で、日常会話だったりSlackでのやり取りだったりで、意見の対立を自覚すると「批判された」「失敗した」と動揺してしまうことがある
後から振り返ると大半は批判でも失敗でもないことが多いので、「意見が違うだけ」ということを自分に言い聞かせる習慣をつけたい
AIに食われないもの
その他
この本は筆者が主張したいところや重要な箇所に最初からマーカー線が引かれていて読みやすい＆読み返しやすかった
もし自分が商業誌を出すことになったら真似したいと思った