以下の内容はhttps://nealle-dev.hatenablog.com/より取得しました。


JDDUG meetup #16@福岡 参加レポート~人生初の登壇をしてきた~

はじめに

こんにちは、SREチームの森原(@daichi_morihara)です。2/26に開催された JDDUG(Japan Datadog User Group) meetup #16@福岡に参加してきました。人生初の登壇も行なったので、記念にイベント参加レポートを書きたいと思います!

会場到着

会場に入った瞬間にとてもお洒落な料理が目に入ってきて感動しました!お腹が空かないようにイベント直前にビッグマックとサムライマックを食べてきた自分を恨みましたね (笑)
(もちろん別腹なので、美味しくいただきました!)

見てるだけで幸せになるお洒落な料理

ハンズオンコンテンツ

前半パートではハンズオンセッションを開催していただきました。実際にDatadogを触りながら、問題を解きポイントを獲得していくゲーム形式で、非常に盛り上がったセッションでした🔥🔥
ニーリーでは導入していない機能にも触れることができ、非常に有意義な時間となりました!

特に印象に残った機能:Continuous Profiler

ハンズオンの中でも、最も印象に残ったのがContinuous Profilerの体験です。Continuous Profilerは関数レベルでCPU、メモリ、I/Oなどのリソースの使用状況を監視するツールです。 APM(トレース)と合わせると、レスポンスタイムの長いリクエストにおいて、どの処理がボトルネックであるかの特定にとどまらず、「ボトルネックの原因(どの関数が原因で処理が長くなっているのか)」まで把握することができる非常に強力なツールであることを、実際に触れて実感することができました!

ハンズオンセッションの様子

登壇

「Datadogのログコスト最適化」というテーマで発表させていただきました。

speakerdeck.com

イベント参加者も多く、発表前はかなりビビっていましたが、緊張しながらも人前で話すという非常にいい経験を積むことができました!

私が発表してる様子

ログコスト最適化に関する取り組みの詳細は、こちらのブログにまとめておりますので、ご興味のある方はぜひ一読ください!

nealle-dev.hatenablog.com

交流

meetupを通じて多くの方とお会いでき、楽しい時間を過ごすことができました。現地イベントならではの良さを体感し、今後はオフラインイベントにも積極的に参加していきたいと思いました!

meetup参加者の全体写真

p.s
懇親会の2次会で食べた福岡名物?のラーソーメン(ラーメンとそうめんが融合した料理)は、締めにピッタリでとても美味しかったです。福岡に行く機会があればぜひ食べてみてください!

「1億人規模の経済圏」のプラットフォームをつくる。共通基盤プロダクトエンジニアを募集します!

こんにちは。ニーリー VPoEの菊地(@_tinoji)です。

ニーリーでは現在、マルチプロダクト化を加速するためにエンジニア採用をめちゃくちゃ強化中です。 note.nealle.com

あらゆるポジションで募集を行っているのですが、今日はその中でもエンジニアのキャリアの特異点となりうる、共通基盤プロダクトエンジニアというポジションについて宣伝させてください。

1億人に利用されるポテンシャルを持つ共通基盤をつくっている

ニーリーの共通基盤プロダクトエンジニアが今どんなことにチャレンジしているかについては、ぜひこちらの記事をお読みください。 nealle-dev.hatenablog.com

簡単に言うと、この2点に集約されます。

  • 急激に加速するマルチプロダクト化のために共通基盤を立ち上げている。
  • その基盤は将来的に日本で最も多くの自動車ユーザーに使われるポテンシャルがある。

「日本で最も多くの自動車ユーザー」を具体的に言うと・・・

内閣府の調べによると、令和5年末時点での運転免許証保有者数は約8,186万人で、前年より約2万人増えており増加トレンドが続いています。

「自動車ユーザー」とは言いましたが、例えば『Park Direct』はtoB側のユーザーとして不動産管理会社様や駐車場オーナーの方もいますし、『Park Direct for Business』では企業が保有する法人車を管理する従業員の方もいます。 さらに、当然モビリティに隣接するドメインにも拡大を目指しているので、これらを考慮すると「1億人」と言っても差し支えない規模になると思います。

1億人にリーチできるサービスをGeminiに聞いてみると、LINEヤフー、楽天、リクルート、NTTドコモのような、いわゆる「経済圏」を想起させるプラットフォーマーが並びます。

まさにニーリーはいま、1億人規模の経済圏に成長しうるサービス群、そしてそのための共通基盤をつくっているのです。

具体的に開発している/しようとしているものの例はこんな感じです。羅列すると素朴な印象になってしまいますが、すべて「1億人に使われるようになっていく」という前提で考えるとワクワクしますね。

共通基盤     概要
認証基盤 複数のサービスで統一的なログイン体験を提供するのはもちろん、エンタープライズのユーザー増加に伴って高まっているセキュリティ要件にも応える。
会員基盤 サービスを横断して会員情報を引き継ぎ、シームレスな体験を実現する。
決済基盤 サービスから接続することにより、最適な決済代行サービスを柔軟に選択するなど。
ポイント基盤 ポイントを起点としてサービス間の相互利用を活発化。ポイ活などの可能性も?

この規模の共通基盤開発の0→1に立ち会うチャンスは極めてレア

「1億人規模の経済圏の共通基盤開発にエンジニアとして携われる可能性」について、頭の中でフェルミ推定をするかAIに聞いてみてほしいのですが、当然ながらめちゃめちゃ希少です。

僕のGeminiの回答は以下でした。

ソフトウェアエンジニアのキャリアとして、「1億人規模のWebサービス群/エコシステム」の共通基盤開発の黎明期(いわゆる0→1)に携われる経験はどれくらい希少なことですか?国内の事例を参考に、全体のエンジニアの何%にチャンスがあるかを推測してください。
客観的な事実と確度の高い論理によって回答してください。私の意見に合わせる必要はありません。

