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

この記事は、リーナーという会社の名前は知ってるけど、どんな会社なのかもうちょっと知れるといいな、という人向けの簡潔な紹介記事です。内容についてより詳しく聞いてみたいことがあればお近くのリーナーメンバーに気軽にお声がけください。

プロダクトとチームの現状と課題

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

二つのプロダクト、一つの新規プロダクト

リーナー見積 https://leaner.jp/sourcing
リーナー購買 https://leaner.jp/purchasing
新プロダクト（開発中）

プロダクト横断の基盤

ID基盤（開発中）
データ分析基盤（開発中）
その他プロダクト間連携に必要になる基盤（検討中）

現状

プロダクトと事業

Good
- 顧客数、ユーザー数は加速度的に増えている
- ビジネスサイドと建設的に議論しながら、プロダクトの意思決定ができてる
More
- 機能開発は進んでいるが、運用まわりの改善が進んでいない

プロダクト間の連携

Good
- 複数プロダクトを組み合わせて使いたい顧客ニーズが高まっている
More
- プロダクトの連携が求められるようになってきたが、まだ基盤構築が進んでいない

プロダクトデザイン

Good
- ビジネスサイドを巻き込んで、デザイン原則、デザインシステムをつくり始めている
More
- ユーザーニーズの探索、ユーザー体験の設計をうまくできてる自信がない
- toB SaaSに適したUIデザインにまだ伸び代がある
- デザインシステムを育てていきたいが知見とリソースが足りない

課題

プロダクト間連携のための基盤構築

直近の大きな課題は基盤構築です。詳しくはこちらに書いてますので、興味ある方は是非お読みください。

リーナーのマルチプロダクトを支える技術基盤チームの発足とこれから - リーナー開発者ブログ

デザインバックグラウンドがあるメンバーの採用

リーナーはtoB SaaSなので、意匠や装飾のデザインニーズは低いです。それよりも、情報を構造的に整理して骨格をつくるデザインを強く求められます。

デザインシステムをつくり始めていますが、これを育てていくうえでも、ただのUIコンポーネント集ではなく、非デザイナー、非エンジニアも巻き込んでみんなでデザインする環境づくりをしたいと考えてます。

調達・購買というまだ未開拓で混沌とした業務をうまく整理して、プロダクトに落とし込むことにモチベーションを感じられるデザイナーの方を採用できたら嬉しいです。

そろそろデザイナーを採用したい！という話 ~ Leaner Technologies ~｜yusuke_kokubo

SRE、プラットフォームエンジニアリングできる余地がまだたくさんある

プロダクトチームがプロダクトのドメイン領域に集中できるように、それ以外で迷うことを減らしたいです。現状はまだ十分にできてるとは言い難く、開発環境の改善、運用監視など、できることがたくさんあります。

機能開発と運用改善の両立

特にリーナー見積においては、歴史的な経緯もあり、運用を改善できる余地がたくさんあります。その一方で、プロダクトの付加価値を開発するための探索も必要です。

リーナーは大規模なエンタープライズ領域へプロダクトを展開しているため、この両方をうまく両立することが課題です。

課題まとめ

技術スタック

Leaner見積

バックエンド
- Rails7 / Ruby 3.3
フロントエンド
- React / Next.js
- TypeScript

Leaner購買

バックエンド
- Rails7 / Ruby 3.3
フロントエンド
- React / Next.js
- TypeScript

新プロダクト（開発中）

バックエンド
- Rails7 / Ruby 3.3
フロントエンド
- React / Remix
- TypeScript

インフラ

AWS ECS
AWS Amplify

コミュニケーション

GitHub ( + GitHub Copilot for Business)
Slack
Notion

リーナーでプロダクト開発に関わる役割

リーナーのプロダクト開発は現状５つの役割があります。

ユーザーが触れるプロダクトを開発して直接的に事業貢献する役割
- プロダクトデザインエンジニア
- プロダクトエンジニア
- プロダクト横断基盤エンジニア
プロダクト開発を支援して間接的に事業貢献する役割
- SRE
- セキュリティエンジニア

※ 便宜上、分かれていますが、誰がどの役割を担うかは状況に応じて変わります（リーナーでは役割はグラデーションだと考えてます）。

ここで挙げている役割以外でも、状況に応じて柔軟に検討すべきだと思ってますので、気になることがあればお気軽にお尋ねください。

プロダクトデザインエンジニア

業務で扱う主な技術スタックと知見
- プロトタイピング（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の設計
  - アラートの見直し、設計
  - パフォーマンス指針の整備
- 各プロダクトの運用のサポート・イネーブルメント
  - 各プロダクトチームでインフラやモニタリングを保守できるようイネーブルメントする
  - 各プロダクトチームが扱いやすいようプラットフォームエンジニアリングを行う
- その他、各プロダクトエンジニアと協力してのパフォーマンスチューニングの実施などプロダクトの安定運用に関わる作業の計画・推進
メモ
- 現状は技術基盤チームが中心になって各プロダクトのインフラ・モニタリングを保守しているが、徐々に各プロダクトチームで見えるようイネーブルメントする形にシフトしたいと考えている

セキュリティエンジニア

業務で扱う主な技術スタックと知見
- Webアプリケーションのセキュリティに関する知識・経験
  - 社内に知見がほとんどなく新規立ち上げになるため、セキュリティ関連の1年以上の経験必須
- バックエンド（Rails、MySQL）
- インフラ（AWS・GCP）
主な業務
- プロダクトセキュリティ指針の設定・実施
  - 社内規定やガイドラインの設定
  - 開発サイクル全体でのセキュリティ施策(DevSecOps)の計画・推進
  - 各プロダクトチームに上記が浸透するようイネーブルメントする
- 脆弱性診断・プラットフォーム診断などの計画・実施
- その他、セキュリティにまつわる施策の計画・実施
メモ
- 主にプロダクトセキュリティ・クラウドセキュリティを高める活動をお願いしたい
- 社内の情報管理規定など、より広いサイバーセキュリティについても意見をもらえたり手伝ってもらえるとより嬉しい(必須ではない)

チーム組成のこだわり

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

詳しくはこちらに書いてます。リーナーならではの組織のあり方を知ってもらううえで、とても重要な情報です。ぜひあわせてお読みください。

developer.leaner.co.jp

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

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

herp.careers

よくある質問

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

大丈夫です。今いるメンバーも大多数が入社してから勉強して理解に励んでいます。

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

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

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

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

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

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

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

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

リーナー開発者ブログ

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

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