ジョブは、成熟しない

自己紹介

ラクスで楽楽明細、楽楽電子保存、楽楽債権管理と複数プロダクトのプロダクトマネジメントを担当しており、この複数のプロダクトを担当する組織のマネージャーをやっています。紀井です。

ある違和感から

プロダクトマネジメントの現場で、こんな会話を聞いたことはないでしょうか。

マーケティングの教科書に出てくるプロダクトライフサイクル(PLC)を学ぶと、自然とこういう発想になります。導入期→成長期→成熟期→衰退期。成熟期に入ったら投資を絞り、刈り取りに回る。そう理解している人は少なくありません。

私は複数のプロダクトのプロダクトマネジメントを担当しています。長く市場で使われているプロダクトに関わっていると、PLCの教科書的な発想や世間一般の見方として、「成熟したプロダクトは、もう大きな開発はないのでは」という前提に触れることがあります。

そのたびに、私の中には小さな引っかかりが残っていました。「成熟」という言葉だけで、そのプロダクトのこれからを語り切れるのだろうか、と。むしろ私自身の実感は逆で、長く使われているプロダクトほど、解決すべき顧客の課題はまだ山ほど残っている、というものです。

一方で、現実には成熟期に機能開発を縮小していくクラウドサービスも確かに存在します。そして、その縮小が正しい経営判断である場合もある。

この記事では、PLCとジョブ理論(Jobs to be Done、以下JTBD)という2つのフレームワークを突き合わせて、「機能開発が減るのか」という問いを、「機能開発を減らすべきなのはどんな時か」という問いまで掘り下げてみたいと思います。

まず、PLCは何を測っているのか

プロダクトライフサイクルは、ロジャースの普及理論をベースに、「ある特定のソリューション形態が、市場にどれだけ浸透したか」を売上や採用率の集計で表したモデルです。

ここで重要なのは、PLCの分析単位が「製品カテゴリの普及曲線」だという点です。成熟期とは「今の形のソリューションが、獲得できる顧客をほぼ獲得し切った」という需要集計上の観察にすぎません。

実は、PLCを広めたセオドア・レビット自身が、このモデルは記述的(descriptive)なものであって処方的(prescriptive)なものではない、と警告しています。「過去を振り返るとこういう曲線を描いていた」と説明するための道具であって、「成熟期だから開発を止めるべき」という意思決定の根拠にするのは、元の理論からしても誤読なのです。

それでも「成熟期=投資縮小」という発想が根強いのは、PLCが買い切り型の物理製品を前提に作られたモデルだからだと考えています。一度売ったら取引が完結する製品であれば、市場が飽和した後にできることは確かに限られます。しかし、この前提はクラウドサービスには当てはまりません。

分かりやすい例がフィルムカメラです。1990年代に成熟期を迎え、PLC的には教科書通りの曲線を描きましたが、起きたのは緩やかな衰退ではなく、デジタルカメラへの急激な置き換えでした。「写真を撮って残したい」という需要そのものは消えておらず、消えたのは フィルムというソリューション形態 だけです。PLCが測っていたのは需要ではなく、特定の形態の普及度にすぎないことが見えてきます。

ジョブ理論には「成熟期」が存在しない

クレイトン・クリステンセンのジョブ理論は、「顧客はプロダクトを買うのではなく、自分の片付けたいジョブ(用事)を解決するためにプロダクトを"雇用"する」と捉えます。

この理論の重要な含意は、 ジョブは時間に対してほぼ不変 だということです。「経費精算を正確に、楽に終わらせたい」「請求業務を漏れなく済ませたい」。こうしたジョブは、成熟も衰退もしません。成熟・衰退するのは、そのジョブに雇用されている特定のソリューション形態だけです。

つまりPLCとJTBDは矛盾しているのではなく、 見ている単位が違う のです。

• PLCの単位:ソリューション形態の普及度

• JTBDの単位:ジョブ(需要の本体)

PLCは現行ソリューションの普及度を示すメーターであり、JTBDは需要の本体です。 メーターが振り切れたことは、需要が消えたことを意味しません。

そしてクラウドサービスの場合、サブスクリプションは「毎月の再雇用」契約です。買い切り製品なら売った時点で取引が完結しますが、クラウドサービスは顧客が毎月「このプロダクトを雇用し続けるか」を判断している。成熟市場であっても、ジョブをより良く解決する競合が現れた瞬間、雇用先は移ります。

