Goが15年でバックエンドの標準になるまで。偉大なる“退屈さ”が世界の開発文化を変えた理由

2009年の登場から15年以上が経過し、Goはかつての「新進気鋭の言語」という立ち位置から、今やクラウドネイティブ時代の「標準言語」とも呼べる確固たる地位を築きました。

言語としての定着期に入った今だからこそ、改めて問いたいことがあります。なぜ、Goはこれほどまでに開発現場に浸透したのでしょうか。そして、その独特な哲学が、私たちエンジニアの開発文化にもたらした影響とは。

本記事では、日本のGoコミュニティを牽引してきた松木雅幸（Songmu）さんにお話を伺いました。ご自身の経験をもとに、Goがエンジニアリングに与えた変化や、その本質的な価値について語っていただきました。

• keyboard_arrow_down ネガティブな第一印象はその後一変した。圧倒的なシステム適合性と開発者体験
• keyboard_arrow_down インフラ領域からWebの「ど真ん中」へ。予想を超えた普及の背景
• keyboard_arrow_down 機能の多様さよりも「シンプルさ」を。Goが貫く引き算の美学
• keyboard_arrow_down 進化はゆっくりと、着実に。GoはAIとの親和性も高い言語

――松木さんはこれまで、『みんなのGo言語 現場で使える実践テクニック』の執筆や100個以上のGo関連のOSS開発などを通じて、日本のGoコミュニティに多大なる貢献をされてきました。そもそも、松木さんがGoに注目したきっかけは何でしたか？

松木：私がGoを意識し始めたのは、Go 1.0がリリースされた直後の2012年頃です。当時、私は面白法人カヤックに在籍しており、同僚にtypesterさん（村瀬大輔さん）という技術的な審美眼に優れたエンジニアがいました。彼が「次はGoが来る」と推していたことがきっかけです。

当時のカヤックでは自社サービスの多くをPerlで開発していましたが、「今後もPerlだけを使い続けるのは厳しいだろう」と、次のフェーズで採用すべき言語を模索している時期でもありました。そうした中、社内の技術選定の議論でGoという選択肢に触れたのが最初の出会いでした。

――Goに対する、最初の印象はいかがでしたか？

松木：正直に言うと、最初は「かったるい言語だな」と感じました（笑）。当時は動的型付け言語での開発が全盛期でしたから。それらに慣れ親しんだ身からすると、Goは型定義や記述の制約などが多く、書くのを面倒に感じていたのが本音です。

しかし、その印象が劇的に変わったのが、はてなに転職し、サーバー監視サービス「Mackerel」の開発に携わったときです。「Mackerel」には各種サーバーにエージェントをインストールし、メトリクスを収集する仕組みがあります。ここで重要になるのが「監視対象のサーバーリソースを圧迫しない」ことでした。

そこで採用されたのがGoでした。Goでビルドされたエージェントは数メガバイト程度のメモリしか消費せず、アプリケーションへの影響を最小限に抑えられます。さらに、コンパイルすればシングルバイナリとして出力されるため、依存ライブラリを気にすることなく、ユーザー環境への配布やインストールも非常に簡単です。この「用途に対する圧倒的な適合性」を目の当たりにして、「Goはすごい」と私の中での評価が一変しました。

――他にも、Goで開発を進める中で感じたメリットはありますか？

松木：開発者体験の良さですね。Goは言語標準でフォーマッターや依存管理といったツールチェーンが整備されています。環境構築やルールの統一に時間を割くことなく、開発そのものに集中できる設計になっています。

また、当初は敬遠していた「型」の存在も、開発規模が大きくなればなるほど安心感に変わりました。「ビルドが通れば、ある程度正しく動く」という信頼感は、ソフトウェアの長期的な運用において重要だと実感しています。

――静的型付け言語にはJavaやScalaなどもありますが、それらと比較してGoが持つ独自の強みは何だと思いますか？

松木：最大の強みは、ビルド速度やランタイムの軽量さにあると考えています。

JavaやScalaは現在でも有力な選択肢ですが、JVM（Java Virtual Machine）上で動作するため、どうしても起動時のフットプリントが大きくなります。コンテナ技術の台頭や、マイクロサービス化の流れにおいて、より軽量で起動の速いランタイムが求められるようになった背景があり、そこにGoが合っていました。

