はてなブックマーク

はじめに TROCCOでdbtジョブを実行・ワークフロー化 dbtのドキュメント生成機能を試してみた 社内のデータ利活用者に公開したい 作成した構成 おわりに・今後やりたいこと はじめに Analyticsチームの清水です。 今回はアナリティクスチームの業務紹介として、将来のAI活用を本格的に見据えたデータ基盤変革の第一歩、 データマートおよびデータカタログ整備の取り組みについてご紹介します。 現在のデータ基盤には、要所要所でViewやデータマートとなるテーブルが手動で作成されており、バージョン管理やメタデータ管理ができていない状態でした。 Analyticsチーム内だけであればコミュニケーションで補えますが、データを利活用する他部署のメンバーにとっては非常に使いにくい状態です。 そして、この課題は単なる業務効率の問題に留まりません。今後、Text-to-SQL(自然言語からのSQL生成)

はじめに Park Direct開発2グループの畠山です。先日在籍エントリを書いて、筆が乗ってきたので続けてもう1本書きました💪 スクラム開発における「ふりかえり」は、チームが継続的に成長するための大切な時間ですが、「毎回同じような話ばかりでマンネリ化している」「具体的な改善策に繋がらない」「メンバーの発言が少なく、どうすれば良いか分からない」といった課題を感じている方もいらっしゃるのではないでしょうか? この記事では、私たちのチームがふりかえりで実践しているフレームワークや、そこから得られた学びをご紹介します!皆さんのチームのふりかえりをより良くするための一助となれば幸いです。 ふりかえりの目的 ふりかえりは、単なる作業報告の場ではありません。日々の仕事を進める上で直面した問題や障害を明らかにし、開発を通して得られた知識を共有することで、プロセスを継続的に改善していくための貴重な機会で

はじめに Analyticsチームの上田です。 皆さんは、データ分析を進めているうちに「このデータ、何のために出したんだっけ?」と目的を見失ってしまったことはありませんか? 目的を見失った分析は本来のゴール達成に繋がりにくいため、望ましくありません。 そこで今回は、迷子を防ぐためのデータ分析結果の整理方法をご紹介します。 はじめに なぜ迷子になるのか 要因1. 分析には繰り返しが伴うから 要因2. 分析では並行作業が発生しやすいから 要因3. 生成AIの発展により、分析のリードタイムが短縮されたから どうすれば迷子を防げるか 実践してみた結果 Miroを使うメリット おわりに ※(注記) CHUO Tech #7の登壇でも関連した話をしているので、よければご参照ください。 speakerdeck.com なぜ迷子になるのか 適切な整理方法を考えるにあたり、まず迷子になってしまう要因を考察しました。

こんにちは。ニーリーのAnalyticsチームで働いている五十嵐です。普段は鹿児島からフルリモートで勤務しています。下の写真は鹿児島の日常です。この程度では誰も見向きもしません。 桜島 5月で入社1年が経ちました & 入社エントリを書くタイミングを逃してしまったので、禊の振り返り記事を書かせていただきました。 面接ではよく「テックブログ読みましたよ」と言われるらしいので、ニーリーへの入社を考えてくださっている方の参考になれば幸いです。 2024 上期(2024年5月〜6月) 2024年5月に入社し当初2週間程度はオンボーディングメニューに沿って月極駐車場やPark Directに関するドメイン知識、データ基盤開発や分析の標準的なフローをじっくり学ぶ期間とその時は思っていました。 しかしそこはやはりスタートアップ。入社3日目くらいに急ぎめの指標値の算出依頼が入り、早速自分が担当することになり

ゴールデンウィークが明け、新たな気持ちで業務に取り組まれている方も多いのではないでしょうか。 長期休暇は、日々の業務から離れて立ち止まり、これまでの歩みを振り返ったり、今後の目標を再確認したりする良い機会になりますよね。 今回、私が株式会社ニーリーに入社してちょうど1年という節目を迎えましたので、この1年間を振り返る在籍エントリーをお届けしたいと思います。 テックブログなのに技術の話じゃないのか、といったツッコミもあるかと思いますが、「妖怪テックブログ」こと菊地さんが率先して書いてくださったので、それに倣おうと思います。 妖怪テックブログについてはコチラ nealle-dev.hatenablog.com 入社後1年を振り返る 元々経営コンサルタントだった私は3年前にWEBエンジニアへ転身し、IT企業2社目として選んだのがニーリーでした。 1年前のブログでは「チャレンジしがいのある課題がた

