#474 スクラムは生成AIで加速させすぎてはいけない

この番組は「エンジニアの成長は楽しい学びから」をモットーに、昨日より少し成長できる学びをわいわいお届けするエンタメ系テックラジオでございます。 イエス。はい、というわけで、えっと今日はですね、僕の社内でですね、GenAI Wants to Speed Up Your Scrum Events という記事がちょっと話題になっていて。

Wants は？

WONT。

ああ、Will Not。

Will Not、はい。まあスクラムイベントを生成AIでスピードアップさせるべきじゃないよと。させないでねっていう記事なんですけど。

うん。

えー、まあなんか生成AIの活用とか、まあちょっとそのへんの話に対してすごいなんかいい示唆があったので、ちょっとここで紹介させていただければなというのでちょっと持ってきました。

はい。

で、まあ生成AIで、まあスクラム開発、生成AI使ってる人、まあよ、いるかなと思います。僕のチームでも、あのアトラシアンでロボっていう生成AIを、なんて、なんて言うんだろうな、あのジラに埋め込まれてて、そのサービスに埋め込まれてて。

はいはいはい。

で、それを使うとなんかAIがチケット操作したりとか、プロセスを調査して、えー記事書いてることを教えてくれたりとか、何かしらのAIを使ったオートメーションを作ったりとかなんかできるのがあるんですけど。

ドッカーでいうゴードンみたいなことですか。

ちょっとゴードン、知らんな。ゴードン何してくれるんすか。

ドッカーに今組み込まれてるAIで、いろいろ使い方を教えてくれるそうですよ。

はい。あ、ドッカーの？

うん。

ああ。

ドッカーデスクトップに組み込まれてんのかな。

はいはいはい。なんか使い方教えてくれるのプラス、なんかもっとアグレッシブになんかやってくれそう、あ、くれるようにできる？

どうなんだろうね。ちょっとそこまでね、詳しく見てないんだよな。

えっと、アトラシアンのロボはまあそんな感じなんすよ。

おお。

はい。で、まあなのでその開発を進めるうえで、まあAIうまく使えるとチームの開発スピードアップできるよねっていうところはまあ皆さん直感的にはそうなんかなというふうに思うとは思うんですけど。

もちろんさ。

はい。で、ただその使い方をまあ間違えると、まあ良くないよねっていうのはまあ当たり前なんですけど。

うんうん。

まあ例えばですよ。えー、スクラムちょっと思い出しながらお話をしていくと。

はい。

えー、スプリントプランニングの中で。

はいはい。

じゃあどのPBI選んでやりましょうかみたいなところを。

PBIってなんでしたっけ？

えー、プロダクトバックログアイテムという、まあチケットというか。チケットより少しまあ粒度が大きいんですけど。

はいはい。

まあやることっすね。

うんうんうん。

やることを選ばせたりとかAIに。

うん。

で、その選んだものをタスクに分解させるとか。

うん。

で、PBIはまだちょっと粒度が大きいので。

うん。

えー、POに、POは何やって、開発は何やって、QAは何やってみたいなタスクに分ける。

はい。

みたいな作業をまあAIにやらせるのって。

うん。

まあ良くないよねっていうふうにこの記事では語られてます。

良くないんだ。

良くないんですよ。

ほお。

で、良くないんだって思うと思うんすよ。

うんうん。占いより良さそうだけどな。

占い？あ、やらないより？

あ、占いより。

占い、占いよりっていうのは？

なんか昔チャットGPTに占いさせるとかめっちゃ流行ってたことあって。

そうなんだ。

それよりはなんか正しい使い方な気するけどなっていう。

うーん、ちょっとなんとも言えないんですけど、でもまあ占いのほうがマシまであります。

マジか。

はい。そうなんすよ。とか。

はいはい。

まああとはなんでしょうね。えー、まあバックログリファインメントと呼ばれる、まあふわっとしているやりたいことを、まあもうタスク化したりとか、エピックとかに分けるみたいな、まあそういう作業があるんですけど。

うん。

まあそのへんもそのふわっとしたものをエピックとかストーリーとか受け入れ基準とかをAIに作らせてみたいなのも良くないんすよ。

良くないんだ。

良くないんですよ。

それは丸投げが良くないとかじゃなくて？

うーん、良くない。

良くないんだ。

あんまり一部を任せるのも推奨していない。

そうなんだ。

