この記事は毎週必ず記事がでるテックブログ "Loglass Tech Blog Sprint" 44 週目の記事です！1 年間連続達成まで残り 9 週となりました！ はじめに はじめまして、2024 年 4 月にログラスにジョインしたエンジニアの石畑です。 まだまだドメインやシステムについて学んでいる最中なのですが、その中でアラート監視・運用周りをより良くできそうだったので、試行錯誤したことをまとめたいと思います。 どんな課題があったのか？ ログラスではフロントエンドからバックエンド、インフラに至る全てのログ・メトリクスが Datadog に集約され、横断的に分析・監視できる仕組みが整っています。アラートも Datadog でモニタリングを作成し、「Slack に通知 → ローテションのオンコール担当が対応」という体制が作れています。 しかし、歴史的に積み重なったモニタリングが過剰にアラー

この記事は毎週必ず記事がでるテックブログ "Loglass Tech Blog Sprint" の 34 週目の記事です！ 1 年間連続達成まで 残り 19 週 となりました！ 株式会社ログラスの龍島（りゅうしま）です。最近はもっぱら新生姜をガリにしてクラフトビールのつまみにする毎日を送っています。今日はデータベースとデータ構造の話です。 この記事でやること データ集計の高速化のため、多くの場合、列指向データベースが選ばれます。列指向が大量のデータ操作を効率的に処理できるためです。行指向のデータベースを利用している状況で、データ集計のパフォーマンス向上のため列指向データベースへの移行をすることはよくある例です。しかし、行指向データベースで有効なデータ構造やクエリが列指向で同様に優れているとは限りません。この記事では、行指向のPostgreSQLと列指向のBigQueryを使って、それぞれに

はじめに 勝丸と言います。ログラスのエンジニアが毎週記事を発信するLoglass Tech Blog Sprint 2周目に突入しました。前回は「心穏やかにDBバージョンアップ！ロジカルレプリケーションで安全にバージョンを切り戻せるようにした話」という記事を書きました。こちらもよろしくお願いします。普段はログラスの横串組織で活動しています。 この記事では「数年来の技術的負債を改修した話 - 2種類のORM並列状態からの脱却 -」というタイトルで、年末から年始にかけてやっていた作業について共有します。 この記事で得られること リファクタリングのやり方や考え方 リリースへの持っていき方 投資判断のタイミングや負債解消について 経緯 ログラスでは2種類のORMが存在していました。創業時にORMとしてExposedを採用したのですが、後に一部機能が足りないことが発覚し、別のORMを利用し始めました

この記事は毎週必ず記事がでるテックブログLoglass Tech Blog Sprintの17 週目の記事です。 1 年間連続達成まで残り 36 週となりました！ はじめに こんにちは！株式会社ログラスでエンジニアをしているd4te74です 🍷 ログラスではレポートと呼ばれる経営データ分析のための機能領域を改善するチームに所属しています。 この記事では、最近取り組んでいたレポート機能のフロントエンドのパフォーマンスチューニングとして行った「巨大なテーブルコンポーネントの仮想スクロール化」について書いていこうと思います。 ※ Loglass は事業の予実を管理するサービスです。 レポート機能とは レポート機能とは、Loglass 内に統合された部署や勘定科目などの経営データに対し集計・分析が行える機能で、ユーザー自身がそれらを自由度高く表形式に組み立てて、表示できるというものです。 以下の

この記事は 株式会社ログラス Productチーム Advent Calendar 2023 18日目の記事です。 はじめに ログラスの龍島(@hryushm)です。 ソフトウェア開発において、「シフトレフト」すなわち開発の早い段階でテスト計画を立て、実施していくことが全体的なコスト削減や価値提供の早期化につながるとよく言われています。 この記事では、シフトレフトによってもたらされる効果をログラスでの実例を用いて紹介した上で、なぜ効果が出るのか？を「抽象度」というキーワードから紐解いてみようと思います。 本記事ではスクラム開発においてPBIを完了させる中でシフトレフトしていくことを念頭に書いていきますが、ソフトウェア開発の任意のタイミングにおいて適用できる概念だと考えています。 テスト設計を実装前にやることの有用性 まずシフトレフトによって何が起こるのか？を考えます。PBIに書かれた受け入

