未来はしんどい、だからこそ次どうするか今本気で考える　増え続けるラクスのインフラ基盤に今後求められること

SEからインフラエンジニアへジョブチェンジ

竹田昌男氏（以下、竹田）：よろしくお願いします。竹田と言います。ラクスではインフラ開発部の部長をしています。入社して約10年やってきており、経歴は、今はインフラ担当ですが、もともとはSE、PG職でした。エンジニア歴は、まあまあ歳もいってきまして、もう24年になります。

もともとのSE系からインフラにジョブチェンジするきっかけになったのは、京都でレンタルサーバーの会社を起業したことです。そのときに誰かがサーバーの面倒を見ないといけないので、インフラにジョブチェンジし、それからはサーバーメインにやってきています。

基本的にそこからエンジニアの一番上を走り続けて、ほぼ独学でやり切り現在に至ります。趣味は音楽ライブに行く、アニメを見る、波乗りしに行くなど幅広く、インドア派でもありアウトドア派でもあります。

最近は、やっぱりコロナで自粛しているので、会社の飲み会もまったくありませんし、テレビにばっかり向かっているんですよね。さすがにどこにも出ないとお金も貯まりすぎてくるので使っちゃおうと、65インチテレビを導入しました。

あともうそろそろ歳なので、タバコもやめました。まあ、こういう人がラクスでインフラのトップをやっている感じで捉えてもらえればなと思います。

本日の話は、はじめは4章立てで考えていましたが、長くなりそうなので3章立てに変えました。

現状のラクスのインフラの基盤と業務、今後求められそうなインフラ基盤を想定してみて、今のラクスが突き進んできたインフラの業務、基盤の作り方ですね。これをモデル的に考え直したほうがいいんじゃないかという話をしたいと思います。

ラクスのSaasアーキテクト（基盤）の現状

現状の基盤の話をします。ラクスの特徴は、SaaSのサービスいくつあるねんと。たぶん、全部は覚えられないくらいあります。スライドに載せているのは約9個ですが、小さいものを入れるとその裏にまだ5個、6個あります。ラクスのインフラ部門では、全部で15個のサービスの管理をしています。

大枠、これ単純に世代としていますが、だいたいこんな感じで分かれているイメージで書いています。世代が進むにつれて昔から通用してきた技術が通用しなくなり、新しい技術を取り入れていって、新しいサービスを作るときに新しい技術もしっかり導入していっている状況ですね。

エンジニアのみなさんにも、昔得意だったものが廃れていって、代わりに新しいものをどんどん学習してもらうことが、ラクスでも必要な状況になっています。ここで言うと私は10年前にジョインしているので、だいたい第2世代が始まったころですね。ここからサービスの製品開発、製品の成長にインフラとして関わっています。

（スライドを示し）ちょっとアーキテクト的に見てみました。サービスの第1世代、第2世代、第3世代。現状はちょっとわかりにくい図になっていますが、仮想化した環境がメインになっています。第1世代のものは完全に仮想化が終わり、第2世代のものはまだ残っています。

楽楽販売、楽楽明細が残っているので、これは今の第3世代の時期にしっかり仮想化するなり、コンテナ化するなり、新しい技術で基盤自体を新しく変えていかないといけないなと思っているところですね。

現状は、ラクスの基盤はオンプレが95パーセントを占め、一部はパブリッククラウドを使っています。あとハイブリッド構成にもしています。AWSを使っている理由は、やっぱり技術的に有利な面がある。AWSのエンジニアも増えていて、エンジニアを増やすときに採用しやすくなる。

そういう構想もあり、AWSは積極的には利用はしていないですが、技術的な最適解をラクスとして得られるのを重要視しているので、新しいことにも積極的には取り組んでいる。ただ割合的に少ないですよという話だと思っておいてください。

業務量の過多、業務の高レベル化が進んできている

私が入社してからも状況がどんどん変わっているんですけど、最近の悩みは、やらないといけないことが本当に多いことです。世代を越すごとになにが増えているって、レガシー技術が収束していく中で、逆にシステムを構成する技術要素が本当に増えていっている。

今、インフラは業務としてはレイヤーに分けたり、技術要素別のチームを作ったりできていません。1人でこれだけ多くのことを全部やっていかないといけないという考え方で進んできたので、今それが大きな課題として見えています。

事業体制については、基本的にラクスは各事業で1つの事業部ができていて、それらに対して縦割りのチームが作られています。ただし、インフラ開発部においてはすべてインフラの部門として統括して管理しています。その中に小さいチームを作り、事業ごとに配置している状態です。

