2025-04-25

業務の不を炙り出せ！〜BizとProductで共創するワークショップ〜

エンジニアリングマネージャー兼プロダクトマネージャーのkobaanです。最近暖かくなってきましたね。そして花粉の季節・・・私は舌下治療のおかげでだいぶ軽減されましたが、それでも目の周りはとってもひどい状態になります。花粉も早く落ち着いてほしいところです。

記事のご紹介

今日は誰にでもできる、業務プロセスの不を発見しプロダクトに装着できるやり方をご紹介できればと思っています。

記事のご紹介
あらためてACES Meetとはなにか
営業活動における不をどう洗い出すか
- 具体的な課題をどう抽出していくか
業務プロセス課題をあぶり出すフレーム化
自分が描けなければみんなに描いて貰えばいいじゃない
- ワークショップを実施してみたら・・・いっぱい書いてくれた
- ワークショップでどんなファシリテートをおこなったか？
結果
PdMやエンジニアを募集しています！

あらためてACES Meetとはなにか

ACES Meetは、高精度な文字起こしと高度な要約が実現できるAI議事録ツールです。

AI議事録ツールは、①会議の議事録を作りたい、②会議の情報を他の活動に繋げたい、という大きく2つのニーズに別れています。

この2つのニーズは重なる部分が大きく、私たちは両方のニーズに応えられるツールにしていきたいと考え、日々開発を行っています。

特に、②の繋げていく他の活動は「営業活動」でして、世の中の営業生産性を大きく向上させるツールに進化させ、名実ともにAI議事録ツールからAIセールステックツールに進化させていきたいと考えています。

営業活動における不をどう洗い出すか

以前テックブログに寄稿していましたが、弊社事業責任者の中川が、PdMの主に戦略部分を担っており、その過程で解決したい業務のプロセスを簡易に記載しています。

tech.acesinc.co.jp

具体的な課題をどう抽出していくか

冒頭EM兼PdMと記載していますが、実はエンジニア→PjM→EMと登ってきているのでPdMのような経験はほぼしていません。

人生経験はそれなりにはありますが、PdMはセンスとひらめきが支配する職能だと思っていましたし、特に今関わっているACES Meetというプロダクトがセールステックツールということで目指しいてる営業領域でのディレクションもほぼしてこなかったため、どのように理想を描いてきながら実装していくか、といった自分の経験値不足から派生する課題感はついて回りました。

そのため、商談報告・・・何それ美味しいの？状態だったことは言うまでもありません。

今思うと、恐ろしいぐらいのドメイン知識不足だったと思います。

業務プロセス課題をあぶり出すフレーム化

困った時は思い込みで進めすぎず~~周囲に助けて〜と頼る~~ステークホルダーを巻き込むのがベストプラクティスだと信じていますので、早速~~助けていただく~~巻き込むためのフレーム整理に向かいました。

大事なことは以下の3つと捉えて、フレームに整理し直しました。

何を解決したいのか？といった要求を整理すること。
そしてその要求は、理想と現実のGAPから生まれること。
現実は、現状の機能に縛られすぎないこと。

そしてそれぞれを業務ごとに解析できたら、明確化されるのではないかと考えたとき以下のようなマッピングで整理しようと思い立ちました。

自分が描けなければみんなに描いて貰えばいいじゃない

by マリーアントワネット

ここから先は（個人的にとても大事だと思っている）ステークホルダーを巻き込むフェーズに入ります。今回、我々のプロダクトはラッキーなことに営業活動の効率化と受注増を目指した時に、ユーザーと我々のセールスの悩みが近いので、彼らにお願いしたところ二つ返事でOKをいただきました。プロダクトが高機能化することは自分たちの業務の非効率性も顧客の悩みも解消していくので一挙両得だったのもあると思っています。普段あまり使わないFigjamを使っていただく形だったので、みなさんの下準備もフォローしました。忙しい中で時間を食いすぎないように非同期でお願いするのは若干の忍びなさを感じましたので、もしお試しする際は5〜10分くらいMtgの中でケアするのも良いかもしれません。

ワークショップを実施してみたら・・・いっぱい書いてくれた

ワークショップでどんなファシリテートをおこなったか？

特定のプロセスに対して7分くらいで自由に付箋で書き込んでもらう
一人一人に特に意図を持ったものを複数共有・発表してもらう
1. 気になった発表については質疑で深掘り
次のプロセスへ

1.については、同期的に実施することをお勧めしたいです。

今や回数をこなしてきたので参加者のメンバーは非同期で記載してきていただく、という手法もとっていますが、どんなことを書いたら良いですかというリアルな質問や、集中して記載するということの大事さ、一つ前のプロセスでの発表・共有内容からの気づきなどがあるため、同じタイミングで実施するのが大事だなと感じています。

2の話を伺うのが大事で、その話を伺うことで業務に対する理解度が一段上がると思っています。あと個人的に、業務の不を聞いててあーこれはこう解決できそうだなみたいなのを考えてる瞬間がとっても楽しかったので、そんな人にはおすすめです（笑

結果

まずワークショップから複数の案件候補が生まれ、セールスメンバーも納得のいくユーザーストーリーが生まれました。

また、複数の業務プロセスに対して要求の抽出を行っていく上で、社外の方にもドメイン知識を借りてワークショップを実施することもあり、かなりプロダクトとして強くなっていく未来が見えたと感じています。

デスクトップリサーチが通用しないので、準備や実施に時間がかかってしまいますが、確度の高い要求を絞り出すことができるため、これからも重宝していきたいと考えています。

PdMやエンジニアを募集しています！

youtrust.jp youtrust.jp

2025-04-11

よくある質問を事前に解消！ChatPlusで高める問い合わせ自己解決率

ACES Meet CRE 問い合わせ ChatPlus

あいさつ

はじめまして、ACESでCREをしている村上です。

年末からトレーニングと体のメンテナンスを兼ねて定期的にピラティスをやるようにしていたのですが、この前会社で「背伸びた？」と聞かれました。やはり姿勢と継続は大事です。

前回の記事では、CREの取り組みとして 顧客の現状を把握する や 顧客の問題を取り除く ための方法をご紹介してきました。

今回の記事では、CS工数削減 の文脈で重要視されている 「問い合わせ自己解決率の向上」 について、実際に行った施策と今後の展望をお話しします。

