はじめに
匠技研工業株式会社で、製造業向けのAIプロダクト「匠フォース」のPdMをしている和田です。
私たちは現在、AIモックを開発フローの中心に置くことで、顧客検証のスピードと質を大きく改善しています。
従来はPRDで要求を整理し、Figmaで画面を作成してから開発に進んでいましたが、現在は実際に操作できるモックを顧客に触っていただき、その体験をもとに仕様を練り上げる開発プロセスへと変わりました。さらに、モックは汎用的な画面ではなく、顧客ごとに項目構造やデータの持ち方をカスタマイズした"その顧客専用のモック"として作成し、実際の業務環境に近い状態で検証を行っています。
その結果、
- 顧客の業務に踏み込んだ具体的なフィードバックが得られるようになった
- ある業務での変更が他業務に与える影響を、リリース前に発見しやすくなった
- 仮説検証サイクルは従来比3倍以上に短縮された
といった変化が生まれています。
ただし、ここに至るまでは試行錯誤がありました。AIモックを開発フローに取り入れ始めた当初、「動くものは出てくる。けれど、顧客に出せる質ではない」という壁にぶつかったのです。これを乗り越えた鍵が、顧客の生の発言を、整理せずにそのままAIに渡すというアプローチでした。
本記事では、この「AIモック中心の開発フロー」と、PdM・デザイナー・エンジニアがどのように協働して体験を具体化し、検証・開発を進めているのかを紹介します。
匠フォースのプロダクト開発体制
まずは前提として、開発体制を簡単に紹介します。匠フォースでは、PRDをオーナー制で進めています。
PRDごとにオーナーを1人立て、そのオーナーが要求の整理からモック作成、社内検証、顧客検証までを一気通貫で担います。オーナーは職種で決まりません。PdMだけでなく、エンジニアやデザイナーがPRDオーナーになるケースも多くあります。
この体制は、関わる全員が現場思考・顧客思考でプロダクトの価値最大化にオーナーシップを持って動くことを、開発体制として体現したものです。特定の役割の人だけが顧客に向き合うのではなく、全員が向き合う前提で組んでいます。例えば1人のエンジニアが、お客様の見積業務を自分が代わりに行えるレベルで理解しているといった解像度を、職種を問わず全員が持つことを目指しています。
この体制を機能させる中核にあるのが、次章で紹介するAIモックを中心とした開発フローです。
なぜAIモックを開発フローの中心に置くのか
「実際に使ってみないとなんとも言えないな〜」
これは以前、お客様から実際に頂いたお言葉です。
このフィードバックの背景には、匠フォース特有のプロダクト特性がありました。
特性1：顧客ごとに項目構造やデータの持ち方をカスタマイズできる仕様
匠フォースは、顧客ごとに項目構造やデータの持ち方を柔軟にカスタマイズできる仕様になっています。顧客は自社の業務フローに合わせてプロダクトを利用できる——SaaSによる汎用化が難しいとされてきた製造業において、このカスタマイズ性は匠フォースが事業を広げてこられた大きな強みです。一方で、新機能を検証する際には、顧客ごとに異なるカスタマイズ内容を反映した状態で体験を確認しなければ、本当にその顧客の業務で機能するのかを判断できません。
例えば見積業務であれば、
- 見積金額の算出ロジック（材料費＋加工費なのか、材料費＋社内加工費＋外注費なのか）
- 図面の特徴（切削図面か、板金図面か、組立図面か）
といった部分は顧客ごとに異なります。
特性2：見積・受注・製造といった複数業務にまたがってデータが流通する
さらに匠フォースは、見積・設計・製造といった複数業務にまたがってデータが流通するプロダクトです。そのため、ある画面の仕様変更が他業務にどのような影響を及ぼすかを、検証時に実際の操作の流れの中で確かめる必要があります。
この2つの特性に対し、従来のFigma中心の検証では限界がありました。
顧客ごとのカスタマイズをFigmaですべて再現するのは現実的ではなく、どうしても汎用的な画面イメージでの検証になります。汎用画面では、実際の運用に照らした違和感や、入力項目・操作順に対する細かな指摘といった、実務に根ざしたフィードバックを引き出すことができませんでした。
また静的なFigmaでは、データの流れ・業務の操作感・画面遷移といった「動き」を共有することが難しく、複数業務にまたがるデータ影響をモック段階で確認することもできませんでした。結果として、実装後に違和感が見つかり、PRDの仮説検証サイクルが遅くなるという課題がありました。
こうした匠フォース固有の検証の難しさを乗り越えるために、私たちはAIモックを開発フローの中心に置くことにしました。
AIモックを中心とした開発フロー
AIモックを中心とした開発は、以下の流れで進みます。
- PRD記載
- AIモック作成
- 社内検証
- 顧客検証
- UI精緻化
- 技術設計
- 実装
体験検証の段階でデザイナーがFigmaでUIを作成するフローはありません。PRDオーナー自身が要求要件をAIモックとして実装し、実際に操作できる形で体験を検証します。
AIモック作成〜顧客検証の実際のプロセス
PRDを通じて要求が確定した後、AIモックの作成に進みます。ここでは、PRDオーナーが中心となってAIモックを作成します。
匠フォースのAIモックの特徴は、顧客ごとに項目構造やデータの持ち方をカスタマイズした"その顧客専用のモック"として作成していることです。汎用的な画面ではなく、初期の検証顧客の実データをベースに、入力フォームや画面構成をその顧客の業務環境に近づけた状態で検証を行います。
複数顧客分のモックを並行して作成・更新していくため、効率化の工夫もいくつか取り入れています。
- Figmaコンポーネントの定義をAIに読み込ませることで、デザインシステムに沿ったUIをモックでも再現する
- 顧客の特徴（業務フロー・UI/UXの好み・業界傾向など）を事前にAIに覚えさせておくことで、毎回ゼロから前提を共有する手間を省く
ここまでが、モックを「効率的に作る」ための工夫です。一方で、モックを作り始めた当初、効率の前にそもそもアウトプットの質が想像していたものに届かないという壁にぶつかりました。
機能要求をPRDからそのままAIに渡してモックを作らせると、出てくるのは確かに仕様を満たしてはいる画面です。しかしそれは、顧客の業務の中で本当に機能する画面ではないことがほとんどでした。「動くものは出てくる。けれど、顧客に出せる質ではない」——この状態をどう乗り越えるかが、最初の壁でした。
試行錯誤を経てたどり着いたのは、AIへの情報の渡し方と、AIとの対話の仕方を意識的に変えることでした。具体的には、次の2つを軸にしています。
- 顧客の業務文脈（一次情報）を、整理せずにそのままAIに渡す
- 「どういう体験が良いとされるのか」の判断軸を、AIとともに言語化する
1. 一次情報を、整理せずにそのままAIに渡す
はじめのうちは、PRDオーナーが業務フローを綺麗に整理し、論点を抽象化してからAIに渡していました。
しかし、振り返ってみると、これがAIの出力の幅を狭めていた大きな要因でした。整理した時点でPRDオーナー自身の解釈が入り、AIの出力もその枠の中に収まる。結果として、PRDオーナーが事前に想像できる範囲のモックしか出てきません。
この反省から、私たちは現場の一次情報をできるだけそのままの形でAIに渡すことを意識するようになりました。
具体的には次のような情報です。
- 顧客インタビュー記録やVoC：その顧客がどんな業務を行っていて、どこに課題を感じているのか
- 顧客の発言そのもの（セリフ）：「この項目はhoge」「この場合はfugaにしたい」といった、業務の中で出てきた言葉をそのまま
- 顧客の業務プロセスの記述：見積を作成するときの判断順序や、参照しているデータなど
これらを整理・抽象化せずに渡すことで、PRDオーナーが見落としていた論点や、別の切り口での体験設計案がAIから出てくることがあります。自分一人では到達できなかった設計の幅が得られるのが、この渡し方の最大のメリットだと感じています。
なお、こうした「一次情報をそのまま渡す」アプローチが機能している前提には、弊社が以前から取り組んできたVoCや面談録画の一元管理があります。PRDに紐づくVoCをいつでもすぐに活用できる土台が整っているからこそ、AIへの一次情報の供給が成立しています。この基盤については、弊社プロダクトエンジニアの小森が以下の記事で詳しく紹介しています。
2. 「良い体験」の判断軸を、AIとともに言語化する
一次情報を渡しただけでは、AIはまだ「正解の方向」を知りません。
そこで私たちは、モック作成と並行して、「どういう体験が良いとされるのか」「複数案がある場合、どういう軸で良し悪しを判断するのか」をAIとともに整理しています。
具体的には、AIに次のような問いを投げかけながら進めます。
- この業務において、ユーザーにとって良い体験とはどのような状態か
- A案とB案がある場合、それぞれのメリット・デメリットは何か
- そのトレードオフは、どういう軸で判断すべきか
AIは、こちらが想定していなかった切り口を提示してくれることが多くあります。例えば「この画面では一覧性を優先すべきか、絞り込み後の編集効率を優先すべきか」といったトレードオフの軸を、こちらが言語化する前にAIが提示してくれることもあります。
従来、こうした「良い体験の判断軸」は、PdM個人の経験や、複数PdMによるレビューを通じて担保してきました。しかしこの方法には2つの限界があります。
- PdMの経験値に質が依存する
- 議論の場を設定するコストがかかる
AIと判断軸を整理するプロセスを取り入れたことで、PdM以外がPRDオーナーになった場合でも、一定の質を担保しやすくなりました。匠フォースではエンジニアやデザイナーもPRDオーナーになるため、この変化は体制全体への効果が大きいと感じています。
なお、AIとの対話で出てきた判断軸のうち、繰り返し使えるノウハウは、チーム全体で再利用できる形(Claude Skillなど)に整理しています。「製造業のユーザーはアイコンのみのボタンより明確なテキスト説明を好む」「図面は可能な限り大きく表示するのが好まれる」といった毎回使えるノウハウをチーム共通の資産として蓄積することで、PRDオーナーが誰になっても同じ品質基準で体験設計に入れるようにしています。
顧客検証後〜開発の実際のプロセス
顧客検証を通じて体験が一定固まった後、実装フェーズに進みます。デザイナーがAIモックをもとにデザインを精緻化し、エンジニアが技術設計を進めます。
AIモックの段階で業務フローや必要なデータ構造が共有されているため、デザイン・実装フェーズでもAIモックを共通言語としたコミュニケーションが継続的に行われます。
この開発フローで得られた効果
顧客検証のスピードと質が向上
AIモックを開発フローの中心に置いたことで、PRDの仮説検証サイクルは従来比3倍以上に高速化しました。従来は1機能を検証するためのFigmaの準備に3日程度かかっていましたが、AIモックでは1日以内に検証可能な状態を作れるようになり、週に複数回の検証が回せるようになっています。
特に匠フォースのようにカスタマイズ性が高いプロダクトでは、顧客ごとに業務フローや項目構造が異なるため、検証準備の工数がより重くのしかかります。AIモックの活用により、同じ期間で顧客ごとのカスタマイズを反映した検証数を増やせるようになったことが、サイクル全体の高速化につながっています。
また、実運用に近い形で触っていただくことで、
- 「この場合ってどうなるの？」
- 「この項目はhogeと入力するので、こうした方がいい」
といった実業務に基づく深いフィードバックを得やすくなりました。
加えて、検証セッション中にその場でモックを修正し、2案を比較できるようになったことも大きな変化です。従来は「フィードバックを持ち帰る → 社内で修正 → 次回再検証」というサイクルで、1回のセッションで1往復しか進めませんでしたが、現在はセッション中に2案を作成して顧客と一緒に判断できるようになり、1回のセッションで意思決定できる質と量が大きく増えました。
複数業務に横断するドメイン知識と要件の共有コストが低減
実際の操作やデータの流れをそのまま見ながら議論できる状態になったことで、ドメイン理解と仕様理解がスムーズになっています。その結果、伝達ミスが減り、要件共有の効率は体感で2倍以上に向上しました。さらに実装後の手戻りも減っています。
特に匠フォースは、見積・設計・製造といった複数業務にまたがってデータが流通するプロダクトのため、ある画面の仕様変更が他業務にどう影響するかを検証時に洗い出すコストが大きく、実装後に違和感に気づくケースが多くありました。AIモック中心の開発フローでは、業務フロー全体を実際の操作の中で確認できるため、こうした業務横断のデータの違和感を実装前のモック段階で発見しやすくなっています。
残された課題と、これから取り組むこと
AIモックを中心とした開発フローは、検証のスピードと質を大きく改善した一方で、まだ仕組みとして再現性を担保しきれていない領域があります。
特に課題として感じているのが、複雑な仕様やUIにおける本番実装との整合性です。
現状のAIモックは、体験を検証するという目的に対しては十分機能していますが、本番のソースコード全体の仕様を踏まえた上でアウトプットを出すところまでは到達できていません。複雑な業務ロジックや画面構成を含む場合、モックと本番実装の間に乖離が生まれ、実装前に人が介入してコンポーネントの粒度を揃えたり、レイアウトルールを整えたりする工程が発生している状態です。
ここを乗り越えるために、エージェントが本番ソースコードの仕様全体を把握した上で、提案・修正できる仕組みを整えていきたいと考えています。
AIモック中心の開発フローは、あくまで「顧客検証のスピードと質を上げる」ためのスタート地点です。ここからさらに、モックと本番実装の間の橋渡しまでをAIが担う開発プロセスへと進化させていくことが、私たちの次の挑戦です。
最後に
本記事では、匠フォースにおけるAIモックを中心としたプロダクト開発フローをご紹介しました。
匠技研工業では、自分たち自身が徹底的にAI-Nativeな組織になること、そしてそこで培ったAI-Nativeな働き方を、プロダクトを通じて製造業界に届けていくこと、この両方に本気で取り組んでいます。
AI活用を前提としたプロダクト開発に興味のある方、製造業のAI化を一緒に進めたい方、ぜひカジュアル面談でお話しできれば嬉しいです。
Discussion