はてなブックマーク

こんにちは、稲垣です。 2025年4月から、プロダクトデザインの組織とプロダクトマネージャーの組織が、同じ「プロダクト部」という部門に統合されたのを受けて 「プロダクト部はじめました」を書きましたが、あれから半年経ちましたので、続編を書きます。 10月より副部長から部長となりました。 まずは改めて自己紹介です(キャリア変遷はコチラへ) エンジニアを軸にこれまで20年以上製品ヅクリに携わってきました。PdMはラクスに入ってから名乗るようになり、デザイナーはファッションECサービスの時に一時的にマネージャー不在の時があり、その時に直接マネジメントをしていました。 （この時には新卒のデザイナー採用課題レビューやスカウトでデザイナーのマネージャーを採用してたりしました） 基本的なプロダクト部の紹介は「プロダクト部はじめました」に書きましたので、今回はスキップし、あれから6ヶ月に経って どう変化や進

2025年、AI技術は新たなフェーズに突入しました。特に、自律的にタスクを計画・実行する「AIエージェント」の登場は、ソフトウェア開発の世界に大きなインパクトを与えています。私たちラクスでも、この技術革新の波を捉え、自社サービスを進化させるべく、社内のR&D活動「技術推進プロジェクト」にて「垂直型AIエージェント」の調査・研究に取り組みました。 申し遅れました、普段は技術広報を担当しているkawa3です。今回は久々にR&D活動を通じてエンジニア業務を担当しました。楽しかったです！ 本記事では、その成果発表の内容をもとに、AIエージェントの基本からSaaSへの応用可能性、そしてPoC（概念実証）を通じて見えてきたリアルな課題と解決策までを簡潔にご紹介します。 この記事を通して、垂直型AIエージェントの技術的な面白さをお伝えするとともに、ラクスがどのように技術のキャッチアップと社内へのナレッジ

こんにちは、開発推進部 SRE課のimamotoです。 SRE課ではSlackを使ってアラートを通知しているのですが、 今回はそのアラートを確認する運用を自動化してGitHub上で運用を完結させた話をしたいと思います。 これまでのアラート確認運用について 運用の流れ 解決したかった困りごと ①見落とし・対応漏れのリスク ②手順書作成コスト ③見るべきツールが多い ④横展開の必要性 改善方針：GitHub Actionsを活用したアラート確認運用の自動化 1. GitHub ActionsによるSlackメッセージの自動分類 Slack Alert Analyzerの機能 作成されたIssue例 2. 未知のアラートのRunbookを自動作成 Issueテンプレート Pull Request 3. 対応完了処理 Slack Alert Resolverの機能 他チームへの横展開：Reusab

ラクスでメールディーラーのUIUXデザインを担当しているたけしまです。 AIを活用した製品づくりに向け、上流工程から参画し、日々業務に取り組んでいます。最近では、社内でも業務効率化やナレッジの蓄積、雑務の処理などにAIを活用するようになってきました。 顧客ヒアリングの情報を収集・分析する際にもAIを活用していますが、顧客の声が蓄積されるにつれ、顧客から見たAIがどんな存在で、何を期待しているのかが少しずつ見えてきました。今回は、その気づきをデザイナー視点のAIの価値と併せてご紹介したいと思います。 顧客視点 業務変革のパートナー 5つの価値的変化 6つの役割イメージ デザイナー視点 新たなUX設計の可能性 1. 製品のUX向上 2. 広く深い顧客理解 3. UI設計と業務効率化 顧客視点とデザイナー視点の比較 まとめ 最後に 顧客視点 業務変革のパートナー 顧客企業にとってAIは、単なる便

はじめに こんにちは！楽楽勤怠開発チームのoo_yoshiです。 勤怠管理システムは「打刻して残業時間や休暇を計算すれば終わり」と思われがちです。しかし、実際にシステムを開発・運用してみると、その裏には複雑なルールと例外が山ほど存在します。 勤務体系は企業ごとに違い、法律や就業規則も定期的に改正されます。有休の付与や消化ルール、代休や振休の扱い、残業の丸め処理など、ひとつひとつのルールが微妙に違い、組み合わせると膨大なパターンになります。 私たちのチームでは、そうした複雑さに対応するために9年前にDDD（ドメイン駆動設計）を採用し、勤怠システムをリニューアルしました。本記事では、その9年間で感じたこと、分かったことを振り返りたいと思います。 はじめに 旧勤怠管理システムで直面した課題 リニューアル時にDDDを導入して変わったこと 属人化の解消 9年経って実感したDDDの価値 まとめ 旧勤怠

