ラクスルのエンジニアって何をしているの?

昨年の10月にラクスルに入社し、3月よりCTOに就任した新米エンジニアの泉です。

最近スタートアップ界隈のビジネスパーソン、飲食を経営されている方など、何気なく出会った人に「あ!ラクスルさんなんですね!実は私も(チラシ|名刺)刷ってます!」と突然「お客様」に遭遇してヘコヘコしてしまうことがありますw。嬉しい限りです。

CMなどもガッツリ力をいれているのもあって、ようやくエンジニアの方でも最近「CMで見ました」「名前は聞いたことはあります」と言っていただくことはあるのですが、さすがに個人でチラシを100部印刷したいといったニーズはなかなか訪れず、比較的サービスに触れる機会は少ないためか、よく「え?ラクスルってそんなに技術に力入れてるんですか?」とか「ラクスルのシステム部って何開発してるの?」と聞かれます。

というわけで、そもそも「ラクスルのエンジニアが何をやっているのか」というお題で少しご紹介したいと思います。

ラクスルのサービス

raksul.comを見ていただければ大体お分かりいただけるかと思いますが、ラクスルはネット印刷通販を行っております。あまりピンと来ないかもしれませんが、世の中周りを見れば、名刺、封筒、ポスター、冊子、中吊り広告、財布の中のカード類、雑誌、おやつや製品のラッピングから、街頭で配っているチラシまで、印刷物で埋まっています。印刷の市場規模は6兆円と言われていますがさほど意外でもないくらい世の中は印刷物であふれています。さすがに雑誌や、おやつのラッピングまでは取り扱っていませんが、ラクスルでは名刺、チラシ、パンフレット、冊子、めずらしいものではうちわや箸袋など約20品目の印刷物を扱っています。利用者の方は、品目と仕様(例えば、大きさ、紙の種類や厚さ)・納期・部数等を選択し、印刷データを入稿し、支払いを済ませると、数日後に印刷物が届く。簡単にいうとそんなサービスになっています。

利用者の方にしてみると、ラクスルで注文するとラクスルから届く、という風に見えるのですが、ラクスルでは自社で機械は持たない、いわゆる「ファブレス」でビジネスをしているので、印刷はパートナーの印刷会社にお願いしています。基本的に印刷会社の非稼働時間を活用して印刷しているので、利用者の方には高品質な印刷をより安く提供し、印刷会社の方にとってみれば非稼働時間を有効活用していただくと、まさにWin-Win-Win。

昨年の12月からは、ハコベル(hacobell.com)も立ち上げドライバーの非稼働時間を利用したネット配達のサービスも立ち上げております。前回のブログは主にハコベルの話だったので今回はネット印刷のラクスルの話を中心にご紹介したいと思います。

ラクスルの技術的なチャレンジ

では、ラクスルのエンジニアは何をしているのかというと、当然raksul.comのECサイトを作るのもありますが、様々な技術的なチャレンジに取り組んでいます。

例えば商品マスター。冒頭で約20品目と上げましたが、利用者が注文をするときは、品目の選択(例えばチラシなのか冊子なのか)だけでなく、チラシの場合だと紙のサイズ、紙種、厚さ、特殊加工(折加工・PP加工・ラミネート)等、これらの要素が一つでも変わると、当然値段も変わります。つまり一意の価格を決定するまでに、1品目に対して十数万のプライステーブルが必要となり、さらに納期と部数でも単価が変わってくるので、価格のレコードは数百万に及びます。商品価格を管理するチームがこれらを効率良く管理したり、原価を割って粗利を毀損しないための工夫等、様々な要件に応える必要があります。

発注のメカニズムも非常に複雑です。単純にチラシは印刷会社A、名刺は印刷会社B、と品目が決まれば印刷会社が決まる、という簡単なロジックであれば良いのですが、 品目だけでなく例えば折り方を含めた細かい商品仕様まで見ないと本当に印刷会社が対応できるのかがわからないため、ロジックの複雑性は増します。さらに商品仕様さえ見れば全て判定できるか、といえばそれも違い、生産側の稼働スケジュールも関係しますし、最近だと「◯◯地方向けの注文は別の会社へ発注」と、注文の届け先の判定も必要になったり、これらを臨機応変にビジネスユーザーが設定するだけで動かせるように、ルールエンジンの導入の検討をはじめたりしています。

