Node.js移行からGo選択までの開発現場で得た実践的な教訓

まずはこのステップを実行してみて - Node.jsからGoへの移行現場で即使える実践的な工夫

既存Node.jsコードを1000行単位で分割し、順番にGoへ書き換える
一度に全体を書き直す混乱やバグを7割以上減らせる
主要なnpm依存パッケージを5個以内に絞り込み、移植優先度を決める
無駄な自作や調査コストが大幅に抑えられ、導入速度が上がる
Goのミドルウェア設計は最初からGinなど既製フレームワーク利用で進める
`自作地獄`回避し学習負担と開発時間どちらも半減できる
`go test`によるユニットテスト比率を60%以上目標で維持する
動作保証とリファクタ時の安心感につながり失敗率も下げられる

Node.js依存からの違和感と転機、最初の選択

# なぜNode.jsからGoに切り替えたのか——最初は後悔した理由

ソフトウェア開発って、ほんとに変わるの早すぎ。まあ、それが面白いところでもあるんだけど、バックエンド技術を選ぶ時なんて、本当に迷路みたいで出口なんて見えない気分になることもある。うーん、思えば長い間、自分はNode.jsばっか使ってたんだよね。JavaScript中心でスケーラブルなバックエンド構築にはぴったりだったし、イベント駆動型アーキテクチャとか巨大なエコシステムのおかげで「これしかないじゃん」と思ってた。フロントもバックもJavaScriptで書けるから、そのまま流れ作業できちゃう感じが楽だった。

たださあ、話はちょっと脱線するけど…プロジェクトが大きく複雑になればなるほど、「あれ？」って感じる部分が出てくるんだよね。高負荷の時にパフォーマンス落ち込むし、大規模コードベースだとJavaScriptの動的型付け管理がカオスになり始めたりして（本当に混乱する）。npm依存関係のトラブルにも何度泣いたことか…。やっぱり一筋縄ではいかない。

そんなこんながあって、自分はGoという新しい言語に目を向けざるを得なくなった。でもさ、「静的型付け最高！」とか「高速実行！」とか言われても…実際移行してみると思ったより全然スムーズじゃなくて、一時期本気で「あーやらなきゃよかったかな」なんて後悔した瞬間も正直あった。でも今振り返れば、まあ結果的には良かったと思える。不思議だけど。

この体験談では、自分がどうしてNode.jsからGoへと舵を切ったのか、その過程でぶつかった困難や疑念（結構多かった）、そして時間をおいてようやく見えてきたメリットについて語ってみたいと思う。別にNode.js信者でもGo愛好家でもなくても、「バックエンド技術どう選ぼうかな」って考えてる人なら、このグダグダした経験談も何かしらヒントになる…かもしれない。

## Node.jsを捨てる決断をした理由

もう5年くらいかな？Node.jsはずっと自分たちのバックエンド屋台骨だった。本当にREST APIだろうがリアルタイムWebSocketサービスだろうがマイクロサービスまで、とにかく色々作ってきたし、ExpressとかNestJSとか有名どころのフレームワークにも随分世話になったよね。それだけじゃなくnpmパッケージも星の数ほどあるし（多すぎて逆につらいときもある）、フロント・バック両方でコード共有できちゃう点も地味に助かった。「生産性上げたいならこれしかない」みたいな勢いだった。

ただ……ユーザー数増えてアプリ全体が膨れ上がるにつれて、「Node.jsならでは」の壁というか限界点みたいなのも徐々に顔出してきた気がする。何回同じことで悩んだっけ？

## Node.jsの課題点

（続く）

パフォーマンス限界と型システムのジレンマ、npm泥沼もちらり

1. **負荷時のパフォーマンス**：Node.jsってさ、シングルスレッドでイベントループ式だからI/Oバウンドなタスクには結構合うんだけど、膨大なデータセットとか計算が絡むと突然「これもう無理じゃない？」みたいにサーバー側が息切れし始めるんだよね。ワーカースレッドもちょっと試した。うーん……ただ、思ったよりややこしくなるし、「全部解決！」とはいかなくて、不満は消えなかった記憶がある。ま、完璧なものなんて無いけど。

