PROFILE
鈴木 勇
技術推進課
2013年ラクスに入社。『楽楽明細』の立ち上げ時に参画。『楽楽明細』の運用保守開発ののち、『楽楽労務』のシステム設計、初期開発を担当。その後、開発部門に対して横断的に改善活動を行う開発管理課に異動し、社内未利用の技術要素を自社開発に適合するか検証する先行技術検証プロジェクトなどを推進。その後、先行技術検証プロジェクトが独立して発足した技術推進課に所属。他にもビジネス部門に向けた技術勉強会を行ったり、各サービス開発チームから課題を吸い上げて解決に導く業務を担う。
技術スペシャリストへのインタビューを通じて、ラクスの日々の技術との向き合い方や、最近注力している実務について知っていただくシリーズです。今回は技術推進課で横断的な技術課題解決や新規技術検証を推進する鈴木さんにインタビューしました！
技術推進課はラクス社内で未利用の技術検証や組織横断的な技術課題解決を行っているとのことですが、改めて部署ができた経緯を教えていただけますか？
技術推進課は2020年４月に立ち上がった新しい組織です。もともと前身としては「開（か）発の未（み）来に先（せん）手をうつプロジェクト（通称：かみせんプロジェクト）」があり、技術推進課はその問題意識の流れを汲んでいます。
プロダクト開発全般に言えることですが、サービス開発初期の時点で最新の技術を採用していたとしても、サービスリリース後にはより新しい技術がが次々に登場してきます。継続的なサービス提供を行いながら、そのような新技術への置き換えを進めることは容易ではありません。本来であれば、こういった新技術も自社の環境に適合するか調査しながら刷新していくべきなのですが、新機能開発が優先されてしまいリソースを割けず、危機感を感じていました。
そこで数年前から少数の有志を募って新規技術検証を行う取り組みを開始しました。これが「かみせん」です。この活動で少しずつ実績が上がってきたのですが、有志の活動では年に２，３テーマが限界でした。これをより大きく組織的に取り組むために技術推進課が立ち上がりました。
新規技術検証とは、具体的にどのような仕事内容なのでしょうか。
SaaSプロダクト界隈での注目技術が、ラクスの開発にマッチするのかを調査しています。調査対象の技術選定は計画的に行っていて、中長期的な「技術ロードマップ」に従っています。技術ロードマップとは「どんな技術の知見をいつごろまでに社内に蓄積しておくべきなのか」という計画です。
技術ロードマップの立案は技術推進課が主導で行っています。社内に技術力の高いエンジニアがいるので、自分たちのSaaSプロダクトに必要な技術を予想してもらい、これを集約してテーマ化しています。だいたい半年から１年くらいで習得していくペースですね。プロダクトに求められる技術要素はマーケットの動きと一緒で常に変化するため、技術ロードマップも毎年更新してかなり柔軟にやっています。
社内の知見を集約しているんですね。社内プロジェクトのような形で進めているのでしょうか。
技術推進課だけでなく、各テーマについて開発チームのエンジニアの参加を募り、業務時間から一定の割合で時間を割いてもらって技術検証に関わってもらっています。また、参加者については検証技術と関連性の高いチームに打診することもあります。例えばモバイルアプリ開発のCIツール「Bitrise」はモバイル開発チームのエンジニアが担当するのが一番効果的、といった感じです。
2020年度のテーマだけ見てもドメイン層設計、機械学習、無停止リリースなど多岐にわたっている印象です。技術検証事例を紹介いただけますか？
アーキテクチャに大きく関わるテーマとして、「フロントエンドとバックエンドの分離」がありました。比較的長い歴史を持つプロダクトはモノリシックアーキテクチャで構築されていることが多いですが、近年はフロントエンド部分がPCブラウザからの利用だけではなく、モバイルブラウザやモバイルアプリから利用されていたり、表示ロジックの複雑化によりSPAといったフロントエンドとバックエンドを分離した構成が一般的になってきています。そこで、ラクスのサービスを分離する場合にはどんな分離のあり方がよいのかを検証しました。
もう一つは「GraphQL」です。バックエンドはビジネスドメインを基に構築しますが、フロントエンドは必ずしもビジネスドメインの単位で表示を行うわけではありません。従来のREST API開発方法には取得できるデータ項目がバックエンドの実装に依存したり、複数のビジネスドメインから取得した値をどこでアグリゲートするかという課題があります。GraphQLを導入することによって、フロントエンドとバックエンドの依存を疎にすることができ、スキーマファイルを通じて柔軟なデータの取得ができるようになります。
※Graphを検証した記事はこちらです。是非ご覧ください！
・GraphQLのアプリケーションへの組み込みを考える
実際稼働中のプロダクトへの導入は影響も大きく簡単ではないと思いますが、展望や課題があれば教えてください。
実際のところ、稼働中のモノリシックなアーキテクチャをすぐに変えるのは簡単ではありません。このような技術ロードマップに基づく取り組みは中長期的なもので、反映タイミングや具体的な設計は慎重に考える必要があります。例えばマイクロサービス化にしても、ドメイン境界を明確にできないのであれば、モノリシックアーキテクチャのままコンポーネントの整理に注力するというのも、一つの判断だと思います。先行技術導入ありきではなく、最適な提案をすることも役割です。
※かみせん、技術推進課でマイクロサービスを検討した参考記事はこちら
・サービス分割に備えたモノリス（モジュラーモノリスとかアグリゲートとか）
・マイクロサービスアーキテクチャにおけるサービス分割の難しさ
もともと技術推進プロジェクトでは、数年先にサービスに取り込まれるようなケースを想定して長期的な取り組みとして検証を行っていました。しかし、より優先度の高い技術の検証に取り組めるよう社内の課題を定期的に吸い上げていくことで、短期間で取り入れられるケースも現れてきました。例えば、GraphQLのケースでは、楽楽明細でのシステム設定の横断的な確認で効率化の成果が上がりました。その他、サービス運用中に発生するエラーで原因特定が技術的に難しいものの対応などもサポートしています。各サービス開発チーム内で発生する技術課題は今後も積極的にヒアリングしていきたいと思います。
長期的な研究成果を活かして、足元の横断的な実務課題も解決していくということですね。最後に今後技術推進課に入る方と一緒にやってみたいことがあれば一言お願いします！
技術推進課では技術の変化に対応するため、アプリケーション開発に限らず、インフラの改善なども含めた幅広い技術領域での課題解決に取り組んでいます。またラクスでは複数のサービスを提供しているため、横断的な課題解決が大きな影響をもたらすことになります。幅広い技術と、複数のサービスに関する知見を身につけることに興味がある方にとっては楽しめるポジションだと思います。技術推進課では自分の技術の幅を広げていきたいという方を歓迎します。