はい、この記事の中ではですね。

酒とタバコと同じだ。

そうかな。うん。

まあスクラム的には酒とタバコいいかもしんないですけどね。

まあそうか。だからスクラムで言えば、AI使うならタバコ吸えってことね。

うん、そう。

なるほどね。はい。

っていうので、今の話をちょっと冒頭紹介させていただいたんですけど、今日の話を聞くと、最初に言ったこの、これはだめって言ってる理由とか、じゃあなんだったらいいのかみたいなところが、まあふわっとつかめるようになるかなというところでちょっとお話を進めさせていただきます。

はい。

で、えー、まあまあ早速なんですけど、じゃあ最初のスプリントプランニングのところからいきます。

はい。

で、プランニングって先ほど言ったように、例えばじゃあそのスプリント内でやるゴールの作成とか、あとはそのタスクの分解とかをさせるのはAI良くないというふうに、まあ最初言ったんですけど、それってなんで良くないかっていうと、えー、本当に達成したいことを達成する助けになっていないから。

ほんとに？

達成できないからか。本当に達成したいことを達成できないから。

本当に達成したいことを達成できないから。

はい。

できないんですか。

できそうじゃないですか、一見。で、ここを、あのー、まあ注意したほうがいいところで。

うん。

これはすごい、あの、よく陥りがちだと思うんですけど。

うん。

スプリントプランニングって、えー、実施するとスプリントバックログができるんですよ。

はい。

で、スプリントバックログっていうのは、このスプリントでやることリスト、まあチケットのリストみたいなやつ。

うん。

が、アウトプットとしてできます。で、2020年に更新されたスクラムガイドの中で言うと、アウトプットのほかにも、まあコミットメントというものが掲げられていて。

はい。

まあスプリントの中では、スプリントプランニングの中では、スプリントゴールという、このスプリントを通じて目指すものはこういうもの、目指しましょうみたいなもの。

うんうんうん。

を、まあみんなで頑張って作ろうぜっていうところを、まあ書いてるんですけど。これなんでそういうふうに書いてるかというと。

はい。

スクラムってそもそもなんのためにやるんだっけっていうところが、まあルーツとしてあります。

うん。

で、えーっと、スクラムってなんのためにあるかというと。えー、スクラム開発って、まあ元々、まあアジャイル開発を実現するための、まあ1つの、うーん、チームのあり方というか進め方としてあると思うんですけど。

はい。

アジャイル開発って結局ウォーターフォールと違って、作るものがまあ決まってない。

うん。

し、えー、何を作ればいいか分からないっていう状態で、なんか最もいい解にたどり着くために。

うん。

まあどう試行錯誤して、で、えー、そのチーム独自の、まあいいアイデアというか、いいものを作っていくかという、まあ手法なんですけど。

うんうん。

それをやるには、今まで誰も知らない、世の中の人誰も知らない知識を積み上げていく必要があるんですよ。

ほう。どういうことさ？

えっとー、なんか何もない、今までないものを作るには、誰も知らない知識をチームに蓄えていく必要があるんですよ。

はいはいはい。

まあいわゆる、なんて言うんでしょうね。まあ最初は暗黙値として蓄積されてって。

うん。

で、その暗黙値が、まあものによっては形式値になるかもしんないし。

うん。

暗黙値のままになるかもしれないし。っていうように、なんかチーム全員で学んでくみたいな。

えーっと、これはどういうことを言ってるんだ？えーっと、めっちゃシンプルに。

はい。

えー、今、タスク管理ツールがめちゃくちゃ盛り上がってるから、俺らもタスク管理ツールを作っていこうぜっていうチームがいたときに。

はい。

何が未知で何が既知なんだ？

はい。じゃ、既知なのは。

はい。

例えばじゃあ、こうこうこういう機能を持った、こういうUIで、こういう、なんかまあデザインの。

うん。

タスク管理ツールを作ろうだったら。

うん。

まあすべてが既知でウォーターフォール的にやれるんですけど。

うんうんうん。

ただ、じゃあそのタスク管理ツールを使うのが工場で、で、それで現場の作業員の人が作業しながら。

うんうん。

えー、なんか防護メガネみたいなやつかけて。

うん。

手袋をして操作をしなきゃいけないから。

なるほど。

みたいなそういうユースケースがあった場合に。

うん。

じゃあそのデザインって未知なんすよ。

なるほどね。

