リーナー開発者ブログ

リーナー開発者の今を発信するブログです。

リーナープロダクトの現状と課題、採用情報 2025年10月版

こんにちは、リーナーの小久保 id:yusuke-k です。

この記事は、リーナーという会社の名前は知ってるけど、どんな会社なのかもうちょっと知れるといいな、という人向けの簡潔な紹介記事です。

リーナーについて

リーナーは調達購買領域で、BtoB SaaS を開発提供しているスタートアップです。 調達購買とはいわゆる「企業の買い物」です。複雑なプロセスが絡み合う領域ですが、現在はその中でも、見積や購買（発注）における業務を中心に扱っています。

例えばリーナー見積というプロダクトでは、見積業務を扱っています。

他にも、調達購買にはモノを買う側のバイヤー企業と、売る側のサプライヤー企業の間に様々なコミュニケーションが必要です。リーナーは両者をつなぐプラットフォームとなる製品群を開発しています。

前回からのアップデート

前回はこちら: リーナープロダクトの現状と課題、採用情報 2025年07月版 - リーナー開発者ブログ

  • 一人目QAエンジニアが入社して、品質保証の話が進みそうです
  • プロダクトデザイナーが2名入社して、デザインの議論も活発になってきました
  • 複雑で難易度の高いエンジニアリングの領域が増えてきました（詳細は後述）

プロダクトラインナップ

  • リーナー見積 https://leaner.jp/sourcing
  • リーナー購買 https://leaner.jp/purchasing
  • 新プロダクト F（初期顧客が導入中）
  • プロダクト横断基盤
    • ID基盤（開発中）
    • データ分析基盤（開発中）
    • その他プロダクト間連携に必要になる基盤（検討中）

事業・プロダクトの現状と課題

Good

  • 顧客数、ユーザー数は順調に増えている
  • 企業の調達・購買を支える重要なサービスになっている
  • ビジネスサイドと対等な立場で建設的に議論しながら、プロダクトのロードマップを決めている

More

  • 探索的に付加価値を生み出す開発、既存の価値を活用して伸ばす開発、運用改善のための開発、それぞれでやることがたくさんある
  • プロダクト横断した基盤開発がまだ十分に進んでない
    • 特にID基盤、データ分析基盤の緊急度が高い

チームの現状と課題

Good

  • セールス・CSなどのビジネスサイドのメンバーと、お互いの役割を尊重しながら同じ目標に向かっている
  • 一人ひとりが自分の貢献を感じられる環境なので、安心して仕事に集中できている

More

  • リーナーとしてビジネスサイドとエンジニア・デザイナーがお互いの仕事を相互補完できる余地がある

エンジニアリングの現状と課題

（主に製造業向け）図面を活用できる機能の開発

prtimes.jp

製造業にとって、図面を活用した最適な調達・購買活動はとてもニーズが高いです。 AIを活用して図面の情報を読み取り、その情報をもとに見積を出したり、関係者とのコミュニケーションを円滑にする開発はとてもホットなトピックです。

（Airtable, Notion DBのような）汎用的に使えるDB機能の開発

調達・購買のプラットフォームはモノを買う側のバイヤー企業と、売る側のサプライヤー企業がいます。 企業間の取引には、多種多様なデータが相互にやり取りされます。 それらすべてのデータを、柔軟なデータ構造で表現できて、高速に扱えるDBをつくる必要があります。

ユーザーアカウント管理の再構築

調達・購買のプラットフォームはモノを買う側のバイヤー企業と、売る側のサプライヤー企業がいます。 それぞれの企業のユーザーアカウントを管理する必要があるのですが、そのアカウント管理をどう構築するべきか、を見直しています。

どの組織に、どこまでの情報を所有させるか、という全体最適を考慮した設計を考える必要があります。

SRE、プラットフォームエンジニアリング

各チームで SLO を策定して、運用をはじめました。 現状の課題として、運用を始めたばかりで効果的に使えているとは言えない状況なので、チーム単体で適切に SLO 運用ができるように支援していきたいです。

また、Terraform による IaC を進めています (AWS, Datadog, Sentry, GitHub)が、まだまだリソースのインポートが終わってません。モジュール化して開発効率も上げたいです。

プロダクトデザインの現状と課題

プロダクトデザイナーが増えて、デザインに関する議論が活発にできるようになってきました。 今まではエンジニア中心にプロダクトを開発してきましたが、今後はデザイン視点を増やしていけるように取り組んでいます。

リーナーではプロダクトデザインもみんなでやっています - リーナー開発者ブログ

各チームの課題

技術スタック

リーナー見積

  • バックエンド
    • Rails8 / Ruby3.4
  • フロントエンド
    • React18 / Next.js14
    • TypeScript

リーナー購買

  • バックエンド
    • Rails8 / Ruby 3.4
  • フロントエンド
    • React18 / Next.js14
    • TypeScript

新プロダクト F

  • バックエンド
    • Rails8 / Ruby 3.4
  • フロントエンド
    • React19 / React Router 7
    • TypeScript

インフラ

  • AWS ECS
  • AWS Amplify

コミュニケーション

  • GitHub
  • Slack
  • Notion

開発ツール

  • Claude Code
  • Cursor Business
  • GitHub Copilot for Business
  • Devin

リーナーのプロダクト開発に今必要な役割

※ 一人のメンバーが必ずしも一つの役割しか持たない、というわけではありません。

プロダクトエンジニア

■ 業務で扱う主な技術スタックと知見

  • フロントエンド（React、Next.js、Remix、TypeScript、TailwindCSS）
  • バックエンド（Rails、MySQL）
  • インフラ・モニタリング（AWS、Sentry、Datadog）
  • その他、他役割の業務も幅広く含まれるが、専門的にやれる必要はない