「1億人規模のWebサービス群/エコシステム」における共通基盤(Common Platform)の黎明期(0→1)に携わる経験は、日本のソフトウェアエンジニア市場において「極めて希少(数千人に1人、あるいはそれ以下)」なキャリアと言えます。
客観的な統計と市場構造から、その希少性を論理的に推計します。
(中略)
・市場全体: 1,440,000人
・100M規模企業の基盤エンジニア: 約5,000人(全体の0.34%)
・その中で「0→1」フェーズに立ち会う人数: 10年スパンで見た場合、同時にこのフェーズを経験しているのは国内で 数百人(300〜500人程度) と推定されます。
推計結果: 1,440,000人 ÷ 500人 = 約0.035% つまり、「ソフトウェアエンジニア約3,000人に1人」 程度の希少性です。

そこまで大げさではない確率なんじゃないかと思います。ぜひお手元のAIで検算してみてください。

「まだいらない」と「すでにある」の狭間に飛び込む

このレアリティについては、僕も自らの体験から実感しています。僕が新卒で入社した会社はいわゆるメガベンチャーに分類されるのですが、そこまで行くと共通基盤は「すでにある」のが普通です。

一方でスタートアップがどうかと言うと、1つのプロダクトがしっかり軌道に乗って第2第3のプロダクトが出現してくるまでは、共通基盤は「まだいらない」という状態が長く続きます。実際僕がニーリーに入社してから、共通基盤のニーズが本格化するまでには4年半かかりました。

この「まだいらない」と「すでにある」の狭間に飛び込むことが、共通基盤開発の面白いフェーズに立ち会うために必要なアクションであり、慎重に判断しないといけないのですが・・・

今ニーリーにはその環境があることを約束します!ぜひ今来てください!

ということでJob Descriptionを貼って締めたいと思います。ご応募お待ちしています!

herp.careers

まずはラフに話を聞いてみたい方は僕のXのDMでもOKですし、共通基盤開発チームのリードの松村や、CTOの三宅とのカジュアル面談もウェルカムです!

nealle.notion.site

TSKaigi 2026にGoldスポンサーとして協賛いたします & セッションの登壇もあります!

ニーリー VPoEの菊地( @_tinoji ) です。 ニーリーは、2026年5月22日(金)〜23日(土)の2日間にわたって開催される「TSKaigi 2026」に Gold スポンサーとして協賛いたします。

TSKaigi 2026 の概要

日程: 2026年5月22日(金)〜23日(土)
会場: ベルサール羽田空港 ↓↓公式サイトはこちら↓↓ 2026.tskaigi.org

3/23の18時からチケット販売されておりますので、ぜひお早めにチケットをゲットしましょう!

協賛の背景

note.nealle.com

↑のnoteにあるとおり、ニーリーでは今まさにマルチプロダクトの波が来ています。 当然、これを実現するために使っていく技術にも大いにこだわっているのですが、フロントエンドを中心に様々な用途で採用している言語がTypeScriptです。

また、プロダクト開発だけではなく、サクセスエンジニアというポジションでも社内のツール作成や業務効率化などにフルスタックに活用されています。
サクセスエンジニアは非常に面白いポジションですし、TypeScriptをフル活用できるので、ぜひJob Description入社エントリを見てみてください!(宣伝)

TypeScriptは、型安全性やコードの可読性を向上させることで、開発者がより効率的に作業できるようにするための強力なツールです。 私たちはいかにTypeScriptという言語特性を活かしつつ、高速に開発サイクルを回し続けるかを常日頃から議論しながら開発に取り組んでいます。

日々お世話になっているTypeScriptに対してなにか貢献したい!仲間と共にコミュニティを盛り上げたい!という社内からの声により、今回の協賛を決定いたしました。

セッションの登壇について

また、テックリードの立川が提出したプロポーザルが採択され、「TypeScriptとAngular Signal で実現する保守性の高いアプリケーション設計 - 3層アーキテクチャによる責務分離の実践」というタイトルでの発表させていただきます。

tskaigi.hatenablog.com

(社内ではTSKaigiへの注目度が高く、プロポーザルを出したいメンバーで集まって「プロポーザル書き終わるまで帰れま10」なんかも開催されていましたw)

その時の様子

ニーリーのブース出展について

というわけで会社全体として非常に気合いが入っています! 現在ノベルティなどの準備を進めており、皆さんに楽しんでいただけるようなブースを作っていきたいと思っています。

セッションの合間や休憩時間に、ぜひニーリーのブースへ遊びに来てください。 事業の話、プロダクトの話、TypeScriptの話など(もちろんそれ以外も大歓迎)ざっくばらんにお話ししましょう!

Product Management Summit 2026 にExhibitionスポンサーとして協賛いたします

ニーリー VPoEの菊地(@_tinoji) です。 ニーリーは、2026年4月28日(火)に開催される「Product Management Summit 2026」に Exhibition スポンサーとして協賛いたします。

Product Management Summit 2026 の概要

「Product Management Summit」は、プロダクト・組織・ビジネスをどのように進化させていくのか、各社の実践と試行を共有しながら次の一歩を考えるカンファレンスです。 今回は「プロダクトマネジメントの進化」をテーマに、職能の境界を越えてPdM・デザイナー・エンジニアが交わる場となる予定です。 詳しくは公式ホームページで!

product-management-summit.findy-tools.io

協賛の背景

ニーリーは、2019年にローンチした月極駐車場オンライン契約サービス「Park Direct」をメインプロダクトとして事業を伸ばして来ましたが、2021年には法人向けサービスとして「Park Direct for Business」を、そして昨年2025年には1日単位で駐車場予約ができるサービス「ワンデイパーク」の提供を開始し、今まさにマルチプロダクトの波が来ています。

単にプロダクトが複数あるだけではなく、

  • Park Direct: 10→100
  • Park Direct for Business: 1→10
  • ワンデイパーク: 0→1

というフェーズの異なる事業が混在し、大きなシナジーを伴いながら全ての事業が高速に伸びている状況、つまりプロダクトマネジメントの重要度が極めて高い事業フェーズに差し掛かっています。

第1の矢 = Park Direct、第2の矢 = Park Direct for Business、第3の矢 = ワンデイパーク

ニーリーではプロダクトエンジニアが一般的にはPdMが担当するようなDiscoveryやPlanning領域にも染み出すカルチャーが非常に強いですが、だからこそPdMはあらゆる事業成長のレバーを引ける環境にあると思います。

