エンジニアの成長は楽しい学びからおもとに日々インプットした話題を話題内容学びを和やお届けするラジオになってますすべてお届けしましょうはい今日の話なんですけど使用駆動開発触ったら理解不細を感じたって話をします難しい言葉がいっぱい出てきた漢字漢字全部漢字すごいなで使用駆動開発って聞いたことありますまあ

うっすら まあちょいバズワードだと思っている うんバイブコーディングに続く主翼道開発だと思っている スペックドリブンデベロップメント デベロップメント はい ああそうなんですね そうですそうですでまず主翼道開発って何だよって話からいくんですけど はい あちなみに今日はその主翼道開発触ってるんですけど仕事じゃなくて趣味でやってて うん でまだ触ってる途中なんですけど うんうん

なのでそのぐらいの感じでお話をするのとあとAI駆動開発がっつりやってるのりさんとその主翼動開発の雰囲気をすり合わせながらこういうことかこういうことかっていう話をしつつ主翼動開発も銀の弾丸じゃないのでただ銀の弾丸じゃないですけどAI駆動開発ってこうやって変わっていくんだなの線がだんだん見えてきたと思うんですよ最初ってコパイロットから始まって

AIエージェントが出てきてバイブコーディングになってで主要駆動開発っていうAI駆動開発がある程度道筋が出てきたとってなると線が出てくるとだんだん延長線上どっち行くんだろうが見えてくるのかなと思っててそれの妄想を膨らませる回になってますっていうので主要駆動開発とはこれから行きます主要駆動開発なんですけど読んで字の落としなんでしょうじゅんぺくん主要を

元にAIにコーディングさせる樋口 はいその通り めっちゃ普通ですよね樋口 今までの開発と何が違うんですか? 順平に聞いてください樋口 本当ですよね 今までもそうですよね

仕様からAIに壊せるっていうのはあんまなかったんじゃないですかね素晴らしいその通り仕様駆動開発ってバイブコーディングの課題感から生まれてきた開発手法ですとバイブコーディングってざっくり言うとこういうことやりたいんだよねっていう曖昧なプロンプトからコードを生成するアプローチだったんですとなので自分のアイデアを早く動くものに落とし込むプロトタイプを作るとかではいいやんっていうので

盛り上がってますただ一方でそれを試している人の中では実務で使うにはちょっと信頼性足んないよねみたいなところが課題感としてありましたその信頼性どうにかする解決策として今最近話題なのが使用駆動開発っていうものをやってます

要するにコンテキストAIエージェントに渡すコンテキストをうまく作りながら仕様とかいろいろ作りながら開発していくアプローチとしての仕様駆動開発があります代表的なツールこの仕様駆動開発って気持ちの問題じゃなくて仕様駆動開発ツールを使いながらやるものになってます有名なやつだとAWSのKiroとか

GitHubのスペックなんだっけなんじゃそりゃ知らないスペックキットあとはCCSTD今日ちょっと僕が触ってたやつCCSTDSDDはいスペックドリブンデベロップメントのSDDクレイジーコマンドスペックドリブンデベロップメントってこといやCCって何の力だっけ調べたかな

クロードコードかクロードコードでした確かにカーソルも最近機能増えてましたねプランみたいな言うてCCSDDクロードコードなんですけどカーソルとかジェミニシーライトも使えるんですけどそういうツールを使って進めていくようなものになってますとその中のCCSDDっていうのを触りながらとあるアプリをなんとなく作ってみようっていうのを今

ちょろーっとやってますCCSDD使ってみてこんな感じで開発進んでいくんだなみたいなところをちょっとお話しするんですけどまずそもそもCCSDD使用駆動開発の走りとして出てきたのがAWSのキロですとただキロってウェイトリスト入らないと使えないとかあと海外製なんで日本語若干弱いとかそういうのがあったりします

その例に対抗してなのかわかんないですけどCCSDDは日本製ですとなんで日本語強いとかあとキロはAIモデル選べないんですよ多分クロード系だと思うんですけどクロードのイメージあるクロード系なのにもかかわらず4.5が出たのにまだ追随してないんかいみたいなのでツイッターがちょっと燃えてたような気分がありますそうなんだCCSDDは大体使えるうん

あとOSSなんでウェイトリストとかない使うの超簡単でNPXでインストールすればすぐ使えますっていうものになってて実際使ってみようって思うとどういう流れで使用していくかというとキロと同じコマンドを使って各種視力度開発を進めていきます

