※この記事はラクスアドベントカレンダー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. デザイナーと“とにかく対話しまくった”
- 再びデザイン組織のマネジメントへ ― 私が今思っていること ―
- 「デザイン」の認識を変えたい
- 最後に：ラクスのデザイナー組織に興味を持ってくれた方へ
お天気エージェントを作りながら学ぶCodex CLI SDK入門
この記事はラクス 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年くらいででてきた名称です。
プロダクト開発の現場では、 エンジニア・PdM・デザイナーという大きな分類だけでなく、 その内側でさらに細かな役割が生まれています。
- グロースPdM / テクニカルPdM / AI PdM
- プロダクトデザイナー / UXデザイナー / サービスデザイナー
- フロントエンド / バックエンド / SRE / Platform / MLエンジニア
こうした細分化は「仕事の複雑さに対応する進化」であり、 同時に「働く側の専門性の見える化」でもあります。しかし一方で、細分化すればするほど“本当に良いことなのか？”という疑問も生まれます。
本記事では、これまで自分の経験やラクスの開発組織を例にしながら、以下のテーマを深掘りします。
- 職種内細分化のメリット・弊害
- 求職者と企業側、それぞれにとっての価値
- 「越境しなさい」という言葉への違和感の正体
- ラクスは専門性と越境をどうバランスさせているのか
目次
- ■なぜ職種は細分化されるのか？──良い面と本質的な価値
- ■しかし細分化には“弊害”もある
- ① プロダクトごとの縦割りが強まる
- ② “越境しないと回らない”状況を生んでしまう
- ③ キャリアの固定化が起こりやすい
- ■では、ラクスはどちらのスタンスなのか？
- ラクスで活躍する人の共通点
- ■まとめ：ラクスは「役割を尊重しつつ、越境も価値」と考える組織
- 最後に
高速リリースを達成するためにプロジェクトマネージャーとしてやったこと
1. はじめに
こんにちは、 id:rksbun です。私は40代の楽楽精算開発のPjMで、元エンジニアです。ラクスには今年2月に入社しました。
最近の開発案件で、通常よりもかなり短い期間でリリースできたので、PjMとしてやったことを書きたいと思います。この記事で、ラクスがただ言われた通りのプロジェクト管理だけでなく、考えたことに挑戦させてくれて、それを評価してくれる会社だということを伝えられたら嬉しいです。
- 1. はじめに
- 2. あったこと
- 3. 意識したこと
- 4. やったこと
- 1. DB設計は全員で重点的に
- 2. AIを使った効率化への挑戦
- 3. リスク管理
- 4. トラブル対応は迅速かつ大胆に
- 5. 結果
- 6. まとめ
焦りから始めた記事投稿が、いつの間にか日常になった話
はじめに
こんにちは。楽楽勤怠のバックエンドを担当しているkoyaです。
約二年前、あるきっかけからQiitaに記事投稿を始めました。
最初は毎週書こうと決めていたわけではありませんが、 気づけば毎週投稿するようになり、いつの間にか100週が経っていました。
振り返ってみると、続けてきた中でいろんな気づきがあり、自分自身も少しずつ成長できたように感じます。
この記事では、その間のことを少し振り返りながら、
書くことを続ける中で感じたことをまとめてみようと思います。
- はじめに
- 入社当初の焦り
- とりあえずで始めた記事投稿
- 毎週投稿の決意、そのためのルール
- 記事投稿をする中で得た気づき
- 1. アウトプットできるかどうかが理解度の物差しとなる
- 2. 書けない週はインプットが少ない
- 3. アウトプットを前提に学ぶことの大切さ
- 記事投稿を継続したいま、思うこと
- おわりに
🧱 プロダクトづくりにAIを溶かす３つの壁― ラクス流AI浸透のススメ ―
こんにちは、稲垣です。
先日、こちらのイベント
generative-ai-conf.connpass.com
のLTで話しました内容についてnoteでもう少し詳しくまとめました。
イベントの登壇資料はこちら
になります
「AIをどう使うか」ではなく、「どう溶け込ませるか」。
生成AIが当たり前になりつつある今、プロダクト開発においても「AIをどう取り入れるか」だけでなく、「どう文化として根づかせるか」が問われています。私たちラクスでは、このテーマに真正面から取り組み、「AIをプロダクトづくりに溶かす」挑戦を続けています。その過程で見えてきた“３つの壁”と、それを乗り越えるための工夫を紹介します。
- 🧩 AI浸透を阻む３つの壁
- ① プロセスやプロダクトフェーズの違い
- ② 職種の役割の曖昧さ
- ③ AIに対するリテラシーや向き合い方の違い
- 🛠️ ラクス流・３つの壁との向き合い方
- 1. 最初から共通化や理想を追い求めない
- 2. 職種としての定義を決める
- 3. みんなが楽しく使う
- 🚀 おわりに ― AIを“当たり前”にするために