この構造を踏まえた上で、10年以上続くクラウドサービス領域の実例を見ていきます。成熟期のクラウドサービスが辿る道は、大きく3つに分かれます。

実例1:成熟しても開発が止まらないドメイン（CRMと会計）

CRM は、Salesforceの創業(1999年)から数えて四半世紀を超える、クラウドサービスとして最も成熟したドメインの一つです。市場浸透は進み、成長率は鈍化した。PLC的には間違いなく成熟期です。

では開発は止まったか。むしろ逆で、Salesforceは生成AIの登場以降、AIエージェント領域(Agentforce)に大規模な開発投資を振り向けています。「顧客との関係を管理し、売上につなげたい」というジョブは不変のまま、その解決形態が「人が入力・参照するデータベース」から「AIが業務を代行する仕組み」へ移ろうとしている。成熟ドメインの王者ほど、形態転換の競争から降りられないのです。

クラウド会計サービス も同様です。米国では2000年代前半に始まったQuickBooks Onlineと、Xero(2006年創業)が20年近く戦い続け、日本でも2012年創業組のfreeeとマネーフォワードが10年以上競合しています。「正しく記帳し、決算を終えたい」というジョブは100年前から変わっていませんが、仕訳の自動化、銀行API連携、インボイス対応、そしてAIによる自動経理へと、解決形態の更新は止まっていません。 ジョブが恒常的で、かつ再雇用競争が続く限り、成熟期でも開発は減らない 。これが第一のパターンです。

私自身が、成熟したプロダクトと向き合って実感したこと

ここまで他社の事例を見てきましたが、私自身も成熟したプロダクトと向き合う中で、同じ構造を実感したことがあります。

あるBtoBクラウドサービスでAI機能の開発ロードマップを描いたとき、私たちはまず「顧客のどのジョブが、これからも変わらず残り続けるのか」を整理することから始めました。機能を起点に「次に何を作るか」を考えるのではなく、ジョブを起点に「変わらない用事は何か」を見極める。順番をそこから始めただけで、議論の質が変わっていきました。

「成熟したから守りに入る」のではなく、「変わらないジョブを、次はどの形態で解決するのか」という問いに、自然と切り替わっていったのです。

正直に言うと、当時の私はここまで言語化できていたわけではありません。フレームワークを後から当てはめて、ようやく「あのとき自分たちがやっていたのは、ジョブの雇用先を問い直す作業だったのだ」と腑に落ちた、というのが実際のところです。ですが、この実感があるからこそ、「成熟期だから」という言葉で思考を止めることの危うさを、肌身で感じています。

実例2:ジョブごと飲み込まれたドメイン（ファイル共有）

一方で、開発投資の構造を大きく変えざるを得なかった実例もあります。 Dropbox (2007年創業)です。

ファイル同期・共有というドメインは急成長の後に成熟しましたが、問題は競合するクラウドサービスではありませんでした。OSやオフィススイート(Google Workspace、Microsoft 365)が、ファイル共有機能を「おまけ」として同梱し始めたのです。「ファイルをどこからでも使いたい」というジョブ自体が、単独プロダクトではなくプラットフォームの一機能として解決されるようになった。

Dropboxは2023年と2024年の二度にわたり大規模な人員削減を実施しました。注目すべきはCEO自身がその理由を「コア事業(ファイル同期・共有)が成熟したため」と明言し、削減で生んだ余力をAI検索プロダクト(Dash)へ振り向けたことです。これは「成熟期だから縮小した」という受動的な話ではなく、 ジョブの雇用先が構造的にプラットフォーム側へ移ってしまった事業への投資を畳み、次のジョブに賭け直す という、能動的な配分判断です。

似た構造の、より厳しい結末がEvernoteです。「思いついたことを記録し、後から取り出したい」というジョブはNotionなど新形態に雇用先を奪われ、2023年の買収完了後には米国・チリのほぼ全従業員が解雇される大規模な縮小を経ました。配分転換の判断が「遅すぎた」ケースと言えます。

実例3:意図して縮小するドメイン（ポートフォリオと資本の論理）

3つ目のパターンは、プロダクト単体ではなく、 事業ポートフォリオや資本の論理から縮小が選択される ケースです。

Atlassian は、長年提供してきたServer版(買い切り型のオンプレミス製品)について、2020年に終了方針を発表し、2024年2月にサポートを完全に終了しました。Server版自体は安定した収益源でしたが、開発リソースをCloud版に集中させ、顧客の移行を能動的に促した。これは旧形態の「計画的な看取り」であり、自社の後継プロダクトへジョブの雇用先を付け替える、自己破壊型の縮小判断です。

