トッパンでプロダクトマネージャーってどんなことやってるの？

──本日は、DXデザイン事業部でプロダクトマネージャー（以下PdM）をやっている今井さんに「PdMの役割」や「トッパンでの働き方」をインタビュー形式で深堀っていきたいと思います！

＜インタビュイー＞
今井洋志｜PdM（プロダクトマネージャー）
経歴：エンジニア5年、プロダクトマネジメント2年
趣味：キャンプ⛺

＜インタビュアー＞
原井隆浩｜EM（エンジニアリングマネージャー）
経歴：トッパン一筋20年（PG→SE→PL→PjM→PdM→EM）
好物：スタートアップのPodcastとSpeaker Deck

アイスブレイク

──お、先日取得したばかりのAWS ソリューションアーキテクト アソシエイトのバッチが背景画像に追加されていますね！

そうなんです、まだアソシエイトレベルではありますが、AWSでベストプラクティスを考えながらサービスを構築できるという証明に繋がるので載せてみました。このデジタルバッチのおかげで初対面の方にもスキルを知ってもらえて相互理解が早まると思っています。PdMとして幅広い役割の中で何が得意かを表明することで、逆に弱点を知ってもらえてフォローしてもらえるというメリットもあると考えています。

──初対面でのアイスブレイクのきっかけにもなるし、バックボーンの理解にも繋がるので良いですね。

フロントエンドエンジニアからPdMへ

──それでは、さっそく簡単な自己紹介をお願いします。

実は私は文系でして、にも関わらずトッパンへ転職する前はSIerに新入社員として入社しています。
そこで3年間、受託開発のプログラミングや、プロジェクトリーダーとしてお客様に提案しながらシステムの仕様検討とプログラマーへの指示出しをしていました。

トッパンにはエンジニアとして入社して、主にフロントエンドエンジニアをしながら、プロジェクトリーダーとしても活動をしていました。
現在は、キャリアチェンジしてPdMをしています。

誰のために作るのか？という視点と実現が魅力

──トッパンでPdMはまだまだ少ないと思うのですが、挑戦したいと考えたきっかけは何だったんですか？

原井さんにPdMの存在を教えてもらったというのもありますが、挑戦のきっかけは2つあります。

1．自身のキャリアパスとしてエンジニアよりもプロジェクトマネジメントの方が向いているのでは？と考えていたため
2．受託開発で決められた仕様の範囲でモノづくりをすることに満足できなくなったため

特に「2」は過去の体験から強く感じるようになりました。
私が担当していたBtoBのシステムを実際に利用されるお客様に受入試験として機能に触れてもらうことがあり、現場のお客様から多くの意見を貰いました。

「これどうやって操作するんですか？」
「文字が小さくて読みづらい」
「これはボタンだと気づかなかった」

実はこれ、既存システムの移行案件で、既存と同じ機能であるかどうかを現場の方々に確認してもらうことが目的でした。
意図せずお客様の生の声が聴けましたが、ポジティブな意見は多くは無く・・・

よくある受託開発のモノづくりは役職者からヒアリングして仕様を決めたり、お客様の開発部隊と仕様を決めたりしていましたが、
「プロダクトを実際に使う人が仕様を決めていない。」
これが私の最大のモヤモヤでした。

私が仕事をする上で意識してることは、誰かのためにならない仕事は無駄だということ。
それはただのお金の循環にしかならないと捉えています。

少し極端な考えかもしれませんが、せっかく作ったのに使われないなんて悲しいじゃないですか。
なので、「誰のために作るのか？」という受託開発にはない視点を持ち、実現していくプロダクトマネジメントは私にとって魅力的なロールでした。

──「（受託）プロジェクト」と「（自社）プロダクト」は必要となるスキルセットや考え方も大きく異なるので、まさにチャレンジですね。EMとして「社員の挑戦と、会社の成長をうまく嚙み合わせる」ことを意識しているのですが、PdMへのチャレンジはまさに良い噛み合わせの１つだと感じます。

開発者に軸足を置いたPdM

──PdMとして「開発者」「顧客」「ビジネス」の3つの領域全てをカバーするのは、めっちゃ大変だと思いますが、自分の軸というか得意領域みたいなものはありますか？

そうですね、3つの領域全てを完ぺきにこなすことは人間が生きられる期間で習得することは不可能だと考えています。
これは、よくPdＭのスキルセットとして表現されているプロダクトマネジメントトライアングルの話ですね。

引用（プロダクトマネジメントを学ぶなら、まずはコレから！ | PMノート - かけだしPMのための記事メディア）

私の場合、開発者に軸足を置いたPdMとして活動しています。
企画・要件定義などの上流工程で、開発の工数がかかりそうか、技術的負債やリスクがないかを考えながら判断できるので、開発知見のないマネージャーよりも、手戻りの削減、開発者とのコミュニケーションコストの削減、特に機能を複雑にせずにシンプルにできるアドバンテージがあると思っています。

