はじめに
はじめまして。サーバーサイドエンジニアの藤本です。
ネット印刷サービスであるラクスルを開発・運用しているPBU（Printing Business Unit）チームに所属しています。
本日はRAKSUL Advent Calendar 2021 4日目です。
ラクスルにjoinして、早いもので3ヶ月が経過しました。ラクスルは2013年より開発、保守されているシステムで非常に巨大なシステムになっています。キャッチアップが大変だったのですが、チームメンバーの手厚い協力もあり、ようやく機能追加を行える程度には理解が進みました。
そこで、先日リリースした折りパンフレット・ポスターのお届け予定日指定機能の開発リードをしました。
その中での学びや気づきを記事にしたいと思います。
お届け予定日指定機能とは？
ラクスルではチラシやポスターなど、様々な商品を扱っています。その中でチラシの注文時にお届け予定日を指定出来る機能を約1年前にリリースしました。
チラシのお届け予定日リリースでの反響を受け、今回はポスターと折りパンフレットでもお届け予定日を指定出来るように開発しました。
各商品で指定可能なお届け予定日のリストは私たちが開発・運用しているECシステム側では管理しておらず、別チームが開発している委託先管理・発注システムにAPI経由で問い合わせています。
ラクスルはユーザーが注文しようとしている商品カテゴリ(チラシ、ポスターなど)や商品仕様(用紙サイズや紙の種類など)をリクエストパラメータに含め、委託先管理・発注システムにお届け予定日の問い合わせをしています。
開発をしていく中での気づき
フルリモート下での他チームとのコミュニケーションの難しさ
私は2021年9月にラクスルにjoinしましたが、ラクスルでは当時フルリモート勤務になっていました（チームビルディングの観点より11月より週1出社を開始しています）。
開発を進めていく上で見えてきた課題感
印刷ECのシステムと委託先管理・発注システムが別れている
ラクスルでは開発手法にスクラムを用いており、スクラムチーム単位での開発を行っています。各スクラムの活動内容は共有されるものの、システムの詳細な仕様は把握できていません。
お届け予定日のリストは委託先管理・発注システムから取得しますので、他チームとコミュニケーションをとって開発を進めていく必要がありました。
他チームとのやり取り
入社して日が浅く、リモートでは自チームメンバーとのコミュニケーションが中心になることもあり、他チームのメンバーの人となりをよく知らない中で、コミュニケーションをとるのに心理的な障壁がありました。
そのような状況の中、認識があっているか何度もヒアリングをする必要がありました。
ドメイン知識の不足
ラクスルでは多くの商品を販売しており、それらの属性がソースコード上に定義（ex. 仕上がりサイズのA4の1/3仕上がりは "A4_ONE_THIRD"）されています。サイズや色、パンフレットのおり方などなど。ソースコードに書かれているものがどの商品定義にあたるのかをパッと頭の中で紐づけるのが難しいです。
また、ECサイトと発注システムは異なるシステムですので、ソースコード上での定義が異なるケースがあります。ECサイト側では、A41/3仕上がりは "A4_ONE_THIRD"ですが、発注システムでは、 "ONE_THIRD_OF_A4" と定義されています。このあたりのパラメータの定義の変換を行う必要がありました。
課題解決のためのアプローチ
上記の課題感への対応として、下記を意識して行いました。
他チームを含めたオンラインMTGを設定し、パラメータの認識合わせを実施する
現状を整理し、自チームの認識している内容をドキュメント化することで、他チームとの認識内容に齟齬がないかを確認しました。
また、他チームのメンバーにコードレビューをしてもらうことで、認識にズレがないことを確認しました。
ぐいぐい聞く 🍶
上述したように人柄を把握していない人とコミュニケーションをとっていくのは大変ですが、他チームのメンバーもそれは同じだと思いますので、まず自分からここがわからない、こう考えていますが合っていますか、とコミュニケーションをとるようにしました。
とにかく自分の考えや意思を表に出すことを意識していました。
ラクスルにはCo-Operationの文化があり、チーム外からの質問や相談にも積極的に対応してくれます。
コミュニケーションを取る際には、Slackでのコミュニケーションが活発なので、さらっと聞いてみたり、最近ではhuddle（Slack上の音声会議）も利用してサクッと相談することにしています。がっつり仕様を確認したい際にはGoogle Meetで顔を合わせながらやるようにしていました。
ローカル開発の複雑さ
前述の通り、お届け予定日のリストを取得するには委託先管理・発注システムとの連携が不可欠なのですが、そこでも課題が見えてきました。
開発を進めていく上で見えてきた課題感
APIのリクエストに成功すると、APIのレスポンスを正しく処理できているかの動作確認が必要となります。APIのリクエストに成功しているかどうかの確認が簡単に行えない状況でした。
課題解決のためのアプローチ
ここまで記載した通り、他チームの開発しているアプリケーションに依存する機能となっていますので、動作確認をするためには、下記2点のどちらかの方法をとる必要がありました。
- ローカルに他チームアプリケーションの開発環境を整備する
- 他チームのアプリケーションがデプロイされているテスト環境が存在するので、そこに自チームのシステムもデプロイする
1. の方法は、ラクスルは商品ごとのマスターデータが非常に多く、他チームのアプリケーションを動作させるのにどのデータを投入するかを判断することが難しかったです。Docker環境が現在整備中（詳細後述）なこともあり、環境構築にかかるコストが高くなりそうでした。
2. の方法は、テスト環境では本番に近いデータが用意されており、またラクスルはデプロイが高速で、早ければ5分もかからない環境になっています。認識合わせを事前に行った上でコードを作成すれば、それほど多くのデプロイをする必要もないと想定しました。
そのため、今回は2の手法を選択しました。
将来的にはDockerなどでコンテナ化されており、ローカル環境で開発可能であることが理想ではあると思いますので、コンテナを利用した開発環境の準備を進めています。
💡 ラクスルは2013年に作成されたシステムを、PHPからRailsへの移行作業を行いながら開発・運用しています。PHPとRailsのハイブリッド構成でnginxでルーティングされている箇所も多いため、Docker環境の構築が難易度の高いものとなっています。ローカル環境の代わりとして、1人1台の個人開発用EC2が提供されていますが、今回はデータ投入の手間などを考えテスト環境を使用しました。
まとめ
印刷ECは結構ニッチな領域で、raksul.comは長年保守されたシステムということもあり、聞かなければわからないこともたくさんあるので素直に聞くことが大切だと思います。
ラクスルは企業のカルチャーとしてCo-Operationが浸透しており、コミュニケーションの取りやすい環境にあると感じました。ただ、やはり人となりがわかっていない人とリモートでコミュニケーションをとり、仕様を詰めていくのはエネルギーのいることでした。
今後は出社日を有効活用し、リアルで熱く議論してチームの交流を推進していきたいです 🔥
ラクスルには出社日にチーム間の交流を促進するための取り組みとして、ドリンクやケータリングが提供されています。
写真はいの一番にケータリングに群がるPBUのメンバーたち。
ラクスルではエンジニアを募集しています！
https://recruit.raksul.com/career/engineer/
ラクスルのアドベントカレンダー全編はこちらから
