アーキテクチャ決めをどう思い切って意思決定しているのか？　SmartHR×LayerXが語り合う議論の過程と決定軸

お互いの発表を聞いた感想

松本勇気氏（以下、松本）：これから「マイクロサービス？モノリス？SaaSアーキテクチャのPros/Cons」ということでパネルディスカッションをします。私のほうでコメントに上がっていたものを汲みながら質問していきますが、お二人の話を通じての諸々を聞いていこうと思います。よろしくお願いします。

一同：よろしくお願いします。

松本：さっそくですが、まず各発表を聞いてみてどうでした？　感想戦的なことをやりたいんですけれど。すがまささんから聞いてもよいでしょうか？

すがわらまさのり氏（以下、すがわら）：そうですね。小学生並の感想ですが、みんな苦労しながらやっているんだというのがわかってもらえてよかったです。

松本：答えがないですよね（笑）。

すがわら：そうですね。

松本：みなさん、ひたすら悩まれている話をしている。mosaさんの感想はいかがでしょう？

榎本悠介氏（以下、榎本）：早く誰か銀の弾丸を作ってくれという感じですね。

（一同笑）

松本：みんなその時その時の活きのいい銀の弾丸を求めて、それに食い荒らされているような感じ（のこと）がやはりどこでも起きていますよね。

榎本：（答えは）絶対に存在しないので、組織のフェーズやドメインによって判断していくしかないんだなという当たり前のことを感じています。

すがわら：そうですね。

思い切った意思決定をどうやって行っているのか？

松本：この話はちょうど次の質問につながるいい返しだなと思ったんですけど。ここまでみなさんと話をしていて、やはりアーキテクチャは難しいと。決め方とか、みなさんどうしているんですかと。「下手すると1回決めたら後戻りできない」みたいなキーワードも、各位からけっこう出てきたと思うんですよね。

その中で、意思決定を「えいや！」でやっていかなきゃいけない。しかも、（その時は）先が見えていないじゃないですか。これってすごく難しいことをやっていると思っていて。社内で実際にアーキテクチャを生み出す背景を聞きたいです。すがまささん、アーキテクチャの思い切った意思決定をどうやっているのか、うかがってもいいですか？

すがわら：SmartHRは先ほど話したとおり、実は大きな決定はしませんでした。決定をしないという決定をしたんですね。まずはリファクタリングを進めようと。なので後戻りできない選択はしませんでしたが、やはり「後戻りできる状態で進めていきたいよね」というのがキーワードの1つとしてありました。

「えいや！」でいってそのまま戻れないとなると、事業的にも成長をしてきて「やっぱりダメでした」はさすがに厳しいというのがあるので、そういったところは気を付けながら判断していきました。他社さんがバシッと決めた理由とか、僕もぜひ聞きたいです。

松本：そういう意味ではmosaさんに聞きたいです。実は僕は一緒に議論をしている仲間なのであえて他人のフリをして聞きますが、ここまでのガッツリしたアーキテクチャの議論はどうやってしてきたんですか？

榎本：ドメインの理解をメチャクチャ深めようすることはやっていて、社内にドメインエキスパートみたいな人がいたり。お客さんに徹底的にヒアリングをする中で、後からわかることをなるべく減らそうみたいな動きを前提としています。

ではその中でどうやって意思決定や議論をしているのかというと。あまり変わったことはしてないというか（笑）。「これでいけるんじゃ？」みたいな意見をMiroとかを使ってわーっと、アーキテクチャをわいわい書いてみたり。

あとは実際リリースするわけじゃないものをバーっと作ってみるみたいなこととか。意外と書いたらわかることが多くて設計図みたいなものを書くだけじゃなくて、実際にコードを書いて「こいつ依存関係で終わるわ」みたいな違和感があるところは手を動かさないと。トップダウンとボトムアップの両方やるようなところはけっこう意識していますね。

松本：やはり後戻りできることはすごく大事ですよね。

最後の意思決定までの議論の過程

松本：とはいえですよ？　「このアーキテクチャでいきます！」と最後にボタンを押す人がいるじゃないですか。それは、チームの何十人という人たちがエネルギーを注ぐ、すごい意思決定だと思っていて。これはチーム内の誰が最後に決めることになっているんですか？　mosaさんからどうぞ。

榎本：最後は僕になるのかな？　ただ真っ向から対決みたいなことはこれまで起きていません。そんなに大きなチームではまだないというのもあるかなとは思います。