■ 主な業務

  • 機能開発・改善
    • セールス、カスタマーサクセスと協力しながら顧客の困りごとを掘り下げる
    • 顧客の困りごとをプロダクトの課題として整え、解決案のプロトタイプを作成する
    • 顧客からフィードバックをもらい、プロトタイプをつくりこむ
    • 解決案が整ったら、実際に動く Web アプリとして作りこむ
  • フロントエンド・バックエンドの改善
    • コードベース
    • パフォーマンス
    • DevOps
  • その他、他役割の業務も幅広く含まれるが、専門的にやれる必要はない

プロダクトデザイナー

■ 業務で扱う主な技術スタックと知見

  • Must
    • プロトタイピング・デザイン (Figma)
    • フロントエンド（HTML, CSS, 基本的なJavaScript）
    • 基礎的なアクセシビリティ知識
  • Nice to Have
    • フロントエンド (React, TypeScript, TailwindCSS, shadcn/ui)

■ 主な業務

  • 機能開発・改善
    • セールス、カスタマーサクセスと協力しながら顧客の困りごとを掘り下げる
    • 顧客の困りごとをプロダクトの課題として整え、解決案のプロトタイプを作成する
    • 顧客からフィードバックをもらい、プロトタイプをつくりこむ
    • 解決案が整ったら、プロダクトエンジニアと並走して Web アプリとしての作り込みを進める
  • デザインシステム構築
    • ただのコンポーネントカタログ集だけではなく、デザイン原則まで含めてチーム全体を巻き込んで構築する
  • その他、他役割の業務も幅広く含まれるが、専門的にやれる必要はない

■ 求める人物像

  • デザインに軸を置きつつ、エンジニアリングやユーザーの課題解決まで含めてプロダクトデザインにこだわれる人が望ましい
  • エンジニアやセールスなど、デザイナー以外の役割のメンバーとも一緒にデザインする場をリードできる人が望ましい

プロダクト横断基盤エンジニア

■ 業務で扱う主な技術スタックと知見

  • バックエンド（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

誰がどれだけデザイン・エンジニアリングをやるかは一人ひとりのグラデーションの中で決まります。 developer.leaner.co.jp

社員に長く働いてもらいたい

リーナーは、すべての社員に長く働いてもらいたいと思ってます。 一人ひとりに長く働いてもらうからこそ、チームとして大きな成果を達成できると信じてます。 そのために「個の尊重」「チームの成果」そして「貢献実感」を意識してます。

developer.leaner.co.jp

必要性を言語化できないポジションはつくらない

強くこだわってるわけではありませんが、リーナーの開発組織には◯◯マネージャーはいません。 説明責任はリードする人が取り、実行責任・結果責任はフォロワーとなるメンバー全員が担うべきだと考えています。

zenn.dev

少しでも興味があればご連絡ください

内容についてより詳しく聞いてみたいことがあればお近くのリーナーメンバーに気軽にお声がけください。 もしくはこちらからご応募いただけると助かります！

herp.careers

よくある質問

事業領域について

調達購買に詳しくないけど大丈夫ですか？

大丈夫です。 今いるメンバーも大多数が入社してから勉強して理解に励んでいます。 ビジネスサイドのメンバーも同様で、みんな入社してから一緒にキャッチアップしています。 キャッチアップするための仕組みも、エンジニアとセールス、CS が一緒になってつくっています。

調達購買という領域の魅力はなんですか？

調達購買は企業の利益を管理する重要なポジションですが、そのことが世間に十分に理解されているとは言えません。（例えば、メーカーが製品開発するときに、取引先から仕入れる物の原価によって利益が大きく左右されます）

そして調達購買で得られたデータは基幹システムとの連携が必須であるにも関わらず、まだデジタル化が十分に進んでいません。 その手付かずの領域を、自分たちの手で、新しい価値を社会に実装できる機会を持てることが大きな魅力です。

リーナーはこの領域のトップランナーとして、新しい調達購買のスタンダードをつくることをミッションにしてます。

リーナーのエンジニア・デザイナーとは

リーナーはどんな人が多いですか？

リーナーはエンタープライズ向けに toB SaaS を開発提供しています。 エンタープライズ領域でユーザーの業務に深く入り込んだプロダクトをつくるためには、お客様の日々の業務を理解することが必須です。

ソフトウェアのエンジニアリングについて話すのもみんな好きですが、それ以上に「ユーザーに不満なく使ってもらえるために何ができるか」を意識している人が多いです。 ビジネスサイドも同様で、エンジニアと一緒に価値あるプロダクトを顧客に提供したい、という気持ちで日々コミュニケーションを取ってくれています。

リーナーで働く面白さはなんですか？

まだデジタル化が進んでいない余白のある領域をゼロからキャッチアップして、自分の手で価値を実装することに面白さがあります。 ビジネスサイドのメンバーがみんなプロダクト開発に協力的なので、ユーザーの困りごとや課題解決を一緒に考えてプロダクトをつくってます。

最近は生成 AI の登場したこともあり、AI を使ってユーザーの業務をどれだけ変革できるのか？を考える面白さもでてきました。 新旧の技術を組み合わせ、ビジネスサイドと一緒になってユーザーを理解して、プロダクトをつくり込めるのが一番の面白さです。

フロントエンドとバックエンドで役割は分かれていますか？

分かれていません。 すべてのエンジニアはフロントエンドやバックエンド、デザイン、インフラ、QA、その他顧客ヒアリングなどプロダクトに関わることすべてをやっています。

ただし、人によって得意・不得意があり、興味関心も違うので、チームとして定期的に話し合い、お互いの役割について、期待値を調整してます。

（各分野のエキスパートによるイネブリングを強めていきたいとは考えてます）