社内コード、どう共有する？4つの方法をゆるっと比較してみた

こんにちは！

開発をしていると、「あれ、この機能、前にも別のプロジェクトで使ったな…」って思うこと、ありませんか？ログ出力とか、APIの呼び出し方とか、認証処理とか。

毎回ゼロから書くのは面倒だし、できれば使い回したいですよね。

そんなときに便利なのが「共通機能の共有」。でも、いざ共有しようとすると、「どうやって？」ってなるんです。
コピーして貼るだけじゃ後で地獄を見るし、かといって複雑な仕組みを入れると運用が大変…。

この記事では、社内で共通機能を共有する方法として、よく使われる4つのパターンを紹介します。
それぞれのメリット・デメリットを、実際に使ってみた感想も交えながら、ゆるっと解説していきます。

特に今回は、依存関係の管理や運用のしやすさに注目して比較してみました。

学生さんや、実務経験が浅めのエンジニアの方にもわかりやすくなるように書いているので、「チーム開発ってどんな感じ？」って思っている人にも参考になるはずです。

それでは、さっそく見ていきましょう！

4つの方法の紹介

方法①：各プロジェクトにコピーを配置する

• 🔧 どんな方法？
  

  • 一番シンプルなやり方です。共通で使いたいソースコードを、各プロジェクトの中に直接コピーして配置します。

  • たとえば、CommonUtils.cs とか logger.js みたいなファイルを、プロジェクトごとに utils フォルダに入れて使う感じですね。

• ✅ メリット

  • とにかく簡単！
    コピーするだけなので、特別なツールや設定は不要。初心者でもすぐに使えます。

  • 外部依存がない
    他のリポジトリやパッケージに依存しないので、ネットワーク環境に左右されずに動きます。

  • 小規模プロジェクトに向いてる
    プロトタイプや検証用のコードなど、短期間で終わる開発にはこれで十分なことも。

• ❌ デメリット

  • 修正が大変
    もし共通コードにバグや仕様変更があった場合、すべてのプロジェクトに手動で反映しないといけません。これ、地味にしんどいです。

  • バージョン管理ができない
    どのプロジェクトがどのバージョンの共通コードを使っているのか、把握しづらくなります。

  • 技術的負債になりやすい
    コピペで増えたコードが放置されると、あとで「どれが最新？」ってなって混乱のもとに…。

• 🔍 依存関係の観点から見ると…

  • この方法は、依存関係が“ないように見えて、実はある”というのがポイントです。

  • コードは独立して見えるけど、実際には同じロジックを複数の場所で使っているので、仕様変更の影響範囲が見えづらいんですよね。

方法②：SVN/Gitの共有リポジトリを使って外部参照する

• 🔧 どんな方法？

  • この方法は、共通機能を専用のリポジトリにまとめておいて、各プロジェクトからそれを外部参照（外部リンク）するスタイルです。

  • Gitなら submodule や subtree、SVNなら externals を使って、プロジェクトの中に共通コードを取り込む感じですね。

• ✅ メリット

  • 共通コードを一元管理できる
    修正があれば、すべてのプロジェクトに反映できるので、メンテナンスが楽になります。

  • コードの重複がない
    コピー＆ペーストが不要なので、同じコードがあちこちに散らばることがありません。

  • 履歴が追いやすい
    共通リポジトリのコミット履歴を見れば、いつ・誰が・何を変更したかがすぐにわかります。

• ❌ デメリット

  • 構成がちょっと複雑になる
    submodule や externals の設定に慣れていないと、最初は戸惑うかも。CI/CDの設定も少し工夫が必要です。

  • 更新タイミングのコントロールが難しい
    共通リポジトリが更新されると、プロジェクト側にも影響が出るので、意図しない変更が混入するリスクがあります。

  • チーム全体での運用ルールが必要
    「いつ更新するか」「どのバージョンを使うか」など、ある程度のルールを決めておかないと混乱しがちです。

• 🔍 依存関係の観点から見ると…

  • この方法は、依存関係が明示的に見えるのが大きなポイントです。
    たとえば Git の submodule を使えば、どのコミット（＝どのバージョン）を使っているかがプロジェクト側に記録されます。

  • ただし、常に最新を参照していると、共通コードの変更がそのままプロジェクトに影響してしまうので注意が必要です。
    安定性を重視するなら、特定のバージョンに固定して使うのがオススメです。

方法③：GitHub PackagesでPrivateパッケージを公開（←弊社で主に運用）

• 🔧 どんな方法？

  • この方法は、共通機能をnpmやNuGetなどのパッケージとして社内限定で公開し、各プロジェクトでインストールして使うスタイルです。

  • GitHub Packagesを使えば、社内メンバーだけがアクセスできるPrivateパッケージを作れるので、会社の資産を外に出すことなく、安全に共有できます。

  • 使い方としては、npm install @company/common-utils みたいな感じで、普通のライブラリと同じようにインストールして使えます。

• ✅ メリット

  • バージョン管理がしっかりできる
    package.json や .csproj でバージョンを指定できるので、どのプロジェクトがどのバージョンを使っているかが一目でわかります。

  • セキュリティが保たれる
    Private設定にしておけば、社外には見えないので、会社のノウハウや資産を守れます。

  • CI/CDとの相性がいい
    パッケージのビルド・公開・インストールまで自動化できるので、運用がスムーズになります。

  • 再利用性が高い
    ライブラリとして設計することで、他のプロジェクトでも簡単に使い回せます。