分かんないし。

はいはいはい。

で、そのデザインも結局じゃあ、えー、手袋で操作しやすいようにこういう形になってます。

うん。

ってなったとして、それがちゃんとなんか設計の決定文書として残ってるのか残ってないとかも、まあものによってありそうじゃないですか。

うんうんうん。

で、それがなんかまあ暗黙値だったり、えー、形式化された知識だったり。

うん。

ドキュメントとしては残ってるけど、開発チームが理解しきれてない、分かってないところ。

うん。

だったりみたいな、なんか知識っていろんな形で。

うんうんうん。

えー、結局チームに落とし込まれますと。

なるほど。

で、スクラムをするうえで1番重要なのって、そのプロダクトの、に対する、えー、あとはユーザーとかに対する、えー、知識なんですよ、チームが持つ。

うーん。

で、それって作りながらだんだん確立していくものなんですね。

うんうんうん。

で、さっきのスプリントゴールで言うと、スプリントとバックログアイテムはもちろんアウトプットとしては非常に重要なんですけど。

はい。

じゃあ今回のスプリントは、えー、何に向かっていくべきなのかっていうのをチーム内でちゃんと会話をしたうえで、1つの目線をそろ、にそろえて1つのゴールに向かっていくっていうことをしないといけないんですよ。

うん。

それがないと、スプリントバックログアイテムの中での優先順位が、まあそれで本当にいいのかみたいなところのコミュニケーションも取れないし、ブラッシュアップもされないし。

うんうんうん。

で、じゃあそのスプリントゴールをやったうえで、じゃあその次のスプリントどうかっていう、なんかそのチームのスプリントの連続性の中の、なんか方向性というか。なんかそのへんのディスカッションも進まないしっていうので、まあ適切にスクラムも動かないし、えー、チームとしてもまあいい方向に進化していくことが、まあできないとは言わないですけど。

うん。

進化していくための材料は得られないというか、得ることが、え、ん？手に入れきれない。

なるほど。

うん。っていう。まあなので、元々のスプリントバック、あ、違うわ。スプリントプランニングの話に戻ると。

うん。

スプリントバックログアイテムを作るのは、確かにAIにやってもらうと。

うん。

効率化できるんですけど。

うん。

ただそのAIにそこをやらせることによって、本当にしなければいけない、まあもちろんスプリントバックログアイテム作るのは大事なんですけど。

うん。

それ以外のチーム内でコミュニケーションを取って、で、チーム内の知識の確立とか、えー、知識をそろえるとか情報をそろえるっていう営み。

うんうん。

が減ってしまうので、開発チームとしての、まあ練度とか習熟度。

うん。

みたいなものを、まあ上げるっていう営みができなくなっていく。

なるほど。

よねって言ってるのが、この、えー、GenAI Born to Speed Up Your Scrum Eventsっていう。

はいはい。

記事の中なんですよ。

うーん。

で、例えばじゃあほかのイベントとかで、どういうことをやるべきじゃなくて、どういうことをやるべきだと言ってるかというと。

うんうん。

え、例えばさっきのプランニング。

うん。

プランニングは、まあさっき言ったように、PBIの選定とかはやらせないべきだけど、逆にできた計画に対して、えー、AIにレビューしてもらうっていうんですか。

うん。

この計画で回せますかみたいな。あ、いや、今週QA担当の人がカレンダー見ると、えー、半分ぐらい休んでるからQAのタスクこんなのらん、のらないっすよって。

おお。

言ってもらうみたいな。

うんうんうん。

なんかそういう、なんでしょうね、コミュニケーションのきっかけを作るもの。

うん。

とか、あとはまあ、なんだ、チェックさせる系っていうんですか。

うんうんうん。

予定とその週の、そのスプリントのストーリーポイント数を。

うん。

見比べて妥当性をコメントしてもらうみたいなことは、まあAIにやらせるといいよねっていうふうに言ってます。

なるほどね。

で、あとはまあデイリースクラムで言うと。

うん。

デイリースクラムは、あの、なんだ、今の状況とかを共有して、で、まあ課題があったらそれをまあすぐ解決できるようにするような営みですけど。

うん。

まあ今の進捗とか、えー、あとはそのタスクのステータスみたいなのをAIで要約させてSlackに送るっていうのはまあ良くないと。

うん。

これはコミュニケーションを減らすから。

確かに。

