自己紹介とバックグラウンド
ken
London Tech TalkのKen Wakatsumaです。本日はTidy First? Part IIIの振り返り収録をしていこうと思います。
じゃあ、今日ゲストにお呼びしているのは、London Tech Talk初めての出演になるんですが、Kojiさんです。
Kojiさん、よろしくお願いします。
Koji
よろしくお願いします。Kojiと言います。
そうですね。僕のまずは自己紹介から。
ぜひお願いします。
僕は現在、カナダのバンクーバーに住んでいて、仕事としてはソフトウェアエンジニアをしております。
一応、もともとは日本で、主に東京でなんですけど、7年ほどソフトウェアエンジニアとして新卒からずっと働いてきていて、
主には結構バックエンドメインで、Ruby on Railsとかそこら辺メインで仕事をしていて、
特にそんな深い理由はないんですけど、
30歳になる前、29歳の時って、人生このままでいいんだろうかみたいな、そういう悩みの時期ってあるじゃないですか。
ken
分かる分かる分かる。これから何を成したいんだろう、俺はみたいな。
Koji
というので、東京で7年ぐらいやってきて、東京でそこそこそれなりにエンジニアとしてやってきて、
一方でなんかすごいコンフォートゾーンにずっといるなみたいな、っていうところを感じて、
ガラッと環境を変えて、自分をもうちょっとコンフォートゾーンからちょっと抜け出したところでやってみようみたいなところで、
みたいなふわっとしたノリで、カナダのバンクーバーに来て住んでいますというところですね。
一応仕事は、今日本の仕事をリモートでやっていて、特に現地の企業で働いているというわけではないんですけど、
日本の仕事もやりつつ、こっちの現地の会社とかも就職活動とかもちょこちょこしているみたいな、
なんかそんな感じで今は過ごしております。
というところが、
ありがとうございます。
ざっくり、僕の自己紹介というか、そんな感じになっております。
技術スタックとコミュニティ
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
そのストーリーすごい好きですね。
僕も過去にCookpadも経験してるし、
今もShopifyだし、
ルビーを嫌いなわけがないということで、
僕もルビー大好きなんですけど、
やっぱり人によってルビーを好きになるストーリーとか、
バックグラウンドが違うので、
どのルビーストに聞いても、
温かい話とかいい話が聞けるので、
とても話していて心地よいんですが、
そんなルビーストのこじさんが、
今回Tidy Firstのブッククラブに
参加したいなと思ったきっかけを聞いてみたいんですけど、
論のテクトーク的にはブッククラブは3回目で、
こじさんは今回の3回目から参加してくださったんですけど、
まずTidy Firstという本自体への興味関心もそうだし、
このブッククラブに参加しようと思ってくれた、
経緯とかモチベーションとかあったら聞いてもいいですか?
Koji
そうですね。
まず、論のテクトークのブッククラブというところ自体に、
興味を持ってなぜ参加したかみたいなところで言いますと、
もともと論のテクトークを聞いていて、
特にDDIA界の話がすごい。
僕、DDIA本結構分厚いじゃないですか。
1人で読んでて辛くなってたんですけど、
論のテクトークのDDIA界を読んで、
そういうことだったんだみたいな。
本自体は自分で読んでるんだけど、
論のテクトークのDDIA界を聞くことで、
一緒に読んでる感みたいな。
すごい得られて。
結果、DDIA本結構読み進められたんですよ。
ken
嬉しいですね。
Koji
そう、そういう体験があったので、
そこからまず論のテクトークというポッドキャスト自体に興味を持って聞き始めて、
聞いていたら、どうやら今度はタイディーファーストっていう本で、
読書会開催するみたいなんだってなって、
これはもうこの波乗るしかないみたいな感じで、
勢いで。
ken
嬉しい。
Koji
僕も参加したいですっていうふうに連絡をさせていただきました。
ken
なるほどなるほど。
じゃあタイミングも良かったということですね。
Koji
そうですね。
っていうところが、なので論のテクトークのブッククラブ自体に参加したかったみたいな理由で、
もう一つ、そもそも今回のネタであるタイディーファーストっていう本自体にも興味があって、
何でしょうね、何でこの本に興味を持ったかっていうと、
ソフトウェアエンジニア界隈でリファクタリングって大事だよねって、
リファクタリングの重要性
Koji
ある種共通認識だと思うんですけど、
何でリファクタリングが大事なのかとかで、
リファクタリングって、
例えば日本だと技術不採とか言われるけど、
技術不採って何みたいなところってあんまり掘り下げられてるシーンとか、
そういう資料とかってあんまりないじゃないですか。
っていうところで、改めてリファクタリング、技術的不採とかそういうものに対して、
どうやって言語化してすればいいのか、
どうやって掘り下げてその中身を知ればいいのかみたいな、
知りたいみたいなところがあったので、
そのヒントとなりそうだ本だなっていうふうにちょっと感じたので、
そこもそうですね、すごい参加したかった大きな理由でしたね。
ken
なるほど、それすごいいいですね。
リファクタリングはいいよねってこうされてる、
いわゆる常識というか通念かな、常識というよりは通念というか、
その前提をきちんと疑ってみようみたいな問題意識が感じた。
そこにちょうどケント・ベックが書いたTidy Firstが割と新しめであって、
Book Clubもやるからじゃあこれは読んでみようかというタイミングが重なったということですかね。
Koji
そうですね、特にリファクタリングっていう概念自体が、
ソフトウェアエンジニアっていうスコープで見ると、
それはやったほうがいいよね、大事だよねってなると、
もっと本当に組織全体、会社全体とか、
それこそVizのメンバーの人たちと一緒にプロジェクト開発していくっていうのがあった時に、
リファクタリングそれは何ですか、なんでそれ今やる必要あるんですかっていうのを、
説明責任がソフトウェアエンジニアには多分僕はあるとは思っていて、
ken
そうですよね。
Koji
ってなった時に、そこちゃんと原稿化できないと、
組織としてリファクタリングをできにくいかなっていうのはすごい感じて、
自分のこれの経験すごいそこ結構苦労してきたので、
今後そういうリファクタリングとか直接顧客に価値を生まないけど、
でも長期的に見ると自分たちのビジネスをより柔軟に、
結局は価値を提供するために大事なものなので、
そこをちゃんとエンジニア以外にも伝えられるようになるための原則みたいなのを、
ちゃんと自分の中で持っておきたいっていうところはすごい、
これまでの経験としてすごいそういう気持ちが結構芽生えて持ってましたね。
チーム内での原則の共有
ken
多分そういうモチベーションを持って読んだっていう方、
結構今回のブッククラブでも多かった印象で、
僕もその機能開発をガリガリする部署にいたことも分かるんで、
その気持ちはすごい分かって、
結局ビジネスサイドの人から見ると、
例えばリファクタリングを無効3週間しますなときに、
機能開発が止まってしまうわけですよね。
それでユーザーに何の価値をその間出しているんですかって、
それはちょっとしたエンジニアリング的なサバティカルじゃないですけど、
コードをコロコロして遊んでるだけじゃないのか、
みたいな思われ方もされなくはないかもしれないですよね。
さっきちょっと苦労されたって言ってたけど、
それはやっぱり説明責任を果たさなきゃいけない場面で、
うまくリファクタリングの必要性を説明できずに、
機能開発でどんどんどんどんスパゲッティコードを作ってしまったりとか、
そういう場面に出くわしたということだったんですか。
Koji
そうですね、本当にそれもそうですし、
あとは、やっぱりエンジニアの採用みたいなところにも、
結構すごく大きくなるみたいなところがあると思っていて、
例えばですけど、本当に分かりやすい絵を言うと、
例えばフロントエンジニアを新たに新規に採用したいってなったときに、
じゃあフロントエンドエンジニアを募集しますと。
さすがに今の時代、リアクトとかVue.jsはもう使っていません。
もうJQueryでゴリゴリフロントエンドを開発するメンバー募集ってなったら、
ちょっときついじゃないですか。
さすがにとはいえ、技術だけでその会社を選ぶとか、
人よりかはもっとプロダクトに興味を持っている人が来てほしいという側面ももちろんあるんですけど、
一方でそれだけじゃなくて、さすがにプロダクトどんだけ魅力的でも、
技術部分があまりにもレガシーすぎると、やっぱり人の足を踏んでしまうっていうのは、
僕含めそういうソフトウェアエンジニアの人はやっぱり多いと思うので、
っていうところで採用のときに不利になりやすいかなというところ。
ken
そういう側面もあるかなとは思っていますね。
なぜリファクタリングを行うのか
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みたいな。
一番ケント・ベックの頭の中が見える部分みたいな感じで、
そこはやっぱりこの本の一番の面白いパートだったのかな、
ケント・ベックの考え方
Koji
みたいな個人的にはすごい思いましたね。
ken
そうですよね。
今後こじさんが経験したような、
例えばエンジニアとしてタイリング、リファクタリングの説明責任を
果たさなきゃいけない場面に今後会ったときには、
僕個人としてはケント・ベックの考え方を借りながら、
ケント・ベックと一緒に考える感じで、
次は迎えそうだなみたいな、
答えは書いてないけど、
一緒に考えてくれる仲間ができたんじゃないかな、
この本を読むことで、みたいなテイクアウェイでしたね。
Koji
そうですね。
あと結構太字とかではないんですけど、
随所にすごい印象に残る文を書いているな、
みたいなすごい感じでいて、
例えばですけど、
パート3、ソフトウェア設計とはみたいな話が一部あったと思うんですけど、
彼は、確かAMとしてはソフトウェアデザイン is an exercise
of human relationship みたいな、
要はソフトウェア設計というのは人間関係なんだ、
みたいなことを何か言っていて、
なるほど、確かにその視点、意外とあんまり研究されてなかったけど、
全然それ思い当たるわ、みたいなのを、
すごいクサッと来て、
そうですね。
そことかあとは、
もうちょっと、
なので人間関係、ソフトウェア設計は人間関係だから、
例えばViz側と、
なんでこの設計にしたらビジネス的に良くなるのか、
インパクトがあるのか、みたいな、
多分そういう文脈の話で、
多分そういうことだったり、
っていうところで、
本当にツイッショツイッショで、
なんとなく、
人は一人歩きしているような言葉、
ソフトウェア設計、ソフトウェアデザイン、
みたいな、でもそれとは何ずや、みたいなところを、
ケントペックがそこでバシッと言語化してくれて、
彼なりの観点で言語化してくれてたりとか、
あと他にも、
ソフトウェアがもたらす価値って何、みたいな、
そういう文章もどこかあったんですけど、
それも確かに、
ソフトウェアの価値って何だろうって、
パッと自分に聞かれたら、
え?ってちょっと、
僕が読む前になってたんですけど、
でもこの本、ケントペックが言っているのは、
今提供している現在の機能と、
あとはなんだっけな、
新しく、
明日以降できる新しいことを、
新しく何かができる選択肢を持つことだ、みたいな。
ken
オプションを持つことだ、みたいなところですかね。
Koji
で、その2つがソフトウェアの価値なんだって、
結構断言っぽい感じで言ってたので、
そこも、
彼はそういうふうに、
ソフトウェアの価値っていう、
ある種の普遍的だけど、
あんまり意外と言語化されてないものを、
バシッと言っててくれてたりしてたので、
そこはすごい印象深かったですかね。
ken
印象深かったですよね。
名言が散りばめられていて、
その1つ目に言及されてたのも、
たぶん27チャプターあたりで、
ソフトウェアデザイン is an exercise in human relationships、
みたいに書かれていて、
これを他の参加者の方も刺さったみたいな感じで、
賛成するっていうふうに言及されてましたね。
結構ブッククラブの中で、
具体的なユースケースとしてあったのは、
例えばスタッフエンジニアみたいな人が、
ジュニアエンジニアに対してレビューするときとかに、
単純にレビューするだけじゃなくて、
メンタリングとか、
コーチング的な観点を入れながら、
技術的視点を与えてレビューしてあげることで、
例えばそれをレビュー受けた人は、
それをただ言われた通りに直すだけじゃなくて、
難しい問題にあたったときに、
どういうふうにプログラムソービングしていくのか、
みたいな、
もうちょっとメタ的なスキルを養いながら、
チームで成長していけるみたいなところに、
ソフトウェアデザインに対するチームのアプローチも使えるよ、
みたいなコメントをしてくれる人がいて、
それは確かになと僕も思いましたし、
結構刺さった言葉を、
結構ブッククラブの皆さん書いてくれてるんですよね。
この一文が刺さりました、みたいな。
結構アナロジーもあったり、ユーマーもあったり、
僕もすごい好きなんですけど、
例えば、僕もう一つあげるな、
例えば、
most important、
これはとある参加者が書いてくれてるんだけど、
most important is you.
Will tidings bring peace, satisfaction, and joy to your programming?
みたいな、最終的には自分自身がどう感じるかが重要だよね、みたいな。
なんかそういうことを言っていて、
本当にいろんな人に刺さるポイントは違うけど、
何かしら刺さる本なんじゃないかと、
僕は本当に思いましたね。
人間関係の重要性
ken
で、最後のオプションの話しましたよね。
ここのオプションちょっと深掘りしたくて、
パート3では、
チャプターが結構10項前後ありましたけれども、
この一つ大きい、
個人的に大きいと思っているやつが、
オプション理論とソフトウェア設計のアナロジーを
バーンと持ってきたところだと思うんですよね。
これはチャプター的には、
チャプター24号あたりから動線を張って、
チャプター26でオプション、
チャプター27でオプションVSキャッシュフローみたいな感じで、
本当に金融工学ベースの話をしてますと。
いわゆるオプションですよね、
ソフトウェアを将来、
どんなビジネス要求があっても変更していけるような
オプション理論の応用
ken
選択肢を持っておくためにタイリングが必要だ
ということを彼は多分言いたくて、
そこにために結構金融工学のバックグラウンドとか、
いろいろDCFOになるものであったりとか、
オプション理論になるものを頑張って説明してるんですけど、
そこに関しては小路さん目線で、
どう感じ取ったのかなって聞いてみたくて、
納得なのか、よくわからなかったのか、
オプション理論とアナロジーに関しては、
何か研究したいことありますか?
Koji
ここはそうですね、
参加者の中でもちょっと賛否分かれるというか、
僕も正直ここは、
ちょっと1回読んだだけだと、
あまり意図をキャッチアップできなくて、
ここで言ってるオプションっていうのは、
金融工学でオプションなのかみたいな、
そもそも金融工学とかがちょっと頭にバックグラウンド性あると、
そっちの混乱もあったし、
っていうところで、
割と何でしょうね、
難しかったですかね、やっぱり。
難しかったですよね。
ただ、最初にソフトウェアの価値ってなんだ、
みたいなところで、
ゲットベックが選択肢を持つことだみたいな、
そこも結構そうだよな、
選択肢があることによって、
例えば本当に具体的には、
あるプロダクトのある機能を、
ちょっと要件が変わったので、
機能の使用変更も必要ですなときに、
その使用変更するコストを、
低コストで変更できるための選択肢を持つっていうのは、
それはすごい大事だし、
そのためになるのでタイリングをやるっていうのは、
そこはしっくりきてますと。
なんだけど、
それをさらに何でしょうかね、
それこそもっとビジネス側の人たちとか、
ステークホルダーとかに説明するときに、
多分それだけだと足りなかったのかなっていうふうに、
もしかして、
ケントベックはそこにさらに、
それだけじゃ足りないから、
なのでこういう、
金融工学的なオプション理論とか、
キャッシュフローの話を、
ちょっとアナロジーとして持ってきたのかなっていう、
そこは完全に想像ですけど、
自分はそういうふうに、
ジャスリしたというか。
ken
確かに。
僕も多分似たようにジャスリしたんですよ。
多分オプション理論のアナロジーを理解するのに、
多分2つの壁があると思っていて、
まず1つの壁が、
金融工学のバックグラウンドが少しでもないと、
いきなりなんか飛び石が飛んできたみたいな感じで、
こいつ何言ってるんだって感じまずなると思うんですよね。
いきなりDCFみたいなの出てきたりとか、
これはまず何みたいなウィキペディアで見るとこから始まると思うんですけど、
それウィキペディアを読んでる間に多分思考がストップしてしまったりとかね。
それが分かったとして、
第2の壁っていうのが、
これも僕のジャスリなんですけど、小路さんと似たような感じで、
想定読書が違うんじゃないかなって思ったんですよ。
ケント・ベックは結構、
もうかなりシニア側で、
いろんな会社のコンサルティングとか、
たまたま僕のメンターが働いてる会社に、
月にぐらいで来てるみたいなこともあったので、
結構上のレイヤーの人と話をすることが多いっていうのは、
事実としては聞いているんだけれども、なので、
普段接する人が現場のICよりは、
経営層とか上の意思決定をする人たちだと思うんですよね。
多分そういう人たちに、ケント・ベック自身の仕事である
ソフトウェアやアーキテクトとかリファクタリングが、
やっていく必要があるよっていうのを彼らを説得するためには、
多分、彼らの言葉で話す必要があり、
それがおそらく経済学とか金融工学とか、
そういったところになってくるから、
ケント・ベックがそういう人々と話していく中で、
結構身につけた彼なりの説得材料がこの路線で、
それを、でも一エンジニアが読むと想定されている
オラエリの方でバーンと出しちゃったから、
Koji
一部混乱が生じたんじゃないかなというのが僕の邪推です。
そうですね。
でも、今のケンさんの話を聞いて、
ちょっと思ったのは、結構本当にシニアの、
それこそスタッフ以上とかの結構経営層と関わる、
エンジニアリングのバックグラウンド、
あるいはエンジニアの人たちみたいな、
人に向けてみたいな話っぽいっていうのは、
すごい僕もそういうふうに思って、
あともう一歩あるのは、本当にそれこそスタートアップの、
Koji
創業に近いエンジニアメンバーとか、
そういう人たちとかも読むと、
これは結構刺さる、
あるいは今後自分で企業とか創業とかで、
立ち上げたいみたいな気持ちを持っているエンジニアとかは、
結構この章を読んでおくと、
後々生きてくるのかなってちょっと思ったりもしていて、
例えば今回このパート3のオプションっていうのは、
オプション理論とスタートアップ
Koji
結構金融工学におけるオプション理論のオプションを指していて、
ここで言ったオプションっていうのは、
オプション、タイリング、
後片付けをするっていうオプションを、
別に絶対後片付けしなきゃいけないってものじゃなくて、
してもいいし、しなくてもいいっていう、
後片付けの選択肢なんで、
そのアナロジーっていうのは、
例えばスタートアップの、
本当に創業のエンジニアがこの機能を作るにあたっては、
今ある既存のこの機能がどうしてもボトルネックになっているから、
まずこの既存機能を何とかしなきゃいけないですっていうのを、
例えばそれこそ信用とか、
それこそよりファイナンス部分に近しいCFOとかに、
そういう意思決定を見てもらう合意を取るために、
多分こういう話を持っていくと、
なるほどねみたいな風にちょっとなりやすいのかなっていうのは、
ちょっとイメージ、想像できましたね。
ken
なるほど、確かにその通りですね。
スタートアップの初期のメンバーとか経営層とかにも、
確かにこういう話し方、選択肢があることで、
市場動向とか競合が実装してくる機能に変化があっても、
素早く動けるよっていうのは、
本当にその小回りが利くスタートアップに大事な特性の一つというか、
動き方の一つだと思うので、
それは本当におっしゃる通りだなと思いましたね。
カップリングとリファクタリング
ken
きっと多分そういうスタートアップ界隈にもアドバイスをすることも多いんだろうから、
そうなのかもしれないですね。
Koji
なるほどね。
ken
いや、なんかそのパート3、他になんかそのこじさん的にこう、
引っかかったり気になってるものがあるかなというのを聞いてみたくて、
結構チャプターで言うとそうですね、
チャプター29あたりでカップリングみたいなところで話をしてたりとか、
チャプター32ではコヒージョンみたいな話もしてたりしますけれども、
どうですか?
三つ結合云々みたいなのは結構日本語の文脈でも、
いろいろみんなオピニオネイティットに話してたりしますけど、
こじさん的に何かもう一つぐらい気になってるトピックとか、
引っかかったところとかあったりしますか?
Koji
そうですね。
なんかカップリングとか、あそこら辺の話は、
なんか最初読んだ時は、
要はこれはなんかの結合度、予習度の話なのかなみたいな、
なんかよく言われるやつなのかなみたいな、
なんか最初はそういう、
最初に読んだ時はそういう印象で、
で、何ですかね、
まあ、そうなんだけど、
なんか、えっと、
ただなんか結合度と予習度って、
この本はちゃんとそこを、
なんかそれぞれ分離、独立して語らずに、
ちゃんとなんかそれぞれが、
まあなんか結び、
まあ本当によくこのクロスなの図があったと思うんですけど、
なんかその結合度と予習度、
まあそれぞれ結合度を減らそうとかあるけど、
まあでもそれは切っては離せないから、
完全に結合をなくすっていうのはできないよとか、
なんかそういうところは何ですかね、
なんか正直ここは結構自分は難しくて、
あんまりそこ深く理解できてないんですけど、
まあなんか、
単に結合度減らしましょう、
凝集させよう、ましょう、以上じゃなくて、
ちゃんとそこに、
彼自身のこれまでの実体験をもとに、
例えばなんだろうな、
えっと、
まああれか、
結合度はどうしてもなくせないし、
なんかそれをなくそうとすると逆に、
なんかその結合をなくそうとするコストが、
逆にそのなんだろう、
ken
上回ってしまうというか、
Koji
上回ってしまうみたいな、
要はコスパが良くないよみたいな、
そういう話があったりして、
それをちゃんとなんかこういう図とかで、
こういう図じゃなくて、
なんですかね、
ken
なんていうんですか、
Koji
あれなんだったっけな、
ken
曲線というか、
Koji
ベルカーブみたいなやつですかね、
そうですね、ベルカーブが交差してるような、
図で表現をしている、
というところで、
そこもなんかより彼なりに掘り下げて、
書籍としてそこに書かれているなというのは、
感じましたかね、
ken
そうですね、
なんかカップリングのところで、
結構個人的に面白かったのは、
彼の主張、いくつか主張ある中の一つで、
カップリングソフトウェアのコストっていうのは、
ソフトウェアの変更のコストとほぼ同時ですと、
ソフトウェアの変更のコストっていうのは、
大きなリライト、大きな変更のコストともほぼ同時ですと、
その大きな変更のコストというのは、
カップリングとほぼ同時です、
なので三段論法というか四段論法的に、
ソフトウェアのコストを下げるためには、
カップリングを減らす必要もあるよ、
みたいなことも言ってたりして、
結構カップリングの章がオプションリルなどって、
実務への応用
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回目のみたいなのが僕はあったので、
本当に良かったです。
彼にも関心ですね。
はい。
ちょっとなんか引き続きね、面白い本があったら定期的に、不定期にやっていこうと思っていて、
なんかその、週間付けでやってるというより面白い本とかがあったりしたら、
なんかその時に興味がある人が集まってっていう感じののをやりたいなと思ってるので、
突発的に多分またアナウンスすると思うんですけど、
その時に読みたい本だったらぜひまた参加してください。
アサイメソッドと新しい試み
Koji
はい、ぜひぜひ。
ken
はい、ということで、じゃあ今日はね、コジさんに参加していただいて、
タイリーファースト、ケント・ベックが書いた本のパート3の振り返り収録をしました。
コジさん、初のゲスト出演参加ありがとうございます。
ちょっとね、今度はブッククラブ関係ない話でぜひ雑談しに来てください。
Koji
ぜひぜひ。
はい、ありがとうございます。
ken
はい、本当にありがとうございました。
Koji
とても楽しかったです。
お会いしまーす。ありがとうございます。
