はてなブックマーク

はじめに お疲れ様です。2357giです。先日のre:Inventで参加したセッション「Build high-performance inference APIs with Lambda SnapStart」にて、「数GB級のLocal LLMをサーバレスで、本番環境の要求水準で動かす」方法を学んできました。 (その際のセッション形式が「チョークトーク」というもので、めちゃめちゃ良い体験だったのですがその話はこちら ) llama.cppなどの比較的軽量なLLM(1GB~5GB)や、それらと同程度のサイズの自作モデルをLambdaを用いて動かすというものです。 bedrockにカスタムモデルインポートがある現在、本アーキテクチャに優位性があるケースは多くないと思います。セッション中でも「YOLOなどの画像認識や、10 GBに収まる言語モデル、文字起こしなどのモデル組織に合わせてカスタム化さ

この記事は、ニーリーアドベントカレンダー2025 の25日目の記事です。 ニーリーCTOの三宅です。今年もトリを担当します。 去年はDXCriteriaで一年を振り返りました。 今年も振り返りを書くつもりでしたが、振り返ってみると、一番伝えたいのは別でした。 採用で最も苦戦したプロダクトマネージャーの面白さです。 この記事では、ニーリーのプロダクトマネージャーの役割と面白さを1つ紹介します。 テーマは、「業務を無くす」プロダクトマネジメントです。 ニーリーのプロダクトマネージャーとは ニーリーのプロダクトマネージャー（以下、PdM）は、ミッションを「顧客とマーケットに向き合い、価値提供を創造し続けること」としています。 役割は「特定領域のPLや事業KPIに、裁量と責任を持つこと」と定義しています。 いわゆるmini CEOに近い役割です。 そして、ニーリーのPdMの特徴は、「価値を作るレバ

お疲れ様です。@2357gi です。 筆者環境では、Terminal.app で開いた tmux の複数のセッション・ペインで同時並行に Claude Code を動かしてます。 Terminal.app 以外を開いてたり、Terminal.app を開いても裏画面の tmux ウィンドウ/セッションで動いている Claude Code の待機状態に気づかないことが多々あります。 そこで、受付状態になった時にいい感じにMacの通知を出してくれるやつと、その通知から直接待機状態の Claude Code が開かれている tmux ペインを開くやつを作りました。 Claude Code にお願いすればサクッと作れるとは思いますが、後者の 通知から該当の tmux ペインを開くスクリプト の実装で若干はまりどころがあり試行錯誤したので、勘所のまとめとスクリプトそのものを共有します。 （*ただし、

この記事はニーリーアドベントカレンダー2025の24日目の記事です。 こんにちは、菊地(@_tinoji)です。今年のアドカレもクリスマスイブを担当させてもらいます！🎄 1ヶ月前に、ニーリー初となるMeetupイベントを開催し、予定枠を増枠するほど多くの方にお越しいただきました。 nealle.connpass.com 当日の様子(撮影許可はいただいてますが参加者には一応ぼかしを、、) ご来場の皆さんにはかなり楽しんでいただけたとは思う一方、僕の不手際でかなりご迷惑をおかけしてしまったので、会の終わりに「アドカレでポストモーテム書きます！」と宣言しましたw ニーリーで普段使っているポストモーテムのテンプレートを一部流用して、それっぽく書いてみます。完全にネタ枠ですので安心してご笑覧ください！ ※一部、会場の設備について触れていますが、全くもってお店側に瑕疵はありません！完全にこちらの準備

手を広げて気づいた、集中の本質—「捨てない」という選択 こんにちは、株式会社ニーリーの中村です。 昨年アドカレでランニングを宣言したわけですが、見事継続し、今年の区民マラソン完走を果たすことができました！ 最初はほんと足が痛くて辛すぎましたし、大会1ヶ月前にコケて、1週間近く走れない、1週間前に熱が出て直前まで走れない、なんてこともありましたが、ほんとよかったです。 さて気づけば、ニーリーに入社して3年が経ちました（2022年8月入社です）。 この3年間、私はサクセスエンジニアとして様々な経験を積んできましたが、振り返ると「集中する」ことの意味を、少しずつ学んできた3年間だったと思います。 皆さんも、「集中したいけど、色々な仕事が降ってくる」という経験、ありませんか？ この記事では、手を広げた経験があったからこそ気づけた「集中の本質」について書きたいと思います。 はじめに いつものことなが