はじめに はじめまして。Analyticsチームの清水です。 2024年12月に入社しまして、約4ヶ月が経過しました。今回が初めてのテックブログになります。 ▼先日、入社エントリも公開しました。 本稿のテーマは、自由記述のテキストをラベリングして分類する分析タスクに対し、Geminiと共に取り組んで分かったことの共有です。 私は生成AIをそれほどたくさん使った経験があるわけではないので、これが最良の使い方というわけではないと思いますが、どのようにプロンプトを組み立て、どう効率的に分析を進められたのかを可能な限りリアルに書いていきます。 ※(注記)今回利用したモデルは、Gemini 2.5 Proです。 はじめに Geminiを活用したデータ分析の進め方 フェーズ0: アプローチの模索 - Notebook LMや教師なし学習の試行 フェーズ1: データ理解とラベルチェック - コード生成と探索的分

プラットフォーム開発Gの菊地(@_tinoji)です。 ニーリーのテックブログを始めて1年が経ったので、振り返りをまとめておこうと思います。 なぜテックブログを始めたのかについては、最初に投稿した記事に書いてあるのでそちらをお読みいただけると。 こういう振り返り記事は、これからテックブログを開設しようとしている人などを想定して「こういう良いことがあるからやろうよ!」という示唆に富んだものが多いと思うのですが、なんかうまく書けなかったのでやめました()。運営した人間が思いつくまま書いた随筆としてお楽しみください。 定量面振り返り 初めてのアドベントカレンダー テックブログ(を含む外部発信活動)と評価 「妖怪テックブログ」の必要性 テックブログによって何が変わったのか おわりに 定量面振り返り 総投稿数は54でした。1年=約52週として、「毎週投稿しつづけました!」と言いたいところですが、めち

はじめに SREチームの森原(@daichi_morihara)です。今後は積極的に発信していこうという誓いを込めてXのアカウントを作成しました。 今回はEC2+ALBでホストしていたフロントエンドをS3+CloudFrontに移行する際に起きた問題について紹介しようと思います。移行後のフロントエンドのインフラ構成としては下の図の通りで、S3の前段にCloudFrontを配置しており、CloudFrontに紐づいたWAFがアクセス制限を行います。 フロントエンドのインフラ構成図 ここでハマった問題というのが「CloudFrontに紐づいたWAFが、なぜかブロックすべきアクセスまで通してしまう...?」というものでした。 本記事では問題の原因と、それに対する解決策を共有していきます。もしかすると気づかずのうちに同じ状況になっている可能性もあると思うのでご参考にしていただけると幸いです。 問題の原

こんにちは、QAチームでSETを担当している宮内です。 少し時間が経ってしまいましたが、JaSST '25 Tokyoに初参加してきたのでレポートを書きました。 1日目は現地参加、2日目はオンライン参加でした。本記事では、現地参加での体験を中心に会場の様子や印象に残ったセッションを共有します。 今回初めてJaSSTに現地参加し、月並みな感想ではありますが現地ならでは熱量を感じ、このようなタイトルにしました。1日目の終了後には有志コミュニティの交流会にも参加させていただき、改めてオフラインでの交流の良さを再確認できました。 オンラインで参加した別のメンバーも先日レポートを投稿しているので、あわせて読んでいただけると嬉しいです。後日また他のメンバーから、今度はJaSSTの内容をチーム内で振り返った結果のレポートを公開予定です。 nealle-dev.hatenablog.com いざ、出発 い

