登壇スライド

感想

DDDの思想では、業務ロジックが複雑で、競合他社との差別化点である「中核の業務領域」に設計コストを集中させる。「満遍なくいい設計をする」ではなく、「価値を生む部分に集中的に設計コストをかける」。

自分は今まで満遍なく「良い設計」を目指していた。そのため、あまり価値を生まない場所に設計コスト（=時間）がかかっている状態だった。今後は「良い設計」をすることでメリットがありそうなところに集中的に時間をかけていきたい。

生成AIはネット上の魑魅魍魎のコードを学習している。そのため、質の良くない学習が生成AIのアウトプットに悪影響を及ぼしている可能性がある。

今まで生成AIを教師のように壁打ちしていた。しかし、適切なプロンプトで指示しないと、質の悪い設計を教えられる可能性があると知った。今後はそれが「良い設計」であるかどうかを自分の目でしっかりと判断していきたい。

「バグサーチャー」は、Cursor + Claude4 で動作する負債分析プロンプトである。静的解析では「コードの意図」を理解することができない。一方、生成AIは意図を推論できる。単に凝集度と結合度を見るだけではなく、変更容易性に着目して意図を汲み取りながらコードを解析する。

今まではリファクタの際、そのコードを書いた開発者に設計の意図を聞いていたが、そのコードを書いた人がいない時はその意図を聞けないという問題があった。今後は生成AIを「コードの意図推測器」として、自分1人でもコードの意図を推測していきたい。

設計を学んでも学ばなくても同じ結果が出るなら、設計を学ぶ必要はない。でもそうではない。今まで以上に設計を学んだかどうかが結果にはっきり出るようになっている。

技術はなんらかの問題を解決するための手段である。保守・変更が難しいコードは何かしらの問題があり、解決していかなければいけない。解決のメカニズムを人間が理解することで初めて、暴れ馬な生成AIを的確に操ることができる。

設計のレベルを上げるしかない。テストをいくら書いても意味はない。テストは、コードの品質が悪いことは検知できるが、品質を上げることはできない。

バグサーチャーが応用可能である。バグサーチャーは、理想的な構造を与えて「理想的な構造に反しているものを負債と見做せ」というプロンプト。これを応用すると、初めからこのようなプロンプトを使えば、最初から品質の良いコードを書かせられるようになる。プロンプトを適切に使えば、品質のコントロールは可能である。