00:00
繰上さん、ちょっと聞いてほしいんですけど、ソフトウェアの設計って普通に難しくないですかね?
いい設計とか悪い設計とかっていろいろあるかなとは思うんですけど、大体、僕が設計を決めるときって、今回はMVVMでやってみようかなとか、またクリーンアーキテクチャでやってみようかなとか、
結構流行りしたりで右往左往しているような自覚が個人的にあるんですよね。その設計を決めるにあたっての指針とかってあったりするんですかね?
いいですね。MVVMとか今ちょうど出てきましたけど、あとMVCとかいろいろありますよね。クリーンアーキテクチャとかいろいろあって、これって実は設計というよりかは流派みたいなもので、
あんまり知られてないのは、どの流派でも実は結構うまくやれるってところなんですよね。それは新しい流派とか古い流派とか抜きにしてです。
例えばクリーンアーキテクチャとか新しい流派だと思うんですけど、そのクリーンアーキテクチャでもうまくいけるし、古い流派であるMVCでもうまくいくことができる。
そういう意味では流派って実はどうでもよくて、一番大事なのはその流派の上にどうやって自分たちにあった城を建てていくかってところなんですよね。
なるほど。流派っていう考え方なんですね。空手だったりとかいろんな流派って呼ばれるものはいっぱいあるかなと思うんですけど、それみたいなものでMVVMとかMVCとかクリーンアーキテクチャも
根底にあるものは全部一緒だよね。ただその表現方法とかがちょっと違うだけだよねみたいな形なんですかね。
そうですね。設計っていうのは何か大きな仕様、こういうふうに振る舞ってほしいなってざっくりとしたビジョンみたいなのがみんなあって、そのビジョンをどういうふうなパーツを寄せ集めて作ることができるか。
その分割なんですよね。その分割は例えばMVMとかMVCで共通しているモデルっていうものを切り出してあげて、
あとはビューの部分はVMしたりとかビューって分けたりコントローラーって分けたりとかいろんな流派があるんですけど、大雑把にはこれをどうやって分けていくかっていう部分なんですよね。
なんですけど実際そこをじゃあこれはモデルねとかこれはビューねとかって分けたとして、そのモデルがじゃあ一つのモデルだけがあってビューがいっぱいあってみたいなこういうアンバランスなやつとかを作っちゃうと結局大変なことになるんですよね。
これはMVVMでもMVCでも同じです。ファットモデルって言われてるんですけど、大きなモデル、一塊のモデルを作ってしまうと大変になる。だから結局一番大事なのはこのモデルをどうやって分割していくのかとか、あるいはビューを分割していくのかってそういうところが実は一番大事なんですね。
そういう意味で流派は割とどうでもいい。なんだけどそれをどうその定められた流派の中でうまく細かくいい分割をしていくかっていうのが大事なんです。
確かにその話を聞いてからMVVMとかMVCとかクリーンアーキテクチャーとかを見直してみると、確かにどう分割しているかのみが結構関心事かなと思います。クリーンアーキテクチャーも詰まるところをどう分割してどうやって層を作っていくかみたいな話なのかなというのは、すごい抽象度高く言うとそういうものなのかなと思ってきましたね、確かに。
そうですね。クリーンアーキテクチャーは他のMVVMとかMVCとはちょっと違っていて、あれはこういう原則を大事にしましょうっていう流派の教えみたいな集まりなんですよね。
03:07
これはなかなか面白くて、クリーンアーキテクチャーってよくヘキゴスってあるじゃないですか、クリーンアーキテクチャーの玉ねぎみたいなやつが、あれがみんなザークリーンアーキテクチャーって思ってる人がいるんですけど、それは実は本をよく読んでみると違っていて、あれはあくまでクリーンアーキテクチャーを実現する例の一つなんですよ。
そういう意味で、クリーンアーキテクチャーはこれこれ、設計っていうのはこういういくつかの原則っていうのを満たすと、すごくあなたに合ったいい設計学に入るよね、それはこういう原則だよっていうことを言ってるに過ぎないっていうのが実は説明されているところです。
なるほど。じゃあクリーンアーキテクチャーという仕様があって、その実装は委ねられているってことですね。
そうですね。
その実装例が玉ねぎアーキテクチャーというか図みたいなものなんですね、単純に。
なので実はここにちょっと面白いことがあって、MVCのクリーンアーキテクチャーとか作れます。
入れ子構造というかガッチャンコすることもできちゃう。
できると。原則を守っているMVCだったらクリーンアーキテクチャーなわけですからね。
そこはあんまりよく知られていないわけですね。
確かになんか設計っていうと、例えばなんか1個を選択すると、その1個に従わないといけないのかなと思っちゃうんですよね。
例えばクリーンアーキテクチャーだったら、あれなんですかね。
もしかしたら本が分厚いから、あの本で全てできるんじゃないかみたいな、なんとなくの考えが出てきちゃうかなと思うんですけど、
他のやつと組み合わせて、それが最適だったらいいよねっていうような話なんですね。
そうですね。あの本を書いたのはボブおじって呼ばれてる人なんですけど、ボブおじさん。
ボブおじさんは説明がちょっと悪くないというか、なかなか言いたいことに対して文が長くなってしまうところが結構あってですね。
そこら辺がちょっと読みづらいところではありますね。
なので、おすすめなのはクリーンアーキテクチャーの言ってることはすごくいいこと言ってるんですよ。
本当にすごくいいこと言っていて、設計はこれこれこういうことを例えば層上にしないとダメだよねとか、いいこと言ってるんですけど、
そのクリーンアーキテクチャーの教えに従っている、なんて言ったらいいんでしょう、従って自分の設計を見つけていくっていうのがすごく大事なんですね。
ただ、みんなこれを結構クリーンアーキテクチャーやってますって人もできてないことが多い。
それはなぜかっていうと、自分の設計に自信がないことが多いんですよ。
だから誰かの設計、誰かが考えた設計に乗っていれば、まあ多分大丈夫だろうと思いたい。
だいたいそうだと思いますね。
クリーンアーキテクチャーでうまくいっているではなくて、クリーンアーキテクチャーを使っているからうまくいっているであろうなんですよね、考え方的に。
で、すごく大事なのは、これファクトとしてあることなんですが、設計っていうのはそこに解きたい問題、
つまり例えばどういうふうにしてお金を稼ぐかとか、どういうふうなお客様を集めるかとかって解きたい問題があって、
06:03
この問題によって設計は変わるし、何ならそれを作っているハウのメンバーの人たち、
ハウの人たちですね、エンジニアどういうエンジニアがいるか、どういう仕様を考える人がいるかとか、
そういうふうな人によっても変わってくるっていうのがあって、つまり実は推しきせずやるってことはなかなか難しいんですよ。
本当は自分たちにうまく合わせた、あったものっていうのを見つけなきゃいけないんだけれども、
みんな自信がないから見つけられるとは思ってなくて、誰かの正解に従いたくなるっていうふうなことになっちゃってるんですよね。
乗っかりたいっていう感じですね、やっぱし。そこのうまくやれてるんじゃないかな、だったりとか、
その自信の部分なんですけど、どうやったら、というかどういう状態になってたらうまくやれてる、自信があるっていうような状況になるんですかね。
何か定義とかってあったりします?国明さんの中で。
はい、自信を持つためには大雑把に分けると2つ大事なことがあると思っています。
1つはたくさんチャレンジすること。それは設計をこうしてみる。よし、これでやってみるぞってやって、設計っていうのは未来の生き物だっていうのは前回とかに言ったと思うんですけど、
未来になってみてこの設計無駄だったなとか、この設計めっちゃハマったなというのが分かる。正解、答えは未来にできるんですね。
その未来に対して実際に到達してみると、うまくいったかな、うまくいってないかなっていうのがざっくりと分かることができると。
なので、そのうまくいったかな、うまくいってないかなっていう見分けられる嗅覚をつけること。これがすごく大事ですね。
もう1つはたくさんチャレンジすること。この嗅覚っていうのはすごく優れた嗅覚を持っていっても1回、2回試すだけだとやっぱりなかなかいい設計にたどり着くことできないっていうのがあって、
なので何回も何回も小さなプロジェクトで試すことでこの嗅覚っていうのを磨き上げていく。その2つっていうのが私はすごく大事なことだと思っています。
嗅覚があることがそもそも重要だし、その嗅覚を鍛え上げていくことも重要っていうことですね。
そのためにはもういろんな、いろんなというかいっぱいチャレンジしていっぱい失敗して、こうしたらこのアーキテクチャというか、自分にとっては合ってないんだなみたいないうところをどんどん見極めていくっていうところがかなり重要っていうところなんですね。
慣れた熟練してくると、こういうシチュエーションだったらこういう設計がはまるなみたいなのはだんだん感覚で分かるようになってくるんですけど、これも確かに嗅覚の1つなんですけど、
これができるようになるためには本当にその人がたくさんたくさん失敗をしてるんですよ。あの時ちょっとあれやっちゃったなとかっていうのがやっぱり記憶の片隅にあって、それを引き出しから引っ張ってきて、だから今回はこうするっていうふうにやって、また新しいチャレンジをするんですね。
そうやってどんどんどんどん嗅覚に従って設計が導かれていく、ガイドされていくっていうのが、私がぜひ皆さんに体験してほしいものになっています。
国明さん、結構そこらへんもいろんなチャレンジしていっぱい失敗して、こここういうのちょっと失敗したなみたいなの、なんか一例あったりします?パッと出てくるもので。
ありますね。私は個人のリポジトリリストが確か2、300あるんですね。2、300件素振りしました、その意味だと。で、その素振りっていうのはすごくちっちゃなプロジェクトだからできることなんですよ。
09:07
一つのデカいプロジェクトでドーンとかってやっちゃうと、素振りつっても1回の素振りをなんかこうすごくゆっくりやるみたいな感じになっちゃって、あんまり学習効果ないんですよね。
だから小さいプロジェクトで運命を共にする、未来を見届けるみたいなことができる小さなプロジェクトをたくさん経験するってことがすごく重要です。
なんか一例あったりします?ここでこのアーキテクチャ設計してみたんだけど、ちょっと失敗したなみたいな具体的な例。
なるほど。失敗したな、なるほど。上手くいった例はすぐ思いつくんですけど、失敗したっていうのはなかなか難しいですね。
例えば、私は最近よく語言語を書いてるんですけど、語言語で設計を、設計って変えたい部分だけ取り替えられるようにすることが大事だってこと。
これは第3回だか第2回だかにいったと思うんですね。それでその変えられる箇所っていうのを作っておくってことが大事なんですけど、
語言語だとその変えられるようにする、プラガブリにするやり方っていくつかあって、一番代表的なのはみんな先に思うかと思うのはインターフェースですね。
インターフェースを思い浮かべる。Javaとかのインターフェースみたいなものでもいいんですけど、あれを思い浮かべると、そうそう、こういうメソッドがあってみたいな。
私最初はインターフェースをバリバリ使ってたんですよ。バリバリ使ってたら、なんかMockしづらいなってことに気がついてテスト書いてるうちに、なんかちょっとMockするときにこのメソッド別にいらないんだけど、
実装しなきゃいけなくなって、中身のないメソッドを実装するみたいなのが増えてくるみたいになって、なんかおかしいってなっていって、
それで、なんかそれが私の滑りに引っかかってたでしょ、ビンビンに引っかかっていて、なんかやっぱり変えたほうがいいんだろうなって思って、それから変えてって、最終的に今行き着いたのはインターフェース一切使ってないんですよ。
何してるかっていうと、関数をオブジェクトとして渡すっていうそれだけ。
そうすると、Mockとかって概念がなくなって、関数適当なの渡せば動いてくれる。
これ、実はGoの中でもよく使われているプラクティスで、なんとかFuncとかっていうのが結構入ってたりしますよね、いろんなところに。
例えばSortとかでSortFunc渡すのもその一つですし、その並び替えを定義するやつをインターフェースみたいな実装するっていうのが、昔邪魔とかだったらやったと思うんですけど、
で、関数渡すだけでいけるようにする。その関数だけにすればMockとかがすごく簡単になるので、こっちのほうが正解なんだって気づいて書いていった例になると思います。
なるほど。やっぱし、そこの今の例を見るにも、テストが書きやすい、書きづらくなってきたから、ちょっとここおかしいんじゃないかっていうところで気づいて、
違う方法に、違う設計方法にちょっと走っていって、これだったらちょっとハマりそうだなっていうのが早めに気づけたみたいなのがあるんですかね。
そうですね。
ちっちゃいプロジェクトで。
そうですね。ここで皆さん多分疑問に思うと思うんですよ。なんでテストコードなんだ、テストコードで気づくんだっていうところが皆さん気になるんじゃないかなと思っていて、
12:05
それは実はすごく理由がちゃんとしてあるんですね。なぜかというと、プロダクトのコードってどんなにコードが入り組んでいても、
例えばすごく長大な処理の中に自分の解体処理が埋もれていても、準備とかって必要ないじゃないですか。もうそこに流れてくるまでにもう準備は整ってしまう。
だから新たに準備とかを用意する必要がなくなっているんだけど、だけど例えばテストとかになってくるとその長大な準備をテスト側で一から準備しなきゃいけなくなっちゃうんですよね。
そうなっちゃうと、これめちゃくちゃ準備必要ですげえ大変だぞとかってことに気づくわけですよ。
そういう意味では隔離されてフレッシュな環境にしたときにどれだけ使いやすいかっていうのが露骨に明らかになるのがテストなんですね。
そういう意味で準備とかも含めたその使いやすさっていうのが一番はっきり言われるのがテストコードだと。
なのでテストコードを書いているとなんかおかしいなって私はそこに耳をすごく澄ませているってことなんですね。
なるほど。そのプロダクションというか、本番実行するコードの方では色々なメインから呼ばれてみたいないうものが全て通った状態でそこの関数に来て、
別に準備することなくそこが実行されるから特に不便はないんだけども、テストの場合はいろんなセットアップの処理とかを書かないといけないが故に、
そのセットアップの処理が面倒くさかったらちょっとおかしいでしょというようなところに行き着くっていうところがテストの良い点というか、
分かりやすく変なところが明らかになるみたいなところなんですかね。
そうですね。例えば例を少し考えてみましょう。あるユーザーに対して例えば年齢確認みたいなのをするようなのを考えてあげましょう。
そうするとユーザーっていうのが多分その本番コードだとデータベースの中に入っていて、
それがもしORマッパーとか使ってるんだったらユーザーファインドバイみたいなとかってやったりして見つけてきますよね。
別にORマッパー使わなくてもケリビルダーから書いてきたものそのまま組み立ててみたいので別にどっちでもいいんですけど、
そうやって組み立てるとユーザーオブジェクトができて、そのユーザーオブジェクトが今手元にある状態でこの関数を読み出すみたいなのが本番コードですよね。
これはすごく準備が簡単。もうすでにユーザーオブジェクトが手元にあるというわけですけど、
テストコードとさてどうやってこのユーザーオブジェクトを用意するかなるわけですよね。
ここでやっぱりすっごく長大な処理とかを使ってこのユーザーオブジェクトを作らなきゃいけない。
例えばユーザービルダー、ユーザーアブストラクトファクトリーを使ってユーザーのなんかを作ってみたいとか言い始めたらめちゃくちゃ大変なわけですよ。
だからユーザーの例えばJSONみたいなので表現できるすごくちっちゃなオブジェクトを作ってあげて、
これをユーザーだということにするっていうふうにしたほうがはるかに簡単なわけですよね。
そのほうが実際なかとしても使い分けしやすいわけですよ。
なぜかといえばDBから拾ってこようか、JSONファイルから要望が通信から取ってこようか、
全部ちっちゃなオブジェクトに変換してあげる処理を書いてあげればどれでも使える、プラガブルになるってことなんですね。
なのでこういうふうなちっちゃなオブジェクトにしてあげるっていうのは、
例えばテストをやってみると気づく、こっちのほうが良かったんだなっていうものになりますね。
15:02
本当に今の話、1個層を挟むみたいな話でクリーンアーキテクチャ的な思想も入ってるのかなと思ったんですけど、
腐敗層ではないかもしれないんですけど、変換層を絶対に挟んで簡単なオブジェクトにした後、
関数に渡してそれを引き連れ回すみたいないうのは、かなりいろんな設計思想の中に出てくるところなのかなと思ったんですけど、
それが当てはまりそうだよねっていうような一例なんですかね。
そうですね。実際このテストコードに耳をすませて、なんかこれ書きづらいなとかっていうことを自然と直していくと、
で、それの後にクリーンアーキテクチャを読み直すと、あ、わかる、ボブ王子の言ってたことわかるなんですよ。
なるほど。
実はこれも理由があって、このボブ王子って実は結構テスト界隈の人なんですね。
テスト界隈ですごく有名な人で、すごく良いテスト書くためにはこうだよとかってテストの良い予算の原則とかを唱えてたりする人だったりするので、
すでに自分たちはボブ王子の通った道を通ってるのと同じなんですね。
なるほど。
これ私、なかなか難しいなって思うのは、ボブ王子の書いた本をやってもその道をショートカットできないんですよ。
だから、なかなか自分ごと化しづらいっていうか、一回体験しないと腹落ちしないよねっていう、当たり前の話かなと思うんですけどね。
そうですね。あとは純粋にボブ王子の説明がちょっとうーんってところもやっぱりあって。
それはある。
ありますね。なのでやっぱり自分で体験して自分の嗅覚を信じて育てることがすごく大事だと思っています。
じゃあもうとにかく設計に自信を持ちたい、もしくはちゃんとできているっていう自覚を持つためにはいろんなチャレンジしてみて、いろいろ失敗してみるっていうのが一番大事っていうところですね。
それはもうあれですね。じゃあ本番のお仕事としてプロダクションでも動いているようなサービスで試すというよりかは、個人プロジェクトでいろいろボコボコやってみた方がいいよねっていうところなんですかね。
そうです。ただ個人プロジェクトは確かにいいのは一つなんですけど、その時間が取れないこともよくあると思うので、そういう時は仕事で使う少し小さなツールを仕事で使うのを作ってみるとかっていうのも手ですね。
確かに。そういったところでちょっと実験的にやってみるっていうのは確かにそうですね。業務時間中にやってても怒られないっていう点でもそうですね。
私は実際今、昨年の9月に入社してから10個20個ぐらいはツールはもうすでに作りましたね。
すごい。
素振りしている回数がそれぐらいあるってことはやっぱりなかなか大事なことなんだろうと思っています。
その中でも結構アーキテクチャとか設計変えてたりするんですか。その10個20個ぐらいの小さいツールの中でも。
これはですねもうだいぶ固まってきちゃいましたね。私の場合は。ただやっぱり変えた部分もあります。
例えば9月とかから今にかけて変わったことっていうのはコーディングエージェントにだいぶ任せられるようになってきたっていうのが大きな変化だなと思っていて、
18:07
なのでコーディングエージェントが見つけやすいようにとか、あるいは実装しやすいようにとかテストしやすいようにっていうことを意識して設計するようになったっていうのは間違いなくありますね。
いや、でかいですね。そこの観点は確実に。
今後の設計のあり方みたいなところで、今までの設計とAIコーディングエージェントが読みやすいというか、多分追加しやすい、編集しやすい、運用しやすいみたいな設計ってちょっとずつ変わってくるかなと。
個人的には思っていて。そこら辺で何か設計の話あったりしますか。
そうですね。一つ私が思っていることがあって、何も真っさらな状態で何か設計してっていうふうにやると、大抵コーディングエージェントの設計って悲惨なんですよ。
二つあるんですね。一つはあんまり質のいい情報を学んでこなかっただろうっていうことが一つ。
これはなぜかというと、いっぱいいろんなリポジトリとかを先生が学習してきてると思うんですけど、やっぱり当たりもあれば外れもあるみたいな。
いいものばっかり集めて学習できてるわけじゃないっていうのがあるんですよね。
なので、いい設計も悪い設計も両方止めてきたから、何かその辺りの平均的なとこでやっとこうぜって感じになると、あんまりよく。
なるほど。重みがつけられてないってことですね。いい設計に対して。
これはたぶん将来的には教科学習とかによってある程度克服される部分ではあると思うんですけど、一旦は先生が覚えてる教材があんまり良くないだったっていうのがたぶん一つあるのと。
あともう一つは、設計は未来の生き物だって私ずっと繰り返して言ってるんですけど、未来に関する情報を教えてあげないとダメなんですよね。
なるほど。
だから例えばこのツール、たぶん将来的にこういうことすると思うから準備しといてっていう、そういう情報がたくさんたくさん必要なんですよ。
それによって設計っていうのは、じゃあここに拡張ポイント作っとこうとかって決めていくものなわけですから、将来どういう方向に伸ばしていくかとか、あるいはどういうところを留保しておきたいかとかっていうのをすごく親切に伝えてあげなきゃいけないんですね。
これは今まで人間には、自分で書いてる分には脳内にあって、たぶんこうしておけばいいかなっていうので、書かなくてよかったものなんですけど、これからはこれをちゃんと書いて、それもコーディングエージェントからアクセスしやすい場所に効率的に配置するっていうそのスキルがすごく大事になってくると思っていて、
なので設計の言語化力っていうのと、それをコーディングエージェントに合った場所にちゃんと置いて、そのシステムを利用していくっていう、この2つが結構重要になってくるんだろうと思ってますね。
いや確かにそうですね、今までだったら自分が書いていく中で今言ってもらった通り、その頭の中になんとなくあるから、じゃあそんな感じでここら辺ではこんな感じにしとこうみたいな形ができたけど、
AIエージェントにお願いすると、単純にエンジニアが部下みたいな形で増えるって考えると、ちゃんと未来のことにコンテキストとして渡してあげないと正しい設計なんてできないよねっていうお話ですよね。
21:09
もう自分自身がたぶんエンジニアじゃなくてマネージャーみたいなお話だと思うので。
その通りですね。何でかっていうと、私はずっと拡張ポイントって話をしていて、設計である一部分だけ変えたいときはちょっとおかしい、その一部分がコリッとコンポーネントとして区切らされてると一番きれいにはまるんだ。
この拡張ポイントっていう話ってやっぱり設計においてはすごく大事で、生成AIに何も伝えずに作らせると拡張ポイント一切ないんですよ。
メイン端数にベタ書きみたいな感じ、プライベート端数めっちゃ使いまくりみたいな感じで作ってくるんですよね。
それはやっぱり未来の情報を与えてないからっていうのもすごく大きくて、将来こういうふうに使っていく、こういうオプションが増えていく、たぶんこういう座が増えてくる、
そういう情報を与えてくると、ここに拡張ポイント作った方がいいねってことで結構生成AIちゃんと見つけてくれるんで、やっぱり未来の情報を渡すってことがすごく大事だなと思いますね。
重要ですね。ちなみにその時に今まで作ってきた10個ぐらいの社内ツールですかね、ちっちゃいツールで、どうやってこう未来の情報を渡してたりします?
普通にプロンプトとして渡すのか、それともなんかいろんな今だったらやり方あるのかと思って、マークダウンで渡してあげるだったりとか、いろいろあるかなと思うんですけど、どうしますか?
そうですね、私はよくtoodle.mdっていうファイルを作ることが多くて、ここに未来はこういうふうに変わっていくよっていうのを書いていくと、何となく読んでくれるんですよね。
拡張されるよとかっていうふうなところがわかってくるんで、それを渡すようなことをよくやりますね。
で、あともう一個なのが、さっき設計を留保したい時があるっていう話をしたと思います。これ一体どういうことかっていうと、ここに拡張ポイント必要かな、わかんねえなっていう時あるわけですよ。
この時に選択肢は三つあって、一つは拡張ポイント作っちゃう。これはつまり拡張されるって方法にかけるってことですね。
で、もう一つは拡張ポイント作らない。これは拡張されないに変えるってことですね。で、もう一個は、これはちょっと拡張ポイント、後で1キロ足すだけで拡張ポイントできるんだけど、その時はまだ拡張ポイントじゃないみたいにしとくっていう留保っていう。
実は設計ではすごく留保が大事なんですね。これは誰が言ってたんだったっけな、誰が言ってたのかちょっと覚えてないんですけど、アーキテクトっていうの、この設計のプロアーキテクトっていう人たちは、とにかく意思決定を先延ばしにした、先延ばしにするべきだってよく言うんですよ。
これはなぜかっていうと、ちょっと意思決定っていうのがどういうふうに行われるかを考えてみるとわかりやすいんですね。意思決定ってその場にある情報を集めて、こっちのほうが得かなと思って選ぶっていうのが意思決定になってくるわけですけど、時間が経つにつれて手に入る情報って増えてくっていうのはやっぱりわかりますよね。
例えばビジネスサービスがローンチ当初はどんなお客さん来るんだろうっていうのが全然わかんない状態からスタートするわけですけど、やっぱりそれで1ヶ月とか1年とかかかってみると、こういうお客さんたち集まったんだ。つまりこういうふうにサービス伸びていくなっていうようなことがわかってくるわけですよ。
24:07
これはサービスのローンチその直後はどういう機能追加をしておこうかっていうことはほぼバクチー。すごく部の悪いバクチーみたいなのをするってなるんだけど、1年後とかになると部のいいバクチーをすることができるようになるってことですね。だから設計を遅延させたいんです。設計って選択を遅延させたい。
なので、情報がよりあるときにその拡張ポイントやっぱりいらんかったとかという決断ができるようになるべく流法するってことがすごく設計では大事ですね。
それはどっちに転んでもいいようにするですよね。そういうことです。考え方として。どっちに転んでもいいような設計をその時意思決定したということですよね。流法っていうのは。
この流法の上ですごく大事になるかな。AI、生成AIとの付き合い方で大事になってくるかなと思うのは、やっぱり自分でこう流法しておきたいなってなかなか意識できないことが多くて、なんかここに拡張ポイントあった方がいいと思うってことは人間がパッと説明できるんだけど、ここでちょっとわかんねえなとかっていうところには大体気づかないんですよ。
わかんないですね。なんかもう作っちゃった方が良くないって思っちゃいますね。そうそう。なので、そういうときにちょっと機械的にある程度は使える方法としてテスト駆動開発っていう方法があるんですね。
テスト駆動開発っていうのは、なんでこんなところでテストがまた出てくるのかって話になると思うんですけど、テスト駆動開発っていうのは結構誤解されがちなのは、なんか品質を高めるためにテスト駆動開発するんだって思ってる人たちが結構たくさんいるんですけど、
テスト駆動開発は品質を高めるというよりかは設計を良くするって方が大事なんですね。ちゃんと順序立てて説明していくんですけど、テスト駆動開発の一番大事なプラクティスは何かっていうとテストを先に書くこと。テストファーストって言われてるやつですね。
なんで先にテスト書くのって言うと、これはさっき言った設計の話なんですよ。先にテスト書くとテストしにくい設計になっちゃうからなんですよね。だからテストが先に書かれていて、そのテストが先に書けるってことは長大な文句とかをしないっていう選択をしてるってことですよね。
なので、例えばユーザーの年齢制限するってことはユーザーの年齢だけ入ってきたらいいやみたいな選択をするわけですよ。そうするとユーザーの年齢だけ取ってくるメソッドみたいなのが必要になってきて、それを本番にはそういうメソッド必要だったろうねってわかる。そういう流れで設計を見ていくっていうのがテスト駆動開発のやり方なんですね。
で、そうすると自然と疎結合で小さいパーツでっていうものが温暖増えてくるんですよ。それって拡張ポイントが実は結構至るところにあるっていうふうにも言い換えることができていて、パブリックな関数はどこでも再利用ができるし、で、ただの関数呼び出しとかったらそこの呼び出す関数ちょっと変えてあげればもういいしっていうふうになって、なかなか実は結構うまく留歩したい部分とかっていうのがうまくいくようになるんですよね。
過読性も低くならずすごくうまくいくって方法で。なのでテスト駆動開発っていうのはすごく設計に効く。これは実は私AIにやらせてみるとすごく違いを感じるんですよね。テスト駆動開発をAIにやらせたバージョンとAIにやらせなかったバージョンっていうのをやってみると、つまりAIにやらせなかったってことは後からテストを書かせたバージョンと先にテストを書かせたバージョンで比べてみると圧倒的に先にテストを書かせた方が質がいいんですよ。
27:22
その設計という意味でですかね。
設計っていう意味で。なんでかっていうと後からテストをやろうとするとMockとかでテストをなんとかしちゃおうとするんですよ、設計AIを。
もうあるやつをなんとか通そうとするってことですよね。ご利用しでもいいからみたいな。
設計を変えるっていう方向にやっぱり設計AIもバイアスがかからないみたいで。なので設計が悪いんだっていうふうにやっぱりスタイルテクニックにはテスト駆動開発がすごく優れている設計手法だなと思いますね。
なるほど。じゃあ先にテストをAIでも自分にしろ作ってしまって、そこから設計をどうしていくのかというか、テストが書きやすい設計がどうなのかなというのを見ていくっていうのが一番現状においても良さそうという。
このテスト駆動開発にはAIについてはいろいろな逸話というかあって、ティーバダさんっていう有名なテスト界隈の人がいろいろとティーバダメソッドに従ってTDDをやれみたいなプロンプトが一時期流行りましたよね。
ありましたね。
これは何を意味しているのかというと、TDDっていう言葉がオリジナルの意味から離れて、いろいろとテストファーストだけやってればTDDだろうみたいな感じになっちゃったりとかしちゃっていて、だいぶその知識が劣化したところがあるんですね。
なるほど。ちょっと広い意味で取られすぎているっていうことですね。
なので、この知識をなるべく当初提唱されたものを戻すっていうふうな意味でTワーダープロンプトとかがやったりとかするんですけど。
私はTワーダープロンプトは使っていなくて、むしろケントベックっていうか、これはテスト駆動開発の提唱者の人なんですけど、このケントベックがGitHubにアカウントを持っていてですね。
ケントベックの書いたことわかるんですよ。ここにケントベックの書いたCloud.mdがあるんですね。私はそれを日本語訳して使っています。
すごいいい持ってき方ですね。確実にテスト駆動開発の創始者の人が使っているものを持ってきて、それを使うっていうのはかなりいいかなと。聞いたことなかったんで結構びっくりだなと思ったんですけど、それ結構いい感じに動くんですか?
そうですね。結構いい感じに動くんですけど、1つ落とし穴というか、私が独自に改良した点が1個だけあって、よくCloudとかCodexとかGeminiとかもそうなんですけど、プライベート関数を作って逃げようとするんですよ。
これTDDの人がすごくよく聞かれるのは、プライベート関数もテストしなきゃいけないんでしょうかみたいな質問をよく受けるんですけど、これ答えはすごくどのTDDの人もこっちを揃えてノーって言うんですね。
プライベート関数にはテストを書くべきじゃないということに甘んじて、プライベート関数にするとテスト書かないんですよ。
30:01
どうやってすり抜けようかっていう感じですね。
だからすぐにプライベート関数にしてきちゃうんで、一文私は足してますね。実装する関数はほとんどパブリックなユーティリティにしろというふうに伝えていて、プライベート関数を作ったら負けだみたいなことを言ってるんですね。
必ずパブリックな関数にし、適切な場所に配置し、テストを必ず書けということを伝えてますね。これをやっぱり加えると加えないとはなかなか違っていて、やっぱりテストコード開発のプライベートメソッドに逃げられちゃう案件はこれでだいぶ減るんですよ。
ただそれでもやっぱり何件かすり抜けてくるんで、これはレビュー基準の方にもう1回書いとくってことは結構大事で、そのAIにもう1回レビューとかさせるじゃないですか。
その時にここの基準でレビューしてっていうところの一番最初にパブリック関数書いてないかこいつとか、プライベート関数書いてないかこいつとかってことがチェックされると。それによってだいぶ担保されている感じですね。
そのMDファイル、GitHubとかで公開されてたりするんですか?
社内だとあるんですけど、多分社会ではまだ公開されてない気がします。
じゃあ公開した後にはどこかで見せていただけると一番いいかなと思いますね。
あとですね、AIというところと技術選択、途中で出てきたたくさん失敗するのが一番重要だよねっていうところで、
AIを使うといろんなちっちゃいプロジェクトとかどんどん試せるのかなと思ってたりして、
あとはそのAI使えば実装がかなり低コストで時間かからずにできると思うので、設計を変えるみたいなこともできるかなと思っていて、
ガラッと変えてみるみたいなこともあるかなと思ってて、そこらへんもたくさん失敗するためにAIエージェントを使っていくっていうのも結構有用性高そうですかね。
私はコーディングエージェントを使うときと使わないときで、その嗅覚の鍛え方っていうのはだいぶ変わってくると思ってるんですね。
実は人間で全部手で書いた方が嗅覚は育ちやすいと思っている。
それはそうですね、そのなんか似たような議論で、AIを使って学習ができているのかどうなのかみたいなの結構あるかなと思ってて、
コーディング、プロダクトを作っていく中でAIを使っていると全然学べてないんじゃないかみたいな、自分の身になってないんじゃないかなみたいな議論あるかなと思うんですけど、それですよね、完全に。
それと似てますね。で、私はちょっと少し似てると濁し方をしたのは、コーディングエージェントっていうのは、何であんなに流行ってるかって言ったらめんどくさくいいこと全部やってくれるからですよね。
だけど、設計の進めるって大抵はめんどくささからくるんですよ。これ目覚めんどくせーわーとか、この準備めんどくせーわーとか、ここからくる。
で、これ書かなきゃいけないのをどうにかして書かないように済ませられない、それが嗅覚を育てる原動力。
だけどコーディングエージェント使っちゃうと、もう彼らご了承してくるじゃないですか。で、なんか寝てる間にできたみたいな感じになっちゃって、全然嗅覚が育たなくなっちゃうんですよね。
33:04
意識決定してないってことですよね。
我々AIエージェントを使ってるユーザーが意識決定をせずに設計を決めてくれていて、なんかご了承していい感じにしてくれてしまってるから、学べないっていうところが結構ありそうですね。
そうなんですよ。それは結構学ぶのが難しいなって思うのがやっぱりあって、例えばクロードとかにはインサイトコマンドっていうのがあって、最近のクロードとの対話はこんな感じだったよ、あなたはここを改善したほうがいいねとかっていうのを出してくれるんですよ。
そういうのがあるんですね。
ヘントクさん使ってみたことありますか。
ないです。
私は結構頻繁に1週間に1回は実行してるかなと。
スラッシュインサイトってやつですか。
クロードコード開いてスラッシュインサイトっていうのをやってみると、インサイトがクロードのディレクトリの中にできるんですけど。
便利。
すごく便利なんですけど、ただこれ実は私は設計に関してはあんまり役に立たないなと思っていて、このクロードインサイトはあなたは毎回ここで方向転換させたからこういうことをちゃんとしたプロンプトに書いといた方がいいよってことをアドバイスしてくれるんです。
設計の悪さってそういうところにはなかなか出てこないんですよ。
それってスラッシュインサイトコマンドってただ単にクロードコードをうまく使うためにはこうした方がいいよという提案を多分プロンプトされてるのかなと思うんですけど、その設計のよしよしのためには作られてないよねってことですよね。
そうなんですよね。
っていうのはクロードコードは例えばプランモードとかしたときに人間が拒否したとかってそのイベントの数とかをちゃんと記憶していて、それがプロンプトに入れた方がいいか入れない方がいいかの統計的な根拠になっているんですけど、実際じゃあ設計がまずかったときにどういうところに影響が出てくるのかってことを考えると、
そのプランとかが変な方向のプランを人間が考え始めてるときっていうのがやっぱり危ない兆候だと思っていて、例えばなんか設計がすごくまずいときによく起こることは時間がめちゃくちゃかかるようになるっていうのはまず一つ悪いこととしてありますね。
なぜかというとその拡張ポイントじゃないところに拡張しようとするっていうのことが多発してくるので、テストもものすごく直さなきゃいけないし、設計も本体コードももちろんいっぱい直さなきゃいけないっていうのがあって、単純にその直すのが増えるっていうのがやっぱりあるんですよね。
コーディングエージェントって人間よりは早いけど、でもそれでも100倍とかは早くないっていうのがコーディングエージェントですよね。なので、もろにその遅さって出てくるんですよ。
だけどインサイトの中には遅さっていう指標がないんですね。そこでなかなか気づかない。
あとはそのプランモードしてるときに、よくツイッターとか見てると、お前にプランモードさせてるけど別にプランちゃんと読んでないんだみたいな話し作学を一時期流行ってましたよね。
プラン見てないんだ、プランをユーザーに見させるという心構えをお前に何回やってほしかったのか。私はあれはいかがなものかなって結構思っていて。
36:03
プランモードがむしろ一番その設計の効かせどころっていうところがあって、プランモードって見たときに、私はクロードコードよりもコーデックスのほうがいいと思っていて、プランモードが優れてると思ってて。
なぜかというと、コーデックスにはプランするときのシステムプロンプトの中に最後に暗黙に仮定した事実みたいなのが最後にちょろっと出てくるんですよ。
そこにあれこれって俺の思ってたことじゃないぞとかって結構ちらちら出てくるんですよ。
なるほど、AIが考えてることを暗黙的に決めてしまっていることをそこに書いてくれるんですよね。
書いてくれるんですよ。クロードコードはなかなかそうはしてくれないんですけど。
確かに。
そこを見ると、あれなんかこいつ間違った設計の仮定をしてるぞとかっていうのが結構わかる。
なるほど。
そこが一番設計の効かせどころっていうのがあって、ただそれでもやっぱり手で書くよりかは随分と感覚が鈍ってしまうっていうのはあるので、なかなか難しいですね。
言ってなきゃちょっと、なのでクロードのインサイトに頼らずに設計の計測をする。どういうふうにしたら計測ができるかっていう部分がやっぱりコーディングエージェントと付き合うためにすごく重要なことだと思っていて。
要するにマレジメントってことですね。
そうですね。
ちゃんとどういうふうにしてフィードバックをかけていくかってことなんですけど、捨てなくても今話してきた通り、クロードのインサイトコマンドは設計のフィードバックには役に立たないっていうのがあるので、
やっぱり一番結構大事かなと思うのは、私はテストコードがどれだけ変更が入ったかっていうのを見てるんですよ。
これは前も言ったかもしれないんですけど、テストコードっていうのはうまく設計がいってる時っていうのは、テストコードの純粋な追加だけでまかないんですよ、機能の追加が。変更が。
テストコードが消えるときはもうデッドコードになって、デッドコードって要するにどこからも呼ばれてない本体コードがどこからも呼ばれなくなって入れなくなった。そのついでにテストコードも消しちゃう。その時だけになってるのが一番いい時なんですよね。
なのでそのテストの変更っていうのはどうやって入ってるかってことをGitコマンドとか見るとだんだんわかるじゃないですか。それを追っていくと、何かこれクロードがちょっと変な設計してるなとかっていうのは後追いでわかったりはします。
そういったところを見つつ、どう設計をAIエージェントがしてきたのかみたいなところをちゃんと自分で決めていくっていうところが一番重要。
そうですね。やっぱりハンドルを握ってあげなきゃダメですね。で、なんでハンドルを握らなきゃいけないかの理由の一つは、未来のことを知ってるのはやっぱり人間だけだからなんですよ。
AI知らない人もね。
AI知らない人みたいなことをどうやって育てていきたいかとか、今どんなユーザーいるかとかっていうのはMCPとかで戦わないとわからない。毎回MPCP戦ってたら遅すぎるじゃないですか。
だからやっぱりまだ人間ってのは高速なキャッシュシステムとしてAIに必要なんですよね。
なるほど。なんか今聞いてて思ったのが、マネージャーだったとしても、今後エンジニアが複数エンジニアを束ねるマネージャーみたいな感じになってくるかなと思うんですけど、AIエージェントを束ねた。
39:04
マネージャーだったとしても、今まで通りエンジニアリングのことを知らないという的確な指示って出せないわけじゃないですか。指示だったり教育だったりとかってできないわけじゃないですか。
それと全く一緒だなと、今聞いてて思ってて。正しい設計だったりとか、いい嗅覚を持った設計判断、意思決定みたいなところが、設計がどうなっていると一番良さそうなのかっていうことを、その人が知ってないとなかなかいいプロンプトだったりとか、いい指示ってのは書けないんだろうなと思ってて。
そういった意味で、全部をAIに頼るんじゃなくて、ちゃんと自分が学べるような個人プロジェクトをいっぱいたくさん作って、いっぱい失敗してっていうのが、より一層重要になりそうだなと思いましたね。
そうですね。やっぱりその意味だとコーディングエージェントはやっぱりちょっと楽しすぎて、カーソルとかのエージェントモードじゃないやつ、タブ補完で結構いっぱい作ってくれるやつ、あれはちょうどいい塩梅だと思いますね。あれぐらいが一番わかりやすいし便利だしのいいところだと思っていて、やっぱ設計を磨こうと思ったときには、
そのようなカーソルの本とか使って、自分で一から組み立てているっていうところを個人的にはすごくお勧めしたい。
いいですね。じゃあ時にはちゃんと自分でも書こうねってことですね。もう本当に。全部AIお任せじゃなくて。
本当にそうで、AIお任せ楽なんですけどね。楽なんですけど、やっぱり楽できるのはちゃんと学んだ人だけっていうのはやっぱりすごく思うなと思っていて、それまでは積み上げが大事なんだろうって。
学んだ人だけというよりかは多分大きくレバレッジを効かせられるのが、もうすでに知ってる人というかスキルがある人ってことですよね。一番よく使えるのってことですね。
実際そのクロードコードとかコーディングエージェントって、ここ違うんだけどここ違うんだけど連発してればいつか今の方向にいってくと思うんですけど、ただそれってすごく遅いですよね。
すごい時間かかります。
だから最初から一発、ここが正しい方向だよと意識っていうのはちゃんと人間が握るよってやってあげて、その人とか多分コーディングエージェントでも10倍ぐらい差が出るんじゃないかなっていうのは個人的には思いますね。
やっぱりそこでもまだ今持ってるスキルっていうのが重要なんだろうと思ってます。
10倍どころじゃない気がしますけどね、その10倍100倍1000倍とかにどんどんスケールしていくんだろうなとは思いますね。本当にできる人がAIエージェント使うっていうのは。ありがとうございます。
じゃあちょっといい時間なので最後に何か設計に関して一言あったら。
そうですね、やっぱり今日伝えたかったことは2つで、やっぱりたくさん技術設計して技術選択して失敗することがすごく大事です。
ちゃんと失敗は失敗だってわかるように嗅覚を鍛えるってこともすごく大事で、コードの声をよく聞いて何か文句のこととか増えてないかなとかそういうふうなところとかを気をつけながらやるのが個人的に一番いいと思います。
42:06
なのでとにかくそういうふうなプラクティスいっぱいやって自分の設計に自信を持てるようになりましょう。そこが一番大事だと思います。
はいありがとうございます。ということで今回はここまでにしたいと思います。もっと詳しく教えてください。
ラジオ略称クワラジではスーパーエンジニアである国明さんに一般エンジニアであるえっとこが技術的な質問をしていく番組になっています。
今後もですねいろんなことを聞いていきたいなと思ってますのでお聞きのプラットフォームで高評価やフォローの方お願いします。
またこんなことを国明さんに聞いてほしいみたいなことがありましたらコメントいただけると取り上げたいなと思いますのでよろしくお願いします。
Xなのでハッシュタグクワラジで呟いてもらっても大丈夫ですので感想なども是非よろしくお願いします。
それでは今回もありがとうございました。ありがとうございました。