そうじゃなくて、えー、まあ議事録のたたきを作ってもらうとか。

うん。

あとはそのボードの更新の補助とかを、まあそのコミュニケーションが減らない範囲で。

うん。

まあやってもらうっていうのはいいよねって言ってたりとか。

うーん、なるほど。ってことは、えー、コミュニケーションとか思考はAIに任せずに。

うん。

作業を任せようっていう。

あ、そう。いいまとめですね。

うんうんうん。

そうなんですよ。で、まあこの記事、ちょっと元記事読んでいただけるともっと詳しく書いてるんですけど。

はい。

まあこういうことが書いてて。で、私はなるほどなと思ったわけですよ。

うんうん。

で、この考え方って、まあスクラムももちろんそうですし、ほかにもまあ転用できるなというか。

うん。

ってのはすごい思って。で、そこでなんか、ここの記事の中にあるエッセンスとなんか別の情報を紐づけて、なんか話できないかなってちょっと調べてる中で。

はい。

えー、1940年の論文にあたって。

えー、1940年？1000年？

ですか、はい。あ、すいません、1985年だ。う、めっちゃ嘘つきました。

あ。

全然違うわ。

だいぶ、だいぶ最近に行きましたね。

はい。で、さっきのそのスクラムの。

はい。

やりたいことって、まあ結局、まあものづくりなんですけど、最終的には。で、まあチームとしての知識を組み立てか、ていかなきゃいけないよねっていうところが。

うんうん。

まあスクラムの元だったりするんですけど。

うん。

えー、1985年の論文にProgramming as Theory Buildingっていう論文があって。

プログラミング as Theory Building？

はい。まあ理論を構築す、理論構築としてのプログラミング。

うん。

っていう論文があって。ここでもちょっとおもしろいなと思ったのが。

はい。

プログラミングって、まあもちろんもの、動くものを作るのはまあ目的なんですけど。

うん。

えー、プログラミングというのは、なんて言うんでしょうね、その、日々仕事してても思うことなんですけど、プログラムが死ぬときって、そのプログラム、作ったプログラムに対する知識というか。

うん。

まあ知識か。そのプログラムに対する知識を持ってる人がチームからいなくなったときなんですよね。

ほう。

なんて言うんでしょう。なんか人って入れ替わるじゃないですか、開発チームって。

うんうんうん。

で、ドキュメントにも残ってるじゃないですか。

はい。

でも、人が入れ替わると、なんか詳しいこと分かんなくなるじゃないですか。

うんうんうんうん。

で、そうすると、めっちゃめっちゃ複雑なソフトウェアだとおそらく、なんかここに手入れたときにどこにどう波及するかって。まあ今やAIあるからまだちょっとマシになったかもしんないですけど。

うん。

昔だとだいぶ厳しかったと思うんですよね、そこらへんの。

うん。

判断というか。

確かに。

で、なので、なんかこの論文の中ではプログラムの死はその理論を持つチームが解散したときに起きるっていうふうに書かれてるんですけど。

うんうんうん。

確かにそのプログラムを作る、書くことって、なんかその営みを通してチームでそのソフトウェアに対する知識を構築していくこと。

うん。

だなあっていうのはすごい思いましたし。

うん。

それを継続的にやれるようにするうえでは、それを俗人的にしないで、いかになんか全員で共有しながら仕事をしていくかみたいな。

うんうんうん。

ところがなんか非常に重要になってくなあというふうに思いますし。

ほう。

それを達成するために、まあそれだけじゃないのかもしんないですけど、それを達成するためのハウとしてスクラムが出てきた。

うん。

っていうところを考えると、最初のそのスプリントプランニングの、え、PBI分割にAIをやるべき、用いるべきではないっていうところにつながってくなあっていうふうに、なんか思ったんですね。

ほう。

ああ、そういうことか。

はい。

うんうんうん。で、ちょっとこの歴史の話もう少し続くんですけど。

はいはい。

で、えー、スクラムの父はなんかジェフ・サザーランドなのかもしんないんですけど。

うんうんうん。

スクラムの祖父っていうのがいるらしくて。

スクラムの祖父？ジェフの？

え、ジェフ・サザーランドのお父さんじゃなくて。

パパ・サザーランドじゃなくて。

パパ・サザーランドじゃなくて。

はい。

えー、野中さんっていう人。

野中さん？

はい。

野中さん。

