AI駆動開発で増えた情報と認知負荷
こんにちは、AI駆動開発部の日常へようこそ。このポッドキャストは、日々AI駆動開発を行う企業家の山本とエンジニアの安倍が、AI駆動開発のリアルを緩く語り合う番組です。
はい、じゃあよろしくお願いします。
よろしくお願いします。
はい、じゃあ今回は安倍ちゃんが話したいことなんで、どんな話題を話したいでしょうか?
そうですね、AI駆動開発を僕らは知っていて、AIによってすごい開発の速度が上がったし、できることの幅も広がったなって感じてるんですけども、
一方で、やっぱり最近感じるのは、やることが多くなった結果、一個一個に集中できないなっていう気がしてきたりとか、
あとはAIからの質問に追われてしまって、回答に疲れるみたいなところであったり、
あとはプロジェクトの詳細までちゃんと自分が把握できてるのかなっていう不安感も抱えていたりする中で、
認知不細みたいな話題とかも、ずっとSNSとか見てると話題になっていたりするかなと思っていたときに、
僕もそうだし、ヤマちゃんとかもこの辺どう感じてるのかっていうところとか、
ヤマちゃんとかがどういう対策してるのかなっていうのがすごい気になってて、
今日ちょっと話してみたいなと思ってました。
なるほど。認知不細の話と、認知不可低減の話?
こんなイメージかなと思ってて。
はいはいはい。なるほど。
そもそも認知不可あったり、認知不細みたいなもの。
そもそも認知不細って何?みたいな話はあると思うんだけど、
ヤマちゃん自身感じてるのかなっていうところも、個人的にはすごい気になってるところ。
うんうんうん。
あー、なるほど。
なんか、あれかな。
PMとエンジニアで異なるAIの負荷
まず前提として、立場の違い。もともとの立場の違い。
2人とも今開発やってるみたいなところもあるけど、俺はちょっと違うところもやっててみたいなけど、
もともと僕自身はPMをやっていて、
阿部ちゃんはPMをやることもあったとは思うけど、エンジニアとしてやってたみたいな感じの、
立場の差みたいなのが、まず前提としてあるかなって思っていて、
僕の経験の話をすると、
例えばPMとして立つとき、
他の会社さんとかの結構大きめのプロジェクトとかも含めてですけど、
PMとして立ったときにオフショアだけチームとかもあったし、
日本人のチームであってもオンラインメインみたいなこともありましたと。
正直僕自身は、その頃からプロジェクト詳細まで把握できてる感覚はなかった。
それは怠ってたからとかじゃなくて、結局そのエンジニアとかがこうですって言っても、
例えば僕的にはちょっと違和感みたいなのがあったときに、
え、けどそれってこうだったら論理破綻してるからこうじゃないですかって言ったら、
ああ間違えてました、こうでしたみたいな。
そういうのが結構あったんですよね。
みたいなのがかなり僕の中では経験としてあって、
それはそのエンジニアが悪いとかじゃなくて、
大きいプロジェクトとかになるとそういうことも結構あると。
それを吸収するのがPMだと思ってたんですよ。
それを正直実態のコードベースを見るみたいなことはあんまりしないんで、
感というか、これそう言ってるけど前は言ってたから、
だとしたら論理破綻してるから、これって今言ってる発言はおかしそうであるみたいな、
引き出すというか、みたいなんでその感がそこそこたぶん鋭かったので、
事故が防げやすいみたいな感じで、
それが一つ他社さんからも評価されていた僕のPMスキルだったかなと思っていて、
正直けどそれは確かに緩和する多いかもしれないですけど、
僕自身も怖いんですよ。
だって実態を見ずに想像で物を言って、
エンジニアから来た実態はこうですっていうことすらも信じられないみたいな、
そんな状況で、しかも何か数万人とか何か数十万人とか使ってるような、
プロダクトとかでみたいなのをうまく安全に進めるみたいなのは、
かなりストレスがありましたと、みたいな中で言うと、
正直認知不細的な文脈で言うと、僕は認知不細が少なくなってるっていう感覚。
聞けばAIが教えてくれるし、何回しつこく聞いても教えてくれるし、
別に向こうはまたかよみたいな感じの態度もあるし、
別に深夜だろうが朝一だろうが、いつでも聞いてもすぐパッと帰ってくるというか、
すぐ調査が始まるし、なんか調査してると思ったら全然してなかったみたいなとかもあるし、
例えば調査してくれてると思って、2,3時間経って、あれまだなんかなって思って、
まだですかって言って、あ、忘れてましたみたいなとかもあるわけですよね。
みたいなのがあることを考えると、
そう考えると、正直認知不細はむしろ軽減されてる、認知不細の方はむしろ軽減されてると思ってます。
一方で認知不可の方も、目隠ししてる中でどこにあるか、物を探すかみたいな感覚だった方が、
ある程度教えてくれたりとか、フィードバックがある方が、
目をつぶって物を、例えば駅まで行く、最寄りの駅まで行くとかって結構しんどいじゃないですか。
そういうことか。
目を開けて、いろんな情報量あるけれども、自分で把握しながら進めれるっていう方が、
はっきりしてるっていうか、みたいなのがあると思ってて、
認知不可というよりはプラスの方が大きくて、
把握できることが嬉しいという感覚の方が、まず前提としてありますっていうのがあって、
なので正直認知不採、認知不可に関しては、
このAI駆動開発は、自分でAIにお願いして開発するにしても、
人に開発をしてお願いするにしてもっていうところを天秤にかけたときに、
僕はAIにお願いしてる方が、認知不採も認知不可も低く感じてるっていうのはまず前提としてちょっとあって。
なるほど。
今、認知不可のところで、自分の中でちょっと気づいたところが一個あって、
不可として捉えている状態が、何もわからない状態を不可として感じるものなのか、
情報量が多くなった結果、それを飲み込むのに読み解くのが大変とか、
そういう意味での処理量的な話での不可っていうのが、
二軸あるね。
この中的には多分後者なのね。
そうだよね。俺も感じてるのは、やっぱりAIのアウトプット量がぐっと増えたことによって、
それの読み解く量っていうのが増えたことに対する不可の感じ方をしていて、
ヤマちゃん的にはそっちにはあまり触れないっていうか、
ないんですよね。
そうなんだ。
これが、おそらくですけど、最近なんでないのかなみたいな、
なんでないのかを言語化できたというよりは、ちょっと違う。
素人のつもりでAIの方向性を見る
少なくても、僕と周りの人と、僕の周りの人とのAIの使い方のちょっと違いが一個あるなって思ってて、
それが、基本的にAIを使うってなった時に、
AIの可能性というよりは、自分の認知領域の中での正解みたいなのを目指す場合は、
これが自分の認知の中で合ってるのか合ってないのかっていうことを考えるわけです。
だから、それは大量の情報を浴びせられたら、そこから全部の正しいか誤りかっていうのを、
自分の認知している範囲内で当てはめていくから、結構負荷高いと思ってて。
で、僕は自分の認知によってAIの可能性を狭めたくないっていう前提がある。
なんで、毎回素人のつもりで、どんだけ自分が知っている、
例えばPMやってる中で、前めちゃめちゃ詳しくなったみたいな領域であれ、
全然もう全く素人のつもりで、ゼロベースで聞くんですよね。
だから、その問題に対して始めてから、ゼロから学び始めるみたいな感覚でやるんですよ。
それが仮に自分が知っている領域であれ。
で、そっちの方が負荷低いんじゃないかなって思ってる。
何だろう。
言われたことに対する整合性だけ、整合性というか、ああそうなんだみたいな、
それって違和感ないかなみたいなことだけを考えてる。
論理破綻がないかっていうことの方が重要だと思ってて、
自分の認知に答えはないっていう前提に立ってるから、
AIがいくつかの角度から言っていることの中で、論理破綻がなさそうである。
その時に一応自分の経験上おかしくないみたいなのは発生するけれども、
この情報が自分の認知の中で正しいのか否かみたいなのをやって、
毎回やると結構しんどいんじゃないかなっていう感覚。
なるほどね。
価値って、最近知り合いの料理人の人と話してて、価値って、
例えば自分の思ってる美味しいっていうのが10あったとしたら、
11、12、13っていう、もっと上がある可能性ってあるじゃないですか。
けどそれって意図して料理すると目指せないんですよね。
11、12、13はだって自分が認知してないんだからっていう。
だから自分がこういうのを作りたいって思った瞬間、
意図を持ち込んだ瞬間、自分の認知の中に固定化されるみたいなイメージ。
そうそう。それが多分プロフェッショナルになればなるほど、
制御能力が高くなっていくから、100目指そうって思ったら100に禁止すると思う。
逆に言うと101に行かない可能性がある。
だからある意味素人がわけもわからずやってたら、
例えばプロの目線からしたら105行ってる可能性もあるけど、
5の場合もあるみたいな。
だけどプロフェッショナルの人だと100から80みたいなの目指そうって思ったら、
そこに収まるような精度が高くなっちゃってるから、
あえて目指さないっていうのが結構必要になってくると思う。
それは味で言ってもそうですよね。だと思ってて、
意図して美味しい料理を作り始めると、想像を超える美味しさは作れない。
逆に言うと、意図してシステムもこういう仕組みって思った時に、
概念としてこういうのを成し遂げたいっていう概念だけから飛躍させていた方が、
なんかより自分の認知の鷹が外れたものを作れる可能性はあるっていう、
っていうのを結構常に意識していて、
そっちの方がむしろ認知負荷が低いのかもしれないっていうのが、
ちょっとなんか最近の。
もともと知らないから、なんか知ってるっていう選定で、
何て言うんでしょう、答え合わせをするのを大量でバーって浴びせられたら結構大変。
なんかそうだよね、システムをこういうのを作りたいって考えた時に、
おそらくデータベースはこれを使って、こういう構成でこうなんだろうな、
AIの言ってることってそれと合ってるかなみたいなのを、
割と確認しに行ったりすることが多いと思うんだけど。
で、だいたい外れてくるじゃん。
そうだね、うん。
でもそれ自体がさ、なんかそのシステムとして、
なんか動いていてお客さんとしてなんか違和感がなくて、
もちろんセキュリティ的な問題が起きなければOKとしている、
ある意味割り切りを持っているのか、
なんかそれとも、なんかそのAIが言ったことに対して、
素人目線で、まぁ素人目線ってかあくまで素人のつもりで
ふんふん鳴るほど違和感がないかなって理解した後に、
なんかそれが本当に技術的に正しいかどうかみたいな、
なんかフィルターを山ちゃんの中で一個通しているのかどうかでは、
なんか結構大きな違いがあるのかなと思って。
あ、けどなんか危なそうな感じだなみたいな時に、
阿部ちゃんに聞くとか、他のAIに聞くとか、
みたいな感じで、まぁ二重三重のフィルタリングを
僕の目では通していない。
なぜなら僕は別にエンジニアじゃないんで、
自分のことは信じていないっていう前提があって、
あとはこう要求があるから、その要求を満たしているかどうか、
だから要求が自分の認識とずれていないかどうかだけは、
しっかりウォッチして、でまぁセキュリティとか一番神様のところは、
阿部ちゃんにお願いしたりとかさ、聞いたりとかするわけじゃん。
ここヤバそうだなって思ったところがあったら聞くようにしてるっていう。
うんうんうん。
だからなんか、それだけというか。
あぁそうなんだ。いやなんか、そもそもなんか、
なんか認知コスト、認知不細に関しては、
僕もちょっとこの後話したいと思うんですけど、
なんか認知コストに関してはなんかそもそもの、
情報を精査するとなんか捉え方が違うっていうか、
そもそも精査という観点にないっていうのかなって思うと、
僕の感じているものとは全然違うんだなっていう。
精査っていうよりはだから方向性の、方向性の選択みたいな感覚。
はいはいはい。
で、なんかそれでいうと、今まで僕がPMとかやってきた、
とかそういう中でいうと、AIは相当ちゃんと答えを出してくれる。
うんうんうん。
で、ちょっと危なそうだなってやつは自分でさ、
例えばSQL叩いてみて、検証とかも、
その検証のSQLに出してもらってみたいなこともできることを考えると、
検証もなんか本当にヤバそうだなみたいな、
ヤバそうかヤバそうじゃないかの判断だけは自分の中でしてて、
みたいな感じなのかなって思いますね。
必要な時に理解する開発とガードレール
で、認知負荷、あともう一つはなんか認知負荷って、
理解負荷みたいなところもあるかなと思ってて、
理解しておかないといけないみたいな感じの、
理解する必要があるみたいなのは、
そこに関してはなんか僕はなんか、
その時々で理解するでいいじゃんみたいな割り切りが、
あるかもしれないって、
それはなんかその、
お客さんの手元で問題に浮上するまででも、
やっぱりさ、これってどうなのとかって聞くことはあって、
問題に浮上するっていうのはその本番リリースする前でも、
動作検証する中であれこれってみたいなところがやっぱあって、
で、なんかそのタイミングで理解すればいいっていう、
感覚が強くて、
だから、どこまでの深さがあるか何かわかんないけど、
それを理解しようとするみたいなことはしないっていう。
だから、なんか顕在化して理解する。
で、別に理解できないことはないっていう認識で、
なんか向き合ってるので、
なんかそれって言うと、なんか俺もなんか、
なんかそれってちょっと認知不細の文脈にも近いような気がしてて、
かつ僕も似たようなスタンスだなって。
なんかそもそも認知不細ってさ、
要はAIのコード生成量があまりにも多くて、
開発したエンジニアも理解してないし、
エンジニアがコードレビューお願いしますって言って、
PMなのかシニアエンジニアとかに依頼した時に、
シニアエンジニアとかも特に見ないで、
AIに聞いてそのフィードバックをコピペして渡してみたいな。
そういうラリーによって誰も何も知らないシステムができるよねみたいな。
ブラックボックス化されていくし、
問題がある時いきなり浮上するよねみたいな文脈とかで、
なんか認知不細って語られてるかなって思ってるんだけど、
なんかそうなった時に、
そもそもAIにコピペしてまるまる聞いた結果、
返ってきた結果を人に渡すっていうこと自体が、
単純に理解を諦めてるだけなのかなっていうふうに感じていて、
問題がありそうだなっていう時に、
その時々で理解するでいいじゃんって言ったことと一緒で、
必要な時に理解をしに行けばいいというところに考えると、
そもそも今よく聞く認知不細っていうのは、
本質的にはあまり起こることのないことなんじゃないかなっていうふうに、
感じていたっていうのがあって、
僕の中でどっちかというと大きい課題っていうのは、
理解しなければいけない時に、
その理解する、認知するそのコストが高いのを、
どうやって対処しなければいけないのかなっていうのが、
個人的な課題だったんです。
なるほど。
全部理解しないといけないっていう人は、
仮にそういう人がいたとして、
じゃあそれを全部理解したとして、
あなたは1年後覚えてるんですか全てをっていう感覚なんですよね。
1ヶ月後、2ヶ月後、いろんな案件とか開発とかこなしていって、
あなたは1ヶ月後、2ヶ月後、
自分の書いたコードを覚えてるんですかっていう話で、
みんな覚えてないと思うんですよ。
全部覚えてるみたいなんじゃなくて、
じゃない?って思って。
それって別に、必要になった時にまた読んで、
分かればいいだけの話というか。
最近、本当の意味でAI駆動開発してる、
プロジェクトと、
それは社内ツールだけで、
とはいえ結構安全めに、
AI駆動開発なんだけど安全めに進めてるよね、みたいなプロジェクト。
それは本番リリースして、実際にお客さん、ユーザーもいるっていう状態。
2パターンの開発を通してちょっと思ったのは、
本当の意味でガンガンとりあえずAIでイケイケどんどんやらせまくるのは、
なんか無理なんだなっていう。
そうなんだ。
だってめちゃ壊れたりもするじゃん。壊れたりもするし、
意味わかんないことになってる時もあるから、
なのでやっぱり人が面倒を見るっていうのは前提なんだなっていうのはちょっと思ってます。
だからある意味、
だからなんか、
始めが結構大事なのかなっていう気はしてる。
プロジェクトの01とかは本当に、
AI駆動開発をする上では、
個人的にはすごい重要だなって。
ルールを縛りまくるとか、
めちゃめちゃ厳しくして、
一番ストイックなやつプラスアルファで独自のルールまで定義してるみたいな、
ぐらいガッチガチに縛り上げて、
AIがどんだけどう行動がこうが、
そうしかならないみたいな状態を作るかっていうのは、
これが聞いてる人的には、
全然なんも見なくていいみたいな、
なると変な誤解を生むなと思ってて。
相当ガードレール引いた上での話だもんね。
ガードレール引けてて、
その上で、
全部把握しておく必要あるんですか?みたいなところ。
ただ、こことここは関連性があるとか、
そういうのは自分の頭では覚えてたりするけど、
別に確実に覚えてるわけでもないし、
一応ドキュメントに書いてはいるけど、
そのドキュメントって、
ちゃんと活用されてたんでしたっけって、
人間社会においてみたいな。
やっぱドキュメントなかなか陳腐化して難しいよねっていうのは、
多分いろんな会社であったことだと思うんで、
その時代から比べると、
AIでやってるのも全然いいでしょっていう。
で、その瞬間的な認知不細よね。
不細っていうか認知不可やんね。
だからその必要になった時に理解しないといけないみたいなのは、
別に、
それで言うとさっき言った通りで、
間違えてましたみたいなのを、
人間から言われるようなヒントより、
圧倒的にAIの方が精度が高い。
正直、向こうのエンジニアとかもプロなんで、
こっちで違和感を感じた時に、
それってちょっとみたいなのを言うのも、
言うのすらストレスなんですよ、正直。
言わせるんだって話すなって。
正直。
けど言うのが仕事だから言うわけですよね。
間違えてましたっていう時もあれば、
やっぱそこだったじゃないですかみたいな時。
あれば、
それはそれで心理ストレスがかかるわけですよね。
なので、その摩擦がないっていうだけで、
僕は万々歳って感じですね。
もともとが負荷が高すぎたのかもしれないね。
心理的な意味でも、
単純に脳のパンクみたいな話ではなくて、
心持ち的の負荷の方が、
よりしんどく感じてたかもしれないよね。
対人間とっていう意味では。
そういう意味では、
負荷は軽くなる方向にしか傾いてないというか、
情報がどんだけ来るのは別に嬉しいことで、
それは精査すればいいだけの話なんで。
精査っていうのが、
いらない情報は切り捨てるっていうだけで、
見るべき情報を選べばいい。
手札が今まで2枚ぐらいしかもらえてなかったのが、
20枚ぐらいくれるようになって嬉しいみたいな感覚。
判断依頼をまとめて処理する仕組み
僕の中で最近やってる認知コスト下げる方法みたいなところっていうと、
そもそも僕の中では認知コストっていうのは、
いかに大量に発生する判断とか情報を
頭の中にインプットして、
イエス・ノーみたいな判断をしていくのかみたいな、
個人的な課題だったんですよ。
それがそもそも山ちゃんとは違ったんだなっていうのは
一個ありつつも。
ただ、そうなった時に、
とにかく結局、
以前は疑問に思ったことをソースボード見に行ったり、
ドキュメント探しに行ったりして、
自分で確認するみたいな作業をしてたんですよ。
だから自分で手を動かして、
理解を深めようみたいな試みを常にやってたので、
でもそれって結構時間当然かかるじゃないですか、手を動かすので。
それを一度諦めて、
例えばAIにとにかく聞きまくるというか、
これってどうなんですかとか、
気になったところを聞くとか、
あとはAIに判断してほしいことリストを
一週とかに大量に作ってもらうみたいなことをやってて、
一週を一個一個、
見たら何を判断すればいいかっていうのを
分かるようにしてあげることで、
分かるような形で一週を作るっていう、
まずテンプレートを事前に作っておいて、
読めば、これはイエスだね、これはノーだね、
あとは判断していけば、勝手にAIが取り込んで
どんどん進めていくみたいな仕組みを作ることで、
そもそも起きてたのって、
AIがいっぱいこういう判断してほしいっていうことを言うから、
答えようとしてるんですけど、
そのうちに考えなきゃいけないことが
どんどん漏れてくるみたいな、
取りこぼしみたいなのがよく起きてたりしてたんですけど、
それ自体は一週にいっぱいあげて、
溜め込むようにしてから、
もともとはローカルのマークダウンファイルとかに
入れてもらってたりしてたんですけど、
マークダウンのファイル読むのも結構めんどくさいし、
っていうのもあって、
一週にあげたりするようになってから、
取りこぼしが減ったっていうところと、
とりあえずなんとなく開いて、
気になった時に見に行けば、
そこで判断ができるっていう状態になったので、
なんかそういう、
AIにそういう、
自分が情報を探しに行くのじゃなくて、
とにかくまとめさせて、
なんか置いといてもらうっていうのを
一個やるだけで、
結構なんか楽になったなーって感じが
しているんですよね。
なんかそれで言うと、
今の話聞いたら、
しんどそうだなって。
まあそうだと思う。
でもなんか、やっぱりね、
これはあれだよね、
なんか、
これこそ認知不細に
陥ってるのかもしれないけど、
なんか新しいプロジェクトとかで、
正直僕が、
ミーティングに出てなかったりした時とかに、
何が決定されて、
どういう判断があるかっていうのを、
ちゃんと議事録も読んでる時間がなくて、
なんか分かんないけど、
とりあえず議事録から、
理解できる、
進めるべきタスクを進めておいて、
判断しなきゃいけないことは、
一周に挙げといてみたいなので、
やっていて、
なんか、
そうすることで、
いちいち全部議事録を追ったりとか、
時系列を探すんじゃなくて、
どういう話し合いがあって、
どういう問題に対して、
対処しなければいけないのかっていうのが、
もうそこにパッと、
1トピックずつに集約されるから、
他の作業をしながら、
ちょっと空いた時にパッと見に行って判断して、
自然とちょっとずつ消化されて、
あんまりそこに対して、
負担を感じなくなっていて、
個人的には結構楽になったなっていう、
感じがしてるんですよね。
うーん、なるほど。
そう。
せーの。
できないな、俺。
多分難しいかもしれないよね。
なんか、
連絡とかもそうなんですけど、
メールとかもそうなんですけど、
溜めるとやらなくなるんですよ。
だからメールを返すの遅い人はある。
僕もちょっと遅い時は遅いんですけど、
例えば僕が遅くなる時あるあるが、
メールを認知した時に、
その場で返さなかったものが、
やっぱ遅くなるんですよね。
うんうん。
でもなんか、
ゼロスタートで何も分からないことを、
例えばだけで他のプロジェクトに、
全く知らない状態で参画して、
いろんなクライアントからの要望が来て、
いろいろ判断しないといけないから。
結局、最終的に判断したりとか、
方針決めたりするのは自分だった時とかに、
逆にヤマチャンはどうキャッチアップして、
一個一個の問題に対処していくのかなっていうのは、
すごい気になっている。
30個の判断を絞り初期成果物を急ぐ
判断ね。
判断で言うと、
僕は時間かけても判断は成熟しないと思っている派なんですよね。
まず前提として。
だから、今パッと判断できたら、
判断できないっていう状態ってことは、
すでに情報が足りてないだけであるという感じなんで、
なんで次のアクションは、
今判断できなかったってことは、
次のアクションはAIに追加で分からないことを質問するんですよ。
だから、
あれなんだよね。
AIじゃなくても人にでもやけど、
なんかのアクションが常にぐるぐる動いてるっていうのが、
基本動作っていう感じで、
自分がその流れを止めちゃった時点で、
僕はその流れにいなくなっちゃうので、
例えばメールだったら返信がめっちゃ遅くなっちゃうとか、
なんかそういうことになる。
多分それは1個の判断とかかなというふうに思ってて、
僕の中の課題っていうのは、
今判断しなきゃいけないことが10個とか20個ボンってできた時に、
どうしようかなっていうのは結構あって。
それはその場でやっていくみたいな感じなのかなって。
例えば判断を30秒とか1分でできる判断があった時に、
例えばその判断を30個ぐらいやってくださいって言われたら、
30秒かける30個だったら、
15分分になるわけじゃないですか。
ずっと集中してパッパッパ判断するのにも15分かかる。
だからそれの時間がちょっとどうしても取れないなっていう時に、
流れていってしまうリスクも結構あるかな。
それはメールの打ち返しできなかったっていう話にも。
いるような気がしていて。
だから僕は無理やりにでもやるようにしてて、
だからミーティングの時でも、
自分が話す時でさえ何かしてる部分は、
もう無理やりにでも今やらないと後回しになるっていうのが分かってるんで、
もう無理やりって感じになるね。
だから置いとくことをできるだけしない努力をするみたいな感じで。
だからこれからミーティングしないといけないみたいになった時でも、
別に喋りながらでも決まってることを喋るんだったらできると思ってて。
とか例えば自分が喋り終わった後に相手が喋ってる間にはできるわけじゃん。
みたいな感じで。
できるだけ今できるタイミングを前倒しにするみたいな。
あとあれだね、それはもしかしたら判断のコスト。
要はヤマちゃんがさっき言っていた素人のつもりで聞いて、
AIからの判断の依頼についても、
違和感があるかどうかみたいなレベルの状態で回答するからこそ、
俊敏に回答できるっていうのもあるのかなと思って。
判断が30個とかあった中で、
たまにこれそもそも何を前提にどういう質問をしていて、
何を判断すればいいんだろうみたいな。
例えばAI駆動開発でいうと、
例えば30個の判断軸があったとしたら、
15個ぐらいには削ろうという努力をしてるかもね。
それはあんまり重要そうではないけど、
考えないといけないみたいなのがあったときに、
あんまり重要そうがないものであれば、
後でアウトプット見て、やっぱ違ったんだったら、
違うって言ったらいいだけって思っていて、
だから推奨方針でやってくださいって言っておくだけみたいなのを、
30分の15ぐらいは多分やっちゃうように常に考えてて、
それはなぜかというと、
やっぱりアウトプット見て、
どんだけ30個これが完璧だって回答しても、
AIはちゃんとした成果物を上げてくれないわけですよ。
そう考えると、30分の15でも30分の30でも、
どっちでも自分が思う完璧なアウトプットは出してくれないんですよね。
だったらアウトプットが、
例えばそれが30分の30を頑張って答えようとしましたってなるだけで、
AIがアウトプット出すのが、
例えば夜とかその翌日とかの落ち着いたときに
判断して返さないといけないってなったら、
それだけで12時間とか24時間とか36時間とか、
そのAIが先に出してくるアウトプットの時間は遅れるわけですよね。
なぜなら、ある回答、質問に全部回答してたら、
あとはAIが勝手に作業してくれるんだからっていうのが前提としてあって、
だから今この時間で、
もしかしたら時間がめっちゃないってなったら、
30分の10とかにするかもしれない。
とりあえず先にアウトプットが来るみたいなのを意識してるかもしれない。
結局AIの待ち時間が長いっていう前提に立って、
しかも全部完璧な回答をしたとしても、
完璧な解が得られないっていう前提に立ったときに、
しかも物があった方がAIには伝えやすい、
AIは理解してくれやすい、何かを走るに、
これこうだからこうって言った方が、
ゼロベースよりAIの作業品質が高いっていうことを考えると、
やっぱりいかに早くAIに初期のアウトプットを出してもらうかっていうことが、
重要だと思っていて、
そこへの意識がすごく強いかもしれない。
なるほどね。
削っちゃうというか、
自分の3でもいい究極みたいな。
優先度色分けして高いものだけ、
3答えたら、
その3から導出できるような、
関連するようなものもあるよねみたいな。
あるから、だから3でいいみたいな。
とりあえず今3しか答えられへんから、
この3だけ答えるみたいなことをしてるかな。
なるほどね。
他勢も推奨でいいよみたいな。
僕も一応その心が気がしてるけど、
どうしても手綱を離しきれてないなって感覚はまだあるな。
手綱を離してる感覚じゃないか。
そうかもね。
これは手綱っていう言い方が悪かったかもしれないけど。
ピッピングポイントが違うみたいな感覚なのかな。
セーブポイントの置き場所が、
阿部ちゃんは多分質問から回答するタイミングじゃん。
だけど僕は、
最初の成果物を出てきて確認して、
再依頼を出したタイミングみたいな感覚だから、
重要じゃないポイントではあるっていう感じなのかな。
あれかもな。
そうだね。
多分出てきた時に、
全然思ってたのと違うなってなったところからの
修正が結構しんどいなって思ってしまってるがゆえに、
思ってより自分が目をかけてしまうんだと。
自分が思ってるよりも、
これ怖いなみたいな思って、
途中でAIの動きを見に行ったりとか。
けど、30分の3答えたとするじゃん。
さっき言った通り、
正さじゃなくて、
方向性を示すっていう。
方向性を示すための一文だけ、
推奨方針で進めてください。
一応こういう背景があるんで、
こういう方向性の方だといいと思ってますみたいな。
ちょっとAIの思考がこっちに重み付くなみたいな感じのだけ
与えてるときはあるかもしれないね。
確かに。
単純にABCのタグを与えられたときに、
Aっていうふうに答えるだけじゃなくて、
なんでその回答をしてるかっていう背景情報を与えると、
よりアジャストされやすいなみたいな。
結構だから3択で出すじゃん、よくAIって。
3択で押してさらにこういうのも背景になります。
よく追加メッセージを書くね、俺。
はいはいはい。
そうだね、確かに。
僕もそれは結構意識してるかも。
やっぱり怖いんですよね、僕の中では。
AIが思ってたのと違う方向に進められるのが。
だからそういう意味でも結構、
多分僕は3択選びながら、
こうしてはいいみたいな意図もちゃんと伝えるし、
っていうのを例えば30個あったときに、
半分ぐらいは書くことができる。
一応半分ぐらいにはできるようにはしてるけど、
とはいえ15個じゃあ考えるんですかって言われて、
じゃあちょっと考えてみるかっていうのをやってみるとか。
あとはそこのコストを下げるために、
さっき言った一周に取りにかけ上げてもらって、
相まぬってできるとか、
あとはたまってきたりするから結局それも。
もうなんならHTMLに書き出してもらって、
チェックしとけば、
とにかく捌けるような仕組みだけ、
その場で作ってもらって、
さっさと捌くみたいな、
そっち側の努力をしてましたね。
なんかあれかも、
ちょっと思ったのが、
もったいないと思う、
残念だと思うポイントが、
僕と阿部ちゃんで違うんだなってちょっと思って、
僕的にはめっちゃ一生懸命頑張って回答したのに、
回答したのにもかかわらず、
思ったようなアウトプットが得られなかったことの方が、
もったいない。
阿部ちゃんは、ちゃんと答えなくて、
ちゃんとアウトプットが出なかった時に、
もったいないって感じてるんだなって思って、
だから、
どうせ、
どうせアウトプットが自分の求めるものには、
完全にはならないっていう前提に立った時に、
答えすぎるのがもうすでに、
僕は僕の時間を使うのがもったいないと思っちゃってる、
みたいなところなのかな。
阿部ちゃんは逆に言うと多分、
AIが稼働した時間分まで含めてもったいないって感じちゃってるのかな。
それはあるかもね。
トークンの、
これはヤマちゃんが意識してないって話は全然ないけど、
僕も僕なりのトークン効率みたいなもの。
1ミリオントークン入ったんだったら、
こんぐらいのタスクしてほしいなみたいな希望感はあったりするから、
かつレートリミットとの戦いがあるからこそ、
ちょっと気にしてしまったがゆえに、
細かめに指示出したりとか。
あとは、
その判断しなきゃいけないかなみたいな温度感が、
どこまでAIに任せられているかみたいなのはちょっとあるかもしれない。
例えば議事録をもとに、
こういう議論があったけど、
本当にこれでいいですかみたいな話を聞かれるわけじゃないですか。
僕も正直その会議に出てないし、
分かんないなってなった時に、
今のプロジェクトのページ開いて、
合理性の高そうな選択肢ってなんだろうなって考えちゃうんですよね。
僕はそれで12時間、24時間止まっちゃうことのほうがもったいないって感じじゃんかな。
言うてね。
例えばレートリミットが終時でとか、
5時間OKでとか、
それで2日を放置しちゃってましたってなったら、
もう7日中2日はもう、
5時間の枠は使えたかもしれない枠みたいなのは使えなかったし、
使い切り続けることが正義になってるかも俺の中では。
それは無駄なことはしないっていう先手はあるけど、
無駄なことではないと思ってるっていうのもあるし、
しかも何か、
多少の強弱はあれ、
やっぱり何か、
所詮何か完全なものは出てこない。
最近出るようになったけどね。
そっちの間隔の違いの方が大きいのかもしれないしね。
それこそ最近はオーパス5.5とかソネット5.5が出たことによって、
よりお任せできるような感覚も。
以前はフェイブルとかに任せてればいいかって感じだったのが、
実行レイヤーも含めてお任せできるようになっている。
実行者にも判断を委ねられるような感覚。
今までフェイブルは計画者としてある程度判断を委ねられる。
実行しているところはフェイブルの判断のところだったけど、
何か問題があったらフェイブルがエスカレーションしてきて聞いてくるみたいなところだったけど、
それがオーパスとかソネットが出たことによって、
問題があっても彼らにも問題解決して進んでもらえそうな感覚があるから、
前よりはちょっと手放しできるかなって。
結局、モデルの優秀さと、
今自分が理解しないといけないと思っている量と、
抱えているこのプロジェクトの量のバランスが、
どうチキンレースするかみたいなのが自分の中にある。
そういう意味では以前よりやりやすくなったような気がする。
それでも今話していたように、
どうしても何か判断しなかったことによる、
AIが無駄に動いてしまったことが、
リスクではないか、もったいなかったなあみたいな感じが
出てしまうのがありますよね。
だから価値観の話じゃんね。テクニカルな話じゃないよね。
アベちゃんはAIを無駄に使っちゃった時間と、
それができたはずの時間にできなかった時間。
どっちのロスが重要と考えているかというと、
理性的に考えたらもしかしたら後者の方が
って思っているかもしれないけど、
真相心理的にはAIを無駄に使っちゃった時間の方を
もったいない差を重要に感じちゃってるみたいな。
でもこれはあれかもしれない。
非実がぴったり決まってたりするタスクとかだと、
その時間までにギリギリになってしまうと、
クライアント向けの説明とかも、
自分の理解を伴ってない状態で説明することになるので、
かなり危ういなと思ってて、
それなりに出てきたアウトプットに対して
理解して説明しなければいけないってなった時に、
初手のアウトプットがあまりにも漁ってない方向、
あまりにもっていうのはないけど、
あさっても標高いかない程度の言葉は授けるよね。
でも一画面の中にやらなきゃいけない仕様っていうのが
いろいろ凝縮されていたりすると、
一個一個違うのを直している時間はもうない、
みたいなことになり得ることが多くて、
それが僕の中では、
とにかく早く回答するみたいな所作をした方が、
最終的にファーストアウトプットが早くなります。
で、その修正します。
で、修正する中で僕はそのプロダクトの中の
詳細情報の理解を得れます。
だから結構、多分今作っているサービス、
俺中の仕様詳しいと思うよね、阿部ちゃんのは。
それは多分そこの中での、
だから必要に責められる状況になるから、
ファーストアウトプットが出て、変な、変ではないけど、
ある程度方向づきはしているけど、
それでも思うことがあったみたいな。
で、その中で理解を深めながら修正していくみたいなのが、
トータル一番早いみたいな感覚。
感覚なのかな。
全く全てを判断するようにしているわけではないから、
僕の中でも結構ちょっとずつ判断の量っていうのは
下がっていってる感覚があって、
それが俺の中で多分今の山ちゃんが言ってた、
とりあえず早く判断して、
早く判断というか、とにかく早く着手してもらって、
アウトプット出してもらって、
そこを調整するっていうところの成功体験の量が、
たぶん徐々に、
僕もそれによる成功体験は感じる瞬間もあるし、
失敗したなみたいな時もあるし、
ちょっとずつ判断の量は減らしつつも、
安全に着地するような感じで、
調整はされてってるなみたいな感覚はあるんだよね。
けどまだまだ、
30個あるものを、
3には絞り込めてないなみたいな。
もうちょっと成功体験を生んでいく、
経験を積んでいく必要が逆にあるの。
AI駆動開発としての経験を。
AIの失敗をスキルに蓄積する
けどあとあれかな?
あと俺結構多分スキルを頻繁にさ、
スキルちょっとアップデートしておいたみたいな、
出ると思うやけど、
そこで絶対に全てに補えるみたいなのは、
今後判断しなくていいよ。
なんかそっちの投資に時間かけてるかもしれないね。
アオイちゃんもやってくれてるけど、
なんか多分そうだね。
そこが、
そっちでレバレッジかけたい感覚が、
強いのかもしれない。
だからミスることはむしろ嬉しいというか、
っていうのもあるかもしれない。
ミスってくれたら、
AIがどういう風に振る舞いやすいのかっていうのが見えてきて、
それをスキル図で抑え込めれるから、
それをなんか自分がコンセス丁寧に言っちゃうと、
自分の思った通りにしかならないけど、
けど、
素でナチュラルに進んだとき、
こう傾くんだ、
じゃあこれをスキルでこっちでガードレール抑えとこう、
みたいな。
そうだね、だから、
なんか速さだけじゃなくてのメリットを感じてるんだな、
今思ったけど。
成功体験っていう話でちょっとピンときたけど。
むしろ失敗させることによって、
その失敗をルール化して、
縛りを、
縛りというか、
AIがミスを少なくするガードレールを
強固にしていくみたいな感覚。
そうすると、自分のその今のその、
何だろう、
質問される量も減っていくし、
みたいな感じになる。
なるほどね。
だから、そうだな、そっちもあるな、
今思ったけど。
スキル化、そうだな、
だからよく、
そのセッション見てもらって、
いや、これこんなミスしてるんだけど、
これって、
AIいつもこんな感じになるから、
みたいなスキルの作り方してるね。
作りの、
作るっていうことはしてないけど、
ブラッシュアップの近いけど、
新規で作ることは少ないけど。
確かに。
まあ、それはけど、
なかなかあれかもしれないね。
その、
01の自宅開発とかではしづらいやり方、
なのかもしれない。
どっちかっていうとね、
汎用的なルールに落とし込むっていうよりかは、
その業務における、
例えば法律的なルールって、
こういうものがありますよって、
知識をとにかくインプットしていく作業になってきてもいるから、
僕の中では。
それは、
もちろんスキルもそうだし、
ドキュメント、
必ず読むドキュメントに、
ひたすら、
判断のミスは蓄積するようにしているかな。
うん。
スキルであっても変わらない。
同じっちゃ同じかなと。
AIのミスっていうのが、
普遍的な、
行動の話なのか、
業務的なルールの話なのか。
で、
各場所はちょっと変わってるっていうのは、
あるけど、
たぶんやってることは似てるのかな。
これが、
大規模に何人もチームがいるとかになると、
たぶんやりにくくなってきたりするのかとは、
ちょっと思うけどね。
特にスキルとか、
頻繁にアップデートするっていうのが、
もしかしたら、
チームで、
チームの方針にそぐわないとかっていうのは、
あるのかもしれないし。
小人数でやってる限りは、
どんどんアップデートした方が。
まあけど、大人数の方が嬉しいんじゃない?
合意とかは、
難しいけど、
レバレッジが効くという意味では、
まあそうだね。
レバレッジの意味では、
10人でやってるチームだったら、
そのスキルを使ってる方がいいから、
1人スキル専属の人が行っていいぐらいだと思う。
っていうぐらい、
結構重要。
10人が10のAIを使うんだったらね、
100になるわけだしね。
そうそうそうそう。
それがしかもスキルによって、
1.5倍の効率が出るんだったら、
150になるわけだから、
レバレッジの効き方が異常だから、
まあ、
そうだね。
まあそう考えると、結構なんか、
面白いね。
大人数のチームじゃ確かに、
動かしづらそうだけど、
大人数のチームの方が、
スキルのレバレッジが効きやすいと。
そうだね。
まあ、
話したいことは、
話せましたか?
話せましたか?
まあどうだろうね。
この辺はもう、僕の中で、
心の持ち方とか、
向き合い方とチキンレースの話かな、
っていう感覚が、
山ちゃんがどういう風に
向き合っているのかなっていうのを聞けたので、
まあ、すごく満足しましたよ。
まあ、なんかHTMLでさ、
うまくこう、
視覚的に分かりやすくみたいなとか、
うんうんうん。
まあ、やったりとするけど、
Claude Designで顧客と目線を合わせる
ああ、けど最近はあれだな、
なんか、
最近はアーティファクト作ってもらうこと
多いかもしれないですね、僕は。
ああ、そうですよね。
僕も、
クッドで目線合わせするみたいな、
うんうん。
まあ、割と僕もそういう風に
なってきてはいますね。
なんか文章でドバッと説明されても
困ったりもするので。
なんか、クロードデザインにやると
一気にノリつながるね。
クロードデザインをやるだけで、
うんうんうん。
最近やったさ、UIの大規模な
大規模な、まあ結構
小賢しいUIのゴニョゴニョを
小賢しい。
小賢しいUIのゴニョゴニョを
いっぱいやってたと思うやけど、
オーケストレーションを奪われたのね。
その、
あれは多分
そのワンショットで
AIにやらせて、
そっからこう、どう
後から追加指示を出しても
導き出せない
UIの
うーん。
なんか、もう絶対になんか
クロードデザインで作ってからやらないと出ない
アウトプットの。
そうだね、あとはまあ
あれだな、これは
だからだけど
やっぱなんかさ
受託とかやってると
お客さんが理想とする
UIと
なんかAIに
なんかこういうのを実現したいって言って
AIがすごいUI出してきたとしても
なんかやっぱり
いやこれだとちょっと今までの業務と
画面が違いすぎるから
こう、あんまり分かりやすいように
感じないんだよねみたいな。
既存のシステムの画面とのギャップが激しくなるから
分かりにくいんだよねみたいな。
こうアジャストするための
指示出しっていうのが結構大変だなと思って
クロードデザインとかに
こういうのやりたい
こういう風なものを実現したいって言うと
めちゃくちゃこう
いいものを作ってくれるような感覚があって
それを一個一個
言語化して伝えるのも
結構まあ大変だなみたいな感覚がある
っていうのも
なんかまあこれは認知コストとはちょっと違うけど
なんか別のなんか
指示コスト的な
課題はあるなって感じるね。
それで言うと俺
そのアベちゃんが
お客さんとミーティングしてる時に
デザインの話して
横でちょっと聞いてたりするけど
なんとなく思うのは
これはなんかPM仕草の
テクニックの話だと思うんですけど
うん
なんか時間短いなって思うかもしれない
もう今日は
画面とかもうなんか
とりあえず叩きつくったんですけど
もう時間かけてどう思うか
どうあって欲しいかを
それこそ3パターンぐらい
作ってもいいと思う
グローデザインあるから
というので
どっちの方がいいのか
どっちの方がいいのかみたいなのを
僕最近ほらデザイン固めた
業務システムではないけど
もうなんかとりあえず
こうバーって言ってもらって
なんかその中で
グローデザインであらかじめ作ったやつは
全然お客さん的にはよくなかったんだけど
じゃあこっちですかねとか
そうするとお客さんがさ
こういうシステム他で使ってて
こういうシステムっぽいのがいいんだよね
みたいなベンチマークっぽいものを
なんか出してくれたりする
うんうんうんうん
だからなんかそこの議論みたいなのに
結構初手の段階で
いかに時間を使って
それを録画しておいて
いかにAIに言語化してもらうかみたいなので
ああ
最近のやったホームページのやつとかは
うんうんうん
それでまとまったよね
逆に言うとその時間なかったらまとまらなかったな
みたいな感覚があって
そこの時間とかはあるのかもしれないしね
だからなんか会話
会話か
一応なんかねどうなんだろうね
そうかな
一応なんか横で見てて感じる
ちょっとなんかその
持ち帰って考えますねみたいな感じの
ああ多いね
けど持ち帰っても分かんないから
今その状況で
うんうんうん
だから時間をかけてやっぱ話しか分かんないっていう
なんかその想像はできないっていう
お客さんの立場をっていう
まあ想像できたらよりいいんだけど
まあ議事録撮ってるし
それをAIが理解できる現状にあるんだったら
なおのことあるよね
多分言語化してもらうっていうのが
そうそうそうそう
顧客の本音を引き出すヒアリング
だからひたすらヒアリングして
言語化してもらうみたいな
何がいいのかみたいなのを
っていうのに時間を割くみたいなのを
一気にクオリティ上がるイメージがあるかもしれない
なるほど
まあでも確かに
言われてみるともう
結構その今の打ち合わせって
もちろん
時間の中に今までは収めるっていうのが
重要だったり
要点をまとめて
綺麗に報告するのも大事かなと思ったけど
お客さんのやりたいことを
いかにお客さんの言葉で
話させるかっていうのを
結構大事だなっていう
なんかこれはもしかしたら
AI時代にも関わらない話かもしれないけど
それがもう本当に
一時インプットに
AIに対してなるから
そこで情報を集めきったら勝ちみたいな
いいいい
そういうのは少しずつ
ありそうだなって思ってたけど
なんかいいPMあるあるやと思うけど
いいPM
この人いいPMだなって僕は思う
あるあるは
例えば10人とかいっぱいの人が
参加している会議が
あったとして
その時に空気を読んで
サクッと終わらせずに
ちゃんと向き合って
周り巻き込んでても
なんかちょっと泥臭くても
聞き切るみたいなことを
する人
が結構
空気読むっていうと
あれかもしれないけど
ちょっと遠慮しないように
遠慮せずにね
そうだよね
っていうところが最終的に
いいアウトプットに
繋がるし
それが無理なんだったら
別でちょっと2人だけ
時間取らせてもらえませんか
みたいな感じとかもあるかもしれないし
っていうのは
結構あるかもしれないな
確かに
あとあれだよね
多分そこのいっぱい
根掘り葉掘りっていうところの
多分期待値調整とか
なんかできるかわかんないけど
もっとより良い高校を目指していきたいとか
理想を描きたいからこそ
こうやっていっぱい時間
使うんですよみたいな
目線合わせをした上で
お客さんにもいっぱい色々
話してた
けどね
僕の感覚的には
それをやられて嫌な気持ちになる
お客さんはいないと思ってて
お金を払ってるから
お客さん心理でいうと
多くの時間を使ってもらったら
お得なわけじゃないですか
そういうことね
確かに
1個あるところで
ちょっと
トラウマではないけど
確かになと思った時が
あったことがあって
システムのプロに頼んでるんだから
お得で考えろよみたいな感じの
ことを言われた時が
それは
そういうお客さんもいるとは思うよ
いるよね
いると思ってて
それは多分システムの話を
しちゃったんだと思う
確かにね
要求の話をせずに
要件定義の
仕組みとか
そっちの方の話をしちゃって
何を目指したいのか
みたいなところの
仕組みの方の話をしたら
それはオタクがやってよ
っていう話
そっちの話をしちゃった説は
あるかもしれない
もしくはそういう話を
してなかったとしても
そっちの話に聞こえちゃった
みたいな
捉えられてしまったがゆえに
仕組みの話は求めてない
みたいなお客さんは
確かに多い
ここも話す時の
温度感っていうのかな
こういう仕組みじゃなくて
こういうより良いものを
作るために
みたいなのを
ワンクッション挟むことで
受け入れられるかというか
感じ方が変わるのかな
それとも本当に
全部お前らが考えろ
みたいなスタンスなのか
まだ僕悪名詞が
あまりついてなかったけど
あるかもしれないね
確かに
そういうことも
ありましたね
そういうことも
そういうこともありましたね
そんな感じで
AIに任せる時間と自分の時間の価値
AI時代結構やっぱり
いろんなことが
できるようになったけど
いろいろやらなきゃいけない
判断したことが
増えたなと
課題感の
今日の話でした
ありがとうございます
これで以上で
できればと思います
ありがとうございました
ありがとうございました
本日も
AI駆動開発部の日常を
お聞きいただき
ありがとうございました
いかがでしたでしょうか
今回は
認知不採であった
認知不可に対して
世の中的に
こういう話をする人は
HTMLで
こういうあれといいよ
とかみたいな
テクニカルな話を
してることが
多いのかなと思うんですけど
もちろん
そういう工夫とかは
してるんですけど
どっちかというと
どこにどう
価値というか
損失した時の
点を置くかというか
どこの時間を
削減できたから
ここは捨てて
大丈夫というか
この時点では
捨ててても大丈夫
みたいな
ちょっと向き合い方
みたいな話には
なったんですけれども
なかなか
僕たちの話が
いい悪いとかではなくて
一時情報として
こういう話してること
少ないかなと思うので
参考になれば
と思います
いつもはですね
いろんなAIとか
使ったりとかして
どのモネルがいいとか
どういうふうに
使ってるとか
あとはどういう
AIサービスがあったら
こういうサービス
使ってみてよかった
みたいな話してるので
ぜひですね
もし何か
これ使ってみてほしいとか
感想聞きたいとかあれば
いつでもコメント
いただければと思います
このPodcastが
気に入ってくれた方は
いいねやフォロー
高評価
ぜひお願いいたします
それではまた次回も
お楽しみください
バイバイ