基本的には個別最適が進んでいると思います。縦割りがどうしても残るので、インフラ開発部としての横串の取り組みが弱い。これをどうして強くしていくかを考えなければいけないと思っています。

この事業部制を導入している理由は、事業ごとに事業判断をしてもらうほうが他社に負けずに事業スピードがアップできるからです。結局、技術的に強くてもビジネス的に負ければ我々の会社としては負けなので、事業スピード優先で進んでいる状況です。

現状を振り返ると、業務量の過多、業務の高レベル化が進んできています。それは個別最適化もしている要素もありますし、インフラ開発部としては大阪と東京に分かれている大きな要因もあります。これらの要素が入っていろいろな課題が実際に出てきている状況です。

新技術を使いたい意見をどうやって取り入れるか

でも現状を考えても本当に複雑化しており、今後求められるものを考えていくとより複雑化するんじゃないかと思いながらも、やっぱりちゃんと考えないといけないフェーズを踏んでみました。

技術要件的に第1世代、第2世代、第3世代も10年で切ろうかなと思いましたが、第4世代をラクスとしては2025年あたり、新しいインフラの業務基盤をしっかり先を見て作ろうかなと思っています。

技術革新が進むことで、実際に社内のエンジニアから新技術を使いたいですっていう意見が強く出てきています。新しい技術に目がいくのもエンジニアの強い本質だと思うので、そこをなおざりにして事業が進むとも思えません。強いエンジニア組織を作っていけないとも思います。

この新技術を使いたい意見をどうやって取り入れていけるかなぁっていうのは、ちゃんと考えないといけないと思いました。

ビジネスサイドの要件は、実はうちの会社は、さっきもPdMの話がありましたが、あまり細かい技術要件までは降りてきません。大きな要件を捉えて技術要件に落とし込んでいくのが我々の業務の進め方です。

常に要件として出てくるのは事業利益率アップ、あるいは維持をしたいので費用対効果ちゃんと考えてくださいよというものです。サービスごとに違いがありますが、サービスごとの事業推進速度は維持してください、あるいはアップしてください。これが個別最適化になります。こういうのは実際には個別最適化という言葉では言われないんですけど、実態としてはあります。

業務飽和状態になると、たぶん今だけを見て終わっちゃう

年表でラクスのサービスの立ち上がりを見てもらいましたが、おそらく今のまま事業形態が進めば、10年後には今の10倍にはならなくても、確実に2倍にはなるんじゃないかなと思います。

もちろん新しいサービスというか、新しい概念で事業を興しているかもしれませんが。我々はSaaSのインフラ部隊なので、SaaSのサービスに限ってこうなるだろうと予測しておかないといけません。

さっきの発表でチャットでも質問がありましたが、お客さんの個別の要件は聞きませんという話ですね。個別の要件は聞かないんですが、これから日本におけるSaaS市場の拡大が本当に進むので、たぶん大きな声になってくると思います。

日本政府もしっかり基準を作って積極利用していく動きになっているので、次の3つですね。サイバーセキュリティ対策、ディザスタリカバリ、BCP対策ですね。これらに対する要件が強くなってくるんじゃないかなと考えています。

未来を考えるとよりしんどくなるんですけど、しんどくなるからこそ次どうするかを本気で考えないといけない時期にきているというのが、今私の頭の中にあります。

実際に忙しくなりすぎて業務飽和状態になると、たぶん今だけを見て終わっちゃうんですよね。だから、まだちょっと余裕があるうちに未来に向けて本当に考えて、変えるべきところをしっかり考えることを、今回のMeetupの機会も使って行いました。

標準化されていないため負の連鎖が起こる

いっぱいモデルを作っていますが、こうなっていたらいいなぁくらいに考えている、1つの考え方として捉えてもらえたらなと思います。

今まで現状の姿を表で表してきましたが、（スライドの図）たぶん実態はこうです。インフラっていう部隊がありますが、各サービスで進みたい方向とかスピードとか、あるいはコストとか、投資できるコストとかもバラバラなんですね。ラクスの考え方は、一つひとつのSaaSサービスにおいてしっかり利益を出し切るというものです。全体でオッケーという考え方ではありません。

サービスをやっている以上、利益を出し切りますというかたちでやっています。ビジネスサイドの各事業部が我々の顧客だとすると、それぞれに対して個別最適化をしているのが現状です。一つひとつの事業を考慮したインフラ設備、業務環境、それに合わせた環境を築いています。

ですから、立ち上がり期で売り上げがほぼ立っていないサービスについては、運用についても手厚い体制は引いていません。

