こんにちは、リーナーの小久保 @yusuke_kokubo です。

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

リーナーについて

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

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

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

前回からの変更ハイライト

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

プロダクトにAIを組み込む開発が本格的に進んでます
エンタープライズ企業への導入・提案が進み、より調達・購買業務を幅広くカバーする開発が必要になりました
認証基盤の開発が進んできました
BIツールにLightdashを使うようになりました

プロダクトラインナップ

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

優先的に採用を進めたいプロダクト

リーナー購買、新プロダクトF は特に採用を進めて、プロダクトを強化したいです。

（それ以外でも随時エンジニア・デザイナー募集してます）

プロダクトごとの現状と課題

リーナー見積

メーカー企業にとって、原材料や部品の調達は製品の原価と利益を決める重要な活動です。リーナー見積は、企業の調達活動を見積業務から支えるサービスです。

バイヤーがサプライヤーに見積を依頼して、回収して、比較する、という煩雑な業務をシンプルに解決します。

リーナー見積

現状

顧客が順調に増え、ユーザーから多様な要望が出てきている
AIを活用して、より高度な見積業務のあり方を模索している
ビジネスサイドと建設的に議論しながらプロダクトのロードマップや仕様を決めている

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

調達DXを推進するリーナー「図面DB」機能を2025年5月に提供開始 | 株式会社Leaner Technologiesのプレスリリース

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

AIの可能性を探りながら、どこまでユーザーの業務にインパクトのある開発ができるかが問われます。

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

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

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

リーナー購買

リーナー購買は、間接材購買と言われる購買業務を支えるプロダクトです。オフィスの消耗品(例えば文房具や用紙)から周辺機器(PC, ソフトウェア)など、幅広く多様な材の購買に使われています。

企業の様々な人が、様々な商品を購入するため、すぐに誰でも簡単に使えることを大事にしています。そのうえ、管理者視点では購買業務のガバナンスにも注意を払う必要があり、利便性と厳密性を両立した開発が必要なプロダクトです。

リーナー購買 | Leaner | 顧客評価No1の購買システム

現状

某大企業へのリプレース導入が進み、本格的に企業の購買を支えるサービスになりつつある
案件は既存システムのリプレースがメインで、既存システムとの競合になることが多い
- 既存システムは機能性が高いが、使い勝手の面で評価が低い
- リーナー購買は機能性と使いやすさを両立している点でユーザーからの評価が高い

課題: 当たり前品質の拡充と作り込み

大企業の購買システムを置き換えるためには、幅広い業務をカバーしている必要があります。それと同時に、既存機能の作り込みも必要です。その両者を同時に進める必要があり、チーム力の強化が急務です。現状は業務委託の力を借りながら、なんとか回しています。

新プロダクト F

未公開の新規事業です。バイヤーとサプライヤーのコミュニケーション課題を、究極にシンプルな機能によって解くことを目指してます。

現状

プロダクトのコンセプトが初期顧客に受け入れられ、導入が進んでいる
顧客ニーズを的確に捉えて、シンプルな機能で様々な課題を解けるプロダクトになりつつある
ビジネスサイド含めてもまだチームが小さいので、エンジニア・デザイナーとの距離感が近い

課題:（Excel, Notionのような）汎用DB機能の開発

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

認証基盤

プロダクト横断の認証基盤です。

現状

開発が進んで、各プロダクトにも順次稼働し始めている
今後のプロダクト連携のためにも重要性が増している

課題

リソース不足によりやることが山積み

データ分析基盤

プロダクト横断のデータ分析基盤です。

現状

各プロダクトでの整備・活用が進んでいる
ビジネスサイドの協力しながらデータ活用に取り組んでいる

課題

1プロダクトで整ってきたので、他のプロダクトへの展開を考える

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
Sentry
Datadog

コミュニケーション

GitHub
Slack
Notion

開発ツール

Claude Code
Cursor Business
GitHub Copilot for Business
Devin

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

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

プロダクトエンジニア

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

フロントエンド（React、Next.js、React Router、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, React Router)の実装比重は大きくない

■ 主な業務

各プロダクトを横断して必要となる基盤機能の設計・開発
- 主に構築中の認証・認可基盤の保守・機能追加
- 将来的にはプロダクト間連携や共通マスターデータなど、各種のプロダクト横断機能に必要な設計・開発にも取り組む予定
各プロダクトへの横断基盤機能の組み込み・イネーブルメント
- 各プロダクトから共通基盤が使えるようにする組み込み実装を、プロダクトチームのエンジニアと協力して行う
- プロダクトチームのエンジニアが共通基盤周りの実装を保守できるよう、ドキュメント整備や知識のイネーブルメントを行う

■ 求める人物像

技術スタックは 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, Lightdash)

■ 主な業務

dbt を用いたデータマートの設計、構築および運用
メタデータ整備を通じたデータ民主化の推進
データ品質を考慮したテストの設計と実施

チーム組成のこだわり

役割はグラデーション

リーナーではデザイナーだけがデザインするわけではなく、エンジニアだけがエンジニアリングするわけではありません。メンバーそれぞれが チームが今やるべきこと、そこに自分がどういう役割で貢献するか を考えて行動できることを重視しています。

developer.leaner.co.jp

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

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

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

developer.leaner.co.jp

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

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

zenn.dev

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

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

herp.careers

よくある質問

事業領域について

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

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

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

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

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

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

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

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

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

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