この番組はエンジニアの成長は楽しい学びからをもっとうにエンジニアリングに関する学びをワイワイお届けするラジオですワイワイワイワイワイワイワイワイワイワイXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

ということで本日ですねカイチとノリでお送りしてますカイチとノリでお送りしておりますはいということで最近ですね読んだ本の話をしていこうかなと思いますありがたい今回読んだ本がですね

良いコード悪いコードで学ぶ設計入門保守しやすい成長し続けるコードの書き方という本を読んでまいりましたいわゆるミノクドウ本というやつですねいわゆるミノクドウ本というやつですね著者の方がミノクドウさんという方でよくXとかでプログラムあるあるイケてないコード風刺動画みたいなやつを作ってるそういう方の書いた本でございます

去年のなんか商業者のエンジニアモン大賞トップ10ぐらい入ってましたっけ気のせいでしたっけあれじゃないですかね2年2個前にプレゼン優勝してませんでしたっけあーそんな感じだったか2023年の大賞ですね技術者部門のおーじゃあ正解でしたねはい今更読みました

僕はいつ読んだかな?でもちょっと前っすね、読んだの。あ、マジ?ちょっと前に読んだ。2年前かもしれない、それこそ。当時多分何か話した気もしないでもない。うそ?はい。まあちょっとこれ読んだきっかけがですね、最後に話そうかな。読んだきっかけが最後に話すわ。わかりました。はい。

どんな本かというと悪いコードを見てこんな問題がありますっていうところが出てきてそれをこう書いたらいいよねっていう感じでいろんな学びがカタログ的に詰まってるようなそんな本ですね設計できるようになるよ設計の入門書で結構良いかなと思ってて確かにプログラムし始めの時に何も書かずに書いたらそうなるよねっていうなんて言うんでしょう

悪いコードが結構たくさん出ててですね早ければ早いほど学びが多いんじゃないかなっていう本でしたね読むタイミングが結構内容も分かりやすいので1年目2年目とかに読んでおくとすごく差がつけられる本なんじゃないかなと思ってますなんか悪いよって言われることはあるけどそれをやると具体的にどうなるみたいなのってあんまり情報としてキャッチしづらいと思ってて

そういうのが分かりやすく明示的に書いてていいなと面白いなと思った記憶がありますそうですね本の中でも言ってるんですけど良くない設計って気づくのがめちゃめちゃむずい

なぜなら何が良くて何が悪いかっていうのを知ってないと気づけないのでそれを基本的には職場で学ぶじゃないですかでも職場にあるコードが合ってるか合ってないかっていう基礎がないとそこの判断まずそもそもできないよねっていうところでちゃんと学んでおかないと知ることがそもそも難しいですよっていうジャンルの話ですねという中でこの本では命名の部分だったりとか

条件分岐複雑になっちゃってるよねっていう時の減らし方とかあとはカプセル化とか値オブジェクトとかコメントとかメソッド定義とかそういう結構多岐にわたって良いコード悪いコードを紹介してくれてるという両者でございますそんな中でですね今回はオブジェクト思考言語で

モデルを作る時のちょっとお話で学びになった部分があったのでその共有をしていこうかなと思ってますそもそもモデルってすごいざっくりした言葉だと思うんですけどそうですねどんな意味だと思いますか意味?モデルか概念的な意味概念的な意味?なんて言うでしょうイデアみたいななんかわかります?

イデアみたいな懐かしいですね国語の現代文思い出すわそれ資格を資格だと認識できるのはみんなの心の中に理想とされる資格イデアがあるからこの資格を資格と認識できるみたいな哲学のやつっていうそういう意味合いの概念ユーザーモデルはユーザーという概念みたいな意味合い

うんうんうんですか?なんとも言えないちょっとムズすぎて消化できなかったんですけどはいここの本ではモデルっていうのは特定の目的達成のために

最低限考慮が必要な要素を備えたものって書いてるんですよねなるほど特に最低限っていうところが結構ポイントになっていて例えば車のモデルを説明するってなった時にその目的が車の構造を理解することだとするじゃないですかそしたら車ってざっくり言うと車を囲ってる枠の部分があって車輪が4つ付いてて車輪が4つ付いてて

車輪をつなぐ車軸がついてて車軸と車軸をつなぐ間にエンジンがあってそこで燃料とかを使ってエンジンを回転させてエンジンを起動させてモーターを回転させて車を動かしてますよっていう感じじゃないですか多分車ってこれがいわゆる最低限必要なものっていう感じで例えばその走る説明をする中であんまりエンジンの細かい構造とか