2. **動的型付けによる課題**：JavaScriptの自由度ってありがたい半面、大きくなると途端に型安全？守れなくなるし混沌としてくる感覚あったよ。TypeScriptを入れてみたこともある。でも根本的には違和感残ったし、ランタイムエラーは普通に発生するし、大規模リファクタリングなんて始めた日には何が起きるかわからない不安でそわそわしてしまう。ああ、自分だけなのかな、この不確実性。

3. **依存関係に関する課題**：npmの世界って豊饒というか…node_modulesの山盛り具合見て「もういい加減整理して！」って叫びそうになったことある人いると思う（私だけじゃないと信じたい）。ひとつ古いパッケージ紛れるだけでビルドごっちゃごちゃになるし、サードパーティライブラリの脆弱性――そういうニュース見るたびゾクッとしてしまう。「また対応増える…」とか思いつつも放置できないこの感じ。

4. **チーム生産性のスケーリング**：チーム大きくすると、新しい仲間来てもらうたびにTypeScript独特の癖とかリンティング云々とかNode.jsならでは注意点？いっぱい共有せざるを得なくなるよね。本当に明確な構造や統一感って維持難しい気がしてきた。自分でも説明途中で「あれ、それ説明したっけ？」となりながら進む毎日だった気がする。いや、本筋戻ろう…。

こういう諸々から代替案探す流れになった結果、Go言語にも興味持つ事例出てきたりしたわけでさ（ぼんやり調べ物して夜更かししたことも正直ある）。Goは最近頻繁に利用されているっぽくて、KubernetesだDockerだ有名どころでも採用例ちらほら見る。それからUberやTwitch等企業でも導入話上げられていたようだ、と聞いた記憶。一方でGoの場合はコンパイル済みバイナリ化による高パフォーマンス・静的型付け・最小限設計＆標準ライブラリ中心という特徴あり、それゆえ余計な依存減らせそうとも言われたりするんだよね。その意味ではNode.js周辺のお悩みに対抗策となり得そう―まあ実際現場によって意見割れる部分も多いと思いつつ、それでも選択肢として検討され続けている理由はそこかな、とぼんやり考えてしまった。

Goに魅せられた理由：速度と静的な安心感？でもそれだけじゃなくて

Go言語は2009年、Googleが開発したんだけど、その思想としては――ああ、ちょっと話が逸れるけど自分も当時何となく忙しくてさ、気づいたらもう10年以上経ってた。戻すと…シンプルさとかパフォーマンス、それからスケーラビリティを重視して設計されてるんだよね。正直、自分がこの言語にどうしようもなく惹かれた理由、挙げろと言われればいくつかあるんだ。ま、とりあえず順番に話すよ。

まずパフォーマンスね。Goはコンパイル型でネイティブバイナリを出せるから、その…Node.jsのインタプリタ型JavaScriptとは違う切れ味というか、速さを感じる場面が多い。高速動作、期待できるし、実際ベンチマークで大量リクエストでも低レイテンシだった。高負荷下でも割と安定してるし。それなのに時々妙に遅延することもあるけど──まあ、大体の場合大丈夫だったかな。

それから静的型付け。この型システムって、厳格なんだけど案外シンプルで。実行中じゃなくてコンパイル時にエラー出してくれる。うーん……これって地味だけどありがたい特徴だと思うんだ。本当に。でも油断すると「あれ？」みたいなバグも混じるのが現実でさ。それでもコードの手直しやすさには繋がった気がする。

並行処理についてはgoroutineとかチャネルとか……何だっけ？あっそうそう、それらのおかげで並行プログラミング苦手な自分にも扱いやすかった感触があるよね。ただNode.jsのイベントループとはまた違うアプローチだから全部良いとも言えないけど、多数コア活用できて並列処理向きって評価は納得できる部分も確かにあった。

