RAKSUL TechBlog

ラクスルグループのエンジニアが技術トピックを発信するブログです

ラクスルグループ各CTOとエンジニアに聞いた!新卒エンジニアに贈る~スペシャルな一冊

こんにちは、ラクスル広報の和田です。 みなさんは、「心に残るスペシャルな一冊」そんな本に出会った経験はありますか? 今回は、ラクスルグループ各CTOとエンジニアに「仕事のみならず、人生観やキャリアの参考に新卒エンジニアへおすすめできる本」というテーマでスペシャルな一冊を伺いました。

ラクスル取締役CTO 泉のスペシャルな一冊 『Clean Code』・『Clean Architecture』

https://asciidwango.jp/post/171118672245/clean-code
asciidwango.jp

https://asciidwango.jp/post/176293765750/clean-architecture
asciidwango.jp

この本との出会い

Clean Codeは外資金融で働いていたときに先輩のエンジニアから教えてもらったのがきっかけです。Clean Architectureはそのしばらく後ですが、技術界隈で耳にするようになり、RAKSULの現場でもClean Architectureを取り入れ始めたときに購入しました。

こんな方、こんな時におすすめ!

はじめて手に取る一冊というよりは、一通りプログラミングを経験した方におすすめです。その上で読むと、より一層内容が頭に入ってくるため、直面した課題に対する解や考え方が得られると思います。

この本の内容

Clean Codeはコーディングのベストプラクティス、変数名の決め方から、メソッドの組み方、コメントを排除するコーディング記法、テストをしやすくするためのコード、リファクタリングの方法などが学べて、Clean Architectureは設計の原則であるSOLIDや、各機能層の分離の仕方、データモデリング等極めて実践的なユースケースを見ながら学べます。

この本がスペシャルな理由

両方ともUncle BobことRobert C. Martinという有名なソフトウェアエンジニアが書いた本です。学問の延長などではなく長年の現場の経験から体系化した内容で、実用的かつ普遍的な内容なので「一生モノ」として血肉になるような本です!原書も読みやすいので、英語に自信のある方は原書もおすすめです!

ラクスル事業本部CTO 二串のスペシャルな一冊 『プログラマが知るべき97のこと』

www.oreilly.co.jp

この本との出会い

私がプログラマーとして駆け出しの頃に出会いました。Perl や Ruby の開発者コミュニティの場は、アートとも呼べるコードとデモンストレーションで参加者を魅了する凄腕のプログラマーが沢山いますが、そのコミュニティの中で私が最も尊敬する方がこの本に寄稿されたということを知り購入しました。

こんな方、こんな時におすすめ!

これからプロのプログラマーとしてお金を稼いでいこうとしている方におすすめです。

この本の内容

プロのプログラマーとして働くためのヒントがたくさん詰まった本です。

この本がスペシャルな理由

様々なバックグラウンドを持つ世界中の凄腕プログラマーから寄せられた97 + 10本(日本語版のみ)のエッセイは、プログラミングのテクニックにとどまらず、プログラマーとしてのマインドセット、勉強法、また他者との協業の仕方などが学べるため。少し古い本ですが、どれも普遍的な内容なので今見返しても刺さる本です。

ノバセルCTO 戸辺、 同新卒エンジニア 田村のスペシャルな一冊 『達人プログラマー ―熟達に向けたあなたの旅― 第2版』

www.ohmsha.co.jp

この本との出会い

戸辺:エンジニア未経験だったところから、1年間の独学を経て「プログラミングは完全に理解できた」と実感したときに、世にいう達人プログラマーとはどういうことか気になって購入しました。

田村:ノバセルCTO戸辺に人生が変わると勧められたのがきっかけです。

こんな方、こんな時におすすめ!

戸辺: (広義の)プログラマーを志す、すべての方におすすめです。「完全に理解した」となる前のなるべく早い時期にぜひご覧いただきたい。

田村:技術の習得方法や仕事での思考法など、基礎を学びたい方におすすめです。

この本の内容

エンジニアリングに携わる方の、経験に基づく50以上の抽象的な学びある内容やプログラマーとしての実践的アプローチが書かれています。

この本がスペシャルな理由

戸辺:本書を理解すれば、その後のエンジニア人生における成長角度が劇的に変化すると自負しているため。エンジニアとしての悟りの書です。

田村:設計の原則だけでなく、日々の開発の心得なども網羅的に言及されていて、様々な気づきを得られたため。実際に議論をする際の引用元としてこの本を使っているので、アウトプットもしやすかったです。理解が難しいパートもありましたが、実際に開発を通して理解したケースもいくつかありました。そのため、実務との反復学習をしながらこの本の理解を進めています。

ノバセル エンジニア 向平(mktakuya)のスペシャルな一冊 『情熱プログラマー ソフトウェア開発者の幸せな生き方』

shop.ohmsha.co.jp

この本との出会い

学生のとき誰かのブログレビューを読み書店で購入しました。

こんな方、こんな時におすすめ!

キャリアの節目(転職を考え始めたり、新しい役割を与えられたとき、目標設定のとき)におすすめです。

この本の内容

自分自身を商品として捉え、技術やビジネスを学ぶというのは自分の時間を投資すること、そのためには情熱を持ち続けることが大切であり、どのようにプログラマーとして幸せに生きるかが書かれた本です。