資本側の論理が縮小を駆動するケースもあります。成熟プロダクトの安定キャッシュフローは、再投資ではなく「刈り取り資産」として評価されることがあり、PEファンドによる買収やアクティビスト投資家の介入を経て、開発投資を絞り収益性を高める手法は、米国のクラウドサービスでは一つの定型になっています。これはPdM単独の判断領域ではありませんが、 自社プロダクトがどの役割を期待されているか（成長エンジンなのか、キャッシュエンジンなのか）を理解しておくことは、開発方針を考える上で重要 だと感じています。

ここで起きているのは、「プロダクトのフェーズが開発量を決める」のではなく、 「このプロダクトに次の再雇用競争を戦わせるか、それともキャッシュを生む役割に切り替えるか」という能動的な経営判断 です。

縮小が合理的になる3つの条件

実例を整理すると、成熟期に機能開発を縮小する判断が合理的になるのは、次の条件に当てはまる時です。

1. ジョブの雇用先が構造的に移ってしまった時。 Dropboxのように、ジョブがプラットフォームや別形態に吸収され、単独プロダクトとしての勝ち筋が細い場合。撤退戦のコスト最小化と、次のジョブへの賭け直しは正しい判断です。

2. 自社の後継プロダクトにジョブを引き継がせる時。 AtlassianのServer版のように、旧形態を計画的に畳み、自社内でジョブの雇用先を付け替える場合。縮小は新形態への投資とセットで初めて成立します。

3. スイッチングコストが堀として機能し、再雇用の脅威が当面低い時。 基幹業務に深く組み込まれたクラウドサービスは、解約コストの高さゆえに刈り取りが一定期間成立します。ただしこの条件は、AIエージェントが「乗り換えコスト自体を下げる」存在になりつつある今、賞味期限が短くなっていると見るべきです。

逆に言えば、この3条件のどれにも当てはまらないのに「成熟期だから」という理由だけで縮小するのは、再雇用競争への不戦敗を意味します。

この問いは、組織で持つべきもの

ここまで「PdMの問い」として書いてきましたが、これはPdM個人が持てばよい問いではないと感じています。

「成熟期だから」という言葉は、どんな組織でも、いつのまにか共通言語になりやすい言葉です。説明として便利だからこそ、一度定着すると、その前提が問い直されなくなっていく。冒頭で書いた私の引っかかりも、突き詰めればこの「問い直されなくなること」への警戒だったように思います。

だからこそ、チームやステークホルダーと「私たちのプロダクトのジョブは、今どこに雇用されているか」を繰り返し問い直す場をつくることが、マネージャーの役割なのだと考えています。一人のPdMが正しい問いを持っていても、その問いがチームの共通言語にならなければ、判断にはつながらないからです。

結論:フェーズが決めるのではなく、判断が決める

「成熟期のプロダクトは機能開発が減るのか」という問いへの答えは、 そうとも限らない 、です。

ただし、こう付け加えたいと思います。 減ることはある。しかしそれはフェーズが自動的に決めるものではなく、ジョブの行き先を見極めた上での能動的な事業判断であるべきだ 、と。

CRMや会計のように、ジョブが恒常的で再雇用競争が続くドメインでは、成熟期でも開発は減らない。むしろAIによる形態転換の主戦場になっています。一方、ジョブの雇用先が構造的に移った時、後継に引き継ぐ時、堀が当面持つと判断した時。こうした場合には、縮小は合理的な選択になります。

危険なのは縮小そのものではなく、「成熟期だから」という受動的な縮小です。プロダクトマネージャーとして持つべき問いは、「このプロダクトは今どのフェーズか?」ではなく、こちらだと考えています。

「このジョブは今、何に雇用されていて、次は何に雇用されようとしているか。そして自社は、その再雇用競争を戦うのか、降りるのか。」

最後に、ひとつ問いを置いて終わりたいと思います。

あなたが今関わっているプロダクトを、思い浮かべてみてください。それはどんなジョブに「雇用」されていて、その雇用先は、これからどこへ移ろうとしているでしょうか。

もし「もう成熟期だから」という言葉で、その問いを考えるのを止めてしまっていたとしたら。それは、PLCというメーターに思考を預けてしまっているのかもしれません。

プロダクトのこれからは、フェーズでは決まりません。それを決めるのは、プロダクトに関わる私たち自身の判断だと、私は思っています。