あとミニマルなエコシステム。標準ライブラリって意外と幅広くHTTPサーバーや暗号化機能まで揃っていて──あ、この間余計な外部依存減らせてちょっと安心したこともあったな。依存関係管理の煩雑さって本当に疲れるから（いやホント）。それ考えると、この点は嬉しい要素なんじゃないかなぁ。

最後に開発者生産性ね。クラス構造無いし構文も必要最小限。その設計理念に従えば、新メンバーにも教えやすかったし、一貫性あるコードになりやすい…と思いたい！　でも皆が皆同じようになるわけじゃなくて、それぞれ癖が出ちゃうこともあるので完璧ではない。でもまあ、おおむね学びやすかったという印象かな。

Goこそ未来有望――そんなふうに思えて、自分はいきなりチームへ移行提案出してみたんだよね。不安半分だったけど。一部議論重ねた末、とりあえず重要なマイクロサービス（ユーザー認証API）の書き換えを試験的に始めることになった。本当は全部一気に変えたいくらいだったけど現実そんな簡単じゃないし……もし順調ならバックエンド全体へ徐々に拡大する予定だった。しかし案外その道程には予想外の課題という奴ら――急カーブみたいなの――後から次々見えてきて、本当に楽観視できない展開になったんだよね。でもまあ、それも今振り返れば悪くなかったかもしれない…。

移行初期の挫折：やる気はあるけど正直面倒だった話

## 成長の痛み：移行を後悔した理由

Goを触り始めて、最初の数週間はなんだかワクワクしていた。ああ、やっぱり新しい技術って、それだけで気分が高揚するもんだよね。`net/http`パッケージのおかげで、HTTPサーバーもさくっと立ち上げられたし、そのスピード感には正直びっくりした——いや、本当に。一時的に「これ最高！」と舞い上がったけど、ふと気付けば現実に引き戻されるというか…。認証APIはNode.js版より明確に1秒あたり10倍ものリクエストを処理できてしまい、メモリ使用量も今までと比べてぐっと抑えられている。…うーん、でも喜びって案外続かないものなのかな。深く踏み込むほど、新鮮味は少しずつ薄れていき、「あれ？これ、大丈夫？」みたいな違和感がじわじわ滲み出してきた。

## 1. Goのミニマリズムによる制約

Node.js界隈では、多様なフレームワークやミドルウェア、それにライブラリなんかがひしめいていて——まぁ便利っちゃ便利だったんだよね。複雑なシステムすら意外とスムーズに組み上げられる雰囲気がある。でもGoとなるとどうだろう。「意図的ミニマル設計」って言葉そのままだなと思った瞬間…まあいいや。本当にExpressのようなバッテリー同梱型フレームワークなんて存在しなくてさ、標準ライブラリ自体は強力なのかもしれないけど、自分が慣れてきた抽象化の層――いやそれこそ包容力と言うべきなのか、とにかく何となく物足りなく感じてしまうことも多々ある。

例えば：

<pre><code class="language-python">- **ルーティング**: Node.jsならExpressでデコレーターとかミドルウェア込みで簡単だったじゃない？でもGoの場合、自作ロジックを書く羽目になることが多かったりする。もちろん`gorilla/mux`など軽量ライブラリも選択肢にはなるけど、それでも「あれ…思ったより不便？」とか内心ぼやいてたりする。

- **ORM**: Sequelize頼みだったNode.js時代とは打って変わって、Goでは似たもの（GORMとか）はあるけどAPI自体それほど直感的じゃない印象だった。そのせいで生SQL書く頻度増えて、「余計手間増えてない？」と疑問符浮かぶ瞬間あり。

- **エラーハンドリング**: 明示的エラーハンドリング（`if err != nil`）ばっかり書いている自分…冗長というより単純作業になっているような虚無感。それまではtry-catch構文とかPromiseチェーン使えば済む話だったから楽できた気がする。

