こんにちは、SmartHR PdMの稲垣（@gackey）です。
本日は、「SmartHRのPdM」連載企画の第4弾！エンジニア専任から、エンジニア・PdMの兼務を始めた疋田駿さんのインタビュー記事をお届けします。開発期間なんと3ヵ月（！）と、爆速の開発速度で新規プロダクトをローンチした敏腕PdMには、どんな思いや工夫が詰まっているのでしょうか。
疋田 駿
SIer、不動産テックのスタートアップにて複数のプロダクト開発を経験。
2018年12月にSmartHRにエンジニアとして入社。文書配付機能の開発を担当し、2020年2月からPdM兼エンジニアとして従業員サーベイの立ち上げを担当。
「組織の病気を防ぐ」従業員サーベイ
稲垣：まずは、担当しているプロダクトについて教えてください！
hikita：従業員サーベイというプロダクトを担当しています。SmartHRに登録されている従業員に対して、例えばエンゲージメントサーベイなどのアンケートを簡単に送信でき、さらに収集した情報を従業員の属性を軸に分析できるプロダクトです。
稲垣：2020年9月リリースですから、現在で約3ヵ月ですね。従業員サーベイでは、どんな課題に向き合っているんでしょう？
hikita：組織課題の発見から解消において、発見・原因特定・対応のそれぞれに課題があると考えています。そもそも組織で発生している課題に気付けていない、気付いても原因が分からない、原因が分からないから、どう対応すべきかが分からない。 組織課題は、大きくなる前に正しく把握して対応していくことが大切だと思っています。 この課題に向き合う中で、「組織課題は、病気と似たような考え方をすることが重要だ」と思うようになりました。病気が症状に表れるように、組織では課題が顕在化します。病気なら体温を測ったり、レントゲンを撮ったり検査をしたりしますよね。病原や影響範囲の特定には、情報が必要なんです。組織課題に対しても同様に、原因や影響範囲を特定したり、未然に防ぐための情報収集ができるようにしていきたいと考えています。
稲垣：普段からどんな情報を収集するかが重要ですね。サーベイが簡単に送信できるだけでなく、課題に合わせた運用方法や、運用に必要な機能も気になります。
hikita：早期に実装したエンゲージメントサーベイは活用しやすい1つのモデルですが、もっと他の課題を知りたいというユーザーのために、サーベイは柔軟に設計できるようにしています。 全社的に行うものだけでなく、例えばマネージャーが部署ごとに行うから意味があるような、細やかなサーベイとかもあると思うんです。できるだけ柔軟な使い方をしてもらえるように、サーベイの作成権限なども柔軟に設定できるようにしています。 ですが、まだまだこれだけでは足りないと思っていて、サーベイについての知識を深めるコンテンツや、カスタマーサクセスとの協力なども強化していきたいと考えています。
最速で学習を繰り返す仕組みと工夫
稲垣：どんなところにPdMとしてのやりがいを感じますか？
hikita：課題に対して解決策を考え、提供して反応を得るという繰り返しにやりがいを感じています。もちろん良いとき・悪いときどっちもあるし、提供する相手によっても結果は違うし、難しくて好きですね。 考えた解決策が間違っていたとしても、間違いに気付けたこと自体が前進ですし、チームでその学習ができるのが大事だと思っています。
稲垣：小さく速い学習サイクルって、0→1の新規プロダクトでは特に重要ですよね。学習サイクルを高速化するために工夫していることってありますか？
hikita：とにかく極力小さくリリースすることと、プランニングで細かく仕様を詰めすぎないことですね。あと僕はプルリクエストをそのままレビューできるので、その点も速さにつながっているかなと思います。夕会で毎日モブレビューを行っていて、細かな確認をそこで終えられるのも良いですね。
稲垣：コードレビューができるのはエンジニアならではですね…！圧倒的な強みを感じます。
hikita：逆に、それしかないですからね。（笑）こうやってプロダクトを作るほうの課題やスピードに全力で集中できるのは、PMMがいてくれるからだと思います。 セールスやCSとのコミュニケーションや、ビジネス側の業務を丸ごと引き受けてもらったり、プロダクト課題の壁打ちをさせてもらっているのも大きいです。もし自分がマーケティングまですべて見なければいけなかったら、こんなに課題検証できていませんでしたし、開発速度も遅かったんじゃないかな。 PMMとPdMの2人体制って、創業者と共同創業者みたいなイメージで、0→1だととてもいいなと思います。
「急成長＝大量の変化」に耐えるプロダクトを設計したい
稲垣：PMMとの協働の仕方もピッタリですね。キャリアの当初から企画職は視野に入っていたんでしょうか。以前のお仕事を教えてください。
hikita：1社目はSIerメイン、プラスちょっと自社サービスをやっていた会社で、セールスエンジニアとして、クライアントへのヒアリングから提案・開発・納品までを行っていました。入社当時、メンバーが5人くらいの小規模だったので、PdM不在・全員エンジニアで、デザインを外注する以外はみんなが全部やる感じでしたね。 2社目も20名以下、TechCrunchの決勝にいくようながっつりスタートアップの会社でした。商用に場所を貸したい人と借りたい人をつなぐマーケットプレイスで、僕が3人目のエンジニアだったと思います。「今期はこのユーザー課題を解決してほしい」くらいの粒度でミッションを渡されるので、ユーザーヒアリングから課題を考えて開発までするし、KPIも見ていました。
稲垣：1社目も2社目も、エンジニアと言いつつ全部やっていたんですね！KPIを見るとは言え、渡されるミッションはユーザー課題だった、と。
hikita：当時同僚だったエンジニア兼PdM的な人がユーザー課題ベースの志向を持っていたので、ミッションはその影響かなと思います。課題から考えるのは好きだったので、楽しかったですし、本当に何でもやっていました。
稲垣：とても充実していたように聞こえるんですが、SmartHRに入社しようと思ったのはなぜだったんですか？
hikita：いくつか要因があるんですけど、プロダクトの課題解決力がビジネスに直結するビジネスモデルをやってみたくなったことが大きな点だと思います。それでSaaSに行きたいなと思うようになりました。 SaaSの中でもSmartHRに入社したのは、急成長ぶりを体験してみたいとか、ドメインそのものが複雑そうな人事・労務領域でモデリングや設計をするのが楽しそうだったからですね。
稲垣：SmartHRには開発に専念するエンジニアとして入社されましたが、抵抗はありませんでしたか？
hikita：プロダクトの仕様やロードマップに関しても質問・提案ができるような環境だったので、抵抗は全然なかったですね。それに、複雑なドメインのモデリングをやりたい、設計力をつけたいという気持ちもあって、やりたいことを楽しくやれていました。 プロダクトって、どんどん変更されていくじゃないですか。その変更を先読みして、いかに後々楽な設計をするかにすごい興味があるんです。経験上、急成長していくプロダクトは負債がどんどんやばいことになっていくのを知っていたからかもしれません。 SmartHRの場合、急成長に加えてドメインが複雑なので、余計に興味がありました。（笑）
稲垣：いかに負債を出さないか、後々の開発者が「設計した人、神じゃん…！」と思うような設計を目指しているんですね。
hikita：はい、手を入れる場所の状態によって、工数が全然変わるじゃないですか。丸々やり直しなのか、1つモジュール追加するだけで良いのか、とか。なので、今でもそういうこと（中長期で見た開発のしやすさ）はとても気にしています。
多様な解を生むチーム総出学習
稲垣：なるほど、開発観点で先を見据えたプランニングをしているんですね。企画の仕方に限らず、PdMの仕事の中で特に大切にしていることって何ですか？
hikita：「今やろうとしていることは本当に問題を解決するのか」と、「その問題は本当に本質的な問題なのか」の2つに意識して取り組むようにしています。 また、その学習を個人ではなく、チームとして蓄積できるようにしたいと思っていますね。
稲垣：チームとしての学習の蓄積、って印象的な言葉ですね。
hikita：僕の中に「エンジニアは解決策を知っているだろう」という前提があるんですね。これまでにいろんなところで経験を積んだエンジニアが集まっていますし、僕だけが解決策を出すんじゃなくて、みんなに解決策を出してほしいな、と思っているんです。 なので、チームとしてユーザーの課題を学習して、どうするのがいいのかをみんなで考えていける状態にしたいんです。
稲垣：疋田さんが大事にしている2つのことを、チームで体現できるようにしていこうとしているんですね。
hikita：そうですね。SmartHRってサービス志向・プロダクト志向のエンジニアを採用しているじゃないですか。僕自身が経験豊富なわけじゃないので、いい形でチームを頼っていきたいです。 エンジニアにガンガン解決策を出してもらうためにも、「問題の大きさ」については注意しなければ、と思っています。以前の僕がそうだったんですが、問題解決に視点を向けていると、問題の大きさとかを深く考えずに解決に向かって動いてしまうことがあったんですよね。でも、ユーザーにとって問題が小さければ、どれだけ良いソリューションを出しても解決の価値は問題の大きさ以上にならないじゃないですか。課題解決の優先順位を明確にするためにも、PdMとしてそこは意識していたいなと思います。
稲垣：チームで学習を積み上げるために行っていることはありますか？
ユーザーからのサポートデスクへの要望は必ず全員に共有しています。またインタビューやユーザーテスト、ユーザー向けの分析会などもチームみんなに参加してもらって、総出で課題を理解するようにしています。 人数も少ないチームですし、スピードは大事だけど開発効率よりも学習の方が重要かな、と考えています。実際、最初は僕が企画して、チームメンバーからの質問に答えることが多かったですが、みんなでユーザーを理解するようにしたことで、チームからの提案が増えたことを実感しています。
「早い方がカッコいい」の代名詞的存在
「チームでコトにあたる」を重視し、チームのありようを大切にする疋田さんに対するメンバーの声を聞いてみました。
工数の読みづらい機能の開発をしたときに、まず技術検証をしてみますと言った数日後にはその機能が完成していた。（PMM）
各方面からの問題点や要望のお問い合わせに対して、既にタスクとしてあがっていたり、開発計画に組み込まれていることが多く、先の先まで見通しているようで驚くことがあります（エンジニア）
仕様などの相談をしたときに適切な回答まで導いてくださるスピードが早いです！PdMでもありエンジニアでもあるので自ら開発されることも多いですが、開発スピードもマッハです！！（エンジニア）
圧倒的なアウトプット量は、高い集中力が支えていそうです。 プロダクトに対して正直で真摯なので、あとからひっくり返すような正論を言っても「いいですね」と受け入れてくれます。 自身にも正直なのでやりたくないことややる気のないことには力を発揮しない傾向がある気がします（人間らしくて素敵）。（デザイナー）
- 人が欲しい物をつくろうという気持ちは強いが、前のめりで突っ込んでいくのではなく、どう作ることで早く提供していけるかを考えているように見える。冷静に状況を判断できることは強みだと言えると思います。（QA）
稲垣：「早いほうがカッコイイ」というバリューがぴったりですね！実際、従業員サーベイの立ち上げにあたって約3ヵ月でのリリースは本当に驚きでした。自分でコードが書けるだけでなく、「どう作ることで早く提供できるかを考える」など、エンジニアとしての視点がプランニングにフィードバックされている点が印象的です。
hikita：プランニングするときには基本的に頭の中でもう設計ができていて、どのくらい期間がかかるかとか、大体わかっちゃうんですよね。企画をしながら調査とかもしてしまうようにしています。 コストとメリットを比較しながらプランニングができますし、企画から提供までが速くはなりますが、できることに縛られてしまう点には気をつけなければと思っています。どうしても、実現できるかを先に考えてしまうんです。
稲垣：理想と現実が頭の中で同時に浮かんでしまうんですね。
hikita：そうですね。PdMならまずは、この問題を解決するべきなのかどうか、解決策はプロダクト提供がベストなのかを考えなくていけないと思っています。 例えば、CSの体制拡充ではなくコンテンツを用意すればいいんじゃないか、とか、つい考えがプロダクトに寄っちゃうんですよね。
稲垣：ビジネス側のチームも巻き込む話はPMMからの意見が重要になりそうですね。「疋田さんの設計全然イケてないよ」って言ってくれるくらいのつよつよエンジニアが現れたらガラリとマインドチェンジされるのでは？（笑）
hikita：「じゃあよろしく！」ってすぐ渡しますね。（笑）そうやってより良い方法を提案してくれるのはめっちゃ嬉しいですし、議論するのが好きなんです。設計だけじゃなくプランニングでも、僕の意見をチームメンバーにもっと跳ね返してほしいなと思います。
稲垣：強みに挙げられていた「冷静さ」にも繋がりますね。今日のお話でも、客観的な視点を大事にされているのかなと感じます。
hikita：うーん、冷静なんですかね。客観性で言えば、何かあったときには立ち止まって「なんで？」を考えるようにしています。前職の上司に「なぜを5回繰り返せ！をクセにしろ」と言われ続けてクセになりました。経験が浅い自分がパッと考えられる答えで済ませてしまうのは危ないと思うんです。 「なんで？」「本当に？」を自分に対して繰り返すことを、今でも引き続き意識しているのかもしれません。
リスクをチャンスに変えるプロダクトづくり
稲垣：PdMになったきっかけは、芹澤さん（CTO）からの提案だったと聞きました。もしジョブチェンジがなかったら、今どうだったと思いますか？
hikita：そのままエンジニアとしてプロダクト作りをしていたかもしれないですし、実際にはもうわからないですが、PdMをやってみたい気持ちが高まっていたら他社への転職も考えていたかもしれません。やっぱりユーザー課題を考えるところからやりたくて、でもPdM専業で入社してきた優秀な経験者がたくさんいる中で自分からは言い出しにくいし、できる自信がなかったんですよね。
稲垣：社員のやりがいを上司が把握して、退職リスクでなく最適配置につなげるって、従業員サーベイにもリンクするお話ですね。
hikita：そうですね、例えば、SmartHRで毎月やっている「自分の能力を充分発揮できていますか？」などのサーベイにそういった役割があると考えています。 定期的に・継続的に同じ質問を繰り返すことで回答の推移が見られて、一時的な悩みなのか、組織で解決が必要な変化なのかを捉えることができます。 もし僕がエンジニアのままだったら、能力発揮や仕事のやりがいのスコアがだんだん下がっていったと思うんですよ。で、一定期間後に面談が入る、みたいな。（笑）情報収集ができていなかったら、やりがいの低下を把握されることもありません。 それに僕の場合はPdMになることが希望でしたけど、人によって解決に必要な対応は全然違っていると思うんです。そういう、個別でより深堀りが必要な点に時間を割いてもらうための情報収集に役立つといいなと考えています。
稲垣：疋田さんのようにエンジニアからPdMにチャレンジしたいと思っている方が最初にまずやってみるなら、どんなことをおすすめしますか？
hikita：いきなり大きくやってみるよりも、小さく試すのが良いかなと思います。影響範囲が小さいプロダクトにチャレンジするとか、もっと小さくいくならまずはPdMに対して提案や質問を増やす、とか。僕の場合は、クロスセルに向けた新規プロダクトの立ち上げだったので、失敗しても売上は下がらないことがプレッシャーを軽くしてくれたと思います。自分に合ったハードルの下げ方を見つけて試せると良いですね。
最後に
プロダクトの課題解決力を上げるには、チームの全員がそれぞれの強みから解決策を出せる状態をつくることが大切だ。聞けばもちろん納得なものの、どんな機会も見逃さずに総出学習を実現し続けられるのは、チーム全員がユーザーを知ることの価値を本気で信じているからこそ、と感じます。従業員サーベイはまだ立ち上がったばかり、今後の機能開発も楽しみですね。
労務の課題解決に始まり、従業員サーベイなど人事の課題解決にも視野を広げ始めたSmartHRでは、解決したい課題がまだまだ山脈のように連なっています。興味を持った方はぜひ、カジュアル面談などお声がけください！
さて、次回のインタビューに登場するのは、非常に複雑度の高い機能開発にじっくり腰を据えて取り組む、SmartHR本体のPdMです。どうぞお楽しみに。2021年も、よろしくお願いいたします！
