技術書の重複と読書ポートフォリオ
このポッドキャストは、ギークの二人が興味のある技術や、熱中していることについて語る番組です。
僕です。 ゾエです。
はい。ちょっと聞いてもらいたいんですけど。はい。 あの最近、オライリーの
脳に収まるコードの書き方ってやつを読んでたんですけど。はい。
読んでたんですけど。
過去すでに読んだことがある、他で読んだような話が、まあ多かったり、
いうのと、参考文献にしている本自体を、そもそも読んだことがある、みたいな、
はい。 量がですね、
やや多くて、はい。 いささか飽きがあるな、みたいなことを感じてたんですよ。
はい。
全体読んだら、あ、ここは役に立つな、みたいなところもあるんですけど、
言うて、そもそも参照元読んだことがあるな、率も結構高いなと感じてて、
はい。 この分野の本、
もしくはこの分野の本で、伝えたい趣旨みたいなものって、
実はもうあんまり困ってない、悩んでないのかなって思うんですよ。
うん。 もしくは、頭には入ってるけど実践はできんなとか、
現実との間で、100%適応できないなと思っているだけで、
知識としては随分あるのかなって思うんですよね。 はい。
ええ、そういった感覚を踏まえて、
ではこの脳に収まるコードを読めば何かが開けるじゃなくて、
過去これ読んできたものも踏まえて、
これ一冊読んでおけばいいよじゃなくて、
この組み合わせで読んでおけば結構お勧めっていう技術者の組み合わせがあるかなと思ってて、
まあそんなものをちょっと今回紹介してみようかなと思うんです。
はい。
そうです、なんか、
ZOEさんのところで、本読んでいく中で、
これをここに書いてやるものを、もう前に読んだな、みたいな経験とかありません?
まあありますよね。
さっきのコードの書き方みたいな話だけで言うと、
リダックブルコードだけ読んでいけばいいかな、みたいなところとか、
リダックブルコードの上読んで、それの前提だった上で、
なんか新しく出たやつも、
どこと差分があるかな、みたいな読み方をしているみたいなところは、
あるっちゃありますね。
なるほど。
差分がここにあるな、みたいなのって割とあるもんですか?
それとも結構誤差みたいな感じなんですか?
うーん、なんか、ちょっと嫌な言い方ですけど、
そんなにないかなと思ってて、
なんかそれで言うと、追加でお金払った分の誤差分、
学んだ分の差分みたいなところで言うと、
ちょっと割高かな、みたいな感じることもあります。
じゃあ、3000円くらい出したとして、
お差だなーを感じるのを仮に500円だとしたら、
1500円くらいは割高かな、みたいな。
そうですね、なんかちょっと割高かな、みたいな、
感じることもありますよね。
そうですね。
逆に、特に参考文献が多くて、
ある種、よく書かれた本は本人の持論じゃなくて、
他の参考文献がめっちゃ踏まえられてるが故に、
過去読んだことがいっぱい載ってる可能性もあるんですけど、
とはいえ、受け取り手からすると別にそんなことはどうでもいいので、
みたいな感じはあるかなと私も思いますね。
新しいことを教えてください、だと思うんで、基本的には。
なんかそういう意味ではちょっと、論文チェックというか、
既存研究があった上で、
新しい研究結果がこちらです、みたいな。
はいはいはい。そうですね。
論文的には正しいんですけどね、たぶん。
そうなんですよね。
なんていうか、とはいえ、
それを踏まえて新しい書籍が出ること自体は、
重要だと思うんですよね。
ただ、それは新しく、
隠人になった人が、こっち読んだ方がいいよね、みたいなところとか、
こっち読んでおけば、古いものを探して読む必要ないよね、みたいな。
そういう選択肢の意味で、必要だと思うんですけど、
個人の尊徳感情みたいなところで言うと、
必ずしも得ではないよね、みたいな、
課題があるというだけだと思う。
ですね。
おおむね同意です。
はい。
開発者とチームの定番4冊
はい。というところで、
私の方から、とりあえずこの辺読んでおけばいいんじゃねえ、
を紹介してみたいかなと、思います。
今回、4冊持ってきたんですけど、
なんとなくテーマとしては、
日本のウェブの会社で、
開発やるんだったら、この辺読んでおけばいいんじゃないっていう、
4冊。
ですね。
ちょっと順番に行きたいと思うんですけど、
達人プログラマー、
一応第2版ですね、最近出た方。
アジャイル侍。
はい。
一旦、まず2冊で切ろうと思うんですけど、
達人プログラマー、
開発者個人の視点、
開発の仕方とか、
個人の学習の進め方、
みたいな観点で書かれている本としては、
定番なんで、
まずこの1冊かなと。
はい。
ですね。ただ、この本も、
この本をまるっと全部実践しなきゃいけないかというと、
そんなこともないかなとは思いますね。
実際、例えば、さっき例に出したのは、
脳に収まる行動。
の方で、達人プログラマーは実は取り上げられているんですけど、
一部、取り上げているところもあれば、
反論しているところがあって、
達人プログラマーで、
毎年1個新しい言語を触りましょうって書いてあるんですけど、
脳に収まる行動は、
やりすぎって書いてます。
よく書いてたりしますね。
別に言語じゃなくていいだろうみたいなことを踏まえて、
やりすぎって書いてますね。
次、アザイル侍の方なんですけど、
こっちもそのまま全部取り入れられるかとおいておき、
個人よりはチームとかプロジェクトみたいな視点になるんで、
これも読んどいて損ないかなといった思うところですね。
特に私、もちろん他のアザイル関係の方全部読んでるわけじゃないんですけど、
いわゆるアザイルのプラクティス、
こういうことをやるんですよみたいな話が、
割と前半の方に比較的まとまってるんで、
こういうことやっていこうねみたいな方針立てていくときに、
結構参考書として良いかなと思ってますね。
どうです?とりあえずこの2冊。
どうです?いいんじゃないですかね。
ちなみにあれ既読ですか?
達人プログラマーは目は通しましたけど、
アジャイル侍は見てないですね。
ちなみにアジャイル関係みたいなやつって、
これ読みましたってあります?
アジャイルソフトウェア開発宣言しか読んでないです。
ある種業界における聖書な気がする。
原点を打って大事ですからね。
日本の開発現場における失敗とレビュー
後半2冊いってみますね。
比較的これ最近出たやつですね。
ソフトウェア開発の現場の失敗集めてみた。
もう1冊伝わるコードレビュー開発チームの
生産性を高める上手な伝え方の教科書ってやつで、
後半2冊はどっちかっていうと
日本独特のやつかなっていうやつを持ってきてます。
特に失敗集めてみたは、
いわゆる組織としてこういう運用の仕方悪かったから
失敗集めてみた。
失敗するよねみたいな事例集として載ってるんで、
ある種のあるある本ではあるんですけど、
このままやってると同じような落とし柄が
落ちるんじゃないのっていう警戒をしていくような
意味として結構いいかなと。
実際こういう風にした方がいいよねみたいな話も
一通り載ってるんでいいかなと思ってますね。
もう1個コードレビューの方なんですけど、
達人プログラマーは各本人の視点、
要は開発者本人としての視点は多かったと思うんですけど、
レビュアーの視点あんまりないと思っていて、
特にレビューにしても結構
欧米コミュニケーション的なレビューの話が載ってたような
記憶があるんです。
なんですけど、どうしても
コードレビューって結構
コミュニケーションだと思ってて、
コードコミュニケーションになるとやっぱり
その前提に立ってる文化があったりとかするんで、
日本の会社みたいなものを前提に置いた本書、
結構いい本だなと思ってますね。
これ面白いのが、
先輩と後輩が置いてあって、
先輩の同僚とか先輩よりちょっと上の人に
すごい怒りっぽいけど技術がある人みたいなのを置いてたりするんですよ。
その人とのレビューでのコミュニケーションの取り方みたいな話が載ってて、
ある種、どこか日本の開発現場に出そうな風景が想定された
本になってるんで、これはおすすめですね。
結構、2025年の前半の方ですかね、
コードレビューに関する本が2,3冊出てるんですよ。
はい。
みんな気にしてるんだな、みたいな雰囲気っていうのは感じるっていうところがありますね。
とりあえずこの4冊読んでみたらいかがでしょうかというものを挙げてみたんですけど、
他にこれいいんじゃない?みたいなものってありますか?
そうですね。
EM・PM向け知識体系を学習ロードマップにする
ちょっとまた別の視点で話そうかなと思うんですけど、
これいいんじゃないのっておすすめって、
自分が読んで読んだやつしかおすすめできないじゃないですか。
そうですね。そうあってほしいですよね。
なんで、自分は逆に自分が参考にしてるやつを話そうかなと思ってます。
自分のおすすめっていうか、これを自分に参考にいろいろ進めようと思ってますみたいなやつを話そうかなと思ってて、
それがKITAにまとまってるやつなんですけど、
ちょっと前にエンジニアリング組織論の招待とかを書かれた、
ヒロキ大地さんって方がKITAにまとめてる記事で、
後でURL貼っておくんですけど、
エンジニアリングマネージャーとかプロダクトマネージャーのための知識体系と読書ガイドっていう記事がありまして、
エンジニアリングマネージャーとかプロダクトマネージャーみたいなすごく幅広いところなんで、
いろんな本が紹介してあるんですよね。
これをもとに、
とはいえ自分の興味があって読んだ本とかから、
かぶってない範囲で本を選別するために、
これを参考にしようかなと思ってます。
例えば、
レビューの話とかテストの話とかであれば、
そこから派生して、
レビューのコミュニケーションみたいな話であれば、
ファシリテーションとかチーミングとかメンタリングみたいな、
似たようなことだけどちょっとずらした分野があるじゃないですか。
自分の伸ばしたい分野を見つけたときに参考にしようかなと思ってます。
なるほど。
このリストの参照をした上で買ったやつとかどれがあるんですか?
これから参考にしようかなみたいなやつとか、
逆にこれは読んだなとか、
今ある書籍の中でこの辺はかぶりそうかなみたいなやつとか。
そういう意味だと、
買ったけど積んでるなみたいなクリーンアーキテクチャとか、
これは買ったけど積んでるなっていうところですけど、
この分野に関してクリーンアーキテクチャは分かりやすいですけど、
この分野についてもう一回学び直そうって思ったときに、
これは新しくあるんじゃなくてこれを読み返せばいいんだけどなみたいな、
そういう判断基準にしたりとかはしてます。
へー、なるほど。
こっちにもアジャイル侍はあげられてますね。
いますね。
私この中だと確かにアジャイル侍はあるんですけど、
ここで挙がってる他のアジャイルとリーンの枠で載ってる本だと多分ないですね。
何だろうな。
迷ったときに何を参考にしようっていう状態が
クリーンになってるのが個人的には、
ありがたいなと思ってます。
この辺のデザインイットとか確かによく聞くし、
ここでもあげられてるし、
これは困ったら、
これを選ぼうっていう指針が出てる状態っていうのが、
個人的にはありがたい状態になってると思ってます。
なるほど。
あれですよね、エンジニアリングマネージャー
前提の話なんで、
幅としては結構広めですよね。
そうですね。
この記事の上の方に
エンジニアリングマネージャーって何する人よ
みたいなことが書いてあって、
強めの定義と弱めの定義みたいな話とかも出てくるんですけど、
いろんな自分が
なってる責務とか会社の状況とか
会社の特性みたいなのを合わせて
いろいろ考え方のベースにできるかなっていう風に思ってます。
なるほど。
これハードですよね。
そうですね。
ハードはハードだと思います。
弱いEM定義はいいとして、
強いEM定義の幅たりはすごいですよね。
重さがなかなか。
図を見てもらえばって感じですか。
でも弱めのEM定義でも
全部入ってるっちゃ入ってるんだなみたいな。
きっかけがゼロというわけじゃないんだなっていうのは思いました。
そうですね。
弱いEM定義と強いEM定義の
間のどこかにいますよね。
そうですね。
実際に
役割として割り振られたときに何を担ってるかっていうと
必ずしもここの範囲に
ここの定義の中に全部入るわけではないなと思いつつ。
カスタマイズできるじゃないですか。
自分は今こういう状態だなって中で
次求められることを
これだなってなったときに
これを強化するためにこのジャンルのこの本を読もうっていうのを
参考にできるなと思って
ずっと考えてるって感じです。
なるほど。
でかいロードマップをもとに
目的となる書籍読みに行けるっていう
体制が整ってるといいですよね。
なるほどな。
それって私自分の興味ベース
基準なので
ここの枠から外れたやつを積極的に手に取りに行くかってと
だいぶ怪しいですからね。
そうですね。
こっちは興味ベースっていうか必要に迫られてみたいな
感じになります。
アジャイルはギリ興味あるんだけど
Bに行くと
イントコンみたいな感じが
あったりとかするな
みたいなものはありますね。
はい、というところで
技術書の話をしてきました。
よければこの本がよかったよというところを
コメントでいただければありがたいかなと思います。