自己解決率が高まると、利用中に顧客がスムーズに疑問を解消できるだけでなく、CSチームのサポート工数を削減できるため、二重の意味で大きな効果が期待できます。

今回は問い合わせ自己解決率向上に向けた取り組みとして

ChatPlusを活用したサポートページへの誘導
自己解決率の計測とチャットボットの改善
今後の展望: AIチャットボット導入

の3つに分けて紹介しようと思います

① ChatPlusを活用したサポートページへの誘導

最初に取り組んだのは、ChatPlus を活用したサポートページへの誘導です。

問い合わせの中には

顧客が抱えがちな「よくある質問」でかつ
サポートページで解決可能

なものがいくつかありました。

そこでまずはそういった質問に対してチャットボットを経由する中で分類し、対応するサポートページに誘導することで自己解決してもらうことを目指しました。

チャットボットの分岐はかなり数が多いのですが、ChatPlusツリーエディタ機能のおかげで直感的な編集ができました。

② 自己解決率の計測とチャットボットの改善

チャットボットからサポートページに誘導できるようになりましたが、これだけではどの程度チャットボット経由で自己解決できているのか把握することができず、そのために改善を回すことが難しいという問題が残っています。

そのため、次に自己解決率の測定に取り組みました。

自己解決率の測定方法

まず自己解決率を測定するにあたって、チャットボットの表示を3つに分類しました。

分岐: 「はい/いいえ」など、ユーザーが選択肢を選ぶ部分
回答: サポートページのリンクや簡単な回答を表示する部分
問い合わせフォーム: 問い合わせを送信するためのフォームを表示する部分

チャットを開いたユーザーには「分岐」→ (「回答」) → 「問い合わせフォーム」の順で表示されるようになっています。

このうち、どの部分で離脱したかを数値化して記録しています

分岐での離脱: チャットの内容がわかりにくいため離脱してしまった
- 自己解決できていない
回答での離脱: サポートページの内容を見て問題が解決できた
- 自己解決できた
問い合わせフォームでの離脱: 解決しないがフォームの記載が面倒になった
- 自己解決できていない

現状は回答部分で離脱した場合のみ自己解決したとみなしています。

問い合わせ内容の分析と改善

自己解決率と合わせて実際にチャットから来た問い合わせの内容を記録しています。

その内容を元に特に多かった質問について

サポートページを追加する
分岐を追加・修正する

などの対応を定期的に行い自己解決率の向上に繋げています。

このように、数値を測定し、その結果をもとにチャットの設計をアップデートする PDCAサイクルを回すことで、自己解決率向上を狙っています。

③ 今後の展望: AIチャットボット導入

上記の取り組みだけでもよくある質問への対応は可能ですが、より幅広い問い合わせに対応していくには限界があります。

今後は、AIチャットボット を導入して、ユーザーの多彩な質問にも自動で返答できる仕組みを検討中です。

ACESではオリジナルのAIエージェントを作成するための環境も整っているのでそれをうまくChatPlusと組み合わせられるようにしていきたいと考えています。

まとめと今後の取り組み

問い合わせ自己解決率 は、顧客が利用中にスムーズに疑問を解消できるかどうかを示す重要な指標です。

自己解決率を高めれば、顧客体験の向上 と CS工数削減 の両立が可能になります。

チャットボットの分岐設定でよくある質問を効率的に潰す
自己解決率や問い合わせ内容を定量的に測定し、改善サイクルを回す
最終的にはAIチャットボットの導入で、より多様な質問にも対応できる体制を目指す

これらの取り組みを通じて、私たちは CS組織の業務効率化 と 顧客満足度の向上 に挑戦していきます。

ACESでは一緒に顧客体験の向上をおっていけるエンジニアの方を募集しています！

少しでも興味を持っていただけた方は、ぜひカジュアル面談のお申し込みをお待ちしております！

ACESの採用情報はこちら↓

youtrust.jp

2025-04-04

Cursor AIエージェントによる既存コードのアップデート戦略

ACES Meet 開発プロセス

こんにちは、株式会社ACES でテックリードをしている奥田(@masaya_okuda)です。

AIエージェントを活用し、自然言語による指示を中心にコーディングする手法が注目を集めています。特にゼロからコードを書く場面では、その効果の高さは多くの現場で実感されているのではないでしょうか？

私たちもこの可能性に注目し、AIコードエディター「Cursor」をフルタイムの開発チームメンバー全員に導入。日々の開発でAIエージェントの活用を積極的に進めています。

一方で、既に運用中のサービスを開発しているチームにとっては、既存コードの文脈を理解させた上でどう活用するかが大きなテーマとなります。本記事では、そうした既存コードのコンテキストを踏まえたAI活用の実践について紹介します。

開発チームの前提と課題

私の所属する開発チームはAI議事録ツール「ACES Meet」を開発しています。このプロダクトは数年にわたって積み上げられてきたコードベースがあり、以下のような課題が存在しています。

異なる時期に導入された実装スタイルの混在
フレームワークの仕様変更によるディレクトリ構成のばらつき
明文化されていない暗黙のコーディングルール

「今後はこのスタイルで書こう」といった最新ルールは決めているものの、古い実装が残っていることで新しいメンバーが迷ったり、AIが非推奨の実装を参考にしてしまうことがありました。

このような背景から、「AIと人間が同じルールを理解・適用しながら開発する」という共通基盤の必要性が強くなってきたのです。

AIエージェント活用の方向性

以前はGitHub Copilotを使っていましたが、プロンプトに多くの補足や説明を付け加えないと意図通りに動いてくれず、AIにコーディングを任せるには手間が大きい印象でした。

AIコードエディター「Cursor」はリポジトリ全体を事前スキャンし、AIがコードベースの文脈を把握した状態でサジェストや修正を行えるため、期待通りのアウトプットを得やすくなりました。また、特定のファイルを“参照”として明示的に渡せる操作性も非常に優れており、ガードレール付きのAI活用が現実的になりました。

この環境を活かし、私たちは以下の2つを重点的に進めています

コーディングルールの整備と活用
古いコードのリファクタリングをAIエージェントで効率化する

実践①：コーディングルールの整備と活用

最初に取り組んだのは、開発チーム内で使用するコーディングルールの整理と明文化です。私が主に領域とするフロントエンドにおいては、以下のようなルールをまず明文化しました。

新しいページの構造と作成方法
コンポーネントの構造と作成方法
サーバーサイドAPIとの通信方法
ユニットテストの基本方針

