London Tech Talkブッククラブ第2弾スタート
はい、じゃあ、アサイさん、今日もよろしくお願いします。
はい、よろしくお願いします。
はい、ということで、London Tech Talkブッククラブ第2弾、今日から始まりましたね。
始まりました。前回最後にやったのが、12月の頭だったので、
約45日ぶりくらいのブッククラブということで、なんか懐かしい気持ちになりました。
だいぶブランクあったよね。なんか逆に寂しいぐらいの感じ。
そうですね。
まあ年末年始もかぶってたからね、ちょっとしっかりやすい。
そうですね、クリスマス休暇ということで、はい。
はい、ということでじゃあ早速どんな本を読んでいるかとか、
まあどんな、前回といろいろ運営の仕方とかもちょっと変えてたりするのかな、
なんかそこら辺の前回の反省や学びを生かしてどんな感じでやってるかみたいなのを、
ちょっとブッククラブオーナーのアサイさんから簡単に話してもらってもいいですか?
タイムゾーンの調整
はい、そうですね。まあやり方自体そんなに変えてないんですけれども、
前回のまま良いところを生かしていくという感じで進めていて、
変わったことは参加者が2人増えていて、日本のタイムゾーンで2人増えたので、
その方々と今やっていて、
で、そうですね、タイムゾーンの問題が大きいので、
アメリカとロンドン、スイスとあと日本ということで、
ちょっと今は検査の時間が5時半で、
日本が2時半、アメリカが何時だっけな、
まあ夜8時とかだったと思うんですけど、
で、やってて、それがすごい、
ケンさんが朝起きるのもちょっと大変だと思いますし、
日本も昼の時間でミーティングとか被ってこれやってる人結構いるので、
タイムゾーンを回していくみたいなことをやっていきたいなとは思っています。
そうですね、タイムゾーンが1つ今トライアンドエラー中ですね。
そうですね、なかなか。
そうだね、なかなか難しいよね。メンバーによって最適解も違うでしょうしね。
コードの重複についての議論
例えば、昼休みを自由に取れるタイプの人もいれば、
2時だとちょっと昼休みかぶんないですみたいな人もいるだろうし。
うん。
だからその、今回あの、あ、そうだもう一個取り組みとしては、
まあ僕が基本的にモデレーターとしてたんですけど、
それを回していくみたいなことをやろうと思ってて、
立候補制でこのショーはこの方がみたいなのをやりたくて、
で、そのショーが方がタイミングがいい時間でやっていきたいなっていうのは思ってますね。
その方優先というか。
うん、確かに。それは分かりやすくていいかもしれないね。
はい。
僕も後半2ショーぐらいモデレーターする予定だから、ちょっと頑張っていこうかな。
お、ぜひ。よろしくお願いします。
あとは、そうだね、それでモデレーターが強い気持ちがある人のショーだけ読むってことで、
なんか全部読むわけではないんだよね。
はい。そうですね、一応これも投票制にして、
ショーが12、3ショーあって、そこに対して投票してもらって、
今は投票が3票くらいあるところだけを選んでとりあえず進めていく。
で、2票以上のところは後回しでやるか後で決めるみたいな感じで考えてて、
全部は選ばないという風にしてみましたね。
はい、これもちょっとやってみて、いろいろトライアンドエラー試行錯誤しながらやってるっていうのはいいですね。
うん。ということで今日の感想というか、やっていきますか。
どうですか?初回モデレーとして見て、全体の感想は。
やっぱり新しい人が入ってきてまた雰囲気が変わったというか、それが楽しかったですね。
かつこの本自体が、あ、そっか本の話もした方がいいですね、先に。
読んでいる本が、ソフトウェアミステイクス&トレイドオフっていう本で、
日本で言うとソフトウェア設計の失敗と謝りみたいな、とトレイドオフみたいなタイトルと思うんですけど、
それを読んでいて、で、今回の章の内容は、コードの重複は常に悪いわけではないというタイトル。
で、まあその内容について議論していくという感じですね。
いやもう、チョイスがいいよね。
なんかこう、過去の収録でアサイさんと2023年振り返り編だったかな、
ロンドンテックトークは失敗をしていくポッドキャストですよみたいな、なんかちょっと盛り上がったじゃん。
確かに。
それとマッチするような、まさにこう失敗から学んでいきましょう、トレイドオフを議論していきましょうみたいな本なんで、
なんか今回も第2章はね、こうコードディプリケーションのところで、
重複は必ずしも悪いことじゃないよねっていうのを結構読んでみたけど、
なんか現場の経験を思い出しながら、うなずきながら読めるような、
なんか本当に地に足ついた本だなっていう印象をさらに強くしました、私は。
うん、確かに。やっぱりいろんな失敗、
その結構章自体はシンプルというか、話の内容はシンプルで、
まあ読んでるとそのまま流しちゃうような話もあるんですけど、
実際にそれをいろんな人の失敗をっていうか、失敗の経験みたいなのを今回人力会議で聞くことができて、
まあその学びがやっぱり改めて大きかったなっていうふうに個人的に思いましたけど。
そうそう、それすごいわかる。なんか書いてることはそんな難しくないんだよね、書いてるサンプルコードとかもさ。
はい。
なんかこう議論の問いかけ方が上手いというか、なんかめちゃくちゃ難しいことがあって、
書いてあって、頑張って理解して読んで知識を得るタイプの本というより、
問題提起の仕方が上手くて、例えばドライ、Don't Repeat Yourselfは絶対解じゃないよね。
じゃあ何だっけ?っていう議論を問いかけられて、それを周りの人と議論するっていう本当に議論向きの本だなと思いましたね。
だから、読みやすいってのも一つ、ブッククラブを運営する意味では、読みづらくて途中でドロップアウトしづらいっていうのも一つ、なんだろうね、アドバンテージになってるかもしれないよね。
確かに。そういう意味では、前回のDDIってちょっと対照的というか、もっと読みづらかったですね、DDIは。
読みづらかった、超難しい。
うん。それを一緒に紐解いていくみたいなところと、今回はもっと議論を活発にしていくみたいな側面で、全然いいですね、今言ったように。
そうですね。ちなみに何で読んでるんですか?アサヒさんは。英語版をKindleで読んでる感じ?
英語にしましたね、Kindleで。Kindle最近買ったんで、それを活用してます。
何買ったんだっけ、Kindle。
Kindleの一番シンプルなペーパーパックって言うんですかね。なんだっけ、あ、それ名前忘れた。はい。8ギガのやつ。
ペーパーホワイト?
ペーパーホワイト、はい。
だったかな?
はい。今回その、この本を選んで議論がしやすいよねっていう話をしたと思うんですよね。
あ、そうでしたね。議論がしやすい本でしたね。
じゃあ簡単にどんな議論をしたか、なんか気になったディスカッショントピックとかを2人それぞれピックアップしていく感じにしようか。
そうですね、はい、確かにそうしましょう。
どうする?アサヒさんの方からいく?
そうですね、じゃあ僕から。
自分が読んだところでもいいし。
そうですね、僕やっぱりさっきも話しましたけど、議論を通して、なんだろう、自分が分かりづらいなと思ったことが
言語化されたような気がしていて、その分かりづらいっていうふうに思ってたけど、言語化されてなかったことを言語化できたような気がしていて。
例えばですけど、その継承対コンポジションっていうのがあって、
その継承をするとなんか分かりづらいっていう話があって、
それ自分でもJavaって書いてて継承したときに、先のコードを理解するには継承元のコードを理解しないといけないっていうことが結構あって、
それを分かりづらいなと思って言ったんですけども、それをあまり分かりづらいっていうのを言語化できてなくて、
そういう友人さんが今日それについて言及されて、確かになみたいな。
友人さんじゃなかったでしょうか。
そういうところがなんていうか、結構当たり前のことなんですけども、
はっきりと自分の中に入ってくるみたいなところがあったのが面白かったなと思いました。
それいいですね。
当たり前を疑うっていう問いかけをしてくれる本だなと本当に思ってて、
例えばドライの原則、Don't repeat yourselfの法則はいいよねみたいななんとなく雰囲気があるじゃないですか。
ドライ当たり前じゃないみたいな。
でも現場でソフトウェアを書くっていう文脈で考えると、
重複してもいい場面って実は結構あるよねっていうふうにスポットライト当ててくれる。
その具体的な例は全本に書いてくれるんですけど、
そこが何だろうね、例えば今後会社で同じような議論をした時にも、
この本にはこういうこと書いてるからとか、相手を説得しやすくなるような、
自分の中での理論とか言語化を手伝ってくれるような本だったので、
これDDIAの時もそうだったけど、結構現場に思ったより生きてくるなっていう印象ですね。
設計議論したりとか、あとはデザインドックレビューしたりするような時に。
確かに。
なんかその場で、これおかしいよねっていうのに気付けるというか、
トレードオフ、これは良くないんじゃないっていう方向もあるんじゃないみたいなところに、
気付きやすくなるみたいなメリットはありそうだなと思いました。
そうですね。
これも僕の失敗だけど、なんかジュニアエンジニアでいろんな本を読んで、
ドライドライってどこにも書いてるから、
ドライ最高じゃん、なんでもドライしていこうぜみたいな思ってた時期もあるんですけど、
じゃあそれでドライをしてみた結果、
その数ヶ月後とかに自分が共通化した共通化の仕方が間違っていたりとか、
必要以上にドライにしすぎたりしてしまって、
コードレベルの共通化とモノリスかマイクロサービスかの議論
逆に運用コストが下がったっていう経験があるからこそ、
なんか結構身に染みてくるというか、
逆にそれがないと多分、
やっぱり現場でどれぐらいやってきたかとかで、
現場の経験をうまく紐付けながら読んだ方が、
なんかためになるというか、議論の深みが出るような気がしますね。
なんか知識として入れるのはさっきも言ってる通り、
表層的にはそんな難しくない本なんで、
書いてあるんだふーんって終わると、
多分数ヶ月後に忘れちゃうと思うから、
他の人の経験とかを、
なんかこう肉付けしながら作っていくような感じで読むのが良さそうですよね、この本で。
そうですね、本当に新しい発見がいろいろあって、
知らない概念もちょっと出てきたりしたので、
そういうのをいろんな出会いがありながら読めるっていうのが、
やっぱり臨時会面白いですね。
そうですね。
けんさんはここが面白かったなとか、
あります?ここ気になったとか。
今回はやっぱりそのドライの原則が、
コードレベルで共通化するのはどうするっていう話と、
2つ目がそのプロセス感というかサービス感で、
そのモノリスかマイクロサービスかみたいな話がありましたね。
で、その2つ目のそのモノリスにすべきかマイクロサービスにするかっていう議論、
一種かなりネット界隈でもいろんなところでも、
ネット界隈でもいろんなところでもどの組織でも議論になっている話だと思っていて、
この本もあげてくれてましたね。
この本はその共通化するとかメンテナンスコストっていうところに着目して、
いろいろいろんなネタを見方を提案してくれたと思ってて、
ここも広げようと思ったらすごい広がるトピックだなというのを読んで改めて思いました。
マイクロサービスの分割とコードの抽象化
例えばコードレベルの話で言うと、
これはマイクロサービスに切り出した方がいいよね。
それともモノリスやった方がいいよねっていうふうに決着がつくように見えるような議論でも、
例えばスタートアップの規模とか採用のプランとか、
あと中長期的なエンジニアの育成の戦略とか、
あとプログラミング言語の習熟度とか、
あと今回参加してくれた人が持ち込んでくれた観点だけど、
例えばCEOが特定のフレームワークに強いとか、
どこどこのビッグテック出身だからこういうカルチャーがあるとかっていういろんなカルチャー的側面とか、
すごいいろんな側面があって初めてマイクロサービスかモノリスにするかみたいなのが決まっていく。
だからマイクロサービスかモノリスかみたいな議論から始めていくというよりは、
もっと本質的にもっと大きいエンジニアチームの戦略みたいなのがあれば、
逆にここもカチッと決まっていくのかなみたいな。
逆にそのボトムアップで決めづらいところでもあったりするのかなと思うんですよね。
なんかインディビジュアルコントリビューターとかが、
いやこれちょっと分かんない。
でもちょっと言ってみるとインディビジュアルコントリビューターとかが本を読んで、
マイクロサービス良さそうって提案して、
そこで初めて議論になるけど、
そこでちゃんと上からのカチッとした方針とかがないと、
とりあえずマイクロサービス作ったけどオーナーシップがなくなって、
中途半端なマイクロサービスが取り残されてしまいましたとかという問題にもなってしまいそうな気がする。
でも上からトップダウンだからいいというわけでもないし、
ちょっと分かんないな。答えがない。
コミュニケーションが大事っていう話が途中でけんさんもおっしゃってましたけど、
撤退コストやチームの運営の重要性
一人で決められる問題ではないところも多いと思うので、
トップダウンの必要ないかもしれないですけど、議論が必要なことは多そうですね。
チーム内での議論とかチームのメンバーの理解状況とか、
そういうところを踏まえて決めていく必要がありそうなことではありますね。
そうですね。
マイクロサービスに関しても参加してる人みんなみんなが自社ではこうしてます。
うちではこうしてますみたいな、どんどんどんどん入れてくれたのがめちゃくちゃよかったね。
そうですね。
まさに世間的にマイクロサービスが流行っているから、
それを導入してみたけど失敗しちゃったみたいな事例も話してくださった方がいて、
その結果人が辞めてマイクロサービスのメンテができなくなってしまったものがある。
個人のオファーサービスがあるみたいなことを言ってる方もいて、
そういうのまさに本当にこの本で言ってる内容とかなり近いのが実際に起きてしまったみたいなのが出てきて面白かったなと思いました。
そうですよね。
オーナーシップの明確感みたいなのを意識して、
やっぱプロセス、サービスとか作っていったりしないといけないなっていうのは改めて思ったし、
はい。
でもそれも結構やっぱりチームの移動とかモチベーションマネジメントとかによって変わってきたりしちゃうので、
なんか自分一個人が悩めば解決するっていう話でもないなとは思いましたね。
やっぱり。
自分がオーナーシップを発揮したところでじゃあオーファーサービス全部管理できますかって言うと別にできないし。
うん。
そうですね。
そこで評価精度がね、ちゃんとついてこないとバーナウトしてしまうし。
うん。結構やっぱり大きい問題ですね。
そうですね。
進めようと思うと。
うん。
でもなんかこう現場でマイクロサービスちょっとやってみたけど、この本を読んでちょっと自分の思考っての抽象レイヤーを一個上げて見れるような客観視して見れるようないい本かもしれないなと思いました。
確かに。
例えば僕とかもインディビジュアルコントリビューターでずっとやっているけど、なんかその戦略を立てる側から見るとこういう観点もあるよねとか。
うん。
チームを採用する観点ではこういうのもあるよねみたいな。
一つくらい。
うん。
なんだろうね、こうレイヤーを上げて見れるというか、なんかそういうのが面白かったな。
確かに。
そういうのもやっぱりこのTakeawayのノートがあるからこそ見えてくるところもあった気がしますね。
うん。
いやーこのフォーマット最高じゃないですか。
いいですね。
うん、今も見ながらさ収録してるけど。
これすごいよね。読むの楽しい、こっち読む方が楽しいもんだって。
いや本当にそうですね。
数週間前に読んどいて書いといて、前日に読むとうわめっちゃ書いてあるみたいな。
めちゃくちゃ学びが多いですね。
うん。
あと本の内容で具体的に気になったというか面白いなと思ったところは、
そうですね、個人的にはマイクロサービスとかに分割するとか、
もしくはコードのレベルの抽象化を上げるっていうのを早い段階にしない方がいいというか、
っていう話があったと思うんですけど、
そういうのは結構マイクロサービスといってはドメインがAMIな時に早めに分割しない方がいいっていうのは結構読んだことがあったんですけど、
コードの抽象化とか継承するみたいなのも同じだっていうのは個人的に勉強になって面白かったですね。
マイクロサービスの場合は早めに分割しない方がいいみたいな話ですけど、
コードレベルの場合はなるべく早い段階では重複していた方がいいっていうことになると思うんで、
それがある意味逆のように見えるというか、逆じゃないんですけど、それはちょっと面白いなと思いました。
撤退コストの違いとかっていうのもあるんじゃないですかね。
例えばライブラリー、一つのライブラリーのコードの中だけだったら、
グレップして探して戻して、ユニットテストでデグレーションがないかカバーして、
そんなに難しくない。30分くらいもあれば多分戻せるようなもの。
だけどマイクロサービスにして作っちゃうと、
例えばデータの移行をしてとか、それを依存しているユーザーへの悪影響がないか考えたりとか、
移行プランとかも考えるし、
クローズしてからちゃんとリソースを全部消せてるかみたいなバリデーションフェーズもしっかり入ってくるし、
下手したらワンクォーター使うし、少なくとも数週間、数日、ものによっては使うかなと思うんで。
はい。
やっぱ撤退プランみたいなのも考えるかどうかとか、
撤退コストの違いでその判断にもなってくるのかなと思いましたね。
いや確かに。
本当に誰がメンテするのか、もしこの人が辞めたらどうするのかみたいな話とか、
そういうところも考えておかないとメンテしず、
それは本当にチーム、どうチームを運営するかみたいなところにつながってくる気がするんですけど。
そうですよね。
この本を受けて聞いてみたいのは、
じゃあ明日、今日から仕事するときに、
どう自分の中で変わりそうなものありますか?
なんかスタンスでもいいし、
逆に現場でこういう課題抱えてたからこれやってみようかなとか。
そうですね。
やっぱりマイクロサービスはかなり取り入れているというか、
そういう的なことをすごいしているので、
また新しいサービスが生まれようとすることが結構あるんですけども、
そのときに本当にそのサービス必要なんだっけみたいな議論に入っていって、
そのプロトコンをどんどん探して提案していくというか、
こういうネガティブな面もあるよねみたいな話をできるようになるかなというふうに思いました。
そうですよね。
やっぱり多分SREとかだと他社の作っている、
他のチームの作っているサービスの設計議論に呼ばれたりとか、
デザインドックをレビューすることも多いと思うんですけど、
コードリプリケーションとOSSの議論
そういうときにオーナーシップ今後ちゃんと運営していけるのとか、
つつかなければいけないクリティカルなデメリットを、
設計段階、なるべく早い段階で叩くことによって、
実際運用してから、やっぱ駄目なんでSREちょっとお願いみたいな最悪のケースにならないように、
自分たちの首を守るというか、自分たちの時間を守るためにも早い設計段階でいろいろ突っ込めるような、
なんだろうね、ツールが勉強してるみたいな感じで、
僕も読んでましたね、同じような感じ。
なんかけんさん他にもあります?明日から使えそうだなみたいな。
そうですね。
コードサンプルとかはすごいシンプルだったから、とりあえずまだ第2章しか読んでない。
あとはマイクロサービスの文脈もちょっと絡んでくるけど、
OSSのライブラリを使うかどうかというところでも似たようなディスカッションができましたね。
今回ブッククラブでもOSSのライブラリはどういうときに使うべきかとか、
どういうときに避けるべきかという議論がありましたけど、
普通にサービス変えてても簡単にサードパーティーの依存で注入できるじゃないですか。
NPMだったらNPMインストールみたいな感じでさ。
でもそれをするのって簡単だけど撤退コストってそんな簡単じゃなくて、
運営していくとセキュリティ絡みでのインシデントも発生するリスクもあるし、
あとはやっぱりインストールしたサードパーティーのライブラリちゃんと読み込んでますかというか、
理解してインストールしてますかみたいなところもあると思うので、
なんかそこが一つ観点としては、
開発していくときに便利だからこのインストールしてみましたみたいなプルリクが出てきたときに、
ちゃんと建設的に批判できるような言語をここで学んだみたいなところは一つあると思います。
確かに。
そのOSSを使うべきか、自分で実装すべきかっていう話はすごいいろんな方からもコメントとか議論になって、
やっぱりドキュメントがないからそのOSSを自分で実装しようと思って実装したけど、
その人が退職してしまってメンテができなくなってしまった。
結局OSSを使い断ったみたいな事例があったりとかしたのでやっぱりこれもマイクロサービスとかの議論と似てますけど、
入れた後に、自分で実装した後にどうするかとか、
ブッククラブの運営とモデレーターの学び
OSSを入れてから今後実際に実装する方向でいけるのかみたいな今後のプランを持っておかないと危険なことも多いのかなというふうには思いましたね。
そうですよね。
いやなんかブッククラブでめちゃくちゃ議論してさ、すごい盛り上がって時間も伸びちゃったからさ、
なんかもう今収録してますけど結構お腹いっぱいもう。
そうですね。
今日はショートで撮ろうかなみたいな話を2人でもしてたからね。
そうですね。
次回以降またゲストの方を呼んで話できたらいいかなと思ってるので、個人的には。
そんな感じでやっていきたいですね。
そうですね。
このショーどうですか?言い残したことないですか?
なんか言い残したことがありすぎてないですね。
逆にそうですね。
言おうと思ったらいっぱいあるんですけど。
そうそうそうそう。
じゃあ逆にこう、今後もこの本でブッククラブ運営していくと思うけど、
なんか隠れ目標とかこういうふうに運営していきたいみたいな。
あと次の章、次は第3章も読むんだよね。
はい。
3章に向けたなんか心意気みたいなのあったりします?
いやー、まあ次は友人さんが、何ですかね。
そっか、モデルでやってくださるって言ってるんで。
それが楽しみですね。やっぱり自分以外の人がいてどうなんだろうみたいな。
で、もっといろんな人に挑戦してもらえるように、今ケンさん、友人さんとケンタさんが行ってくださってるんで、
まあ他の人にもやってもらえるようにちょっと声掛けしていきたいなと思います。
いいねー。
はい。
なんかその、まあモデレーターがね増えると、
ブッククラブ自体もやっぱあさひさんのスタイルの良いところもあるけど、
他の人の良いところも入ってくると、お互いモデレーターの仕方みたいなのも学べるだろうしね。
うん。確かに。そういうところも楽しみですね。
ね。確かに。
まあモデレーターとかもしかしてやったことないようなジュニアの方とかがいたら、ここで練習してもらって。
確かに。ぜひまだ参加者募集してますので。
DDAの時もなんか6章7章ぐらいで入ってきてくれた人もいたしね。
うん。いましたね。
そう。そのブッククラブやってるってことをね、途中で知ったんですけど、今から入りますかみたいな。
はい。
ケンタ君とかも途中で入ってくれたし。
そうですね、まさに。
はい。楽しかな。
はい。
いやーなんか今年もちょっと面白い本を選定してくれたので、まあ楽しみですね。
楽しみですね。また今年も何本かブッククラブやっていけたらと思うので、引き続き頑張っていきたいと思います。
はい。ということで、まあじゃあ第2章のコードリプリケーションis not always bad読んだ感想は、まあ2人ともお腹いっぱいということで今日はショートバージョンでこれぐらいにしましょうかね。
はい。ありがとうございます。
はい。じゃあお疲れ様。
お疲れ様です。