ニーリーが提供するプロダクトはシステム単独で価値を生み出しているのではなく、システム+オペレーションが一体となってユーザーに価値を届けているというのが大きな特徴です。よってニーリーのPdMは、ユーザーが求めるプロダクト開発で伸ばすのか、業務プロセスにdeep diveしてオペレーションで伸ばすのか、はたまたマーケティングでアプローチして伸ばすのか、あらゆる選択肢を持っています。

そのような裁量の大きなPdMが、「AI」という新たな武器を持ち今後どのように顧客価値を生み続けていくのかを考える中で、Product Management Summit 2026のテーマに共感し、今回協賛をさせていただくことになりました。

↓ニーリーのPdMのことが分かる参考記事 nealle-dev.hatenablog.com

note.nealle.com

ニーリーのブース出展について

当日は Exhibition スポンサー としてブースを出展します! 今回のブースでは、事業と開発がどのように連携してPark Directをはじめとしたマルチプロダクトを進化させていくのか、CTOやPdMが直接お話しさせていただきます。

今回は新しいノベルティや、ニーリーのカルチャーを感じていただける展示をご用意して皆様をお待ちしております。 スタンプラリーも開催されるので、ぜひお気軽にお越しください。

セッションの合間や休憩時間に、ぜひニーリーのブースへ遊びに来てください。 事業の話、プロダクトの話、組織の話までざっくばらんにお話ししましょう!

CTO三宅は当日の懇親会にも参加予定ですので、会場で多くの皆様とお会いできることを楽しみにしています!!

次世代モビリティインフラへの小さくて大きな一歩を踏み出す〜月極駐車場と1日貸しをつなぐワンデイパークが目指す世界〜

こんにちは、株式会社ニーリーでエンジニアリードをしている鈴木正太郎です。 和菓子では上用饅頭が好きです。

先日公開した入社エントリでは、10年働いた会社を離れてニーリーにジョインした理由を書きましたが、今回は、#ニーリー開発組織の野望シリーズとして、私がエンジニアリードを務めるワンデイパークというプロダクトについて、その魅力と可能性、そして開発の舞台裏を書いてみます。

ワンデイパークとは

ワンデイパークは、Park Directに登録されている月極駐車場を、1日単位で貸し出せるサービスです。1日貸しの設定がされた駐車場は、専用のWebサイトから、事前に予約・支払いをすることで、当日は予約した区画に車を停めることができます。

prtimes.jp

ワンデイパークのビジネスモデル

ワンデイパークは約3ヶ月という期間でリリースを行いました。今もなお非常に速いスピード感で開発が進んでいます。2026年2月現在は導入社数が100社を超え、すでに毎日どこかの駐車場がワンデイパークで予約されている状態です。

Park Directという月極駐車場のサービスを軸に展開してきたニーリーには、すでにPark Direct for Businessという2つ目のプロダクトもありました。しかし、ワンデイパークのリリースによって、いよいよ本格的にマルチプロダクトの会社としての歩みを始めます。

ワンデイパークの強みと特徴

ワンデイパークの強みは大きく3つあります。

  1. No.1のPark Directが抱える駐車場にアプローチができる
  2. 月極の空き状況とシームレスにつながる
  3. 単なるクロスセルにとどまらないシナジー

1. 業界No.1の駐車場すべてにアプローチができる

Park Directは、業界No.1*1の月極駐車場のオンライン契約サービスです。ワンデイパークはこの駐車場をベースに展開できます。1日貸しの駐車場予約サービスにおいて駐車場のシェアは競争力に直結するため、これは非常に大きなアドバンテージです。

また、すでにPark Directをご利用いただき信頼を築けている管理会社様へのアプローチとなるため、導入も非常にスムーズです。データ登録も、既存の駐車場情報に対して「1日貸し」の設定を有効にするだけで完了します。この導入障壁の低さが、圧倒的な立ち上がりの速さにつながっています。

2. 月極の空き状況とシームレスにつながる

ワンデイパークのもう一つの強みは、月極駐車場の空き状況や手続き状況とシームレスに連携できることです。例えば、以下のような運用が可能になります。

  • 月極駐車場の空き区画を1日貸ししながら、月極の申し込みが入ったら1日貸しの貸し出しを自動で停止する
  • 月極契約が解約されたら、自動で1日貸しの貸し出しを始める
  • マンションの駐車場で、月極は入居者のみに限定しつつ、1日貸しだけは広く貸し出しする

ダブルブッキングを防ぎながら、駐車場の収益機会を最大化する運用が実現できるのです。

これは、Park Directという月極駐車場の管理システムを持っているからこそできることです。月極と1日貸しが別々のシステムだと、こうした連携を手動で行う必要があり、手間がかかる上にダブルブッキングのリスクもあります。実際、ワンデイパークの導入を決めていただいた不動産管理会社様の多くが、まさにそこを課題に感じていました。

3. 単なるクロスセルにとどまらないシナジー

ワンデイパークとPark Directの関係性は、単純なクロスセルにとどまりません。これこそ私がワンデイパークが今後「モビリティインフラ」を牽引すると確信している理由なので詳しく語りたいところなのですが、極めてシンプルにまとめると、

Park Directの市場拡大が、そのままワンデイパークの成長に繋がる。そしてワンデイパークが1日貸しのニーズに応えることにより、Park Directの営業力を強化する。

という理想的な好循環が生まれています。ワンデイパークは単なる1つの新規事業ではなく、事業間の強力なシナジーを生み出すための新たな柱なのです。

ワンデイパークのワクワクの裏にある難しさ

新規プロダクトの立ち上げは、ワクワクする一方で多くの困難も伴います。 事業は急激に成長していますが、急成長ゆえの課題も山積しています。 リリースからまだ日は浅いですが、すでに技術的な課題と日々闘っています。

月極駐車場とのシームレスな連携の難しさ

ワンデイパークの事業面での大きな強みである「月極駐車場とのシームレスな連携」は、技術的な面では大きな挑戦でもあります。

Park Directは多機能ゆえに仕様が複雑化しており、駐車場区画の状態一つとっても様々なレイヤーでステータスが管理されています。 そこに1日貸しによる区画の状態が追加されるので、ワンデイパーク・Park Directどちらからでも、整合性を保ちながら貸出可否を判断する必要があります。

