Copyright COMO Inc. 2026
我が社に12月から、新たにエンジニアの方が1名加わりました。
現在在籍しているエンジニアの紹介で、COMOに関わってくださることになった方です。
海外での開発経験も豊富で、今回かなり込み入った機能改修をお願いしたのですが、
仕様のすり合わせ段階から非常に丁寧で、細かいところまで一つひとつ整理してくれました。
「エンジニアってすごいな」と、改めて感じさせてもらい、
個人的にもエンジニア熱に火を灯してもらった出来事でした。
今回は、そのエンジニアの方による社内勉強会（LT）で共有された内容をまとめます。
勉強会の中で、特に印象に残った言葉がありました。
「AIを活かせるかどうかは、エンジニアの設計力にかかっている」
今の開発現場を見ていると、まさにその通りだと感じます。
ChatGPT や Cursor など、AI開発ツールは日々進化しています。
実装スピードは確かに上がり、「コードを書く」こと自体は以前よりずっと楽になりました。
一方で、日本語で
「こんな機能が欲しい」と入力すれば、AIがすべて作ってくれる
——そんな夢のような環境になったかというと、実はそう簡単ではありません。
実際の開発環境となると、こんな感じになることもしばしば。
AIは優秀なのに、プロダクトは安定しない。
この原因はどこにあるのか——。
今回の勉強会で聞いた話が、その答えでした。
AIは「ガードレール」があって初めて正しく走れる。
ここでいう「ガードレール」とは、
AIの自由度を奪うものではなく、正しい方向に導くための設計上の前提条件のことです。
AIにいきなり「実装して」と投げるのではなく、
こうした設計の前提が明確であればあるほど、
AIは意図に沿ったコードを生成しやすくなります。
逆に、設計が曖昧なままAIを使うと、
「動くけれど壊れやすいコード」を量産してしまう、というわけです。
特に印象的だったのが、
TDD（テスト駆動開発）の捉え方でした。
一般的にTDDは「テストを先に書く手法」と説明されることが多いですが、
今回の説明は少し違っていました。
テストコードは、ドキュメントそのもの。
それを人間にもAIにも分かる形で表現したものがテストコードです。
文章で書かれたドキュメントは古くなりがちですが、
テストコードは「動いている限り、常に最新」です。
フロントエンド設計の話では、
コンテナ・プレゼンテーションパターンの紹介もありました。
これらを明確に分けることで、
結果として、
AIに「何を作らせたいか」を正確に伝えられる設計になります。
生成AIが出る以前にコンテナ・プレゼンテーションパターンを実装してみたこともあるのですが、コードを書く量の割にはメリットが少ないという結論にいたり、一度取りやめたことがあります。
AI時代の今でこそ、クリーンな設計の考え方としてコンテナ・プレゼンテーションパターンが生きるのではないかという意見でした。
AI時代の開発では、
以上に、
「どう分けるか」
「どう責務を定義するか」
が、圧倒的に重要になってきています。
設計があるからこそ、
のだと感じました。
正直に言うと、
現在の PICO では「思いもよらないバグ」が出ることもあります。
だからこそ、
ことで、
AIによる「必要のない大量のコード」を減らせるのではないかと考えています。
私たちは、
設計をAIと一緒に育てていく
そんな開発の仕方に舵を切ろうとしています。
AIはとても優秀です。
でも、
何を正解とするかを決めるのは人間
そのための共通言語が「設計」なのだと、
今回の勉強会を通して強く感じました。
新しいエンジニアにとっても、
そして私たちのようにプロダクトを育てる側にとっても、
「まず設計」
これは、AI時代の一番の近道かもしれません。
今回の議論の中で、「設計」という考え方を深めるために
紹介された書籍・リンクです。
※ いずれも「コードを書くための本」ではなく、
考え方を揃えるための本として勧められたものです。
頑張って読みます！冬休みは読書ですね💪
を見る