こんにちは、リーナーの小久保 id:yusuke-k です。
この記事は、リーナーという会社の名前は知ってるけど、どんな会社なのかもうちょっと知れるといいな、という人向けの簡潔な紹介記事です。
リーナーについて
リーナーは調達購買領域で、BtoB SaaS を開発提供しているスタートアップです。 調達購買とはいわゆる「企業の買い物」です。複雑なプロセスが絡み合う領域ですが、現在はその中でも、見積や購買(発注)における業務を中心に扱っています。
プロダクトラインナップ
- リーナー見積 https://leaner.jp/sourcing
- リーナー購買 https://leaner.jp/purchasing
- 新プロダクト F(初期顧客にトライアル導入中)
- 新プロダクト M(開発中)
- プロダクト横断基盤
- ID基盤(開発中)
- データ分析基盤(開発中)
- その他プロダクト間連携に必要になる基盤(検討中)
事業・プロダクトの現状と課題
Good
- 顧客数、ユーザー数は加速度的に増えている
- 調達・購買という目立たないけど企業のビジネスを支える重要なサービスになっている
- ビジネスサイドと建設的に議論しながら、プロダクトのロードマップを決めている
More
- 探索的に付加価値を生み出す開発、既存の価値を活用して伸ばす開発、運用改善のための開発、それぞれでやることがたくさんある
- プロダクト横断した基盤開発がまだ十分に進んでない
- 特にID基盤、データ分析基盤の緊急度が高い
チームの現状と課題
Good
- セールス・CSなどのビジネスサイドのメンバーと、お互いの役割を尊重しながら同じコトに向かっている
- 一人ひとりが自分の貢献を感じられる環境なので、安心して仕事に集中できている
More
- リーナーとしてビジネスサイドとエンジニア・デザイナーがもっとお互いの仕事を相互補完できる余地はまだあるが取り組みきれていない
エンジニアリングの現状と課題
生成 AI 活用と QA
直近だと Claude Code を導入するなど、積極的に AI 活用に取り組んでます。その結果として開発スピードは上がっていますが、レビューが追いついていません。 チームとしては少人数を担保したいので、AI が自走できるように、Linter の整備や人間の受け入れテストがしやすくなるような仕組みを整えていきたいです。
品質面でも、生成 AI を前提とした新しい QA のあり方を今後決めていく必要があります。
探索と活用(+ 運用)の両立
主力であるリーナー見積は、歴史的な経緯もあり、既存価値を活用して伸ばす余地がたくさんあります。 その一方で、プロダクトの付加価値を増やすための探索も緊急度が高いです。
リーナーは大規模なエンタープライズ領域へプロダクトを展開しているため、この両方をうまく両立することが課題です。 さらに運用面でも改善すべきことが山積みです。
直近は外部ベンダーに業務委託として一部開発のお手伝いをお願いしています。
SRE、プラットフォームエンジニアリング
各チームで SLO を策定して、運用をはじめました。 現状の課題として、運用を始めたばかりで効果的に使えているとは言えない状況なので、チーム単体で適切に SLO 運用ができるように支援していきたいです。
また、Terraform による IaC を進めています (AWS, Datadog, Sentry, GitHub)が、まだまだリソースのインポートが終わってません。モジュール化して開発効率も上げたいです。
プロダクトデザインの現状と課題
リーナーは toB SaaS なので、意匠や装飾のデザインニーズは低いです。 それよりも、情報を構造的に整理して骨格をつくるデザインを強く求められます。
デザインシステムをつくり始めていますが、これを育てていくうえでも、ただの UI コンポーネント集ではなく、非デザイナー、非エンジニアも巻き込んでみんなでデザインする環境づくりをしたいと考えてます。
調達・購買というまだ未開拓で混沌とした業務をうまく整理して、プロダクトに落とし込むことにモチベーションを感じられるデザイナーの方を採用できたら嬉しいです。
リーナーではプロダクトデザインもみんなでやっています - リーナー開発者ブログ
課題まとめ