お疲れ様です！SREの大木 @2357gi です。そろそろ冬なのでスノボのために身体を温めています。 re:Invent 2025 へ参加してきたので、早速レポートをしていきたいと思います！ 今回は弊社とAWSのリセール契約を結んでいる Megazoneさんに招待していただきました。大感謝です🔥 具体的なセッションのレポートや、「準備してよかったもの・いらなかったもの・しておけばよかったものまとめ」などはまた別のテックブログとしてアウトプットする予定です🙌 ざっくり前提：re:Inventとはなんぞや ざっくりre:Inventについて説明しますと、AWSが毎年ラスベガスで開催するクラウドサービス最大規模のカンファレンスです。 基調講演や技術セッション、ワークショップで最新サービス・ベストプラクティスなどが発表され、多くの学びを得ることができます。 また、それ以外にも大規模なExpoや

はじめに この記事はBPaaS/AI+BPO Advent Calendar 2025 22日目の記事です。 サクセスエンジニアとして働いている増田です。 サクセスエンジニアってなんだ？ と興味を持たれた方はぜひこちらの記事を読んでください。 日々の業務では、社内ツールの開発やデータ変換システムの構築、業務設計や自動化などに取り組んでいます。 最近はAIを活用したワークフローの構築にも挑戦していますが、正直なところ、まだ大きな成果が出ているわけではありません。ただ、その過程で「自動化やAIワークフローを機能させるためには、その前段階のデータ整備が重要だ」という実感を強く持つようになりました。 本記事では、私が自動化基盤として導入した「プロダクト外にデータを集約する」というアプローチについて、その背景と考え方、そしてメリット・デメリットを共有します。 業務で起きがちな問題 自動化やAIを業務

こんにちは！ニーリーアドベントカレンダー2025 の22日目を担当する阿部です。 普段はプロダクトマネージャーをしながら、マーケティングの部署も兼務しています。 今回のアドカレでは、技術的な実装の話…ではなく、「社内のデータ基盤が整ったことで、利用者である自分の業務がめちゃくちゃ楽になった！圧倒的感謝...！！」 という、いちユーザーとしての感動と感謝を綴りたいと思います。 結論から言うと、「整備されたデータマート」 と 「AI Analytics」 の組み合わせは、分析業務における「強力な武器」になりました。 半年前まで戦っていた日々 まずは、半年前の状況を振り返ります。 当時もデータ分析自体は行っていたのですが、 「SQLでゴリゴリ集計」 する力技でした。 特に自分たちのチームでは「カスタマー単位」での分析頻度が高いのですが、これを行うためには、以下のような多種多様なテーブルを自分で紐

こんにちは、ニーリーの佐古です。 現在開発速度や開発者体験の向上のため、取り組みの諸々を遂行しています。 ニーリーアドベントカレンダー 19日目の記事です。 トレンドや流れを無視して今回は「よく使うけどなぜかパッと見つかるところで資料化されていない設計パターン」についてのメモです。ご利用の際のタイムゾーンはよきように。 はじめに アプリケーションのあちこちで日付判定が重複したり、バッチ実行時にシステム日付をいじったり、UT追加の度に日付取得処理/判定処理をモックしたり、それが原因でUTがflakyになって煩悶したりしていますか？私は割としています。ということで今回はその対策について。 ステップ1: 業務日時の抽象化 業務に関する日時判断・計算を行う際はオブジェクトを定義して各種判定を楽にしたいものです。 from __future__ import annotations from dat

