エンジニアだけでなくビジネスメンバーも巻き込んでいく　“ラクスル流”技術的負債との上手な付き合い方

ラクスル流技術的負債との上手な付き合い方

二串信弘氏（以下、二串）：「ラクスル流技術的負債との上手な付き合い方」ということで発表いたします。今日はラクスル主催の技術イベントにご参加ありがとうございます。

ではさっそくですが、まずは自己紹介を簡単にいたします。あらためまして私は二串と申します。現在、印刷を中心とする事業部でHead of Engineeringとして、事業部の技術全体のリードをしています。私自身ずっとエンジニア畑を歩んできていましたが、ラクスルに入社しまして、マネジメントを経て、現在の役割に就いております。

というわけでラクスル流の、技術的負債とどうやって付き合っていくといいのかをお話いたします。流れとしましては、まずはラクスルの紹介を簡単にして、そこから弊社で取り組んでいる、いわゆるプロジェクト型の技術的負債の取り組みを紹介し、最後に私がエンジニアとして関わっていった中で得た学びについて紹介するという感じで進めさせてください。

今日のお話を聞いていただいて、みなさまが関わっているプロジェクトとか、そういったところにおける技術的負債の取り組みがよりスムーズになればと思っています。

仕組みを変えれば、世界はもっと良くなる

では弊社の紹介をいたします。弊社は2009年に創業しまして、もともと「印刷比較.com」というWebサービスからスタートしていますが、こちらの「仕組みを変えれば、世界はもっと良くなる」というビジョンを、創業当初より掲げています。インターネットやソフトウェアの力を使って、より良い世界にしていくといったビジョンを掲げている会社です。

具体的にラクスルでは非常に大きく伝統的な産業にフォーカスしまして、そちらにテクノロジーを持ち込んで、さまざまな非効率が存在する産業において、そこを21世紀型のより便利な産業構造に変えていくという変革をミッションにしています。

今ラクスルにはメインで3事業あり、一番左から印刷の「ラクスル」、物流の「ハコベル」、さらに広告やテレビCMのプラットフォームであります「ノバセル」といった事業を展開しています。私が所属しているのはこのラクスルで、今日のメインはこの印刷事業部でのお話です。

その事業部の中でどんなことをやっているのかというと、1つがモノリスなアプリケーションからマイクロサービスへの移行です。なので、技術的負債がある前提でこれ以降はお話したいと思っています。

モノリスなアプリを小さなプロダクトに分割する「Raksul Platform Project」

Raksul Platform Projectが2017年よりスタートしました。これはモノリスのアプリケーションを小さなプロダクトに分割していって、最終的には事業継続の柔軟性を作る、といったところを目的としたプロジェクトになります。

ラクスルは2009年からスタートした非常に歴史あるプロジェクトですので、そういった中で、スタートアップとしてモノリシックなアプリケーションからスタートするのはよくある話かなと思うんですが、事業がどんどん大きくなる中で、開発の効率性や、人が増えても技術的負債により開発がスケールしないといった課題感、またはその中に眠っている価値のある機能などさまざまあり、そちらをより有効活用していきたいというところで、こういったプロジェクトをスタートしました。

これは非常に大きなプロジェクトで、これを語ると1時間や2時間では終わらないので、今日はあっさりとご紹介というかたちなんですが、興味がありましたら、ぜひあとでお声がけいただければ、いくらでもお話しいたします。

そういったところで、分割が非常に進んでいまして、チーム数としても当時私が参画した時には3チームだったのが、今は10チームで非常にスケールするようになりました。また、開発の生産性を測る1つのメトリクスとなっているデプロイ数も順調に推移している状況で、うまく開発がスケールするようになったところが、事業としても大きな成果として上がってきている状況です。

また、エンジニア組織の紹介も兼ねますが、2020年には日本以外にベトナム、インドといった海外に開発拠点をオープンしまして、よりグローバルな開発を現在行っています。私のいる事業部でも4割が外国のメンバーで、非常にグローバルなかたちで、完全に独立しているというよりはプロダクト単位で協働しています。

こういったことができるようになったのも、お馴染みのいわゆるマイクロサービスで、スケーラブルな開発ができるようになってきているおかげです。

ここまでが簡単な紹介なんですが、エンジニアとして入り、今はマネジメント、経営というところに関わっているので、そういった中で、どうやったらこの規模の大きなリファクタリング、プロジェクトをうまく回せているのかを後半で伝えたいと思っています。

技術的負債にもっとも関心があるのは誰？

ちょっとアイスブレイクなんですが、技術的負債にもっとも関心があるのは、次のうち誰でしょうかという質問です。1番エンジニア。2番はビジネス、ビジネスのメンバーですね。3番は経営者。というところで、みなさんいかがでしょうか。

私もエンジニア時代は1番かなと思っていました。正解なんですが、実は全員でして、なぜかというとエンジニアは当然技術的負債をなんとかしたいとか、できれば関わりたくないとかなどなど、さまざまな思いがあります。

