この番組はエンジニアの成長は楽しい学びからをもっとに日々インプットした話題をワイワイお届けするラジオになってますはいはいはいというわけで今回はですね吉田さんゲスト回の後半戦になってますはい前回はですね前吉田さん

私の会社の先輩の吉田さんの開発チームでまあ ai 駆動開発をやってみた でその後まあ ai 駆動開発をしたりスクラムをしたりその後使用駆動開発のというものに出会い親使用駆動開発というかまあ ai ai 駆動開発ってひょっとしたらスクラムのスプリントと相性悪いん じゃないっていう

話で終わって相性悪いんじゃないの続きが今回になりますなるほど前回はビフォービヨンドスクラムで今回はビヨンドスクラムということですねはいそうですねビフォーってきたからアフター来るのかと思ったのはビヨンドなんでねビヨンドだからアフターじゃないですからねというわけで吉田さん自己紹介お願いしますはい吉田と言います

私はエンジニアもやったりスクラマスターやったりとかアジャイルコーチもやって最近は会社のAI駆動開発の推進をやってたりしますAIの力でみんなが幸せになれるような環境を作るのが大好きですよろしくお願いしますよろしくお願いしますありがとうございますでは吉田さんのチームで使用駆動開発はスプリントと相性悪いんじゃないっていう話が出た後に一体どういう打ち手とか

打ち手打ってどういうことがあったのかというところをちょっとお話しいただいてもいいですかそうですね前回は見積もり見積もりじゃないわスプリントと相性が悪いなぜならば5日間スプリントがあって

5日間のスプリントの中で3日間計画会議をしてしまっているのでそもそも開発期間2日しかないものを見積もったりすることってそもそも微妙だよねみたいな話とかあとはその5日間の中でAIを使ってどんどん開発をしていくと

振り返りが遅くなるっていう話をしましたよね1個開発をやって1個振り返りをやってみたいなそういうサイクルで行った方がいいんじゃないかなみたいなことがきっかけでしたとそうなってくるとじゃあAI駆動開発をしながら使用駆動開発はやっぱりチームとして前回も振り返りがめちゃくちゃ開発者から使用駆動好評だったっていう話をしたと思うんですけど

なのでAI駆動とか仕様駆動はやり続けたいんですよチームの総意としてでもスクラムとはスクラムは全員がやり続けたいっていう風な思いは持ってなかったんですよねっていうのがあって結構色々調べ始めましたとでエンドレスのブログを読んで

漁っていってる中でAI DLCというものを発表してる日本語のブログを見つけたんですね私前職で一緒に仕事してたメンバーがちょうど和訳をした記事だったのでおー何これってよくよく読んでみるとAIを使った中のそもそも開発のライフサイクルっていうものは今はこれがいいんじゃないかみたいなことを提案しているブログがあったんですよでよくよく読んでみると

英語のブログなんですけどホワイトペーパーそのものはそのホワイトペーパーをよくよく読んでいると今私が言ったような不安不満が書いてあったんですよまさにこれなんか私が思っているペインポイントをすでになんかAWSの中の人が

それを解消した新しい実践方法として世に出してくれているぞと思ってこれはやってみる価値があるんじゃないかって思ってチームの中に提案として放り込んでみたんですよ今我々はこういう課題があるからこれをやってみるのはどうですかっていう風にやってみるんですけどやっぱり結構そこで問題になってくるのが僕が支援しているのは割と大企業

なんですよねで大企業の方々というのは結構往々にして上のメンバー まあ偉い人たちから俺たちはアジャイル開発とかスクラムをやるべきなんだみたいなふうに言われていて結構やっていたりするんですよ で私がそこにじゃあスクラムは上手にやるのはこうですよって言ってしない役として入っている中で スクラムをやめるみたいな

決断になるわけじゃないですかそれを試すっていうだけだと上の人が許してくれませんっていう話があってでもAWSさんが言っている新しいAI駆動の手法っていう手だったらやってもいいですっていう風に言葉をいただいたんですねなのでAI駆動にマッチした新しい開発手法をチャレンジしているっていうのはやっぱり

大きな会社にとっては他の部署に対してもすごいアピールになるっていうのがやっぱりあるみたいなんですよっていうのもあって誰が見てもこのAIDLCになるものをやってみたいぜっていうのが障害がなくなった瞬間だったんですよでもいきなりそれをやめるだけではなくてやっぱり一回じゃあどういう風にやっていくかを計画立てた方がいいよねってなって私が1週間2週間ぐらい