はじめに 前前回のブログの後編を書かずに野望記事を書いている、アーキテクチャチームの野呂です。 この流れで、アーキテクチャチームの、というよりは僕の野望について語らせていただきたいと思います。 アーキテクチャチームの野望 ニーリーの開発組織のテーマは「価値を最速で実現する」だと思っています。それは、ニーリーのミッションである「社会の解像度を上げる」と、Valuesである「今、“いいもの”を作る」を体現し、T2D3を超えるハイグロースを実現するのに必要だからです。 T2D3を超える、というのは決して夢物語ではなく、今まさに、それを超えるスピードで事業は成長しています。 そのため、僕の野望はそのまま「価値を最速で実現できるアーキテクチャを作り、維持し続けること」です。 野望と呼ぶには地味に聞こえますが実態は非常に難しく、ほとんど「この世界のすべての答えを知る」と同義な、やや現実離れした内容だと

ニーリーアドベントカレンダー 18日目を担当します榎本です。 2025年12月から、株式会社ニーリーに初代DevHR（Developer's Human Resources）として参画することになりました！（ちなみに、やりたいことが山積みのため、私と一緒に組織づくりに挑んでくれる仲間も早速探しています…！） 私自身、これまでプロダクト開発の現場で様々な経験を積んできましたが、この度、新たなロールへチャレンジすることになりました。 なぜ現場を知る私が、このタイミングで「DevHR」という道を選んだのか。その理由と、DevHRとしてニーリーの成長を駆動させるために何を成し遂げようとしているのか、現時点での想いを綴ります。 1. 成長の証：T2D3を目指すペースでの成長と、その先に現れた「組織の壁」 ニーリーが提供するモビリティSaaS『Park Direct』や『Park Direct for

こんにちは！ニーリーアドベントカレンダー2025の17日目はプラットフォーム開発チームの松村からお届けします。 直近、プラットフォーム開発チームでは複数のビジネスプロダクトから利用される会員・決済といった共通基盤機能を提供するプロダクトを開発するためのエコシステム整備を進めています。 そんな中で出会った Redocly CLI が OpenAPI 定義を管理するツールとして素敵そうにみえたので今回はその話をしていきます。 なぜOpenAPI？ OpenAPIの定義管理で欲しかったもの Redocly CLIとは 機能の紹介 バリデーション 定義のマージ その他 おしまい なぜOpenAPI？ これから構築していく共通基盤機能は主にWeb APIの形式で提供していきます。 そんな中、エコシステムの整備において用意したいものの一つに「APIドキュメント・カタログを用意する仕組み」が上がりました

この記事は ニーリーアドベントカレンダー 16日目です。 こんにちは。株式会社ニーリー QAチームの関井（@ysekii_）です。 昨今、QA界隈のテックブログでも「生成AIによる業務効率化」の話題で持ちきりです。 そんな中、ニーリーでも生成AIの活用について地道に試行錯誤を重ね、ようやくこれなら実務で通用するかもしれないというフローを構築しました。 今回は、私たちが生成AIを活用してテスト設計の効率化をどのように実現しようとしているのか、その取り組みをご紹介します。 小規模開発の「仕様書ない問題」とテストの悩み 本来はドキュメントがあるべきですが、リソースの限られる小さな機能変更やバグ修正などの小規模な開発案件では、ドキュメントが十分に整備されていないことは現場でよくある悩みだと思います。 ドキュメントがない中でテスト設計を進めると、QAと開発者の双方に課題がのしかかります。 QAエンジ

ニーリーアドベントカレンダー 15日目を担当する増田(ますた)です。 実は昨日誕生日を迎えました！ お祝いとしてぜひ先週に書いた記事も読んでいただけると嬉しいです！ 今年からClaude Codeを利用するようになって、あまりの便利さにMaxプランから離れられなくなりました。 この記事では個人的に今年作っておいたお陰で助かったなっていうスラッシュコマンドをいくつか紹介します。 スラッシュコマンドとは Claude Codeには、プロジェクト固有のプロンプトをコマンドとして登録できる機能があります。 作成したコマンドはClaude Codeに限らずCursorでも利用することが可能です。 .claude/commands/ ディレクトリにMarkdownファイルを置くと、Claude Code上で /ファイル名 として呼び出せるようになります。 your-project/ ├── .clau