ミニマル設計に苦しむ日々、Express恋しさ全開で遠回りしたことも

Goのコードベースって、なんていうか、エラーチェックのボイラープレートがどんどん膨れ上がっていく現象があった。正直、「まさかここまで増えるとは…」と思ってたんだけど、この最小主義的な設計思想が、気付いたら既存の仕組みをまたゼロからこしらえる羽目になり、開発速度にも微妙に影響し始めた。まあ、その…うーん、Node.jsだったら1日で終わる作業なのに、Goだと1週間もかかったこともあってさ、その結果チーム内でため息交じりの不満がポツポツと漏れてくるようになっちゃったわけ。疲れるなあ。

## 2. チームにとっての学習曲線

大半の開発者はJavaScript畑出身で、とっくにNode.jsの非同期プログラミングモデルには慣れ親しんでいた。なのにGoでは並行処理（ゴルーチンとかチャネル）が新しいパラダイムとして目の前に現れて…最初は「おおっ」と思ったけど、それ自体は確かに強力。でも正直ね、競合状態やデッドロックという新しい厄介ごともついてきて、うまく備えていない状況だと並行処理コードをデバッグする難易度が急上昇した気がする。話は逸れるけど—いや、大事な話か—Chrome DevToolsみたいな非同期スタックデバッグ機能もNode.jsほどには整備されていなくて、そのへんもじわじわ効いてきた感じ。

Goの文法は見た目シンプルなのになぜか引っかかる場面も多かった。当時利用していたバージョンがGo 1.17だったせいでジェネリクス機能が存在せず、異なる型を扱うリスト処理みたいな単純タスクでも同じようなコードを繰り返し手打ちする必要が生まれた。ま、いいか。でもさ……map・filter・reduceみたいなJavaScript的流儀になじんだ人間からすると、この明示的なforループ記述にはなんとも言えない戸惑いと疲労感があったよ、本当に。

さらに、新規メンバーを迎えるときにも問題はいろいろ露呈したという…。この一件で余計に心配性になった気すらする。

ゴルーチンやチャンネルって…頭痛い？JS脳がぶつかった壁とか新人困惑祭り

jsの場合、ジュニア開発者ですら、まあ数日で何かしら貢献できることが多かったんだよね。でもGoとなると…いや、これは自分だけじゃなくて他の経験豊富な人たちもそうだったみたいなんだけど、イディオムとかベストプラクティスを理解するのに本当に数週間かかったケースがちらほら見受けられた。うーん、我ながら思い返すとさ、そのころチームの士気？もう正直低空飛行だった。ま、自分自身も「ああ、この選択は失敗だったかもしれない」なんて考え始めたりして…一度こういう迷いに陥ると、不安ばかり膨れてく。

Node.jsのnpmエコシステムってさ、不満もあるにはあるんだけど、一応その場で必要なものがだいたい手に入る感じなんだよね。JWTライブラリ欲しい？うん、npm覗けばきっとある。ロギングフレームワークはどう？テストスイートも？どれも揃っている。ただ、それに対してGoだと…成長中ではあるけどやっぱり選択肢が限られていて、多くの場合ユーティリティを自作したり、「これ大丈夫かな」って首傾げつつ未成熟なライブラリに頼ることになる。…あ、ごめん余談だけど、一度自作したログ周りのツールがバグまみれだったこともあったっけ。それで結局、不具合増えたり保守負担重くなる羽目になった。たとえばNode.js APIならOpenAPIジェネレーターを使ってクライアントSDKを問題なく生成できていた。しかしGoでは同等レベルのツール探しに時間取られるし、試してみても出力が不完全とかバグ混入とか散々な結果で…。そのせいでフロントエンド担当のみんなは手作業対応増やされて、「移行、大丈夫なの？」という不安まで出始めた。本当に面倒だった。

