ADHDの特性として、環境設定に時間を取られて注意が散れてしまう、設定を途中で投げ出してしまう、という悩みは多くのエンジニアに共通しています。そこで有効なのが「使い捨て開発環境」――短時間で作って使って捨てられる環境です。セットアップを自動化し、必要なものをテンプレート化しておくことで、迷いを最小化できます。

この記事では、実際に動作するスクリプトと構成例をもとに、ADHDエンジニアが挫折しない開発環境の作り方を紹介します。

なぜ「使い捨て開発環境」が有効なのか

従来の開発環境構築には次のような落とし穴があります。

• 依存関係の解決に時間がかかり、本来の作業に入る前に集中力が切れる
• 環境が壊れたときの復旧手順が不明確で、修正に数時間かかることがある
• 設定が増えるにつれて「どこで何をしたか」が追えなくなる

「使い捨て」というアプローチは、これらの問題をリセットします。環境を使い終わったら削除し、次回は同じテンプレートから再構築する。この繰り返しにより、「壊れたら直す」ではなく「壊れたら作り直す」という軽いメンタルモデルに移行できます。復旧に悩む時間がゼロになるのが最大の利点です。

設計方針：挫折しないための3つのルール

1. 短時間で動くこと：初期化は数分で終わらせる。長いセットアップは途中離脱の原因になります。初回起動が5分を超えるようなら構成を見直しましょう。
2. 戻せる／捨てられること：失敗しても復旧が簡単。コンテナや仮想環境を使えば、削除してやり直すだけです。「壊れたら終わり」という恐怖をなくすことが大切です。
3. 最小限の決断で済むこと：選択肢を減らす。テンプレートを使えば「何を入れるか」で悩む必要がなくなります。迷う余地を設計段階で排除します。

具体的な構成案

ここではローカル＋コンテナ方式をベースにした実践パターンを紹介します。「テンプレリポジトリ」「起動スクリプト」「クリーンアップスクリプト」の3点セットが核心です。

1. テンプレリポジトリを作る

よく使う設定をGitHubのテンプレートリポジトリにまとめます。リポジトリ名は dev-template など分かりやすい名前にしておきましょう。GitHubの「Use this template」機能を使えば、新しいプロジェクトを始めるたびにこのテンプレートから即座にリポジトリを作成できます。

用意するファイルの構成例：

• Dockerfile
• docker-compose.yml
• .devcontainer/devcontainer.json
• init.sh
• cleanup.sh
• README.md（起動・終了の手順を3行以内で記載）

テンプレートは「最低限の必須ツールだけ」に絞るのが原則です。最初から全部入りにしようとすると、テンプレート自体の管理が重荷になります。

2. ワンコマンドで起動するスクリプト

以下は init.sh の実装例です。実行するとリポジトリをクローンし、Docker環境を起動します。

#!/bin/bash
set -e

git clone https://github.com/you/dev-template workdir
cd workdir
docker-compose up -d --build
echo "環境の準備が完了しました。"
echo "VSCode Dev Containerを使う場合："
echo "  コマンドパレット（Ctrl+Shift+P）から"
echo "  「Dev Containers: Open Folder in Container」を選択してください。"

Windowsユーザーは、WSL2上でこのスクリプトを実行してください。WSL2が未設定の場合は、Microsoftの公式ドキュメントに従ってWSL2とDocker Desktopを先にセットアップしてください。PowerShellで動かしたい場合は init.ps1 を別途作成する必要があります。

3. クリーンアップスクリプト

作業が終わったら環境を丸ごと削除します。以下は安全に動作する cleanup.sh の実装例です。

#!/bin/bash
set -e

TARGET=$(pwd)
echo "削除対象: $TARGET"
read -p "本当に削除しますか？ (y/N): " confirm

if [[ "$confirm" == "y" || "$confirm" == "Y" ]]; then
  docker-compose down --volumes --remove-orphans
  cd ..
  rm -rf "$TARGET"
  echo "環境を削除しました。"
else
  echo "キャンセルしました。"
fi

便利ツール比較

なお、direnv・asdf・nix はローカルに環境を永続的に管理するツールです。「使い捨て」環境とは異なるアプローチですが、プロジェクトごとに環境を自動切替できるため、「どのバージョンを使うか」という決断を減らす目的で組み合わせることができます。完全な使い捨てより「切り替えを自動化したい」という場合に検討してください。

実践例：Node.jsプロジェクトの場合

