「キャパシティ」「柔軟性」「コミュニケーション」「費用」…　新規SaaSを創る際にインフラが考えること

インフラにとってSaaSを創ることをどう捉えるか

柏木達仁氏（以下、柏木）：今日は楽楽労務をテーマに「新規SaaSを創る際にインフラが考えること」ということで、私、柏木が発表いたします。よろしくお願いします。

簡単に自己紹介なんですが、私の名前は、柏木達仁といいます。右下に娘の写真があります。まあ最後ですし、ちょっとこんな感じでリラックスして、聞いていただければと思います。

2010年に、新卒でto Bのシステムインテグレーション会社に入って、パッケージやSaaSに関わっていました。2017年にラクスに入社して、もう4年ですね。入って、主にAWS系のサービス、blastmailや楽楽労務を担当しています。よろしくお願いします。

ではちょっとテーマが抽象的な内容ですが、インフラにとって、SaaSを創ることをどう捉えるかというところ。どっちかというと、やっぱりSaaSなんで、創るだけでは価値は出ません。お客さまに使っていただいて、初めて価値が出ます。

なので、本当の勝負は、やはりお客さまが増えてからが勝負だろうなと。けれども、先ほどの岡本さんの発表じゃないですが、負債を抱えないように、初期の想定と準備はとても重要になってきます。

次に、Webシステムの構築がゴールじゃないですよ、というところですね。下記を常に考慮したSaaSの提供が重要ですと書いていますが、この「常に」っていうのは、初期バージョンをローンチしてからだけではなく、その後も常に「こういう変更する時ってキャパシティ大丈夫なの？」と。「柔軟性大丈夫だよね」みたいなことをしっかり考えながら変化させていくのがとても重要と思っています。

この後のコンテンツは、このキャパシティ、柔軟性、コミュニケーション、運用、費用、最後にちょっとおまけみたいなとこも書いていますが、ここに沿ってお話ししていきたいと思います。

楽楽労務のミッションとキャパシティ

その前に楽楽労務のミッションです。一言一句違わずではないんですが、人事労務業務に関わる人のストレスをゼロにする、というところを掲げています。もちろん人事労務担当者だけじゃなくて、手続きをする一般の従業員の人や、そういった人の手間をなくしていきましょう、と。

というので、さきほど岡本さんから発表があったUIなどの使いにくさも、バージョン負債的には解消していきますよという話、そういうところも大事にしているサービスです。

こんな中で、やはりお客様が増えていくので、キャパシティ面でいうと、何がどうなったらどこをスケールさせていくのかは、決めておくのがとても重要だろうなと思います。

やはり、いきなり「ここ増やしたいです」って言ったときに、アプリケーション的にはちょっと不都合があったり、キャパシティはしっかり考えとかないと、柔軟性が非常に低くなるというところですね。

ただまあ、やはりどれぐらいのスピードで伸びていくかや、実際アプリケーション作っていた時に、どこがボトルネックになりやすいかは、SaaSであるがゆえにけっこうわかりにくい、難しいのかなと思います。なので、少なくとも、どこをスケール化させるかを決めておくのは必須かなと思います。

下でちょっとお絵描きしていますが、楽楽労務の場合、アプリケーションECSで動いていて、ここは少なくともスケールアウトしていきましょう。データベースの分はRDS使っていますが、これはスケールアップでいきましょう。これぐらいは最低限やっぱり決めておくと、後々安心ができるかなと思います。

過度に柔軟性を求めない

次に「柔軟性」っていうワードが出ましたが、これに関しては、極力シンプルにすることが重要かなと思います。やっぱり最初から通信の関係線が多いなど、そういうシステムになっていると、何か変更する時に、新しいものを追加したい、もしくは分割したいという時に非常にミスが出やすい。またはやはり確認に時間がかかってしまうので、シンプルにしていくことが一番いいと思います。

なのですが、ここもバランスの問題で、過度に柔軟性を求めない。SaaSをやっていくと、経験が長い方はわかるかと思うのですが、実はけっこう初期から変わっていない部分が多くあるのは、多々あることかなと思います。

なので、そういった部分はやっぱり経験とか「この部分って将来変わるのかな」「いやもうほぼここは固定だよね」っていう部分は、そんなに過度に柔軟性を求めていかない。Infrastructure as Codeで、コード化するといった時にも、「変わらないんだったらそこまでコードに落とし込む必要ないよね」というジャッジもしっかりしてかなきゃいけないな、というところですね。

