Japan Product Manager Conference (#pmconf) に行ってきたのでその所感などを書いてみました

pmconf PM

pmconf.jp

先日、会社のお金で Japan Product Manager Conference (#pmconf) に行ってきました。 学ぶところが多かったので、その内容と所感を簡単にまとめてみました。 （誤植ありましたらご指摘ください、修正いたします）

トピックス

nekokak さんのスピーチ 「大規模システム開発に於けるプロダクトマネジメントについて」

[大規模システムの課題]

サービス開発は具体的なユースケースが想像できるが、大規模システムの場合はパーツごとに担当者がバラバラである。よって、各パーツの作業者は全体像が把握しにくい。 結果、抜け漏れが発生したり、必要なSpecが想定しきれず、抜け漏れが発生する可能性があった。 また、そこから起因して、モチベーションが下がってしまう作業者も発生する危険性がある。

[プロダクトマネジメント]

そこで、全体像を把握し、指揮者として、作業者に適切に伝える人が必要 = プロダクトマネージャー また、プロダクトマネージャーは適宜モチベーターとしての役割も担う必要があるだろう。

freee 「絶対失敗すると言われたプロダクトを成功させること」

そもそも、クラウド会計ソフトをやろうと思ったきっかけは、自身がALBERTでCFOとして働いていて、その時に会計関連業務に感じた課題を解消したいという思いから。

プロダクトによって、スモールビジネスに関わるみんなが創造的な活動にフォーカスできるようにしよう、と考えていた。そのために、これまでのバックオフィスの業務を徹底的に見直した。 コンセプトはスマホから5分で会計などの業務を完了させること。

プロダクトは9ヶ月の開発期間を経てリリースしたが、製作途中のインタビューではほとんど手応えが感じられなかった。殆どの人がクラウド会計ソフトという新しいものに興味を示さなかった。 しかし、それでも実際にプロトタイプまで作ってみて、改めて自分たちの作業をこのソフトを使ってやったらどれくらい業務短縮につながるか計測してみた。 結果、作業量が 1/50 程度となった。

この結果から、迷いは確信に変わり、プロダクトの完成までモチベーションを持って作り上げることができた。

あとになって思うのは、インタビューはペルソナをしっかりと定義し、そこに合致した人に対して行うことの重要性だった。保守的な人は最初の顧客になりえない。この手のサービスの場合、最初の顧客を見つけ、その顧客に最適化する形でプロダクトを成長させていくのが基本。よって、そのような人をきちんと定義してインタビューしたほうが本当は良かった。

クックパッド

クックパッドにはプロダクトマネージャーという肩書の人はいない。 クックパッドでは基本ユーザーのデータから仮説建てを行い、検証するための機能開発を行うスタイル。機能開発はあくまで検証のため、スプリットテストは必ず実施する。 効果があったものだけ、全展開する。

楽天トラベル 「What's PM?」

  • 営業
  • マーケ
  • プロダクト

PM とは、プロダクトやサービスの定義・設計を行う。 顧客を喜ばせ、戦略的な価値を会社に与えるものである。

PM が行う仕事で、必ず行うべきと結論が出ているのはドキュメンテーション。 プロダクト・サービスの定義、設計は必ず文字に落とし込むことが大事。 それがない状態での開発開始は絶対に行ってはならない。

楽天トラベルでは、ドキュメンテーションを行うことをルール化してから、開発スピードが5倍程度まで向上した。

プロダクトを作るときには、一番話者が多い英語で作り始めましょう。話者が多ければ、市場も大きく、結果投資も集まりやすく、世界を取る確率も高まります。

メルカリ 「メルカリ流グローバルなプロダクト開発」

社内リソースの9割をUS開発に当てている。 これを明確にすることで、「どっちのほうが優先度高いんだっけ？」みたいな無用な議論を発生させる必要がなくなった。 新機能はUSにどんどん入れて試し、良かったものを一部JPにも適用、というような考え方。 ソースコードは共通化されており、if文を外せば適用される、という感じ。

[PMにとって邪魔なもの]

  • 余計な説得
  • 余計なツッコミ
  • 余計な心配

メルカリでは経営陣がスピードにこだわっており、とにかく権限委譲をしてくれる。 承認会議もスラックで報告するだけでよくなった。 スピードを高めるためには、経営陣の理解が不可欠である。

学んだこと

  • PM の役割
    • プロダクトやサービスのプロフィールを作り、設計をする
    • 一度出荷したら、その後は定常状態にしない。変化の仕掛けを作る。
    • 顧客を喜ばせ、会社の価値を高める
  • PM に期待されていること
    • プロダクトを出荷させる
    • 市場に受け入れられるプロダクトを作る
  • PM に求められる能力
    • 問題解決
    • コミュニケーション能力
      • 技術の会話ができ、エンジニアからリスペクトされる
    • プロジェクトマネジメント
  • バグの定義
    • 仕様と実際の振る舞いが異なること
      • 仕様に書いていないものはバグではない！！！
  • スピードを高めるためには何が必要なのか
    • 経営陣の権限譲渡が極めて重要