プロダクトエンジニアという魚は水が変わっても生きていけるのか？〜toC サービスから IVRy に転職したエンジニアの事例〜
本記事は IVRy Advent Calendar 白組の 23 日目の記事です。紅組は yuki yoshida さんが記事を書かれています。
また、昨日の白組は macchiitaka さんが「Re: チンチロに負けて AI FAX を開発した話」という大変おもしろい記事を書かれています。明日は IVRy 遊佐さんが記事を執筆予定なので、よろしければ合わせてご覧ください！
自己紹介と背景
こんにちは。今年の 9 月に IVRy に入社し、ソフトウェアエンジニアとして働いている新井(@SpicyCoffee66)です。
私は 2017 年度新卒で前職クックパッドにソフトウェアエンジニアとして入社し、時にはエンジニアとしてシステムを開発したり、時にはマネージャーとしてチームを牽引したりと、転職するまでの７年間で様々な仕事を経験しました。時と場合に応じていろいろな役割を担当しましたが、一貫して「ユーザーに価値を届けたい」という想いを持っていました。
転じて自分のキャリア観としては「プロダクト理解と技術力の掛け合わせで価値を出せるエンジニアになりたい」と考えるようになり、当時はサービス開発者の勉強会を企画・運営していたりしました。
近年、自分が目指している、あるいは担ってきた役割が「プロダクトエンジニア」と呼ばれることが増えていることを知ったため、本記事でもその言葉を使います。言葉の定義や役割のイメージとしては、プロダクトエンジニアを定義しているアセンド株式会社の note をご参照ください。
ここまで述べてきたように、プロダクトエンジニアはプロダクトやドメインへの理解と技術力・開発力の掛け合わせで価値を出す役割です。技術力やプロダクト開発の方法論は比較的ポータビリティが高い一方で、プロダクトやドメインの理解についてはそうはいきません。そのため、転職時には「これまで積み上げたプロダクト理解を失っても、自分は価値を出せるのか」と不安になることもありました。前職では 7 年以上一貫して toC サービスに携わっていたため、toB サービスを運営する IVRy への転職においてはなおさらでした。
この記事では、初めての転職によって新たなプロダクト開発に挑戦する際に、自分がどのようにしてプロダクト理解を組み立てているかを述べ、プロダクトやビジネスモデルによらない、一定の再現性を持つ形に落とし込むことを試みます。
プロダクト理解を組み立てる
一口にプロダクト理解を組み立てると言っても、いきなり全ての機能について全てを理解することはできません。私の場合はざっくりと以下のようなモデルが頭の中にあり、それぞれの機能について自分がどの位置にいるかをイメージできるようにしています。
ピラミッドの形をしていますが、厳密に下を満たさないと上にいけないというわけではなく、あくまでもイメージです。まぁ直感的には大きく外していないんじゃないでしょうか。
ここからは各階層についての解説と、それを満たすために私がどういう取り組みをしているかを述べていきます。
プロダクトや事業を好きになる
「プロダクトやドメインを理解する」というのは一朝一夕で終わることではありません。仮説を立て、実装し、フィードバックを得て仮説を組み直す。この営みを何度も繰り返して少しずつ自分の中に積み上がっていくものです。また、重要な事実として、一度理解したプロダクトやドメインも時間と共に変化していきます。つまり、我々はプロダクトやそれが利用されているドメイン、使ってくださっているユーザーさんにずっと向き合い続ける必要があります。
このことを考えた時、そもそもプロダクトや事業が好きかどうかというのは重要な要素です。自分達のつくっているプロダクトが誰かにとって意味のあるものか、きちんと価値を届けているか、その実感を得られているかといった点は、長期的に走り続ける原動力に大きく効いてきます。そしてこれは、「能動的にプロダクトや事業を好きになる」ことが重要なスキルであることを意味します。
プロダクトを好きになるポイントは人によって様々かとは思いますが、自分の場合は「使ってくださっているクライアントさんやエンドユーザーさんの声」が大きな要素なので、意識的にそこを拾いにいくようにしています(*1)。
IVRy では、プロダクトを使ってくださっているクライアントさんにインタビューをさせていただき、導入事例としてホームページに掲載をしています。
この記事を読むだけでも IVRy の意義というものを感じることをできますが、この導入事例インタビューにはメンバー誰でも同席することができます。方法としても、インタビューの予定が確定したら Slack に通知が届き、参加を希望する場合はそれにリアクションするだけ。インタビュー自体は専任のインタビュアーが進めるため参加ハードルも高くありません。
私は何度かこのインタビューに同席していますが、実際に使ってくださっている方の生の声を聞けるいい機会で、参加する度にプロダクトへの愛着が湧いてきます。
機能や利用シーンに詳しい人を知る
プロダクト開発を生業にしている以上、自身が全ての機能について詳しくなることが理想です。しかし、IVRy には現時点でも多くの機能が存在し、それが利用されるシーンもクライアントさんによって様々で、これら全ての掛け算に精通することは実質的には不可能です(*2)。とはいえ、全く何もわかりませんという機能は少しずつでも減らしていきたいものです。横の繋がりが見えない要素が多いとプロダクト開発の精度に関わりますし、障害対応やお問い合わせ対応の際にも困ります。
このことを考えると、機能そのものではなく「機能に詳しい社内の人」を知ることもプロダクト開発において重要になってきます。詳細を知らない機能に触れる機会があった際にヘルプを求め、そのコミュニケーションを通して自分もその機能に詳しくなっていく。そのサイクルが回り始めると、自分の詳しい領域がどんどん増えていきます。
具体の方法としては日々地道にコミュニケーションを取っていくしかないのですが、IVRy には Keep on Groovin' という共創をよしとする Value があり、この辺りの動きが非常にやりやすくなっています。
ウェルカムランチのような活動も活発で、メンバー間に壁を感じない良い環境です。
機能や利用シーンに詳しくなる
自分で機能に詳しくなっていくには、やはり自分で触ってみるのが一番です。これについては通常の開発業務を通して担保できるポイントも多いですが、それだけではどうしても触る機能が偏ってしまったり、断片的になってしまいがちです。かといって漠然と「プロダクトを触る」といわれても、数ある機能からどれをどう使えばいいのか取っ掛かりが掴めないことも多いでしょう。
この段階の理解のために、私は「お問い合わせ起点に機能を触る」ことにトライしています。
IVRy では、主にセールスやサクセス、サポートのメンバーから、クライアントさんの困り事やプロダクトの不具合報告が届きます。その際に、もらった情報をもとに技術調査をして回答するだけはなく、お問い合わせを投げてくれたメンバーに少し踏み込んでヒアリングし、クライアントさんの操作を手元で再現してみます。そうすることで、クライアントさんの実際の操作に沿ってプロダクトを触ることができ、ユースケースに沿って機能を理解することができます。
また、起点がお問い合せであるため、触っているうちにプロダクトの至らない点やわかりづらい点にたどり着く可能性が高く、次の段階であるユーザー課題への理解も深めることができます。
ここではクライアントさんの体験について述べましたが、IVRy は実際に電話をかけるエンドユーザーさんの体験向上も鍵になってきます。この辺りについては今後「プロダクトを触る会」のような取り組みを実施してみようと計画中です。
ユーザー課題に詳しくなる
プロダクト開発がユーザーの生活を豊かにすることを目的にしている以上、機能提供は手段でしかなく、本当に詳しくなるべきはユーザーさんの抱えている課題です。ここに対する洞察の深さは、要件定義のみならず開発フェーズでの設計精度にも影響を与えるため、自分の中にしっかりと積み上げていきたいところです。
ユーザー課題を理解する最もよい方法は、プロダクトを触っているシーンを実際に見せてもらうことです(*3)。IVRy では最近までデザイナーメンバーが少なかったこともあり、プロダクト開発者がクライアントヒアリングを実施する機会はそれほど多くないようでした(*4)。しかし、最近では開発者が商談に同席したり、社内で実際に業務利用をしてくれたセールスやサポートのメンバーにヒアリングをする機会も増えてきています。
私も先日、新リリースした AI 対話機能を実際に業務利用していたセールスとサポートのメンバーにヒアリングをし、プロダクトの解像度がグッと上がりました。
実際にクライアントさんの声を聞く機会としては、先ほど触れた商談やオンボーディングも存在します。商談では IVRy ご利用前のクライアントさんのお話を聞くことができるため、業務オペレーションそのものに対しての課題感をうかがうことができます。2nd オンボーディングと呼ばれる場では、IVRy をご利用いただいた際の困りごとを解消する場のため、プロダクトを使ってみての課題感を吸い上げることが可能です。
私自身はまだ同席を経験していないのですが、多くの商談・オンボーディングは社内に動画が残されているため、よくそれを閲覧しています（この記事も商談動画を BGM にして執筆しています）。
また、ホリゾンタル SaaS である IVRy では、向き合うべき業界やクライアントさんも多岐に渡ります。この難しさに対する明確な回答は私の中にまだないのですが
業界によらず共通するユースケースはしっかりと抽出する
その上で「今注力すべき N=1 である業界・クライアント」に対しては、これまで述べてきた取り組みを愚直に当てていく
ことが必要になるのではないかと考えています。プロダクトに関する知識はプロダクトサイドに、業界等のドメインに関する知識はビジネスサイドに寄りやすい構造ではあると思うので、それを意識しつつ上手く共創していきたいところです(*5*6)。
今後トライしたい取り組み
ここまで私が IVRy に入社してから、プロダクトを理解するために取り組んできたことをまとめてきました。最後に、今後この文脈でトライしていきたいと考えていることを述べて記事を締めくくります。
今後トライしたいこととして考えているのは大きく以下の2点です。
クライアントさんへのヒアリングを目的とした会の設定
エンドユーザーさんへのヒアリング機会の創出
これまで紹介してきた導入事例インタビューや商談、オンボーディングは、それ自体にヒアリングとは別の目的が設定されている時間です。そのため、例えば特定の話題について徹底的に深ぼっていく、といったような時間の使い方は難しいものとなっています。今後 IVRy というプロダクトをより "強く" していくためにも、純粋にヒアリングを目的とした場を設定し、クライアントさんの課題理解を高めるための時間をつくりたいです。
後者について、ここまで触れてきたのは IVRy という商品を契約して使ってくださっているクライアントさんについてが主でした。しかし、IVRy はクライアントさんのサービス向上を通して、実際に電話をかけるエンドユーザーさんの生活を豊かにしたいと考えている会社です。そのため、エンドユーザーさんへのヒアリングについても、今後機会を増やしていきたいです。特に、私が所属している AI チームは「AI がエンドユーザーと対話する」機能をつくっているため、対話体験に対するフィードバックはいくらあっても足りないくらいです。
最後に
ここまでに、私が IVRy に入社してから、プロダクト理解を深めるために取り組んできたことを紹介しました。もちろんまだまだ足りていない点は多くありますが、少しずつ自分の中でこの辺りの型化が進んできたようにも思います。
改めて整理してみると、プロダクトの変化や toC → toB といったビジネスモデルの変化はあれど、「ユーザー課題に向き合うために自分で情報を集める」ことが変わらず重要なのではないかと思います。その根底の上で How の部分で必要なチューニングをおこなうだけという話なのかもしれません。
記事を読んでいただければ伝わる点もあるかと思いますが、IVRy は私のようなエンジニアがプロダクトやドメインをキャッチアップしながら、"Work is Fun" に働ける会社です。その上で、まだまだチャレンジしていける余白も多く、とてもやりがいがある環境だと思います。事業としても「AI 対話を社会実装して、世の中を圧倒的に便利にしていく」という激アツな領域・フェーズに差し掛かっており、ここからさらにプロダクトの "強さ" が求められる局面だと理解しています。
そんなわけで、IVRy ではこのような環境に興味のあるプロダクトエンジニアを絶賛大募集中です！プロダクト・組織・技術とプロダクトエンジニアとして携わる全ての領域に挑戦余白のある最高の環境に身を置いて、社会を便利にするトライをしてみませんか？もし興味を持っていただけたなら、どのような形でも構いませんので是非お声がけください！
*1：一口に「ユーザー」と言っても、B2B2C の IVRy には間の B である「クライアント」さんと、実際に電話をかける C である「エンドユーザー」さんがいます。
*2：日本標準産業分類の中分類のうち約95%に導入いただいており、業種によって利用シーンも様々なので本当の本当に様々です。
*3：もっと言うとプロダクトを触っていなくても、対象ドメインにおいて困っているシーンを見せてもらうことです。
*4：クライアントヒアリングについてはデザイナーに限った業務ではないと思いますが、実態としてはスキルセット的に先導してもらった方がスムーズなことは多いと思います。
*5：「〇〇業界を中心に活動しているセールス」という役割のメンバーも社内にいますが、少し話すだけで洞察の深さに驚かされます。
*6：社内 Notion には「業種別_顧客の痛み理解」というページもあったりします。