松本：確かに小さいチームだと議論がしやすいというのもありますよね。参考までに、今はどれくらいの人数でアーキテクチャをやっているんですか？

榎本：プロダクトのエンジニアでいうと、今は15人ぐらいかな。その3つのプロダクトや新プロダクト、OCR基盤など、かなり独立性の高いものやちょっと依存しているものを含めて、1チーム2、3人くらいでいろいろなプロダクトを並列して作っている感じです。

松本：1チーム2、3人。なかなか少ないですね（笑）。ちなみに、すがまささんは先ほどの大きい意思決定を最終的にはリファクタリング（する）という、すごく地に足のついたかたちで改善していく話になったわけですが、最後に誰が意思決定を決めたんですか？　SmartHRさんの中で、すごい議論があったんじゃないかなと推察されます。

すがわら：今回の件でいうとそこまで大きな対立とかはなくて、議論をしていくうちにだんだん収束していったというのが正しいです。話をしていくうちに「モジュラモノリスかリファクタリングかだよね」というところまで収束していって、モジュラモノリスにする前にリファクタリングは必要だし、直近の課題を解決するリファクタリングがよさそうというところで。そこに関しては、誰が特別に決めたとかはなくて、会議で自然にそうなった感じです。

YouTubeコメントの質問で「リファクタリングをするのにどういう組織体制にしたんですか」みたいな話があったと思いますが、そこも特に誰かに稟議を通して決めたとかではなくて。SmartHR本体の開発をしているのは30名ぐらいですが、その中から数名が小さく試してやれそうかどうかを検証しながらリファクタリングを進めていく。リファクタリングをするチームが作る検証もしている感じです。

松本：そのチームを拠出するのも、みんなが納得してとは言いつつ、経営的なところも含めてなかなか大変な意思決定だったんじゃないかなという気はします。どれくらいの期間、議論されたんですか？

すがわら：議論自体は3ヶ月くらいですかね。1週に1回か2週に1回ぐらい集まって、「うーん」となりながら考えていって。「今年はこうやっていきたいと思うんですよね」とエンジニアマネージャーから提案があって、それをもとに3名のリファクタリング専門チームを組成してやっていこうという感じになっています。

松本：3ヶ月と数人でけっこうな時間をかけていますね。

すがわら：そうですね。

松本：LayerXみたいに小さい組織では、物によりけりだとは思いますが、アーキテクチャで悩むときにどれくらいの時間とリソースをかけて意思決定をされているんですか？　

榎本：スピード感をかなり大事にしているので、うんうん唸って2週間かかったら絶対にやっていないですね。全部モジュラモノリスにするんだという時も、2週間は絶対にかけないと自分の中で決めて、1週間ちょっとで意思決定をするようにやりました。

どのような軸を持って意思決定しているのか

松本：この話は次の質問にも関わってくるのでmosaさんにつなげていこうかなと思います。今日のみなさんの発表から、アーキテクチャをどんどん変更していこうとする意志をすごく感じました。でも、アーキテクチャ変更のリソースはすごく大きいじゃないですか。

ここの中で事業との兼ね合いや、ユーザーの理想形の体験と開発のしやすさみたいなものや、事業と開発のしやすさのトレードオフは、シンプルに見てみるとどうしても出てくる気がするんですよね。そこに対して、みなさんはどういうふうな軸を持って意思決定をしているのかを聞いてみたくて。

「今後もアーキテクチャを変更していく？」という質問も最初に考えていましたが、どうせ変更するというのが答えだと思ったので。どちらかというと、変更する時の軸やリソースの意思決定の方法などをぜひ聞きたいと思っています。先ほどの続きで、mosaさんから聞いてもいいですか？

榎本：アーキテクチャを本当に大きく変えるか、今から全部モノリスに変えるかというと、「たぶんしない」と1回実験をして思いました。ただ、どのデータをどこに持つか、依存関係を変えるようなことはちょこちょこ発生していくんだとは思っています。それはなぜかというと、どちらかというと僕はユーザーに最高の体験を作るためにアーキテクチャを変更するという見方が強くて。

「ここにデータがあることによって、呼び出し元をこっちからにしないと依存がおかしなことになるじゃん」みたいな、なぜかユーザーが使うべき画面ではないところで操作をさせちゃうようなことが起こるのを絶対に避けたいと思っていて。なので、事業を進めるため、ユーザーにいい体験を届けるためにアーキテクチャを変更して、そうじゃない自己満足的なものは絶対に止めたいと思っています。

