GoにGoすることにした。Django使いが次の言語を選ぶまでの思考プロセス
Django・React・AWSを軸にしてきたWebエンジニアが、次に学ぶ言語にGoを選んだ理由。Rustや他の候補を検討した思考プロセスと却下理由も含めてお話しします
コラム
kkm
Backend Engineer / AWS / Django
2026年、エンジニアを取り巻く景色が変わった
2026年3月現在、エンジニアとして最も意識すべき変化は、圧倒的にAIの台頭です。少し離れてメタバース、ブロックチェーンあたりでしょうか。
中でもインパクトが大きいのはAIがWeb業界の構造そのものを変えつつあることです。検索系サービスはAIに凄まじい勢いで食われつつありますし、2024年12月にはMicrosoft CEOのSatya Nadellaが「SaaSは死んだ」と発言して話題になりました。実際、2026年2月にはソフトウェア株から約2,850億ドルが消失するという事態も起きています。
もちろんForresterが分析するように「SaaSが死ぬ」というより「形を変える」のが実態で、Gartner予測ではSaaS支出は2029年に5,760億ドル規模に成長するとされています。完全に消えるとはさすがに思えません。でも、Webの領域が狭まってくるのは確実だと感じています。
私の今の技術スタックと、その課題
現在の私の技術スタックは(最近ガッツリ使ってるのは)こんな感じです。
- ▶ バックエンド: Django (Python) + Django REST Framework + Wagtail
- ▶ フロントエンド: React + TypeScript + Tailwind CSS
- ▶ インフラ: AWS (Terraform) + Docker + Kubernetes
- ▶ その他: PostgreSQL, Celery, Sentry, OpenTelemetry など
この中で一番力があるのはDjangoだと自認しています。ただ、日本でのDjangoの立ち位置はなかなか複雑です。Pythonは人気言語ですが、WebフレームワークとしてのDjangoとなると求人数はそこまで多くありません。日本市場では圧倒的にPHP (Laravel)やRuby (Rails)のほうがメジャーです。
Django自体は堅実なフレームワークで、JetBrainsのState of Django 2025でもグローバルでは安定した人気を保っています。でも「日本でDjango一本で食っていく」には選択肢が狭い。これは以前から感じていた課題です。
Webの先行きが怪しいなら、次はどこへ?
今の技術スタックを全部捨てる度胸はまだありません。でも、Webが縮小傾向にあるなら、次の活路を考えておく必要はあります。
一説では、AIによってWeb・モバイルの次のインターフェースはロボットじゃないかとも言われています。いっときは時計とかメガネとか言われていましたが、GoogleがIntrinsicをロボティクスの「Android」にしようとしているのを見ると、ロボットという方向には納得感があります。言語インターフェースで一番自然に動くのがロボットですからね。
一方で、そうそう落ちてこないのはゲームじゃないかとも思っています。UnityやUnreal EngineがAIでサクサク置き換わる未来はまだまだ見えませんし、ゲーム産業そのものの需要はしぶとい。そしてゲームバックエンドは、非同期処理や大量の同時接続を捌く必要があるGoの得意分野です。実際にRiot GamesはValorantのバックエンド全体をGoで構築していますし、ByteDanceはマイクロサービスの70%をGoで運用しています。
ゲーム開発者になりたいわけではありません。ただ、Goを覚えることで「ゲームバックエンドもいける」「クラウドインフラもいける」「CLIツールもいける」という活路が広がるのは魅力的だなと。
検討した選択肢と、却下した理由
Goに決めるまでに、いくつかの選択肢をテーブルに載せました。それぞれ却下した理由を正直に書きます。ただし、どの技術も優れたものなので、あくまで「今の私の状況で選ばなかった」という話です。
| 選択肢 | 魅力 | 選ばなかった理由 |
|---|---|---|
| Rust | 最速・最安全。Stack Overflowで最も愛されている言語。最適化コードでGoより30%+高速 | 学習曲線が急。今20歳で空っぽの技術スタックだったら選んでいたかもしれません。でも既存スタックを活かしたい今の状況では、LambdaのGo移行なども視野に入れるとGoに軍配 |
| Flutter (Dart) | クロスプラットフォーム開発。1つのコードベースでiOS/Android | モバイル系は「作りたいものが明確に定まっていないと学びにくい」というのがReactとFlutterを少し触った実感。何かをモバイル対応したくなったときに自然に覚えるくらいで十分 |
| Kotlin | Androidネイティブ + サーバーサイドKotlin | Flutterと同様、モバイルの必要性が今はない。サーバーサイドKotlinもJVM圏にわざわざ入る動機が薄い |
| Unity (C#) / UE (C++) | ゲーム開発。個人的な興味は正直一番ある | 今の自分の技術スタックから遠すぎます。興味だけで飛び込むにはリスクが大きい |
| PHP / Laravel | 日本での圧倒的な案件数 | 成熟した市場にこれから参入するよりも、広がりのある方向に投資したい |
| Java | エンタープライズの王様。案件は山ほどある | PHP/Laravelと同じ理由。既に確立された市場に後から入るより、自分の技術スタックを広げる方向で考えたい |
どれも素晴らしい技術で、状況が違えば別の選択をしていたと思います。特にRustとUnity/UEは「もし違う自分だったら」という意味で魅力的でした。でも今の自分には、既存の技術スタックを活かしながら選択肢を広げるのが最も合理的だと判断しました。自分自身、どちらかというとバックエンド寄りの人間で、Dockerとかインフラ周りも好きですしね。
GoにGoする理由
そんなわけで、GoにGoすることにしました。決め手になったポイントをまとめます。
「逃げ道が多い」は武器
Goの最大の強みは、どのシナリオでもそこそこ以上に戦えることだと思っています。Web APIもいける、CLIツールもいける、クラウドインフラもいける、ゲームバックエンドもいける。Go公式 Developer Survey 2025では開発者の55%がAPI・CLIの両方を構築していると回答しており、この「活路の広さ」は数字にも表れています。
変化が激しい今の時代、一つの領域に全賭けするリスクは高い。Goなら「Webが縮んでもこっちがある」「ゲームが来たらこっちもある」という保険が効きます。
学習コストが比較的低い
Goは言語仕様が小さく設計されているのが特徴です。Riot Gamesも「言語仕様が小さいので新しいエンジニアのオンボードが容易」と評価しています。2年3年かけないと戦力にならない言語を今の状況で始めるのはリスクが高い。その点、Goの学習曲線はありがたい。
既存スタックとの親和性
DjangoのバックエンドをいきなりGoに書き換えるつもりはありません。でも、たとえばAWS Lambdaで動いている一部のPython処理をGoに移行するとか、新しいマイクロサービスをGoで書くとか、段階的に導入できるのがいい。Docker・Kubernetes・Terraformといった今使っているインフラツールもGoで書かれているので、その周辺を深く理解する意味でも相性がいいんですよね。
数字で見るGoの現在地
Go Developer Survey 2025によると、Go開発者の満足度は91%。世界で約580万人の開発者がGoを使っており、プライマリ言語として使用する人は220万人と5年前の2倍に増えています。
一方でTIOBEインデックスでは2025年の7位から2026年1月に16位へ下落しました。ただこれは面白い話で、「安定しすぎて退屈だから」ランキングが落ちたという分析がされています。破壊的変更がなく、ハイプもなく、ただ静かにバックエンドを支え続けている。この「退屈さ」はむしろ、仕事で使う言語としては安心材料ではないでしょうか。
今日時点では、という但し書き
ここまで書いておいてなんですが、これはあくまで2026年3月時点での判断です。目まぐるしい変化の昨今、半年後には状況が変わっているかもしれません。
でも、だからこそGoだと思ったんですよね。腐りにくい。学習コストが高すぎない。逃げ道が多い。どの道に進んでも結構いいパフォーマンスを出せる言語。「今の最適解」として、これ以上の選択肢は私には見つけられませんでした。
もし自分が専門学校講師をもう一度やるなら、カリキュラムにはPython (Django)、JavaScript/TypeScript (React)、Go、AWSあたりを入れると思います。この記事で検討した候補たちもそれぞれ触れる価値はあるので、初学者の方がもし読んでくれていたら、選択肢のひとつとして参考にしてもらえたらうれしいです。
この記事のまとめ
変化の時代にエンジニアとして生き残るには、一つの領域に全賭けするより「逃げ道の多さ」を武器にするのも戦略です。私にとってのその回答がGoでした。あなたにとっての回答が見つかるヒントになれば幸いです。