RAKUS Developers Blog | ラクス エンジニアブログ

株式会社ラクスのITエンジニアによる技術ブログです。

PdM像は十人十色──「我々は何者か」

PdM イベント

どうも、稲垣です。

先日、PM、PdM向けイベントを0からみんなで作る会に参加しました

参加のきっかけは、これまでとは少し違った雰囲気のイベントだったこと。それくらいの軽い気持ちでしたが、参加してみると、たくさんの気づきがありました。

せっかくなので、ブログにまとめてみようと思います。 思ったことを、感じたままに綴ります。読んでくださる皆さんにとって、何かしらの学びや気づきになれば嬉しいです。

前置きが長いですが是非！（イベントの内容については、ブログの後半でレポート）

  • プロダクトマネージャーの解像度のあげ方
  • そもそもプロダクトマネージャーって何者？
  • 「我々は何者か？」を明らかにすること
  • ラクス？楽楽精算って聞いたことあるけど、どんな課題があるの？
  • 「漫画」ができたら、次は？
  • イベント登壇・対談・参加の新たな価値
  • まとめ
  • 「PM、PdM向けイベントを0からみんなで作る会」の参加レポート
  • 最後に
続きを読む

『速読会』に参加してみた

PdM イベント

こんにちは、稲垣です。

2025年度からはイベント参加や登壇だけでなく
RAKUS Developers Blog | ラクス エンジニアブログやRakus Designers Rakus Designers
にも積極的に投稿して行こうかなと思っています。

Xでもプロダクトマネージャーのこと、デザイナーのこと、マネジメント全般なことをポストしていますのでよろしくお願いします。

前回は「フィッシュボウル」参加について書きましたが、今回はその翌週に参加した「速読会」について書きます。
この会ですが、今PdMの中では話題になっています。参加した方々の声がブログにノートであがっています

●ログラスさんの速読会に参加してきた話
●4月30日にログラスさんの速読会に参加してきましたレポート
●3時間で6冊読む！人生を100倍速にする「速読会」に参加しました
●社内速読会を開催してみました

自分が参加したのは、4/30(水)の会です(上記、noteのtktさんと同じ会です。)

参加のきっかけはＸ等でこの話題を見て、別のイベントでお会いした @tomosooon さんに声をかけてからです。
（ちなみに本イベントはconnpass等での募集はないです。）

  • いざ速読会へその前に
  • 速読会スタート
    • ポイント
    • 感想
  • 今回速読会で読んだ他の本
  • 最後に
続きを読む

『PMフィッシュボウル 〜組織デザインってむずくない？編〜』参加してみた

PdM イベント

こんにちは、稲垣です。

2025年度からはイベント参加や登壇だけでなく
RAKUS Developers Blog | ラクス エンジニアブログやRakus Designers note
にも積極的に投稿して行こうかなと思っています。

Xでもプロダクトマネージャーのこと、デザイナーのこと、マネジメント全般なことをポストしていますのでよろしくお願いします。

今回の内容は4/23(水)に「ゲスト」で参加したこちらについてです。

※PMフィッシュボウル 〜組織デザインってむずくない？編〜

非常に学びと良い経験ができたイベントだったので、書いておきます。 また、今後「フィッシュボウル形式」でのイベントや取り組みを検討している方へも参考になれば幸いです。

自分は「フィッシュボウル形式」は初で、「OST形式」は前職で経験がありました。ただ、今振り返ればOST形式だったんだという程度でした。 人数はともかく、360度人に囲まれて話すという経験も初体験です。

余談ですが、ログラスさんの新オフィスも初（以前の三田オフィスへ対談イベントでお邪魔したことがあった）でしたが 、イベントに最適な綺麗なオフィスでした（泉岳寺駅からもすぐ！）

  • ■「OST」と「フィッシュボウル」とは？
  • ■『PMフィッシュボウル 〜組織デザインってむずくない？編〜』
  • ●前日談
  • ●当日
続きを読む

開発生産性計測について見直して開発速度向上を狙っている話

開発戦略

こんにちは。
株式会社ラクスで先行技術検証をしたり、ビジネス部門向けに技術情報を提供する取り組みを行っている「技術推進課」という部署に所属している鈴木（@moomooya）です。

ラクスでは社内独自指標での開発生産性指標の計測を行ってきましたが、今年度からFindy Team+を開発本部全体に導入しFour Keysをベースとした計測1に切り替えてきました。

今回はFindy Team+導入に関する記事を書こうと思います。

  • 導入と経緯
    • 課題
    • 経緯
  • ファインディ社との関わり
    • 開発生産性カンファレンス
      • 指標のハックについてはひとまず考えない
    • Findy Team+ 検討、仮決定
      • 内製でやるのは結構大変そう
    • 試用期間
  • 2チームでスモールスタート
  • 全チーム本格導入
  • 今後やっていきたいこと
  1. Four Keysを元にしていますが、厳密にはFour Keysではありません。おおまかにはデプロイを基準にしている部分を、レビュー後のマージに置き換えた考え方で定義しています。当初は本来の定義を変えることに疑いがあったのですが、SPACEフレームワークの考え方に則って考えれば問題ないだろうと判断しています。↩