松本：最優先はやはりユーザー体験やお客さまのところだと。おもしろいですね。そこに対して技術が貢献するように意思決定をしていく。

榎本：そうですね。

松本：すがまささんはどうですか？　アーキテクチャの意思決定軸というか、技術全般になっちゃうかもしれないですが。どういった軸や事業との兼ね合いを考えているのか。

特に今回は最終意思決定がリファクタリングじゃないですか。事業的に考えると、これはすべてのエンジニア、すべてのCTOが悩んでいる課題だと思うんです。「リファクタリング or グロース」みたいな。SmartHRさんの中で、どういう軸で意思決定をしているのかなと。

すがわら：そうですね。実際にチームを組成してやる話に関しては、特別に大きな合意はとっていなくて、我々の属しているチーム内の範疇でやっている感じです。やるものに関してはやはり効率、お得度の高いものを考えていて。

それは何かというと、そこを解消することで統一的な体験ができたり、データが壊れなくなったり。お客さんにもメリットがあって、僕らにとっても開発を進められるところが重要だと思います。

松本：やはりみなさん「お客さまに最高のものが届くように」という意思決定の軸は変わらないと。その中で、「今回はリファクタリングするからこの方向になったんだ」みたいな。

ちなみに、CEOの芹澤さんは元CTOなので、今では意思決定がすごくスムーズだと思いますが、それまでの体制でも特段悩みはなかったですか？　「えー!?　リファクタリングをするならこれをやろうよ！」みたいな。

すがわら：そのあたりは、ちゃんと伝えれば必要性は伝わる人なので、なにも不自由なく進められました。

松本：いい会社ですね。SmartHRさんに入ろうか迷っている方はぜひどうぞ。

（一同笑）

すがわら：ありがとうございます。

松本：でもやはり経営的な意思決定にするか、完全に任せてしまうかは、やっていかないとユーザーのための技術的意思決定は難しいですよね。すごくいい話だなと思いました。

新規事業を始めるとしたらどうやって開発を始めるか？

松本：もう1つ質問をしたくて。例えば、二人が今起業しました。CTOです。新規事業を始めるとしたら、これからどうやって開発を始めますか？

聞いている方たちの中には、これから新しく事業を作っていこうかなと考えている方もいると思うので、ぜひ二人の意見を聞いてみたいなと。特に今日、マイクロサービス、モノリス、モジュラモノリスとかいろいろな案が出てきている中で、どういうふうにされるのかを聞いてみたいです。すがまささんからいいですか？

すがわら：そうですね。新たにサービスを作るなら、ある一定まで行ったらモジュラモノリスは考えてもいいだろうと思っていますが、今現在だと普通のモノリスでいいんじゃないかと考えています。

でも最初はやはり開発速度が大切ですし、その時に一番速度を損なわずにやっていけるのはRailsかなというところはあるので、それを使いながら破綻しないようにしながら開発していくのが大切だと思います。

松本：自分の手元にある道具で一番いいアーキテクチャを選択したいという、そんな感じの背景ですかね。

すがわら：そうですね。

松本：それがやっぱり一番早くお客さんにモノが届くからですか？

すがわら：はい。そうです。

松本：今やってきたことをさらにコードの設計上でよりいいものにできるように、同じくモノリスでスタートするような意思決定と。やはり慣れている開発で新しく始めたほうが、スピード的にも結局お客さまにいいものが届きやすいみたいなことはありますよね。

すがわら：そうですね。あとは注力すべきところに注力できるメリットもあるので。始まった直後はそんな感じで進めるんじゃないかと思います。

松本：ちなみに、ここまで踏んできた悩みとかあるじゃないですか。例えば、ただモノリスを作るのだと「じゃあモノリスでがんばるか。でもどうすれば」となってしまうと思うので。もしモノリスでやるとして、気を付けるポイントがあるとしたらどういうところですか？

すがわら：あまりゴテゴテしていると大変なことになるので、サービスを設けるとか、そういったところは早めに導入して整理したほうがいいだろうなとは思います。

松本：リファクタリングしやすい設計を先に心掛けると。同じ質問をmosaさんにも聞きたいんです。もし今ゼロからなにか新しくやるとしたら、どういう選択をとりますか？

榎本：これはもう明らかに一般論がない答えな気がするんですけど。

（一同笑）

松本：そうですね（笑）。そうなんですけどね。わかってはいるんですけど、ぜひ答えていただきたいですね。

