この記事は、ニーリーアドベントカレンダー2025 の25日目の記事です。
ニーリーCTOの三宅です。今年もトリを担当します。 去年はDXCriteriaで一年を振り返りました。 今年も振り返りを書くつもりでしたが、振り返ってみると、一番伝えたいのは別でした。
採用で最も苦戦したプロダクトマネージャーの面白さです。
この記事では、ニーリーのプロダクトマネージャーの役割と面白さを1つ紹介します。 テーマは、「業務を無くす」プロダクトマネジメントです。
ニーリーのプロダクトマネージャーとは
ニーリーのプロダクトマネージャー（以下、PdM）は、ミッションを「顧客とマーケットに向き合い、価値提供を創造し続けること」としています。 役割は「特定領域のPLや事業KPIに、裁量と責任を持つこと」と定義しています。 いわゆるmini CEOに近い役割です。
そして、ニーリーのPdMの特徴は、「価値を作るレバーはプロダクトだけじゃない」 という点に尽きます。
ニーリーには「プロダクトエンジニア」という役割があります。
プロダクトエンジニアは事業に染み出します。その結果、PRDを書くようなPdM業務の一部を、プロダクトエンジニアが担う場面があります。開発スケジュールの管理も、プロダクトエンジニア側で対応します。だからこそニーリーのPdMは、さらに事業へ染み出すことを推奨しています。
さらに「事業へ染み出す」とは何か。 それは、「プロダクト × マーケ × オペレーション」、あらゆる手段を使って価値を作ることです。手段を限定せず、使えるものを全部使います。
ニーリーはいま、3つの事業を展開しています。 どの事業でも、価値はプロダクトだけで作っていません。「プロダクト × マーケ × オペレーション」を組み合わせて作っています。
そのため、ニーリーのPdMはレバーを幅広く持つ必要があります。 それもただ、持つだけではなく、使いこなすことが求められます。
そしてこの記事では、「プロダクト × オペレーション」にフォーカスしてお話しします。
機能がないなら、まず自分たちで業務を引き受けるという選択肢
SaaSプロダクトを開発していると、機能要望への対応は避けて通れません。個社カスタマイズの要求。ロードマップにはあるが「今ほしい」という声。対応すべきか、優先順位を変えるべきか、迷う場面は少なくありません。 ニーリーでは、機能がないとき、開発ロードマップの見直しはもちろん検討します。ただ、それに加えて「機能がないなら、まず自分たちで業務を引き受ける」という選択肢を持っています。 プロダクトで解決できないなら、Ops（オペレーション）でカバーする。業務を回しながら、プロダクト化の道筋を探る。私たちはこれを「Opsファースト開発」と呼んでいます。（今、命名しました笑）このアプローチがVertical SaaSで急成長してこれた秘訣の1つだと思っています。
なぜOpsファースト開発を選択するのか
「プロダクトがないのに業務を引き受ける」と聞くと、非効率に見えるかもしれません。 人手がかかる。スケールしない。その通りです。 それでも私たちがOpsファーストを選ぶ理由は、3つあります。
1. 顧客への価値提供を最速最大にできる
SaaSを導入しても、システムを操作する業務は残るため、顧客の業務は楽になれどゼロになることは少ないです。また、データ移行、運用フローの変更、社内への説明など、SaaSを導入するまでにも時間がかかります。 業務がゼロか、少しでも残るか。この差は大きいと考えています。私たちが業務を引き受ければ、顧客は「導入した瞬間から業務がなくなる」状態に近づきます。 私たちは、顧客の業務を最速でゼロにすることを目指しています！
2. 変更をコントローラブルにできる
一度導入されたシステムを変えるのは大変です。 「このフローを変えてください」と頼んでも、顧客側にも事情があります。 結果として、よい機能を作ってもリリースしづらくなります。 現場にとって、業務変更は負担です。通常業務を回しながら、新しいやり方に切り替える必要があります。そのため「今の業務に合わせてほしい」というカスタマイズ要望が増えがちです。 ここにジレンマが生まれます。 一方で、業務を私たちが引き受けていると話が変わります。 やるべきことさえ満たせば、業務フローは自由に変えられます。新機能のリリースも社内で完結します。フォローもしやすく、出しやすくなります。 つまり、価値提供のスピードを上げるためには、「”システム”や”業務”を変えられる側に立つ」ことが重要になります。
3. いいプロダクトを早く作れる
プロダクト開発で一番むずかしいのは、業務解像度を上げることです。 ヒアリングだけでは限界があります。顧客の言葉と、実際の業務にはズレが出ます。 そのズレを埋める最短ルートは、自分達で業務をやることです。 Opsを引き受けると、業務解像度が一気に上がります。 社内に実務者がいるので、いつでも聞けます。自分でも体験できます。 リリースの刻み方も変わります。 外部の顧客向けは、ある程度作り込まないと出せません。 一方、社内ユーザー向けなら相談できます。 「このエッジケースは一旦外してOpsで耐える」、「70点の完成度でも先にリリースして価値検証する」など、小さく出して、早く学べます。
「受ける・受けない」の判断軸
「Opsで受ける」といっても、何でも受けていいわけではありません。 やったことがない業務を正確に見積もるのは難しいです。 しかも、始めるのは簡単です。また、どうしても目先の目標や要望に引っぱられやすくなります。 しかし、判断を誤ると、業務量が膨れ負債となり、 最悪予算を逼迫してプロダクト開発が減衰します。 だから私たちは、受ける・受けないの判断の時に、アウトカム効率（効果と対応コスト）に加えて、次の2軸で判断します。
軸①：トップラインへの影響度合い
この軸は、受ける・受けないの判断以外にも、「受けたOpsをいつ自動化するか」を決めるときにも使います。 優先順位は、次のとおりです。
- トップラインや重要KPIに直結するもの
- 業務効率化を通じてトップラインや事業KPIに効くもの
- 業務効率化でコストが下がるもの
1は分かりやすいです。ポイントは同じ業務効率化でも2と3を分け、基本は1,2を優先することです。コスト削減も重要です。ただし私たちは、事業成長に効く開発を優先しています。
軸②：将来、自動化しやすいか
トップラインに効くなら何でも受けるかというと違います。すべての業務をずっとOpsで対応するわけにはいきません。だからこそ、将来システムで自動化できる見込みを必ず見ます。
ただし、この判断は事業フェーズで変わります。 たとえばパークダイレクトには、貸与物（機械式駐車場の鍵など）の管理ニーズがあります。現物を扱うので、システム化しづらい業務です。私たちは当初、この要望へは対応していませんでした。
いまはフェーズが進み、Opsの体制も整いました。その結果、オプションサービスとして対応しています。「業務を無くす」という価値提供を優先し、受ける判断に切り替えました。
自動化できないなら受けないではなく、理想とする世界観を目指して、その時の事業や組織状況を踏まえて、バランスをとるのが大事です。
プロダクトだけではなくOps組織をマネジメントする
Opsで受けるなら、業務設計が要ります。 組織の構築だったり、メンバー育成も要ります。日々の業務管理も発生します。 ニーリーの特徴は、Ops管理にPdMが深く関わることです。
現在、お金周りのオペレーションを司るPAYグループとそれ以外のオペレーションを司るOpsグループ、それぞれの責任者をPdMが担当しています。PdMが実務の組織を管轄するのは、珍しい構造かもしれません。 しかし、PdMがOps組織を管轄することで、「受ける／受けない」の意思決定スピードを速められ、さらに、業務で得た学びをプロダクトへフィードバックし、プロダクト開発の速度も上げられています。
出口戦略なきOps受けは沼になる
ここまでOpsファースト開発や、PdMがOps管理に関わるメリットを語ってきました。ただ、いい話ばかりではありません。
出口戦略がないと、Opsから抜け出せません。
事業が伸びるほど、業務は増えます。急成長を狙うほど、増え方も急になります。「増える量」より「減らす量（効率化）」を上回らせることが重要です。 でも、引き受けた業務は止められません。必ず回す必要があります。そのため、PdMがOpsに染み出している場合、時間は「回す」側に寄ります。その結果、プロダクト開発に割ける時間が減り、効率化が遅れ、より詰まります。悪循環です。 このループに入ると、抜け出すのは難しいです。だからこそ、受けるなら最初に出口を用意することが重要です。たとえば、効率化のロードマップを先に引き、追加の開発リソースも確保します。
当事者だから味わえる、速さと手触り感の面白さ
プロダクトマネジメントや開発をやってきた人ほど、Opsは「面倒で楽しくない」と感じるかもしれません。自分もそうでした。エンジニアの道を選んだ理由の1つは、「できるだけ楽したい」だったので、その気持ちはよく分かります。
でも、実際にやってみると印象は変わります。Opsは、想像よりずっと面白いです。
わたしは、前職はITコンサルで、業務効率化の案件を多くやっていました。 仕事自体はやりがいがあり、楽しかったです。ただ、不満もありました。業務を変えるスピードが遅いことと、変わった実感を持ちづらいことです。
金融のように業務の正確性が重要な領域では、業務変更に慎重になるのは当然です。 それでも自分は、もっと速く業務を変えたかった。 また、システム導入で「楽になった」と言われたときは嬉しいですが、当事者ではない自分にとっては手応えが薄い、そんな感覚が残りました。
けど、今は違います。 自分の裁量で決められるので、変えるスピードが速い。遅いなら自分の責任です。 変化もダイレクトに返ってきます。自分次第で、業務変革のダイナミックさを手に入れられる。それが、いちばんの面白さです。
さいごに
ニーリーのPdMの役割と面白さの1つとして、Opsファースト開発を紹介しました。 PdMがOpsへ染み出し、業務を引き受け、業務を無くしていく。そんなプロダクトマネジメントの話です。
「業務効率化」と聞くと地味に見えるかもしれません。 でも実際は、変化の速さと手触り感があります。しかも、インパクトも出ます。だから面白いです。
最近はプロダクトAI開発チームと組み、AIで業務の完全自動化にも挑戦しています。 ビジネスだけでなく、技術的にも面白いフェーズです。
業務効率化の余地は、まだまだあります。 業務を減らし、可処分時間を増やし、社会をよくしていきましょう。 少しでも興味を持っていただけたら、カジュアル面談で話しましょう。
カジュアル面談はこちらから！
