はてなブックマーク

こんにちは！株式会社ニーリーでコーポレートエンジニア（以下、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名のメンバーが参加しました。 組織が成長を続ける上で、「品質」という根本的なテーマにあらた

こんにちは！Analyticsチームの上田です。 今回は、 #ニーリー開発組織の野望 シリーズの第8弾として、Analyticsチームの野望を語りたいと思います！ さっそく野望を... と言いたいところですが、2023年5月にAnalyticsチームが始動してから2年半が経ち、チームにもデータ基盤にも大きな変化がありました。以前noteにチームの紹介記事を投稿してから1年半ということもあり、まずは野望に入る前に、それぞれの現在地を確認したいと思います。 Analyticsチームの現在地 ミッションはチーム紹介noteの時と同様、「事業や経営の意思決定を支援するデータ分析結果の創出」です。ニーリーのデータが蓄積されビジネス価値を発揮するまでのフルサイクルを支えています。 取り組む業務 しかし、取り組む業務はnoteの時から大きく拡大しました。 業務は主に次の4つで、太字にした箇所がnoteの

はじめに お疲れ様です！株式会社ニーリーsREの大木 ( @2357gi )です！寒くなってきましたね、スノーボードの季節です。嬉しいですね、気持ちテンション高めでやっていきます。 「#ニーリー開発組織の野望」第7弾の今回は、ニーリーの今後のプロダクト展開のためにsREチームが仕掛けようとしている取り組みを紹介し、sREが「マルチプロダクトの”起爆剤"」であり、「事業成長へのレバレッジポイント」たるぞという話ができたらなと思います。若干ビッグマウスですが、私は本気でsREが今後ニーリーの成長角度を左右すると思っています！ ワンプロダクトのsREからマルチプロダクトのsREへ 我々のメインプロダクトである Park Direct（パークダイレクト） はこれまで T2D3 を超えるスピードで成長してきました。3年連続で月極駐車場オンライン契約サービスの「導入社数」「オンライン契約可能台数」の項

1人目プロダクトセキュリティエンジニアの募集を始めました こんにちは。ニーリーのプラットフォーム開発グループでマネージャーをしている菊地です。 先月「プロダクトセキュリティエンジニア」という求人をオープンしました。なるべく求人票に思いを込めたつもりなのですが、なかなか求人票のフォーマットで全てを伝えるのは難しかったので、今回 #ニーリー開発組織の野望 の第6弾として改めて詳細をお話しさせていただきます。 herp.careers 詳しくは後述するのですが、今年に入りPark Direct(パークダイレクト)というサービスが「社会インフラ」として認知していただくようになりつつあり、ニーリーとしても1段階目線を上げる必要があると実感しています。7月に行われた全社キックオフではCOOの根目沢から「会社の基準をあげる」という強いメッセージが発されました。 このメッセージを聞いて社員はみんな「自分が

こんにちは！株式会社ニーリーのプラットフォーム開発チームでエンジニアをしている松村です。今年はきちんと秋が来て散歩もはかどる季節となりましたね。秋刀魚も無事に食べられて喜ばしい限りです。 さて今回は「#ニーリー開発組織の野望」シリーズ第5弾、プラットフォーム開発のターンです。CTO三宅の記事にもあった通り、今のニーリーにはマルチプロダクト化の波が押し寄せています。この記事ではそんなマルチプロダクト時代の始まりにおける共通基盤アプリケーション開発が持つ魅力をお話しできればなと思います。 note.nealle.com プラットフォーム開発の黎明期からマルチプロダクト黎明期へ 思い出してみると、自分の入社エントリー記事にも「黎明」という言葉を使いました。この言葉は何かが始まる時のカオスさ・ダイナミックさを感じられる気がして好きです。夜明けが始まりに例えられるなんていうちょっとした厨二っぽさもあ

