今回は、株式会社ナレッジラボでプロダクトマネージャー（以下、PM）を務める小野 敦志さん（@taxashtax）に仕事内容やキャリア、マイルールなどを伺った。
小野さんは、新卒で税理士法人に就職し、アメリカに渡り会計事務所で勤めた後、日本の大手会計事務所で働いていた。その後、現職のナレッジラボに転職し、カスタマーサクセスを経てプロダクトマネージャーにキャリアチェンジした。
そんな彼が「なぜ事業会社のプロダクトマネージャーにキャリアチェンジしたのか？」をはじめ、カスタマーサクセスの経験で培われたユーザーの声から本質的な課題を見つけるVoCのコンピテンシー、ドメインエキスパートとして細部のこだわりは、これからPMを目指す方の参考になるはず！
また、ITの知識が少なかったからこそ意識している、エンジニアやデザイナーに対する尊敬やコミュニケーションの取り方は、長くIT業界で働いている人も改めて大切にすべき考えとなっており必見である。
この記事は100人100色のプロダクトマネージャーのリアルを知るためのインタビュー記事「PdM Voice」の連載第37回目の記事である。
目次
PMノート マツバラ（以下、PMノート）：まずはご自身の仕事について教えてください。
小野：株式会社ナレッジラボという会社で、Manageboardのプロダクトマネージャーをしております。
ナレッジラボは、株式会社マネーフォワードのグループ会社です。
Manageboardは、端的にいうと経営管理や予算管理の課題を解決するためのプロダクトです。
例として、「会社が予算を作り、その予算と実績を比較をする」という、いわゆる予算管理業務は多くの会社で行われているかと思いますが、現状このような業務を表計算ソフトで行っている会社が大多数です。
表計算ソフトで生じる経営管理や予算管理の課題をManageboardというプロダクトを通して解決しております。
PMノート：株式会社ナレッジラボの成り立ちを教えてください。
小野：弊社の創業は2013年です。
創業当初は事業再生コンサルティング事業を行っていました。
その後、Manageboardの開発を始めたのが2017年頃です。
それまではずっと事業再生コンサルティングを中心とする事業を展開していた会社となります。
2018年にManageboardをリリースして、そこからSaaSのビジネスを開始しました。
そのため、創業メンバーをはじめ会計士や税理士のメンバーが多く、私自身もその一員です。
PMノート：続いて、これまでのキャリアについて教えてください。
小野：私は新卒で税理士法人に入社しました。
そこでは3年半ぐらい中小企業向けの税務や会計の仕事を広く行っておりました。
その後、ニューヨークにある会計事務所に転職しました。
そこでも1年半ほど現地アメリカの会計や税務の仕事をしていました。
その後は、日本に帰ってきて大手税理士法人で約5年ほど働いていました。
そこでは国際税務の仕事をメインに、国を跨いだビジネスにかかる税務アドバイスを行っておりました。
そして、その次に入社をしたのが、ナレッジラボになります。
2020年7月のことです。
そこからの2年間はカスタマーサクセスの仕事をやり、その後の2022年12月から現在のプロダクトマネージャーを担当しています。
PMノート：ナレッジラボ社にご入社された際には、カスタマーサクセスを担当されたとの事でしたが、それ以前までのキャリアからガラッと職種が変わられたかと思います。
どのような経緯で入社することになったのでしょうか？
小野：転職したきっかけとしては、「プレイヤーとして自分の会社や事業を伸ばしていく」という経験をしてみたいと思ったということが大きなポイントとなります。
延べ10年ほど税理士法人や会計事務所で働いていたのですが、外部のアドバイザーではなく、事業会社で「自分の会社や事業を伸ばしていく」経験をしたいという思いが強くなってきました。
そのように考えていた時に、ナレッジラボの創業メンバーで私が新卒で入った税理士法人で一緒に働いていた人がいたので、その方にコンタクトをしてみました。
「何かお仕事ありますか？」と聞いてみたところ、「カスタマーサクセスの仕事があるよ」と紹介いただき、縁あって入社をしました。
そのため、カスタマーサクセスの仕事がしたいという想いで転職をしたわけではなく、事業会社で働きたいという想いから、知人の紹介を経て入社をし、たまたまカスタマーサクセスを担当することになりました。
PMノート：新しい職種で業務を行う際に、どのように知識をキャッチアップしてきましたか？
小野：Manageboardは会計に関するプロダクトなので、ドメイン知識に問題はありませんでした。
ただ、IT業界で働いた経験がなかったので、この業界でよく使われている用語は全くわからなかったです。
IT企業で求められる用語などの知識に関しては、基本的に本を中心にインプットしていきました。
今もそうですが、何かインプットする時には本に頼ることが多いです。
PMノート：2022年12月頃からプロダクトマネージャーになったということで、ここでもジョブチェンジをされているかと思いますが、その際はどのような流れでプロダクトマネージャーになったのでしょうか？
小野：会社の意思決定という部分も大きいですが、今までは取締役CPOがプロダクトマネージャーを兼任していました。
取締役ということもあり、経営者としての仕事がある中、プロダクトマネジメントやピープルマネジメントも行っており、職域がかなり広がってしまっていたという課題がありました。
そこで、プロダクトマネジメントの業務は専任で置こうという話になったのですが、ただでさえ少ないプロダクトマネージャーの市場の中、弊社の場合だと、どうしても会計という専門的な領域のドメイン知識が必要となります。
そのような知識を持っている人が社内にいないかと見渡した際に、白羽の矢が立ったのが私となります。
開発経験はなかったのですが、カスタマーサクセスの立場でユーザーの声を届けていたり、前職以前の経験を活かしてステークホルダーの気持ちになりきったりして、「こうした方がいいのではないか？」という意見をよく伝えていたので、その様な部分も加味されて私が選ばれたのではないかと思っています。
PMノート：カスタマーサクセスをやっていたからこそ、プロダクトマネージャーへの移行がスムーズだったということはありましたか？
小野：それは間違いなく、ありました。
全く別の業界から来て、かつ、プロダクトのことを全く分からない状態でプロダクトマネージャーをやって欲しいと言われたら、多分何をやっていいか、何からやればいいのかが全く分からなかった気がします。
カスタマーサクセスの経験を挟むことで、Manageboardというプロダクトがどのように作られているかなどの解像度が高かったので、プロダクトマネージャーへの移行もスムーズにできたのかと思います。
PMノート：所属組織におけるPMのミッションは何でしょうか？
小野：シンプルな表現だと「プロダクトを成功させる」ということになります。
具体的には、プロダクトビジョンを策定しているので、そこに近づける、もしくは、達成するということを長期目線での成功の定義としています。
PMノート：お伺いできる範囲で作成されているプロダクトビジョンを教えて頂けますか？
小野：前提としてManageboardというプロダクトには、「マネジメントプラン」と「アドバイザープラン」という２つのプランがあります。
この2つのプランはターゲットが違い、マネジメントプランは「事業会社」がターゲットとなり、アドバイザープランは「会計事務所」をターゲットにしています。
それぞれのプラン毎にプロダクトビジョンを分けています。
プロダクトビジョンは、会社のミッションである「日本中の中小企業の経営インフラを変えていく」や、ビジョンである「テクノロジー×コンサルティングによって経営のプラットフォームを提供する」をブレイクダウンする形で設定しています。
プロダクトによるサービス提供はあくまでも会社のミッション・ビジョンを達成するための手段ですので、会社のミッション・ビジョンから逆算して、プロダクトで叶えたい世界観を表現しています。
PMノート：プロダクトマネジメントトライアングルを元に、具体的な業務範囲を教えてください。
小野：一番濃度が濃い部分としては、開発者とビジネスの間かと思います。
その中でも特に時間を割いているのは「プロダクト仕様」の部分で、スクラム開発におけるプロダクトオーナーの役割も担っています。
その他には、社内外調整の部分では、社内やステークホルダーへの説明などのコミュニケーションにも時間を使っています。
また、元々カスタマーサクセスを担当していたので、ユーザーとの接点は一般的なプロダクトマネージャーより多いのではと思っております。
カスタマーサクセス時代のつながりから、インタビューなどをさせていただけるユーザーがたくさんいるので、そこは強みと感じています。
PMノート：続いて、12PMコンピテンシーを用いて、小野さんのスキルや強みについて掘り下げていきたいと思います。このフレームワークに基づいて小野さんには事前に自己評価していただきましたが、「Customer Insight」の箇所の平均点が最も高くなっており、特に「VoC」の部分が強みと見受けられましたが、合っておりますか？
小野：はい、そうです。
この部分に関して、意図的にここを伸ばしたいと思いスキル開発をしたというよりかは、2年間行っていたカスタマーサクセスの業務により自然に培われたかと思います。
その際に培われた能力として一番大きいものは「課題の本質を見抜く」という部分です。
カスタマーサクセスをやっていると、お客様から「○○のような機能が欲しい」というような要望があるかと思いますが、その裏にある「本当の課題は何なのか？」という部分を抽出することは特に意識をしています。
お客様が欲しいと思っているソリューションが1番良い解決策とは限らないので、裏にある本質的な課題は何なのかということを見極めることを心がけています。
また、その課題に関しても、最初の時点では抽象的なものになるので、それを具体的にした上でプロダクトに落とし込めるように、情報をうまく整えるところは、特にプロダクトマネージャーを始めてからは意識をするようになりました。
PMノート：他の領域では、Influencing Peopleの「ステークホルダー」の評価が6となっておりますが、こちらはどのようにスキル開発をしていったのでしょうか？
小野：ここでいうステークホルダーに関するスキルとは、「ステークホルダーと協力をして、彼らの要求を製品の決定に反映させる能力」という意味かと思いますが、この部分はもちろん、逆のケースも意識しています。
先ほどの話と似ているポイントではあるのですが、ステークホルダーの要求も必ずしも最適解ではない場合があるかと思います。
様々な立場のステークホルダーがいるので、マーケティングとカスタマーサクセスでは、欲しい機能が全く逆のものであったり、あるいは、経営陣目線では「この機能はいつまでに欲しい」など、それぞれの立場によって様々な意見が出てくるかと思います。
その際には、プロダクトのビジョンに照らし合わせた上で、最適でないものにはしっかりNOを言ったり、私が最適だと考えるものはしっかり反映できるように、コミュニケーションをとっています。
特に、NOとなったものに対して、なぜそれがNOなのかを説明するコミュニケーションは人一倍気を使っています。
PMノート：今まで様々なご経験されている中で、このスキルが磨かれたのはどのタイミングのことでしょうか？
小野：おそらく前職以前の会計や税務の仕事を通じて磨かれたのではないかと思っています。
クライアントの会社の数字を、わかりやすく経営者の方々に説明したり、税務上の取り扱いをわかりやすくまとめてレポーティングするなどの仕事が主だったので、そのような仕事を通じて磨かれたスキルではないかと思います。
PMノート：今までお話いただいたもの以外で、明確にスキル開発をしようと思って取り組んだことはございますか？
小野：Product Excutionの特に「要件定義」や「デリバリー」辺りは、まさに自分でスキル開発を行いました。
エンジニアリングやデザインのバックグラウンドは持っていなかったので、プロダクトはどう作られているのかであったり、デザインの原則は何ぞや、みたいなことは本当にわからなかったです。
フロントとバックエンドの違いもわからないレベルだったので。
そのため、エンジニアやデザイナーに、わからない言葉があったら質問したり、ひたすら本を読んで勉強をしました。
その上で、自分でコードを書いてみたり、デザインを勉強していくことで、彼らと対等にというわけではないですが、彼らが言っている言葉は最低限わかるとか、「こういう仕様にしたいけど、ただし開発上このような制約があるからダメ」みたいなところは、せめて理解できるレベルに持って行こうとして明確にスキル開発をしていたし、現在もしている部分です。
PMノート：現在、向き合っているプロダクト課題は何ですか？
小野：プロダクトそのものの課題ではないのですが、現状プロダクトマネージャーは私1人で担当しており、仕様の決定なども割と深く関わっております。
そのため、良くも悪くも深く入ったことにより、属人化されてしまっているので、そこを仕組み化していくことも課題だと認識しています。
PMノート：「属人化」の部分に関して、どのように解決していきたいと考えておりますか？
小野：しっかり役割分担をすることが必要だと考えております。
要件定義はデザイナーやエンジニアが行い、プロダクトマネージャーは要求定義を行うという感じです。
プロダクトマネージャーとして、「ユーザーは何を求めているのか」「どのような課題を持っているのか」という部分に注力して、その先どのようなソリューションでその課題を解決するかという部分は、デザイナーやエンジニアに渡した上で考えていくことで、役割分担をしていくイメージです。
現状は、私の方で要件定義の部分まで深く入ってしまっている状況です。
そのため、この線をもっと手前に引けるようにしていくことが、解決の道筋ではないかという感覚ではあります。
PMノート：大切にしているマイルールを教えてください。
小野：1つこだわっているとしたら、「細部にこだわる」ということです。
「細部に妥協しない」とも言えますが、この部分にはこだわりを持っています。
具体的には、エンジニアが作ってくれたものにレビューをする際、その時に「ちょっとここのインデントを1列をずらして欲しい」など細かい部分でも、気になった箇所は全部指摘事項として挙げるようにしています。
もちろん時間や工数などの兼ね合いで妥協することは当然あるのですが、基本的には細かい部分でも気付いたものは全部指摘しています。
その背景として、自分が大切にしている言葉に「神は細部に宿る」があります。
本当に細かいところのUIやUXにこだわっているということは、当然大きな部分やメインの部分もこだわってやっているだろうとユーザーも理解してくれていると感じています。
そのため、細かいところだからとか、100回やって1回出会うようなエラーだから適当に対応するなどをしてしまうと、ユーザーの信頼を損ねてしまうので、自分としてはこだわってやっています。
ただ一方で、それが行き過ぎた結果、本当に些細なことで、数週間かけて直すというようなことになってしまうのもナンセンスかと思うので、理想と現実の間の線引きもしっかりやろうとは心がけています。
こだわりをもって向き合いたいとは思っていますが、実際に作業をしてくれるのはエンジニアやデザイナーの方々になるので、そこは人と人のコミニケーションで思いやりを持って、負担をかけ過ぎないようにしています。
そのために重要なのは、やはりコミュニケーションだと思っています。
例えば、レビューに関しても、何もコミュニケーションしなければ、私からの一方的な指示になってしまいますが、「これを直すのはどれぐらい時間がかかりそうですか？」ということは、必ず聞くようにしています。
このようなコミュニケーションを取らないと、些細なことで1週間もかけてしまうということは現実的にあり得たりするので、コミュニケーションをとった上で、『10分ぐらいで終わります』ということならやったり、『1日かかります』という場合は、『本当に1日かけてやる必要があるのか？』ということを一緒に相談しながら決めています。
PMノート：「細部にこだわる」という部分を意識したキッカケは何かございますか？
小野：前職が大手の税理士法人で国際税務のアドバイスをする仕事をしていたのですが、その時の仕事では、日本企業が海外に進出する際の税金についてや、進出した際に気をつけなければいけないことを、パワーポイントにまとめるような仕事が多かったです。
そのパワーポイントの資料が成果物になるため、日本語の表現からデザインの細かい部分まで徹底的にこだわって作るということが会社のルールとなっており、そこで鍛えられた気がします。
資料内のオブジェクト1つとっても、ちゃんと縦横を揃えたり、フォントサイズや色の使い方のルールが決まっており、そこで鍛えられたものを今も引き継いでいる感じはあります。
PMノート：いいチームを作るために工夫されていることはありますか？
小野：「相手の仕事をリスペクトする」ということを大事にしています。
先ほどの話と通ずるところもあるのですが、私自身はコードも書けないですし、デザインもできません。
一方で、エンジニアの方々はプロとしてコードを書ける人の集団であり、デザイナーはプロとしてデザインができる人の集団だと思いますが、それぞれ仕事として出来るように至るまでにかけた時間やお金は、膨大になるかと思います。
逆に私も、税理士などの資格を取るために費やした時間とお金は莫大なものがあったりするので、同じように彼らもプロとして積み重ねてきたものがあることに理解が及びます。
そのようなメンバーの裏側にある積み重ねてきたものを尊重するようにしています。
例えば、何か不具合が出てしまった際にも、不具合が出てしまったことをそのまま責めるのではなくて、『不具合が出てしまったけど、そもそもコードを書けてること自体が私にはできない凄いことだな』と思うようにして、その人に対するリスペクトを忘れないように、コミュニケーションを取るということは意識するようにしています。
PMノート：質の高い企画や課題に対して筋のいい打ち手を生み出すために、意識して取り組まれていることはありますか？
小野：意識しているのは、「関係各所とのコミュニケーションをしっかり取る」ことです。
何かを企画する際に、例えば、セールスはこの機能が欲しいけど、カスタマーサクセス目線だとこの機能はいらない、といったように意見がバッティングしてしまうということは多々あるかと思います。
たとえば、「今回はセールス側の意見を優先させた」という場合、なぜそのように意思決定したかをカスタマーサクセス側にしっかり説明をするということは意識して行っています。
説明をするに当たっては、優先順位を決めるフレームワークが可視化されていないと、理由もなく判断したように映ってしまうので、「この様なルールで優先順位をつけます」というルールをまず最初に作成をして、周知するということをしています。
そのため、そこのコミュニケーションがうまくいく様に事前の準備を行うこともそうですが、1つの意思決定についても、なぜそのような意思決定をしたのかという背景を数字やファクトを使って説明するように心がけています。
また、それ以外では課題に対する優先順位付けには、やはり「ユーザーと話す」ということが大切だと思っています。
自分はこれが課題だと思っていても、ユーザーと話すと実は違ったということは、どうしても出てくるので、時間の許す限りユーザーと話しながら課題を擦り合わせていくということも行っています。
PMノート：ユーザーにはどのような感じで対話を行っているのですか？
小野：直近解決したい課題をベースに、「この課題はこのユーザーが該当しそう」というユーザーに対して、話を伺いにいくイメージです。
そのため、ユーザーに「課題は何ですか？」と聞きにいくというよりかは、「3ヶ月後にこの課題を解決したいから、この課題を持ってそうな〇〇と△△と◇◇に話を聞きにいく」という感じで、課題ファーストで動いている感じです。
ただ、そのためにはユーザーの課題をしっかり把握しておく必要があるため、ユーザーからの要望や課題の管理などを仕組み化してやっています。
PMノート：プロダクトマネージャーにおすすめの本がありましたらご紹介お願いします！
小野：「正しいものを正しくつくる」という本がよかったです。
理由としては、プロダクトマネジメントについて基本から一通り解説されているのはもちろん、それ以外でも、ディスカバリーフェーズとデリバリーフェーズを分けて、なぜディスカバリーするのかであったり、どうやってデリバリーに回すのかという様な部分がわかりやすく解説されており、個人的には凄く学ぶものがありました。
小野さんのお話はいかがでしたか？
感想や得られた気付き、気になったフレーズがありましたら、「#PMノート」を付けてツイートしてみてください〜！
PMノートでは、先輩PMにオンライン相談ができます！
小野さん以外にも、相談可能な素敵な先輩PMがたくさんいますので、こちらからぜひご覧ください！
