タイディーファーストの紹介
こんにちは、エンジニアの博多家です。
こんにちは、エンジニアの三田です。
ゆるテクは、三田と博多家が緩く技術の話をするポッドキャストです。よろしくお願いします。
よろしくお願いします。
はい、あけましておめでとうございます。
あけましておめでとうございます。
世間のポッドキャストは、年が明ける前に2025年の一発目を撮ることが多いと聞きますが。
なんだって?
我々は普通に年が明けてからこれを撮っております。
はい。
はい、2025年もよろしくお願いします。
よろしくお願いいたします。
はい、で、今日のネタですが。
はい。
これね、今日なんか私がホストのようになってますけど。
うん。
あの、今回本の話ですよね。
そうですね、はい、本の話です。
で、珍しく今回は2人とも読んでおります。
確かにいつも片方が読んだのを紹介するとかですもんね。
ですです、今日は本の名前がタイディーファーストですよね。
はい、去年のクリスマスですかね、発売になってた。
そうですね、で、2024年にその翻訳版が出たんですけど、自分がそっちを読んでないので。
うんうん。
えーと、2023年の冬に出たんですよね、これ原著が。
はいはい、なるほど。
そっちで読んだきりなので。
うん。
ちょっと翻訳版がどう変わってるのかは気になるところです。
なるほどですね、じゃあちょっとその翻訳版を読んだ時の感想というか、
記憶と読んでない時の記憶で、こここうだったねっていうのが話せると良さそうですかね。
リファクタリングの意義
そうですね。
うんうん。
はい、まず気になるのが。
はい。
タイディーファーストっていうこのタイディーって聞き慣れない単語だったんですけど。
はい。
えーと、自分のメモにはセイリセイトンと書いてあるんですけど。
はい。
これはどういう訳をされてたんですかね。
あ、そういうピンポイントでくるやつですね。
はい、それでいくと、ちゃんと訳もセイトンとかでしたね。
で、ちょっと僕まだこの読み方がタイディーなのかティディーなのか。
確かに。
いまいちピンときてないところはあるんですけど。
はい。
身近なところで自分がこの文字を見るときは、ゴーランのコマンドとかでたまに見るなっていうところはありました。
なるほど。
セイトンね。
じゃああんまりその直訳の意味と変わりはしない感じか。
そうですね。
はくたけさんも読んでいらっしゃるのであれだと思うんですけど、書籍の中でも出てきてたのがリファクタリングとの住み分けと言いますか。
何でしょうね、住み分けというよりは言い換えのようにも個人的には感じたなって思うんですけど、どうです?
一番最初の序文から筆者の嘆きから始まる感じですよね、確かね。
リファクタリングを時間がかかるものだというニュアンスで説明しやがってみたいなとこありました。
そうですね。だからリファクタリングって本当はこうなんだよっていうのじゃなくて、このTDがそのぐらいの気軽さで始めるものなんだみたいな雰囲気で使われてますよね、この単語。
そうですね。なので翻訳側だとセイトンはミニリファクタリングだっていうような表現をされていて、本当に今だと多分リファクタリングっていう言葉が結構長期間のっていうのを暗黙的に意味しちゃってるから、わざわざミニをつけてるのかなって気もしますよね。
そうですね。そういう別のものなんだよってニュアンスで使われてるんでしょうね。
という感じでいくとどうしようかな。じゃあ全体的に三沢さんどうでした?三部構成ですよね、まずね。
そうですね。三部構成で全体的にっていうと、なんか私は読んでみて感じたのは結構最初は本のタイトルを見たときに、またリファクタリングとかコード整理の具体的な方法とかテクニック。
をたくさん説明してるのかなって最初は思っていたんですけど、実際読んでみるとこの本の他のコーディング本との差別化の部分って、整理、セイトンとかリファクタリングをするにあたってのキャッシュフローのところ。
第3部とかですかね。
そうですね。第3部のキャッシュフローのところに対して結構厚めに説明をしているので、自分たちがリファクタリングとかって間違いなく行動に対していいことだよねって漠然と思っているところをちゃんと、
それをやることによってどういう利益というか、メリットがあるのかってお金の面でちゃんと説明できるようになりそうな本だなって思いました。
そうですね。一応流れができているというか、第1部はさっき三沢さんがある意味期待どおりというか予想どおりのちょっとハウというみたいなチップスみたいなのがいっぱい書かれてて、
この部分だけだったらもっといい本は多分他にいっぱいあるでしょうね。
そうですね。最初そこ読んだ時にパッと思い浮かんだのはリーダブルコードでしたっけ。
そうですね。
リーダブルコードに書いてそうなことだなって思いました。
あれ系ですよね。だからね。
あれ系をシンプルに書いてますよね。すごく。
っていうのがいっぱいあって、2部はそれをいつやるか。
いつやるかどう管理するかとかですよね。
そうですね。マネージングだから。
3部がさっきの話とかですかね。
そうですね。3部はいきなりここから金融の言葉がいっぱい出てきてて。
技術的不採用の考察
そうなんですよ。めちゃめちゃ調べました。
そうですね。自分もオプションぐらいは聞いたことがあったんですけど。
オプションの中に法則がオプションを決めるためのグリークスとかっていうパラメーターがあってとかって書いてあって。
そうそう。この辺も私寄生する電車の新幹線の中で読んでたんですけど。
3部あたりに入ってきた途端に急に頭に入らなくなってきて。
NPVとか書かれてますからね。
なんだなんだと思ってスマホで調べながら一生懸命読んでましたね。
自分なりの解釈で言うと、ここは金融の話を出したのは、
たぶん単純になるべく支払いを後に回すのかっていう費用を出したかったんだろうなっていう感じですよね。
そうだと思いました。なので意識的に使ってないのかどうかはちょっとわからないんですけど。
しかし考えで言うと技術的不採用をどう借り入れてどう返すのかに近いニュアンスなんじゃないかなと思ったんですけど。
確かに。それで言うと、ちょっと待ってくださいよ。
今この三沢さんと自分が見ているところにメモを貼ってるんですけど、
たぶんここにテクニカルデブなかった気がするんですよ。
そう、まだないんですよ。
ないですよね。検索しても出てこない。たぶんないんですよね。
ないんで、意図的に使ってないのか、それとも技術的な不採っていう言葉の詳細がいつ借りてどういう返済計画をしてとかのところに分解されてるのかがちょっと気になるなと思ってます。
そうですね。
確かにな。もしかしたらそういうの使いたくないから使ってない。
そう、あるかもですよね。
かもしれないし、あと序文だったかどっかに、この本ケントベックさんが書いたやつですけど、
ケントベックさんがすごい昔に読んだストラクチャードデザインっていう本があって、それがいいと思って
それの色褪せてない部分をもう一度世に残したかったんだとか言ってるところがあったんで、
そこにないから書いてないだけとかかもしれないですね。どういう感じかわかんないですけど。
そうですね。勝手にネガティブに考えると、技術的不採っていう言葉もリファクタリングっていう言葉と同様に、
基本ただの悪いものっていう極端な捉え方をされちゃっている可能性があるから、使ってないのかなって思ったりもしてて。
確かに確かに。
技術的不採自体って、プロダクトの価値とかを優先的に提供するために一時的に借り入れる、結構戦略的に取るものだったりするじゃないですか。
そうですね。
じゃないですかって言ったけど、私はそう思っていて。
今すごく広く使われている用途ではそうじゃない使い方もあるけど、本来的にはそういう意味をニュアンスとして持たせたいでしょうね。
なのかなって思っているので、簡単に使っちゃうとそこの戦略性が無視されて、ただの良くない技術群みたいな捉え方をされたくなかったんじゃないかっていう感じですね。
そうかもしれない。確かに日本ではそんなニュアンスですけど、海外ではどういうふうに使われているんでしょうね。
そうですよね。そこちょっと気になりますよね。
日本で技術的不採って言ったら、結構単に読みにくいコードみたいなそういうニュアンスで使われているけど。
読みにくいコードとか、ずっと塩漬けにしてきた何かしらのバージョンアップとか。
けど、この本で第3部で語られている文脈で言うと、それが全体としてコストを、ちょっと一言で言うのは難しいな。
もちろんポジティブに多分書かれてますよね。
そうですね。ポジティブに書かれてるし、やっぱり一番大事なポイントって基本小さくやってるんだなっていうのは、全書を通して書いてるとかあるのかなって思いません?
そうでしたね。なるべく小さくして、小さくしてこのタイディのコストをゼロにするっていうのを多分推奨してる感じがしますね。
少しそれを積み重ねていった先で、徐々に整理整頓されていくから結果良くなっていくんだよみたいなところでしたよね。
そうでしたね。全然コストがないから、そのコストが片付けしてから変更するコストがしないで変更するコストを下回るならもうすぐさまやれっていう感じでしたね。
これちょっと書籍から外れちゃうんですけど、僕これまでの経験でたまにあるのが、例えばスクラム開発とか、別にスクラム開発に限った話じゃなくてもいいんですけど、
とかをする中でスプリントプランニングとかするじゃないですか。たまに違和感を覚えちゃうのって、タスクにリファクタリングっていうタスクを積むときがあったなって思ってて。
ありますね。
整頓の重要性
おそらくこのTDfastが言ってるものってそういうタスクに積むまでもなく、何かしらコードを開発する際についでにシャシャっとやっちゃっていこうねぐらいのニュアンスなんだろうなとは思いますよね。
そうですね。それ自体をタスクとして、どっかに書いてあった気が。
そう書いてあった気がする。きっとそれが結局タスクにしちゃった時点で、結構レビューも大変だしとかにつながっていくと思うんですよね。
ですね。理想としてはもうTDで生み出された、ここではコミットとしますけど、コミットはレビューされないのが望ましいって確か書いてありましたね。
なので、ボーイスカウトルールじゃないですけどね。触った時よりも綺麗にしてちょっと変えるぐらいで、それを繰り返せばいいんじゃないかみたいなのありますよね。
そうですね。それ自体はよくあるプラクティスというか、今から変更する箇所が変更しにくかったら、リファクターみたいなことをしてから新しくプールリクを作るみたいなのって、
よく見るテクニックだと自分は思っていて、それで限界が来るのって大きなリファクタリングというかリアーアーキテクチャーぐらいのやつになると及ばなくなるんですけど、
特にそれについては触れられてなかったと思うんですよね。
触れられてなかったと思います。
1回の対議がどのくらいだったっけ?1時間未満ですか?5分から。
1時間とかでしたっけ?もうちょっと短かった気もするんですけど、でもそうですね。
長いとダメみたいな感じだったんですけど、それで今、みんなが苦しんでいるものが解決されるのかって自分は思ってたんですけど、
それがあれですよね。その小さいのがひたすら積み重なれば、最終的に良くなるんだよっていう感じでしたね。
変更管理の戦略
本当そう思いますよね。
あとあれもありましたね。なるほどって思ったのが、変更って大体なんだっけ?
80%の変更は20%に集中するっていうのが、パレートの法則だ。
みんながよくいじるところは少ないところに集中するから、そのすごい小さい回収タイディでも、めっちゃ多分何回も行われるんだよっていうことが確かどっかに書いてありましたね。
1回ガッツリやってとかじゃないんだよって感じですよね。
そうですね。よくいじるところはよく整頓されるんだよってことですよね。
確かに今の流れとして大きいのって、まとまって整理整頓する時間をとって、1回整理したら次汚れでやべーってなるまでほっとくって多そうですよね。
そうですね。
結構そういうことがしっかり文章の節々に感じ取られる本だし、きっと読んでいくとすぐコード触りたいって気持ちにもなるのかなって。
すぐにちょっとやりたくなるっていう。
これは確かにありそうとかありますもんね。
ありますね。
っていう本だったかなっていうところですけど、これあれですね、博多くんさん先ほど2023年?
だったと思います、多分。このメモの。
まだあれか、2部3部が出ていないので。
だと思います。どうなんでしょうね。自分はこのケントベックさんの何らかSNSアカウントとかがあるような気はするんですけど、フォローとかしてないんで。
もう書き始めてはいるのかな、どうなんでしょうね。
気になりますよね。
ですね。この本の最後に表があったんですけど、この表って翻訳版でもありました?
ちょっと待ってください。
メモの一番最後に表をスクショしてあるんですよ。
WhoとWhen、What's、How、Whyが書いてある。
ありますあります。
ありました?
同じこと書いてますね。ちなみに今見ている表っていうのが多分33章のやつですよね。
そうですね。
で、リファクタリングとかを対象が誰でいつやるのとかそういう話ですよね。
ですです。
言うと博多家さんが貼っ付けてくれてる表と全く同じですね。
だから第一章とか言ったら分かりにくいか。
一冊目、この本がWhoがYouになってるんですよね。
そうですね。
個人とかもしかして訳されてますか?
あなたってなってます。
あなたか、普通そのままか。
で、次がYou and Programmer's colleaguesかな。
同僚、そうですね。あなたと同僚。
で、全てのステークホルダー。
だからチームメンバーと最後がステークホルダーにまで及ぶ3冊目なんですよね。
ですね。
で、この表面白いなって思ったのは
リファクタリングのところはしっかり数日から数週間ってなってるんですよね。
そうですね。
大きなものとして捉えてるぐらいありますよね。
そういう意味で言うと次の本はリファクタリングの本になりそうですよね。
ですね。
フォーカスしてるのが個人じゃなくてチームとかでしたよね。
チームでリファクタリングをすると。
で、なぜのところがこの1冊目だと
クープリング&コヒージョンか。
だから業種。
うん。結合と業種。
のためにやるんですよね。それの解消。
ですね。
結合を解消して業種をさせるために。
うん。
で、2冊目はパワーローズなんですけど、これがべき定則ってやらされるんですよね。
うん。
だからあれですよね。複雑さが一気に跳ね上がるってことですよね。
ですね。グラフで言うとグインティ行くやつですよね。
ですね。リファクタリングしないとそうなるからしなきゃいけないってことですよね。きっと。
うん。
で、気になる3冊目。
はてな。
そう。ホワイトのところがはてななんですよね。
なんでっていう。
なんでやるんだろう。これ、Howなんて書いてあります?
3冊目ですか。
はい。
ダイナミックバランスなんで、たぶんそのまま略してますね。
カタカナでダイナミックバランスって書いてあるんですか。
そうです。英語と一緒。
なるほど。ここ何なんだろうと思ったんですよ。ググると運動学とか何か。
力学とか。
力学って言葉自体は結構あれじゃないですか。組織系の本とかだとよく出てくるじゃないですか。
出てきますね。
それ系なのかなって思ってますけど。
そういうことですかね。
うん。
What'sがアーキテクチャルエボリューション。
アーキテクチャの進化。
進化的アーキテクチャなのかなと自分はこれで思ったんですけど。
これ、私なんかシンプルにそのときの技術の進歩によるアーキテクチャの変更とかに適応するってことなのかなって思ってたんですけど。
そういうことか。
それこそあれじゃないですか。ここ数年だとやっぱモノリスからマイクロサービスアーキテクチャとかまさにそういうのなのかなって思いましたけど。
そういうことか。組織をアーキテクチャで当てはめて。
なんかでもWhoがAll Stakeholdersだからそれこそそれぞれの文脈で考えたときのWhyってすごく大きいことを考えるともう企業の成長ぐらいしかないんじゃないかって当てはまるもの思っちゃうんですけどね。
そうですね。でもAll Stakeholdersだから、本当あまりにもちょっと広く解釈すると、2Cとかだったらカスタマーもお客さんも入るわけで。
確かにそうですね。
決定基準と具体例
2Bとかだったら相手の会社とかも入るから。
これはどこまで入ってるんだろうね。
ちょっとね、なかなかあれですけど。
これはむしろ参考にされた書籍を読んだ方が何か見えてくるのかな。
なるほど。
読もうとしてないけど全く。
何を書くかはね。そして3作目まだ2作目も出てないから。
そうですね。
出るのかな本当に。
いや、出るんじゃないですか。出るって思いつつ、これは何の答えもない話というかただの感想なんですけど。
結構一部の整理するためのTipsというか考え方とか自体は、今後ってこういうのってゴリゴリに人がやるっていうよりは
AIエージェントとかがやってくれちゃうんだろうなって思ったりはしました。
そうですね。こういうテクニックって人間が読みやすくするためのテクニックだから。
そうなんですよね。
AIが読むならいらないでしょみたいな極論話になってくるかもしれないですね。
なってくるかもしれないって思いましたね。
そうですね。
なるほどね。
なんかすごい取り留めもなく話してきましたけど、気になった章とかありました?今さら聞きますが。
気になった章はやっぱ後半の3部全般とかですかね。
確かに全般。
もっと言うと3部の主にキャッシュフローとかコスト面を話し出したところとかですかね。
27あたりがオプションズVSキャッシュフローなんでこの辺かな。
多分その辺ですかね。
今日の1ドルを取るのか。
明日の1ドルを取るのか。
可能性を増やすのかって感じですかね。オプションだから多分。
だからそうか翻訳されてる部分でいくと多分24章から27章ぐらいが結構私は用語を調べながら読んだところかもしれないです。
そうですね。
自分は多分そこら辺も面白かったんですけど2章の最後ら辺に
この本のタイトルTidy Firstなんですけど
ファーストかアフターかレイターかネバーかっていう章があるんですよ21章かな。
ありましたねありましたね。
ここがケースバイケースではあるんですけどちゃんと言い切ってるから好感が持てましたね。
わかります。
よくある結局ケースバイケースなんで章じゃないですもんね。
このパターンではこれ、このパターンではこれみたいなというのがあって良かったですね。
一つ迷った時の指標には間違いなく判断基準になりますよね。
そうですね。
コストと選択肢の重要性
結局やるかやらないかで言うとコストメリットがあるならやれっていう一言なんですけど
まあそう。
ただまあそのコストメリットがあるかどうかを見積もるのが難しいんだよという話ではあるんですけど
そういう意味でも小さく小さく繰り返すことによって見積もりを確実さを上げるっていうんですかね。
Tidyのコストを減らしていけばいつやっても同じ失敗することがないってことですよね。
そうですね。あとすごいもう突拍子もないことを言うとさっきこういうとこってAIやっていくよねって言ったんですけど
まあシンプルにやっぱ整理してると楽しいですよね。
そうですかね。なんかそれもあったな。
メンタル面のヘルスのためにやっても良いみたいな。
やっても良いけど大体その夢中になっちゃうから夢中になるのは気をつけない。
気をつけないみたいなのありましたよね。
なんか後に残して楽しみは後にとっておくといいよみたいな。
お楽しみリストにしておくといいよみたいなね。
ありましたありました。
まあねそうなんだけど。
自分はその言われていることとは逆の感想を持って楽しみとしてやるっていうよりも機械的にやっちゃえばいいじゃんと思ったんですけどね。
全ての作業の最初に。
あーなるほど。
5分とか10分とかぐらいやっちゃえばいいじゃんって。
最初に持ってきてパッとやって次に行くみたいな。
そこがあれですよね。
どれを選択するのが組織のパフォーマンスとかに対して一番効果的なのかってとこですよね。
そうですね。
多分それダメなんでしょうね。
仕組みを停止して。
ちゃんと考えろってことなんですよね。
確かにね。
考えながら作れって話ですよね。
構造と振る舞いの区別
あーもうケントウィックさんに怒られてしまった。
そうですね。
結構その金融とかの話だとみんな当たり前に知ってるもんなんかもしないですけど、
このオプションを作るっていう表現は結構面白かったですかね。
オプションを作る。はいはいはい。
確か後半の方でしたよね。
そうですね。
そうですね。
24に書いてあるかな。
物ではなく選択肢を作る。
26?
6にもあります?
うん。
これを作ることによって後々の選択肢増えていくよねっていうニュアンスかなって思いましたけど。
今日の1ドルより明日の1ドルの方が価値が低いっていうのは確かにそうだなって感じですからね。
結構そこを読み直したんですよ。いまいちこう、ん?ん?ん?ってなったんで。
そう、自分はあそこも調べた形跡が残ってて、ここに外部リンクが多分貼ってあるんですけど。
そうですね。
水保証券のファイナンス用語集のリンク集が貼ってある。
大事大事。
オプション、プレミアムとか書いてあるしさ。
最初何だろうって思いましたけどね。
やったことないからなオプション取引とか。
この辺経験ある人とか知見ある人からするとすごい例えがうまいとかになってるんですかね。わかんないけど。
かもしんないですね。ふに落ちるわみたいな感じなんかもしないですね。
なるほどなーってなってんだろうなー。
このメモを眺めてて思い出したんですけど。
28章にストラクチャー、これ何て訳されてるんですかね。構造の変更。
科学的な構造変更。
ストラクチャーだから構造ですよね。
そのストラクチャーの変更は、ビヘイビアは何て訳されてるのかな。振る舞い。
振る舞いですね。
そっちと比較してすぐ戻せるからどんどんやったらいいよっていうのが書いてあって。
この本全体的にそのストラクチャーとビヘイビアが区別されて論じられていて。
そこをちゃんと分けて考えたことが自分はなかったかもなーと思いましたね。
そこは私も思いました。というかその科学的なところかどうかっていう観点ってしっかり言語化したことなかったなって自分で気づきましたね。
読んでみて。
これはちょっと収穫だったかも。
リファクタリングに慣れてる人は当たり前なんかもしれないですけどね。構造を変えて振る舞いを変えないんだから。
当たり前だけど、人に説明するときにちゃんとその言葉を使って説明できたかっていうと自分は多分できてないなーって思いましたね。
改めて考えて構造だけを変えるのはどんどんやっていくんだっていう感じですね。やっていきたい。
やっていきましょう。
そんなとこかな。何かありましたか?
他は大丈夫です。やっぱり読んでみて、読んだ人と話すといろいろ気づきとかが得られるんだなっていうのを改めて思ったので、今日話せてよかったなっていう感想です。
それは自分も思いました。この本、自分の観測範囲だと読んでいる人が多い気がしています。
私もそう思います。
あれかな?ちょっと短かったから。
手に取りやすいはありますよね。
それもあったかもですよね。
あと周り聞いてると結構品薄になってて、1月に手に入るとかも聞いたりはしましたけど。
そうなんだ。これって物理本しかないんでしたっけ?
電子版もあったんじゃないです?私物理本で買っちゃいましたけど。
ちゃんと手に入ってよかったですね。
よかったです。
今日はそのとこですかね。
そうですね。
今回はDaily Firstについて話しました。
感想などは、ハッシュユルティックをつけて投稿してください。
Googleフォームからも送れます。
今日はありがとうございました。
ありがとうございました。