続きを読む

mcp-goで作って学ぶMCPサーバー

AI Go

はじめに

こんにちは、エンジニア３年目のTKDSです！ 最近MCPが盛り上がってます。
流れに乗ってGoでやる方法を調べて試してみました！
まず簡単に現在時刻を返すMCPサーバーを作ったあと、割と実用的に使えそうなファイルを連結して返すMCPサーバーを作っていきます。
今回書いたコードのリポジトリです。
https://github.com/tkeshun/mcp

  • はじめに
  • MCPとは？
  • 今回使用するライブラリ
  • 現在時刻を返すMCPサーバー
    • 1. プロジェクトの準備
    • 2.コード作成
    • 3. パッケージのダウンロードとビルド
    • 4. 試す
  • 特定のディレクトリ以下のファイルを返すMCPサーバー
  • まとめ
続きを読む

「プロダクト部はじめました」

組織づくり PdM デザイン

こんにちは、プロダクト部副部長の稲垣です。

2025年4月から、プロダクトデザインの組織とプロダクトマネージャーの組織が、同じ「プロダクト部」という部門に統合されました。
マルチプロダクトでサービスの開発・運用を行う企業にとって、「製品づくりの組織デザイン」をどう構築するかは、各社が試行錯誤を重ねているテーマだと思います。本記事が、少しでもその参考になれば幸いです。

この記事では、以下の4点について紹介します：

  • ラクスにはどんな製品があり、どのような組織体制なのか
  • デザイナーとプロダクトマネージャーは、これまでどのように連携してきたのか
  • 今回、なぜ「プロダクト部」が立ち上がったのか
  • 「プロダクト部」はどのような役割を担うのか
続きを読む

Kotestで使われる不思議な記法の裏側について調べてみた

Kotlin

はじめに

皆さん！初めまして！　楽楽請求新卒エンジニアの kaihatsuda です。

本記事では、Kotlin のテストフレームワーク Kotest に使われている Kotlin の特徴的な記法や技術を紐解いていきます！　(本記事は Kotest の 使い方解説 ではなく、その背後にある Kotlin の技術を理解することに焦点を当てていますので、ご了承ください。)

私たちが開発する 楽楽請求 では、サーバーサイドの実装に Kotlin を採用しています。テストコードの記述も開発サイクルに欠かせない重要な工程の一部として位置づけられており、品質を担保するための必須要素になっています。特に、テストコードの 簡潔さ や 可読性の高さ は、効率的な開発において非常に重要です。

楽楽請求では、単体テストを記述するために Kotest を採用しています。私自身、学生時代に単体テストを書く経験がほとんどなく不安でしたが、配属後に初めて触れた Kotest で以下のようなテストコードに触れたとき、その直感的な書き方に感動しました。

初めて触れた Kotest のコードのイメージ

class MySpec : FunSpec({
    context("四則演算の正常系") {
        test("正しく加算できる") {
            (2 + 2) shouldBe 4
        }
        test("正しく減算できる") {
            (9 - 2) shouldBe 7
        }
    }
    context("四則演算の異常系") {
        test("0で除算すると算術エラーが投げられる") {
            shouldThrow<ArithmeticException> {
                val result = 1 / 0
            }
        }
    }
})

このコードを見たとき、私はこう思いました。

「なんだこの shouldBe とか context とかいう書き方...
でも、めちゃくちゃ可読性が高いし直感的に書けてすごい！」

一見すると、まるで普通の日本語の 箇条書き のように見えませんか？

  • context("四則演算の正常系") の中に、test("正しく加算できる") がある
  • (2 + 2) shouldBe 4 は「2+2は4であるべき」という意味のテストである
  • 正常系と異常系を文脈で分けて記述している

Kotlin を知らなくても、何をテストしているのか直感的に理解できそうです。

でも疑問も浮かびます

  • 「shouldBe はまるで演算子みたいにスペース区切りで呼べるのは何故？」
  • 「なんで波括弧 {} の中に context と test が並んでるの？　なぜ呼び出せるの？」
  • 「shouldThrow<ArithmeticException> はどうやって型をチェックしているの？」

こうした Kotest の "魔法のような記法" を支えているのは、Kotlin の infix、拡張関数、レシーバ付きラムダ式、inline & reified といった特徴的な機能です。(その他にも様々な技術が使われていますが、今回はここまでに留めます)

  • はじめに
  • 本記事のゴール
    • 本記事で読み解くコード例
  • それぞれの記法の解説
    • 1. infix
    • 2. 拡張関数
    • 3. レシーバー付きラムダ式
    • 4. inline & reified
      • 4.1 inline
      • 4.2 reified
  • まとめ
続きを読む
ラクスの技術 / デザイン情報サイト
Copyright © RAKUS Co., Ltd. All rights reserved.