特に頭を悩ませているのが、既存のデータモデルと現実の運用のギャップです。 例えば、「月極としては募集停止中(データ上は『満車』)だが、実際には空いているため1日貸ししたい」といった現場のニーズへの対応です。これに応えるため、現在は運用での回避や、本来は行わない設定で対応しているケースがあります。 このような「現実とデータの乖離」をシステムで正しく吸収するために、現在はアーキテクチャチームと連携し、根本的なデータモデルの再設計を含めて様々な対応に取り組んでいます。

事業の変化による負債との付き合い方

新規プロダクトを立ち上げる際、既存システムとどう向き合うかは重要な判断ポイントです。

ワンデイパークでは当初、「将来的にPark Directからシステムを切り離せるようにしたい」一方で、「最速でリリースしなければならない」という相反する要件がありました。 そこで、バックエンドのコードベースは共有しつつDjangoアプリケーションだけを分割し、駐車場データをレプリケーション(複製)して参照する設計を採用しました。「月極と1日貸しは独立していたほうがサービスとして扱いやすいだろう」という仮説があったからです。

しかし、ビジネス検証が進むにつれ、この仮説は覆りました。むしろ「月極と1日貸しのデータを密に連携させること」こそが競争優位性になると判明し、切り離しを前提とした設計は、逆にプロダクトの負債になってしまったのです。

そこで正式リリースの2ヶ月後には方針を転換し、レプリケーションを廃止してデータを共有する構成に変更する判断をしました。すでに変更は完了していますが、負債を早めに解消したことによって、機能追加するに当たっての考慮事項が減っていることを実感しています。

速く走るために作った仕組みでも、状況が変われば潔く捨てる。ビジネスの解像度が上がったタイミングを見逃さず、開発スピードを落とさないように負債を解消していく。このバランスを大切にしています。

短期リリースの舞台裏

冒頭で述べた通り、ワンデイパークは約3ヶ月というスピードでリリースを行いました。このAI時代におけるMVP開発としては十分な期間に感じるかもしれませんが、Park Directとの連携の作り込みの程度から考えると、かなり短納期でのリリースでした。スタートアップにおいて「市場に問いを投げるスピード」は命なので、早くリリースするために工夫を凝らしました。

決断したトレードオフ

リリースに向けて、多くの「今はやらないこと」を決めました。

例えば、直前で発覚したデータモデルの不備による仕様のねじれを、影響度合いとその範囲を慎重に見極めた上で「積み残し」として許容しました。また、お問い合わせフォームの実装も見送り、PoCと同様に電話対応のみでスタートするという判断も下しました。

もちろん、こうした判断は開発チーム内部で完結する話ではありません。 リスクとメリットを提示し、社内のワンデイパークチームの方々と密に連携して合意形成を行いました。 リリース前にはCEO、CTO、ビジネスチームの執行役員を含む多くのメンバーにプロダクトを触ってもらい、直前までフィードバックをもらいながら、プロジェクトメンバー全員で盛り上がりながらリリースを迎えることができました。

なお、上記で挙げた積み残し部分は、リリース後に順次解消しています。 このスピード感あるリリースがあったからこそ、早期に営業活動を開始でき、ビジネスチャンスを最大化できたと確信しています。

リリース後の最大の山場

ファーストリリース自体は完遂しましたが、実はその裏には非常に大きな「今はやらないこと」がありました。 それは、管理画面の機能をすべて落とすことです。開発工数を削減するため、リリース当初は管理画面を作らず、BaseMachinaというツールを用いた機能外運用でカバーすることにしていたのです。

リリース後、管理画面の機能を実装する段階になったときは、画面イメージこそありましたが、細部の仕様は詰め切れておらず、根本的な部分で既存の実装とコンフリクトする箇所もいくつかありました。そのため、改めて機能要求の整理から始める必要があったのです。

すでに強力な営業メンバーの活躍により受注は順調に増えていました。しかし、不動産管理会社様に安心して導入を決めていただき、更に事業を伸ばしていくためには、やはり管理画面の存在が不可欠です。一方で、「月極駐車場とのシームレスな連携の難しさ」に記載した通り、様々な状態を考慮した「ちゃんとした」管理画面をリリースするには、どうしても長い時間がかかってしまいます。

そこで最終的には、管理画面だけですべてを完結させることにこだわらず、BaseMachinaとの並行運用を一時的に行う判断をしました。その上で、データの不整合を即座に検知できるアラート機構を整備する。このように安全性を担保しながら段階的に移行することで、この最大の山場を乗り切りました。

[野望]これからのワンデイパーク - 次世代モビリティインフラへ

ワンデイパークの目指す世界は、単なる「月極駐車場の空車を有効活用するサービス」以上のものです。

ゆくゆくは駐車場という土地の管理をニーリーにすべてお任せいただき、その中で1日貸しや月極など柔軟な駐車場の貸し出し方・利用の仕方を可能にすることで、モビリティインフラとして社会に様々な価値を提供できるようになります。

例えば、駐車場を起点としたカーシェアリング、駐車場での充電サービス、駐車場を活用したラストワンマイル問題の解消、関連サービス提供による月極駐車場の賃料負担の軽減など。駐車場という物理的な拠点を抑えているからこそ、リアルとデジタルをつなぐ様々なサービスが展開できます。

このような、必要とされている価値を届けられるサービスをどんどん世に送り出していきます!

エンジニアとして、ワンデイパークを作る面白さ

記事が長くなってしまったので、今まで書いた内容をエンジニアとして「今」ワンデイパークを作っていく面白さという観点で整理します。

事業の伸びをダイレクトに感じられる

新規プロダクトの立ち上げフェーズだからこそ、事業の立ち上がりをダイレクトに感じられます。事業のトップラインを伸ばすために「何を作らないか」を決める裁量をエンジニアが持ち、ワンデイパークに関わるメンバーと議論しながら仮説検証を回せる機会はかけがえのないものだと思います。

