技術選定のカギは「プロダクト中心」　ラクスルの技術スタックと背景にあるビジョン

ラクスルの技術選定について

二串信弘氏：ラクスルの二串です。

今日はYouTubeでの配信ということで、実は年始目標で今年はテック系のYouTuberになるのもいいかなと思っていたんです。真面目にです。「まあ半年後ぐらいだな」と思っていたんですけど、こうしてイベントの登壇がYouTubeになるということで。びっくりしたんですけど、さっそく夢が叶ってしまいました。

ちょっとだけ前のめりになって話していこうと思うので、みなさん、ぜひよろしくお願いします。

あらためまして自己紹介です。二串といいます。ラクスルという会社で、ラクスル事業本部という印刷の事業を行っている組織のHead of Engineeringとして働いております。

Head of Engineeringというのが少しわかりにくいと思うかもしれませんが、簡単に言うと、事業部のCTOですね。CTOとして事業の技術組織の開発全体をリードする役割でございます。

2017年よりラクスルで働いております。今日はよろしくお願いします。

さて、技術選定というお題を今回いただいたんですよね。「技術選定ってすごく難しいな」と正直すごく悩みました。いろいろ考えた結果、単純に技術の話をするというよりは、もう少し深堀って、「技術は何のために使うか？」みたいなところに行き着きまして。今日はラクスルで私が3年間働いた経験から、リアルなところを交えながら、技術選定という話題を膨らませてシェアできたらいいかなと思っております。

というわけで、今回のテーマは「技術選定は会社を知ることから始めよ」です。

流れとしては、まず「ラクスルの技術の位置づけ」をご説明させていただいて、そのあと複数の観点で具体的な技術選定の話を紹介します。

技術選定話の前に、ラクスルという会社がどういった会社かということを……。みなさんラクスルという会社をご存じですかね。ご存じでしたら手を挙げてください……って、まあ挙がらないですね。リモートでした。なので、簡単にラクスルという会社を説明させてください。

リアクションがないのですごく難しいですね。がんばっていきます。よろしくお願いします。

「仕組みを変えれば、世界はもっと良くなる」

ラクスルという会社は、「仕組みを変えれば、世界はもっと良くなる」というビジョンを掲げて事業を行っております。

「仕組みを変えれば」の意味としては、我々がやっているエンジニアリングやITの力はもちろんですが、我々はリアルな産業を相手にしているので、そのリアルな産業の課題をひも解いて、ITの力以外にも、オペレーションの巻き込みやビジネスの事業解像度などを高めていくことで産業構造の仕組み自体を変え、世界もっと良くするということを目指しています。

ラクスルのミッションをご説明させていただくと、伝統的な産業にフォーカスし、テクノロジーを持ち込んで産業構造を変えて、21世紀型のより価値の高い産業へとアップデートしていくことに取り組んでいます。

こちらの図の例ですと、自社でプロダクトの企画・製造を行って、さらに営業部門がいてそれを販売するというような、一気通貫のモデルの会社を20世紀型と我々は呼んでいます。

一方で、ラクスルが目指す世界は、（右側の図を指して）この21世紀型の事業構造ですね。エンドユーザーに対しては、より便利な機能を提供していって、ユーザーの体験を最大化する。いい購買体験を提供する。一方で、サプライサイドに関しては、製造のキャパシティというか、稼働率を最大化したり、より利益が生み出せるような機会を提供する。

ラクスルが間にプラットフォームとして入ることで、双方にとってメリットのあるビジネスを生み出そうというかたちで、ビジネスを進めております。

ラクスルのサービスとして今どういったものがあるかというと、印刷・広告の「ラクスル」というサービスと物流の「ハコベル」というサービスをメインで展開しております。

ラクスルの技術スタック

では、ラクスルという会社がどういった技術スタックを使っているか。

まずサーバサイドはメインでRuby on Railsを使っております。もともとのPHPのモノリシックなシステムから今リプレースをかけていて、今のメインのとしてはRuby on Railsですね。あと一部でGoを使っているところもあります。

フロントエンドに関しましては、Vue.jsをメインフレームワークとして開発をしております。インフラはAWSやGCPを使っています。

我々はリアルな産業を相手にしておりますが、ひょっとしたら外からどういう開発をしているのかあまり見えない部分があったかもしれませんが、toBのサービスとして非常にモダンな開発をしている会社だと思っております。わりとtoCに近い開発のスタイルでかもしれません。

技術は究極的には手段

あらためまして、今回のテーマは「技術選定は会社を知ることから始めよ」ということで、まずは技術というところから深掘っていきたいと思います。

私の前職・前々職は非常に技術力・開発力が強い会社でした。前職はDeNAに勤めていて、それこそモバイルゲームのブームが2011年、12年ぐらいにあったと思うんですけれども、その当時とても優秀なエンジニアがたくさん集まって、その時期に私も働いていました。

