実例1 ドメインとアーキテクチャを繋げて削減
丹哲郎氏：では実例の話、お待ちかねの話をしていこうかなと思います。まず1個目ですね。株式会社RECLOさんというところで、ここは「Refresh your closet!」というスローガンのもと、CtoCでブランドのアパレル、ファッショングッズを出品してそれを買い取って別の人が格安で買うという、売るのと買うということができるプラットフォームを運営されている会社さんです。僕らはここで月30万円ぐらい削減したという事例があります。
「何をやったの？」という話でいうと、まずはバックアップ戦略の見直しです。これは普通にマネコンでできることなのでどちらかというと王道なのですが、王道的なところでいうと、アセットをアップロードする処理のアルゴリズム改善をやったんですね。
（スライドを示して）具体的に何かというと、これはめちゃくちゃ簡易的に図式したやつですが、ファイルが3つあったら、普通はそのファイルの3つをループして3回、1枚ずつアップロードするわけですね。
わかりやすいように脚色しているので真実ではないのですが、イメージは、その3つのファイルを3回ループする中で、それぞれが3回アップロードして（合計）9回アップロードしているみたいな箇所がロジック上あります。
そうすると単純に通信料もかかるのと、同じファイルを重複してアップロードすると履歴がその分いっぱいできるので、履歴の保存代もかかっていました。それを単純に各ファイル1個目のみとしました。
みなさん「へぇ」と思うかもしれないですけど、これでドメインとアーキテクチャを繋げることができたのかなと思っています。
「どういうこと？」というと、これがSKUの数しかアセットがないECサイトだったら、あまり意味がないんですよね。だって画像をアップロードするのは新しいSKUが増えた時だけじゃないですか。しかし、彼ら（のサービス）でいうと中古のものを出品するという行為があるので、そうすると同じSKUに見えるかもしれません。
例えば、今日僕はISSEY MIYAKEのジャケットを着て来たのですが、同じISSEY MIYAKEのジャケットでも、違う人が出品したら「そのジャケットは美品なのか良品なのか」を示すために、その時の状態を写真で撮ってアップロードすることが、誰かが出品するたびに起きるわけですよね。
なので、トランザクションの数だけ×3とか×4とか。いろいろなアングルで撮るので、アセットのアップロードがそれだけいっぱい起こるというところが、結局アルゴリズムとして若干効率良くない。コストに響いてくるはずです。
こういうことは「このプロダクトが何をしているもので、だからここのアルゴリズムの……」というほど上等な話ではなくて、「普通にアップロードの処理が効率が悪かったら、その分コストにこういうふうに跳ねてくるはずだよね」ということが読めていないと、「ここがボトルネックだよね」というところまで、ソースコードまでブレイクダウンして探していくのがけっこう大変だと思います。
みなさんのプロダクトで言ったら、どういうところのチューニングをするのがコストや負荷の軽減のところに関わってくるのかということは、やはりドメインとそれを支える裏側のインフラやアーキテクチャがつながって考えられていないとできないと思うので、これは1個の良い事例だったのかなと思っている次第です。
実例2 大きなところでも工数をかけて削減
2個目です。事例は何個かあります。これはSUPER STUDIOさんという、「ecforce」というカートシステムのBtoBtoCサービスを運営している会社さんとやったやつです。（スライドを示して）これは2023年6月に1回、弊社オフィスで対談のイベントをやった時のものです。
もともとは「Shopify」さんみたいな感じで、サインアップして、新しいショップというかページを開設したいお客さんたちがいて、彼らがこのSaaSを通じて自分のショップを開設して、そこに訪れる「お買い物したいよ」というお客さんのトラフィックは、ショップのオーナーのサーバーではなく、SUPER STUDIOさんのecforceのサーバーに行くような仕組みになっていました。
いわゆるBtoBtoCですね。マルチテナントではなくてシングルテナントになっていたので、この図にあるとおり、ショップの数だけ新しいインスタンスが必要になってしまっていました。
聞いてみれば当たり前の話なのですが、ドメインやリクエストしてきたURLに対して動的に接続する先のデータベースを切り替えようという、いわゆるマルチテナント化をやって、それによって、必要なインスタンス数はスペック的に充足していれば、1ショップ1インスタンスなんて当然いらないよねということで大幅に削減できた事例になっています。
Railsなので想像つく方はいるかもしれないですがやることはめちゃくちゃあって、initializeの中で実行される処理を、今までは起動時に設定とかいろいろ読み込めば良かったのですが、毎回動的に読み込み直すように処理を書き換える場所がいっぱいありました。
あとは、ものすごくいっぱいテナントがあって……。当時は200個で、今はたぶん4桁あるはずです。もともとシングルテナントだったショップをマルチテナント環境に移行していくために自動化する処理や、「そこのダウンタイムは大丈夫なの？」みたいな話を僕と先方のCTOで地道に半年ぐらいかけてやりました。
効果としては、1個のショップにかかるコストが80パーセント減ったという話があって、コスト的にはめちゃくちゃインパクトがあったようなプロジェクトでした。
結局シングルテナントの環境でEC2がめちゃくちゃかかっているのがBillingを見たらわかるのですが、そこから先は何もできないんですよね。
「EC2にかかっています」「あぁ、そうですか」となっちゃうところを、「でもこれって、そもそものアーキテクチャをマルチテナントに変えたらいけるよね」というふうに、「いや、そんなことはわかっているんだけど」ということをちゃんと半年ぐらいかけてやりきるのが大事かなと思っています。
コストに対して向き合うという場合、「それで1個のショップにかかるコストが80パーセント減りました」となったらぜんぜんペイするわけですよ。
なので「コストを減らしましょう」と1回腹をくくったら、「大きいところを普通にやろうよ」ということを、ある程度工数をかけてでもやるのが非常に大事かなと思っています。「なんでコストを下げる必要があるの？」という話は、再三言ったとおりで、将来に渡って直接利益が増えるからといった話になっています。
実例3 経営層に近い人が音頭をとってみんなで削減
他にも事例があります。（スライドを示して）これはピクシブさまですね。ピクシブさんがAWSのイメージはあまりないかなと思うのですが、オンプレが有名ですよね。ベニヤ板サーバーというのが非常に有名だったかなと思います。
「Palcy」さんという女性向けの漫画アプリの事業部はAWSを利用されていたので、そこに一緒にコスト削減に入らせていただいた事例になっています。
（スライドを示して）ここでやったことは、リクエストのデータ通信料を減らすことでした。もともと1MB超えのレスポンスだったやつが400KBぐらいに減ったので、サイズとしては減らせました。これはあとで聞いたら「そうなんだよね。了解」という感じなんですが、リクエストの中で実際にはフロントエンドで使われていないデータが含まれていることを調査して、そこを枝刈りしていった感じです。
なので、やったことで言うと、バックエンドでOpenAPIの仕様を書き換えて、バックエンドのロジックも普通に変えて。フロントエンドのiOSとAndroidの2つがあったので、それぞれで「このフィールド使っていないよね。使っていないけどカウンターには書いてあるから、それはない扱いにしないとダメだよね」みたいなものを1個1個やって、それぞれを全部修正してデプロイすることを通してコスト削減を実施したという事例です。
結局僕がAPIもiOSもAndroidも全部自分でやったんですが、みなさんの組織で実際に「明日やりましょう」と言ってできるかは、けっこう大変なのかなと思っています。当然iOSの部署とAPIの部署が分かれている可能性もあるし、APIからしたら「一応返しているけど、これはiOSから使われているんだろうか」なんて知る由もないわけですよね。
なので、実際にある程度の大きな組織で実現するにはどうしたらいいかというと、やはり全員が考えるということなのかなと思っています。
「コストがすごく高いね」「ここのレスポンスって1MBも必要なんだっけ？」となった時に、「いやいや、実はうちって返してきているレスポンスの4割ぐらいしか使っていないんだよね」とか言われたら、「あぁ、じゃあそれ消そうよ」となって、バックエンドの人はこれをやって、フロントエンドの人はこれをやってというのがあります。
そこに対して彼らも忙しくて、結局ロードマップをいろいろやっていかないといけないのですが、「いやいや、コストって早く下げたほうがいいよね」ということを、CTOの方や経営層に近い人が自分で音頭をとって全員に考えさせることができれば、それだけ直接的に利益が増えて、会社としてもハッピーになるということができるのかなと思っていて、これはすごく象徴的な事例だったのかなと思っています。そんな感じです。
コスト削減はお祭りムードで総力戦を
最後に振り返りいきます。めちゃくちゃ情報量があったと思うので、ゆっくり振り返ります。まとめです。
月額のコストは早く安くなればなるだけ利益がめちゃくちゃ増えるので、とてもハッピーです。早く成果が出たら出ただけ事業インパクトが大きいし、しかもどうせ安くするんだったら小手先で安くするのではなくて、根本的に安くしたほうが事業インパクトとしては大きいです。
（スライドを示して）なぜなら、点線のスケールでいくはずのところが、絶対値としてのコストも減るし、サービスのスケールに伴ってコストが増えていくという傾きをゆるくすることができるんだったら、時間積分でその分事業インパクトが出てくるので、どうせやるんだったら根本的に安くしたほうが絶対にいいです。
「根本的に安くするにはどうしたらいいの？」ということで、全員が参加しましょうということです。どうせやるんだったら楽しくやってほしいし、いろいろなアイデアが出れば出るほどコストがその分減らせたらとてもうれしいので、モブコスト分析というやり方がとてもいいのかなと思っています。
モブコスト分析をどうやったらいいのかというと、全員が考えるということです。CSの人もそうだし、QAの人もそうだし、フロントエンドの人もバックエンドの人もアプリの人もインフラの人も、全員が考えることですね。
あとは、ドメインとアーキテクチャを繋げることです。ドメインという言葉の意味はいろいろあるのですが、それぞれの職域という意味でのドメインです。フロントエンドだったらフロントエンドのドメインがあるし、バックエンドだったらバックエンドのドメインの領域がある。あとはビジネスのドメインです。
「このビジネスはどういう特性があって、だからどういうアクセスパターンがあるから、どこがボトルネックになるであろう」という勘どころは、やはり内製でふだんそのドメインと向き合っているみなさんだからこそできることなのではないかなと思っているので、これも非常に大事です。あとは、どうせやるんだったらElephant in The Roomと向き合いましょう。
「コスト削減をやりましょう」と言って、まず手堅く足元で減らせそうなところで結果を出すのは非常に重要だし、我々もそれをやっているので別にそれを否定するつもりはありません。
しかし、先ほどの図みたいに、そもそも傾きを変えていくとなると、やはりどうしてもBilling上はEC2とかRDSみたいな、「まぁ、了解。でもそれって中身何だったっけ？」みたいな、そんなに簡単に分析できないようなところに現れてくるものなのかなと思っています。となると、そこにタックルして、それぞれの知を集結してケモノ道を探してデリバリーしていく覚悟が必要になるのかなと思っています。これはみなさんも身につけていただくといいのではないかなと思っています。
ただ、どうせやるんだったらお祭りでやってほしいので……。これがあらためて最後のツイートタイムになるのですが、コスト削減はお祭りムードで総力戦をやってほしいです。「やってほしい」って何ですかね。やるといいんじゃないかなという提案をしたいなと思っています。
僕らも実際に成果報酬というかたちでお客さまの環境をコスト削減して、その分のお給料をいただくみたいなところをやっていて、毎日本当に楽しくてしょうがないです。
「なんで楽しいのか？」というと、全員で「ここって、こんなことできないかな？」とか「なんだったらre:inventで言っていたこの新しいやつを使ってみたらもっと安くなるんじゃね？」みたいなのを日々みんなで話して、「それできそうじゃん！ やりましょうよ！」と、お客さんともチームになって総力戦してお祭りでやっていく。
今日メディア・ヴァーグさんとのリリースがnoteに出たのでどこかで見てほしいですが、コストのグラフがもともと300万円ぐらいだったやつを60万円とか40万円ぐらいにしたこととかがあったんですね。その時もグラフがふんってなって、気持ちいいですよね。なんか「あぁ、整うわぁ」って感じです。
（会場笑）
僕は毎日夜のデイリーの時に、「ちょっとメディア・ヴァーグさんのCost Explorerを1回見ようぜ」と言って画面を映して、「あぁ、気持ちいい」みたいなことをやります。気持ちいい。とても楽しい。数字に出てくるのはやはり報われるし、楽しいですよね。
なので、それをちゃんと楽しんでやってほしいし、そういうムードを作るのはやはりCTOやVPoEや技術責任者の人が、主体的に「いや、これは儲かるし、やろうぜ」とやってもらえると、非常におもしろいイベントになるんじゃないかなと思っているので、みなさんの社内でもモブコスト分析やコスト削減祭りを、ぜひ開催してもらえると、とてもいいんじゃないかなと思っています。
最後に宣伝のコーナーです。毎日楽しくインフラコスト削減代行サービスをやっています。なんと診断に関しては無料で行っていて、「お客さんの環境をこのぐらい減らせそうですよ」ということを言った上で、実際にお客さんが「こいつらは頼もしそうだから、なんかやらせてみるか」と思ったら施策を実行して、浮いた分から（報酬を）いただきます。
成果報酬なので実質無料でコスト削減できるという、非常に夢のようなスキームの所業をやっているので、コストに困っている方々がいたら、ぜひご縁をいただければと思っています。
同時に、僕らと一緒に働くエンジニアの方々もめちゃくちゃ募集しています。僕らの組織は基本的には「もともと受託やっていたよ」とかクライアントワークをやっていた人はなかなかいなくて、事業会社で責任を持つ立場で技術的な意思決定をしてきたテックリードの方や、もともとCTOやVPoEだったという方が、「この知識をいろいろなところで使ってみたいな」ということで入ってもらうことが多いです。
なので、次なる成長企業の開発組織のために、エンジニアのためのエンジニアチームを作っているので一緒に働く仲間を募集しています。
宣伝が多いですよね。最後です。みたいな僕らがいろいろなハックについて自慢し合うような会を、2024年2月22日、にゃんにゃんにゃんの日にやります。定期的に弊社オフィスでやっているので、みなさんもぜひ足を運んで、興味があれば、淡々と話ししてみたいなとかがあれば、お話ししてもらえればと思っています。
以上となります。今までご清聴ありがとうございました。
