文章で要件定義するのをやめた。AIでモックを先に作ったら、認識ズレが実装前に全部見つかった - Qiita

はじめに 社内 SaaS に「アプリ内アンケート機能」を追加しました。質問を作るのはビジネス側の責任者、箱を作るのは開発側という分担です。 要件のすり合わせ開始から、実装完了（PR 3本マージ）までは 2 日でした。 速かった理由は、AI の実装力ではありません。要件定義の順序を変えたことです。文章で要件を固めてからモックを作るのではなく、モックを先に作って画面で要件を決めました。 この記事では、実際にやった 5 ステップと、その過程で「認識ズレが実装前に 3 回見つかった」話を書きます。 想定読者はこんな人です。 少人数チームで、ビジネス側（PdM・事業責任者）と仕様をすり合わせながら開発しているエンジニア Claude Code などの AI コーディングツールは使っているが、要件定義のやり方は変えていない人 前提 チーム: 開発は少人数。要件の決裁者は非エンジニアのビジネス側責任者

[mostan]

AIで作った画面モック見せると、一般人にはほぼ完成品に見えるため、簡単にできるじゃんと工数を買い叩かれる恐れはある

[hdampty7]

訓練されていない一般職の人は文章だけでシステム仕様やアプリ動作を想定するのは難しい。物を出す方が進みが早い。一方でアプリ内アンケート機能の要件定義が甘いのでどうせまた同じような別機能を作るとかありそう

[shikiarai]

わしゃ昔からポンチ絵フロー図とモックと文章のセットで要件定義しとるで

[hecaton55]

システム開発経験が少ないと文章だけで完成品を想像するのは難しい。なのでユーザー向けには画面イメージを元に説明してフィードバックを求めるというのは昔からやっていたと思う

[ls-ltr]

画面への指摘をどう要件定義に落とし込むかなんよな、、、

[cinq_na]

自分も入社して最初の仕事はこんなんだったな。さらっとAccessで画面作って客先と仕様詰めて実装する。なんで新人が一人でやってるのか謎だったけど、利益率は社内トップだった(利益額としては誤差)

[and_hyphen]

パッケージカスタマイズだとこうはいかんよなよいう気はする。あとめちゃくちゃ画面数があるでかいやつ。文章だと読み解けないのは同意する

[shinji]

流し読みだけど、それって見せ方が重要な要件だったてだけじゃね？見せ方以外の要件たくさんあるだろ。モックで解決するんならもともと目的や実現したいことにたいして要件定義の進め方が非効率だっただけじゃね？

[masatotoro]

モック駆動開発？

[ys0000]

プロトタイプ開発を再発明しなくてもいいのよ。操作イメージがつくとフィードバックが出しやすいのは昔から知られている。AIを効率的に使える部分。

[yarumato]

“文章で要件を固めてからモックを作る（それぞれ別の画面を頭に描く）のではなく、モックを先に作って画面で要件を決めた。あとから変えるとテーブル設計からやり直しになる箇所だけ、先に決める”

[miiruW]

これは私もやってみて良いなと感じたことなり

[bike-a-to-z]

uiuxデザイナーが駆逐された理由はこれよな。今思うと理想ばかり掲げてるやつは可視化されない分凄そうに見えてただけで、間挟まないでやり取りできたほうが質がいい

[abcdefghijklmnopqrstuvwxy5]

読んでたら文章で決めた方がいい箇所とモックで決めた方がいい箇所がある気がしてきた