単なる「技術的な正解」よりも「今、事業が勝つための最適解」を自ら主導して定義し、実行できるのが今のフェーズの醍醐味です。これによって、受注や利用数がダイナミックに変化する。これを体感できるのは今のフェーズだからこそだと感じています。

toBとtoCの両面を経験できる

ワンデイパークもPark Direct同様に、管理会社様向け(toB)と駐車場利用ユーザー向け(toC)の両面があります。 例えばB側の管理画面に加えた一行のロジックが、C側のユーザーの利便性をダイレクトに向上させることにつながります。

「管理会社が空きを登録しやすくなる(B)」→「街中の予約可能枠が増える(C)」→「ユーザーがより便利に移動できる」→「管理会社の収益が増える(B)」

この一連の流れを俯瞰し、「システム全体の整合性」を保ちながらプロダクトを成長させていく経験は、toBもしくはtoC単一の領域だけでは決して得られない、プロダクトエンジニアとしての大きな武器になります。

このようにtoBの複雑な業務要件と向き合いながら、toCのユーザー体験も設計する。 それ故に、事業を伸ばすポイントもたくさんあるし、やるべきことも多岐にわたります。この幅広さが開発としての醍醐味です。

複雑な問題を解決できる

月極駐車場とのシームレスな連携、急激な成長に耐えうる設計、コストと体験の両立。ワンデイパークには、複雑な問題が山積しています。 Park Directという巨大な既存システムの制約と向き合いながら、いかにシンプルで拡張性の高い新システムを構築するか。 リアルな駐車場というアセットを、いかにソフトウェアで柔軟に、かつ堅牢に制御するか。この複雑な問題を解くことこそが、エンジニアとしての腕の見せ所です。事業に直結する複雑な問題を解決して、ビジネスの成長を自分たちが牽引するのはとてもワクワクします。

事業の拡大フェーズを「最初から」経験できる

ワンデイパークはまだ始まったばかりです。1日貸しから始まり、将来的にはカーシェアや充電サービス、月極では賄えない一時貸しなど、駐車場を起点とした様々なサービスへと広がっていく可能性があります。 この拡大フェーズを「プロダクトが安定してからの途中参加」ではなく「最初から」経験できるのは、今このタイミングだからこそ。短期的な課題解決だけでなく、中長期を見据えた設計や意思決定に関われることは、エンジニアとしての大きな成長の機会だと感じています。

一緒に働く仲間を募集しています!

ワンデイパークは、まだまだ始まったばかりです。 これからもっともっと機能を充実させ、事業を成長させ、これからリリースしていくプロダクトと共に次世代モビリティインフラへと進化させていく必要があります。

そのためには、一緒に挑戦する仲間が必要です。

  • 複雑な問題を解決することにワクワクする方
  • 事業の立ち上がりをダイレクトに感じながら働きたい方
  • toBとtoCの両面を経験したい方
  • 長期的な視点で、プロダクトと事業を成長させたい方
  • チームで一体となって、困難を乗り越えることを楽しめる方

そんな方と一緒に働けることを、心から楽しみにしています。

駐車場という一見地味に見える領域ですが、その先には大きな可能性が広がっています。次世代モビリティインフラを、一緒に作っていきませんか?

ご興味のある方はぜひカジュアル面談からお気軽にお話ししましょう。一緒にワクワクする未来を作れることを楽しみにしています。

nealle.notion.site

*1:「月極駐車場のオンライン契約サービス」の「導入社数」(サービス導入をしている不動産管理会社数)と「オンライン契約可能台数」、「オンライン契約者数」について、2025年11~12月の株式会社未来トレンド研究機構によるサービス提供事業者に対するヒアリング調査およびデスクリサーチ。

数GBのLLM用モデルを、LambdaでLinuxシステムコールを駆使して本番水準で動かす

はじめに

お疲れ様です。2357giです。先日のre:Inventで参加したセッション「Build high-performance inference APIs with Lambda SnapStart」にて、「数GB級のLocal LLMをサーバレスで、本番環境の要求水準で動かす」方法を学んできました。
(その際のセッション形式が「チョークトーク」というもので、めちゃめちゃ良い体験だったのですがその話はこちら )

llama.cppなどの比較的軽量なLLM(1GB~5GB)や、それらと同程度のサイズの自作モデルをLambdaを用いて動かすというものです。
bedrockにカスタムモデルインポートがある現在、本アーキテクチャに優位性があるケースは多くないと思います。セッション中でも「YOLOなどの画像認識や、10 GBに収まる言語モデル、文字起こしなどのモデル組織に合わせてカスタム化されたモデルで、且つ高スループットと低レイテンシーを必要とするケースに適している」と語られていました。
が、Lambdaのパッケージサイズ制限に収まらないモデルを動かす方法や、そのLambdaを本番環境レベルのレイテンシ(1~2s)で動かす方法など技術的面白ポイントが多かったので、そういった点を中心にレポートしていきたいと思います。

正月休みの自由研究として、公式のサンプル実装を先に見ずにまず実際に手元で実装し検証してきたので、そこで得た躓きポイントも含めてレポートしていきたいと思います💪
AWSによるサンプル実装はこちら
AWSによる関連ブログはこちら (車輪の再発明にはなりますが、長期休みの自由研究なので😎 )

セッションの中で、数GB級のLocal LLMをサーバレスかつ本番環境の要求水準で動かすにあたって、大きく以下3つのポイントとして語られていました。

  • 数GBのモデルと、Lambdaパッケージサイズ制限
  • コールドスタートの問題
  • LLMに求められるストリーミングの実現

それぞれ解説していきます🙌

(*情けない前置きと保険になってしまいますが、本記事内で出てくる「セッションの内容を元にした情報や説明」は筆者の乏しい英語力と、LLMによる文字起こしを根拠にしているので、誤情報が含まれる可能性があります。ご容赦ください 🙇️)

数GBのモデルと、Lambdaパッケージサイズ制限