コーディングルールの具体例

たとえば、Next.js（App Router構成）で新しいページを追加する場合、以下のようなルールと実装方法定めています。

# Pageの実装方法

ページのエントリーポイントとなるpage.tsxの実装方法について記載します。

## ディレクトリ構成

app
├── (authed) // 要認証画面
│   ├── initial-settings
│   │   ├── page.tsx
│   │   ├── styles.module.scss
│   │   └── usePage.ts
├── (authless) // 認証不要画面
├── layout.tsx

## 各ファイルの役割

- `page.tsx`
    - Mustで必要なエントリーポイントのtsxファイル
- `styles.module.scss`
    - page.tsxにスタイルを当てるためのSCSSファイル
- `usePage.ts`
    - page.tsxで使うuseStateやuseCallbackなどロジックを配置するtsファイル

## 作成手順

例えば、`src/app/(authed)` 配下に新しく`watchlists` というページを新規作成したい場合、以下の手順で実装します。
1. ディレクトリだけをまずは作る
    1. `src/app/(authed)/watchlists`
2. このディレクトリの相対パスをコピー
3. ページの雛形実装コマンドを実行
   1. `npm run generate:page`
   2. 1つ目の質問で `src/app/(authed)/watchlists` をペースト

AIエージェントが実行する場合は、バックグラウンド処理を介さないよう以下の手順で実行してください。
1. ディレクトリだけをまずは作る
    1. `src/app/(authed)/watchlists`
2. ページの雛形実装コマンドを実行
   1. `npm run generate:page:ai --path="src/app/(authed)/watchlists"`

フロントエンドではscaffdogというライブラリを使っており、ページの雛形を1コマンドで生成できるようにしています。

このようなドキュメントをAIに渡すことで、「ルールに沿ってこの箇所を書き換えてください」といった明確な指示が可能になり、AIの出力の一貫性を高めることができます。また、scaffdogコマンドの実行で作成される雛形がガードレールとなり、不要なファイル分割を回避することができます。

実践②：古いコードのリファクタリングをAIエージェントで効率化する

コーディングルールを整備した後は、人間もAIもミスリードの原因となる古いコードを、最新のコーディングルールに基づいて修正させる取り組みを進めました。

従来であれば「リファクタリング週間」などの名目で人手によって地道に修正していた作業を、AIエージェントを使って継続的かつ効率的に行えるようになりました。

私はよく以下のステップでリファクタリングしています。

まず「何をどのように修正するのか？」というゴールとステップを明確にする
AIエージェントにコーディングルールを渡しつつ、1ステップずつ期待結果を出力できるか確認する
期待通りでない場合は、プロンプトをチューニングする
成功した修正指示をテンプレート化し、1箇所を一気通貫で修正させる
修正対象を範囲指定し、一括でリファクタリングさせる

プロンプトの具体例

以前は、__tests__ディレクトリに分離してテストを書くルールでしたが、コードジャンプが必要で実装とテストの行き来が面倒といった課題がありました。最新のルールでは、xxx.test.ts のように実装と同じ階層に置くように変更しました。ですが新メンバーやAIが古いルールに倣ってしまうケースがあり、最新のルールに全実装を揃えたいと考えていました。

最終的なプロンプトは以下のようになります。

ユニットテストを実装と同階層に配置するリファクタリングを行います。

まず私に移動対象のディレクトリを質問してください。
そのディレクトリに複数のテストファイルがある場合は、1ファイルずつ下記のステップをすべて実行し、完了後に次のファイルに進んでください。

1. ユニットテストが対象とする実装をsrc/xxx/yyyから探してください
2. @unit-test.mdを参考に、実装と同階層に移行してください
3. 実装ファイルとテストファイルの両方のimportの定義を、@import.mdを参考に修正してください
4. `npm run typecheck` を実行し、エラーしないことを確認してください
5. 移動したユニットテストを実行しテストが通ることを確認してください
6. `npm run check` でフォーマット後、Gitでコミットしてください

ポイントはコーディングルールのドキュメントを参照させることで、プロンプトの具体記述を省けることです。指示実行後はしばらく放置し、適当なところでPR作成 → レビューすれば完了です。Cursorは通常の課金では25 Callで止まってしまうため、プロンプトが組み上がった後は従量課金でひたすら実行し続けるタイプと相性が良いと思います。

また、途中で静的解析やLint/Formatを挟むことでミスがある場合はAIエージェント自身が修正を試みます。細かく挟む際には、BiomeやVitestのように高速に実行できるツールを選定しておくと効率的です。

このようにして、AIに“回し続けるリファクタリング”を任せ、人間はレビューと承認に集中するという体制を整えました。

AI導入の成果と今後の展望

こうした取り組みを通じて、開発体制に以下のような変化が生まれました。

コーディングルールというガードレールを軸に、AIと人が同じルールを守れる状態に
タイミングを選ぶ必要があった古いコード修正を、気軽に一括でリファクタリング可能に
AIにコードベースのコンテキストを踏まえて、狙った出力をさせるナレッジが蓄積

AIが守りやすいルールは同時に人間も守りやすいため、これまで新しいメンバーが入るたびに、「どこを参考にすればわからない」という課題が解決に向かいました。また、リファクタリングのほとんどはAIに任せることができるため、従来の「リファクタリング週間」などは新しい技術や開発手法を試す、といった別の時間に充てることができます。

今後はここまでのナレッジを活かして、以下の3点に注力していきます：

新機能開発の最適化：仕様書＋ルールをAIに与えて、期待通りの新実装を生成するプロセスを確立
ルールとドキュメントのアップデートの自動化：AIにとって理解しやすい構造・命名に合わせて、ルール自体も最適化し、更新もAIに任せていく
他領域への展開：フロントエンドで得た知見をバックエンドやその他の開発領域にも水平展開

まとめ

ここまで、既存コードのコンテキストが複雑に混在する現場で、AIエージェントを活用した開発効率化の取り組みをご紹介しました。日進月歩でAIエージェントも進化するため、ご紹介した内容ももう古いかもしれません。

テックリードだけでなく、現場のエンジニア1人1人が日々活用方法を試しながらチームに展開することが重要と考えていますし、そこにきちんとコストを投下できる環境です。ACES Meetの開発チームだけでなく、全事業部のエンジニアへのCursor配布や、全社エンジニア横断でAI活用LT会なども行っています！

