こんにちは、株式会社ACES でテックリードをしている福澤 (@fuku_tech) です！
最近、新車を購入し、遂に昨日納車されました！しばらくはノー残業で早く帰宅して、たっぷりと新車を楽しもうと心に決めた今日この頃です。
1. はじめに
ACES Meet は商談や会議内容を可視化し、営業組織の強化を支援する 営業DX×AI SaaS です。音声書き起こしや対話分析など、多様な AI アルゴリズムを活用し、営業の生産性向上をサポートしています。
現在、ACES Meet は PMF（Product Market Fit）に向けて試行錯誤を続けている段階にあり、市場のニーズを捉え、素早く仮説検証を繰り返すことが不可欠です。
そのため、私たちは MVP（Minimum Viable Product）の考え方を取り入れ、ユーザーのフィードバックをもとにプロダクトを進化させる戦略を採っています。
本記事では、ACES Meet のプロダクト開発戦略を以下の MVP - not "bike to car" の記事の内容を踏まえながら、私たちがどのように MVP を考え、どのようにプロダクトを成長させているのかを具体的に紹介していきます。
また、本記事は以前公開した以下の記事の内容をさらに掘り下げたものです。併せて読んでいただくことで、ACES Meet の開発戦略についてより深く理解していただけると思います。
2. MVP - not "bike to car" の記事における主張
MVP - not "bike to car" の記事で筆者は、MVP開発において異なる製品を段階的に発展させるのではなく、最初から最終製品の形を意識しながら試作と改良を重ねることが適しているのではないか、という考えを主張しています。
ここで、説明しやすいように以降の文章では、下図の中段の絵のことを「キックボードから作る絵」と呼称し、下段の絵を「手押し車から作る絵」と呼称します。
MVPについて語る時、キックボードから作る絵のように「キックボード → 自転車 → バイク → 車」といった形で、段階的に進化させることがMVPのあり方とされることが多い*1ですが、筆者はこのアプローチが部分的にしか正しくないと指摘しています。MVPでは、最初から最終製品の形を意識しつつ、必要最低限の機能を備えたものを開発し、そこから改良を重ねる方法も有効なのではないか、というのが筆者の主張です。
例えば、車を開発する場合、キックボードから始めるのではなく、最初から「最低限の車」として試作し、テストを繰り返す方が目的に合っているのではないかと述べています。
また、筆者はユーザー体験（UX）の視点も重要だと指摘しており、初期のプロトタイプでは技術的な要素を最小限に抑えながら、ユーザー体験を検証する方法が有効であるとも考えています。
具体的には、手押し車から作る絵のように、初手はエンジンを搭載せず、ボランティアが車を押して動きを再現することで、技術的な負担を抑えつつ、ユーザーの反応を確かめることができるのではないかと提案しています。
このように、筆者は段階的な製品の進化ではなく、最初から本来目指す形を模索しながら改良を重ねるアプローチがより実用的ではないかと主張しています。
3. ACES Meet における「手押し車から作る絵」の解釈
以降、手押し車から作る絵の各フェーズのことをそれぞれ以下の名称で表現します。
- STEP1: 手押し車
- STEP2: 簡易トラック
- STEP3: 試作車
- STEP4: 完成車
ACES Meet の開発チームでは、プロダクト戦略として手押し車から作る絵を意識しながら開発を進めています。さらに、手押し車 → 簡易トラック → 試作車の進化と、試作車 → 完成車の進化には本質的な違いがあるのではないか？ という独自の解釈を入れています。
この違いを端的に言うと、手押し車 → 簡易トラック → 試作車のフェーズは少しずつ形状が変化しながら進化しているのに対し、試作車 → 完成車のフェーズではタイヤ・エンジンの厚み・ライト・ボディ・塗装が一気にアップデートされていることが挙げられます。つまり、試作車 → 完成車のフェーズでは、それまで積み上げた知見やデータをもとに、プロダクトを抜本的に刷新するフェーズに入るのではないか？ という仮説を持って解釈しています。*2
この考え方をもとにすると、手押し車 → 簡易トラック → 試作車は、試行錯誤を重ねながらロジカルに改善を積み重ねることで進化するフェーズであり、試作車 → 完成車は、それまでの知見をもとにプロダクト全体を再構築する大規模な転換フェーズであると捉えることができます。
この認識を持つことで、開発チームとしては、手押し車 → 簡易トラック → 試作車を「実験フェーズ」と割り切り、過度に時間をかけないようにする一方、試作車 → 完成車でスクラップ & ビルドしやすい形になっていれば多少の荒削りな部分があっても許容できる、という意思決定がしやすくなります。
4. ACES Meet の開発への適用
ACES Meet では、最初から最終製品の形を意識しつつ、最低限の機能を備えたMVPを市場に投入し、ユーザーのフィードバックをもとに進化させるというアプローチを採用しています。特に、第3章で述べたように、手押し車 → 簡易トラック → 試作車は実験フェーズ、試作車 → 完成車はプロダクトを抜本的に刷新するフェーズと捉えており、開発の進め方もこれに合わせて調整しています。
各フェーズでは、プロダクトの本質的な価値を見極め、開発リソースを適切に投下することが重要になります。
そのため、何を開発するかだけでなく、何を開発しないかを明確にすることも常に意識し、「やらないことを増やす」という方針を持ちながら取捨選択を進めています。
4-1. 実験フェーズでは本質的な価値を優先
手押し車 → 簡易トラック → 試作車のフェーズでは、ユーザーが求める本質的な価値を最小限の形で提供し、試行錯誤を重ねながら改善を続けることを重視しています。すべての機能を網羅するのではなく、仮説を立てながら最もインパクトの大きい機能に優先的にリソースを投下することで、スピードと価値提供のバランスを取っています。
4-1-1. ユーザーが価値を感じる部分を優先する
このフェーズでは、ユーザーが「業務プロセスの改善に繋がった」と実感できる体験や機能を最小限の形で提供することを最優先としています。そのため、すべての機能を作り込むのではなく、利用頻度やフィードバックをもとに、本当に求められている機能に集中し、優先的に開発を進めています。
仮説の精度を高めるために、ワークショップやユーザーインタビューを定期的に実施し、ユーザーの実際の課題やニーズを深掘りしています。こうした検証を繰り返しながら開発を進めることで、限られたリソースの中で最大の価値を生み出せるよう努めています。
ワークショップやインタビューの具体的な進め方については、また別の記事で詳しくご紹介する予定です。
4-1-2. 試行錯誤を前提にしつつ、拡張性を担保する
MVP開発では、試行錯誤を恐れず、素早く価値を届けることが重要です。初期段階では何が正解か分からないため、細かい仕様にこだわりすぎず、ユーザーに少しでも価値を提供できるのであれば試す、という柔軟なスタンスで進めています。
ただし、試行錯誤を重ねるからこそ、拡張性の確保も欠かせません。すべての機能を作り込むのではなく、将来的な変更や追加がしやすいように設計の柔軟性を持たせます。そのため、どこまで作り込むべきかは事前にチームで議論しながら進めています。
MVPとして開発を進める際、今後の拡張性をどこまで考慮するかはケースバイケースです。「とりあえず動けば良い」と割り切るのか、ある程度の変更を見越して設計しておくのかは、プロダクトの状況や開発の優先度に応じて判断する必要があります。
こうした判断に迷った際には、以下のフローチャートを指針の一つとし、「今回はどこまでやるか・何を捨てるか」を議論しながら進めています。
このように、ACES Meet の開発チームでは、試行錯誤を前提にしつつ、将来的な変更や拡張にも対応できる形を維持することで、スピードと継続的な進化のバランスを取ることを意識しています。
4-1-3. スピードと品質を両立するための開発方針
MVP開発ではスピードを優先する一方で、品質をおろそかにすると後のフェーズで修正コストが膨らみ、結果的に開発スピードを損なうリスクがあります。そのため、「スピードと質はトレードオフではない」という前提をチームで共有し、両立を前提とした開発を行うこと を重視しています。*3
たとえば、データモデルの設計やAPIのインターフェースなどの後からの変更が難しい部分は、序盤から適切に設計し最低限の拡張性を確保します。一方で、後から調整しやすい部分はスピードを優先し、短期間での改善が可能な範囲で進めることで、過度な作り込みを避けながらも品質を維持しています。
また、単一責任の原則を守ることで、コードの修正や拡張を容易にし、不必要なリファクタを減らすことを意識しています。責務を明確に分割することで、変更の影響範囲を最小限に抑え、開発のスピードを損なわない仕組みを構築しています。
加えて、チーム内では「スピードを維持しつつ、無駄な負債を抱え込まない方法」を学ぶ機会を設け、コードレビューやペアプログラミングを通じてナレッジを共有しています。さらに、判断に迷った際には、4-1-2で示したフローチャートを指針とし、意思決定の基準を統一することで、開発のスピードと持続可能性の両立を図っています。
4-1-4. 中長期的な借入（技術的負債）を「借入メモ」で管理する
ACES Meet の開発チームでは、Nealle さんの ソフトウェア開発における「借入」との上手な付き合い方 を参考にしながら、借入メモを活用した技術的負債の管理を試験運用しています。
「借入メモ」は、技術的負債を記録し、適切なタイミングで解消するための仕組みです。設計・実装時に「ここはスピードを優先する」と判断した場合、その背景や課題、関連URL、解決案をドキュメント化し、該当コードには以下のようなコメントを残しています。
# TODO: DEBT {日付} {ドキュメントのURL}
借入はリリース後できるだけ早く返済することを基本としつつ、優先度を見極めながら管理します。また、次回そのコードを触る際には、boyscout 的に改善を加えることも推奨し、負債の放置を防いでいます。
このように、MVP開発のスピードを維持しながら技術的負債を計画的にコントロールすることで、プロダクトの健全性を保つことを意識しています。
4-2. 試作車を完成車までアップデートするかどうかの意思決定
試作車 → 完成車では、試行錯誤を経た上でプロダクトのコアになり得るものを厳選し、完成形へと昇華させるフェーズに入ります。すべての機能を一律にアップデートするのではなく、ユーザーが本当に価値を感じているコア機能とその周辺に限定して取り組むことが重要です。
プロダクトを抜本的に刷新する試作車 → 完成車のフェーズはそれなりに時間とリソースを無駄を使う工程になるため、どこまでをアップデート対象とするかはユーザーの利用データやフィードバックをもとに慎重に判断する必要があります。
また、このフェーズでは、従来の延長線上での改良ではなく、抜本的な変革が求められる場合も多くあります。そのため、スクラップ & ビルドの必要性を受け入れ、開発チーム外の関係者（経営層・ビジネスチーム）とも事前に合意を取ることが重要です。
ここでの決断はプロダクトの中長期的な成長を左右するため、単なる技術的な判断ではなく、事業戦略の観点を含めて慎重に検討する必要があります。
5. おわりに
本記事では、MVP 開発における「手押し車から作る絵」の考え方をもとに、ACES Meet の開発方針を紹介しました。
手押し車 → 簡易トラック → 試作車のフェーズでは、本質的な価値にフォーカスし、スピードと品質の両立を意識しながら試行錯誤を重ねることが重要です。仮説検証を繰り返しつつ、拡張性を考慮し、技術的負債の管理を徹底することで、後のフェーズへの負担を最小限に抑えています。
試作車 → 完成車のフェーズでは、プロダクトのコアになり得るものを厳選し、必要に応じて抜本的な再設計を行うことで、最終製品に向けた進化を加速させます。従来の延長線上の改善にこだわらず、スクラップ & ビルドも視野に入れながら開発を進めています。
MVP 開発では、単に早く作るだけではなく、「何を開発し、何を開発しないか」を明確にし、適切な投資判断を行うことが重要です。
今後もこのアプローチを磨きながら、プロダクトの成長を支えていきます。
本記事を通して、ACES に少しでも興味を持っていただけた方は、ぜひカジュアル面談のお申し込みをお待ちしております！
ACES の採用情報はこちら↓
*1:https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp
*2:MVP - not "bike to car" ではそこまでは語られていないため、あくまでも私たちの独自の解釈です。