めちゃくちゃChatGPTに質問してホワイトペッパー食わせてChatGPTプロプランを契約して壁打ちをしてもらってめちゃくちゃChatGPTにいっぱいアドバイスをもらってうちのチームではじゃあこういう風にやったらうまくいくっていう

プランを出したんですよでその後にちょうど前職の同僚がブログを和訳した本人だったんでもうその人にDMして強いこの前のブログ読んだよで今俺が考えてる最強のAI DLCはこのやり方だバーンってスクショ送っていやこれはダメってすごいそもそもこれはダメっていうアドバイスをたくさんそこでもらってそうなのみたいな

というのもそのホワイトペーパーって実はもう1年半とか前に書かれたものだったらしいんですよ樋口 へえ深井 なので新しいバージョンを出すつもりもないらしいんですよねその当時のメンバーの話だと最新は今こうじゃないんだよみたいなアドバイスをもらってそうなのちょっともっと詳しく話聞かせてよって言って

ちゃんとAWS JAPANのメンバーとちゃんとした公式のミーティングをセットして今俺たちはこう考えてますっていうのを再度説明して分かりましたじゃあこういうやり方どうですかこういうやり方どうですかって超その場でやり取りをいっぱいしてなるほどよく分かりましたちょっともう一回練り直しますっていうことをやって今に至ると

めちゃくちゃ興味深いんですけどまずそもそもで申し訳ないですけどAIDLCってざっくりと何でしたっけっていうところでお話できますかAIDLCはソフトウェアデベロップメントライフサイクルっていう大昔から伝わる既存のソフトウェア開発手法があると思うんですよねSDLCっていう言い方をすると思うんですけどそれそのものをAI駆動で設計し直したとAWCジャパンのメンバーの

メンバーがやり直しましたと AI前提でライフサイクル組むんだったらこうだよねっていうのをバンと出してくれたブログが今年の7月ぐらいに公になったのかなその後にちょうどキロが出てきたんですよ なのでキロが結構インパクト世の中的にはでかかったと思うんですけど実はそれとほぼ同じタイミングでAIDLCなるものを発表していて そっちはあんまり注目を浴びてない

っていう形になりますね内容としては割とスクラムにはっきり言って近いですね割とアジャイルの流れを乗っ取っていてでもスプリントはない役割としてもスクラムマスターがいないんですよだってスクラムじゃないからなのでロールとしてはプロダクトオーナーと開発者あとはAIこの3つしか出てこないんですねでスプリントって通常

チームによりますけど5日間とかあとは2週間とかあと1ヶ月みたいなチームもあると思うんですけどAIDLCの場合はボルトっていう単位でイテレーションを回していきますとそのボルトの範囲は短いもので数時間長くても2,3日みたいなそういう周期でやるんですよみたいなことがホワイトペーパーには書いてありますねあとすごい大きいなって思うのが

スクラムとかエクストリームプログラミングとかアジアの開発全般そうなんですけどアーキテクチャーとか技術をこうしなさいみたいなことって書いてないんですよチームで決めてねなんですよねでもAIDLCは基本的にDDD前提なんですよねホワイトペーパーを読むとそう書いてあるんですよでもちょっとここら辺もね

あの、エフスの人に聞いたら「いや、DDDは必須じゃないんだよ今は」って言われて つ:へぇ~ つ:あ、そうなの?みたいなというのも、やっぱりDDDってめちゃくちゃ大規模なシステムにこそ向いているんですよねでも、そもそもDDDいらないシステムもあるので、まあそういう人でも柔軟にAIDLCは使えるように今、広げてるんだよみたいな話もあって

そうなんだここは必須なんだここは必須でこれは必須じゃないみたいなことは決まってるんだみたいなこともたくさん質問してようやくわかってきたという感じですかねめっちゃいいですね最近読んだんですけどそのホワイトペーパーでその先ほどおっしゃってたこのDDD BDD TDDをわざわざ言ってるあたりスクラムのガイドブックってやっぱり言わないじゃないですか吉田さん先ほどおっしゃってた通り

