AI時代の開発は「改善速度」の競争へ

bravesoftに入社して5年。案件を30件近く担当する中で、イベント × BtoCアプリや大規模Webシステムに関わってきた。最近では億単位の案件も実施させていただくようになり、生成AIの登場以降、その進め方も変わってきたように感じる。現場で触れながら感じていることを、書き留めておきたい。

1. AIによって開発速度は劇的に向上した

ChatGPTやClaude、Gemini、Cursor。いろんなAIを触ってみて、まず感じたのは「作るスピードが全然違う」ということだった。リサーチも資料作成もコード生成も、以前よりずっと速くなった。

ただ、速く作れるようになっただけでは成果につながらないケースも多いように思う。AIは「作る」ことは速くしてくれる。でも「何を作るべきか」「何を直すべきか」までは、結局人間が決める必要がある。だから今、僕が大事だと感じているのは、開発スピードそのものより、改善し続けるための仕組みの方かもしれない。

2. なぜ多くのプロダクトは成長しないのか

リリース後に伸び悩むケースを見てきて、理由は技術力不足だけではなさそうだ。僕が見てきた現場では、だいたい次の3つが重なっていることが多い。関係者ごとに課題の捉え方がバラバラで、仕様が特定の人の頭の中にしかない。画面仕様はFigma、APIは別ドキュメント、業務フローはPowerPoint…と情報が散らばっている。リリースがゴールになっていて、それ以降の改善体制がない。

この状態だと、どこを直すべきか判断しにくい。AIで開発コストが下がった今だからこそ、何を改善すべきかを見極める力の方が、プロダクトの成長を左右するのではないか、と思うようになった。

3. 改善の第一歩は「見える化」

改善しようとしても、現状が見えていないと話にならない。レガシーシステムのリプレース案件では、ドキュメントが古い、コードが複雑に絡み合っている、暗黙知が残っている——そういう「ブラックボックス」状態が、思ったより多い。全体像が掴めないまま改善に入っても、どこから手をつければいいか分からない。

僕が関わる案件では、AIとFigJamを使った調査・分析から入る動きをとることが増えてきた。ドキュメント、ソースコード、DB、関係者へのヒアリング——散らばった情報を整理し、ホワイトボックス化していく。構成図、仕様書、ER図、課題マップなどが出てくると、改善ポイントが見えやすくなる。地味だけど、効く場面が多いと感じている。

4. 一方通行型から、反復型の要件定義へ

最初から完璧な答えを出すより、仮説を立てて検証し直すサイクルを速く回す方が大事だ、と感じてきた。以前は要件定義やデザインを長期間かけて固めてから開発に入る一方通行型が多かった。最近は、仮説→プロトタイプ→ヒアリングを繰り返す反復型へ移行する動きをとっている。生成AIの進化で短期間でプロトタイプが作れるようになり、画面を触りながら議論すると、認識のズレが早い段階で見つかりやすい。抽象的な言葉だけで話すより、具体的な画面をもとに議論した方が、意思決定が速くて精度も高い気がする。

5. デザインシステム × Figma MCPで、デザインと実装をつなぐ

情報が散らばる問題のうち、特にデザインと実装のズレに対して、Figma × デザインシステムでUIの正本を一本化していく動きをとっている。特に効いてきているように感じるのが、Figma MCP経由で開発環境につなぐ仕組みだ。従来は、Figmaのデザインをエンジニアが目視でコードに落とし込む「翻訳」工程があった。Chipsひとつのpaddingやborder、カラートークンでも、Figmaと実装でズレが出やすい。

Figma MCPを挟んで、Figma → MCP → Cursor という流れをつくっていく。コンポーネントのリンクを取得し、Cursorに指示を渡すと、デザイン仕様をもとにコードが生成される。Figma上で決めた色やフォントなどのルール（スタイルガイド）のリンクを渡すだけで、実際のアプリ側にも同じ見た目のルールが自動で反映されることもある。エンジニアが一つひとつカラーコードを写し取る必要がなくなり、デザイン変更も開発全体に伝わりやすくなる。画面やデバイスをまたいでも見た目が揃いやすく、認識のズレや手戻りも減りやすい。何より、エンジニアとデザイナーがFigmaという同じ場所でコメントしながら会話できるようになった。デザイン通りに実装しやすくなってきた——5年見てきた中では、大きな変化のひとつだと感じている。

6. 仕様駆動開発で改善速度を上げる

AIを開発に使い始めてから、コードを書くことより仕様を整えることの方が重要になってきた、と感じる。仕様（SPEC）を基準として据え、要件やUI/UX、業務ルール、API設計などを構造化して置く——そこからデザイン・実装・テスト・ドキュメントを連動させる仕様駆動開発へ、動きを広げていっている。

開発は、SPECをもとにタスクを分解し、AIがコードやテスト、ドキュメントを生成し、検証したうえで仕様に結果を反映する——というサイクルで回していくイメージに近づいてきた。仕様変更が起きたときにAIが影響範囲を解析し、画面仕様書やAPI一覧など関連ドキュメントをまとめて更新する動きも、試す場面が増えてきた。以前は一箇所直すと別のドキュメントの更新漏れが起きやすかったが、SPECを起点に連動させると、その手間が減りやすい。

AIはSPECに沿った実装やテスト、レビューの下書き、品質チェックなど「どう作るか」を担いやすい。人は何を作るべきか、どの順番で作るべきか、これで十分か——方針判断と最終的な品質確認を担う。この分担が機能しているとき、改善サイクルを止めずに回しやすいように感じる。効果は単にコードが速く書けるからではなく、SPECが更新可能な状態として保たれているから——そう捉えている。

7. 改善速度が、競争力を決める

かつては開発速度そのものが競争力だった。でもAIを触っていくうちに、その差は縮まってきている気がする。見える化して、反復型で仮説を検証し、Figma MCPでデザインと実装をつなぎ、SPECを軸に改善サイクルを回す——全部が整ったわけではないが、試しながらその方向に進めている。これから大事なのは、どれだけ早く課題を見つけて、検証して、改善し続けられるか。リリース後も、利用データやユーザーの声をもとに改善を続けられるか。

競争力の源泉は「開発速度」から「改善速度」へ移っているのではないか。最も多く作った会社ではなく、最も多く学んで、改善し続けられる仕組みを持てる会社——今は、そう感じている。