膨大な印刷需要を支えるプラットフォーム構築に向けて、ラクスルのシステム全体を根本から見直し、技術的負債解消に向き合う「Raksul Platform Project」。
パート1は、「プロジェクトの目的と発足するまでの歩み」についてご紹介しました。本日のパート2では「プロジェクトが迎えた試練」について振り返ります。
プロジェクトとは？
短期の成長にとらわれずに、本質的な価値を出すことを目的とした取り組みを「プロジェクト」と呼んでいます。プロジェクト発足当時のラクスルは、顧客や現場接点を失っており、長期の”価値創造”へ目が向けられていないという課題がありました。そこで、ユーザーに選ばれる本質的な価値あるサービスを、長期の軸で設計して作りきることを目的としたプロジェクトが始まりました。
チームは、起案者となるリーダーの提案内容に賛同した、部署横断型のメンバーで構成されています。
本プロジェクトの概要
技術的負債解消プロジェクト：Raksul Platform Project（以下RPP）
流通300億規模の印刷需要を支えるプラットフォームへ
プロジェクトメンバー
●水島壮太（執行役員CPO /プロダクトマネージャー）
IBM→DeNAを経て現職。本プロジェクトのリーダー/CPOとしてラクスル全体の開発指揮を行う。
●有澤 高介（エンジニア）
大手IT企業等でアーキテクトとして数々のプロジェクトをけん引したのち、ラクスルに参画。本プロジェクトを設計の要として支える。
●小林 寛武（エンジニア）
大手IT企業にてインフラ/サーバーサイドエンジニアとして活躍後、ラクスルに参画。美しいコードを書くことで社内では一目置かれる存在。本プロジェクトでは認証基盤を主に担当。
●二串 信弘（エンジニア）
大手ISP→事業会社を経てラクスルに参画し、現在は印刷事業の開発をエンジニアリングマネージャーとして牽引。本プロジェクトでは主に商品基盤部分を担当。
●三瓶 広紀（エンジニア）
※次回より登場
ヤフーを経て2018年4月に参画。本プロジェクトでは主に決済基盤部分を担当。
技術的負債解消プロジェクト：RPPにおける試練
水島を中心とした「最強のチーム」でスタートした技術的負債解消プロジェクトですが、ここまでの道のりは決して簡単なものではありませんでした。特に印象に残っている２つのエピソードをご紹介します。
決済システムは全体像を理解するのに一苦労
水島：ラクスルのお客さまは基本的に法人の方なので、いわゆるB2B決済システムをつくります。ただ、法人に多い請求書払い対応などは、個人決済では主流のクレジットカード決済などと概念が大きく異なり、対応したことがある人でないと理解するまでに時間がかかります。
三瓶：決済システムと一口にいっても、その下には決済代行会社のシステムとの連動があり、それ以外に、直接売掛、銀行振込、コンビニ払いなどもあって…。それぞれのシステムは古くからあり、かつ複雑に入り組んでいたため、そこをうまく吸収して、途中で止まらないように、ステータスの不備が起きないようにと、考えないといけないことはいくらでもありました。私は入社直後にこの部分を進めていたのですが、概念を完全に理解するまでに２ヶ月くらいかかりました。
有澤：複雑なものは一気にやるのではなく、ニーズが高そうなところから少しずつ手を付けていきました。まずは主要な決済方法からリリースしていくことで、既存システムが動かなくなってしまうリスクを軽減、さらに新しいサービスにも決済システムを活用することに成功しました。
決済基盤部分を担当した三瓶
ようやく日の目をみた「商品基盤構想」
二串：思い出深いのは、マイページのリニューアルです。認証基盤ができたので、新しくマイページを作り直そうということになったのですが、めちゃくちゃつらくて…。ラクスルには商品カテゴリーが80種類あり、それぞれにサイズ・印刷スタイル・紙種・加工のオプションなどがあります。マイページに商品仕様を表示させることができるまでに２〜３ヶ月かかりました。たった一行出すだけなのに、“めちゃくちゃ”大変なんです。
商品や仕様それぞれにidがついていて。idのひとつひとつを古いコードの中から解釈して、マッピングして、新しい定義を与えるデータを書いたりして、という地味な作業が80カテゴリー×商品仕様の組み合わせで数百万。冊子だけで30万通り。もともとのコードにはこれがべたっと書かれていて、いたるところに散らばっていました。その整理を進める中では、色々な人に手伝ってもらったのですが…非常辛い作業でした(笑)。
商品に関わるところも既存コードのいたるところにあったのですが、全然きれいに管理できていなかったので、現在は、商品とプライシング、いわゆる「商品システム」の切り出しを行っています。
有澤：ラクスルではやはり商品を扱うところが一番難しい。マイページだと商品名を表示するところは難しいし、料金表も、商品とオプションの掛け合わせで値段が変わる仕組みは、この（商品コードの）世界で動いているのでこれまで手がつけられなかったんです。
ここがきれいにならなかったら、今後エンジニアがどんどん増えていった時に、新しく入社するメンバーに暗号みたいなidをまず全部教えなければなりません。それを想像した時に、そんな未来はちょっと無理だよね、と。
二串：「商品基盤構想 Ver.3」と名付けたのですが、Ver.1は構想の段階。そしてVer.2は私がマイページに着手する前に、商品の料金表ページに着手したいと思ってやりかけたんですがその時は工数が足りずに劣後させたという段階。そしてようやく、今、3代目（Ver.3）が日の目を見ており、新しく「クイック注文」というチラシの手元到着日指定ができるサービスが始まったのですが、それに採用されました。
商品基盤部分を担当した二串
何をやるかも、どう解決するかも、とにかく徹底的に議論する
三瓶：これまでお話したように、RPPにはいろいろな難題が日々生じます。それを解決する時間であり、このチームの特徴ともいえるのが、毎朝11時からの「議論の時間」です。通常は「朝会」といって、昨日何をしました、今日何をします、といった報告がメインなのですが、RPPはそういった定例の報告はなく、毎朝“議論”するんです。チームの方針として、進捗の足並みを揃えることや全体のタスク管理よりも、それぞれが自立して進めながら必要なことを議論することを大事にしています。
小林：特に最初の方は具体的にはやることが決まっているわけではないので、何をどうやるかについて、徹底的に議論してお互いの知恵を絞りあうようにしています。
・・・次回に続く
試練に向き合い克服しながら進み続ける技術的負債解消プロジェクトのRPPチーム。最終回は、プロジェクトの今後についてお話します。
当社の技術的負債への取り組みをセミナーでお話ししました。
前回記事
Related Stories
関連するストーリー