そのHowを指定してきてるのだいぶ思想強いなと思っててすごいこだわりがあるんだろうって思ってたんですけどDDDはまあそこまででもないよみたいなそこまででもないですね感じなんですねTDDもBDDもそうですね結局やっぱチームで決めていいようなんですねあとはなんかスクラムでもペアワークとかモブワーク推奨されてるかなとは思ってるんですけど

AIDLCはモブワークじゃないと回んないんだろうなっていう感触を受けてますあれはもうモブワーク前提って書いてますよね実際そこの点は変わってなかったですねAWSさんが言うやつ実際の回してる例とかも見せてもらいましたけどあれも全部モブでやってましたね実際やってみてもモブでやんないとうまくいかないんだろうなっていう気はしますね頻繁に意思決定していくので

いちいち非同期で裏でやり取りしてたらそれだけで時間かかっちゃうんでねホワイトペーパーって何でしょう厳密にルールみたいなのが書いてると思うんですけど多分こうやったら絶対うまくいくっていうのはないはずでないですね言える範囲でいいんですけど今ってどういうフローでAIDLCで開発をしてる感じになるんでしょうか

前半戦でもちょろっとお話をしたんですけど今僕たちは10人チームぐらいになってます正確にはちょっと9かもしれないですそのくらいなんですけど基本的に私が常に2つのチームの中で分かれるんですけど2つのチームを私が常に行ったり来たりをしながら片方が設計をしている間片方は開発をやるし

同時に開発をすることもあるんですけどね同時に開発をしてその裏では私が一人でプロダクトと相談しながらのパターンもありますけどもっと未来のバックログをホワイトボードを書いたりして常に私が叩きを作っているっていう動きを最近はしていますね片方のチームが開発が終わったらじゃあ私の一緒に設計に入ってもらって片方のチームの開発が終わるまでは一緒に設計をしてもらってじゃあ終わったタイミングで全員で振り返りをやって

じゃあ続きのホワイトボーディングここで終わって次のスペックが出てるのでじゃあこれ説明してみたいななので常に必要な時に計画会議をやって必要な時に振り返りをやって必要な時にホワイトボーディングしながら開発をしてみたいなことを常にぐるぐる回すような動きですねAIDLCで出てくる概念でインテントっていうなんとなく作りたいものの要件なのかな

があってそれを何とか仕様に落とし込んだ後にタスクに落とし込んでコードにして動くものになってフィードバック回すみたいなのがざっくりとした流れになると思うんですけど今の吉田さんのチームでそのインテントを作ってるのがPOと吉田さんいやPOですねPOがインテントを作るんですけどもうすぐにもう他のメンバーでそれをどうどうこうするというかホワイトボーディング始めちゃう感じですねめちゃくちゃAIの力を借りながらうんうん

なのでADLCですごい面白いなと思ったホワイトペーパーを読んで一番面白いなと思ったのはボルトというものの存在なんですよこれがスクラムだったら固定のタイムボックスですよねでも2,3日とかそういう最初にAIにイテレーション期間を計算させますって書いてあるんですよでもこれもすごい面白いなと思ったのがAWJapanの人に聞いたらボルトはやってませんって言われてえーえっと

ってここ一番肝じゃないのみたいなそうですよね思ったんですけどそこがもうなんだろうなスクラムも大規模なスクラムのパターンっていうのも実はあったりするじゃないですかスクラムアットスケールっていうものがあったりとかあとはレスって言われているものがあったりとか結構大規模なスクラムのフレームワークってあると思うんですよ

あそこのホワイトペーパーに書いてあるのは個人的にそっちに近いなと思っててめちゃくちゃ大規模例えば今から楽天作りますとかヤフーショッピング作りますとかヤフオク作りますとかああいうレベルでやるときにはあそこのホワイトペーパーに書いてあるようなめちゃくちゃ一番外側でDDDでやってドメイン分割をして例えばなんだろうなショッピングカートユニット

注文履歴ユニットとかそういう風にどういう風に分化するか分かんないですけどめちゃくちゃ大規模なやつはホワイトペーパー通りにやると思うんですよでもそうではなくてもっと簡略化できますっていう話をされたんですねそれがさっきさボルトがないパターンとかなんですよボルトってあくまで期間というか1回の1週ぐらいの気持ちなんですけどないってどういうことになるんですか

ユニットで始めるんですよねAI DLCでいうところのユニットスクラムでいうとこれをエピックって言ったりする時もあるんですよねでもユニットの単位で僕らは今バックログ一番最初の単位のバックログにしてしまっていますねなのでそこで終わるまでやるっていうことをやってますすいませんユニットって何でしたっけユニットはスクラムでいうところのエピックですなのでバックログを複数束ねたものなんですよね

