SVNのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

SVNのシステム開発は、要件整理と環境選定から始めます。そのうえで、設計・移行、検証、稼働、定着の順に進めると、変更管理を安全に運用できます。SVNは本体だけでなく、認証やバックアップ、CIなどの周辺機能を含めて組み立てる必要があります。

▼全体ガイドの記事
・SVNのシステム開発の完全ガイド

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

SVNのシステム開発の全体像

SVNはApache Subversionを使う集中型のバージョン管理システムです。

サーバー上のリポジトリからcheckoutして作業し、updateとcommitで変更履歴を一元管理します。ソースコードに限らず、設定ファイル、設計書、Webサイト素材なども管理の対象にできます。

SVNのシステムは本体のほかに、認証や権限、バックアップといった周辺の仕組みを含みます。加えて、監視やCI、課題管理、利用ルールも、一体で考える必要があります。

SVNの基本構成とGitとの違い

基本構成は、PC上のSVNクライアントと、リポジトリを置くサーバーです。サーバーにはApache HTTP Serverとmod_dav_svn、またはsvnserveを使います。さらに、認証基盤、バックアップ先、監視・ログ基盤も構成に含めます。

Gitと異なり、開発者ごとに完全なリポジトリを持たず、正本をサーバーで一元管理しやすい方式です。そのため、サーバーが止まったときの影響やネットワーク品質は、事前に評価しておく必要があります。

SVNと周辺ツールは、連携の範囲と今後の方向性によって組み合わせが変わります。開発連携、SVN継続、Git移行・併用の3つの構成要素ごとに、選定条件を見て選びます。開発者のPC側では、TortoiseSVNやVisualSVNといったクライアントも連携の対象になります。

• 開発連携：Jenkins、RedmineやJira、IDEを組み合わせ、コミットからビルドや課題追跡までつなぐ構成です。
• SVN継続：社内拠点での統制、バイナリのロック、既存SVN資産の活用を重視する場合の候補です。
• Git移行・併用：多拠点のオフライン作業、頻繁なブランチ、プルリクエスト中心のレビュー、クラウドCIを重視するなら、検討の対象になります。

新規構築・ホスティング・既存環境移行の使い分け

導入形態は、標準的な運用の負担と、独自の要件の多さに応じて比べます。

• ホスティング：マネージド型のサービスを契約し、標準的なソース管理を始める方法です。
• 自社基盤：AWS、Azure、社内の仮想基盤に構築し、運用も自社で受け持ちます。
• パッケージ：Windows中心の環境に、製品を導入する方法です。
• 個別構成：SVNとJenkins、Redmine、認証基盤などを組み合わせて構成します。

標準的な管理であれば、ホスティングやパッケージのほうが、設計、パッチ適用、バックアップにかかる負担を抑えられます。一方で、独自の監査やデータ配置の要件が強いとき、また冗長化や既存システムとの連携が必要なときは、個別構築を詳しく検討します。

既存環境の移行前に、リビジョン数、容量、最終更新日時を洗い出します。さらに、タグとブランチ、権限、フック、連携ジョブも洗い出しておきます。移行方法は、dumpとload、svnrdumpなどから選び、検証環境でリハーサルしておきます。

移行後は、旧環境を一定期間、読み取り専用で残します。

切り替え後に問題が起きても戻せるよう、ロールバックの条件と責任者も先に決めておきます。

SVNのシステム開発の進め方と6フェーズ

要件整理から始めて、選定、設計開発、テスト、稼働、定着の順に進みます。

各段階では記録と判断基準を残し、業務側と管理側が合意してから次の段階へ進みます。

認証連携や既存CI、データ移行は、後から追加すると当初見積もりの工数が1.3〜1.5倍に膨らむ場合があります。そのため、初期の段階で洗い出すことが大切です。

フェーズ1：要件整理で決める利用範囲と制約

要件整理では、利用範囲、データ量、制約、連携の順に確かめていきます。