この本がスペシャルな理由

「一番の下手くそでいよう」という章に感銘をうけたので。 自分が一番の下手くそになれる環境を意識して選べば、自ずと自分自身のスキルも上がっていく。最初は自信をなくして凹むかもしれないけど、いつの間にか溶け込んで組織の一員になっている。という部分は、いまも私の行動指針となっています。 また、「コーディングはもう武器にならない」「ビジネスの仕組みを学ぶ」といった章の内容はラクスルの行動指針に繋がる部分も多かったため自分にとって特別感のある本です。

ラクスル Director of Engineering, Core Print 加藤一平のスペシャルな一冊 『エンジニアリング組織論への招待』

gihyo.jp

この本との出会い

著者のTwitterでの宣伝を見て購入しました。

こんな方、こんな時におすすめ!

これから開発組織のマネジメントをしていく人、すでにしっかりマネジメントをしている人におすすめです。

この本の内容

「開発組織のマネージメント理論」についてわかりやすく言語化されています。

この本がスペシャルな理由

「開発組織のマネージメント理論」について、理論の理解促進に繋がったのが理由です。個人的に「海外の●●社の成功事例」というような書籍より、実際のエンジニアリングマネージャーという仕事の日本での現場レベルの話が書かれているため、すごく参考になりました。 基本的な仕事の進め方についての話から発展して、複雑な状況に対応していくための「基本的な考え方」の説明のされた章もあり、自分ごととして頭に入ってきやすかったです。

おわりに

ラクスルグループ各CTOとエンジニアに聞いたスペシャルな一冊はいかがでしたでしょうか? 技術書の相性や好みなど、きっとみなさんが置かれている状況によっても心に残る一冊は異なると思います。 駆け出しエンジニアのあなたにとって、スペシャルな一冊と出会うきっかけとなれば幸いです。

ジョーシスのデータ分析チームでの RDS → BigQuery 連携

はじめに

ラクスルグループジョーシス株式会社のデータ分析チームの「麦茶22」です。

ジョーシスは2021年9月にプロダクトをローンチし、2022年2月に Data Analytics Team が発足し、自分は2022年4月にチームに入りました。

チームに参加して初めてのタスクは、データウェアハウスを Single Source of Truth とする分析基盤をつくることでした。背景として、これまではアプリケーションの分析用 DB を Redash に接続して分析していましたが、データソースが増えたことや、クエリ・レポートの数が増えて管理しづらなくなったことがあり、チームの発足と合わせて分析基盤も整えることになりました。

本記事では、このタスクの一貫として行った、 RDS <-> BigQuery 間の連携をどのように構築したかをご紹介します。

前提

ジョーシスのアプリケーションは AWS 上で構築されていて、データベースは RDS を使用しています。

アプリケーションに接続する本番環境のデータベースと、分析用のデータベースが分かれていて、データウェアハウスに繋ぐのは後者です。

また、本タスクの前段階として、ウェアハウス・ETL ツールの選定がしてあり、それぞれ BigQuery と Fivetran に決まっていました。

RDS (分析用データベース) -> Fivetran -> BigQuery

RDS → Fivetran のアーキテクチャを考える

アプリケーションデータを BigQuery に流すために、まずデータベースである RDS と、ETL ツール の Fivetran との連携を考えました。

RDS と Fivetran の連携には大きく分けて、

  1. RDS を直接 Fivetran に連携する
  2. RDS のデータを S3 にエクスポートしてから、S3 と Fivetran を連携する

の2つが考えられました。

はじめは (1) の方法で考えていたのですが、

  • 踏み台サーバーを EC2 に新たに構築・メンテナンスする工数
  • binlog によるパフォーマンス影響

の要因から、(2) の RDS のデータを一旦 S3 にエクスポートする方法を採用しました。

なお、(1) の方法では EC2 を立てずに AWS PrivateLink で RDS と接続する方法も提供されていましたが、Fivetran の最上位プランが必要だったためこちらもコスト面の理由から採用しませんでした。

RDS → S3 のエクスポートを考える

RDS ではなく、S3 のバケットを Fivetran に接続することが決まったので、次に RDS のデータをどのように S3 に移すかを考えました。

こちらも選択肢が2つありました。

  1. RDS のスナップショットをエクスポートする方法
  2. SELECT INTO OUTFILE S3 の SQL を実行する方法

既に RDS の機能として提供されている 1 の方がシンプルに実装できそうでしたが、問題としてアプリケーション DB にはレコードの変更記録を残す数百万件の大きさのイミュータブルなテーブルがあります。

これを毎回エクスポートして Fivetran で同期しようとすると、無駄が多いだけでなく、Fivetran の料金もかさんでしまいます (Fivetran の料金は従量課金で、月当たり何行のデータを取り込んだかにもとづいて計算されます)。

そこで、前回の同期分と今回の同期分の差分のみを同期対象とし、Fivetran では append_only モードを使用することを考えました。このモードでは、名前のとおり既存のレコードは変更せず、新しく同期した分を追記します。

差分更新のイメージ

こうすると、毎回全データを更新するのではなく、新しく追加されたレコードのみをデータウェアハウスに追加でき、利用料金も低く抑えられます。

このとき、下記の通りスナップショットのエクスポートでは、エクスポートの対象をテーブル単位までしか制御できないため、2の SELECT INTO OUTFILE S3 の方法を採用しました。