具体的なことを言うと例えばユーザー登録っていう機能があるとしたらユーザー管理みたいなのがエピックですかスクラムの用語で言うと例えばですよ例えばメールをたくさん送りたい送るプラットフォームを作ります違うなそれちょっと言い過ぎだなどういう単位かなわかりました例えば楽天を作ります楽天を作りますっていう時に

クレジットカード決済の機能を作りますっていうのがエピックですねその中で例えばJCBを対応するっていうのがバックログクレジットカード決済全般を対応するっていうのがエピックですねうんうんうんうんうんでビザ対応しますっていうバックログマスターカード対応しますっていうバックログが生まれたりしてそれを束ねるのがエピックっていうのがAIDLCのホワイトペーパーに書いてあるユニットなんですようんうん

でもそれもめちゃくちゃでかい規模のパターンだとそういう風にもできますというだけであって実際のユニットは最小の単位でやってもいいんですよなのでホワイトペーパーを読み込むとそういう風に誤解しがちなんですけど実際の現場でやるときは最小の単位をユニットにしてもOKなんですよなので僕らはちょっと前半戦の中で例えばデータベースを作りますみたいな話をしたと思うんですけどこのデータベースを作りますっていうのを今ユニットにしちゃってます

なるほどしかもボルトはないなのでデータベースを作りますっていうユニットで使用駆動を始めてしまっているっていう形になりますね今やっているのはなるほどユニットが思ったより小さい規模になっていてひょっとしたらプロダクトバックロガイテムよりも小さい規模ぐらいでユニットとして回しているみたいなイメージそうそうおっしゃる通りですねそうですね

それでサイクルとしてはユニットで仕様整理してタスク整理して実装をしてユニット単位で動くのをスプリントレビューみたいな何かイベント打ち合わせがあって振り返りをしてみたいなサイクルでやってるんですか片方の2つの開発が同時にほぼほぼ動き始めるんですよねそれがお互いが

リクエイメント書いてデザイン書いてサブタスク切って開発をするっていう流れでそれぞれが進んでいくんですよでも同時に終わることってないんですよね例えば片方は3日で終わる片方は5日で終わるみたいな時があるんですよ先に終わってしまったあと2日余っちゃうじゃないですかそっちは私のホワイトボーディングを手伝ってもらいながら軽い検証を一緒に小さい中で回してしまって片方のチームが開発終わるのを待つっていうやり方で今はやってます

両方ともが終わるのが5日5日経ったタイミングで終わったら振り返りをやるでこのホワイトボーニングの結果も5日間頑張ってきたチームにも共有したりして一緒に振り返りやってじゃあ次はこういう風にやっていこうかっていうのを全員で話すみたいなことをやってますねなので固定サイクルではなくて必要な時に必要な振り返りと必要な計画会議が入ってくるみたいなイメージですねなんか本当に何でしょうね全員が100%稼働で同じ

タスクを全員でやってるから打ち合わせの調整とかもいらないですしいらないですねっていうので回せるスタイルな感じもしますねどこのプロダクトもそうなのかもしれないんですけど今の開発始めてから1日2日休む人がいるじゃないですかやっぱりどうやっても体調不良とかもそうで休むとみんな休んでる間に進みすぎて浦島太郎状態ですってみんな言いますね

すごいシニアなエンジニアでもそういう発言をするので多分うちのチームの開発すると多分めちゃくちゃ早いですなんかその趣味で触りますけど

業務時間1日だから7時間ちょいぐらいを設計とかを開発がガーって進んだ後追いつくのはちょっとしんどいですねでもこれが使用駆動のいいとこだなって思うのがやっぱり片方がホワイトボーディングをして片方は使用駆動してるだけなんでドキュメント全部残ってるんですよ僕ら今Google Meetとかも使っててそこの議事録全部出るようにしてるんですね

なので休んでもその時の議事録全部要約してもらったやつが出るようにもなっているし片方のモブの要約も全部出るし仕様書も残ってるんでなんだかんだ追いつけますねあと検索しやすいというか探しやすいというか探せる状態になってるって感じなんですよねそうですねそういう意味だと情報の透明性はすごい高いんじゃないかなみたいな気はしてますねそれは確かになるほど

