こんにちは。2019年に初々しい記事を書いていた山本です。今でも元気にモノタロウで働いております。
この記事では、社内カンファレンスで私が業務部門向けに行ったプレゼンテーションを基に、マイクロサービス化に踏み切ったエピソードを紹介します。モノタロウがGoとprotobufで進める爆速マイクロサービス開発とそれを支えるプロセス と被る部分もありますが、同じ内容でも今回は易しめに解説していますので、空き時間にでもさらっとお読みください。
--
--まさか共通化されてないなんて
2022年の暮れに、こんな改修依頼を受けました。私はプロジェクトの開発リード担当でした。
出荷目安アイコンとは、当社商品が何日で出荷されるかを表すアイコン群のことです。
正確な値を表示するように工夫していますが、モノタロウでは自社在庫を含む様々なパターンの出荷があり、当時拡大が進んでいた「サプライヤ在庫連携」では特に出荷目安の変動が激しかったため、日付の元になるデータを商品部のメンバーが毎日手作業で書き換えていました。
その負担をなくすために自動化しよう、と。
ええ、やりましょう。
--
↓「当日出荷」のアイコンでの例。「翌日出荷」「翌々日出荷」「ｎ日以内出荷」も出荷目安アイコンの仲間です。
きっと簡単です。
だって、このように多くのページで表示されている以上、アイコン生成処理が共通化されてないわけないのだから。
どこかにあるひとつのAPIを改修するだけで、要求は満たせるはずでしょう。
--
・・・・本当に？
--
--
ソースコード読んだ。
--
そうなんです。当時、出荷目安アイコンを表示する処理は、各ページ各システムで独立していました。
てんでばらばらのAPIを使い、APIによってはデータソースすら違う。データソースによっては情報鮮度すら違う。そんなちぐはぐなパッチワークが実態でした。
--
--ひとつのシステムに便利機能がてんこもり
また、出荷目安アイコンを表示するには、はじめに在庫状況を参照する必要があります。欠品中に「当日出荷」と表示すると嘘になってしまうからです。
だというのに、あちこちのページ・システムが好き勝手に在庫状況を参照しており、改修は困難を極めました。
たとえば「バスケットの内容」画面を作るだけのはずの処理に在庫状況の確認処理がガッチガチに組み込まれていて、どこに改修を施せばいいか慎重に調査しないといけなかったり。
商品情報だけをインデックスすることに特化しているはずのバックエンドシステムが実は在庫状況を独自に参照していて、そのシステムの責任範囲に照らし合わせて専用の要件を作らないといけなかったり。
--
レガシーでモノリスなシステムにありがちなことですが、
長い年月をかけて少しずつ多機能にしていった結果、各システムが責任範囲を超えた機能を満載にしてしまっている、というわけですね。
その迷宮っぷりは、もはや人間が理解できるレベルを超えていました。
かくして、2022年暮れに受けたこの依頼。出荷目安アイコンの日数を、モノタロウ＋サプライヤの在庫状況を勘案しながら生成するようにし、商品部の手作業をなくすことができたのが2023年9月でした。半年どころか、半年以上かかりました。
--
--こんな大変な思いをするのは私が最後でよい
たくさんのAPIを改修せねばならず、
APIによっては他所のチームに改修を依頼せねばならず、
そのチームの今期やることが確定する寸前だったので大急ぎで調整をかけたり・・・
プロジェクトの序盤、やらないといけないことが多すぎて絶望している私を、横で励ましてくれる尊敬する上司の山﨑さん（この記事で登場）は、今回はもう仕方がないものとして、先々を見据え、二度とこんな困難が起きないように打てない手はないかと考えていました。
2022年夏、米国で同じ事業を展開する兄弟会社であるZOROを、我が社の精鋭のエンジニアが訪問。
そこで、在庫状況表示の仕組みを改善するAVL（Availabilityの略称）というシステムを紹介してもらったそうです。
↓ZOROから共有された資料の1ページ。素敵な理念が書かれています
ZORO訪問時にはモノタロウには関係ない話だと思っていたものの、
サプライヤ在庫連携という画期的だが複雑な仕様が現れた今となっては、お客様との “promise” を守るために、在庫状況の把握にのみ責任を持つかわりに正確でリアルタイムな在庫状況を返却することを保証するサービスが必要なのだと、我々も気づかされたのです。
多種多様なシステムは、独自に在庫状況を参照するのをやめて、AVLにその役目を一任しレスポンスを活用するようにしよう。
こうして、大規模(モノリス)なアプリケーションから、サービスを切り出して独立させるのだ。
そう、 マイクロサービス化です。
--
--マイクロサービス化した！
どんなメリットがあったかは以下のスライドの通りです。
開発スピードがどれほど上がったかというと、マイクロサービス化が完了したシステムのデプロイリードタイムは、
まだモノリシックなシステムのデプロイリードタイムと比較すると、8分の1から9分の1の短さです。
もし、出荷目安アイコンの表示改善プロジェクトより前に、在庫状況のマイクロサービス化が完了していたら、開発に半年以上かかるなんてことはなかったでしょう。
--
いかにしてマイクロサービス化を迅速に進めたか？
どんな壁があってどう乗り越えたか？ について気になる方は、
モノタロウがGoとprotobufで進める爆速マイクロサービス開発とそれを支えるプロセス tech-blog.monotaro.com
マイクロサービス化するならリビルドで！ビジネスロジックをGoで書き直してわかったことtech-blog.monotaro.com
をあわせてお読みください。
--
--おわりに
・・・といった内容を、2023年夏の社内カンファレンスで発表しました。
最後はこのようなスライドで締めくくりました。
プロジェクト進行当時、マイクロサービス化が急務であるという点は全社的に認められており、その半期の全社OKR（会社全体で優先して取り組むべき目標を指す）にも含まれていました。よって、他のプロジェクトからリソースを借りたり、優先度判断で下がってもらったりと、多くの協力を得て進んでいました。
協力者のみなさんが「全社OKRだから仕方なく」ではなく、前向きに協力してもらえるといいなと思い、自分の学びの発表とともに、身をもって知った重要性を訴えました。
--
↓ 発表当時のSlackの実況スレの様子。絶望に共感してくれるみなさん
--
↓ 応援してくれるみなさん
発表は好評で、現社長の田村さんにも、「山本さんの言葉で、なぜマイクロサービス化が大切なのかが腹に落ちました。やはりその裏にある、なぜこの取組をすすめるのかという言葉の芯の強さの大切さを改めて実感しました」とおっしゃって頂き、とても光栄でした。
AVLは在庫状況にのみ責務を持つシステムですが、他にも、出荷情報にのみ責務を持つシステム、バスケットの中身への操作にのみ責務を持つシステム、といった具合に、次々とサービス分割が進行中です。
システム改善をスムーズに進めるコツは、易しい説明で重要性を伝え、社内全体を味方につけることなのかもしれません。
私の発表を通じてマイクロサービス化がいかに大事かをみんなに分かってもらったことが、スムーズな展開への貢献になったならば幸いです。
小さく小さく切り出していって、数年後にはどれほど高い開発生産性になっているか、今から楽しみですね！
--
モノタロウでは随時エンジニアの採用募集をしております。この記事に興味を持っていただけた方や、モノタロウのエンジニアと話してみたい！という方はカジュアル面談 登録フォームからご応募お待ちしております。
