1. となりのデータ分析屋さん
  2. 139. 【後編】100人研修!AIツ..
2025-10-22 28:05

139. 【後編】100人研修!AIツールの選定はナンセンス?知見を蓄える仕組みと仕様書の重要性【Devin】【Spec-Driven Development】

サマリー

このエピソードでは、SDD(スペックドリブン開発)を通じて、AIツールの適切な使用法やコーディングプロセスの改善について議論しています。実際の取り組みを通じて、ドキュメンテーションの重要性とAIとの効果的なコミュニケーションの必要性が強調されています。さらに、現代のソフトウェア開発におけるエンジニアリングやレビューの重要性と、AIの進化がプロジェクトに与える影響について考察しています。また、使用書の必要性やデータベースへの新しいアプローチについても議論されています。エンジニアリングと開発文化に関する話題が中心となり、特にSDDに対する関心の変化について掘り下げています。細木香里さんに関連する六星戦術の話題も交えつつ、リスナーからの質問に答えています。

SDDの実践
VSコードとか、それこそCopilotを使ってますよとか、そういう人たちが、このSDDの考え方で開発しようと思うと、スムーズにいけるものなんですか?
あ、これね、いけるね。俺、なんか半分ぐらい、それ結局実践してたわっていうのが、俺の中ではあるから、別に他でもいけるなって思ってて、
例えばCopilotとか、カーソルとかもそうだけど、カーソルルールズとか、ああいったものみたいな感じの記憶媒体のベースをちゃんと作っとくみたいな発想なんだよね。
それを、使用書とかを毎回参照しながらコーディングさせれば、基本的には変な方向行かないじゃんみたいな。
なるほど。
ガードレール作りみたいな感じだから、別にそれがやりやすく作ってはあるが、
他のAIツールでも、ちゃんとこの手順を踏むときにこのファイル参照するようにしようぜとか、っていうのを引いてあげれば、基本はうまくいく。
ああ、そういうことね。だから別にテンプレートとかが、もうこれじゃなきゃダメってのがあるわけじゃなくて、
まあAIが読みやすい形で、マークダウンのフォーマットで、リコイアイメンツみたいなところをマークダウンで残しておけばいいってこと。
そうそうそうそう。
ああ、それでいけるんだ。
いけるいける、だいぶいける。
であれば簡単だね。
うん。
でもその、結局その、そこを丁寧に作ってないから、そのバイブコーディングという言葉がふわっとしたものになっちゃってるじゃん、っていうだけ。
だから多分割とみんなやってると思う。
まあやらないと確かにうまくいかないよね、もう。
そうそうそう。
だからそこはうまくいってるし、多分みんなやってるから、だから多分逆にでかいムーブメントにあんまなってないのは、
普通に地に足ついたAIの使い方してる人たちは割とやってたからっていう話は多分あって。
ああ、そういうことか。
けどなんか、そうそう、俺はこの、なんかこの流れ見たときに、やっぱ一番大事なのは結局その、AIを魔法の杖として今はまあ使えなくねっていう、
まあAIをなんか舐めるじゃないけど、過小評価して使うっていうやり方だから、
これその、表面で使うモデルが進化していけばいくほど、まあこの丁寧さってまあ不要になっていくっちゃなっていくんだよね。
ああ、今後、そうなのか。
こんなに細かくやんなくても、そもそもAI自体がこういう、人間がこうやって考えてるのがまあ合理的だってなるかもしれないから、
必然的にそいつらがこういうのをどんどん作っていって、勝手にそのフローの、自分のコーディングのフローの中にこのスペックドリブンを取り込むっていう可能性もあるし、
AIが組み込みやすいやり方でやっていくっていうのもそうだし、まあそれが全部暗黙的に進んで気づいたらめっちゃ自分の作りたいものが超完璧なクオリティでできるっていう時代にはなると思うんだけど、
本物のワイブコーディングができる時がまあ来るだろうと、そのうちね、はい。
けど、使うのは人だし、ってなってるから、なんか表面のAIのモデルがどう変わろうとも、ある程度変わらず持てる資産として残していけるものをちゃんと作っていくっていう発想が多分SDDとは言わずとも一番大事な発想だし、
コーディングの文化
今仕込むんだったらそれだと思うんだよね。
人間中心っていうのは結構普遍な話だから今後も。
まあきっとね。
そうね、まあ使うの人っていうところがまあそうなんじゃないですかね。
だからなんかその最適なAIツールどれなんだとかっていう選ぶのは多分今の時代ナンセンスで。
っていうのは会社とかでもなんかいろんな人とずっと喋ってんだけど、それはナンセンスで、そうじゃなくて、どのAIツール使ったとしても、
その成果が出るような足元のこうドキュメント作りとルール作りとそのリテラシー形成みたいな。
そうだよね。
だから表面のAIの支配者みたいなやつが変わったとて、多分仕事のアウトプットのクオリティ、俺らのは変わらないんだよね。
文化みたいなところをどう作っていくかが結構大事なんですね。
このSDDっていう言葉を使って、それが大事だよねっていう共通認識をチームとか会社で作っていくみたいな。
そうだね。
慣れっ地をちゃんと慣れっ地として蓄える。AI時代、暗黙地っていうものがなくなっていくはずだと思ってるから俺は。
暗黙地を作ってるのはもうほんと人間で、で暗黙地がなんで解消されないかは、一番はそれ実装されたら暗黙地からなくなるじゃんっていう話が一個ある。
はいはい。
データ分析、ここは一回データタイプ変えなきゃいけないんだよねみたいな。最初から変えとけよみたいな話だから、そういうので一個解決するんだけど、
それがすぐできないからみんなの中に溜め込む慣れっ地として作っておくんだけど、AIにその暗黙地を誰かが教えて、同じAIモデルで同じ参照をみんなしてれば、暗黙地はもう世の中がなくなるんだよね。
そうだね。
で暗黙地に蓄えられたものがAIが定期的に観察しに来て、勝手に仕様を変えてくれれば暗黙地自体がなくなるじゃんっていうサイクルも勝手にできるはずでそのうちみたいな。
っていう意味で暗黙地って世の中からAI時代一番最初になくなるんだろうなと思ってるんだけど。
なるほど。人間の中にあるものが一回表に出てさらにAIが理解してってことになってくる。
そういうのも、このバイブコーディングって言っちゃえばその暗黙地めっちゃあるから、作った時のバイブスとかそのプロンプティングのお作法みたいなのとか、そうじゃないみたいな。
ちゃんと作り方、レシピちゃんと書いておこうよ全員がみたいな。結局はそのレシピを書き続けるだけみたいな。
これでもどうやって広めればいいですかね。結構この文化とかを作っていくって簡単じゃないじゃないですか。
なんか結構これまでテスト駆動開発とかっていう言葉でやっていこうぜみたいな流れとかはあったものの、またちょっと一個話変わって、
いやまずは仕様書なんだよっていうのが今回のSDDだと思ってて。
そうね。
なんかこの今までやってたやり方からちょっと変えなきゃいけないみたいな。AIとちゃんとコミュニケーションとって仕様を固めていく、開発の仕方を作っていくみたいな。
これをチームで共通認識測るって簡単じゃないと思うんですよね。
そうね、まあ既存サービスは結構大変。既存サービスの中で浸透させるには、まあなんかインパクトの出る、ちっちゃいサイクルでインパクトの出るところで一個実績を作るしかないよね。
成功体験の共有
そうだよね。実務ではあれですか、このSDDを活用して結構いいサイクル回してる感じなんですか。
いや、あのね、超綺麗に回るかどうかは、この形にのっとったものでやり切ったっていうのはまだないね、手探りだから。
そうなんだ、今まだこれからやっていこうっていう感じか。
そう、けど、2個ぐらいはなんかおもろいなって思ってる実際の取り組みはあって、まずはなんかこの間このスペック動開発でプロダクト作ろうよっていうデビンの研修をやったんだよね、会社で。
なるほど。
何人いたんだろうな、60人、70人ぐらいかな。
おーおもしろいですね。
の新卒のエンジニア非エンジニアも含めて、1日集めて、そこでもうデビン使って、1から自分の作りたいものを1人1個作る。
で、その時にまず作りたいものとりあえずバイブスで作ってって言って、その途中でちゃんとSDDの概念理解して、仕様書しっかり作るところから入ろうみたいなので1回作り直すみたいなのをやって、結構ちゃんとみんなできてるなみたいなのは実感的にもあった。
なるほどね。結構そういう大掛かりなイベントというか勉強会みたいなのを開いて、一気にその成功体験をそれぞれで獲得してもらうみたいなやり方でもうすでに始めてはいるんですね。
そうだね。
やり方としてはあれか。
あとはですね、そのSDDっていう形にのっとってるわけじゃないけど、ほら新卒の子、アナリストの新卒の子をこうやって育ててますみたいな話をこの間したじゃん。
ああ、はい。そうですね。なかなか受けも良かったですね。
そうそうそう。受け良かったあれね。エピソードで言うとたぶん134とかかな。
かな?
4回5回前ぐらいのやつなんだけど。
で、そこも結局は別に新卒の子の育て方とかもそうだけど、チーム全体がちゃんとクエリ生成とかを全部AIに委ねられるようにするシステムを作ってるっていうところは、
なんかSDD出る前から割とSDD的な発想でドキュメンテーション作り込んでたなっていうのはある。
まあ確かに言ってましたね、そのAIに読み込ませるようなドキュメントを作る時間をあえて設けるというか、
その時間は絶対に確保するっていう話をしてたと思うんですけど、まさにそのドキュメントが今回のあれですか、仕様書みたいなものになってたってことですか。
あ、そうそうそう。仕様書の各セクションを作ってたみたいな感じかな。
あ、そういうことか。なるほどね。で、それをちゃんと一箇所にドキュメントとして集積して、
全員がちゃんとその恩恵を常に受けられるようにGitHubのリポジトリとかを管理するみたいな。
言ってましたもんね、こう数日数時間かかるタスクが20分で終わったっていう、もう成功体験を新人の子が得られたっていう。
で、それでうまくは行ってたんだけど、やっぱちょっとバイブスで動いてる部分もあるから、
最近運用の方法をもう一回見直す必要あるよねみたいな話になってきて、
多分彼に振られてた仕事は当時はAIでバイブスで作ってある程度回るものだったんだけど、
その求められるレベルがこのスピードめっちゃ上がってるみたいな話したじゃん。
エンジニアリングの重要性
そうなってくると、こっちのバイブスだけじゃどうにもならんレベルになってるのに、バイブスのままいってるみたいな形になってるっぽくて。
で、なった時に多分今、ベースのドキュメントはできてるから、ちゃんと使用書作っていくみたいな。
ところから出直して、もうちょっと作り方丁寧にいかないと、
たぶん到達できない域が見えてきたんじゃないみたいな話をしてて、そこのサイクルを今回してる、回し始めようとしてるみたいな。
全体の仕事のスピードが上がっていったせいで、バイブスのスピードに追いついたというか、バイブスじゃどうにもでもできなくなってきたんだ。
そう。
そんなことが来るのか。相当早いっすね。
そう、だから、いいねっつって。ありがとう。そこまでいくんだ。ありがとうみたいな。
はいはい。結果、仕事のスピードが上がっているのが素晴らしいことっすよね。
そうそうそう。
なるほどね。じゃあそういうところで、新人に対しての教育というか文化作りはやりやすいのか。
そうだね。でもまあなんか、そのレビュー、その行動のレビューしてくれてるのが今別の人なんだけど、
まあ別に、そもそも1年目のこのレビューって結構時間かかるからね、みたいな話はしてて。
そう、だから、実際レビューコストめちゃめちゃ上がってるのかで言ったら、どうなんだろうみたいな。
まあスピードが速くなった分、ちょっと個数が増えてレビューコスト上がってんのかなって感じをしてて。
ああ、はいはい。
けどまあ、新人の子ってそんなもんだよね、みたいな気持ちもベテランの人だからあるみたいな。
AIの影響と必要スキル
なるほどね。でもプルリクの回数とか多分増えてくるから、単純にレビューの回数とボリュームも増えてくるんじゃないかなと思いますけどね。
ああまあね、そうね。でもその、今の俺らが作ってるサイクルの方は、そのプルリクで上がってくるもの自体はその前にめっちゃレビューが入った状態で最後送られてきてるから。
ああ、そっかそっか。
そうそうそう。まあ結局どこのタイミングでレビューが入るかっていう話なんだけど。
はいはい。
で、なんかじゃあその問題にぶち当たった時に、どういう解決方法を打つのかみたいな話もやっぱ大事で。
ほう。
SQLもっと上手かったら解決するんじゃないっていう、あの実力底上げの発想と。
はいはい。
あとは、いやプロンプトとかのステップとかをのシステムが悪いって考える派と。
はいはい。
っていうところがやっぱ出てくるんだよね。どっちも正解なんだけど。
はいはい。
はいはい。
俺はもう完全に後者に振り切るって決めてて。
うんうん。
だからその正直、詰めるとこまでシステム詰めた上で無理なら、ちょっともう一回勉強し直せばいいけど。
多分もうほとんどいらないんじゃないかなと思ってて。
その字型、字型つけるのもほんと数週間の研修だけで十分だろうみたいな。
川塚おじさんの話ですか?
あそうそうそうそうそう。でそれはそうじゃなくて、じゃあなんで今そのうまく狙った、あの言われたものと狙ったものにこう買い入りが、狙って作ったものに買い入りがあるのかみたいな。
うん。
ので言うと、それこそ俺的には、その仕様書ちゃんとお前丁寧に作ってるのかみたいな。
あー。
そしたらまあ、今までのバイブスの感じで言ってたみたいな話になって。
けど、もう一方でさっきの俺とは違う派って言ってた人たちは、
AIがバイブスで出してきたAIのやつをしっかりレビューできればいいんじゃないっていう自分で。
セルフレビューの能力が高ければその上の人のレビューコストかからないじゃんみたいな。
っていう発想。
あーまあその気持ちも分かるね。
ってなって、あーまあ確かにな。
まあどっちも正解なんだけど、
今、今書けるんだったら俺は、そのひたすらシステムの整理していく方がいい気がするんだよねっていう。
なるほどね。
それは何?今後の未来を見据えてっていうこと?
あ、そうそうそうそう。
こっから2ヶ月ぐらいじゃあ、自型をつけるためにエンジニアリングとか分析とかの自型をつける期間を取ったとして、
そいつが伸びるだけじゃん。
そうだね。
でもなんか、その2ヶ月間でシステムを作りきったらチームメイト全員が助かるんだよなみたいな。
でなんなら来年の1年目のこの初速もっと上がるよなみたいな。
って思うと、その個人のただの能力だけ見たらもしかしたら自型をつけるのが大事なのかもしれないけど、
チーム全体とかちょっと長い目で見たときは、システムの整理してそれを解決しまくって、
でその姿勢をSQLを磨く時間よりもそれを推進してきた経験を積んでもらった方が、
結果新人の子もいいんじゃないかみたいなチームとしてもいいし。
確かに確かに。
全体のパフォーマンス向上というかが上がるという。
なんかあれですね、最初の自己紹介の通りですね、AI新規事業開発責任者でしたっけ。
AI新規事業責任者ね。
まさにその観点であれですね、見てますね。
そうね、そうね。
まあそうだよなあと思いますね、確かに。
けどまあ。
分かる。気持ちは分かる。
分かる。
でもなんか徐々にその共通認識とかもあってくるといいですよね、チームメンバー。
他のレビュアーの人たちも含めて。
そうね。
近いうちにその答えは出てくるんだろうし、パフォーマンスどっちが上がるかっていうところは。
そうね。
そういうどうなんだろう、正直わからんよね。
でもなんかSQL書く能力は1年後ぐらいには本当に必要なさそうじゃん。
でもどうなんだろうね、本当にわからない。
その全くできないのは多分無理じゃないですか。
SQL何それおいしいの状態じゃ絶対話にならなくて。
まあそうね。
じゃあどこまでつけるかっていうその線引きというか。
そうね、そうなんだよね。
でもそこの実力をスキルを持つことにどれくらい価値があるかっていうのがちょっとまだ見えない。
あんまスケーラブルな話じゃないように感じるんだよね。
じゃあ必要最低限ってどこのラインだろうとか。
それが時間とともに変化するものなのかその必要なスキルが。
すんじゃないのかなさすがに。
やっぱAIが賢くなっていきすぎちゃうからね。
はたまたSQLとかPythonという言語をもう意識しなくて良くなる世界線があるかもしれないしとかね。
それはねそう思ってるマジでそう思ってる。
使用書と自動化の進化
ちょっとこればっかりはな。
そうデータベースの持ち方の思想みたいなのは多分こっちで持つ必要があるから。
ちょっとまだ見えにくいとこですねここは。
そうね。けどまあ変わっていく中でとりあえずそのそれに順応できる土台を作るみたいな。
とこだけ注力していく以外もうなんか松川だからさ俺らって結局AIの進化法。
もうなんかオープンAIの動きあって地味にあってみたいなさ。
もうなんか多分3から5手先ぐらいまでもう開発終わってんでしょみたいな。
その可能性は全然ありますよね。
誰が一番最初に出すかみたいな。
で出したところにかぶせにいく手札を多分地味に4ぐらいまで持ってんじゃないのもうみたいな。
手札だけめっちゃ持ってそうっすよね。どれでいこっかなみたいなね。
そこはもう政治判断みたいな。
政治判断みたいな。お前らはとりあえずどんどん作ってろみたいな現場の。
それを待つだけの俺らっていうね。
いやそうだと思うな。
まあでも今日の今回の話はそれとはまたちょっと違って
死をどう決めるかっていう人間がどうしたいかを実現するための方法論っすもんね。
そうそうそう。でしかもそれはある程度までのAI賢くなったり
ステイトオブジェアートみたいなのが変わっても変わらず資産として残り続けるものだから。
いやこの考え方は大事だよな。
改めて使用書ちゃんと考えようっていうそう考えるきっかけになりましたね。
リッチなドキュメント一瞬で作るのは結構いい時代なんでそこをちゃんと過論じない方がいいっていう。
そうだよね。別に使用書作るのは面倒くさいって思わなくていいんだもんね。
そう。
いいよね。これはめちゃめちゃいいよな。
なんなら使用書がもうないサービスとかきっとあるからね。昔過ぎて。
あーあるね。全然ある。
使用書から作るのみたいな。
結構あると思うよ。プロジェクトとか新しく入ってあれ?使用書どこ?みたいな。
あーもう更新できてないんだよねみたいな。
最終更新2018みたいなね。
恐ろしい。
2022みたいな。あれっつって。
そんなサービスはもうダメだと。プロダクトはもうダメだとね。
でもAIのおかげで。別に動いてるから逆にいいんだよね。
動いてるからむしろコードがちゃんと噛み合ってるから動いてるわけで。
そうするとコードから使用書は作れるから。
はいはい。そうか。
リバースエンジニアリング的なことができるから。
壊れたときが最後だよね。なんで壊れたんだろうで終わるよね。
そうそう。その前にレガシーコード的なものは使用書も含めて整理して自動化できるところは自動化しておくみたいな。
のがめちゃめちゃ大事なんだよね。
っていう感じでしょうか。
はい。いい回ですね。
エンジニアリングとSDDの話
珍しくエンジニアリングの話というか。
開発文化の話にもなるけれども。
あんまりAIとかに振り切った話でもなくて。
大事な考え方の話ですね。
実務に活かせそうな良い話でした。
でもなんかね、最近10月入ってからあんま聞かないなSDDはっていう話もちょっとある。
そうなんだ。これ一時バッと話題になったのを自分は知らなかったよ。
俺もね、たぶん割と後から勢ではあるんだけど、ちゃんと知ったのは。
けどなんか、たぶんキロのタイミング、8月末ぐらいに確か出たんだよな。
っていうのがあって、9月ぐらいにみんながバーって試して。
で10月になってからどうなんだろうみたいな。
まあでもちらっちらまだあるか最新の記事はみたいな。
でもまあその後の、やっぱこっちだろうみたいなのもなんかでかく出てるわけじゃないし、
まあ考え方はこれが大事っていうだけの話だからまあいいんじゃないかって感じだよね。
六星戦術とリスナーの質問
なんかまあエージェントに言いたいシステムプロンプトとか全部エージェント.mdに入れようとか、
そういう話とかもありましたよね。
まあもうそんなことだよ。結局はベーシックなルールどんどん固めていくしかないみたいな。
そういうことだよね。
じゃあマークダウンをちゃんと書いていきましょうとこれからは。
そう。そういう話ですね。
勉強になりましたね。
しゃべると整理されるからね、俺も。
よかったです。
次回。
ワークフローの話ありだよね。
ワークフローの話はあり。
バリューはある。
じゃあお便りいただいているんで、久しぶりに読んでおきます。
最初のやつ一個言っていいですか。もう秒で終わると思うんですけど。
いいよ。
コアカネーブ、ユージさんからです。
六星戦術の今のボスは細木和吾の娘です。
っていうお手紙をいただきました。
嘘でしょ。
本当に。
これあれだよね。前回かな。
くらいのエピソードでハルシネ賞の話した時に。
そうそうそうそう。
AIがなんか嘘をつくというか。
六星戦術みたいな占いはなかなか当てられないっていう話をしていて。
そこの中で最近流行りのこの細木和吾っぽい女性がいるんですよっていうのをリョッチが言っていて。
多分その人が実は娘でしたっていうことを教えてくれたんですよね、ユージさんが。
そういうこと?
本当だ。
本当だ。
細木香さん。
なんか私もwikipediaでちゃんと事前にチェックしておいたら。
なんか六星戦術の後継者。
あんだその後継者とか。
マジで娘だったらしいですね。
確かにね。
えー。
めちゃめちゃすげーじゃん。
なんか特殊能力なのかなやっぱ。
六星戦術って。
AIには真似できないんだよってことは。
そういうことなのかな。
ルールベースだったらいけるからね。
おもろいな。
ちょっとやっぱ占い。
占い掛けAIはね。
あると思うんだよね。
俺は振れないけどそこに。
市場はありますかね。
俺のキャリアはそこに振ることできないけど。
まああるんだろうなと思うよね。
宇宙絡めたらいけそうですけどね。
確かにね。
確かに。
元NASAが占う六星戦術。
六星戦術AI。
元NASA公安。
六星戦術自体がもうあれなんでしょ多分。
商標みたいなのがあるんでしょきっと。
ずっとこのシリーズで書籍が出てるらしいですからね。
コンビニに置いてあるやつでしょ。
ありますね。
細木さんの顔が載ってるやつね。
いやすげーなー。
聞き取り何時になるんだろう。
ちゃんとやろう今度。
お手紙これだけでいい?
もう1個読んどきます?
確かに。
ちゃんと毎エピソード1個読むっていうやっぱあれにするか。
そうしましょうか。
せっかくね。
そのエピソード、前回のエピソードを踏まえて送ってくれてる人もいるんで。
確かに確かに。そうしよう。
次の収録の時も1個読もう。
そうしましょう。
じゃあ今日は細木勝徳の娘でしたと。
すごいわ、細木香里さん。
ありがとうございますお手紙。
引き続きなんか面白い情報あったらいただけると幸いです。
じゃあ終わりましょうか。
終わりましょう。
隣のデータ分析屋さん今回も面白いと思ったらフォローレビューよろしくお願いします。
番組の感想や質問はハッシュタグ隣の分析屋。
また概要欄に貼ってあるお手紙フォームからコメントを寄せてください。
ではまた。
バイバイ。
28:05

コメント

スクロール