この記事は ラクスルの2022年アドベントカレンダー ４日目です。昨日は同じラクスル事業部のAMチームのタインさんの記事「Rails development environment troubleshooting on Mac with M1 chip - RAKSUL TechBlog」でした。 タインさんは日本在住で日本のチームで一緒に仕事をしていますが、普段は日本語で仕事をしています。ベトナムのメンバーも日本語上手な方が多くて日本語でのコミュニケーションも多いですね。ただ、英語を使ったり日本語で喋ったりと話の内容に応じて切り替えたりしています。
自己紹介と今日のテーマ
ラクスル事業部の印刷集客開発部長の加藤一平です。元祖加藤さんが居るので、私は「一平さん」と呼ばれることが多めです。
ラクスル事業は、ビジネス・オペレーション・プロダクト（プロダクトマネージャー、エンジニア）、という三つの役割の人たちで構成されています。 私はエンジニア組織でマネージャーのマネージャーという感じでお仕事しています。今は直接開発をしていなくて、ビジネスとの接続について動いていたり、事業の目標に沿った開発ができるような組織にする、みたいなところをミッションとして動いています。
今日のテーマはテクノロジ系じゃなくで事業・マネジメント系のお話です。 もしラクスルで開発するならどういう課題が転がっていて、それはどんな感じで解決可能な状態になってるのか？という話をしたいと思います。 思いっきりラクスルに興味持ってくれそうな方向け、面接で聞きたいことTOP3に入るテーマだと思いますｗ
エンジニアが仕事・会社を選ぶときの重要要素の一つとして「仕事の良し悪し」があると思っています。 ちょっと難しくても貢献度高めの課題があって、それが着手可能な状態でやっていいよ、って転がってたら喜んでその仕事を選ぶのではないでしょうか？ですよね？ （もちろん、一緒に働く人が良いとか、作るモノが良いとかも大事。お金も大事！）
ラクスルの技術負債・課題について
ラクスルでは RPP（Raksul Platform Project）というのを 2018年頃からやっていましたが2021年に一つの節目を迎えています。（ https://recruit.raksul.com/story/rpp03/ ） もともとモノレポだったラクスルのシステムでしたが、このプロジェクトによって現在はドメインごとにサービスが分割されて、程よい粒度で開発のしやすさが大きく上がっています。
という話を聞いていると、いまはモダンでいい感じの開発やってるよ、というポジティブなイメージを打ち出したい雰囲気を感じますね。 ところが、課題が大好きな身としては、これってそんなに響かなくて「まだ直すところが多くて」という方がワクワクしますｗ
実際、まだ技術負債がところどころに残っていまして、開発のスピードが上がらない要因になっているのが現状です。 新旧システムの両方に重複ロジックがあったり、旧システムの設計をそのまま移行先の新システムに持ってきているのでDB設計に無理があったりと、あまり色々書けないですがなかなか解決の困難なものから、時間があればどんどんやれる手元の軽いものまで課題と言えるものが転がっています。
また、昨年まで成長戦略・方針として「High Growth」を謳っていたこともあって、横へ拡大することにウェイトを置いて開発を進めていました。このため、運用面でも改善の余地の多い箇所がたくさんあるシステムになっている、というのも現状です。
（事例を書こうかと思ったのですが、文字数が倍増しそうなのでちょっとガマンします。他の方の記事から読み取れるかもしれませんね・・・？カジュアル面談とかで指名していただければ喜んで喋ります！）
技術負債に向き合う・基盤に投資する流れ
「技術負債」っていう単語とセットで気になるのが、経営陣はこの問題に賛同してくれるのか？ということではないでしょうか？ ラクスル事業では、ここにとても強い関心とやりきることへの理解があります。 前述したRPPをプロジェクトとして経営承認して、数年がかりでやってきたことでもわかるようにテクノロジーをとても大事に扱っています。
ビジネスの実行力がとても強いことがラクスルの成長・事業としての強みを牽引しています。 しかし、ラクスル事業CEOやビジネス統括から「しっかりやりきる」というミッションを提示しており、決してビジネスサイドがパワーを持ってゴリゴリと推し進めるだけではない、というのがラクスル事業の強みの理由だと言えるでしょう。 「仕組みを変えれば、世界はもっと良くなる」というビジョンをそのまま体現しているのがラクスルであり、テクノロジーの力とそれを実現するプロダクトメンバーに信頼を置いて任せています。これがラクスルの変わらないスタイルなのだな、と実感しています。
大体みなさん同意してくれるのですが、エンジニアで「課題が好きじゃない人」って居ないですよね？
肝心なのはその先、その課題を解決する余地があるのか？解決できる環境があるのか？ってことだと思います。これは明確に Yes で、まだまだ「現状すごくムーブメントがあって・・・」というところまで行ってないですが、半年後にはこれがじわじわと流れになっているはず。
私が入社してから、特に体制を整備するところに大きくエネルギーを費やしてきました。
事業を推進するのに足る体制を作ることに加えて、技術負債や開発を阻害する課題を解消していく。このために、必要な対処ができるということも並行してやっていけるように、ということを明確に意図しています。もともとの流れもありますが、このウェーブにしっかり乗ることで課題解消環境が整っていっていきます。
ラクスルのエンジニアはどうあるべきか？
このウェーブに乗りそこねないためにやるべきことがあります。
CTOや私がやってきていることは、「任せてくれたらしっかりやりきるよ・やりきらせますよ」っていうアピールなのですが、これはエンジニアメンバーの「しっかりやりきる」ということへの期待を前提にしています。エンジニアの仕事は投資（開発）に対してのリターン（効果・成果）までの期間がちょっと長めなので、なかなか説明や投資判断の難しいところですよね。
「約束」することの難しさはありつつ、信用・信頼をもとに仕事を任されていくので、説明責任はもちろんのこと、しっかりやりきること／それを推進することを明確に求められます。
（ちょっと “自分の考え” も含みますが）説明責任には「計画の提示」を含み、状況の変化を適切なタイミングで提示していくことなどがとても重要になってきます。
説明は任せて、と私から全方位に言っていきたいので、「説明の素材」と「やりきりはまかせて」、というのはみんなにお願いしたいと思っています。
ごくごく基本的な仕事のスタンスですが、有言実行で「提示しておいたもの(計画)を実行する」ということがとても重要です。
これはエンジニアリングなら「設計したものを実装する」（設計しながら実装するじゃん、ってのは一定あると思いますが）というのと同じで、設計したけど実装してみたらちょっと思ったんと違った、といって設計見直すのと近いものだと思っています。計画を立てたけど実行してる途中でちょっと変わった、っていうのを調整していくのと同じですよね。
エンジニアリングもマネジメントも、ほかのすべての仕事についても「考えたものを実行する」というのは同様で、これが事前に考えたものに近いかたちで進められるというのは、「再現性のあること」がやれる証左になると言えます。
まとめ
事前に考えを提示してから実行していく、これを繰り返していくことで「再現性がある」と見られることに繋がり、任せていこう、って思われていきます。
ラクスルのエンジニアは、開発力と事業理解が強いメンバーが非常に多いため、こういった面での「再現性」を強めていくということを期待しています。
また、「課題大好き・任せてくれたらやりきりますよ」という方と一緒に仕事をしたいですね！
