見出し画像

複数プロジェクトが並行稼働するプラットフォームのプロダクトマネージャー

こんにちは、ヤプリでプロダクトマネージャー(以降、PdM)を担当しています元嶋と申します。

「プロダクトマネージャーのお仕事」シリーズ、5回目の記事です。前回の記事はこちら

ヤプリでは、随時複数の新規開発・改善のプロジェクトを並行して進めています。今回の記事では、複数のプロジェクトが動くヤプリのPdMとして自分が心掛けている内容について紹介します。

ヤプリではスムーズな意思決定・開発を心がけ、各開発プロジェクトにPdMがつくことで、スピード感のある開発を実現しています。

各PdMがこれまで経験してきた職務が異なること、開発内容によって重要視するポイントが異なることから、プロジェクトからのアウトプットには特色が出てきます。

サービスの多様性を考えると、特色が出ること自体は歓迎なのですが、プロジェクト内の開発サイクルを早めることを重視して進めていると、どうしても担当PdMの視野もプロジェクト内に狭まりがちになります。

ここで発生する各課題をPdMのスキルやメンバー間のコミュニケーションのみに頼るのではなく、仕組み化することで解決するために2つの取り組みを進めています。

プロジェクト間の課題解決についての仕組み化については、こちらの記事に記載しています。ヤプリのPdMが持つ共通意識やPdM像について知りたい方はこちらの記事もご覧ください!

さて、ここから本題になります!

1. 共通ルールを運用する。

まず1つ目はプロダクトの成長に合わせて共通ルールを運用することです。

一般的なプロダクト開発と同様に、Yappliにおいてもサービス水準を担保するための基本ルールを策定しています。

このルールの中には各担当PdMが、プロジェクトの仕様検討・開発・品質保証などの各工程で注意するべき共通チェック項目なども含まれます。

プロジェクト内で完結するような開発の場合はこれだけでも十分とも言えます。

ただ、プラットフォーム上での開発ではプロジェクトのアウトプットはプロジェクト外の開発内容やこの基本ルール自体に影響を与える場合があります。担当PdMの視野が担当するプロジェクトに狭まっていると、稀に他プロジェクトの開発・進行へ与える影響が十分に伝わっていないなどのケースも発生します。

この情報共有不足によるヒューマンエラーの防止のため、自分自身が担当するプロジェクトのアウトプットかどうかに問わず、定期的に開発内容を確認し、共通ルールのアップデート検討・変更対応などの運用を行っています。

2. 社内仕様書へのフィードバック

2つ目はヒューマンエラー発生時のフィードバックの仕組みについてです。

共通チェック項目に定義している開発内容の場合でも機能を活用するお客様の仕様用途や技術的観点から対応しないと判断する項目もあります。

共通チェック項目は対応している前提で認知されてしまうことが多く、イレギュラーな対応をした仕様について、ビジネスサイドのメンバーの認識が不足しているケースが出てきます。

このケースに対応するために社内の問い合わせ対応チームにも協力してもらっています。

社内からの問い合わせ対応を進める上で、開発↔︎ビジネスサイド間で認識の相違が発覚した場合、問い合わせチームから情報をキャッチアップし、全社員が閲覧できる各種ドキュメントへフィードバックする社内フローを作り、運用しています。

基本的にビジネスサイドへの情報展開は各プロジェクトを担当しているPdMが担当してくれているので、頻繁に発生するような内容ではありません。

Yappliはお客様自身が管理画面を操作し、アプリ上の機能設置や運用まで行うことができるプラットフォームです。

カスタマーサクセス・カスタマーサポートのメンバーがお客様からの要望に対して、迷わず対応できるよう正確な情報を届けるために、この2つ取り組みの運用・改善を進めています。

おわりに

これらの取り組みについて、自分自身の対応が不足している点を挙げるときりがないのですが、プラットフォームの成長に合わせて、この取り組み自体もアップデートできるように日々奮闘中です!

いつも迷惑をかけている社内エンジニアメンバーの皆様に感謝です!!

プラットフォームの成長に合わせて、PdMとしても成長を目指せるいい環境だと思うので、ぜひ気になる方がいらっしゃっいましたらTech Blogや採用サイトもぜひご覧ください!

Yappli Tech Blog
カジュアル面談

この記事が参加している募集

PMの仕事