転職の準備中にDockerとLinuxをどこまで学ぶか決めて、2作目のアプリはDockerなしで作り終えた

2026年10月7日

自分の発信を1か所に集めるハブサイト「Hubpin」を、個人で作りました。
制作の経緯は「Hubpin 開発記録」に時系列でまとめています。
Claude Code を取り入れながら、設計から実装まで一人で進めています。

7月の終わり、転職の準備を進めるなかで、Docker と Linux を今から学ぶかどうかで迷いました。
自分の構成と並べてみて、Docker は2作目に入れない、Linux は基礎から通しては学ばない、と決めました。
その後、2作目の Hubpin を Docker なしで作り終えています。
決めた理由と、そのあと実際に Docker が出てきた場面を残しておきます。

求人やスキルシートを見ていて、Docker と Linux で迷いました

React と TypeScript を学び始めて、1作目のアプリを作り終えた頃です。
次に何を学ぶかを整理していて、2つの疑問が出てきました。

1つは、docker-compose を2作目に導入したほうがいいのか。
そもそも Docker が何をするものなのかも、説明できるほどは分かっていませんでした。

もう1つは、Linux のコマンドを基礎から勉強したほうがいいのか。
それとも、使えれば十分なのか。

どちらも求人票やスキルシートの例でよく見かける名前です。
並んでいないと不利になるのでは、という気持ちがありました。

理由は「要らない」ではなく、組む相手がいないことでした

結論は、Docker は2作目に入れない、Linux は基礎から通しては学ばない、です。
ただ、そう決めるまでに理由の置き方を一度変えています。

最初は「必要か、不要か」で考えていました。
この問いだと、どちらにも答えが出せません。
実務では使われているので「不要」とは言えず、かといって今すぐ要るとも言えないからです。

そこで、問いを「自分の構成に、Docker で組む相手がいるか」に変えました。
これなら、手元の構成を並べるだけで答えが出ます。

構成を並べると、Docker で束ねるものがありませんでした

docker-compose は、アプリ本体やデータベースなど、複数のものをまとめて立ち上げる道具です。
2作目の構成と並べると、次のようになりました。

Docker で束ねるもの	2作目の構成
アプリ本体	Next.js。`npm run dev` で動く
データベース	Supabase のクラウド。ローカルに立てない
デプロイ	Vercel。Docker のイメージを受け取らない
環境を揃える相手	いない（1人で開発）

この状態で docker-compose.yml を書いても、載るのはアプリ1つだけになります。
それでは「Docker を使えます」の証明にはなりにくいと感じました。

ただ、Docker そのものは実務で必ず必要になる技術だと思っています。
求人を見ても、必須スキルに挙がっていることが多く、書かれていなくても使えることが前提になっている求人も多いと感じます。
なので、2作目に入れるかどうかと、Docker を身につけるかどうかは、別の話として分けました。

Linux は、事情が少し違いました。
私は教材を最初から通す期間に手が止まりやすいと分かっています。
作り始めると進むので、体系的に学ぶのはいまの優先順位には入れませんでした。

知識として押さえる範囲は先に決めました

2作目に入れないと決めたものでも、仕事では確実に出てきます。
なので、知識として押さえておく範囲を先に決めました。

Docker で押さえておくのは、次の場面です。

入社初日の環境構築が docker compose up で終わる現場は多い
WordPress のローカル開発で使う wp-env も、中身は Docker で動いている
CI でも、ジョブをコンテナの中で動かす設定がある
Supabase をローカルで動かす supabase start は、Docker Desktop が前提になっている

WordPress の制作を2年半やってきたので、2つ目は身近な話でした。
使っている道具の下で Docker が動いていた、という場面はほかにもありそうです。

Linux は、押さえる概念を3つに絞りました。

パイプとリダイレクト
標準出力と標準エラー出力の違い
ファイルのパーミッション

この3つは、日々の作業でもコマンドを打つたびに関わっています。
ほかのコマンドは困ったときに調べれば済みます。
この3つは土台の考え方なので、改めて言葉で説明できるように整理しておく枠を予定に入れました。

スキルシートの書き方も、このとき決めています。
Docker を書くとしても、既存の環境を起動してローカルで開発した経験の範囲までにします。
使っていないものを、使ったように見せないための線です。
キャッチアップを進めたら、その分だけ書き足します。

2作目を作るなかで、Docker が出てきた場面は2つありました

8月から作り始めた2作目は、9月上旬に予定していた工程をひととおり終えました。
最後まで Docker は入れていません。
それでも、制作の途中で Docker が顔を出した場面が2つありました。

1つ目は、データベースの変更を Supabase のクラウドへ反映したときです。
supabase db push を走らせると、Docker Desktop が無いという警告が出ました。
止まったと思って最後まで読むと、反映は完了していました。

2つ目は、作業の手順書です。
初版に supabase db reset が3か所書かれていました。
これはローカルのデータベースを作り直すコマンドで、Docker が無いこの環境には、そもそもローカルのデータベースがありません。
作業に入る前に食い違いが見つかり、実行はしていません。
手順書の冒頭に「この環境の前提」の節を足して、どのコマンドを使うかを先に書く形にしました。

2つ目で気づいたのは、「入れない」と決めたことも、書き残さないと伝わらないということです。
Docker が無いのは、自分にとっては当たり前の前提でした。
ただ、コードにもデータベースの変更ファイルにも、その前提はどこにも書かれていませんでした。