• 業務要件：導入範囲と、誰が何をいつcommitするかを決めます。
• データ要件：履歴とタグの保持範囲、保存年限、ファイルサイズ、ロック運用。
• セキュリティ：LDAP・Active Directory、TLS、最小権限、MFA、アクセスログの確認。
• 運用要件：バックアップ世代数と復旧訓練を確認します。
• 連携要件：Jenkins、Redmine、Jira、メール通知、コミットフックとの接続を確かめます。

利用者数、同時アクセス数、リポジトリ数は、一覧にしておきます。さらに、総容量、年間増加量、バイナリ比率、利用拠点、委託先も、同じ一覧に加えます。

停止を許容できる時間と、目標とする復旧時間も決めます。

設計書、IaC、画像、CAD、ゲーム素材を置く場合は、そのサイズとロック運用も要件に含めます。

フェーズ2：SVN継続かGit移行かの判断

方式と提供形態は、要件をもとに比べます。方式を決める材料は、既存履歴の価値、バイナリのロック、ネットワーク環境です。

• 方式選定：SVN継続、Git移行、チームごとの併用から選びます。
• 提供形態：ホスティング、パッケージ、自社構築を、運用責任とあわせて比べます。

レビュー方法やCI/CD、開発者の習熟度、委託先との接続も比べます。さらに、将来のクラウド利用も判断材料になります。

SVNからGitへ移すこと自体が目的になると、履歴変換、権限の再設計、運用教育、CI再構築といった作業が発生します。そのため、まず解決したい経営・開発課題を言葉にしておきます。

ホスティングは、サーバーやバックアップの負担を比較的軽くできます。一方で、自社構築はネットワークやデータの配置を自社で制御できます。また、パッケージは、Windowsの管理画面や認証連携を重視する場合の候補です。

比較表には、容量・ユーザー数・リポジトリ数の上限、IP制限の条件を入れておきます。さらに、バックアップ取得、SLA、障害対応、移行支援、料金改定の条件も入れます。機能に加えて、運用責任の分担も比べます。

フェーズ3：設計開発で固める構成・権限・移行方法

設計では、リポジトリの構成、サーバーの設定、データ移行の方法を決めます。

• リポジトリ運用：分割方針、trunk・branches・tags、authz、命名、commit文、レビュー、ロックの決め方。
• 構成の粒度：細分化すると権限管理とバックアップ対象が増え、集約しすぎるとアクセス制御と容量管理が難しくなります。
• 基盤設定：OS、Apacheまたはsvnserve、ストレージ、TLS、認証、監視、バックアップ、障害時の切り替えを決めます。

リポジトリを分ける基準を、プロジェクト、製品、機密区分、ライフサイクルのどれにするかは、業務責任者と合意して決めます。

2026年8月時点でApache公式が安定版として案内しているSubversion 1.14.5には、CVE-2024-46901への修正が含まれます。

2026年7月20日公開の1.15.0-rc3は本番向けではないため、検証環境で評価し、本番では安定版を運用します（出典：Apache Subversion News Archives）。

移行については、方式、対象リポジトリと除外対象、履歴の保持範囲、停止時間、ロールバック方法を設計書に記しておきます。移行ツールは、小規模、大容量、バイナリ中心、複雑な権限を持つ代表的なリポジトリで順に試します。

NRI OpenStandiaは、公開している工程を、要件定義、構築・テスト、移行ツールの準備・テスト、保守サポートに分けています。発注時にも、誰が何を納めるかを分けて示すと、比べやすくなります（出典：NRI OpenStandia 開発環境構築）。

フェーズ4：テストで検証する機能・性能・復旧

ログインやcheckout・update・commitの確認に加え、受入の可否は、機能、連携、性能、障害・復旧、移行受入の面から判断します。

• 機能：作成、読み書き権限、ブランチ・タグ、ロック、差分・ログ、フック、通知が想定どおりか。
• 連携：認証、CI、課題管理、監視、バックアップが想定の権限で動くかを試します。
• 性能：通常時とピーク時のcheckout、commit、ログ、バイナリ取得の応答時間を測ります。
• 障害・復旧：停止、容量不足、認証停止、通信断、証明書切れから復旧できるかを試します。
• 移行受入：移行前後のデータが一致しているか。

バックアップは実際に復元し、リビジョン数、タグ、ブランチ、権限、最終更新日時が一致するかを確かめます。

