2026-02-21

実装から設計をまとめる

従来のデザインプロセスでは、設計が先にあり実装がその後に続く。要件を整理し、画面設計を行い、仕様書を書き、エンジニアに渡す。ウォーターフォール型であれアジャイルであれ、この「考えてから作る」という基本的な流れは変わらなかった。

AIコーディングツールの登場で、この順序が逆転する場面が出てきた。先にプロトタイプを作り、触りながら改善し、最終的に設計のポイントを逆算してまとめる。実装が設計書に先行する。これは単にプロセスが速くなったという話ではなく、プロセスの構造自体が変わったことを意味する。

具体的なケース

ある業務アプリの改善案件で実際に起きたことを整理する。

クライアントから要件資料を受け取る。アプリのUIが使いにくいのでなんとかしてほしいという依頼。従来なら、資料を読み込み、課題を整理し、改善案をFigmaで作り、提案書にまとめ、承認を得てから実装に入る。

AIを使ったプロセスはこうだった。まず資料をClaude Codeに読ませて前提条件を整理する。整理した条件をもとに「じゃあ実装して」と頼む。出てきたプロトタイプを触ってみる。アンケート画面が一覧形式になっていたが、1問1答の方がユーザー体験として良いと判断し、その場で変更を依頼。配色が寂しかったので暖色系に変更。フォントをユニバーサルデザイン対応のものに差し替え。

こうしてプロトタイプを磨き上げた後、Claude Codeに「ここまでの会話をもとにこのアプリのUI/UXのポイントをまとめて」と依頼する。AIが会話のログから設計判断を抽出し、構造化してくれる。それを資料に仕上げて提案書にする。

この一連の流れを、他の仕事と並行しながら実稼働約2時間で完了した。

なぜこの逆転が成立するのか

従来、実装は高コストだった。間違えたらやり直しに時間がかかる。だから事前にしっかり設計し、手戻りを最小化する必要があった。この制約がなくなりつつある。

AIによる実装コストがほぼゼロに近づくと、「まず作ってみる → 試す → 直す」のイテレーションが極めて安くなる。効果的な探索には全方位的探索から仮説検証型探索への段階的移行が不可欠であるが、探索のコストが劇的に下がったことで、仮説を立てる前に「とりあえず作る」という全方位的探索が合理的になった場面がある。

これはエリック・リースのリーン・スタートアップが提唱した「Build-Measure-Learn」のループが、プロダクト単位ではなく画面単位、機能単位で回せるようになったということだ。MVPを作るコストが十分に低いなら、考えるより作った方が学びが速い。

粘土造形としてのプロダクト開発

デジタルプロダクト開発が粘土造形化しているのはツールが素材の可塑性に追いついたからであるで詳しく論じているが、この変化を「粘土造形」と呼ぶことにしている。

従来のデザインプロセスが「建築」だとすると、新しいプロセスは「粘土造形」だ。建築は設計図なしには始められない。構造計算があり、施工順序があり、やり直しのコストが極めて高い。一方で粘土は、手で触りながら形を変えられる。途中で「やっぱりこっちの方がいいな」と思ったら簡単に直せる。

デザインをするとは、意図を持って設計と意匠を行うということであるが、意図の形成プロセス自体が変わった。事前に頭の中で完成形を描いてからそれを実装するのではなく、作りながら意図が明確になっていく。手を動かすことで考えが整理される感覚に近い。

これはかつてのFlasherたちの仕事のやり方に似ている。Flash全盛期、優れたFlasherは考えながら作り、作りながら考えていた。道具がプログラムであり、面白いものを作れるかどうかの勝負。AIの登場で、あの時代の即興的な作り方が再び可能になったとも言える。

逆算で得られる設計書の質

面白いのは、この逆算プロセスで得られる設計書の質が意外と高いことだ。

事前に書く設計書は、まだ作っていないものを言語化するため、どうしても抽象的になりがちだ。「ユーザーにとって使いやすいUI」「直感的な操作性」。こういった言葉が並ぶ。しかし実物を作った後にまとめた設計書は、具体的な判断の積み重ねが記録される。「1問1答にしたのは認知負荷を下げるため」「暖色系にしたのは高齢者向けアプリで安心感を優先したため」。実際に判断した理由がそこにある。

プロジェクトには「仮説立案・合意フェーズ」と「仮説検証・評価フェーズ」があり、仮説立案が最も労力がかかるのだが、実装ベースのプロセスでは仮説立案と検証が同時に進行する。作ること自体が仮説検証であり、その検証結果を事後的にまとめることで仮説が精緻化される。

このプロセスが使えない領域

ただし、この逆転プロセスが万能というわけではない。

設計ロジックが重要なプロダクト(業務アプリ、ツール系)では極めて有効だ。画面の構造やフローが主な論点になるため、作りながら検証する方が効率的になる。

一方で、ブランド表現やビジュアルの方向性が重要なプロダクトでは、先にコンセプトを言語化・視覚化するプロセスを省略しにくい。デザインツールはマスターデータ制作からAIへの視覚的インプット生成へと役割を変えるにしても、ビジュアルの方向性を決める段階ではデザインツールでの作り込みが引き続き必要だ。

この使い分けを判断すること自体が、AI活用能力とマネジメント能力は本質的に同じスキルセットであると言える所以でもある。どのプロセスを選ぶかは経験に基づく判断力に依存する。