この記事は毎週必ず記事がでるテックブログ "Loglass Tech Blog Sprint"の25週目の記事です！ 1年間連続達成まで 残り28週 となりました！ こんにちは。ログラスのLLMチームでソフトウェアエンジニアをしているr-kagayaです。 LLMを使ったアプリケーション・機能を作りたいとなったらいくつかのライブラリ選択肢があります。代表例はLangChainでしょう。 最近はオブザーバリティツールとしてLangSmithが登場するなど、LLMシステムを構築する上で必要・便利なモジュールの網羅が進み、LLMアプリ開発のデファクトに向かって爆進しています。 プロダクションで使うことに批判的な声もありましたが、最近はver0.1(それでも0.1ですが)に到達。 LangChain、LangChain Community、LangChain Coreに切り出され、LangSmit

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

この記事は毎週必ず記事がでるテックブログ "Loglass Tech Blog Sprint"の22週目の記事です！ 1年間連続達成まで 残り 31 週 となりました！ はじめに こんにちは、株式会社ログラスでエンジニアをやっています、Kyosukeです。 早いもので、私がログラスに入社してもうすぐ3ヶ月になります。 今回は、入社3ヶ月の節目に、自分とチームの成長のために行った取り組みについて紹介したいと思います。 TL;DR 入社3ヶ月目を迎えて、成果を出せていないことや、自分の成長に対して不安を感じていました。 その原因として、Feed forward の不足を感じ、自分から積極的にそれを求める行動を起こしました。 上記の行動を通じて、成果が出ていないと感じる原因や、自己評価と他者評価のギャップ、より伸ばしていくべき部分を認識し、具体的な改善案を立てることができました。 この取り組みは

この記事は毎週必ず記事がでるテックブログ "Loglass Tech Blog Sprint" の 21週目の記事です！ 1年間連続達成まで 残り 32 週 となりました！ はじめに 明けましておめでとうございます、ログラスでエンジニアをしております南部です。 さて唐突ですが、ログラスでは大まかに以下のようなテストの作成と実施がされています。 JUnitで作成された単体テスト・結合テスト 実際にプロダクトを触ってのE2Eテスト 後者のE2Eテストは、ユーザー目線でのテストができると言う点で非常に価値のあるテストです。 一方で、実施にあたっては非常にコストがかかります。 特に直近では、そのコストは開発作業を圧迫しかねないほど大きくなりつつあると認識しています。 そこで、E2Eテスト自動化を各開発チームが行える基盤を整え始めました。 まだまだ道半ばですが、単体テストや結合テストと同様に組織に定

この記事は毎週必ず記事が出るテックブログ "Loglass Tech Blog Sprint" の 20 週目の記事です！ 1 年間連続達成まで 残り 33 週 となりました！ 明けましたね。今年もよろしくお願いします！ ログラスでエンジニアをしている塩谷 @shioyang です。 "Loglass Tech Blog Sprint" 20 週目の記事をお届けします！！！ 今年の干支は「辰」ですね。辰は変化と成長の象徴です。 進化し続ける Web アプリ開発にとっても大きな変化と成長の年になるのではないでしょうか。 昨年 12 月 5 日、Meta Platforms, Inc. から新しい CSS-in-JS ライブラリの StyleX がオープンソースとして公開されました[1]。大規模なアプリケーション、再利用可能なコンポーネントライブラリ、静的型付けされたコードベースなどの要件を満

こんにちはこんばんわ、ログラスで開発のあれやこれやをしているknih（Kenichi Suzuki）です。 クリスマスいかがお過ごしでしょうか？本稿はログラスのプロダクトアドベントカレンダー最終日の投稿になります。 さて、強い組織であるためには情報の伝導率が重要です。意思決定をするにしても現状がどうなっているのか、決定されたことがどうなったのか、情報が錯綜して見通しが立たない状況では何をするにしても動きが悪くなってしまうでしょう。 ソフトウェアも同じく、型の伝導率が重要です。型を無理やり剥がしていては、リファクタリングするときの正確性が損なわれて、改修を重ねるたびにいつの間にか品質が落ちてしまいます。 高信頼で安全、それでいて簡潔で認知負荷の低い、すなわち複雑性に立ち向かえるソフトウェアを作っていくためにはどうしたらよいでしょうか。そのヒントになるやもしれないと、私が近年注目しているFli

背景 現在ログラスでは、スクラムで開発を行っています。（私の所属するチームでは） 2023年11月~スクラムマスター（以下SM）の方が新しく自分のチームに参画したので、参画前後でどうチームが変わったのか紹介したいと思います。 チーム構成 前提知識としてチームの構成を紹介します。 チームは以下のメンバーで構成されています。エンジニアはデリバリーだけでなく、PdM・デザイナーと協力してディスカバリーも行うのが特徴です。 エンジニア正社員2名 エンジニア業務委託2名 PdM1名 デザイナー1名 SM参画前の開発 SM参画前までは1日スプリントに近い形で開発を行っていました。デイリースクラムで1日のやることを決め、それに向かいベストエフォートで各々進めていくスタイルです。プランニングは必要に応じて都度行う形としていました。 元々は1週間スプリントで開発をしていたのですが、不確実性の高い開発をチーム

