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

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

リーナーについて

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

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

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

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

リーナーコネクトがローンチ 🎉

新規事業として取り組んでいたリーナーコネクトがお披露目されました。

まだチームとしても小さく、やらないといけないことがたくさんあるのでスタートアップを楽しみたい人にはピッタリです。

AIエージェントを活用したサービス提供

より幅広く、さらに高度に顧客に価値を届けるためにAIエージェントをうまく活用してサービス提供する開発が進んでいます。

まだAIモデルの選定や、安定して動かすためのノウハウには課題があるので、強くしていきたいです。

顧客からの関心はとても高く、AIを使って業務をどう変えられるかを考えるのはとてもワクワクする仕事です。

新たな役割として「チームカタリスト」を追加

チームが自律的に動くための環境づくりをする役割としてチームカタリストを追加しました。一般的なエンジニアリングチームではエンジニアリングマネージャー（EM）と呼ばれる役割に近いですが、リーナーではマネージャーが管理統制するのではなく、チームが自律的に動く仕組みづくりを重視しているため、このような名前づけをしました。

"カタリスト" には「周りの力を引き出して変化を起こす存在」という意味を込めています。

プロダクトラインナップ

リーナー見積 https://leaner.jp/sourcing
リーナー購買 https://leaner.jp/purchasing
リーナーコネクト https://leaner.jp/connect
プロダクト横断基盤
- 認証基盤（複数プロダクトで稼働中）
- データ分析基盤（一部プロダクトで運用中）
- その他プロダクト間連携に必要になる基盤（検討中）

優先的に進めたい採用のサマリー

リーナー購買 、リーナーコネクト、プロダクト横断基盤 は特に採用を進めて強化したいです。

また、AIエージェントを活用したサービス提供 を積極的に進めたいと考えているため、興味関心・強みがある人だと嬉しいです。

（これらに限らず随時エンジニア・デザイナー募集してるのでお気軽にお問い合わせください）

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

リーナー見積

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

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

リーナー見積 | Leaner | AI活用でソーシング高度化を実現する調達DXクラウド

現状

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

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

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

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

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

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

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

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

リーナー購買

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

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

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

現状

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

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

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

リーナーコネクト

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

リーナーコネクト | Leaner | 自律稼働するSRMプラットフォーム

現状

顧客ニーズを的確に捉えて、シンプルな機能で様々な課題を解けるプロダクトになりつつある
ビジネスサイド含めてもまだチームが小さいので、エンジニア・デザイナーとの距離感が近い
顧客企業とのシステム連携が増えてきてるので、連携のためのノウハウが必要になってきている

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

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

課題: システム連携

他社システムとの連携に関する調整ごとが増えてきました。顧客側との調整に関するノウハウ（すり合わせのためのチェックリストなど）が必要になり始めています。

認証基盤

ユーザーが一貫したログイン体験を得られること、一度のログインでプロダクト間をシームレスに移動できることを目指して、プロダクト横断の共通認証基盤を開発しています。各プロダクトが個別に認証機能を持つのではなく、共通基盤に集約することで、プロダクトチームがコア機能の開発に集中でき、セキュリティ対応も一箇所で完結できるようにしています。

現状

パスワード認証・SAML認証などをサポートしており、複数プロダクトで本番稼動しています
直近ではログイン方式の柔軟性向上や機能強化を進めています

課題

認証基盤は少人数で保守運用と機能開発を並行して進めており、やりたいことに対して手が足りていない状況です。例えば以下のような課題があります。

エンタープライズ顧客が求める多様な認証要件への対応
社内のカスタマーサポートが利用するプロダクト横断のユーザー管理
プロダクトチームが共通基盤を自走して活用できるようにする組み込み・イネーブルメント

データ分析基盤

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

現状

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

課題

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

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

現状

オブザーバビリティ向上のため、トレース、メトリクス、ログデータをDatadogに集約させている
Solid QueueやDelayed Jobのジョブキュー情報をメトリクスとして送信するための基盤を構築して、プロダクトチームに展開してる
セキュリティチェックやプラットフォーム診断等の年次対応
一定期間プロダクトチームに在籍して技術支援を行っている (Ruby/Railsやライブラリ更新、パフォーマンス改善等)
お客様のセキュリティチェックや定期的なプラットフォーム診断等への対応
AWS RI/SP購入

課題：SREにおけるAI Agentの活用

AIエージェントを使った障害調査やポストモーテム作成支援の実例が公開されており、リーナーでもその活用を通じてサイト信頼性の維持に努めたいと考えています。現在、テレメトリデータがDatadogとAWSに分散しているため、これらをDatadogに集約することで、AIエージェントが十分に機能する基盤を整えたいと考えています。

課題：AWS Copilotのサポート終了に伴う移行先検討

リーナーではデプロイツールとしてAWS Copilotを採用していますが、2026年6月にサポートが終了する事が決定しています。すぐに使えなくなる事はありませんが、喫緊の課題として移行先の検討とその作業を進める必要があります。

課題：ガバナンスの強化

オブザーバビリティやアクセス権の運用に対するお客様の要求水準はますます高まってきています。その対処がお客様の課題解決のスピードを削がないよう、そのままトイルになってしまわないよう、IaCやAIを駆使してイネーブルメントする方法を日々模索しています。

技術スタック

リーナー見積

バックエンド
- Rails8.1 / Ruby4.0
フロントエンド
- React19 / Next.js15
- TypeScript

リーナー購買

バックエンド
- Rails8.1 / Ruby 4.0
フロントエンド
- React18 / Next.js14
- TypeScript

リーナーコネクト

バックエンド
- Rails8.1 / Ruby 4.0
フロントエンド
- React19 / React Router 7
- TypeScript

インフラ・モニタリング

AWS ECS Fargate
AWS Amplify
Sentry
Datadog
Terraform

コミュニケーション

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 アプリとしての作り込みを進める
デザインシステム構築
- ただのコンポーネントカタログ集だけではなく、デザイン原則まで含めてチーム全体を巻き込んで構築する
その他、他役割の業務も幅広く含まれるが、専門的にやれる必要はない

■ 求める人物像

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

チームカタリスト

■ 業務で扱う主な知見

ピープルマネジメント
タレントマネジメント

■ 主な業務

チームのメンバーと1on1を通して成長を支援する
他チームと連携しながら、最適な人材のアサインを調整する
ビジネスサイドと連携し、チームが「自分たちのミッション」として合意し、自ら責任を持って動けるよう、議論のプロセスを設計・主導する

■ 求める人物像

チーム全体の最適を考えながら、各メンバーと向き合える人
チーム活動の流れを整えるのが好きな人
チームを管理統制するよりも、チームが自律的に活動できる土壌づくりが好きな人

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

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

バックエンド（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 を開発提供しています。エンタープライズ領域でユーザーの業務に深く入り込んだプロダクトをつくるためには、お客様の日々の業務を理解することが必須です。

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