1. はじめに

プロジェクトを３つも持っている状態でさらに社長直轄のAI駆動開発プロジェクトにぶっこまれるという状態で、七転八倒している毎日でございます。
社長直轄ということで、意思決定がとても早いのは良いですね。社長自らGenSparkを操り、画面モックを作って「こんなの作って」状態となっております。

うちの社長ってエンジニアじゃないんだけど、GenSparkで画面モック作れるとかどこで覚えてくるんだろう、、、

その画面モックを起点に、２日ほどで実装可能な状態まで要件から設計まで昇華させたプロセスで得られた知見を共有いたします。

2. １〜２日で完了した「リバース要件定義」のワークフロー

さて、この画面モックをどのようにすれば設計、実装の流れに持っていけるのか？
以下のように進めてみました。

モック生成とローカル展開

GenSparkが生成した画面ページをPlayWright MCPを使って、HTML/CSS/JSに落とし込み、全く同じ画面・動作を行うローカルモックを作成しました。ClaudeCodeに読み込ませるには、まずはClaudeCodeのインプットにしないことにはどうしようもないため、一番に実行。
PlayWright MCPはとても便利ですね。

Playwright MCPを使って、https://〜 のサイトにアクセスして、同じ画面モック(HTML/CSS/JS)をローカルに作成してください。

というだけでしばらくすると画面モックが作られます。ただ、細かいところまで取得できず、ローカル画面モックを触りながらGenSparkと違うところを修正する作業が結構ありました。
この作業だけで1日かかりました。

画面定義・遷移の整理

ローカルに画面モックができたらこっちのもんです。
ローカルを画面モックソースをベースにClaudeCodeで画面定義と遷移図を作成し、画面の理解を行います。

データモデル・業務フローの構築

画面仕様を起こせたら、次に業務の可視化を行います。
画面遷移図と項目から具体的にどのような業務を行うか分析させ、仕様に起こします。
また画面項目からエンティティを導き出し、ER図を作成します。
後述しますが、ドメイン知識がないために、ここが一番難しかったです。

機能一覧作成とMVP抽出

ここまでくればあとは機能一覧を作成し、MVPおよびそれ以降の開発フェーズごとに実装する機能を切り分けていきます。

ここまで2日で作成できました。

3. 考察

今回のプロセスを経て、エンジニアの役割が劇的に変化していることを実感しました。

「最強の意思決定者＝ UI作成者」がもたらすチート

要件定義フェーズの多くは、「ヒアリング→ドキュメント→レビュー」で数週間かかって「何を作るか」を合意していたが、今回の場合はモックの完成と同時に終わっている。
　社長：「これ作って」
　僕：「あ、はい」
つよいです

曖昧な言葉から仕様を「想像」するのではなく、すでにある動くものからビジネスロジックや整合性の抜け漏れを「検知」する作業へ変わりました。

AIによってエンジニアは「本質」に向き合えるようになった

モックから仕様を推測・整理する部分はAIが担当するので、浮いた時間でもっとWhy/Whatを考えることができました。

「結局これで何をしたいのか？」
「顧客の解決される問題はどこにあるのか？」
「導入後の業務はどう変わるのか？」

ドメイン知識の壁

考える時間ができた故に、この業務ドメイン知識のなさが露呈しました。
サービスを使っている現場の詳細を想像することができないし、このサービスを営業している現場の想像も難しい自分がいた。現場や営業を知っている人がいればサービス価値が上がると考える。

社長がモックで「やりたいこと」を可視化
エンジニアがAIで整合性と設計を実現
PdM(ドメインエキスパート)が現場や実運用の設計を検討

これらが噛み合うと早い開発に加えて、正しい価値をサービスに注入することができると思う。

4. 終わりに

あまりにも要件フェーズがあっさり終わってしまったので、びっくりしてQiitaで共有しています。社長がGenSparkでUI設計して画面モック作れる時代がくるとは、改めてすごい時代に生きてるなと思います。

文中で「PdM誰かやって」って書きましたが、自分がドメイン知識つけてPdMやれば最強ですよね。FDEとかはまさにその方向だし、これからのエンジニアはドメイン知識が必要で、全員PdMとなり得る時代が来るかもです。