ランサーズのサービスでは、toCに向けたいわゆるグロースハック的に体験を向上させていく部分と、仕事の契約が結ばれてからのtoB的な業務システムの部分の両方が必要となります。それらの「パッと作って色々と試す世界」と「しっかり作り込んでいく世界」の両立をどうしていくか、そんな中でどのように技術負債と向き合い、新しい技術に挑戦していくか、普段の私達の開発を通じての課題や解決方法についてお話いたします。

昔ながらのシステムが残る業界にどのようにテクノロジー変革を起こすか、その答えの鍵となるのが、ラクスルのコアバリューのひとつでもある「リアリティー」というキーワード。我々がどうやって彼らの課題を高い解像度をもって理解するか、如何にユニークなソリューションで解決に導くか。個人ではなくチームでの解決にこだわる理由とは。今回は主に、Ruby biz Grand prix 2016を受賞した物流サービス「ハコベル」を中心に、どのような変革をどのような開発プロセスを用いて進めているかをご紹介したいと思います。

今回はプロダクトの領域が広く、複雑な場合に、効率的に業務知識を得るために、どのような取り組みをしているのかということについて話したいと思います。 現在私が、開発メンバーとして加わっている人事労務freeeもプロダクトとして大きくなってきており、またプロダクトに関わるメンバーも増えてきました。そうなってきたとき、プロダクト領域の広さと複雑性から必要な業務知識の量も多くなってきました。結果として、当時、多くの問題が起こっていました。今、その問題を解決するために、『DDDなどの設計手法を用いて、実装と業務が一致したモジュールに分割することで必要な業務知識を少なくする』という取り組みを行っていますが、そこに至る道筋は単純ではありませんでした。
今回はこの取り組みに至るまでの仮説検証をどのように行ってきたのかということについて話していきたいと思います。