移行前後の照合では、リポジトリ件数、ファイル件数、代表的な差分を比べます。また、新環境からcheckoutし、普段のビルドやリリースを完了できることも受入条件です。

基準に届かなかったときに旧環境へ戻す条件、データ凍結の時刻、意思決定者は、事前に決めておきます。

フェーズ5：稼働で管理する切り替えと初期運用

本番切り替えは、準備、切り替え、利用確認、初期監視の順に進めます。

1. 手順書、連絡網、作業時間、データ凍結、旧環境の扱い、ロールバック条件の事前確認。
2. 移行を伴う場合は、最終dumpや差分反映、整合性の確認、DNSや接続先の変更、利用者の接続確認、CIジョブの再開を、この順に並べます。
3. 管理者だけでなく、開発者や外部委託先、承認者も普段どおりに操作し、現場が止まらないことを確かめます。

稼働直後は、コミット数、エラー、認証失敗を重点的に監視します。加えて、容量、バックアップの成否、CI失敗、問い合わせ数も監視します。

重大障害が起きたときの一次切り分け担当、ベンダーへの連絡条件、暫定策、復旧目標は、運用表に記しておきます。なお、自社で運用する場合は、OS・Apache・Subversionのパッチと証明書を、月次か四半期で確認します。さらに、アカウント、監視、バックアップも、同じ周期で点検します。

フェーズ6：定着で続けるルールと改善

運用が定着したあとも、手順の共有、利用者管理、定期点検、安全対策、委託条件を続けていきます。

• 手順共有：利用ガイド、命名、ブランチ・タグの条件、レビュー、ロック解除、誤commitの訂正を記録に残します。
• 利用者管理：参加時の権限申請と教育をそろえ、退職や契約終了時の停止、権限の見直し、共有アカウントの廃止を定期的に行います。
• 定期点検：月次で容量、利用者、権限、バックアップ、復旧、脆弱性、障害を確かめ、四半期で構成とGit移行を見直します。
• 安全対策：機密・個人情報を入れない分類、TLS、アクセスログ、最小権限の維持。
• 委託条件：ソースコード、IaC、設計書、移行スクリプトの引き渡し、著作権、著作者人格権、契約終了後の利用範囲を契約書に明記します。

SVNのシステム開発にかかる費用相場と内訳

SVN本体はオープンソースですが、予算には、要件整理やサーバー・ストレージのほか、認証、権限、移行、テストも含まれます。さらに、バックアップ、教育、保守も必要です。

金額は、公開ホスティング料金と一般的な開発規模をもとにした目安です。SVN専用の公的統計ではないため、サーバー台数、容量、連携、移行履歴、可用性によって変わる点を踏まえて、幅で比べます。

利用形態別の初期費用と期間の目安

費用と期間は、利用形態によって変わります。各レンジは、要件の組み合わせによる推定値です。

• 小規模ホスティング：初期0〜30万円程度、即日〜2週間程度です。
• クラウド移行・標準構築：初期30〜150万円程度、2週間〜2か月程度です。
• CI等を含む社内基盤：初期150〜500万円程度、1〜4か月程度です。
• 高可用性等を含む構成：初期500〜1,500万円以上、3〜9か月以上となる場合があります。

小規模な構成では、アカウント、リポジトリ、権限、利用手順を設定し、簡易的なデータ移行を行います。一方で、標準構築には、現状調査、dumpまたはsvnrdump、認証、TLS、バックアップ、受入テストが含まれます。

高機能構成では、複数拠点、高可用性、大容量を含む場合があります。さらに、監査・規制対応、移行リハーサル、障害訓練が加わることもあります。ここで示す金額は要件の組み合わせによる推定の幅で、特定の会社や案件の確定価格ではありません。

ホスティング料金と自社運用費の分け方

ファーエンドテクノロジーのMy Subversionでは、民間向けの料金が公開されています。

• スタンダード：月額4,000円、6GB（税込4,400円）です。
• ラージ：月額6,400円、12GB（税込7,040円）です。
• エクストララージ：月額10,000円、30GB（税込11,000円）です。