こんにちは！ニーリーで SRE をしています 高 (@nogtk) です。 ニーリーでも LLM を活用した業務や開発効率の改善が日々あちこちで行われているのですが、そんな事例の1つをご紹介できればと思います。 この記事は ニーリーアドベントカレンダー 12日目です 🎉 バッチの定義方法について ニーリーでは、スケジュール実行されるバッチ処理の実行基盤として Step Functions を利用し、Step Functions から ECS タスクを呼び出す形を取っています。 そしてその sfn や ECS タスクは Terraform でコード化（IaC）されており、SRE チームによってそれらの具体を隠蔽する Terraform module を提供しています。 バッチを追加したい開発者は、その Terraform module を利用するように PR を出し、マージすることで各バッ

こんにちは！ ニーリーアドベントカレンダー11日目を担当するPDBiz開発グループの古庄(@k_furusho)です。 私は10月16日にニーリーへ入社し、「PDBiz（Park Direct for Business）」開発グループにジョインしました。 このPDBiz、社内では主力事業であるPark Directに続く「第二の矢」として、強烈な事業成長が期待されているフェーズにあります。 note.nealle.com 今回は、入社から短期間で「法人車両の月極駐車場管理」というドメイン業務の解像度を一気に高め、システム戦略を描くために実践したアプローチについてお話しします。 コードの外側に広がる「複雑性」 まず、PDBizというプロダクトの特性について触れておきます。 私たちは「法人車両の月極駐車場管理」というソリューションを提供していますが、その裏側には、システムと複数のコンテキストが

この記事は ニーリーアドベントカレンダー10日目です。 こんにちは！Analyticsチームの上田です。 データ分析基盤を運用していると、「データの鮮度を上げたい」「転送コストを下げたい」という欲求は尽きないものです。ちょうど私たちもETLの改善に取り組んでいたのですが、そこには思わぬ落とし穴が潜んでいました。。🥲 今年の反省は今年のうちにということで、得た学びを共有したいと思います！🙏 3行まとめ データ転送コスト削減のため転送方式を 全件洗替え転送 → 差分転送 に切り替えたところ、転送漏れが発生 原因は、Django ORMのsave(update_fields=...) 利用時に、更新日時 (updated_datetime) が自動更新されない仕様を見落としていたこと 現在は洗替えに切り戻し、再発防止策としてLinterによるコード検知の仕組みを導入。併せてCDC (変更デー

この記事は ニーリーアドベントカレンダー 9日目です :🎉 お疲れ様です。re:Invent 2025へ参加した大木( @2357gi ) です。 今回はre:Invent 2025で行われている Chalk Talkに参加し、だいぶ衝撃的&お勧めしたいと感じたのでレポと攻略法をまとめます💪 そもそも 今年の目玉が発表されるキーノートから実際に手を動かすワークショップ、グループ対抗でスコアを競うGameDayなど、re:Inventには様々なタイプのセッションが存在します。 その中でも「チョークトーク（Chalk Talk)」という”対話型”のセッションがあるのですが、これはスピーカーがただ講義を行うだけでなく、聴講者が挙手をし、直接質問やディスカッションができるものとなります。 予め用意してあるスライドに加えて、ホワイトボードを用いたライブ感のある説明が行われたりします。 実際にホワ

ニーリーアドベントカレンダー 8日目を担当する増田(ますた)です。 文章力に乏しいため、AIに助けてもらいながらこの記事を書きました。 去年に続きススメシリーズです。 コードレビューで「こうした方がいい」と指摘したのに、意図が伝わらず違う方向に修正されてしまった——皆さんそんな経験はありませんか？ 本記事では、今年私の中でハマっている手法である「AI巻き込み型レビュー」を通じてこの問題を解決するアプローチを紹介します。 コードレビューにおける「伝える難しさ」 コードレビューは単なるコードのチェックではありません。「なぜこう書くべきか」という意図や背景を、レビュイーに正確に伝える必要があります。 しかし、これがなかなか難しいんですよね。 指摘の理由をうまく言語化できず、結果としてレビュイーが意図を曲解し、誤った方向に修正してしまう。そして再レビュー、再修正……。この手戻りは、チーム全体の生産