一方で、マーケティングやデザインの知見はないので、イメージを形にするところや売り方で悩んだ時は専門家にヒアリングをしながら何がいいかを判断していく必要があります。
なので、PdMである限り人を巻き込んで進めていくコミュニケーション能力は求められると考えています。
この三角形でいうと「プロジェクトマネジメント」や「プロダクト仕様」については経験がありますが、最近は「データ分析」、「カスタマー技術サポート」の領域に手を広げてより良いプロダクト開発ができるよう日々精進しています。

「データに基づいた意思決定」を目指す

──データ分析によって今井さんが解決したいことって何でしょう？

データに基づいた意思決定ができるようになりたいですね。
というのも私がPdＭとして活動を始めて大きな壁にぶち当たったのが、「意思決定」でした。

「どの課題を優先して対応するのか？」「どういった機能であるべきか？」「UIはどうあるべきか？」

立ち上げ期のプロダクトではデータもなく、正解のない中でメンバーがなんとなく腹落ちする内容で進めていました。
ただ、やはり納得していないメンバーもいましたし、意見がまとまらない中で進めなくてはならないプレッシャーもあり、妥協して進めていたこともありました。こういった課題を解決するために、データ分析をしてデータを元に意思決定していきたいですね。

──データインフォームドなプロダクトの意思決定はとても重要だし、私たちがやりたいけど十分にやれていない部分ですね。めっちゃ共感します。

PdMとPMM？

──最近では、PMM（プロダクトマーケティングマネージャー）といった役割も注目されていますが、今井さんとしてはPdMとPMMの違いをどのように意識していますか？

PdMの領域が大きすぎるが故に分離したという理解です。
PMMとは？を自分の言葉にすると

何を売るのか、どうやったら売れるのかを「事業性」と「ユーザー視点」の2軸で考え、推進する人

ですかね。SmartHRの重松さんの記事でわかりやすく図式化してくれていますね。

引用（PMMとは？ PdMとどう違う？ SmartHR 重松さんが徹底解説【2021年最新Ver】 | キャリアハック）

こうやって作業分担することは規模の大きくなったサービスにおいてはハマると思っていますが、初期成長の段階にあるサービスではPMMの役割は不要だと考えています。

例えば、以下図のようにSaaSを5つのフェーズに区切った時に

引用（湊 雅之 | Masayuki Minato@ALL STAR SAAS FUND）

「フェーズ1」の段階ではまだ、データも顧客とのタッチポイントも整っていない可能性があるのでそもそもPMMの存在意義がないように感じています。
「フェーズ2」の段階はまだ「売り方」が最優先ではなく、「売り物」の改善が最優先で成功事例を作り出すところに重きを置くのでまだPMMは不要。
「フェーズ3」になるとSaaSで1顧客以上の成功事例（CV・KPIの達成）が出てきて、その成功事例を他の顧客にも拡販していくということが最優先課題になってくるので、フェーズ3以降にPMMのロールが必要になってくると考えています。
このフェーズで「顧客の成功に重点を置く」ということはCS（カスタマーサクセス）が必要になってきて、このCS活動もまた多岐にわたり作業があるためPdMだけでは回せなくなり、PMMが生まれたんだと思います。

──確かに、開発者に軸足を置いているPdMとしては、顧客に軸足を置いたPMMはかなり頼りになる存在ですね。今後、PdMとPMMの連携が不可欠になってきますね。
──ありがとうございます。PdMという役割について、解像度が上がってきたので、次はプロダクトについて深堀りしていきたいと思います。

新規事業は失敗を小さく・早く回して成長する

──担当プロダクトである「ピタマチ」について教えてもらえますか？

自治体と生活者（移住希望者）向けのサービスです。
エレベーターピッチで以下のように表現しています。

・「ピタマチ」は
移住者の獲得に時間を掛けている自治体と増加傾向にある、移住確度の高い移住希望者をマッチングさせたい。移住希望者・自治体向けの、移住マッチングサービスです。
・このプロダクトは
移住希望者の理想と実際の地方暮らしのギャップを埋め、移住希望者が理想の暮らし探しができる。
自治体はコストをかけずに確度の高い移住希望者にアプローチができます。

──どちらか片方でも大変なのに、自治体と生活者の両方の課題を解像度高く捉えるとなると、相当な苦労があったと思います。印象的な苦労談や失敗談があれば教えてもらえますか？

これも意思決定の課題につながる話なのですが、KPIツリーを作って事業戦略を考える際に、自治体のニーズを満たすだけでは、顧客は満たされない。顧客を満たしても自治体は満たされないという「にわとりたまご」問題が出てきて議論が白熱し、なかなか決まらなかったことを覚えています。
また、顧客理解のために、ペルソナやカスタマージャーニーマップを作る際も自治体と生活者で2つ作る必要があり、その両方が満たされるものが何なのかを分析して抽出するには双方の話を聞かないといけないし、たくさんの意見があってまとめ切れませんでした。

