仕様の複雑化、過渡期特有の難解なコード、技術スタックの老朽化…　システムの健全な成長を妨げる要因に対する基本戦略

アーキテクチャ刷新の現場における取り組みと成果を発表

成瀬允宣氏：みなさん、こんにちは。GMOインターネットグループでデベロッパーエキスパートとして活動しています、成瀬允宣と申します。本日はよろしくお願いします。

私、所属はGMOインターネットグループ株式会社で、システム統括本部に所属している一般のプログラマーではありますが、私からお送りするお話は、「アーキテクチャ刷新の現場」で、ここ数年……2年ほどですかね、アーキテクチャを刷新する現場で一番前を走っていたので、その現場のお話をしようかなと思っています。

非常に苦労して、やっと花開いてきたところなので、今日は、何を予測して、何を準備して、そして何を失敗したのか。そんなお話をしようかと思っています。よろしくお願いします。

今日のお話の流れですが、全体としては4つのテーマですね。ことのあらましと、次に課題の予測ですね。そして準備したもの。次にそれを受けて、失敗。実際、何を失敗したのか。そして成果をお話ししようと思っています。

アーキテクチャを刷新した理由

それではさっそくいきましょう。まずは、ことのあらましですね。なぜアーキテクチャを刷新したのかというお話をしていこうと思います。

やはり組織は、成長し続けなくてはなりません。チャーチル（ウィンストン・チャーチル氏）の言葉のとおり、「成長はすべての矛盾を覆い隠す」。成長していると、不満を押さえつけるわけではありませんが、結局癒されるという事実があります。それは開発組織も同じで、成長し続けなくてはなりません。

ただ、我々はプログラマーなので、やはり成長させるべきは、もちろん個人の能力でもありますし、さらにシステムを成長させなくてはいけません。ということで、我々が成長させるものは何かというと、システムです。

システムが成長し続けるために必要なことをちょっとひもといていきましょう。

システムの成長を何が阻害するかというと、（スライドを示して）ここに書いたとおり、仕様の複雑化。最初の仕様って、非常にシンプルなものができているんですよね。その仕様がビジネスの要求を受け取ることによって、どんどんどんどん複雑化していく。コードで言えば、if文が追加されていくようなものです。これが非常に複雑になっていく原因の1つです。

さらに、みなさんもご経験があると思いますが、忙しい中でとにかく作らなきゃいけない。動くものが正義だ。そうすると、やはり過渡期特有の読みにくいコードが後々成長を阻害していきます。

最後ですね。技術スタックの相対的な老朽化。それこそ弊社、GMOインターネットグループ株式会社には、15年以上前から継続しているサービスがごろごろあります。当時のフレームワークをみなさんご存じですかね？　みなさんが知らないものがけっこう多いと思うんですよね。

仕様の複雑化・メンバーの入れ替え・ドキュメントの不確実性…システムの成長を阻害するものたち

それぞれを、さらに詳しく掘り下げていきましょう。

まず、仕様の複雑化について。サービスの成長に伴う機能追加ですね。10年、20年とサービスを継続すると、「あっ、こんな機能があるんだ」というものがよく出てきます。

続いて、メンバーの入れ替えですね。サービスを開発するメンバーは、どんどん入れ替わっていきます。同じサービスから人が離れていく。そしてやはりその分、新たなメンバーが入ってきます。

メンバーの入れ替えが発生すると何が起きるか。例えば、仕様について若手の子が先輩に聞きました。そうすると、「あっ、そこは誰々さんが詳しいよ」って（先輩が）言うんですね。その若手の人は、誰々さんを探しにいきます。あそこの部署にいるらしいぞと聞きにいきます。そこにいるマネージャーに聞いてみました。「誰々さんいますか？」「退職したよ」「なるほど」と。よくあることですね。

あとは、ドキュメントの不確実性ですね。ドキュメントは、やはり仕様を書いておくのに必要なものですが、これがどうしてもメンテナンスされにくい。

