Recustomerに入社して1年。プロダクトを“ちゃんと作る”ようになった話

はじめに

Recustomerというスタートアップに中途入社してから今月で1年が経ちました。
大変キリがいいのでこの1年の中で自分の感じたことを少し振り返ってみようと思います。

そもそも私はどんな人

新卒時は他業種で働いていたため、エンジニア経験としては前職と現職を合わせて3年ほど。
さらにその3年のうち1年はマネジメント業務だったので、実装経験だけを見るとそこまで多いわけではありません。
現在はエンジニアが10人ほどの小さなチームで、主にバックエンドを書いています。

入社直後はルールに追われ続けていた

入社してすぐの頃は、本当に毎日いっぱいいっぱいでした。
覚えたルールがすぐに変わったり、仕組みがどんどん改善されていったりして、ルールを覚えながらもルールにおいて行かれないようにという状態でした。
そんな中で感心したのは、日々変化していくルールについて、全員で共有し、適応しているということ。

前職（受託開発）は、ある意味で個人の宗教(コーディング思想)と別の個人の宗教が殴り合っているような状態でした。
書く人によってまったくコードのスタイルや考え方が違い、プロダクト全体に統一感がなく、中には属人化の果てに誰も管理ができなくなった開かずの間のようなコードを誰が引き継ぐかの爆弾ゲームになることもしばしばありました。
その結果、レビューもやりづらく、一貫した判断基準があるわけでもなく、常に個人戦という雰囲気でした。

一方で今の環境は、ルールへの対応に追われながらもみんながちゃんとやるから自分もやらなきゃという空気が自然にあって、そういう流れに乗る形でコードが揃っていくところに、良いギャップを感じました。

思っていたスタートアップ像と、実際のギャップ

先ほど良いギャップに触れた勢いで、私がRecustomerに入社する前に持っていた、いわゆるスタートアップのイメージと、実際の環境の差について触れたいと思います。

なんとなく入社前に想像していたスタートアップは、以下のような組織を想像していました。

思っていたスタートアップ

• スピード最優先でとにかく作る
• コードの統一感はあまりない
• レビューは軽めで、ひとまず要件通りに動けばOK
• 方針の変更でカオスが起きる

実際これらはリリース優先の現場ではあるあるだと思っていて、どこかで技術負債に耐えられなくなった際に大規模なリニューアルを実施するのが伝統芸のようなものだと思っていた節があります。
しかし、この期待をRecustomerという会社は良い意味で裏切ってくれました。

Recusotmerという環境

• エンジニアが品質にまで責任を持つDevOpsの文化
• 方針はよく変わるけど、レビューはかなり丁寧
• モデルレビュー・テーブルレビューで認識合わせを必ず実施
• 誰が書いても大きく揺れない統一されたコードになる
• 自主的なリファクタリングの頻度が高く、持ち回りで負債を解消していく文化

そんな会社本当にあるんだと思いましたが、なんとあるんです。
ですが、これを実現する環境では本当にキャッチアップの量、考え事の量が多く、チームメンバーの優秀さと日々の積み重ねの賜物だと実感しています。

▼ DevOpsについてはかなり良い事が書いてあるので弊社のイケてるEMの発表資料も是非覗いて欲しいです！

で、自分がどう変わっていったのか

UIから考えるのをやめた

Recusotmerではドメイン駆動開発を実施しています。
恥ずかしながら、この会社に入社して初めてドメイン(扱う概念)駆動という方法を学んだ私にとって、それまで「何を作るか」を考えることは = 「誰にどんなUIを見せるか」を考えることとほぼ同義でした。
つまり、画面から逆算してテーブルを作ったり、UIに合わせて責務を寄せたりする世界で生きていたわけです。

UIから逆算していた頃は、このロジックはどこに置くべきかという問いを真面目に考えたことがありませんでした。
なんとなく汎用化できそうなコードをutilsフォルダに共通化したりして、なんとなくコードを整理したような気になっているのが日常でした。

この状況の最も大きな問題は、何を触るとどこに影響出るか分からないまま改修しなければならないところにあったと思います。
そのせいで新しい関数がよくわからない位置に増えていったり、特定の条件を持つバリデーションが謎のファイルに埋め込まれていったりと、混沌としたさらに扱いづらいコードが量産されることになったのは苦い記憶です。

今思い返すと、UIから考えていた頃に迷っていたのは、結局何を基準に置き場所を決めるべきか？の答えが自分の中になかったからだと思います。
UIは変更や仕様追加で姿が変わるため、そこを基準にすると決めようがなかったのかもしれません。