本記事を通じてACES Meetの開発チームにご興味をお持ちいただけましたら、ぜひカジュアル面談でお話ししましょう！

ACESの採用情報はこちら↓

youtrust.jp

2025-03-14

“PdMは一人が全部やる”は限界？複数PdM体制で得られた成果と学び

自己紹介

初めまして。株式会社ACES でACES MeetのPdM業務を担っている中川(@ShuNakagawa) です。

数年前から再開したゴルフで、フックボール（強く左に曲がるボール）に悩まされていて、ゴルフそのものが嫌いになってしまいそうです（とはいえ、ゴルフ場に行ってしまえば楽しくて、またい行きたい！と思うのですが）。仕事も出来る限り綺麗なストレートボールや、突進力の高いドローボール（緩く左に曲がるボール）で攻めていきたいです。

パットが大事？わかります。でも、私は素人ですからショットを楽しむことにします（笑）

はじめに・ACES Meetとは何か

まず、ACES Meetの紹介をさせていただきます。

ACES Meetは、書き起こしも要約も高精度なAI議事録ツールです。

AI議事録ツールは、①会議の議事録を作りたい、②会議の情報を他の活動に繋げたい、という大きく2つのニーズに別れています。

この2つのニーズは重なる部分が大きく、私たちは両方のニーズに応えられるツールにしていきたいと考え、日々開発を行っています（私は非エンジニアなので、正確には「日々開発を行ってもらっています」）。

PdMは何をやる人なのか

さて、このブログではPdMについて書いていきますので、ACES Meetの開発におけるPdMの役割も説明します。

その前にインターネットやChatGPTにPdMの役割を聞くと、以下のようにスーパースター・こんな人いるの？年収いくらで採用できるの？と思うような広大な役割を定義してきます。

プロダクト戦略
ユーザーリサーチとニーズの把握
開発ロードマップの策定
開発チームとの協働
事業成長と収益化
ステークホルダーとの調整

特に、プロダクトを開発していく能力・スキルと、事業成長と収益化のスキルとを、同時に高度な水準で身につけることは、一般的なキャリアでは困難ではないでしょうか。

プロダクト開発の能力・スキルに限ったとしても、プロダクト戦略を立案しながら、足元のユーザーリサーチとニーズの把握や開発チームとの協働を、一人の人物が両立させ続けることは難しいケースが多いと思われます。

この様に一人でPdMの役割を取り仕切っていくのは非常に難しいと判断し、私たちは上記のPdMの役割を複数人で分担して実施することにしています。ですので、今、ACES Meetのチームには複数人のPdMが存在しており、私もその内の一人です。

恐らく、ACES Meetチームだけでなく、上記のPdMの役割を複数人で分担しながら企業・事業・チームも多いのではないでしょうか。少なくとも、厳密に全ての役割を一人で実施することは難しいと思いますので、大なり小なりは複数人で分担しているのではないかと思います。

どの様にPdMの役割を区切っているか

それでは、どの様にPdMの役割を分担・区切っているかを説明したいと思います。

大きく、A. プロダクト戦略・方針の検討に近い部分と、B. 具体的な開発テーマの検討で区切っています。

なお、「戦略」という言葉も広い意味合いがあります*1が、ACESでは「戦略＝優先順位を付けること」と定義しています。

例えば、経営戦略は「会社の成長・収益性向上のための、経営リソースの投下先の優先順位を付けること」で、プロダクト戦略は「プロダクトの成長・提供価値増大のための、開発リソースの投下先の優先順位を付けること」と考えます。

A. プロダクト戦略・方針の検討

まず、A. プロダクト戦略・方針の検討が具体的にどの様を作業しているかを説明します。

このプロダクト戦略・方針の立案は、事業全体の戦略を踏まえて、「どの様な顧客の・どの様な課題を・どの様な順番で・このくらいの経営リソースで」解けるだろう、ということを考えます。

プロダクト戦略だけでないと思いますが、戦略・方針の立案は非常に多くの情報を取捨選択しながら、それでも論理的な意思決定ができないことも多く、全ての要素を積み上げて作るものではなく、大きな要素が整合しているか・大きな方針として納得感があるかがポイントになります。

そのため、ここで想定する必要な経営リソース量は根拠があるものではないので、具体的な開発テーマ・開発計画が決まり、必要な経営リソース量が出てきた段階で、すり合わせを行い優先順位の見直しを行うことになります。

戦略・方針の検討イメージ：一見すると関係なさそうな事から、一つの方針を導き出す（ACESのコーポレートVISION）

B. 具体的な開発テーマの検討

次に、B. 具体的な開発テーマの検討ですが、開発テーマは大きく2つに分類することができます。

一つがプロダクト戦略を実現させるテーマ（B-1）。もう一つがユーザー様からのVoC*2・エラーに対応するテーマ（B-2）。

B-1. プロダクト戦略を実現させるテーマは、プロダクト戦略上で優先的に解くことになった「顧客の課題」を「どの様な業務プロセスで・どの様な機能で」解決するかを考えます。

B-2. VoCの実現・エラー対応の開発テーマは、VoC・エラーが「どこで・何が・なぜ」発生しているかを考え、不満・エラーであれば解消する仕組みを、希望であれば実現する仕組みを考えることになります。

そして、ここまで来ると必要な経営リソースが根拠のある形で見積れるので、戦略・方針の検討を行っているPdMと経営リソース・開発スケジュールのすり合わせを行います。

PdMの役割を分担してみてどうなったか

結論から言うと、複数人でPdMの役割を分担してプロダクト開発が円滑になったと感じています。

PdMの役割をプロダクト戦略の立案から具体的な開発テーマの決定まで幅広くして、一人のPdMで担当すると以下の様な不都合な事が起きていました。

PdMになるために、多くの経験やスキルが必要となり、そもそも、PdMのなり手がいない。
頭・時間の使い方が全く異なるため、A. プロダクト戦略・方針の検討と、B. 具体的な開発テーマの検討とで、何度も頭の切り替えが必要になったり、検討時間の偏りが出てしまう。
PdMに権限が集中しすぎ、様々な面で属人性が高くなってしまう。

何事も最後は誰か一人が意思決定をする必要がありますが、事業経営にはできる限り多くの視点を取り入れ、論理的・合理的にディスカッションを積み重ね、多くのメンバーの納得感を持って進めることが重要だと考えています。