もちろん、ある程度有意義なものになってはいますが、実際読んでみると、「あれ？　ここの部分はもう古いよね。今は前と違うぞ」ということが起きてきます。それを不確実と言っています。これはかなり、システムの成長を阻害してしまいます。

続いて、過渡期特有の複雑なコードですね。これがいいか悪いかはわかりませんが、自分が書いたコードが、なぜかほかのプロジェクトに移されているのを見たことがありませんか？　僕はあります（笑）。

うまくいったサービスのコードを移してきて、自分のところで使おうということがよく起きます。

書いたコードが、ほかのプロジェクトに侵食していくんですね。本来のサービスの仕様に合っていない複雑なコードが、そのまま持ってこられることがあります。

あとは、チャレンジコード。誰しも初めてはありますよね。私も初めてコードを書いた経験があります。当時のコードは、自分でも正直どうかなと思うコードです。でも、そこに「忙しい」が加わるとどうなるかというと、コードレビューをすり抜けてしまうんですよね。

あまりきちんとコードレビューがされずに、「これはどうなんだろう？」というコードが、結局プロダクトのコードになってしまうことがあります。

最後に、やはり動いているのが正義という言葉が強すぎて、リファクタリングの選択肢を取れないことがあります。「もう動いているところを直したほうが、ほかの機能のためにはいいんだけど、どうしようか？」「いや、そこは残しておいて別のコード書きましょう」。似たようなコードが2つできます。これは、かなり成長を阻害します。

あとは、先ほど書いた技術スタックですね。今となってはMVCフレームワークがもう当たり前ですが、20年前はMVCがありません。弊社の技術スタックで、例えば「ASP.NET」、Microsoftですね。こちら、かなり古いものだと1.0が……ここに書いてありますね。2009年3月。2009年3月、今から何年前だ？　14年前。私が就職した頃ですかね（笑）。

さらに「Struts」に至っては、2001年ですね。22年前。まだ学生ですね。なるほど。そんな時期の技術スタックが使われていることもあります。

あとは、弊社にはVBというものを使っているところがありました。VBと言うとみなさん眉をひそめるのですが、20年前はマジョリティでしたからね。今私たちの使っているVBって、要するに「.NET Framework」なので、言ってしまえばC#とほぼ一緒ですね。ちょっと構文が違うだけです。

なので、老朽化しているなという印象はあまりありませんが、パッケージマネージャーというのが登場したのが、実は「npm」で、npmが2010年。10年前ですね。サービスはその頃もうとっくにローンチされていました。つまり、今パッケージマネージャーがないプロジェクトもいっぱいあります。今のマジョリティのイケイケの技術スタックではないことが相当ありますよね。

あとは、「健全な成長は健やかなシステムから」ということで、今のものをなんとか排除して、健やかな、成長しやすいシステムを目指しましょう。そうすると何をしなきゃいけないのか？

成長しやすいシステムを目指すために考えたこと

まず考えたこと。ほとんどのシステムは、モノリスと呼ばれるものが多い。とにかく巨大なシステムなので、それを小さな単位に分解することが必要だろうと。

なぜかというと、理解の範囲を狭めないと、それを理解するのにすごく時間がかかってしまうから。理解するのが難しいものの修正は難しいからですね。

さらに、密結合なシステムを疎結合にしましょうと。これも同じですね。複数のサービスで依存関係が密結合してしまうと、変更の余波がもう一方のサービスにどれだけ波及するかわからない。なので、互いを疎にしましょうと。

最後に、無意味なコードの多様性ですね。コードは、プログラマーに委ねられて、それぞれにすばらしいコードを書いていただければいいと思いますが、ほとんど同じようなことをやっているのに、なぜか多様性が。コードが随所で違う。こういった無駄な部分をなんとか改善して、書き方をある程度統一しましょうと考えました。

逆コンウェイ戦略を採用　望ましいアーキテクチャを考えた

そこで何をしたいか。結局はこれを達成することでチームの機敏性を確保したかったんですね。というわけで、さっそく、何を予測して、準備したのか。お話ししていきましょう。

