こんにちは、株式会社ACES でテックリードをしている福澤 (@fuku_tech) です。
この記事では、私が所属する ACES Meet の開発チームが掲げる「フィードバックサイクルの高速化」という開発哲学について、その背景や具体的な取り組みをご紹介します。この記事を通じて、ACES Meetの開発チームの挑戦にご興味を持っていただいたり、皆様のプロダクト開発にとってご参考になる部分があれば幸いです。
- フィードバックサイクルとは何か
- 一般論としてのフィードバックサイクルの重要性
- ACES Meetにおけるフィードバックサイクル高速化の重要性
- ACES Meetにおけるフィードバックサイクル高速化の具体的な取り組み
- まとめ
フィードバックサイクルとは何か
ここで言うフィードバックサイクルとは、開発やリリースの各段階で得られるフィードバックを迅速に活用し、次の行動へ反映させるプロセスのことを指します。このサイクルが効率よく回るほど、価値提供までのリードタイムが短縮され、顧客に迅速に成果を届けることが可能になります。
具体的には以下のような項目が挙げられます。
- ローカル環境での確認: コードを実行し、テスト結果を即時確認します。Green/Red (成功/失敗) の把握で初期エラーを検出し、素早く修正につなげます。
- CI/CDによるテスト: 継続的インテグレーション環境でコードを検証し、品質を保証します。問題を早期に発見し、リリース前に修正することが可能です。
- Pull Requestのレビュー: 他の開発者からフィードバックを受け取り、コードの改善点を素早く反映します。
- 検証環境での動作確認: 実際の利用環境を想定し、期待する挙動が実現されているかを確認します。リリース前に問題を排除することができます。
- 社内でのドッグフーディング: 開発チーム自らプロダクトを使用し、実際の使用感から改善点を見つけ出し、顧客視点の課題を洗い出します。
- 顧客からのフィードバック: MVP (Minimum Viable Product) などを通じて顧客から直接得た意見を次の改善につなげ、プロダクトの方向性を調整します。
フィードバックは、上記のような段階ごとに発生します。これらの段階は、それぞれ異なる粒度でプロダクトの改善や価値提供を支え、いずれのフェーズでも「フィードバックを得るまでの時間を短縮すること」が鍵となります。この一般的な考え方は、ACES Meetにおいても同様で、顧客やビジネス要求に迅速に応えるためにフィードバックサイクルの高速化を最重要課題の一つとして掲げ、開発体制を整えています。
一般論としてのフィードバックサイクルの重要性
「フィードバックサイクルの高速化」は、単なる効率化ではなく、市場の変化に迅速に適応し続けるための重要な鍵となります。その有効性は、データに基づく研究結果で裏付けられると同時に、プロダクト開発現場での経験からも多くの示唆が得られています。
2.1. DORAの研究レポートが示す事実
DevOps Research and Assessment (DORA) による調査によれば、高速なフィードバックサイクルはプロダクトの成功に直結しています。
例えば、DORAの2024年の最新のレポートによると、パフォーマンスレベルがエリートのチームは「コードの変更から本番リリースまでのリードタイムが1日未満」であることが報告されています。*1
このような短いリードタイムを実現することで、競争の激しい市場でも迅速に新しい価値を顧客に提供することが可能になります。
これは、フィードバックサイクルの高速化が単なる「スピードアップ」ではなく、プロダクトが市場で競争力を保つための重要な戦略であることを示しています。
2.2. プロダクト開発における重要性
フィードバックサイクルは、開発チーム内の効率化にとどまらず、プロダクト全体の方向性を迅速かつ柔軟に調整する上で重要な役割を果たします。特に以下の2点で、その重要性が際立ちます。
- 顧客ニーズへの適応: 高速なサイクルによって顧客からの意見をタイムリーに収集し、改善へ反映できます。これにより常に市場の期待に応える状態を維持します。
- ビジネスサイドとの連携強化: フィードバックサイクルは、開発とビジネスの橋渡しとしても機能します。初期アイデアからリリース後の評価まで、継続的なコミュニケーションがプロダクトの方向性を正確に調整します。
このようにフィードバックサイクルの高速化は、常に変化する市場にプロダクトが適応し続けるために欠かせないアプローチです。次章では、ACES Meetがこの高速化を重視する背景について掘り下げます。
ACES Meetにおけるフィードバックサイクル高速化の重要性
ACES Meetは、商談や会議内容を可視化し、営業組織の強化を支援する営業DX×AI SaaSです。音声書き起こし、話者分割、トピック抽出、議事録自動生成、対話分析など、多岐にわたるAIアルゴリズムを組み合わせて価値を提供しています。
さらに、ACES Meetはリリースから2年半ほどの比較的新しいプロダクトであり、市場からのフィードバックを受けながら進化を続けています。
このような特性を持つACES Meetにおいては、一般論としてのフィードバックサイクルの重要性に加え、以下の2つの理由からフィードバックサイクルの高速化を重視しています。
3.1. PMFを目指すプロダクトとしての挑戦
ACES Meetはまだ完全にPMF (Product-Market Fit) を達成していない段階にあります。そのため、顧客ニーズや市場動向を迅速に捉え、改善を繰り返すことが極めて重要です。特に市場からのフィードバックを素早く仮説検証へと反映し、プロダクトの進化を加速させることが欠かせません。
プロダクト開発において、成功するアイデアと失敗するアイデアを見分けることは非常に難しいとされています。多くのケースでは、どの機能や改善案が市場に受け入れられるかは事前に予測がつきにくいため、試行錯誤を繰り返しながら学んでいくアプローチが求められます。この点について、以下の記事で次のように指摘されています。
これらのことから、人間は基本的に、成功するアイデアと失敗するアイデアを見分けることが得意ではないということがよくわかる。長年、ソフトウェアプロダクト開発に携わっていれば、これに頷ける。プロダクトのアップデートを何度繰り返しても重要指標が一向に改善されないことや、自信を持ってローンチした新機能がほとんど使われないといった経験を重ねてきただろう。
このような背景を踏まえ、ACES Meetでは「とにかく多くの打席に立つ」姿勢を重要視しています。効率的なフィードバックサイクルを活用し、迅速な仮説検証を通じてプロダクトを市場に適合させる取り組みを進めています。
3.2. AI開発の不確実性への対応
AI機能はその特性上、精度や性能を事前に予測することが難しく、不確実性への対応が求められます。PoC (Proof of Concept) での仮説検証や、実運用環境での予期せぬ挙動への迅速な対処が必要です。また、ビジネスサイドとの密接な連携を通じて、技術的な不確実性を早期に解消し、顧客に求められる価値を確実に届ける取り組みが重要となります。
こうしたPMFへの挑戦とAI特有の不確実性を背景として、ACES Meetはフィードバックサイクルの高速化を、プロダクトの進化と競争力維持のための戦略的要素と位置づけています。
ACES Meetにおけるフィードバックサイクル高速化の具体的な取り組み
ACES Meetでは、フィードバックサイクルを高速化するため、フィードバックを「フィードバックサイクルを高速化するための取り組み」と「フィードバックを最大化するための取り組み」の2つの視点から捉え、短期間でのプロダクト進化や市場ニーズへの柔軟な対応を実現しようとしています。
4.1. フィードバックサイクルを高速化するための取り組み
ACES Meetの開発チームでは、設計、実装、テスト、デプロイの各段階でサイクルを効率的に回し、開発プロセス全体の速度を向上させる取り組みを進めています。これにより、アイデアの具現化から実装、リリースまでを短期間で繰り返し、プロダクトの進化を加速させています。この章では、それぞれの段階での具体的な工夫や改善策について簡単にご紹介します。
4.1.1. 初期アイデア段階からの設計レビュー
開発前キックオフで要件を明確にし、懸念点を洗い出したうえで設計方針を議論します。以下の取り組みを通じて設計段階での問題を早期発見し、後続工程での手戻りを最小限に抑えています。
- 要件確認や懸念点の洗い出しを行い、設計方針を議論する。
- ペアでの設計とタスク分解により、作業の粒度を細かくする。
- 週1回の設計レビュー会で進行中の設計や実装について壁打ちとフィードバックを行う。
- SlackのHuddle機能を活用して、即時的な相談と議論を可能にする。
4.1.2. 小さなPull Requestの徹底
一度に扱う変更量を最小限に抑えたPull Requestを作成することで、レビューと修正の迅速化を実現しています。
- 変更量を抑えた小規模なPull Requestを作成することで、レビュー効率を向上させる。
- タスク分解を徹底し、Pull Requestは1つの変更に限定する。
- レビュアーが素早く変更内容を把握できる状態を保つことで、レビュイー・レビュアー双方の負担を軽減する。
詳細については以下の記事をご覧ください。 tech.acesinc.co.jp
4.1.3. CIの高速化
継続的インテグレーション (CI) では「5分以内で完了」を目標に定期的な改善を行っています。以下のアプローチにより、全体のテスト時間を短縮しています。
- Slow Testsを撲滅し、CIのボトルネックを解消する。
- GitHub Actionsのmatrix機能を活用してテストを並列実行する。
- Rust製のLintツールを導入し、数秒で完了するコードスタイルチェックを実現する。
これらの具体的な改善内容については、別の記事で詳しくお伝えする予定です。ぜひご期待ください！
4.1.4. デプロイプロセスの改善
以前はデプロイ前の準備や実行に多くの手間がかかり、開発者にとって負担が大きいプロセスでした。この課題を解決するため、特定のブランチに変更をマージするだけで自動的にデプロイが実行される仕組みを整備しました。
さらに、マイグレーションファイルに変更がない場合には該当工程をスキップする仕組みを導入することで、デプロイ時間を短縮しました。特にSandbox環境ではデプロイ頻度が高いため、この改善によりデプロイの回転数が大幅に向上し、開発フロー全体の効率化に貢献しています。
4.2. フィードバックを最大化するための取り組み
ACES Meetでは、顧客やステークホルダーからの意見を迅速に収集し、それをビジネスサイドとの連携を通じて即座にプロダクトの方向性へ反映しています。この取り組みにより、フィードバックを迅速に次のアクションへとつなげる仕組みを構築し、顧客ニーズに適応したプロダクト開発を加速させています。
4.2.1. ワークショップの開催
社内のステークホルダーを対象に、定期的なワークショップを実施しています。この場では、利用者が直面している業務上の課題や背景、具体的な影響を詳細に共有し、それらを解決するための最適なアプローチを議論します。たとえば、営業やカスタマーサポート部門が抱える課題を可視化することで、プロダクトがどのように貢献できるかを具体化し、開発テーマの優先順位を整理しています。
この取り組みは、単なる課題共有にとどまらず、ステークホルダー全体で仮説検証を推進する場として機能しています。結果として、開発テーマやプロダクト戦略が明確になり、チーム全体で共通認識を持ちながら迅速な意思決定を行う体制を構築しています。
4.2.2. リリース前の検証
リリース前の検証プロセスでは、開発前と開発後の2つの段階でフィードバックを収集し、プロダクトの完成度を高める取り組みを行っています。
開発前
開発に着手する前の段階では、UIデザインやプロトタイプを活用してステークホルダーからフィードバックを収集しています。開発者、PdM、デザイナーだけでなく、営業やCSとも積極的に壁打ちを行い、認識のすり合わせを徹底しています。特にAI機能の場合は、プロンプトと生成結果を確認できる簡易画面を活用することで、具体的なフィードバックを得る環境を整えています。この段階では、実装というコストの高い作業を進める前に可能な限り課題を洗い出し、仕様の精度を高めることを重視しています。
開発後
完成したプロダクトについては、営業やCSに実際に触ってもらい、使用感の確認を行います。特に以下の観点でフィードバックを収集しています。
- 実際の業務で使用する際に違和感がないか。
- 他の機能と組み合わせてシームレスに利用できるか。
また、収集したフィードバックをもとに、リリース前に修正可能な課題については即座に対応し、可能な限り最適な形で顧客に提供できるよう準備を整えます。
4.2.3. MVPのリリース
ACES Meetでは、MVP (Minimum Viable Product) のリリースを通じて、必要最小限の機能を持つプロダクトを早期に市場へ投入し、顧客からのフィードバックを迅速に収集することを重視しています。これは、3.1節で述べた「何が成功するか分からない」という前提に基づいており、提供したいユーザー体験や解決すべき課題の本質を見極めるための重要なプロセスです。
このアプローチでは、下図の下段一番左の絵のような手押し車からスタートして徐々に肉付けしていくように、まずは最小限の形で価値を届けることを目指します。*2
提供する体験や解決する課題の方向性が正しければ、それを強化する形で進化させ、間違っていれば迅速に次の仮説を検証する足掛かりとなります。
また、仮説を大きく外さないようにするためにも、4.2.1で述べたワークショップや、4.2.2で実施するリリース前の検証といった工程を大切にしています。これらを通じて、ステークホルダーの声を早い段階で収集し、仮説の精度を高める工夫を重ねています。
まだまだ課題は多く、すべてが完璧にワークしているわけではありませんが、試行錯誤を重ねながら改善を図っています。
4.2.4. ユーザーインタビュー
定期的にユーザーインタビューを実施し、現在のプロダクトが顧客にとって本当の意味で価値を提供できているかを確認するようにしています。
インタビューでは、ACES Meetを利用することで顧客のKGIやKPIが改善につながっているかをヒアリングし、プロダクトが業務上の課題解決や効率化にどの程度寄与しているかについてフィードバックを収集しています。これにより、プロダクトの現状を顧客視点で見直し、さらなる改善のための材料としています。
なお、顧客とのACES Meet導入前の商談や導入後のCS活動、ユーザーインタビューの内容はすべてACES Meetに記録されています。これにより、初期の課題から利用後の変化までを一元的に管理でき、後からの振り返りや分析も容易に行える環境が整っています。
まとめ
本記事では、フィードバックサイクルを高速化することの重要性と、ACES Meetのプロダクトチームがそれをどのように実現しているかをご紹介しました。
今後もこの取り組みを進めることで、ACES Meetは顧客に求められる機能と体験をスピーディに届け、常に進化し続けるプロダクトを目指していきます。
本記事を通して、ACESに少しでも興味を持っていただけた方は、ぜひカジュアル面談のお申し込みをお待ちしております！
ACESの採用情報はこちら↓ youtrust.jp