[Partial] を選択すると、スナップショットの特定部分がエクスポートされます。スナップショットのどの部分をエクスポートするかを特定するには、[Identifiers] (識別子) に 1 つ以上のデータベース、スキーマ、またはテーブルをスペースで区切って入力します。

(https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_ExportSnapshot.html#USER_ExportSnapshot.Exporting より引用)

日次ジョブの実行を考える

AWS 側の最後の工程として、 SELECT INTO OUTFILE S3 を日次で実行するサービスを選定しました。

候補として、

  1. Lambda
  2. ECS タスク
  3. CodeBuild

の3つがありました。

まず、Lambda のデメリットとして15分の実行時間の制限があります。将来的にテーブル数が増えたりジョブが複雑になって実行時間が伸びた場合、アーキテクチャを再度変更するための工数がかかるため、Lambda は採用しませんでした。

また、ECS タスクを採用した場合、アプリケーションのバックエンドの ECS からタスクを実行することになります。

しかし、この ECS は普段は本番環境の RDS と接続しているため、 SELECT INTO OUTFILE S3 を実行するときに接続先 DB を切り替え、再度戻す必要があります。

この設定の変更とテストを考えると、工数が大きくなることが予想され、かつ本番環境に影響する可能性もあったため、 ECS タスクも採用せず、最後の候補の CodeBuild でジョブを実行することにしました。

ここまで決定したアーキテクチャをまとめると、

  • CodeBuild で SELECT INTO OUTFILE S3 を実行し、
  • RDS の各テーブルについて、差分または全てのレコードを S3 にエクスポートする

となります。

アーキテクチャ

Fivetran → BigQuery

以上の AWS の設定が終わり、Fivetran と S3 のコネクタを必要なテーブルに対して作成すると、同期が日次で実行されるようになります。

BigQuery へのデータのロードについては、 Fivetran の最初の設定で既に ETL 先のデータウェアハウスが選択されているため、追加の設定は必要ありませんでした。

コネクタを作成した各テーブルについて、BigQuery 上のレコード数と分析用 DB のレコード数が一致することを1週間モニタリングし、正しく連携できたと認識しました。

さいごに

本記事では、ジョーシスのデータ分析チームで RDS のアプリケーションデータを BigQuery にロードするアーキテクチャを紹介しました。

各 AWS サービスの選定にあたり、思っていたよりも多くの選択肢があったため、最適なサービスの組み合わせを考える点が難しかったです。

なお、ラクスルグループでは AWS インフラはグループ全体のインフラチームが担当しています。各サービスの設定を実際にしていただいたのはインフラチームの皆さんで、アーキテクチャを決定する際もたくさんの助言をいただきました。

RAKSUL TechBlogをリニューアルしました!~ ブログ運営を支える技術 ~

こんにちは、22新卒でラクスル事業本部の灰原です。この度、ラクスル株式会社*1の公式テックブログをリニューアルし、こちらのはてなブログを開設しました! この記事ではテックブログをリニューアルした背景に加えて、GitHub上ではてなブログの記事を管理・レビューする手法について紹介します。

リニューアルの背景

ラクスルではこれまでもテックブログ を運営してきました。 また昨年からはアドベントカレンダー企画も行っています。 qiita.com しかしながら、当時利用していたブログシステムでは社内のユースケースに合わない部分がありました。

  1. レビューのフローが煩雑
    • これまでの運用では、レビューのフローが煩雑でした。例えばNotionに原稿を書いて、それを上司に渡してコメントをもらい、修正が終わったらまた上司に連絡して、というように、レビューイ・レビュアーともに負担が大きいものでした。
  2. 同時編集が難しい
    • 特にアドベントカレンダーの準備期間には、複数人がそれぞれの記事を編集したいことがあります。以前のシステムでは、サイト全体としての変更を追従する方式だったため、システム上で複数人それぞれの編集を進めることが困難でした。

これらの課題が浮かび上がったことから、エンジニアが楽しく書き続けられるテックブログを目指してリニューアルに踏み切りました。

ブログ運営を支える技術

ラクスルは「仕組みを変えれば、世界はもっと良くなる」をビジョンに掲げる企業です。 この度のテックブブログリニューアルにあたって、上記課題を解決するため、有志のエンジニア数名で「仕組みを変える」ことに挑みました。

まず上記課題は、GitHubで記事を管理することで、以下のように解決できると考えました。

  1. レビューのフローが煩雑 --> GitHub上でのレビュー・承認を可能に
  2. 同時編集が難しい --> PR毎に複数人がそれぞれ編集できるように

これを実現するために、GitHub ActionsからはてなブログAPIを利用するワークフローを構築しました (下図)。

記事の作成・レビュー・公開フロー

はてなブログAPIへのアクセスには、blogsyncを使っています。blogsyncについてはこちらの記事で紹介されています。 現状では、社内のユースケースに合わせて機能を追加したフォーク版を使っていますが、今後PRをお送りしてupstreamのものを使うようにできればと思っています。

記事の作成・レビュー・公開フロー

さて、記事の作成・レビュー・公開は、以下の手順で行われます。ポイントは、記事を編集する際、ローカルにcloneしたものを編集する場合と、はてなブログのUIから直接編集する場合があることです。GitHub Actionsのワークフローを工夫して、これら両方に対応できるようにしています。

記事の作成

  1. 執筆者は、はてなブログから記事の下書きを作成する。
  2. 執筆者は、ローカルでスクリプトを実行する。 (編集画面のURLを引数に与える)
    • この時スクリプトは、編集画面のURLからエントリID*2を取得し、それを元にしたGitブランチを作成してgit pushする。ブランチがpushされると、GitHub Actionsのワークフローが発火する。この時ワークフローは、ブランチ名からエントリIDを取得し、はてなブログAPIでそのエントリIDに一致する記事を取得する。また変更内容をステージしてgit pushする。
  3. 執筆者は、上記ワークフローが終了したことを確認して、git pullする。
    • ここで上図の黒い四角で示した3つ (はてなブログ・GitHub・Local Git Repo)で当該記事が同期された状態になる。

レビューと修正

  1. 執筆者は、GitHubでレビュアーを設定する。
  2. レビュアーは、指摘事項をコメントする。
  3. 執筆者は、指摘事項をローカル or はてなブログから修正する。
  4. ローカルから修正を加えた場合、執筆者は、変更をステージしてgit pushする。
    • コミットがpushされると、GitHub Actionsのワークフローが発火する。この時ワークフローは、レポジトリ上の記事をはてなブログに同期する。また変更内容をステージしてgit pushする。
  5. はてなブログから修正を加えた場合、執筆者は、空コミットをしてgit pushする。
    • コミットがpushされると、GitHub Actionsのワークフローが発火する。この時ワークフローは、コミットが空だった場合、はてなブログからレポジトリに記事を同期する。

記事の公開

  1. レビュアーは、指摘事項が修正されたことを確認して、PRをApproveする。
  2. 執筆者は、PRをmainブランチにマージする。
    • PRがmainブランチにマージされると、GitHub Actionsのワークフローが発火する。この時ワークフローは、レポジトリからはてなブログに記事を同期する。

ここで記事が公開されます。複雑そうに見えますが、やっていることは普段の開発でのGit/GitHubの操作とほとんど変わりません。 レビューイ・レビュアーともに使い慣れたGitHubのレビュー機能で、同時編集も気にせずに、ブログを書くことができます。

おわりに

エンジニアが楽しく書き続けられるテックブログを目指して、リニューアルを行いました。 このブログを通して、ラクスルのエンジニアの技術と文化を伝えていければと思っています!

*1:ラクスル株式会社:ラクスルグループは、「仕組みを変えれば、世界はもっと良くなる」という企業ビジョンのもと、印刷、広告や物流といったデジタル化が進んでいない伝統的な産業にインターネットを持ち込み、産業構造を変えることで、より良い世界にすることを目指す企業です。現在ではネット印刷・集客支援のプラットフォーム「ラクスル」、マーケティングプラットフォームを提供するノバセル株式会社、物流プラットフォームのサービスを提供するハコベル株式会社、コーポレートITのサービスを提供するジョーシス株式会社を運営しております。

*2:はてなブログの記事のID

ラクスルでフルリモートインターンをした話

こんにちは、22新卒内定者の灰原です。この記事では、昨年6月末から約半年続けてきた、ラクスル事業本部でのインターンについて振り返ります。

実は私は北海道に住んでおり、今回のインターンはフルリモート勤務となりました。北の大地から画面越しに感じたラクスルの雰囲気と共に、インターンを振り返っていきます!

リリース内容のレビューツール

インターンが始まって始めに取り組んだ仕事は、リリース内容のレビューツールの作成です。開発の背景として、統制の観点から、各チームのPdM (Product Manager)はリリース内容(mainブランチにマージされたPR)を定期的にレビューする必要があります。しかし、該当するPRをGitHubで一つずつ開いて確認するのは大変です。このツールを使えば、対象レポジトリ・期間を指定すると、それに該当するmainブランチにマージされたPRが一覧表示されます。またそのPRのレビューが完了した際には、このツールから各PRに「レビュー済み」のラベルを付けることができます。このラベルがレビュー完了の証跡となります。

このツールはGoで開発しました。私はもとよりGoに慣れ親しんでいたこともあり、機能開発自体はスムーズに進みました。一方で要件やユーザビリティについては熟考しました。まずは、このツールのユーザーであるラクスル事業本部の開発者について知ることが必要でした。このツールの開発を通して、ラクスル事業本部の開発体制や組織構造について理解を深められたことは、新卒入社する自分にとって大きなアドバンテージになったと思います。

現在では、このツールは実際に各チームで運用されています。これは私が初めて仕事で制作したソフトウェアということになります。「自分の手を離れて自分の書いたコードが使われる」というソフトウェアエンジニアとしての喜びを感じる瞬間でした。

生産性可視化基盤

2つ目の仕事は、生産性可視化基盤の構築です。これは開発組織の生産性を計測・可視化するシステムです。このプロジェクトは各チームがデータに基づいた意思決定ができることを目指して開始されました。

AWS CDK・Permissions Boundaryの導入

この基盤はAWS上に構築しており、Lambda・S3・Glueなどのサービスが中心になっています。また弊社ではAWSのリソースをTerraformで構築しており、このTerraformをインフラチームが管理しています。そのためAWSのリソースを変更する場合には、TerraformのレポジトリにPRを送るか、インフラチームに作業を依頼する必要があります。この運用はサーバレスアーキテクチャとの相性が悪く、開発者・インフラチーム双方の負担が大きくなってしまっていました。

この問題はAWS CDKというIaCの仕組みと、Permissions BoundaryというIAMを制限する仕組みを組み合わせることで解決しました。これについては先日のブログ「Permissions Boundaryでガードレールを設けてAWS CDKを安全に使う」でも紹介しています。

Four Keysの計測

「生産性」の指標には、Four Keysを採用しました。Four Keysとは「デプロイの頻度」「変更のリードタイム「変更障害率」「サービス復元時間」の4つの指標のことで、書籍「LeanとDevOpsの科学」やGoogle Cloudのブログ「エリート DevOps チームであることを Four Keys プロジェクトで確認する」で紹介されています。これらの指標の値は、ソースコードや障害チケットを管理しているGitHubや、プロジェクト管理ツールであるClickUpからデータを取得し、それを元に算出することにしました。

計測基盤は以下のようなアーキテクチャでAWS上に構築しました。これは大まかに以下のような流れで動作します。

  1. CloudWatch Scheduled Eventで各種Lambdaを発火
  2. 各種LambdaはそれぞれGitHub・ClickUpのAPIを叩いてデータを取得、それをS3バケットに置く
  3. Athenaクエリで、Glueデータカタログを通してS3バケットに置かれたデータを解析

Lambdaの実装にはGoを使いました。GoからGitHub APIを叩く際にはgoogle/go-github を使うのが定番です。一方でClickUpにはこのようなデファクトなクライアントライブラリがありませんでした。そこで、ClickUpのクライアントライブラリであるgo-clickupを先輩エンジニア達が新たに開発しました!また、このgo-clickupはOSSとして公開しており、コントリビューションもお待ちしております!

ベロシティ計測

Four Keysに加えて、各スクラムチームのスプリント毎のベロシティも計測することにしました。開発チームの生産性を測る方法として、1スプリント毎のベロシティのモニタリングは一般的に行われていることかと思います。ラクスル事業本部では、スプリントごとに計画していた実績値(ベロシティ)と、目標値(コミットメント)との誤差が小さいことを是としています。そこで、ラクスル事業本部での生産性を計測するためには、実績値に加えて目標値も必要です。

ClickUpはスプリント毎にタスクボードを作成する機能があります。つまり、このボードがクローズされた時に、ステータスがCOMPLETEになっているチケットのポイントを合計した値が実績値になります。一方で、ClickUpにはそもそも目標値を入力することができないようですので、ClickUpのAPIから目標値を取得することはできません。

そこで、スプリント毎に、各チームのメンバーからの目標値を教えてもらう必要があります。これには、各チームのメンバーにはタスクボードのDescriptionにマジックコメントを書いてもらい、その内容をClickUpから送られるWebhook経由で取得するという方法を採用しました。この方法であれば、開発者はスプリント期間内にClickUpに情報を書くだけで済みます。

アーキテクチャとしては、まずClickUpからのWebhookをAPI Gatewayで待ち受け、そのHTTPリクエストをLambdaでValidateした後、Step Functionsを起動させます。このStep Functionsの中で各種Lambdaを実行し、S3にデータを貯めていきます。このベロシティ計測機能の開発は、ClickUpのWebhookとの連帯や、Step Functionsの扱いなどで何度か試行錯誤する場面がありました。今思えば、この開発に着手する前にCDKを導入していたことで、かなりの工数を削減できたのではないかと思います。実際、CDK導入後ではインフラチームへの問い合わせはほとんどなくなりました。

可視化

さて、ここまででFour Keys・ベロシティを算出するためのrawデータを蓄積することはできました。これらのデータに対してクエリを実行して可視化するために、Redashを使いました。Redashから発行するAthenaクエリや可視化の設定は、先輩エンジニアであるIchijimaさんにやっていただきました。

そして運用へ

この生産性可視化基盤もまた、各チームの振り返り(retrospective)などで使われています。今後、運用時間が長くなるほどデータも多くなり、さらなる分析ができることが期待されます。

また、この基盤は自分がゼロから組んだシステムの中で一番大きなものでした。この先も使われることを想定した設計や、CDKを初めとした技術調査など、今後のエンジニア人生にとってプラスになるであろう経験でした。

内定者インターンを振り返って

このインターンを通して、4月からの仕事のイメージがグッと深まりました。例えば各チームのSlack channelを見たり、朝会に参加したりする中で、そのチームの雰囲気や個人個人のひととなりを感じることができました。特に開発に関わる相談や、障害対応時のやりとりなどを見ることで、ある種のケーススタディのように学びを得ることができました。

冒頭でも述べましたが、このインターンは北海道からのフルリモート勤務でした。リモート勤務ではコミュニケーションの不足などが問題視されがちです。しかし、私のtimes (Slack上の、個人的なつぶやき用のchannel)に社員の皆さんが反応してくれたり、毎週の社内勉強会で他のチーム・事業部の方と会話ができたりと、リモート故の心細さのようなものは感じずに働くことができました。

私はラクスルに対して少し堅い印象を持っていたのですが、皆さんメリハリをつけて働いていて、Slack上でも和気あいあいと話す場面もあります。下の画像は某チームのテックリードがPdMのために作った似顔絵チョコです。

半年近く続けてきたインターンも終わり、いよいよ4月からは本格的にラクスルで働くことになります。今度は社員として技術的なアウトプットをしたいと思いますので、お楽しみに!

Final Entry: Looking back the year 2021

Merry Christmas!

さて、RAKSULのアドベントカレンダーも最終日を迎えましたが、運営チームから締めを仰せつかりましたので、微力ながら2021年の振り返りという形で、今年取り組んだことを話しながら今後テック集団として我々がどこにいて、どこへ向かいたいのか?そのあたりを少し共有できればと思います。

2021年の振り返り

気づけばもうRAKSULに入社してから7年目。歳のせいか1年が年々短く感じるようになってきて、今年もあっという間に過ぎ去ってしまいましたが、世の中も、RAKSULも様々なことが起きました。

年始はコロナ真っ只中からの出発。春からようやく日本でもワクチン接種が始まり、夏には1年遅れで東京オリンピック・パラリンピックも無事に開催されました。秋には、デジタル庁始動、新内閣の発足など政府の動きが目立ち、年末に差し掛かるとようやく収束しかけたと思ったコロナもオミクロン株で再燃。

経済でいえば、圧縮された需要が一気に開放され過去最高益を記録するほど回復路線に乗れたトヨタのような企業もあれば、飲食やツーリズムなど相変わらず厳しい状況が続くセクターもあり、昨年に続き環境変化に適応できたところとそうでないところで二分化がさらに進んだように思えます。

せっかく需要が回復傾向にあるセクターにおいても「半導体不足」に代表されるようにサプライチェーンの回復の遅れが起きたり、それを支える貿易・物流インフラが春先の「スエズ運河封鎖事故」に足を引っ張られたりと、なかなか思うように回復が進まず、もどかしい状況が続いてます。

資本市場も「サステナビリティー」が大きなテーマとなり様々な動きがありました。11月に英国グラスゴーで開催されたCOP26では、これ以上先送りできない温暖化に歯止めを効かせるため、CO2の排出に対して一層厳しい達成目標が敷かれ、火力発電の抑制や、化石燃料を主としたビジネスも大きくシフトせざるを得ない状況となりました。

行き過ぎた資本主義が招いた諸問題の張本人とも言える投資銀行やフィナンシャルセクター全体が、急に手を返したようにグリーンな企業広告を連発しているのを見ると、非常に皮肉だなと思いつつ、これを糧に新しい勝機を見出しているアントレプレナーを見ると、これも人類の進歩の通過点だと割り切って、ポジティブに頭を働かせることのほうが重要なんだろうと思ったりしてます、(苦笑)

そんな中、RAKSULも様々な経済変化に揉まれつつも高い成長率を堅持し、売上高で30.4%、売上総利益で前年比29.5%増という好成績で第1四半期を終えました。

(参考:https://ssl4.eir-parts.net/doc/4384/ir_material_for_fiscal_ym/110767/00.pdf

昨年資本参加したダンボールワンへの技術投資が始まり、アカウント連携などの共同機能開発や、RAKSULのエンジニアが出向して検索機能のオプティマイゼーションの開発を推進したり、ペライチの社外取締役にハコベルのシステム開発部長/VPoEが就任するなど、グループ企業との協業・参画も本格化してきました。

また、ESGに対する意識も高まり、例えばハコベルで「CO2排出量の算出」の可視化をしたり、ラクスルも「付け合せ」のロジックの改良で紙の無駄の削減に取り組む等、まさにデジタルテクノロジーによって環境問題にアドレスし始めたことは、まだまだ序章ではあると思いますが、非常に意義のある成果だと思っています。

自分がこの1年取り組んだこと

自分はと言うと、組織開発の領域では「エンジニア組織のグローバル化」と、事業開発の領域では「新規事業の立ち上げ」に集中しておりました。

エンジニア組織のグローバル化

年初からインドの開発チームに自分もPO兼フロントエンドエンジニアとして加わり、新規事業に向けた初期のエンジニアリングチームの立ち上げを行いました。アジャイル開発やソフトウェアに関する共通言語は問題なく伝わりますが、細かいニュアンスや仕事のスタンス・価値観など日本とは大分異なるダイナミクスがあり、戸惑うところはありつつも、インドの拠点長との連携や日本のメンバーの理解も得ながら前進し、今においては日本と変わらず、かなりスムーズに開発が進むようになったと思います。

少し話を巻き戻すと、RAKSULのグローバル化は2019年10月から本格始動しました。実は、同月に開かれた取締役会にて初参加いただいた社外取締役の宮内さんから開口一番に「なぜRAKSULはエンジニア組織のグローバル化に取り組まないのか?」という問いが立てられたことがきっかけでした。

エンジニア組織のグローバル化の必要性を、宮内さんがいの一番で指摘されたことも衝撃でしたが、年々激化するエンジニア採用の構造的な問題をなんとかしないといけない、というのは自分が持っていた大きな経営課題でもあり、宮内さんの問いは実は大きな後押しにもなりました。

気づけばエンジニアの外国籍メンバー比率はわずか2年で10%程度から36%にまで拡大し、現在RAKSULにある20開発チーム中、普段から英語で仕事をするチームおよそ半分。ベトナムもこの2年間で9名から31名に組織が拡張され、当初はサーバーサイドエンジニアが中心でしたが、今はフロントエンド・PdM、加えてシニアメンバーの参画も進み、この勢いでいくと2~3年内には全体の6割以上が外国籍メンバーになると思います。

もちろん国外拠点への投資だけなく、国内においてのグローバル化も重要なポイントとして捉えています。上述の通りミックスチームをより成立させるため、RAKSULでは専任の英語教師が2名体制で英語力の強化を担っており、よくエンジニアがひぃひぃ言いながら業務時間外で英語の宿題を間に合わせているのをみかけます(笑)。その甲斐もあってか、半年スパンでみると「え?急にこんなフレーズが会話に出てきたぞ?」とか、英語がほとんど話せなかったメンバーが妙に自信を持ってHack Weekのプレゼンを英語でしたり、Slackでバンバン仕事を進めているのを見ると「英語がネックじゃない、意思がネックなんだ!」と改めて思わされます。TVCM事業のノバセルでは日本語を話せないメンバーの国内採用さえも、チャレンジとして積極推進していたり、国内のグローバル化もすごいスピードで変化しています。

先日、マネーフォワードCTOの中出さんがエンジニアブログで「エンジニア組織の英語化」を積極的に推進されており「世界中からエンジニアの採用をすすめるという方針は不可逆」「英語で仕事ができるようになることは、将来の選択の幅を広げ、市場価値をあげる機会につながる」といった考えを拝見しましたが、この考えには自分も大賛成で、日本のソフトウェアエンジニアがグローバル環境で働けることにはキャリア上非常に意味のあることで、その後のオプションを広げる大きなきっかけになると思います。

このトレンドから読み取れるように今後日本のソフトウェアエンジニアにも大きなシフトを迫られていると思います。今思うと、楽天がとった戦略は10年のスケールで見れば大正解で、今や半数を超えるエンジニアが外国籍メンバーで構成されていることは、経営上非常に大きな優位性になっていることは言うまでもありません。もはやその戦略は異端の発想ではなく、マネーフォワードはじめ、ビジョナルやメルカリもエンジニア組織のグローバル化を進めており、日本のテック企業のエンジニア組織のグローバル化は戦略上必要不可欠だと言えるでしょう。

また今後グローバルに向けたサービス・プロダクトが生まれるのも、まさにここがベースになると見据えており、ますますこの戦略の重要性はRAKSULにとっても大きなものになると考えます。

新規事業の立ち上げ

もう一つ大きく関わっていたのは「ジョーシス」の新規事業の立ち上げでした。9月に発表された「ITデバイス & SaaS 統合管理プラットフォーム」と称したこのサービス、これまで印刷・物流・TVCMといった産業に対してバーティカルな路線とはまた少し違ったターゲットに向けたプロダクトとなります。

DX・リモート時代のIT管理者の業務はますます複雑化し、デバイスやSaaSアカウントの管理工数も増大。あるリサーチによると海外企業一社あたりが利用しているSaaSは平均80にも及ぶと言われており、その波は日本でも着実に押し寄せてきています。

そんな中、ありがたいことに、ローンチ当初からかなり反響があり、カスタマーサポートに寄せられる機能開発要望や改善要望の声をほぼ毎日いただきながら、急ピッチでブラッシュアップしております。

つい先日は「シャドーID(隠れID)」の管理機能をリリースしました。様々なアプリケーションから集積したデータから「従業員台帳では認識されていないID」を可視化することによって、不要になったアカウントの削除を行うことができます。我々の調査では、一社あたり平均100個ほどのシャドーIDが知らずにSaaSアプリケーションに蓄積され大半の企業がこの実体を認識していないのではと考えております。コストダウンはもちろん、管理の対象から外れているアカウントを認識することで事前にセキュリティーリスクの低減にアドレスできると考えております。

(「おっと、こんなところにもShadow IDが隠れてやがる!」の図)

先日21日の開示で新規事業である「ジョーシス」のスピンオフについて報告しましたが、今後さらに当プロダクトへの投資をスピードアップして行えるように事業基盤・組織基盤を強化していく予定です。

今回のアドベントカレンダーでは「ジョーシス」のインドチームからもいくつか日印のコラボレーションに関する記事が投稿されています。日本とインド開発チームのコラボレーションから生まれたこのサービスは、チームワークを成り立たせるための数々の工夫をこらしてきたことはもちろん、まさに構想からローンチまで一貫して「クラウド上」で実現され、数年まえでは想像することさえできなかった特異な環境で生まれた事業です。

余談ですが、この一年、クラウド上で新たな事業や組織が0から作られるのを目の当たりにしていると、ふと「カイシャの実体って一体何なのか?」と不思議に思うことがあります。(もちろん会計上の「主体」としてというのは別としてですが)

本質的には「会社」に限らず、あらゆる組織は、所詮人間の作り出した「概念上の定義」でありもっと言ってみれば「虚構」に過ぎない。我々はぼんやりと認識している実世界に境界線を引いて名前をつけることで、かろうじて仮想的に実体があるように認識しているだけなんですが、こうもクラウド上でプロダクトもシステムも組織も事業もすべてクラウド上で作れるようになると「会社の実体」は、ますます「人のつながり」とそれを可能にする「仕組み」や「共通の価値観」が本質なのだと感じます。

マネジメント体制・組織文化・新卒採用の強化

他に取り組んでいたこととしては、マネジメント体制・組織文化・新卒採用。これだけ組織が大きくなるとマネジメントや組織文化を強化したり、新卒採用を加速させることで組織の新陳代謝を一定促すことも重要。

マネジメント体制については、数年前からEM(エンジニアマネージャー)の職種をオフィシャルに設置し、新たに任命したマネジメントメンバーのトレーニングなどに力を入れてきました。HoE・VPoE・EMを中心にメンバーの評価はもちろん、コンディション把握、モチベーション管理、昇格計画、機会設計などに責務をもち、その結果エンジニア組織は低い退職率を維持しており、直近のアンケートでは8割以上のメンバーが現在のチームやポジションに満足しているとの回答もあり、今後もこの状態をしっかり維持したいと思います。

組織文化についてはChief Culture Officerのメンバーと連携し、今年で7回目になるRAKSUL Vision Day(全社合宿)や、社内の組織文化の明文化、「Slack Etiquette」などに取り組み、よりグローバル、より多様化する組織の中でメンバーが最大成果が出せる環境を作れるような活動を行ってきました。RAKSULは元々「メンバーの自律性を信じ、マイクロマネージはしない組織文化」である反面、「放任主義」「サバイバーシップ主義」と言われる側面もあり、来年に向けてはそういった習慣を変化するような方向に会社全体を向けたいと思っております。

新卒採用は2017年新卒から組織的に取り組むようになり、早くも今年で7期目。採用チームにかなり力を発揮していただき、今年は昨年の倍にあたる採用計画を立て、年初から採用イベント、サマーインターンの実施等を推進していただいています。はじめは自分・人事中心に2・3名くらいではじめた新卒採用活動ですが、ここ数年でRAKSULの新卒メンバーがどんどん力をつけて活躍する姿をみると、自然と他のメンバーも採用活動に積極的に参加してくれるようになり、ありがたい限りです。

他には、RAKSULエンジニアの恒例イベント Hack Week 2021の開催や、地味にコーポレート・ブランディングの一貫で新ロゴのコンセプトムービーの音楽を作曲したり、「経営と技術」という視点で日経のXTECHの連載記事を書いたり、Shippioに技術顧問として参画させていただいたりと、ランダムに色々な活動してました。

最後に:2022年に取り組むこと・・・あるいはどういう姿勢で臨むか

基本的には2022年に取り組むことは、今年の延長と考えていますが、全社グローバル化、RAKSUL INDIAの組織開発、ジョーシスのプロダクト開発、テック組織としてのカルチャーへの働きかけ、このあたりは個人的にも興味関心の強い領域ですし、会社のこれからの進展に大きく期待がかかる領域なので力を弱めずにどんどん前に進みたいと思っています。

また、グローバル化・他事業化する組織において各組織の遠心力はますます高まると思うので、横軸の部分ではやはりエンジニアの知の共有、組織としての流動性は色々な手段で保ちたいと思います。いよいよRAKSULも時価総額2,000億規模が見える中、エンジニア組織の意識も変化は必至です。

すこし話は変わりますが、先日金融アナリストの知り合いとそれとなく情報交換をしたときに「世界全体の経済的な豊かさが平均的に増したのは良いかもしれないが、CO2の排出による温暖化はもちろん、急成長する各国の急激な動物性タンパク質の消費の増加により、無茶な飼育が生態系へに与えるダメージや衛生面への影響、加えて物流や人の行き来がグローバル化する世の中でこれだけ活発になると、果たしてコロナが収束しただの、オミクロン株が減少したところで、ウイルスに対する脅威はマクロで見れば根本的には何も変わっていないよね」ーそんな話をしてました。

思い返すとSARSやMARS、鳥インフルなどはここ四半世紀の出来事。もちろん人類の長い歴史にあった世界の人口の1/4の命を奪うようなパンデミックのレベルからすれば、規模は全然小さいものの、「脅威」としては最大規模。たとえコロナが去ってもパンデミックに対する警戒は緩められないし、「ニューノーマル」という言葉もだいぶ聞き慣れてしまってさほど反応しなくなってしまいましたが、結局のところ「パンデミックの脅威」は時間の問題でそれを前提に行動するしか無く、コロナを理由に変化が停滞したり、課題を先延ばしにしても無駄に時間が経過するんだろうな、と思ってます。

そういう意味ではグローバル拡張は踏み切ったかと思ったら昨年コロナ到来で二の足を踏みそうになりましたが、いま思えば無理矢理にでも推進してよかったと思っています。

「以前のような状態」なんていつまで経っても来ないだろうし、もはや「前の世界は幻想だ」という覚悟で、新しい環境の中で違うやり方を考えたり、創意工夫をするほうがよっぽど建設的だし面白いと思います。2022年はそんな姿勢で色々な環境変化に戸惑いながらも、楽しく過ごしたいですね!

何だが最後はとりとめのない話になってしまいましたが、皆さん今年も1年お疲れさまでした&Happy New Year!

<今回RAKSUL Tech Blogにてアドベントカレンダーを実施するにあたり、企画・運営・執筆を担当していただいた皆さんありがとうございました!そして読んでいただいた皆さんにも感謝!>