Node.jsでは認証・ログ記録・レート制限とか…そういう横断的な処理？ミドルウェア挟むだけで案外簡単だったんだよね。でも——いや、本題から逸れるけどさ、「ミドルウェアって要するに魔法か何か？」って初見時ちょっと勘違いしかけた。でも実際には設定項目ポチポチ追加すれば済むくらい楽ちんだった。それが当たり前になっていた分、新しい環境（Go）では「ここで言うミドルウェアはどこなの？」と心底戸惑った覚えがある。

エコシステム衝撃波、npm天国からGoツール砂漠へ　備品自作地獄編

Goの`net/http`パッケージには、正直に言うとさ、もともと「ミドルウェア」っていう明確な仕組みが無かったんだよね。あれ？自分で全部ハンドラーを繋げていくしかなくて、「え、これ何やってるんだろう…？」とかしょっちゅう思ったものだ。そのせいでコードはどんどん複雑になるわ、保守も面倒になるわで、もう溜息ばかり。実際`chi`とか`negroni`みたいなライブラリも試したけど、Expressみたいな単純さには到底及ばない感じだった。うーん…。この時点では、自分たちの選択がプロジェクトに悪影響を与えてしまったんじゃないか、と夜中に急に不安になったこともある。不満がチーム内でも広まってきてね、納期も徐々に遅れていく。なんなら、本当は手に入れられると思っていたパフォーマンス向上すら全然体感できなくて。「Node.jsへ戻した方がいいのかな」と本気で悩む夜もあったっけ。でもまあ、それだけじゃ終われないし…。

## 転機：どのように適応したか

ほぼ投げ出しそうだった時期―なんというか、本当にダメかもしれないと思った矢先―少しずつ状況は変わり始めた。不思議だよね。転機となった瞬間と言えばやっぱり「Go独自の哲学」に身を委ねる覚悟を決めたタイミングだった気がする。…今思えば大袈裟だけど、その過程で直面した課題一つひとつ乗り越えるために色々模索していった。それについて話すべきなんだろう、多分。

## 1. Goのシンプルさを受け入れる

Node.js的な抽象化をゴリ押しするより、「最小限主義」…いや、「質素」を受け止めることに舵を切った。理想的なORM探しは途中で疲れてやめて（ま、永遠に見つからなそうだし）、代わりに`database/sql`使って生SQL書き始めた。実はそれだけじゃなくて、型安全なクエリ生成ツールとして`s qlc`も取り入れてみたら意外とよかったんだよね。そのおかげでサードパーティ製ライブラリへの依存度が落ち着いて、データベース層もちょっと予測しやすくなった感じ？あとルーティングについては、自分たちサイズで十分だったので、大仰なの避けてごく薄いラッパーとして`gorilla/mux`使ってる。本筋から逸れるけど「ああ、この辺もう少しシンプルなら…」と思いつつ結局慣れたかな。そしてGo特有の冗長だけど明示的なエラー処理にも段々順応してきて、それ簡素化するヘルパー関数まで作っちゃった。当初は本当に「煩雑すぎ！」と思っていたけど、不思議と後になればその冗長さこそ可読性・信頼性につながる部分なんだと納得できるようになっていた。どうしてこうなるんだろう。

## 2. チームトレーニングへの投資

習得コスト問題――これは根深かった…。対策としてGoワークショップ開いたりペアプログラミングセッション増やしたり、と学習支援には割と力を注いできた気がする（余談だけど準備疲れる）。まあ、一朝一夕では身につかないという事実には誰も逆らえないわけで…。ただ地道でもそういう場のお陰で次第に知識共有が進み始めたところ、本当に助かった気持ちは強い。まだ完璧とは言えないものの、「昔より全然マシ」という実感くらいは手元に残っている。それでも油断するとまた元通りだから怖いんだけどさ…。

中間処理(middleware)のない虚無感、自作か既存利用か堂々巡り失速期