こんにちは！ニーリーでプロダクトエンジニアをしている大友凜です。 私事ですが、昨年に 30 歳を迎えました。 年齢に合わせた生活やキャリアの変化を痛感する最近です。 30 代を節目に色々と将来に考えを巡らすということは、あるあるだと思います。 僕の場合、エンジニアとしてキャリアを重ねるにあたり「20 代は元気で評価してもらえる、30代は実力で評価を勝ち得る、40代は実績で評価されるだろう」と想定して 20 代を過ごしてきました。 そのため、今、この瞬間は「30代の身の振り方を決める大事な時期」だと考えています。 そういった個人的な節目ということもあり、今回は在籍エントリを通して自分の経験の棚卸しをしつつ「今後ニーリーにどう携わり、どう一緒に成長したいか」という個人的な野望を書いていきます。 同じぐらいのライフステージの人、あるいは今後の将来を考えている人にとって面白い、あるいは元気のお裾分

こんにちは。株式会社ニーリーでQAエンジニアをしている池端です。 普段はラーメン食べてばかりでこういう記事を書かないのですが、熱量が高いうちに書き切ろうと思います。 そんなタイミングで、「#ニーリー開発組織の野望」シリーズも第3弾に突入しています。 各メンバーがそれぞれの“野望”を語る中で、今回はQAの番です。 (シリーズ全体の記事は Nealle Developer's Blog からご覧いただけます！) その“野望”を語るうえで外せないのが、先日Xでも展開したQA Recruiting Deckのリニューアルです。 ニーリーのQAエンジニア向けのRecruiting Deckを大幅アップデートしました！🎉 体制の変更やミッションの刷新に伴い、"今の"ニーリーQAチームの魅力が詰まった内容になっています。 少しでもご興味のある方は、ぜひご覧ください！ https://t.co/UiXx

こんにちは、プロダクトAI開発の宮後(miya10kei)です。 先日、数年遅れで初コロナにかかってしまいダウンしていました（コロナ辛いですね、、、）😷 生成AIで画像やPDFのOCR（文字認識）を試したことはあるでしょうか？ ニーリーでは事業で様々な形式の書類を扱っており、如何にしてオフラインのデータを構造化されたオンラインデータに変換するかが業務効率化の重要な要素となっています。 今回は、画像やPDFのOCRに生成AIを用い場合に、どれくらいの精度がでるかを検証した結果を紹介します！ ⚠️ 読む前の注意点 ⚠️ OCR（Optical Character Recognition/Reader）は光学文字認識ですので、既にデジタル化された画像やPDFの文字認識をOCRと呼ぶことに違和感がある方もいるかと思います。ただ、画像やPDFに対する文字認識もOCRと一般的に呼ばれているので、本記

こんにちは、プロダクトAI開発の宮後(miya10kei)です。最近はMakuakeで変わったガジェットを探すのにハマっています🛠️ 昨年、ニーリーで社内AIチャットボットのPoC開発をし、今年の4月から全社で本格的な利用を開始しました。現在は知識領域毎に特化した4つのチャットボットを運用しています。 チャットボット 説明 AI Park Direct Park Directのドメイン知識を回答してくれるチャットボット AI Park Direct for Business Park Direct for Businessのドメイン知識を回答してくれるチャットボット AI 労務 労務関連の社内規定に関して回答してくれるチャットボット AI Analytics BIツールのクエリー検索/解説、NL2sQLなどを回答してくれるチャットボット 今回は、最近新たに社内公開し評判の良かったデータ活

こんにちは、プロダクトAI開発の宮後(@miya10kei)です。 最近は暑さにやられて、自宅に引きこもっている今日この頃です💦 今回はコールセンターの通話内容を通話終了後に、ニアリアルタイムで要約する仕組みを構築したので紹介します。 はじめに ニーリーでは月間数万件の通話が発生する社内コールセンターを運営しています。カスタマー（駐車場の借主様）とクライアント（不動産管理会社様）からの問い合わせに対応する中で、オペレーターの業務効率化が課題となっていました。 オペレーターは通話が終わるたびに内容をテキストでチケット管理システムに記録する必要があります。 慣れた方なら通話しながらメモを取って、電話を切ると同時に記録も完成させられますが、そうでない方は、通話内容をまとめるのに数分かかってしまうこともあります。 その間、次の電話を受けることができないため、あまり長引いてしまうと受電率にも影響が

