こんにちは、菊池（akikuchi_rks）です。 私の所属するチームではClaude Codeを開発フローに取り入れており、私自身も設計書のレビューや定型調査の自動化など、さまざまな業務でスキル（Agent Skills）を作成してきました。 スキルを書き続けていて特に感じるのは、「とりあえず動くスキル」と「安定して業務に組み込めるスキル」は別物だということです。同じスキルなのに実行のたびに結果の形が変わる、自分は使えるのにチームメンバーが動かすと品質が落ちる、という悩みに心当たりのある方も多いのではないでしょうか。 私はこの差を分けるのは、AIにどう仕事を任せるかをしっかり設計できているか…

こんにちは、技術広報のyayawowoです。 私たち株式会社ラクス開発本部では、Missionである 「顧客の成長を支援する、圧倒的に使いやすいクラウドサービスを創り提供する」 を念頭に、日々プロダクト開発に励んでいます。 現在、ラクスでは歴史あるロングセラーのプロダクトから、近年立ち上がった新規プロダクトまで、多くの開発プロジェクトが並行して動いています。このように古いものから新しいものまで多くのプロダクト開発に深く携われるからこそ、エンジニアやデザイナーが触れられる技術の機会が非常に多い点が、私たちの組織の大きな特徴であり魅力です。 本記事では、各プロダクトの「技術スタック」を改めて整理し…

こんにちは！AIエージェント開発課です。 近年、生成AIの進化スピードは凄まじく、単なるテキストの要約やドラフト生成の枠を超え、自律的に判断してタスクを実行する「AIエージェント」が大きなトレンドとなっています。 このような技術的な潮流の中、私たちのチームは2025年5月に「AIエージェント開発課」として産声を上げました。累計導入社数 約20,000社以上の顧客基盤と、16年以上にわたって蓄積された膨大な業務データ（ドメイン知識）というラクスの強みを活かし、バックオフィス業務の「完全自動化」という未来へ向けて、日々泥臭く開発を続けています。 私たちがメインで取り組んでいるのは、主力プロダクトで…

こんにちは、ラクスでバックエンドエンジニアをしている斉田真也（GitHub: shinya / X: @saita_shinya）と申します。業務のかたわら、Markdownエディタ Bokuchi を個人で開発していて、仕事でも個人開発でも、いまやClaude Codeはすっかり相棒になっています。 先日大阪の梅田で開催された Claude Code Meetup Osaka に参加し、LT枠でも登壇してきました。AIは失敗する。でもその失敗を"使い捨て"にせず記録して次に読ませれば、二度目から同じつまずきを繰り返しにくくなる ── 私が登壇で話したのは、そんな「Claude Codeの育て…

「自分が時間をかけて作った機能、ちゃんと使われていますか？」 エンジニアだったら、たぶん一度は胸の奥に刺さる問いだと思います。仕様書通りに作って、テストも通って、リリースして。でも数か月後にログを見るとあまり利用されていない。そういった経験があるかと思います。 この記事では、冒頭の問いに対して「ちゃんと使われている」と言える機能を開発できた事例を紹介します。AIを活用することで2週間でベータ版提供までこぎつけ、楽楽自動応対の翻訳機能が最終的に「この機能の導入前にはもう戻れない」と顧客に言ってもらえるまでの裏側です。 実際の業務フローをヒアリングすることで機能への解像度を上げた 社内の認識合わせ…

「勉強のため」から「持ち帰るため」に変わった アウトカムを意識するようになった 将来の自分たちが楽になるかどうかで見ている レベル300のセッションが「ちょうどいい」と感じた AI一色、そしてフィジカルAIの存在感 まとめ

1. はじめに この記事で書くこと この記事で書かないこと 前提 2. バージョンアップ作業フロー Step 1：メジャーバージョンアップによる影響調査 Devin の Playbook を作成する Devin の Playbook を実行して一覧化する Step 2：対応が必要かどうかの判断と方針検討 Step 3：更新作業 3. AI 活用の所感 影響度判定の精度評価 良かった点 微妙だった点・反省 4. まとめ 5. 今後の展望 参考文献

