引き継いだSaaSの開発ロードマップを立て直す方法
前任のPdMやCTOが抜けたタイミングで、既存SaaSの事業責任者を引き継いだ——着任した初週にこの状況に直面する方は少なくありません。開発チームに「今何を作っているんですか」と聞いても要領を得ず、バックログを見ても優先順位の根拠が分からない。とりあえずロードマップを作ろうにも、何を材料にすればいいのか分からず手が止まる、という相談をよく受けます。
この状態でいきなり「今期の目標達成に必要な機能」からロードマップを引くと、高確率で失敗します。技術的な制約もチームの実力も分からないまま数字だけで計画を立てるからです。この記事では、既存SaaSを引き継いだ立場で、開発ロードマップを立て直すまでに踏むべき手順を順番に解説します。
いきなりロードマップを引かない理由
新任PdMが最初にやりがちな失敗は、事業目標から逆算して機能リストを作り、それをそのままロードマップとして開発チームに渡すことです。これがうまくいかないのは、事業目標側の情報しか反映されておらず、技術側の制約(既存コードの複雑さ、負債の量、チームの実際の生産性)が一切考慮されていないためです。
結果として「3ヶ月で終わるはずが8ヶ月かかる」「着手したら想定外の依存関係が出てきて他機能が止まる」という事態が起き、ロードマップ自体の信頼性が最初の四半期で崩れます。一度崩れた信頼は、次に出すロードマップも「また希望的観測では」と疑われる形で尾を引きます。
だからこそ、機能を並べる前に現状把握を先にやることが、遠回りに見えて最短ルートです。
現状把握で見るべき4つの軸
着任後2〜3週間で、次の4つを埋めます。すべて埋まらないと、次のロードマップ再構築のステップで判断材料が欠けます。
1. 開発の現在地(何が終わっていて何が進行中か)
- 直近3〜6ヶ月のリリース履歴を実際にコードとchangelogで追う(口頭説明だけを鵜呑みにしない)
- 「進行中」と言われているタスクが、実際にはどれくらいの期間止まっているか(着手日をgit historyやチケットの更新日時で確認)
- チームが今のベロシティで1スプリントに実際にこなせる量(見積もりではなく実績)
口頭の進捗報告と、コード・チケットの実態がずれているケースは珍しくありません。ここは「聞く」より「見る」を優先します。
2. 技術的負債の可視化
- 主要フレームワーク・言語のバージョンがEOLにどれだけ近いか
- テストカバレッジの有無と、CI で実際に通っているか
- 「触ると何が起きるか誰も分からない」領域がどこにあるか(開発チームに直接聞くと大抵は自覚がある)
これを可視化するだけで、「なぜあの機能追加に3ヶ月かかったのか」の答えが見えてきます。負債を数値やリストで示すと、経営層への説明材料にもなります。
3. ユーザー課題の再整理
- サポート問い合わせ・解約理由・NPSコメントを、前任者の解釈を挟まず一次情報から読み直す
- 使われていない機能(アクセスログ・イベントログで実測)を洗い出す。作ったが使われていない機能に工数を継ぎ足していないか
- 課金プランごとの利用実態と、実際に解約影響が大きい課題の重なりを見る
前任者が残したロードマップの前提(「この機能があれば解約が減る」)が、実データで裏付けられているかをここで検証します。裏付けのない前提のまま計画を引き継ぐのが、ロードマップが崩れる最大の原因です。
4. 開発チームの実力とキャパシティ
- 現在の人数・スキルセット・稼働率(他業務との兼任があれば実質稼働は額面より少ない)
- 外部委託・フリーランスへの依存度と、その継続性
- チームが「本当は直したいが言い出せていない」箇所(1on1で個別に聞くと出てくることが多い)
ここを飛ばして機能数だけでロードマップを組むと、着任者自身が「無茶な計画を押し付けた人」になってしまいます。
実現可能なロードマップの引き方
4軸が埋まったら、ロードマップを次の順序で組み立てます。
- 技術的負債のうち、事業影響が大きいものを土台に組み込む。全負債の解消を目標にするのではなく、「これから機能追加する領域」に隣接する負債だけを先に片付ける対象にする
- ユーザー課題を、解約・売上への影響度で並べ替える。声の大きさではなく実データの裏付けで優先順位をつける
- 1機能あたりの見積もりに、実績ベロシティを使う。前任者やベンダーの見積もりをそのまま信じない。同規模の過去タスクの実績時間を参照する
- 四半期ごとに「土台」「ユーザー課題対応」「新機能」の比率を決める。すべてを新機能に振ると負債が積み上がり続け、次の四半期のベロシティが落ちる悪循環に入る
目安として、技術負債への対応が完全にゼロの四半期が2期続くと、3期目以降の見積もり精度が大きく落ちる傾向があります。新機能一辺倒のロードマップは短期的には威勢がいいですが、持続しません。
開発チームとの合意形成
ロードマップは事業側だけで作って渡すものではなく、開発チームと共同で検証する必要があります。
- ドラフトを見せて「このタスクの見積もりは妥当か」を個別に確認する。事業側の希望的観測が混じっていないか、現場の感覚とすり合わせる
- 「なぜこの順番か」を数字(解約影響・技術負債の危険度)で説明できる状態にしておく。感覚的な優先順位づけは、開発チームからの信頼を得にくい
- 最初のロードマップは、あえて保守的な見積もりで出し、達成実績を積んでから次の四半期で精度を上げる。着任直後のロードマップが未達になると、以後の計画すべての信頼性に響く
前任者体制で「計画と実績が乖離し続けていた」場合、この合意形成のプロセス自体が、チームとの信頼関係を再構築する機会にもなります。
外部の技術パートナーで現状診断する価値
ここまでの4軸の現状把握は、社内だけでもできますが、次の理由で外部の技術パートナーに依頼する価値があります。
- 前任者の説明を鵜呑みにせず、コードとインフラを直接読める。社内の人間関係のしがらみなく「実際はどうなっているか」を評価できる
- 技術的負債の深刻度を、他社事例と比較した相場観で判断できる。「これは危険水域」「これは後回しでよい」の線引きに経験が要る
- チームへのヒアリングを、事業責任者を介さずに第三者として行える。開発チームが事業側に言いにくかった懸念が出てきやすい
torcheees では、こうした引き継ぎ直後のSaaSを対象に、コードとインフラの現状診断から着手します。買収・M&A後のプロダクトの技術デューデリジェンスに近い進め方は、買収したプロダクトの技術監査をどう進めるかでも解説しています。また、既存プロダクト改善に外部チームが入る際に最初に見る観点は既存プロダクトの改善、外部チームが最初に見る観点にまとめています。
まとめ
- 引き継いだSaaSでいきなりロードマップを引くと、技術的制約を無視した計画になり四半期内に崩れる。まず「開発の現在地」「技術的負債」「ユーザー課題」「チームの実力」の4軸を実データで把握する
- ロードマップは技術負債・ユーザー課題対応・新機能の比率を四半期ごとに決め、実績ベロシティで見積もる。全て新機能に振ると負債が積み上がり次期の精度が落ちる
- 開発チームとの合意形成は数字で説明できる優先順位づけが前提。着任直後は保守的な見積もりで信頼を積むほうが長期的に速い
「何から手をつければいいか分からない」という段階でも、torcheees はご相談を受け付けています。CTO/PdM右腕としての開発支援や、まずは1〜4週間の「既存プロダクト改善 診断」で、現状のコードとインフラを一通り確認し、ロードマップ再構築の材料と概算費用をご提示します。継続的な改善支援も承っています。お問い合わせフォームからお気軽にご連絡ください。