目次： はじめに 前提知識 当時の課題 実施した改善策 結果 その他 まとめ はじめに こんにちは。今年に入って2ヶ月に1回以上K-POPなどのライブに行っている、楽楽債権管理開発チームの冨澤です。 楽楽債権管理は新サービスとして2025年7月1日から販売を開始した、ラクスの中では比較的新しいサービスであり、高速に開発することが求められます。 本記事ではそんな高速開発を支える取り組みとして、CIのテスト実行時間を短縮した話をご紹介したいと思います。 前提知識 本記事での取り組みでは、以下の内容を前提としています。 対応時期 2025年3月 技術スタック 言語 Java 21 FW Spring Boot 3 テストツール Spock ビルドツール Gradle（Groovy） CI GitHub Actions アーキテクチャ オニオンアーキテクチャ 1つのGradleプロジェクトで管理し

はじめに AI関連の話題 AI活用状況のスナップショット うまくいっていること オンボーディング支援 コードリーディングの支援 ボイラープレートの自動生成 単純で広範な一括修正の自動化 AIによるプルリクの一次レビュー うまくいかなかったこと（限界と落とし穴） 自立型コードエージェントによる実装 非決定性（出力の揺らぎ） コンテキスト忘却 Kotlin×IDEロックイン問題 学んだこと まとめ 参考文献 はじめに 楽楽請求開発チームのkyoshimotoです。 バックエンド開発チームに所属し、開発チームをスケールさせるための開発プロセス整備、チーム内でのAI活用の推進を担当しています。 本記事では、現時点のAI活用状況や、うまくいっている点・うまくいっていない点、学んだことを共有します。 AI関連の話題 AI活用に関する期待を一段と高める話題が増えています。代表例を挙げます。 Anthro

はじめに こんにちは。楽楽請求でバックエンド開発を担当しているmarumoです。 楽楽請求は2024年10月にサービスを開始した新サービスで、請求書を一元管理し、経理業務を効率化する請求書受領システムです。 その中で、請求書の内容をデータ化するために OCR エンジンの API を活用し、自動データ化機能を提供しています。 請求書の自動データ化は、楽楽請求の中核を担う機能です。 サービスの価値を支えるこの仕組みを安定かつ効率的に動作させるためには、大量の請求書を迅速に処理できることが欠かせません。 大量の請求書を確実に捌くため、OCR エンジンの API 呼び出し処理は高並列化を前提に構築しました。 しかし、高並列処理の負荷検証中に「CPU やメモリは安定しているのに、スレッド数だけが増え続ける」という現象に遭遇しました。 本記事では、その原因をどのように特定し、どのように解決したのかを紹

はじめに こんにちは。メールディーラーAI開発課のmarronです。エンジニアブログ初投稿となります。よろしくお願いします。 私が所属しているメールディーラーAI開発課では、主にメールディーラーに搭載されるAI機能の開発を担当しています。 現在は10月にリリース予定の回答自動生成エージェントの開発を進めています。 この機能を開発するにあたって、新たにベクトルDBを利用したナレッジの検索機能が必要となりました。 本記事では、ベクトルDBでの検索精度を上げるために導入したハイブリッド検索についてご紹介します。 はじめに ベクトルDBの選定 ベクトルDBとは メールディーラーで採用したベクトルDB 密ベクトルを用いた検索 Qdrantでの密ベクトル検索 密ベクトル検索の欠点 疎ベクトルを用いた検索 疎ベクトルとは Qdrantでの疎ベクトル検索 両方の検索結果を組み合わせるハイブリッド検索 密ベ