あんまり気にしなくてもいいというかうんうんざっくり車っていうものの仕組みを理解するっていう特定の目的達成のためには今のが最低限必要だよねっていうので結構その何て言うんでしょう無駄を削ぎ落として理解を助けるためにあるものみたいなうんうんうんっていうのがこのモデルっていうものですよと言ってますなるほどはいで

オブジェクト思考の中で作られるまたモデルっていうとちょっとドメインモデル的なものになってくるのでどちらかというと理解を助けるというよりは世の中にあるものをプログラムで表現したものっていう方がちょっと近しい感じするんですけどそれを表現するにしても結局最低限がいいよねみたいな目的達成のために最低限のものを詰め込むといいよねとなるほどまあなんかなんだろうな

タイヤの空気圧とかどうでもいいよねみたいな話なんですかね細かいところまで書いてると結局それは理解を助けないから理解を助ける範囲である必要があってそれは必要最低限っていう言葉に込められてるとですそのプログラミングの中で作られるモデルのちょっと今回はニッチなんですけど命名の話ほう

好きしていきます 命名好きはい命名ってあのすごく大事でこの命名をミスっただけで同じコードでもあの今後の保守性が全然変わってくるというか 特に今回は本の中ではですね存在駆動ではなく目的駆動で命名せよみたいなことを書いてるんですけど ほう

これ超大事だなってちょっと思ったんでこれを紹介していこうと思います気になるけどどういうこっちゃですねしかもビュッフェでビュッフェでビュッフェでって言うとあれなんですけどどっちかっていうとキッチンでまた?キッチンが一番いいと思うんだよねでもそうですね

これまでキッチンで説明してきたとかそういう文脈なしにキッチンで説明するのが一番いいと思うなるほどちょっとそれも気になるなお願いしますはいというのでまずよくあるウェブサイトのやばい行動になりがち系のやつでこの本で紹介されてた例をそのまま出してくるんですけど商品

商品アイテム英語名だと多分プロダクトって書かれてた気がするこの商品っていう命名どう思います?ちなみにテーブルはもう一旦いろいろ忘れてこの商品1個しかないですわかりました商品という命名ですか?いやまあまあ商品扱うならいいんじゃない?まあ結構そうなるよねって感じの命名じゃないですかただですね

この本では商品っていう名前は良くないですよと言ってますなるほどなぜならこの商品がいろんな使われ方するからなんですよ例えば注文するとき

商品使いますよね注文とちょっと近いかもしれないですけど予約するときその商品の購入予約みたいなのをするときこれも商品使いますよね商品使いますね商品予約しますねあとはもしそのECサイトがモールみたいな感じだったとして各お店が出すために出品をしますよねそうしますねその時も商品使いますよねはい

で購入成立しましたよって言って発送するときこれも商品使いますよねっていうので実は1個の商品っていうものに対してすっごいたくさんの関心事が詰め込まれてしまっているうんうんうんのでそれを分けないといけないよとうんうんうんっていうので例えば予約に関するものだったら予約品っていうオブジェクトを作ってあげるしうん

注文に関するものだったら注文品ってオブジェクトを作ってあげるし出品に関するものだったらこれは出品した結果在庫に追加されるので在庫品っていうキーワードを使ったりとか配送するなら発送するなら発送品っていう名前をつけてあげてそういう風に目的に特化した

命名をしてあげることによってそのクラスの中にその目的にしか関係ない要素が詰め込まれることになるんで分かりやすくなるよねみたいななるほどこれはキッチンでも同じで

キッチンって食材全部冷蔵庫か冷凍庫に入ってるはずじゃないですか物に入れますけどだいたい入ってますね常温もありますよもちろんクルトンとか多分常温で保存してますよよく出ましたねクルトンクルトンはそうですねクルトンは常温で保存してるんですけどとはいえだいたい1個のデータストックがありますよねこれって要はさっきのECサイトの例で言うと1個のデータベースに入ってるよねっていうところと同じだと思うんですよ

要は一つのデータソースがあってそこに食材っていう同じ存在が入ってるよと一方実際にその食材がどう扱われるかっていうのはちょっと目的によって違っていて例えば仕入れの時だったらそれは仕入れ品じゃないですか仕入れ品だったら仕入れに関する関心事なんだろうな農機とか価格もそうですね

