ken
shino
{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">
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
なかなかハードルの高さと得られるものと、
あとそのドロップ率のトレードオフなのでそこが難しいですね。
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
あとそのプロダクトの機能実装のデリバリーとかプライオリティを考えたときのタイミングっていうのを、
リズムという表現をしているというのが個人的にすごいユニークだったというか面白かったなと。
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
チームごとにってこと。
チームっていうのはコンテキストを理解しあえてるから、そこに入れていくのは早いよねっていうことか。
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に対してだけロールアウトする機能とか、
エンタープライズだけにロールアウトするみたいな、