はじめに こんにちは。楽楽明細開発チームのtkktです。 楽楽明細は2013年のサービス開始以来、10年以上の運用を続け、現在では1万を超えるお客様にご利用いただいています。 しかし、この成長の裏側では、長年の機能追加や複雑化による技術的負債が蓄積し、 新機能追加のたびに調査やテスト工数が増大するなど、サービスの成長スピードを阻害する課題に直面していました。 今回は、その課題を乗り越えるために取り組んだシステム刷新の一部をお話ししたいと思います。 目次 刷新の背景 実際の取り組み リリース後の課題と改善 成果と効果 今後の展望 まとめ 刷新の背景 長年の運用により、システムには以下のような課題が生じていました。 古いフレームワーク利用によるリスク サポート終了が迫り、セキュリティリスクが高まっていた 周辺のミドルウェアやライブラリのバージョンアップも妨げられていた 開発効率の低下 度重なる

こんにちは、株式会社ラクスでデザイナーをしているかっつです。 今回は私が所属しているプロダクトデザイン3課でデザインレビューを始めることになった話をご紹介します。 デザインレビューをする文化がなかったところからなぜ始めることになったのか、 上手く行っていること・行かなかったことなどお話しします。 これからデザインレビューをチーム内で始めようとしている方の参考になれば嬉しいです。 1. デザインレビューを始めるきっかけ 2. どう始めたか いきなりレビューではなく、まず輪読会から レビュー用フォーマットの導入 3. 上手くいったこと 議論が建設的になった 副次的にチームの課題を解決できた 4. 課題とこれから 5. まとめ 1. デザインレビューを始めるきっかけ ラクスのデザイナーはそれぞれが担当するプロダクトを持ち、デザインを進めています。 その状況もあり、プロダクトをまたいだレビューの機

こんにちは。40代インフラエンジニアのAと申します。 今回は今さらながら、Kubernetesを勉強し始めたエンジニアのポエムになります。 あまり技術的な内容はありませんがご容赦ください。 経歴 手作業のインフラの時代 新しい時代の幕開け、そして焦り 重い腰を上げ下げしてようやくKubernetesへ 金はかけるがコスト感をもつ （参考）AWSのマニュアルにあるゲーム（2048）をデプロイしてみる 難しく考えず、実は根本はあまりかわらないよ おわりに 経歴 私はエンジニア歴20年以上の世間では「ベテラン」といわれるインフラエンジニアで 経歴としてはSIerでOSインストールや機器設定を現場でがむしゃらにこなす所から始まり、 SaaS業界で運用を経て、昨今はオンプレ機器の導入・設計をリードする立場で働いてまいりました。 また、現在の会社は在籍年数も10年以上と長く、何やらベテラン臭のする、

こんにちは！！ラクス技術広報担当です。 2025年8月7日(木)に、オンラインにて「RAKUS Tech Conference 2025」を開催いたしました。平日にもかかわらず、多くの皆様にご参加いただき、大盛況のうちに幕を閉じることができました。登壇者、関係者の皆様、そして何よりご視聴いただいた皆様に、心より感謝申し上げます。 本イベントの開催目的は、私たちラクス開発本部が最も大切にしている「顧客志向」という概念を多くの方に知ってもらうことでした。参加後アンケートの結果から、9割の視聴者の方に「ラクスが顧客志向な開発組織であるという印象が伝わった」という回答をいただき、イベントの目的が果たせたことは大変良かったと思います。 各セッションでは、ラクスのサービスが日々どのように顧客と向き合い、その価値を技術で実現しているのか、7つのセッションを通じて開発の裏側にある「強み」や「想い」をお届け

はじめに こんにちは。新卒3年目のymyhero7です。 メールディーラーという自社開発プロダクトの開発チームに所属しています。 入社してすぐの頃は、実装やテストの工程を担当していましたが、新卒2年目から徐々に要件定義を任されるようになりました。もともと就職活動の面接段階から、「どうすればお客様にとって本当に価値のある機能を作れるか」といった上流工程への関心が強く、そうした業務に携わることを希望していました。 そのため、2年目という比較的早い段階から要件定義に関われるようになったときは、非常に嬉しかったのを覚えています！ しかし、意気揚々と始めた要件定義の業務は、想像以上に難しく、苦労の連続でした。作成した要件定義書はレビューで指摘を受けることが多く、大幅な手戻りが発生してしまうことがしばしばありました。 本記事では、そうした経験を通じて学んだ要件定義の進め方のコツや「顧客理解」の重要性を