日本人なんですけど。

急になんか盆栽職人みたいな感じ出てきたよ。

野中さんっていう人がなんかスクラムの祖父らしいんですけど。

はいはい。

石モデルって聞いたことあります？

え？

石、えっとSECI。

聞いたことある。

僕もうっすら聞いたことあるんですけど。

なんか名前だけ聞いたことあるぞ、それ。

これ何かっていうと、まあ知識の、だから暗黙値と形式値があって。

うん。

えー、例えばS、ソーシャライゼーション、まあ暗黙値から暗黙値を、えー、共有する。

うん。

これはなんか人同士のコミュニケーションで、暗黙値から暗黙値がどんどん共有されるよねっていうのがS。

うん。

で、Eが、え、エクスターナリゼーション。

うん。

えー、表出化。暗黙値が形式、形式値になる。

うん。

で、そうやってチームに共有されるみたいな。

はい。

で、Cがコンビネーション、まあ連結、形式値を形式値に変換して。

うん。

えー、情報が整理される。

うんうんうん。

で、Iが、えー、インターナリゼーション。形式、形式値が暗黙値になる。もうなんか書き残しておくほどでもなく、もうチームに浸透しきるみたいな。

ああ、常識になるみたいな。

あ、そうです、そうです。

うん。

みたいな感じで、この形式値と暗黙値を、まあなんでしょうね、そのー、変換する。

うん。

うん、これなんだ、フレームワークというか、まあモデル？

うんうんうん。

知識ってこういうふうに移り変わるよね的な。

はい。

石モデルっていうのがあるんですけど。

うん。

このAIに任せるべきか任せないべきかっていう判断軸、この石モデルでモデル化できんじゃねってちょっと思って。これは勝手に僕が思ってるだけなんですけど。

急に？

急に。

はい。

さっきのその、結局人間同士のコラボレーションをしてチームとして理論を構築していくべき、していくべきだよねみたいな話って。

うん。

ほぼ暗黙値だと思うんですよ。

うんうんうんうん。

で、まあ2種類あって、まあほぼ完全なる暗黙値と、あとはドキュメントになってるけど、なんか理解されてないドキュメントと理解されてるドキュメントがあると思ってて。

うんうんうん。

で、その理解してるドキュメントの領域を、まあどれだけ増やせるかっていうところと暗黙値を共有するが、多分チームで共有できてる知識になると思いますと。

うんうんうん。

で、なので、暗黙値はAI使うべきじゃないんですよ。

うん。

暗黙値の共有は。

うんうんうんうん。

暗黙値の共有は絶対にAIを使うんじゃなくて、人間同士のコミュニケーションをもってされるべき。

うん。

だから、まあ暗黙値を取り扱うような自動化は、AI自動化とか効率化はすべきではない。

うんうんうんうん。

で、一方で、えー、Eの表出化ですね。暗黙値を形式地化する。

うん。

暗黙値になってるものをドキュメントにするとか。こういうのはAI使っていくべきだと思うんですよ。

うん。

えー、以前のそのAI DLC V2の話でもちょっとしましたけど。

はい。

人間の知識はAIに上流ができる。

うんうん。

で、レビュー観点として、えー、今まではなんかレビュー観点として定義できてなかったけど、あなたはこういうコメントいっぱいしてますよねっていうのをAIが、えー、フィードバックしてきて。

うん。

ああ、じゃあそれはレビュー観点に組み込もうと言って形式地化する。

うんうんうんうん。

これは石モデルという、言うとEのその表出化なんですけど。

はい。

ここはAI積極的に使っていく必要がある。

うんうんうん。

で、次の、えー、石、えー、だからCか。Cは形式地から形式地。

うん。

ここもめっちゃAI使っていくべきだと思うんですよ。

確かに。

すでに形式地化されてるものを、まあAIが読みやすいように。

うん。

置き直すのかな、多分。元々、えー、ドキュメント管理ツールかなんかに入ってるやつを、まあ何かしらのプロンプトやらスキルに落とし込むみたいな。

うんうんうん。

作業になってくと思うんで。これもAIを積極的に使うべきですね。

うん。

形式地を形式地。で、最後の、えーっと、Iか。これは内面化、形式地が暗黙地になる。

うん。

これは、なんなんだろうな。

これなんか使う意味ねんじゃねって気もするけどね、なんか。