また、コンパイルにかかる時間が長い言語だと、開発における待ち時間の割合が増えてしまいます。対してGoは、静的型付け言語でありながらビルドが一瞬で終わります。「書いては動かす」というサイクルを高速に回せるんです。これはスクリプト言語の開発リズムに近く、動的言語出身のエンジニアがストレスなく移行できる大きな要因だったと思います。

――登場から現在までの、Goを取り巻く環境の変化をお伺いします。当初はどのような用途で導入されるケースが多かったのでしょうか？

松木：初期のGoは、並行処理を活かしたマイクロサービスや、システム記述言語などの用途で採用されるケースが主だったと思います。安全かつ高速に動く言語として、まずはインフラに近い領域から浸透していきました。

――インフラに近い領域から普及が始まったのには、何か理由があったのでしょうか？

松木：いくつかの大きな転換点があったと思います。一つは、HashiCorpの動向です。彼らはもともと「Vagrant」などをRubyで開発していましたが、ある時期からGoへのシフトを進めました。その流れの中で、「Consul」や「Terraform」といった現代のインフラを支える重要ツールがGoで開発されるようになったんです。

さらに決定的だったのは、「Docker」や「Kubernetes」がGoで開発されていたことです。コンテナのデファクトスタンダードとなる技術がGoでつくられているという事実は、エンジニアコミュニティに強烈なインパクトを与えました。

――現在ではインフラツールだけでなく、Webアプリケーションのバックエンド開発にもGoが広く使われていますよね。

松木：正直に言うと、Webアプリケーション開発のメインストリームとしてこれほど広く受け入れられたのは、個人的には意外でした。

先ほど申し上げたとおり、Goはコンテナとの相性が良くデプロイも容易ですが、言語の機能が豊富というわけではありません。そのため、複雑なビジネスロジックを持つ大規模なWebシステムを「すべてGoでつくる」のが最適解なのかどうか、懐疑的な見方をしていたんです。

「コアとなる複雑なシステムは表現力の高い言語で構築し、周辺のマイクロサービスやツールをGoでつくる」という構成が、バランスの取れた選択だと考えていました。しかし蓋を開けてみれば、現在はバックエンドのすべてをGoで開発する企業も珍しくありません。この適用範囲の広がりは、想定以上の変化でした。

――なぜ、当初の想定を超えて、Webバックエンド開発の「ど真ん中」までGoが普及したのでしょうか？

松木：10年前を振り返ると、新進気鋭のサーバーサイド言語としてGoとScalaが二強のような時代がありました。しかし現在、Scalaは当時に比べると勢いが落ちており、一方でGoは標準的な選択肢として定着しました。この対比にヒントがあると考えています。

Scalaのような関数型言語のエッセンスを取り入れた言語は、非常に表現力が高く素晴らしいものです。しかし、高度な抽象化や表現力は、難解さにもつながります。チーム全体でそうした言語を使いこなし、保守し続けることは、多くの組織にとって予想以上にハードルが高かったのだと思います。

また、2010年代前半のWeb業界には「静的型付け言語への回帰」を求める渇望がありました。その際、スクリプト言語に慣れ親しんだエンジニアたちが求めていたのは、「文法がシンプルで、コンパイルが速く、安全に書ける型付き言語」でした。

Goは機能が少ない分、誰が書いても似たようなコードになりやすく、学習コストも低い。この乗り換えやすさと実用的な型安全性のバランスが、Web開発の現場が抱えていた課題にフィットしたのだと思います。

――「機能が少ない」といえば、Goの設計哲学において、「Less is More（少ないことは、より豊かなこと）」は中核となる概念のように思います。なぜ、この方針をこれほどまでに重視しているのでしょうか？

松木：Goの設計思想の根底には、「一つの目的を達成するための方法は、一つ（または少数）に限定されていたほうが良い」という考え方があるように感じます。プログラミングにおいて、同じ処理を書くために何通りもの構文やライブラリが存在すると、書く人によってコードのスタイルがバラバラになり、読み手への負担が増してしまいます。

また、ライブラリやモジュールの設計においても、機能のオーバーラップを避ける傾向があります。「このライブラリは、この課題だけを解決する」という単一責任の原則が徹底されており、いわゆる「全部入りの巨大フレームワーク」よりも、小さな道具を組み合わせて使うことをよしとする文化です。