はじめに 私が開発ツールに求めることをZedは満たしていた すぐに開けること コードが追いやすいこと 複数画面を上下左右に開けること ディレクトリがツリーで開けること Git関連機能にアクセスしやすいこと VSCode、Ghostty、Zedを比較する Zedの使用感 Zedの微妙なところ ACP経由のエージェント体験はCLIより遅く感じる ファイルパスクリックで開けない VSCode拡張に依存している人は移行しづらい まとめ

まず「測る」ことを設計した 「使わない」には、それぞれの理由があった AI活用は確かに進んだ。でも、浸透しきってはいない 顧客に届けるための、AI活用標準化 今期進める4つの取り組み 「エンジニア非稼働時間帯でも開発が進む」を目指して

はじめに 楽楽シリーズUI統一プロジェクトとは フェーズ1: AIに任せられない領域 フェーズ2: 規模がもたらした新たな課題 AI活用の勘所: 実装ルールをAIに翻訳する なぜ「セルフチェック」だったか Cursor Rulesという仕組み 運用してみての手応え 振り返って見えたパターン 作業の性質とAI活用の相性 AI活用は、人間の作業との連携で成立する おわりに

はじめに 登壇資料 登壇内容 発表の背景 なぜ全部自動化しなかったのか 作成したCLIの概要 半自動設計のポイント 細かいTips LLMに渡す範囲を狭くする 読み取りを自作ツールで行う ツールを絞る Claude Code標準プロンプトは必要な場所だけ使う 登壇してみて まとめ

はじめに JJUG CCCとは 登壇スライド 外部発信のモチベーション 登壇を通じて得られた気付き 振り返り

はじめに 給与計算オプションの開発で最初に困ったこと なぜ開発部だけでなく事業部にも給与計算の知識が必要だったのか まず、初心者向けの課題図書を選んだ MVP開発に必要な知識に絞って、学習コンテンツを作った 仕様説明では、「なぜその機能が必要なのか」まで説明した リリースまで進めるうえで大事だったこと 1. 自分だけが詳しい状態にしない 2. 開発部・事業部が必要な知識を持てるようにする 3. すべてを学ぶのではなく、今回必要な範囲に絞る 4. 仕様の背景や目的まで伝える まとめ

こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） tech-blog.rakus.co.jp 今回は、私が作った「PdMタイプ診断」という取り組みについてご紹介します。 この診断は、既存の性格診断をそのまま用いたものではなく、PdMとしての思考や行動の傾向を整理するために、認知スタイルに関する考え方をヒントに独自に設計したものです。 診断の仕組みと、ラクスの開発組織で実施して見えてきたことをレポートします。 なぜ作ったのか 診断の仕組み：3つの軸、8つのタイプ 軸① コミュニケーション 軸② 価値の方向性 軸③ 志向性 ラクス社内で試してみた…

はじめに 本イベントについて 登壇内容の解説 他の方のLT登壇 まとめ

こんにちは！ラクスのエンジニア採用担当です。 今回はラクスのエンジニア職のサマーインターン「RAKUS Tech Lab」を紹介します。 このインターンシップは、単にコードを書く体験ではありません。 チームで開発を進めながら、「何を作るべきか」から考えるプロセスを体験していただくプログラムです。 ラクスのエンジニアがどのようにプロダクト開発に向き合っているのか。 その一端を、3日間で感じていただけます。 インターンで大切にしている考えや、実際の流れ、参加いただいた方の声を紹介します。 ラクスが大切にしている「顧客志向」 インターンシップ「RAKUS Tech Lab」について 3日間の流れ D…