使ったことがないその辺も合わせてざっくり使用駆動開発の改造の流れって使用を作ってその使用を元にした進める計画を作ってタスク分解してそのタスクごとに実装していくっていうものをツールのコマンドを使ってやっていくんですねなのでこのCCSDDで言うと最初は

スラキロコロンスティーリングっていうコマンドを打つとスティーリングどんな単語の意味か分かんないですけど盗む?いやS-T-E-E-R-I-N-GR?ステアリングE-AじゃないんですよねE-Eそうだステアリングかステアリングって読むのこれ違う?いやステアリングですねでもステアリングかって言ったけどステアリングって何?って俺今なってるよステアリングがあの

ハンドルの操作のことを言いますね車でよく聞くけどハンドルのことです要するにハンドルのハンドルですキロのスティーリングコマンドステアリングって読むのかな本当にS-T-E-E-R-I-N-Gスティーリングって言いますスティーリングコマンドを打つと既存のプロジェクトに対しても新規プロジェクトに対しても使えるんですけど既存のプロジェクトだったら現在のプロジェクトのコードを解析してプロジェクト概要とかアーキテクチャをドキュメント化してくれますなんで

結構強くてどのくらい何を書いてくれるかというと今のプロジェクトでこのコードで作っているものの概要の日本語ベースのドキュメントとかアーキテクチャこのフォルダ構成がこうなってて各ファイルと各フォルダでこういうことをやってますみたいなツリーズっていうんですかあと命名規則とか作ってくれます新規プロジェクトでも

このプロジェクトではどういう方針で進めるかみたいなものを作ってくれますどうやって最初に要件伝えるんですよねこういうのやりたいみたいなそれでまず雰囲気で叩きを作ってくれてそれを受けてこういう風にしてっていうのを変えながら進めていくような感じになりますねで次にスラスペックイニットっていうのを作ると使用書のテンプレートを作ってくれてで次にスラキロスペックリクエイメント

っていうのを打つと要件作ってくれますrequirements.mdっていうで要件はもう僕初めて知ったんですけどイヤーズ記法っていうeasy approach to requirements syntaxっていう要件定義を書くための記法があってえー

常に成立する要求は○○は○○しなければいけないとかイベント駆動だと○○の時○○は○○しなければいけないみたいなそういうシステムの型というか動作の型ごとに一定の書き方で要件をまとめてくれるようなまとめる記法があってそれベースで要件を作ってくれますここまでで

プロジェクトのざっくり概要と方針あとは要件が決まりましたと次にキロスペックデザインっていうのをやるとアーキテクチャとかの設計が書かれたドキュメントを作ってくれますシーケンスとかアプリケーション全体の作りとかすごいボリュームだなすごいボリュームです先ほどスペックデザインで設計ができましたと設計できたらスペックタスクズっていうコマンドを使って

タスクを分解してくれますそのタスク分解してくれますっていうのは今まで要件とか仕様を整理する中で全体としてこういうのを作りたいっていうのが決まったわけじゃないですかこれをどっから実装していくかっていうのを超細かい単位で作ってくれます今まで人力でやったと思うんですけどまず最初にここだけ実装するここだけ実装するメインタスクとサブタスク単位でチェック

ボックス付きの箇条書きみたいなのを作ってそこにチェックつけながら進めてくれるようなタスクをガーって作ってくれて最終的にタスク1実装ってコマンドするとタスク1の実装が走るみたいな形で使用駆動開発が進んでいくのがこの使用駆動開発っていうものになりますさっきお話しした通りこれめっちゃ簡単なんですよコマンド打つだけだったらで

とんでもねえ量のドキュメント出てきますですよねレビューやばいですマジで僕今お遊びアプリを作ろうとしてとんでもねえ量のドキュメントが出てきてレビュー中ゆえ今実装に移れてないですなるほどねでも楽しいんですけどねあとこれちょっと感動したのがこのCCSDD最初からTDDでやってくれるように明示的にドキュメントが書かれてますへー面白いそうなんだうん

TDDとはっていうドキュメントがあってこういうものでまず最初にレッドグリーンリファクタリングのレッドから始めます必ずだから最初にこける単体テストを作るところから始まってっていう感じでちゃんと進めてくれてましたね今作ってる趣味のアプリじゃなくて別でやったときそれってどんくらいのTDDのあれになるんですかどんくらいのTDDのあれになるんですかTDDって思ったよりさ