この状況が生み出しているもの、みなさんもよく聞く言葉かと思うんですが、標準化っていう視点に合わせると、標準化できている範囲が本当に少ないなと思っています。これが将来我々の業務をより複雑化することになるだろうな、と。

実際に標準化できていないことで何が起きているかと言うと、想定の人数よりも人を増やさないといけない状況になっています。数年前から見ても、今はより人を増やしています。

今の仕様とかが標準化されていないためにいろいろな考え方とかルールがあるので、仕様変更時に新しく来る人に伝えられていないことがあったりと、人が増えることによって考慮不足が起きます。

そうすると、知らないことで運用作業時にミスが出ます。負の連鎖がこういうかたちで起こっていることも、たぶん未来には実態として出てくるので、この事象を防ぐやり方をちょっと考えたいと思っています。

個別に基盤を作っていく考え方から、大きな基盤を全体的に用意する考え方へ

（スライドを示す）図に表すと、こんな感じです。さすがにバラバラな方向に進んでもらうのは標準化しきれないので、せめて同じ方向は向いてよと。この方向を向いてくれたら共通化できる部分が必ず増えてくるので、それを標準化したいと考えています。

標準化も1つ大きな言葉なので、これをさらに解像度を上げて分解していくと、やらないといけないことは組織体制の標準化。役割を技術的レイヤーで分けたり、インフラだと今強く取り組んでいるのが自動化周りです。

自動化専門のチームを作って、そこの事業速度、計画速度を上げたり、より専門的なチームを作り、その中で標準化を進めたりとか。そういうことも組織全体として考えないといけない。

あとは業務自体の標準化、全体的にバラバラなやり方をしていたりするので、それを標準化していく。根本的に設備、使っている技術がバラバラだと標準化はより難しくなるので、使っている技術、設備、アーキテクト面の標準化。この3つでの標準化という観点で何ができるかを考えていく必要があります。

大きな考え方として、今までバラバラで作ってきたのは、求められるインフラは個別に要望を聞いてカスタマイズしていかないと作れなかったからです。今後は共通システムインフラというかたちで大は小を兼ねる考え方を入れて、大きな基盤を作る。

今までの個別に基盤を作っていく考え方から、逆に大きな基盤を全体的に用意しておいて、やりたいことがすぐにできる環境を大きく作ってみてはどうかと考えてみました。

どうしたら大きな方向性を維持できるか

そのときにやらないといけないことを考えたときに、標準化っていう1つのキーワードの中に、何をどのように標準化していくのかをちょっと考えてみました。

（スライドを示し）ここで記載しているのは標準化業務スタッキングとインフラサイドの図の部分になります。まずやらないといけないことは、設備周り、ツール、技術周りの技術的な標準化の部分ですね。なのですが、単純に標準化するだけだと標準化してもたぶん形骸化していくと思います。

なので、スタッキングという概念を入れて、自分たちが持てている技術が何なのかをしっかりと明確化していきながら、自分たちの武器を蓄えていく考え方をすればどうかなと思いました。

技術だけではなく、方針、ルールとかね。業務自体ですね。業務資料だったり、業務手順だったり、業務フローだったり、全部が揃ってしっかりスタッキングしていく動きができないと、標準化は維持できないだろうと思っています。まずスタッキングという動きを標準化の中に入れてはどうかと考えています。

たまに単純な標準化で、今までもそういう動きをしたことがありますが、標準化ってあまりエンジニアにとってはおもしろくなさそうなんですよね。正直（笑）。より刺さる進め方を考えないといけないかなと思います。

それぞれについて違う考え方を入れて、どういう良いことがあるかをより見える化していかないと、新しい業務モデルも動かないかなと思っています。

これをビジネスサイドから見たときにどう捉えてもらいたいかなんですけど。インフラでやりたいこと、やれることっていうのをちゃんとスタックしていくので、自分たちでやりたいことをチョイスしていってください、ということです。ここを広げれば広げるほどビジネスサイド、開発サイドの要件に応えられていくと思います。

はじめは小さいスタックしかできませんが、それを積み上げ、しっかりPDCAを回していく。この標準化業務スタッキングを回せれば最終的には大きなものに仕上がり、どんな要件にも一定応えられていくんだろうなと思います。ないものっていうのは絶対あると思うので、そういうものはスタッキング業務に回す考え方を入れてはどうかと思っています。

スタックするのは、ある意味明確化していくこと

技術スタックの仕方についてもちょっと考えました。インフラ面でいくと、動けばいいというものではないんですよね。我々がやらないといけない部分はシステムの開発から運用までのフェーズのほぼ運用フェーズに入ります。もちろん基盤の開発とか設計とかもするんですが、そのあたりも考えて運用メインで考えるとこのあたりですね。