ちなみに今の一周サイクルをお話したかと思うんですけどそれぞれ具体的などんなツール使ってどうやってるみたいなのとかって話せる内容はあったりしますか使用駆動は私のビヨンドスクラムの登壇をした時にはキロとCCSDDっていうものを使ってましたとキロはGUIになっているのでリクエイメントとかめっちゃ書きやすいんですよデザインに進むみたいなこともやりやすいんですね

対してCCSDDはキロが作ったやつって.kiloっていうディレクトリに保存されるんですけど.kiloの中身を当たり前のように標準で読んでくれるのでプロダクトオーナーとかスクラムマスターは結構GUIでやりたいんですよでも開発者はクロードコードでそのままシームレスにやりたいみたいな思いがあってそのツールを使い分けていたのが

ちょうど1ヶ月前ぐらいまでですね 1ヶ月前の登壇だったんでねで最近CCSDDがバージョン2.0に上がったんですよ で使用駆動のツールってスペックキットっていうGitHubが出しているツールとかもあったりしてそこでやってるやり方とかって例えばなんか research.md っていうデザインを補足してくれる

途中経過を作ってくれる、あのやってくれるやり方があったりするんですよで、最近CCSDDもそっちの流れを取り込んだみたいでなんかキロとは別の進化を遂げてきてるんですよっていうのがあってなんかCCSDDめっちゃいいんですよめっちゃ良くてその

他の使用駆動ツールの流派も取り入れてくれてガラパゴスじゃないですけどちょっと独自進化を遂げてきててそれがめっちゃいい感じなんですねキロがそれに追いついてないんですよ僕ら目線だとなので1ヶ月前まではキロとCCSDDで両方使ってたんですけどちょっとこれなんかそれぞれが独自進化遂げちゃうんだったらCCSDDに一本化した方がいいんじゃないかなみたいなことはちょうど今日喋ってましたねへー

キロ触ったことないんですけどGUIでリクワイメントとかが作れるってどういう感じなんですか?ごめんなさいGUIでっていうとただのIDEなんですよIDEなんですけどVSコードの左側にキロちゃんアイコンがあってそこを押すとリクワイメントとかがいい感じに見やすく出てくるぐらいのイメージでいいと思いますエンジニアじゃない人からしたらそっちの方が触りやすいっていう意味でってことなんですねそうですへーなるほど

インテント作るときはチャットGPTとかでやってたりするんですか最近はそんなことはあんまやってなくて割と

今昼1昼の13時から14時だけはプロダクトオーナーも絶対そこに来てねっていう言い方をしていてそこの中で結構プロダクトオーナーが口頭でいろいろ言ってきてくれるのでデベロッパーとか私とかがその場で一緒にチャットGPDとか使ってこういうことですかねみたいなことを合意しながら進めていくってやり方でやっていますね

なのでプロダクトオーナーは結構最近ステークホルダーとの調整にいっぱい走ってもらってそういった開発環境は全部こっちで吸収しちゃうみたいなこれがいいのか悪いのか分からないですけど今そういうやり方でやっちゃってますねなるほどそのインテント作る時のプロンプトじゃないですけど形とかってあるんですかこういう形式で作るみたいないやそれないですね今言われて思いました確かにそれあった方がいいのかもしれないなって思い始めました

今結構インテントをそもそもリクワイアメントに変えるみたいなことは結構デベロッパーでしかも各個人に任せちゃっているのがあるので結構人によってそこを決まってないですねありがとうございますインテントがあって叩きは

吉田さんが作るんですか?いや、それもさ、あのさっきの13時から14時の間でプロダクトの方にどんどんその場でバックログを、スペックの卵みたいな、インテントの卵みたいなやつをどんどんジラに切っていってもらってそのジラの中から後でみんなで整理していくみたいなことをやってますねそれをそのちっちゃいやつを元にみんなでホワイトボーディングするっていうのは片方のウィップでやってますねホワイトボーディングしたやつをPOがレビューしてで

レビューOKになったやつが開発というか設計に移るそうですねそのホワイトボーニングした結果もプロダクト内全部共有してますねうちのプロダクトがすごいいいなと思うのは技術にガンガン口出してくれるんですよこれが嫌だって思う人もいるかもしれないですけど

