本記事は、正解のない状況で意思決定を迫られるプロダクトマネージャー（PdM）に向けて、SaaSスタートアップの第一線で活躍するカミナシ右田涼氏による勉強会の内容と学びをお届けします。

事業変革を支えるテクノロジーとPdM

こんにちは、ドコモデータプラットフォーム部（以下、DP部）PdMチームの浜松、三上です。

ドコモは現在、お客様に様々な価値を提供するため、通信事業に留まらず、様々な事業を展開しています。　変化の激しい時代の中で、止まることなく最高のCX（顧客体験）を届けるためには、日々事業そのものを変革し続けることが必要です。DP部では、AI×データを活用して、事業変革を加速させる、『事業オペレーション変革プロジェクト』を推進しています。

これは、単にデジタルツールを導入して業務を便利にするだけの「業務改善」ではありません。プロセス・データ・AI・人を一体で捉え、事業が成果を出し続けるための“運営の仕組み”そのものを再設計する取組みです。

これまで各現場では、AIやデータ活用に関する挑戦が数多く行われてきました。一方で、それらは個別最適・属人的な取組みに留まり、事業全体の成果や再現性のある運営モデルにまで昇華しきれていない、という課題がありました。そこで私たちは、「業務の集合体として事業を見る」のではなく、価値を生み続けるオペレーションとして事業を捉え直す必要があると考え、「事業オペレーション変革プロジェクト」を推進しています。

この変革を実現するための中核として、社内データ活用プラットフォーム「Pochi（※1）」を展開し、その上で動く130以上のアプリケーション一つ一つを「プロダクト」と定義しています。そして、それぞれのプロダクトにプロダクトマネージャー（以下、PdM）を配置し、現場密着型での変革に取り組んできました。

その中で見えてきたのは、PdMの意思決定の質と速度が、変革のスピードと成果を大きく左右するという事実です。

一方で、PdMという役割はまだ発展途上であり、「正解のない状況でどう決めるのか」「事業KGIと日々のプロダクト判断をどうつなぐのか」といった問いに、私たち自身も日々向き合い続けています。

こうした課題はドコモ固有のものではなく、現場変革やプロダクトづくりに取り組む多くの組織に共通するテーマでもあります。

そこで今回、私たちと同じように「現場の変革」に向き合い続けているPdMの先駆者、株式会社カミナシの右田涼さんをお招きし、勉強会を開催しました。

テーマは「プロダクトマネージャーのマインドセットと実務」。スタートアップのPdMとして第一線で活躍する右田さんの言葉には、組織の規模を問わず通じる、本質的なヒントが詰まっていました。

本記事では、その講演と質疑応答の様子と学びをレポートします。

株式会社カミナシについて
「ノンデスクワーカーの才能を解き放つ」をミッションに掲げるスタートアップ企業です。工場や店舗など、PCやデスクを使わない現場向けにDXプラットフォームを提供しており、現場帳票のデジタル化をはじめとした複数のプロダクトを展開しています。

登壇者プロフィール
右田涼氏（株式会社カミナシ / プロダクトマネージャー） 2015年にドコモへ入社し、ヘルスケア事業やデータ分析業務に従事。その後、教育系スタートアップを経てカミナシへ入社。現在は新規事業のPdMとして、工場の「設備保全」に特化したSaaSプロダクトの開発を牽引。点検・記録をデジタル化して予防保全につなげることで、保全担当者が誇りを持って働ける世界の実現を目指しています。

社内データ活用プラットフォームPochi（※1）とは
私たちDP部は社内のデータ民主化を目指し、StreamlitとGoogle Cloudを活用したデータ活用プラットフォームを開発・推進しています。このプラットフォームは、24年度には30万時間もの業務効率化を実現し、直近では5,000人以上の社員に利用が拡大しています。
参照：ASCII.jp：NTTドコモ、Streamlit利用の“ポチポチ分析アプリ”開発で社内データ活用を促進
※1: Pochiは社内の開発コードネームです

【講演パート】正解のない中で「決める」ためのマインドと仕組み

前提は違っても、PdMの悩みは共通している

ドコモとカミナシでは環境が大きく異なります。しかし、前提の違いがあっても、「正解のない中でどう意思決定するか」という悩みは共通していると語ります。

PdMの本質は「価値を決める」という役割

右田さんは、PdMの役割を次のように整理しました。

エンジニアリング：「どう作るか（How）」を担う
プロダクトマネジメント：「どんな価値を届けるか（Value）」を担う