こんにちは！株式会社ニーリーでコーポレートエンジニア（以下、CE）をしている小島拓也です。この記事は ニーリーアドベントカレンダー2025 の5日目の記事です！ ニーリーは「社会のインフラ」を創るべく、駐車場オンライン契約サービス「Park Direct」を展開し、ありがたいことに事業も組織も急成長しています。 そんな「Park Directを支えている人」を支え、社内のIT基盤を運用保守しているのがコーポレートエンジニアです。 この記事は、そんなコーポレートエンジニアが今年一年で取り組んだ、社内のIT基盤の課題をITIL4の考え方を取り入れ改善のサイクルを回し始めたふりかえりのお話です。 ITIL4導入前の"運用"という名の課題 なぜITIL4だったのか？：「継続的改善」への共感 私たちの「ITIL4×Jira」改善プラクティス 改善がもたらした「チームの変化」 展望：事業成長に先回りす

はじめに どうも、ARCHチームの野呂です。 今日は（前回の記事の後編を書かずに！）近所の美味しいラーメン屋について書かせていただきます。 名古屋市千種区にある「太陽」というチャーシューメン専門店なんですけれども。 世間の流行とはちょっと違うのかもですが、近所の人々から愛されていて、昼過ぎにはいつも完売している感じのラーメン屋です。 別に店主から聞いたわけではないので以下の文章は半分くらい妄想＆ただの感想なんですが、しかし自分の感じている魅力を文章にしてお届けしたいと思っております。 特徴と美味しい食べ方と まず、スープがあっさりしているというところが特徴です。 それ単体で味わうと少し物足りないくらいの、今どき珍しい薄味。 麺をすすってもやっぱり少し薄味すぎるくらいの感じで、でも出汁が効いていて旨みは十分にあります。 何口か食べて、その味に慣れてきた頃にチャーシューを少しだけ食べると、実は

はじめに こんにちは、ARCH チームの立川です。ニーリーアドベントカレンダー2025、3番手を務めさせていただきます。 早いものでニーリーに入社してちょうど 1 年が経ちました。先日、とても稀なエラーに遭遇したので、今回はその件について書きたいと思います。 電話番号フォームを入力すると画面が真っ白になる いきなりタイトルでなんじゃそりゃとなるかと思いますが、本当にこのようなことが起きました。とある案件で全体的に様々なデバイス、ブラウザで動作確認をしていて、本当に偶々見つけたのですが、iOS Chrome ブラウザで電話番号フォームを入力していたところ、11 桁目を入力するとエラーが起きて画面が真っ白になってエラーメッセージが表示されるのです。 10 桁目までは以下の画面で、 10 桁目まで入力したところ 11 桁目を入力すると以下のエラー画面となりました。 11 桁目入力時のエラー画面

ニーリーアドベントカレンダー2025、２番手を務めますプロダクトエンジニアの大友凜です。 最近、今更になってグランメゾン東京を見て「ボナペティ（召し上がれ）」と言うことにハマっています。 ただ、完全に時期を逃してしまっているため、あまりネタが人に伝わることがなくスベりまくっています。 さて本題に戻りまして、直近「ニーリーには今、エンジニアとしてのキャリアを賭ける価値がある」という強気なタイトルの記事を書くにあたり、自分の経験の棚卸しやふりかえりをしました。 その中で僕がニーリーに勤めてから「あ〜、これは上手になったな〜」「ここはエンジニアとして強くなったな〜」と感じたことが「合意形成の推進、意思決定や判断の推進」だと思っています。 そこで今回は個人的な持論やふりかえりを基に「実はエンジニアはドキュメントを合意形成の推進を念頭に書くと仕事が捗るのでは？（≒ 開発スピードが早くなるのでは？）」