はじめに こんにちは。フロントエンド開発課でチームリーダーをしています、北嶋です。 私が所属する開発部では、開発の「スピードUP」と「生産性の向上」を今年度の大きなテーマとして掲げています。 そこに向けて、私のチームでは開発プロセスの中でAI活用を実践していく「AI駆動開発」を推進することに、積極的に取り組んでいます。 本記事では、今年度から本格的にAI活用に取り組み始めた私たちが、どのようにAI活用を進めて、どのような成果や学びを得たのか、具体的な事例を交えながらご紹介できればと思います。 まだまだ発展途上ではありますが、私たちが実践してきた取り組みが、開発業務でAI活用をしていきたい方への、何かヒントになれば幸いです。 はじめに どのようにAI駆動開発を進めてきたか ステップ1：KPIの設定 ステップ2：個人での利用とアイデアの共有 ステップ3：チームでの標準化 例①：DevinのAP

自己紹介 こんにちは、株式会社ラクスでプロダクトマネージャー(以下PdM)をしている柴と申します。 楽楽精算のPdMを経て、現在は楽楽精算モバイルアプリ・楽楽明細・楽楽債権管理・AIリーン開発と複数のプロダクトでPdMを担当しています。 （PdM積極採用中です！！） 今回はPdMという役割を経験して私が感じてきたことを記事にしてみます。 PdMを目指している方やPdMという役割にもやもやしている方の参考になると幸いです。 はじめに 「隣の芝が青く見える」——この言葉が、私のPdMキャリアの最初の数年間を象徴していました。 SNSで目にする「戦略を描くPdM像」、イベントで語られる「PMFを達成したPdMの話」、そして「経営に貢献するPdM」の事例。 それらと比較して、私は「自分のやっていることは、本当にプロダクトマネジメントと言えるのだろうか？」と疑問を持っていました。 そんな中でも派手で

こんにちは、フロントエンド推進課の水野です。 普段はWebフロントエンド領域を中心に、商材開発や技術支援、開発改善に携わっています。 自動化・標準化、開発プロセスの変遷に関心があり、作るものだけではなくその過程や運用設計を意識して取り組んでいます。 note.com 最近、自分の中でコードレビューのやり方が変わったなと感じています。 GitHub CopilotやClaude Codeのようなツールが当たり前になり、構文エラーやコーディング規約のチェック、命名規則の統一のような作業はほぼ自動化できてしまいます。 成果物の出てくるスピードと規模感も桁違いで、レビューだけで1日が溶ける日もたまにあります。 その中で、改めて「自分は何をレビューすればいいんだろう」「コード以外に見るべきものはなんだろう」と考えることが増えました。 個人的にコードレビューや開発現場に関する話が好きで、ブームが再燃し

自己紹介 ラクスでPdMをしております。@keeeey_mと申します。 現在の担当商材は、楽楽シリーズ(楽楽精算、楽楽明細、楽楽電子保存、楽楽債権管理)を担当しており、個人としては楽楽精算×AIの担当、楽楽明細・楽楽電子保存・楽楽債権管理PdMチームのリーダーをしております。 はじめに 前回までの記事では、ジョブ理論とノーススターメトリックそれぞれの重要性について詳しく解説しました。第1回では顧客の真のニーズを理解する鍵としてのジョブ理論、第2回では組織全体の方向性を統一する鍵としてのノーススターメトリックについてお伝えしました。 しかし、これらを単独で活用するだけでは、真の事業成長を実現することは困難です。本記事では、ジョブ理論とノーススターメトリックを組み合わせることで生まれる相乗効果についてまとめました。 自己紹介 はじめに 相互補完的な関係 単独での限界 相互補完的な役割 相乗効果

はじめに 私たちのモバイルアプリ(Android／iOS)開発チームでは、2024年頃から段階的にAIツールを導入し、開発プロセスの改善に取り組んできました。プロセス改善とチーム体制の強化も相まって、PR作成数などの指標で大幅な改善を実現しています。 本記事では、私たちがどのようにAIツールを活用して開発効率を向上させているか、具体的な取り組みをご紹介します。 はじめに 生成AI活用の文化づくり 生成AI情報共有会の開催 多様なAIツールの活用 独自MCPサーバーによる開発環境の革新 MCPとは 1. GoogleDrive MCP 2. Redmine MCP 3. 検証環境 MCP 4. GitHub PR/Issue MCP 5. Figma MCP 6. ファイル編集 MCP 具体的な活用事例 開発プロセス全体での活用 ナレッジの蓄積と共有 導入効果の測定 PR作成数の推移（1日あ

