こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。）tech-blog.rakus.co.jp

• ■ 「Noを伝える技術」の感想
• ■ イエスと言って「誠実に合意形成する」ための技術とは？
  • ① まずは「強いイエス」を返す
  • ② ただし、本当にやるのは「徹底的なリサーチ」
  • ③ そのまま“事実として”レポートする
  • ④ 相手は自然と「今回はやめるか」と判断する
• ■この技術の良いところ
• 📝 まとめ：本気で向き合う姿勢が、結果的に“ノーを機能させる”あるいは“イエスのコミットメントをあげる”

この記事はラクス Advent Calendar 2025 12日目の記事です。

はじめに

こんにちは。ラクス フロントエンド開発課のたぐちです。

今回は、私たちフロントエンド開発課で取り組んでいる学習文化の醸成に関する取り組みをご紹介します。

• はじめに
• 取り組み内容
• 情報共有会の良いところ
  • 1. 学習のハードルが下がる
  • 2. メンバーの価値観や思考を知る機会が増える
  • 3. 気になる技術をその場で試せる
• 今後の改善ポイント
  • 1. ファシリテーターが固定化している問題
  • 2. 記事を投稿するメンバーが偏りがち
• おわりに

はじめに

請求書の明細表をOCRによって自動で読み取ることができると、経理業務自動化の実現に役立ちます。ところが実際には、多様なフォーマットの存在や OCR の誤読が積み重なり、AIモデルとルールベース後処理だけでは思った以上に精度が出ない、という壁にぶつかることがあります。AI モデルそのものの改修となると、学習データの追加やモデル更新など、時間もコストも必要になります。また、ルールベース後処理を増やし続けるのは、将来の保守を重くする心配がつきまといます。そこで、「大規模言語モデル（LLM）を後処理に加えたら、より柔軟に・より構造的に・まるで人間が行うように誤りを補正できるのではないか」という発想のもと、既存処理に GPT による補正ステップを追加し、精度改善ができるか検証しました。

• はじめに
• LLM による後処理の追加
  • 追加した処理の流れ
  • GPT に与えたプロンプト
• 検証結果
• まとめ

※この記事はラクスアドベントカレンダー2日目の記事です

はじめに

こんにちは！
エンジニア3年目のTKDSです！
今回はEKSでOtel Collectorを用いたContainer Insightsメトリクスの取得についてご紹介します。
ぜひ最後まで見ていってください！

• はじめに
• Container Insights
• Otel Collectorによるメトリクスの収集
• Otel Collectorのマニフェスト例
• まとめ

こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。）tech-blog.rakus.co.jp

2025年4月、ラクスではプロダクト部が新たに組成され、デザイナーとプロダクトマネージャーが同じ組織に加わりました。

そして2025年10月から、私はこの組織のマネジメントを担うことになりました。

実は7〜8年前にも、兼務という形でデザイナーのファーストラインマネージャーを経験しており、採用も含めて直接マネジメントをしていた時期があります。

その経験があるため、今回デザイン組織が含まれることに対する不安はありません。むしろプロダクトマネージャーとデザイナーが同じ組織でコラボレーションできることにワクワクしている というのが今の正直な気持ちです。

この記事では、これまでの自分とデザイン／デザイナーとの関わり、そして今回のマネジメントに向き合うにあたって考えていることをまとめました。

ラクスでデザイナーとして働く未来を考えてくれる方に、少しでも私の考えが届けば嬉しいです。

目次

• 「デザイン」との出会い
  • SI企業時代：管理画面の“画面設計”から始まった
  • はじめて「デザイン」を意識した案件
• デザイナー理解が一気に深まった転職先での経験
  • ●フラッシュセールサイト：国内にないコンセプトを形に
  • ●ECプラットフォーム：UXとクリエイティブの両軸
• デザイナーが入るだけで“世界が変わる”という実感
• デザイナー採用への深い関与
• エンジニア出身の自分がデザインを理解するためにやった2つのこと
  • 1. デザインに関する本を“読みまくった”
  • 2. デザイナーと“とにかく対話しまくった”
• 再びデザイン組織のマネジメントへ ― 私が今思っていること ―
  • 「デザイン」の認識を変えたい
• 最後に：ラクスのデザイナー組織に興味を持ってくれた方へ

この記事はラクス Advent Calendar 2025 1日目の記事です。

はじめに

こんにちは！エンジニア3年目のTKDSです！今回はCodex CLI SDKの入門記事を書きました！Codex CLI SDKはChatGPTの有料プランに契約していれば、特に追加費用不要で使用可能です。そのため、さくっとMy AIエージェントを作るのには非常におすすめです。では早速本題に入っていきたいと思います。

• はじめに
• Codex CLIの概要
• Codex CLI SDKについて
• 環境情報
• 基本的な操作
• お天気エージェントを題材にした解説
  • シンプルなエージェント
• 最終版
• まとめ

こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。）tech-blog.rakus.co.jp

先日、こんなイベントでモデレーターをしました。このイベントではプロダクトエンジニアをテーマに対談をしました。この『プロダクトエンジニア』という言葉はここ5年くらいででてきた名称です。

rakus.connpass.com

プロダクト開発の現場では、 エンジニア・PdM・デザイナーという大きな分類だけでなく、 その内側でさらに細かな役割が生まれています。

• グロースPdM / テクニカルPdM / AI PdM
• プロダクトデザイナー / UXデザイナー / サービスデザイナー
• フロントエンド / バックエンド / SRE / Platform / MLエンジニア

こうした細分化は「仕事の複雑さに対応する進化」であり、 同時に「働く側の専門性の見える化」でもあります。しかし一方で、細分化すればするほど“本当に良いことなのか？”という疑問も生まれます。

本記事では、これまで自分の経験やラクスの開発組織を例にしながら、以下のテーマを深掘りします。

• 職種内細分化のメリット・弊害
• 求職者と企業側、それぞれにとっての価値
• 「越境しなさい」という言葉への違和感の正体
• ラクスは専門性と越境をどうバランスさせているのか

目次

• ■なぜ職種は細分化されるのか？──良い面と本質的な価値
• ■しかし細分化には“弊害”もある
  • ① プロダクトごとの縦割りが強まる
  • ② “越境しないと回らない”状況を生んでしまう
  • ③ キャリアの固定化が起こりやすい
• ■では、ラクスはどちらのスタンスなのか？
  • ラクスで活躍する人の共通点
• ■まとめ：ラクスは「役割を尊重しつつ、越境も価値」と考える組織
• 最後に