ken
Koji
{openStarringSelector = false;})"
wire:loading.class.remove="cursor-pointer"
wire:loading.class="cursor-wait"
aria-label="Relate starring">
ken
{openStarringSelector = false;})"
wire:loading.class.remove="cursor-pointer"
wire:loading.class="cursor-wait"
aria-label="Relate starring">
Koji
ken
いやー、コンフォートゾーン抜け出すいいですね。僕も大好きなので。
コンフォートゾーン抜け出したいっていう、抜け出した時の気持ちよさが快感というか。
Koji
そうですね。
ken
でもそれでね、いきなりカナダに行くっていうのはね、またなんかすごいかっこいいムーブだなと思いますけど。
Koji
でもそこはなんか、一方でそういうちょっと感情的な部分で行動したのと、
一方でもうちょっと合理的な部分で、
カナダとかだと、何でしょうね。
なんか日本人のエンジニアテックコミュニティとか、
ケンさんとか多分ご存知だと思うんですけど、
フロックとかみたいなコミュニティとかもあったりもするし、
なんだかんだ言って、日本、アジアから出やすい英語圏の国って限られてるじゃないですか。
ken
確かにそうですね。
はい。
Koji
っていうところで、いろいろそう、
それこそヨーロッパ、ドイツとか僕個人的好きなんで、
いろいろなんか比較検討した上で、
でも一旦カナダかなみたいな。
確かに確かに。
はい。
ken
いやーいいですね。
実はコジさん、今回パート3に呼んだ理由みたいなの後で話せたらと思うんですけど、
なんか今回ブッククラブに参加してくれた後で、
ロンドンテックトークのブッククラブに参加しましたみたいなの、
ブログ記事を書いてくださって、
note.comで。
それで初めてコジさんのnoteアカウント知って、
ちょっと昔の記事も拝見させてもらったんですけど、
なんか日本にね、結構ソフトエンジニアとして滞在されてて、
なんかすごい活躍されてたみたいで、
なんか技術賞も出したりとか、
なんか結構。
Koji
おお、そんなところまで。
ken
そうです。
手も書かれてたので見たんですけど、
なんか当時はレール全を中心とした、
フルスタックとかバックエンドエンジニアっていう、
その技術スタックとしてはそこら辺が強みだったんですか?
Koji
あ、そうですね。
本当にバックエンドはRuby on Railsメインで、
っていうところと、
あとはALabsでインフラを設計とか構築したりとかで、
たまにフロントエンドはそんなに得意じゃなくて、
なんですけど、
まぁ一応フロントエンドもVue.jsとかでやってたり、
今の仕事はReactとかもちょっとやったりするんですけど、
基本的にはそうですね。
バックエンド寄りのフルスタックエンジニアみたいな感じで、
やらせてもらっていましたね。
ken
なんか雰囲気わかりますね。
僕も2社目がすごい4人ぐらいのスタートアップで、
なんかそんな感じだったんですよ。
Railsのアプリケーション作りながら、
時々インフラも見て、
時々Reactも書いてみたいな感じだったので。
じゃあこいさんインフラも触られることがある。
AWSが中心多いですか?
そうですね。
Koji
それこそ僕がその2社目の会社とかが本当に、
割と規模が小さい会社で、
で、インフラとかももう自分とかがちょっと、
なんでしょう、巻き取って、
なんかこう行った方がいいなみたいな、
そういう感じの環境だったので、
自然となんかそっちの方もやるようになって、
っていう、そうですね。
はい。
ken
なんかじゃあ好きな技術って何ですかって聞いてみたくて、
全然これタイディファース関係ないちょっと話なんですけど、
会社の会社だったかな?
でも輪読会をされてして、
確かオブザーバビリティエンジニア役読んでる、
みたいな話もされてたりとか、
結構その読書ノートも、
バックエンドエンジニアリング的な視点もそうだし、
たまにインフラもちょっと書かれていて、
なんかいろいろすごいされてるなという印象なんですけど、
なんか最近気になってるという文脈でもいいし、
自分のキャリアでコアとなってるみたいな観点でもいいんだけど、
なんか好きな技術一つあげるとしたら何かなと。
Koji
そうですね。
でもなんかすごい、
いや、ちょっと面白いですもんね。
いいですね。
結構そうですね、
いろいろ右往左往あったんですけど、
なんかなんだかんだで、
やっぱり僕はルビーストだなというか、
ルビーが好きだなっていうのは、
なんだかんだってルビーだなっていうところですね。
ken
なるほど。
それどんなところで感じたのかなと聞いてみたいんですけど、
最初に始めた言語がもしかしてルビーとかですか?
Koji
いや、実は僕最初に本当にプログラミング初めて触った言語はPythonだったんですよ。
ken
そうなんだ。
Koji
大学時代、僕が大学金融系とかを学んでいて、
ちょっとそこの関係でPythonとかをやってたんですけど、
なのでPythonから入り、
その後に大学の時にIOSアプリ開発のアルバイトをしていて、
なのでObjective-C Suisseとか、
ちょうどSuisseが出てきた当初とかだったんで、
PythonからIOS系のSuisseとObjective-C入って、
その就職した診察の会社でアプリ、
IOS開発とかではなくルビーっていう、
なのでルビー自体は3番目に触り始めた言語ですかね。
ken
それからやっぱりいろんな言語経験されてると思うけど、
ルビーのAPIとか書き心地とかが好きっていう感じですか?
ルビーのコミュニティとか。
Koji
そうですね、本当に言語自体書きやすいというのもそうですし、
やっぱりルビー会議中心としたコミュニティがすごい。
間違いない。
なんか賑わってるし、みんな個性があるし、
何より温かいみんな。
ken
分かる。
Koji
ウェルカムな、ウェルカミングな感じ。
ken
はい、そうですね。
Koji
そうですね、あとはそうですね、
やっぱり僕診察で入った会社が、
ルビーの作者の、ルビーのパパのマッツ、
松本幸寛さんが技術顧問でいたっていう会社だったんですけど、
なので結構それこそ月一とかで、
マッツとシマネからリモートで繋いで、
本当にルビーについてあれこれ、
なんでリファイ、ルビーのリファイメントとかあれ、
なんでこれ実装したんですか、その経緯何なんですか、
直接本人に聞けたりみたいな。
そういう機会があったので、
なんかまあ本当に、
なんかよりこうやっぱ、
作ってる中の人の実際に対面して、
それで話してみたいな、
そういうのができる言語じゃないですか、
ルビーって日本生まれのプログラミング言語なんで。
っていう結構そういうエモーショナルな部分で、
すごい好きになったっていうところですかね。
ken
なるほど。その観点はちょっと忘れてましたね、すっかり。
確かにそのリクルーティングとか、自分がそのジョブにアプライする側のときもそうですけど、
結構エンジニアから技術ブログとかが出ていて、技術財をこういうふうに返していますみたいなアピールがあったりとか、
あとそのジョブディスクリプションの中で、割とその先進的なテクノロジーをきちんと使っていたりチャレンジしているみたいなのが出ると、
アプライする側からしてもすごい魅力的にも映るし、
技術的財をちゃんと返せるチーム体制だし、それを理解されている文化なんだなっていうのは大きな暮らしになりますもんね。
そうですね。
本当にその、なかなかこう答えは出せない問いだと思うんですけど、
ちょっとパート2の内容に入る前に、じゃあその、もともと抱えてたこじさんの問いは、この本を読んで答えが分かりましたか?
Koji
説明責任を果たすみたいな。
それで言うと、本当にあの、何でしょうね、こうすればいいみたいな、なんかメソッド、なんかハウトゥーみたいなものは正直使ってはいないですと。
で、僕はでもそこに関しては最初からそれでいいと思っていて、
なぜなら、なんかそういうハウトゥーとか具体的なメソッドって賞味期限が短いと思うんですよね。
賞味期限も短いし、なんかあの、
まあそれってじゃあ自分たちの今働いてる職場とか組織とかでワークするのかってなったら、
そこまで具体的に落とし込められてると、ちょっと自分たちのとこには適応しづらいみたいなって結構あると思うんですけど、
この本がなんかすごい、僕としての期待値としても良かったのが、やっぱり原則みたいなところに留めてたのが、
なんかそこは意図的なのか分かんないですけど、
なんかそこを留めてたのが良かったのかなっていう、
まあなんかその原則エッセンシャルをもとに、じゃあなんか、
実際の自分たちの今の環境とかでの特有のところをそこに混ぜ込んで、
でなんか自分たちのチームとか環境でうまくワークしそうなものに消化するみたいな、
なんかそういう風に最終的になればいいかなと思ってたんで、
でもそもそもそこまで消化するには原則をそもそも知ってないと、理解してないと、
まあそもそも足場がないみたいな状態なので、
ken
そうですよね。
Koji
まあそういう意味ではなんか自分の中でそのリファクタリング、タイリングみたいなところの、
なんか足場作りが自分の頭の中でなんかできたかなとはすごい思いましたね。
ken
いや今の話、僕がこの本を読んで感動したエッセンスがきれいに言語化されていたなと思っていて、
その多分大事なポイントが多分3つあって、
まず1つはいわゆるその表面的なアドバイス、
ハウツーみたいなものっていうのは賞味期限も短いですし、
やっぱりその間違ったところに適応してしまいがちなんですよね、
特にまあ結構ジュニアエンジニアとかそのユースケースとかを理解せずに、
間違ったところにハウツーを当てはめても効果がないし、
場合によっては逆効果だったりするから、
その結構表面的なアドバイスに閉じていない。
じゃあそれで何が必要だかっていうと、
1つ目大事なこととしても原則っていう言葉を挙げてくれましたけど、
原則って言葉は僕的にもすごいしっくりきたんですけど、
そのソフトウェアのリアーキテクトとか設計ということに関しても、
ケントベックはもうずっとキャリアを掲げて考えてきた人じゃないですか、
もうプロというか。
そのキャリアの中で磨き上げた彼なりの原則っていうのが、
多分僕も本当に意図的だと思うんですけど、
そのハウツー本、賞味期限の短いけれども売れるようなハウツー本に流れずに、
ちゃんとその原則を時々くどい、
時々わかりづらい英語もあったかもしれないんだけど、
それで説明するところに逃げずにそこやってたっていうの、
僕もすごいよかったですし、
やっぱりそれがあるからこそ、
なんか哲学的な感じだと思うんですよね。
僕の言葉で言うとその3つ目の観点というのは、
いろんなリファクタリングに関しての本はあると思うんですけども、
なんかそれこそ、
僕はこの本を読んでこう受け取ったけれども、
例えばじゃあ小路さんはどう受け取ったんだろうとか、
前回も出てくれた篠さんはどう受け取ってくれたんだろうとか、
他に参加者がいる中で、
多分受け取り方ってその人のそれまでの経験とか、
今いる状況で全然違うと思うので、
それを多分そのDDIAとはまた違う感じで
ブッククラブしたら面白いんじゃないかなって思ったのが結構あったんですよね。
DDIAは結構難しくて分厚い本をみんなで頑張って読もうみたいなコンセプト。
で、タイリーファースすごい薄かったじゃないですか。
Koji
そうですね。文量としては。
ken
読むのはそんな難しくないですよね。
だけど多分その咀嚼するところがすごく難しいというか、
いろんな解釈があったから、
いろんな人と読みたいなと思ってたんですよね。
だからもうすごい同意ですね。
で、その多様性を考えたときに、
今回小路さんが入ってくれてパート3お呼びしたんですけど、
パート3の感想どうでしたかというのを聞いてみたくて、
ちょっと簡単に振り返ると、
パート1は明日から使えるようなメソッドがつらつらと書いてあって、
パート2のマネジングのところでは、
じゃあリファクタリングはするべきだよねみたいな、
タイリングはするべきだよねという前提に立った上で、
じゃあいつするの、明日するの、マッチしないという選択肢を取るのとか、
そのやり方ですよね。
ストラクチャーとビヘイビュアルに分けてみようとか、
バッチングしてみようとか、
そういったメソッドが書かれていたと。
そこからパート3は結構個人的にはガラッと色が変わったところじゃないかなと思っていて、
新しいコンセプトとか彼なりの哲学が結構どんどんどんどん出てきた、
一番面白い章だったかと思うんですけど、
こじさん的にパート3全体の印象というのを伺ってもいいですか?
Koji
そうですね。
今けんさんがおっしゃった通り、
パート1が結構明日から使えるメソッド集みたいな感じで、
パート2が本当にじゃあどうやってやる、
どうやってやる、howみたいな部分で、
パート3は何でやるのか、whyみたいな。
一番ケント・ベックの頭の中が見える部分みたいな感じで、
そこはやっぱりこの本の一番の面白いパートだったのかな、
ken
ビッて入ってきてますけど、
要するに彼はカップリングに対していろいろ思いがあって、
証明というか説得するために、
この章を割いてるんだなというのがあって、
個人的にも先に結論を書いてくれたほうが、
多分分かりやすく読めたなというのがありますね。
Koji
個人的にはオプションの話からカップリングのところに、
ちょっと僕はそこに結びつきが、
あんまりちょっとキャッチアップできなかった、
っていうのはちょっとあったので、
あんまり今理解も覚え過ぎてないとかはありますしね。
ken
ここ書いてる内容ちょっとよく分かんないよね、
とか違いはないみたいなのを、
みんなで言い合えていたのが良かったなと思います。
個人的にも一人で最初読んだときは、
ケントベック様が書いてるものなんで、
もう僕からするときっと正しいこと書いてるだろう、
とか思っちゃうけど、
全然そんなことはなかったりすると思うので、
集合地で読めたっていうのがすごい良かったかなと思います。
そうですね。
Koji
でも結合度のところで、
なるほどなと思ったのは、
僕みたいに普段コードを書いてる人間が認識する結合度って、
あるクラスとかモジュールがすごい巨大になって、
いわゆる単一責任の原則が守られてないようなクラスになっちゃってるみたいな、
そういう観点で結合度を認識してたんですけど、
でもこの本だともうちょっと広い枠での結合度も語っていましたよね。
例えば、そういう実装ベースの結合度だけじゃなくて、
もうちょっとシステムの機能、
システム機能間の結合度とか、
さらに引いてはもうちょっとアーキテクチャレベルの結合度みたいな、
そういう話もあったりして、
そこに関してはTidy Firstを読んでから、
結合度っていうものに対する解像度は上がったかなとは思いましたね。
ken
確かに確かに。
複雑なマイクロサービスアーキテクチャとかコンプレックスなシステムにおける、
ネットワークや通信とかシステム同士のインターコミュニケーションとか、
確かにクラスレベルとか実装レベルだけではなく、
いろんなところでカップリングで語れるよねっていうのは、
新しい視点をもたらしてくれたんじゃないかなみたいなところは同意ですね。
どうですか、一通り1回読んでみたけど、
消化できましたか、Tidy First。
Koji
そうですね。
読む前よりかは確実に、
まずリファクタリングっていうものから一段下り下げて、
もうちょっとタイリングっていう小さい単位でありますよみたいな、
っていうところを、
そこは明日から実践できそうなところかなと思いますね。
じゃあタイリングみたいな、タイリング的なニュアンスのプレリクエストを出す時も、
ちゃんとストラクチャーとビヘイビアで分けてみたいな、
そことかは読む前とかだと多分、
割とそれなりの規模のリファクタリングPRみたいな、
結構やりがちとか、
あるいはさすがにプレリクエストの量は抑えるけど、
でもやっぱりストラクチャーの変更と、
ビヘイビアの変更がごちゃ混ぜになった状態でPR出しちゃったりみたいな、
そういうのは自分の中でタイリングファーストを読んでいくことで、
ブレーキが効くようになった、
ブレーキを手に入れたみたいなところはあるかもしれないですね。
ken
ブレーキを手に入れた、いいですね。
かっこいい。
何か武器を手に入れたみたいな感じで。
Koji
そうですね、そこはすごい。
そこはデベロップメントチームのスコープで、
多分使えるエッセンスなのかなという気がしますね。
それはさらにもっとタイリングっていうのをやる必要が、
例えばスプリントとかで回してて、
プロタクトマネージャーとかに、
ちょっとそういうタイリング系のタスクをやる必要があります、
やりたいとしたときに、
そこは本当にパート3の内容が生きていく。
説明責任みたいなところで生きていくのかなという気はしました。
ken
本を読んだ後の現場への生かし方とか、
ネクストアクションまで見えてて、
さすが綺麗なまとめだなと思いました。
やっぱ本を読んで、
テイクアウェイまで出すっていうところが大事なと、
僕も個人的に思うので、
読んで終わりじゃなくて、
ブログに書くでもいいですし、
コジさんもローノテクトークのブックラブ参加したブログ書いてくれましたけど、
そうじゃなくても、
例えば現場にどう生かすかを考えたりとか、
明日これを読んで何するかってなって、
初めてナレッジがスキルに昇華していくと思うので、
僕は個人的にはネクストアクションがそこまできれいに出せなかったので、
それはちょっと考えなきゃいけないところではあるんですけど、
すごい参考になりました。
ありがとうございます。
Koji
こちらこそありがとうございます。
ken
パート3、一緒に読めてよかったです。
最後に、パート3言い残したことでもいいし、
初めて今回ロンドステクトークのブッククラブに参加してくれた、
雑な全体的な感想でもいいし、
次読んでみたい本でもいいし、
次のアクションみたいなところを最後に一言いただいてクロージングしようかなと思いますが、
聞いてもいいですか?
Koji
そうですね、まずは本当に、
これはもうブッククラブ全般に言えることなんですけど、
一人で読むよりか、
みんなで読んで、その内容をみんなで議論するっていうことで、
よりその本の内容が理解できるっていうのは、
これは本当にブッククラブのすごい素晴らしい点だなって思いますね。
なので、それの点ですごい参加してよかったっていうのと、
あと、これはちょっと何かやってみて、
事前に予期してなかったけど、やってみて分かった新たな発見みたいなところなんですけど、
ken
何ですか何ですか?
Koji
僕はこのタイリーファーストっていう本と同時で、
別の本を読んでいて、
リファクタリング系の?
そうですね、リファクタリング、
なんかより人間が理解しやすいコード?
リーダブルコード?
クリーン?
何だっけな、最近の本なんですけど、
わかんないかも。
ロンドンテックトークのディスコードチャンネルにも何か上げてた、
ちょっと待ってね、タイトル忘れちゃった。
ken
最近出された日本語の本かな?
Koji
あれだ、脳に収まるコードの書き方っていう本があって、
ken
あれも同時英語で読まれてたんですね。
Koji
読んでたんですけど、
別の本の内容もタイリーファースト観点で見た時に、
なるほど、みたいな、
何ですかね、予期しない驚きみたいなところもありましたね。
ken
なるほど、そっか。
それはじゃあ他の本と並行して読むからこそのメリットですね。
Koji
そうですね。
ken
はいはい。
Koji
っていうところらしいですかね。
あとは本当にこのロンドンテックトークブッククラブ特有のところだと、
やっぱりみんないろんな国とか町に住んでる人が参加してるし、
みんな、僕も含めみんな結構やってることが、
同じソフトウェアエンジニアっていうところですけど、
結構その中でもちょっとロールが違ったりみたいなところで、
例えば僕みたいに結構機能開発よりのアプリケーション開発エンジニア観点だとこうだけど、
例えばケンさんとか他の参加者の方みたいに、
サイトリアラビリティエンジニアリングとかをやってて、
そっちの観点だとこう見えるよねってか、
あとは他にもモバイル開発のエンジニアの方とかだとこういう意見みたいなので、
なんかそういう、なんか異なるロールから見ると、
あ、こういう意見もあるんだみたいな。
そこが発見でしたね。
ken
いやもう、それがもう僕がブッククラブやって自分が感じてるメリットの一番だったりするので、
本当に参加してくれてありがとうございます。
新しいね、やっぱ参加者がいてくれると観点も全然フレッシュになるので、
もうなんかこうポッドキャストのためにブッククラブやってるっていうよりは、
ブッククラブのためにポッドキャストやってるってもう過言ではないので最近。
ブッククラブの方が多分メインとなってきてるので。
昔はね冗談で、
なんだっけ、ポッドキャストの仮面をかぶったブッククラブだみたいに言ってたけど、
もう最近本当にそんな感じになってきてるので、
それはちょっと個人的にはいいね。
Koji
いやでも本当にこれはなんかすごい良い試みで、
なんか今後もまたあれば参加したいなと。
特にロンドンテックとかの元ホストのアサイさんのアサイメソッドでしたっけ。
なんかそのブッククラブの場でみんなで読み合うじゃなくて、
事前に読んだ上でその内容をブッククラブの場でみんなで発表して議論するみたいな。
このアサイメソッドは本当にもっと世のブッククラブ界隈で徹底してやった方がいいんじゃないかみたいな。
それこそ今の僕の働いてる職場でアサイメソッドをちょっと使わせてもらって、
別の本で臨特会してすごい把握したんで、
ちょっとアサイメソッド流ブッククラブ術みたいな、
なんかそういう会があってもいいんじゃないかみたいな。
なんか本でそう。
そうですね、そういう帯をつけて。
ken
アサイ氏推薦みたいな。
そうです。
本当にもう彼が作ってくれたファウンデーションがあってからこその3回目のみたいなのが僕はあったので、
本当に良かったです。
彼にも関心ですね。
はい。
ちょっとなんか引き続きね、面白い本があったら定期的に、不定期にやっていこうと思っていて、
なんかその、週間付けでやってるというより面白い本とかがあったりしたら、
なんかその時に興味がある人が集まってっていう感じののをやりたいなと思ってるので、
突発的に多分またアナウンスすると思うんですけど、
その時に読みたい本だったらぜひまた参加してください。