• ❌ デメリット

  • パッケージ化の手間がある
    最初にライブラリとして整える必要があるので、ちょっとだけ設計力が求められます。

  • アクセス権限の管理が必要
    GitHubの設定で、誰がインストールできるかをちゃんと管理しないと、思わぬトラブルになることも。

  • 更新は手動で反映
    新しいバージョンを使いたいときは、プロジェクト側で明示的にアップデートする必要があります。

• 🔍 依存関係の観点から見ると…

  • この方法は、依存関係がとても明確です。
    バージョン番号で管理できるし、セマンティックバージョニング（例：1.2.3）を使えば、互換性のある更新だけを取り込むこともできます。
    

  • さらに、共通パッケージが他のライブラリに依存していても、使用者はそれらをまとめて簡単にインストールできるのがパッケージ化の強みです。
    複雑な機能を自分で組み立てる必要がなく、必要なものがすぐに使えるのは、開発効率の面でも大きなメリットです。

方法④：GitHub PackagesでPublicパッケージを公開する

• 🔧 どんな方法？

  • これは方法③と似ていますが、違うのはパッケージを“パブリック（公開）”にするという点です。
    つまり、GitHub上で誰でもアクセスできる状態でnpmやNuGetのパッケージを公開し、他のプロジェクトからインストールして使えるようにします。

  • OSS（オープンソースソフトウェア）と同じような扱いになるので、社外の人も使えるし、フィードバックをもらえる可能性もあります。

• ✅ メリット

  • OSSとして展開できる
    社内だけでなく、社外の開発者にも使ってもらえるチャンスがあります。技術発信にもつながります。

  • npmやNuGetで公開されている他のライブラリと同じように扱える
    公開パッケージとして扱えるので、他のOSSと同じように依存管理やバージョン管理ができます。

  • CI/CDとの連携がしやすい
    公開パッケージは自動化しやすく、更新もスムーズに行えます。

• ❌ デメリット

  • 会社の資産を公開するリスクがある
    コードの中に業務ロジックやノウハウが含まれていると、それが外部に漏れてしまう可能性があります。

  • ライセンスやセキュリティの管理が必要
    公開する以上、ライセンスの明記や脆弱性への対応など、責任が発生します。

  • 意図しない利用が起こることも
    公開したパッケージが、思わぬ形で使われたり、依存されたりすることもあります。

• 🔍 依存関係の観点から見ると…

  • この方法も、依存関係が明確で管理しやすいのが特徴です。
    バージョン指定で安定した運用ができるし、npmやNuGetの仕組みをそのまま使えるので、開発者にとっては扱いやすいです。

  • ただし、誰でも使える＝誰でも依存できるということなので、一度公開したら簡単には壊せないというプレッシャーもあります。
    「互換性を壊さないように慎重に更新する」みたいな、OSS的なマインドが求められます。

共通機能の共有方法 比較表

項目	方法①：コピー配置	方法②：外部参照（Git/SVN）	方法③：Privateパッケージ	方法④：Publicパッケージ
導入のしやすさ	◎ 超簡単	△ 設定が少し複雑	○ 少し準備が必要	○ OSS経験があればスムーズ
保守性	× 手動で更新	○ 一元管理できる	◎ バージョン管理が明確	◎ バージョン管理が明確
依存関係の管理	× 見えづらい	○ 明示的に管理可能	◎ セマンティックバージョン対応	◎ セマンティックバージョン対応
セキュリティ	◎ 完全社内	○ 外部参照の設定次第	◎ 社内限定で安全	× 公開リスクあり
CI/CDとの相性	× 手動運用	△ 工夫が必要	◎ 自動化しやすい	◎ 自動化しやすい
運用コスト	◎ ほぼゼロ	△ 管理ルールが必要	○ パッケージ化の手間あり	○ 公開管理の手間あり
弊社での採用	△ 状況に応じて採用	〇 一部採用中	◎ 主に採用中	×

まとめ

ここまで、社内で共通機能を共有するための4つの方法を紹介してきました。
それぞれにメリット・デメリットがあって、プロジェクトの規模やチームの体制によって向き不向きがあるな〜と感じます。

特にポイントになるのは、保守性・依存関係・セキュリティ・運用コストあたり。
「とりあえず動けばOK」なフェーズではコピー配置でも十分ですが、長期的に見てメンテしやすい仕組みを作るなら、やっぱりパッケージ化して管理する方法（③や④）が強いです。

弊社では、会社の資産を守るという観点から③のPrivateパッケージ公開を採用しています。
最初はちょっと手間がかかりますが、慣れてくるとCI/CDで自動化できるし、バージョン管理もラクになるので、結果的に運用が安定します。

この記事が、これからチーム開発を始める人や、社内のコード共有に悩んでいる人の参考になればうれしいです！

弊社のソースコード管理の歴史についてはこちらの記事をご確認ください。
ソースコード管理今昔物語 - KENTEM TechBlog

おわりに

KENTEMでは、様々な拠点でエンジニアを大募集しています！ 建設×ITにご興味頂いた方は、是非下記のリンクからご応募ください。 recruit.kentem.jp career.kentem.jp