こんにちは！ ニーリーアドベントカレンダー2025 始まりました！ トップバッターを務めます、PDBiz開発Gの古庄(@k_furusho_)です。 入社して1ヶ月が経過しました。(入社エントリもきっと書く..!!) 架電業務や駐車場探しの実業務にも参加し、ニーリーの「染み出すカルチャー」を肌で感じる中で、オペレーションやシステムの解像度を一気に上げている最中です。 さて、システムの解像度を高める過程で、開発現場における永遠の課題である「ドキュメント管理」について、改めて思考を巡らせる機会がありました。 「Code is the executable design document（コードこそが動く設計書である）」 私は長らくこの原則を前提に開発プロセスを設計すべきだと思っています。コードが「How（どう動くか）」を最も正確に語っている以上、それと重複する内容を自然言語で書き下すことは、メ

お疲れ様です！ プロダクトエンジニアの石倉です。 実は今回が初のブログ投稿となります、お手柔らかにお願いしますw はじめに 私はエンジニアとして「単に仕様通りに作る（How）だけでなく、それが本当にユーザー価値・事業価値につながるのか（What/Why）を問い続けるべきだ」というこだわりを持っています。 （AIの台頭なども含め）これからの時代、技術力だけで価値を出し続けるのは難しく、ビジネスの課題解決にどれだけ深くコミットできるかが、エンジニアの市場価値を決めると考えているからです。 しかし、ニーリーに入社した当初は、そのこだわりが空回りしていました。 「プロダクト志向」を自負していましたが、ある評価面談でのフィードバックをきっかけに、自分のスタンスが独りよがりなこだわりでしかなかったことに気づかされました。 「#ニーリー開発組織の野望」第10弾の今回は、私の「こだわり」が、いかにして本質

こんにちは、ニーリーの佐古です。 現在開発速度や開発者体験の向上のため、取り組みの諸々を遂行しています。 DevRelKaigi 2025に行ってきました さて、さる10月2～4日に開催されたDevRelKaigiの3日目に参加してきました。 (一か月以上経ってしまった……) devrelkaigi.org 日本では唯一となるDevRelをテーマにしたカンファレンスです。 DevRelとは Developer Relationshipの略で、原則としてはある主体が提供するプロダクトを「利用する開発者」との関係を指し、この分野ではその維持改善への取り組みがテーマとなります。 プロダクトのユーザーグループ(UG)との関係維持やフィードバックの吸い上げのほか、UG自体の立ち上げも行ったりと、自社プロダクトのファンとなる開発者を増やし、「パイを広げに行く」活動を行います。 DevRelエンジニアや

こんにちは。ニーリーでプロダクトエンジニアをしている西村です。 「#ニーリー開発組織の野望」第9弾では、ニーリーでプロダクトエンジニアをやる面白さについてお話しします。 単なる機能開発じゃ、もう物足りない。事業を動かすような、本質的な開発に挑戦したい — そんな思いを抱いたことはありませんか？ 複雑な要件を解きほぐし、不確定な要素と向き合いながら、事業にクリティカルなインパクトを与える。単なる機能追加ではなく、会社の成長スピードそのものを左右する開発。難しいからこそ、面白い。 そう感じるエンジニアの方に向けて、今回はニーリーにおけるこの「高難度開発」の面白さについてお話しします。 決済会計業務効率化プロジェクト：消込処理の自動化 私が2023年から約1年かけて担当した決済会計業務効率化プロジェクトについてご紹介します。全体のコード量の約40%を追加する大規模開発で、複雑なビジネスロジックと

こんにちは、QAチームの宮原です。 少しずつ肌寒くなってきて、もうすっかり秋ですね。 この季節は美術館や博物館に行きたくなるので、ちょくちょくホームページで企画展をチェックしています！ おすすめの美術展などがあればぜひ教えてください！ 先日、Findyさんのイベント ＃QATT番外編 秋の夜長に品質ゆるトーク交流会 にて、「品質ワークショップをやってみた」というテーマで同じQAチームの関井がLT登壇させていただきました。 今回は、そこでお話した品質ワークショップについて、より詳細なレポートをお届けしたいと思います。 当日の発表資料はこちらです。 speakerdeck.com 10月上旬、ニーリーのプロダクト統括本部で「品質ワークショップ」をオフラインで開催し、開発・QA・PdMなど職種を超えた約30名のメンバーが参加しました。 組織が成長を続ける上で、「品質」という根本的なテーマにあらた