実際、複数人で役割分担をするために、戦略・方針を具体的にしたり、スライドや文書を作成したしたり、メンバーに共有する活動の中で、プロダクトビジョン・ロードマップ・コアバリューなどを作ったりしました。

また、具体的な開発テーマの決定ではワークショップを実施したりするなど、様々な仕組みを作ってきました。そして、この仕組みが一定上手く回りだしてからは、チーム全体としてレベルアップできている感覚が強くなっています。

PdMの役割を分担してわかったこと

これらのPdMの役割分担を進める中で、いくつかわかった事がありますので、最後にわかった事・思っている事・今の課題を共有して終わりたいと思います。

わかった事① : 必要な作業工数の違い

1. 戦略・方針を検討するPdMの作業工数はそこまで必要ではありませんが、具体と抽象を行き来することが求められるため、進まない時は全く進みません（笑）。
逆にB. 具体的な開発テーマの決定は作業工数が膨大に必要になります。具体の世界で作業を積み上げていく必要があるので、全く進まない事は少ないですが、絶対的に作業工数が必要になります。

わかった事② : 相性が良い頭の使い方・スキルの違い

1. 戦略・方針の検討は一般的に右脳的な頭の使い方が多いと感じています。抽象的な概念で考えたり、複数の要素を統合して新しい概念を生み出すことが多く、また優先順位が論理的に決められれば良いのですが、エイヤッ!!で決める場合もあります。ですので、良い意味で真面目すぎない方が向いているのではないかと考えています。
逆にB. 具体的な開発テーマは左脳的です。具体的な目の前の課題を見つめ、具体的・現実的に業務プロセスと機能を考え、共通認識が取れる要求定義・ユーザーストーリーを作っていきます。出来る限り論理的に説明することが求められますし、真面目にコツコツと作業を積み上げられる方が向いていると考えています。

思っている事 : ACES Meetチームでの名付け方

完全にミスってしまった笑い話ですが、ACES Meetチームでは、A. 戦略・方針を検討するPdMを「左のPdM」、B. 具体的な開発テーマを検討するPdMを「右のPdM」と読んでいます。
これはPdMの役割分担を試行錯誤している際に、プロダクトビジョンや戦略から具体的な開発テーマがどの様に繋がっているかをPPTXのスライドで整理している中で、プロダクトビジョンや戦略を左側に配置し、具体的な開発テーマを右に置いていたからです。
ただし、わかった事②で記載したように、頭の使い方としては戦略・方針が右脳的で、具体的な開発テーマが左脳的で、PdMの名称と頭の使い方が逆になってしまっています。
私は密かにPPTXのスライドの左右を逆転させてやろうと目論んでいるのですが、経営会議や人事のメンバーにも共有してしまっているため、なかなかチャンスが訪れません。どうしたものか、、、といつも思っています。

今の課題 : プロダクトが成長しだしたからこその課題

PdMの役割を見直して具体的な開発テーマが決まり、開発生産性が高まってきた事もあり、ACES Meetは様々な機能リリースが実現できています。
ただし、多くの機能をリリースすればするほど、「あれ？この機能ってこちらの機能と似てない？ユーザーからするとわかりづらくない？」であったり、「このままリリースを続けるより今のUI/UXを全面的に見直した方が良いのでは？」と思う事が多く・強くなってきました。
機能が少ない段階では機能をドンドン作りリリースしていれば良かったのですが、現在では使いこなすのに時間がかかるプロダクトになってしまう懸念があります。ですが、これは開発チームが成長した事により新たに出てきた課題＝成長痛と捉えています。
この成長痛をどの様に解決していくかは、今の私たちにとって大きな挑戦です。しっかりと向かい合って、上手く乗り越えていきたいです。乗り越えられたなと感じた際には、また皆さんに共有できればと思います。

PdM採用してます

最後になりますが、今、ACES Meetチームでは左のPdM・右のPdM共に採用しています。

是非ともACES Meetの開発に加わっていただき、AI議事録ツールからAIセールステックツールに進化させていく道のりを歩んでいただけると幸いです。

youtrust.jp

*1:「戦略とは何ですか？」とChatGPTに聞いてみると、「目的を達成するための全体的な方針や枠組み」と返ってきました

*2:Voice of Customer＝顧客の声

2025-03-07

エンジニアがPdM領域に踏み込む挑戦 - 10%ルールの実践と学び -

こんにちは、株式会社ACES でテックリードをしている奥田(@masaya_okuda)です。

今日のLLM並びにAIエージェントによる開発体験の変化は凄まじいですね。以前はコーディングだけで手一杯でしたが、多くの業務でスピードアップの恩恵を受けています！

そんな中で、フロントエンド・バックエンド・デザインなどあらゆる領域を越境してプロダクトのあるべき姿を構想し、優れた顧客体験を生み出すプロダクトエンジニアという職種が注目されています。

note.com

本記事ではプロダクトエンジニアを目指し育てるためのチャレンジをご紹介します。

フルサイクルエンジニアが多く所属するチーム

私たちのチームでは、エンジニアのほぼ全員がフルサイクルエンジニアとして働いています。要件定義から設計、実装、テスト、リリース、リリース後のサポートまで一貫して関わるため、縦割りの役割分担はしていません。

しかしプロダクトロードマップのような上段の戦略からお問い合わせレベルの軽微なものまで、「何を作るのか？」の意思決定がPdMに集中し、同時にボトルネックにもなっていました。

Right Touch社の責任分解点のスライドが非常にわかりやすかったので引用すると、以下のような状態になることが理想でした。

参考: 小規模組織のプロダクトエンジニアとして、アンラーニングしたこと - Speaker Deck

このような責任分解点のチームを目指すにあたり、「10%ルール」という取り組みを実践することになりました。

10%ルールとは？

10%ルールとは、エンジニアの毎月のリソースの10%を「エンジニア主体でプロダクト価値向上の仮説検証に充てる」ための時間にするというものです。エンジニアが主体となり、プロダクトやユーザーの課題に対してどのような打ち手が有効かを提案し、要求定義も行います。

この実験的な取り組みを、まずは私が3ヶ月実践しチームにFBすることとなりました。「毎月1つ提案からリリースまでやり切る」を目標にして取り組んだことを以下でご紹介します。

1ヶ月目: 顧客課題の把握