まあその場合だとちょっと価格っていうとあれだから原材料費とかなるかなはいになるしあとなんかあるのかな数量まあ数量もあるかあとどっから仕入れてるかとかも関係あるかうんそれに紐づいた伝票とかもあるはずうんっていうので今出てきたこれらって料理するとき全然どうでもいいですよねまあそうですねうんあのコンソメスープ作るときにあの

この玉ねぎの納期は確か2日前だったからとかあんま気にしないですよねちょっと食品だとややこしいですけどねいやあのあれだよわかるよはい納期が1年前だったらさすがにダメだなってなるよね的なはいそうです賞味期限的な意味でねやっぱり

賞味期限気にすればいいじゃんまあ確かにねそうですね原材料費は関係ないですね料理するときはまあそうだね目付けとかは関係ないですね料理するときはああ確かにそう考えるとあれかもね試作品作るときはまた別のモデルが必要なのかもねなるほど確かに試作品作るときは原価関係ありますよね

作るのとどうなんだろうそうですねコスト気にしないと利益出なくなっちゃうんでっていうのでまず仕入れ品っていうのがあるよねとあとは在庫に残ってる時とか今すでに持ってるもの在庫とかって言ったりすると思うんですけど

在庫は在庫でまたチェック項目違いますよねまあそんな気がする例えば順番があれになってるか兄貴弟になってるか先に来たやつ兄貴って呼んでるんだ飲食店だと先入れ先出しのこと兄貴弟って言うんですよいやいや知らないです知らないです僕言ってなかったですマジで居酒屋結構ね言いますよそうなんだなんで

先入れ先出しだから先に入れたものから使っていけよっていうやつ順番だから関係あるよねとファーストインファーストアウトあれ兄貴弟なんですねあれ兄貴弟って言いますねあと在庫管理してるなら数量大事ですよね大事ですね賞味期限も多分廃棄するときとかに必要なので大事ですよねそしてもう一個使い方としては調理するときに食材として使うケースもありますねと

食材で使う場合だと今度は数量関係あるんですけど多分単位変わってくると思うんですよ例えばトマトだったら一玉なら一致するんですけど半玉とかあるじゃないですか半分使うよみたいな

そういう場合って多分これまで使ってきた単位とまた異なってるし確かに確かに冷凍のフライドポテトとかだと在庫時点では1袋2袋だけど調理する段階でグラムになりそうですねそうそうそうそうとかあと賞味期限とかももちろんそうなんですけど賞味期限気にしつつもあと多分食材の見た目自体も気にするんじゃないかなって気がするんですよね調理する時になると見た目の悪い部分切り落とさなきゃいけなかったりするのでうん

一旦そんな感じでいいかな同じ1個の食材っていうものに対しても複数の使われ方があってその使われ方によって気にするべきポイント全然違うよねとそれをプログラミングでもやろうぜっていうこのモデルの話でしたね食材でそれを一つに扱うと今言ってた膨大な役割がその時に使う変数っていうんですかねが

まるっと一つのモデルに入っている状態になって分かりづらいよねみたいな話ですかそうですこれがプログラムで一個で使われてしまうと関係ない部分出てきたりとか全然使ってないけどこんなにたくさんプロパティあるよみたいな状態とか例えば2000行このファイルあるけど実は600行しか関係ないみたいなこととか600行も多いような気もするんですけどインスタンス作るの大変そうですよねなんかうん

確かにっていうので役割ごとに見え方によって目的によってか分ける必要がありますよとただ実際にやっぱりアプリケーション作るとさどうしても特に僕はララベルユーザーだから非常に分かるんですけどララベルってMVCパターンで作られてるんですねはいでMVCのMで

ここRuby on Railsと同じで各1テーブルにつき1モデル作られるんですよそれがあるからそれに引っ張られてビジネスロジック各サービスを作っても結局そのテーブルと同じ単位で作られてそれをコントローラーが使ってみたいなうまく目的で集約されてないのをすごいよく見かけるなっていうのを印象としてあってそれに引っ張られた結果

ユーザーとかプロダクトって1個になっちゃうよねと思っちゃったんですよねただそれが1個になると使いにくいから分けようぜっていう継承を今日はしたかったっていうはいちょっとじゃあディスカッションパート入ってもいいってことですか聞きたいこととか議論したいこととか

言いたいんですけど言ってることは分かるそうできるようになりたいなと思う中でもどうやってやっていくのがいいんでしょうねっていうところで多分最初は一つで作っていくと思うんですよ最初に出てた