自己紹介 ラクスでPdMをしております。@keeeey_mと申します。 現在の担当商材は、楽楽シリーズ(楽楽精算、楽楽明細、楽楽電子保存、楽楽債権管理)を担当しており、個人としては楽楽精算×AIの担当、楽楽明細・楽楽電子保存・楽楽債権管理PdMチームのリーダーをしております。 はじめに 前回の記事では、ジョブ理論の重要性について詳しく解説しました。顧客の真の「ジョブ」を理解することの重要性と、それが企業にもたらす競争優位性についてお伝えしました。 しかし、顧客の真のニーズを理解したとしても、それを組織全体で効果的に追求していくためには、もう一つの重要な要素が必要です。それが「ノーススターメトリック（North Star Metric: NSM）」です。 本記事では、ノーススターメトリックの重要性と、組織全体の方向性を統一する鍵としての役割についてまとめてみました。 自己紹介 はじめに 従来

はじめに こんにちは！ラクスの楽楽精算でプロジェクトマネージャーを務めている@rks_bunです。 最近、YouTubeで「1/3の純情な感情」が流れてきて、中学生〜高校生くらいの時にこの曲を聞いていた私は、これが30年近く前の曲だと知って時の速さに驚きました。一緒に見ていた奥さん（私と同年代）が「30年前？最近じゃん」と言っていて、ちょっと共感しちゃった自分にさらに驚きました。 このように時が経つのは早いもので、私がラクスに転職してから半年が経ちました。 この記事は、ラクスへの転職を迷っている方、特に30代〜40代で転職を考えているPMやエンジニアの方に向けて書いています。 率直に言って、ラクスは良い会社だと思います。でも、当然良いところばかりではありません。この記事では、私の実体験を踏まえて、良いところと悪いところの両方をお伝えします。 はじめに 転職の背景 転職を決意した理由 ラクス

自己紹介 ラクスでPdMをしております。@keeeey_mと申します。 現在の担当商材は、楽楽シリーズ(楽楽精算、楽楽明細、楽楽電子保存、楽楽債権管理)を担当しており、個人としては楽楽精算×AIの担当、楽楽明細・楽楽電子保存・楽楽債権管理PdMチームのリーダーをしております。 はじめに 最近、プロダクト開発の現場で事業成長のための指標設計について考える機会がありました。現代のビジネス環境は、技術革新の加速、市場のグローバル化、そして顧客ニーズの多様化と複雑化により、かつてないほどの速さで変化しています。 このような状況下で、単に優れた製品を開発するだけでは持続的な成長を確保することが困難になっていると感じています。従来のプロダクト開発手法では、往々にして市場の要求や顧客の潜在的な欲求を見誤り、結果としてリソースの無駄や競争力の低下を招くリスクが高まっています。 特に気になるのが、多くの企業

1. はじめに こんにちは！配配メール開発チームのos188です。 今回は、長年動き続けてきたレガシーシステムに向き合い、現実的なリファクタリングに挑戦した事例をご紹介します。 1. はじめに なぜリファクタリングに踏み切ったのか？ 2. リファクタリング方針と技術選定 既存システムの構成 リファクタリングの主な方針 3. 実践！レガシーコードをモダンに生まれ変わらせるステップ ステップ1：既存ソースの徹底把握 ステップ2：新クラス構成とフォルダ構成の検討 ステップ3：ドメインモデル設計・実装 ステップ4：実装 ステップ5：E2Eテスト・リグレッションテスト 4. 数値で見る劇的改善！PhpMetricsとPHPUnitカバレッジが語る真実 PhpMetricsで見る静的解析と構造変化 PHPUnitカバレッジで見るテスト品質の変化 内部品質の総評 5. 肌感覚で実感する変化 6. まとめ