最初の月は、どのような機能がプロダクトの価値向上に寄与するのかが分からず、手探りの状態でした。多くの機能アイデアは思いつくものの、それをどのように優先順位付けすればよいのかがわからなかったのです。

そこで、まずは以下のアクションを取りました。

これまでのお問い合わせ履歴を一通り確認
営業、カスタマーサクセス（CS）、社内のユーザーから課題をヒアリング

その結果、少しずつ共通する課題も見えてきました。ここからユーザーストーリーや機能を考えるにあたり、「その場限りではなく、プロダクトに中長期的な価値となる提案をしよう」と考えました。いくつかの機能を考えて改めてBizメンバーに壁打ちしたところ、「短期的な売上や解約防止には直結しない、結びつくまでに他にも機能開発が必要」というFBを受けました。

短期的な価値も踏まえてもう一度提案したいと考え、企画した機能は取り下げることにしました。この時EMの小林から「一発で通る企画なんてないから、何度もチャレンジしよう！」と励まされたことが印象に残っています。

2ヶ月目: 既存機能の価値向上

改めて課題を整理した際に、「MVPとしてリリースしたが、その後の改善が滞っている機能」に注目しました。ファーストリリース後、ユーザーにとって使いにくいまま他の開発に埋もれている機能はないか？という観点です。

具体的には、会議の一括操作機能をリリースしたものの、閲覧権限に関わるグループの紐付けを一括で変える操作が未実装であり、使いづらさに繋がっていました。ユーザーはプロダクトを少数のメンバーで使い始めて徐々に展開していく際に、グループの運用を見直したかったのです。

今回は開発まで進むこととなり、UI/UXの設計もデザイナーと行いました。この際、AIツールのBoltを活用することで、複数の機能モックを作りデザイナーやBizメンバーと「具体的な動きや操作感」まで擦り合わせることができました！

3ヶ月目: データに基づく意思決定

次に取り組んだのは、CSやユーザーから寄せられた「音声のみの会議を一時的に外部共有できないことがネックになることが多くて…」というフィードバックでした。

私たちはZoomなどのオンライン会議の議事録サービスを提供しており、会議の動画と議事録を一時的に外部共有する機能がありますが、音声のみの会議は2つの理由から共有機能を提供していませんでした。

リリース当初、音声のみの会議はIP電話ツールと連携しないと作成されず、利用するユーザーがかなり限定的だった
開発コストが高く、他の開発候補と並べた時に劣後となっていた

特に1つ目の理由があったためCSから相談を受けた時は意外でした。詳細を聞くと、以前リリースされた「動画音声ファイルをアップロードして議事録を作成する機能」をご利用するお客様が増えており、伴って音声ファイルをアップロードして作成する会議の割合が増えているとのことでした。

実際にアップロードして作成された会議の割合を調べると、この機能の利用率は右肩上がりで伸び続けており、動画と音声の割合は4:6で音声のみの会議の方が多く作成されていることがわかりました。

開発コストが低いことに気づき、数日で機能が完成

先の調査で音声会議の割合は増えており、伴って共有機能の不足が使いづらさにつながっていることがわかりました。次に開発コストですが、調べてみると簡単に開発できることがわかりました。

近い箇所の実装を直近で行なっており、コードの知識が深くなっていた
リファクタリングによって複雑性が軽減され、コンポーネントの共通利用ができる状態になっていた

最終的に設計〜実装までを3日ほどで完了しリリースすることができました！

要件定義の際に、「合わせてこんな改善もした方が良いのではないか？」という意見もいくつか上がりました。開発コストとリリーススピードを考慮し、ユーザーストーリーに直接関係ない部分はスコープ外と判断しました。

振り返り: エンジニアがPdM領域まで踏み込む難しさと面白さ

この3ヶ月を振り返って、PdM領域の仕事の難しさを痛感しました。「作った方が良さそうなこと」は無限にありますが、その中で優先順位やスコープを決めるには多くの時間をインプットにあてる必要があります。

プロダクトロードマップなど大きな粒度でのスケジュールを決定、調整
日々お問い合わせの確認
Bizサイドとのmtgを通して情報の収集/把握/深掘り

エンジニアが限られた時間の中でPdMのインプットをトレースするのは非常に難しく、時間を要することを実感しました。

一方で、エンジニアには「より適切なHowを考えられる」という強みがあります。要求定義の段階から関わることで、

どうすればユーザーの課題を埋められるのか？
どの選択肢が最もコストパフォーマンスが良いのか？
将来の開発のしやすさを考慮した際に最適な設計は何か？

といった視点を持つことができます。PdMが「難しい」「時間がかかる」と考えることでも、エンジニアが見ると「すぐにできる」「選択肢が複数ある」といった視点が持てる場合があります。

これらの強みを活かし、エンジニアとPdMが適切に噛み合うことで、プロダクト開発はよりスピーディーに、品質の高いものになっていくのだと感じました。今後もこの取り組みを継続し、さらなる価値向上に貢献していきたいです。

最後に

本記事では、エンジニアがPdM領域に踏み込み、プロダクト価値向上に主体的に取り組む「10%ルール」の実践を通じて、PdMとの適切な役割分担や意思決定のスピード向上に挑戦した事例をご紹介しました。

この取り組みを支えているのは、「エンジニアがプロダクト全体を見渡し、ユーザーの価値に直結する意思決定を行う」文化です。ACESでは、エンジニアがPdMやBizと密に連携しながら、技術だけでなく、プロダクトの未来を共に創る環境があります。

このような開発スタイルに興味をお持ちの方、プロダクトエンジニアとして幅広い領域で価値を発揮したい方、ぜひ一度カジュアルにお話ししませんか？ ACESのチームで、新しいプロダクトのあり方を一緒に探求していきましょう！

ACESの採用情報はこちら↓

youtrust.jp

2025-02-28

「徹底的にパクる」で開発生産性を最大化！他社の知見を活かす方法

ACES Meet 組織・文化開発プロセス開発哲学

こんにちは、株式会社ACES でテックリードをしている福澤 (@fuku_tech) です！

最近、新車を購入し、遂に昨日納車されました！しばらくはノー残業で早く帰宅して、たっぷりと新車を楽しもうと心に決めた今日この頃です。

1. はじめに

大学院時代、ポスドクの方から「論文や技術書には執筆者の数ヶ月・数年にわたる集大成が詰まっている。それを短時間でトレースできるなら、とても効率の良い投資だ」という話を伺ったことがあります。