こんにちは、ニーリーでQAエンジニアをしている鹿間です。 先日 JaSST ‘25 Tokyo にオンラインで参加し、品質に対する新たな視点を得ることができました。 その中でも、内容に親近感がありつつも品質とは何かを再考させてくれた2つのセッション B4)ゲームテストシラバスを読み込んでみた C5-2)チームで自信を持つためにアウトプットに触れて対話する機会を増やす から学べたことを書いてみようと思います。 https://jasst.jp/tokyo/25-about/ B4)ゲームテストシラバスを読み込んでみた まず、「ゲームテストシラバスを読み込んでみた」の企画セッションについてです。 こちらは、ゲームテスト関係者によるパネルディスカッションでした。 以前、入社エントリでも書いたのですが、私がQAという業界に入るきっかけとなったのはゲームテスターのアルバイトだったため、 このシラバス

背景と悩み SREチームの大木(@2357gi)です。いよいよ暖かくなってきましたね。春スキーの季節です。 チーム開発においてCIを如何に高速化するかという話は日夜行われていると思います。 弊社でも同様のことが行われており、その中でパッケージ管理ツールによるライブラリのキャッシングなどの高速化も実施しています。 しかし、キャッシュを指定しているはずなのに、「PRを作成して最初に走るCIではキャッシュがまったく効いていない」 というケースが存在しました。 お使いのGitHub Actions Workflow によっては実は同じ症状の方もいると思うので、ご参考になれば幸いです。 GitHub Actionsのキャッシュ仕様のおさらい GitHub Actionsのキャッシュはブランチごとに分けて生成されます。 もう少しいうと、キャッシュは「 ワークフローが実行されるブランチ」に紐づいて生成さ

こんにちは。SREチームの高 (@nogtk)です。ゼノブレイドXリメイクで惑星ミラの探索に勤しんでいる今日この頃です。 直近行った取り組みとして、アプリケーションログの構造化を行い、ログの検索性の向上を行いました。この記事では実際の実装も交えつつ実施した内容についてご紹介したいと思います。 構造化ロギングによって解決したい課題 Park Direct のバックエンドアプリケーションは Django で作られ、ログの出力先としては Datadog Logs を利用しています。このアプリケーションログは、長らくデフォルトである非構造化形式でログが出力されており、以下のような課題を抱えていました。 タイムスタンプやログレベル、トレースバックなどの各要素について、Grokパーサなどを駆使し Datadog のログパイプライン処理で抽出を行なっていたが、パターン網羅に限界があり、うまくパースできて

こんにちは、QAチームの関井(@ysekii_)です。 かなり時間が経ってしまい今更ではありますが、1月20日(月) に開催された QA engineer at a Startup vol.4 ysekii編 に登壇したので、準備から当日までの様子をレポートしたいと思います。 ちなみに、イベントの様子は以下の動画でご覧いただけます。 www.youtube.com QA engineer at a Startup って何? 「QA engineer at a Startup」(QaaS)は、スタートアップの現場で働くQAエンジニアが同じ目線で話し、共に成長できるコミュニティです。大企業とは異なる、スタートアップならではの意思決定のスピードやリソースの制限、日々直面する課題や悩みを相談し励まし合える場を目指して立ち上げられました。 このコミュニティイベントでは「〇〇さんの日常」というシリーズ

こんにちはSREチームの宮後(@miya10kei)です。 最近、Keychron K2 HEが届いて天然木のぬくもりを感じています⌨️🌲 気づいたら1ヶ月ほど経ってしまいましたが、2025年1月26日に開催された「SRE Kaigi 2025」で登壇させていただいたので簡単ですがレポートを書きたいと思います。 セッション内容について 今回は「SRE、開発、QAが協業して挑んだリリースプロセス改革」というタイトルで登壇いしました。スライドを抜粋しながら簡単に内容を紹介させていただきます。 speakerdeck.com 課題 弊社では2022年頃に「デプロイ頻度の低さ」と「変更障害率の高さ」という2つの課題がありました。プロダクトをグロースさせていく上で高頻度に安定したリリースをしていくことは重要なため、開発から運用までを含めたリリースプロセスの改革をはじめました。 取り組み セッション

