“新アーキテクチャ導入”における失敗と成果　GMOは何を予測し、何を準備し、何に失敗してきたか？

スキルの習得支援に特化した「イネイブリングチーム」を結成

成瀬允宣氏：ということで、まず1つのサービスを打ち出すために、メンバーと一緒に作り始めました。まずはコンセプトの説明からですね。道は遠いです。

かつ、フレームワーク以外にさらに必要なものが何か、みなさん、思い浮かびますかね？　

ここに書いたとおりですが、メンバーはRDBを使って作るシステムではなく、今まで見たことがないアーキテクチャを習得しなきゃいけません。でも、我々、組織は生きているので現業は続ける必要があります。食糧がなければ死んでしまいます。なので現業をおろそかにはできません。

結果、新しい技術をキャッチアップするために、なにかしらの施策が必要だと私は考えました。

そこで、この本ですね。チームトポロジー、イネイブリングチームという、スキルの習得支援に特化したようなチームが必要だと考えました。なので、イネイブリングチームを結成しました。

当初は、本当に自分と、もう1人ですね、Aさん……これ、Aさん、仮の名前じゃないです、イニシャルです（笑）。Aさんと2人で始めました。先ほどのサービス開発を担当するメンバーを支援しましょうと。ただ、やはりAさんも初めて触るものなので、最初の2ヶ月ぐらいは、やはり学習フェーズでしたね。なかなかすぐには進みませんでした。

属人化の問題にはイベントストーミングで対応

さらに、まだ属人化の問題がありました。これをどうするべきか？　やはりドキュメントしかないんですよ。先ほどの問題は、ドキュメントがメンテされないからでした。であるならば、今度はドキュメントがメンテナンスされるようにしましょうと。

どうすればいいか？　なんでメンテナンスされないのか？　結局は、開発者に実利がないからなんですね。書くだけ面倒なだけ。しかもそれがメンテされているかがわからない。なので、既存の開発フローにドキュメントのメンテナンスを組み込んだほうが得と思えるような手法を入れましょう、という考えになりました。

そこで使ったのが、イベントストーミングです。私、いろいろなところでしゃべっているので、もしこの内容を詳しく知りたい方は、ぜひとも、そちらの「YouTube」を見てください。

これのいいところは、図とコードが一致するところです。図の付箋がそのままクラスになってきます。だから、図を描くことがコードのヒントになります。

さらにいいところは、そのコードを変えるとどこに影響するかがよくわかるところです。結果として、後発のメンバーも、図を見ることでシステム全体を理解することができるというのが、後からメンバーが追加されて成長していく上では、非常に有利に働きます。

というところで、さらに、説得力というのが、私は必要だと思いました。やったことない人の話を聞いてくれないんですね。なので、やったことある人の助力を得ました。

どういうことかというと、技術支援を入れていいという許しが出たので、1人、信頼するツテをたどって入っていただきました。壁打ち相手として、非常に助かりました。

フレームワーク選定・複数プロジェクト同時並行・意思疎通…プロジェクトで起こった失敗事例

それだけ準備をして、結果、どうなったのか？　まずは、失敗ですね。失敗には学びが多いです。見ていきましょう。みなさん、この失敗と同じ轍を踏まないでください。

まず、フレームワーク選定ミスをしました。何かというと、Akkaが有料化しました。完全に巻き込まれましたね。成瀬が選ぶフレームワークは、全部有料化されていく（笑）。

開発の途中だったんですが、1円も稼いでないのに、年間で2,000万払うことになっちゃうなという予測が立ちました。

「これはちょっと看過できん」ということで、プランBのAxon Frameworkを使いました。結果的に、ハレーションを生まずにSpringっぽいコードが書けたので、けっこうみんなも読みやすくなりました。

ただ、フレームワークを変更したことによって、せっかく作ったライブラリが結局使えなくなりました（笑）。メッセージブローカーも「Amazon Kinesisは使えません」となりました。どうしましょう？

Axon Frameworkと相性のいいものを探して、「やはりKafkaだな」と。なので、TopicとかSASLとかSCRAMとかよくわかりませんが、土日でがんばってキャッチアップしました（笑）。

続いて、複数プロジェクト同時並行。これ、非常につらかったですね。当初より、無理があると私は思っていたのですが、複数チームで同時にマイクロサービス化が始まったんですね。それを支援するのが私しかいないのに。相当厳しかったですね。やはり先行事例を作ることに集中するべきでした。

あと、もう1個、ちょっと観測しただけなんですが、逆コンウェイ戦略を目論んでチームの改変が起きたのを、僕は見ていました。ただ、やはり戦略は戦略なんですね。アーキテクチャを変更するという余力と実行力がなくて、ただ単純にもともとのかたちに依存したコミュニケーションが継続されるのを見ました。なので、ただチームを分ければいいというわけではないということは、非常にいい知見かなと思って、今回ご紹介します。

