こんにちは、リーナーの小久保 id:yusuke-k です。
この記事は、リーナーという会社の名前は知ってるけど、どんな会社なのかもうちょっと知れるといいな、という人向けの簡潔な紹介記事です。内容についてより詳しく聞いてみたいことがあればお近くのリーナーメンバーに気軽にお声がけください。
プロダクトとチームの現状と課題
リーナーは調達購買領域で、BtoB SaaSを開発提供しているスタートアップです。 調達購買とはいわゆる「企業の買い物」です。複雑なプロセスが絡み合う領域ですが、現在はその中でも、見積や購買(発注)における業務を中心に扱っています。
プロダクトラインナップ
- リーナー見積 https://leaner.jp/sourcing
- リーナー購買 https://leaner.jp/purchasing
- 新プロダクトF(開発中)
- 新プロダクトM(開発中)
- プロダクト横断基盤
- ID基盤(開発中)
- データ分析基盤(開発中)
- その他プロダクト間連携に必要になる基盤(検討中)
現状
プロダクトと事業
- Good
- 顧客数、ユーザー数は加速度的に増えている
- ビジネスサイドと建設的に議論しながら、プロダクトの意思決定ができてる
- More
- 機能開発は進んでいるが、運用まわりの改善が進んでいない
プロダクト間の連携
- Good
- 複数プロダクトを組み合わせて使いたい顧客ニーズが高まっている
- More
- プロダクトの連携が求められるようになってきたが、まだ基盤構築が進んでいない
プロダクトデザイン
- Good
- ビジネスサイドを巻き込んで、デザイン原則、デザインシステムをつくり始めている
- More
- ユーザーニーズの探索、ユーザー体験の設計をうまくできてる自信がない
- toB SaaSに適したUIデザインにまだ伸び代がある
- デザインシステムを育てていきたいが知見とリソースが足りない
課題
AIなどの最新テクノロジーのプロダクトへの活用
生成AIをはじめとした最新テクノロジーをうまく活用するための取り組みがまだ十分にはできていません。 DevinやCursorなど自分たちの開発環境には取り入れていますが、それ以上に生成AIをプロダクトの機能として組み込んでお客様に提供するまでの知見はまだ十分とは言えません。
エンジニアリングで解決できる選択肢を増やすためにも強化する必要があると考えています。
プロダクト間連携のための基盤構築
プロダクトとしての直近の大きな課題は基盤構築です。 詳しくはこちらに書いてますので、興味ある方は是非お読みください。
リーナーのマルチプロダクトを支える技術基盤チームの発足とこれから - リーナー開発者ブログ
デザインバックグラウンドがあるメンバーの採用
リーナーはtoB SaaSなので、意匠や装飾のデザインニーズは低いです。 それよりも、情報を構造的に整理して骨格をつくるデザインを強く求められます。
デザインシステムをつくり始めていますが、これを育てていくうえでも、ただのUIコンポーネント集ではなく、非デザイナー、非エンジニアも巻き込んでみんなでデザインする環境づくりをしたいと考えてます。
調達・購買というまだ未開拓で混沌とした業務をうまく整理して、プロダクトに落とし込むことにモチベーションを感じられるデザイナーの方を採用できたら嬉しいです。
そろそろデザイナーを採用したい!という話 ~ Leaner Technologies ~|yusuke_kokubo
SRE、プラットフォームエンジニアリングできる余地がまだたくさんある
プロダクトチームがプロダクトのドメイン領域に集中できるように、それ以外で迷うことを減らしたいです。 現状はまだ十分にできてるとは言い難く、開発環境の改善、運用監視など、できることがたくさんあります。
直近一人SREとして入社したメンバーが取り組み始めてくれていますが、今後強めていきたいです。
機能開発と運用改善の両立
特にリーナー見積においては、歴史的な経緯もあり、運用を改善できる余地がたくさんあります。 その一方で、プロダクトの付加価値を開発するための探索も必要です。
リーナーは大規模なエンタープライズ領域へプロダクトを展開しているため、この両方をうまく両立することが課題です。
直近は外部ベンダーに業務委託として一部開発のお手伝いをお願いしています。
課題まとめ
技術スタック
リーナー見積
- バックエンド
- Rails8 / Ruby3.4
- フロントエンド
- React18 / Next.js14
- TypeScript
リーナー購買
- バックエンド
- Rails8 / Ruby 3.4
- フロントエンド
- React18 / Next.js14
- TypeScript
新プロダクトF(開発中)
- バックエンド
- Rails8 / Ruby 3.3
- フロントエンド
- React18 / React Router 7
- TypeScript
インフラ
- AWS ECS
- AWS Amplify
コミュニケーション
- GitHub
- Slack
- Notion
開発ツール
- Cursor Business
- GitHub Copilot for Business
- Devin
リーナーのプロダクト開発に今必要な役割
※ 便宜上、役割が分かれていますが、誰がどの役割を担うかは状況に応じて変わります(リーナーでは役割はグラデーションだと考えてます)。 developer.leaner.co.jp
以下、挙げている役割以外でも、状況に応じて柔軟に検討しています。
プロダクトデザインエンジニア
- 業務で扱う主な技術スタックと知見
- プロトタイピング(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の設計
- アラートの見直し、設計
- パフォーマンス指針の整備
- 各プロダクトの運用のサポート・イネーブルメント
- 各プロダクトチームでインフラやモニタリングを保守できるようイネーブルメントする
- 各プロダクトチームが扱いやすいようプラットフォームエンジニアリングを行う
- その他、各プロダクトエンジニアと協力してのパフォーマンスチューニングの実施などプロダクトの安定運用に関わる作業の計画・推進
- 運用インフラ整備
- メモ
- 現状は技術基盤チームが中心になって各プロダクトのインフラ・モニタリングを保守しているが、徐々に各プロダクトチームで見えるようイネーブルメントする形にシフトしたいと考えている
チーム組成のこだわり
社員に長く働いてもらいたい
リーナーは、すべての社員に長く働いてもらいたいと思ってます。 一人ひとりに長く働いてもらうからこそ、チームとして大きな成果を達成できると信じてます。 そのために「個の尊重」「チームの成果」そして「貢献実感」を意識してます。
必要性を言語化できないポジションはつくらない
少しでも興味があればご連絡ください
内容についてより詳しく聞いてみたいことがあればお近くのリーナーメンバーに気軽にお声がけください。 もしくはこちらからご応募いただけると助かります!
よくある質問
事業領域について
調達購買に詳しくないけど大丈夫ですか?
大丈夫です。 今いるメンバーも大多数が入社してから勉強して理解に励んでいます。 ビジネスサイドのメンバーも同様で、みんな入社してから一緒にキャッチアップしています。 キャッチアップするための仕組みも、エンジニアとセールス、CSが一緒になってつくっています。
調達購買という領域の魅力はなんですか?
調達購買は企業の利益を管理する重要なポジションですが、そのことが世間に十分に理解されているとは言えません。(例えば、メーカーが製品開発するときに、取引先から仕入れる物の原価によって利益が大きく左右されます)
そして調達購買で得られたデータは基幹システムとの連携が必須であるにも関わらず、まだデジタル化が十分に進んでいません。 その手付かずの領域を、自分たちの手で、新しい価値を社会に実装できる機会を持てることが大きな魅力です。
リーナーはこの領域のトップランナーとして、新しい調達購買のスタンダードをつくることをミッションにしてます。
リーナーのエンジニア・デザイナーとは
リーナーはどんな人が多いですか?
リーナーはエンタープライズ向けにtoB SaaSを開発提供しています。 エンタープライズ領域でユーザーの業務に深く入り込んだプロダクトをつくるためには、お客様の日々の業務を理解することが必須です。
ソフトウェアのエンジニアリングについて話すのもみんな好きですが、それ以上に「ユーザーに不満なく使ってもらえるために何ができるか」を意識している人が多いです。 ビジネスサイドも同様で、エンジニアと一緒に価値あるプロダクトを顧客に提供したい、という気持ちで日々コミュニケーションを取ってくれています。
リーナーで働く面白さはなんですか?
つくってるプロダクトは今はまだ素朴なWebアプリです。そこに特段の技術的なチャレンジや面白さはありません。 それよりも、まだデジタル化が進んでいない余白のある領域をゼロからキャッチアップして、自分の手で価値を実装することに面白さがあります。
そこに最近は生成AIの登場したこともあり、AIを使ってユーザーの業務をどれだけ変革できるのか?を考える面白さもでてきました。 新旧の技術を組み合わせ、ビジネスサイドと一緒になってユーザーを理解して、プロダクトをつくり込めるのが一番の面白さです。
フロントエンドとバックエンドで役割は分かれていますか?
分かれていません。 すべてのエンジニアはフロントエンドやバックエンド、デザイン、インフラ、QA、その他顧客ヒアリングなどプロダクトに関わることすべてをやっています。
ただし、人によって得意・不得意があり、興味関心も違うので、チームとして定期的に話し合い、お互いの役割について、期待値を調整してます。
(各分野のエキスパートによるイネブリングを強めていきたいとは考えてます)