はじめに ここ一年でGitHub Copilotはかなり浸透し、Cursorなどの開発者向けのLLM（Large Language Models）ツールの利用も増えてきていることを実感します。 下記の通り、Copilotによって多くのコードが生成される時代となりました。 GitHub Copilotは改善され続けている。2022年6月にこのツールが初めて個人向けに提供されたとき、開発者のコードの27％以上が平均してGitHub Copilotによって生成されたものだった。現在では、この数字はすべてのプログラミング言語で46%に達し、Javaでは61%に跳ね上がっている。 https://github.blog/2023-05-09-how-companies-are-boosting-productivity-with-generative-ai/ CopilotやCursorも便利で愛用

はじめに こんにちは、ログラスの小林(@mako-makok)です！ 昨日は@asa_kossyさんの「ログラスのプロダクトマネージャーチームが今年取り組んだこと、いま苦労していること 2023」でした。 ログラス社はありがたいことに、 CTO 協会主催の「開発者体験が良い」イメージのある企業で 25 位にランクインさせていただいております。 この結果は非常に光栄だと思っており、自分が想像する要因としては DDD、スクラム、技術的投資の 3 点だと思っています。 これらは継続的に活動しています。 ライブラリバージョンアップは欠かさずやりますし、DDD に関しては社内で DDD という言葉はもうほぼ使われていないレベルで浸透しており、機能追加の際はドメインエキスパートと会話つつ、モデルと実装を行き来して開発しております。 この認知は非常に嬉しい結果ではありますが、実際は開発者体験に課題を感じ

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

はじめに こんにちは！10 月から株式会社ログラスでエンジニアをやっています、Kyosuke です！ ログラスでは、エクセルファイルをプログラムから操作する処理が一部存在しており、Apache POIというライブラリを使用しています。（以後POIと呼びます） しかし、POI には処理方式によってはメモリを多量に使用してしまうという問題があります。 今回はその対応として、まずエクセルファイルの読み込みをFastExcelというライブラリに置き換えた話を振り返っていきます。 TL;DR POIのXSSFWorkbookは、ファイルをメモリ内に読み込んで操作するため、大きなエクセルファイルを処理する際にファイルサイズ以上のメモリを必要とすることがある POI の公式ドキュメントより FastExcelは、POIより機能は劣る代わりに、読み書きともにパフォーマンスは大幅に上回る 書き込み Fast

はじめに 株式会社ログラスでエンジニアリングマネージャー(EM)をしているよしだです。 実は11月からEMになりました。キャリアとしてEMになぜなると決めたか？という記事をあまり見たことがないのでEMになるか悩んでいる方のために、私がEMになるまでに歩んだ道を書こうと思います。 ログラスに入る前の私のキャリアにおけるマネージャー経験は2回あります。それらは「マネージャーやりたい！」と自らの明確な意志でやるのではなくて「自分の技術力の限界が見えたので、とりあえずマネージャーやってみよう」というキャリアの選択として、とても曖昧な状態でした。 ただ、そのマネージャー経験の中でEMに興味を持ったきっかけがあり、そのきっかけから実際にアクションをしEMになろうと思いました。それらEMになるまでの変遷をまとめ、これからのキャリアとしてEMを考えている方への参考の一例になれば幸いです。 記事の想定読者

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

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

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

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

この記事は毎週必ず記事がでるテックブログ "Loglass Tech Blog Sprint" の 15 週目の記事です！ 1 年間連続達成まで 残り 38 週 となりました！ はじめに ログラスでエンジニアをしているよしだといいます。SNSではお酒中心の生活を日々過ごしています。 いきなりですがみなさん、スプリントゴール立ててますか？立てていたら、ゴールの立て方で悩んでいたりしませんか？今回は私が所属しているチームでスプリントゴールに川柳を導入してみてスプリントゴールとしてより良いものが出来た話をしようと思います。 そもそもスプリントゴールとは 詳細に書くとそれだけで一つの記事になりますので、ここではスクラムガイドの中でのスプリントゴールの定義を転記します。 スプリントゴールはスプリントの唯⼀の⽬的である。スプリントゴールは開発者が確約するものだが、スプリントゴールを達成するために必要と

輪読会、してますか？ こんにちは。ログラスのQAをしています、コタツと申します。普段はnoteやXで発信しています。 このたびテックでもなんでも無い私がテックブログにお誘いいただき、何の話ができるかな〜と思って出てきたのはこの「輪読会」というネタでした。 ログラスでは、直近1年ちょいでこんな本を開発チーム全体で輪読しました。 （以下アジャイルテスト本と呼びます） （以下単体テスト本と呼びます） おかげで、開発チーム内でのQAの役割についてや、具体的な取り組みについての理解が格段にアップし、チームの品質に対するステージ（？）が1段上がった感覚がありました。私が主催した輪読会は前者のアジャイルテスト本のみですが、この少ない経験の中から、輪読会を開催したい！と思っている誰かのためになりそうなノウハウを書いていきたいなと思います。 また、「どんな本を読んだらいいか？」についてはこの記事では取り扱い

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

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