私の経験上ですが、この下の5つはけっこう変わりやすいかなと思います。アプリを分割する。こういった機能のところはLambdaに逃がそう、など。下の楽楽労務の場合は、これは最初から入れているんですが、WAFを入れるとか。

メール送信部分ですね。最初は利用者が少ないので、単一のメールサーバーにJavaアプリから投げればいい、としていたところが、やはり利用者が増えていくとボトルネックになって。メールサーバーから従業員や利用者が届くところには、遅延が発生してしまいます。

あとログですね。先ほど岡本さんからも、「ログのところはこういうふうにサーバーに溜めといて、日付で検索しやすくするようにしました」みたいなお話がありましたが、さらにサービスが拡大すると、よりアクティブにログをウォッチしていく必要があります。

例えば「あ、この時間帯、このへんのURLアクセスが多いのね。じゃあ次ちょっとキャパシティ的にはそこを分割していかなきゃ」とか。そういうアクティブな方法でログを分析していくこともよく発生するかなと思います。

あと監視ですね。最初は死活監視やログ監視ぐらいだったものが、だんだんレイテンシーの監視になったり。もしくは1個のバッチの所要時間の監視になったりと。

こういった5項目が、比較的変わりやすい部分かなあと思います。

情報はオープンなほうが自律的に動きやすい

次にコミュニケーションですね。これはテーマとして挙げたんですが、正直、企業やそのチーム、組織が目指す方向性など、行動ポリシー次第だろうなというのが、私の今の結論です。

ただ、やっぱり情報はオープンなほうが各々が自律的に動きやすい。先ほどの、また岡本さんの話ですが、こうやってスプレッドシートに残したり、事業側と調整したり。情報は最初からオープンであるがゆえに、やっぱり動きやすいなと思っています。

今、楽楽労務の場合は、と書いていますが、全職種のチャットにもインフラが参加するんです。メインがアプリケーション運用担当者と、インフラ運用担当者のチャットですね。あと営業動向も、週1ぐらいでは共有されているので、キャッチアップしたり。あとは定例ミーティングはしっかりやっています。個別テーマがあれば随時やっています、というようなコミュニケーションです。

もしかしたら、1つのすごいサービスで、その企業としてやっていく場合には、トップダウンの場合もあるかなと思いますが、われわれラクスは、社員ももうすぐ800名近くの組織になるので、どちらかというと、現場が能動的に動けるほうが、スピード感が速く、各サービスが成長していきやすいので、オープンなコミュニケーションが多いです。

リストアップして自動化

あと運用面ですね。正直、サービスができた当初は、そんなに自動化の準備もできておらず、簡単な運用の量が多いことは、けっこう普通にあったかなと思います。

2個目ですが、リストアップして自動化をする。これが最短かなと思います。1人だけで抱え込むのは赤信号と書いていますが、とはいえ、さすがに運用の量が多いから、誰かしかできないみたいなところは、その人が倒れたら、やはりサービスの提供をし続けることができないので、しっかり汎用的な自動化をすることと、その実行の仕方もしっかり残していきましょうというような感じです。

楽楽労務の場合は、とまた書いていますが、実際けっこう自動化は進んでいて。週で考えたら多くて数時間ぐらいかなと読んでいます。もちろんサービスが新しいので、イレギュラーな運用はあります。このへん1個1個、自動化を意識しすぎて毎回すべて自動化していくというよりも、発生頻度も含めて、型にはめすぎない、スピードを落とさない運用を心がけています。

あと、体制的には2名います。やることをリストアップして自動化することは、7割ぐらいはできているんじゃないかと思います。

理想なのは逓減的な費用増

次、費用の部分。ちょっとこれも抽象的な図ですが、クラウドだとリニアに伸びやすいかなとは思います。直線的な、という意味ですね。お客さまが増えていくと、それだけリソースも使って、かつ処理スピードが落ちないようにって考えると、どうしてもリニアにはなっていきやすいですね。

逆にオンプレは、1回キャパシティを確保して、そのままいって。また次、そろそろ増やさなきゃねってガツっと増やしてなので、階段的な費用にはなりやすいかなと。

理想線でいうと、一番右の、逓減的な費用増で、上には昇っていくけど、お客様が増えてもより傾きが一定にならず、下がっていくような増え方を目指してやっていくのがとても重要だと思います。