プロダクトの例もそうですし食材の例もそうですけど多分最初って調理するだけみたいな役割が一つしかなくてでただサービスっていうかプロダクトがどんどん進んでいくにつれて複雑化していくみたいな複雑化した地点でモデル分けるみたいな作業が発生するってことなんですかねそれはやった方がいいよね理想論で言うとうん

影響範囲ってかそうだよなとんでもないと思うよ場所によってというかマジで最初にやらないといけない最初って言ってるのは機能増えた時点でこれ今あるプロダクトに足すんじゃなくて分けなきゃなって思わなきゃいけないってことですよねそうだねそれむずいよねっていうことそうですねむずいむずそう

どうやっていくんだろうなーって僕ちょっとこれに関しては1個あってこの本の内容とかではないんですけど何で読んだんだっけなボブおじさん系のなんかだった気がするんですけど単一責任原則ってあったじゃないですかはいソリッドネース個々のモジュールは1つの責任だけを持つべきだよねみたいなの説明の時に

一人のアクターに対して責任を持つみたいなやつがどっかに書いてあったんですよね情報源出てこないな俺も聞き覚えがあります読み覚えがありますなのでそれを見て思ったのはユースケース図書いてユースケース図ってシステムと棒人間みたいなやつを書いてどういう操作ができるかっていうのを書くUMLの図なんですけどあれ書いた時に

同じじゃなかったら絶対分けるよねっていう判断は結構強いのかなと思いましたねその上で最初プロダクトっていう命名をしているけどプロダクトがプロダクトじゃない方がいいなってなる瞬間あるってことですよねあるねそれ怖いね確かにでもアグレッシブに書いてくるのが理想論というか書いていけると読みやすいってことなんでしょうねうん

本当になんかもう手遅れだって状態になったら変えれないかもしれないですけどまあ確かにまあそうね多分本当にマジでリフタリングするんだったらテスト書いてからやるんでしょうけどテスト書いていやむずそうだな同じプロダクトがいろんな名前に変わるんですもんね分けようと思ったらそうなるねまあじゃあちょっと職人技が伴いますね多分

マジでそうねそうね多分1個の共通のプロダクトになってたやつはとりあえず残したまんま新しい概念のやつを作って1個ずつ入れ替えていくしかないよね多分そうですねなるほどないや絶対やっちゃうんだよな何も考えてない超気をつけないとというかアクターマジで直す勇気本当に直す勇気持ちたいですねそういうのねそれがまず

コスパ見合ってるならって感じだけどねそうですねもちろんそうですね無駄に直す必要はないですねそうですね前提としてこの本って保守しやすい成長し続けるコードの書き方っていうとこなので一発作っておしまいみたいなことはあんまないと思うんですけどそれがあるならそこまでめんどくさいことしなくてもいいかもしれないうんうんうん

なんならねその機能が変わらないところとかでも差はなくていいですねそうねでも機能が変わらないっていうのは将来まで変わらないかどうか分かんないっていうジレンマもあるんだよねまあまあ確かにだからちょっとそこの旧CDの部分というかどれくらい一箇所に気をつけるかみたいなところは結構職人技な気はするそれはもう本当に日々考え続けて勘どころを見つけていくしかないですねうんうん

でもとりあえずこの本を読んで思ったのはプロダクトもそうだけどあとユーザーもそういうの起こりやすいらしいですねユーザーテーブルってことですねユーザーモデルユーザーテーブルさっきメルカリのサイトを見てみたんですけどメルカリってユーザーとユーザーが商品のやり取りするじゃないですかこれどっちもユーザーにしちゃいそうだなと思ったんですよね

実際どうなってんだろうでもみんな買えるしみんな売れるんですかメルカリって多分そうだと思うけどオブジェクトってその位置機能が動いた時のスナップショットみたいな役割するようなイメージあるんで多分

購入者と出品者作った方がいいんじゃないかなとは思いましたねデータベースのテーブル上は一緒かもしれないけどいざデータの操作が伴うときにインスタンス作るような操作では分けてやった方がいいみたいな話ですねそうそうそうプラス出品者も多分個人と法人があってそこを分けた方がいいかなって気がするのと

あとログインというか会員登録系の認証で使うユーザーとかも分けた方がいいのかなっていう気はしましたね確かにね一緒にしちゃうよねでもねめっちゃシンプルだったら一緒でも究極いいのかもしれないですけど複雑っていうかメルカリはめんどくさい方な気がするんでそういうのは分けた方が読みやすそうですよねECサイトにおける商品とかなんか