この記事は 株式会社ログラス Productチーム Advent Calendar 2023 13日目の記事です。 はじめに 〇〇を削除できるかどうかのビジネス処理、皆さんはどう実装していますか？ 同僚の話題になった記事でも削除の認可処理をどこに記述すべきか？は難しいと説明されています。今回はお題は認可っぽいもので書きますが広範に「削除ができるかどうか？」のビジネスロジックをドメイン層にどう閉じ込めるかの便利な実装パターンを紹介します。 削除処理のビジネスロジックの取り扱いは難しい 削除処理のビジネスロジックの実装はシンプルだけど更新処理や作成処理と比べて意外と難しいです。 それはなぜかというとドメインオブジェクト内の実装に削除処理を書くことができないからです。 例えば権限に管理者と一般ユーザーの二つの権限があるとします。

最近、少々複雑な権限機能の開発を担当している中で、対応方針を悩んでいたことがありました。 権限機能というものは取り扱いが難しく、影響範囲が広いにも関わらず、対応漏れや考慮不足があると情報漏洩に繋がってしまいます。 また、機能拡張をしてく中でも対応漏れを起こさないようにする必要があるなど、考えることも多く頭を悩ませておりました。 そこで、認可処理の設計のベストプラクティスやDDDの実装パターンに認可処理を組み込む方法など、色々と調べていたのですが、その中でいくつか知見を得られたのでまとめようと思います！ 権限と認可 権限と切っては切れない関係にあるのが認可です。 権限はある操作を実行できる権利を指します。 それに対して、認可は操作を実行する許可を出すため仕組みのことを指します。 例えば、ブログ投稿サービスで考えてみると、以下のような感じです。 権限: 投稿者はポストを編集できる。 認可: ユ

はじめに 本記事ではログラスにおけるスクラムマスターの考え方、そして専任化についての取り組みの現在地点をお伝えできればと思います。 なぜこのテーマを選んだか？というと、この1年を振り返る過程において、スクラムマスターという役割が改めて重要な役割を果たすのではないか？と考え、直近で専任スクラムマスターを置く取り組みを実施しておりました。 こちらの取り組みから、どんな仮説を立てたか？現在どんな状況か？などをまとめることで、同じくスクラムマスターの位置付けについて悩んでいる企業があれば参考にしていただけるのではないかと考えたためです。 この記事では私がエンジニアリングマネージャー（以下EM）として、スクラムマスターとEMの責務の切り分けをどうすればお互いがパフォームできる状況を作れるのか？という視点から話を進めていきます。 ログラスのスクラムについて ログラスでは創業時の1チームのスクラムチーム

この記事は毎週必ず記事がでるテックブログ "Loglass Tech Blog Sprint" の 9 週目の記事です！ 1年間連続達成まで 残り 44 週 となりました！ はじめに こんにちは、株式会社ログラスでエンジニアの浅井（@mixplace）です。開発チームのいちメンバーとして、チームの開発生産性改善を行う傍ら、デザインシステムの構築に携わっています。 ログラスもプロダクトローンチをして 3 年が経ちました。日々新しい機能の追加や改修が入っていく中で、開発チームも増え、チーム内でアウトカムを出していくことが増えてまいりました。 機能が増え画面数も増えてくると、比例するように「UX負債」や「共通UIコンポーネントの技術的負債」も目に付くことが増えてくるようになります。 このような課題について、プロダクト全体の品質や一貫性担保する観点で「デザインシステム」を構築して運用していくことが

はじめに アジャイル開発では、技術やビジネスといった側面だけでなく、開発を担う人々の「人的側面」への取り組みが欠かせません。この記事では、その「人的側面」を強化する効果的なアプローチとして、「システムコーチング®」を紹介します。 特に「アジャイル・フルーエンシーモデル(アジャイルのプラクティスを包括的にまとめるモデル)」とシステムコーチングとの相互補完性に焦点をあて、ログラスの事例を交えて具体的な効果を探ります。システムコーチングを導入することで、チームや組織にどのようなインパクトがあるのか、そのポイントをお伝えします。 アジャイル開発とは アジャイル開発は、顧客の要求に迅速に対応するためのソフトウェア開発手法の総称です。短期間のイテレーションを通じて、開発チームは頻繁に製品のリリースを行い、顧客のフィードバックをすばやく取り入れることができます。 このアプローチはその柔軟性と迅速性により

