こんにちは、株式会社ACES でテックリードをしている奥田(@masaya_okuda)です。
今日のLLM並びにAIエージェントによる開発体験の変化は凄まじいですね。以前はコーディングだけで手一杯でしたが、多くの業務でスピードアップの恩恵を受けています！
そんな中で、フロントエンド・バックエンド・デザインなどあらゆる領域を越境してプロダクトのあるべき姿を構想し、優れた顧客体験を生み出すプロダクトエンジニアという職種が注目されています。
本記事ではプロダクトエンジニアを目指し育てるためのチャレンジをご紹介します。
フルサイクルエンジニアが多く所属するチーム
私たちのチームでは、エンジニアのほぼ全員がフルサイクルエンジニアとして働いています。要件定義から設計、実装、テスト、リリース、リリース後のサポートまで一貫して関わるため、縦割りの役割分担はしていません。
しかしプロダクトロードマップのような上段の戦略からお問い合わせレベルの軽微なものまで、「何を作るのか？」の意思決定が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の採用情報はこちら↓
