要件定義の「待ち時間」が消えた話です。
こんにちは、リノエッジ代表の原田祥吾＠ベトナムです。
システム開発の打ち合わせって、「待ち」が多くないですか？
会議で要望を話す。「持ち帰って設計します」と言われる。次の定例まで1週間。出てきた画面を見て「うーん、ちょっと違うんだよな」となって、また1週間。
動くものを見られるのは、いつも数週間先。このループ、発注する側も、実は作る側もしんどいんですよね。
今日は、このループがうちの現場でどう変わったかという話を書きます。前に「共創」というテーマで一度書いた記事なんですが、あれから現場が大きく変わったので、実感ベースで全面的に書き直しました（2026年7月改稿）。
「FigmaよりAIに話したほうが早い」と気づいた日
きっかけは、うちで進めている子育て支援アプリの案件でした。
お客さんへのヒアリングを終えたあと、いつもならデザインツール——うちの場合はFigmaです——を開いて画面を描き始めるところを、先にAIに向かって「話す」ことから始めてみたんです。誰が使うサービスで、何のためにあって、どこをゴールにするのか。絵を描く前に、背景を言葉に落としていく。
やってみて気づいたことがあります。
画面って、画面だけでは決まらないんですよね。
どんなユーザーが、何を達成したいのか。その背景がことばになっていると、AIはユーザーインターフェースだけでなく、裏側のデータの持ち方——バックエンドの仕組みまで含めて、一貫した形にしてくれる。絵から入ると「見た目はいいけど裏側はこれから」になるところが、言葉から入ると表と裏が一緒に立ち上がってくるんです。
誤解のないように言うと、Figmaが要らなくなった話ではありません。仕上げの精度を詰める場面では、いまもデザイナーがFigmaで作り込みますし、そのほうがいい場面も正直まだ多いです。
変わったのは順番です。絵から入るか、言葉から入るか。
いわゆる「バイブコーディング」と呼ばれている開発のやり方ですが、僕の実感でいちばん大きいのはコードが速く書けることではなくて、この順番の逆転でした。
要件定義の数週間が、1週間になった
順番が変わると、時間の構造が変わります。
従来の進め方だと、ヒアリングのあとに設計へ1週間。次の定例で画面を見せて、「違う」となれば、修正してまた次の定例まで1週間。お客さんが「動くもの」に触れるまで、どうしても数週間かかっていました。
いまは、画面のイメージ1枚なら打ち合わせのその場で。実際に触れる「動く紙芝居」——動くインターフェース——でも、その週のうちに見てもらえます。ヒアリングから動くプロトタイプまで、体感で数週間が1週間くらい。これは案件に恵まれた話じゃありません。進め方の順番を変えた結果なので、再現性のある変化だと思っています。
動くものを見た瞬間、お客さんが変わる
ここからが、この記事でいちばん書きたかったことです。
僕は長いこと、要件がなかなか固まらないのは「聞き出す技術」の問題だと思っていました。こちらのヒアリングがうまければ、お客さんの頭の中を全部引き出せるはずだと。
違いました。頭の中のイメージは、誰のものであっても、言葉のままでは正確に共有できないんです。お客さんのイメージも、僕自身のイメージも。ヒアリングでどれだけ話しても、お互いが頭の中に描いている絵は、実は少しずつ違う。
ところが、動くものを目の前に置くと、打ち合わせの空気が変わります。
「この画面、押したらどうなるんですか？」
「こう動きます」
「へえ。……ねえ、ここにこういうボタンって置けたりします？」
この「置けたりします？」が出てきた瞬間が、僕は好きなんです。その場でアイデアが湧くか、「これは違う」と明確なNOが出る。どちらも前進で、曖昧な「持ち帰って検討します」が消える。
このとき起きているのは、たぶん「依頼する人」と「つくる人」の境界が消える、ということなんだと思います。動く紙芝居を囲んだ瞬間、お客さんは進捗報告を受け取るだけの席ではなくなって、一緒に手を動かして決める側に回っている。会議が「報告の場」から「つくる場」に変わる。
前の記事で僕は「共創」という言葉を使っていたんですが、正直、当時はまだ半分スローガンでした。いまは中身を1行で言えます。共創とは、お客さんが開発の輪の中に入ってくることです。開発に入る前に動くモックアップで認識を合わせる進め方については、「見てから作る」に順番を変えた話としても書いています。
ただし、AIは嘘をつく
ここまでだと良いことばかりなので、失敗の話もします。
うちでも、1日分——ひどいときは3日分の作業がまるごと無駄になったことがあります。原因は、AIの「できました」でした。それらしい顔で、動いていないものをできたと言ってくる。僕たちはこれを「AIの嘘」と呼んでいます。
最初は「人間がちゃんとレビューすれば防げる」と考えていました。でも、AIが出してくる量とスピードに対して、人間の目視だけで嘘を全部止めるのは、正直もう現実的ではなくなってきています。
だからうちでは、発想を変えました。AIの嘘を止める仕組みも、AIで作る。AIが作ったものを、別のAIが検査する。それでもすり抜けるので、さらに別の角度からもう一段検査を重ねる。チェックは一つでは止まりません。二重三重にして、初めて効きます。
地味で、大変です。でも、この「暴走を止める仕組みづくり」まで含めてやって初めて、さっき書いたスピードが安心して使えるものになる。速さの話とセットで、必ずこの話をするようにしています。
「以前はこれ、何してたんだっけ」
最近、ふと思うことがあります。AIがなかった頃、僕たちはこの時間、何をしていたんだっけ、と。
それくらい、うちの現場の仕事のやり方は変わりました。デザイナーもエンジニアも仕事の中身が入れ替わりましたが、いちばん大きく変わったのは、お客さんの席です。報告を待たされる側から、動くものを囲んで一緒に決める側へ。
一方で、変わっていないこともあります。何を作るべきかを考え、それでいくと決めるのは、いまも人間です。AIはそこを代わってくれません。だから僕は、AIを恐れる対象だとはあまり思っていなくて、人の考える力を引き出してくれる相棒くらいに捉えています。
こうした社内でのAIの使い方は、AI導入支援のページにもまとめています。興味があればどうぞ。
もしいま、開発会社との「待ち時間」にモヤモヤしているなら、これだけ持ち帰ってもらえたら十分です。
開発は「作らせて、待つ」ものから、「一緒に見ながら、決める」ものに変わり始めています。
頭の中のイメージは、言葉で完璧に伝えようとしなくていい。動く形にするところは、僕たちの仕事なので。
【今回のまとめ】
- 絵より先に、言葉 — 背景・ゴール・ターゲットを言葉に落とすと、画面の見た目だけでなく裏側の仕組みまで一緒に形になる。
- 数週間が、1週間に — ヒアリングから「動く紙芝居」までの待ち時間が消えると、反応はその場で返ってくる。アイデアも、明確なNOも。
- AIの嘘は、AIで止める — 検査は一つでは止まらない。二重三重の仕組みにして初めて、スピードが安心して使えるものになる。
よくある質問
バイブコーディングとは何ですか？
作りたいものを自然言語でAIに伝えて、コードやプロトタイプを生成してもらう開発のやり方です。仕様書を書き上げてから作る、という順番を取りません。話しながら動くものを育てていきます。僕の実感では、本質は「コードが速い」ことより「背景やゴールを言葉に落とす行為そのものが設計になる」ことです。うちでの取り入れ方はAI導入支援のページにまとめています。
AIが作ったプロトタイプは、そのまま本番のシステムになりますか？
なりません。ここは正直に言っておきたいところです。プロトタイプは「認識を合わせるための動く紙芝居」で、本番のシステムには性能・セキュリティ・保守性の作り込みが別途必要です。本文に書いたとおりAIは嘘もつくので、二重三重の検査を通してから本番の品質に仕上げます。本番開発の進め方はシステム開発のページにまとめています。
試してみたい場合、何を準備すればいいですか？
準備は要りません。「こういうことができたらいいのに」という頭の中のイメージのまま持ってきてもらえれば、それを言葉に落とすところから一緒にやります。資料は、あってもなくても大丈夫です。まずは下の壁打ちで、そのモヤモヤをそのまま聞かせてください。
頭の中のイメージ、一度「動く形」で見てみたくなったら、下からどうぞ。
そのアイデア、まず原田に話してみませんか
頭の中のイメージを言葉に落とすところから、壁打ち相手になります。動く紙芝居をどのくらいの速さで見られるか、あなたの案件に当てはめて具体的にお話しできます。
15分の壁打ちを予約する → AI導入支援の詳細を見る
東京とベトナムの二拠点で、ITオフショア開発・海外進出支援事業を展開。「気合いより仕組み」を信条に、不透明になりがちな越境ビジネスを構造化する経営者。「個人のスキル」ではなく「再現性のある品質」を組織と顧客へ提供することにコミットしています。