プロダクトオーナーって何か事故が起こった時とかにいろんなところに説明責任みたいなものもあると思ってるんですよっていうのがあって積極的に結構技術のことを質問してくれて理解した上で進めてくれるプロダクトオーナーが僕はすごい好きですねなるほどそれで開発ずつって

ちなみに先ほどもちょっと触れていただいたと思うんですけどチームとしてAIに情報を渡しやすくするためにいろんな仕組みを入れていると思っていてそれこそ議事録の話とかもそうですけどそうして今使っているツールってどんなのがあるんでしたっけ今は

結局全部VS Codeに集約させているんですよでさっき言ってたホワイトボーニングは今そのVS Codeの中でDraw.ioのファイルで設計書というかホワイトボーニングの内容を食わせてるんですねなので今こういうことやりたいっていうのをそもそもクロードコードにお願いをしてそのドローIOの描画すらやってもらってたりするんですよあと僕らが手で書いた内容もそのドローIOのファイルを読んでもらってクロードコードに理解させるみたいな

ことやってますねなので結構さっき言った通りすごいちっちゃい単位なんですよでそれそのスペックごとの繋がりっていうのを見ていくのはそのホワイトボーディングの絵とかになってくるんですよねなのでその合わせてAIに読んでもらうっていう環境を作りやすくしているのでツールはもうすべからく基本的にはVS Codeの中に集約していく流れですVS Codeというかソースコードのリポジトリですね中に全部集約していくイメージですねうんうんうん

確かにグラフィカルなもの系見ろとか書くとかあの辺どうやってAIに渡せばいいんだろうって思ってましたけど確かにドローアイオーっていう手があるのかとは今思いましたあるんですけどドローアイオーはやっぱドローアイオーですごい課題多いですねコンテキストが足りなすぎてやっぱ一つのドローアイオーの中に絵描きすぎるともうそれで読めなくなっちゃうんですよあとやっぱAIに描いてもらうのってめっちゃ時間かかるんですね

なので書いてもらうのはそんな使わないですね実はやっぱり文字でどういうアーキテクチャがいいっていうのを相談に乗ってもらって僕らがドローアイの中に書くみたいなことが多い気がしますAIだと時間がかかるっていうのは見やすい図に起こすのに時間がかかるみたいな感じなんですかそれがね分かんないんですよ今ね作業中ですってずっと出て

ずっといつまで経っても待ってるしか無駄だねって書いちゃうんですよ書いてる途中だと他のページ触ってるから今もう書けないよみたいなことで後から出てきておめえが遅いからだよみたいなことをみんなで突っ込んでましたそうなんだ何なんですかね確かにそれ謎ですねそうなんですよ最近ジェミニー3とか出たじゃないですかあっちだとねコンテキストめっちゃモテるよねみたいな話がしていたりすると思うので

コンテキストはどんどんウィンドウが広がっていく流れになるとそこら辺も変わってくるのかなみたいな期待はしてますねちなみにそのAIが読める系の図形とかだとなんかプラントMLとかマーメイドとかもあると思うんですけどその辺とかはもう既に試し済みみたいな感じなんですか

実はですねプラントUMLってすごいモデリングの図としてはめっちゃいいなと思っているんですけど僕らAWSのアイコン使った絵をめっちゃ描くんですよってなってくるとやっぱドローIOが一番見やすいよねってなっちゃってますね単純におっしゃる通りシーケンス図とかユースケス図とかねそっちだったらプラントUMLとかマーメイドとかも試したんですけど

やっぱAWSのアイコン出てくるドローIOこそだよねってなっちゃってますねもちろん試しました話すまで気づかなかったんですけどうちのチームめっちゃ実験してますねやっぱねそれはそう思いますよ愚直にやってて当たり前すぎてこうやって話してみると実はめっちゃいろんなこと試してるなって思い出させていただいてありがたいですねすごいなんでしょうね

メンバーだなチーム作りが一番いいんでしょうねきっと本当に学びこれちょっと喋ってなかったことが一個思い出してこれホワイトペーパーに書いていないことなんですけどさっき言った通りAIDLCってプロダクトオーナーとデベロッパーしかいないんですよ人って

これはちょうどAIDLC JAPANのメンバーと喋っていたんですけどプロセスを俯瞰して見れる人っていうのがいないと例えばAIDLCがうまくいかないみたいなことを俯瞰して見れる人がいないじゃないですかなので僕らがスクラム辞める時も僕がある意味俯瞰して見てたからスクラムを辞めてAIDLCに行くっていうチャレンジにするっていう観点が生まれてきたと思ってるんですけどAIDLCやっていく中で俯瞰してる人がいないとそういう判断できないじゃないですかうん