私自身も技術はすごく大好きで、最新の技術も追いかけたいというところはもちろんあって、そういった志向を持ってこれまで働いてきたんですけれども、そんな中で3年前ラクスルに転職しまして、会社を認知するまでに少し時間がかかったというか、そういったところがありました。

ラクスルという会社は技術力がすごく高い会社で、内製でプロダクトを作っているんですけど、「安易にほかのテックカンパニーと一緒くたにしていいのかな？」「安易にテックカンパニーと言っていいのかな？」とちょっと思っていた時期があったんですね。今回登壇をするにあたって、このあたりを深掘っていったらわりと気づきがあったので、ご紹介していきます。

端的に言うと、ラクスルはビジネス開発が非常に得意な会社なんですね。伝統的な産業にフォーカスして課題を定義していって、ITの力で仕組みを変えていく。高い解像度で勝ち筋を見つけていくというところが非常に得意な会社です。

これはどういうことかというと、印刷や物流向けに事業を展開している会社だというであって、技術の会社ではないんだというところを認識しました。

究極的に、技術というのは我々にとっては手段です。プロダクトの価値を最大化させ事業を成功させることこそが目的。この目的を忘れないことが非常に重要だと思っております。ここで書いたのは、自分も過去に何度も何度もこういった反省をしておりますので、自戒を込めてというところですね。

隣の芝は青いんですけど、単純に他社のおもしろそうな技術や事例をまねてもうまくいかないなというのが、私の過去の経験も踏まえてあります。

技術選定の軸は「現戦力でいかに成果を出すか」

「コストパフォーマンス技術選定」。もう少し具体の話も紹介していきたいなと思います。

ラクスルの技術選定の基本スタンスは、「現戦力で成果を最大化させる技術選定」を今のところとっております。どういうことかというと、タイトルに「コストパフォーマンス技術選定」とあるとおり、現戦力でいかに成果を出すかというところにフォーカスしています。

コストといってもいろいろなコストがあるんですけど、学習コスト、開発の人数、お金であるとか、そういったところですね。一方で、コストに対して成果の量というのは何があるかというと、売上や品質であるとか。あと、間接的にはエンジニアのモチベーションみたいなところも成果につながるかなと。離職リスクや採用の観点というのもあるかと思います。

あえて技術選定のポリシーみたいなところで1つ言うとすると、ラクスルではすごく複雑な産業をシステムにするところにフォーカスしているので、ドメインをよく知った上で設計・実装しないといけないので、すごく時間がかかるし難易度も高いんですね。なので、それ以外をなるべくシンプルに、システムの問題を複雑にしすぎないというところをわりと重視しています。

なので、「あとからジョインした人が理解できるか？」という観点を持つのが非常に重要かなと思っています。ラクスルは長期目線でプロダクト開発に投資する会社なので、プロダクトとして長期的にバリューを発揮していけるような技術選定・設計を心がけています。

もう1つの事例としては、弊社のインフラ環境は今EC2をメインにしております。一部でECSやEKSといったコンテナも使ってはおりますが、今のところ本番環境をコンテナ化しようというモチベーションは……ムーブメントは時々起こるんですけど、いろいろディスカッションして今のところは本格導入はしていないのが実情です。開発のツールとしては大いに使われています。

もちろんフェーズ感とかそういったところもあると思うので、今のところ弊社では、例えばDevOpsの専門のチームなどは持っていなくて、SREチームと開発チームという体制でやっております。なので、将来的にはそういった組織も出てくるかとは思うのですが、今はまだそういったフェーズではないという判断で行っていないというところですね。

あとは、このあとのスライドで出てくるんですけど、弊社はマイクロサービスといった戦略をとっておらず、小さいサービスがたくさん出ていくということが今のところないので、現状のChefやTerraformを使ったEC2ベースのインフラというところで、あまり困っていないというところが実情です。

ラクスルのサービスアーキテクチャ

サービスアーキテクチャについて。先ほどちらっと言ったマイクロサービスですが、今のところ、弊社ではマイクロサービスはオーバーエンジニアリングです。現時点ではDevOpsの体制というか人材に割けないというのも正直なところでございまして、今導入するべきではないという判断をしているわけですね。

わりとビジネスの特性もあるとは思うんですけど、弊社としては、今はモノリスとマイクロサービスの中間的な立ち位置でアーキテクチャを組んでおります。一つひとつのアプリケーションはモノリシックにコード圧縮して効率化し、一方でビジネスドメインに応じてきっちりシステムを分割していく戦略をとっております。

エンドユーザーが接するコンポーネントとして、印刷ECや、印刷にローカルマーケティングの機能をアドオンした集客支援サービスなどがありまして、これらをそれぞれ独立したコンポーネントとして切り出すということをやっています。

