はじめに
コミューン株式会社でプロダクトマネージャーとして働いている岡上と申します。
コミューンでは「あらゆる組織とひとが融け合う未来をつくる」をビジョンとして掲げ、｢commmune｣と｢SuccessHub｣のプロダクトを提供しています。
「commmune」はオンラインコミュニティプラットフォームをノーコードで作成できるSaaSです。toB/toC問わず、スタートアップからエンタープライズまで幅広いクライアントにご利用いただいています。
私はこれまでカスタマーサクセスとしてキャリアを歩んできましたが、コミューンに入社してプロダクトマネージャーにジョブチェンジいたしました。
カスタマーサクセスはユーザーの課題に詳しく、課題解決能力も求められる職業です。そのため、プロダクトマネージャーに求められる適性を満たしているケースがあると考えています。
本記事では、プロダクト開発未経験の状態から、自社の開発チームと外部の開発会社と協力しながら、commmuneのモバイルアプリのリプレイスさせた経験について書かせていただきます。
そのため、本記事は以下のような方の参考になるのではないかと考えています。
- アソシエイトプロダクトマネージャーの育成に悩まれている方
- プロダクトマネージャーのキャリアを歩み始めたばかりの方（またはプロダクトマネージャーのキャリアパスを検討されている方）
- カスタマーサクセスとして働いている方
- コミューンに興味関心がある方
プロダクトマネージャーになるまでの道のり
私は2020年のシード期のコミューンにカスタマーサクセスマネージャー(CSM)として入社いたしました。
CSMではコミュニティに参加するエンドユーザーにどんな価値を提供するべきか、それをどうクライアントのビジネス成果に還元させるかという「クライアントのビジネス成果を最大化」にフォーカスして、クライアントを支援してきました。
入社から1年後、企業フェーズ的にカスタマーサポートの重要性が増し、サポートチームの立ち上げを引き受けました。サポートチームでは迅速かつ正確なテクニカルサポートを実施し、「プロダクトに対する早期問題解決」にフォーカスしてきました。
2年間のカスタマーサクセス・サポートの業務を通して「目の前のお客様だけではなく、より多くのクライアント・ユーザーの皆さまにより良いサービス価値を届けたい」という想いが日々強くなってました。また、自身のキャリアパスとしてサポートチームのマネージャーを目指す方向で良いのか悩んでいました。
ある日、弊社CEOの高田が全社員に向けて「コミューンという会社はキャリアを実現するためのビークルでしかない」「皆さんがコミューンで働いた時間を人生のハイライトと思えるような会社にしたい」というメッセージがありました。
今ではエンプロイーサクセスとして採用資料にも落とし込まれていますが、当時の自分はキャリアに悩んでいる最中だったため、夜通し考え込む良い機会になりました。
夜通し考えた結果、目の前のお客様だけではなく、より多くのクライアント・ユーザーの皆さまにより良いサービス価値を届けるためには、プロダクトマネージャー(PdM)が最適だと考えました。
そこからは、プロダクト開発の知識を独学でインプットし、自己分析(強み / 弱み)を行い、社内面接を経て、2022年9月にPdMへジョブチェンジいたしました。
そして、PdMへジョブチェンジしてからの1ヶ月間は、機能改善系の業務をメインに携わりました。
具体的には、機能要件の定義、プロダクトバックログの管理 (優先順位付けを含む)、リファインメント (エンジニアやデザイナーと工数見積）、機能リリース、という一連のプロセスを経験することで、スピーディーにPdMの業務を体感できました。
また、並行して開発リソースを必要としない外部ツールを活用した機能改善施策を主導する機会があり、プロジェクトマネジメントの要であるQCD（Quality、Cost、Delivery）の重要性を体感できました。
モバイルアプリリプレイスの成果
ジョブチェンジから1ヶ月後、モバイルアプリのチームのPdMに任命されました。
それまでのモバイルアプリは、WebViewを利用してコンテンツを表示しておりました。しかし、WebViewでは、UI/UXの観点で最適なユーザー体験の提供が困難な状態でした。
そこで「アプリにおけるユーザー体験の最大化」をゴールとし、段階的にモバイルアプリのリプレイスをできるように開発を進めました。
第一弾リプレイスでは、モバイルアプリ開発の基盤乗り換え、コンテンツ表示速度やタッチ感度の改善等を中心としたユーザー体験の改善にフォーカスいたしました。
当時の詳細につきましては以下記事をご覧ください。
私がモバイルアプリのチームのPdMに任命されたのは、第二弾のリプレイスを開始するタイミングであり、外部パートナーのリソースを追加するタイミングでした。 最終的に7ヶ月間の開発期間を経て、第二弾のモバイルアプリをリリースできました。
今回のモバイルアプリのリプレイスのゴールは「アプリにおけるユーザー体験の最大化」と定義しており、特に「パフォーマンスの最大化」と「UI/UXの最適化」を重要視していたため、十分な成果を出せたのではないかと思います。
開発未経験者がプロダクト開発するうえで意識すべきこと
PdMにジョブチェンジし、これまでの経験を活かせた部分が多かったですが、反省すべき点もありました。
プロダクトマネージャーとしてこれまでの経験を活かす
commmuneのカスタマーサクセスとカスタマーサポートの両方を経験していることで、「ドメイン知識」と「既存仕様」に長けており、最適な意思決定が可能でした。
一般的にプロダクト開発する際には「Why」「What」「How」の順で進めていき、PdMは上流部分の「Why」に責任を持つべきと言われています。
なぜなら、「Why」によって何を作るのか、機能の仕様どうするべきなのかという「What」が大きく変わり、ユーザーに価値提供できる機能なのかどうか決まります。そして「Why」を思考するうえで、ドメイン知識が必要です。
ドメイン知識とは、特定の専門分野に特化した知識のことです。いわゆる自社サービスに関連した知識です。
「commmune」の場合、クライアントであるコミュニティマネージャーの業務、ユーザーとしてコミュニティに参加する人々の行動を深く理解し、課題を理解しておく必要があります。また、コミュニティプラットフォームという特性上、多種多様な属性のクライアント・ユーザーが存在するため、幅広く理解しておく必要もあります。
さらにリプレイスプロジェクトの場合「既存機能がなぜこの仕様であり、ユースケースとしてクライアント・ユーザーが日々どのように機能を利用しているのか」を広く深く理解しておくことが重要です。
なぜなら、モバイルアプリですべての既存仕様を踏襲するわけではなく、ユーザー体験的に仕様変更を判断する機会が多々あり、都度仕様確認する時間が存在しないためです。
言い換えれば「ドメイン知識」を持っていれば「Why」の質を高められ、「既存仕様」を広く深く理解していると「What」の質を高められます。ただし、「ドメイン知識」と「既存仕様」を理解しているだけではなく、仮説構築・仮説検証力や優先順位の判断力、問題解決能力なども必要です。
したがって、commmuneのカスタマーサクセスとカスタマーサポートの両方の経験があることで、クライアント・ユーザーにとって必要十分な機能提供するための意思決定を行えました。
プロダクトマネジメントに必要なマインドを持つ
PdMを実際やってみて強く実感しましたが、PdMだけではプロダクトマネジメントを実現することは到底不可能で、多職種・他部門を巻き込んでチームで行う必要があります。 そのため、プロダクト開発に関する知識・スキルだけではなく、チームとしてプロダクト課題に向き合えるマインドも重要です。
会社によって「どんなマインドが必要か？」という点で様々な考えがあると思いますが、私にとっては、弊社バリューの「チームコミューン」の「プロスポーツチームとして背中を合わせる」という考え方がとてもしっくりきています。
例えば、私は以下のようなマインドセットでPdMの業務に携わっています。
- PdMはプロダクトのビジョンの実現に責任を持つ
- プロダクト開発する中で何か問題が発生した場合はPdMが責任を負う
- PdMは「Why」と「What」に責任を持つ
- ただし、PdMはチーム全体で「Why」と「What」を納得できるようすべきであり、デザイナーやエンジニアも「Why」と「What」を理解したうえで業務を進める
- PdMは「How」のUIデザインや実装の責任範囲外とする
- デザイナーがUIデザインに責任を持ち、エンジニアが実装部分に責任を持つ
- ただし、PdMは全体の進捗とバランスを保つために、これらの領域を抽象化して理解しておく
- PdMはプロダクトマネジメントするうえで落ちているボールに対して、主導して問題解決に責任を持つ
外部の開発パートナー含めた全員で「チームコミューン」を実現する
ドメイン知識・仕様理解が十分で、チームで開発するマインドを持っているPdMがいたとしても、それだけではプロダクトマネジメントはできません。
大前提の部分にはなりますが、｢一緒にプロダクトを開発してくれる、優れたモバイルアプリエンジニア」が必要です。その点においては、私が参画した時点で優秀なメンバーが揃っていたのは幸いでした。
ただし、Flutter開発は比較的新しい開発フレームワークのため、優秀なメンバーであっても「Flutter開発の経験が豊富ではない」という課題がありました。そこでFlutter開発の経験豊富な外部パートナーも巻き込んで開発を進めていきました。
外部の開発会社との開発については、「受託開発」や「SES」といった関係をイメージされる方も多いかもしれませんが、最近では「伴走型」といった開発の進め方も存在しています。
「伴走型」とは、企業とベンダーが共創的関係の中で開発を進める新たなアプローチであり、委託 と受託の関係に囚われず共創の関係を築いていくことが重要です。
共創関係を築くための具体的な手段として、スクラムイベント（デイリースクラム、スプリントプランニング、スプリントレトロスペクティブ、バックログリファインメント）に参加してもらいました。また、共同開発を開始してから最初の2,3ヶ月間は、定期的に連携体制のすり合わせや両社の改善点を洗い出し、強固な共創関係を築くことに注力いたしました。
外部パートナーと共創関係を築き、自社・外部の開発チームを含めて「チームコミューン」になれたため、確定した機能要件やUIデザインに対して改善案の提案などもいただける関係になりました。また、外部パートナーはどうしても「ドメイン知識」と「既存仕様」という点で理解度が浅いため、私の強みを活かして開発を進めることができました。
弊社のエンジニアは、Flutter開発に関する問題に直面した場合、「同様の問題が以前に発生したことがないか？」や「良い解決策はないか？」といった疑問を持ちながら開発を進め、その結果Flutter開発の経験値が向上し、開発効率も向上しました。
メンバー全員の強みを「チームコミューン」で活かせたからこそ、「アプリにおけるユーザー体験の最大化」のためのモバイルアプリをリリースできました。
自身の弱みを改善できるように行動すべき
これまでポジティブなことをベースに書いてきましたが、反省点としては自身の弱みである「プロダクト開発の経験がなく、技術的知識が不足している」点を改善しなかったことです。
基本的にPdMへジョブチェンジする際のキャリアパスとして、何かしらの形でプロダクト開発に携わっている方が多く、開発の基本知識やUI/UX、データベース管理などのスキルを身につけるのは最低限やるべきことです。
開発経験が不足していたため、リプレイスプロジェクト全体の進め方に改善すべき点があり、技術的知識が不足していたため、初期設計や要件定義に改善すべき点がありました。これらの問題に対しては、事前に対策を講じる必要がありました。
前提として、モバイルアプリをWebViewからリプレイスする場合、UI変更や仕様変更によって、ユーザーの操作性を損ねるリスクもあります。
皆さんも普段利用しているモバイルアプリで仕様・UIデザインが変更されて戸惑った経験はありませんか？
基本的には、より良いユーザー体験を追求するために仕様やUIデザインを変更することが多いため、マイナスな体験になるケースは少ないです。しかし、WebViewからのリプレイスにおいては、技術的な制約によって変更せざるを得ない場合があります。
今回開発を進めている最中に技術的制約が発覚する場面があり、モバイルアプリの開発経験があれば、初期設計や要件定義の段階で気付くことができたかもしれません。
実装中に技術的制約に気付くことで、解決案の検討や影響範囲の洗い出しをする必要があり、さらにステークホルダーへの確認などに時間が割かれてしまうため、一時的に実装が停止してしまいました。その結果、要件定義が中途半端だったり、UIデザインが確定していない箇所の実装を進めることになり、最終的に余分な修正工数が発生することになりました。
モバイルアプリの開発経験がなくても初期設計や要件定義の早い段階でエンジニア全体を巻き込めれば事前に防げたかもしれないのですが、そもそもの開発を経験していないことやプロジェクト参画直後でエンジニアと信頼関係を築ききれていない状態では、中々難しかったと思います。
今回の場合、モバイルアプリ開発に携わっている他社のPdMの方に、モバイルアプリならではの躓きポイントや意識すべきことをヒアリングして、モバイルアプリのプロダクト開発の解像度を高めるべきでした。
まとめ / 今後の展望
本記事を最後までお読みいただきありがとうございます。本記事が誰かの役に立てたようであれば嬉しい限りです。
今回の経験をまとめると、プロダクト開発未経験のPdMがWebViewからモバイルアプリへのリプレイスを成功させるためには、ドメイン知識・仕様理解の習得、プロダクトマネジメントのマインドが必要不可欠でした。
また、自社と外部の開発チームを一体化させるためには、優秀な自社のモバイルアプリエンジニアが採用されており、全員で密なコミュニケーションを取りながら、メンバー全員の得意領域を最大限に活かすことも重要でした。
第二弾のリプレイスでモバイルアプリの主要部分を実装できましたが、まだWebViewが残っている状態です。そのため、今後の展望としては引き続きWebView箇所をリプレイスし、モバイルアプリとしての土台を整えていきます。
また、同時に大きく改善すべき機能に対しては、UXリサーチャー、UIデザイナーと開発着手前に連携してユーザビリティテストを行い、既存ユーザーに価値あるモバイルアプリを提供できるように努めてまいります。
個人的な展望としては、PdMにジョブチェンジしてからの1年間は新鮮な世界で先が読めず行き当たりばったりな場面が多く、今後は自分のスタイルを固めつつPdMとして必要なスキルを磨き上げ、サービス価値を高めていけるように精進していければと思います。
何か個人的に聞きたいことがございましたら、遠慮なくX (旧:Twitter)のDMでご連絡ください！
また、コミューンではプロダクト開発を強化するために全方位的に採用を強化しています。
特にPdMやエンジニアの方は大歓迎です。カジュアルに会社の話を聞いてみたいという方は以下のカジュアル面談のフォームからお申し込みください！