っていうのがあってなんかAI DLCマスターみたいなそういう人がいないとうまくいかないと思うんですけどどう思いますかって聞いたんですねうん

そしたら実はそれみんなから言われてますって言っててやっぱそうなんだと思って多分これからもしかしたらAIDLCもいつかホワイトペーパーが更新されるときにAIDLCマスターみたいな新しいロールが生まれるかもしれなくて今ちょうどそれをジャパンからグローバルのAWSに報告しようと思ってますみたいなことも言ってたんでもしかしたら日本発信でそういう文化が生まれるかもしれないですね面白い

今後コミュニティとかもできるかもしれないですね今はもうあるんですかコミュニティは聞いたことないですね多分いろんなところで試すと絶対にどうしたらいいんだが連発する系のものではあると思うので試験を集めようで多分なんかできたりもするかもしれないですねそうですね多分これからね積極的に登壇も僕もしていきたいですねAIDLCはいやーお願いしますそれお願いします

ちなみにいいですか質問AIDLCのホワイトペーパーみたいなところで結構いろんな細かいルールとか書かれてると思うんですけど最新だと意外とこれ必須じゃないよみたいなのさっきお話あったじゃないですか僕の今の脳内の中のAIDLCがルールがほぼ全てなくなってしまってるんですけど結局今って何が残ってるんですか残っているのは

最初に設計をしましょうと それはAIDLCの中ではDDDでやるんだよって書いてあるんですけどそこはDDDは必須ではないのでまずはスペックにユニットに分割するっていうことが残ってますねそれはプロダクトオーナーも同席でMOVでやりましょうっていうのがルールです

それがInception Phaseって呼ばれてるやつですね その後にConstruction Phaseだったかなっていうのがあって実際作っていくフェーズになるんですけども僕らはそれを仕様駆動でやっているってだけなんですよAIDLCは仕様駆動でやれとまでは書いていないのでその中でさらに細かく設計をして開発をやっていきなはれやっていう流れですねで必要に応じて振り返りもやるんだったかな 振り返りをやるとも書いてなかった気がするな

ある程度決まった単位で本番環境にデプロイしなさいとその前にテストもちゃんとやれよっていうのは書いてありますね多分それぐらいだと思いますルールざっくり言うとTDDとかBDDの話とかってどのぐらいの厳密さなんですか?割と必須なんかなと思ってたんですけど必須じゃないですあのホワイトペーパーはDDD版なんですよ

っていう風に書いてあるんですねなので待ってればいつかTDD版とかBDD版みたいなの出てくるのかもしれないですけどあれはDDDにフォーカスして書いてますって書いてありますねそうなんですねとはいえ人間見るの限界あるから何かしらで自動で品質担保する仕組みがいるけどみたいな感じではあると思うんですがそうですね詳しくなっていきたいなこの辺

やっていきましょうぜひぜひ吉田さんにちょっと今探索時期ではあると思うんですけどAIDLCこういう開発チームだったら導入向いてるんじゃないかみたいなのって見えてたりするのってあったりするんですかプロダクトの条件なのかチームの体制なのか逆に向いてないチームがいっぱいあるなと思っててそれも気になりますねAIDLCは

シニアなエンジニアがいないと無理なんじゃない仮説を今持ってますっていうのもなんでかっていうとやっぱりAIありきだからなんですよねAIが言ってることを間違ってることは間違ってるって判断できる能力がないとできないし最初の設計のフェーズですら正しい設計ってできないんですよね普通にチャットGPTプロとかのめっちゃ一番高額なやつですら平気で

AWSの仕様とかで嘘ついてくるんでいやそれできないでしょとかいやこれそもそもこのサービスじゃできないでしょとかいやもっとこういうやり方あるでしょっていうのを質問に質問で返すというかそういう能力が求められるのでAI DLCというかAI駆動開発はシニアなエンジニアがいないと

いいプロセスで回んないんじゃないかなっていうのが最近の僕の持論ではあるし多分世の中的にもそういう人がすごい増えてるんじゃないかなって思っていて僕の場合はAIDLCの場合は