1. はじめに なぜ改善が必要だったか どんな改善をした？ 2. バージョンアップ運用フロー 2-1. CIによる機械的チェック（GitHub Actions） ①helm templateコマンドによるレンダリングチェック 実装詳細 ②PlutoによるKubernetes API互換性チェック 実装詳細 ③HelmChart展開後のマニフェスト差分把握 実装詳細 2-2. AIによる影響調査 AIレビューコメント例 なぜラベル起動にしたか プロンプト なぜDevinを選定したのか 3. 導入後の効果 4. 今後の展望 5. まとめ 参考文献

こんにちは。SRE課のtaku_76です！ 今回はKubernetesマニフェスト内の非推奨API / 削除済みAPIを継続的に検知する仕組みについて紹介します。 PlutoとGitHub Actionsを使い、定期実行から検出結果の更新まで自動で行うようにしました。 他チームにも使ってもらうことを想定していたため、Plutoを実行するだけでなく導入方法や検知結果の確認方法まで含めて運用に乗せる形にしています。 はじめに 仕組みを作成した目的 全体像 利用者の負担を減らすために工夫したこと Issueを作るだけで管理対象に追加できるようにした 結果確認をIssueに集約した READMEを自動…

はじめに 開発部と事業部では、見ているものが少し違う 開発観点だけで判断を閉じると、議論が進みにくくなる 議論が噛み合わなくなるのは、「必要性」と「実現性」が混ざるとき 要望をそのまま受け取らず、課題として整理する 「やるか・やらないか」ではなく、スコープを分ける 仕様だけでなく、届け方まで含めて考える まとめ

こんにちは、CTOの公手です。 この4月から、ラクスの新しい中期経営計画がスタートしました。 前中期経営計画の5年間、私たちは「ハイグロース」を掲げ、売上・組織規模ともに約4倍という急成長を遂げました。次なる3年で私たちが目指すのは「クオリティグロース（質の高い成長）」です。AIを駆使して組織をより筋肉質に変え、真の意味で「強い」組織へと進化させるフェーズに入ります。 この方針のもと、次の中期経営計画で開発本部が推進する3つのプロダクト戦略と、それを実現するために不可欠な3つの変革について、簡単ではありますが共有できればと思います。

楽楽明細、楽楽電子保存、楽楽債権管理と複数プロダクトのプロダクトマネジメントを担当しています。紀井です。 4月より、この複数プロダクトのプロダクトマネジメントを担う組織の課長に就任しました。所信表明も踏まえて、私がプロダクトマネジメントを意識するようになったきっかけと、今考えていることについてお話しします。 「Whyのない開発」が、私にプロダクトマネジメントを教えた PMFしたら、終わり？違う。そこからが、始まり ラクスのプロダクトマネージャーが目指すこと あなたの原動力は、なんですか？ 最後に

こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） tech-blog.rakus.co.jp 2027年3月期の初日ということで、自組織でもキックオフMTGを先月実施しました。プロダクト部が組成されてちょうど1年経ちましたので、昨年度の振り返りと今期の取り組みや今後とその先について、今考えていることをまとめてみました。 ※本記事は、プロダクト部の取り組みを紹介する目的で、執筆時点の考えを整理したものです。状況や学びに応じて、方針や進め方はアップデートしていきます。 2026年3月期の振り返り（確かな歩みと見えてきた本質） 組織強化という「Go…

2026年1月、株式会社ラクスに技術広報として入社した髙須賀（たかすか）と申します。 早いもので入社から3か月が経過しました。新年度という区切りを迎え、これまでの振り返りと、これから私たちが目指す姿についてお伝えできればと思います。 1. 自己紹介 2. ラクスの開発組織の魅力について 3. 入社後の取り組みについて ヒアリングと施策立案 顧客志向表彰の実施 ブログの執筆 社内向け記事の執筆 商談動画のまとめ その他 4. 今後の展望：発信を楽にする環境づくり 5. おわりに

こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） tech-blog.rakus.co.jp デザイナーとプロダクトマネージャー（PdM）が同じ組織になってもうすぐ1年が経ちますので、その挑戦、苦労、変化について書こうと思います。ラクスは3月末決算のため4月には来期に向けて取り組みを書こうと思いますが本記事は厚めに振り返ります。 組織図を書き換え、デザインを解放する なぜ統合が必要だったのか：「上流×一次情報×検証」が欠けると、協働は痩せていく デザインの再定義：それは「問題を解決するための設計」である 壁を壊すだけでは足りない：一次情報・意…

こんにちは、ラクスの技術広報です。 2026年2月20日（金）、ラクスの社内テックカンファレンス「Rakus Tech Conference for Us 2026」 を開催いたしました。 組織が拡大し、それぞれのプロダクトや職種の専門性が高まる中で、いかに「横の繋がり」を強め、新たな価値を生み出すか。熱気に包まれた当日の様子をレポートします。 開催の背景とテーマ：『Synergies』（シナジー） 多彩な8セッション：技術の先にある「協働」を語る 発表内容 【セッションラインナップ】 イベント後に寄せられた感想（抜粋） アフターイベント：東京・大阪の2拠点で同時開催 開催を終えて

目次 目次 0. はじめに 1. レビューされる側だった頃の問題点 2. レビューと設計の関係性 2.1 なぜレビューが必要なのか 2.2 なぜ「設計」が関係するのか 3. コードレビュー指摘の傾向から学んだこと 3.1. 様々な設計原則 3.2. 設計指摘を具体的に理解する 3.3. 設計指摘をものにするためには？ 4. before / after で見る設計指摘の具体例 4.1. SRP: 「責務が多い」と言われたケース before: 1つのクラスに複数の責務がある after: 責務ごとに分離する 4.2. OCP: 「将来増えそう」と言われたケース before: 条件分岐で処理を…

こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） tech-blog.rakus.co.jp お客様を知らないといけないので、「もっと深く考えて」と言われた瞬間に、急に手が止まることがあります。 フレームワークや知識は増えているのに、いざ実務だと「機能の足し算」しか出てこない——。 これ、能力の問題というより “鍛え方の種類” の問題だと思っています。 今日提案したいのは、名作を使った超シンプルな思考トレーニングです。 同じ作品を「読む→聴く→観る」の3回、メディア違いで摂取する。 それだけで、ユーザー理解に必要な「論理／情緒／直感」を行き来…

こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） tech-blog.rakus.co.jp マネージャーの役割を一言で言うなら、私は「管理」ではなく “支援” だと思っています。 現場の専門性を信じ、意思決定の質を上げ、チームが成果を出しやすい状態をつくること。 この記事では、そのために私が意識している2つの視点を紹介します。 コト（成果・意思決定）には解像度を上げる支援 人（成長・キャリア）には未来を描く支援 ※前提として、最適な距離感はチームの成熟度・状況・業務特性で変わります。ここでは「私の経験ではこうすると機能しやすかった」という一…

こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） tech-blog.rakus.co.jp 社内で口癖のように使っている「製品解像度」と「UX志向」について自分の思考の整理もかねて記事にまとめてみました。 はじめに：私たちは「誰」を見ているのか？ 「製品解像度」とは何か？ まず押さえたい：製品解像度が低いと起きる“あるある” なぜ「お客様解像度」だけでは不十分なのか？ 質の高いアウトプットを生む土壌 UX志向を支える「意思決定」の力 「OR」ではなく「AND」を模索する 「架け橋」としての役割 ラクス プロダクト部としての「UX志向」 製品…

こんにちは。 株式会社ラクスで、楽楽精算のプロダクトデザインチームのリーダーをしているimamuです。 ラクスでは現在、「ベストオブブリード」戦略から「統合型ベストオブブリード」戦略へ進化を目指し、製品開発を進めています。 www.rakus.co.jp www.rakus.co.jp 私たちプロダクトデザイン組織でも、デザインガイドラインの整備やUIリニューアルを行っています。 tech-blog.rakus.co.jp note.com その一環として、UXライティングガイドラインについても共通化と各製品への浸透を目指して取り組んでいます。 でも実はこのライティングガイドライン、私たち自身…