この記事は、モチベーションクラウドシリーズAdvent Calendar 2019の23日目の記事になります。

いよいよクリスマスが近づいてきましたね！
息子から「お父さんもサンタさんにプレゼント頼んだらいいよ！子供っぽいプレゼントなら多分ダイジョーブだよ！」と言われました。
息子の脳内グルーピングでは、私も子供側にいるようです。笑

さて、こんな私ですが、普段はモチベーションクラウドシリーズのプロダクトマネジャー(PdM)をしています。
よくエンジニアの皆さんからは「相談したくても席にいない。何してんスか？てか、Slackはよ返せ」と言われ、申し訳ないなーと感じる日々です。

なのでこの機会に、PdMって具体的に何をしているのかをまとめてみました。

この記事を読んでほしい人

-今日からアナタはPdMですとか言われて困ってる人
-もっと役割を広げさせろよ！というやる気あふれるPdMの方
-少しくらいPdMのことを理解してやるか！という心優しいエンジニア

PdMってザックリどんなことしてるの？

だいたい、以下のようなことをしてます。

• 戦略(Why)をつくってる
• 要件(What)をつくってる
• 概念を整理してる
• デザインを確認してる
• スケジュール確認してる
• できたものを色んな人に共有してる
• トラブルシュートしてる

戦略(Why)をつくってる

多くの時間を割いていることは、「どんな未来を創るのか」です。しかし残念なことに、私には未来視のスキルが備わっていないので、地道に活動をしてます。

1.お客様にヒアリング

• 買ってくれた理由
• 買ってくれなかった理由
• 継続利用してくれる理由
• 利用を止めてしまった理由

について、具体的なお客様を明確にしながら集めます。できる限りは自分でお客様先に同行させてもらって、一時情報をゲットするようにしています。

2.事業責任者や現場リーダーと議論

• これからどうしていきたいか
• 解決したい問題は何か

を聞いて回ります。

この時、どんなKGI、KPIを重視するのかを共通認識化できるように話をするととてもよい感じになります。

3.要素を整理

ここまでに出てきた観点について、競合サービスとの比較を行います。

ここまで情報を集めると、いわゆる3Cの情報が整理されてきます。
あとは、ここから向かうポジションを見いだします。この辺りはさらに長くなるので、またの機会に。

これをもうちょっと具体化して、会議で承認を取ったらロードマップが完成します。

要件(What)をつくってる

ここはエンジニアの方にも見えている部分かと思います。
ロードマップが固まった後は、それを具体的な要件に落としていきます。

1.関係者みんなにヒアリング
このステップでは、より多くの人の力を借りて進めています。具体的には、
1.お客様対応してる人(コンサルタント、カスタマーサポート)
2.内部でお客様やコンサルタントをサポートしてる人(オペレーションサポート)
3.オンボーディングなどの体験設計をしてる人(カスタマーエクスペリエンス)
4.実際に形にしてくれる人(エンジニア、デザイナー)
に相談をしながら、何がベストなのかを紡いでいきます。

2.ドキュメント化する
これらの方々と議論しながら優先順位を決め、具体化しながらドキュメントにまとめていきます。
まとめ方は、Googleのデザインドックをベースにオリジナルフォーマットを活用してます。
※詳しく知りたい方は、梅原くんや武田くんが詳しいので、彼らの記事のコメント欄に記事をまとめろと依頼してください。笑

ここで何より大切なのは、みんながWhyを共有できていることです。なので、隙あらばWhyを語るオジサンになっています。

概念を整理してる

このステップはたまにしかしてませんが、とても重要です。
新しい概念が入ってきた時に、その概念が今ある概念とどんな関係にあるのかを整理します。
ユビキタス言語とかドメインモデルとか言われるようなことです。たぶん。

この部分のミスショットは、データベース設計やコード設計、デザインのUIとかにまでめちゃめちゃ影響を与えてしまいます。
SaaSと呼ばれるような「戦略もUIもひたすら変えながら進化していく」息の長いプロダクトが競争優位性を保ち続けるには、この部分が命だと感じています。

とても大切なので書いてみましたが、まだしっかりとドキュメント化できていません。ここはもっと時間をかけてやらないとと反省しました…。

デザインを確認してる

実際には要件の一部ですが、デザインの確認にも多くの時間を割いています。
私にはデザインのセンスが全くないので、表面的なデザインについてはデザイナーにお任せです。

PdMが担っているのは、

• Whyとズレていないか
• ユーザーが使っていて気持ちよいか
• データの構造と概念が揃っているか

を確認することです。

お客様先に行ったり現場にヒアリングして掴んだ現場感をデザイナーに伝えて、デザイナーの感性を引き出せるようにしています。
また、ここで行っているフィードバックは全てデザインガイドラインに反映させるようにしていて、「誰々が言ったから」ではなく「ガイドラインに沿っているかどうか」で判断できる状況を作っていっています。

スケジュールを確認してる

開発のスケジュールは、当然エンジニアの皆さんが管理してくれています。

ただ、うちのエンジニアの皆さんは責任感が強いので、ギリギリまで自力でガンバろうとしてくれます。すると、「どうにか間に合わせよう！」と、気づけばオーバーワークになってしまうこともよくありました。