そのへんを「じゃあどうやるの」というのが、実際のところエンジニアの腕の見せどころかなと思います。単純に機能は使えるだったり、アプリケーションエンジニアの人にこういうのが欲しいですって言われたらそれを技術的に提供するだけじゃなくて、インフラエンジニアとしてはこのあたりは費用をどうしていくのかなど。

ビジネスサイドと話したり、もしくはアプリケーションエンジニアと「ここはちょっと不便だけど、こうすることで費用的にはこれぐらい抑えられるんだよねー」みたいな話をしたりして。「それぐらいだったら妥協点か」というところを探っていくのが、けっこう重要かなと思います。

クラウドとオンプレミスの使い分け

最後のコンテンツですが、おまけですね。けっこうクラウドとオンプレミス、ラクスの場合オンプレミスのサービスがけっこう多くて。どういう使い分けですか、みたいなところは、採用していても聞かれることがあります。

ラクスの場合、というのもあるんですが、そもそもクラウドとオンプレミスは、「簡単さ」と「自前でなんでもできる」のトレードオフかなと思っています。

クラウドだと、大概準備されているアドバンテージが大きいかなと思います。何を言っているかというと、あんまりパッと選んでも、大失敗しにくい。オンプレミスに限って言うと、相乗りできるのだったら、クラウドとあんまり大差ないかなとは思うものの、一切使っていない時、初期設計をけっこう間違えると大失敗しやすいです。

物理的に電源容量の設計をしたり、増えてきた時にそれで足りるのか、電源のウォッチみたいなところも。そういったことを考えると、オンプレミスの運用をイチからやってくのは、けっこうハードルが高いかなという意味で、クラウドの手軽さがあると思います。

ウォッチして会話したりしながら前向きに変えていく

最後にまとめです。SaaSを作り続けて提供するということは、けっこう変化との戦いが大きいです。なのですが、インフラエンジニアをされている方はなんとなくわかると思いますが、そんなにインフラってぽいぽい変更できないよと。おっしゃるとおりです。でも、常に想定とか準備、あとしっかり対話をしていくところがあれば、ビジネスにしていくってことは可能なのかなと捉えています。

なので、下記はとても重要で、最初からガチガチに固めて作るわけではなく、変化してくことは考えておきましょう。その後「こういうのやりたいんですが、こういうふうにできます？」みたいなところで、そこが変化した時に「うーん、将来的に大丈夫かな」「今は大丈夫だけど、将来こういう時にはきっとだめだから、こういう準備しとこうね」と対応できるようにしておきます。そういったところをしっかりウォッチして会話したりしながら、前向きに変えていくということはとても重要だと思っています。

最後になりますが、宣伝です。ラクスでは、一緒に日本の企業の生産性に貢献していくことを目指してくれる方を募集しています。もちろん生産性にはエンジニアがとても大事なので、エンジニアも同様に募集しています。ぜひ興味がありましたらご応募ください、というのが私からの発表でした。以上です。

質疑応答

司会者1：ありがとうございます。ちょっと発表とは関係ないところなんですが、伝言ゲームがなぜ嫌いなのかが気になるんですけど。

司会者2：ああ、冒頭の嫌いっていう（笑）。

柏木：嫌いっていうかあれですね、直接話してもらったほうが、背景など抜け漏れないですし。そういうとこで、右から左に流していくよりは、直接話がわかる人たちと話したほうが、生産性が高いだろうなというところで。そういう伝言ゲームがあんまり好きじゃないという意味ですね。

司会者1：たらい回しにされるのが嫌いな。

柏木：たらい回しはまあ何かしら理由があると思うんで、それはそれで自分がされる分にはしゃあないなとは思うんですが。なんか「これを誰々さんから結果もらっていいですか」みたいなのは、当事者同士で話したほうが早いよなあと思います。

司会者1：なるほど、わかりました。では質問と感想に移りたいと思います。恐らくAWSとかで構築をされている方なんだと思いますが、理想論で作れないからじょうずにバランス取らざるを得ないよねというところで、共感の意見をいただいています。

柏木：ありがとうございます。おっしゃる通りですね、はい。

司会者1：初期から変わらない部分として、例えばどのような要素が挙げられますか。

柏木：このへんですかね。やっぱりAWSを使ってたりとかすると、バックアップ要件みたいなのは、AWSのサービス要件や機能みたいなところになるので、そういうところは逆に変わらないし、変えにくいところだとは思います。とか、あと「変わらない」で言ったら、ドメイン周りはほぼ変わらないでしょうし。