この考え方は、開発生産性の改善にも当てはまるのではないでしょうか。試行錯誤を繰り返すことも大切ですが、すでに成功している企業の知見を活用することで、より効率的に進めることが可能です。

ACES Meetの開発チームでは、他社の技術ブログや取り組みを参考にしながら、開発生産性の向上に努めています。本記事では、「徹底的にパクる」というアプローチで、どのように開発生産性を向上させているのかをご紹介します。

2. 他社の知見の取り入れ方

私たちは、以下の基準に沿って参考にする企業を選定しています。

開発生産性の向上に成功している企業
開発の進め方や文化を積極的に外部に発信している企業
自社と開発思想や文化に共通点が多い企業

具体的には、最近では Findyさん、Nealleさん、ユーザベースさんといった企業のテックブログや公開資料を参考にし、自社の開発プロセスの改善に取り組んでいます。

ただし、単に他社のやり方をそのまま模倣するのではなく、自社の課題や現状を踏まえて、適用可能かどうかを判断することを重視しています。どんなに優れた施策でも、環境やチームの状況が異なれば、そのまま導入することが最適とは限りません。

そのため、まずは他社の取り組みの背景や目的を理解し、それが自社にどのような価値をもたらすのかを十分に咀嚼した上で、自分たちなりにアレンジして取り入れるよう努めています。

3. 実践事例

私たちは、開発生産性向上のために他社の知見を積極的に活用し、実際にいくつかの施策を取り入れてきました。ここでは、特に効果が大きかった事例を紹介します。

なお、昨年10月からこれらの施策を継続的に取り入れた結果、PR数の観点では、施策実施前（7～9月）と施策実施後（10～12月）を比較すると、開発生産性が1.5倍以上に向上しました。

3-1. Findyさんの爆速開発シリーズを徹底的にパクる

以下のテックブログやスライドを読み込み、自分たちの課題感に刺さるところから愚直に取り入れていきました。

Findyさんは、私たちが目指したいと考えているものに近い開発文化や思想を言語化して発信してくれているため、非常に参考にしている企業の一つです。特に、「とにかく早く顧客に価値あるものを届ける」という姿勢に共感を抱いています。

なお、ACES Meetの開発チームでは、Findyさんのテックブログに記載されている内容を施策として次々に展開することで、「次はFindyさんの記事に書いてあるこれをやってみよう！」といった会話が自然に成立するようになっており、チーム全体でFindyさんのファンになっていますw

tech.findy.co.jp tech.findy.co.jp tech.findy.co.jp tech.findy.co.jp tech.findy.co.jp tech.findy.co.jp speakerdeck.com

3-1-1. 小さなPull Requestの徹底

課題感：
- 1つのPull Requestに複数の変更が含まれ、レビュー負担が増大
- レビュアーと実装者の認識がずれ、指摘や修正が多発し、手戻りが発生
実践内容：
- タスク分解の強化：事前に要件を具体化し、小さなタスク単位で開発
- PRの粒度を明確化：「意味のある最小単位」でPRを作成する指針を共有
- レビュアーとの事前認識合わせ：実装前にバディを組み、タスク分解と開発方針を共有
結果：
- PRの適切な粒度が維持され、レビューが効率化
- レビュー時に「何を見るべきか」が明確になり、負担が軽減
- 仕様や設計の共通理解が深まり、手戻りが減少

本取り組みの詳細については、以下の記事をご参照ください。 tech.acesinc.co.jp

3-1-2. レビュー最優先の文化醸成

課題感：
- PRのレビューが後回しになり、開発の停滞やリリース遅延が発生
- レビュー待ちの時間が長くなることで、フロー効率（開発のスムーズさ）が低下
実践内容：
- レビューの迅速化：Google’s Code Review Guidelines - Speed of Code Reviews を参考に最遅でも1次レビューは1日以内としていたところを、2〜3営業時間以内を目標に修正
- フロー効率の低下を防ぐための認識合わせ：「レビューの遅れが開発全体に与える影響」をチームで共有
- レビュー通知の見逃し防止：SlackとGitHubを連携し、PRの通知を確実に受け取れるように
結果：
- レビューの迅速化により、開発の停滞が減少し、フロー効率が向上
- レビュアー・レビュイー双方の負担が軽減し、フィードバックの質が向上
- 通知を活用することで、PRレビューの抜け漏れが減少

3-1-3. CIの高速化

課題感：
- CIの実行時間が長く、開発者の待ち時間が増え、フィードバックサイクルの高速化を阻害
実践内容：
- Rust製のLinterへの移行：フロントエンドは Biome、サーバーサイドは Ruff に移行し、Lint時間を短縮
- テストの並列実行：GitHub Actionsの matrix機能を活用し、テストの並列実行を実現。その際、各コンテナにテストケースを均等に配分し、全体の実行効率を最適化
結果：
- Lint時間：1分弱 → 3秒未満、テスト時間：10分弱 → 5分未満に短縮
- CIの高速化により、開発者の待機時間が減少し、フロー効率が向上

3-1-4. feature flag の活用

課題感：
- 一定規模のユーザーストーリー開発ではepicブランチを運用していたが、長期間のブランチ維持によりコンフリクトやマージ負荷が発生
- 一部のユーザーに対して先行リリースを行う仕組みがなく、段階的な展開が難しい
実践内容：
- DevCycleの導入：feature flag を手軽に管理できる環境を整備
- feature flag の運用開始：完成した部分から順次マージできるようにし、完全ではないがトランクベース開発に近づけた
- 段階的なリリースフローの確立：社内限定リリース → 全体公開と、柔軟なリリースを実現
結果：
- epicブランチを不要にし、開発中の変更を早期にメインブランチへマージできるようになり、コンフリクトの発生が減少
- 段階的なリリースが可能になり、リスクを抑えながら新機能を展開できるようになった
- デプロイのハードルが下がり、よりスムーズでカジュアルなリリースが可能に

3-2. Nealleさんの借入メモを徹底的にパクる

Nealleさんは、Findyさんと同様にACES Meet開発チームと共通する開発思想や文化を有しており、さらにACES Meetの開発チームと同様に Python/Django を採用しているため、技術面でも参考にしやすいと感じている企業です。そのため、テックブログを定期的にチェックしています。

