ラクスルのエンジニアリング・プロダクト全体にまたがる壮大な技術的負債解消プロジェクト「Raksul Platform Project」を3編に分けてご紹介！第1回目は、プロジェクトの目的と発足するまでの歩みを振り返ります。
プロジェクトとは？
ラクスルでは短期の成長にとらわれずに、本質的な価値を出すことを目的とした取り組みを「プロジェクト」と呼んでいます。プロジェクト発足当時のラクスルは、顧客や現場接点を失っており、長期の”価値創造”へ目が向けられていないという課題がありました。そこで、ユーザーに選ばれる本質的な価値あるサービスを、長期の軸で設計して作りきることを目的としたプロジェクトが始まりました。
チームは、起案者となるリーダーの提案内容に賛同した、部署横断のメンバーで構成されています。
本プロジェクトの概要
プロジェクト名
技術的負債解消プロジェクト：Raksul Platform Project（以下RPP）
プロジェクトビジョン
流通300億規模の印刷需要を支えるプラットフォームへ
期間
2017年7月～（進行中）
プロジェクトメンバー
●水島壮太（執行役員CPO /プロダクトマネージャー）
IBM→DeNAを経て現職。本プロジェクトのリーダー/CPOとしてラクスル全体の開発指揮を行う。
●有澤 高介（エンジニア）
大手IT企業等でアーキテクトとして数々のプロジェクトをけん引したのち、ラクスルに参画。本プロジェクトを設計の要として支える。
●小林 寛武（エンジニア）
大手IT企業にてインフラ/サーバーサイドエンジニアとして活躍後、ラクスルに参画。美しいコードを書くことで社内では一目置かれる存在。本プロジェクトでは認証基盤を主に担当。
●二串 信弘（エンジニア）
大手ISP→事業会社を経てラクスルに参画し、現在は印刷事業の開発をエンジニアリングマネージャーとして牽引。本プロジェクトでは主に商品基盤部分を担当。
●三瓶 広紀（エンジニア）
※次回より登場
ヤフーを経て2018年4月に参画。本プロジェクトでは主に決済基盤部分を担当。
プロジェクト誕生まで
エンジニアと経営、どちらも幸せにしたい
本プロジェクトの起点となったのは、2017年9月にCTOの泉が立ち上げた「ラクスル本体のリビルドを考えるチャネル」というslackチャンネルでした。
通常、プロジェクトは起案者がリーダーを兼ねるものの、本プロジェクトについてはラクスルのエンジニアリング全体の喫緊の課題であったため、
CTO自らが起案・申請し、企画設計/実行については水島がリードする形となりました。
水島：本プロジェクトの目的は、主に以下の2つです。
1.技術的負債と思われている部分を根本的に解消して開発しやすい状態にする（エンジニアを幸せに）
2.システムに柔軟性を持たせて経営戦略の選択肢が増えている状態にする（経営を幸せに）
特に前者の「エンジニアを幸せに」という目的に対する経営陣の温度感が高いことについては私自身、非常にポジティブに感じています。短期的な投資対効果ではなく、「ものづくり」を大切にする会社になるんだという意思が強く感じられるので、長い道のりにはなりそうですが、エンジニアとデザイナーがさらに輝けるようにするために是非やりきりたいと思っています。
後者の「経営を幸せに」という目的は、プロダクトマネージャーである私のバランサーとしてのプライドみたいなものです。ただ作り直してキレイになりました、幸せです！だけでは虚しさがあるので、経営の潜在ニーズを今回のプロジェクトで一定先回りして、いつかドヤ顔したいと思っています。
つまりは、単純に他言語、他フレームワークで作り直すということではなく今後のアーキテクチャーから見直していくプロジェクトです。
「もうこれ以上リフォームできません！」という状態だった
有澤：プロジェクト化される前からも、泉とはずっと（システムの切り出しなどの）話をしていました。ユーザー認証を切り出そうとか、ちょっとずつは進めていたものの、「ちゃんとやろう」と始めたのがようやく人も揃い始めたこのタイミングでした。もともとは“印刷プラットフォームを作ろう”という話で、他の印刷ECがラクスルに対して発注できる仕組みを作りたいというのがそもそもの始まりでした。仕組みをつくろうにも、既存システムに新しいシステムを載せることは難しく、家で例えると、ラクスル本体のコードは「もうこれ以上リフォームできません！」という状態でした。それで、どうせ作り直すんだったらちゃんと再設計して作り直したいなと考えました。
二串：すごくポジティブな言い方をすると、組織が拡大していく中で、今のコードベースだと開発がスケールしなくなる状態でした。例えば、新しく入ってくれた人に、ラクスル独自のルールに則ったコードの書き方を教えなければならなかったりするのですが、そのためのコミュニケーションコストが非常に大きかった。しかも、各システムが密に連携しすぎていて、１箇所に手を入れるとその影響がどこまで波及するかの予測がつかないというからくり箪笥状態。システムを小分けにして、コードを整理して、小さいチームで動かせるようにしていこうというのがこのプロジェクトの思想です。
プロジェクト始動
ユーザーにプラスになるのであれば、個別のアプリケーションの開発は自由に進めよう
水島：プロジェクトが始まって、まず最初に着手したのが決済システムと認証基盤における技術的負債の解消です。この2つのコンポーネントを優先した理由は、システムを作り直すにはセオリー通りの順番というものがあって、決済と認証は最初に切り出すところなんです。あとは、開発規模的にも決済のところが一番小さそうに見えた、というのもポイントでした。プロジェクトの最初のインパクトも早く出したかったので、ここから切り出そう、と。実は前職でも決済系のシステムを担当する決済開発チームのマネージもしていたので、やることがイメージしやすかったのもあります。でも、蓋を開けてみると想像以上に大変で、３ヶ月くらいでできる予定が、2017年11月にスタートして、本番稼働できたのが翌年の8月。でも、このとき切り出した決済の仕組みは、今は他プロダクト（ノベルティEC）でも使われています。
小林：認証基盤というのはお客様のIDとパスワードを共通化し、同じログイン画面を通して特定の商品・サービスの購入だけでなく他でも使えるようにしたものです。例えば、楽天では同じID・パスワードでショッピングもトラベルも、楽天が運営する様々なサービスにログインできますよね。あのような感じです。
今までは入り口がラクスル本体にしかなく、ラクスルというひとつの大きな箱の中に印刷EC（チラシや名刺など）、集客支援サービス（新聞折込やポスティング）、その他様々なシステムが組み込まれていました。そこにノベルティECなど新しいサービスを作ろうとすると、狭い一軒家の中に無理やり部屋を作るイメージで、それをいざやろうとするとコードが膨らんで開発が大変になります。そこで各世帯（システム）に分けるために、まず新しい玄関を作り、いろいろな人がそこを通って先に進めるようにしなければいけなかった。これが認証のメカニズムです。
有澤：基本的にはサービスごとにそれぞれが使うシステム、という形でシステムを切り分けています。あとは、それぞれのサービスで必要なシステムを組み合わせて、最終的には共通の決済システムに集約される。だからこそ、その要となる認証基盤と決済が大事だったんです。そこがちゃんとしていて、ユーザー体験がよければ、それぞれ個別のアプリケーションの開発はそれぞれのチームでよりよく進化させていくことができます。
・・・次回に続く
こうして2つの大きな要「決済」と「認証基盤」の構築から走り出した技術的負債解消プロジェクトRPP。ラクスル史上最強との呼び名高いこのチームに試練が訪れます。
次回はいよいよ決済のメイン担当三瓶が登場、RPPチームが迎えた試練を振り返ります。乞う、ご期待！
当社の技術的負債への取り組みをセミナーでお話ししました。
Related Stories
関連するストーリー