既存プロダクトの改善、外部チームが最初に見る観点
前任の開発会社やCTOが去り、既存のプロダクトだけが手元に残っている——スタートアップではよくある状況です。「動いてはいるが、誰も中身を分かっていない」プロダクトを前に、どこから改善に着手すればいいか分からず時間だけが過ぎていく、という相談を私たちはよく受けます。
既存プロダクトの改善は、ゼロから作るより難しい場面が実は多くあります。理由は単純で、「今動いているものを壊さずに直す」という制約が常に付きまとうからです。この記事では、外部チームとして既存プロダクトを引き継ぐとき、私たちが最初の1〜2週間で必ず確認する観点を、発注者向けに整理します。
まず確認するのは「動かす」ための土台
機能追加の前に、そのプロダクトを手元で動かせるかを確認します。ここでつまずくケースは想像以上に多いです。
- READMEの手順通りに
bundle install/npm installが通るか - ローカル環境の再現に必要な情報（DB、環境変数、外部APIキー）がドキュメント化されているか
- 開発環境と本番環境の差分（Rubyバージョン、Node バージョン、ミドルウェアのバージョン）
ここで詰まるプロダクトは、往々にして「前任者の頭の中にしかない手順」に依存しています。動かせない状態は、改善以前に触ることすらできないという意味なので、最優先で潰します。
デプロイの再現性を見る
次に見るのは、本番へのデプロイが再現可能かどうかです。
- デプロイ手順がコード化されている（CapistranoやCI/CDパイプライン）か、それとも「担当者が手でSSHして再起動」の属人運用か
- ロールバックできるか。できないなら、改善作業自体がリスクの高い一発勝負になる
- 本番のRuby/Rails・Node/Reactのバージョンが、サポート切れ（EOL）に近づいていないか
デプロイが属人化しているプロダクトは、改善の着手前にここを直すだけで「安心して手を入れられる」状態に変わります。逆にここを飛ばして機能追加から始めると、リリースのたびに事故が起きます。
テストの有無とカバー範囲
テストがあるかどうかは、改善の進め方を大きく左右します。
- テストがあるなら、それが実際に通るか、CIで回っているかを確認する。古いテストが放置されていて実は失敗し続けている、というケースも珍しくない
- テストがないなら、いきなり全体にテストを書くのではなく、これから触る箇所だけに絞って最小限の回帰テストを足しながら進める
「テストがないから全部書き直す」は多くの場合オーバーキルです。まず触る範囲を安全にし、改善のたびにテストを積み増していくほうが、予算対効果が高くなります。
依存関係の古さとセキュリティリスク
Gemfile.lock や package-lock.json を見て、依存ライブラリがどれだけ古いかを確認します。
- 主要フレームワーク（Rails / React本体）のバージョンがEOLを迎えていないか
- 既知の脆弱性を含むバージョンで固定されていないか（Rubyなら
bundle audit、npmならnpm auditで機械的に確認できる） - アップグレードを阻んでいる要因（古いgemへの強い依存、非推奨APIの多用）が何か
古い依存を放置したまま機能追加を重ねると、後になるほどアップグレードコストが跳ね上がります。すぐに全面アップグレードする必要はありませんが、「どれだけ借金が積み上がっているか」を可視化するだけでも、改善の優先順位づけに役立ちます。
コードの構造と「変更の影響範囲」の見えやすさ
技術的負債の見極めで最も時間をかけるのがここです。
- 1つのコントローラやコンポーネントが肥大化し、変更の影響範囲が予測できない状態になっていないか
- ビジネスロジックがビュー（HamlやJSXの中）に直接書かれ、テストしにくい構造になっていないか
- 同じロジックが複数箇所にコピーされ、片方だけ直して不整合が起きるパターンがないか
ここは「きれいに書き直したい」という開発者側の欲求と、「今すぐ機能を追加したい」という発注者側のニーズがぶつかりやすい部分です。私たちは全面リファクタリングを最初の提案にはしません。改善したい機能に隣接する箇所だけを段階的に整理しながら進める方針を基本にしています。
ドキュメントと「知識の所在」
コードと同じくらい重要なのが、知識がどこにあるかです。
- 仕様や設計判断がドキュメント化されているか、それとも前任者の記憶にしかなかったか
- 「なぜこう作ったか」の経緯が分かるコミットメッセージやPRの説明が残っているか
- 管理画面やインフラの認証情報が引き継がれているか（これが引き継げていないだけで着手が数週間遅れる例もあります）
ドキュメントが薄いプロダクトほど、最初の数日は「読む」より「動かして観察する」時間が長くなります。これは無駄な工程ではなく、地図のないコードベースで安全に手を動かすための必要な投資です。
どこから着手するか
以上の確認を終えたら、私たちは次の順番で優先順位をつけます。
- 動かない・デプロイできない状態を最優先で解消する
- 今後触る予定の範囲に最小限のテストを足す
- セキュリティリスクの高い依存だけ先にアップグレードする
- 機能改善・新機能開発を、上記の安全網の上で進める
この順番を飛ばして機能追加から着手すると、後々「直したはずの箇所が別の場所を壊す」事故が起きやすくなります。地味に見えますが、土台を先に固めることが結果的に一番早い改善ルートです。
torcheees では Ruby on Rails を中心にこうした既存プロダクトの引き継ぎ・改善を数多く手がけており、モダナイゼーションや保守・運用のサービスとして提供しています。
症状別の詳しい進め方
この記事は既存プロダクト改善の全体像です。個別の症状ごとの具体的な進め方は、以下の記事で詳しく解説しています。
- 引き継ぎ・体制の空白: 前任者退職後の引き継ぎで最初にやること / CTO退職後も開発を止めない引き継ぎ方 / 開発会社を変更するときのチェックリスト
- 技術的負債・古いコード: テストがないシステムを安全に改修する進め方 / Railsバージョンアップを外注する前に見るべきこと / 技術的負債は改修とフルリプレイスどちらを選ぶべきか
- フロントエンドの改善: Reactリファクタリングを外注すべき症状と進め方 / Next.jsのリファクタリング外注で確認すべき論点
- 運用・信頼性の改善: 障害が多いWebサービスを改善する優先順位 / デプロイが属人化したシステムを改善する方法
まとめ
- 既存プロダクトの改善は、機能追加の前に「動かせるか」「デプロイが再現可能か」「テストがあるか」を確認するところから始まる
- 依存の古さやコードの構造は、全面書き直しではなく段階的な整理で優先順位をつけて着手するのが現実的
- ドキュメントが薄い場合は「読む」より先に「動かして観察する」時間を確保することが、安全な改善への近道
「引き継いだプロダクトをどこから改善すればいいか分からない」という段階でも、torcheees はご相談を受け付けています。まずは1〜4週間の「要件整理・開発診断」で、現状のコードとインフラを一通り確認し、改善の優先順位と概算費用をご提示します。お問い合わせフォームからお気軽にご連絡ください。