ユーザー数やリポジトリ数、パス権限はオプションです。さらに、コミット通知、移行、バックアップデータの取得、IP制限も、オプションに含まれます。そのため、月額だけで総額は判断できません（出典：My Subversion サービス内容・料金）。

自社で運用する場合は、クラウドやサーバーの利用料がかかります。また、OS・Apache・Subversionの更新や証明書の対応も工数になります。監視、バックアップ先、障害対応、アカウント管理の工数も発生します。

業務システムの保守運用費は、初期費用の年15〜25％程度という一般的な目安から、月5万〜30万円程度を想定するケースがあります。これはSVN専用の統計ではなく、対応時間やSLAを含む推定です。

小規模ホスティングは月数千円から1万円台のものもありますが、調査票や復旧訓練は別費用になることがあります。

見落としやすい追加コストの確認

追加費用と予算の調整対象は、分けて確認します。

• 移行・権限：履歴移行、リポジトリ整理、複雑なauthz、AD・LDAP・MFA連携。
• 連携・運用：CI改修、課題管理、監視、別リージョン保管、性能試験、復旧訓練、教育。
• 見積項目：調査、設計、構築、移行、テスト、切り替え、教育、保守を分けて書きます。
• 調整項目：初期連携数、画面、教育回数、移行範囲。

移行時には、古いフックや文字コード、巨大なバイナリ、不要な履歴、クライアントの互換性が課題になります。

予算を抑える場合でも、バックアップと復旧テスト、権限設計、パッチ適用は削らないでおく必要があります。

将来追加する条件と費用は、契約や見積条件に残しておきます。さらに、どのリスクを誰が負う見積もりかを確かめ、追加請求や運用停止につながらないようにします。

SVNのシステム開発で見積もりを取る際のポイント

見積もりには、構築に加えて、変更管理を安全に行う設計と検証も含めます。工数を比べるなら、利用者数や容量と合わせて、どこまでの設計と検証が含まれるかも見ます。

RFPには、現状、目的、対象データを記します。加えて、連携、セキュリティ、移行、運用、納品物も記載します。同じ前提を複数社に示せば、提案を同じ条件で比べられます。また、未確定の事項は、仮定として明記してもらいます。

RFPに具体的に書く利用実態と受入条件

RFPには、利用実態、運用条件、納品物、受入条件をそろえて記載します。

• 利用実態：部署・人数・拠点、リポジトリ数、容量・増加量、バイナリ比率、現行版、OS、認証、クライアント、委託先。
• 接続・運用：アクセス元、保存年限、停止時間、trunk・branches・tags、権限、ロック、フック、通知、CI・課題管理。
• 監査・納品：監査ログ、バックアップ世代、復旧目標、構成図、パラメータ、リポジトリ一覧、authz、移行計画・結果。
• 運用の納品物：テスト仕様・結果、復旧手順、運用設計、利用者ガイド、教育記録、ソース、IaC、スクリプト。
• 受入条件：権限の境界、履歴の整合性、CI、復元、障害時の復旧時間を、数値で示します。

受入の完了は、ログインやcommitの成功を確かめるだけでなく、上の条件をすべて満たしたかで判断します。

ベンダーのSVNの公開実績と移行力

ベンダーの実績、移行時の検証方法、契約上の裏付けを確かめます。

NRI OpenStandiaは、新規環境の設計・構築、CVSからSubversionへの移行、アクセス制御、ログ、バックアップ、保守の内容を公開しています。

• 担当実績：構築、移行、認証、権限、バックアップ、連携、障害対応のどこまでを担ったかを確かめます。
• 移行検証：リビジョン数と権限の照合、大容量バイナリの性能、旧環境の保持期間を質問します。
• 運用証跡：脆弱性の確認、パッチ期限、退職者の停止の記録。

回答が経験談にとどまらず、手順書、テスト項目、SLA、どこまでを誰が受け持つか、契約上の納品物で示されている会社を優先します。

公開情報と提案書の担当範囲を突き合わせ、実績がどれだけ具体的かを評価します。

金額とは別に比べるリスクと契約条件

見積金額、契約条件、委託時の安全管理、脆弱性対応を、それぞれ分けて比べます。

