プログラミングは速くなっても、プロダクトは速くならなかった

デザインレビューで、こういう反応が返ってきました。

「この課題に対して、このアプローチで本当にいいのでしょうか？」

問われたのは、ボタンの位置や余白ではありません。機能のアプローチそのものでした。

dev環境で動いていたその画面は、デザイナーの手を一度も通らずにできたものでした。エンジニアの私がAIで作ったたたき台が、ほぼそのまま実装されていたからです。

AIによって、コードを書く速度は格段に上がりました。

ところが、それだけではプロダクトが出る速度は上がりませんでした。

速くなった工程の先で、別の工程が詰まり始めたからです。

この記事では、AIを使い始めたことで私たちの開発プロセスがどう変わったのか、そして一度失敗してからどのようにプロセスを組み替えたのかを書きます。

「どう実装していいかわからない」

私たちは、業務ワークフローを設計・実行する「Nulab Flowbase」というプロダクトを開発しています。

以前、Refinement（スプリントに入れる前に、開発アイテムの中身を詰める場）で、毎回同じところで止まっていました。

仕様を口で説明します。画面はありません。

すると、

となります。

つまり、着手できません。

Nulab Flowbaseは業務ワークフローを扱う製品で、画面にさまざまな状態があります。どの状態で何を表示するのか、何が操作できるのか。言葉だけですべてを共有するのは簡単ではありません。

そこで、画面を用意する必要がありました。

当時の課題。文章だけで状態を説明していた

デザイナーにお願いするにしても、「こういう課題があって、こういう方向を考えている」という材料があった方が話しやすい。

そのためのラフな画面を、自分でFigmaで作っていました。

私はエンジニアなので、当然それほど上手くありません。

出来上がったものがそのままデザインになるわけではありません。

それでも、一枚画面があるだけで会話はかなり進みます。

問題は時間でした。

たたき台を作るのに2〜3日。そのあとデザインに1週間。実装に入れるのは、その後です。

他に方法がなかったので、それを特に疑っていませんでした。

数時間で、たたき台が出るようになった

そこでClaude Designを使い始めました。

既存のコードやFigma、画面のスクリーンショットなどを渡し、プロンプトで意図を伝えると、実際に触れるモックを作ってくれます。

既存のコードとスクリーンショットを貼り、プロンプトで意図を伝える

頭の中にあるものを、短時間で画面にできます。

案が固まっていなければ、複数案を出して壁打ちすることもできます。

URLを共有すれば、他のメンバーも実際に触れます。Backlogの課題に貼っておけば、それを見ながらRefinementできます。

以前なら2〜3日かけて作っていたたたき台が、数時間。長くても1日程度で出てくるようになりました。

しかも、私がかつて作っていたものより、ずっと良く見えました。

「短時間で、これだけのものが作れるなら、もう十分なのではないか」

このとき私は、そう考えていました。

Claude Codeで最初に出てきた画面

デザインができた気になっていた

ここで、冒頭の話に戻ります。

正直に言うと、嬉しかったです。

画面もある。実装方法も見える。

「あとは作るだけだ」と思いました。

それなら、デザインの完成を待つより先に実装してしまい、動くものをデザイナーに見てもらう方が効率的ではないか。

そう考えて、そのまま開発を進めました。

ですが、当然そんなに簡単にはいきません。

デザイナーから返ってきたのは、「もっと良い方法がある」という指摘でした。

しかも、ボタンの位置や余白を変える程度の話ではありません。

「そもそもこの操作をここでさせるべきなのか、別のアプローチの方が、課題に対して適切ではないのか」

という、構造そのものに関わる話です。

こうなると、実装後の修正コストは一気に上がります。

細かいUIの手戻りなら構いません。今はAIを使えば修正も速い。

でも、構造からやり直すとなると話は別です。

事前にデザイナーと方向性を共有していれば、防げた手戻りでした。

AIでたたき台を作れることと、デザインができることは、まったく同じではありませんでした。

手戻りは安くなった。でも手待ちは安くなっていない

この失敗のあと、開発チームで話しました。

テーマは、「どこで時間をかけるか」です。

話してみると、困っていたのは手戻りそのものではありませんでした。

今は実装も修正も以前よりずっと速い。

本当に困っていたのは、実装に着手できる状態になるまで待つ時間でした。

以前は、課題を共有してから、たたき台の作成に2〜3日、デザインに約1週間かかり、ようやく実装へ進める流れでした。

AIによって、たたき台は数時間で作れるようになりました。

しかし、その後の工程を何も変えなければ、開発者はデザインが完成するまで待つことになります。