「良いプロダクト」の定義は、toCかtoBか、フェーズがどこかによって変わります。だからこそPdMは、「誰を、どんな状態にしたいのか」を言語化し、そこからブレない軸を持つ必要があります。

プロダクトビジョンという「北極星」

不確実性の高い世界で判断し続けるために必要なのが、プロダクトビジョン=「製品が将来実現したい理想の世界観や、顧客に提供したい価値を明文化した未来像」です。

右田さんはこれを「北極星」に例えました。カミナシの設備保全プロダクトでは、「保全担当者が誇りを持って働ける状態」を掲げ、紙での記録からデジタルへ、トラブル対応中心の対処方法の確認から、予防保全への転換をプロダクトを通して後押ししています。

「判断」と「決断」を使い分ける

プロダクトマネジメントにおいて、何かを決める時に情報が十分に揃うことはほとんどありません。そこで右田さんは、「判断」と「決断」を意識的に使い分ける重要性を語りました。

判断：情報を集め、整理すれば自ずと見えてくる答え
決断：情報が不十分でも、「やる」と腹を括り、選択肢を捨てる行為

PdMは、可能な限り「判断」の領域を広げる努力をしつつ、最後の最後は「決断」から逃げてはいけない。選ばなかった選択肢を捨てる覚悟こそが、PdMの仕事だと強調されました。

不確実性と向き合うための「3つの覚悟」

右田さんは、PdMに必要なマインドセットとして次の3つを挙げました。

1. 決めるのは自分

意思決定は、最も情報を持ち、最もコミットしている人が行うべきです。それは多くの場合、PdM自身です。PdMは上司や周囲を動かす「Managing up」や、権限がなくても影響を与える行動「Influence without authority」といったアクションを意識し、提案の質を高めることが求められます。

2.Noと言う

「やらないこと」を決めることが、開発速度に最も効く。作らなければ実装コストはゼロです。まずは「どうやってやらずに済ませるか」を考える。開発チームの会話が価値ではなく機能の話ばかりになっていたら、ビルドトラップに陥る黄色信号。「価値」を意識するうえで、機能リリースを祝うのではなく、価値が届いた際に祝うマインドセットも重要。

3.実行する

PdMは「プロダクト成功のために、あらゆることを何とかする人」。職能や役割の境界を越え、浮いているボールを拾い続けることが信頼とスピードを生みます。

覚悟だけに頼らない。「不確実性を下げる仕組み」

右田さんは、「覚悟」だけでは長く戦えないとも語ります。重要なのは、意思決定を支える仕組みを回し続けることです。以下の3つが特に重要だと話します。

1. 現場という一次情報に触れ続ける

カミナシでは昨年度、年間約3,900回の現場訪問が行われています。右田さん自身も、入社して20ヶ月で約70回訪問したといいます。PdMだけでなく、エンジニアや経営層も現場に足を運び、「憑依できるレベルで顧客を知る」ことを大切にしています。

2. 広義のデータマネジメント

定量・定性データだけでなく、「いつ、なぜ、その意思決定をしたのか」というログを残し、学習に活かします。

3. 高速な学習ループ

リリースはゴールではなく、価値提供のスタート。小さくリリースし、測り、学び、修正する。このループを高速で回すことで、不確実性を少しずつ下げていきます。

まとめ：正解は「作っていく」もの

プロダクトづくりは、正解のない中で決め続けるものの連続です。不確実性とうまく付き合うためには、覚悟と仕組みの両輪が必要です。最後に右田さんは、こう締めくくりました。

PdMは、学びが尽きることのない仕事。自分で決めて、責任を持ち、新しい当たり前を作れる。正解を自分たちで作ることを、ぜひ楽しんでほしい。

PdMという仕事の厳しさと、それ以上の面白さを改めて実感する講演でした。

Q&Aセッション

イベント後半では、会場およびオンライン参加者から多くの質問が寄せられました。右田さんとの質疑応答の全内容をお届けします。

Q1. 個別要望と汎用化のバランスはどう取る？

質問者：現場に入り込むと、その現場特有の条件や仕様に引っ張られることがあると思います。カミナシさんでは、そうした「型から外れた個別要望」に対してどうアクションしていますか？