はじめに こんにちは、プラットフォーム開発グループの菊地(@_tinoji)です。 この度、ニーリーがFindy Team+ 利用企業の中で特に開発生産性が優れた企業として「Organization Award Medium Division」を受賞いたしました。 prtimes.jp 表彰式でトロフィーを受け取るCTO三宅(写真左) ニーリーがFindy Team+を導入したのは今年の3月のため、導入から5ヶ月で表彰していただいたことになります。 まだ利用期間も短く、多くの取り組みができたわけではないのですが、これから開発生産性に力を入れていきたい企業・チームの知見となればと思い、本記事では行った施策の一部を紹介させていただきます。表彰の基準となったのは「開発生産性スコア」というもので、おそらくそれに大きく寄与しているであろうデプロイ頻度と変更リードタイムの2つについて取り上げてみます。

はじめに こんにちは、ARCH チームの立川です。 最近、Axios のリリースノートをチェックしていて 1.8.0 で Breaking Changes が入っていたので（ただし、メジャーバージョンが上がっているわけではない）、今回はその内容について書こうと思います。具体的には、 allowAbsoluteUrls というオプションが追加されたのでそちらに関する説明となります。allowAbsoluteUrls について触れている記事が見当たらなかったので、この記事が皆様のバージョンアップ対応の一助となれば幸いです。 github.com 1.8.0 より前の仕様 allowAbsoluteUrls オプションの設定は、baseURL オプションを利用したリクエスト URL 指定について影響を及ぼします。まずは、1.7.9 での baseURL オプションを使用した例について見ていきます

はじめに こんにちは、sREチームの森原(@daichi_morihara)です。 今回はAmazon ConnectのIaC化および開発体験向上に関する取り組みを共有していきたいと思います。Amazon ConnectはGUIのドラッグ＆ドロップによる手作業で簡単にリソースを作成・変更できる利便性が特徴的です。その一方で本番環境でのリソース変更を手作業で行うのはオペミスのリスクが伴うため避けたいものです。 しかし通常リソースのようにAmazon Connectを完全にIaCで管理するのも、必ずしも適切ではありません。なぜならAmazon Connectの長所である直感的なGUIでのリソース作成・変更ができなくなってしまうからです。 そこでAmazon ConnectのGUIベースの開発を維持しつつ、Terraformでリソースを管理し安全にリリースできる仕組みを整えた事例を紹介したいと思

こんにちは。プロダクトAI開発の宮後(@miya10kei)です。 7/31に株式会社find様、株式会社ALGO ARTIs様と共催で「生成AI、実際どう？ 〜現場エンジニアたちのぶっちゃけトークミートアップ〜」というイベントを開催させていただきました。 find.connpass.com 「ニーリーにおける生成AI活用の進め方と活用事例」というタイトルで登壇しましたので、今回はその内容をスライドを抜粋しながら紹介します。 speakerdeck.com 生成AIの活用事情 これまで ニーリーで本格的に生成AIの利用を開始したのは2024年下期（7~12月）からになります。きっかけはこちらのブログにある登壇駆動開発です。社内向けのAIチャットボットのPoCを開始し、そこから生成AI活用のテーマを発掘し始めました。2025年上期には事業部門／開発部門ともに業務で生成AIを本格的に活用するよ