まず Dockerfile のシンプルな例です。

FROM node:20-slim
WORKDIR /workspace
COPY package*.json ./
RUN npm install
COPY . .
CMD ["bash"]

次に docker-compose.yml の例です。

version: '3.8'
services:
  app:
    build: .
    volumes:
      - .:/workspace
    ports:
      - "3000:3000"
    stdin_open: true
    tty: true

作業の流れはシンプルにまとめられます。

1. テンプレートリポジトリから新しいリポジトリを作成（GitHubの「Use this template」）
2. git clone <リポジトリURL> workdir でローカルにクローン
3. cd workdir && ./init.sh で環境を起動
4. VSCodeで対象フォルダを開き「Reopen in Container」を選択して開発開始
5. 作業終了後は ./cleanup.sh で環境を削除

Node.js以外のプロジェクトでも、FROM に指定するイメージを変えるだけで同じ手順が使えます。Python なら python:3.12-slim、Go なら golang:1.22 に置き換えてください。

挫折しにくくする4つの工夫

チェックリストを短文化する

起動から終了までのステップを3〜5行のチェックリストにまとめ、README.md に書いておきます。毎回迷わずに始められるようにすることが目的です。「コマンドを覚える」のではなく「READMEを見れば動く」状態を作ります。

テンプレのバージョンを固定する

DockerイメージやNode.jsのバージョンを固定しておかないと、ある日突然動かなくなることがあります。node:20-slim のようにバージョンを明示し、latest タグは避けましょう。環境の「突然の変化」はADHDエンジニアにとって特にストレスになるため、安定性を優先します。

タイムボックスを設定する

セットアップは最大30分までと決め、超えたら「最小構成で動かす」に切り替えます。完璧な環境を最初から目指さないことが継続のコツです。30分で動かなかった部分は翌日に回しても問題ありません。

小さな成功体験を積む

最初は「README.md に書いてあるコマンドを1つだけ実行する」から始めましょう。環境が動いた瞬間の達成感が次への動機になります。「完成させる」ではなく「1ステップ動かす」を繰り返すことが大切です。

よくある質問（FAQ）

Q. 依存が多すぎて環境が重くなってしまいます

A. テンプレートに含めるのは「最低限の必須ツールだけ」にしてください。追加したいツールが出てきたら、その都度テンプレートに反映する習慣をつけると、気づかないうちに最適化されていきます。「全部入り」ではなく「後から足す」の思想で管理しましょう。

Q. 設定を忘れて環境が動かないことがあります

A. docker-compose.yml に healthcheck を追加し、起動時に自動でサービスの動作確認をさせましょう。ヘルスチェックが失敗したら原因を調べるだけで済みます。また、init.sh の末尾に動作確認コマンドを追加しておくと、起動直後に問題を検知できます。

Q. 作業の途中で飽きてしまいます

A. セットアップ作業を「5分×複数回」に分割してください。「今日は Dockerfile だけ書く」「明日は init.sh を書く」という区切り方が有効です。1回のセッションを短くすることで、離脱しても「また明日から再開できる」という感覚を持てます。

Q. クラウド環境（CodespacesやGitpod）は有料ですか？

A. どちらも無料枠があります。GitHub Codespacesは月60時間、Gitpodは月50時間まで無料です。個人の学習・開発用途であれば無料枠で十分なケースが多いです。ローカルのDockerセットアップに詰まった場合、クラウド環境への切り替えが最速の解決策になることもあります。

Q. Windowsでも同じ方法で使えますか？

A. WSL2（Windows Subsystem for Linux 2）とDocker Desktopをインストールすれば、同じ構成で動作します。WSL2のセットアップに最初だけ時間がかかりますが、一度構築すれば以後は同じ手順で使えます。WSL2の設定に詰まる場合は、最初からGitHub CodespacesやGitpodを使う方が早い場合もあります。

まとめ：小さく始めて習慣化する

「使い捨て開発環境」は完璧である必要はありません。大切なのは迷わずに始められることです。

まずは1つのテンプレートリポジトリを作り、毎回同じ手順で立ち上げる習慣をつけましょう。慣れてきたら自動化やクラウド化を少しずつ追加していけばOKです。

投稿 ADHDエンジニアが挫折しない使い捨て開発環境の構築法 は ADHDエンジニア成長日記 ― 障害を抱えながらIT業界で活躍するためのブログ に最初に表示されました。