今仕込むんだったらそれだと思うんだよね。
人間中心っていうのは結構普遍な話だから今後も。
まあきっとね。
そうね、まあ使うの人っていうところがまあそうなんじゃないですかね。
だからなんかその最適な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でバイブスで作ってある程度回るものだったんだけど、
その求められるレベルがこのスピードめっちゃ上がってるみたいな話したじゃん。
なるほどね。でもプルリクの回数とか多分増えてくるから、単純にレビューの回数とボリュームも増えてくるんじゃないかなと思いますけどね。
ああまあね、そうね。でもその、今の俺らが作ってるサイクルの方は、そのプルリクで上がってくるもの自体はその前にめっちゃレビューが入った状態で最後送られてきてるから。
ああ、そっかそっか。
そうそうそう。まあ結局どこのタイミングでレビューが入るかっていう話なんだけど。
はいはい。
で、なんかじゃあその問題にぶち当たった時に、どういう解決方法を打つのかみたいな話もやっぱ大事で。
ほう。
SQLもっと上手かったら解決するんじゃないっていう、あの実力底上げの発想と。
はいはい。
あとは、いやプロンプトとかのステップとかをのシステムが悪いって考える派と。
はいはい。
っていうところがやっぱ出てくるんだよね。どっちも正解なんだけど。
はいはい。
はいはい。
俺はもう完全に後者に振り切るって決めてて。
うんうん。
だからその正直、詰めるとこまでシステム詰めた上で無理なら、ちょっともう一回勉強し直せばいいけど。
多分もうほとんどいらないんじゃないかなと思ってて。
その字型、字型つけるのもほんと数週間の研修だけで十分だろうみたいな。
川塚おじさんの話ですか?
あそうそうそうそうそう。でそれはそうじゃなくて、じゃあなんで今そのうまく狙った、あの言われたものと狙ったものにこう買い入りが、狙って作ったものに買い入りがあるのかみたいな。
うん。
ので言うと、それこそ俺的には、その仕様書ちゃんとお前丁寧に作ってるのかみたいな。
あー。
そしたらまあ、今までのバイブスの感じで言ってたみたいな話になって。
けど、もう一方でさっきの俺とは違う派って言ってた人たちは、
AIがバイブスで出してきたAIのやつをしっかりレビューできればいいんじゃないっていう自分で。
セルフレビューの能力が高ければその上の人のレビューコストかからないじゃんみたいな。
っていう発想。
あーまあその気持ちも分かるね。
ってなって、あーまあ確かにな。
まあどっちも正解なんだけど、
今、今書けるんだったら俺は、そのひたすらシステムの整理していく方がいい気がするんだよねっていう。
なるほどね。
それは何?今後の未来を見据えてっていうこと?
あ、そうそうそうそう。
こっから2ヶ月ぐらいじゃあ、自型をつけるためにエンジニアリングとか分析とかの自型をつける期間を取ったとして、
そいつが伸びるだけじゃん。
そうだね。
でもなんか、その2ヶ月間でシステムを作りきったらチームメイト全員が助かるんだよなみたいな。
でなんなら来年の1年目のこの初速もっと上がるよなみたいな。
って思うと、その個人のただの能力だけ見たらもしかしたら自型をつけるのが大事なのかもしれないけど、
チーム全体とかちょっと長い目で見たときは、システムの整理してそれを解決しまくって、
でその姿勢をSQLを磨く時間よりもそれを推進してきた経験を積んでもらった方が、
結果新人の子もいいんじゃないかみたいなチームとしてもいいし。
確かに確かに。
全体のパフォーマンス向上というかが上がるという。
なんかあれですね、最初の自己紹介の通りですね、AI新規事業開発責任者でしたっけ。
AI新規事業責任者ね。
まさにその観点であれですね、見てますね。
そうね、そうね。
まあそうだよなあと思いますね、確かに。
けどまあ。
分かる。気持ちは分かる。
分かる。
でもなんか徐々にその共通認識とかもあってくるといいですよね、チームメンバー。
他のレビュアーの人たちも含めて。
そうね。
近いうちにその答えは出てくるんだろうし、パフォーマンスどっちが上がるかっていうところは。
そうね。
そういうどうなんだろう、正直わからんよね。
でもなんかSQL書く能力は1年後ぐらいには本当に必要なさそうじゃん。
でもどうなんだろうね、本当にわからない。
その全くできないのは多分無理じゃないですか。
SQL何それおいしいの状態じゃ絶対話にならなくて。
まあそうね。
じゃあどこまでつけるかっていうその線引きというか。
そうね、そうなんだよね。
でもそこの実力をスキルを持つことにどれくらい価値があるかっていうのがちょっとまだ見えない。
あんまスケーラブルな話じゃないように感じるんだよね。
じゃあ必要最低限ってどこのラインだろうとか。
それが時間とともに変化するものなのかその必要なスキルが。
すんじゃないのかなさすがに。
やっぱAIが賢くなっていきすぎちゃうからね。
はたまたSQLとかPythonという言語をもう意識しなくて良くなる世界線があるかもしれないしとかね。
それはねそう思ってるマジでそう思ってる。
ちょっとこればっかりはな。
そうデータベースの持ち方の思想みたいなのは多分こっちで持つ必要があるから。
ちょっとまだ見えにくいとこですねここは。
そうね。けどまあ変わっていく中でとりあえずそのそれに順応できる土台を作るみたいな。
とこだけ注力していく以外もうなんか松川だからさ俺らって結局AIの進化法。
もうなんかオープンAIの動きあって地味にあってみたいなさ。
もうなんか多分3から5手先ぐらいまでもう開発終わってんでしょみたいな。
その可能性は全然ありますよね。
誰が一番最初に出すかみたいな。
で出したところにかぶせにいく手札を多分地味に4ぐらいまで持ってんじゃないのもうみたいな。
手札だけめっちゃ持ってそうっすよね。どれでいこっかなみたいなね。
そこはもう政治判断みたいな。
政治判断みたいな。お前らはとりあえずどんどん作ってろみたいな現場の。
それを待つだけの俺らっていうね。
いやそうだと思うな。
まあでも今日の今回の話はそれとはまたちょっと違って
死をどう決めるかっていう人間がどうしたいかを実現するための方法論っすもんね。
そうそうそう。でしかもそれはある程度までのAI賢くなったり
ステイトオブジェアートみたいなのが変わっても変わらず資産として残り続けるものだから。
いやこの考え方は大事だよな。
改めて使用書ちゃんと考えようっていうそう考えるきっかけになりましたね。
リッチなドキュメント一瞬で作るのは結構いい時代なんでそこをちゃんと過論じない方がいいっていう。
そうだよね。別に使用書作るのは面倒くさいって思わなくていいんだもんね。
そう。
いいよね。これはめちゃめちゃいいよな。
なんなら使用書がもうないサービスとかきっとあるからね。昔過ぎて。
あーあるね。全然ある。
使用書から作るのみたいな。
結構あると思うよ。プロジェクトとか新しく入ってあれ?使用書どこ?みたいな。
あーもう更新できてないんだよねみたいな。
最終更新2018みたいなね。
恐ろしい。
2022みたいな。あれっつって。
そんなサービスはもうダメだと。プロダクトはもうダメだとね。
でもAIのおかげで。別に動いてるから逆にいいんだよね。
動いてるからむしろコードがちゃんと噛み合ってるから動いてるわけで。
そうするとコードから使用書は作れるから。
はいはい。そうか。
リバースエンジニアリング的なことができるから。
壊れたときが最後だよね。なんで壊れたんだろうで終わるよね。
そうそう。その前にレガシーコード的なものは使用書も含めて整理して自動化できるところは自動化しておくみたいな。
のがめちゃめちゃ大事なんだよね。
っていう感じでしょうか。
はい。いい回ですね。