Goのコンサルタントを呼んで、Wait Groupってやつの使い方とか、共有状態の回避方法とか…あれこれ並行処理におけるベストプラクティスを学ぶことになった。うーん、正直最初は「え、本当に全部覚えられる？」って思ってたけどね。`go vet`とか`golangci-lint`みたいなツールが案外役立ってくれて、普段見逃しがちなミスも拾ってくれる。あ、そういえばパフォーマンスプロファイリングには`pprof`も導入したっけ。それでAPI最適化がかなり進めやすくなった気はする。まあ途中で関係ない話に逸れたりもしたけど…結局チーム向けにカスタマイズしたスタイルガイドまで作っちゃった。フォルダ構造やエラー処理の標準化なんかにも手を出して、新しいメンバーにも「こうすればいい」って指針を示せるようになったから、それがちょっと自信につながったかな。ま、いいか。}

{エコシステムが…いや、なんだろう、不足していると感じた場面では、自分たちで必要なユーティリティを黙々と開発する羽目になったわけだ。Expressから着想を得てGo用ハンドラーモデルに合う軽量ミドルウェアフレームワークも実装したし。えっと、その流れでOpenAPIジェネレーターも自作してみたんだけど、それのおかげでSDK生成の効率は明らかに上がった気がする。でもね、Node.js向けほど洗練されてるとは言い難い…そこは正直。でもnpm依存関係に縛られず運用方針も好き勝手決められるから、それはそれで良かったりする。不便さと自由さが共存してる感覚？まあ結局、自前管理の安心感に落ち着いたというか…。}