不動産系のサイトにおける物件とか求人サイトにおける求人とかもそんな気がするんだけどそのサイトにおいて占める役割の大きいやつはだいたい分ける可能性ありそうな気がするね分けれる余地というかライフサイクルがあるやつみたいな感じなんですかねそれは確かにそうかも生まれて死んでいくみたいなYouTubeの動画とかあんのかなでもやっぱりユースケース

でかい気がするなそうですねウェブサイトってだいたい使う人と管理する人いるじゃないですかその両者が同じものを触ってたら起きうるよねこの分けなきゃいけないっていう状況うんうんうんうんうんそうですね業務用システムとかだとそもそもアプリ分かれてたりするじゃないですかだから分かれてる方が管理しやすいというか分かりやすいんでしょうねうん

それこそ我々も使ってるボイシーとかだと配信者用のアプリと使うユーザー用のアプリがあってみたいなそういうことですよねですですですだから多分モデルレベルでは分かれているはずアプリが違うから多分アプリ違うから一緒かもしれないですけど多分違うんで

ありがとうございますまた明日の今日のリファクタリングにつながるいい話だったと思うんでそうねなんかちょっとぜひ特に今新しくプロダクト作ってるよっていうフェーズの時はなんかちょっと振り返ってこれもしかして分けれる概念なんじゃないかっていうのは考えてみると良いのかなって思ってます確かに僕も読んだんですけど多分結構抜け落ちてるんで

読み直したいな定期的にすごいでも本当に優しいって言ったらあれですけど分かりやすいことがいっぱい書いてますよね分かりやすくしてくれてますよねめちゃくちゃだいぶ入門本って感じのイメージでしたねこれを今更読んだ背景というかきっかけなんですけど今会社で新卒のOJTみたいな感じで一緒のプロジェクトで働いてる新卒の子に

ワンオンワンというか振り返りを毎日やってたりするんですけどある日ですね思い出したことがあっていつだかのLT会参加した時にオンボーディングこうやってやるといいよみたいな発表してた方がいたんですよその人がやってた内容がその会社のフードとか

働き方みたいなところが学べる本を使って臨読会をするみたいなその中で読んだことで学んだこととか分かんなかったこととかそういうのを共有し合う時間にワンオンを使うみたいなそれを

その人は週1とかでやるって言ってたのかな毎日かなちょっと頻度忘れたんですけど定期的にそれをやっていきますよとでも本読むってあんま業務中にはやらないじゃないですかなので読めなかったらその時は潔くリスケしていいよっていう風にまず決めておくとそうすることによって

まず心理的安全性が高まるというかできてなかったらそれでいいんだっていうところが心理的安全性につながるっていうのとあとはその臨読会を通じて本の内容から学びを得られるみたいなのがあってこれオンボーディングでめっちゃいいですよっていうのを言ってた人がいてやってみたんですよそれをすごい会社の風土とか仕組みのところを学ぶっていうと

本のチョイスとかむずすぎたのでそこがちょっと分かんないですねどういう本なんですか例えば会社が本出してないと無理じゃねって思ったんですけどそうですよねそれこそサイボーズさんとか社長が本出してますけどそういうのじゃないと難しいですよね多分あれなのかなともしくはちょっとあんまりいい例じゃないんですけど会社がアジャイルな文化を大事にしているとかだったらアジャイル関連の

そういうの読むとかは確かにありかもしれないですねなるほどな経営人が例えば一周から

異臭から始めようとかをすごい影響を受けていてそれに関する考え方をいっぱい取り入れているとかだったらそういう本を読んだりとかそういうことなのかなと思いつつでもチョイス難しいですね翻訳して本に落とし込む作業が求められるんですね事前に一冊読んどかないと無理じゃないみたいなそんな感じなんだけどでも我々はエンジニアだろうということでそういう技術的な本

を読んでそれを学びにして共有できればまあコードの書き方変わっていいのかなと思いつつ あーいいあとちょっと他にこう振り返りがちょっとまんねり化しつつもあったっていうのがあって取り入れてみたんですよ はいそれきっかけでちょっと読んだんですけどこの林読会がめっちゃ良くてですね なんか良さそうだな聞いてるとまず