ちっちゃいところから始めてるイメージがあって例えばクリーンクラフトマンシップに書いてあった例だとボーリングのスカーを記録するアプリを作るためにまずは何か入力入れたらこの点数が返ってくる

っていうテストを書いてその実装を書くんだけどその実装は固定でその値を返すようにしてるみたいなその次に次の別のピンの倒し方をしたら別の点数が記載されるようにする

で次は前の実装だと固定の値しか返せないからそこが可変になるようにするみたいな感じでマジでもう超絶細かステップをもう1回の実装30秒ぐらいで終わるんじゃないかみたいなぐらいの細かさのやつをバーって細かく回してやってるイメージがあってうん

一方俺それをAIでやるっていうイメージが湧かなかったんだよねどっちかっていうとただのテストファーストになるんじゃないかなと思ってて最初にテストである程度しっかりしたものができてそれを通すように実装するみたいなのになるんじゃないかなっていう印象があったんですけどその辺はどんな感じになるんですかそれでいうと開発中に1個のタスクをする中で中身どうなってるかぶっちゃけ分かんないですけど

タスクの切り方次第なのかなと思いますなるほどタスクがもしボーリングのピンで言うと固定値を返すっていうタスクが切られてるんだとしたらその流度でTDDをしてくれるしそうじゃない流度だったら多分やってないんじゃないかなそんな細かいことはただ我々というかユーザーのチェックを返さずに進んでいくんで分からんす

それでいうと今作ろうとしているお遊びアピールのタスク単位でいうとどんな感じで分かれてるんだろうタスク作れてないわタスク作れてませんでしたまだ仕様を見てる段階なのであと作ってたらクロードの上限足して止まっちゃいましたすごい量のドキュメント作るってそういうことドキュメントでめちゃめちゃ消耗するんだクレジットしたなやる気出てたんですけどねその日

あー終わったと思ってあーそれ悩むなーまあでもレビューしなきゃいけないのいっぱいあったんでっていうのがまあざっくり主要駆動開発っていうまあものになりますとでこれ見て僕思ったんですよ前々から思ってたんですけどなんかちゃんと理解して進めようとしてるんですけど今大変なんですよめっちゃボトルネック折れ自分がうん

ただAIエージェントの開発ってなんかAIにうまいことを任せて進めていくのがいいよねみたいなところはあると思うんでどういう風なスタンスでAIエージェントの開発AI駆動開発をやっていくのがいいんだろうかっていうのはみんな探ってるところだと思うんですよそんな中でですねTワダさんのXのポストで理解不採っていうものに触れられている

ものを見てなるほどなと思ったんでちょっとその理解不細の紹介なんですけど元記事は日和田さんの記事じゃなくて海外の方が書いたブログなんですけどLLM生成コードの次元爆弾っていうタイトルで理解不細について話してますで理解不細何かというとですねこれっていうのはコードにコードを理解するためにかかる余分な時間のことを理解不細と言いますうん

もう少し詳しく言うとチーム開発チームが理解できるスピードよりも早く行動が生成されるようなことができる時代になったんですけどそれがどんどん進むと理解不細がどんどん溜まっていくというようなイメージですなるほどなのでなんかLLMを使って爆速で開発だーって言って開発します開発しますでAIが作ったバーって見てるうん良さそうマジっていうのを繰り返して繰り返して繰り返していくと

いずれなんか既存コードの修正とかが必要だったりとかあと新機能開発するときに追加するときにAIがうまく修正してくれないなってなりますとなったときに修正してくれることもあるし修正してくれないんでずっとぐるぐる回るパターンもありますと結局だからコードは自分で編集しなきゃいけないことは必ず来るんですよそういうタイミングって

そのタイミングが来た時にうわこれなんだってなってうーんってやる時間は要するに技術不採というか理解不採が溜まってる状態なんですよ直接的に説明できなくてあれなんですけど事例から理解してくださいありますありますよねちなみにその時理解不採だけじゃなくて技術的不採も溜まってます知らないうちにねそうそうそう

この理解したりすごい感じてて僕はこの主翼道開発ってもともとバイブコーディングがあんまりなんか実用的じゃないというか信頼性に欠けるよねっていうところで課題があって主翼道開発っていうのが生まれたと思ってるんですけど主翼道開発あまりにもレビューするのが大変なんじゃないかと思うんですよ僕ちょっと実務でやったことないんでまだ分かんないですし実務は実務でねちゃんと人間がドキュメント作ったりはするんで時間かかりますけどね