こんにちは。プラットフォーム開発チームの松村です。 はちゃめちゃに寒い今日この頃ですが、この時期に入浴剤をいれてお風呂に入るのが好きです。 泡が出るような固形タイプもいいですが、各地の温泉地とかがモチーフになってる昔ながらの(?)粉タイプが好きです。 にごり湯だとなおよし。 さて、今回はリリース管理のための仕組みであるリリーストグルの運用をどのように整備したかというお話をしようと思います。 先日の SRE Kaigi で弊社SREの宮後がした発表の中でも紹介がありましたが、ニーリーではリリースプロセス改善の一環でリリーストグルの運用改善に取り組みました。 この記事ではこの取り組みをもう少し掘り下げて紹介していきたいと思います。 宣伝ですが、発表ではこれ以外の話も含めてリリースプロセス改善全体の話が横断的に紹介されています。 そちらの方もぜひご覧ください! speakerdeck.com そ

お疲れ様です。大木 @2357gi です。 とっておきの豆知識なのですが、スノーボードというものは滑走時は運動して体が温まり、リフトで体が冷えるので実質交互浴実質サウナであります。 本題ですが、今回はEC2のAWS Patch Managerを用いて本番環境のEC2に自動でパッチを当てる際のノウハウについて共有したいと思います。 背景 弊社のAWS環境は、DBの踏み台に至るまで基本的に全てECSで運用されており(踏み台ECSについてはこちら)、EC2のメンテナンスからは解放されているのですが、本番環境の一部ではEC2上でアプリケーションが動いているところがあります。 消える目処は立っているものの、それまでの期間はパッチ適用といったEC2のメンテナンスに一定のコストを払う必要があります。 そこで、AWS Patch Managerを使用することによりそこを解消しようとしました。 ただし、愚直

お疲れ様です。今年は豪雪らしくワクワクが止まらないスノーボーダーの2357giです。 AWSリソースをIaCで管理しているプロジェクトにおいて、IaCリポジトリとアプリケーションリポジトリが分かれている中で、どのようにアプリケーション用ECS ServiceのCDを実現するかは悩むところではあると思います。 そんな中で、弊社がどのような構成でそれを実現しているかを紹介したいと思います。 特筆して珍しいことは行なっていないのですが、AWSリソースをIaC化し始めた方の参考になれば幸いです🙌 背景 ALBとECS Service自体はインフラリソースであり、IaCリポジトリで管理したいという思惑があります。 それに対して、ECS ServiceやECSタスク定義のライフサイクルはアプリケーションと一致しており、アプリケーションリポジトリから更新したいです。ここでいうライフサイクルの一致とは、

この記事はニーリーアドベントカレンダー2024の25日目 その2の記事です。 こんにちは、ニーリーの佐古です。 最終日ということで、短く冬休みの自由研究の予告をして終わりたいと思います。 テーマ Quarkusで簡単なWebアプリケーションを作る Quarkusとは 高速性がウリのJavaフレームワークです。 ja.quarkus.io 曰く、以下の特徴を持ちます。 GraalVMによるネイティブコンパイルを前提にしたフレームワーク Mutinyによるリアクティブプログラミングサポート Kubernetesのネイティブサポート 動機 RxJava + Vert.x の開発経験がある身としてはいろいろと都合が良すぎるので そんなオイシイ話があるのか?ということで実際に組んでみようと思った次第です。 社内の技術スタックとは全く別ですが、そこは余暇の手すさびでございまして。 一応、将来的な技術選

この記事はニーリーアドベントカレンダー2024の25日目 その1の記事です。 こんにちは。ニーリーのCTOの三宅(@katzhide)です。 とうとうアドカレも最終日ですね。 今年3月からこのテックブログを始めたのですが、開設からしばらくの間は執筆者が偏ってしまっていました。全体で盛り上げるために勢いでアドカレをやろうと、とある人直伝の無茶振り駆動で実施を決めたのですが、埋まらない場合は自分が何本も書くしかないと覚悟していました。 しかしそんな心配は杞憂でした!完走するだけじゃなくてまさかシリーズ2まで爆誕するとは!忙しい年末に頑張ってくれたみんなに感謝です。 はじめに ニーリーでは、開発のアジリティを高め続けていくことを大事にしています。サービスローンチ直後はそれこそCI/CDすら整っていない状態からのスタートでしたが、開発プロセスだけではなく、全体のアジリティを高めるために色々な施策を