実装機能設計、セキュリティ、バックアップ、モニタリング、実際に運用をどうするのか。最低限メンテナンスとトラブルシューティングの設計はしていきましょう、これを項目ごとにやっていったものを体系的に積もらせていきます。もちろん当初の設計は失敗するだろうし、設計自体はこれも見直しをしていく。その中でスタックを強めていくというかたちを取れればなと思っています。

でも完全な考え方は標準化業務スタッキングした中に各事業を丸ごと放り込んでしまえないかなと。こういう考え方で、第4世代のインフラが作れないかなと考えています。

スタックするのは、ある意味明確化していくことっていう考え方もあります。これを利用する技術、エンジニアが習得すべき技術範囲もより明確になるだろうと思います。インフラエンジニアは、今やらないといけないことが本当に多いので、何をやっていかないといけないかの羅針盤になると思っています。

システム開発においては、技術選択・利用がスタックするところから選べるようになるので、逆に事業スピードは上がるんじゃないかなと思います。アプリエンジニアも、インフラは何ができるの？　と、実際に我々の会社でも知らなかったりすると思います（笑）。個別最適化されているので、ほかに聞かないとわからないみたいな。なので、こういうものの共有、横展開も自動的にできると思います。

標準化をどのレベルで考え実現すべきかの答えを探している

まとめ。標準化をどのレベルで考え実現すべきかの答えを今探していますので、一旦既存の枠にとらわれない、ゼロベースで考えてみたっていうのが今日の発表です。

今回考えたモデルはおそらく短期的にはコストが上がります。一旦、大を兼ねないとならず、拡張性を担保する技術は今はまだコストが高いので、そういう意味でコストが上がると思います。

ただ、個別最適化を続けるよりも全体の最適化をしたほうが、将来コストダウンを実現できると思っています。何に跳ね返ってくるかと言うと、必ず人件費になります。

最終的なまとめは、今日は1つの考え方をお伝えしたかったことで、今まで続けてきたことが間違いだとは思っていないです。ラクスは事業も非常に成長していますし。

ただ近い将来、そのままで正しいのかは、本当に求められるものとか、取り巻く環境、社会情勢によってもいろいろなものに変わります。向かうべきゴールも我々は通年ごとに見直しているのでどんどん変わってきているんですよね。

昔だと事業スピード優先、安全性安定性はちょっとその次でしたが、おそらく大きくなったサービスについては、これからは安全性が一番求められるんじゃないかと思っています。

それぞれ環境の変化は自分の周りでも今強く起こっているので、今回はそういう機会としっかり向き合いました、というお話でした。みなさんもエンジニアリングの世界でもそういう機会が常に出ていると思うので、時折、向き合うようにしてもらえればなと思います。以上です。

標準化に何が求められているか

藤澤貴之氏（以下、藤澤）：ありがとうございました。

池田智裕氏（以下、池田）：ありがとうございました。かなり大きな話になりましたね～。

藤澤：標準化って難しいですよね。

竹田：標準化の逆が属人化なんですよ。

藤澤：弊社の場合はある種垂直統合というかたちでやっていたからこそ業績を伸ばせているところはあるけれど、一方、水平統合がなかなかできていないのが現状ですよね。

竹田：そうですね。ただね、標準化に何が求められているかと言うと、やっぱり伸びきって大きくなったサービスは、本当に事業責任者の方から安全重視という言葉が出てきています。標準化の進め方についても安全性、品質管理を強く押し出すのであれば、全サービス一気に取り組むのもなかなか難しいです。

池田：どのサービスからいくかみたいなところもけっこう重要になってきそうですよね。

竹田：強く求められているのは楽楽精算ですけどね。

池田：まあそこが一番パワーもあるので。

藤澤：主力商材というか。ZoomやTwitterのほうでもコメントをいくつかもらっています。「その時々で『正しい』って変わるので、いつまでも昔の正しいに固執しない、ですね」というふうに共感してもらっていますね。

あとは、「生々しいお話が聞けて大変参考になります。製品、事業の独立採算性に開発の要素技術までインクルードして経営判断しすぎると属人化して人的コストとヒューマンエラーが増えますよね」ということで。

ずばり弊社が同じ状況かと言うと、似たような背景で、コストが増えていっているみたいなのは今発表した内容に近いでしょうか。

