事業・プロダクトの成長を長期的に捉え、モメンタムを生み出し続けるCTO兼PdMの視点

今回は、株式会社enpayでPdMを務める田野晴彦さん（@hikoharu06）にお話を伺いました。

田野さんは、ワークスアプリケーションズでエンジニアとしてキャリアをスタートし、その後リクルートに入社。保育関連事業「キッズリー」と、同グループのQuipperで「スタディサプリ」のPdMを務め、Fintech事業を手掛ける株式会社enpayを共同創業し、CTOとPdMを兼務しています。

CTOの職責を兼ねていることもあり、技術的な思想を綿密にプロダクトに織り交ぜる姿勢が印象深く、その姿勢は、私たちが事業やプロダクトの持続可能性や発展性を考える上でとても参考になると思います。

この記事は100人100色のプロダクトマネージャーのリアルを知るためのインタビュー記事「PdM Voice」の連載第19回目の記事です。

集金業務支援SaaSプロダクトのCTO兼PdM

Q. まずはご自身の仕事について教えてください。

株式会社enpay( https://enpay.co.jp )という会社で、取締役CTOを務めております。ただ、スタートアップあるあるだと思いますが、1人が多くの役割を担っている状況でして、私の場合、コードを書き、EM（エンジニアリングマネージャー）として現場の育成にも携わり、そしてenpayのプロダクトマネジメントを行う、という複数の役割を包括して担っています。

田野さんの個人ブログ：https://hikoharu06.hatenablog.com/

Q. 具体的にenpayとはどういったサービスなのでしょうか？

enpayは保育園・こども園・幼稚園・学校・塾・習い事教室などに特化した集金業務支援サービスです。

サービスサイト：https://enpay.co.jp/top/

類似の集金支援サービスとしては、スポーツジムや塾などの集金支援を手掛ける他社サービスがありますが、顧客層が微妙に異なるため、あまり競合という捉え方はしていないです。むしろ我々が競合と捉えているのは、既存の決済手段、とりわけ「口座振替」かもしれません。

というのも、口座振替というのは古くからあるレガシーな仕組みで、事業者（請求する側）にとって口座振替による請求業務は非常に面倒なものとなっています。一見、消費者（請求される側）からすれば、毎月決まった日に費用が自動的に引き落とされて便利に思えるのですが、事業者は決済事業者が提供する管理画面を使って、対象となる口座一つ一つに対して請求し、また残高不足などで引き落とせない場合のイレギュラー業務も煩雑です。

さらに、最近ではd払いやゆうちょの不正引き出しが問題となったことから、口座振替申込のセキュリティが厳格化され、消費者にとっても敷居が高い存在となっています。

そのため、enpayを使うと、事業者は従来の口座振替や現金受け渡しによる業務の煩雑さを解消することができます。

もちろん、消費者にとっても使いやすさを実現しています。保育園の他に複数の習い事を行っているお子さんの保護者様には、これまで事業者ごとに請求の案内がなされていましたが、enpayが導入されることで、複数の事業者からの請求内容がLINEを通して一括で送られてくるようになります。

このように、保育施設や保護者様との間において、これまでの口座振替や現金受け渡しによる集金で生じていた課題を解消したいと考えております。

エンジニアからPjM・EMを経てPdMへ

Q. どのようなキャリアパスでPdMになったのでしょうか？

1社目のワークスアプリケーションズでは6〜7年程エンジニアとして従事していました。経験を重ねるにつれて、PjM（プロジェクトマネージャー）やEMの役割を担うようになりましたが、比較的エンジニアが主体となってサービスの成長を考える文化があったので、PdM的な業務も経験するようになりました。

ですが、本格的にPdMとして従事するようになったのは、2社目のリクルートに入社してからのことでした。入社当初は保育サービスの「キッズリー」のエンジニア・EMを務めていましたが、キッズリーの事業譲渡に伴いチームが解散となり、「スタディサプリ」に関わったことでPdM業務の比重が高まり、私自身の大きな転機となりました。

その頃は世間的にもPdMの役割定義が明確になっていなかった頃でしたので、自分なりにこの組織でPdMはどのようにあるべきなのかを考えながら、色々とチャレンジをしていました。

Q. PdMを務めることにあたってこれまでの経歴とのギャップはありましたか？

特に気にならなかったです。事業にもよりますが、ワークスアプリケーションズではエンジニアが要件定義やUIデザインなどをフルスタックで担うケースが多いです。結構ハードワークでしたが、その経験を通じて、事業やプロダクトと向き合う視野・視座を養えたと感じています。

強いて言うなら、そこからリクルートに転職した時、ギャップの大きさを感じました。

それまでは会社組織が大きく、営業組織と開発組織が分かれていたことで、開発側がプロダクトでどのくらい収益を得ているかなどを知る機会がほとんどありませんでしたが、リクルートに転職し、プロダクトの収益性やユーザーの反響など様々な観点でプロダクトと向き合う機会が増えました。

Q. リクルートは会社全体で見るとものすごく巨大な組織と思いますが、個々の事業やプロダクトはスモールチームが集合しているイメージなのでしょうか？

「ゼクシィ」や「スーモ」など巨大プロダクトの場合だと、事情は違うのでしょうけど、最初に携わった「キッズリー」は1つの事業部内で製販一体の組織として運営していました。私は1社目に属していた組織の経緯から、スモールチームにこだわった転職活動をしてきました。

「会社の成功」が最大のミッション

Q. 今の会社でのPdMのミッションを教えてください。

まだ10名程のスタートアップなので、「会社の成功」が最大のミッションとなっています。

職種ごとに明確なミッションがある感じではないのですが、事業戦略からロードマップを策定し、進捗させることでプロダクトを成長させ、会社を成功させることが私のミッションと捉えています。

現時点での主な事業KPIとして、チャーンレート（解約率）があり、チャーン（解約）をいかにして下げていくかに重点を置いています。ただ、直近ではチャーンも少なく、ユーザー数も堅調に推移している状況です。今後はKPIの磨き込みをしつつ、アライアンス提携の引き合いが増えていることから、その提携関係の強化に取り組んでいく方針です。

テクノロジーを柱としてCEOと二人三脚でプロダクトを牽引する

Q. プロダクトマネジメントトライアングルを元に、具体的な業務内容を教えてください。

CTOのロールを担っていることもあり、開発とビジネスの比重が非常に高くなっています。CEOがビジネスとユーザーに関わるPdM業務に重きを置いており、カウンターパートとして議論しながらプロダクトマネジメントを推進しています。

ちなみにこのプロダクトマネジメントトライアングルの傾向は、前職のリクルート時代も同様でした。リクルートは事業組織ごとにPdMの職責が異なるのですが、スタディサプリを担当していた頃は「TPdM（テクニカルプロダクトマネージャー）」という役割で、プロダクトにおけるテクノロジーの側面に責任を持っており、プロダクトオーナーが全体のPdMを務めるという構造でした。

その他のプロダクトマネジメントの領域については、まず、デザインやデータ分析といった開発とユーザー領域については、私自身が手を動かして進めています。特にデータ分析は前職の頃からかなり経験してきました。一方で、カスタマーサポートやビジネスディベロップメント（事業企画）に関してはCEOと共に推進しています。

CTOの視点でプロダクトのモメンタム（勢い）を維持するためのマイルールとは？

Q. 行動指針やマイルールはありますか？

まず、CTOとして、プロダクトへの機能追加は長い目で見るようにしています。目先にあるユーザーからのニーズや取り込むべき要望があっても、プロダクトを機能させるアーキテクチャが歪んだ形にならないようコントロールし、綺麗に積み上げていかないと、持続的にエンハンスするのが困難になってしまいます。

一方、システム開発のプロジェクトにおいては、半年〜1年といった長期間開発リソースを占有するような大規模なプロジェクトもしばしば行われます。特に技術的負債の返却などは、長い工期を伴うにもかかわらず、ユーザーや社内のセールス担当者からはプロダクトの何が良くなったのかが伝わりにくい開発といえます。言い換えると、プロダクトのモメンタム（≒成長の勢い）が鈍化しているように見えてしまいます。

そうならないように、リリースノートを始め、様々なチャネルを通して、「今回のリリースでこういう部分が良くなった」というのを声高らかに発信し、「プロダクトの成長を演出する」ことも積極的にやるようにしています。

Q. 「モメンタム」という言葉が非常に印象深いのですが、それを維持するための取り組みとしては他にどのようなことを実践していますか？

先程もお話したように、大きなプロジェクトを行う時は、細かいエンハンスタスクを織り交ぜたり、事業KPIに直結する施策とソースリファクタリングを一緒に進めるようなタスク調整を行っています。

また、ロードマップを策定する際、事業とテクノロジーという2つのロードマップを引くようにしています。事業がこの地点までスケールしたら、テクノロジーや品質はこのレベルまで高める必要がある。そうしないとどこかで事業・プロダクトに歪みが出てしまう。というふうに、事業とテクノロジー双方の整合性を取りながらコントロールすることを意識しています。このように、当社ではロードマップを、事業とテクノロジーという二軸で管理をしていますが、エンジニアリソースが1つの組織でまとまっているので、事業をスケールする施策とシステムの品質向上を両立した開発に努めています。

経営視点でテクノロジーと組織・プロダクトのロードマップを考える

Q. PdMとして自慢できる実績はありますか？得意な領域はありますか？

元々エンジニア出身のPdMとして、ビジネスとテクノロジーの両面を考えてロードマップを策定し推進していくことが得意です。事業がこういうふうになりそうだから、技術的な側面でおそらくこういう問題が発生しそう、という観点で考えられることが強みだと感じています。

また、CTOというのは組織で一番技術に長けている人が就くものだと思われがちですが、そうではなく、あくまで経営層の中で最も技術に精通している職責だと、私は考えています。自分のカウンターパートとなるのはCEOや事業部長といった立場となるため、ただ技術的な側面を語るのではなく、経営者然とした立ち回りを意識しています。

Q. ビジネス面や経営者視点といったスキルセットはいつどのような機会で養われたのでしょうか？

リクルートに勤めていた頃かと思います。新規事業コンテストなどが多かったり、事業に携わっていると一緒にプロジェクトを進める事業開発の方から学ぶことも多かったです。他には、大先輩のCTOからお話を伺って学ぶことも多かったです。そのため、体系的に学んだ自覚はないですが、現場で経験しながら学んだという意識が強いです。

ちなみに、スタディサプリでTPdMを務めていた時は、自分とは別の人がPdMを担当していて、職責の境目が曖昧な部分を残しつつも、テクニカル寄りのPdMといったロールを担当していました。

こうした経験もあって、職責を複数の人で割るのか、1人のPdMが担うのか、というふうに、組織作りやPdMにとってより良い配置とは何かをよく考えています。例えばtoB向けプロダクトでは、社内と顧客を両方コントロールする役割が別れている方が良くて、toC向けプロダクトだと1人がオーナーになった方がうまく推進できるのではないか、など、他社事例も見ながら何が最適かを研究しています。

ビジネスの急成長に対応できるプロダクトと開発組織作りへの挑戦

Q. 今、挑戦していることはありますか？

もっぱら、ビジネスの急成長に対応できるプロダクトと開発組織作りですね。これまで携わってきた事業・プロダクトでは、0→1のフェーズに関わることがほぼありませんでした。そのため、多くの技術的負債やアーキテクチャの歪みを目にする事が多かったです。

今は0からスタートしている分、こうした負を生み出さないように、容易にエンハンスができ、ビジネスの急成長に追従できるプロダクトと組織作りにチャレンジしていきたいと思っています。

そのためにポイントとなるのが、先述した通り、プロダクトを長い目で見て、ビジネスの将来的な変化を見据えるということです。特にSaaSは複数の業種に跨ってスケールすることが多く、enpayでは今は保育がメインですが将来的に他業種に展開するようになった際に備え、複数の業種に内在する問題を共通化する視点は必要と感じています。複数の業種に関わっていくと、個々の業種特有の問題が見えてきますが、1つ1つの要望に対応していくとプロダクトの構造に歪みが生じがちになります。

特にビジネスが急成長している今、こうしたプロダクトの構造を共通化していく課題に対応するのは、難易度が高く、チャレンジしがいがあります。

Q. PdMとしての悩みや困りごとはありますか？

PdMの宿命だと思うのですが、器用貧乏になりやすいのが悩みですかね。自分の価値やスキルについて自問自答することがあり、何かしら専門的なものを1つ持っていたいという思いがあります。

今の田野さんは元々深掘りしてきたテクノロジーを伸ばしたいのか、それともビジネスやユーザー領域に理解を広げていきたいのかというと、どちらの気持ちが強いのでしょうか？

今後もテクノロジーを掘り下げていきたいと思っています。

テクノロジーといっても、アプリやサーバサイドなど、専門領域が細分化され、その中にCTO・経営という要素があります。また、一言で経営と言っても、事業の性質や規模によってもかなり毛色が異なり、細分化されると思います。その細分化されたものを掛け合わせて深掘りしていくことで希少性が生み出せるのではないかと考えています。

テクノロジーと組織作りに向き合うPdMがオススメする本

Q. かけだしPdMに向けてオススメする本はありますか？

ベタですが「INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント」がオススメです。一昨年くらいにこの本の2作目が発売されたのですが、私は数年前に1作目も読んでいます。

1作目が発売された当時は、フルスタックなエンジニア組織が良いとされた潮流でしたが、年月が経つにつれ、そのような開発組織があまり今風ではないなと感じるようになりました。そして2作目が発売され、それを読んでみると、開発チームが、モバイルやサーバサイドなど専門領域ごとに分業されている組織を前提に、プロダクトマネジメントを考察しており、現代の風潮に合ってきているなと感じました。

これから読まれる方は2作目からでも充分ですが、1作目から読むと時代の移り変わりが楽しめるかと思います。

あと、「世界で闘うプロダクトマネジャーになるための本 ~トップIT企業のPMとして就職する方法~ 」という本もお気に入りで、発売されてだいぶ経つのですが、MicrosoftやGoogleなどの職責の定義の違いや、採用の仕方も各社特色が感じられる内容となっていて、私自身がPdMの職責の定義に迷っていた頃によく読んでいました。