ここからRecustomerでの開発に触れる中で、UIではなくドメインから考えるという考え方を知りました。

ドメインを意識して設計するようになると、自然とフォルダの構成やコードの置き場所も変わっていきます。
例えば今のプロジェクトでは、画面単位ではなく概念単位でコードがまとまっています。
ざっくり書くと、ディレクトリ構成はこんなイメージです。

project-root/
├── domain/               # 扱う概念そのもの
│   └── order/
│       ├── order.py      # 集約ルート
│       └── interface_repository.py
│
├── usecase/              # アプリケーションとしての振る舞い
│   └── order/            # 注文に関するユースケース
│       ├── create_order.py
│       └── cancel_order.py
│
└── adapter/　　　　　　　　# 外部との接続（API・DB など）
    ├── inbound/
    │   └── order/　　　　# order に関する入力アダプタ群
    │       └── adapter.py
    └── outbound/
        └── order/　　　　# order に関する出力アダプタ群
            └── repository.py

層やユースケースごとにフォルダが分かれているので、必要な処理がその範囲内で完結しやすく、余計なロジックが混ざりにくい構造になっています。
そのおかげで、処理の置き場所で迷うことが少なくなり、変更するときにも見るべき場所がはっきりしていて扱いやすくなりました。

もし過去の私と同じようにディレクトリ迷子になっている人がいるとしたら、何か参考になれば嬉しいです。

エラーの解析についてちゃんと考えるようになった

これも本当に良くなかったのですが、以前の私は、エラーは起こったら対処すればいいものという認識でした。

自分で気づくか、顧客から連絡をもらって初めて調査が始まり、サーバーに入ってログを眺め、ローカルで再現が取れたら直す。これの繰り返し。
特にログを深く読み解いていたわけではなく、サーバーが吐いたエラー文を手がかりに、きっとこの辺りのエラーだろうと当てに行く調査を行い、とにかく再現をとっていました。

原因が複雑に絡んでいると、調査に時間がかかることも多かったです。

それが今では、エラーに対する向き合い方がかなり変わってきました。
特にエラーが起こったときに何のデータがあれば解析しやすいかを事前に考えるようになったことが自分にとって大きな変化です。

例えば、

• エラーが発生した対象IDは必ずログに出す
• 独自のエラー型を定義して、原因ごとにエラーを分ける
• エラー型を見るだけで「どの前提が壊れたか」が分かるようにする

といった工夫を行うようになりました。
これにより、エラーが起きた際に「どの辺りが怪しいのか」「何が前提と違ったのか」が以前よりずっと明確に掴めるようになり、圧倒的に調査がしやすくなったと感じています。

エラーは起きたら直せば良いもの、ではなく、起きたときにすぐ理由が分かるようにしておく ものなのだと知りました。

pyconに出てみた

もうひとつ自分でも驚いた出来事がありました。
PyCon JP 2025 に出ました。

社外向けのカンファレンスの、しかも登壇側なんて自分には全然縁がないことだと思っていたのですが、
どういう流れだったか、今年のPyConにチーム全員がプロポーザルを出すという流れになり、まあみんな出すなら出すかという軽い気持ちで自分も出すことになりました。

Python歴も1年と短いのでそんなに大層なことを話せるわけでもなかったのですが、とりあえず出したプロポーザルが気づいたら採択されていました。

そこからは急に慌ただしくなり、資料作成のための調査や発表練習などバタバタとして、
やってきた当日は緊張でいっぱいでしたが、会場の雰囲気がとても温かくて、ああやってみてよかったなと素直に感じます。

こんなことになるとは、1年前の自分では想像もしませんでした。

▼ なんと弊社には沢山登壇者がいるので気になったら見てくださいね！

自分の成長を振り返ったら、環境の話になった

さて、振り返ってみると、この1年で得たものの多くは、自分の努力で身についたというより、周りの影響を受けて自然とそうなった部分が大きいように感じています。
ドメインから考えることも、エラー解析の向き合い方も、PyConに出たことも、私にとってはこの環境にいたからこそ経験できたことでした。

最初は慣れるまで本当に大変な時期もあったのですが、気づけば1年前よりも視野が広がり、できることも増えたように思います。

Recustomer、結構いい環境かもしれませんよ。

というわけで採用宣伝をします

弊社に興味を持ってくださった方！

ぜひぜひ一度カジュアル面談をしてみませんか？

カジュアル面談は Startup CTO of the Year を受賞した CTO が必ず担当するようです！

まだ面談するほどじゃないよって方も

エントランスブックがあるので良ければご覧ください！
(弊社のアーキテクチャ概要図とか書いてます！)