Go 開発者向けロードマップのほとんどは、根拠のない雰囲気で作られています。誰かが一度でも package main から何かをリリースしたことのあるフレームワークを片っ端から並べ、それを学習パスと呼んでいるのです。このロードマップは出発点が違います。2025 年の終わりに、現役の Go 開発者 5,379 人が Go チームに対して、Go を実際に何に使い、どうデプロイし、どこでつまずいているのかを伝えました。以下のロードマップは、そのデータに沿っています。
2026 年に Go を始めるなら、Gin に 3 週間を費やす前にこの記事を読んでください。
要約
- 「プログラミング入門」系の教材は飛ばしましょう。Tour of Go を開き、ターミナルから何も考えずに Go のプログラムをビルドして実行できるようになるまで、ツールチェーン（
go run、go build、go mod）を使い込んでください。 - Effective Go は早い段階で読みましょう。調査の回答者の 33% が「自分たちの Go のコードがベストプラクティスやイディオムに従っているようにすること」を最大の不満に挙げており、どの機能不足よりも上位です。
- 現役の Go 開発者の 73〜74% が実際にリリースしている 2 種類のプロジェクト、つまりコマンドラインツールと API/RPC サービスを作りましょう。
- フレームワークより先に
net/httpと標準ライブラリを学びましょう。フレームワークは、プロジェクトで必要になったときに後から追加すれば十分です。 - 次は並行処理です。goroutine、channel、
contextによるキャンセルを学びます。テストは進めながら書いていきましょう。 - Go チームは「公式」のロードマップを公開していません。なので、公式を名乗るものは少し疑ってかかりましょう。このガイドは、代わりに調査結果、Go のドキュメント、言語の設計者たちの言葉を拠り所にしています。
- 全体の道筋を知りたいですか？LevelUpGo のインタラクティブなロードマップなら、hello world から本番環境のアプリまで一通り進めます。
flowchart LR A["Stage 1<br/>Toolchain + Tour of Go"] --> B["Stage 2<br/>Effective Go + Idioms"] --> C["Stage 3<br/>Concurrency"] D["Stage 4<br/>CLI + HTTP service"] --> E["Stage 5<br/>Testing + Standard library"] --> F["Stage 6<br/>Frameworks (only when needed)"]
ロードマップの 6 つのステージ。フレームワークは最後に置いています。
2025 年に Go 開発者 5,379 人が Go チームに伝えたこと
Go チームは毎年、開発者調査を実施しています。2026 年 1 月に公開された 2025 年の結果には 7,070 件の回答が集まり、そのうち 5,379 件がデータクリーニングを通過しました。回答者の 87% はプロの開発者で、82% は本業で Go を使っています（出典）。
以下の順序はすべて、この調査の次の数字をもとに決めています。
| 指標 | 値 | 意味すること |
|---|---|---|
| 最も多いプロジェクトの種類 | コマンドラインツール（74%） | CLI の章を飛ばすと、現役の Go 開発者が作っているものの 4 分の 3 を飛ばすことになります。 |
| 2 番目に多いプロジェクトの種類 | API/RPC サービス（73%） | CLI とほぼ互角です。この 2 つで Go の仕事の大半をカバーできます。 |
| デプロイ先 | Linux コンテナ（96%） | 書いたコードは Linux 上で動くことになるので、docker build は早めに覚えましょう。 |
| 最大の不満 | イディオム / ベストプラクティス（33%） | 機能不足よりも「何が Go らしいのか」で悩んでいる人のほうが多いのです。 |
| エディタのシェア | VS Code 37%、GoLand 28% | どちらでも構いません。どちらかに決めて、コードを書くことに戻りましょう。 |
xychart-beta title "What Go developers build, 2025 survey" x-axis ["CLIs", "API services", "Libraries", "Cloud infra", "ML tools"] y-axis "Percent of respondents" 0 --> 100 bar [74, 73, 49, 33, 11]
CLI と API サービスが大きく引き離しています。フレームワークを選ぶ前に、それぞれ 1 つずつ作りましょう。
ステージ 1：ツールチェーンと最初のプログラム
Go チームの公式な「Getting Started」の手順は、意図的に短くなっています。Go をインストールし、hello world を実行し、go コマンドを理解し、モジュールを書く、という流れです（出典）。
何よりも先に、次の 3 つに慣れておきましょう。
goコマンド。go run、go build、go install、go fmt、go test、go modです。フラグを暗記する必要はありませんが、どの場面でどのコマンドを使うかはわかるようにしておきましょう。- モジュール。
go mod init <name>でgo.modが作られ、import を追加するとgo.sumが自動で更新されます。複数モジュールのワークスペースという仕組みもありますが、しばらくは必要ありません。 - A Tour of Go。 Russ Cox が書いたもので、Go チームが最初のインタラクティブな教材として勧めています。演習はすべてやりましょう。
最初のプログラムは次のようになります。
example.gogopackage main import "fmt" func main() { fmt.Println("hello, go") }
ビルドの手順を踏まずに、そのまま実行できます。
example.gogo$ go run main.go hello, go
何かを動かす前にビルドパイプラインを設定する必要はありません。小さな Go のプログラムの多くは、このシンプルさのままです。
ステージ 2：Effective Go（ほとんどのロードマップが飛ばすステップ）
Effective Go は頻繁に引用されるのに、早い段階で読む人はあまりいません。Go チームはこれを「新しく Go を書くすべてのプログラマーにとって必読」と呼んでおり、公式サイトで無料で読めます。
現役の Go 開発者の 33% が「自分たちの Go のコードがベストプラクティスや Go のイディオムに従っているようにすること」を最大の不満として挙げています。これは「言語機能の不足」（28%）や「信頼できるモジュール」（26%）を上回っています。構文は簡単な部分です。難しいのは、ほかの Go 開発者が読んで「普通の Go だ」と感じるコードを書くことです。
Tour の後、フレームワークに手を出す前に読みましょう。約 50 ページの密度の高い内容で、命名、エラー処理、interface、並行処理、フォーマットを扱っています。
たとえば、エラーを処理する標準的な書き方はこう教えています。
example.gogofile, err := os.Open(path) if err != nil { return fmt.Errorf("open %s: %w", path, err) } defer file.Close()
エラーはその場ですぐにチェックします。%w でラップするとエラーの連鎖が保たれるので、呼び出し側は引き続き errors.Is や errors.As で中身を調べられます。後始末は finally ブロックではなく defer に書きます。
このパターンは、どの Go のコードベースを開いても目にします。Effective Go を飛ばした人は、これを自己流で、しかも下手に再発明しがちです。LevelUpGo の Go Idioms & Naming コースではこうしたパターンをインタラクティブに練習できますが、元のドキュメントは無料で、権威ある一次情報でもあります。
ステージ 3：実際の Go のコードと同じやり方で並行処理を学ぶ
並行処理は、多くの人がそれ自体を目的に学び、そして間違った使い方をしてしまう Go の機能です。実際の Go のコードが使っている部品、つまり goroutine、channel、context を通して学ぶと、身につきやすくなります。
少なくとも次の 3 つは必要です。
- goroutine は
go someFunc()で開始します。OS スレッドではありません。ランタイムが、少数のスレッドからなるプールの上にスケジューリングします。 - channel は、goroutine 同士が連携するための型付きのパイプです。バッファなしなら
make(chan T)、バッファ付きならmake(chan T, n)です。 context.Contextは、関数や goroutine の境界をまたぐ処理をキャンセルするための仕組みです。現在では、ブロックする標準ライブラリの API は context を受け取ります。
最もよく使われる組み合わせは、goroutine に処理を分散し、channel で結果を集め、context がキャンセルされたら途中で止めるというものです。
sequenceDiagram participant Caller participant Main as fetchAll participant G as Worker goroutines participant Ch as Results channel Caller->>Main: ctx, urls Main->>G: spawn one goroutine per URL G->>Ch: send result Caller-->>Main: ctx cancel signal Ch->>Main: collect via select Main->>Caller: results
処理を分散し、結果を集め、キャンセルされたら止める。Go のサーバーは内部でこの形を使っています。
example.gogofunc fetchAll(ctx context.Context, urls []string) []result { out := make(chan result, len(urls)) for _, u := range urls { go func(u string) { out <- fetch(ctx, u) }(u) } results := make([]result, 0, len(urls)) for range urls { select { case r := <-out: results = append(results, r) case <-ctx.Done(): return results } } return results }
ctx.Done() に対する select があるおかげで、呼び出し側がキャンセルしたときに関数がきれいに戻れます。net/http や database/sql も、内部で同じことをしています。
context に対する select が自然に書けるようになれば、日常的な Go のコードが頼っている並行処理の部分は身についています。Concurrency Fundamentals では、モデルの残りの部分をインタラクティブに学べます。
ステージ 4：CLI と HTTP サービスを作る
現役の Go 開発者の 73〜74% が実際にリリースしているのが、この 2 種類のプロジェクトです（出典）。フレームワークに触れる前に、それぞれ 1 つずつ作りましょう。
CLI。 flag パッケージは標準ライブラリに含まれています。普段使っている CLI の多く（kubectl、docker、terraform、gh）も Go で書かれています。最小限の CLI は次のようになります。
example.gogopackage main import ( "flag" "fmt" ) func main() { name := flag.String("name", "world", "who to greet") flag.Parse() fmt.Printf("hello, %s\n", *name) }
example.gogo$ go build -o greet . && ./greet --name=patrik hello, patrik
できあがるのは静的リンクされたバイナリで、ほかの人に渡せばそのまま動きます。ほかの多くのバックエンド言語では、ここまでたどり着くのにもっと手間がかかります。Building CLI Apps コースでは、サブコマンド、終了コード、出力の整形を扱います。
HTTP サービス。 net/http も標準ライブラリに含まれているので、HTTP サービスをリリースするのに Gin も Echo も必要ありません。
example.gogopackage main import ( "encoding/json" "net/http" ) func main() { http.HandleFunc("/health", func(w http.ResponseWriter, r *http.Request) { json.NewEncoder(w).Encode(map[string]string{"status": "ok"}) }) http.ListenAndServe(":8080", nil) }
これで、依存関係なしで動く HTTP サーバーができあがります。構造化ログ、ちゃんとしたルーティング（http.ServeMux は Go 1.22 で大きく改良されました）、テストを加えれば、API サービスになります。
ステージ 5：フレームワークより先にテストと標準ライブラリを学ぶ
go test は Go に付属しており、Go のテストの多くは次のようなテーブル駆動で書かれています。
example.gogofunc TestAdd(t *testing.T) { cases := []struct { name string a, b, want int }{ {"zero", 0, 0, 0}, {"positive", 2, 3, 5}, {"negative", -1, 1, 0}, } for _, tc := range cases { t.Run(tc.name, func(t *testing.T) { if got := Add(tc.a, tc.b); got != tc.want { t.Errorf("Add(%d, %d) = %d, want %d", tc.a, tc.b, got, tc.want) } }) } }
example.gogo$ go test -v ./... === RUN TestAdd === RUN TestAdd/zero === RUN TestAdd/positive === RUN TestAdd/negative PASS
アサーションライブラリもモックフレームワークも使っていません。Go チームの公式チュートリアルにはファジングの章（go test -fuzz）があり、testing パッケージは追加の準備なしでベンチマーク（go test -bench）に対応しています。Professional Go Testing では、テストがおもちゃのような例の規模を超えたときに必要になるパターンを扱います。
Go Developer Survey 2024 H2 では、「一貫したコーディング規約を保つこと」が 58% で最大の課題でした。テストがあれば、レビューで言い争うことなく、チームは一貫性を自動的に保てます。
ほかにしっかり学んでおきたい標準ライブラリのパッケージを、おおよそこの順番で挙げます。
errors、fmt：%wによるエラーのラップ、errors.Is、errors.As。io、os：Reader、Writer、ファイル操作。encoding/json：struct タグ、エンコーダー、デコーダー。context：上ですでに扱いました。net/http：上ですでに扱いました。database/sql：コネクションプーリング、プリペアドステートメント。pgxやsqliteは後から追加しましょう。log/slog：Go 1.21 で追加された構造化ログ。初日からlogの代わりにこれを使いましょう。
ステージ 6：Web フレームワークをいつ学ぶか（そもそも学ぶべきか）
公開されているロードマップの多くは、Gin、Echo、Fiber を序盤に置いています。Go チーム自身の入門資料は Gin を使っていますが、Effective Go と標準ライブラリのチュートリアルは net/http を直接使っています。公式の資料どうしでも本当に意見が分かれているところで、私たちは標準ライブラリの側に立ちます。
その理由はこうです。
net/httpはランタイムに含まれています。フレームワークは、Go をアップグレードするたびに保守しなければならない依存関係です。- 2025 年の調査では、「信頼できる Go モジュール」が不満の第 3 位（26%）に挙がっています。Go を始めたばかりの開発者がこの問題に初めてぶつかるのは、たいていフレームワークを選ぶときです。
- Go 1.22 での
http.ServeMuxの改良により、そもそも Gin が選ばれていたルーティング上の理由の大半がなくなりました。メソッドベースのルーティングとパスパラメーターは、今では標準ライブラリに含まれています。
フレームワークは、プロジェクトが本当に必要としたときに学びましょう。Gin と Echo は問題ありません。Fiber は net/http を完全に使わず fasthttp の上で動くため、ミドルウェアの互換性について独自の問題を抱えます。
仕事が「スタートアップ向けに JSON API を作る」なら、net/http と chi（薄くて Go らしいルーター）の組み合わせにしておけば、後から乗り換える必要はまずありません。
キャリアと年収の疑問：データからわかること（とわからないこと）
Go に絞って給与を分析した、厳密な公開データセットは存在しません。Levels.fyi の 2025 End of Year Pay Report は 5,000 社にわたる 245,000 件のデータを扱っていますが、言語別には一切分けていません（出典）。
実際にあるデータは次のとおりです。
- 2025 年の Stack Overflow Developer Survey では、Go を使っている人は回答者全体の 16.4%、プロの開発者では 17.4% で、プログラミング言語の中で 13 位でした（出典）。
- Glassdoor に自己申告された米国の「Go Developer」の年収は、2026 年 4 月時点で平均 $133,673 です。25 パーセンタイルは $105,368、75 パーセンタイルは $171,400 です。自己申告のデータなので、給与支払いデータよりも信頼性は低いと考えてください。
- Go Developer Survey 2025 では、回答者の 75% が 6 年以上のプロとしての開発経験を持っています。Go 開発者の多くは Go を始める前からバックエンドのキャリアを持っており、「Go 開発者」がその人の初めての仕事であることはまれです。
つまり Go は、ブートキャンプで覚えて 6 週間後に採用される、というタイプの言語ではありません。給与水準の高い企業で広く使われており（Google、Cloudflare、Uber、Datadog はいずれも Go を大量に運用しています）、バックエンドの経験に加える 2 つ目のスキルとして大きな強みになります。採用の面で 2 つの言語がどう違うかは、Go と Rust のバックエンド開発の率直な比較で取り上げています。
ロードマップとしては、給与データをもとに計画を立てる必要はないということです。ものを作る力を磨けば、仕事の選択肢は後からついてきます。
注意点：Go チームの公式ロードマップは存在しない
Go チームが公開しているのは、Tour of Go、Effective Go、言語仕様、ドキュメントの索引、そして開発者調査です。どれもロードマップではありません。公式のものに最も近いのは go.dev/learn のページで、学習リソースを初級、中級、上級に分けて紹介しています。
ネットで見かける「Go 開発者ロードマップ」は、この記事も含めてすべてコミュニティが書いたものです。GitHub で 18.4k のスターを集める Alikhll のロードマップリポジトリは、README に今も「in 2021」と書かれています。roadmap.sh の Go のパスは良い内容ですが、商用です。Medium のロードマップ記事は、ほとんどが互いの焼き直しです。
なので、この呼び名は疑ってかかりましょう。長く通用する道筋は、公式の Tour、次に Effective Go、次に CLI と HTTP サービスという順番で、並行処理は実際のワークロードを通じて学び、テストは進めながら書いていくものです。フレームワークは最後です。
よくある質問
Go 開発者になるにはどれくらいかかりますか？
すでにほかの言語でバックエンドの仕事をしているなら、3 か月ほど着実に練習すれば、本番環境で Go のコードをリリースできるようになります。ゼロから始める場合は 9〜12 か月を見込みましょう。その時間の多くは、構文よりもシステムの仕組みを学ぶことに使うことになります。
Go 開発者になるのにコンピュータサイエンスの学位は必要ですか？
いいえ。2025 年の調査は採用の指標として学位を追跡していません。また、Go は DevOps やプラットフォームエンジニアリングの職種で広く使われているため、運用の仕事や独学を経て Go 開発者になった人も多くいます。
初心者のうちに Gin/Echo/Fiber を学ぶべきですか？
最初に学ぶ必要はありません。まず net/http のサービスを端から端まで作り、ルーティング、ミドルウェア、リクエストのライフサイクルを理解しましょう。フレームワークは、プロジェクトに本当にメリットがあるなら後から追加しましょう。
Tour の後に Go を練習する一番の方法は何ですか？
現役の Go 開発者がリリースしている 2 つのもの、つまり CLI と HTTP サービスを作りましょう。次にテストと Dockerfile を追加します。これで、ジュニアレベルの Go の仕事の日常の約 80% をカバーできます。
2026 年も Go の需要はありますか？
はい。2025 年の Stack Overflow の調査では、プロの開発者における Go の利用率は 17.4% で、2024 年から 2 ポイント上昇しました。Go Developer Survey では満足度が 91%（「非常に満足」は 63%）で、これで 7 年連続です。
次のステップ
上で紹介したステージに沿ったインタラクティブな学習パスが欲しいなら、LevelUpGo の Go Fundamentals コースが、ツールチェーン、Go のイディオム、並行処理、標準ライブラリ、テストを順番に扱っています。無料プランでは基礎を学べます。Pro では、このロードマップが勧める CLI や HTTP サービスを実際に作るプロジェクトコースが利用できるようになります。