基本戦略として、コンウェイの法則と逆コンウェイ戦略というものがあります。コンウェイの法則、これは何かというと、組織、チームのコミュニケーション構造を真似た設計が生み出されるというものです。

それを逆手に取って、逆コンウェイ戦略は、チームと組織構造を私たちが求めるかたちに進化させることで、望ましいアーキテクチャを作ることが得られるんじゃないかという考え方です。これをメインに考えました。

望ましいアーキテクチャがわからない、そこに至るためのチームのかたちというのが見えてきません。というわけで、まず望ましいアーキテクチャを考えました。

当時流行っていたのは、やはりマイクロサービスでした。今回の要件にこれがけっこう合致していると思いました。どういうところがというと、サービスのサイズが小さいです。かつ、サービスが互いに疎です。この特性が、先ほど申し上げた目的に合致しているなということで、この方向に進んでみましょうということで調べ始めました。

この時、私が手に取った本がいくつかあったのですが、その中で特に役に立ったものが、この2冊ですね。『マイクロサービスパターン』と『モノリスからマイクロサービスへ』。

実は、前者は社内でも読書会をやったりしました。『マイクロサービスパターン』を読む中で、特にこのCQRS+ESという考え方と、Pub/Subのアーキテクチャがどうもゴールであるというのが、私の中で腑に落ちた部分でした。

かつ、今動いているシステムもあるので、そのシステムから新しいシステムに移行するための手法として、『モノリスからマイクロサービスへ』という本が非常に役に立ったんですね。なので、みなさんも、考えるならぜひともまずここを読んでいただきたいです。

目指したのは“Pub/Subのかたち”

その上で、目指すものはPub/Subのかたちだということがわかってきました。どういったものかというと、（スライドを示して）ここに書いた図のとおりですね。図、ちょっとわかりにくいですかね。サービスAに、データをイベントで持たせます。そのイベントをそのままメッセージブローカーですね、「Kafka」や「MQ」など、そういったところにすべてメッセージを投げていきます。

投げられたメッセージを、好きなタイミングでサービスBが読み取る。そうすると、サービスBはサービスAに依存しないんですね。サービスAのデータを勝手に使っているから。ちょっと言い方が悪いですけどね。ということは、疎になる。

サービスAはサービスBのためにデータを作っているというよりも、サービスAの結果が使われてサービスBが作られているので、互いの関係性が疎になります。これは非常にチームの成長を阻害しないかたちになってきます。

そこで、「じゃあ、実際にマイクロサービス、今のかたちに進みましょう」とは言っても、やはりPoCしなきゃいけません。Proof of Concept。フレームワークに依存しちゃいけません。

どういうことかというと、もちろん最終的には依存しますよ。ただ、やっていく上で、このような新しいこと、最悪「フレームワークを使っちゃ駄目です」と言われちゃったら困っちゃいますよね。なので、自分でできるようになにか作らなきゃいけない。

ということで、一般的なMVCに比べてマイクロサービスに関しては、誰もいない。ということは、私が先駆者にならなきゃいけません、ということで、自分で知るために実際にCQRS+ESのコードを、ピュアなライブラリを使って動くように作ったりしました。

もちろんただそれを使ってもらうのは非常に難しい。なぜならば、便利なツールがないから。それを全部作っている暇はないので、なにかフレームワークがないかなということで見ていくと、主に4つですね。「Akka」「Axon」「Eventuate」「Spring Boot」＋「Spring Cloud」。

それぞれ、メリット・デメリットがありますが、結局、最初はAkkaで進めました。Scalaですね。最終的には、Axon Frameworkというものを使っています。これについては後ほど少し触れます。

さらに、CQRS+ESを実現するために必要なライブラリは、やはり自分で作っていきます。最初は、Amazonさんの「Kinesis」というメッセージブローカーを使おうとしたんですね。そのためのライブラリが必要なので、実際に開発をしたりしました。

あとは、先行開発事例ですね。やはり道を切り拓かねば誰もついてこられません。せめて獣道でも用意しないと、誰も歩いてこられないんですね。なので、事例をとにかく作るのが先決です。

（次回へつづく）