これはまさに、UNIX哲学そのものですよね。GoはKen ThompsonやRob Pikeといった、UNIXやC言語をつくり上げてきたレジェンドたちが設計した言語ですから、彼らが培ってきた「シンプルさを保つための規律」が色濃く反映されているのだと思います。

――Goの特徴として、例外処理機構を持たず、戻り値としてエラーを返す仕様も挙げられます。この設計にはどのような印象を抱いていますか？

松木：非常にユニークであり、かつ合理的な設計だと思っています。特に画期的だったのは、関数が「多値（複数の値）」を返せるようにした点です。

Goの前身とも言えるC言語では、関数は一つの値しか返せません。そのため、処理結果とエラー情報の両方を扱いたい場合、引数にポインタを渡してそこに結果を書き込んでもらうといった、少々トリッキーな実装が必要でした。Goでは「戻り値の最後にエラー型を置く」というシンプルなルールで、これを解決しました。

――最近では、Result型やパターンマッチを用いてエラーを扱う言語も増えています。Goにはそういった機能を取り入れる動きはないのでしょうか？

松木：確かにResult型やパターンマッチは便利ですし、それらがあればより安全にコードが書ける場面もあります。しかし、Goの開発チームは最近の議論においても、エラーハンドリングの仕組みを大きく変えない判断を下しました。ここには、「関数型言語的なエッセンスを取り入れることへの慎重さ」が見て取れます。

それらの機能を導入すれば、表現力は上がりますが、代償として言語仕様が複雑になります。そうなると、コンパイル時間の肥大化や、学習コストの増大などのリスクがあります。機能が増えることで書く人によるブレ幅が大きくなり、コードも難解になりがちです。

Goはユーザーに対して、誰が書いても同じような「ある意味では退屈でつまらないコード」になるように強制します。でも、その「つまらなさ」こそが、チーム開発における可読性や、高速なビルド時間を守っているんです。

――システム開発において、Goを選択することの利点をどう捉えていらっしゃいますか？

松木：Goの最大の利点は「ゆっくりと、だが着実に進化している」点にあります。多くの言語やフレームワークは、機能の追加と廃止を繰り返します。そのため、過去に使えた機能や記法が、次のバージョンでは使えなくなったり、非推奨になったりすることもあります。

しかし、Goは「無駄なものをつくらない」という哲学が徹底されており、標準ライブラリや言語機能に追加されるものは厳選されています。極端な話をすると「5年間Goに触れていなかったエンジニア」でも、今のGoのコードを違和感なく読み書きできると思います。非互換変更によりコードを書き直さなければならないこともありません。これは長期運用において強力な特性です。

また、OSSのサステナビリティ（持続可能性）という観点も見逃せません。各種の言語やフレームワークの中には、残念ながら開発コミュニティに問題が発生して、進化が滞ってしまうケースもあります。ですが、GoはGoogleという巨大企業がバックボーンにあり、彼ら自身がシステム開発でGoを使い続けています。この事実は、技術選定をする上で大きな安心感につながります。

――最後に、これからGoを学びたいと考えている方、あるいは今Goを使っているエンジニアに向けて、メッセージやアドバイスをいただけますか。

松木：個人的な見解ですが、Goは「生成AI時代に最も親和性が高い言語」の一つではないかと考えています。Goは初期からgofmtによるコードフォーマットの統一を強制してきました。その結果、世の中に存在するGoのコードは、誰が書いても似たような構造になっています。これを学習したAIが出力するコードは、品質が安定しており、書き方のブレが少ないです。

また、Goが大切にしてきた可読性は、AIが書いたコードを人間がレビューする際にも役立ちます。AIが生成したコードが読みやすく、構造がシンプルであれば、私たちはそれが正しいかどうかを瞬時に判断できます。

GoogleもAI開発の最前線にいますから、今後もGoとAIの親和性を高めていくでしょう。学習コストも運用の負担も低く、かつAIとも相性が良い。エンジニアの「道具箱」に入れておいて、決して損はしない言語だと思います。

取材：中薗昴、池田恵実
執筆：中薗昴
編集：池田恵実
撮影：山辺恵美子