プロダクトマネージャーを2ヶ月やって思ったこと


# 自己紹介

こんにちは。田村壽英（タムラ トシヒデ）です。

freee株式会社でプロダクトマネージャーをやり始めて早くも２ヶ月が経ちました。この２ヶ月間、どのようにPMとして動けば顧客にちゃんと価値を届けられるか、そのためにどうしたらfreeeの社員が熱狂をもって働けるかを悩みながら活動してきました。この記事では現時点での悩んだ結果を共有したいと思います。

# 背景

PMになるつい最近まではエンジニアとしてあるプロダクトのリーダーをしていました。そのときの悩みはだいたいこんなものでした。

- 今やっている開発が手一杯で次何するかをちゃんと考えられない
- サービス利用者の本当の課題は何なのか十分に検討できないまま開発に入ってしまい、本当にこの機能でよいのか実装中にも迷いが生じた
- せっかく開発した新機能の魅力を営業チーム等の他のチームにちゃんと伝えられてない

このような悩みがあると「このプロダクトはどこに向かっているのだろう？既存のサービスと何が違うんだ？」というのを自分自身だけでなく、社内の人もぱっと答えられない状況になっており、これはまずいなと思ってました。


# プロダクトの思想を明確にする

freeeが活動している会計・給与計算という領域は、法律や昔から慣習が数多くあり、それら全てに愚直に対応しようとすると難解になり、それらの業務の専門家ですら使うのが難しいプロダクトになりがちです。