司会者2：そうですね。

柏木：ネットワークのVPC周りも、よっぽどサービスがドメスティックに変わらないと、変わらない部分だとは思います。そういう低レイヤーの部分というか。良くも悪くも、AWSサービスに乗っかっている部分などは、変わらないことが多いんだろうなと思います。

司会者2：昔はサーバーが変わらないと、全部が変わらなかったんですが（笑）、だんだんと変わる部分がどんどん増えてきているような感じ。

柏木：そうですね。そういえばいい意味で、AWSやると、そのへん、スペックみたいなところとか、容量みたいなところは柔軟性は高いかなと思いますね。

司会者1：なるほど。ありがとうございます。質問とちょっと違うかたちなんですが、あえて、ここはどちらかと言うとオンプレではない文脈でお話しいただいたと思いますが、あえてオンプレを選んだことっていうのは、これまでありますか？

柏木：あえてオンプレ。私が初期のサービスを作る時にオンプレを選んでいたことはないので、正直わからないです。前職でオンプレを選ぶお客さまは、どう考えても社外からアクセスする必要がない。これもうSaaSじゃなくて完全に社内システムの場合はオンプレでやるし、自社ですでにオンプレのサービスあるから自社内はオンプレを選んでいるお客さまが多かったですね。

司会者1：そういう構築案件に携わられたことも、柏木さん自身はあるということですよね。

柏木：そうです。SaaSでオンプレをどうやろう、しかもオンプレのリソースを今まったく持っていないっていう最近の企業さんは、あんまり見かけないですね。

司会者1：そうですね。お客様側のほうも理解が進んできたっていうところもありますよね。

司会者2：そうですね。本当に10年くらい前の話になりますが、「そんなクラウドとかにうちのデータを置くんですか？」みたいなのはありましたね。

司会者1：そうそう。そういうのありましたね。

柏木：そういう時代から自社でオンプレでサービスを提供している会社さんは、ラクスがけっこうそうだと思うのですが、オンプレっていう選択肢も持てるし、クラウドっていうのも出てきたので、クラウドのアドバンテージを使うっていうことも可能な状態ですね。

司会者1：なるほど。ちょっと私からの質問ですが、今回楽楽労務の基盤でAWSを選定されたその主たる理由はどういったものだったんですか。

柏木：ちょっとここは想像も含むんですが、人事労務領域で言うと、楽楽労務はどっちかというと後発なサービスです。そう考えると、ここのクラウドで大概準備されているアドバンテージというのが、すごく大きかったんだろうなって思います。

オンプレのリソースが載っていますが、これからどうスケールしていくのかを考えた時に、やはりパッと準備をして、アプリケーション開発して試していくところには、クラウドのメリットがあったんだろうなと想像しています。

司会者1：立ち上げが非常に早いということと、もしそれを急激にスケールアップしても大丈夫というところが、一番の選定理由になったっていうところなんですかね。

柏木：そうですね。他社の人事労務領域のシェアを考えても、というところだとは思います。

司会者1：なるほど、わかりました。ありがとうございます。

司会者2：最後、質問ではないですが、インフラもビジネス要件やサービスの使われ方を自ら把握することで、柔軟に動きやすくなりますね、というところで。

柏木：そうですね。どんな機能が載っかっているのかや、何を重視しているのかみたいなところは、やっぱり理解しておくと、開発の人が言っていることや、サポートの人が言っていることなど、それってこういうことだよね、みたいなことがわかるので、そのへんがオープンなのは、すごくいいことだなと思います。

司会者2：あとは開発とのミーティングも週1でやっているということで。

柏木：はい。

司会者1：これは、当社のプロダクト、比較的全般的にそういう動きですよね？

柏木：そうですね。すべてのチームでやっていますね。

司会者2：ありがとうございます。なにか問題あった時は両方の視点で解決していくみたいな感じでやっているような。

柏木：ちょうど今そうですね。組織上は分かれているんですが、実際、楽楽労務のインフラ担当と楽楽労務の開発担当は、インフラ課の中と同じぐらいしゃべっているんじゃないかなと思いますね。

司会者1：「インフラとしてだけでなく、やっぱりアクティブに、営業などのビジネスサイドと一緒にアクティブに動けるのはいい話だなあ」というツイートもいただきました。ありがとうございます。では柏木さん、最後までありがとうございました。

柏木：ご清聴ありがとうございました。