00:00
aozora.fm、このポッドキャストは雑談系ポッドキャストです。 今回は、ゲストに脱脂綿さんをお迎えしています。 脱脂綿さん、よろしくお願いします。
よろしくお願いします。
では、脱脂綿さん、軽く自己紹介をお願いします。
はい、脱脂綿という名前で、昔いろいろやっていた人で、 5、6回、aozora.fmの第5回と第6回のゲストを行わせてもらった人です。
で、それから株式会社に入ると、この時点では転職しなかったんですけど、 その後、株式会社に入ることになりましたので、
僕の前に、その時点では生きることなく、 キイチさんと同じ会社に転職して、そこでいろいろ、本当のエンジニアから、
エンジニアから、できることは何でもやるという精神を、 キイチさんと一つになっていた人です。
今日はよろしくお願いします。
はい、よろしくお願いします。
そうですね、もう2019年とかですか?
食べましたね。
ぐらいに前回お呼びしていて、
その後、世間的にはコロナだったりとか、 お互いその環境というかライフステージというか、
みたいなものも変わり、なかなかお話しする機会もなかったんですけど、
技術書店が先なんですかね?ツイッターですかね?
いや、技術書店。
技術書店でリアルでお話しする機会がありまして、
そこからいろいろお話しさせていただいている中で、
これを収録している時点では、直近の回数で言うと、
277回にお呼びしたキイチさんの話をお聞きして、
ぜひポッドキャストを出たいですということで今回、
だから収録としては2回目なんですよね。
そうですね。
という形でお呼びしましたという流れでした。
何の話をするかというと、今話題にあがったキイチさんとの話が面白かったよね。
キイチさんも7年ぶりとかだったんで、
お互い最近どうですかみたいな話から、
結果としてソフトウェア開発話になったんで、
そういう話をしていけたらなというところで、そんな感じですかね。
そんな感じです。
じゃあどうしましょうか。先に雑誌面さんからこんな感じっていう直近を喋ってもらうといいですかね。
そうですね。
直近…でも5回、6回、ヘビービスナーの方がいて、
5回、6回も全部聞いてらっしゃる方がもしいて、
何だろう。
差分がそこからだとすると、
そこから全部話そうというのは若干尺が足りないと思うんで、
すごいかいつまんで喋ると。
03:00
そうですね。転職をしていきまして、
転職した株式会社MEって受託開発の会社なので、
そこで10の指にはいくくらいの案件はいろいろやって、
そのうちの直近2つが重く長く付き合いがある会社。
それぞれ3年ずつくらい。
3年ずつはちょっと全部受け入れにいっちゃうか。
でも2年3年くらいの付き合いのある会社になっていたので、
すごい良くしていただいたなというのもありつつ、
そこで一般プレイヤーというよりは、
マネジメントの真似事なんかもさせてもらいながら、
お前がリーダーだなというふうに周りからの評価とか、
事務院担任をもらいながら仕事ができてきたかなっていうのが概要。
その中でも基本的には主に使っていたのはゴーラング。
ゴーラングのメディアスペシャリストになったかと言わないようにそうではなくて、
ゴーラングが上手いやつがたくさんいるので、
もうちょっと別のことで上手くやれる価値を出せるようなことはないかなと思っていたときに、
前の話でも軽くしてたテスト駆動開発が結構僕はまだ好きなので、
そこから始まりのちゃんと自動テストをやろうとか、
ちゃんとテストって何をテストしなきゃいけないんだっけ?
テスト技法ってなんだっけ?
そのあたりの勉強とかをやっていって、会社の案件の行動に対して、
こんなことすればいいんじゃないかみたいなことを口出しをしてみたりとかいうのをやっていたりしてました。
僕もその文脈というかベクトルで近況直近の話をすると、
記者さんの回を聞いたのであれかもしれないですけど、
僕が2019年ぐらいだとAndroidのスマホアプリ開発をやっていて、
その後自社サービス、SaaSですね。
営業支援向けのSaaSのツール開発をやっていて、
そのときの技術スタックはバックエンドがRailsで、
フロントがAngularJSのほうかな?
あとリアクトでした。
いろいろやってたんで、バックエンドもフロントもチームリーダー的なことをやっていました。
その後SaaSに行って、SaaSは3案件、4案件ぐらいやったんですけど、
その後Pythonでバックエンドを書いたり、
06:02
スクラム開発の開発者として入って、
ゾンビスクラムみたいになっているのを経験したり、
そのときはフロントビューのバックエンドPythonだった気がしますね。
最後の案件がインフラの現場リーダー、いわゆるSaaSというところの現場リーダーみたいなのをやっていて、
そこはテラフォームでAWSの構築もやってたんですけど、どっちかというと保証用って感じの案件でした。
それが全職で、転職して現職で、名刺の肩書き的にはアジャイルコーチスクラムマスターみたいな感じなんですけど、
主にプロジェクトマネジメント文脈でのアジャイルコーチスクラムマスターだったりっていうのをまず1案件やって、
2案件目がほぼ現場コンサルみたいな感じで、QAが先に開発現場に入っていて、
そのQAチームの効率化とか作業支援みたいなのを生成AIでやろうみたいな案件でした。
それをやってから今月からプロダクトマネジメントとかプロダクトオーナーみたいなのをやっていて、
プロジェクトのマネージャーが他にいるので僕が口を出さないように、でも口を出したいみたいなのを最近やっているみたいな。
はい、そんな感じでした。
ところで、どうしようかな。僕からダッシュメンさんの話で気になったところを掘り下げてもいいんですけど、
逆にダッシュメンさんから僕に聞いてもらってもいいですけど、どうやっていきましょうか。
いや、掘り下げてもらいたいことは。
なんでしょうね。どうしようかな。いろいろもちろん気になるところみたいなのはあるんですけど、
あえてでもないですけど、7年前の話も含めてTDDからちょっと入っていくのはいいかなと思ったんですけど、
TDD、2026年4月、5月ぐらい現在でも、引き続きなのか改めてなのか脚光を浴びているなというところがあって、
いわゆる生成AIの文脈みたいなところであったりすると思うんですけど、
改めてその自分がやってきたTDD、ダッシュメンさんがやってきたTDDと、今社会で世間で言われているTDD、
その辺一旦俯瞰するというか、遠くから見てみて思うところとかあったりするんですか。
そうですね。TDDテスト駆動の開発手法として見たときに、
それを生成AI時代にどう俯瞰してみているかっていうことで言うと、
09:08
僕は懐疑的なものから入っちゃうんですけど、
フロードとかが最初にテスト駆動でやるといいもの書けるよみたいな、最初に出たりするんですよ。
チップスみたいな。あれには若干懐疑的というか、
だって君たちテスト駆動で自分で手で書いてからプロンプトを書くんじゃなくて、
テスト駆動で書いてってプロンプトを書くじゃん。
エンジニアがテスト駆動のテストコードを書いてから、これを生み出すコードを書いてくださいって言うんだったら、
まあ可能性はあるけど、でもそれって本当に各エンジニアが望むスピード感になるのっていうところの疑問というか、
僕はそういうふうには書いてないよっていうのは少なくともあるのと、
じゃあ生成AIにテスト駆動で書いて、キーワードのテスト駆動で書いてっていうのって、
ごめんなさい、これは試してない人に言うのも何なんですけど、
結局AIは自分が理解した仕様をテストに書いて、それをパスするようにコードを書くので、
あんまりその通りになるとなっちゃうんだよね。
テスト駆動で僕が欲しい、テスト駆動が愛していたメリットとしては、
語呂解で喋ってた話って主にテスト自動化のメリットじゃないかって語呂解のときが一番いいって思うなとして、
ちょっと分かっていないなみたいな。
7年前の自分はと。
例称系になったりしたんですけど、例称系は最近出た言葉ね。
というよりは自分の今やってる作業を細かいステップで分解していって、
目の前の作業に今俺は何をしてるんだっけっていう。
それに対して全集中力を果たすことで、比較的発散した思考じゃなくて、
ある今作っているカンセルとかパッケージっていうところにフォーカスを置くことによって、
大きな仕事を果たすときに、大きな仕事全体のことを考えながらコードを書くより、
その小まけにした小さな仕事のことに、今のガードレールを引きながら取り組んでいく。
っていうことによって個別のパッケージの関数が品質高く保つことができて、
12:03
結果的にそれらが組み合わさったものも品質高くなるよね。
これは全部の品質っていうのは、その作業中についていた自動テストがある程度保証してくれるよね。
保証してくれるっていうのもまたちょっと違う言い方かもしれないけれども、
そういうふうに使えるよねっていうふうに思ってて。
昔テスト駆動開発を結構ガッツリ自分の手でやっていたときに、
いわゆるヘリシングの小作のコラーを使って、
テスト駆動は素晴らしいけど、君たちの賞金は誰が保証してくれるの?
個別のテストの正しさは誰が保証してくれるの?っていう漫画のコラーにしてたやつがあって、
僕は明確にそれが回答できると思っていて、
保証はできないけど、でも100のことを仕事をするときに考えていたテストより、
10とか5とか2とか1とかでスコープ切って考えていたほうの正しさのほうが、
正しいものにより近づくと思うんだよねっていう。
そういうのがテスト駆動の良さだと思ってて、僕は。
っていうことを考えたときに、
生成Iって100本と出してくるじゃないですか。最低限の。
1ずつ出すやり方だとみんな満足できないと思うんですよね。
って僕は思うから、
僕は自分で生成I使ったコードを書くときにはテスト駆動はやってないです。
僕は。
ちょっと上手いテスト駆動と生成Iとの付き合いをしてらっしゃる方がいたら、
それはそれで募集を超えちゃいます。
ぜひこれを聞いている人がいたら、
聞いている人がまずいるのかいないのか問題と、
聞いている人の中にTDDをそこまでって人がいるのか問題っていうのはありつつなんですけど、
なんか今の話すげえ面白いなってところがあって、
なんか最終的にはちょっとこうTDDとはみたいなところにちょっと話を持っていきたいなと今思っているんですけど、
なんかその中で1個面白いなと思ったのが、
最初にその生成AI、コーディングエージェントにTDDでやってっていうのってどうなんだろうってところが面白いなと思っていて、
それって人間に置き換えると、
例えばマネージャーとかチームリーダーみたいな人がメンバーに作業指示をするときに、
これをTDDでやってって言ってるのと同じことなわけじゃないですか。
で、それはなんか開発ルールとしてTDDでやろうっていうのとまたちょっと違うじゃないですか。
で、TDDでやることが目的だったんだっけっていうのはあると思っていて、
どっちかというとなんでTDDなんだっけ。
どうして僕ら、僕らっていうのはチームとして、
15:02
僕らのチームはTDDを求めたんだっけの部分だと思っていて、
なんかそれが生成AI、コーディングエージェントになったときに、
コーディングエージェントに対してはTDDが有効であるってなっちゃってるのが何か違和感なのかもやってるのかなっていうのは、
なんか僕もそう思うし、だしめんさんもそうなのかなとはちょっと思いましたね。
そうですね。
話しながら1個思い出したというか、よく一般的に言われてるTDDのメリットの1つ。
もう1個がテストアビリティを最初から意識できるよっていう、
このモジュールコンポーネントの関数のテスト可能にするための考えをテスト駆動とかきながら、
テストしづらいわってすぐ気づけるっていうメリットがあったりするって話があったりするんですけど、
それすら生成AIの速度なのとすれば、テスト書いてって言ったときに、
AI君は賢いので、いや賢いかどうか知らないけど、
これ今の会社だとテストしづらいね、じゃあ直すねって直してやっちゃうんじゃないかなって思ったりする。
そうおっしゃった通り、僕も生成AI以前の世界線で一緒に働いてきた人にTDDでやると面白いよとかこんな風に書けるから、
多分今の君の過去に書かった後輩とか部下とかを追いかけて、
ちょっとあんまり品質が高くないコード、テストアビリティが悪いコードとかを書くときに、
こういう手法もあるんだけど、やってみると解決するかもねっていう言い方はするんですけど、
俺のオーダーはこれをやってくださいじゃなくて、
それはあくまで助言アドバイスであって、オーダーとしてはいいコードを書いてきてねっていう、
いいコードとは少なくともテストアビリティが高くて、テストされていて、
アビリティとかは厳密に指標にするとそれはそれで嫌なことになるんであれですけど、
少なくとも僕が水準としてここはテスト書いた方がいいなと思うところがちゃんと書けてるなっていうところは書いてほしいねっていうところはお願いするけど、
それをTDDでっていうのはなんか違うなっていうのは完全にそうかなと思います。
うーん、なんかそういう意味で言うと、そこからやっぱりなんでそのTDDなんだっけ、
多分もっと抽象化すると、なんで僕らはテストを書いているんだっけみたいなのがあると思っていて、
今おっしゃったように、コード、プログラミングコードとしての品質、
これ品質っていうと多分良いコードかどうかなんだと思うんですけど、いわゆる素結合であるとか、
18:07
まあ言い方が違うだけで同じ意味ですけど、何かに依存してないとか、
っていうのもテストを書くことによって分かりやすくなるとか、あるいはそのメソッド、特にTDDの文脈で言うと単体テストになると思うので、
あるテストコードが何か異様に長いとか、すげー複雑な条件網羅をしなきゃいけないってなった時に、
それはテストコードが悪いんじゃなくて、そもそもメソッドが何かデカすぎるんじゃないかとか、
もっと切り出した方がいいんじゃないかとか、何かそういうとこに自分で築けるみたいなのがある、
メリットとしてあると思ってますと、それってプログラミング良いコードに対するメリットじゃないですか、
じゃあ本当にそれが目的で僕らはテストをやってるんだっけ、テストをやりたいからTDDやってるんだっけ、みたいな1個あると思っていて、
その辺も含めて、生成AI、コーディングエージェントとTDDみたいなところのモヤモヤ感は何かあるのかな、とか思いましたね。
そうですね、僕自身、生成AIの進化のスピードとか開発手法の変化にまだ混同されている1人だなっていう自覚はあって、
だから今日喋ってることが、明日何言ってんだこいつってなっちゃう可能性は誰にしろあると思うんですけど、
あとで今リンクを送るんですけど、前の回でも話してたブロッコリー査定とかが、
AIコーディングツーリングによって加速するコード生成に現実を保証する方はどう立ち向かうかっていう記事の、
これは他の方が書いた翻訳記事なんですけど、自身のブログで公開されていて、それに対して本当にそうそうそうみたいなことを思っていて、
詳しく読んでもらってた話なんですけど、この話に関わる部分っていうと、テストコードをAIに書かせても、
AIは最初から何かバグの音症を生んでいたとしたら、そのバグに沿ったテストを書いてしまう予定。
だからAIに書かせたテストによってバグは開発分類では見つからない。
後ほどリグレッションテストとして役に立つテストが書けていたとしたら、それを壊してしまった時に気づくことはあるかもしれないけれど、
っていうところが書いてあったりしたので、僕らは生成AIによってスピード感を早く物を作れるように、
開発の部分、コードを書くというステップでは早く物ができるようになったけど、
21:05
それが品質高いものかどうかとかいうのは結局今テスト界隈でどう検査しようかっていろいろ話しているんだけど、
それが僕の中ではまだこうすればいいんだなっていうのは思っていなくて、
だけどおっしゃった通り、総結合だったりテストがあれば一つのコードが無意味に頂戴な、
手続的なコードになってほしくないとか、こうやってほしいなっていうのは、
今後このAIコード、このツールが書いたコードを募集する上で、いまだに維持してほしい検出特性があって、
そこをどう担保するのかっていう部分は、いまだに人力なんですよね、僕の中では。
でも実際のところ、出てくる行が多すぎるので、今まで通りのチェックはできない。
いうところは本当に今どうしようかっていうのは思ってて、
最終的に今僕がやっているのは、振る舞いを検査する、シェナリオテストをもらうということで、
内部品質はわかんないけど、とりあえずこれだけは守ってほしいものは守りきるっていう防衛ラインを下げているような感覚。
品質を担保してほしいみたいな、でもAIはしてくれない。
これ品質とは何かみたいな話がまた出てきちゃうんですけど、一旦それを置いておいて、
自分が望む品質はやっぱりAIは担保してくれないし、今のところできないよねっていうのはめちゃくちゃわかる。
そうですねっていうとこがあって、そのために振る舞いテストみたいなのをやっているっていうのは、
それも一つの解というか取り得るオプションの一つなんだろうなというのはありつつなんですけど、
結局これも人間に置き換えてみるとそうだよねっていうところがあると思っていて、
メンバーとかに品質担保してよって言った、あるいは自分が言われたとしてさっきの、
じゃあ品質って何ですか?テスト書きやすかったら品質高いって言えるんですか?ってなると思うんですよね。
でもそれってさっきだしめんさんが言ったように、いや元のコードがバグってたら、
いかに疎結合で綺麗なコードが書かれててもバグってたら意味ないですよねって話になりますと。
じゃあバグって何だろうって言ったときに、たぶん単純にその実装上のバグ、
まあ基本的に最近の言語はあんまりないですけど、ここで変数宣言してないのに変数使ってるから、
未定義でこけるやんけみたいなものもあれば、なんかわかんないですけど一覧画面を実装したときに、
24:06
20件出してほしいのに10件しか出てませんでしたみたいなバグもあるわけじゃないですか。
でたぶん校舎の方のことを僕は言っていると思っていて、でこの校舎の方はAIにテストコードを書かせても、
テストを書かせても発見できないよねだと思ってますと。
でじゃあ人間に同じことをやったときに、人間が書いてきたPR見たら一覧が10件しかなくて、
いやいやいや仕様20件だよねみたいな。でこれってAIだろうが人間だろうが同じことであって、
AIだから品質を考えねばならない、ではないと僕は思ってるんですね。
なので僕からするとこのTDDの話もそうなんですけど、
品質こと品質においてもそうだし、なんで今更騒いでるんだろうって思ってるし、
ソフトウェア開発っていう大きな目線で見ても、なんか焼き直しみたいな。
もう20年間同じこと言ってないみたいなすごい感じるんですよね。
挟まないという、同意だなと思っているんですけど、
同意だなって思うところと違うな、僕がこの話でホルチャーさんと認識が違うなって思ってるのが一つあるとすると、
量だと思ってて。
実装させる、アウトプットの量ですよね。
そうです。探さないといけないんですよ。
特にマネジメントをやってたっていうのに関わった時に、僕も同じ理解をしてて、
マネジメントにつまりコードを自分の手で書くんじゃなくて、
人に言われて自分ではあんまり直さない、あるいは書くとしては限定的になっていった時に、
でもチェックは僕がしてるっていう時に、やっぱり同じようなところ。
何が品質だとか、それをどう担保するかみたいなことは思ってたんですけど、
でもそのルールがなくてもなんとかなったんですよ。
ルールなり手法なりなくても、僕一人でなんとか見れるなっていうアウトプットだったんですよ。
でも生成AIが始まって、元から生還性高かったメンバーが3、4倍くらいドカッと出してくると。
その人たちは生成AIが完璧だと思っているから、これでいけますって出してくるんですよ。
でもこういったんですけど、テストしては下がってるんですよ、感覚。
あんた自分の手で書いたらこんなことしないじゃんっていうのが結構入ってて。
で、それを指摘すると、ああそうですねっとってわかってはくれるんで、
27:02
そこまでパパッと直してくれるんですけど、パパッと直すのをまたAIが半分やってるみたいな。
結局その部分をパパッと直したやつに、またちょっとそこは入れないなみたいなのが入ってたりするみたいな。
っていう意味で、生産性が上がってるということ自体に若干怪異的なのと、
保守というか品質を守る防波堤だった人たちの部下はむしろ上がっていると思っていて、
という意味で、よりこの20年間より節に何か改善が必要だという感覚は持ってますね。
そうですね、生産性が上がってないよねみたいな部分は僕も同意だと思ってますと。
ただそれでも僕は20年間変わってないよね。仮に生成AIがあったとしてもとは思っていて、
要は今の話って生成AIがない前、出てくる前は何とか脱出面産が見れていたっていう話なんですけど、
それって見れる範囲の生産量だったからでしかなくて、要はメンバーが2倍いたら見れてましたかだと思ってるんですね。
人数が同じでもめちゃくちゃ優秀な人が入ってきて、出力される行動量が2倍になったら多分見れなかったと思うんですよ。
これ全く同じことだと思っていて、今の状態と。で、何でそうなってなかったかって言ったら、
脱出面産が見れる範囲でしかやらなかったからだと思う。要は自分は今の10倍PRデビューできるんで、
メンバー10倍にしてくださいとは言わなかったわけじゃないですか。そっちの方が明らかに作業効率はいいとしても。
それはもう自分ができないって分かっているからだと思っていて、それって別に今のAIも同じですよねと思っていて、
これって技術的な話で言うと、これ多分ティーワラさんが言ってたと思うんですけど、
GitHubができた時にブランチ切りまくれば無限に並行実装できるよね。
必要な機能が100個あります。それが並行で実装できる。要はクリティカルパスにならないのであれば、
100ブランチ切って100人投入したら、1日で実装終わるよね。どうなりますかって言ったら、
デビューがまずできない。100個あるし。相互に関連する、これは機能というよりは行動の問題なんですけど、
要はコンフリクトするみたいなことがあって、その話は一瞬で無くなったんですね。
今コーディングエージェントでやってることってそれと同じじゃないですかって思っていて。
僕はその観点でも20年間、もちろん個別具体の人は違いますけど、抽象化すると同じだと思っている。
なるほどな。そう言われるともうそうだなって今のところは思いますね。
30:01
なので、今の雑誌面さんの話で優秀なメンバーがAIで速度を上げて帰ってきた時に、
それはまあそうなるよね。だって昔からそうだしだと思うので。
なんかこれはAIが悪いってわけじゃないですけど、何が良い悪いって言い方は良くないかもしれないですけど、何が悪いか言ったら多分マネジメントのやり方が悪いんじゃないか。
それは開発ルールとか開発手法とか、開発チームのマネジメントの問題なのではとはちょっと僕は今感じちゃいました。
なるほどですね。あんまり異論がないな。ないから、それをどうしていくかっていう話自体に。
もともと僕がスケールするためには何が必要かっていうトピックは別の問題としてあり続けていて。
それはAI以前からっていうんですよね。で、そのためにちゃんとテスト技法を学んで、
練れるところをちゃんと必要な、絶対に逃してはいけないやつは逃さないけど、
そうじゃない、例えばつまんないゴジラとジュースとかだったら見つけたらいいよ別に後でシェルトプリント上げといて別にないし、
ログでしょって言えるかどうかみたいな文脈のスケールアップは別の文脈でやろうっていうふうには思ったんですけど、
そういう意味では僕はAIによって自分がスケールしなかったっていう問題は、
なんかどこか別枠で捉えていた趣旨はあったんですけど、そうじゃないかもなっていうのが改めて思ったな、今の。そうかもっていう気がする。
じゃあどうすればってなったときに、今の話で思ったところで、じゃあどうすればいいのかってところに話を持っていくと、
一番簡単に思いつくのは、じゃあ生成AIやめますだと思うんですね。今まで通りにすれば今まで通りにいけますよねと。
それはそうなんだけど、現場も当然納得してない。なんでAIがないんですかってなるし、ビジネスとしても許されない。
AI使ってみたいな看板的なPRみたいなところもあるし、単純に今AI使ってない、例えば会社だったり組織って転職みたいな文脈でもちょっと人材広報的なところでもきついし、
単純にその競合他社との速度に勝てなくなりますよね。なので、生成AIコーディングエージェントを使ったまんまうまくやる方法を考えなければならないと思っていて、
33:07
その時に思うのが、じゃあ今までってなんでできてたかっていうと、出し面さんだったり僕だったり、あるいはレビュアーみたいな中身ちゃんと分かっている人がちゃんとレビューをして外に出していたから品質の速度も担保できてましたよねだと思いますと。
じゃあメンバー側がそのレビュアーの権限を、あるいはスキル、知識をデリゲーションしてメンバー側ができるようになったら、1チーム例えば5人いったうちの1人がやっていたものが4人もできるようになって、全員が速攻担保できますよねと。
で、仮にそのクロスチェックっていう意味でレビューするんだったら、細かい行動を見るんじゃなくて、どういう観点でチェックしましたかっていう上っ面だけ見てあげれば大丈夫ですよね、品質担保できますよねだと思っていて、そこのデリゲーションが今足りないと僕は思っているなぁと感じております。
先に送った、これは別の話かな。ブロッコリーさんの、これはブログじゃなくて、ブロッコリーさんがやっている別のポッドキャスト、Bテストインディセンスっていうのがあって、それでまさに何だっけ、何回だったかな、直近で自分の持っているテストの観点をスキルに持っていくと、
結構AIのレビューの質が上がったよっていう話があったりしたんですよね。それはやれてなかったなっていうふうに反省して、今ちょっといろいろスキルの多さをしてみているところだったりするんですけど。
で、それのスキルが完璧になるっていうよりは、そのスキルを、スキルって自然言語で書くじゃないですか。そこが素晴らしいと思っていて、僕は。そのスキルをアップデートするたびに人間も読んでみている。どういうことを気にしてレビューしているのかっていうところがドキュメントとして使えるし、
そのドキュメントを更新するとAIっていうのが賢くなるっていう、スキルって仕組みがすごくいいなって僕は思ってるんですよね。そこをすごくやっていきたいことでは少なくともあるかなと思ってますね。
うん。今その話を聞いて思い出した図があるんでチャットに送ったんですけど。赤モデルっていう考え方があって、赤モデルの赤はSECIで赤モデルなんですけど、いわゆる暗黙値と形式値を行ったり来たりするみたいな話のモデルで、
36:01
これはスクラムの原点にあたる論文を書いた野中育次郎先生っていう方が作ったモデルなんですけど、まさに今のスキル、この場合のスキルっていわゆるクロードとか生成ライン食わせるための何とか.mdみたいな、スキル.mdみたいな意味でのスキルだと思うんですけど、まさにこれだなと思っていて、
ブロッコリーさんでいえばテスト観点とか技法とか考え方みたいなの前にある暗黙値、自分の当たり前をスキル.mdっていうマークダウンで形式化する。で、この形式値を受け取った人がこの場合だと他のプログラマーだったりITエンジニアがまた内部に取り込んで暗黙値化して、またその現場でいろんなドメイン知識だったりもろもろあると思うので、
暗黙値化したものがまた形式値に、例えばブログによって出てくるとかみたいな話だと思っていて、これダシメンさんがマネジメントのデリゲート権限以上をしても多分同じようなことになると思うんですけど、まさにこの話だなとは今ちょっと思いましたね。
いや、これは僕初めて見ましたけど、まさにこの話かなっていうのはおっしゃる通りで、結局形式値に持っていくということを労力として払ってこなかった付はみんな払うよねっていうのは間違いなく思ってて、
でも、さっきまでアンティAIみたいな口笛をしていたら申し訳ないですけど、僕もそういう意味ではスキルMDは描けば描くだけ、今目の前の仕事が楽になると思ってて、そういう意味で形式値に持っていく力学が強く働くなって思っているんですよ。
今までの形式値に持っていくのって、結構応用のドキュメントを整備して読んでって読まれなくて、読んでくれよって思いながら誰もやらなくなるみたいな、ちょっとそういう悲しいループが働いたと思うんですけど、
AIは読んでくれるし、俺の友達はAIだけかっていうのはあるかもしれないけど、でもAIに書けば、そもそもAIがブレイク上のコメントでちょっとそれぞれいうことを言ってきたりするんで、
なんでこれこんなこと言ってんの、こんなことがMDに書いてんのかっていうようなループで、より良い形式値を他のメンバーに浸透させていく助けにもなるんじゃないかなっていうふうには期待してますね。
なんか本当におっしゃる通りだなっていう感じで、本当にブロッコリーさんの例もダッシュメンさんの例も、形式値化したスキルをじゃあメンバーに渡してメンバーのAIがそれで動くようになった時に、
39:07
メンバーがその自然言語、スキルの中身を理解して同じように振る舞ってくれることが、まあ期待値というか目的じゃないですか。別にメンバーにAIのオペレーターになってくれって言ってるわけじゃないので、
自分一人がやっていたことをみんなでできるようになろうねって話を言ったと思うので、つまりそれってメンバーもコーディングエージェント、AIエージェントっていうのはちゃんとマネジメントしてねってことだと僕は思っていて、
なんでエンジニアリングマネージャーみたいなEMみたいな役割だったり、まあ役職という役割ですね、役割だったり責任っていうのが今後AIを使って開発したいならば、あなたEMですよっていうことをちゃんとやっていかなきゃいけないんだよなって僕は思って。
完全に同意見。なんだ、そうなんだ。
ちょっと言葉が強いかもしれないですけど、自分メンバーです、プログラマーです、でもAI使いたいです。でも出した結果は自分は知りませんわ、もう通らんよって僕は思ってます。
あのね、その話すると思ってなかったんですけど、僕もじゃあ言葉強く言っちゃうかもしれないけど、本当にそうだと思っていて、だから僕エンジニアは世代時代に突入しているなって思ってるんですよ。間違いなく。
だって責任が増えるんですよ、確実に。今までは二人に銃のコードを書いていた人が、まあバグを生み出したってのはそのプログラマーの責任なのかという話はまた別の話としても、まあでも責任は一旦はあるとするならば、その銃のコードの面倒だけ見たのを聞いてたら、まあよかったとするならば、
あなたの手元でAIがいて、すごいAIめっちゃ成功した、最高コード出した、1000出したっていう、その1000のやつの責任はAI持ってくれないんだよって。でも結構無邪気に1000できたって喜ぶんですよ。
で、この1000できたコードを言ってしまえば大して理解もしてない、めちゃくちゃ悔しいわけじゃないから、なんかバグったぞって怒られた時に、そんなコード書いては聞けないんだよ、コードを読まなきゃいけないって。
で、お給料はさっき増えた。僕らが10コードを書く以上の10人のエリアにどちらかが付いていたら、まあだいぶ上がるように見えた。
だけど、昨日言いましたよって言っても、ああ、そうなんだよ、AI使えてよかったって言って、最終的に上がってるように見えた。まあ、分かんないですけど、僕の話でその時に1000万円上げてるっていう話があったりするから、多分上がってるのかもしれないけど、まあ福田さんはそういうのまだスタンダードじゃないですよ。
42:13
っていうのって、エンジニアが精神的に上がっているって言って、めっちゃ生産性が上がって、市場価値が上がってって言ってる、そういう無邪気な喜び方とは、なんか実際は乖離してないかなっていう心配はあるんですか?
いや、まさにその通りで、生産性っていうのもまた難しいなと思っていて、さっきだしゅめさんはエンジニアって言い方をしたんですけど、どっちかっていうとプログラマーだとは思ってるんですけど、
プログラマーがその生産性を語るときに、もちろん出力したプログラムソースコード、まあ20年ぐらい前に話を戻すとステップスみたいなものは確かにコーディングエージェントによって生成量によって増えましたよねと。
それでじゃあおっしゃるように市場価値が上がるんですかっていうと、あんだけステップスわらわらとか言ってきたじゃないですかみたいな、そうじゃないって言ってたじゃないですかだと思っていて、じゃあその生産性って市場価値って何なんですかっていうと、この言葉を使うとまたこれも嫌がる人が多いんですけど、
プログラマーにしろITエンジニアにしろ、僕らビジネスをやっているので、そこで出力したソースコード、まあ別にExcelでもいいんですけどが、おいから万円、ビジネス的価値はおいからって話でしかないと思うんですね。だから無意に大量にコード書いてステップスおいからっていうのが批判されてきたと思っていて、
一行で100万円稼げるならそれでいいよねって話だと思ってるんですよ。だから生成AIコーディングエージェントで生産性増えましたねってなった時に、じゃあいくらあなた稼いだんですか、そのプロダクトにいくら寄与できたんですか、価値はって話になっちゃうと思っていて、そういう意味で責任が増えるっていうのはそうだねだと思うし、
僕に言わせると増えたんじゃなくて、見ないようにしてきただけでしょ、本当は見なきゃいけなかったのに、あなた方はこれもバイネームで言っちゃいましたけど、プログラマーは見ないようにしてきただけでしょ、誰かにおんぶに抱っこにしてきてもらっただけでしょっていうのを突きつけられているだけだと僕は今思っちゃいますね。
うーん、なるほどね。
でもこれ自分もそうですよ、自分ももちろんプログラマーだったんで。
そうですね、マネージャーの責任に膝が上がるというか、っていうのは間違いなくそうだと思っていて、
そうですね、いくら稼いだのもそうだし、機能はそうですね、ステップ数じゃないんだったら機能数でもまだ基金なものとしてあるかもしれないけど、機能をいくつ作って、その機能はどのくらい使われていて、
45:13
使わない機能などがわかったんだったら潰していくっていうフィードバックループは早いかもしれないけれども、当たった機能、残すと決まった機能も当然増えていくので、生産性がバンバン出していくんだとするんだとすれば、
で、その分の補償はしなきゃいけないし、補償する上で気にしなきゃいけないことって、今までの、そこにギャップは少なくともあると思っていて、そのAIを使ってそのものを出力した人と、その出力されたものを受け取る人。
当然、脱脂綿が納品しますって言って書いたコードは、受け取る側は脱脂綿さんが持ってきたんだから、脱脂綿さんに聞けば教えてくれるなとか、脱脂綿さんに何かバグったら直してもらうなっていうふうに思っているだろうに、俺はそれを究極的に部下にかけてたのと同じようにAIがやってたっていうふうに思っているとすれば、
なんか、その部下がやってる分は責任を取ろうというマインドは少なくとも僕は思う。
思ってきたけど、じゃあ個々のエンジニアが、そのAIがやってきたことを、じゃあ同じように責任を持つっていうふうになるかというと、そこまで覚悟は決まっているかどうかは、僕はあんまりそういうふうには見えない。
いやー、それはね、ソースでとしか言えないんですけど、こういう話をするとね、じゃあさっきの給料が、責任を増えたのに給料が上がらないんですかみたいな、俺たち苦労するだけなんですかみたいなことを言われちゃうんですけど、
まあ、そういう側面もある。そういう見方もできるし、別にそれはマネージャーだって、EMだって、リーダーだって、同じですよっていうのはあるし、それが正々AIっていうものの、なんだろう、もたらした一面でもある。
それが正の面なのか、負の面なのかっていうのは、感じ方次第なんで。なので、みんな同じスタートラインに立って勝負していかなきゃいけないですねっていうだけだと思っていて、じゃあ、よーいどんスタートですねってなったときに、責任だけ増えるんですかって言っている人と、じゃあどうやろうかなって言っている人と、
いやもう言われたことしかやりたくないんで、コートだけかかせてくださいって人と、どれだけじゃあ走って進めるメートル数違いますかね、だけだと思っていて。だから、ここ5年ぐらいで話題になった小学校の特競争は、みんなで手繋いでゴールにはならんよっていう。
なぜならば、これはビジネス、市場主義だから、横根全力疾走してる会社がいたら、僕らも全力疾走してないとビジネス負けますよっていうだけでしかない。それ以上でも以下でもないので、だからお互いみんな大変ですねって。
48:22
いやそうなんですよ。僕も本当に、見えてるよって言い方がしたいわけではなくて、世の中の世の中っていうか、つまり1600年からこの方法変わってないよねっていう。
いやそうなのよね。
メルトコンベア違うか、メルトコンベアはあの時代だったのかわからないけど。
1600年っていうのは。
産業革命で。
あ、なるほど。
産業革命ができると、一般労働者はネジ閉めて良かった人たちはもうみんな廃業して、業機で動く機械を眺める人に置き換えられるとしたらば、
業機機関で動くものを、いわゆる1人で今までネジ閉めた人がネジ閉める機械1秒間に1000台やれるようになったら生産性が1000倍になるわけじゃないですか。
でも別に給料はそこまで上がってないんだろうなって。
なんか私皆さんが見たことあるかわかんないですけど、その産業革命の写真で有名なのが、これイギリスの労働者の写真なんですけど、ロジに紐が張ってあって、その紐に脇の下を腕をかけて寄りかかっている写真があって、
これは何なのかというと、宿屋の写真ですけど、当時働いていた機械工、機械監視工ってさっきの話で言うとなっちゃうと思うんですけど、の人はすごい安い賃金で寝るところもない状態でみたいな感じになっている。
で、また別の話で聞いたのが、見回り、就業見回りっていう仕事があったらしくて、当時のイギリスには。要は房石、糸を紡ぐ機械で働いている児童、児童労働とか当時は当たり前だったんで、働いている児童がいた時にやっぱり仕事中に寝ちゃうらしくて、で、17時とか定時になったら見回って寝ている子供を起こして外に出すっていう仕事があったらしくて。
もうなんかそれを考えるとなんかもう痛ましい。でもそれって今の話ともやっぱり崩れるところがあるよなぁみたいなのはあって、別になんかその勉強しないとそうなっちゃうよってことが言いたいわけじゃなくて、
その産業革命、あるいはその前からの市場主義、お金を稼ぐっていうことに最適化されてしまうと、人間性ってどんどん失われていくよなみたいなのはあるよねっていうのは、歴史をひも解いてもそうっすねっていうのはありますよね。
51:13
いや別にそうなんですよ。市場主義というか経済的な、経済的というキーワードのもとに何でも許されるとは少なくとも現代、21世紀を生きている我々がそういう価値観になっていいかというと絶対ノーだとは思うんですけど、
一方でさっきほどおっしゃられたように市場原理というのがあって、市場原理によってそのある種倫理的な側面を無視した方が稼げると気づいてしまった人たちっていうのは世の中で少なくともずっと、言ってしまえばその恩恵を受けてしまったりしたわけじゃないですか。
特に日本ってこの世紀経済成長の時代の猛烈なサラリーマンがいなければ、あれって悪だったよねって言ってる僕らは、もうちょっと貧しい暮らしをしているかもしれないわけですから。
っていうのは、悪だったよねっていう、悪でもうやらないようにしましょうねっていうのとは別に法罪として認識はあるべきかなというふうには思うんだが、じゃあ自分はそれを再生産する気は少なくもないよって思ってて、
話が取れましたけど、SAIが何だろう、によってエンジニアは幸せになれるかっていうと、なんかほったらかしたら、それこそフェルトコンベアで眺める作業員にクラスチェンジして辛い風になってしまう可能性はあるので、
付き合い方というか、使い方というか、ちゃんと言って覚えて、自分なりの何かを気にしておかなければならないんだろうなとは思っています。それが何なのかはまだ僕は分かってないんですけど。
いやーそうなんですよね。おっしゃる通りで。だって言われたことをやるんだったらAIでいいじゃんってなっちゃいますもんね。
そうなんですよ。なんかね、既に100万回言われた話題だと思うんですけど、新人教育はすごい難しい。新人にこの仕事お手頃だっていうのを渡すと、終わりましたってAIで持ってくるんだけども、まあ確かに終わってるんだけどね。
じゃあ、AIを使うにはちょっと難易度が高い仕事をやらせてみようかっていうと、普通に難しいものしか残ってない。あるいは規模が、スコープがでかくなっちゃうとか、それを因数分解することは新人にはまだ難しいから、そのままAIに投げっ端するか、訳も分からずに完全に手が止まるか、
54:08
そういう意味では、まあ伴奏してやっていける体制だったらまだマシだと思うんですけど、伴奏できないとか、まあちょっと、伴奏する仕事が今手ごろにないやつがないとか、現場によってステーカスがいろいろあるじゃないですか。
そういう時に、これやっといてって普段だったら言ってんだけどなってやつを渡せないというか、渡しても教育にならないとか、っていうのはすごい大変なところ。まあちょっと今話したものが文脈が変わる話なんですけど、かなあっていうのはですね。
そうですね。多分この話するともう1時間ぐらい喋れちゃうんで、適当なとこで切りますけど、ティーワダさんも同じことを言っていて、いわゆるITエンジニアの教育とか成長とか体験を積む、経験を積むみたいなのが難しくなってますね、みたいに言われてますけど、
いわゆるジュニアっていうエンジニアよりも、ティーワダさんは4年目から7年目って言い方をしてたかな?の方が困るって話をしていて、4年目から7年目ってどうやってそこから10年選手とかいわゆるシニアになっていくかっていうと、
その時のジュニアに自分が説明をすることによって、まさに設計モデルで自分が手で動かすとできるんだけど、教えようとするとあれなんでこれこうなってるんだっけが言えなくて、また勉強し直すみたいな。あれがあったからシニアになっていけるみたいな。でも今のジュニアってみんな生成AIを使うんですよ。
何を使うかっていうと、AIに効くんですね。先輩に効かない。だから先輩は答える場がない。ので3年目、7年目は永遠にジュニアのままだよねって話をしてて、確かにって思っちゃってる。
なるほどね。
その結果どうなるかっていうと、生成AIに対するプロンプト力が磨かれるのでは?みたいなのをちょっと思っていて、最近NOWみたいな感じ。
でもね、わかるというか、現場によっては後輩がなかなかいないってあったりするじゃないですか。
わかる。
僕も割とその類だったんで、3、4年目くらいアウトプットを頑張った、最近やってないという反応があると思ってて、その辺でアウトプットが間違ったものも発信したかもしれないなと思いつつも、
57:16
でも自分なりに整備してアウトプットしてっていう経験は間違いなく人に教えるっていうのによって、自分の知識度とかを整備していって、改めて正しくインプットし直す、インプットアウトプット、生のループを回すっていう意味で有効だったなと思うんで、そうですね、3、4年目アウトプットしましょう。
3、4年目だけじゃないですけど。
そうですね。そういう意味で言うと、さっきの最初のTDDの話も多分そこに繋がってくる部分もあるなと思っていて、最初にテストを書こうとすると、今自分が何を実装しようとしているかを言語化できないとテストを書けないじゃないか。
価値のあるテストを書こうとすると、さっきの一覧って20件だよねっていう、求められている仕様だったりとか、このソフトウェアとかシステムとかサービスプロダクトが外に出ていった時に何で価値を得るのかみたいなとこ分かってないと、やっぱり価値のあるテストって書けないじゃないですか。
動くことを確認するテストって別に価値があるわけではないので、そういう意味でもここはアウトプットだし、設計モデルでもあるんだなっていうのは、今最後話してて思いましたね。
そうですね。だから僕も改めてTDDがAIにやらせてもなんでヒントが来ないのかっていうところをさっきの言葉でより強く思って、人間がTDDでコードを書くときってまさにそういうこれが重要だなっていうところを分かっているからそれを書けるのだって、
AIに一覧機能を書いてって言ったときに何が肝なのか分解してくれるわけがないし、そんなことはプロンプトに全部載せろって言ったら、それこそ面倒くさいですよみたいな。
だからそれこそ仕様駆動とか、結構最近やってないんですけどこれも。そういう風にものがフィーチャーされてくれるんだろうなとは思うし、そっちの可能性はあり得るなとは思いつつも、ハーネスがちがちにするのはそれはそれでしんどくないっていう感じにあるっていう作りたい努力として、
どんだけのものが必要なのかっていうのはあって、注視はしてるんですけどまだなんだろう、これだとバランスいいねっていうのは分かってないんですよね。これやってない人間に分かってないんですよねって言ったら当たり目だろって言われてるんですけど。
1:00:05
時間は有限ですからね。
という感じで今は、今は出来上がったものの品質を保つものの方に習慣がありますけど、作りながら品質を保つっていうのも当然あるべきプロセスで、それが昔はTDDだったし、SAI時代はスペック緑であったっていうのにSDDか、だしっていう変化は当然見ていかないといけないんだろうなとは思ってます。
ありがとうございます。非常にTDDから記録深い話ができたなと思って楽しかったです。
というところで、今1時間7分になったのでこの辺で締めていこうかなと思うのですが、何かダッシュメンさんから告知とか宣伝したいことありますか?
告知宣伝はあまりないんですけど、最近また旧ツイッター、旧Xって言うんですかね。
Xを再開にしましたので、直々過去にフォローしていた方をフォローし直したりしてますので、ダッシュメン生きてたんだっていう方も見つけたらフォローいただけるとありがたいと思っております。
ありがとうございます。出演者の欄と、あと概要欄にも一応リンクを貼っておくのでよかったら見てください。
では最後にエンディングトークってことで、ポトキャスターの収録どうでした?と話をしてるんですけど、最近はあんまりなかったですよね。
いやもう全然ないです。最後に撮ったのが令和1年の。
はいはいはい。
あれは何だったっけ?ポルテさんをやさないと。
あれは何だろう。カネさんのボッドキャスト。
カネさんだっけ?
いや終わらないです。ワンタイムアウトライフィルムだったかも。
アウトライフィルムなのでもあるなと思って。いやなんかその辺で喋ったのが多分最後かなと思うんで、それ以来声のアウトプットっていうのはずいぶん久しぶりだったんですけど。
やっぱりポルテさんが劇役が、劇役も話役も両方いって、なんかこう吠えた話ができて、自分はそんなことを考えていたんだってことに気づけたりしたので、結構面白かったり、面白かったです。
かったり。
はい面白かったです。
まあ一応このポッドキャスト楽しい予定でやってるんで、まあ面白いとか楽しいとか言って非常によかったなというところではございます。
というわけで今回はゲストにダッシュメンさんをお迎えしてお送りしました。ダッシュメンさんどうもありがとうございました。
ありがとうございました。
1:03:07
また青空FMではご感想やご意見をお待ちしております。
SNSでハッシュタグシャープ青空FM、シャープAOZORAFMをつけて投稿してください。
配信ページのお便りボタンからもお便りを送ることができますのでよろしくお願いします。
さらにお願いとなりますが、青空FMではご支援を募集しております。
フィクシブファンボックスかオフ製あるいはルームというサービスでも投げ線のような形で支援可能となっております。
もし支援してやってもいいよという方は何卒よろしくお願いいたします。
すべて配信ページにリンクがあります。
それでは最後までご視聴していただきありがとうございました。