一方ビジネスのメンバーも、やはり技術的負債があるからできないこともありますし、できれば何らかの施策をやっていきたい。経営者としても、負債という言葉が表すとおり、一定の「抱える」はポジティブに捉えられますが、抱えすぎると負債の超過に陥って事業が立ち行かなるなどのリスクもありますし、実際にヒューマンリソースとして人件費にも跳ね返ってくるので、みんな関心があるというところを、ぜひ認識してもらえればなと思っています。

なのでエンジニアだけの関心事ではないというのが、先ほどのプロジェクトや今回の登壇テーマの中で思考したところです。

何のために技術的負債をなんとかしたいのか

では技術的負債にまつわる、よくありがちなパターンとして、こんなところもあるのかなと思っていて。聞いていただいている方の中で、チームの中でビジネスとエンジニアの技術的負債を跨った対立構造が、ひょっとしたらあるのかなと思っています。ラクスルも、私が入社した2017年ぐらいには、こういった対立構造があったとは感じています。

エンジニアとしては生産性高く仕事をしたいですし、ビジネスとしては先ほど申し上げたとおり、新しい施策もやってみたいし、今は踏み込んでやりたいといった思惑もあると思うんですが、ここの両者の意見は、なかなかうまく合わないのかなと思っています。

こういったところは、一歩引いてみるというのがすごい大事だなと思っていまして、エンジニアとして技術的負債を何とかしたいというのは、みなさん一度関わったことがある方なら当然そう思うところですが、「何のために技術的負債をなんとかしたいんだっけ？」をぜひ考えたほうがいいのかなと思っています。

利害関係を一致させるというのがひとつのテクニックと言いますか、ひとつのやり方かなと。こういったことをすると、チームの中の流れがよくなるのかなというのが実感としてありました。

具体的にいうと、特にラクスルやSansanさんは事業を行っていますので、そういう事業会社かそうでないか、といった会社のかたちには寄ると思いますが、ラクスルを前提にすると、技術的負債の前条件として、本当にチームとして成し遂げたいことが必ずあるので、こういったところを一緒に考えるというアクティビティをするのがいいのかなと思っています。

結果として、新しい価値、売上が上がったり、新しいお客さまを獲得したり、そういった強みが生まれると。必ずしも100パーセント言い切るつもりはまったくないんですが、1つのアプローチとしては、そういったところもあるのかなと。実際にラクスルの場合も、技術的負債も非常にいろいろあるんですが、そこを乗り越えて、しっかり事業として価値を上げることに成功してきたというところはあります。

またビジネスとエンジニアだけではなく、プロダクトマネージャーやデザイナーも一緒に議論に入れて、みんなで技術的負債を絡めて話していくというところを、ラクスルではやっています。

そうやってビジネスを巻き込むのもひとつの目的ですが、やはり相互に理解するというのも大切だなと思っていまして、エンジニアもビジネスを理解するし、ビジネスもエンジニアリングを理解するところがあるのかなと思っていて。

大切なのは「Reality」

ここでちょっと「Reality」という言葉を入れたんですが、エンジニアとしてもビジネスへの解像度を上げるといったところが、1つのキーというか、重要だと思っています。エンジニアがビジネスを全部理解するのは、やはり専門性が違うので難しいかもしれませんが、関心をもつというのは非常に重要だと思っています。

ラクスルはもちろんSansanさんもそうだと思いますが、複雑な産業のビジネスを相手にしていますので、そういったところにReality、解像度をもってソフトウェアにしていくのは、クリエイティビティが必要だと思っています。クリエイティブを伴う作業ですので、そういったところで、ビジネスとかステークホルダーなど非エンジニアの方々の理解は必須になってくると言えるのかなと思っています。

また、非エンジニアの方からエンジニアを理解していくといった活動というのも、より技術的負債をうまくドライブしていくところで必要になると思っています。

最近ラクスル全社員が集まるイベントを利用して、「技術的負債って何ですか？」とか、技術的負債にまつわるプロジェクトの学びや失敗というところをわかりやすい言葉で伝えていくのをちょっとやってみました。

ビジネス側からすると、技術的負債はうまくデリバリーできないコードとか、なんとなくそういう雰囲気で思われていた節があったんですが、それだけではなくて、うまく付き合いながらトレードオフとしてやっていくんだよ、といったところを話しました。

あとは溜め過ぎると立ち行かなくなっちゃうねとか、広く浅く社内にお話ししました。結果として、ビジネスの方とかが、リファクタリングという言葉を理解し、「組織のリファクタリングをする」といったところにも使うようになって、思わぬ効果もあって非常によかったなと思っています。こういうところは1人ではできないので、協力体制として、社内の広報の方と連携して進めたりしました。

そういったかたちで、やはりエンジニアだけで留まらず、ビジネスや非エンジニアの方も含めて巻き込んでいくというのが、プロジェクトをうまく進める上で重要という気づきがあった、という紹介でした。

共通の目的を導入して協力体制を作ろう

というわけでまとめですが、取り組み方によっては、攻めの施策にもなるんじゃないかということで、共通の目的を導入してぜひ協力体制を作ってみたらどうでしょうかと。あとは技術的な観点だけではなくて、学びや相互理解というところを大事にして、うまく伝え合う。組織とカルチャーを作っていくというところを紹介しました。