1.昔の反省…
今思い出すと、気軽な気持ちで仕様変更を入れてみたり、優先順位を変えてみたり、仕様確定が遅れたり、デザインをギリギリまで修正してみたりと、最低の進め方をしていました。本当にゴメンなさい…本当に反省してます。

2.反省から生まれたスケジュール管理
そんなことを繰り返してきたため、徐々にスケジュールが遅れる予兆に気づけるようになってきました。

• 進めるタスクの順番を決めるときに、不確実性についての話題が出ない(スケジュールがキツいと、安心感のあるところから進めたくなる)
• プランニングや課題管理の精度が落ちる (リーダーが１人で見積もっている、担当や〆切不在の課題が増えて中々消えない)
• 朝会の進捗報告で、定性情報が増える(目の前のタスクをつぶすことに全力投球している可能性)

これらを察知したときに、問題が大きくなる前にエンジニアリングマネジャーと相談して調整を行うようにしています。

最近では、エンジニアの皆さんに安心感を持って働いてもらうと、開発スピードもクオリティも上がるんだってことを実感しています。昔の私をぶん殴って差しあげたい気持ちでいっぱいです…。

できたものを色んな人に共有してる

モチベーションクラウドは、現場の方も含めるとゆうに100名以上の方が関わってお客様に価値を届けています。そのため、認識のズレが発生しやすい状況になっています。
そのため、お客様にご迷惑をおかけしないよう、しっかりと情報が行き交う状況を作っています。

1.伝達する対象と頻度を決める
まずは、

• 誰に
• どんな情報を
• どんな頻度で
• どんな方法で

伝えるのがよいかを決めました。
ザックリいうと、現場のリーダーには「詳しく×週次×ミーティング」、メンバーには「要点のみ×月次×集合型のセッション」などです。

最初は、頻度が高いと大変な気がしていましたが、いざ始めてみると密につながるべき人とは「細かく、早く」接点を持つほうが圧倒的にスムーズになりました。

2.実際に伝達する
柴田くんの記事にもありましたが、「伝わる言葉」で話すことが大切です。
うかつにドヤ顔で専門用語を使おうものなら、現場の方には笑顔でスルーされてしまいます。
「この言葉、うちのオカンでも通じるかな？」というマインドで挑むと、間違いなく伝わります。

トラブルシュートしてる

どれだけガンバっていても、バグが発生することもあれば、お客様との期待値がズレてしまうこともあります。
そんな時は、兎にも角にもお客様を優先して対応しています。大きなトラブルが発生した場合に、それをチャンスに変えるのもPdMのお仕事だと思っています。

クレーム対応の精神性
リンクアンドモチベーションでは、クレームが発生した場合に、わざわざ伝えて下さったお客様に感謝の気持ちを持って、「即座に、誠実に、最大限の犠牲を払ってでも」しっかりと対応しようという価値観が浸透しています。
そのため、あらゆる機能の人がスムーズに連携できる文化ができています。

圧倒的なスピードと強度で反応する
上記の文化があるため、トラブルが発生した場合は全員が機敏に行動を開始します。
しかし、その反応の仕方は役割によって違うことに気づきました。

• エンジニアは、本当にバグが起きているのか、起きているならその原因と影響範囲を突き止めたい
• 現場のメンバーは、何よりお客様のクレームを収めたい

そのため、みんなが全力で解決に向けて行動していても、「現場が騒いで問題解決が遅れる」とか「エンジニアは現場の温度感が分かってない」とか、切ないすれ違いを起こしてしまいがちです。

その間をつなぎ、

• 「まずは再現テストとか最低限の情報を整えよう！」
• 「とりあえず現場とお客さん対応の方法考えて、状況によっては謝ってくるよ！(うかつな発言しないから安心してね)」

ということをしてます。

この対応は、非常にアーティスティックなバランスを要するため、若手PdMが一撃でメンタルブレイクを引き起こすことがあります。
適切な経験を持った人にお願いする勇気も必要かもしれません。

感じたこと

改めて書き出してみましたが、色々な人に頼って存在しているんだなーということを再確認しました。

プロダクトマネジャーとか言ってますが、自分ひとりではお客さんを連れてくることもできないし、デザインすることもできないし、コーディングもできないし、トラブルの原因究明や対策なんてこともできません。

なので、せめて皆の考えてることをひとつのビジョンにリンクして、その実現のために皆をモチベートできる存在でありたいなーと思ってます。

まだまだ未熟な面も多いので迷惑かけることも多いですが、色んな人と一緒に成果を喜べるこの役割が、結構キライではありません。(怒られることも、凹むことも多いけど)

注意点１
ここまで上げてきた役割を、全部ひとりでやろうとするとヤヴァイです。大切なのは成果を上げることなので、適切に役割分担しましょう。
巷ではやり始めている「PMMとPdMを分ける」という考えは、とてもステキですね！

注意点２
ここまで書いたことは、あくまでモチベーションクラウドの2019年12月現在のことです。
うちのプロダクトではこんな感じなこともしてるよ！という方がいらっしゃいましたが、ぜひ教えてもらえますと嬉しいです！