コミュニティ参加の経緯
ken
はい、London Tech TalkのKen Wagatsumaです。
Tidy First? Part IIの振り返り収録をしていこうと思います。
はい、Shinoさん何笑ってるんですか?
shino
すみません。
なんかちょっと恥ずかしくなっちゃった、急にすみません。
ken
急に?急に?
shino
ちょっと汗かいてきた。
ちょっとジャケット脱ぎます。
ken
今日3回目ですよ、もう。
shino
はい、よろしくお願いします、Shinoです。
ken
はい、Shinoさん。
めっちゃ笑ってるから、これどうしたんだろうかなって。
shino
なんだろう、なんかちょっとかしこまっちゃうとね、笑っちゃう。
ken
はいはいはい、わかるわかる。
やっぱ、ポッドカストの導入いつも悩むんですよね。
shino
結構かしこまって入るタイプなので。
うん。
ken
なんかめっちゃ笑ってるんで、いいアイスブレーキングになりました。
shino
やめて。
ken
今日はですね、タイディーファースト第2回目パート2の振り返り収録をしていこうと思うんですが、
Shinoさんはロンドンテックトーク自体は、もう2回ね、過去に収録参加してくれてるんですけど、
ブッククラブの自体は今回、DDIAとSMARTに続く3冊目から参加してくださっているということで、
今回参加した経緯を含めて聞いてもいいですか?
shino
はい、もちろんです。参加した経緯は、まずロンドンテックトークのコミュニティに参加できたっていうので、
ブッククラブへの参加のハードルがすごい低かったっていうのもあり、
前回も気にはなってたんですけど、ただちょっと本の内容的に私向けではないかなって思ってて、
今回Tidy Firstだと、タイディングってね、多分どのプログラマーにもぴったりな内容だと思うんですけど、
これでも、これは面白そうだなって思ったのと、私はなんか輪読会っていうのがすごい好きなんですよ。
そうなんだ。
そうなんですよ。前のコミュニティでも輪読会やってて、
クリーンアーキテクチャーの輪読会とかも1年か2年ぐらいやったし、
インフラのもやったし、みたいな。
だからやっぱり、自分が普段これすごい読みたいって思わない本は、
輪読会っていう制限があるっていうか、ここまでにここまで読むっていうのがあることで、ちゃんと読むっていうね。
ken
分かる分かる。
shino
で、アウトプットするから、ちゃんと理解しないといけないっていうのがすごい良くて、
新しい発見にもなるし、すごい勉強にもなるし、
今回参加してみて、すごいですよね。
過去の輪読会スタイル
shino
何が何が。
レベルが高い。
すごい、思ってたよりも100倍ぐらい面白かったです。参加してみて。
ken
多分それ、参加者の方のおかげですね。
過去の輪読会は、でも多分やり方というかスタイルっていうのは多分違うかなと思ってて、
ロンドンテックトークのやり方で言うと、DDIAの時にアサヒさんがある程度確立してくれたメソッドなんですけど、
みんな事前に読んで、で、Google Docsに思ったこととか感想を書いて、
ディスカッショントピックがあれば立てて事前にそれを書いておくみたいな、
事前に文章に書くみたいなスタイルで、
集まったミーティングでは、みんな内容を振り返ることはせずに、
いきなり感想紹介に入っていくっていうスタイルなんですけど、
篠さんが過去に読んだ本のスタイルっていうのはどういう形だったんですか。
shino
輪読会、私は2パターンあって、
まずは集まってその場で1行ずつどんどん読んでいくっていう、
これだと本当にそれこそ2年ぐらいかかるんですよね。
ken
分厚い本だったね。
shino
そう、だからね、これはちょっとあんまり良くないんですけど、
参加のハードル自体はすごい低くなるかっていう利点はありますよね。
確かに。
で、もう1個はTDAかTDBか、
待って、テストドリブンデベロップメント、TDDか。
わかんなくなっちゃって。
ken
こういうのいっぱいあるから。
shino
フォローはありがたい。
ありがたい。
TDDの本を読んで、
それはやっていくスタイルだったからみんなでやって、
1パーチャプターごとにやって、
それをコード上げて、
そのコードについてみんなで話し合うみたいなやり方をとってました。
大体この2つが多いですね。
ken
TDDの本って、
ティーワダさんが訳された参照コードを見ても結構あるやつでしたっけ。
shino
そうそう、ティーワダさんが訳された。
TDDの話になっちゃうんですけど、
あれすごいティーワダさんのあとがきがすごくて、
すっごい面白くて、
だから、画前翻訳版をおすすめしています。
ken
それね、僕もあれ読みましたね。
内容自体は覚えてないけど、
確かにすごい熱い思いがあったのを記憶しています。
shino
そうそう、役者あとがきなのに、
すごい10ページくらい書いてて、
これはすごい。
ken
あれは日本語で読むメリットですよね。
shino
そう、役者の思いが見えるっていうのがね。
ken
そっかそっか。
ちなみにその過去の2つの輪読会における、
篠さんの役割は何だったんですか。
自分で企画した側、それとも誰かお友達が参加した側だったんですか。
shino
クリーンアーキテクチャーの方は毎回読んでいくわけです。
他の方が企画してたんですけど、
ほぼコーホストみたいな感じで。
ken
いいですね。
shino
最終的にはYouTubeに勉強会の様子とかも上がってて、
読んだ内容のこういう感じでしたよみたいな。
TTTの方は私ともう一人の方、
もう3人かな、3人で企画してやってっていう感じでしたね。
ken
なるほどなるほど。
コード書きながらみんなで見合いながらっていうスタイルも一回やってみたいですよね。
ロードテクトクでやってないので。
どうですかメリデメ。
shino
デメリットとしてはやっぱり参加しなくなっちゃうことがあるんですよね。
ken
ハードルが高いというか。
shino
ハードルが高い。
エンジニアスキルによってやっぱりこれがやってて楽しいとか簡単すぎるとかもあるんですけど、
TDDの方は書くだけって言われたら書くだけなんですけど、
各自自分の好きな言語で書いてたんで、
例えばPythonで書きたいけどJavaのコードで書かれてるから、
どうやってPythonのコードに移して直したらいいかわからないみたいなこととかが起こったりとかして、
でもその方も最後まで参加してくれたったんですけど、
そこはちょっと難しかったなって。
でも、最終的にはちょっとやっぱり最初10人ぐらいやるって言ってくださったけど、
最終的に残ったら3人ぐらいだったんです。
4人か4人か3人とかだったんで、
振り落とされはするなって。
ken
なかなかハードルの高さと得られるものと、
あとそのドロップ率のトレードオフなのでそこが難しいですね。
Tidy Firstの内容
shino
そう、Tidy Firstのやつも結構参加ハードルは高いじゃないですか、
このミーティングノート書いてて、ディスカッショントピック書いてとかって、
でも結構みんな参加されてたから、どうやってるんだろうって思い出した。
ken
参加者のモチベーションにこうおんぶに抱っこしてるしかない。
参加できなかったけど、非同期でノート書いてくれた人とかもいるから、
個人的には同期でも参加できるけど非同期でも参加できる口があるっていうのが、
個人的にも気に入ってて、
そのSMARTの時はアサヒさんが基本的にはずっとファシリテーションしてくれたので、
僕も同期のミーティングはまた障害が起こったりして出れなかったけど、
非同期でノートを見てキャッチアップしたみたいなのがあったので。
shino
確かに。
ken
それが良かったかな、個人的にはと思ってます。
shino
確かに、けんさんめっちゃコメント書いてくれてて、
それ見るのもすごい、今見直してたんですけど、すごい楽しいなって。
ken
そうそうそう、これ結構楽しいんですよね、なんか読んでるのが。
やっぱ本読んでると自分で勝手に理解しちゃったりとか、
あと分かんないところがあるんですけど、
みんなで読めるっていうのがいいかな。
shino
そうですね、あとなんか自分が個人的に読み飛ばした場所を、
その他の人がここ面白かったって言ってて、
え、そんなのあったっけみたいなね、もう一回思って。
じゃあ分かる。
ken
しゅんさんのコメント、僕結構あったよ。
あれ、ここ突っ込んでるけど、確かに読み直してると分かんないわ。
shino
そうですよね、ストラクチャーとビヘイビアの話ですよね、きっと。
そうそうそうそう。
あそこは読んでて分かんなくて、3回ぐらい読んでも分かんなくて、分かんないです。
ken
それがめっちゃよくて、なんか自分で1回読んで分かった気になってるんだけど、
他の人が分かってないって言ってくれて、読み直してみると、
shino
あ、俺も分かってないわみたいな。
ken
そう。
なんで、ここの今回のパート2、
パート1は結構その明日からでもすぐに使えるようなTipsが多かった感じなんですけど、
パート2はもうですね、まずセクションの名前を見直してみると、
5、6チャプターって結構その考え方に、Tipsから考え方に寄ってきたかなと思ってて、
チャプター16が、
で最後に、
みたいな感じでしたけれども、
なんかその篠さんの中で、すごい記憶に残ってるチャプターというか、
ありますかね。
shino
タイディング、それこそいつするかっていう話は面白かったですね。
なんかタイディングファーストっていうタイトルから、やっぱり最初にするべきだっていう話なのかと思いきや、
割となんかいつしてもいいってほどではないかもしれないですけど、
なんかいつやるの、
例えば後でやるとか、
最初にやらなくてもそれはそれでメリットがあるよねみたいな感じで提示してくれてたのは、
ちょっと嬉しかったというか。
ken
あー分かる。
shino
良かったですよね。
それこそ後からやっていくとしたら、
学びにもなるよねみたいな、フォードを学ぶっていうのになるよね、確かに。
なりましたし。
ken
そうですよね。
そのチャプター21がたぶんパート2で言うと一番目玉で、
まあなんかその、
それまでは、
behavioral change Bとstructural change Sを分けましょうねみたいなことを言ったりとか、
あとはそのタイディングってポテトチップスみたいだよねみたいなのをチャプチャー17の最初で言ってて、
要するにこう、やり始めると止まらない?
ケントベックがソファーの上でポテトチップスを食いながらっていうイメージを、
なんかすごい想起してしまったんですけど、
タイディングのアプローチ
ken
まあそんな感じで多分タイディングもやり始めると止まらないのかなみたいなことを言ってたりするんだけど、
そのチャプター21では今しのおさんが言ってくれたように、
そもそもタイディングをしない、neverっていう選択肢も取れるし、
後でする、それから後でするのがlater、
その機能実装の完成前でするか、
after、その機能実装の完成後というか、
結構一回後でrevisitしてやるみたいな、
もしくはタイディファースト最初にやっちゃう、
いろんな選択肢があるよねっていうのをチャプター21で結構、
考え方を紹介してくれたのは個人的にもすごくありがたかったなと思いますね。
shino
確かに。
あとはやっぱり、ちょっと私もさっきチラッと言ったんですけど、
タイディングの中にbehavior structureで分けるっていう、
これがなんか割と新鮮だったというか、
私の中ではなんだろうな、
タイディングの中にbehaviorは含まれてないと思ってたんで、
それを分けるっていうのが大事って、
書かれていたのは結構面白かったですね。
ken
そうですよね、ここ僕もそうで、
なんかビジュアライズされてる図が結構個人的に好きだったんですよ。
shino
手書きの図ってやつですよね、すごいかわいい。
ken
かわいいBとSに分けて、
iPadの中で書いてるのかなとか思いながら。
shino
GIF手書きですよね。
ken
あれ面白い。
そうそう、なんかそこかわいいなと思って。
shino
確かに。
ken
それで言うと、なんか結構個人的には、
そのチャプター19のリズムっていうところも、
なんか好きで、好きというか、
たぶん章自体はそんな1,2ページのそんな長いこと書いてないんですけど、
なんかタイディングみたいなソフトウェアのコードを書くときに、
どれぐらいタイディングしたらいいかみたいな考えるときに、
リズムっていうの大事だよねみたいな、
なんか割と感情論じゃないですけど、
心情的なところもちゃんとチャプターを当てて書いているのが個人的には好みでしたね。
リズムの重要性
shino
確かに。
でもリズムのところ正直あんまり理解できてなくて、私は。
ken
うんうんうん。
shino
なんかどう、何の話したっけなって思って、
あの輪読会、輪読会というか、
あのブッククラブのときどういう話しましたっけ、あのとき。
輪読会でリズム。
ken
リズムのとき。
shino
リズムのときになったかな。
ken
ディスカッショントピックではそんなに上がらなかった気がするんですけど、
なんかそのリズムの章を読んで、僕の理解としては、
なんかその、ストラクチャーチェンジとかビヘビアルチェンジに分けたときに、
タイディングしたくなる箇所ってたくさん出てくると思うんですけど、
例えばその、同じような似たような箇所をリズムが乗っているときに一気に直しちゃったりとか、
でもそうじゃないときには、今直さなくていいものは後にしてみたい。
結局そのチャプター21のレイターとかアフターとかにつながってくる前の話だと思うんですけど、
例えば今目の前にしているタイディングのものを今するのか後するのか決めるときに、
全て同じタイディングするものかどうかって判断しなくてよくて、
書き手のそのリズムというか、
レビューコストの考察
ken
あとそのプロダクトの機能実装のデリバリーとかプライオリティを考えたときのタイミングっていうのを、
リズムという表現をしているというのが個人的にすごいユニークだったというか面白かったなと。
shino
なるほど、そういうことなのか。今ちょっと理解できました。
リズムの最後の方にね、1時間以内ぐらいでやるのがいいタイディングだよねみたいな書いてて、
それは確かに思いつつ、でも1時間でできるかなってちょっと、
どのぐらい1時間なのか、ケントベックの1時間と私の1時間違うような気がして。
ken
この1時間難しいですよ。
なんか例えば朝こう起きて、
今日はじゃあこのタイムブロックで何しようかなって考えながら、
でも実際にパソコンの前に座ってる時間が1時間っていう意味なのか、
そういうのを考えるのも含めて1時間なのかで結構作業法律も変わってきそうですよね。
shino
考えるのも含めて1時間だったら本当に何か3行ぐらいしかタイディングできない気がします。
ken
本当にこうコフィジョンオーダー変えたりとかリネームしたりとかコメント消したり、
まあまあそれでいいってことなのかもしれないですけどね。
shino
なるほどね、そっか。
何の章、どこの章だったか忘れたんですけど、これ結構みんな言ってて、
プルリクのコストの話してたじゃないですか。
タイディングをいっぱいやりすぎるとプルリクのコストが1回のコストが上がるけど、
ただいっぱいチャンクに、なんかちっちゃくしすぎて何回も何回も上げると、
それもコストになるみたいなバランスが大事だよって話をしてて、
なんか最終的にプルリク上げずにもうマージしちゃおうみたいな。
どこでしたっけ、ちょっと覚えてないですけど、
みんな突っ込んでましたよね、いやいやいやみたいな。
ken
今回のディスカッショントピックであったところかなと思ってて、
そのチャプター18のバッチサイズのところで、ケント・ベックが提案しているのが、
つまりそのタイディングのコストを下げるためには、レビューのコストを下げることができるよって言っていて、
それに対して皆さん賛成ですか反対ですかってディスカッショントピックがあったので、
その時に盛り上がった話かなと思うんですけど、
shino
本には書いてなかったのか、なんか本に書いてあるんだと思っちゃった。
ken
現場はどうですか、今篠さんの職場というか、レビューコストに対して。
shino
うちはそもそもプルリクないとマージができない仕様になってますね、レポジトリ的に。
ken
それは例えばミスとかでメインにプッシュしようと思ったらできるっちゃできる?
なんかもうプロテクトブランチとかでもできないようにしちゃってる?
shino
できないですね、もうプッシュもできないです。
ken
例えば間違ったバグが入っちゃったりするじゃないですか、
ロールバックもしくはリバートのプロセスってどういう風になってるんですか?
shino
バグが入っちゃった場合、
ロールバックというよりは普通にプルリク上げてそこを直してマージするっていう、
あんまりリバートに、リバートする時は例えばこのバージョンに含めるはずだったけど、
やっぱり含めないことにしましたみたいな時はリバートするけど、
バグがあったのでっていう時は普通に上書きするかなって、
普通にチケット切ってバグフィックスとして。
ken
それはどっちもレビューが必要ってことですよね?
shino
必要ですね。
ken
わかんないですけど、すごい緊急度が高いような修正とかで、
それを上書きでフィックスフォワードもしくはリバートプルリク出さなきゃいけないみたいな時も、
例えば出してちょっとこれ急ぎなんだけど早く見てくれないみたいな感じでコミュニケーションするって感じですか?
shino
多分金融系なんであんまり今すぐパッと直してっていうことができなくて、
それやるんだったら一旦リリースをオンホールドして、
一旦前の、例えばプロダクションで問題起こった時とかだったら前のバージョンにリバートして、
で、やり直すっていう風になりますね、うちだと。
ken
そっか、プルリクをマージしてからリリースするまでにまたクッションがあるってこと?
shino
どうなんだ、うちすごいなんだろうな、
まずリリースブランチを切るじゃないですか、それをいろんなエンバイラメントにデプロイするんですよね。
テストエンバイラメント、サンドボックス、プレイプロットみたいなものでやって、それで最後にプロットになる。
まあでもプロットまで行ったとしても、割と普通にリリースの前にどうやってリバートしますかみたいなの、その手順もちゃんと書いてからじゃないとリリースができないので、
そこはちゃんと、そうですね、なんかちょっとのミスが許されないような感じになってるから、そこはすごい厳しいですね、うちは。
ken
そっか、でもじゃあプルリクをマージするタイミングでも完璧に保証しなきゃいけないというわけではなくて、
マージした後でもいろんな段階的フェーズ、ロールアウトのところがあるから、
レビュアのストレスというか、ここでもうバグをどうしても検知しなきゃいけないみたいな、そんなプレッシャーもそこまでないっていう感じですかね。
shino
それはないです、うちはテスターもいるし、そこはね。
そうですね、バグが検知できなかったらそれはなんか全体の責任でもあるので、
あんまり、でもてかプルリクのときにバグがあるかどうか見ます?
ken
なんかそのうちだとトップハットってカルチャーがあって、なるべくそのレビュアが自分のローカル環境で同じようなプロセス、
実装者と同じプロセスで期待する動作がしているか確認するように推奨されていたりとかしますけれども、
うちもかなりフェーズロールアウト的なステップがあるので、自動でロールバックしたりという仕組みとかもあったりはするんですけど。
shino
それでいうとうちめっちゃテストがあるかもしれない。
なんかユニットテストもあるし、
オートマティックアクセプタンステストかな。
ken
アクセプタンステストか。
shino
それをCICDで流して、それの結果も貼り付けて、じゃないとインテグレーションブランチ、デベロップメントブランチですね。
そこにもマージできないんですよ。
ちゃんとテスト通りました。
じゃあテスト通ったんでレビューしてくださいみたいな感じなので。
結構しっかりしてますね。
そこまでやって爆が出たらもうしょうがないというか。
ken
テストの漏れとかになってくるのかもしれないけど。
それこそテストの漏れの話になっちゃうから。
レビューのコストに戻りますけど、この本を読んだ踏まえた上で、
今の篠さんの現場のレビューのコスト感というのはもっと下げたいなと思いましたか。
でも割といいラインかなと思いました。
shino
いや下げたいですね。
でもそれこそインテグレーションブランチにマージするのはすっごいコストかかるんですよ。
AATを走らせて、いろんなものの結果の、
例えばチェックマークを走らせて、
この結果何も新しいバグを生み出してませんとか全部やらなきゃいけなくて、
それこそ1日とか2日とかかかるんですけど、
それしんどいのです毎回やってたら。
チームで1個ブランチを作って、そこにどんどん1回マージしていくっていうのをやってますけどね。
ken
チームごとにってこと。
チームっていうのはコンテキストを理解しあえてるから、そこに入れていくのは早いよねっていうことか。
プルリクエストの改善策
shino
そうそうそう。それこそそれはもうユニットテストだけでバンバンバンバンマージして、
これを全部のチームフィーチャーブランチみたいなのをマージするときだけ、
そのAAT走らせてってやってっていう。
ken
なるほど。
そうですね。
チームのブランチってめちゃくちゃ面白いアイデアだなと思っていて、
このディスカッショントピックを話したときにあったアイデアとしても、
そのレビューコストを下げるために、
そのプルリクのディスクリプションとかに全て書くのではなくて、
例えばデイリースタンドアップで話すときとか、
あとそのコミュニケーション、同期でコミュニケーションするときにそのプルリクについて説明すると。
なので全て非同期コミュニケーションでやろうとするのではなくて、
同期コミュニケーションでサポートすることで、
そのレビュワーは、あ、そういえば朝のデイリースタンドアップで話したこれか、
コンテキストが分かるのにすぐマージできるみたいなことを言っていて、
まあなんか似たような話かなと思いました。
shino
確かに。
なんかミーティングやるときもあるっていう話ありましたよね、確かに。
ken
うん、プルリクの説明というか、
アドホックミーティング、テックディスカッションするみたいなアイデアもありましたね。
確かに。
shino
あ、でもそれはやってるかもしれない。
なんかフィーチャーブランチごとにその、
スプリントの終わりごとにこういうことやりましたっていうのを一人が、
その大きいチケットを貼った人がやって、
でこう質問とかってやってるかもしれない。
ken
めっちゃいいですね。
ビデオというか動作確認の動画とかも結構使ったりします。
うちとかだとそのタイムゾーンが結構分かれてるので、
同期ミーティングのハードルがめちゃくちゃ高いんですよ。
shino
そっか、そうですよね。
ken
なのでなんかその動かしてる動画を動画にとってプルリクに貼り付けたり、
もしくはそのコンテキストを説明する数分の動画をパッと貼り付けたりみたいなのを結構使ってますね。
shino
それって結構手間じゃないですか?
ken
結構手間だと思います。
手間だと思うけど、たぶんちょっと早起きしたり、
遅くまで仕事して他の人と時間合わせるよりは、
自分の時間で撮ったほうがっていう理解だと思います。
shino
それいいですね、でもね。
明らかにすっごいややこしいプルリクの時ってどうしようって思うじゃないですか。
わかる。
チーム貢献とレビューコスト
shino
20ファイルぐらいチェンジがあったら、え?と思って。
ken
わかる。
shino
ちゃんと見れてない気がしてます、そういう時は。
ken
僕も動画結構ハードル高いなと思ってたんですけど、
Mac使ってるんですけど、
デフォルトのやつで普通にスクリーンシェアも、
スクリーンの動画を撮るっていうのもすぐできちゃうし。
shino
そうなんですか。
ken
意外とみんなやってるし、真似してみたらそんなにハードルは高くなかった。
喋りのハードルは高いけど、動画を撮るツーリング周りのハードルは全然高くないので。
shino
でもちょっと1回試験的にやってみようかな、それ。
ken
いいんじゃないですか。
shino
明らかにややこしいプルリクの時だけ。
こうやってってかいって。
ken
ウォークスルーしてみたらいいかもしれない。
確かに。
shino
ただね、何だろうな、みんな見るかなって。
ken
そこ。
せっかく作ったのにね、見てくれなかったら寂しい。
shino
なんか結構みんなミーティング話聞いてないじゃないですか。
ken
エンゲージメントが足りないですよね。
shino
そう、なんか今話してたことなんで、ごめんもう1回説明してみたいな。
ken
よくあるよくある。
よくあります。
あれ30分前にそれ同じ質問したけどなみたいな普通に。
shino
そうそう。さっきじゃあこれでアグリーデねみたいななった後に、
私に普通にチャット飛んできて、これどうなったのみたいな。
ken
よくある。
チャットで聞くあたりちょっと意識してるのかもしれないですね。
shino
そうそう、こっそり聞いてくるんですよね。
1人ワンツーワンで。
ken
分かる。
でもそこで聞きたいっていうポジションを確立しようってすごいですね。
信頼チーム。
shino
なんか怖くないっていうのもあるかもしれない。
ken
怖くない、怒らないみたいな。
shino
そうそう、もう言ったでしょみたいなことを言わなさそうっていうのもあるかもしれない。
言わないですけどね。
ken
いいじゃないですか。
shino
全然何回でも説明します。
ただその代わり私が聞いてないときも聞きます。
私も聞いてないことがある。
ken
持ちつもたれつ。
そうそう。
協力関係ですね。
shino
そう。
ken
動画ちょっと試してみてください。
試してみます。
なんかそのレビューコスト下げるために自分のコストかけてるって声じゃないですか。
要するに動画を1時間かけて撮ることでレビューのコストを30分から10分にするみたいな。
そこのトレードオフも結構難しいなと思っていて。
なんか事前にすごい頑張ってプルリクのディスクリプションを書けば、
そのレビューのコストが下がるけれども、
なんかそれをやりすぎると自分のベロシティも下がっちゃうので、
そこのトレードオフっていうのが結構難しい。
shino
そっか、確かに。
でもなんかなんだろうな。
やっぱりプルリクって、
ちゃんと見ようとしたらすっごい時間かかるじゃないですか。
そこのコストを下げてあげるっていうのは、
ちょっとなんだろうな、
チームに優しいみたいになるのかなって。
あとアピールポイントにもなるのかなってこのね、
チーム貢献っていう意味で。
ken
あいつはいつも優しいプルリクを書く人だみたいな、
わかりやすいプルリクを書く人だみたいな。
shino
最近それこそチーム貢献してますかみたいなのを、
結構毎回聞かれるんですよね。
タイリングのアプローチ
ken
誰にですか?
shino
うちのチームリーダーに。
どういうことでチーム貢献をしましたかみたいな、
スプリントごとに聞かれるんですよ。
ken
なるほど、それワンオワンの場で?
shino
ワンオワンです。
ken
どう答えてるんですか?
shino
それこそこういう、
例えば新しい、みんなで今1個のことやってるんですけど、
それで、これは技術者じゃないとちょっとわかりにくいな、
みたいなところをウィキに全部書いて、
これはこの通りに全部やったら問題なく見れるようになってる、
抜けがないようになってるからちゃんと見てね、
とかチェックリスト作って、
コミットする前にこれ全部チェックして、
やってねっていうのを、
主にドキュメントが多いかなとかね。
それこそなんか詰まってる人とビデオコールしてとか。
ken
すごいヘルパーなんですね結構。
shino
そうなんですよ。
求められてんのかなって、そういう役割がそろそろ。
大事大事。
シニアだしね。
ken
そうなんですよね。
そういうことをリードに伝えてあげると。
自分がこういう場で貢献してるよみたいな。
アピールしなきゃいけない。
で、自分が貢献したことをドキュメントにまとめたりします?
いわゆるブラグドキュメントみたいな感じですけど。
shino
そういうものを書く場所があるので、
オブジェクティブみたいなところ。
ken
なるほどなるほど。
shino
そこに書いてます。
ということはタイリングもその一環で、
どうやってコードメンテをするかみたいな、
コードクオリティを保つためにどういうことをすればいいかみたいな話もあって。
ケント・ベックがチャンクに分けて、
いっぱい余った時間にちょっとやるみたいな。
それこそケンさんもおっしゃってたファンリストみたいな感じで、
チケットをここをじゃあ直すみたいなのをチケットにやって、
時間あるときにこれをやるっていう。
うちのチームもやってて、
すごいなって。
やってるなって思いましたね、うちのチーム好き。
ken
一応ファンリストを説明しておくと、
ケント・ベックがこのパート2で提案してたやり方で、
タイリングしたらいいリストみたいなのをまとめておけば、
時間があったメンバーとか時間があった人がそのときに、
ここら辺からもっときれいにしたいなと取れるっていう。
要するにリスト化するっていうだけなんですけど、
ファンリストって呼び方もいいなと思うし。
確かに。
shino
ファンリストって確かにいいですよね。
ただのto doリストじゃなくて、
ファンリストってやりやすい。
ken
やりやすい。
ファンだからね。
ポテトチップスなんで、タイリング。
shino
ある程度のところで止めなきゃいけないっていうのは大変。
ken
ポテトチップスと一緒ですよ本当に。
止める止めないも議論になったり、
パート2だったか覚えてないけど、
そこで悩んだりしたことあります?
今タイリングやりすぎてるな、
タイリング3時間くらいやっちゃったなみたいな。
shino
タイリング普通に3時間くらいやりません。
でも本当にどこまでやるかってすごい難しいですよね。
やろうと思えばずっと、なんだろうな。
こっちの方がいい気がするって。
でもやっぱりさっきの方が良かったみたいなのを、
繰り返し繰り返しやっちゃうから。
ken
めっちゃ上がる。
その時に試行錯誤の過程ってのは、
どういう形でGitで表現してますか?
例えばタイリングブランチみたいなのを切り分けて、
そこでいろいろタイリングをパイルアップさせて、
最後に振り返ってマージしようみたいな感じにするのかも、
割とメインブランチにどんどん入れちゃっちゃったりするのかとか。
shino
それこそチームのフィーチャーブランチに
マージしていくっていうのが多いですよね。
ken
例えばどっちがいい?
例えばコフィジョンオーダーとかインターフェースとか、
どっちがいいみたいな、なんだろう、
プリファレンスの違いというか、好みの問題みたいなのがあった時に、
今日の気分でこっちって言ったけど、
翌日振り返ってみるとやっぱりあっちの方が良かったみたいな、
タイリングの決断を後悔することとかありません?
shino
あります。あるけどしょうがないじゃないですか。
ken
諦めた。
shino
そうなんです。私5年前に書いたコードがすごいなんか、
もうずっと直したいんですよ、5年間。
でもしょうがないんですよね。
過去のコードの振り返り
ken
なるほどなるほど。これでもう前に進んでいくしかないと。
shino
そう、もう諦めてます。
もうあのコードちょっとほんと嫌だなって、
ずっともう5年間思ってるんですけど、直せない。
ken
もう動いてるから。
そこから学んだっていうところが糧になってるのかもしれないですね。
shino
そうなんです。それこそケントベックのNeverの話なんですけど、
新しい機能が追加されてないんですよ、その5年前に書いたコードは。
だからタイリング必要ないんですよね。
ken
もうケントベックも推してるんでね、タイリングする必要ないですね。
shino
そう、Neverの領域になって、
なんかもう変わらないんだったらもういいよみたいなこと言ってたじゃないですか。
言ってた言ってた。
だから、もういいんだって。諦めるしかない。
ただ書き直したいなってずっと思ってます。
ken
5年ぶりとかに戻ったときに、
結構その周辺のソースコードとか改めて理解し直さなきゃいけなかったりするから、
思ってる時間かかったりするし。
shino
ずいぶん壊したりしたらね、タイリングじゃないし、みたいになっちゃうから。
確かに。
でもちょっと言い訳をすると、5年前の自分は、
やっぱりこの綺麗に書こうとか、読みやすいコード書こうじゃなくて、
私はこのライブラリーが使いたい。
このライブラリーを使うためにどうやってコードを変えたらいいかっていうのをメインに考えてたんで、
ぺいぺいの考え方ですよね。
なんか読みやすさとかパフォーマンスとかのこと全然考えてなくて、
でもこのライブラリーを使うことで私のスキルがインプローブするから、
これ使いたいみたいな、そういう技術選定をしてたから、
ken
だから嫌なんですよね。
その話すごい面白いですね。
そこから、その当時のマインドセットから今に切り替わってきた、
どういうきっかけがあって徐々に変わっていったのかなと思っていて、
シンプルさの重要性
ken
それは単純にポジションとかが上がっていくことによって目線が上がって、
例えばチームメンバーのこととか、チーム全体の貢献とかアウトプットを考えるようになってきたからなのか、
そういう選択をしてきて何か後悔したりとか、
それは違うなと思う瞬間があったのかというと、
どういうふうにしのさんはレベルアップしてきたのか。
shino
なんかその時は、例えばこれを使えることによって、
履歴書にこれが使えますって書けるかなと思ってやったんですけど、
でも今思えば、何だろうな、それを5年前に使えたとして、
またエアブラリーバージョンとか仕様とかも変わってきてるから、
5年前の自分が使えたとして、今使えるっていうわけでもないし、
今結構バグじゃないけど、ちょっと遅かったりとか、
いろんなちょっと変な動作したりとかも多かったんですよ。
だからそんな変な動作になるぐらいだったら、もっとシンプルでわかりやすくって書いておいたほうが、
他の人からのメンテナンスもしやすいだろうしって、そういう後悔ですよね。
それこそ、自分の技術を肯定する場所じゃないじゃないですか、会社って。
そういうのに気がついたというかね、やっぱり。
ken
そのストーリーめちゃくちゃ説得力ありますね。
シンプルなソフトウェアを作ろうぜっていうのは多分誰でも言えるし簡単なんだけど、
じゃあなんでって言われたときに、いや実は自分がこういう後悔とか失敗体験があってみたいなのがあるとすごい説得力があった気がするというか。
shino
そうなんですよ。何でもちょっと小難しくやりすぎるとダメなんですよね。
ken
考えすぎてるというか。
shino
そう。文章とかでもそうじゃないですか。
それこそ、大学のときに論文は中学生がわかるような言葉で書けって教授に言われてたんですよ。
ken
なるほど。
shino
当時はわかんなかったんですけど、今ならわかるんですよね、言ってた意味が。
わかりやすく書かない、人に理解できない論文って意味がないというか。
ken
読まれない論文というかね。
shino
そう、小難しければ賢そうには見えるけど、でも別にそれは賢そうに見えるから何、みたいな。
それは本質じゃないじゃないですか。
わかる。
そう、でもそういうのね、なんか最近気づけるようになったんですよね。
ken
めっちゃ大事ですね。いやそれすごい共感するというか、僕もすごい気にしてるポイントだし、
そういうのはあれですよね、ペダンティックって言うんですよね、言学的というか、たぶん。
そうなんですか。
賢そうに振る舞っている。
shino
そうなんですよ。
今、私ドイツ語を勉強してるんですけど、ドイツ語の作文も同じなんですよね。
どういうことですか。
難しく書こうとすればするほど意味がわからなくなって、意味がわからないと、やっぱり意味が通ってない作文は罰じゃないですか。
どんなに難しい表現をたくさん使えてて、でもそれ意味が通ってなかったら罰、ゼロ点じゃないですか。
だから、確かにちょっと小難しい表現使わなくても、シンプルでちゃんと伝わる作文の方がきれいなんですよね。
そっか。
それよりも、まだそこはちゃんとたどり着けてないんですけど、やっぱりちょっとまだ小難しく書こうとしすぎて、先生に小難しいですみたいな、小難しく書こうとして失敗してますって言われて。
ken
わかってる先生。
shino
まだちょっと、作文はそこの域に達してないんですけど。
ken
習いたての単語とか使いたくなっちゃうんですよね。
今一気に中学校、中学生ぐらいにフラッシュバックしました。
絵作文でちょっとかっこつけた英単語を使いたくなるみたいな。
そうそうそうそう。
懐かしい。
ソフトウェアエンジニアも一緒ですよね。
shino
一緒です。もうどの言語も一緒です。シンプルが一番。
ken
本当にできる人の行動って、読んでわかるんですよね。本当に。
すごいわかりやすいストーリーを読んでるみたいに。
業界の常識とフィーチャートグルー
shino
確かに。
ken
ケントベックのコーダーどうなんだろう、読んでみたいな。
shino
ケントベックあれじゃない、TDDって読めるじゃないですか。
ken
そっか、そういうことか。
shino
どうなんかな。
ケントベック。
ken
日本語がすごい良かったっていう印象ですね。
もう読んだの数年前だけど。
shino
でも私ケントベックの英語の癖が、なんかちょっと癖あるじゃないですか。
ちょっと読みにくいというか。
ken
どんな感じですか、言語化できますか。
shino
え、言語化、なんだろうな。
ken
アナロジーが多い。
shino
それこそシンプルに説明しなくって、
それこそちょっと難しい表現使ってみたいとか。
劇場型というか盛り上げる感じ。
で、なんだろうな、ボボウジさんの時も思ったんですけど、
同じ感じなんですよ。
本に、なんだろうな、
たぶんすごくひょうきんな感じの表現なんだろうけど、
でもノンネイティブの私たちにはなんかわかんない表現ばっかり、
ちょっと多くて読みにくいみたいな。
ken
独特のユーモアセンスというか。
shino
そうそう。
で、このケントベックの本を読んだ後に、
他の技術書を読んでみると、
あ、全然読めるじゃんってなるんですよね。
ken
わかりやすいみたいな。
shino
そう、わかりやすいなこれみたいな。
たぶん、うーん、まあまあ。
ken
親戚のおじさんがちょっと話してるような感じがする。
shino
そうそうそう、だから子供はポカーンとしてね。
ken
本人楽しそうにしゃべってるみたいな。
shino
たぶんそんな感じなんだろうな。
ken
もしかしたらね、ノンネイティブ的には面白い文章なのかもしれないけど。
確かに癖はあるかもしれないですね。
shino
文句、ケントベックの文句。
ken
でもなんかこうみんなで話して結構、
いやこれケントベックに言ったほうがいいんじゃないかみたいな。
結構出てたんで。
shino
確かに。
そうですね。
パート3の話になっちゃうんですけど、
カナダのネイティブの子が、
いやこれ私にも難しかったって言ってたのがちょっと嬉しくて。
ね。
やっぱそうだよね。
ken
あれはちょっとね、僕も良かったです。
嬉しかったです。
shino
良かったって。
読めないから、もう全然ダメだって思わなくていいんだなって。
ken
そう、だからその結構英語、第二外国語で仕事してたりすると、
分かんないってなった時に、その分かんない理由を、
本当は言語の問題じゃなくて、中身が分かってないのか、言語で分かってないのかと、
分けて考えなきゃいけないじゃないですか。
でもなんかその第二外国語で仕事してたりすると、
第二言語か。
本当は内容が分かってないのは英語のせいにしちゃったりとか、
またその逆も起こっちゃう。
僕はスルーしてきた経験があるので、そういう風にする。
例えば同じものをネイティブの方が読んで、
これはちょっと言ってること違うとか分かんないって言ってくれるっていうのは、
すごい貴重なことだなと思いました。
shino
確かに。
うん。
ken
ね。
良かった。
はい。
ところかな、パート2。
なんか他にカバーしてないところで、
ここはコメントしておきたいみたいなこととかありますか?
shino
パート2全体として。
本には書いてなかったんですけど、
フィーチャートグルーの話が面白かったなっていうのがあって、
フィーチャートグルーって多分、
ECとかそのウェブサイトの界隈だと、
当たり前のことなんですね、きっとね。
なんか不当然のように話されてたから、
ken
なんかでも、私の界隈にはない単語だったから、
shino
なんかこういう、なんだろうな、他の業界での常識みたいなのが、
垣間見れたのがすごい良いなって。
ken
確かに、確かに。
shino
すごい面白いし、
なんか、なんだろうな、
その業界では、え、でもこんなのは普通にできるじゃんみたいな、
言われても、いや、うちの会社ではできないですみたいなね、
そういうのも。
やっぱその身軽さとかも全然違うんだろうなっていうのがあって、
なんか面白そうだな、他の業界覗けるのがすごい面白かったですね。
ken
それもある。
そのフィーチャートグルーの話で言うと、
多分結構ビジネスモデルも影響してるのかなと思ってて、
例えばその、なんかオブザーバビリティ関係のプラットフォームアザーサービス作ってたりとか、
うちみたいにエンタープライズが使ってくれてるようなECのツールを作ってるとすると、
例えば大きい会社、この会社Aに対してだけロールアウトする機能とか、
エンタープライズだけにロールアウトするみたいな、
エンタープライズカスタマイズの課題
ken
エンタープライズカスタマイズみたいなのがどうしても出てくるんですよね。
そこを切り分けるときにif部分を書きまくるんじゃなくて、
UIからボタンをトグルしてロールアウトがコントロールできるような
フィーチャーフラグ的な仕組みを入れると楽っていうのがあるんですけど、
個別エンタープライズに別に物を売ってるわけじゃない、
例えば自分たちのプロタクトをバーンってやってユーザーに売るだけとか、
あと全然別の機関システムとか作ったりすると、
そもそもそういう個別カスタマーの切り分けが必要なかったりするので、
そこも会社の業界の違いかなっていうのはすごい話だと思いましたね。
shino
なるほどね、確かに。
ken
私結局if分を書いてないとはいえ、条件分岐が増えるだけなので、
SR的にはめちゃくちゃ嫌な機能で。
shino
そうなんですか、そうなんだ。
ken
なんでこのエンタープライズは障害が出てんのって、
切り分けてみてソフトウェア開発者に行くと、
これちょっと昨日ロールアウトしたフィーチャーフラグオンにしてね、
この人たちだけみたいなのがあったりするんで、
そんなパターンがあるとね、みたいなのが結構あったりするんです。
要するに条件分岐というか、ケースが増えるので。
shino
そっか。
ken
シンプルではないですよね。
shino
なるほどね。
やっぱ面白いな、人の業界の話。
ken
ね、面白いですよね。
そんなところかな、パート2は。
古典的な書籍の読書希望
ken
じゃあ、なんか宣伝しちゃうこととかありますか?
言っときたいから。
shino
いや、特にないですね。
3回目だし、
1回目と2回目でいろいろ話したからいいかなって。
ken
ありがとうございます。
ちょっとまた雑談会とか出てください。
shino
出ます、ぜひぜひ出させてください。
また、リンロックじゃないわ、ブッククラブさん参加したいです。
ken
ありがとうございます。
今ね、結構、なんかその、やっていく本を選んでいて、
いい本があったらやるって感じにしたいんですよね。
いい本じゃなくても何か無理矢理習慣化してやるっていうよりは、
いい本があったらやるみたいな。
shino
なるほどね。
ken
参加したときの満足度の方が何かこう、
ただやるっていうよりはいいかなと思ってて。
うん、確かに。
本の選定をしてるんですけど、
どうですか、何かその、今、
積読リストに入ってたり、もしくは読み直したい本とかあったりします?
shino
えーの、1個ね、やりたいっていうか、
私これ、1人じゃ読めないなっていう本があって。
ken
何ですか?
shino
ちょっと待ってくださいね。
ミスティカルマンマンスって知ってます?
ken
結構古い本じゃないですか。
shino
そう、めっちゃ古い本。
多分古い本だから難しいんですよね、きっと。
でも、これって何か、
みんなが知って、何かすごいクラシックというか、
みんなここから派生していったみたいなとこがあるじゃないですか。
ken
なるほどなるほど。
古典を読むみたいな感じで。
shino
そうそうそうそう。
絶対1人じゃ読めないなって。
ken
確かに確かに。
shino
1975年らしいんですけど、初版が。
ken
英語とかも結構モダンな英語じゃないから。
shino
そう、きっともっと。
ken
うん。
shino
難しいけど、名言がたくさん出てるじゃないですか、この本から。
うんうん。
ね、僕のシルバーブレッドとか。
ken
よく引用されたりしますよね。
shino
そう。
何か1回読んでおきたいなと思いつつ、
ちょっと手が出てないから何かもし、機会があればね。
確かに。
ken
ねー、私ちょっと検討してます。
ちなみにそれを読もうと思ったのは、
なんかそのいろんなとこで引用されてるからってことですか。
shino
そうですね。
なんか、けなしき言ってるとやっぱり何かそこから出てる。
何だろうな、やっぱりみんなが読んでおくべき名著みたいなのを
1回読んでおきたいっていう、ちょっと身早なところがあるので。
うんうん。
達人プログラマーとかもそれこそまだつんどくにあるんですけど。
あーわかるわかる。
ね、もう読んでおきたいなっていう。
ね。
うん。
ken
確かに。
なんかあの古典とかも、
あれを読んだ上で当時の状況を推測して読みつつ、
今のコンテキストに置き換えるとこういうディフがあるよねとか、
こういうところは活かせるけど、
ここはちょっと古いかもねみたいな議論ができるといいですよね。
shino
確かに。
あとここちょっと読み取れなかったから、
なんかどうなんだろうみたいなね。
ken
うんうん。
shino
確かに。
ken
はい、アイデアありがとうございます。
shino
ぜひぜひ。
はい。
ken
はい、じゃあということでタイディファーストパート2の振り返りをしのさんとやってみました。
ありがとうございました。
shino
ありがとうございました。
