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

この記事について

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

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

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

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

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

プロダクト横断の基盤

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

現状

プロダクトと事業は順調に成長している
- 顧客数、ユーザー数は加速度的に増えている
- 機能開発は進んでいるが、オンボーディングや運用まわりの改善が進んでいない
プロダクト間の連携
- プロダクトの連携が求められるようになってきたが、まだ基盤構築が進んでいない
デザイン観点でまだ足りてないことが全体的に多い
- プロダクトデザイン
  - ユーザーニーズの探索、ユーザー体験の設計
  - （toB SaaSに知見のある）UIデザイン
  - デザインシステム（開発中）
- プロダクトデザイン以外
  - イベント用のバナー、スポンサーブースなど
  - コーポレートカラー、ロゴなどのブランディング全般

課題

機能開発・改善と運用改善の両立
プロダクト間連携のための基盤構築
デザインバックグラウンドがあるデザインエンジニアの採用
SRE、プラットフォームエンジニアリングできる余地がまだたくさんある

技術スタック

Leaner見積
- バックエンド
  - Rails7 / Ruby 3.3
- フロントエンド
  - React / Next.js
  - TypeScript
Leaner購買
- バックエンド
  - Rails7 / Ruby 3.3
- フロントエンド
  - React / Next.js
  - TypeScript
インフラ
- AWS ECS
- AWS Amplify
コミュニケーション
- GitHub ( + GitHub Copilot for Business)
- Slack
- Notion

リーナーでプロダクト開発に関わる職種

リーナーのプロダクト開発は現状５職種あります。

デザインエンジニア
Webアプリケーションエンジニア
プロダクト横断基盤エンジニア
SRE
セキュリティエンジニア

※ 便宜上、職種は分かれていますが、一人が複数の職種を担うこともあり、誰がどの役割を担うかは状況に応じて変わります（リーナーでは役割はグラデーションだと考えてます）。ここで挙げている職種以外でも状況に応じて柔軟に検討したいと思ってます。

デザインエンジニア

業務で扱う主な技術スタックと知見
- プロトタイピング（Figma、Miro、実際に触れるWebアプリなど）
- フロントエンドエンジニアリング（React、TypeScript、TailwindCSS、shadcn/ui）
- アクセシビリティ
主な業務
- 機能開発・改善
  - セールス、カスタマーサクセスと協力しながら顧客の困りごとを掘り下げる
  - 顧客の困りごとをプロダクトの課題として整え、解決案のプロトタイプを作成する
  - 顧客からフィードバックをもらい、プロトタイプをつくりこむ
  - 解決案が整ったら、実際に動くWebアプリとして作りこむ
- デザインシステム構築
  - ただのコンポーネントカタログ集だけではなく、デザイン原則まで含めてチーム全体を巻き込んで構築する
- 主にフロントエンドの改善
  - コードベース
  - パフォーマンス
- その他、他職種の業務も幅広く含まれるが、専門的にやれる必要はない
メモ
- 直近で特に求めているのはデザインに強みのあるデザインエンジニア
  - ReactやTypeScriptなどに習熟する必要はない
  - ただし（エンジニアのサポートを受けながら）自分のローカル環境を構築し、エンジニアと一緒にプロダクトを開発して欲しい

Webアプリケーションエンジニア

業務で扱う主な技術スタックと知見
- フロントエンド（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)の計画・推進
  - 各プロダクトチームに上記が浸透するようイネーブルメントする
- 脆弱性診断・プラットフォーム診断などの計画・実施
- その他、セキュリティにまつわる施策の計画・実施
メモ
- 主にプロダクトセキュリティ・クラウドセキュリティを高める活動をお願いしたい
- 社内の情報管理規定など、より広いサイバーセキュリティについても意見をもらえたり手伝ってもらえるとより嬉しい(必須ではない)

チーム組成のこだわり

リーナーでチームをつくるうえで今まで大切にしてきたこと、これからも大切にしていきたいことをまとめてます。

職能・職種を超えてユーザーとプロダクトの課題に向き合う

職能・職種の違いは個人のスキルの強みの違いでしかありません。

自分たちが一番にやるべきことはユーザーとプロダクトの課題に向き合うことであり、それ以外のチーム体制・ツール・プロセスなどはすべて解くべき課題に追従して考えます。

「何のために技術を使うのか」を間違えないようにしてます。

（より大きな課題を解くためには、あえて余力を残し、人や研究開発に投資する必要もあります）

一人ひとりのオーナーシップを引き出す

メンバーはみんな自分の所属するプロダクトの意思決定に関わります。

誰もが自分なりの得意分野、自分なりの視点を持ってプロダクトに貢献することを尊重します。

そのために一つのチームをできる限り小さく維持しています。

みんなで成長する（ときどきコンフォートゾーンから出てみる）

※ まだ構想だけで余力がなくて実践できてません

自分の職種の業務だけでなく、たまには関わりの薄い業務もやれたら良いと思ってます。

会社業務の全体像を実体験として理解する
- → 視野が広がり、視座が上がる
自分の苦手（= 相手の得意）を実体験として理解する
- → 自分の苦手を得意な人にカバーしてもらうことで、チームとして一体感を持てるようになる
- → 相手のやりたいことをより理解できるようになる
- → 自分の得意に新しい視点を加えられるようになる

役割はグラデーションであり変わり続ける

最適なプロダクトマネジメント、開発手法、チーム体制などはその時々で変わります。

プロダクトのフェーズ、競合の存在、市場動向、会社の資本やチームが持ってる人材・スキル・ツールなどの色んな要素によって、取るべき最適解が変わります。

それを特定の役割の人だけが考えて判断するのではなく、みんなが自分の得意分野を活かして自分ならではの視点を持ってチームの最適解を探し続けることを大事にしてます。

そのためにリーナーでは、チームメンバー間や職種・職能をまたいだコミュニケーションの場をつくることを大事にしてます。

例えば、四半期ごとにチームとしてやるべきこと、自分がそれにどう貢献するかをチームと擦り合わせる
例えば、プロダクトのマネジメントやデザインはみんなを巻き込んでやる
- 営業やカスタマーサクセスなども含めてみんなでデザインを考えて、フィードバックを送り合う
例えば、現状のチームメンバーで不足しているスキルがある場合
- 安易に採用を考える前に、今のメンバーでできることをまずやる
- その方が採用したい人の解像度も高まる

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

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

herp.careers

よくある質問

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

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

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

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

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

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

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

分かれていません。すべてのエンジニアはフロントエンドやバックエンド、デザイン、インフラ、QA、その他顧客ヒアリングなどプロダクトに関わることすべてをやっています。（各分野のエキスパートによるイネブリングを強めていきたいとは考えてます）

リーナー開発者ブログ

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

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