【なぜAIに設計を任せると成長が止まるのか】Kiroを使っても学べない設計スキルの真実
はじめに
僕自身、実務や個人開発でAIを活用して開発しています。Kiroやcc-sddを使った仕様駆動開発を行い、AI を使って生産性は向上している。また余った時間をコードレビューにも使い、コードの質もある程度は担保出来るようになりました。
しかし、ある時ふと感じました。「僕自身の設計スキルは向上してないのでは？」と。
AIに機能要件を伝えれば設計書を作ってくれるし、その段階でレビューすれば設計の質も担保できる。しかし「自分自身は何も成長していない」とも同時に感じていました。
そこで「AIを使いつつ、設計スキルを最大限高めるにはどうしたらいいか？」を自分なりに整理してみました。まずは「いい設計」の定義を整理した後、「AIに設計を任せると成長しない原因」と「AIを使って設計スキルを向上させるための方法」を紹介しています。
「AIを使いアプリは作れてるけど成長できていない」や「タスクはなんとなくこなせてるけど成長できてる実感がない」と感じている方には、ぜひ読んでいただけると嬉しいです！
他にも色々な考え方があると思います。また、僕の至らない点も数多くあると思います。
ぜひご指摘やコメントをいただけると嬉しいです！
そもそもいい設計とは？
「いい設計」の定義
「いい設計」には色々な観点があると思います。
- 今後の展望をどれだけ考慮できているか？どのような機能を実装していくのか？
- そのアプリケーションの強みは何か？
- 可読性は高いか？直感的に理解できるか？
- 応答時間は短いか？
- 保守性は高いか？
これらは一例です。ただ一つ言えるのは「機能要件通りに動く ≠ いい設計ではない」です。
例えば、今後似た機能を水平展開して開発する予定があるなら、水平展開する部分を抽象化しておけば、追加機能実装時の口数が圧倒的に減ります。
しかしこの考慮がなければ、全てのロジックがハードコードされて作られます。その結果、追加機能を開発する際、既存実装にも大幅に変更が入り機能追加時のデグレにも入念に注意する必要が出てきます。
大規模アプリは様々な要因が絡むため、局所的な設計は技術的負債を抱えやすい
大規模アプリの場合、個人開発や小規模アプリよりも考慮するべき事項が増えます。
先述の内容以外にも、インフラ構成は？どこがI/Oのボトルネックになるか？外部サービスとの連携やリプレースの予定は？受託開発ならお客さんの要望なども汲み取る必要があります。
上記の要件・要望を汲み取れていなければ、今後どこかのタイミングで修正する必要があります。これが技術的負債です。
そのため「とりあえず動く ≠ いい設計」と言えます。
AIに全ての文脈を伝えられない
最適な設計は、上記の要件・要望を汲み取った上で考えられるものです。
では「これらの要件を汲み取ってAIに渡せば問題ないか？」と言われると、答えはNoだと思っています。
もし伝え忘れた要件があったら？要件自体が変わったら？あるいは全ての要件を伝えても、AIが設計書を作成する段階で考慮漏れが生じるかもしれません。「途中の文脈が抜け落ちる」という危険性もあります。
つまり「AIが作成する設計書 ≠ 抜け漏れがない設計書」です。そのため、人が設計書をレビューする必要があると考えています。
AIに設計を任せると成長しない原因
知らないことは指摘できない。
AI駆動開発を実践されている方の中には「コードレビューして負債になりそうな箇所を修正させればいい」という意見があります。私もこの考えは正しいと感じていますし、レビューにより設計の質はある程度担保できます。しかしこれは「自走できているエンジニア」に対してのみに言えると思っています。
駆け出しエンジニアの場合、何が正解か分かっていない状態です。それだと「AIが出力したコードのどこが問題か？」が見極められないため、「レビューしても問題が解決されない」という事象が起こります。
例えば、作成された設計書は「クラス同士が全て密結合で保守性に問題がある」とします。しかし「疎結合」や「DI」の考え方・メリットを理解していない場合は、密結合な設計に対して問題意識が生まれません。もちろん設計書の修正もできません。
つまり、レビューは「自分の知識の範囲内」しかできないです。そのため知識が十分でない場合は、設計書やコードの質を担保するのが難しいです。
以前ココナラさんが出されていた「同じ5行のコードが全く違って見える12の瞬間、なぜ私たちは学ぶのか？」も非常に勉強になります。ぜひご覧ください！
「知らないこと」に気づけない。
上記の「質が担保できない」事象に加え、さらに深刻な問題が発生します。それは「知識がアップデートされない」です。
AIに設計書を作らせた場合、主体的に他の設計方法を調べない限り、その設計書に対して「Yes or No」を伝えるだけになります。
その結果、インプット出来る情報は「AIが出してきた設計」のみになります。もしAIが提案してきた内容を既に知っていた場合、「インプット情報が0になる = その開発から学べることがなくなる」可能性も高いです。
つまり、AIに設計を任せると、他の設計方法を知る機会が減り、設計のレパートリーが増えません。その結果「もっといい設計方法」があったとしてもそれらの存在を知れず、成長が止まります。
設計力は自分で決断しないと身につかない。
技術選定やアーキテクチャ設計に関しても同様のことが言えます。他の技術やアーキテクチャとの比較やトレードオフを意識できなくなります。
実装レベルの設計なら、局所的な最適解が出やすいのでトレードオフはあまり意識しないです。しかし技術選定やアーキテクチャ設計ではこれらを意識する必要があり、費用や可用性など要件に応じて取捨選択する必要があります。「アーキテクチャ設計をAIに全て任せるのは危険」である。これは全員が理解できると思います。
「自ら進んでトレードオフを取りに行く」、つまり「選択・決断する力」が設計力では大切ですが、このスキルもAIに全任せだと身に付かなくなると感じました。
AIを使って設計スキルを向上させるための方法
今までお伝えした背景情報をもとに、AIを使って設計スキルを向上する方法を考えてまとめてみました。もし取り入れられそうな所があれば、ぜひ取り入れて貰えると嬉しいです！
1. 設計を先に自分で考えてみる
AIに設計書を作らせる前に、一度自分で設計を考えられるといいと思います。アプリの実装であれば、機能要件から必要なテーブル構成やクラス図をイメージして作りましょう。
先に自分で設計書を作ると、AIが作成した設計書と比較した時に「足りてなかった観点」・「AIの設計書の不備」・「自分では思いつかなかった設計手法」などに気付けます。
その結果、設計スキルだけでなくAIに出す指示のコツなども学べます。
逆に、予め設計書を作っていない場合は「座学」に近い経験になります。もちろん勉強にはなりますが、「なぜその設計がいいのか？」を深く理解できていないので、身につくスキルも少なくなる、と思います。
実装時の設計書を作成する際の観点は、以前作成した記事でまとめています。もし興味があれば読んでもらえると嬉しいです！
2. 作成した設計書に対して「拡張性」や「保守性」などの評価と改善点を挙げてもらう。
自分やAIが作成した設計書に対してAIにレビューしてもらうことで、自分では認識できなかった着眼点を得られます。
例えば、保守性に関して評価してもらった場合、「なぜそれだと保守性が低いのか？」の理由を教えてもらうことで、「アンチパターン」の知識を得られます。同時に「保守性が高い設計」の作り方や仕組みについても学べます。
3. 複数の設計例を作ってもらい、メリットデメリットを比較する
実装レベルの設計だと、今の機能要件を満たす最適な設計は一つに定まると思います。
しかしこの時に「なぜ他の設計ではダメか？」を言語化しておくことは大切です。この内容が「他の設計を考える際の検討項目や観点になりうる」からです。
また、「最適な設計」はケースバイケースなので、今回は最適ではないけど将来同じ機能を実装する時は、最適になる場合もあります。
幅広い設計スキルを持っていると、場面場面で最適な設計が出来るようになり、設計の質も向上するのでオススメです。もちろん、このスキルはAIの設計書をレビューする際にも役立ちます。
おわりに
「設計スキルは、手を動かさないと学べない」という格言がありますが、その通りだと考えています。ただ僕なりに補足をすると「実際に手を動かす = 自分の頭で考える」だと思っています。
色々と考え、仮説を出してはAIに壁打ちして、さらにブラッシュアップして…
このプロセスを繰り返し、自分で考え続けて初めて身につくものだと思います。
もちろん「開発スピードを優先するため、AIに全ての設計を任せる」も有効な選択肢です。しかし、もし成長できていないと感じている方がいれば、ぜひ上記の方法を試してもらえればと思います！
余談ですが、現在Cursorのカスタムエージェントとカスタムコマンドを使い、設計の壁打ち用のエージェントやプロンプトを作っています。完成度が高ければ記事にまとめようと思うので、興味があれば見てもらえると嬉しいです！
Xフォローしてくれると嬉しいです
Xでも情報発信しているので、フォローしていただけると励みになります！
Discussion