一方で、バックエンドといいますか、共通機能として、認証や決済などが独立コンポーネントとして切り出されています。また弊社の独自のユニークなシステムとしては、印刷データのチェック部分や、印刷会社に対して発注するといった機能も別システムで持っております。

図のとおり、各アプリケーションがそれぞれシングルなデータベースにぶら下がるかたちで構築していて、各サービス間がAPIで通信するという戦略になっています。マイクロサービスほど細かく分かれていなくて、大きな単位で分かれているかたちになっています。

今のところ、こうした戦略で十分機能していて、かつ効率もよくて、細かく分割するよりはすごくrapidに開発できています。

もう1つだけ実例を紹介すると、システム刷新をやっています。技術スタックのところで説明したところもあるんですけど、もともとザ・スタートアップの時にはモノリシックなPHPのシングルリポジトリのアプリケーションで動いていたのですが、やはり当時は少ない人数でrapidに開発していたというところで負債もたくさんたまっております。そういうわけで、我々はここしばらくシステム刷新も並行して取り組んでいます。

目的としては技術選定なので、システムを刷新するのはもちろん重要なんですけど、究極的には、「システムに対して柔軟性を持たせて、経営戦略の選択肢が増えている状態にする」ということがこのプロジェクトのゴールだと我々は思っています。なので、言語やフレームワークなどは本質的には課題ではなくて、どちらかというと「いかにドメインをきれいに分けて既存のPHPのモノリシックな部分を分割する？」というところが重要でした。

こういうとき一般的にエンジニアとしては新しい技術を採用したくなりますよね。未習熟な言語やフレームワークを導入することは不確実性が高まるし、これ自体が再度負債化してしまうリスクもあります。それは経営として一番避けたいところだと思うんですね。なので、このリスクを徹底的に排除するところを非常に心がけていました。

長く続いているプロジェクトなんですけど、今のところうまくいっております。ここはしっかり刷新していくぞというところでやっております。

ラクスルにおけるエンジニアとしての楽しみ

では、最後に少し軸を変えて「プロダクト中心の技術選定」についてもう少し説明したいなと思います。

今までの話で、堅実で堅牢でわりと節約していて、というイメージを持たれるかもしれないんですけれども、「じゃあエンジニアとしてどういう楽しみがあるんですか？」という問いをひょっとしたらもらうかもしれないので、このスライドを用意しました。

答えとしては「楽しい！」です。

どういったところが楽しいのかというところを最後にご説明して、今日は終わりにしたいと思います。

テックな会社から転職してきた私は、最初の頃は「いい技術・新しい技術を導入して、もっとテック組織として目立っていくのがいいんじゃないか」みたいなことを考えていた時期も正直あったんですけど、そういったことを周りにメンバーに話すと、けっこうみんな新しい技術に対してシビアというか、「何がうれしいんですかね」「工数下がりますか？」「難しすぎませんか？」ということを言ってくるので、最初「うーん、なんかな……」と思ったんですけど、掘り下げていくと、みんなスタートアップで働くことをすごく心得ているんだなと、その当時思いました。

やはり私が入社した3年前はまだまだスタートアップのフェーズで、時間もお金も人も限られていて、かつ、みなさんなにより残業したくないということで、「どうやったらプロダクトをもっと使ってもらえるか？」「よりお客さんに定着してもらえるか？」「リリース期日という制約のなかでどういう戦略をとっていけるか？」ということを考えている人たちが非常に多い。

そういうわけで、当時はけっこう新鮮だったんですけど、技術の会社から来た私としてはすごく刺激になっているところです。そういったエンジニア組織です。

エンジニアとしての役割を考える

ラクスルがどういったかたちで開発しているかというところなんですけど、こういったかたちですね。

プロダクトを中心に考えるエンジニアがすごく多いです。もちろんプロフェッショナルなので、最新の技術もキャッチアップするのですが、軸としては、プロダクト中心の技術選定を心がけている人が多いです。

現場やユーザーの観察も一緒にチームでやることもあるし、プロダクトマネージャーも一緒にプロダクトビジョンを考えて、プロダクトマネージャーが最終的には決めて、「よし、こうやっていこう。こうやったらプロダクトの価値が高まるし、こういったビジョンでいこう」というのをみんなで揃えて開発をするというスタイルでやっております。そういったかたちです。

というわけで、いろいろとご説明を差し上げたんですが、まとめると、ラクスルという会社は技術の会社ではありません。「産業の課題をプロダクトで解決する会社です」と言い切ることで、自分の中で腑に落ちたというところがあります。

なので、ここでのメッセージとしては、「エンジニアとしてバリューが出せてないな」ということを思ったら、会社が何のために会社をやっているのかということを振り返っていただければいいんじゃないかなと思って、このスライドを入れさせていただきました。