プロダクトマネージャーとプロダクトデザイナーに聞く新規事業 SaaS の作り方 〜お互い・エンジニアとの協業について〜
カミナシが新しく設備保全領域に向けて開発している製品の正式リリースが近づいており、それを担当しているプロダクトマネージャーの @migi とプロダクトデザイナーの @satoami に、PdM と PD がどう協業しているか、またエンジニアとどう協業しているかというお話を聞かせていただきました。
ーー 本日はよろしくお願いします！まずはお二人の経歴を簡単に教えてください。
migi：新卒で NTTドコモに入社し、Web サービスのディレクター、データ分析などの業務を担当した後、atama plus で PdM を担当しました。そして、今年4月にカミナシへ入社しました。
satoami：カミナシには2023年11 月入社に入社しました。新卒から事業会社のデザイナーとしてキャリアを歩んできており、BtoBtoC→toCサービスときてカミナシは 3 社目です。
▼satoami さんの入社エントリー
ーー 現在お二人が担当されているプロダクトを教えてください。
migi：カミナシはノンデスクワーカー、現場仕事をされている方向けのプロダクトを提供しています。まるごと現場DX構想を発表しており、「作業方法」「人」「設備」の3つの領域を軸に事業を展開しています。
私はそのうちの「設備」についての課題解決を目指す、新しいプロダクトの担当です。
製造業の方が製品を生産する上で重要な設備保全業務がかなりアナログなので 、IT の力を使って効率よく生産性を上げるということを目指しています。
特に、設備に問題が発生し生産が止まってしまう「ダウンタイム」を短くする、究極的には起こらないようにするために必要な業務支援 をするSaaS を提供していく予定です。
現場の機械・設備の異常報告や修理履歴などの記録を行い、予防保全から事後保全まで設備保全の業務を一気通貫で管理するクラウドサービスです。設備カルテに蓄積したデータ活用によって生産設備の予期せぬ停止を最小限に抑えます。
ーー プロジェクトへのアサインはそれぞれどのぐらいの状況からでしたか？
satoami：入社してすぐがちょうどプロジェクトの始まりのタイミングでした。この領域での探索を始めたぐらいから参加できました。
migi：自分は今年の 4 月に入社して、キャッチアップ期間を経て 5 月から参加しました。すでに satoami さんたちが60 社ぐらいのヒアリングを終え、一部機能のプロトタイプを使っていただいていて、PSF (プロブレム・ソリューション・フィット) が見えてきた時期でした。
ーー プロジェクトはどういう流れで進んできましたか？
migi：最初はエンジニアもデザイナーも入らず、営業スライドだけで仮説検証していたと聞いています。
その後、いくつかの課題仮説が見えてきたので、プロトタイピングして、それを数社使っていただいてフィードバックを収集しました。プロトタイプを使っていただくことで、どの課題をどの順番で解いていくかのストーリーを決めることができ、実際のプロダクトを作り始めたという感じです。
現在、正式リリース前に一部のお客様に先行してご利用いただいています。
satoami：プロダクトを本格的に作るタイミングでエンジニアも増え、チームとして出来上がってきました。
migi：作り始めて 4ヶ月で今のところまで来ているんですね...。
satoami：濃いですね〜。
ーー プロダクトのコードはプロトタイピング時点では一行も書かれていないという感じだったんでしょうか？
migi：捨てる前提の検証用のコードがあったという感じですね。
satoami：展示会とかだと Figma のプロトタイプで試していただいていましたね。
ーー そうすると、かなり具体的なプロトタイプを Figma で作られていたんですね。
satoami：探索時に検証したいことを洗い出し、それぞれの項目に対し「どうすれば検証できるか？それは本当に動くもので検証が必要か？」をPMやチームとよく話し合っています。それはエンジニアの貴重な時間を確実に価値創出に繋がることへ当てたいということや、ユーザーに動くものを見てもらえば検証が進むとは限らない、という理由があります。
ーー プロダクトデザイナーとしてチームとのコミュニケーションで意識していることや工夫していることはありますか？
satoami：最近は「粗いデザインをサッと出して共通認識を作る＆前へ進める」を心がけています。 これまでの経験で、画面が早い段階で登場すると議論が細かい箇所に引っ張られやすくなると感じていて、画面を起こすタイミングやさじ加減は長年の悩みポイントでした。 ですが、今のチームに来てからは、ぼやぼやっとした状態で話し続けるよりも早めにざっくり作ってイメージのすり合わせをするメリットの方が大きくなっています。
話しながら「なぜだろう？」と思ったのですが、エンジニア含めて全員がユーザーに対する解像度が高く、ユーザーストーリーをベースに会話ができているからかも知れないですね。
ーー ユーザーストーリーベースとはどういう会話でしょうか？
migi：こういうゴールを達成したいから、こういうユーザーストーリーを満たしたいんだよね、という会話が中心になっています。画面を見せて「この画面を作りたい」と会話するよりは、ビジネスゴールやユーザーのペインの大きさについて話すことが多いです。
ユーザーにとって、何が達成されるといいんだっけというのを揃えている感じですね。PdM やデザイナーが How だけ持っていく説明はしていないです。なのでエンジニアが Howに対してのみコメントするのではなくて、どうしてやるんだっけ？という抽象度からコメントをしてくれます。
これはエンジニアを含めたチーム全員が現場を見ているおかげかもしれないですね。
satoami：ユーザーストーリーとインサイトを行き来しながら、Howや優先度をチーム全員が納得感持って決めることができていると思います。ユーザーストーリーは「フィルター機能を使用できる」のような機能単位ではなく「設備をすぐに特定したい」など、ユーザーがプロダクトを使って実現したいことや価値を読み取りやすい粒度で共有するようにしています。そうすることで、デザイナーは思いつかなかった実現方法や、「実はこっちの方が簡単だよ」というようなエンジニア視点での意見をもらうことができます。
ーー エンジニアが How を出すケースは多いのでしょうか。
migi：デザイナーの satoami さんに一連の体験をデザインしてもらっています。なので、エンジニアからは体験の大枠の中で「こっちのソリューションの方がいいんじゃないか？」というコメントをもらっています。
satoami：エンジニアがオーナーシップを持ち続けられるようにしたいなというのがあります。
そのため、エンジニアとは整理したユーザーストーリーとそれに付随する顧客の生の声も一緒に確認して、それから画面を見てもらうという感じにしています。
ーー ユーザーストーリーがわかりやすくまとまっていますね！
migi：ユーザーストーリーも型化していただいています！チームのエンジニアからも好評でしたね。
satoami：全体のユーザーストーリーのマッピングもチームでマッピングしてきました。
ーー PdM が細かい仕様を切っていくというのはされているのでしょうか？
migi：今のところ、あえて PRD （要件定義書）を書かないようにしています。まだまだ不確実性が高く、ユーザーからのフィードバックで変更することも多いフェーズなので固めすぎても手戻りが多いからです。
その代わりに、プロダクトが実現したいいくつかのゴール、ユーザーの課題や課題解決した時の価値など、一番抽象度が高いものを定義していて、具体化せずに渡すことを意識してやっています。
これを解決したらユーザーは喜ぶよねー！というテーマをチームに渡している感じです。
細かい優先度を決めるのはもちろんやっていますが、素案のドキュメントを作って、チームで話しながらブラッシュアップして詰めていっています。
ーー エンジニアが事業オーナーシップをもてそうな環境だと思います（※注：インタビュアーはエンジニア出身）。ただ、そうしたい理由はどうしてでしょうか？
satoami：最終的にプロダクトを形にする役割であるエンジニアが、ユーザー解像度が高くオーナーシップを持って走れることが、最短経路で最大の価値を出すことに繋がると考えています。
過去の経験でも、デザイン提出→画面を元に見積り→実装という流れで開発を進めることで、コストパフォーマンスの悪い仕様を知らずに依頼していたり、モチベーションが上がりにくい状況にしてしまっていた反省があります。 何より「誰のためになぜやるのか、それはどんな価値になるのか」を全員が共感できているチームで仕事をするのはとても楽しいので、今の状態をキープしたいです。
ーー ではお互いへの要望みたいなのをぜひお聞きできればと思います。 PdM にとって、デザイナーは何がわかっているといいと思いますか？
migi：カミナシは「現場ドリブン」がバリューにあるように、前提として全員現場に行くチームで、ユーザーを軸にエンジニアもデザイナーも PdM も会話をするようにしています。同じユーザーを見た上で、メンバーそれぞれのいろんな視点からユーザー観点や開発観点が混ざって会話をしています。
特にPdM はユーザー、開発だけでなくビジネス観点もチームに持ち込んでアラインさせる責務があると考えており、常にユーザーの目線だけで語れないこともあります。
そのため、デザイナーにはユーザー目線の最後の砦になっていて欲しいです。それが satoami さんは自然とできていらっしゃるので、ぜひこの状態をキープしていただきたいです。
そして、エンジニアに比べると人数が少ないので、デザイナーとしてここが気になるとか、デザイナーの目線から開発がもっとこうあるべきといった意見は場に出していただけると嬉しいです。
そうするとチームとしてはもっと上を目指せると思うので、ぜひお願いします。
ーー 開発に対してどういう意見を場に出して欲しいというイメージですか？
migi：例えば「実装したもののレビューをこのタイミングでした方がもっと品質が上がるはずだ」とか、「コンポーネントを共通化した方がもっとスピードが上がるはずだからそこに投資がしたい」とか。
ちょうど最近はアクセシビリティの話とかをチームに持ち込んでくれていて、それはユーザーのために必要な観点でした。それをビジネス上のマイルストーンの話と、エンジニアの技術負債を解消したい話とちゃんと綱引きしたいと思っていて。デザイナーはチームの中で人数が少ない側面があるので、押し負けないでほしいですね。
今はチームが小さいので課題になっていませんが、チームが拡大しても継続していきたいです！
ーー ありがとうございます。では逆にデザイナーにとって、PdM は何がわかっているといいと思いますか？
satoami：こんな立派なことを言えないかもしれない。(笑)
migi：ぜひ聞いてみたいですね！(笑)
satoami：えーと…広く PdM に対してですが、自分が弱い領域に強い方と組めると楽しいなと思います。デザインについて分かっていて欲しい気持ちは特になくて、分野は何でも良いのですがデザイン以外の何かしらの事象に強い方と組めると観点が広がって楽しいなと感じます。 でもそれよりも PdM の方は、話しかけやすさとか、意見を聞いてくれる姿勢がわかりやすかったりすると嬉しいです。何を当たり前のことを…という感じなのですが、専門分野のことはその分野のメンバーが強ければ良いと思っています。PdM はチーム内外で様々なメンバーと会話をする必要があったり、各職種の話している内容の主旨を的確に把握しながら前へ進めなければならないと思うので、ヒアリング上手な方はすごく安心します。 migi さんとは半年程ご一緒させていただいていますが、いつも丁寧かつ細やかなコミュニケーションで接してくださるのでとても感謝しています。ちょうど少し前の全体ミーティングで私が発言しそびれてしまい、どうしようかな〜と思っていたのですが、その後の1on1で「さっきのどうでした？」的なフォローアップをすぐ入れてくださって助かりました。 色々なスキルをお持ちな方ですが、コミュニケーション面が一番ありがたいと思っています。
migi：ありがとうございます、そう言ってもらえるのはよかったです(笑）。
PdM はあり方を求められる役割だと思います。ハードスキルより意思決定とか、いろんな人が言っていることを聴いて、考えて、伝える役割で、そこそこ無理難題を言うこともあるので、「この人が言ってるからまぁやってみるか」な状態でいないと チームとしては詰むよなと思っているところもあります。
ーー ありがとうございます。では将来、これからプロダクトをどう成長させていきたいですか？
migi：今のところアナログな業務をしていて、デジタルが届いていないユーザーに「すごく楽になった！」と言ってもらいたい、というのを目指しています。ユーザーの相棒になるような、気が利くプロダクトですね。
自分の大好きな本に「融けるデザイン」という本があるのですが、ユーザーの業務に融けているプロダクトを作りたくて。透明性と身体性の拡張みたいなことをちゃんとやれるのがバーティカルな SaaS だと思っているので、よいチャンスをもらったと思ってやっていきたいです。
そして CEO の諸岡さん（@kaminashi_ceo）がよく言っていますが、僕にとっても、チームのみんなにとっても代表作になるようなプロダクトにしていきたいです。まだ一部のお客さんにしか使ってもらえていないですが、これから世の中に届けて、もっと広く多くのお客さんの役に立ってるぞと実感できるようにしていきたいですね！
satoami：それに加えてデザイナー視点で言うと、デザイナーは「この方がより便利！」を描くことはそれほど難しくはないのですが、今のチームはまだ立ち上げから日が浅く、人数も多くありません。理想を追い求めながらも優先度を決め続ける仕事が中心になっていくと思うので、生の現場を沢山見て得られたインサイトからペインの深さとかユースケースの公約数や大きさなどを見定めながら、最小限でもユーザーが現場で確実に使えて「カミナシ入れて良かった」と感じてもらえるプロダクトにしていきたいですね。
ーー 最後にこう言う人と働いてみたいなという方がいたら教えてください。
satoami：やっぱり現場ドリブンに共感してもらえるようなエンジニアにきて欲しいですね。
migi：そうですね。自分と satoami さんは今のところ境界線を曖昧にしていて、オーバーラップしながら動いていてます。私たちだけでなく、エンジニアもオーバーラップしてくれています。
チームで一緒に要件を決めていくような、そういうカオスな状況でも楽しんでやれる人はとてもフィットするかなと思います。ぜひ一緒に、代表作を作りたいですね！我こそはという方は、ぜひ力を貸して欲しいです。
▼ご応募お待ちしています！
■全求人