メルカリ（メルペイ）のiOSエンジニアが、仕様を固める前に生成AIで動くプロトタイプを作り、それを見せながら議論する開発手法「Build First, Discuss Later」の実践事例を公開した。
メルカリ（メルペイ）のiOSエンジニアkubomi氏が、2026年6月15日に開発手法「Build First, Discuss Later（まず作る、議論は後）」の実践事例を公開した。仕様を固めてから実装に入る従来の流れを逆転させ、生成AIで動く試作品を先に作ってから議論する手法だ。
プロトタイプはミーティング前・中・後の3段階で活用する。前段階ではA案・B案と推奨案まで添えて議論の土台を作り、動く画面を見ながら議論することで言葉だけでは生まれていた認識のズレを潰す。これによりミーティングがほぼ1回で完結し、PdMの確認負担も軽くなったと報告している。
ただし著者は適用を数時間〜1日以内で作れる小規模な施策に限定している。大規模実装では議論で方針が変わったときの手戻りリスクが大きいためだ。エンジニアが要件を受け身で実装する役割から、アイデアと推奨案を持って議論に加わる役割へ移る点も、この事例の示唆として挙げられている。
この変化で何が要点か。図解と出典つきで一目で。
構造化された事実を最初に。誰が何をいつどこでなぜどのように。
従来の開発では、まずプロダクトマネージャー（PdM）が大まかな仕様を用意し、ミーティングで詳細を議論してから仕様を確定し、エンジニアが実装に入る流れが一般的だった。しかしこの方法では「この場合の挙動はどうするのか」といった疑問が実装中に次々と出て、その都度PdMへ確認したり追加のミーティングが必要になり、コミュニケーションの往復が増えていた。生成AIによってエンジニアが短時間で試作品を作れる場面が増えたことが、この手法を可能にした背景にある。著者はこれを数時間〜1日以内で作れる小規模な施策に限定して適用している。
生成AIで試作のコストが劇的に下がったことで、「仕様を固めてから作る」という開発の前提そのものが見直されつつある。動く画面を見ながら議論すると言葉だけより認識のズレが減り、議論が速く前に進むという現場の実感は、開発プロセスやチーム運営を考える読者にとって参考になる。エンジニアが受け身で要件を実装する役割から、アイデアを持って議論に加わる役割へ変わる点も示唆的である。
メルペイのiOSエンジニアkubomi氏が、2026年6月15日に開発手法「Build First, Discuss Later（まず作る、議論は後）」の実践事例を公開した。従来は、プロダクトマネージャー（PdM、製品の仕様や優先順位を決める担当者）が大まかな仕様を用意し、ミーティングで詳細を詰めて仕様を確定してからエンジニアが実装に入る流れが一般的だった。この記事はその順番を逆転させる。
生成AIによって、エンジニアが短
背景にあるのは、生成AIによってエンジニアが短時間で試作品を作れる場面が増えたことだ。動く画面があれば、言葉だけの議論よりも認識のズレが減り、議論が速く前に進む——というのがこの手法の出発点になっている。
この手法の特徴は、プロトタイプを1回見せて終わりにせず、ミーティングの前・中・後の3段階で使い分ける点にある。
従来の流れでは、こうした疑問が実装中に次々と出て、その都度PdMへ確認したり追加のミーティングが必要になり、コミュニケーションの往復が増えていた。動く試作を先に出すことで、その往復を議論の前に前倒しで片付ける構造になっている。
この手法は万能ではない。著者は適用を「数時間〜1日以内で作れる小規模な施策」に限定している。大規模な実装をいきなり試作してしまうと、議論の結果で方針が変わったときの手戻りリスクが大きいためだ。
この線引きが、誰にとって得かを分ける。小規模施策を担う国内の開発チームは、動く試作を持ち込むことでミーティングがほぼ1回で完結し、確認の往復が減る。PdMは、動く画面とA案B案・推奨案が事前に揃うため、仕様の細部を確認する負担が軽くなったと報告されている。
一方、この手法を大規模実装にそのまま適用しようとするチームは、作ってから議論で方針が覆る作り直しコストを抱えやすい。読者が自分の現場に持ち込むなら、まず「数時間〜1日で作れるか」という基準で対象を絞ることが最初の判断になる。
この事例が示すのは、開発プロセスの効率化だけではない。エンジニアが、PdMの決めた要件を受け身で実装する役割から、自分でアイデアを持ち、A案B案と推奨案を携えて議論に加わる役割へと移る点だ。
動く試作を先に出せるようになったことで、議論のたたき台を作る主体がエンジニア側に寄る。生成AIで試作のコストが下がったことが、この役割の移動を後押ししている。開発プロセスやチーム運営を考える読者にとっては、「誰が議論の起点を作るか」という分担そのものを見直す材料になる。
立場別、明日から動ける一手。
この手法を適用してよい施策の上限を「数時間〜1日で作れる小規模」の基準で定義する。
次の小さな施策で、ミーティング前に動く試作とA案B案・推奨案を用意する進め方を試す。
公開直後で反応はまだ限定的。
公式発表と各所の反応から編集部が要約した主な論点です。個別のX投稿そのものは下部のセクションに表示されます。
「動く画面を見ながら議論すると認識のズレが減る」
開発プロセスやチーム運営を考える層を中心に、「動く画面を見ながら議論すると認識のズレが減る」という現場の実感に関心が向いている。生成AIで試作コストが下がったことが、仕様確定前に試作を出すという順番の逆転を可能にした点が論点になっている。
※トレンド検出時刻付近の人気投稿を表示