Lambdaのパッケージサイズには厳しいサイズ制限が存在します。zip Lambdaの場合は250MB、 OCI(Open Container Initiative)の場合は10GBです。数GBのモデルを動かそうとする場合、zip Lambdaではまず不可能です。しかし、無邪気にOCI Lambdaを使用して数GBのモデルをLambdaに乗せようとするとコールドスタートが長くなる可能性があります。10秒以上のコールドスタート時間が発生するケースもあります。
この問題について、re:inventのセッションでは、「モデルをS3に配置し、実行時にLambdaの実行環境にロードする」というアプローチが紹介されていました。
ただ、シンプルにS3からロードしようとすると、Lambdaの /tmp ディレクトリが512MBに制限されているという、また別の壁が立ちはだかります。

通常、Lambdaの /tmp (エフェメラルストレージ)は最大10GBまで拡張することができますが、本番環境で求められる水準で動かすとなると、コールドスタートによる遅延に対処するために後述するSnapStartを有効化する必要があります。
しかし、SnapStartは512MBを超えるエフェメラルストレージに対応していない為、この制限が出てきます。

この/tmp制限を回避するために、S3 SDKのPython Boto Streamを使用して、メモリに直接ストリーミングする方法があります。
しかし、llama.cppなどlocal llmで推論を用いるためにはファイルディスクリプタ、つまりファイルパス必要になります
これを解決するために、Linuxのシステムコールであるmemfd_createを利用して、インメモリファイルを作成し、次にS3ファイルをダウンロード、そのmemfdへ直接書き込みを行います。
非常に面白いハックで、S3からダウンロードしたモデルデータをディスク(/tmp)を介さず、直接メモリ上に「仮想ファイル」として作成する仕組みです。
これにより、ディスクI/Oのオーバーヘッドをゼロにし、/tmpをバイパスしてファイルを読み込むことで容量制限を完全に回避できます。

memfd_createでインメモリファイルの作成

    libc = ctypes.CDLL("libc.so.6", use_errno=True)
    MFD_CLOEXEC = 1  # Close the fd when executing a new program
    
    memfd_create = libc.memfd_create  # インメモリファイルの作成
    memfd_create.argtypes = [ctypes.c_char_p, ctypes.c_uint]
    memfd_create.restype = ctypes.c_int
    
    fd = memfd_create(b"model", MFD_CLOEXEC)

サンプル実装リンク

S3 マルチパートダウンロードを用いてmemfdへ書き込み

    # Create memory file
    fd = create_memfd()
    
    # Pre-allocate the full file size
    try:
        os.ftruncate(fd, file_size)
    except OSError as e:
        logger.error(f"Failed to allocate {file_size/1024/1024:.2f}MB in memory: {e}")
        cleanup_fd(fd)
        raise RuntimeError(f"Not enough memory to load model of size {file_size/1024/1024:.2f}MB")
    
    # Calculate parts for parallel download
    parts = []
    for start in range(0, file_size, chunk_size):
        end = min(start + chunk_size - 1, file_size - 1)
        parts.append({'start': start, 'end': end})
    
    logger.info(f"Downloading {file_size/1024/1024:.2f}MB in {len(parts)} parts")
    
    # Download parts concurrently using ThreadPoolExecutor
    download_func = partial(download_part, s3, bucket, key, fd)
    with ThreadPoolExecutor(max_workers=multiprocessing.cpu_count()) as executor:
        executor.map(download_func, parts)
    
    # Create a path that can be used to access the file
    fd_path = f"/proc/self/fd/{fd}"
    return fd, fd_path

サンプル実装リンク

LambdaからLinuxのシステムコールを呼び出すという概念が無かったので流石に痺れました。

実際にこの手法を試し、ファイルサイズが4.5GBもあるllama-2-7b-chatモデルをLambda上でロードすることに成功しました。

コールドスタートの問題

memfd_createでモデルのロードは成功したものの、そのまま呼び出すとコールドスタートの所要時間が絶望的に長い状態でした。
サンプル実装よりも使用しているモデルサイズが大きいこともありますが、以下のような計測値になっていました😇

フェーズ 所要時間
S3ダウンロード(4.5GB) 62-63秒
推論など 20-25秒
合計 84-87秒

そこで、セッション中で紹介されていた解決策である「Lambda SnapStart」を導入しました。 これは、関数の初期化フェーズ(今回のケースではモデルのS3ダウンロードとメモリへのロード)を完了した状態をスナップショットとして保存し、次回以降はそのスナップショットから高速に復元する仕組みです。
スナップショット時の処理はモジュールレベルで、ハンドラーの外側に記述しておくことで、Lambda関数のデプロイ時(厳密にはalias発行時)に行われます。

SnapStartの適用により、S3ダウンロードの時間をまるまる削減することに成功しました。

フェーズ 所要時間
スナップショット復元時間 4.1-4.4秒
推論時間 17.1-17.2秒
合計 21-22秒

間話: 推論の高速化

推論時間に20秒もかかるのはとても辛いのでパラメータチューニングを行い、8秒ほどに短縮しました。
これはモデル固有のチューニングであるので詳細は省きますが、割り当てられたCPUリソースを使い切るthreads数を指定していなかったというオチでした😇

LLMに求められるストリーミングの実現

次なる目標は、LLMチャットなどに不可欠な「レスポンスのストリーミング」の実現です。 re:Inventセッションでは「Lambda Web Adapter + FastAPI」というアーキテクチャが紹介されていました。これはLambda内でWebサーバーを動かし、Lambda Function URLs経由でストリーミングを実現するものです。 Lambda内でLLMの回答生成が完了するまでバッファリングすることなく、逐次回答していくことにより、結果として最初の1トークン目がクライアントに届くまでの時間(TTFT[^Time To First Tokenの略])を、Warm Start時には 1~3秒 ほどまで短縮することに実現しました🎉

フェーズ 所要時間
ColdStart時のスナップショット復元時間 4.1-4.6秒
TTFT 1.1-3.8秒
合計 1.1-8.4秒

この辺り、筆者は5GB近いサイズのモデルを利用しているためこの時間ですが、モデルの選択やスペックによってはもっと早くいけると思います。実際にサンプル実装では1GBほどのモデルにより1~2秒でのレスポンス速度を実現してるとのことです。