スクラムをめちゃくちゃやってきた経験があるのでこのプロセスこういうことをやった方がいいなっていう改善案が山のように出てくるんですよでもやっぱりそういう人がさっきのAIDLシマスターが必要なんじゃないですかにすら行き着かないと思うんですよスクラムをめちゃくちゃやってきた経験がないというのがあってシニアなエンジニアあとはちゃんとシニアな開発プロセスを理解している人

がいてこそ真の意味でAIDLCが回るんだろうなっていう気はしていてその段階に至ってない人がやっても成果は得られないんじゃないかなって今は思っているんですよなのでなんでしょうねいきなりジュニアのエンジニアだけでスクラムやってもうまくいかないのと同じでそこそこちゃんと分かっている人がAIDLCやらないとうまくいかないんだろうなっていう思いですありがとうございますシニアっておっしゃってるのって主に

アーキテクチャとか全体って言っちゃ全体なんですけど全体か本当に全体なんですね技術領域とかも全部だしインフラもだしなんならこういう時にはこのプログラミング言語がいいよねとかですらやっぱり判断できた方がいいと思うんですよね少なくとも一人じゃなくてもその辺が全部揃ってるメンバーが集まってるチームでやる必要ありそうですねそうですね

やっぱりなんかゼネラリストかこそ勝つんじゃないかなみたいな気は最近特にしてますねなんかあんまり最近見ないですけどなんか僕はiOSしかやりませんみたいな人はそもそも多分アジャイル開発あんまうまくいかないんじゃないかなみたいな気もしますけどねうちのチームはたまたま全員が全部をやるっていうことをやりたいっていうメンバーが揃っているのですごいうまくいっているっていうのがあると思ってて

なんか今私iOSそんな得意じゃないですけど今クロードコードとかコーデックスとかの力を借りればiOS全然開発できるなっていう気がするんですよこれもやっぱりそこそこの経験があるからこそできるなっていうのも思うので何はともあれ

シニアがいないとうまくいかないような気はなんとなくしててでもそこら辺の畑でシニアエンジニア取ってこれないのでやっぱり現場でねこういうのでビシバシ学んでいくしかないんだろうなって思いますありがとうございます聞いてる方もシニアの人はチャンスだと思っていただいてシニアじゃない方は多分AIあっても

それこそAIDLCにAIの品質担保するのは人間で知的化をかけながら自分で頑張ってレビューしろよっていうことが書いてたかと思うのでそこは変わらないのかなと思っててやっぱりエンジニア自身のスキルアップとかは引き続き大事だなっていうところがありますねはいじゃあ大事ですねでは結構お話していただいてしまってもう時間がぼちぼちいってしまったのでそろそろ締めようかなと思うんですが

事前に言っておけばよかったんですが何か宣伝するものがあったら宣伝していただいても構わないんですけど何かあったりしますかいや何もないですはい分かりましたなんかX載せといた方がいいとかもありますか

URLにじゃあXお願いしますはいでは説明欄の方に吉田さんのXあと登壇資料スピーカーデックに載ってるやつですね概要欄に載せておきますのでもし興味があったら見ていただいたりXでポストお願いしますお願いしますはいでは吉田さん2回に渡りまして駆動開発の話ありがとうございましたありがとうございましたちょっとまたノウハウたまったら

またお話いただきたいなと思っているのでぜひよろしくお願いいたしますぜひぜひお願いしますイベントとかで吉田さん見かけた際にはお声掛けしてみてくださいひまプロ聞いてましたっていう人来たよって言われたら僕が喜ぶんでぜひ話しかけてくださいお願いしますでは締めますハッシュタグひまじんプログラマーでSNSでフィードバック募集してますので本日のエピソードの感想お願いしますぜひ学んだことをつぶやいてほしいですね

お願いします質問とかあったら拾えるかもしれないです私が拾って転送するかもしれないですお願いしますあとはポッドキャストのエピソードの説明欄からGoogleフォームで番組の要望・感想・質問お待ちしてます感想だけでも良いのでお気軽にお願いいたしますあとはチャンネル説明欄からスラックのオンラインコミュニティひまプロ談話室

の参加申し込みフォームありますのでAI駆動開発の話したいよという人いたらぜひお気軽にご参加くださいいろんなイベントもやってるのでぜひ覗いてみてください頑張ってますはいそうですね順平送別会をやるのかなオフ会がそうなんですかね

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