二兎追うものは一兎を得ずとよく言いますが、こればっかりは二兎を追いかけずにいられなくて、たくさん失敗しました。
ただ、失敗は悪いことではないので、小さい失敗を繰り返して成果に現れるようにプロダクトの改善を回していければと思います。

──ありがとうございます、新規事業は失敗 or 成功のどちらかではなく、失敗、失敗、失敗・・・の先に成功があるので、いかに失敗を小さく・早く回していくかが大切ということですね！

PdMとしての働き方

──PdMの平均的な一日の働き方ってどんな感じですか？

午前中の方がたくさんアイデアが生まれるので意識的に朝方にしていました。
なので以下のようなスケジュールでした。

6:00　 起床
7:00　 移住に関する情報収集
8:00　 仮説出し
9:00　 メールチェック・返信
|　　　打合せやチケットのやり取り
12:00 昼食
|　　　打合せや開発のレビュー作業など
18:00　終業
|
21:00 寝る前の情報収集

──私も朝方派で昼寝も18分で習慣化してます。学習のためには、どのような工夫をしていますか？

学習する余裕がないくらい忙しい時を除けば基本的に、時間の確保は自分次第でできると思っているのでルーティン化しています。
「平日」だと、移動時間や寝る前に本やUdemyの視聴。
「休日」は土曜日に運動、日曜日に学習というルーティンを組んでます。
できなければ、寝る前に本読んだり、Udemy見たりといった感じです。

あとは、基本自分のタスクは抱えないようにバシバシ、作業を誰かに割り振りしたり、処理したりすることを心掛けています。これはマネージャーとしてデリバリーを意識しているからです。
上手くできると自分に時間ができるので、勤務時間内でも次の計画や作業に向けて学習の時間に充てています。

本当は平日でも決まった時間に学習時間を設けるようにスケジュールに入れて周りにアピールしているのですが、割とそのタイミングで作業をしたくなることが多いので、結局手が空いたときに学習といった感じになっています。

泥臭いDX？

──普段働くなかで、モチベーションを感じるのはどんな時ですか？

• 自分が仕事したことで誰かがポジティブな感情を持つこと。お客様しかり、社内の人しかり
• 探検や目的のない散歩が好きなので。割と無我夢中に新しいことをやるのは好きかもしれないです。
• 期待されたら応えられるように頑張りますね。野球部だったこともあり結果出せるように泥臭く頑張ります

──「DXの"D"は泥臭さ」という説もあるぐらい、泥臭いDXも大切ですよね。

SX（サステナビリティ・トランスフォーメーション）を自分ゴト化

──一緒に働くチームメイトに関して「どのような人」と「どのような課題」を解決していきたいですか？

【どのような人】
プロダクト開発において何事も自分ゴト化できてお客様に寄り添える人の方であれば一緒に議論ができて、向いている先も一緒なので仕事がスムーズに進むかなと考えています。

【どのような課題】
企業利益を担保しながら、社会課題の解決をしていきたいなと思っています。
特にキャンプ好きということもあり、自然環境保護のテーマで何か検討したいなあと思っています。
今は生ゴミを堆肥化（コンポスト）してゴミを燃やすCO２の削減に取り組んだり、畑を借りられるサービスで、スタッフさんに教えてもらいながら野菜を育ててます。🍆🍅

「大事な人へのプレゼント」のようにプロダクトを届ける

──最後に、今井さんの目標を教えてください。
PdMは大変と思われがちですが、同時にワクワクできる楽しさもあります。

例えば、ペルソナのゲイン／ペインポイントについて開発メンバー内で共通認識が生まれてきて、
「こういうソリューションを届けたら喜んでくれそうだ。」
と大事な人にプレゼントを届けるかのようにチームメンバーとサービスを検討出来ているときはとてもやりがいがあり、チームの一体感が合ってワクワクします。

こういった楽しさ（チームの一体感）を増やせると開発メンバーも楽しいし、ユーザーにも我々の楽しさが伝わって、より良いプロダクトが届けられると思っています。

なので、今後はチームの一体感を生みやすい、プロダクト開発の型作りをして、それをトッパンの当たり前にしていきたいです。

──最後まで読んでくださった皆さんへ

トッパンならではの校閲・校正を自動化するSaaSや、社会課題を解決するサービス、医療関連のサービスなど様々な事業が立ち上がっています。
プロダクト開発の型作りや、PdMに少しでも興味をもって頂いた方は是非気軽にお話をしましょう！

プロダクト

• ピタマチ：田舎に移住してゆったり暮らそう
• review-it! for Package：校正業務の"見なくていい"をつくる