ハマりポイントとして、Lambda Web Adapte(LWA)を有効化したところ、SnapStartのためのINIT処理が失敗するようになりました。具体的にはモデルのロード中に失敗してしまう状態です。 原因はLWAがモデルロードの完了を待たずに初期化処理を完了していた点でした。 LWAは同期/非同期2種類の初期化モードを持ちます。非同期モードの場合、LWA自身のReadiness Check(/health等への応答確認)が成功した時点で、Lambdaサービスに対して「INITフェーズ完了」を報告してしまいます。
AWS_LWA_ASYNC_INIT='false'(同期初期化モード)を使用することにより、モデルのロードを待ってINITフェーズの完了とすることになります。この辺りは自前実装をしないと理解に繋がらないポイントだと思うので、良い学びでした。

まとめ

今回はLocal LLMをLambdaで実行するという少し珍しいケースでしたが、この検証を通じて得られた知見は、他の多くのケースでも応用できる汎用的なものばかりでした。

  • memfd_createは、LLMに限らず、機械学習のモデルファイルや遅延呼び出し可能なライブラリなど、GB級のファイルをLambdaで扱う際の強力なテクニックになりそう
  • SnapStartは、モデルのロードだけでなく、DBコネクションの確立や重いライブラリの初期化など、初期化処理が重いあらゆるLambda関数で有効なコールドスタート対策
  • Lambda Web Adapterは、PythonランタイムのLambdaでFastAPIなどの標準的なWebアプリケーションフレームワークを動かすための非常に強力なツールであり、ストリーミング以外にも様々なユースケースが考えられる

ちなみに余談ですが、本セッションの登壇者はLWAの開発者でもありました。
「Pythonランタイムは、今のところ応答ストリーミングを公式にはサポートしていません。幸いなことに、私が作成したLambda Web Adapterというツールがあります。」はウケました(会場もウケてた)。
いやー本当に良い経験をしました。チョークトークに参加して良かったとしみじみ思います。

それではみなさん、良きサーバーレスライフを👋

業務を無くすため、Opsファースト開発という選択肢

この記事は、ニーリーアドベントカレンダー2025 の25日目の記事です。

ニーリーCTOの三宅です。今年もトリを担当します。 去年はDXCriteriaで一年を振り返りました。 今年も振り返りを書くつもりでしたが、振り返ってみると、一番伝えたいのは別でした。

採用で最も苦戦したプロダクトマネージャーの面白さです。

この記事では、ニーリーのプロダクトマネージャーの役割と面白さを1つ紹介します。 テーマは、「業務を無くす」プロダクトマネジメントです。


ニーリーのプロダクトマネージャーとは

ニーリーのプロダクトマネージャー(以下、PdM)は、ミッションを「顧客とマーケットに向き合い、価値提供を創造し続けること」としています。 役割は「特定領域のPLや事業KPIに、裁量と責任を持つこと」と定義しています。 いわゆるmini CEOに近い役割です。

そして、ニーリーのPdMの特徴は、「価値を作るレバーはプロダクトだけじゃない」 という点に尽きます。

ニーリーには「プロダクトエンジニア」という役割があります。

プロダクトエンジニアは事業に染み出します。その結果、PRDを書くようなPdM業務の一部を、プロダクトエンジニアが担う場面があります。開発スケジュールの管理も、プロダクトエンジニア側で対応します。だからこそニーリーのPdMは、さらに事業へ染み出すことを推奨しています。

note.nealle.com

さらに「事業へ染み出す」とは何か。 それは、「プロダクト × マーケ × オペレーション」、あらゆる手段を使って価値を作ることです。手段を限定せず、使えるものを全部使います。

ニーリーはいま、3つの事業を展開しています。 どの事業でも、価値はプロダクトだけで作っていません。「プロダクト × マーケ × オペレーション」を組み合わせて作っています。

そのため、ニーリーのPdMはレバーを幅広く持つ必要があります。 それもただ、持つだけではなく、使いこなすことが求められます。

そしてこの記事では、「プロダクト × オペレーション」にフォーカスしてお話しします。


機能がないなら、まず自分たちで業務を引き受けるという選択肢

SaaSプロダクトを開発していると、機能要望への対応は避けて通れません。個社カスタマイズの要求。ロードマップにはあるが「今ほしい」という声。対応すべきか、優先順位を変えるべきか、迷う場面は少なくありません。 ニーリーでは、機能がないとき、開発ロードマップの見直しはもちろん検討します。ただ、それに加えて「機能がないなら、まず自分たちで業務を引き受ける」という選択肢を持っています。 プロダクトで解決できないなら、Ops(オペレーション)でカバーする。業務を回しながら、プロダクト化の道筋を探る。私たちはこれを「Opsファースト開発」と呼んでいます。(今、命名しました笑)このアプローチがVertical SaaSで急成長してこれた秘訣の1つだと思っています。


なぜOpsファースト開発を選択するのか

「プロダクトがないのに業務を引き受ける」と聞くと、非効率に見えるかもしれません。 人手がかかる。スケールしない。その通りです。 それでも私たちがOpsファーストを選ぶ理由は、3つあります。

1. 顧客への価値提供を最速最大にできる

SaaSを導入しても、システムを操作する業務は残るため、顧客の業務は楽になれどゼロになることは少ないです。また、データ移行、運用フローの変更、社内への説明など、SaaSを導入するまでにも時間がかかります。 業務がゼロか、少しでも残るか。この差は大きいと考えています。私たちが業務を引き受ければ、顧客は「導入した瞬間から業務がなくなる」状態に近づきます。 私たちは、顧客の業務を最速でゼロにすることを目指しています!

2. 変更をコントローラブルにできる

一度導入されたシステムを変えるのは大変です。 「このフローを変えてください」と頼んでも、顧客側にも事情があります。 結果として、よい機能を作ってもリリースしづらくなります。 現場にとって、業務変更は負担です。通常業務を回しながら、新しいやり方に切り替える必要があります。そのため「今の業務に合わせてほしい」というカスタマイズ要望が増えがちです。 ここにジレンマが生まれます。 一方で、業務を私たちが引き受けていると話が変わります。 やるべきことさえ満たせば、業務フローは自由に変えられます。新機能のリリースも社内で完結します。フォローもしやすく、出しやすくなります。 つまり、価値提供のスピードを上げるためには、「”システム”や”業務”を変えられる側に立つ」ことが重要になります。