mixedbread-ai/ Alibaba-NLP / OpenAI GPTによるリランキング【実装サンプル付き】 はじめに RAGをはじめとする現代の情報検索システムでは、「リランカー（Reranker）」と呼ばれる仕組みが使われることがあります。 検索候補を単にキーワードマッチやベクトル検索でピックアップするだけでなく、さらに高精度なモデル(＝リランカー)で再スコアリング（再ランキング）することで、ユーザーが本当に求めている情報を上位に表示できます。 本記事では、筆者が実際に業務中の検証作業で利用した次の3つのモデル: mixedbread-ai/mxbai-rerank-v2 Alibaba-NLP/gte-multilingual OpenAIのGPT（Chatモデルをリランカーとして活用） を題材に、特徴や実装例を紹介します。 mixedbread-ai/ Alibaba-NL

先日、株式会社ラクス主催の技術イベント「RAKUS AI Meetup」がオンラインで開催されました。本イベントは、ラクスのAI技術への取り組みや活用事例を社外の方々にも広く知っていただくことを目的としており、当日は多くの方にご視聴いただきました！！ 「楽楽精算」「メールディーラー」といった主力サービスへのAI機能組み込みの裏側から、開発本部全体でのAIツール活用による生産性向上まで、3つの具体的なセッションを通して、ラクスのAI開発のリアルが語られました。 本記事では、各セッションの模様をダイジェストでお届けします！ （記事執筆は当イベントの司会も担当しました、技術広報の川東がお届けいたします） セッション1：AIは精算業務をどう変える？自律型エージェントが実現する未来のワークフロー セッション2：メールディーラーにおけるAI活用事例～クレーム検知機能リリースの舞台裏～ セッション3：自

はじめに：1年後の私たち――進化の軌跡と、ささやかな告白 第1章：グローバル開発モデルの進化――オフショア開発とAIの幸福な出会い 1.1 旧来の認識 vs 現代の現実：オフショア開発の再定義 1.2 中核となるアナロジー：優れたオフショア開発プラクティスは、優れたAIプラクティスである 1.3 AIによる認知負荷の軽減とスキルの平準化：言葉の壁を越える力 1.4 代替不可能な「ヒューマン・イン・ザ・ループ」：AIの限界と人間の価値 第2章：絵に描いた餅で終わらせない――現場起点のAI活用、その道のり 2.1 「なぜやるのか？」から始めるデータ駆動アプローチ 2.2 活用のための足場作りと血の通ったフィードバックループ 第3章：チームトポロジーの加速――自律する現場が生んだ「イネイブリングチーム」の新たな使命 3.1 理論から現実へ：私たちの進化の可視化 3.2 ストリームアラインドチーム

開発組織の価値観は、社内にあるだけでは届きません。 定義や行動指針を掲げても、それだけで伝わるわけではない。 むしろ、「なぜ、行動したのか？」「どう意思決定しているのか？」という現場の声こそが、その組織の“らしさ”を表すものだと思います。 私たちラクスは、創業以来大切にしてきた「顧客志向」の価値観を、外部に伝える活動に本格的に取り組んでいます。 本記事では、ラクスの開発組織がどのように情報発信と向き合い、今のかたちにたどり着いたのか。その背景にある試行錯誤や、ブログ、イベント開催、カンファレンス登壇などの取り組みをご紹介します。 フェーズ①当初の狙いは“認知拡大” フェーズ②「顧客志向」を軸にブランディングへ 情報発信の２つの方向性 １、技術広報による戦略的かつ計画的な情報発信（=組織ブランディング） ２、開発組織による自主的な情報発信（＝文化づくりと学び） 具体的な情報発信活動事例 エン

自己紹介 こんにちは、稲垣です。ラクスの開発組織のプロダクト部 製品管理課の組織のマネージャーをしています。 └ プロダクト部の紹介はコチラ / 製品管理課の紹介はコチラ / 私自身の経歴はコチラ こんな方におすすめ ・自身の提案が上司や必要な人に届いてないと感じてる方 ・AI時代でも廃れない価値を獲得したい方 ・プロダクトマネージャーとして人としての巻き込み力をあげたい方 目次 はじめに AI時代の「言っていること」は差別化できない PdMの武器は「信頼」 どうしたら「信頼」を得ることができるのか？ 「信頼」があるとどうなるか？ 最後に はじめに 若い頃こう思ってました 『自分が言っていること』と『上司が言っていること』と内容はほぼ同じなのに何故？ 自分の意見は採用されず上司が言っていたことが採用されるのか。 自分が一定の立場になったら「誰が」ではなく「何を」言っているかで提案等を採用し