要件とか仕様まとめるのもね1週間かかったりしますけどAIがやったらね10分とかでできるんで確かになのでシンプルにね例えば1時間で終わるとしてAIが人間が1週間かかるとして1日8時間働くとしたら40倍のスピードで出てくるわけなんですよねだから40倍のスピードでレビューできないじゃないですかっていうのでスピード感を持って進めるとやっぱり理解不細がたまるわけでどうやっていくのがいいんだろうねっていうなるほどね

ところはひまプロ的な議題として今日持ってきたくて使用駆動開発は最新情報なんでキャッチアップする上で話した方がいいかなっていうのでやや触れつつAIエージェント開発AI駆動開発で積み上がりがちな理解不細我々はどう立ち向かっていくべきなのかというトークテーマでこう思うよって話を聞きたいっていうのが後半戦でございますなるほどねいいですね

理解さえ感じますよね思うこといっぱいありますよノリさん特にあるんだろうなと思ってなんで順平から聞こうかなすごく難しいですね難しい答えないよこれはアーキテクチャと一緒でなんかトレードオフ感あるけどな場合によって使い分けていくんだろうなと思いつつ全然避ける術を思いつかないなしょっちゅうそれは僕もぶち当たってることなんで

ちょっとしたコードの修正でもそのコードだけじゃなくて周りの部分の理解とかもしないともうちょい綺麗なコードにしたいなみたいな時とかにAIが修正したコードだけじゃなくてその周りのコードもちょっと理解しないといけないみたいな時とかがっつり不採用を感じますしかといってそれをためないようにするのか

できなくねって思っちゃいますねなんかもう都度やっぱり理解しに頑張ってかかるしかないくないですか全然思いつかないなちなみに今開発する時ってなんか事前の仕様みたいなところってAIにどれだけ渡すとかその辺ってどうなってる?その辺はまあ確かにえーと

雑にやってるって言ったらあれですけど雑にやってますねそのがっつりその仕様書みたいのを渡して読み込ませてみたいなとかは全然やってなくてこういう機能で既存のものにこういう風な機能をつけてこういう風にやって作ってほしいっていうのを自然言語ベースで伝えてるって感じですねプロンプトに全部そういう配信を載せるみたいな感じか場合によっては画像とかを渡したりしますけど画像なんか

何ですか素材のそれともデザインのデザインとかこういう感じにしたいみたいなとか参考になりそうななんかドキュメントとかできるようにバッて渡したりとかはあるんですけど基本プロンプトベースですねはいプロンプトベースでやったらさあんまりなんか理解不採みたいなの起きなくないそんなことないかそうですか結局その修正してきたコード出してきたコードがなんか

理解さえ起きなくないっていうのは出来上がったものに対してはもちろん起きるんだけど途中に挟まるさこの仕様でいいのかみたいなの全部スキップした上でいきなりこっちの指示がコードに変わってないっていうのがあるからコードがどんどん積み上がっていって積み上がっていくとそのコードを本当に意図とかを

構造とかを理解しない状態で自分で変更しなきゃいけないかなって時によう分からんってなるじゃないですかそれを理解不細と呼びますそれも多分そうですね1回目プロモプトバーンって出してコードバーンって書かれてきたら

それを単純にちょっと読む読んでこんな感じかってなってでもなんかちょっと気に食わなくてもうちょっとこうとかいろいろ修正あるじゃないですかそれ位置機能に対してもってなってたら理解不細はあれこれこういう修正今度出してきたけどいいんだっけみたいのはめっちゃなりますしでもそれってなんかどうしようもないなってなっちゃってますね正直という回答になってしまったなるほどねとにかく頑張るしかないと

なんでまあそうですね小さい変更で済まさせるというか小さい変更の積み重ねをすることで都度の理解不採は減らしていくみたいなよかったりするんですかね確かに結局バグった時が一番理解不採進むんだよなわかるなんでこれこうなるんだろうみたいなのをさ結局AI解決してくれないのが続いてよし

俺がやるってデータベース見ながら動かしてみてここでこう動いてるからかってなるよねその時に一番理解進むというか思うことあるのりさん理解不正にどう立ち向かうか僕はですね理解しようとする姿勢を抑える方向で抑える対策していますどういうことですかえっと