3. いいプロダクトを早く作れる

プロダクト開発で一番むずかしいのは、業務解像度を上げることです。 ヒアリングだけでは限界があります。顧客の言葉と、実際の業務にはズレが出ます。 そのズレを埋める最短ルートは、自分達で業務をやることです。 Opsを引き受けると、業務解像度が一気に上がります。 社内に実務者がいるので、いつでも聞けます。自分でも体験できます。 リリースの刻み方も変わります。 外部の顧客向けは、ある程度作り込まないと出せません。 一方、社内ユーザー向けなら相談できます。 「このエッジケースは一旦外してOpsで耐える」、「70点の完成度でも先にリリースして価値検証する」など、小さく出して、早く学べます。


「受ける・受けない」の判断軸

「Opsで受ける」といっても、何でも受けていいわけではありません。 やったことがない業務を正確に見積もるのは難しいです。 しかも、始めるのは簡単です。また、どうしても目先の目標や要望に引っぱられやすくなります。 しかし、判断を誤ると、業務量が膨れ負債となり、 最悪予算を逼迫してプロダクト開発が減衰します。 だから私たちは、受ける・受けないの判断の時に、アウトカム効率(効果と対応コスト)に加えて、次の2軸で判断します。

軸①:トップラインへの影響度合い

この軸は、受ける・受けないの判断以外にも、「受けたOpsをいつ自動化するか」を決めるときにも使います。 優先順位は、次のとおりです。

  1. トップラインや重要KPIに直結するもの
  2. 業務効率化を通じてトップラインや事業KPIに効くもの
  3. 業務効率化でコストが下がるもの

1は分かりやすいです。ポイントは同じ業務効率化でも2と3を分け、基本は1,2を優先することです。コスト削減も重要です。ただし私たちは、事業成長に効く開発を優先しています。

軸②:将来、自動化しやすいか

トップラインに効くなら何でも受けるかというと違います。すべての業務をずっとOpsで対応するわけにはいきません。だからこそ、将来システムで自動化できる見込みを必ず見ます。

ただし、この判断は事業フェーズで変わります。 たとえばパークダイレクトには、貸与物(機械式駐車場の鍵など)の管理ニーズがあります。現物を扱うので、システム化しづらい業務です。私たちは当初、この要望へは対応していませんでした。

いまはフェーズが進み、Opsの体制も整いました。その結果、オプションサービスとして対応しています。「業務を無くす」という価値提供を優先し、受ける判断に切り替えました。

自動化できないなら受けないではなく、理想とする世界観を目指して、その時の事業や組織状況を踏まえて、バランスをとるのが大事です。


プロダクトだけではなくOps組織をマネジメントする

Opsで受けるなら、業務設計が要ります。 組織の構築だったり、メンバー育成も要ります。日々の業務管理も発生します。 ニーリーの特徴は、Ops管理にPdMが深く関わることです。

現在、お金周りのオペレーションを司るPAYグループとそれ以外のオペレーションを司るOpsグループ、それぞれの責任者をPdMが担当しています。PdMが実務の組織を管轄するのは、珍しい構造かもしれません。 しかし、PdMがOps組織を管轄することで、「受ける/受けない」の意思決定スピードを速められ、さらに、業務で得た学びをプロダクトへフィードバックし、プロダクト開発の速度も上げられています。


出口戦略なきOps受けは沼になる

ここまでOpsファースト開発や、PdMがOps管理に関わるメリットを語ってきました。ただ、いい話ばかりではありません。

出口戦略がないと、Opsから抜け出せません。

事業が伸びるほど、業務は増えます。急成長を狙うほど、増え方も急になります。「増える量」より「減らす量(効率化)」を上回らせることが重要です。 でも、引き受けた業務は止められません。必ず回す必要があります。そのため、PdMがOpsに染み出している場合、時間は「回す」側に寄ります。その結果、プロダクト開発に割ける時間が減り、効率化が遅れ、より詰まります。悪循環です。 このループに入ると、抜け出すのは難しいです。だからこそ、受けるなら最初に出口を用意することが重要です。たとえば、効率化のロードマップを先に引き、追加の開発リソースも確保します。


当事者だから味わえる、速さと手触り感の面白さ

プロダクトマネジメントや開発をやってきた人ほど、Opsは「面倒で楽しくない」と感じるかもしれません。自分もそうでした。エンジニアの道を選んだ理由の1つは、「できるだけ楽したい」だったので、その気持ちはよく分かります。

でも、実際にやってみると印象は変わります。Opsは、想像よりずっと面白いです。

わたしは、前職はITコンサルで、業務効率化の案件を多くやっていました。 仕事自体はやりがいがあり、楽しかったです。ただ、不満もありました。業務を変えるスピードが遅いことと、変わった実感を持ちづらいことです。

金融のように業務の正確性が重要な領域では、業務変更に慎重になるのは当然です。 それでも自分は、もっと速く業務を変えたかった。 また、システム導入で「楽になった」と言われたときは嬉しいですが、当事者ではない自分にとっては手応えが薄い、そんな感覚が残りました。

けど、今は違います。 自分の裁量で決められるので、変えるスピードが速い。遅いなら自分の責任です。 変化もダイレクトに返ってきます。自分次第で、業務変革のダイナミックさを手に入れられる。それが、いちばんの面白さです。


さいごに

ニーリーのPdMの役割と面白さの1つとして、Opsファースト開発を紹介しました。 PdMがOpsへ染み出し、業務を引き受け、業務を無くしていく。そんなプロダクトマネジメントの話です。

「業務効率化」と聞くと地味に見えるかもしれません。 でも実際は、変化の速さと手触り感があります。しかも、インパクトも出ます。だから面白いです。

最近はプロダクトAI開発チームと組み、AIで業務の完全自動化にも挑戦しています。 ビジネスだけでなく、技術的にも面白いフェーズです。

業務効率化の余地は、まだまだあります。 業務を減らし、可処分時間を増やし、社会をよくしていきましょう。 少しでも興味を持っていただけたら、カジュアル面談で話しましょう。

カジュアル面談はこちらから!

nealle.notion.site




以上の内容はhttps://nealle-dev.hatenablog.com/より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます

不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14