右田さん：私が担当しているプロダクトの場合は基本的に個別カスタマイズは原則していません。SaaSビジネスとしてスケールさせるためには、特定の1社にしか使えない機能を作ると後々リスクになります。「共通化して機能にできるか」「他社でも使えるか」を重み付けして判断し、個別対応しないと導入できないと言われたら、残念ですが丁寧に開発方針をお伝えした上で「すみません」とお断りすることもあります。ただ、関係が切れるわけではなく、「できるようになったら教えてね」と言っていただけることも多いです。そこは事業上のバランスですが、基本的には「汎用化できないものは作らない」スタンスです。

Q2. 関係性のない企業へのヒアリングはどう行う？

質問者：社外ユーザーへのヒアリングについて、全く関係性のない会社にはどうアプローチして信頼関係を築いていますか？

右田さん：ヒアリングするときの大前提は、まずは「いいやつ」であること、そして圧倒的な業務理解です。相手の業務を深く理解していると「こいつになら話しても大丈夫だ」と信頼されるのが早いです。製造業の現場の方は「現場で同じものを見ながら話せる方がいい」という方が意外と多いので、あまり「来るな」と言われたことはありません。アプローチ方法としては、ターゲットに近い既存顧客に聞くのが一番早いですが、新規事業の立ち上げ初期などはハウスリスト（メルマガ等）に投げ込んだりもします。私が担当したサービスの初期は、メールを送って反応があったお客様にひたすらヒアリングに行きました。最初は「お前ら何なんだ」と言われても、「あ、そうですか、改善します」と受け流して改善を続ける鈍感力も大事ですね。

Q3. 「決断」の踏ん切りはどうつける？

質問者：「覚悟を決める」ことの重要性は理解しました。ただ、考えようと思えば無限に考えられます。どこまで考えたら決断に至るのか、踏ん切りをつけるポイントはありますか？

右田さん：ユーザーの反応を見て「これはいける」と確信した瞬間です。機能開発であれば、ゴールを設定し、検証すべきことを書き出し、クリティカルパスを整理します。その上で、コンセプトやモックをユーザーに当てて検証します。不確実性を減らすには、ユーザーが実際に使う環境にいかに早く持っていくかが勝負です。感覚的に決断するというよりは、フィードバックを受けて「もうこのソリューションでいけるね、これしかないね」という状態にしてから進むイメージです。すぐにモックを作って感触を聞きに行くといったスピード感でやっています。

Q4. デザイナーやエンジニアと一緒に現場に行く価値は？

質問者：現場訪問の際、PdMだけでなくデザイナーやエンジニアも同行されているとのことですが、連れて行くことで何か違いはありますか？

右田さん：全然違います。例えば、工場の方が衛生管理のために分厚い手袋をしてタブレットを操作していたり、場所によってはネットワークが届いていなかったりします。「この回線速度じゃサービスは使いづらい」「ボタンはこの大きさじゃないと押せない」といった課題をエンジニア自身が肌で感じることで、「これは改善しないと無理ですね」と自発的に修正が始まります。私が「改善、修正したほうがいいんじゃないか」と説得する必要がなくなり、チームに強いオーナーシップが生まれます。

Q5. 決断後の振り返りやピボットの判断は？

質問者：一度決断して突き進んだ後、それが間違っていたかどうかの検証や、方向転換（ピボット）の判断基準はどうされていますか？

右田さん：今の事業では大きなピボットは経験していませんが、意思決定の一貫性とログは大切にしています。「なぜ今この開発テーマを選んだのか」「ビジョンに向かっているか」というドキュメントを残し、後から振り返れるようにしています。もし事業が伸びない場合は、市場への出し方が悪いのか、プロダクト自体がズレているのかを点検し、必要であれば方向転換します。半年前のことは忘れてしまうので、未来の自分のためにログを残している感覚ですね。

Q6. 「機能の話ばかり」になるのをどう防ぐ？

質問者：議論が「機能の話（How）」ばかりになっていると黄色信号というお話がありましたが、それに気づいた時、どうやって軌道修正していますか？

右田さん：プロセス自体を「Why」から始めるようにしています。例えばAI機能を作る際も、PdMが仕様書を書いて渡すのではなく、まずは「お客さんの業務フローはどうなっているか」「どんなユースケースか」という認識合わせをエンジニア・デザイナー全員で行います。そこからドメインモデル、データモデル、実装へと落とし込むので、議論がHowに偏って詰まったら、一つ前の「業務フロー」や「ユースケース」の話に戻るようにしています。仕様書などを私が一人で書いて渡して、作ってくれということは絶対にしていないです。

Q7. PdMとしての学習の優先順位は？