ちょうど「やらないことを増やし、開発スピードを上げる」ことを意識していたタイミングで、以下の記事を拝読しました。借入メモについて、具体的な運用イメージが得られたことで、すぐにチームに展開し、運用を開始しました。

nealle-dev.hatenablog.com

私たちのチームでは、まずは運用に乗せることから始めたいと考え、上記記事で紹介された方法をよりライトな形にアレンジして取り入れています。

結果として、開発時に「この部分は積極的に借入を実施し、戦略的に判断・着手を遅らせよう」というコミュニケーションが増えた感覚があり、導入してからすぐに借入メモの効果を実感できています。

関連する内容を以下の記事でも記載しているので、詳細はそちらをご覧ください。

tech.acesinc.co.jp

3-3. ユーザベースさんのペアプロのノウハウを徹底的にパクる

私たちのチームは、これまで自然発生的にペアプロやモブプロを実施していましたが、体系的なプラクティスとして意識できていなかったため、より効果的な方法を模索していました。

そのような中、ユーザベースさんが公開している以下のpair-programming-guidelineの存在を知りました。実践的な内容が整理されており、チーム全員で読み合わせを行った上で、取り入れやすいプラクティスから適用を始めています。

github.com

もともと設計フェーズではペア作業を推奨していたため、その流れを活かしながら導入を進めました。最初のステップとして、従来のdesign doc作成時のペア作業に対してプラクティスを適用することから始めています。

そして、実際にペアプロ・モブプロを実践してみたところ、以下のような効果が得られています。

複雑な実装の早期解決： 1人で進めていたら1日以上かかりそうだった実装が、ペアプロで知恵を出し合うことで 15分で解決
ハイコンテキストな設計の効率化： 新規ユーザーストーリー実装時に、既存の認可ロジックに手を加える必要があったケースで、モブプロを活用し、ナレッジシェア・影響範囲の洗い出し・設計を迅速に実施。結果として、フロー効率とレビュー速度が向上

このように、ユーザベースさんのガイドラインを活用することで、チームのコラボレーションが強化され、ペアプロ・モブプロが「なんとなくやる」から「効果的に活用する」へと進化しています。今後もプラクティスを深化させ、さらなる開発生産性の向上を目指します。

4. まとめ

本記事では、「徹底的にパクる」という戦術を通じて、他社の知見をどのように取り入れ、ACES Meet の開発生産性を向上させているかをご紹介しました。

このアプローチは、単に模倣するのではなく、自社の課題や状況に合わせた最適な形へと落とし込むことで、より効果を発揮していると考えています。

そして、徹底的にパクる戦術が実現できるのは、チーム全員が新しいチャレンジに寛容で、変化を楽しむ組織であるからこそだと感じています。

本記事を通じてACES Meetの開発チームにご興味をお持ちいただけましたら、ぜひカジュアル面談でお話ししましょう！

ACESの採用情報はこちら↓

youtrust.jp youtrust.jp

2025-02-21

失注の理由はココだった！CREが解き明かした勝ちパターンと負けパターン

ACES Meet CRE

あいさつ

はじめまして、ACESでソフトウェアエンジニア兼CREをしている村上です。

最近はポーカーにハマり、内でも外でもポーカーばかりしています。社名のACESはポーカーにおける最強ハンドの名前と一致しているのでそれにあやかってポーカーも強くなりたいものです。

前回の記事で、CREの役割として以下の3つの挙げました。

顧客の現状を把握できるようにする
顧客の問題を取り除き、やりたいことを実現できるようにする
CS業務を効率化し、顧客に向き合える時間を増やす

今回はこの中から、

顧客の現状を把握できるようにする
顧客の問題を取り除き、やりたいことを実現できるようにする

の2点を中心に、どのような取り組みをしているかを紹介します。

顧客の現状を把握する

顧客の課題解決にはまず顧客の現状を把握することが大切です。

ここではどのような方法で顧客の現状を把握し、その中でどのような気づきがあったかを具体例を交えて説明します。

トライアル中のミーティングの内容を確認する

顧客の現状を把握するうえで、CREになった僕がまず始めにやったのはトライアル中に行っている顧客とのミーティングをひたすら見ることでした。

初期は過去200件程度のミーティングを確認し、以降も月100件弱のミーティングを継続的に確認して常に顧客の現状を把握するようにしています。

これだけ多くの会議を見るとなると問題になるのが時間です。1つのミーティングが1時間ほどあると仮定すると、そのまま再生して全てをチェックするのは非常に時間がかかります。そこでポイントを絞り、主に以下のような点を重点的に確認しています。

顧客が何に困っていて、どのような期待を持ってトライアルを始めたのか
- 「営業向けの教材を作りたい」「自社のノウハウを記録・共有したい」など
実際にプロダクトを使う中で詰まった部分や質問されたこと
- 「UIが分かりにくい」「文字起こしが正しく出なかった」など
最終的に顧客の目的は達成できたか、その理由は何か
- 「十分な会議が蓄積できなかった」「フィードバックを得る時間が足りなかった」など

これらの確認を通じて「顧客が求めている価値」と「その価値を阻害する要因」を把握することができます。

(ちょっと寄り道) ACES Meetで要点を簡単に把握できます！

実はこのトライアル中のミーティングの内容確認には、弊社のプロダクトであるACES Meetを活用しています。

ミーティング動画を丸々チェックするのが大変でも、以下の機能を使うことで効率よく要点を掴むことが可能です。

AIまとめ機能
- 会議内でどんなトピックが話されていたかを、大まかにテキスト化・要約してくれます。
ハイライト機能
- 指定した内容に関連する部分をピンポイントで抽出し要約してくれます。

これらの機能を活用することで、顧客が本当に言いたかったことや困っている部分を効率よく抽出・分析できています。

どんな現状が把握できたか

実際に数多くのトライアル中のミーティングを見ていく中で、トライアル時に満足していただける顧客と逆にトライアル時に満足していただけず失注してしまう顧客をいくつかのパターンに分類することができました。

一例として、「ACES Meetで営業向けの教材を作りたい」という顧客に対して多かった失注パターンを紹介します。

教材を作りきれずにトライアルが終わってしまう
- 教材を作るには大量の商談からお手本になる商談を抽出する必要があるが、トライアル期間内に十分な量の商談を録画することができない
トライアル期間中に会議を振り返る時間が取れない
- 大量の商談を録画したとしてもその内容を確認して教材を作る時間をトライアル期間中に取れない