今の進め方的には僕使用駆動開発に近いことをやってると思うんですよジェミニの一個のチャットをずっと育て続けているんですけど

仕様の相談全部そこに投げて次こういう機能付け足したいんだけどどういう変更すればいいつったらもう差分で出してくれるんだよね今までこういう機能実装してるんでこういう風にすればいいですよみたいな分かったじゃあそれをカーソル用の指示書にしてくれつって指示書作ってそれをマークダウンで一回書き出してそれをコンテキストで渡しチャット欄で渡して

作ってもらうみたいな流れでやってますとまず一番最初に負荷かかるのはその仕様ができた時なんですよこれでいいのかみたいな僕はそこめっちゃチェック適当ですねまず動かせって思ってるで動くじゃないですかただ出来上がったものに対して動かしてこういう機能欲しかったのになっていう意見はもちろんあるんで

どっちかというと自分はテスターとして動くみたいな方が強いかもしれないひたすらテストをしまくってOKならそれはOKっていう気持ちでやってますねコードの中身についてはどう?

してますその行動の中身はそれこそもうこれはこそバグ駆動中身理解なんですけど バグが起きて見なきゃってなった時に見るうんでその時に大改革を起こすねそこの中にっていうのが多いですかね なるほど

ベースは結構動けばOKみたいな感じで進めてるなるほど動けばOK駆動ですねできるだけAIに働いてほしいっていうベクトルでやっぱり進めてる感じなんですね自分がテストしてOKならOKでしょって思ってる感じで動いてますねでもコードの品質ももちろん見るっちゃ見るでもそんなしっかり見ないから後で見た時に

こんなコード残しやがってみたいな全然あるこの前もあったのは同じ概念なんだけど今作ってるサービスがですね結構お金の移動があったりするんですけどお金の振り込みになるタイミングとかお金に対してステータスがあるんですよいつから承認されたら振り込みできるようになるとか引き落とし申請したら引き落とし申請のプールに入るとかお金にステータスみたいなのがあってで

だからその似たような単語めっちゃあるんですよちょっと寄っちゃう名前というかウィズドローアブルグロスバランスみたいなその手数量もあってグロスとネットで両方あるからいろいろな単語がこう行き交ってるんだけどなんかパッと見いい感じにできそうだなできてそうだなって思ってたんだけど実は半分ぐらいいらない変数を使ってて

そんなことあるんだ名前のブレが起きてたんだよねめっちゃ1個の意味に対して2,3パターンの似たような単語の並びみたいな難しいそれはこれのせいで全然理解できないってなったんでもう1回辞書作って日本語英語意味のマークダウンのテーブルだよねそれでその周りのテーブル作って

一旦ここわけわかんなすぎるからこの辞書に基づいて全部明々書き換えろってそれで全部書き換えたらここも重複してますねここも重複してますねってAIが自分で判断できるようになって変数が半分ぐらいになったっていうのはありましたねなるほどなあいいこと聞いた単語帳辞書めっちゃ大事な気がするしかも辞書書くことによって自分も明確になったその

どういうキーワードが何なのかみたいなのが結局AI書いたコードの名前が何指してるかが分かんないことがめっちゃ多いなって気づいて辞書作ると一気に理解せずもなってなりましたねなるほどありがとうございます今の話面白く聞いてたのは僕も割ともともとこれ理解不正にどう立ち向かうかっていうところについて結局コードは人間が理解しなきゃいけないっていう

ベースですと僕はプルリクのレビュー見るぐらいの気持ちでコードをちゃんと見てダメなとこ指摘しなきゃいけないから結局レビューめっちゃ労力かかるしおそらくそこがボトルネックになっていくと思ってますとなのでそのボトルネック感を少しでも増しにするためにAIが制裁するコードを理解できるような基礎力をつけるのとか

あとは自分が理解しやすいようにコードを書いてもらうそれは広く言うと自分が知ってる言語でコーディングしてもらうのもそうだし自分が得意なアーキテクチャでコーディングしてもらうのもそうだしあとはコード作ったらコメントアウトなのかなを添えてもらうとかドックコメントかドックコメント添えてもらうような作りにするとかみたいなそういう工夫でなんとか作られたコードを理解しやすくする

テクニックを詰めていくしかないんじゃないかなってちょっと元々思っててあとは情報まとめ力っていうか今回の変更はこういう風な変更だっていうところを読み取ったメモを書いておいてこのメモ合ってるって聞いてみるとかみたいなそういう小手先のテクニックを駆使しながら頑張って理解するスピードを上げていく

