2026年6月6日
Software EngineeringDockerProductivity

もっと早く作っておけばよかった開発ワークスペースのアーキテクチャ

複数の雇用主・サイドプロジェクト・クライアント案件を抱える開発者向けにスケールするフォルダ構成。ソースコード・インフラ・データを分離し、マシン移行を苦痛から解放する。

2 分で読めます

あなたのコードはボトルネックではない。あなたの環境がボトルネックなのだ。

ほとんどの開発者は、何時間もかけてこう議論する。

  • React か Vue か
  • Docker か Podman か
  • Claude Code か Cursor か
  • PostgreSQL か MySQL か

その一方で、毎日触れているものには、ほとんど注意が払われていない。

自分の開発ワークスペースだ。

数か月前、ほぼ1年触っていなかったプロジェクトに戻る必要があった。

覚えていたことはいくつかあった。

  • PostgreSQL を使っていた。
  • どこかに Redis が絡んでいた。
  • アプリケーションは Docker の中で動いていた。
  • ワークフローに AI ツールが入っていた。

覚えていなかったのは、そのどれもがどこにあるかだった。

コードが問題ではなかった。アーキテクチャが問題でもなかった。

自分の開発環境が問題だった。

スタートアップで働き、サイドプロジェクトを作り、AI ツーリングを試し、クライアント案件を管理してきた間のどこかで、自分のマシンはつながりのないプロジェクトの寄せ集めと、重複した環境と、忘れられたインフラの集合体になっていた。

新しいプロジェクトはどれも、目の前の問題を解決した。だがどれも長期的な問題は解決しなかった。

キャリアとともにスケールする開発環境は、どう組織すればいいのか?

その問いが、自分のワークスペースの構造をゼロから設計し直すきっかけになった。

🚨 ほとんどの開発者が無視している問題

キャリアの早い時期、プロジェクトの組織はたいていこんな感じになる。

デフォルトの姿:1年後には誰も説明できないフォルダの山

最初はうまくいく。

それから、人生が起きる。

会社に入る。フリーランスを始める。スタートアップを立ち上げる。オープンソースプロジェクトを作る。AI ツーリングを試し始める。PostgreSQL、Redis、Docker コンテナ、ローカルサービスを動かし始める。

プロジェクトの数が問題なのではない。構造の欠如が問題なのだ。

リポジトリが増えるにつれ、頭の中のオーバーヘッドも増えていく。

  • あのリポジトリはどこにあったか?
  • どの PostgreSQL インスタンスがどのプロジェクトのものか?
  • Docker の設定はどこにあるか?
  • このフォルダは安全に削除できるか?
  • なぜ Node.js のバージョンが3つも別々にインストールされているのか?

これらの問いは些細に聞こえる。だが何年もの開発を経ると、それらは積み重なって膨大な生産性の損失になる。

🧠 システムエンジニアのように考える

転機は、自分のワークステーションをプロジェクトの集合として扱うのをやめ、ソフトウェアシステムとして扱い始めたときに訪れた。

自分にこう問いかけた。

もしこの先10年で何百というリポジトリを管理しなければならないとしたら、自分の開発環境はどんな姿をしているべきか?

その問いが、自分のアプローチを完全に変えた。

今日のプロジェクトのために最適化する代わりに、次のもののために最適化した。

  • 複数の雇用主
  • スタートアップの取り組み
  • クライアント案件
  • オープンソースへの貢献
  • Docker ファーストの開発
  • AI 支援の開発
  • 容易なマシン移行
  • 長期的な保守性

その結果、こうなった。

一つのルート。4つの所有ドメイン。インフラとデータを第一級のレイヤーとして扱う

シンプルだ。予測可能だ。スケールする。

🧱 ソースコードはインフラではない

開発者がやりがちな最大の間違いの一つが、ソースコードとインフラを混ぜてしまうことだ。

リポジトリが含むべきものはこうだ。

  • ビジネスロジック
  • アプリケーションコード
  • テスト
  • ドキュメント

そして、以下のもののゴミ捨て場になってはいけない。

  • ローカルスクリプト
  • Docker の実験
  • データベースストレージ
  • AI ツーリング
  • マシン固有の設定

だから、専用のインフラ層を導入した。

infra/
├── docker/
├── ai/
├── scripts/
└── templates/

インフラはアプリケーションとは独立して進化する。両者を分離することで、リポジトリはクリーンで焦点の定まったものに保たれる。

🐳 すべてを単純にした Docker のルール

Docker ファーストの開発環境が欲しかった。だが、すべてのリポジトリを同じように扱うべきではない。

自分がたどり着いたルールは、驚くほどシンプルだ。

✅ そのリポジトリを自分が変更できる場合

1 Project = 1 Containerized Development Environment

クローンすることになるすべてのリポジトリをカバーする2つのルール

すべてのプロジェクトが、自分専用の隔離された環境を持つ。

その利点は次のとおりだ。

  • 依存関係の隔離
  • 再現性
  • オンボーディングの容易さ
  • CI/CD との整合
  • より良い AI ツーリングのサポート

