この記事は ラクスルの2022年アドベントカレンダー14日目の記事です。
はじめまして！ラクスル事業部 PBU（Printing Business Unit）開発チームで内定者インターンをしている23新卒の杉山です。今日の記事では、ラクスルグループ（ラクスル・ノバセル・ハコベル）の各サービスで内定者インターンをしている23新卒のメンバーにどんなことをしているのかを聞いてみました。
はじめに
ラクスルグループの新卒内定者のうち、希望者は内定承諾から入社までの間に内定者インターンとして実際の開発の現場に参加できます。
なお、入社後の配属先は内定者インターンとは別に、それぞれの希望によって決定します。
この記事では内定者インターン参加メンバーがインターン開始からこれまで、どんなことをして、どんな学びがあったのかを各メンバーに振り返ってもらいました。
ラクスル
杉山
あらためまして、ラクスル事業部 PBU（Printing Business Unit）開発チームでサーバーサイドエンジニアの内定者インターンをしている23新卒の杉山です。内定者インターンは2022年7月から開始し、リモート・出社のハイブリッドです。
ラクスルの本番・テスト環境のマスタデータの同期
ラクスルでは取り扱っている商品仕様などのマスタデータをデータベース上で管理しています。本来、本番環境とテスト環境のマスタデータは一致しているのが望ましいですが、これまでは複数あるテスト環境のうち、ひとつのテスト環境のみが本番環境のマスタデータと一致してる状況で、このテスト環境以外は本番環境とは一致していませんでした。
このような状況では、テスト環境での挙動が本番環境と違う可能性があり、QAやデバッグにとても不便です。そのため本番環境と複数あるテスト環境のマスタデータを同期する仕組みをつくることになりました。
実装にあたり考慮したこと
本番環境とテスト環境のマスタデータを同期するにあたり、本番環境のマスタデータをそのままそれぞれのテスト環境にリストアすれば完了というわけにはいきません。なぜならテスト環境にはこれまでのQAなどでつくられた注文などレコードがあり、テスト環境と本番環境のマスタデータに差異（テスト環境のみ存在する商品仕様など）がある場合、そのままテスト環境にリストアするとテスト環境のデータベースに不整合が生じる可能性があります。今回つくる仕組みではデータの同期に伴う不整合の検出と修正も行う必要がありました。
実装
ラクスルのメインアプリケーションはRuby on Railsでつくられているため、この同期処理はthorのタスクとして実装しました。今回作成するタスクの内容は大まかに次のような流れになります。
テスト環境のアプリケーションから本番環境のデータベースに接続することはできません。そのため、本番環境のデータベースにあるテーブルのうち、マスタデータに関連するテーブルのみをAWS Database Migration Service を用いて特定のテスト環境（以下、X）のデータベースにリストアする仕組みを別途作成し、そのマスタデータを各テスト環境に同期するようにしています。
- Xと同期対象のテスト環境（以下、A）のマスタデータの差異をAのデータベースのテーブルに記録
- 変更の内容に応じてAのデータベースのレコードを更新・削除
- Xのマスタデータにない商品を含む注文を削除
- 同一の商品仕様を示すレコードXとAに存在するものの、XとYでその主キーが異なる場合、注文商品のレコードのなかの商品仕様テーブルへの外部キーを更新
- XのマスタデータをAのデータベースに別テーブル名でリストア
- Aのマスタデータテーブルを
DROPし、別テーブル名でリストアしたマスタデータを正しいテーブル名にRENAME
実装してみて勉強になったこと
ラクスルのデータベースはMySQLを採用しています。MySQL特有の挙動やActiveRecordとの組み合わせたときの挙動について初めて知ることがありました。
- 時刻型カラムに
0000-00-00 00:00:00を入れられる - TINYINT(1)型カラムの値はActiveRecordではboolean型になる
また、当初は3.の処理をSQLの LIMIT N OFFSET m （N は固定でm にNを加算する）を使って実装していましたが、オフセットが大きくなるにつれて所要時間が増えてしまいました。このクエリではN + m行のレコードを先頭から取得してから m 行のレコードを読み飛ばした結果が返されます。そのため、 OFFSET m の m の数値が大きくなればなるほど無駄な参照が増えるため所要時間が増えてしまうのです。
そこで行の絞り込みを WHERE PK >= n AND PK < m （m はn + N を加算し、次のn にする）で主キーの下限と上限で絞り込むようにしました。これによりインデックスが使われて無駄な参照がなくなります。このようなSQLクエリを書くのは初めてで勉強になりました。
サマーインターンのサブメンター
ラクスルのサマーインターンは社内ハッカソン HACK WEEKの参加チームとして、2~4人のインターンメンバーとメンター1~3人のチームで1週間のチーム開発をします。私がラクスルに興味を持ったきっかけになったのはこのサマーインターンでした。
その時にもテックブログに記事を書いていました（チームメンバーとの合作です）。 techblog.raksul.com
このインターンを通して、ラクスルのサービスを支えるアプリケーションの複雑さ、長期にわたってシステムを運用し改善も同時に行っていく難しさに興味やおもしろさを感じたのでした。
そのため、何かしらの形で今年のサマーインターンにも関わりたいと思っていました。このサマーインターンのメンターに同じ開発チームのエンジニアの方がなったこともあり、今年はサブメンターとして参加させてもらいました。
昨年との違い
昨年のサマーインターンは1週間フルリモートで実施されましたが、今年はオンサイト・リモートのハイブリッドでした。全体の様子については以下のイベントレポートが詳しいです。 recruit.raksul.com
昨年はVisual Studio CodeのLive Shareを使ったペアプログラミングや、発表会後のGatherでの懇親会などがあり、リモートでも不満を感じることはなく、とても充実したインターンでした。
そのサマーインターンが今年はオンサイトの要素も加わりさらに充実したものになったのではないかと、サブメンターとして参加しながら感じました。大きなディスプレイにエディタを映して議論をしたり、オフィスの近くでランチをしたりなど、振り返ってみるとラクスルでの働き方を5日間に凝縮してサマーインターンの参加者の方々は体験できたのではないかと思います。
サブメンターとして
今年はサマーインターンの参加者ではなく、サブメンターとしてサマーインターンに関わりました。サマーインターンの実施前にテーマの検討をメンターの方と一緒にしたり、5日間という短い期間でもスムーズに開発が進むように開発環境構築の手順を準備して、本質的ではない落とし穴を埋めておくなどできるだけサポートにまわることを心がけていました。
また内定者という、サマーインターンのインターン生とある意味もっとも近い立場なので社員のメンターの方との橋渡しができたのではないかと思っています。
入社後の来年はメンターとしてサマーインターンに関われたらいいなと思っています。
おわりに
今回実装した同期タスクは徐々にテスト環境で動きだしています。このタスクを実装する過程でActiveRecordやMySQLについての理解が深まりました。この記事では省略していますが、2.の処理では複雑なSQLを書いてレコードを修正しています。このような経験は普段の大学生活では経験できない貴重な経験でした。
また来年4月の正式入社の前にラクスルのドメイン知識を学んだり社員の方々と交流でき、ラクスルで働く解像度を高められました。来年の4月の入社が楽しみです。
ノバセル
宮本&浅田
初めまして！ラクスル23卒内定者インターンとしてノバセル株式会社NA(Novasell Analytics)チームに所属している宮本と浅田です。 我々のパートでは直近担当した案件と学びについてざっくばらんに紹介していきたいと思います！
内容と背景
ノバセルではテレビCMの効果を可視化するノバセルアナリティクスというサービスを提供しています。このサービス上でCMの各種効果データを表示するためには、裏で広告主毎に計測するデータや評価したいCM素材などの準備をする必要があります。こうしたオペレーションは基本的にエンジニア作業であり、大きな負担となっていました。
そこで、様々なオペレーションをエンジニア以外のメンバーが独力で実施出来るようなシステムを開発することにしました。これによって、エンジニアのオペレーション対応コストを削減し、より機能開発に専念できるようになることが期待できます。
我々が担当したCM動画素材のアップロードとサムネイルの自動生成は、上記オペレーション改善に関するシステムにおける一機能となります。
実装
実装した内容としては、以下になります。
- ブラウザ上からS3署名付きURLを用いてCM動画素材をS3にアップロード
- EventBridgeを用いて任意のS3バケットにオブジェクトがセットされたことを検知
- イベントを検知してサムネイル生成、保存を行うLambda関数を実行
- サムネイルの生成、保存が成功したタイミングでサムネイルの生成状況を管理するRDSのレコードを更新
フロントはVue.js、バックエンドはRuby on Rails、AWS CDKを用いた各種AWSリソースの定義にはTypescriptを、そしてLambda関数の実装はPythonを利用しました。
実装してみての学び
我々は共にAWSを触ることがほぼ初めてということもあり、各サービスに対する理解に始まり権限管理や設定に至るまで四苦八苦しました。特に一番最初に実装したブラウザからの動画ファイル直接アップロードに際しては、S3からのエラーレスポンスが非情にも一行かつ問題解決における情報としては非常に簡素な（我々の勉強不足なんですが、、）ものだったことで大変苦しめられました。
一方で、様々な設定の見直しや実装コードを修正する過程でドキュメントや記事を貪り読んだことで、食わず嫌いによるAWSアレルギーを克服し「AWSナニモワカラナイ」から「AWSチョットワカル」に変遷する大きな一歩を踏み出せたのではないかと思います。また後続のタスクにおける新しい知識のキャッチアップに際しても大きな変化があったなと感じます。
まとめ
インターンを始めて宮本・浅田各々9ヶ月、7ヶ月ほどになりますが、日々新しい経験・知識を得ることができ大変充実しています。入社まで約4ヶ月ほどですが、即戦力となれるように日々研鑽していきます。
小川
初めまして！ラクスルの23卒内定者の小川です。2022年の10月からノバセル株式会社のノバセルトレンドチームでサーバーサイドエンジニアとしてインターンをしています。
23卒内定者インターン参加記としてトレンドチームでの約2ヶ月のインターンを通してやってきたことをご紹介しようと思います。
Rustでの開発
トレンドチームではサーバーサイドの開発にRustを使用しています。その中でも私は細かなバグ修正やAPIの変更などを主に担当しました。
私は以前Golangを使っていたので静的型付けの言語に抵抗はありませんでしたが、最初はRustの所有権やライフタイムの概念に苦労しました。ペアプロをしていただいたり、Rust by Example を合間に進めることで徐々にキャッチアップしています。
まだまだ理解しきれていないこともありますが今後もタスクを進めたり、The Bookに挑戦することでより理解を深めてRustを使いこなせるようになりたいと思います。
業界カテゴリの並び替え
ノバセルトレンドは競合他社のテレビCM「効果」を可視化するサービスです。興味があるブランドと比較したい競合ブランドを選択し、それぞれのテレビCM効果を可視化できます。
そのブランドを選択する際に業界カテゴリでグループ化された中からブランドを探すことができるのですが、この業界カテゴリのリストは「その他」が中途半端な位置にあったり、似たような業界カテゴリ（e.g. 「食品」と「菓子」）が離れていたりと特定のカテゴリが探しにくい状態でした。そのため業界カテゴリを適切に並び替えられるようにしました。
ノバセルトレンドではテレビCM「効果」の分析データをアプリケーション上で利用するため、DWH(Data Ware House)のSnowflakeからRDSへリバースETLをしています。具体的にはSnowflakeからS3にデータをCSVとして出力し、RDSへインポートしています。
先日公開された記事にこれと関連する内容のものがあるので是非こちらもご覧ください。
そのため今回のタスクでは以下のような作業を行いました。
- Snowflakeの該当Schemaに並び順カラムを追加
- SnowflakeからS3に出力する値の設定に並び順カラムを追加
- rds-loaderでRDSにインポートする値の設定に並び順カラムを追加
- RDSの該当テーブルに並び順カラムを追加
- サーバーサイドで並び順カラムをRDSから受け取り、フロントへ渡す
- フロントで並び順カラムを受け取り、それを元にソートして表示
影響範囲が予想以上に大きかったり、Snowflakeではロールの設定によってSQLの実行ができない、本番環境に誤ってSQLを流してしまったりと様々なトラブルがあり大変なタスクでしたが、ノバセルトレンドでのDWH〜フロントエンドまでのデータの流れを理解できたのでとても良い経験でした。
様々な人に助力いただき乗り越えられたタスクだったので今後はこれを糧に頑張っていこうと思います。
まとめ
初めてDWHを触ったり、Rustでコードを書いたりとインターンとして働き出してから2ヶ月ほどですが様々な新しい経験ができてとても充実しています。
一方でテレビCM放映のドメイン知識が足りなかったり、コードを書くのに手間取ったりと自分の知識・能力不足を感じる場面もあります。
インターンでコツコツと成長していき、正式入社した時にスタートダッシュを切れるよう邁進していきたいと思います！
ハコベル
堀崎
はじめまして！ラクスル23卒内定者の堀崎です。今年の8月から週2,3の頻度でインターンシップに参加しています。インターンシップではハコベルDPO（Delivery Planning Optimiization）チームに所属し、主にサーバーサイドの開発に携わらせていただきました。
インターンシップを通して、モダンな開発スタイルや配送計画最適化アルゴリズム、物流ドメインの知識を学んだので、私のパートではこれらの学びを共有したいと思います。
Golang, GraphQLを用いたサーバーサイド開発
DPOチームは配送計画最適化に取り組むチームでサーバーサイドの実装言語はGolangやPythonを使用しており、下図のようなマイクロサービスの構成になっています。
インターン期間ではフロントエンドとGraphQLで通信するバックエンドの開発に主に携わらせていただくことになりました。
配送計画最適化のプロジェクト自体はまだリリース前なので詳細は省きますが、リリースに向け必要となる機能をスクラムでゴリゴリと開発していました。
普段は主にRuby on Railsを触っておりGolangでの実装には不安がありました。さらに、gRPCやGraphQLも技術的に知っているだけで触ったことがありませんでした。技術的な不安を感じながらインターンを始めましたが、チーム内（会社全体）に浸透しているモブプロ文化により、リアルタイムでコミュニケーションを取ることができ、技術的なキャッチアップを円滑に行うことができました。
ハコベルにおけるモブプロの取り組みはこちらの記事で詳しく書かれているので是非ご覧ください。
普段Rubyを触っていたこともあり、Golangのシンプルな構文とその書き心地には驚かされました。
また、クリーンアーキテクチャ・DDDを採用しているので、チーム内でモデリングや実装の方針を決めるための議論が不可欠になる機会も多くありました。これらもモブプロ中に活発に議論を行うことができ、問題を一人で抱えて詰まってしまうこともありませんでした。
適宜質問できるモブプロのおかげで、先輩のフォローを受けて各技術の理解を深めることができ、インターン中は常に学びが多かったです。
配送計画最適化アルゴリズム開発
配送計画を作成するためのアルゴリズムを回すにあたり、データ整形の効率化・リファクタリングを行いました。
アルゴリズムを回すためにはお客様から商品や利用車両の価格表などのマスターデータを頂き、事前にデータベースに登録しておく必要があります。しかし、頂くデータ形式はお客様によって変わってくるので、私たちのサービスのデータベースに投入してアルゴリズムを回すためにはデータの整形作業が必要不可欠になります。この作業にかなりの時間を割いていたので、GASでスクリプトを用意しデータ整形を効率化しました。
また、お客様に最適な配送計画を実現するには、最適な配車計画の設定をお客様ごとに切り替えて、アルゴリズムを実行できるようにする必要があります。しかし、当初のプログラムはプロトタイプとして動くことを優先して作られていたため、制約設定を複数のお客様で再利用できる共通のロジックとして注入するには困難を要していました。そこで保守しやすいアプリケーションの実現のために大規模なリファクタリングを現在進行形で行っています。
物流倉庫への訪問
リリース後の最初のユーザーとなるお客様の倉庫へ伺いヒアリングさせていただく機会があり、インターンの身でありながら参加させていただくことができました。
実際の配送計画の作成作業を見学させていただきましたが、手作業が多く配送計画のロジック自体は担当の方の頭の中にあるので、事前に聞いていた以上にかなり属人性が高いと感じました。
インターン当初は物流ドメインの専門知識のキャッチアップにかなり苦労していましたが、実際に訪問し見たり聞いたりすることで、物流ドメインの解像度が一気に高まり開発をスムーズに行えるようになりました。現場を見て学ばない限り、得られない知識・課題感が多くあることを体感し、ラクスルスタイルのひとつであるRealityの重要性をひしひしと感じました。ラクスルスタイルについてはこちらを参照してください。
まとめ
インターンに参加して3ヶ月程度ですがモダンなアーキテクチャに挑戦する中で技術的に成長できているなと強く感じています。
属人化している配送計画のロジックをアルゴリズムに落とし込み、使いやすいアプリケーションを開発するという複雑な課題に取り組んでいる環境は、すごく刺激的で楽しく、インターンに参加して本当によかったです。
おわりに
以上、各メンバーからの振り返りでした！ラクスルの内定者インターンの雰囲気は伝わったでしょうか？ ラクスルの2022年アドベントカレンダー はまだまだ続きます！