のが良いのかなって今のとこは思ってるんですけどただのりさんの話はそれとは逆でそれでもAIのスピード感を生かすいいアプローチだなとは思って今面白く聞いてましたそうねテストに割く時間増やしてチェックはするけど行動の品質とかもあんましっかりはやんないかなっていうやってらんないっちゃやってらんないっていうかやってると意味ない可能性もあるんですよねそのAIで生産性を上げようって思った時に

なんかかつての日本がなぜ生産性を上げれなかったかで言うとよく言われるのは海外は新しく出てきたツールに仕事のやり方を合わせに行くけど日本は既存のやり方にツールを合わせに行ってたから生産性が上がりに切らなかったみたいな逸話というか何だ話があって

今ののりさんの話を聞いててなんかちょっとその話を思い出しながらなるほどちょっと聞いてたりしましたねツールに合わせるパターンただ日本がどっちに走っていくかですねあとはねAIがじゃあ見捨てたらしょうがないかってなるのかいやおい何やってんだってなるのかちょっとAIがやったらしょうがないかってなる未来はあんまりない気がするんですけどなるほどねそれは今のポジションだからこそできるやつかもしれないなうん

本当はAIに任せれるところは任せた方がスピード感持ってやるんだろうっていうのは確かに思いましたこれは答えある話じゃないんでねみんなどう思いますかっていうところもありつつあとは来年

聞いてみたら何言ってたこいつらってなる系のエピソードだと思うんでめっちゃなるよね来年ちょっと楽しみだなと思いながらちょっと締めようかなと思いますAIは基本そうなるからなあとすいません会社内のAI駆動開発の振り返りをしてた会社チームの振り返りシートみたいなのを盗み見をしておもろって思ったのちょっと一つだけ共有するんですけどAI駆動開発によってコーディングの楽しさがなくなったっていう

そうなんだちょっとわかりませんいやどうだこれはもうプロリクを見て自分が作ったと思ってるからなんか細かいロジックとかなんかその綺麗にコードを書くなんか小手先ってなんてそのちっちゃい工夫の入れる城がないじゃないですか今なんかどんどんできてっちゃうからここどうやって実装しようかなみたいなあーそういうことねそうそうこのビジネスロジックビジネスルールをどう

コードのロジックに落とし込もうかなみたいな謎解き感が皆無 深井:そうかも 樋口:うん 仕様を考えるときはもちろんあるかもしれないですけどとかっていうのを聞いて「あーおもろ」って確かにって思って 深井:そうなんだ でもまだ楽しさなくなった感覚ないんだよね 樋口:そうなんですね物作りの楽しさはあるんですけどね プログラミングっていうかコーディング試験とかのああいう楽しさはもうなんかないなって感じしますね

はいっていうちょい話でした締めますハッシュタグひまじんプログラマーでSNSNEXTでフィードバック募集してますので本日のエピソードの感想とかありましたらお気軽にお願いしますAIの使い方

使用駆動開発案件で使ってみたらこうですって話はすごく聞いてみたいです使ってたらすごいですねただこれドキュメント起こすとかだったらめっちゃいいと思いますけどね例えば新しくチームにジョインした人がコードをキャッチアップするためになんかドキュメント作ってもらってとかは別にありだと思いますよコード上のものとあとなんかそのドキュメント管理ツールって離れてるじゃないですかURL的には探しに行くというか突合するの大変なこともあると思う

URL的にはあとはそもそもそんなに整備されてないとかもあるかもしれないんで最新かも分かんないしね設計書がコードのメインリポジトリあればそれは間違いなく最新だと思うのでそういう意味だと今の主翼度開発の既存のコードを読み込んでドキュメントを作ってくれる機能はなんかいいんじゃないって思いますただ成果物が本当にあってるかは知りません確かにそこの精度気になるなあとは

ドキャストの説明欄からグーグルフォームで番組の要望・感想・質問お待ちしてますエピソードではなくチャンネルの説明欄でスラックオンラインコミュニティひまプロ談話室の参加申し込みフォームありますのでオンラインコミュニティ気になる方他のエンジニアの日々のインプットに刺激を受けたい方とか入っていただけると幸せになるんじゃないかなと思うのでお願いします談話しましょう談話談話談話談話談話

最後に各種ポッドキャストプラットフォームのフォロー高評価お願いします待ってますそれではまた次回バイバイ