はじめまして。
モチベーションクラウドシリーズ Advent Calendar 2019の6日目の記事を担当する武田です。
プロダクトマネジャーになってから、ちょうど1年が経つので、
やってよかったこと、やればよかったことを振り返ろうと思います。
#はじめに
自分の経歴を簡単にお伝えすると
- 2018年4月：新卒でリンクアンドモチベーションに入社
- 2018年7月：エンジニア（の卵）として配属となり、研修が始まる
- 2019年1月：研修が終わり、プロダクトマネジャーとして配属
実は入社した4月から、エンジニアを中心とした開発の職種に新卒を配属するという
会社として大きなチャレンジをするタイミングでした。
受けた研修はとても手厚く、
未経験の自分でも簡単なアプリの作成（要件定義～テスト）までやることができました。
研修後は、自分の希望もあってプロダクトマネジャーに配属となりました。
対象とする読者
- プロダクトマネジャーになりたての人
- プロダクトマネジャーを受け入れる人
- 他社のプロダクトマネジャーがどんなことをしているかを知りたい人
プロダクトマネジャーの役割
ネットや本でプロダクトマネジャーについて調べると、このような定義が見つかります。
プロダクトマネージャーは、「何を作るか」「なぜ作るのか」に責任を持つ人
シンプルで分かりやすいですが、実際に何をするのか曖昧です。
さらに調べてみると、
プロダクトマネジャーの役割は、企業ごとに全く違う
企業によって役割が変わるということもよく聞く言葉です。
企業ごとに違うのなら、上司に聞くのが一番と思い、聞いてみました。
上司「間に落ちそうなボールを拾い続けることが役割だよ」
自分「なるほど...（結局、何するんだろう）」
困った顔をしていたことが伝わったのか
「ここに分かりやすく定義されているよ」とあるものを教えてもらいました。
それがこのプロダクトマネジメント・トライアングルです。
※話を簡略化するために、改案の方を引用しています
要するに、プロダクトマネジャーとは
- 「ビジネス」と「顧客」と「開発者」をつなぐ役割
- それぞれをつなぐためにすべきことは3個ずつある
- 企業やプロダクトのフェーズによって、何を重きを置くかが変わる
ということを理解しました。
今回はこのトライアングルに沿って、やったことをまとめていきます。
1年間でやってきたこと
上司や先輩のサポートのもと、顧客と開発者・開発者とビジネスをつなぐ2つをやってきました。
- 1ヶ月目：オンボーディング（プロダクト・プロダクトマネジャーの理解）
- 2~3ヶ月目：プロジェクトマネジメント
- 4~6ヶ月目：カスタマー／技術サポート
- 7~12ヶ月目：プロダクト仕様・デザイン
1ヶ月目（プロダクト・プロダクトマネジャーの理解）
担当するプロダクトを自分で操作し、どんな仕様になっているのかを理解しました。
また、書籍などでプロダクトマネジャーの仕事内容や、SaaSのビジネスについて学びました。
学びになった本や動画
- プロダクトマネジメント入門講座：作るなら最初から世界を目指せ！シリコンバレー流Product Management
- プロダクトマネジャーの教科書
- INSPIRED
- The Model
- サブスクリプション
やってよかったこと：データベースの構造を理解する
プロダクトを操作するときに
この操作をしたらどのようなデータが変わるのかを考え、
実際に変わるデータの値を調べていました。
実際にデータ構造を理解することで
- エンジニアとの会話ができるようになる
- 仕様を考えるときに、データ処理を意識しながら考えることができるようになる
- 「あるデータを出してほしい！」という社内からの要望に対応できるようになる
といった様々なメリットがありました。
最初はできないことに向き合うことが多い中、できることが増えて自己効力感も持てました。
やるべきだったこと：他社のプロダクトマネジャーと話す
プロダクトマネジャー向けに様々なイベントが開催されていますが、
「知識ないから、話聞いてもわからない」
「懇親会とかで、自分が誰かに話せることなんてない」
といった言い訳をしてしまい、他社のプロダクトマネジャーと話すことをしませんでした。
プロダクトマネジャーの役割は、企業ごとに全く違うと知っていたので、
他の会社でのいい事例をきちんと知り、うまく取り入れることをすべきだったと思います。
2～3ヶ月目（プロジェクトマネジメント）
プロジェクトマネジメントと書くと大げさですが、
スクラムマスターのサポート役として、チームの進捗管理や課題解決をしていました。
当時は4ヶ月の開発プロジェクトを2チーム体制で行っていて、
15名ほどいたチームの予実のGAPを少しでも減らすために、奔走していました。
やってよかったこと：タスクの優先順位をつけ、理由を丁寧に伝えた
チームの進捗を上げるためにやったことは主に以下のことです。
- MUSTとWANTに分けて、MUSTから対応する
- バックエンドとフロントエンドの開発者が同じユーザーストーリを対応する
- 依存関係のあるものから着手をする
QAにうまく引き渡すためには何からやるといいのかを考えて順番を組み替えました。
また、理由を丁寧に伝えることで
個人で開発をするのではなく、チームで開発する意識が生まれ、
チームの雰囲気も良くなりました。
やるべきだったこと：課題管理の優先順位も決める
毎日の朝会では以下のことを聞いていました。
- 予実のGAP
- 昨日やったこと
- 今日やること
- 困っていること
1チームの人数が多いと、朝会が予定している時間をオーバーしたり
１つ１つの課題の深堀りが十分にできなかったりしていました。
また、進捗状況が悪くなると、チーム全体で時間軸が狭まり
なぜGAPが生まれたのか、今日・明日の予定はうまく進むのかといった話に時間を費やしていました。
中には、プロジェクトの振り返りとして話すべき課題（体制などすぐには解消できないもの、要件定義やデザインなどの進め方などすでに終わったフェーズもの）について長時間話すこともありました。
結果として、将来起きそうな課題をなかなかチームメンバーから引き出せず、
問題が起きてから、その都度対処することになってしまいました。
課題を放置するのではなく、今どんな課題を解決することがチームにとって最も効果的かを考えると良かったです。
4~6ヶ月目(カスタマー／技術サポート）
大きなプロジェクトが終わると、お客様からの問い合わせが増えたため、
問い合わせや障害の対応をしていました。
個人的にはここで経験が今に生きていることがとても多くあります。
- 既存の機能の細かい理解が深まった
- 障害に伴って少しずつどういう仕様にすべきかを考えられた
- お客様が困っていることをどうすれば解決できるかの問題解決能力が向上した
やってよかったこと：お客様に伝わる言葉で話す
お客様はプロダクトを自分たちほど知っているわけではありません。
また、技術的なことを知っているわけでもありません。
自分たちが普段使う言葉をそのまま伝えてしまうと、伝わらないことが多いです。
カスタマーサポートチームとのコミュニケーションが多かったですが、
意識していたポイントは以下の通りです。
- 前提となる考えや現状のすり合わせをする
- 問題が起きるときは、発生条件と原因を分けて伝える
- 伝えることを諦めない（伝わらないと思って言わないと隠されているのではないかという印象を与えうる）
社内のカスタマーサポートチームへ伝わらなければ、お客様へは伝わらないと思って話しましょう。
やるべきだったこと：課題の背景を正しく理解するために事前にすり合わせる
お客様が要望していることと本当に実現したいことは必ずしも一致するわけではありません。
実現したいことを正しく理解しようとするあまり、
「それを解決するのは本質的ではない」「本当に実現したいことはこれだろう」と思って、
かえってお客様が思っていることを外してしまうことがありました。
きちんとコミュニケーションをとりながら、
「課題はなにか、その要望の背景はなにか」と適宜確認して、背景や課題を正しく理解するといいと思います。
7~12ヶ月目(プロダクト仕様/デザイン)
この時期から、新規開発の要件定義をすることになりました。
具体的には、顧客や事業の課題、機能の価値、機能の要件などを書いています。
また、新規の画面を作成するときは、デザイナーと相談しながら画面デザインを作成しています。
やってよかったこと：難易度の低い要件定義から始める
いきなり、新しい機能の要件定義をするのは難しいと思います。
自分が最初に取り組んだ要件定義は、「対応する言語数を増やす」という既存機能の改善でした。
新規で考えるパターンやユースケースは少なく、
既存のUI/UXをどれだけ保つことができるか？
他の言語がさらに追加されたときにはどうするのか？
といったことを中心に考えるので、比較的最初ながらも順調に進めることができました。
その後も何度か、全く新しい機能ではなく、
既存機能の改善機能を中心に要件定義をすることで少しずつどうすればいいかがわかってきました。
現在は、新しい機能の要件定義に挑戦中です。
やるべきだったこと：完了条件を明確にする
プロジェクトの炎上を防ぐためにSEが「要件定義」で気をつけたい4つのことにも記載されていますが、曖昧のまま部分を残したり、細部まで要件を詰めきれずに開発を始めてしまったり、手戻りや追加で工数が発生することが多々ありました。
インパクトが
- インパクトが大きいもの
- 異常系のユースケースの考慮漏れ（バリデーション）
- APIの考慮漏れ
- インパクトは小さいが忘れがちなもの
- 画面遷移
- 文言（ツールチップ・）
プロダクトマネジャーもエンジニアも協力して漏れや曖昧をなくしていく努力をしていくために
相互に要件定義書や設計書のレビューを丁寧にして、事前に解像度を高くして開発できるかが重要です。
1年間プロダクトマネジャーをやってみて
今回は、プロダクトマネジメント・トライアングルでまとめましたが、
会社ではスキルマップと呼ばれる
若手からマネジャーまでどのようなスキルを身に着けるべきかという基準を設定してます。
なんとなく与えられた役割をこなすのではなく、
プロダクトマネジメント・トライアングルのどの領域をやっているのか
どんなスキルを伸ばそうとしているのか
を意識することで、プロダクトマネジャーとして成長を実感することができました。
「1年目のプロダクトマネジャーはこんなことをしている」というのがありましたら、
コメントいただけますと幸いです。