00:02
財布を新調して、財布が薄くなって、カード入れが減ったんで、マイナンバーカードに免許証を統合して、マイナ免許証にして、カードの枚数を減らそうとしたら、いろいろあって失敗しました。MKです。
おだしょー えっと、今日ワイヤードのYouTubeチャンネルに小島秀夫監督の〇〇だけど何か質問あるシリーズの動画が上がっていて、非常に体験というか内容が良くて良かった、面白かったです。はい、としでーす。
ちょうど今日公開されたやつなんだ。 今日だったはず。
リンク後で貼っておきます。 なるほどねー。
ゲームクリエイター小島秀夫だけど質問あるってやつだね。
あ、そうか。あれ?質問ある?これワイヤード?
ワイヤードのテックサポートっていうシリーズか。 そうそうそう。
なんかだいぶ前のワイヤードに小島秀夫出てたんだよな。多分デススト2が発売したタイミングのワイヤードかな。
今年の6月か。なるほどね。
さっき言った理由でマイナー免許証にしようとしたんだけど、
マイナンバーカード自体の有効期限が10年で、その中の電子証明書の期限は5年らしいんだけど、
ちょうど来年の4月の僕の誕生日が10年のカードの有効期限で、
このタイミングでマイナー免許証にしてしまうと、
要するにマイナンバーカードの更新っていうのができる期間が決まっていて、
でも今マイナンバーカードの運用が回ってないから、
2ヶ月とか待たされますと、新しいのをもらうまでに。
もし新しいのをもらうのを待ってる間に、
10回目の誕生日がマイナンバーカードの有効期限なんで、
2026年の4月6日が来た場合、マイナンバーカードが有効期限になって、
つまり有効なマイナンバーカードを持ってない状態になりますと。
その時にマイナ免許証にしていると、免許不形態の状態になるらしくて。
免許証自体は持ってるんだけど、免許不形態っていうのがあって、
免許持たずに車運転したら罰金確か2000円ぐらいかな。
点数はつかないからゴールド免許とかは大丈夫のはずだけど、
違法なのよ。そういう状態になるんだって。
03:06
危ないな。
僕が今そういう状況だから、
自動車免許の更新のタイミングとは関係なくあれできるんだけど、
マイナ免許証に。
だからやりに行ったんだけど、そういう説明を警察署の人にされて、
泣く泣く帰ってきたっていう。
なるほど。難しいね。
てかね、いつの間にか警察署もキャッシュレスになってて。
免許の更新とか、
去年車買った時は車庫証明とかやったんだけど、
車買うけど路上違法駐車しないようにちゃんと駐車スペース持ってますよっていう証明。
を警察署に行って去年やったんだけど、その時の手数料は収入因子っていうので払ったのね。
なんか警察署の外にちっちゃい建物があって、
なんか警察の人に皆さんあちらの方に行かれますねって言われて。
あちらの方の建物で収入因子っていうのを買って、
その収入因子を免許の更新だったら更新の申請書類だし、
車庫証明だったらそれの申請書類とかに貼ってお金払うって感じだったのが、
今なんか普通にイオンモールとかにあるようなクレカの端末みたいなのが警察署にあって、
そこでお金払うっていう。
俺一回お金払っちゃった後にその話をされて、じゃあやめますって言ったのね。
でさ、ないじゃんそんなこと。クレカの取り消しなんて警察署で。
普通のアパレルのお店とかだったら返品とかってやっぱあるからさ、
慣れてんだろうけど業務不老として。
でもなかなかないことだから、なんか警察の人めっちゃなんかアタフタしてて、
最終的に5人ぐらい集まってきて、なんか喧嘩してんの僕の前で。
これだからこのボタンを押してもうそれで終わりでいいんだってみたいな感じで言ってる人もいれば、
いやいやいやもう1回あのクレジットカードを、
同じカードをタッチしてもらわないと取り消しにならないんだってとかって喧嘩し始めて。
あの現金で返金する方が早ければそれでもいいんですけどって言ったら、
いやそれはダメですよみたいな感じでめっちゃ待たされて。
貴重な皆様の横浜市民の皆様の貴重な税金を、
僕のマイナー免許証失敗のせいで無駄にしたことをここにお詫びしますっていう感じだったわ。
06:02
いやー私のために争わないでだね。
本当に。
なんかだからその、皆さんあちらの方に行かれますね的なことにさ、
大人の事情があってそうなってんのかと思ったらさ、
普通に警察署でキャッシュレス、警察署が直接お金をもらうっていうのがOKってなるんだったらさ、
いよいよあの収入因子っていうのは何だったわけって思っちゃうんだけど。
収入因子、何のためのものなんだね。
いやそう、だってそうだよね市役所とかだって収入因子ないもんね。
ないね。なんか住民票払う、発行する時とかも、
あの普通にお金を、その時は現金だったけど現金を手渡しで、
会計してくれた気がするから。
いやそうだよね多分千歳市役所だとその場で住民票を発行って200円とか300円だっけ。
なんか普通に100円玉渡した記憶があるし、横浜市役所は同じ建物のカウンターのすぐ後ろに、
あのなんか牛丼の券売機みたいのがあって、そこで200円券300円券っていうのを先に買って、
それでやった気がするな。
収入因子とか何なのか。
収入因子マジで、あのやっぱあれかな、皆さんあちらに行かれますね、
あの人たち用のなんかこう、職を確保するための概念だったのかな。
ありえるね。
よくわかんない札をね、札を持っていってね。
キャッシュレスで失業かな。
いやマジでね、青葉警察署の隣にね、あちらに行かれますね的なね、
2階建てのプレハブみたいのがあってね、
多分収入因子以外の用事は多分ないと思うんだよな、その建物。
どうなんだろうね。
すごいな。
何やんだろうなあそこ。
いや気になるわ。
朝早くから並んで。
みんな並んで整理券をもらって。
で、いろいろ終わったらあちらに行かれますねってこう。
え、パチンコって打ったことある?
ない。
俺もなくてさ、だからさ、
あの、どこにあんのかわかんないんだよね。
全然わかんない。なんか昔、
母方の祖母、祖父がすごいパチンコが好きで、
あちゃんパチンコ打ってくるからねって遊びに行った時とかも夜になると言って、
最後母と一緒にアイス買いに行くがてら、迎えに行くっていうのをやってたんだけど、
09:02
その時になんかあちらに行かれますね的なことやってたはずなんだけど、
なんか、
水曜その仕組みはわかんなかったし、
未成年だから入れるわけもないんだけど。
なんかちょっとわかりにくいところにあるらしいね。
そうみたいね。
パチンコ屋はな、僕入ったことあるんだよね。
うちのお父さんがよくね、
出先で街とかに出かけた時に、
トイレに困ったらパチンコ屋に行くといいぞって言ってて、
綺麗だから。
だから入ったことは何度もあるんだけどね。
トイレのためにね。
でも、ルールすら知らない。
ルールも何もないからあれ回して、
なんかあのいいとこに入ったら、
玉がいっぱいもらえて、
でその玉は、
直接お金にならない方が一旦なんか、
景品になって、
特殊景品か、特殊景品になって、
で、みなさんあちらに行かれますねのとこに行って、
それ現金になんかするみたいな。
魔法の力でね。
現代の錬金術と言っても囲んではない。
これあれかな、
パチンコの話したから、
一応ポッドキャストってそのなんか、
R18的な話をした場合はタグをつけなきゃいけないのよ。
番組ごとでも、
番組に丸ごとつけてもいいし、
番組自体はそうでもなくても、
特定のエピソードだけ、
そうだった場合はそういうタグをつけなきゃいけないんだけど、
これつけたほうがいいかな、パチンコの話したから。
つけておこう。
ギャンブル。カテゴリーギャンブル。
まあそんな感じで、
はい。
モノレポ?
モノレポ、ポリレポ、ロンソ、マルチレポ?
モノレポじゃない方はいろいろ言い方あると思うんだけどさ、
最近仕事でやってるプロジェクトで、
モノレポ構造で行動を管理するようにしてみたんですよ。
モノレポ構造で何管理してるかっていうと、
アプリケーションのコードはもちろんのこと、
インフラのIAC、テラフォームのコードとか、
あとはミドルウェア、
僕の環境だと使ってるのログルーターとか、
ETLツール、エンパルクとかね、
そこら辺も全部同じディレクトリ、リポジトリで管理しましょうっていう風にして、
やってみてるんですよ。
チームの状況としては、僕含めてエンジニア2名プラス1、
他のチームから一瞬だけ借りて手伝ってもらってるメンバーがいて、
3人でやっていて、
領域ごとにフロントエンドはこの人とか、
インフラはこの人みたいな感じじゃなくて、
チーム全員で全ての開発になって進行してるような
12:00
プロジェクトの状況なんだけど、
っていうところでモノレポやってみましたみたいな感じです。
今時ね、この人はフロントだけ、この人はバックエンドだけってしないよね結構。
みんな全部書こうぜって流れだよね。
特に事業会社って、
そんなにでかい組織にもなりにくい場所によるんだと思うんだけど、
うちの場合は1個のチームがすごい小さくて、
1個のプロダクト、内室事業になってることが多いので、
チーム全員で全てのことをやりましょうみたいな、
果て付けのことが多いですね。
っていうので、そういう背景もあって、
じゃあもう全てのことをやるんだったら、
1つのリポジトリにコードがまとまっていて、
必要に応じて参照できるような形にしておいた方が便利なんじゃないの?
と思ってやってみたっていうのが考え方って感じですね。
僕が実際にこのモノレポ、3ヶ月くらいモノレポでやってるんだけど、
実際にやってみた感じと、
もともとモノレポっていうものに対して抱いてたイメージみたいなのの、
現実とかギャップとか、これはこうだったみたいな話、
ちょっとしていこうかなと思っていて、
最初に、例えばアプリケーション、
例えばRailsのアプリケーションを書いていて、
何かしらインフラ触んなきゃいけないみたいな、
例えばSQSとかSNSとか、GCPだとPubSubとかね、
そういうものを触んないといけないようなケースにおいて、
結構IDEをまたいだり、エディターをまたいだりして、
例えばRubyMineでアプリケーションコードを書いて、
VSコードでテラフォームを書き回すみたいな作業が発生したときに、
ツールをそもそもスイッチしなきゃいけないっていう、
ちょっとの手間あるし、
検索、この構成って今どうなってんだっけみたいなときに、
アプリケーション側からその構成を見たいときと、
インフラ側からアプリケーションどういうふうに設定を参照してんだっけって見たいとき、
いくつかあるじゃないですか、みたいなことをするときに、
手間が減るのでハッピーになりそうだなと思ってて、
確かに減るんですよ、すごい楽なんですよね。
一方で、これはコードが一個のリポジトリにまとまっている弊害なんだけど、
BuzzyFinderとかRubyMineとかIntelliJだと、
Shift2回押すと何でも検索ってあるじゃないですか、
あれとかでバックエンドのコードみたいのに同じ行為を使っているフロントエンドのコードをヒットしたりして、
これじゃない、これじゃないって言ってまた検索し直すみたいなことがあったりとかっていうので、
ちょっとそういう検索の難しさはあるなみたいなのが、
実際やってみると出てきたりとかっていうのがあって、
確かに便利だけど、考えなきゃいけないことは増えるなみたいなのが、
15:01
実際にはありましたとかね。
バックエンドのコードを触るんだったら、バックエンドスペースなんとかってやると出てくるんだけど、
単純にタイプ数増えるんで、コマンドシフトでツール切り替えるのとどっちがいいんだろうっていうのはちょっとどっこいどっこいぐらいなのかなみたいなのが、
やってみて思った、ここら辺の感想ですね。
インフラのコードとかを実際触るときってさ、
人の環境にもよると思うんだけど、別のエディタツールとかを開いてやったりしてます?
いや、RubyMineのままだな。
RubyMineのままで複数のプロジェクトアタッチしてやってるような感じかな。
アタッチってか別ウィンドウで開いてるな。
あー別ウィンドウでRubyMineを開いてってかとか。
そうそうそう。
そうだよね。僕ももともとそっちでやってて、
今回モノレポなんで一つのエディタの中で触れるんだけど、さっき言ったみたいなことが起きたり、
あと単純にファイルツリーが縦にすごい長いから、
自分の今カーソルしてるファイルが今どこのなんだっけみたいなのを結構迷子になることも多くて、
そういうのは難しさとしてあるなーみたいな感じでした。
なんかモノレポ用のツールみたいなのって使ってる?
いや、使ってないかな。
単純にディレクトリは書いてるだけ?
うん。
バックエンドがRailsでフロントはJSでって感じだよね?
うん。
そうだね。
なるほどね。
なんかモノレポって聞いて一番真っ先に思いつくのは僕ライブラリ系のやつで、
例えばAWS CDKとかはCDKで、
タイプスクリプトとかPythonとかでいろんなAWSのリソースを扱えますっていう感じになってて、
S3ならS3、EC2ならEC2で一個一個が一応パッケージになってんだよ、NPMの。
なんて言えばいいんだろう?
NPMインストールってするときの一個一個は別のパッケージなんだけど、
でもリポジトリは一つでっていう感じで。
リノベートとかGitHubがやってる、なんだっけ?
GitHubがやってるリノベートってなんだっけ?
Dependabotだ。
とかでサブ見るときに若干うざいなって思うみたいな。
そういうのを結構思いつくなって思いながら聞いてて、
18:00
自分たちのプロダクトを作るときのモノレフォーマーしか。
でもそうね、確かに、
JetBrains IDEだけに絞った話で言うと、
多分JS書くことそのものって全部のエディターでできるじゃん、ちゃんと。
できるね。
RubyMineでPythonを書くのはちょっと大変なんだけど、
なのでPython書くときはPyCharm使うけど、
でもJS書くときはWebStormを起動するかって言うと僕はそうではなくて、
WebStormにイメージ的にはRubyMineとかPyCharmとかって、
WebStormにその言語特有のいろんな機能が乗った感じになってんじゃん。
だからRuby書くときはRubyMineで、
JS書くときはRubyMineでそのまま書けるなっていう感じがあって、
そのときにモノレフォーだと別ウィンドウで開く必要がなくてめっちゃ便利だな。
マルチェラフォームとかはプラグインでれば書けるから、
そうだね。
っていうのができて便利だよなっていう気はする。
そうですね。
私最近のエディターツール、VS Codeに始まりCursorとか、
VS Codeベースのエディターツールとかっていうのは大体マルチランゲージサポートで、
一個のプロジェクトの中にいくつの言語があってもちゃんと機能するようになってるので、
そこら辺はツールのこれこれっていうのはあんまり影響なく便利に使えてよかったなみたいなのがありますね。
あとはこのモノレフォーの記事とかをいくつか見ていて、
LMのコンテキストを渡しやすいんですみたいな話をよく見てて、
確かにそうだなって思うし、実際やりやすかったんですよ。
例えばバッジ処理とかをStep FunctionっていうAWSのプロダクト使って、
こういうふうにやりたいですとか、このデータはこういうふうに渡ってきますよみたいな構成の情報を
いちいち与えなきゃいけないみたいなパターンの時に、
これはこのStep Functionから実行される想定なので、構成を参照してデータ構造を分析して、
入力がどうなってるのかみたいなことまで踏まえてこういう仕様で処理してくださいってやると、
結構その通りに素直にRailsのバッジ処理を書いたりしてて、
そういう意味でやりたいこととか関連するコードとかを含めて、
LLMに渡しやすいっていうのはめちゃめちゃモノレポのメリットだなと思いながらそれを享受してやってたし、
初回のプロンプトである程度のコンテキスト渡したらその依存をちゃんと辿ってくれることが多くて、
LLMが、というかAIエージェントが暴走して何か変なことをするみたいなのが結構少なかったなっていうのが初感としてあって、
21:07
これはめちゃめちゃメリットだなと思いながら使ってました。
たしかにStep Function、ラムダとかをジューズ繋ぎしてピタゴラスイッチするやつだと思うんだけど、
たしかにStep Functionとかに関しては普通にやればモノレポっぽい感じになる。
Step Functionで束ねられる前提でラムダファンクションを量産するってなった場合、
意識しなくてもモノレポっぽい感じになるし、そこにLLMが加わるとたしかに、
勝手に各ラムダファンクションの入出力とかを見て、はいはいはいつってステータマシン書いてくれるのやばいな。
めっちゃ便利だし、Step Functionのステートランゲージって言うんだっけ、
あの構成書くのって結構慣れが必要だし、癖強いじゃないですか。
入力のパラメータをJQのダラーから始まる表記でこういう風にやりましょうとか、
こういう時はこのパラメータしか渡せませんみたいな時とかも、あれ覚えたりリファレンスを見たりするの結構大変だったから、
それが自動化できて、かつアプリケーションともインフラとも繋ぎやすいっていうのが、
本当にストレスなく開発できてよかったなと思ってます。
めっちゃいいな、確かにな。
そっか、ステータマシンのあれ、僕CDK経由でしかStep Function扱ったことないから。
なるほど、なるほど。
何だっけ、何ランゲージって言ったっけ。
ステートランゲージかな。
みたいなやつも多分僕タイプスクリプトで書いて、あとはCDKが勝手にビルドしてくれてる気がするな。
はいはいはい。確かにね。
でも確かに、成果物としてそんなのが出てたような気がしなくもない。
それを確かに空気読んで勝手に書いてくれるのは素晴らしいね。
めっちゃ素晴らしかったです。
はいはいはい。
みたいな感じで、LLMで少人数でいろんな機能作るときはコンテキスト渡しやすくて超便利ですね。
次、設計とか調査結果、API仕様とかね。
ここら辺含めてドキュメントをいろいろ作ると思うんですけど、
僕らの場合はドキュメントも1個のリポジトリに入れてて、
例としてはデザインドック、設計ドキュメントだね。
設計ドキュメントとか調査結果とかでは、
ここのWebhookからこういう仕様でこういうものが飛んでくるのでこれ使えば大丈夫ですみたいなのを結構ドキュメントとしてマークダウン書いて残していて、
24:02
今までだとNotionとか社内のドキュメントツール使ってやってたんだけど、
今回は思い切ってリポジトリの中に全部まとめるっていう判断をしてみましたというのがあって、
これもいろいろ世の中にあるモノレポに対する言及のあるテックブログとかから見て、
リポジトリまとめの方がいいなと思ったんでやってみたんですけど、
実装とドキュメントの内容が常に一致してて、
それを参照すればシステムの全体像であったり、
例えばインフラだったりインフラはこの構成でとか、
フロントエンドはこういう戦略でみたいなところがキャッチアップしやすいっていうのがあるなと思ってたんで、
その効果を狙ってやってみましたという感じです。
結果から言えばそれは言えると言えるし、そうとも言えるしそうとも言えない。
なあと思ったっていうのがあって、
新規メンバーが途中から参加してくれるっていうタイミングが2回あって、
1人は復帰してくるタイミングで、もう1人はヘルプで入ってくれるってタイミングだったんですけど、
確かにその人にお願いする領域の参入コストというかキャッチアップコストみたいなところは明らかに低い。
コードを見ながら、ドキュメントを見ながら方針を理解できるんでいいなと思いつつ。
ただ一方でそのキャッチアップに必要なドキュメントを常にメンテナンスし続けることが非常に難しい。
俺はどんなドキュメントツールを使っていようとやっぱ同じなんだなっていうふうな感想を持ったんだけど、
少人数で実装もドキュメントも調整もいろいろしなきゃいけないっていうところがあるので、
常に正しい状況を作りながら実装を進めて、何か仕様が変わったり方針が変わったときにそこをアップデートしてっていうのを、
いろんなところでコミュニケーションしたり、ビジネス側とコミュニケーションするときにはGoogleDocs使ってコミュニケーションしますってことも結構あったので、
そういうものをディポジトリの中で同期させるっていうのがすごいコストのかかることだったし、
それがやりきれてないっていうのが一個あるなーっていうふうに思っていて、
単純なそういう抜け漏れもあるし、細かな語彙とか表現による不一致で誤解を生んでしまって、
あれ実はこう思ってたんだけどみたいなのがチーム内で生まれてしまったみたいな課題もあったし、
あとは配線の部分で、小人数で結構厳しめの納期を目の前にして、
何かが変わったときにドキュメントをメンテナンスしながら同時に実装も変えてテストやってデプロイしてみたいなことをやってる体力がもはやない、
そういうことをやってられる状況ではないみたいなことも状況としてはあって、
27:00
というので、ドキュメントのメンテナンスっていうのがやはり課題なのかなっていうのがあるなと思っています。
これっていうのは、例えばAIの力借りるっていうので解決できるのかなと思ったけど、
今まだ導入できてないんでやっていきたいなっていうのが振り返りと、今後やるならこうしたいっていうので、
GitHub Actionsとクロードコードの組み合わせだったりとか、クロードコードのスキルズだっけ、
フックとかそこら辺のガードレール機能をうまく使って、
ドキュメントとうまく一致させにいくとかっていうのはやれるんだったりやったほうがいいなっていうのが振り返りというか反省というか、
ありますなーっていうのがこの話ですかね。
そうね、なんかさ、AIがガツガツ実装を変えてきてそれにドキュメントが追いつかないというか、
AIじゃなくて人間が実装しててもそれはそうなんだけど、
結構あれだよね、クロードMDとかにドキュメントちゃんと更新してくださいとか、
コミットある程度まとまったらコミットしてくださいみたいなって書いてるんだけど、
ちょくちょく無視されるから、
ちょっとスキルズっていうのが、スキルズもあれだよね、クロードMDと同じっちゃ同じだよね。
そのはずかな。
支援読み込みしてくれるみたいな感じだっけ、違ったっけ、スキルズちょっと俺まだ解像度が低いんだけど、
スキルズとかあとはフックス、フックスは強制でやらせることだからフックスかあるいはアクションズ、
そもそもクロード構造の外のどこかで強制の仕組みを使ってガードレールを整備するっていうのは確かになってのは思ったのと、
あとなんかさ、そのドキュメントでいうとちょっとモノレポとかAIの話からずれちゃうけど、
最近なんかADRっていうのが流行ってんじゃん。
アーキテクチャーディシジョンレコードかな。
そうそうそうアーキテクチャーの意思決定の、だからなんかこうレコードって言ってるのが何かこうミソなんじゃないかなと思うんだけど、
結構世の中のADRの例を見るとADR00に何々をするコンテキスト何々決定何々みたいな。
それを残すことを何かクロードにフックスとかで強制しつつ、
ADRだとなんかこうさ、ADR積み重ねだからさ、多分。
俺書いたことないからちょっと全然違うこと言ってたら申し訳ないんだけど、ADRっていうのは積み重ねであるから、
なんかこうADR、全ADRを踏まえた最新の設計ドキュメントっていうのを例えばGitHub Actionsで回して作るとか、
30:07
だからちょうどNailsのデータベースのマイグレーションファイルとスキーマRBみたいな。
そうだね。
そういうのとかにするといいのかなっていう妄想はした今。
確かにADR積み重ねて個々のADRに関連する場所をいじるときは、
そこが一致しているかアップデートされているかのチェックをすればいいし、
全体像のドキュメントが変わるケースがあるんであればそっちも変えて、
普通に全体のドキュメントの情報が実装と一致しているみたいな状況を作れそうだよね。
だんだんADRなんて大げさなものじゃなくてもGitHubのプルリクエストのディスクリビションがそれっぽいやつだから、
例えばあるプルリクエストがマスターに回避されたときにディスクリビションとかコードのDiffを参考にして、
この設計書を更新するプルリクを自動で作るとか、なんかそういうのがあるんかな。
確かに。
僕が直近に3ヶ月くらいやってたプロジェクトはNotionでドキュメントやってて、
クロードコードのNotion MCP使って、クロードコードにNotion MCPを認識させて、
この設計ドキュメントの通りにやってとかっていう、そのNotionからクロード側に情報インプットはしたんだけど、
その逆を全然してなかったから。
今Notionのドキュメント腐ってるんだよな。
僕らも3人で開発してて、ハドルとか繋いで毎朝連携しながら話してたから、
もうみんなの頭の中では完璧に認識あってんだけど、
この間一通り開発終わって一息ついて設計書見たら嘘しか書いてなくて。
起きるよね。
いやこれしかもさ、もう納期間に合ったーっつってさ、もう肩の力抜けてるタイミングだから今からドキュメント更新しようってならんって。
そうなんだよね。もう達成感とさ、その終わったーという開放感で、
ドキュメントを更新して今の実装に合わせるような形で整理し直そうっていうのができないよね。
なかなか難しいわ。人間の心理的にもそうなんだろうとは思うんだけど。
まあでもその更新したドキュメントが未来の自分を含む他人に迷惑をかけることになるからね。
それを何とかしてから年を越そうとは思ってるけどね。
いや本当にそうなんだよね。なんか行動はさ、HowとWhatであるみたいな話あるじゃないですか。
HowとWhatだっけ?何を表現してるのか。
それTワラさんのコミットメッセージには怖いよみたいな文脈の話?
33:06
そうそう。
そうなんだ。それドキュメントもあるんだ。
ドキュメントにはWhyを書いて、なぜこうしなきゃいけないのかみたいな背景と、
そのなぜを解決するためにはこういう方針を取るみたいなのを書いて、
その実装がCodeであるからみたいなのがどっかで議論されてたなと思ってて、議論というか言われてたなと思ってて、
やっぱそのWhyの部分がずれてたというか、実装とずれてると、
これなんでこうなってんだろうみたいな、実装の背景をちゃんと構成に伝えられないみたいなのが結構あって、
それを僕はこのプロジェクトはリプレイスプロジェクトというか既存のものを新しく作り直すプロジェクトだから、
作り直すものがどういう背景から作られていたのかみたいなのを結構調べなきゃいけないことが多くて、
ちょっとWhyというかなぜなのかの部分がなかなかキャッチアップしにくい環境とかがあったんで、
そういうのはすごく思いながらドキュメントをリポジトリに加えたんだけど、
結局自分もWhyを残せていないというのが悔しい部分だなと思ってます。
これ最後に思ってたのがCIが遅いってよく言われるなと思ってたんだけど、
実際には僕らGitHubにホストしてるから、
アクションを使うんですけど、GitHubアクションを使うんですけど、
その場合パスパターンとかでどのアクションこれは実行する、これは実行しないっていうのがチェックできるので、
全然困らなかったなっていうのがありましたと。
例えばフロントエンドのコードを変更したらテラフォームのチェックも走るし、
レールズのRスペックも全部走るみたいなことは起きないってことだね。
そうだよね、GitHubアクションでのワークフローの山手ファイルのオンとかでいろいろ書けばそうやってできるよね。
パスパターンだったかファイルだったかな、パスパターンかなみたいな項目で設定できるので全然課題にはならなかったなと。
リポジトリが小さいっていうのもあるんだけど、あるかなと思いつつ。
ただじゃあ他のCIツール使ったりしてるところは同じくできるのかって言われるとちょっと分からないので、
もしかしたらこの製品はこれができないみたいなので同じ問題が顕在化するかもしれないなっていうのはちょっと一個思ったくらいですかね。
はい。
なんかリリースの単位は、モノレポでリリース単位とかを結構気にするというか、なんだろうな。
36:06
CDの方か。
なんて言えばいいんだろう、リリースタイミングがずれ始めると辛くなるみたいな話はよく聞くけど。
ちょうど今ググって出てきたのが、トシが貼った記事だったわ。
マルチレポVSモノレポっていうやつかな。
今のところ、そうそうそう。リリースタイミングの違いが運用コストになるみたいな。
そういうのとかは今はない?全部リリースタイミング一緒?
そうだね、まだリリースタイミング全部一緒だね。
はいはい。
なので、バックエンドとかの機能が重くなったりとか、関連するものが増えたり、関連するもの同士が更新されるタイミングがずれたりし始めると、
リポジトリの中でのデプロイの仕方が複雑化していって、管理しきれなくなって、これちょっと辛いねってなるのはちょっと未来としてはあるかなと思うし、
予測できるなというのはすごい感じる。
これ結論のそのモノレポ、ポリレポ、マルチレポ、どれがええんっていう話は、
やっぱりチームとか事業とかそのプロジェクトの置かれている状況、会社の中での状況とかによって、
もう一端以外の階はないかなっていうのが、ようはバランス王子さんみたいなことを言ってんなって自分でも思ってるんだけど、
これ以上ないかなと思っていて、
今回は僕はチームが小さくて3人しかいないところで全員で全部をまかなうっていう風にやっていて、
その場合はやっぱりモノレポのメリットが圧倒的に強いなと思いつつ、
例えばチームの人数、関わる人が増えていく。
チームの人数が例えば3倍とか4倍になった時に、
全員が全員、例えばフロントエンドしかやらない人がいるのに、
インフラの知識を常にコンテキストとしてリポジトリに持っておく必要があるのかって言われたら、
ちょっとそれは無しかなと思ったりするので、
どんどんリポジトリが分割されていくんだろうなみたいなところで、
チームの状況、プロジェクトの状況で使い分ける必要があるななんて思っているし、
リポジトリ設計からやっぱりソフトウェアの設計っていうのは始まっとるのだなというのが初感としてあります。
っていうのが結論ですかね。
ここまでいろいろ話したんですけど、
今MKからも言及があった記事、
MetaPSアドベントカレンダーっていう、今年の2025っていう
メタプスだわこれ。
メタプスか。
39:00
この会社のことすごく知ってるけど、
すごく知ってる理由はここでは言わないで僕は。
全然ネガティブな意味じゃないんだけど。
ネガティブな意味じゃないんだけど。
会社のアドベントカレンダー2025の17日目の
マルチレポVSモノレポという記事にすごく上手に丁寧にまとまっているのを観測していたので、
この記事で提案されているものとかも含めて、
今後はいろいろ実践できればなと思ったっていうのが僕の最後の感想ですかね。
びっくりした今ちょっとなんか、
ちゃんとプレスリリースが出てることだからちゃんと言っていいか。
この会社さんがやってる事業のうちの一つを、
僕の所属している会社が事業上とされてて。
あーなるほどなるほど。
予想外のところからその会社の名前が飛び込んできて今びっくりしたわ。
なるほど。
はい。ということでモノレポとポリレポどうなんだみたいなのをちょっと話したくなったんで書いてみました。
はいはい。
なんか僕もトッシーもRuby on Railsを主に書いてて、
でフロントエンドリアとか書きますとか、
インフラ触るときテラフォーム書きますとか、
そういう感じの文脈だから今みたいな議論になったけど、
今度はタイプスクリプト界隈だと結構モノレポ進化というかなんて言えばいいんだろうな。
熱くて。
ターボレポとかっていうモノレポ用のツールが出ていて、
それをベースにするとデプロイの課題とかもすごい解決しやすいみたいなのは記事で読んだことがあるので、
フルスタックTSプロジェクトとかだとなんかちょっとまた違う視点が入ってきそうな雰囲気あるよね。
あとはTRPCみたいなのがあって、みたいなとかTRPCってやつがあって、
なんて言えばいいんだろう。俺扱ったことない。なんか検討しただけでもあったから。
RPCベースの。
ちょっと違うこと言ってたら申し訳ないんだけど、
要するにそのバックエンドもフロントエンドもタイプスクリプトで書いておくと、そのなんか通信の間のインターフェースというか、
インターフェースでいいのかな。
ちゃんと定義できて、それ共有できて、バックエンドとフロントエンドで型を共有できるみたいなのは嬉しくて、
もうそうなるとTRPC自体が結構モノレポ前提でみたいな。
42:03
話とかもあるみたいなんだけど、ちょっと僕の知らない世界なんで。
プロトコルバッファーでデータのシリアライズの仕方を定義しておいて、
リモートプロシージャーコール的な実装を置いておけば、
もうそのプロトコルバッファーの定義に従ってクライアント側はデータを受け取れるし、
アプリケーション側は呼ばれる関数を実装すれば、APIの実装になるんですっていう。
その乖離値がAPIのレスポンスとして使えますっていう世界観かな。
それをプロトバッフ使ってるのか、タイプスクリプトの型使ってるのかちょっと分かんないけど、
それでもクライアントとか関連するマイクロサービスなら、
マイクロサービス同士の通信がそれで全て定義できるので、
すごく便利に使えますっていう言葉と睨んだ。
大体そうだけど、多分プロトコルバッファーは使ってなくて、
普通のHTTPとJSONでやっててって話ぐらいかな。
GRPCだとプロトコルバッファーって、逆に俺GRPCは本当に全然知らないんだけど、
あれって多分HTTP2じゃないと動かないよね。
動かないかも。
あんまりWebのフロントエンドとバックエンドの通信では使わないイメージがあって、
バックエンド間のシステム連携で使われるイメージが僕はあって、
なぜかっていうと、別にフロントエンドとかでも使えようと思えば使えるのかもしれないけど、
なんでフロントエンドとバックエンドの通信でGRPCってあんまり使わないイメージなんだろう。
僕の理解だとGRPCってHTTP2じゃないと動かないんだけど、
CDNとか、あとはALBとELBってどっちが新しいんだっけ。
ロードバランサーとかSSLの終端をやるようなやつらがのきなみにHTTP2対応してなくて、
なんでGRPC使えないっていう理解を僕は知るんだけど、
それを置いといて、GRPCは普通にWebのフロントエンドとバックエンドを通信するのにも全然使えて、
それもあって、そのレイヤーの話で言うと単なるJSONを通信してるだけで、
多分型を共有できて嬉しいぐらいの話だった気がするの。
なるほどな。
で、あとグラフQL的な感じで、エンドポイント1つじゃなかったかな。違うかな。それは嘘かも。
いや、でもRPCだから多分そういうことだよね。
そうな気がします。
45:01
まあいいや、TRPCの詳細はいいんだけど、
今僕らはRubyでバックエンドを書いて、フロントエンドはTSです、リアクトですみたいな前提で話してたけど、
多分ね、全部TSでやる人たちはあらしたら、いやもうそれは俺たちは乗り越えた課題だからみたいな、
そういう感じかもしれないなっていう。全然知らないんだけど。
俺たちはもうRESTは卒業したけどみたいな。
なるほど。
とかも、と思いました。
でもそうだね、モノレポ話で、僕がモノレポじゃないものって何て言うんだろうと思ったっけ、ポリレポとかマルチレポって言うんだね。
モノレポ、ポリレポ問題で結構調べたのは、
どうやってフロントとバックエンドで型共有しようかなとか、インターフェースをいい感じにしようかなみたいな話だったんだけど、
それ言うと、Toshiの今やってるプロジェクトでは、バックエンドでAPI書きました、
フロントエンド側でWebAPIを叩くのに、何かリクエストとかレスポンスとかの型を書かなきゃいけないじゃん。
そうだね。
そういうのってどうしてんの?手で書いてんの?
僕のチームだと、Ruby側のツールとしてR-SWAGっていうツールがあって、
Rスペックの拡張みたいなもんなんだけど、これ使うとRスペック側にスキーマを書いて、
Rスペックでレスポンスタイプごとに200を返すんだったら200のテスト、400を返すんだったら400のテストみたいな感じで、
エンドポイントとステータス、コンテキストごとにテストを書けるR-SWAGっていうツールが存在していて、
これを使うと自動的にAPIスキーマをオープンAPIの3.0のスキーマをはけるんですよ。
初めて知った、素晴らしい。
というので、APIスキーマファーストにしつつ、APIのテストも実行できて、
かつ、SWAGとかSWAG.jsonみたいなのを常にCIとかで吐き出すこともできるので、
基本的にはAPIを変更するときはテストを変えなきゃいけないはずなんで、
テストを変えて、スキーマを変えて、実装を変えてテストが通れば、
常にデベロップには更新され続けた最新のOpenAPI.jsonが含まれているので、
フロントエンドはそれを参照しますっていう構造にしてます。
初めて知った、こんなのあるんや。
このR-SWAGめっちゃ便利で、好きなジェム何ですかみたいな質問があったとしたら、
絶対にR-SWAGって答えるぐらい僕は愛用してます。
いいっすね。
48:03
なんか、昔、多分僕がKiitaに書いた記事で一番読まれてるであろう記事であるところの、
Dales 5 APIモード、グレープたすグレープエンティティで作るWeb APIっていう記事と、
それの続きとしてのグレープスワッガー、グレープスワッガーエンティティで
Web APIのドキュメント自動生成みたいな記事があるんだけど、
それの現代版だね。
なるほど。
もう多分グレープ使ってる人、今あんまりいないと思うから、
普通にDalesのコントローラーで直書きして、で、スキーマは長らくあれかな、
直接OpenAPIのYAMLファイル直書きするしかないのかなっていうふうに思ってたんだけど、
なるほど、ちゃんとあるんですね、Rスワッグ。
そうなんです。あるんですよ、Rスワッグめっちゃ便利。
一個欠点があるなと思っているのは、Rスペック書くんですけど、
DSLが独自なんですよね、Rスワッグの。
そうだね、見た感じめっちゃ独自だね。
パスとかポストとかゲットとかっていうので、ディスクライブとかコンテキスト内部的に生成してるんですけど、
これがRubyMineとかのIDツールと結構相性が悪くて、
悪そう。
ジャンプできなかったり、ロボコップのリントとかも正しく反応してくれなかったりみたいなのが結構あって、
その辺はね、ちょっとあんまり自分も正しく整備できていなくて、課題がまだまだあるなと思いつつも、
APIのスキーマを常に最新にするという一点においては最強だと思ってます。
これでも、これなんだっけ、RスワッグのReadMeにあるGetting Startedの3番を今僕読んでるんだけど、コードを。
スペックリクエストブログズスペックっていうのがあって、ディスクライブブログズAPIのブログは普通のRスペックだよね。
そこからいきなりパススラッシュブログズっていうのがあって、これDSLで。
で、ポストなんちゃらっていうのがあって、レスポンスレスポンスレスポンス201レスポンス422ってあるんだけど、
これはだから、このDSLを読み込んでこいつを元にOpenAPIのスキーマが生成されるっていうのはわかるんだけど、
これは何かをテストしてるとかなわけ?
例えば認証が必要なAPIとかだったらそう?
認証っぽいところはbefore設に変えたりするの?これ追加で。そういうわけではないの?
します。できます。
するんだ。
で、AuthorizationヘッダーとかをAPIのスキーマでセキュリティ属性かな、セキュリティコンポーネントみたいなの指定しておくと、
51:01
ベアラートークンとしてAuthorizationヘッダー指定しておけば、それをランテストっていう、実際にリクエスト送ってテストするメソッドがあるんだけど、
それを実行するときにExampleのメタデータ集めて、そこからリクエストを構成して送ってくれるところまでやってくれるし、
レスポンス側、その指定したレスポンスステータスにHTTPステータスになってるかどうかのチェックと、
あとボディのスキーマチェックまでやってくれるんですよね、こいつ。
だから、ルートにUsersっていうのがあって、その下に配列でユーザーのオブジェクト、IDとかネームとかがあるオブジェクトが入っていて、
最後にページネーションがありますみたいなスキーマを定義したときに、
そのスキーマ通りになってるかっていうのをチェックできるっていう機能まで入ってます。
へー、なるほどね。で、かつ、それもその認証とかもSecurityっていうDSLで書けば、
多分、なんだっけ、OpenAPIのドキュメントって、
自分の認証トークンを持ってる人の場合、そこにセットして、そのドキュメント上で動かしてみたりとかできるじゃん。
できるできる。
そういうのの元データになるってことね。
そうです。
へー、なるほどね。なんかエンティティというか、エンティティとかはどこで定義するんだ?
レスポンス3の下のブロック、PathBlogs IDとかを見てもらうと、
レスポンス200のところに、スキーマ、タイプ、オブジェクト、プロパティスとかって指定してると思うんだけど、
これがそのレスポンスオブジェクトのスキーマになりますね。
へー、はいはい。で、その下のRequestParamsってところで、普通にBlog.createとかしてるね。なるほどね。
うんうんうん。
なるほどなるほど。これは良さそう。
結構良かったです。
ちょっとスキーマと、そうだね、YAMLファイルでスキーマを書いて、それと実装が離れてないことをテストする、なんだっけ、コミッキーとかだっけ?
あるね。
みたいなアプローチか、このRスワークみたいに、実際にAPI叩いちゃって、
このRスワーク自体がOpenMPのYAMLファイルを生成する拠り所としてあって、
そいつがちゃんと正しく動くかどうかみたいなのを、Rスペックの仕組みでテストできるみたいなののアプローチってことか。
ちょっと多分一番良いのは、全部TSにして型共有して、本当に全部自動生成とかなんだろうけど、
54:00
それはそれができないという前提においてはいいのかもね、これ。
それでまたLLMの話に戻っちゃうけど、
ちゃんとガードレールというか、そういう指示を与えられれば、その実装をそういう風に変えたんだったら、Rスワーク側も勝手に変えてくださいとか、
Rスワーク側勝手に変えたんだったら、フロントエンドのNPMのスクリプトで多分、
YAMLファイルからあれをリクエストでスポンサーの型を自動生成していると思うから、
それを実行してくださいみたいな。
ことはやりやすいね。
Rスワーク使ってみようかな。
チャック使ったりできるので便利です。
Railsヘルパーの代わりにスワガーヘルパーだったかな、みたいなのが自動生成されて、
そいつをリクワイヤーしている下では、このRスワークのDSLが使えるようになるんで、
一本のAPIから始めるとかも全然できるので、おすすめです。
ということで、みっちり技術ポッドキャストらしい話をしていました。
確かに。
今、Notionに貼ってあるディレクトリ構成を見てて、これは読み上げちゃって大丈夫?
ルートにアップディレクトリがあって、その下にバックエンドとフロントエンドがあって、
ドキュメント以下にまたデザインドックスとかがあって、
インフラストラクチャーディレクトリにステージングプロダクション、
これはだからテラフォームのモジュールがそれぞれ入っているみたいな感じかな。
ミドルウェアにETLツールのエンバルクのファイルとかが入っていて、
コンポーズ・ヤムルがルートにいて、これはあれかな、PosGreとかかな。
バックエンドのアップディレクトリとか。
この環境下ではメイクファイルをいかにちゃんと書くかが肝になりそうだよね。
そうなんですよ。
メイクファイルめちゃめちゃ重要で、
これ2ビルドしたいみたいな時にどういうワークフローにするかというか、
これとこれが事前に揃ってないといけないからこれやりますみたいなのを結構、
ただのプロジェクトコマンドツールとしてだけじゃなくて、
ちゃんと書かなきゃいけなくて、結構真面目にメイクファイルを今書いたりしてます。
なるほどね。
という感じですかね。
ちょっとモノレポ解像度僕だいぶ低いんで勉強になりました。
57:02
という感じですかね。
で、トッシーがおそらくこれが年内最後かな。
来週ぐらいから実家の方に寄生されてしばらく、2、3週間ぐらいいるって言ったっけ?
2週間ぐらいあっちに北海道にいます。
冬帰るのって久々?
めっちゃ久々。
じゃあ多分氷の上を歩くスキルが失われてるはずなんで。
そうだね。
怪我しないように気をつけては。
なんか最近ツイッターで道民は雪道を、つるつる路面をこう歩くみたいなのがバズってたね。
ずり足でザザザザザザザーって歩くみたいな。
確かに。
ちょっと思い出しながらやっていきます。
じゃあそんな感じで、今日はエピソード330かな。
お疲れさまでした。
お疲れさんでした。