はじめに こんにちは、sREチームの森原(@daichi_morihara)です。 今回はDatadogのログのコスト削減に関して最近行った取り組みを共有していきたいと思います。AWsやGCPなどのクラウドに関してはコスト削減・最適化に積極的に取り組んでいる一方で、Datadogに関してはあまりできていない、、というケースは多いのではないでしょうか？ (Datadogを使用している場合に限りますが。) 弊社でもDatadogのコスト最適化はあまり行えておらず、提供するサービスのスケールに伴ってDatadogのログコストが着々と増加してきたため、コスト削減に取り組むに至りました。 Datadogログコストの構造 Datadogのログコストは主に2つの要素によって構成されます。 ログの取り込み（Log Ingestion)：Datadogに送信されたログの収集・処理・パースするのに発生するコス

yuru-sre.connpass.com お疲れ様です。sREの大木 ( @2357gi ) です。本日は 『ゆるsRE勉強会 #12 sRE乗り越え体験まつり 〜聞いてくれ俺の武勇伝〜』の参加レポです💪 ゆるsRE自体は『ゆるい雰囲気で肩肘張らずにsRE関連のトピックについて話す勉強会』と銘打っており、その通りにゆるくワイワイできるコミュニティです。 今回で12回目、そして2周年だそうです！めでたい 👏👏👏 今回の会場はLINEヤフーさんのLODGEです！ 広くてオシャレなオフィス、素敵ですね〜 フードスポンサーは株式会社スタディストさん、ドリンクスポンサーはリブセンスさんです🍻 会場スポンサーLT『オブザーバビリティコミュニティの近況報告』@msksgm speakerdeck.com o11yの公式ドキュメント ja-docs-approver の @msksgm さんの

こんにちは！QAチームの関井（@ysekii_）です。 先日、札幌で開催されたソフトウェアテストシンポジウム JassT'25 Hokkaido に参加してきました！オフラインでのJassT参加は6年ぶり、そしてJassT Hokkaidoへの参加は今回が初めてです。 さて、本記事ではJassT'25 Hokkaidoの中でも、私が最も楽しみにしていたワークショップ「技法を探せ！2 ～生成AIで進化するテスト設計の実践～」を中心に、その学びや気づきをレポートします！ ……なお、せっかく「生成AIで進化するテスト設計」をテーマにした内容なので、この記事自体も生成AIと一緒に書いています（笑） 実践あるのみ、ということで、AIとペアライティングしながら当日の空気感や気づきをまとめてみました。 JassT'25 Hokkaidoとは？ JassT Hokkaidoは、ソフトウェアテストに関する知

こんにちは、ニーリーの佐古です。 現在開発速度や開発者体験の向上のため、取り組みの諸々を遂行しています。 Celeryの"接ぎ木" もともと弊社プロダクトではバッチの実行などにCeleryを利用していた経緯もあり、 高速化のために処理の並列化を考えると あるCelery TaskからべつのCelery Taskに処理を逃がすことが起きます。 これ自体は発想として割と自然なのですが、以下の問題があります。 単純に実装しづらい(特にWeb側) Webリクエストなどバッチ以外のエントリポイントから、 気軽に並列処理を書こうとするとCeleryの構成や制約が邪魔になるのです。 非同期実行を行うには明示的なTask定義とapply_async()が必要で、 依存関係やエラーフローの扱いも暗黙的です。 エラーハンドリングというかエラー検知自体が困難 Task間の例外伝播がされず、モニタリングやトレース

はじめに さて今回はBigQueryで自由記述形式のデータを分類するPart 2ということで、予告通りVector search を利用したテキスト分類を手軽にできるのか検証していきたいと思います。 （前回のブログでVector search Indexと述べてますが、Vector searchを利用するという部分が趣旨になります。） 利用するデータはPart 1と同じ駐車場申し込みのキャンセル理由となりますがインデックスの作成なども検証したかったので前回よりもデータが多めです。 検索対象となるデータが5000件に満たない場合はそもそもインデックスを作成する意味がないため、Vector search Indexは利用できないのでご注意ください。 なお、結論から言うと前回実施したgeminiIを利用した手法よりは精度が劣っており今回は70%程度の正答率でした。 前回のブログはこちら neal