{Goコードベース最適化していく過程で、パフォーマンス面でも色々と利点が見えてきたんだよね。本当、認証APIでは20,000リクエスト/秒をサブミリ秒台レイテンシーで捌けるようになって驚いたし（Node.jsだと2,000リクエスト/秒だった）。それだけじゃなくてメモリ使用量も70%減少しちゃって、「あれ？同じハードウェアなのにサービスもっと動くじゃん」みたいな状況にもなった。その結果としてクラウド利用料もちょっと減ったっぽい？まあ細かい数字まで把握できてない部分あるけど。そしてリアルタイム機能でもGoの並行処理モデル活躍中。Node.js製WebSocketサービスからGo版へ移行した時、多数同時接続への対応力というか—goroutineによる柔軟性—それが意外と簡単だったことは新鮮な体験だったと思う。「まさかここまで違うとはね」と今更ながら実感中…。

発想転換・腕試し開始。独自道具開発～速度覚醒で空気変わるまでの日常断片

このコード、前のevent-emitter方式よりも…まあ、正直に言うとね、ずっとシンプルだったしメンテも楽になったんだ。いや、本当に。なんか昔は無駄に複雑で触るのも気が重かったけど、新しいやつは肩の荷が下りた感じ。あっ、ごめん脱線した。本題に戻す。

## 長期的なメリット

移行してから2年――もうそんな経ったんだっけ？最初は「あれ、ミスったかも」って後悔が頭をよぎった瞬間もあった。でも今となってはGoへの切り替えは正しかったと思える。不思議な安心感というか…。これから、その苦労以上に実感した長期的な利点について書くことにする。

まずね、**堅牢な信頼性**という話。Goの静的型付けとコンパイル時チェックのお陰で、Node.js時代によく遭遇したバグがほぼ消え失せてしまった。不意打ちみたいなランタイムエラーも激減したし、それにリファクタリング（言い換えると地味だけど大事な作業）もしやすくなってる気がする。ま、ときどき見落としそうになるけど。

それから**スケーラビリティ**の面でも良い意味で裏切られた。Go特有の性能とか並行処理モデルのおかげで、大規模トラフィックにも妙に強くなっちゃってさ。一番驚いたのはコアサービスを大改造することなくユーザー数10倍まで増やせたところだろうか。不安だった夜も今となれば笑い話…。

次に**メンテナンス負荷軽減**についてだけど……実はそうでもなくて、と一瞬疑う自分がいる。でも現実には依存関係が少ない標準ライブラリのおかげで保守作業そのものは本当に最小限ですんでるし、脆弱性対応とかパッケージアップデートにも時間取られなくて済むようになっている。

あとね、**チーム生産性**について。「全員Go覚えられる？」みたいなどこか他人事だった不安もあっさり解消された。言語自体シンプルだからコードベースにも自然と一貫性出て、新しく入る人でも1週間くらいですぐ役立つコード書いてたりして、自分でもびっくりするほどだった。「そんな簡単なの？」とも思う反面、不思議と腑に落ちる感じ…。

最後になるかな…いやまだあるな？まあいいや。**コスト効率**だ。そのお陰でインフラ費用まで抑えられてしまうとは正直思わず（半信半疑だった）。サーバー台数50%削減できちゃって、その結果毎月何千ドル分節約できている事実にはただ唖然としてしまうばかりなんだよね。

## 得られた教訓

もしこれを読んで「Node.jsからGoへの移行」をぼんやり考えている人がいたら、自分自身ちょっと伝えたいことあるんだよね。

<pre><code class="language-python">- **学習曲線を過小評価しないこと**: Goは表面的には簡素そうだけど、それだけ見て油断すると痛い目を見る。

2年後の景色：教訓・成果・今ならこうするかな…結論みたいな未完

チームがGoのイディオムや並行処理モデルを身につけるための時間、ちゃんと確保してほしい。ま、急いで進めてもロクなことにならないし。いや、それはまあ、どこでも言われてることだけどさ…たぶん意外と忘れがちなんだよね。

**ミニマリズムを受け入れること**——Node.jsの抽象化とか、そのままGoに持ってきたくなる衝動、正直ある。でもGoの強みはその「単純明快さ」だったりするわけで、うーん、ここはぐっと我慢すべきかな。ああ、今も自分に言い聞かせてる気分だ。余計な機能でゴテゴテしたくなるけど、本筋に戻すなら「シンプル命」なのよ。

**ツールへの投資**についてだけど、自分たちのワークフローにぴったり合うものを作るか探すか、それが肝心になってくると思う。Goエコシステムって案外選択肢少なくて…逆に自由度高いとも言えるかも？実際、自前で必要なもの組み立てる余地は残されてるし。ただ、その過程で迷走する危険性もちょっとあるから注意かな。

**小規模から始めること**——最初から全移行なんて無謀だし、とりあえず一つサービスだけPoC（概念実証）として書き換えてみればいいと思う。大規模なリスク負いたくないし。それに、このやり方なら、「これほんとに使える？」って疑問を現場レベルですぐ検証できるんだよね。…まぁ、一回じゃ足りない気もするけど、本題へ戻そう。

**チームとのコミュニケーション**も忘れちゃダメ。課題とかメリットとか、包み隠さず共有しておくことで仲間から理解得られるし。その結果、「思ったよりハードル高いな」とか「あれ意外と楽じゃん」みたいなリアルな声が出やすくなるから、困難にも何となく対処できたりするんだよ。不思議なものだよね。

## 結論

Node.jsからGoへの切り替え――技術リーダーとして過去イチ悩まされた決断だったらしい。最初はGo独特のミニマリズムとか学習曲線、それにエコシステムの物足りなさで、「ほんとによかったのかな…」って何度も考え直したって。でもトレーニングへの投資や、自社向けツール開発も地道に続けていった結果、不思議と状況が変わってきた。最近ではバックエンドが前より速くて信頼性高まったし、おまけに運用コストまで下げられている感じ。ちょっと驚いたよ。

こういう移行を検討している人には「途中で絶対後悔しかける瞬間がある」と伝えておきたい。でも、多くの場合その先には納得できる成果も待っている…ような気がする。万能薬じゃないとは思うよ、Go。でも、新しい環境へ適応する気持ちさえあれば、有効打になる可能性は十分ある。ただ最初何度か「あ～もう嫌！」ってなるのも自然だから、それすらプロセスと思っちゃえば良いんじゃない？……いやホント、自分にも言い聞かせてるところだしさ。