この記事はニーリーアドベントカレンダー2024の24日目 その1の記事です。 こんにちは、菊地(@_tinoji)です。 クリスマスイブですねー。今年も特に予定はなく( )、井上尚弥の試合を唯一の楽しみにしていたのですが、延期になってしまったのでアドカレを書くことにしました 😇 前職では新卒入社から4年連続でクリスマスイブにアドカレを書いていたので、とても懐かしい気持ちです。 何を書くか迷ったのですが、先月でちょうどニーリーに入社して丸3年経ったので在籍エントリを書いてみようと思います。自分がジョインしたときには入社エントリという文化もなかったですし、「1年ごとに振り返り記事とか書きたいなー」という気持ちは忙殺されつづけていたので、3年分まとめて書きます(今書き終わったところなのですが、長くて読みにくいと思うので来年から毎年分けて書きますw)。 検索してみると在籍エントリーは(おそらく「

BigQueryとTROCCOを利用したお手軽リバースETL事例紹介 本記事はニーリーアドベントカレンダー2024の24日目の記事です🎅 はじめに こんにちは。Analyticsチームに所属する五十嵐です。 2024年も早くもクリスマス・イブですね。 2024年、ニーリーではデータ基盤の整備が進み、Park Direct事業のさまざまなデータを統合し分析する環境が整ってきました。 nealle-dev.hatenablog.com こうした取り組みの中で、データ基盤で集計したデータをPark DirectのDBに転送しアプリケーション側で活用してもらう、いわゆるリバースETLの運用が始まっています。 本記事では、ニーリーのデータ基盤におけるリバースETLについて簡単にご紹介しようと思います。 ちなみに、登場するテーブル定義やデータ転送設定は仮のものです。 リバースETL導入の背景 まず、

GAS高速化のススメ はじめに こんにちは。サクセスエンジニアリングチームの増田です。 今年の8月に入社して早4か月が経ちました。 入社エントリも公開していますので良ければ見ていってください note.nealle.com 最近週4でカレーばっか食ってます。 美味しいカレーの後がけスパイスやソースなどあればぜひ教えていただきたい...! GASについて みなさん普段から業務でGAS(Google Apps Script)利用されてますでしょうか。 GASは知っての通りセットアップ不要で使え、Googleサービス(Google Sheets、Gmail、Driveなど)への認証が標準で組み込まれている非常に便利なツールです。非エンジニアでも扱いやすく、業務効率化の手段として広く活用されています。 GASのデメリットと課題 そんな便利なGASですが多くの制限が存在します。 その中でも代表的なも

連載「過渡的設計に挑む」#2 pre リポジトリパターンこの記事はニーリーアドベントカレンダー2024の23日目 その2の記事です。 こんにちは、ニーリーの佐古です。 現在プロダクト統括本部内のARCHチームというチームでテックリードとして開発速度や開発者体験の向上のため、取り組みの諸々を遂行しています。 今回またその一例を 年末にチャレンジしたいことLT会 - connpassで発表した内容をもとにご紹介できればと思っていたのですがが、 その前に書籍紹介を。 書籍「進化的アーキテクチャ」の紹介 www.oreilly.co.jp このような本が出ていることにこの連載の#1 をほぼ書き終わった後に知りました。 ちょっと触れずにはおけない内容ですので紹介しておきます。 訳者まえがきには、 この本はM. Fowler氏*1のブログ*2 の「Is Design Dead?」にある「進化的設計」を

70点で始める業務効率化開発この記事はニーリーアドベントカレンダー2024の20日目 シリーズ2の記事となります。 こんにちは。グロース開発チームのエンジニアの西村です。 この記事では、事業成長に伴い増大しているオペレーションの効率化を目指した開発の一例について紹介しようと思います。 ニーリーでは、月極駐車場のオンライン契約サービスであるPark Direct(パークダイレクト)を展開しています。 パークダイレクトでは、ソフトウェアとオペレーションを組み合わせることで、管理会社様や借主様に価値を提供しています。そのため、パークダイレクトの機能は管理会社様や借主様だけでなく、オペレーションを行うニーリーの従業員も利用しています。 「ソフトウェアとオペレーションを組み合わせる」という点が、先日の記事↓でもあったようにプロダクトとして面白いポイントで、SaaSでありながらオペレーションの効率化が

コストと開発体験を両立させるfeature環境の運用方法この記事はニーリーアドベントカレンダー2024の20日目 その1の記事です。 こんにちは、SREチームの森原(@daichi_morihara)です。 今回はニーリーのfeature環境の管理方法について紹介していきたいと思います。 feature環境 feature環境とは、新しい機能やバグ修正を検証するために作業用ブランチを、インフラにデプロイしたものを指します。ニーリーではこのfeature環境の管理をPRのラベルで行っています。ラベルで管理することで以下のような利点があります。 特定のPRのみに対して簡単にfeature環境が作成・削除できる PRのラベルとライフサイクルに紐づいているのでfeature環境の立ち上げっぱなしを防ぐことができる feature環境とブランチの紐付きが明確で管理が簡単 以前のブログでSREチームの

QAチーム2年目を振り返る(取り組み編)この記事はニーリーアドベントカレンダー2024の19日目 その2の記事です。 こんにちは、QAチームの関井(@ysekii_)です。 先日書いたQAチーム2年目を振り返る(体制編)の続きで、今回は2024年にQAチームとして取り組んだことを振り返りたいと思います。 ちなみに、今年取り組んだ内容は「これってQAがやることなの?」と思われるかもしれませんが、そのあたりは大目に見ていただけると幸いです😉 開発チームへの問い合わせの窓口設置 まず、今年の初めから取り組んだことは、開発チームへの問い合わせの窓口設置になります。 ニーリーではPark Directを利用いただいている不動産管理会社様や駐車場ユーザーの方から日々さまざま問い合わせを受けています。 これらの問い合わせを受けているビジネスサイドのメンバーで調査・回答が難しい質問(特定の操作履歴やある

人生3度目のE2Eテスト自動化への挑戦この記事はニーリーアドベントカレンダー2024の19日目 その1の記事です。 こんにちは、ニーリーでQA/SETをしている宮内です。 今年の10月に入社し、現在3ヶ月目になります。 アドベントカレンダーに何を書こうか迷いましたが、入社後の最初のメインタスクであるE2Eテスト自動化について携わるのが人生で3回目となるので、過去の経験を振り返りながら意気込みを書きたいと思います! 自己紹介 私は新卒から11年間IT業界で働いており、8年間は開発エンジニア、その後3年間はQAエンジニアとして活動してきました。なぜ開発からQAへ転身したのかについては、また別の機会にお話します(入社エントリーより先にアドベントカレンダーを書いてしまいましたが笑)。 ニーリーでは、開発経験を活かしたくQA/SETというポジションで入社しました。 ただ、SETというポジションの必要

エンジニアだけど積極的に兼務を駆使して事業成長にコミットしている話この記事はニーリーアドベントカレンダー2024の18日目 その2の記事です。 こんにちは。サクセスエンジニアリングチームの中村です。 気づけば今年もあとわずかになってきましたね。我が家では「年末だからいいよね」が合言葉になっており、食生活がものすごく崩れます。今年こそはランニングで体型維持するんだ、、とビールを飲みながら、、 この記事ではサクセスエンジニアリングという組織に所属しながら、エンジニアリングとは違うことをしている話をしたいと思います。兼務が多いことはアンチパターンといわれることもありますが、実際にやってみたら、主務に大きな影響があったり、事業成長によりコミットできたので紹介したいと思います。ニーリーという会社にはこんな人もいるんだよ、みたいな視点で見て頂ければと思います。 はじめに そもそもサクセスエンジニアリン