手戻りは安くなりましたが、手待ちは安くなっていません。

そこで、全部決めてから作ることをやめました。

決めることと、決めないこと

代わりに、「後から変えると高くつくもの」と「後から安く直せるもの」を分けました。

Refinementで合意するのは、後から変えると実装全体をやり直す可能性があるものです。

先に決めるもの

• データモデル（何が何を持つのか）
• コアロジックと状態（どの状態で、何ができるのか）
• 情報設計（何を、どこで設定するのか）
• ラフワイヤー（大まかにどう操作するのか）

この時点では決めないもの

• 細かいUIやビジュアル
• 確定用語

構造がずれたら作り直しになります。

一方、余白や配置、細かなインタラクションは、実際に動くものを見た方が判断しやすく、後からの修正コストも低くなっています。

手戻りを無条件に許容しているわけではありません。

「安く戻せるところだけ、後ろに送る」という線を引きました。

これは、実装と修正が速くなったから成立するやり方です。

以前と同じ開発速度なら、後から直すコストが高すぎて成立しません。

今のプロセス

現在は、大まかに次のような流れで進めています。

デザイナーには、前と後の2回入ってもらいます。

実装前は、

「この課題に対して、このアプローチで進むこと自体が妥当か」

を確認します。

ここでは構造的な間違いを防ぎます。

実装後は、実際に動くものを触りながらレビューしてもらいます。

細かいUIやインタラクションは、この段階で詰めます。

なぜ2箇所に分けるのか。

ラフなモックなら数時間で出せるので、実装前に確認できます。

一方、完成したデザインを毎回実装前に用意するには時間がかかります。デザイナーへの依頼も、私たちのチームだけではありません。

そこで、アプローチだけは先に合意し、その後は実装を先行できるようにしました。

冒頭の失敗との違いはここです。

デザインを飛ばしているのではなく、デザイナーに判断してもらう場所を分けています。

このプロセスも、まだ途中

このやり方にしてから、まだそれほど時間は経っていません。

十分な数をこなして、効果を定量的に判断できる段階でもありません。

デザイナーの作業量が本当に減ったのかも、まだ分かりません。

ゼロから画面を考えるより、ラフなモックがある方が考えやすいはずですし、動くものをレビューする方が確実です。

ただ、私たちが速くなった分だけ大量のレビューを渡しているのであれば、今度はデザインレビューが次のボトルネックになる可能性もあります。

これから数をこなしながら、また変えていくつもりです。

AIが作る画面は「答え」ではなく「問い」

ただ、一つだけはかなり明確になりました。

AIが作る画面を、完成したデザインだと思わないことです。

AIが出す画面は、パッと見はかなり良く見えます。

むしろ、そこが少し危険です。

自分で雑なFigmaを作っていた頃は、「これはあくまでたたき台だ」と自分でも分かりました。

AIが作ったものは完成度が高く見えるので、作った本人まで「これでいいのでは」と思ってしまいます。

私が最初に踏んだのは、そこでした。

Figmaで作っていたモックが最終デザインとして使われなかったのも、考えてみれば同じことです。

あれは最初から、答えではありませんでした。

判断してもらうための問いだったのです。

なら、たたき台の完成度を上げることに、必要以上の時間をかける意味はありません。

目的は、きれいな画面を作ることではありません。

チームの判断を早く引き出すことです。

Claude Codeは、そのための道具として、とても優秀です。

速くなったのは、プログラミングだけだった

AIでコードを書く速度は上がりました。

これは実感として明らかです。

でも、それだけではプロダクトが出る速度は上がりませんでした。

詰まる場所が動いただけでした。

実装が速くなると、それまで相対的に見えにくかった仕様策定やデザインにかかる時間が、目立つようになります。

そこで、実装で浮いた余力を上流へ持っていきました。

仕様を整理する。

画面のたたき台を作る。

判断材料を先に置く。

そうすると、以前2〜3日かかっていたたたき台は数時間で出せるようになり、一定の条件を満たせば、デザインを完成させる前に実装へ進めるようになりました。

AIがデザイナーを代行しているわけではありません。

できるようになったのは、チームが判断するための材料を早く用意することです。

プログラミングが速くなったからといって、その余力をすべてプログラミングに使っても、プロダクト全体はそれほど速くなりません。

ボトルネックになっている場所に、その余力を使う。

今のところ、それが私たちのチームのAIの使い方の１つです。

プログラミングが速くなったのは、きっと私たちだけではないでしょう。

その浮いた余力を、みなさんのチームではどこに使っていますか。