こんにちは。2020 新卒としてラクスルに入社したサーバーサイドエンジニアの宮田です。
今年の 4 月に入社し、印刷のラクスルで印刷発注を支える発注基盤システムの開発に携わっています。
今回の記事では、入社して約 3 ヶ月の間に経験したことについてご紹介します。
リモート入社にまつわるあれこれ
新型コロナウイルスの影響により、ラクスルでは 3 月下旬から全社フルリモート体制に移行しました。
新卒メンバーの入社式もオンラインで実施され、同期との初顔合わせも画面上でした（直接対面できたのはそれから二ヶ月半後！）。そのような状況で新しいチームにジョインするにあたり、一抹の不安を感じたことを覚えています。
そんなオンラインでの入社ですが、メリット・デメリットと、それをどのように乗り越えたかについて振り返ってみました。
メリット：インプットの時間が増える
通勤時間が一時間程度の私にとっては、通勤時間が丸ごと業務上必要な知識のインプットに当てられるようになった点は大きかったです。また、移動にともなう体力的な消耗がないため、業務終了後にも自主的に学習する習慣がついた点も大きなメリット。
キャリアのスタートダッシュとも言える時期に、技術書籍をはじめ言語仕様やシステム仕様などのドキュメントに目を通す時間が多く取れたことは、特に知識面で差を感じる新卒エンジニアにとっては少なからぬプラスでした。
また、定期的な学習の習慣が身についたことは、今後エンジニアとしてキャリアを重ねていく上での財産だと感じています。
デメリット：質問量が減る、ちょっとしたコミュニケーションも減る
とは言っても、やはり非対面でのオンボーディングにはデメリットもつきもの。
特に新卒メンバーとしては先輩社員の様子がわかりづらく、質問への心理的なハードルが高くなってしまいます。対面であれば隣の先輩社員に聞けば瞬時にわかる内容も、コミュニケーションコストが大きいオンラインではなかなか確認できず、無駄に時間を浪費してしまうことも。
また、質問できたとしても Slack などでの文章だけでは細かいニュアンスが伝わらず、git 操作や実装の詳細などで齟齬が生じ、作業に手戻りが生じることもちらほら。
その解決のために「困ったときは Slack でチーム全体にメンション」、「30 分以上悩んでいる内容は Slack で相談するか Google Meet で直接尋ねる」など、個人的にルールを設定して改善につなげました。
また、コミュニケーション量が減ることについてはチームとしても対処しており、Meet による雑談タイムを設定し、交流の時間を用意するなど工夫していました。
このように、オンラインの問題点は少なからず存在したのですが、それらについてはチーム全体で対処してもらうことで、次第に業務に慣れることができました。
メンバーのつまずきはチームで乗り越える！
入社して驚いたのは、エンジニアメンバー同士のコミュニケーション量の多さです。
ラクスルでは、開発で積極的にペアプログラミング、モブプログラミングを取り入れており、エンジニアが一人で悩む時間を極力減らすようにしています。私も入社直後は Meet の画面共有機能によりリモートでのペアプロ・モブプロをやり、タスクをある程度自力でこなせるようになりました。
ペアプロ・モブプロは私も入社して初めて体験したのですが、実装が高速化してタスクの消化スピードが上がるだけでなく、先輩エンジニアの思考過程をトレースすることができ、新人エンジニアにはうってつけの密度の濃い時間になります。集中力フルスロットルで作業するため、終了後はフラフラなのですが...。
このように、入社当時はチーム全体に支えられながら少しずつ業務に慣れていきました。
入社後の開発経験
ここからは、入社以降に取り組んできた開発内容についてお話しします。
印刷のラクスルというと EC サイト開発のイメージが強いと思うのですが、私はその裏側でサプライチェーンの最適化を目指すチームに所属しています。
入社してからこれまで取り組んできた内容は以下の三つです。
1. 印刷発注基盤システムの開発 (Golang, Vue.js)
ネット印刷のラクスルでは、ユーザーから印刷物の注文を受ける EC サイトと、注文内容を各印刷発注先に振り分ける発注機能を分離し、後者を新たなシステムとして切り出すプロジェクトが進行中です。私が入社して最初に着手したタスクは、この基盤システムの API 開発でした。
新たな発注基盤システムでは Go 言語を使用しており、クリーンアーキテクチャの流儀にのっとってレイヤー分けされた構成になっています。ラクスルというと Rails 開発の印象が強いのではないかと思いますが、一部では Go を使用したプロダクト開発も行っています。
主な作業内容としては委託先への商品 ID の通知など実際のユースケースに沿った API の追加や、注文内容を登録する社内向け管理画面の作成(Vue.js)などです。
ネット印刷というとそこまで複雑なことをしていないのでは？という印象を持たれる方も多いかもしれませんが、実際に開発に加わってみると、商品仕様の複雑さや、システムに関わるアクターの多さに悩まされることが多く、特に入社当初はシステムのビジネス的な背景の理解に苦労しました。
現実世界の商業活動をシステムに落とし込む難しさを感じる業務ではありますが、印刷発注の新しいプラットフォームとなるシステムの開発に携わる経験であり、自分の開発経験の大きな糧となっていると感じています。
2. 社内向けシミュレータ管理画面の開発 (Ruby on Rails)
印刷事業部の「最適発注」プロジェクトの一環として、社内向けのシミュレータの社内向け管理画面を Ruby on Rails により作成しました。
最適発注プロジェクトとは、ユーザーが入稿した印刷物を委託先工場へ発注するにあたり、印刷コストを低下させるような注文の組み合わせを数理的に探索する＝「最適発注」をシステム上で確立するプロジェクトです。効果検証のためにシミュレーションを行っていたのですが、従来はエンジニアが手作業で行っていた内容を、新たに管理画面を作成して誰でも操作できるようにすることが目標です。
開発は Web サービス開発のフルコースを経験できる内容で、rails new からはじめて、
- Draper を導入したフロント画面作成
- AWS S3 バケットへのデータアップロード
- 非同期ジョブ実行用のワーカープロセスの作成
- デプロイ用の Capistrano タスクの作成
- CircleCI でのテスト自動化
- Jenkins での実際のデプロイ
などを一通りこなすことができました。
入社前に Web サービス作成の経験がほとんどなかった自分としてはとても教育的な内容で、貴重な経験となりました。
3. 印刷発注最適化ロジックの改善 (Ruby on Rails)
また、上に書いた最適発注ロジックの改善にも取り組みました。
ラクスルでは全国各地の委託先印刷工場から、商品仕様に合わせて最適なコストの委託先を選ぶことで低コストを実現しています。今後、より低コストを実現するために、委託先選定ロジックの精緻化を進めている段階です。
メンテナンスしやすいコードを書くためには、委託先企業や印刷に関わる各コストなどをうまくモデル化する必要があり、オブジェクト指向に基づく設計の訓練になりました。
一連のタスクはまさに現実世界のビジネスの複雑な要件をシステムに落とし込む作業であり、 B to B サービスの開発に携わる醍醐味を実感しています。自分の書いたコードが会社の利益に直結する可能性があり、とてもやりがいのある業務です。
今後の目標
ラクスルが挑戦するリアル産業の課題は、まだまだ改善の余地がある業界の商習慣を技術の力でアップデートするという大がかりなもの。
これらに立ち向かうためには、エンジニア個人として能力を最大化するだけでは限界があると考えており、高い技術レベルと深いドメイン知識を併せ持ったエンジニアの組織が不可欠だと考えています。そこで、エンジニアマネージャとしてそうしたチームを率いる存在になることで、リアル産業の課題を解決することが今後の目標です。
そのために、システムに負債を作らず、開発効率の高いエンジニアに成長することと、チームの経験豊富なメンバーに追いつき追い越すことを目指しています。また、ビジネス上のインパクトを出すために事業貢献にもこだわりたいと考えており、常に自分が関わっている開発のビジネス的な背景を理解することを意識して日々のタスクに取り組んでいます。
おわりに
ラクスルが扱う「リアル × インターネット」の世界は、お堅くてシブいと思われがちですが、これまでインターネットが浸透していない世界に技術の光が当たることでどんな化学反応が起こるのか、個人的にはワクワクの絶えない毎日です。
また、ラクスルでは会社全体としてニューノーマル時代の新しい働き方を模索している最中でもあり、今後どのようなスタイルが定着するかについても大いに期待しています。
私たちと一緒に、新しい時代の産業に変革をもたらしてみませんか？