この記事は毎週必ず記事がでるテックブログ "Loglass Tech Blog Sprint" の 8週目の記事です！ 1年間連続達成まで 残り45週 となりました！ はじめに チームビルディングというとチーム開発をしている人ならばありふれた取り組みで普段からやっているよ！という人も多いかと思います。 しかしながら、初めてチームビルディングをリードする人にとってはどうやって取り組んだらいいか悩む人もいるのではないでしょうか？ 特に「いつやればいいのか？」「どうなったら成功と言えるのか？」といった疑問については言語化が難しいところでもあります。 この記事ではこれからチームビルディングにトライする人向けに、チームビルディングを始める際の考え方やHowの接続について解説します。 チームビルディングとは チームやチームビルディングの定義についてはペパボさんの以下のスライドが非常にわかりやすいので、

🐳この記事は「ログラスサマーアドベントカレンダー2023」の28日目の記事です。 次はデザイナーチームの高瀬さんです。 こんにちは、ログラスの松岡です。 ログラスのプロダクトチームでは、ドメイン駆動設計とアジャイルプラクティス（スクラム、エクストリームプログラミング等）を併用していました。 その中で、「アジャイル・フルーエンシーモデル」(以下、省略時には「フルーエンシーモデル」と表記)という概念が多くのプラクティスを取りまとめ、全体感を把握してチームの成長余地を考えるのに役立つものなので、この記事で紹介したいと思います。 アジャイル・フルーエンシーモデルの面白いポイント 面白いポイントはいくつもあるのですが、この記事で紹介するポイントは二つあります。 ポイント①: 技術的負債への対策が組み込まれている 一つは、「技術的卓越性によってアジャイルの持続可能性(サステナビリティ)を高めるという

はじめに みなさん、DBをバージョンアップして酷い目にあったことありますよね？ 先日ログラスの本番データベースのバージョンアップをしたのですが、Site Reliability Engineeringの観点で非常に良いトライが出来たので共有します。 PostgreSQLのロジカルレプリケーションを使って、データを最新に保った新旧のインスタンスを用意した。結果的に安心安全にバージョンアップ作業ができました。 データベースのバージョンアップはサービス運用やっていくと絶対にやらないといけない作業ですが、影響範囲は甚大です。この記事では工夫することで、何か問題が起こってもすぐに切り戻すことが出来るという話をします。 このメンテを通じて、ログラスで利用していたAurora PostgreSQLをエンジンバージョン11.19（PG11）から15.2（PG15）にバージョンアップしました。 バージョンア

本記事は株式会社ログラス Productチーム Advent Calendar 2022の20日目の記事になります。 昨日はtkamaiさんのto B SaaS企業を2社経験して感じた、プロダクトマネージャーに大切なことでした。 はじめに 昨今、開発生産性や開発者体験、Four Keys(DORA Metrics)にDeveloper Productivity Engineering(DPE)などの言葉を耳にする機会が少しづつ増えてきたように思います。 生産性可視化・改善の動きは弊社でも強まってきており、先月11月からログラス開発組織初のnot フィーチャーチーム、チームトポロジーで言う所のイネーブルメントチームが誕生しました。 私は上述のイネーブルメントチームの中で、特に開発生産性・体験の向上を役割として持つことになったため、開発生産性は個人的にもホットトピックです。 様々な企業の取り組

はじめに 最近スパイスカレーを食べるのはもちろん、作るのにもハマっている小林(@mako-makok)です。 近所のお気に入りのお店の閉店が決まってしまい、悲しみに暮れていますが頑張ってアドカレの記事を書きました。 この記事は株式会社ログラスProductチームの2022年12/18(日)の記事です。 株式会社ログラス Product チーム のカレンダー | Advent Calendar 2022 - Qiita なぜ今更Gradleかというと、最近社内で構築しているSheetlinというライブラリがあります。 ニッチな話になりますが、Sheetlin のインターフェース設計に関する話をKotlin Fest Reject Conference 2022でしてきたので、よろしければこちらもご覧ください。 そんなSheetlinですが、ビルドツールはGradleを利用しています。 私も雰