プロジェクトは自己完結する。誰かが明日それをクローンしても、まったく同じ環境が手に入る。

🔒 そのリポジトリを自分が変更できない場合

1 Organization = 1 Workspace Container

これは特に、会社のリポジトリで役に立つ。

自分が管理していないリポジトリに Docker ファイルを追加する代わりに、外部のワークスペースコンテナを作る。

infra/docker/workspaces/acme/

そのワークスペースは、その組織に属するすべてのリポジトリをマウントする。

volumes:
  - ~/Developer/company/acme:/workspace

これにより、会社が所有するコードに触れることなく、Docker ファーストのワークフローを維持できる。

小さな区別だ。だが、多くの摩擦を取り除いてくれる。

💾 なぜデータをそれ以外のすべてから分離するのか

これはおそらく、最も重要なアーキテクチャ上の決定だった。

ほとんどの開発者は、次のどちらかをやっている。

  1. データをリポジトリの中に保存する、または
  2. 完全に Docker が管理するボリュームに頼る。

自分はどちらのアプローチも気に入らなかった。代わりに、専用のデータ層を作った。

データはソースツリーを鏡写しにし、所有権が曖昧になることはない

この構造により、所有権が明白になる。自分はすぐにこう分かる。

  • どのプロジェクトがそのデータを所有しているか
  • どのデータベースがどのアプリケーションに属しているか
  • 何をアーカイブしていいか
  • 何をバックアップする必要があるか

利点は大きい。

  • よりクリーンなリポジトリ
  • より簡単なバックアップ
  • よりシンプルな移行
  • より速い Git 操作
  • ストレージ使用量への、より良い可視性

最も重要なのはこれだ。

自分のデータがどこにあるか、常に分かっている。

🤖 AI ネイティブな未来のために設計する

ソフトウェアを書く方法は変わりつつある。AI ツールは開発環境そのものの一部になりつつある。

  • Claude Code
  • Codex
  • Gemini CLI
  • ローカルモデル
  • 将来の自律エージェント

ほとんどの開発者は、これらを今もプロジェクトレベルのツールとして扱っている。

自分はこれらをインフラとして扱うことにした。

AI ツーリングはリポジトリの中ではなく、インフラの中に住む

これにより、すべてのプロジェクトで機能する再利用可能な AI 層が生まれる。

ツーリングが進化しても、自分のリポジトリはクリーンなままだ。AI スタックは、アプリケーション自体とは独立して変化する。

その分離は、これから数年でますます価値を増していくはずだ。

⚡ 最大の生産性向上は Docker ではなかった

AI でもなかった。自動化でもなかった。

認知負荷を減らすことだった。

すべてのプロジェクトが予測可能な構造に従うとき、

company/
startup/
clients/
personal/

もうこんな問いは発しなくなる。

  • このリポジトリはどこにクローンしたか?
  • どのデータベースがこのプロジェクトのものか?
  • どの会社がこのコードベースを所有しているか?
  • Docker の設定はどこにあるか?
  • これは安全にアーカイブできるか?

答えは明白だ。

そしてその一貫性は積み重なる。すべてのコンテキストスイッチが速くなる。すべての新しいプロジェクトが、オンボーディングしやすくなる。すべての未来の決定が、よりシンプルになる。

📦 マシン移行が退屈になる

ほとんどの開発者は、新しいノートPCを買うまで移行のことを考えない。

それから苦痛が始まる。Docker のボリューム。設定ファイル。スクリプト。データベース。環境変数。すべてがどこにあるか、誰も覚えていない。

自分のゴールはシンプルだった。

もし今日マシンが壊れたら、一つのディレクトリからすべてを再構築できるべきだ。

重要なものはすべて、この下にある。

Developer/

リポジトリ。インフラ。永続データ。それだけだ。

開発環境は持ち運び可能になる。

そして持ち運び可能であることは、投資する価値のある生産性機能の中でも、最も過小評価されているものの一つだ。

🎯 本当の教訓

フォルダ構造そのものが重要な部分ではない。その背後にあるマインドセットが重要なのだ。

優れたエンジニアは、アプリケーションだけを設計するのではない。システムを設計する。

あなたのワークステーションはシステムだ。あなたの開発ワークフローはシステムだ。あなたの生産性はシステムだ。

そうしたシステムの設計にどれだけ意図的になれるかによって、それと戦うために費やすエネルギーは減り、実際のエンジニアリングの問題を解くためのエネルギーが増える。

よく設計された開発環境は、一晩であなたをより優れた開発者にしてはくれない。

だが何千時間もの作業を経る中で、それは触れるすべてのプロジェクトから静かに摩擦を取り除いていく。

それこそが、本当の生産性向上が生まれる場所だ。

💬 あなたの開発ワークスペースはどんな見た目ですか?

Docker、Dev Containers、そして AI 支援開発が標準的なワークフローの一部になりつつある今、他のエンジニアがどう自分の環境を組織しているのか、いつも興味がある。

ツーリングの状況は毎年変わる。

優れたワークスペースのアーキテクチャは、そのすべてを生き延びるべきだ。