プログラミングを始めたばかりの方が、プロジェクトを開くと必ずといっていいほど目にするのが「src」というフォルダです。
「srcって何？なぜ必要なの？」
「プログラムファイルを直接プロジェクトルートに置いちゃダメなの？」
こんな疑問を持つ方は多いのではないでしょうか。実際、初心者向けのチュートリアルでは、この「src」フォルダについて詳しく説明されないまま、「とりあえずsrcフォルダの中にコードを書きましょう」と進んでしまうことがよくあります。
しかし、srcフォルダの役割を理解することは、プログラミングのプロジェクト管理において非常に重要です。適切なディレクトリ構造を理解することで、コードの整理がしやすくなり、チーム開発もスムーズになります。
この記事では、srcフォルダの意味、役割、なぜ使われるのか、そして実際のプロジェクトでどう活用するのかを、初心者にも分かりやすく解説します。
srcフォルダとは何か
基本的な意味
「src」は「source（ソース）」の略語です。
つまり、srcフォルダは「ソースコードを格納するためのフォルダ」という意味になります。
ソースコードとは、プログラマーが書いた、人間が読めるプログラムの元となるコードのことです。このソースコードをコンピューターが理解できる形に変換（コンパイル）することで、実際に動くプログラムになります。
なぜsrcと略すのか
プログラミングの世界では、フォルダ名やファイル名を短く簡潔にする習慣があります。
- 長いパスを何度も入力する手間を減らすため
- コマンドラインでの操作を効率化するため
- 世界中の開発者が共通で理解できる標準的な名前にするため
「source」を「src」と略すのは、プログラミング業界全体で広く使われている慣習です。
srcフォルダの役割：なぜ必要なのか
「全部のファイルをプロジェクトのルート（一番上の階層）に置けばいいじゃないか」と思うかもしれません。確かに小さなプロジェクトならそれでも問題ありませんが、srcフォルダには重要な役割があります。
役割1：ソースコードとその他のファイルを分離する
プロジェクトには、ソースコード以外にも様々なファイルが必要です：
- 設定ファイル（package.json、tsconfig.jsonなど）
- ドキュメント（README.md、使い方のマニュアルなど）
- テストコード（test/フォルダ）
- ビルド結果（dist/やbuild/フォルダ）
- 依存関係（node_modulesなど）
- 画像や静的ファイル（public/やassets/フォルダ）
これらを全部プロジェクトルートに置いてしまうと、どのファイルがソースコードで、どのファイルが設定ファイルなのか、一目で分からなくなります。
srcフォルダを使うことで、「ここがプログラムの本体だ」と明確に示すことができるのです。
役割2：ビルド前とビルド後を分ける
特にコンパイルが必要な言語（Java、TypeScript、C++など）では、この分離が重要です。
ビルド前（src/）
- 人間が読み書きする元のソースコード
- 編集・開発するのはこちら
ビルド後（dist/、build/、bin/など）
- コンピューターが実行できる形に変換されたファイル
- 配布・実行するのはこちら
この2つを明確に分けることで：
- どのファイルがバージョン管理の対象か分かりやすい（通常、src/は保存、dist/は除外）
- ビルドツールがどこを処理すればいいか明確になる
- プロジェクトの構造が整理される
役割3：チーム開発での共通理解
世界中の開発者が「src」という名前を標準的に使っているため、初めて参加するプロジェクトでも「ああ、srcフォルダにソースコードがあるんだな」とすぐに理解できます。
これは、新しいメンバーがプロジェクトに参加したときや、オープンソースプロジェクトに貢献するときに非常に重要です。
プロジェクトの基本的なディレクトリ構造
srcフォルダは、通常こんな構造の中に配置されます：
MyProject/
├── src/ ← ソースコード（プログラムの本体）
│ ├── index.js
│ ├── components/
│ └── utils/
├── dist/ ← ビルド結果（実行ファイル）
├── test/ ← テストコード
├── docs/ ← ドキュメント
├── config/ ← 設定ファイル
├── public/ ← 静的ファイル（画像など）
├── node_modules/ ← 依存パッケージ
├── package.json ← プロジェクト設定
├── README.md ← 説明ファイル
└── .gitignore ← Git除外設定この構造により、それぞれのファイルがどんな役割を持つのか一目瞭然になります。
言語・フレームワーク別のsrcフォルダの使い方
srcフォルダの使い方は、プログラミング言語やフレームワークによって少しずつ異なります。
Java（Eclipse、IntelliJなど）
Javaプロジェクトでは、srcフォルダは必須といえます。
JavaProject/
├── src/ ← ソースコード
│ └── com/
│ └── example/
│ ├── Main.java
│ └── Utils.java
├── bin/ ← コンパイル後のclassファイル
├── lib/ ← 外部ライブラリ
└── test/ ← テストコードJavaでは、パッケージ構造（com.example.Mainのような）がディレクトリ構造に対応しています。srcフォルダを使わないと、IDEやビルドツールが正しくパッケージを認識できません。
JavaScript/TypeScript（Node.js、React、Vue.jsなど）
JavaScriptプロジェクトでもsrcフォルダは一般的です。
ReactProject/
├── src/ ← ソースコード
│ ├── index.js ← エントリーポイント
│ ├── App.js
│ ├── components/ ← コンポーネント
│ ├── pages/ ← ページ
│ ├── utils/ ← ユーティリティ関数
│ └── styles/ ← スタイルシート
├── public/ ← 静的ファイル（HTML、画像など）
├── dist/ ← ビルド後のファイル
├── node_modules/ ← 依存パッケージ
└── package.json特にTypeScriptでは、src/のコードをコンパイルしてdist/に出力する流れが一般的です。
Python
Pythonでは2つのパターンがあります。
フラットレイアウト（小規模プロジェクト向け）
python-project/
├── my_package/ ← パッケージ（srcは使わない）
│ ├── __init__.py
│ └── module.py
├── tests/
└── setup.pysrcレイアウト（推奨、大規模プロジェクト向け）
python-project/
├── src/ ← ソースコード
│ └── my_package/
│ ├── __init__.py
│ └── module.py
├── tests/
└── setup.pyPythonコミュニティでは、srcレイアウトの方が推奨されています。理由は、テスト時にインストールされていないコードが誤って動作してしまうのを防げるためです。
C/C++
C/C++では、srcフォルダに加えてincludeフォルダも使われます。
CppProject/
├── src/ ← 実装ファイル（.cppファイル）
│ ├── main.cpp
│ └── utils.cpp
├── include/ ← ヘッダーファイル（.hファイル）
│ └── utils.h
├── build/ ← ビルド結果
├── lib/ ← 外部ライブラリ
└── Makefile ← ビルド設定ヘッダーファイルとソースファイルを分けることで、公開すべきインターフェースと内部実装を明確に分離できます。
Ruby（Ruby on Rails）
Railsでは、srcフォルダではなくappフォルダが主に使われます。
RailsProject/
├── app/ ← アプリケーションコード（srcの代わり）
│ ├── controllers/
│ ├── models/
│ ├── views/
│ └── helpers/
├── config/
├── db/
└── test/これは、Railsの「Convention over Configuration（設定より規約）」という哲学に基づいています。
srcフォルダの内部構造
srcフォルダの中身は、プロジェクトの種類によって異なりますが、一般的なパターンを紹介します。
パターン1：機能別に分ける
各機能ごとにフォルダを作成する方法です。
src/
├── auth/ ← 認証機能
│ ├── login.js
│ └── register.js
├── user/ ← ユーザー管理機能
│ ├── profile.js
│ └── settings.js
├── payment/ ← 決済機能
│ └── checkout.js
└── utils/ ← 共通ユーティリティ
└── helpers.js関連するコードが一箇所にまとまるので、機能の追加・修正がしやすくなります。
パターン2：レイヤー別に分ける
MVC（Model-View-Controller）のような、アーキテクチャのレイヤーごとに分ける方法です。
src/
├── models/ ← データ構造・ビジネスロジック
│ ├── User.js
│ └── Product.js
├── views/ ← 画面表示
│ ├── UserView.js
│ └── ProductView.js
├── controllers/ ← 制御ロジック
│ ├── UserController.js
│ └── ProductController.js
└── routes/ ← ルーティング
└── api.js役割が明確になり、責任の分離がしやすくなります。
パターン3：ハイブリッド型
機能別とレイヤー別を組み合わせた方法です。
src/
├── components/ ← 再利用可能なコンポーネント
│ ├── Button.js
│ └── Input.js
├── pages/ ← ページ単位のコンポーネント
│ ├── Home.js
│ └── About.js
├── services/ ← API通信など
│ └── api.js
├── utils/ ← ユーティリティ関数
│ └── helpers.js
└── index.js ← エントリーポイント多くのモダンなフレームワーク（React、Vue.js）でこの構造が使われています。
srcと関連する他のフォルダ
srcフォルダは単独で存在するのではなく、他のフォルダと連携しています。
dist/（またはbuild/）フォルダ
役割：ビルド後の実行可能ファイルを格納
srcフォルダのコードをコンパイル・バンドル・最適化した結果がここに出力されます。
特徴：
- 自動生成されるため、通常はGitで管理しない（.gitignoreに追加）
- ユーザーに配布するのはこちら
- srcフォルダより小さく最適化されている
src/index.js →（ビルド）→ dist/index.min.jstest/（またはspec/）フォルダ
役割：テストコードを格納
ソースコードが正しく動作するかをチェックするテストコードを入れます。
配置パターン：
- 別フォルダに分離：test/フォルダにまとめて配置
- ソースコードの隣に配置：user.js の隣に user.test.js を置く
最近は2番目のパターン（テストファイルをソースコードの近くに置く）が増えています。
lib/フォルダ
役割：共有ライブラリや外部ライブラリを格納
- 自作の共有コード（複数の場所で使う関数など）
- 外部からダウンロードしたライブラリ
プロジェクトによっては、srcフォルダの代わりにlibフォルダを使うこともあります（特にライブラリを開発する場合）。
public/（またはstatic/）フォルダ
役割：画像、フォント、HTMLなど静的ファイルを格納
ソースコードではない、そのまま使うファイルを入れます。
public/
├── index.html
├── favicon.ico
├── images/
│ └── logo.png
└── fonts/
└── custom-font.ttfconfig/フォルダ
役割：設定ファイルを格納
アプリケーションの動作を制御する設定ファイルを入れます。
config/
├── database.json ← データベース接続設定
├── api.json ← API設定
└── app.json ← アプリケーション設定srcフォルダを使う際のベストプラクティス
1. プロジェクトルートをすっきり保つ
プロジェクトルートには、最小限のファイルのみを配置します。
良い例：
MyProject/
├── src/
├── dist/
├── package.json
├── README.md
└── .gitignore悪い例：
MyProject/
├── index.js ← srcに入れるべき
├── utils.js ← srcに入れるべき
├── config.js ← configフォルダに入れるべき
├── test1.js ← testフォルダに入れるべき
├── package.json
└── README.mdルートが散らかると、プロジェクト全体の把握が難しくなります。
2. エントリーポイントを明確にする
srcフォルダの直下に、プログラムの開始点となるファイルを置きます。
よく使われる名前：
index.js（JavaScript/TypeScript）main.js（JavaScript/TypeScript）Main.java（Java）main.cpp（C++）app.py（Python）__init__.py（Python）
これにより、「どこから実行すればいいのか」が一目で分かります。
3. サブディレクトリを適切に使う
srcフォルダが大きくなってきたら、機能やレイヤーごとにサブディレクトリを作ります。
小規模プロジェクト（10ファイル以下）：
src/
├── index.js
├── utils.js
└── config.js中規模プロジェクト（10〜50ファイル）：
src/
├── index.js
├── components/
├── utils/
└── services/大規模プロジェクト（50ファイル以上）：
src/
├── index.js
├── features/
│ ├── auth/
│ ├── user/
│ └── payment/
├── components/
├── services/
└── utils/4. READMEファイルを用意する
srcフォルダの構造が複雑になってきたら、README.mdファイルでディレクトリ構造を説明しましょう。
# ディレクトリ構造
- `src/` - ソースコード
- `components/` - 再利用可能なUIコンポーネント
- `pages/` - ページコンポーネント
- `services/` - API通信などのサービス層
- `utils/` - ユーティリティ関数
- `index.js` - アプリケーションのエントリーポイント新しいメンバーが参加したときに、すぐに理解できます。
よくある質問：srcフォルダに関するQ&A
Q1. srcフォルダは絶対に必要ですか？
いいえ、必須ではありません。
小さな個人プロジェクトやスクリプトなら、srcフォルダなしでも問題ありません。ただし、以下の場合はsrcフォルダを使うことを強く推奨します：
- チームで開発する場合
- ビルドプロセスがある場合
- プロジェクトが成長する可能性がある場合
- 将来的に公開・配布する可能性がある場合
Q2. srcフォルダとappフォルダ、どちらを使うべき？
コンパイルが必要な言語（Java、TypeScript、C++など）：
→ srcを使う（業界標準）
Webアプリケーションフレームワーク（Ruby on Rails、Next.jsなど）：
→ フレームワークの慣習に従う（Railsならapp、Next.jsならsrcまたはapp）
一般的なルール：
特に決まりがなければsrcを使っておけば間違いありません。
Q3. srcフォルダの中にさらにsrcフォルダを作っても良い？
通常は避けるべきです。
srcフォルダの役割は「ソースコードをまとめる」ことなので、src/の中にsrc/を作ると構造が複雑になります。
もし階層が必要なら、機能名やレイヤー名でフォルダを作りましょう：
src/
├── client/
│ └── （クライアント側のコード）
└── server/
└── （サーバー側のコード）Q4. srcフォルダをGitで管理すべき？
はい、srcフォルダは必ずGitで管理してください。
srcフォルダには元のソースコードが入っているため、バージョン管理の対象です。
逆に、distフォルダ（ビルド結果）は通常Gitで管理しません（.gitignoreに追加します）。
Q5. srcフォルダとsourceフォルダ、どちらが正しい？
どちらも正しいですが、srcの方が圧倒的に一般的です。
短い名前の方が入力の手間が少なく、コマンドラインでの操作も楽なため、srcが好まれます。
Q6. HTMLの<img src="...">のsrcと関係ある？
実は関係あります！
HTMLのsrc属性も「source（ソース）」の略で、「画像のソース（元ファイル）がどこにあるか」を指定しています。
どちらも「元になるもの」を指す点で共通しています。
Q7. 既存プロジェクトにsrcフォルダを追加できる？
できますが、慎重に行ってください。
手順：
- srcフォルダを作成
- 既存のソースコードをsrcフォルダに移動
- ビルド設定やimport文のパスを修正
- 動作確認を徹底的に行う
大規模プロジェクトでは、一度に全部移動するのではなく、段階的に移行する方が安全です。
まとめ：srcフォルダでプロジェクトを整理しよう
srcフォルダについて、重要なポイントをおさらいしましょう。
srcフォルダとは
- 「source（ソース）」の略
- プログラムのソースコードを格納するフォルダ
- プログラミング業界で広く使われる標準的な慣習
srcフォルダの役割
- ソースコードとその他のファイル（設定、ドキュメント等）を分離
- ビルド前（src）とビルド後（dist）を明確に区別
- チーム開発での共通理解を促進
言語別の使い方
- Java：必須（パッケージ構造との関係）
- JavaScript/TypeScript：非常に一般的
- Python：srcレイアウトが推奨
- C/C++：srcとincludeを併用
- Ruby on Rails：appフォルダを使用
ベストプラクティス
- プロジェクトルートをすっきり保つ
- エントリーポイント（index.js等）を明確にする
- サブディレクトリで適切に分類する
- README.mdでディレクトリ構造を説明する
- srcフォルダはGitで管理、distフォルダは除外
最後に
初心者のうちは「srcフォルダなんて面倒だな」と感じるかもしれません。確かに、10行のスクリプトならsrcフォルダは不要でしょう。
しかし、プロジェクトが成長するにつれて、適切なディレクトリ構造の重要性が分かってきます。特にチームで開発するようになると、誰が見ても分かりやすい構造が不可欠です。
srcフォルダは、そんな「分かりやすいプロジェクト構造」を実現するための、最も基本的で効果的な方法なのです。
プログラミングのスキルが上達したら、ぜひ自分のプロジェクトのディレクトリ構造を見直してみてください。srcフォルダを中心とした整理された構造が、あなたのコードをより理解しやすく、メンテナンスしやすいものにしてくれるはずです！
コメント