技術スタック
リーナー見積
- バックエンド
- Rails8 / Ruby3.4
- フロントエンド
- React18 / Next.js14
- TypeScript
リーナー購買
- バックエンド
- Rails8 / Ruby 3.4
- フロントエンド
- React18 / Next.js14
- TypeScript
新プロダクト F(開発中)
- バックエンド
- Rails8 / Ruby 3.3
- フロントエンド
- React19 / React Router 7
- TypeScript
インフラ
- AWS ECS
- AWS Amplify
コミュニケーション
- GitHub
- Slack
- Notion
開発ツール
- Claude Code
- Cursor Business
- GitHub Copilot for Business
- Devin
リーナーのプロダクト開発に今必要な役割
※ 便宜上、役割が分かれていますが、誰がどの役割を担うかは状況に応じて変わります(リーナーでは役割はグラデーションだと考えてます)。
以下、挙げている役割以外でも、状況に応じて柔軟に検討しています。
プロダクトデザインエンジニア
■ 業務で扱う主な技術スタックと知見
- プロトタイピング (Figma, Miro, 実際に触れる Web アプリなど)
- フロントエンドエンジニアリング (React, TypeScript,TailwindCSS, shadcn/ui)
- アクセシビリティ
■ 主な業務
- 機能開発・改善
- セールス、カスタマーサクセスと協力しながら顧客の困りごとを掘り下げる
- 顧客の困りごとをプロダクトの課題として整え、解決案のプロトタイプを作成する
- 顧客からフィードバックをもらい、プロトタイプをつくりこむ
- 解決案が整ったら、実際に動く Web アプリとして作りこむ
- デザインシステム構築
- ただのコンポーネントカタログ集だけではなく、デザイン原則まで含めてチーム全体を巻き込んで構築する
- 主にフロントエンドの改善
- コードベース
- パフォーマンス
- その他、他役割の業務も幅広く含まれるが、専門的にやれる必要はない
■ メモ
- 直近で特に求めているのはデザインに強みのあるデザインエンジニア
- React や TypeScript などに習熟する必要はない
- ただし(エンジニアのサポートを受けながら)自分のローカル環境を構築し、エンジニアと一緒にプロダクトを開発して欲しい
プロダクトエンジニア
■ 業務で扱う主な技術スタックと知見
- フロントエンド(React、Next.js、Remix、TypeScript、TailwindCSS)
- バックエンド(Rails、MySQL)
- インフラ・モニタリング(AWS、Sentry、Datadog)
- その他、デザインエンジニア・基盤エンジニアでやることも幅広く含まれるが、専門的にやれる必要はない
■ 主な業務
- 機能開発・改善
- セールス、カスタマーサクセスと協力しながら顧客の困りごとを掘り下げる
- 顧客の困りごとをプロダクトの課題として整え、解決案のプロトタイプを作成する
- 顧客からフィードバックをもらい、プロトタイプをつくりこむ
- 解決案が整ったら、実際に動く Web アプリとして作りこむ
- フロントエンド・バックエンドの改善
- コードベース
- パフォーマンス
- DevOps
- その他、他役割の業務も幅広く含まれるが、専門的にやれる必要はない
プロダクト横断基盤エンジニア
■ 業務で扱う主な技術スタックと知見
- バックエンド(Rails、MySQL)
- インフラ・モニタリング(AWS、Sentry、Datadog)
- 認証・認可や複数プロダクトの連携機能に関する経験があると望ましいが必須ではない(歓迎条件)
- フロントエンド(React, Remix)の実装比重は大きくない
■ 主な業務
- 各プロダクトを横断して必要となる基盤機能の設計・開発
- 主に構築中の認証・認可基盤の保守・機能追加
- 将来的にはプロダクト間連携や共通マスターデータなど、各種のプロダクト横断機能に必要な設計・開発にも取り組む予定
- 各プロダクトへの横断基盤機能の組み込み・イネーブルメント
- 各プロダクトから共通基盤が使えるようにする組み込み実装を、プロダクトチームのエンジニアと協力して行う
- プロダクトチームのエンジニアが共通基盤周りの実装を保守できるよう、ドキュメント整備や知識のイネーブルメントを行う
■ メモ
- 技術スタックは Web アプリケーションエンジニアと近しいが、複雑なアーキテクチャを設計したり認証認可などの専門知識を調べたりなどが増えるため、そういう業務を楽しめる人に join してもらえると嬉しい
SRE
■ 業務で扱う主な技術スタックと知見
- インフラ・モニタリング(AWS、Sentry、Datadog)
- SRE・監視・プラットフォームエンジニアリングなどの知識
- New Relic や Datadog などの APM の利用経験があると望ましい
- バックエンド(Rails、MySQL)
■ 主な業務
- 運用インフラ整備
- AWS の運用方針整備・権限設計
- Terraform を利用した IaC の推進
- モニタリング整備
- SLO の設計
- アラートの見直し、設計
- パフォーマンス指針の整備
- 各プロダクトの運用のサポート・イネーブルメント
- 各プロダクトチームでインフラやモニタリングを保守できるようイネーブルメントする
- 各プロダクトチームが扱いやすいようプラットフォームエンジニアリングを行う
- その他、各プロダクトエンジニアと協力してのパフォーマンスチューニングの実施などプロダクトの安定運用に関わる作業の計画・推進
■ メモ
- 現状は技術基盤チームが中心になって各プロダクトのインフラ・モニタリングを保守しているが、徐々に各プロダクトチームで見えるようイネーブルメントする形にシフトしたいと考えている
データエンジニア
■ 業務で扱う主な技術スタックと知見
- Google Cloud (BigQuery、DataStream など)
- dbt Cloud
- BI ツール(Looker、Looker Studio)
■ 主な業務
- dbt を用いたデータマートの設計、構築および運用
- メタデータ整備を通じたデータ民主化の推進
- データ品質を考慮したテストの設計と実施
チーム組成のこだわり
役割はグラデーション(デザインもエンジニアリングもそれ以外もみんなでやる)
上述した通り、リーナーでは役割はグラデーションだと考えています。 役割に人を割り当てるのではなく、 メンバーそれぞれがチームが今やるべきこと、そこに自分がどういう役割で貢献するか、を考えて行動できる ことを重視しています。 そのため採用も、現時点のスキル以上にカルチャーマッチを重視した採用をしています。
デザインもエンジニアリングも区分けなくできるのを理想としています。 developer.leaner.co.jp
社員に長く働いてもらいたい
リーナーは、すべての社員に長く働いてもらいたいと思ってます。 一人ひとりに長く働いてもらうからこそ、チームとして大きな成果を達成できると信じてます。 そのために「個の尊重」「チームの成果」そして「貢献実感」を意識してます。
必要性を言語化できないポジションはつくらない
強くこだわってるわけではありませんが、リーナーの開発組織には◯◯マネージャーはいません。 説明責任はリードする人が取り、実行責任・結果責任はフォロワー含めたメンバー全員が担うべきだと考えています。
少しでも興味があればご連絡ください
内容についてより詳しく聞いてみたいことがあればお近くのリーナーメンバーに気軽にお声がけください。 もしくはこちらからご応募いただけると助かります!
よくある質問
事業領域について
調達購買に詳しくないけど大丈夫ですか?
大丈夫です。 今いるメンバーも大多数が入社してから勉強して理解に励んでいます。 ビジネスサイドのメンバーも同様で、みんな入社してから一緒にキャッチアップしています。 キャッチアップするための仕組みも、エンジニアとセールス、CS が一緒になってつくっています。
調達購買という領域の魅力はなんですか?
調達購買は企業の利益を管理する重要なポジションですが、そのことが世間に十分に理解されているとは言えません。(例えば、メーカーが製品開発するときに、取引先から仕入れる物の原価によって利益が大きく左右されます)
そして調達購買で得られたデータは基幹システムとの連携が必須であるにも関わらず、まだデジタル化が十分に進んでいません。 その手付かずの領域を、自分たちの手で、新しい価値を社会に実装できる機会を持てることが大きな魅力です。
リーナーはこの領域のトップランナーとして、新しい調達購買のスタンダードをつくることをミッションにしてます。
リーナーのエンジニア・デザイナーとは
リーナーはどんな人が多いですか?
リーナーはエンタープライズ向けに toB SaaS を開発提供しています。 エンタープライズ領域でユーザーの業務に深く入り込んだプロダクトをつくるためには、お客様の日々の業務を理解することが必須です。
ソフトウェアのエンジニアリングについて話すのもみんな好きですが、それ以上に「ユーザーに不満なく使ってもらえるために何ができるか」を意識している人が多いです。 ビジネスサイドも同様で、エンジニアと一緒に価値あるプロダクトを顧客に提供したい、という気持ちで日々コミュニケーションを取ってくれています。
リーナーで働く面白さはなんですか?
つくってるプロダクトは今はまだ素朴な Web アプリです。そこに特段の技術的なチャレンジや面白さはありません。 それよりも、まだデジタル化が進んでいない余白のある領域をゼロからキャッチアップして、自分の手で価値を実装することに面白さがあります。
そこに最近は生成 AI の登場したこともあり、AI を使ってユーザーの業務をどれだけ変革できるのか?を考える面白さもでてきました。 新旧の技術を組み合わせ、ビジネスサイドと一緒になってユーザーを理解して、プロダクトをつくり込めるのが一番の面白さです。
フロントエンドとバックエンドで役割は分かれていますか?
分かれていません。 すべてのエンジニアはフロントエンドやバックエンド、デザイン、インフラ、QA、その他顧客ヒアリングなどプロダクトに関わることすべてをやっています。
ただし、人によって得意・不得意があり、興味関心も違うので、チームとして定期的に話し合い、お互いの役割について、期待値を調整してます。
(各分野のエキスパートによるイネブリングを強めていきたいとは考えてます)