「印刷」という一見地味に聞こえるドメインでも、様々な技術的な課題解決が必要とされています。特に注文数・売上が拡大する中、ちょっとしたミスでも大きな事故につながるので、ラクスルのビジョンでもある「仕組み化」は極めて重要です。

ラクスル流、技術負債との向き合い方

もちろん、ラクスルのエンジニアが向き合うのは、興味深い技術課題だけはありません。

ラクスルは、おかげ様で非常に幅広い利用者の方にお使い頂いておりますが、創業時代から7年も経つソースコードの上に成り立っているので、技術負債とうまく付き合っていかないといけません。「技術負債」なんてスタートアップあるあるですが、あまりにも規格外の技術負債のため、今年ラクスルに入社したエンジニアの山本にいわせると「味のあるコード」らしいですw。

Facebookのように「半年間サービス開発を止めて、リファクタを行う」というドラスティックなことをするサービスもありますが、ラクスルでは日々「部分的なリファクター」を重ねています。例えば、ある機能を開発している時に、これから変更をかけようとしているソースコードがリファクタした方が良いと判断したら、バックログの計画時に「リファクタのためのタスク」を立てて、その部分のリファクターが終わったら本開発に入る、ということを心がけています。

以前「ウチのコードはほんとヤバイくらい◯◯なんですよ・・・」と現役のGoogleのエンジニアに相談したら「大丈夫だよ。かつてYouTubeもこんなだったから」「えっtまじ!!!」そんな言葉に少し救われながらも、大切なことは「普段からこつこつ改善していく」こと。どの教科書に書いてある当たり前のことをいかに日々やっていくかが重要だと感じています。

  • マジックナンバーをconstに置き換える
  • コード規約を徹底する(一度ファイルを変更する前に自動でリフォーマットをかけてもいいし)
  • リピートしているコードをメソッドに置き換える
  • 大きいメソッドを分解する
  • 等など、、、

仮に、半年間リファクターをしても、その後継続出来なければまた「味のあるコード」に戻ってしまうので。

技術負債は「直す必要がある」からその存在を表すわけであって、停滞しているサービス、あるいは消えゆくサービスなら直す必要もないので「技術負債」なんて存在しない。急成長しているからこそ、あらゆるステークホルダーに求められているからこそ「技術負債」なのです。これはもう闘うしか無い!!

チーム構成、開発の流れ

事業戦略上、割りと流動的にチームは変わっていきますが、現時点ではラクスルには開発部隊が5チームあります。

  • raksul.com を開発する印刷ECチーム
  • デザインや配布のサービスを開発する集客支援チーム
  • raksul.comで受けた受注を生産とのつなぎ込む発注基盤チーム
  • hacobell.com を開発するハコベルチーム
  • サーバーインフラ・社内インフラを開発するインフラチーム

それ以外に、直接開発ではありませんが、アプリケーションサポートを行う「ヘルプデスクチーム」があり、エンジニアに対する様々な問い合わせを一手に引き受け、エンジニアの生産性を超絶支援してくれるチームもいます!

編成はチームごとに変わりますが、スタンダードな構成としては

  • プロダクトマネージャー
  • クリエイティブ
  • フロントエンドエンジニア
  • サーバーサイドエンジニア

という構成になっております。

最近テレビや、ソファー、カーペットが敷かれる「ラクスル工房」ではクリエイティブとエンジニア約20名が、チーム毎に固まって仕事をしています。

仕事の流れとしては、バックログを中心に、スクラム・ライクにレビュー・振返り・計画を2週に一度行い、それ以外の日はスチレンボードに貼ったタスクボードの周りを囲んで毎朝朝会を行っています。

因みに、朝会終了時の集客支援チームの掛け声はオーソドックスに「今日も頑張るぞ。オー!」


さて、色々書きましたが、ラクスルならではの技術チャレンジ、あるいは技術負債に対する姿勢、チームや働き方等、簡単に説明させて頂きましたが、今後もブログで様々な戦いの記録を発信していきたいと思いますので、少しでもラクスルに興味を持っていただければと思います!