竹田：この数年、人をこれまでよりちょっと多く増やしたんですよね。やっぱり、そうするとヒューマンエラーがけっこう如実に出てきていて。人員計画的にも今後5年でインフラの人数も倍増くらいの計画をリアルにしているので、現状を考えると先手を打って動き出したほうがいい時期に来ている。実際にミスの件数として黄色信号が出ていると思っていますね。

もっとその先を見て技術をスタックしていく

藤澤：今日紹介したやり方案は、4ページくらい前でしたっけ？　スタックをっていう。あ、このあたりですね。

これは今ある既存のプロダクトの技術をそのまま無理やり標準化していくわけじゃなくて、標準化できそうな、今後していきたいものを徐々にカタログみたいな感じで作っていって、長期的に見たらその中から標準化したものをチョイスしていくっていうような流れにしたいっていう理解であっていますか？

竹田：そうですね。残念ながらインフラって、私にとって部下だけじゃなく設備も部下みたいにおって、取っ替え引っ替えできません。5年ごとに新しくリプレイスみたいなサイクルで回っているので、より先を見てあげないといけないんですよね。

ですから、すぐに変えますっていうのができなくて、今あるべきところを徐々にどう変えていくかを必ず踏まないといけない。先にどうしていたい、どういう設備、どういう技術を使っていたいみたいなのをイメージしておかないとなりません。

池田：その時々で求められる必要最小限の技術で対応するのではなくて、もっとその先を見てとか、ほかのサービスも見て取り入れる技術をなるべくスタックしていくということですね。

藤澤：未来思考、逆算思考というような感じですかね。わかりました。ありがとうございます。ほかにも共感のコメントをもらっていて、「技術スタックと業務ルールやドキュメントのスタックを別領域でスタックしていって、それぞれの要件に合わせて教育していく考え、すごく気持ちよくまとまっていると感じました」と。

あとはビジネスサイドの要求に対してどれをチョイスするのが最適化を選び抜くスキルも重要ですね。

竹田：たぶん選んであげないといけないというのは必ずあると思うので（笑）。そこはラクスで各部署間連携を常にしているところの強みなので、こういうところでまた連携を強められたらなと逆に思いますけどね。

部門間での属人化の対策

藤澤：そういえば、わりと前半のほうで、「ラクスのエンジニア組織はインフラとアプリが完全に分かれているんですね」っていうTwitterのコメントがありました。

部門間での属人化みたいな部分は、例えば開発やインフラといった感じで起きがちだと思いますが、そこに対して今取り組まれていることはありますか？　

竹田：いやこれがね、できていないんですよね。なので、ここのページの一番下ですよね。こういうことをやるので、こういうことをやってくださいねっていうメッセージにもしたいと思っています。アプリエンジニアにもインフラをより知ってもらう活動とができるんじゃないかな。

池田：いい意味で言うと、すごく切り離されて安心して任せているので、僕らがそこに入らなくてもいいからやってもらっているという部分ももちろんあるんですけど。悪い面で言うと、お互いに知らない部分ができてしまっていることが時々あったりします。

竹田：でもインフラの中でもリアルにやらないといけないことがどんどん増えているので、これでアプリのことも理解しろっていうのは鞭打ちすぎているんじゃないかなっていうのを非常に思っていて。

池田：そこはやっぱりお互いがお互いを知れる状態になるっていう。

竹田：そういうところが変に遠慮になっていて、悪い関係じゃないけどうまくシナジーが生まれていない要因になっている。

藤澤：それもあって選択肢自体をスリムにしていきましょうというようなところですよね。今、質問がもう1つ届いています。「大は小を兼ねるというスライドがあったと思うんですが、ラクスさんではパブリッククラウドは積極導入されているのでしょうか？」という質問です。

竹田：2020年度に初めて「楽楽労務」という、ハイブリッドではなくAWS単体のアーキテクトを使ったサービスをリリースしています。が、なんせ5パーセントの枠の中にいますので、積極的ではないです。今のところ我々の試算上は、AWSはオンプレよりもコストがかかるのではないかというリスクが出ているんですね。

費用対効果、利益率アップという概念を考えるとちょっと積極的には勧めにくいですが、ラクスのエンジニアの部隊としてはそのときに求められる最適解を技術的に選び抜きたいというのがあります。その選択肢にちゃんと入るように取り組みはしているのが現状ですね。

池田：運用も含めてコスト的にトントンになるのであればとか、そこを見ながら積極的に取り入れるフェーズもどこかで出てくるかもしれないところですよね。

竹田：はい。

藤澤：ありがとうございます。いろいろと聞きたいところもありますが、ちょっと時間が迫ってきましたのでそろそろ次にいこうかなと思います。

池田：竹田さん、発表ありがとうございました。

竹田：ありがとうございました。