未来を見据えたトレンド技術をいち早くキャッチアップ。実務で活用を目指す。

PROFILE

堀内 泰秀

技術推進課 課長。2013年ラクス入社。北米向けサービス開発のマネージャーとして活躍。その後、楽楽精算でスマホアプリ開発、AI機能開発など主導し、新しい技術要素を積極的に導入してきた。
2018年には新サービス開発をチーム立ち上げから担当し、サービスをリリースに導く。2020年に技術推進課を新たに立ち上げ、技術検証、現場の技術課題解決支援、共通基盤開発など幅広いミッションにマネージャーとして取り組んでいる。

技術スペシャリストへのインタビューを通じて、ラクスの日々の技術との向き合い方や、最近注力している実務について知っていただくシリーズです。今回は技術推進課長として、横断的な技術課題解決や新規技術検証を推進する堀内さんにインタビューしました!

技術推進課はラクス社内で未利用の技術検証や組織横断的な技術課題解決を行っているとのことですが、改めて部署ができた経緯を教えていただけますか?

技術推進課は2020年4月に立ち上がった新しい組織です。もともと前身としては「開(か)発の未(み)来に先(せん)手をうつプロジェクト(通称:かみせんプロジェクト)」があり、技術推進課はその問題意識の流れを汲んでいます。

プロダクト開発全般に言えることですが、サービスの初期開発時に最新の技術であっても、サービスリリース後も新技術が次々に登場してきます。継続的にサービスを提供していると、そのような新技術に簡単に置き換えはできません。本来こういった新技術も自社の環境にうまくはまるかどうか調査すべきなのですが、日々の開発が忙しいのでリソースを割けず、危機感を感じていました。

そこで数年前から少数の有志を募って新規技術検証を行う取り組みを開始しました。これが「かみせん」です。この活動で少しずつ実績がでてきたのですが、有志の活動では一度に2,3テーマぐらいが限界でした。より大きく組織的に動かそうとなったのが技術推進課が立ち上がった経緯です。

堀内さんのいる大阪オフィスにて。チームの岡本さんと会議中。

新規技術検証とは、具体的にどのような仕事内容なのでしょうか。

SaaSプロダクト界隈での注目技術が、ラクスの開発にマッチするのかを調査しています。調査対象の技術選定は計画的に行っていて、中長期的な「技術ロードマップ」に従っています。技術ロードマップとは「どんな技術の知見をいつごろまでに社内に蓄積しておくべきなのか」という計画です。

技術ロードマップの立案は技術推進課が主導で行っています。社内に技術力の高いエンジニアがいるので、自分たちのSaaSプロダクトに必要な技術を予想してもらい、これを集約してテーマ化しています。だいたい半年から1年くらいで習得していくペースですね。プロダクトに求められる技術要素はマーケットの動きと一緒で常に変化するため、技術ロードマップも毎年更新してかなり柔軟にやっています。

社内の知見を集約しているんですね。社内プロジェクトのような形で進めているのでしょうか。

技術推進課だけでなく、各テーマについて開発チームのエンジニアの参加を募り、業務の一定時間で技術検証に関わってもらっています。最近では検証技術と関連性の高いチームに打診することもあります。例えばモバイルアプリ開発のCIツール「Bitrise」はモバイル開発チームのエンジニアが担当するのが一番効果的ですよね。

2020年度のテーマだけ見てもドメイン層設計、機械学習、無停止リリースなど多岐にわたっている印象です。技術検証事例を紹介いただけますか?

アーキテクチャに大きく関わるテーマとして、「フロントエンドとバックエンドの分離」がありました。比較的長い歴史を持つプロダクトはモノリスですが、近年はフロントエンド部分がPCブラウザからの利用だけではなくモバイルブラウザやモバイルアプリからの利用などにより多様化していたり、業務ロジックと表示ロジックを分離したいという要求からSPAといったフロントエンドとバックエンドを分離した構成が一般的になってきています。そこで、ラクスのサービスを分離する場合にはどんな分離のあり方がよいのかを検証しました。

 もう一つは「GraphQL」です。バックエンドはビジネスドメインを基に構築しますが、フロントエンドは必ずしもビジネスドメインの単位で表示を行うわけではありません。従来のREST API開発方法には取得できるデータ項目がバックエンドの実装に依存したり、複数のビジネスドメインから取得した値をどこでアグリゲートするかという課題があります。GraphQLを導入することによって、フロントエンドとバックエンドの依存を疎にすることができ、スキーマファイルを通じて柔軟なデータの取得ができるようになります。

オンラインで行われた検証成果発表の一コマ。

※Graphを検証した記事はこちらです。是非ご覧ください!
GraphQLのアプリケーションへの組み込みを考える

実際稼働中のプロダクトへの導入は影響も大きく簡単ではないと思いますが、展望や課題があれば教えてください。

実際のところ、稼働中のモノリスなアーキテクチャをすぐに変えるのは簡単ではありません。このような技術ロードマップに基づく取り組みは中長期的なもので、反映タイミングや具体的な設計は慎重に考える必要があります。例えばマイクロサービス化にしても、コンポーネントをどの粒度で分割すべきか明快でなければ、流行に乗るだけではなく現在のアーキテクチャを戦略的に維持しておくことも一つの判断だと思います。先行技術導入ありきではなく、最適な提案をすることも役割です。

東京オフィスで技術検証を推進する鈴木さん

※かみせん、技術推進課でマイクロサービスを検討した参考記事はこちら
サービス分割に備えたモノリス(モジュラーモノリスとかアグリゲートとか)
マイクロサービスアーキテクチャにおけるサービス分割の難しさ

展望ですが、こうした長期的な取り組みとして検証していた技術を、より実務的・短期的な技術課題に応用するケースが出てきています。GraphQLのケースでは、楽楽明細でのシステム設定の横断的な確認で効率化の成果が上がりました。その他、サービス運用中に発生するエラーで原因特定が技術的に難しいものの対応などもサポートしています。各サービス開発内で発生する技術課題は定期的にヒアリングしていきたいと思います。

長期的な研究成果を活かして、足元の横断的な実務課題も解決していくということですね。最後に今後技術推進課に入る方と一緒にやってみたいことがあれば一言お願いします!

 技術推進課では、今後の技術の展開の中で、特に変化も激しいインフラ領域に注目しています。そこでインフラを含めた幅広い技術領域に興味を持ちつつ、横断的な技術課題を解決していきたいエンジニアの方は楽しんでいただけると思います。当社には専門のインフラ開発部があるので、やり取りを深めつつ技術推進課にも新しい知見をためていけるとよいと思っています。研究だけではなく実装とのかかわりもあるので、プロダクトの知見と技術を両面で磨いていきたいという方も歓迎です!

ありがとうございました。また新しい展開がありましたら是非お話聞かせてください!

Back to list