臨読会って言ってるんですけどほぼ臨読会ではない何回なんですか?各々呼んでる会いいですね各々呼んでる会でしたまず良かったポイントはこっちもまず本読まなきゃいけないよってことで刺激されたっていうのはあるんですけどそれよりも相手がまずコードをどんどん学んでってるっていうのがね

目に見えてわかったですねだからこれちょっと本のチョイスも大事だと思うんですけど今回この本選んだのはマジでめちゃめちゃ正解だったなと思ってその業務の質問とかもされるんですよその実装のところとかででなんか

ここどうしたらいいですかねっていうのじゃなくてなんかこれ本だとこういう風にするのがいいっていう風に書いてあったと思うんですが実際のこのコードだとこういう問題があってこうこうこうでみたいななんかちょっと1段階2段階深い議論ができたというかすごいなそれはそういうのができるようになったっていうのがまず1個良かったなっていうのとあとねなんかこれはあの

めっちゃ主観なんですけど本人がよりプログラミングにハマってる感じが出てきたような気がするめっちゃいいですねもともとフロント結構興味ありますっていうタイプの子だったんですよなんか今バックエンドに熱中してますねこの設計とかを読んで今までデータ取って渡すだけだと思ってたんでフロントの方が楽しいなって思ってたんですけど

めっちゃ奥深かったっすよみたいになってめっちゃいい林道会って言ってもねほぼその日の業務の質問で終わってたんであんまり感想の言い合いとかもしてないんですよ具体的に言うと何分枠で何やってるんですか15分枠で

まず最初にその日の業務の質問とか不明点あった時にそれを解消してるだいたいそれで終わる奇跡的に時間が余った時だけ本の話するっていうなるほどじゃあ各々読みましょうねはやっててあとは共通の話題としてその技術書があるみたいな感じなんですねそうそうそうそういいなお互い共通の知識持ってるのめちゃいいですね確かに

じゃあここまでに何章読んできてねみたいな進め方ではない?ではないとりあえず読めるペースでいいよって読めるペースで読んでもらってのりさんはさっと読んどいて質問受けたらディスカッションするみたいなそれが理想だったんですけどなんなら僕は追い越されましたねそれでも質問受けたらそのとこちょっと読んで

みたいな感じなんですねそうそうそうそういいなめっちゃいいですねこれね良かったんでおすすめですねそれなんか本当に1エピソードにできる気もしないでもないですけどまあなんかうまく回った後はうんいいですねちょっとやってみようかなマンネリ化したらそうねなんか1個本をテーマにして読むっていうのはね非常に良い体験でしたねうん良さそう選書が結構キモかもしれないでも今の感じだと

まあでもこの本外さなそうまあもちろんレベル感にもよりますけど確かに選書大事だなこれ選書大事ですよねその人が成長する本を選ばないといけないですからねそうそうそうそう確かにむずすぎても簡単すぎてもダメですねそうだから書店員のスキル書店員もね記述書選書してくれるわけじゃないですからね確かに確かにな

本好きエンジニアにしかできない作業かもしれないエンジニア育成技術書選書コンサルそうねだから会社にいる技術書に詳しい人からアドバイスもらいながらやるのがいいかもしれないですね確かにいやーむずいねまあでもやってみたいなありがとうございますちょっとやってみたいなと思いましたおすすめですはい

では最後にお知らせでハッシュタグひまじんプログラマーでSNSNEXTでフィードバック募集してますので本日の話の感想とかあとはおすすめの本とかありましたらSNSNEXTで共有お願いいたしますぜひお願いしますあとはポッドキャストの説明欄からGoogleフォームで番組の感想要望質問何でもお待ちしてますお気軽にお願いいたします定期的に読み上げていきますはいちょっと落ち着いてないんですけどお願いします見てはいますはい

あとはポッドキャスト説明欄じゃないや各種ポッドキャストプラットフォームでのフォロー高評価もお待ちしてますこちらもお願いしますじゃあお願いしますではのりさんありがとうございましたまた次回バイバイ

さあ皆さん次の商品は目玉商品ですこちらめちゃくちゃでかいエンターキーわー大きいこれがあるとストレス発散生産性アップ快適な睡眠もえ枕にしちゃうんですかこちらの商品はお値段など1024円わーお2の10乗

そして今番組終了1時間以内にGoogleフォームよりお便りを送った方はちっちゃいスペースキーも付いてきますポケットに入れて持ち運べますね番組の高評価フォローもすると会員割引なんと90%オフほぼただ今すぐご応募