これはなんか消してったほうがいいってことですよね。もう暗黙地になるような、なんかもうすでに常識ですみたいな。

うん。

あ、でもどうなんだろうな。でもAIが理解できてない形式地であればプロンプトとして食わせるべきだとは思うので。

うん。

すいません。石モデルのIに関しては、まあ最小限にとどめとくべきだが残すべきですね。

うーん。

うん。なんか冗長なのは多分いらないと思うんで。

どうなんだろう。これ、人間だから暗黙地になるのであって。

うん。

AIの場合暗黙地にならないんじゃないか説？

あ、そうですね。

うん。

だから、まあAIにとっての暗黙地じゃないものは残しておくべきですね。

うんうんうん。

まあ、つまり、Sだけは絶対に使うながらですね。

うーん、暗黙地のものを。

で、その、暗黙地、暗黙地。

暗黙地、暗黙地。

だからAIで何かを自動化しようと思うときに、その作業によって暗黙地の、から暗黙地のそのコミュニケーションによる情報共有という機会が奪われてるかどうかっていうところを、非常に注意して使う必要があるんだなって。

うーん。

いうふうに思ってたんですね。

なるほどねー。

まあ、なので、えーっと、まあ最初はスクラムの話から入りましたけど。

うん。

スクラムだと、あの、AI DLCというか開発ライフサイクルとかの考えたときに、まあやっぱりここらへんポイントになってくるかなと思うので。

うんうんうん。

まあぜひ自分のチームで、ちょ、AI活用するときは、まあさっきの元記事、スクラムやってる方はさっきの元記事も読んでいただけると、あ、そもそも自分のチームにこれやると良さそうだなっていうヒント結構あると思うんで。

うーん。

ちょ、読んでいただいてほしい、読んでほしいなっていうのと。あとその話からはみ出たそのプログラミングを、ん？石モデルとかなんかそのへんの話は僕は勝手にガッチャンコしただけなんで。

うんうんうん。

そこは開地ゾーンなんですけど。

うん。

まあでもやっぱ暗黙地から暗黙地っていうところのコミュニケーションはやっぱチームとしては奪うべきではないし、それが奪われちゃうと、もうほんとに、えー、なんて言えばいいんだろうな。なんかAI以上の価値発揮ができないチームになっちゃうので、ほんとに。

うーん。

それは、あのー、ちょ、僕が大事にしてることわざの1つで、早くやるなら1人で行け、遠くに行くならみんなで行け。

うんうんうんうん。

が、すごい大事だと思ってて。で、チームとして動く価値ってやっぱチームで持ってる暗黙地にあるのかなと。個人的な思うので。

うん。

えー、強いチームを育てたい方は、てかまあ僕はちょっとそこを大事にしながらやってこうと思ったんすよっていうのが、まあ今日のお話になります。

なるほどねー。

うーん。いや、なんかこう作業を自動化するみたいな。

うん。

のはまあ、ばん、めっちゃ賛成でどんどんやってったほうがいいと思ってて。

うん。

で、そのコミュニケーションの部分を代替すべきじゃないっていうのもめっちゃ賛成なんですけど。

うん。

一方で、えー、コミュニケーションを代替するんじゃなくて品質上げるみたいな使い方できないのかなってのはちょっとふと思っていたというか。

うんうんうんうん。

それは大いにありだと思いますよ。

うん。

それこそ、えっと使い方は気をつけるべきだとは書いてたんですけど。

うん。

例えばだから録音した内容を。

うん。

議事録のたたきとして出すみたいなのは、なんかコミュニケーションの効率化になるかもしんないですし。

うんうんうん。

で、あと、もう1個出てておもしろいなと思ったのが、スプリントレビューかな。

うん。

で、まあステークホルダーに操作させますと、アプリケーション、デモで。

うん。

で、それを録画しといて。

うん。

その動画をAIに食わせて。

うん。

詰まったところを、なんか異臭とかにして。

うん。

チケット化して。

うん。

で、まああとの、のちのリファインメントとかでやるやらない、決めてやるみたいなところとかは。

うんうん。

なんかおもしろいなあと思って見てましたね。

うーん。

それも結局ね、ユーザーとのコミュニケーションというか、ステークホルダーとのコミュニケーションを、の質を上げるためのAI。

うん。

なのかなって思います。

あー。最近あのGeminiのさあ。

はい。

あのMeet使ってるときにGemini使えるじゃないですか。