榎本：まずドメイン境界がどこにあるのかは常に考えないといけないとは思っています。Scalebaseさんとか、1プロダクトにいろいろなファンクションがあるものを無理に分割するのかとかがあったと思っていて。僕もさらに極端なマイクロサービスを作ったことがあるんですが、基本的に1プロダクトで完結しているものを分割する時は、経験上、さすがにプロダクト境界は意識したほうがいいかなと。

ただ一方で、認証基盤やメール、プッシュ通知とかファンクションベースで切り出せるものはあるんじゃないかなと思っていて。そういったところは、ドメインがあまり関係なくあり得るのかなと。なので、基本は1プロダクトだったらあまり切れないけれども、ファンクションベースで切り出せるものは切るみたいな感じなのかなと思っています。

今もバクラクシリーズでデータ連携がいろいろありますが、OCR（Optical Character Reader）や認証基盤は間違いなく成功だったなと感じています。あとはメルカリさんなど、1プロダクトだけどメチャクチャ分割してもうまくいっている事例もあるので。

逆に、マイクロサービスに慣れているんだったらある意味そっちに寄るみたいな手もあるんだろうなという気はしています。それを言うと、僕はかなりマイクロサービスに慣れてきているので、そちら寄りの選択をとることはぜんぜんあり得るかなという感じはします。

松本：慣れはあるけど、やはりプロダクトの状況に応じて（行う）。シングルプロダクトでいくのであれば、分割しすぎると逆に最初のスピードを失ったりとか。

実は僕らは昔、辛いサービスをやって発表したことがありましたね（笑）。「マイクロにしすぎた結果がこれだよ」というのを、ぜひみなさんに参照いただければと思います。

榎本：1,000はてブ（はてなブックマーク）いった伝説のスライドですね。

（一同笑）

松本：すごい辛い思い出ですね、忘れましょう。しかしやはり場合分けというか、自分のプロダクトをきちんと知ることがスタートラインだと。その上で、自分の慣れた道具を使うことが大事なんだなと感じました。

お互いへの質問

松本：お二人の間で質問したいことはありますか？　今日の発表についてでもいいですし。

榎本：すみません、ちゃんと理解していないところがあって。コア以外でもいくつもあったじゃないですか。その部分はどうしているかというと…？

すがわら：クラスアプリと呼ばれているものはそれぞれが1Railsアプリケーションで、そこには数名のエンジニアが専属でついています。基本的に、アプリケーションの連携はSmartHRの本体とクラスアプリでやり取りをしていて、そこはデータベースの共有はせずにREST APIとGraphQLを使ってやり取りする感じです。

榎本：そこを分けたのは完璧にうまくいったという感じですか？

すがわら：そうですね。僕もどういう意思決定で分かれたのかは知らないんですけが。今のところそこはうまくパキッと分かれていて、それで困ることはあまり多くはないです。

榎本：うまくドメインが切れたということなんですね。

松本：スピードに貢献する分割だったということなんですかね。

すがわら：そうですね。

松本：逆にすがまささんからmosaさんに質問とかありますか？

すがわら：先ほど2週間くらいで「えいや！」とやっちゃうという話を聞いて腕力がすごいなと。そのあたりは、やり始める時に「ある程度これぐらいでここまで行くだろう」みたいな目算があってやっているんですか？

榎本：難しい質問ですね。どちらかというと事業の責任者として自分を追い詰めているみたいなところが大きいかもしれないです（笑）。

すがわら：なるほど。

榎本：「絶対に2週間以内にいい結論を出すんだ」「そのためには自分でも手を動かすし、みんなも巻き込むし」という覚悟でやっているという。どちらかというと腕力ですね。

（一同笑）

すがわら：なるほど。ありがとうございます。

松本：でもある瞬間、腕力で「えいや！」で決めるというのが重要なタイミングはありますよね。そうやってみないと見えないものがあったりするので。

榎本：まだまだPMF（Product Market Fit）していなかったり、一部しかしていないプロダクトもあったり、僕らも成長過程のサービスなので。プロダクトによってはお客さんにすごく使われてガチガチになっているわけではないので、戻れる余地もあるかもしれないと正直思っていて。ある種の「えいや！」はやりやすい状況かなとは思います。

松本：ありがとうございます。というところでだいぶお時間がきてしまいました。パネルディスカッションを以上とします。すがまささん、mosaさんありがとうございました。

一同：ありがとうございました。