新しい役職と開発手法の紹介
AI新規事業責任者のりょっちです。
データサイエンティストのたっちゃんです。
なんすかなんすか?
いやちょっと、さすがにデータアナリストじゃなさすぎるなと思って。
なんて言いました?
AI新規事業責任者。
あー。これからそれでいきます?
なんか固いよね。
まあ慣れてくるかもしれないんで、ちょっとそれでやってみましょうか。
ちょっともうね、俺が一番アナリストしっくりこなくなってきてる。
前回の収録ぐらいの時に、あれ?みたいな。
俺、もうアナリストか。
まあ、みたいな。
まあまあ。
変わっていくものだからね。職種は。
何がいいかね。
ちょっと探りながらやってくわ。
そうですね。
はい。ということで。
今日はSDDでございます。
バイブコーディングの問題点
SDD。
聞き慣れない言葉じゃないですか。
SDD。
確かにね。
スペック・ドリブン・ディベロップメントの略でSDDだね。
いやー、ピンとこないね。
まあ、あれだね。
バイブコーディングはこれからSDDだよねっていう世の中の流れがあるから、
ちょっとバイブコーディングからなんでそういう世の中の流れになってるかみたいな話をちょっとしていこうかなっていう。
バイブコーディングは聞くようになってきたし、バイブス上げてやっていこうぜみたいな、
そういうノリとテンションでコードを作っていくっていうやつだよね。
そう。で、ノリとテンションで仕事してるやつ、いいけど嫌じゃんっていうのはあるじゃん。
そうだね。そのせいでよくわからないコードが量産されて、
実はAI使ったせいで仕事が全然遅くなってるみたいな弊害もあったりなかったりと聞きますよ。
そうそう。一般的にまあそんな言われてて、で、スペックドリブンデベロップメントが、スペックが仕様とか仕様書。
で、ドリブンが駆動でデベロップメントが開発だから、仕様駆動開発とか仕様書駆動開発って言われる略称だね。
なるほど。
俺的には天文の研究ずっとやってたからシリコンドリフトディテクターなんだけど。
もっとピンとくる人少なくなったよ。
久しぶりに聞いたでしょ。
久しぶりに聞いたけど。
シリコンドリフトディテクター。
はいはい。SDDね。
俺最初なんでいきなりこのタイミングでシリコンドリフトディテクター出てきたのかなと思ったんだよね。
そんな人多分一人もいないんじゃない。
俺だけ多分そのSDDって言葉に違和感を感じずに吸って入ったの多分。世界でも結構俺がトップレベルだと思う。
シリコンドリフトディテクターについての解説は宇宙話聞けばいいっすか。
そっちでお願いします。
はいそっちで。
宇宙で使うX専用のCCDカメラの機構ね。
そうですね。
それは一旦覚えておいて。
で何でしたっけ。
SDDスペックドリブンデベロップメントね。
それがあることでバイブコーディングの弊害や課題みたいなところが解消されるってことなの。
そうそうそうそう。もう本当に本当にその通りで。
さっき言ってたみたいなバイブコーディングバイブスドリブンデベロップメントなんだよね多分ね。
なるほどVDDなんだ。
バイブコーディングといい感じに対にしようとするとバイブスドリブンなんだよ。
もう溢れるがままのアイディアを溢れるがままのコーディングに乗せて即興でまあ即興ラップみたいな即興で歌作ってとりあえずなんかぽいものができてるみたいな。
けどCDにしたらおおみたいな。
編曲結構する方がいいなみたいな感じ。
わかるわかる。実業部とかでバイブコーディングし始めるととりあえずなんか動くものできるんだけど実際にこう世の中にリリースできるクオリティのものはできてこないというか。
完成度80%90%くらいまでは作ってくれるけど残りの10%が全然到達しないみたいなのがよく起こるのがバイブコーディングですよね。
まさにでなんかそれってそのまあAIのそのモデルが良くなってきたからこそAIに結構任せてよくねみたいなエージェンティックな動きしてくれるAIツール増えてきたし
まあそのあたりに任せていけばある程度魔法の杖っぽくAI使えるなみたいな。
でなんかそんな感じなのにもうエンジニアの仕事なくなるよねみたいなのとか言い出してて世の中こうちょっとアンチの雰囲気が出てたり驚き屋さんが叩かれたりみたいななんかそういう世の中の流れになっちゃうみたいな。
わかるめちゃめちゃそのなんだろう心理をついているところが見えにくくなってきてすごいAI詳しい人たちが量産されている世の中SLSの世界みたいなのが見えてきてますよね。
逆にこうめくれてきてますよね。
まあそうね。
本当のこと言ってる人言ってない人で。
そうそうそうでなんかそういう話を聞きたいと結局はなんか個別の勉強会とか行かんとあんまこう実務で使うにはこうすりゃいいのかみたいなところまでたどり着けなくて困るみたいな。
困る困る。
そうっていう風になっててでそんな中でちょっと開発の方法VIVEだけじゃきつくねVIVEだけだとちょっときつくねってなって今までじゃあ俺らってどうやって開発してたんだっけって考えると結局仕様書ちゃんと作ってたよねみたいな。
AIとSDDの連携
はいみんな大嫌い仕様書設計書。
そうでよく考えたらいやこれ仕様書をちゃんとAIと作ればいいんじゃないかみたいな発想でこうものを作っていこうっていうので提唱されてるのがこのスペックドリブンデベロップメントなわけよ。
あーなるほどよりなんか実務に近いというかリアルの仕事の中だとこの方法がいいんじゃないかっていうことか。
そうそうそうでただまぁその概念だけ伝えられても正直多分浸透しなくてで浸透した要因はあのAWSから出たキロっていうIDEのサービス。
うんうん。
まぁあのコパイロットとかカーソルとかみたいななんかそういうツールとして使えるAIエディターみたいなやつがAmazonから出たと。
それが何SDDと関係があったの?
あそうでキロのその設計がそのSDDを実行するための仕様になってるの。
へーあそうだったんだそれは全然知らなかったな。
なんか例えばまぁカーソルとかコパイロットGitHubコパイロットとかはASKモードとエージェントモードみたいな感じのこううまく使い分けながらコードを理解しつつこう伴奏してもらうような形でこうコーディングしていくみたいな流れがあったところに
あのSDDの要素が入ってるキロではバイブモードとスペックモードだったかな。
へー。
っていうのがあってその仕様をちゃんとバイブでバイブスでどんどんどんどん作りたいものをまぁ描いていきながらそれをこう仕様処理もどんどん落としていってその俗人性みたいなのを減らしつつちゃんとドキュメント落とした上であの最後ゴーサイン出そうぜみたいななんかそういう作りになってる。
なるほど。理解はしつつそんな簡単にできるものなんですか?その仕様処作りつつバイブスを使って覚え描くのこの相反するものをうまくこうまとめながら開発できるイメージがまだ持ってないんだけど。
でもその基本的にはそのスペックの方、仕様処の方をガンガン磨いていくっていうのが重要で、そこをいい感じそのバイブスで生み出していこうとしていたものをまずは仕様処に落としていくところを手伝ってくれるのがキロだったみたいな。
だからこういうの作りたいってなったらこういう仕様処に落とせるものですよねみたいなイメージ。
なるほど。じゃあその提案してもらった仕様みたいなのをこの専用の形式のドキュメントとしてまとめていかなければいけないと思うんですけど、
それって今までの仕様処と全然違うんですか?今までって結構エクセルとかそれこそスプレッドシートとかもしかしたらドキュメントベースでばーっと文章で仕様処を書くみたいなのがあるあるだったかなと思うんですけど、
それをAIが作れるとあんまり思えなくて。
でもあれってちゃんと構造化してるデータとかでやってるから、一応MDファイルとかで再現は一応できる。マークダウン型で再現はできる。
テーブル構造で持っていたものを落とすこともできるし、一応ちゃんと最初にこれをやんなきゃいけないとかこういうリクワイアメントがあるとかも含めて、一応まとめれるはまとめれるはずなんだよね。
それを結構AIが補助してくれる。むしろこういうの作りたいんだったらこういう仕様になるっていうイメージだけどいい?みたいな感じにしていく。
で、これ俺もキロめっちゃ詳しいわけではなくて、キロともう一個その後ぐらいからそのキロあんま、ウェイティングリストとかでめっちゃ待つみたいになって、
で、そのぐらいから日本語に特化したSDDができるツールみたいなのが出たのよ。AI開発の国産ツールが。これがCCSDDってやつで。
CCSDD。ただのツールの名前ね。で、これも普通にターミナルでNPXほにゃららみたいなのであれば簡単に落とせるようになっていて、
で、こいつもSDDを実行するためのツールとして割とその時期に名を馳せたものになってるんだけど。
裏でLLMみたいなのが接続されて、対話形式でドキュメント生成とか開発ができるみたいなものなんですか?
そうそうそうそう。で、イメージ3段階ぐらいのファイルを、3段階というか3種類ぐらいのファイルを一緒に作っていくみたいな感じで、
まずはその要求仕様書みたいな、requirements.mdってやつを作っていくらしいのね。
マークダウン形式なんだね、基本的に作っていくと。
そうそうそうそう。で、これがなんかそのどういうものを作りたいのかっていうのを投げかけてった時に、
要求している、そのこっちが要求している事項をどんどんまとめたもの。
こういう認証条件欲しいですとか、こういうサービスを作ろうとしてて、こういうログインの形を取りたいとか。
で、ここのサービスの中にはこういう風に、例えば、to do管理するアプリだからこういう機能を載せたいとか。
そういったものがバーって入る要求、ユーザーからの要求が、Vibesだけじゃなくてちゃんとドキュメント化されたものをまず一緒に作っていくみたいな。
なるほど。それはもう人と対話しながら文章としてまとめてくれるんだ。
そうそうそうそう。俺も結構ドキュメンテーションするのに、AI出てきて正直一番助かったもののうちの一つは、俺はドキュメンテーションな気はしてて。
使用頻度としては多いかもな。
そうそうそう。だから書きたいこととかバーって羅列しとくと、ある程度ルール決めてあればちゃんとその形式でできるみたいな。
日報とか、自分の中の振り返り用の日報とかも、形ある程度ルール作っといて、箇条書きでバーって投げて日報っぽくなるみたいなので残しといたりもできるし。
書籍とか書いてるとなおさらもうそういう機会も増えますよね。
増える増える増える、マジ増えるね。なんかこれ書きたい、それこそ書籍書くときに多分俺の一番の強み多分その引き出しの多さなんだよ、宇宙の中でいうと。
その宇宙の書きたいことと書きたいことをバーって箇条書きみたいなバーって書いて、それをどういう文章に落としたいかみたいなイメージとかを伝えて、多分それの方向性をまとめてくれてるのがSDDの一発目みたいな部分。
これを入れたいんですよね。この要素を入れたいんですよね。こういう文章の形にしたいんですよね。
で、これ参考文献とかなきゃいけないんですよね、みたいなのもバーって書いてあるみたいな。
でもそれはすごいイメージが持てるから、多分プレゼンシルとか作るときの使い方としても同じような使い方してる人いっぱいいると思うし。
あー、そうねそうね確かに。何を伝えたい資料で、1ページ目はこれがあってキーメッセージはこれでみたいな。
そうそう。それのプロダクト開発版みたいなイメージだね、今回。
そうだね。それも、その後も全部AI駆動で動いていくから、人間が自分が作りたい雰囲気でそのドキュメントを作るんじゃなくて、
AIと対話してあくまでAIが作っていく。で、それを人間がレビューするみたいな形で、使用書をしっかりと固めていくっていうフェーズをちゃんと取るみたいな。
なるほど。
魔法の杖っぽく使わないようにしようねってことだね、もう。
ちゃんと段階踏むから、それがファーストステップなんですね。
そうそうそう。あとは、じゃあそこにどんな技術が必要なのかっていう、技術設計書みたいな。
技術関連の情報をまとめとくファイルっていうのを作っていく。
技術関連。具体的にどういうものが入るんですか?
例えば、裏で作る、そこから取得できるデータテーブルとかの定義はそこに入るし。
ああ、なるほど。
とかもそうだし、さっき言ったみたいにログイン機能をつけるときに単純にメールアドレスでやるとかってなったら、
メールアドレスの情報を取るだけでいいけど、例えばGoogleでのログインしなきゃいけないってなったら、そこの認証はこういう技術設計で取っていきますみたいな。
なるほどね。どういうAPIとつなぐのかとかそこら辺の。
裏側で使うエッジサービスとかそういう話か。
たぶんここがちょっとエンジニアが一番パワーを発揮しやすいというか。
そうですね。インフラの設計とかバックエンドフロントエンドの実際に使うツールコンポーネントみたいな話を。
結構はそうですね、今までの開発と近い技術スタックが必要になってくる領域ですね。
仕様駆動開発の重要性
ここでしゃべってって解像度低いところが出てきたら自分で調べればいいし、人に聞けばいいしみたいな。
で、技術系のそのテックMDとかなんかデザインMDみたいなテクニカルなんちゃらドットMDみたいなファイルを作るわけよここで。
なるほど。
要求がこういうもの、それに対してこういう技術スタックが必要ですみたいなものが出てきて、
それを含めて実装する時にはどこからどういう順番で実装すりゃいいんだみたいなところをAIにプランニングさせて、
それを人間がレビューしてその順番でいいかどうかをまずは決める。
ああ、そうなんだ。まだその段階でも走らせるんじゃなくて、さらに計画を立てをするんですね。
そう、そうしないとやっぱりうまくいかないみたいなことが分かってたりするわけ。
一番AIを万能だと思わない使い方で、ブレることなく開発を進めようぜっていうのがまず多分根本思想にあるんだよ。
いろいろ見てると。し、実感するし、自分で触ってても。
使用書ちゃんと作るか作んないかだけでもバイブコーディングと多分断値の差が出るじゃん。
そうだね。
それにプラス使用書めっちゃちゃんと作っても、その技術要件固めてなかったらAIにそこを任せることになるから、
なんかそれって人間にそんな仕事の振り出し方しなくねっていうところに多分帰っていく。
だから、人間にはちゃんと丁寧にやるんだから、AIにも人間に仕事振り出すときぐらいちゃんとやろうよみたいな発想なだけなんだよね。
多分何も新しいことはほぼないの。
開発プロセスの改善
確かになんかジャンプせずに今までやってきたことをAIを巻き込んで作ってくてるみたいな、そんな進め方ではありますね。
で、そこまで仕様固まってるんだったら、じゃあどっから作ればいいのかはさすがに考えれるっしょみたいな感じでAIに計画作らせるみたいな。
で、それをさらに人間がレビューをするんだ。
そう、人間の認証をおろそかにしないっていうのは結構重要なポイントらしくて。
それでようやく何、それでOKってなったら、後はもう丸投げでいいってこと?
実行していける。そうするともう後はようやくそれで道がもう、ここ行ったらこっち左行って、ここ行ったら右行ってっていうのが全部手順書に書いてあるから、
それの上をAIエージェントが走るっていう一番ブレが発生しないし、誰がやってもほぼ同じような実装になるように作るイメージ。
確かに聞いてる感じだと上手くいきそうな未来が見えますね。
けどなんか色々触ったり調べたりしても何ら特別なことではないというか、むしろ引き戻されたみたいな感覚の方が近いなと思ってて。
これまでのバイブ数、バリバリのバイブコーディングの状態から、今までこれまでところに引き戻されたってこと?
そうそうそうそう。ブレがデカすぎて仕事で使い物にならないから、仕事で使うんだったらバイブコーディングじゃなくて、今までのやつにAI組み込む、
AIに伴奏してもらうだけじゃねっていう発想の提唱で、実際超目新しいこと実はあんまりないみたいな。
そうかもしれない。正しくAIを使ってるのが、より正しく使ってるだろうなっていうのがすごく伝わりますね。
でもやっぱり楽になる。実際に使ってみると、そのSDDの方法でやると。楽にはなるよね。
最後の、バイブコーディングで気持ちいいのって多分思考の時間が短くて、けど形になるっていうのが多分めっちゃ気持ちいいポイントなんだけど、
そこの中毒性みたいなのを一旦犠牲にしてるけど、けど出来上がるものへのイメージ?
指数関数的な多分、スピードの上がり方。最初はめっちゃ緩やかで、いっぱい詰めて詰めてってやって、最後それがドーンってクリアになった瞬間に、
開発スピードがブワって上がるみたいな。AIも迷うこともないし。
そうだよね。最初に言った90%まではいくけど完成度がね。それより上になかなかバイブコーディングだといかないっていうところも解消されるわけ。
そうそうそうそう。で、そこがうまくいかないのって、
情報を追加する余地とかが残ってないとか、新しい機能を追加するとどっかに弊害が出るみたいなことになって、
そうするんじゃなくて、普通にモデルとかあったり、ソフトウェアというかウェブアプリとかがあったりみたいな、
あった時に、じゃあ新しい機能を追加しますってなったら、今の手順を踏むじゃんきっと。
仕様書があって、仕様書をこういう仕様に書き換え、変えます。で、それでこういう技術系をカバーしなきゃいけない。
で、それに対して今ある実装に対してここに追加しますみたいな、多分手順を書くのか、ちょっと他のところも修正しつつ新しい機能追加するのかみたいな感じになるから、
さっき作った仕様書を一回ブワーって縦に作り切ったところに書き加えていくような形で多分修正もできるから、差が出にくいというか。
仕様変更にも強いんだ。ありがたいね。あとドキュメントが残ってるっていうことで、チームで開発するときとかのこの横のコミュニケーションコストとかもぐっと下がるし、
それがすごくいいのかなと思いますね。いやまさにそこだよね。そこがやっぱりどの手順でやったか。
バイブコーディングって再現性がないっていうのが多分一個あるから、それを再現性のあるやり方で俺はやってるぜみたいな人たちの多分いろんな画流とかがある中での、
一個割といいよねって思われてるのがSDDみたいな。大事だね。このプロンプト使っておけば大丈夫だからとかいう。自分は信じていなくて、それは。
そうじゃないからね。いや仕事においては大事ですね、この仕様書設計書っていうところ。
けどなんかそう、やっぱじゃあ元の今、ナチュラルにAI使って仕事するみたいな人たちはピンとこないかもしれないんだけど、
俺多分最初そのアクセンチュアイズムがめちゃめちゃ強いコンサルの中で働いてる時とか、仕事の振られ方めちゃめちゃ楽だったなぁと思ってて、
AIに置き換えられるような仕事からスタートしてるからさ、言ってしまえばこういう集計がしたいからやってくれとか、
こういうモデル作ろうと思ってて特徴類をこうやって追加してくれみたいなのも、もう出力される、
例えばテーブルの構造からデータタイプまで俺の上に入ってくれてた人とかはもう全部書いてあって、
それを渡されて、これでわかるよねみたいな、OKっすって言ってそれを作るだけだったから、
俺も割と人への仕事の振り方、なるべくそういう形にするか、もう自立性を育ててもらうために一旦雑に投げるみたいなのもある、たまにはあるけど、
なるべくそのぐらいの流度で渡したいっていう自分の経験も含めてね。
そうしたらそれってなんか、まあSEDってそういうことだよなみたいな。
手順のところまでは口を渡さないにしても。
なんかそれと一緒だから、やっぱ自分がやってたこれAIに置き換えれるようなあの時の俺の仕事って思ってるものを解消する時の振り出し方が別に、
優秀なコンサルの人がやるそれや、みたいな感じ。
部下を過剰評価しすぎて期待値爆上げしとかないみたいな。
AIとの協力とコミュニケーション
ああそうそうそうそう。
それと一緒にAIに対してすごい期待値上げすぎないで、まあ言うてもAIなんだからくらいで、
まあ本当に部下に接するときと同じような使い方ってことですよね。
で、自責だよね。その自分の振り出しの流度が荒すぎたからAI群はうまく動けなかったって考え方もそうだし、
あとは多分その人たちの頭の発想的には、手戻りの方が自分の取られる時間がでかいっていう発想多分あるんで。
めちゃめちゃわかるなそれは。バイブコーディングの手戻りえげつないですからね。
そうそうそうそう。
っていう多分その感じをうまくぶれないように、
AIに投げたいところを一個我慢してAIと一緒にプランニングしようぜみたいな。
いい考え方だし、なんかすぐにでも取り入れられそうなのかなと思いつつで、
これ最初言ってたキロで始まって今は何でしたっけ?CCSDでしたっけ?
CCSDっていう日本語特化ツールみたいなのも出てるって。
正直その2つキロも含めてあまり馴染みないくて、
VSコードとかそれこそコパイロットを使ってますよとかそういう人たちが、
このSDDの考え方で開発しようと思うとスムーズにいけるものなんです。
となりのデータ分析屋さん、今回も面白いと思ったらフォローレビューよろしくお願いします。
番組の感想や質問は、ハッシュタグとなりの分析屋。
となりのがひらがなで分析は漢字でお願いします。
また概要欄に貼ってあるお手紙フォームからコメントを寄せください。
ではまた。バイバーイ。