これも私の失敗ですね。先行事例を最初、人任せにしちゃいました。自分が持っているシステムじゃなかったので、その人にやらせたいという思いで始めたのですが、どうしても私としても、トンネルに手を突っ込んで、見ないようにしながらコードをいじるイメージになってしまって、非常に進捗が出なかった。なので、最初の先行事例はいったん引き取って、自分が書くことにしました。

最後ですね。成果を出すまでの期間です。この意思疎通もかなり失敗したなと思っています。（スライドを示して）ここに書いたんですけど、「あと歩く　人の道拓くは　険し道のり」と。非常にね、道を拓くのはやはり大変なことで、すごく時間がかかるんですね。

やはりアーキテクチャの刷新に伴っていろいろなものを変えたので、1年程度では収まりきらず、でも、会社というのはやはり1年でけっこう決算が始まったりするので、年度末頃にちょっと方針変更が下されてしまったんですね。

ただ、僕が引き取った先行事例が、あとわずかだったので、ここはがんばって主張して、サービスのアーキテクチャシフトの継続を死守して進めました。

アーキテクチャ刷新にどんな成果があったのか？

という感じで、今、失敗を赤裸々に語っていたんですが、なにか成果はあったのかと。

成果はありました。まず、イネイブリングチームが活躍しましたね。ほかのチームになにかを教えるチームですね。現在9名います。そのうち、技術支援をメインとしているメンバーは4名です。最初、僕とAさんの2人だったのが、今では、4人もいるわけです。最近は僕が行かなくても、そのメンバーが技術支援してくれるので、僕の手が非常に空いてきました。

あとは、マイクロサービス。一応、私の目論見どおりのアーキテクチャのシステムが完成して、Spring＋Axon Frameworkなんですが、見た目はほぼSpringで書けるので、やはり非常にハレーションが少ない。

かつ、どの粒度でコードを区切って、どうやってAPIをコールして、それを自サービスに紐づけて、というところのコードが、基本的に同じ書き方で書けるようになりました。これ、すごいですね。実装者によらないんですね。

あとは、イベントストーミングですね。本格的なマイクロサービスもやる場合、やはりイベントストーミング図がないと非常に理解が難しいです。結果として、自走しているメンバーを見てみると、まず図を作って、それを見ながらコードを書くという習慣を自然と習得しているのが観測できて、これは非常に良かったなと思っています。

Pub/Subの実現ですね。メッセージブローカーをKafkaにしたことで、非常にいいことが1個ありました。何かというと、Kafkaはそもそもイベントデータを無制限に保存するという選択肢があります。

（スライドを示して）この図のサービスAからサービスBにデータを伝えるのを、リードモデルを作ると言います。サービスBがデータを見たい時に、サービスAからデータを送り直す必要があるかなと思っていたのですが、メッセージブローカーに溜め込むことができるので、サービスAはサービスBを意識しなくとも、サービスBがデータを読み取ることができるようになりました。

アーキテクトの仕事とは「後から歩くメンバーのための道を拓くこと」

といったところで、まとめに入ります。

課題は解決できたのか？　システムの成長を阻害する要因ですね。仕様の複雑化。過渡期特有の難解なコード。技術スタックの相対的な老朽化。

仕様の複雑化は、先ほどのドキュメントですね。イベントストーミング図とか、それに伴うコードとの一致によって、だいぶ見やすくなりました、わかりやすくなりました。もちろん複雑な仕様はありますが、図に起こすことができます。

過渡期特有の難解なコード。こちらは、ある一定以上の書き方、一定のレールがあるのでそれに沿ってコードを書くことができるようになりました。

技術スタックの相対的な老朽化。もう全部一新しました。もちろん弊社のシステム全部をマイクロサービス化していくということで言うと、全工程ははるか長く、何年かかるんだろうな？　そもそも終わりなんてあるのか？　改善、改善、改善なので、基本的には終わりがないと思っていて、まだまだ道半ばではありますが、これらの対策が全部そろった感覚になっています。

というところでね、今回、1句詠んでみました（笑）。「あと歩く　道拓くは　険し道」と。アーキテクトの仕事って、後から歩くメンバーのための道を拓く仕事かなと思っています。それはすごく険しい道。そもそも道、ないですからね。

なのでみなさんも、ぜひとも、いろいろな準備をして、予測して、失敗して、成功を勝ち取ってくださいということで、今回の知見をみなさんにお話ししたく、アーキテクチャ刷新の現場でした。

私からのセッションは以上となります。ありがとうございました。