そんな迷子になりそうな状況の中で、どのような人にどのような価値を提供するのか、つまりプロダクトの思想をまとめた「神ドキュメント」というものを作りました。これは同じfreeeのPMである[aomegane](http://qiita.com/aomegane)が実践していた手法でこのドキュメントがあったプロダクトは設計時から開発まで目的や仕様がブレることなく、すばらしいプロダクトになりました。

この手法を丸パクリして、チームミーティング等で神ドキュメントを共有し、そのプロダクトの判断基準の大元となる「freeeらしいプロダクトのありかた」の認識を合わせて行きました。

ただ、「このプロダクトの思想は何？」と今社内の人に聞いてもちゃんと答えが返ってくるかというと怪しいので繰り返し言い続ける必要があると思っています。

僕自身、判断に迷うときがあればプロダクトがブレないようにこのドキュメントをよく見ています。そして学びがあれば日々このドキュメントをアップデートしています。


# 未来像を見せる

人は自分やっている仕事の価値がわからなくなるとやる気を失います。その逆に今の仕事がどう将来につながるのか明確だと今取り組んでいることの意義がわかり、モチベーションが湧きます。

実際、あるミーティングで「将来はこのようなプロダクトにしたい！」というプレゼンテーションをしたときにチームの熱量があがり、未来を語るのはやはり大事だなと肌で感じることがありました。

また、2～5年先までの具体的な未来像を作ると、この未来にたどり着くには今何をすればよいか考える元になります。


# PMはどのように動くか・どこまでやるか



## 課題の発見・整理

これがPMになって一番やりたかったことかもしれません。社会の、顧客の本当の課題は何かをじっくり仮説検証します。これが今までちゃんとできなかったがゆえに「この機能で本当にいいんだっけ？」という迷いが生じていたからです。ここの課題の発見・整理に失敗するとそれを元にした機能はだいたい無駄になると思います。

社会の習慣・法律・動向を俯瞰しながら、サービスの利用者に常に接している顧客サポートチームや営業チームへのヒアリング、税理士さんや社労士さんからの指摘などを元に、何が本当に問題なのかを探っていきます。サービス利用者に直接会って話を聞くと多くの情報が得られるのですが、この２ヶ月はあまりできませんでした。

もちろん競合サービスも観察しますが、課題に対する仮説の裏付けの１つとして観察します。いきなり競合サービスを観察してしまうと「こういうものだ」と思い込んでしまう危険がけっこうあるので、競合の観察はなるべく最後にするようにしています。

## 餅は餅屋

僕はエンジニアからPMになったため、ともすると本当の課題の探求よりも先にプロダクト上の具体的な解決策を考えてしまうところがあります。ここは今後も直していかなければならないところだと思っています。解決策の提案には謎の自信があったのですが、PMになって１つの課題解決に費やす時間の絶対量が少なくなってきて自分の出す解決策は微妙だなと思う場面が増えてきました。

２ヶ月間で思い知らされたのは、具体的な解決策を考えるのはその機能のエンジニア・UXエンジニアのほうがはるかに上手だということです。だからPMとしては課題の発見・整理をしっかりやって、あとはエンジニアに任せて、具体的な解決方法をじっくり考えてもらうほうが良い物ができます。

このときプロダクトの思想をまとめた「神ドキュメント」の内容がチームにちゃんと伝わっていればプロダクトの一貫性を保てるんじゃないかと考えています。

あとは出された解決策をレビューして課題解決できるものになっているかチェックすればOKかなと。開発が終わった後に「これじゃないんだよねー」と言うのはPMの無責任だと思うので。

## ちゃんと説明する

考える範囲を絞ってその中でエンジニアに解決策について悩んでもらえば出てくる解決策は大ブレはしないはずです。また、なぜその課題なのか、そしてその課題を解くことに価値があるのか納得してもらわないとプロダクトを作る人も、売る人も、顧客サポートする人もちゃんと力が出せないと思います。

とは言え、自分の頭の中の考えを他の人の頭の中に移すのはちゃんとやろうとするとけっこう大変です。なので、なぜそれが課題なのか資料にまとめて説明するのがいいと思います。

効果的だなと思ったのは課題についてまだ整理しきれてない段階から営業担当者や顧客サポート担当者、エンジニアに課題について「相談」してみることです。他チームの本業を阻害しないように注意する必要がありますが、巻き込んで一緒に考えるとお互いの考えが同期でき、なにより思ってもいなかった知見が得られます。

## 社内に血を巡らす

課題が整理できてそれを解決するためにプロダクトが改良されても、その内容やインパクトが社内全体に十分に伝わっていないことがよくあります。例えば、新しい機能が追加されてもその良さや本当の狙いが営業チームに伝わっていないと営業チームはその機能を自分たちで観察し、自分たちで良さを見つけ、そこからセールストークを組み立てなければなりません。すごくもったいないですね。

だからプロダクトの改良されたらその内容とインパクトを資料にして共有します。資料の良いところは一度作ってしまえば何度もいろんな部署に説明しに行く必要がないところです。ただ、資料だけだと思いが伝わらないことがあるので、特にインパクトがある新機能などについては資料をもって対面で話にいくのが一番です。

あと資料を営業用に転用できる作りにしておくと、営業チームが顧客向けの資料の作成する手間も省けます。

# 自分の仕事が手一杯になって回らなくなったらどうするか

これはまずい状況です。たぶんいろいろやりすぎてます。実際、僕も機能の細かい仕様まで首を突っ込みすぎたときがあったりと反省してます。やはり餅は餅屋です。

そんなときは自分の仕事の範囲を明確にしてそれに注力するすることを周りに伝えるのがいいと思います。周りはちゃんと動いてくれます。

あとは素直に助けを求めると良かったです。「これどうするべきか悩んでるんだよね。。どう思う？」けっこうみんな助けてくれます。freeeはいい会社です。

# 何が人を熱狂させるか

ワクワクする未来を示して、その未来に向かって一緒に考え、悩みながらも楽しんで前進している状況が人を熱狂させるんだと思います。その熱狂の中こそで良いプロダクトが生まれると思っています。

PM業は大変ですが、そういう未来を考える仕事をやらせてもらっているのはすごくありがたいです。


# 宣伝
freeeは「スモールビジネスに携わるすべての人が、創造的な活動にフォーカスできるよう」というミッションをもった会社です。現在は、会計や給与業務を効率化するクラウドサービスやモバイルアプリをリリースすることで、ミッションの実現を目指しています。

ちなみに、[freeeのAdvent Calendar 2015](http://qiita.com/advent-calendar/2015/freee) は技術ネタでいっぱいなので、エンジニアの方は是非どうぞ。