実例に学ぶGoのアーキテクチャ - 「開発スピード優先」でGMOペパボが採用したのはMVC

• なぜ、MVCを採用するのか
• 「いま直面する問題」を解決するために、シンプルな構成を選ぶ
• MVCを採用し感じる課題
• ディファクトに従うのではなく、必要とされるものを選ぶ

2012年のバージョン1.0発表以降、Golang（以下、Go）はさまざまなサービスでの採用事例を増やしています。しかし一方で、Goを活用したサーバサイド開発における設計の大方針に関しては、どのような手法を採るべきか多くの議論が重ねられてきています。

例えば、DDD（Domain Driven Design：ドメイン駆動設計）やクリーンアーキテクチャ、レイヤー化アーキテクチャなど、さまざまな設計手法や概念が提唱されています。

では、Goを活用した開発に注力する企業では、どのようなアーキテクチャを採用しているのでしょうか。GMOペパボ株式会社ではホスティングサービス『ロリポップ！マネージドクラウド』のGoを用いた開発において、MVCモデルを採用しています。多様なアーキテクチャが提唱されているなかで、なぜ基本ともいえるMVCを採用しているのでしょうか。

その背景には「開発スピードを上げる」「Goらしいシンプルさを確保する」「いまある問題を解決する」という、極めて実用的な視座がありました。

なぜ、MVCを採用するのか

——まずは担当されているプロジェクトで、サーバサイドのGoはどのような設計になっているのか教えてください。

田中　私が担当しているのはホスティングサービス『ロリポップ！マネージドクラウド』内で、ユーザーさんが使っているサーバがリクエストを受けた際、構成情報を取得するAPIを作成するプロジェクトです。このプロジェクトではMVCを採用しています。誰でもすぐにコミットできる環境にすることで、新たなメンバーが「環境を理解するための時間的コスト」を削減し、開発速度を上げる、というのがMVCを採用している背景にあります。

——なるほど。他にもMVCを選んだ理由はありますか。

小田　2年ほど前、Goを使用したプロジェクトの開始当初、社内にGoのノウハウは蓄積されていない状態でした。一方で、過去Ruby on Rails（以下、Rails）で開発を推進していたこともあり、多くのエンジニアにとってMVCなら親しみがあり理解しやすいと考えたのです。

プロジェクトの立ち上がり速度を上げるために「設計は開発をしながら変えていこう」という意見にまとまり、設計変更を視野に入れつつ、まずはMVCでいくことになったんです。

——ディレクトリ構成はシンプルなMVCを採用しているのでしょうか。

田中　現状では/modelディレクトリにモデル層を、/controllerディレクトリにコントローラー層をそれぞれ配置していくMVCの基本的な形になっています。

——その他のGoを使用したプロジェクトでもMVCを採用しているのでしょうか。

田中　マネージドクラウド系のサーバAPIでは、ほぼ共通した構成になっています。ディレクトリ構成はMVCを採用しているプロジェクトがほとんどです。

小田　弊社では他プロジェクトチームとの情報共有に注力していて、ひとつのプロジェクトがうまく走りだすと、それに似た構成が自然と増えていきます。

同じ構成のプロジェクトが多ければノウハウを共有しやすいですし、別のプロジェクトに参加した際、構成をすぐに理解できるという利点があります。とはいえ、弊社ではMVCをディファクトとして設定しているわけではありません。あくまでプロジェクトの立ち上げ時のさまざまな条件に合致するアーキテクチャを検討した結果、MVCを使用しているんです。

「いま直面する問題」を解決するために、シンプルな構成を選ぶ

——DDDやクリーンアーキテクチャなどの設計を取り入れるという判断にはならなかったのでしょうか。

小田　Goの強みは言語のシンプルさにあると思っています。標準機能が強力なので、外部ライブラリの助けを借りる必要もそれほどないので、設計もシンプルに保てます。だからこそ、あえて複雑な設計にならないようにすることが大切だと考えています。

DDDやクリーンアーキテクチャーに関しては、その全てを踏襲するのではなく、参考にする程度にとどめています。DDDやクリーンアーキテクチャを実装するとなると、ディレクトリ構造など、基本に忠実に再現するというアプローチがあると思いますが、大事なのはコアの部分だと考えています。ルールがいくつもあると開発が複雑化してしまうことも予想されます。必要な部分を最低限決めて導入していくのがいいと考えています。弊社で大事にしている

• 循環参照に陥らないようにすること
• 新しくプロジェクトに入ってきた人がすぐに構成を理解できること
• テストがしやすいこと

こうした条件をクリアできれば、既存の設計に強くこだわることはありません。自分たちが直面している問題を設計によって解決できるかどうかを優先します。

田中　言語仕様に則し、Goらしくないことはやらないようにすることを心がけています。ついメタプログラミングぽいことしたくなりますが、書いた人しか理解できないコードはなるべく避けるべきです。

——Goらしさを大切にしているんですね。

小田　ソフトウェア設計で良いとされるものが必ずしもGoにあてはまるとは限らないので、まずはGoらしい書き方を理解し実践することに努めています。失敗しながら学んでいくものなので、ひたすら書いていくしかないでしょう。

複雑なコードを成立させるためには、チーム内での認識合わせが必要になり、どうしても開発スピードが落ちてしまいます。繰り返しになりますが、シンプルなディレクトリ構成で分かりやすいということが大事です。未来に起き得る問題を想定してアーキテクチャを複雑に考えるのではなく、まずは目の前にある問題を解決するための設計を優先したいと考えているのです。

——プロジェクトの途中で設計を変更しなければならない場合、労力が大きくなるというデメリットがありませんか。

小田　将来的に設計変更が必要になるか、といった予測を完璧に行うことはできません。予測できないことに備えた設計をしておく、というのはコストが必要ですし、新たな設計のためにチーム全員の習熟度を上げるのにもコストがかかってしまいます。構成は変わるものだという前提を理解しておき、テスタブルな設計であることを守っていく方が大事です。

テスタブルであれば、設計変更があってもバグのリスクを恐れず移行できる。あとは工数を確保すれば変更 / 改修に対応できるでしょう。先々のことを考えるよりも、いま直面している問題に労力を振り切った方がいいと考えています。

——設計を考える際に参考にしているものはありますか。

小田　golang-standardsというリポジトリにプロジェクトのディレクトリ構成例が書かれています。ここに書かれているものは非常に洗練されていて参考になります。

MVCを採用し感じる課題