• 費用内訳：初期構築、移行、ライセンス・利用料、クラウド、保守、教育、追加作業単価の区分。
• 契約条件：固定価格の範囲、前提、対象外、変更、検収、瑕疵・障害対応、データ返却、終了時の移行支援を確認します。
• 委託先管理：接続元、個人アカウント、秘密情報、ログ、終了時の権限停止を契約と運用に反映します。

Apache Subversionの公式な脆弱性情報には、Windows上の引数インジェクションなどについて、影響を受ける版と対策版が掲載されています。

公式情報の確認は、見積もりに含めておきます。また、旧版の補完策、パッチ停止時間、緊急連絡経路も決めておきます（出典：Apache Subversion Security）。

SVNのシステム開発でよくある質問（FAQ）

導入や移行では、費用だけでなく、運用変更の範囲や、履歴と権限をどこまで残すかが判断の分かれ目になります。よくある質問には、実務の基準に沿って答えます。

SVNは2026年も新規導入して問題ありませんか？

要件に合えば、2026年でも新規導入できます。バイナリのロックや社内での一元管理、既存資産との互換性を重視する場合は、候補になります。

プルリクエストや多拠点のオフライン作業、Git向けCI/CDを優先するなら、Git移行か併用を比べます。

導入の前に、Apache公式の安定版とセキュリティ情報を確かめ、サポート期間と更新方針を決めておきます。

SVNのシステム開発費用は無料ですか？

SVN本体はオープンソースですが、システムとして使う費用が無料とは限りません。サーバーやストレージ、認証、バックアップ、監視も費用に含まれます。

移行やテスト、教育、保守にも費用がかかります。なお、小規模ホスティングは月数千円から1万円台の例もあります。

個別構築や移行を含めると初期30〜150万円程度、CIや冗長化を含めると150〜500万円程度になるなど、要件によって変わります。

既存SVNを移行するときに履歴や権限は残せますか？

方式と対象範囲を適切に設計すれば、履歴、タグ、ブランチ、権限をできるだけ引き継げます。

認証、パス構成、フック、文字コード、ツールの互換性によっては、変換や再設計が必要になります。移行後は、件数、リビジョン、容量、更新日時、差分を照合します。

受入テストとロールバック手順を準備してから、本番を切り替えます。

外部委託先にSVNを使わせるときの注意点は何ですか？

共有アカウントは避け、個人アカウントを使わせたうえで、必要最小限のパス権限、接続元の制限、TLS、アクセスログを設定します。

契約終了日に合わせたアカウントの停止と、貸与データの返却・削除を、契約で明確にしておきます。ソースコードやIaCの引き渡し、著作権と著作者人格権の扱い、障害時の連絡も、契約に書いておきます。

個人情報や機密情報を保存する場合は、委託先の安全管理と、漏えいが起きたときの対応も確かめます。

まとめ：SVNのシステム開発は運用定着までの設計

まずは、新規構築、既存移行、SVN継続、Git移行、併用のどれを目指すかを決めます。そのうえで、要件整理から定着まで6フェーズで進めます。

利用者数や容量だけでなく、認証、権限、バイナリも要件に含めます。さらに、CI、バックアップ、復旧、委託先も、要件に加えます。

進め方の要点は判断基準と検証結果の記録

各段階で、誰が何を確認し、どの状態なら次へ進むかを記録します。移行では、履歴や権限、復元、通常の開発作業を確かめ、問題が起きたときに旧環境へ戻れるようにしておきます。

導入後も、アカウント、脆弱性、容量、バックアップ、復旧訓練を定期的に点検します。

見積もりの要点は運用責任と将来費用まで比べること

見積もりでは、費用の範囲、責任の所在、作業の確かめ方をそろえます。

• 費用範囲：OSSのライセンス費だけでなく、構築、移行、テスト、教育、保守を含めます。
• 契約・受入：作業範囲、前提、受入基準、納品物、障害対応、終了時の返却を明記し、金額の根拠を確かめます。
• 事前確認：迷う場合は環境を洗い出し、小規模な移行リハーサルで必要な構成と工数をつかみます。

▼全体ガイドの記事
・SVNのシステム開発の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。