2022 年 7 月から株式会社ログラスに業務委託として関わっている近藤です。 ログラスではスクラムによる開発体制を採用しています。この数ヶ月でスクラムイベントの 1 つであるスプリント・レトロスペクティブ（ふりかえり）の改善に取り組みました。この記事では主に次の対象者向けに、改善した内容について紹介します。 スクラムに取り組んでいる人 ふりかえりのやり方、効果に悩んでいて、改善したい人 ファシリテーションに興味がある人 ※ 以下、記事中ではレトロスペクティブのことを省略してレトロと呼びます。 経緯 改善前、レトロでは Miro を使った KPT[1] を次の流れで行っていました。 スプリントで完了したチケットの確認（Jira の Backlog 確認） KPT 作成の非同期ワーク[2]（以下、KPT ワークと呼びます） 各参加者が KPT 内容を発表 付箋のグルーピング Try について

はじめに フロントエンドのテスト手法の 1 つに Visual Regression Testing（以下、VRT）があります。 これは、アプリケーションの画面を画像として保存し、画像の差分比較をすることで意図せぬ変更が生じていないかテストする方法です。 ここ数年で広く普及し、用語としても一般的になったように思います。 私も以前、とある OSS に reg-suit & Storycap を使った VRT を導入したことがあるのですが、その後もいくつか VRT のためのライブラリが登場したもののキャッチアップできていませんでした。 そこで今回は知識のアップデートを目的として、ここ最近登場した（と思われる）VRT のライブラリをいくつかご紹介します。 なお、今回紹介するツールはすべてこちらのリポジトリで試しています。 具体的な設定ファイルや動作結果を確認できるようになっていますので、ご興味が

ログラスエンジニアの村本です。 この記事では、ログラスのスクラムチームで取り組んだ改善事例をご紹介しようと思います。 改善事例を紹介しようと思ったキッカケは、2022年8月から私の所属チームのチームリーダーがEMに昇格し、私がチームリーダーになったことです。 チームリーダーになったことで、これまであまり意識してこなかったチームの成果を最大化する方法を考える機会が生まれました。 そして様々な改善アプローチをスピード感を持って試すことで、効果を実感できた改善もいくつか生まれ、チームがどんどん良くなっていくという素晴らしい経験ができました。 この記事では、効果を実感できた改善の中で特に印象的だった7つをご紹介しようと思います。 この記事を通して、スクラムをやりたいと考えている方や、スクラム開発をやっていて課題感を感じている方、ログラスに少しでもご興味がある方のご参考になれば幸いです。 2022年

株式会社ログラス　エンジニアの山﨑（@zaki___yama）です。 ログラスではフロントエンドエンジニアとしてプロダクト開発を担当する傍ら、CRE（Customer Reliability Engineer）というロールも兼務しており、業務時間のうち一定割合をこの CRE としての活動に充てています。 本日はこの CRE というロールを立ち上げた経緯と、立ち上げにあたり具体的にどんなことをやってきたのか、そして今後取り組みたいことを紹介します。 CRE 立ち上げの経緯 ログラスにおいてカスタマーサクセスは非常に重要な要素です。 ログラスが扱う「経営管理」という領域は非常に複雑なドメイン知識が求められます。弊社のカスタマーサクセス（CS）チームには、元々お客様と同じ経営企画業務を経験していた者も多く、単なるプロダクトの使い方にとどまらずお客様の業務に踏み込んだ支援を可能にしています。経営企

皆さんこんにちは！ 最近、猫様をお迎えし最高な毎日を過ごしていております、塩対応のしおりん（@jamgodtree）です。 はじめに 私はログラスのエンジニアチームにて、2022年8月からリーダーを半年経験してきました。 この記事では、チームパフォーマンスの最大化に向けて行動してきたこと・失敗談について書いていきます。 タイトルにもあるように、私は受身気質であり、先頭を走っていくタイプのリーダーではありません。 その上で、以下のような悩みがある方に読んでもらえると幸いです。 リーダーになる前に何をやったらいいのかわからない人 リーダーになりたてでどうしようか同じように悩んでいる人 また、ログラスに興味がある方も是非参考にしてみてください。 ログラスにおけるリーダーとは? ログラスにおいてリーダーは　「役割」　として定義されています。 「上司」と「部下」ではなく、フラットな関係性を指している