質問者： PdMは見るべき領域が広いですが、学習の優先順位はどうつけていますか？また具体的な学習方法は？

右田さん：「バーベル戦略」で優先度をつけています。直近で必要な緊急度の高いスキル（例：今はセールスイネーブルメント）に8割、中長期で必要なスキル（例：組織マネジメント）に2割の時間を割くイメージです。学習方法としては、最近は本を読むよりも「人に聞く」ことが多いです。Xで経験者にDMして話を聞かせてもらったり、社内の専門家に教わったりします。また、強制的に仕事の時間を減らして、インプットの時間を確保するようにしています。

Q8. 価値提供できたかどうかの確認方法は？

質問者：「リリースを祝うな、価値提供を祝おう」という言葉が印象的でした。実際に価値が出たかどうかは、どのタイミングでどう確認していますか？

右田さん：リリースしたその日に電話しまくります（笑）。定量データも大事ですが、定性的なフィードバックを最速で取りに行きます。カスタマーサクセスチームにも協力してもらい、お客さんの反応を集めます。年に180回リリースしているので、ほぼ毎日誰かしらとお客さんが話している状態です。淡々と改善を続けます。

Q9. 複数プロダクト間の連携や全体整合はどうする？

質問者：プロダクトが増えてくると、PdM同士の連携や全体設計が難しくなると思います。カミナシさんではどうされていますか？

右田さん：まさに現在進行形で課題になっています。PdMが増えて各自が「個人商店」のように動き出した結果、リソース効率が悪くなったり、似たような機能の検討がそれぞれに動いていたりということが起きました。。そこで今は「ProductOps」というチームを作り、情報流通や意思決定のプロセスを整えています。以前は「自分たちのプロダクトが成長すればいい」という勢いでしたが、今は会社全体の戦略にいかにアラインするかを重視するフェーズに移行しています。組織として全体最適を考えるようになりました。

Q10. チームへの「No」の伝え方と意思決定の浸透

質問者： PdMとして決めること、時には「No」と言うことが大事だと思いますが、それをチームに伝えて納得感を持ってもらうために工夫していることはありますか？

右田さん：「100回でも、1000回でも言う」ことです。ドキュメントを書いてもなかなか読まれません。だからこそ、現場に行き続けて得た一次情報を元に、「なぜこれをやるのか」「なぜやらないのか」を自分の言葉で、腹の底から話し続けます。「俺たちのサービスはこんなもんじゃねえ」みたいな熱いメッセージを書いたドキュメントを渡したりもします。面倒がられても言い続けることで、ふとした時にメンバーが同じようなことをSlackで言っていたりすると、「あ、伝わったな」と感じます。泥臭いですが、コミュニケーション量が鍵だと思います。

学びとまとめ

今回の話を通じて強く感じたのは、「プロダクトマネージャーの仕事は、環境が違っても本質は驚くほど共通している」ということ。カミナシとドコモでは、前提条件は大きく異なりますが、それでも「正解のない中で決め続ける」というPdMの宿命は変わりません。

また、現場に足を運び続けること、定性・定量データだけでなく意思決定の背景をログとして残すこと、そして小さく作って学習を高速に回すこと。これらは精神論ではなく、再現可能な実務プロセスとして語られていました。

これはドコモでもただプロダクトを提供するだけでなく現場に足を運び、声を聴き、データ活用が誰でも当たり前に業務の一部として組み込まれていくように業務変革に取り組んでおり、大きく通じるものがありました。そして特に印象的だったのは、「覚悟」だけでなく「不確実性を下げる仕組み」を徹底的に回し続けている点です。「どの機能を作るか」ではなく、「どんな価値を、誰に届けたいのか」。そして、その判断を将来振り返れる形で残しているか。一つ一つの小さな積み重ねが、大きな成果に繋がると実感しました。

DP部では今回の学びを受けて、・PdMが「Yes/No」を判断する観点の言語化・意思決定を行う際のプロセスの定義と、意思決定背景を残すレビュー項目の整理といった取組みを進めています

正解は、最初からどこかに用意されているものではない。だからこそ、覚悟を持ち、仕組みで支えながら、自分たちで作っていく。その営み自体が、プロダクトマネジメントの面白さなのだとあらためて感じることができました。

本記事が、PdM・エンジニア・データ人材としてプロダクト開発に携わる皆さんにとっても、気づきのきっかけになれば幸いです。今後も外部の知見を積極的に取り入れ、より良いプロダクト開発を目指していきます。右田さん、貴重なお話ありがとうございました！