「理解を手放さない」記事の紹介とAI時代のエンジニアリング
こんにちは、三長です。
こんにちは、博崎です。
ゆるテクは、緩く技術の話をするポッドキャストです。 よろしくお願いします。
よろしくお願いします。
はい、というわけで、今日も2人で 喋っていきましょうという感じですね。
はい、お願いします。
はい、お願いします。
でですね、今日はですね、1つ最近読んだブログ記事で、 これ面白かったなっていうネタを持ってきたので、
そこの内容に対して、僕ら2人って、 じゃあこう思うよねとか、
そういう見解を述べられたらなって思っています。
はい、また無責任に喋るやつですね。
そうですそうです。 何も裏取りをしてるわけとかじゃなくてっていう方ですね。
はい、大丈夫ですよ。 この好き勝手に喋るだけのやつ大好きです。
はい、それでいきましょう。
今日持ってきたブログっていうのが、
2026年の7月26日に書かれている、 作書者の方のお名前どこだっけな。
しんばらさん。
しんばらさんか。ありがとうございます。
しんばらさんの書いている、 理解を手放さないっていう記事を読んだので、
なんかこの辺どう思うみたいなことを 無責任に話していければなって思っていますと。
いやーこれ、いい記事ですね。
いやーいい記事ですよね。
一応読んでない人向けにというか、 ざっとすごい本当に表層だけ要約をしていくと、
あれですよね、この時代AIに実装を任せてるんだけど、
人間はちゃんとその実装の中身の、 中身って言うとちょっと言葉あれだけど、
その実装の理解を手放しちゃダメだよねっていう話が書かれてますよね。
そうですね。
ここで言うタイトルが理解を手放さないですけど、
この理解というのは自分たちの作っているシステムとか、
もっと言うとコードとかに対しての理解という意味ですね。
ですです。
なので割と抗議なというか、
どのレイヤーでも捉えられるんだけれども、
各レイヤーでそれぞれ理解とはというような表現を 使われているように僕は感じましたというところ。
はい。
その記事の中身を2人で話していければかなって思うんですけど、
ちなみに僕はこれ読んでてすごくここいいなって思ったのが、
とはいえAIが実装する内容を100%網羅して理解できるかって言われたら、
物量というか数の暴力だからなかなか難しいとは個人的に思っていて、
それはAIが出てくる前から1人のコード変更が大量になったときは、
若干理解を諦めてたなって自分で思い返しながら読んでたんですけど、
その中で結構これいい表現だなと思ったのが、
理解を01ではなくて、
どの理由と抽象度で握るかっていうのが大事なんだよっていうのは個人的には刺さったポイントだったんですけど、
理解不足がもたらす恐怖とAI時代の理解への工夫
博多家さんはこの辺は自分的には結構わかりみがあったなとかってありますか?
これ理解不足は恐怖を生むっていう章があるんですけど、
ここが何というか今まで自分が感じていた、
今までシステムに持っていたこういうことが問題だよなみたいな、
知ってる問題と同じ問題なんだなっていうことがあって、
テストに対する例としてですね、
テストのないレガシーコードだとチームが変更を恐れるようになってっていう、
よく知られた問題がありますよね。
それと同じ面があるんだよっていうのが書かれてて、
理解しやすくなったというか、それがスッと入ってきてよかったですね。
なるほどですね。
これちなみに、わからないものに対する恐怖を生むっていうのは確かにそうだなって今聞いてて思っていて、
じゃあその理解するための工夫とかって普段あったりします?
AIによって出てきたものを理解するための工夫。
普段からそんなにバリバリに書いてるわけではないですが、
まず大前提として自分は一応全部見ています。
見ないという人も多分結構いると思うんですけど、
自分は一応全部見ていて、まだそのレベルの量しか見ていなくて、
実は一応自分でほとんどファイルを開いて、
ちょこちょこ直したりもしています。
ほうほうほう。
これ全く説明ができないんですけど、
わかってくれる人もいると思ってしゃべるんですけど、
自分が書いたコードと、もうほんと少しでもですね、
書いたコードと読むしかしていないコードだと理解が全然違うんですよね。
何でかわかんないんですけど、レビューだけしたコードと書いたコードでは理解度が全く違う。
それって掘り下げてみると、
コードを書くっていうコードをやるにあたって、
それこそ事前知識じゃないですけど、
インプットしないとやっぱり書けないからっていうそこの差が大きかったりするんですかね。
きっとそういうことですよね。
自然とやっているってことでしょうね。
コードを書くために集めている情報があるということだと思うんですけど。
なるほどな。
でも読むときもそれなりにやってはいるんだけどなみたいな。
この書くというだけで理解度が上がる気がする。
これは何だろうなとはずっと思ってますね。
なるほど。確かにそれは気になりますよね。
何でしょうね。語感の一つ。
でも別に増えてないな。
よく言うじゃないですか。
視覚、聴覚、語感を多く使った方が記憶に残りやすいとか。
それでいくとコードレビューって視覚?
いやでも見てるしな。
何が違うんだろうな。
そこは近しいものがありそう。確かにありそうですよね。
見るだけなのと実際自分がその中に入って何かを変えるっていうところで
必要なインプットは絶対やってるだろうから関連はしてそう。
だから難しいところは自分がどのぐらいの理解度なのかっていうのを
客観的に測る数値がないというか指標がないというか
ちょっと難しいところですね。
理解を手放さないっていうブログタイトルですけど
本当に手放してないのかとか
どのぐらい理解してるのかっていうのが測れないじゃないですか。
それでいくと僕たまに定量的にすごくしっかりやってるとかじゃなくて
擬似的にやってることはあるなって自分で思うときはあって
これはコードレビューに限った話だったりはしてるんですけど
AIでアウトプットされたコードをレビューする機会って
もう昨今みんな多いと思いつつ
だいたい僕がよく自分のコードレビューフェーズでやってるのって
そのコードの処理フローを必ずグラフィカルに
シーケンスっぽいのを作ってもらってるんですよ。
どういう流れで何をやってるのかみたいなのを
シーケンスずつ作ってもらって理解しようとしてるっていう一つと
あとは時間があればやってることなんですけど
その内容に対してクイズを出してもらってたりしてます。
これをやる背景は何なんですかとか
そういうものをいくつかランダムにAIにクイズを自分に出してもらって
それをある程度自分が回答できてたら
処理の中身がちゃんとわかってる
プラス解決したい課題が多分わかってるみたいなことを
議事的にやってたりはしますね。
面白いリカイドクイズ
どっかのブログでも
この記事に対するリカイドクイズみたいなのが
最後についてるブログあった気がする
どっかにあった気がするな
でも確かに仕組みで考えてみるとそういうことですよね
最後に小テストをやって
ちゃんとわかったのっていうのを確認してるって話ですもんね
めっちゃ学校っぽいですね
なるほどな
それだったら確かにある程度
それこそリカイドを図ることができそうですね
認知的不協和とモブワークへの回帰
最近だとそこのリカイよりも
スピード優先しようねみたいな動きもあったりしちゃうから
そこをちゃんと踏みとどまって
理解する時間取ろうねっていうのを
ちゃんと伝えたい記事なのかなと思いましたよね
理解をしてないと何が問題かっていうのも書いてありましたね
変更もできなくなるのかな
変更恐れてしまう
変更恐れてしまうっていうのが
あれですよねさっきのキーワードで言う
テストのないレガシーコードを触ると同じ感じですよね
不細ですね
不細なんですよ
今不細って言ってくれたからちょっとつなげちゃうと
僕この記事読んだ時に
読んだ時だったか読んだ後だったかあんま覚えてないんですけど
ちょうどYouTubeで
どのチャンネルだっけな
スクラム東京のチャンネルのYouTubeで
ティーワダさんの講演をちょうど見てて
その中でティーワダさんがおっしゃってた
認知的不細の話が出てきてたんですけど
割とこの理解を手放しちゃうと
いわゆる認知的不細がたまっていくっていうところに
近しい文脈があるんだろうなって思って
読んでましたね
なるほど
同じような課題を抱えているってことですよね
です
そこでおっしゃられてたのが
今までの不細って言われると
大体僕らのところで言うと
技術不細がたまってるたまってないみたいな話があったと思うんですけど
目に見える技術不細に対して
認知不細って現時点だとあんまり計測方法がないよねっていう話が出てて
まさにその通りだなっていう
その通りですね
認知不細というのは
このブログで言われている
理解してないのと同じ意味ですかね
だと僕は解釈してますね
なるほどね
やっぱたどり着くところは今みんな同じなんですね
そう同じになっている
その認知不細が蓄積されていくと
言ってしまうと後からじわじわボディーブローのように
スピードに影響が出てくるっていうところが大きかったりするから
やっぱり認知不細をなるべく減らすように取り組んでいこうねっていうのが
結構T和田さんの講演の中でも出てましたね
なるほどね
そう
っていうのがあると
割と昨今またペアワークであったりモブワークであったりとか
回帰している組織も増えているのかなっていう印象がある
そうですね
なんかモブワークのメンバーの
モブの一人としてAIを加えるとか
ドライバーをAIにさせるとか
そういう雰囲気での組み込み方が多いような気がしています
なんとなく
ですね
モブの一人として組み込んで
最後の対話によって固まったアイディアを言語化して
それを形にするのは完全にAIに任せている感じはしますよね
しますね
作業が全然自分たちでやらなくてよくなったから
いや面白いですよね
今またモブワークが注目されているというのが
そうですね
多分ねもともとモブワーク自体は僕は結構推奨派で
なんならみんなずっとやってたいぐらいの気持ちなんですけど
とはいえやっぱそのフロー効率だけじゃなくて
リソース効率を重視しなきゃいけないであったりとか
なんだかんだ開発に時間がかかるから
上流工程にいっぱい時間をかけられないよねみたいな話ってあると思っていたんですけど
それがやっぱこうAIが出てきてくれたことで
開発側のスピード感アップっていうのはかなり見込めているから
ようやくその形をやってもちゃんと回るんじゃないかみたいな状態が
できてきたんじゃないかっていう期待はありますよね
そうですね自分はそこの状態に実際仕事になったことがないんでわかんないですけど
チームでの共通理解とAI時代の課題
なんかそのよく聞く話だとよく聞くというかよく見る話だと
その一人で複数のエージェントを使って複数の開発並列にして開発してるみたいな人が
なんか多そうな気がしていて
それ一人でやるのなんか限界こないんかなみたいな感じがしているんですよね
だからちょっと前で言うと全員マネージャーみたいな感じになって
指示を出しまくるみたいな感じになるわけじゃないですか
なんかその状態が辛そうだから
それこそ二人で話し合いながら人間二人で話し合いながら
複数進めていく方が楽ではとか確実な選択ができそうって
ですですなんかめっちゃ僕は僕もそっちですね
人間一人と複数エージェントは無理ではって思っちゃうんだけど
みんなできてるんですかね
突き進む分にはいけるとは思うんですけど
将来的な運用とかを見据えたことを考えると結構無理ではって思っている
疲労の強度も強いけど今三沢さんが言った運用っていうのはどういう意味ですか
たぶん一人でアイディアとかを進めていくってなった時に
走り出すのはめちゃめちゃ早くなってると思うんですけど
たぶんその自分たちが出していったアイディアの先って
うまくいった後って必ず継続させるためのメンテナンスっていうのが来ると思うんですよ
そのメンテナンスをするってなった時に
発案から実行まで全部一人でやった時って
本当にあなた全部できるんですかって僕は思って
そうですよね完全に今回の理解の話もあるし
そうそうそう
一人じゃ難しいだろうからな
チームで合わせるっていうのもありましたよねどこだったっけ
どの抽象度で握るかチームでも揃えるっていう説が
たぶんまさにそこが大事だと思っていて
チーム全員がとか個人全員が
コードの一行一文字まで全部把握してねって話ではないじゃないですか
このブログ自体も
たぶんそこの抽象度は揃えて
チーム全員の共通理解の抽象度はここで
さらに深掘って理解しとくのはこの人たちなんですぐらいの分け方はした方がいいと思うんですよね
そうですねそれがそして全員認識が取れていて
いないと摩擦が起きますからね
なんでこれが分かってないのに変更を出してくるんだとか
リリースしちゃったんだみたいな話になるから
そこの認識を合わせとかないとですね
ですねめっちゃそう
全然関係ないんですけど
今って変更失敗率みたいなのみんな上がってないんですかね
AIのあれになって
なんだっけ去年のドーラレポートだと上がってましたよね
あってしたっけ
上がってたけど
あれはどういうふうに再計測とかしてるんだろう
結局その失敗率が上がったとして
じゃあその失敗の影響がどれくらいあったかとかのデータってないですもんね
そうですね
あとあれかこの理解が
っていう話でいくとそっから
どこが問題でみたいな原因を突き止めて直すまでの
MTTRが長くなりそうな気はしますね
それなんか確かTワザさんおっしゃってましたよね
長くなってるって話ですか
なってるって話をしてた気がする
結局障害が起こった後に初めて認知不可があったんだな
認知不採があったんだなっていうのを認知するから
そっからの調査でまた時間かかるよねみたいな話があるみたいですね
分かってないとそうなりますね
でも単純に今思ったところだと
そこもAIに任せてしまうんじゃないですかね
どうなるんだろう
まさにおっしゃる通りそこもAIに任せるんだが
結局そのLLMに任せてても
暗黙値的なところって
例えば落とし込めてないって一定数あると思っていて
そこが漏れちゃうから
結局その暗黙値を把握してないとダメだから
AIに任せてもそこの爆速の改善ってあんま進まないよねっていう感じでした
なるほど暗黙値はホワイの部分とかが多いのかな
のかもしれないしあとはちょっとわからないけど
いわゆる叩きまではざっとAIで作って
その後の微修正はちょっと暗黙的に人がやったとか
運用ルールとしてふわっと決まったとかがあるんじゃないですか
そうかじゃあやっぱ自分がやってるみたいに
コード変更してダメなんだな人間が
確かに作り直させた瞬間消えちゃいますもんね
そうだそうだLLMはそんな変更してないんだけどって思っちゃうわけだ
どっかで見たのはコード変更するんじゃなくて
あくまで仕様側のプロンプトに渡す情報の大元を変更して
そこからAIに書き直させるみたいなことをやってるチームとかは見ましたね
確かになたまに見るのが
プロンプトの方を保存しておいてほしいみたいなのを見る気がするよく
なので結構確かに言われてみると僕もコードレビューとかするときに
結局これどんなプロンプト書いて出してきたのっていうのをよく聞いてるかもしれない
そうなんだなるほど
っていうところで
多分いろんなところの組織で今ちゃんとやっぱり解しないとダメだよねーが返ってきてる感じ
ちょっと揺り戻しになってるんですかね
なってる気がする
やっぱり理解できる本数を並べるぐらいが
今も昔もいいよねっていうのが再確認できた感じがしますね
ちょうどいい数も一旦行き過ぎてみないと分からないですからね
というところでちょっとしまった感じもしたので
今日はこれぐらいにしますか
しておきましょう
そしたら今日はなんだろうこれ
理解を手放さないの記事についてお話をしました
ユルテクでは感想や話してほしいことなどを募集しています
Xでハッシュユルテクをつけて投稿するか Mixi2のコミュニティまでお願いします
今日はありがとうございました
ありがとうございました