はじめに こんにちは！楽楽勤怠開発チームのoo_yoshiです。 勤怠管理システムは「打刻して残業時間や休暇を計算すれば終わり」と思われがちです。しかし、実際にシステムを開発・運用してみると、その裏には複雑なルールと例外が山ほど存在します。 勤務体系は企業ごとに違い、法律や就業規則も定期的に改正されます。有休の付与や消化ルール、代休や振休の扱い、残業の丸め処理など、ひとつひとつのルールが微妙に違い、組み合わせると膨大なパターンになります。 私たちのチームでは、そうした複雑さに対応するために9年前にDDD（ドメイン駆動設計）を採用し、勤怠システムをリニューアルしました。本記事では、その9年間で感じたこと、分かったことを振り返りたいと思います。 はじめに 旧勤怠管理システムで直面した課題 リニューアル時にDDDを導入して変わったこと 属人化の解消 9年経って実感したDDDの価値 まとめ 旧勤怠管理システムで直面した課題 リニューアル前の勤怠システムは、自作フレームワークをベースに作られていました。 そのため「どこにどんな処理があるのか」が一目で分からず、長く在籍しているメンバーが「知っているからなんとかなる」という属人化した仕組みになっていました。結果として「この処理の正解は◯◯さんしか知らない」という状況も珍しくありませんでした。 新しく入ったメンバーにとってもハードルは高く、普段は残業や休暇を申請していても、システムがどう計算しているかを理解できない。用語として「休暇残数」「振休」「代休」を知っていても、コードを読んでもピンと来ない。結果として教育コストは大きく膨らみました。 私自身も新卒2年目の頃から旧勤怠システムに関わらせてもらい、数えきれないほどの失敗を経験しました。。。振り返れば大きな糧になりましたが、正直に言えば「他の人にはあまりおすすめできない環境」だったと今では思います。 リニューアル時にDDDを導入して変わったこと 旧勤怠管理システムで一番困っていたのは「何をどこで処理しているのかが不明確」という点でした。 そこで新システムではDDDを採用。まず「勤怠ドメインを整理してモデルに落とし込む」ことから始めました。 要するに「現実の勤怠の仕組みを、チーム全員が同じ言葉で説明できるようにする」というアプローチです。 モデルの分け方の例 労働パターン 勤務区分（固定、フレックス、管理監督者など）や勤務カレンダーなど勤怠計算に必要な設定を定義します。 打刻 出勤・退勤・休憩といった「事実」だけを表す。ここには「遅刻」や「残業」といった解釈は入れず、純粋に「いつ押したか」だけを残す。 勤務実績 打刻で登録された値や勤怠計算で計上された、その日の「働いた結果」を表現。ユーザーに見せるのはここからだけにした。 休暇履歴 有休の付与・取得・消滅をすべて履歴として積み上げる。残日数は履歴をたどれば自動的に導けるようにして、「この値は正しいのか？」と悩む必要をなくした。 ドメインを整理してモデルに落とし込むことで、「どの処理がどこにあるのか」が明確になり、コードを追いやすくなりました。 ※DDDを導入する際に整理した代表的なモデルを、簡単ではありますが役割とドメインルールとあわせてまとめると以下のようになります。 属人化の解消 もう一つ大きな効果は、ユビキタス言語によるチームの共通理解です。 「労働パターン」「打刻」「勤務実績」「休暇履歴」といった言葉をチーム全体で使うようにしました。以前は「ロジック名」や「○○画面の処理」といった曖昧な表現をしていましたが、今では具体的なモデル名を指して会話できるようになり、仕様確認やレビューがスムーズになりました。 その結果、属人化は大きく解消されました。知識が特定のメンバーに偏るのではなく、モデルに閉じ込めたドメイン知識をチーム全体で共有できるようになったのです。 9年経って実感したDDDの価値 9年間システムを運用してきて実感したのは、DDDが「複雑な業務知識をチーム全体で維持し続ける仕組み」としてとてもよく機能しているということです。 新メンバーの立ち上がりが速くなった 「休暇履歴」「勤務実績」といった用語をベースに理解できるようになった 制度変更にも柔軟に対応できるようになった（該当モデルにルールを追加・修正するだけで済む） 旧システムのように「勤怠ドメインの理解に数カ月」かかることはなくなりました。 まとめ 勤怠管理システムは、一見シンプルに見えて実は非常に複雑です。その複雑さは、エンジニアがドメイン知識を理解するだけでも大きな負担になります。 9年前にDDDを導入してから、私たちは「休暇履歴」や「勤務実績」といったドメインを整理し、モデルに落とし込むことで属人化を解消し、新規メンバーでも理解しやすく、制度変更にも柔軟に対応できるシステムへと進化させることができました。 振り返ってみると、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プロジェクトで管理しており、 /app 配下に処理に必要なディレクトリが存在し、単体テストコードも実装と同じパッケージ構成で用意しています。 また層を跨ぐ依存関係にはテストダブルを利用することで、各層の単体テストを独立して実行できるようにしています。 以下はパッケージ構成の例です（物理パスはGradle標準のsrc/main/java、テストはsrc/test/groovyなど各プロジェクト標準に準拠） src/main/.../app ├── controller ├── domain ├── infrastructure ├── persistence └── usecase src/test/.../app ├── controller ├── domain ├── infrastructure ├── persistence └── usecase 改善前のCIワークフロー設定 lintジョブ Spotlessを使ったチェック unit-testジョブ DBコンテナを起動 DBマイグレーション 単体テスト実行 カバレッジの集計 当時の課題 プロダクトフェーズから考えると、CIの時間はもちろん早い方がいいです。 ですが、当時は以下のような状況でした。 計測時期 2025年3月 テストの平均実行時間（成功のみ） 20分50秒 成功したワークフローのみを対象としたのは、失敗したワークフロー（ビルド or テスト失敗や、 cancel-in-progress による早期打ち切りなど）を含めると平均実行時間が実態より短く算出され、改善効果を正確に測定できないためです。 実行時間が長い主因として、まず直列実行を疑いました。 キャッシュの未使用やマシンスペックの問題も考えられましたが、小さく早く試して効果を検証するという観点から、設定変更で実現できる並列実行が最も着手しやすい改善策だと判断しました。 そこで今回は「テストジョブの並列実行」を第一の改善策として採用し、その効果を検証することにしました。 実施した改善策 lintジョブ Spotlessを使ったチェック 4並列のテスト実行ジョブ A B C D カバレッジジョブ 各ジョブで実施した内容を集計 GradleとGitHub Actionsの組み合わせ テストジョブの並列実行を実現するために、GradleとGitHub Actionsの2つを組み合わせました。 ①：Gradleでカスタムタスクの作成 Gradleでの並列化としてよく maxParallelForks が紹介されますが、これは単一のタスク内でJVMプロセスの並列度を上げるための設定です。 一方、今回の取り組みではCI全体の実行時間を効率よく短縮することを目的とし、GitHub Actionsのジョブそのものを分割して並列実行できるようにする必要がありました。 そこで、workflowのmatrix戦略にそのまま割り当てられる実行単位としてカスタムタスクをGradle 側に定義しました。 この方法により、特定のテストグループをジョブ単位で独立して制御できるようになりました。加えて、カバレッジの集約も簡素化され、将来的な差分テストなどへの拡張性も確保できました。 以下にその定義例を示します。 // 共通のテスト設定 tasks.withType(Test).configureEach { useJUnitPlatform() } tasks. register ( 'A' , Test) { include '**/persistence/**/*.*' , '**/infrastructure/**/*.*' , '**/domain/**/*.*' } tasks. register ( 'B' , Test) { include '**/usecase/a**/**/*.*' , '**/usecase/b**/**/*.*' , '**/usecase/c**/**/*.*' , '**/usecase/d**/**/*.*' , '**/usecase/e**/**/*.*' , '**/usecase/f**/**/*.*' , '**/usecase/g**/**/*.*' , '**/usecase/h**/**/*.*' , '**/usecase/i**/**/*.*' , '**/usecase/j**/**/*.*' , '**/usecase/k**/**/*.*' , '**/usecase/l**/**/*.*' } tasks. register ( 'C' , Test) { include '**/usecase/m**/**/*.*' , '**/usecase/n**/**/*.*' , '**/usecase/o**/**/*.*' , '**/usecase/p**/**/*.*' , '**/usecase/q**/**/*.*' , '**/usecase/r**/**/*.*' , '**/usecase/s**/**/*.*' , '**/usecase/t**/**/*.*' , '**/usecase/u**/**/*.*' , '**/usecase/v**/**/*.*' , '**/usecase/w**/**/*.*' , '**/usecase/x**/**/*.*' , '**/usecase/y**/**/*.*' , '**/usecase/z**/**/*.*' } tasks. register ( 'D' , Test) { exclude '**/persistence/**' , '**/infrastructure/**' , '**/domain/**/*.*' , '**/usecase/**' } ./gradlew test --tests hoge から着想を得ました。 また公式ドキュメントにも「テストのグループ化」というセッションで、似たような方法を紹介しており、こちらも参考にしました。 またこの4つの分け方は、実行時間が均等になるように調整しました。 なぜこの書き方なのか GradleのTestタスクは、正規表現ではなくAnt形式の include/exclude パターンをサポートしています。 クロージャーやSpecを利用した柔軟なフィルタリングもできますが、当時はとにかく早く並列化を実現したかったので、Ant形式を採用しました。 ②：GitHub Actionsでのジョブの並列実行 こちらは matrix を使って、並列実行を実現しました。 unit-test: strategy: matrix: test-task: [ A, B, C, D ] シンプルに、先ほど作成したカスタムタスクを指定し、並列で実行するように設定しました。 ③：JaCoCoレポートの作成 改善前は、1つのジョブで全てのテストを実行していたのでJaCoCoレポートの作成も容易でした。 しかし、テスト実行ジョブを4つに分割して並列化したことで、実行結果をうまくマージしないとJaCoCoレポートが作成できない問題に直面しました。 これに関しては、各テストジョブ実行後に classes ディレクトリと jacoco/*.exec をアーティファクトにアップロードし、カバレッジジョブで集計するようにしました。 レポートを作成しないと、リファクタリングの結果（カバレッジは変わっていないが、実行時間が短縮されている）を正確に確認できないので、まずはこちらを先に設定することをおすすめします。 以下にその定義例を示します。 # 各テストジョブ - name: Upload Compiled Classes and Jacoco Execution Data uses: actions/upload-artifact@n.n.n with: name: compiled-classes-and-jacoco-${{ matrix.test-task }} path: | build/classes **/build/jacoco/*.exec retention-days: 1 # カバレッジジョブ - name: Download Combined Artifact (Compiled Classes & Jacoco Data) uses: actions/download-artifact@n.n.n with: pattern: 'compiled-classes-and-jacoco-*' path: build/download-artifacts - name: Restore Compiled Classes and Jacoco Exec Files run: | mkdir -p build/classes mkdir -p build/jacoco # 各アーティファクトディレクトリからクラスファイルと.execファイルを抽出 for d in build/download-artifacts/*; do echo "Processing artifact directory: $d" if [ -d "$d/build/classes" ]; then cp -R "$d/build/classes/." build/classes/ fi find "$d" -name "*.exec" -exec cp {} build/jacoco/ \; done - name: Generate Jacoco Report run: ./gradlew jacocoTestReport --info 結果 日付 平均実行時間（成功のみ） テスト実行方法 2025年3月 20分50秒 直列 2025年3月 10分40秒（最短10分5秒） 並列 2025年4月 12分5秒 並列 2025年5月 14分26秒 並列 2025年6月 12分5秒 並列 2025年7月 13分41秒 並列 2025年8月 14分47秒 並列 テスト数は増え続けています（3月から8月で、約1,000件増加）が平均実行時間にばらつきがあるのは、GitHub Actionsのランナーリソースが他のワークフローと競合する時間帯に、実行時間が伸びる傾向があるからです。 そのため、開発が活発な期間やバグを集中改修する期間は同時実行数が増え、ほぼ同じテスト数でもリソース待ちが発生し実行時間が伸びてしまっています。 その他 CI実行時間の短縮に直接関係のある話ではないですが、この対応に関連して行ったことを少し整理してみます。 費用対効果の確認と事前調整 今回の対応によってCIのテスト実行時間が短縮されること自体は望ましいですが、並列化によりジョブ数が増えるため、その分消費するGitHub Actions の利用時間も増加します。 私たちの組織では、Enterprise単位で利用可能なGitHub Actionsの分数に上限が設けられているため、この増加が他チームの上限枠を圧迫する可能性を考慮する必要がありました。 今回の対応はCPU/OS 種別の変更を伴わず、あくまでジョブ数の増加による実行時間消費への影響が論点となります。 そのため、改善策を導入する前に社内の横断的な技術サポート組織である開発管理課に相談し、利用状況や上限枠を確認しました。 あわせて、公開情報を参考にコストと削減時間を試算し、想定される費用対効果を数値として提示しました。 その結果、管理職から速やかに承認を得ることができ、問題になる前に先に相談したことで、気持ち的にも余裕を持って対応することができました。 gh コマンド＋Claude Codeを使ったワークフロー統計分析 今回の対応を実施し、毎月の推移を集計・確認していました。 内容としては成功したワークフローの実行時間を集計し、平均実行時間を出していました。 ただ集計方法は、正直パワーで押し切っていました。画面からワークフロー結果をコピペし、スプレッドシートに記載して計算していました。 MCPを使って上手く集計できないか試したんですが、当時は適切なツールが無く（自分で開発出来ず）実現はできませんでした。 ただ今回の記事を書くにあたって、 gh コマンドとClaude Codeを使ってみたんですが、これが大成功でした！ 以下のようにプロンプトを入力し、期待した結果を得られました。 もし同じような操作を行う場合、選択肢の1つとして覚えていただけたらと思います。 （ちゃんと手作業で計算した結果とほぼ一致していました！） ghコマンドを利用して、hogeリポジトリの「Parallel Tests」ワークフローの2025年n月分の成功時のみの平均実行時間を計算してください！全ブランチ対象で！ ↓ 📊 2025年8月 「Parallel Tests」ワークフロー実行統計 全体サマリー - 平均実行時間: 14分47秒（886.93秒） 月間推移（3月→4月→5月→6月→7月→8月） - 平均時間: 10分40秒 → 12分5秒 → 14分26秒 → 12分5秒 → 13分41秒 → 14分47秒 社内へのナレッジ展開 月1回の技術発表の機会で発表してきました。 ラクスではJavaを使った商材が他にもあるので、何か参考になればと思い発表したのですが、後日他のプロダクトのエンジニアから直接声をかけられ、対応方法を聞かれました。 早速今回の対応が少しでも他チームに貢献できるチャンスがあると思うと、嬉しい限りです！ 伸び代 最後に伸び代を書きます。 キャッシュの有効活用 重複しているビルド資材のキャッシュ活用 ジョブの再配置 テスト実行時間に偏りが生じてきたため、均等に再分配 セットアップの分離 DBのセットアップ部分を1つにまとめ、各テストへ配布 Self-Hosted Runnerの利用 費用面や速度面で、改善余地の可能性 発展的な改善案 PRで変更があった部分だけテスト実行 ここで「将来的な差分テストなどへの拡張性」が有効に機能する想定 @SpringBootTest などのテストが遅くなる設定を減らす 不要な場所でも使っているので、精査し削除していくことで早くなることを期待 まとめ 今回は、Gradle + GitHub Actionsを用いたCIのテスト実行時間短縮についてご紹介しました。 実施内容と成果： Gradleのカスタムタスクによるテストのグループ化とGitHub Actionsのmatrix機能を組み合わせ、テストを4並列で実行 実行時間を20分50秒から10分40秒へと約50%短縮を実現 テスト数が約1,000件増加した現在でも、14分台で実行完了 特に重要だったポイント： 小さく早く試す - 複雑な最適化より、まず設定変更で実現できる並列化から着手 計測の正確性 - 成功したワークフローのみを対象に改善効果を測定 事前の調整 - 費用対効果を算出し、関係部署と事前に相談することでスムーズな導入 今後もキャッシュ活用や変更箇所のみのテスト実行など、さらなる改善の余地があります。 実際に高速開発には様々な要因が影響するため、今回のCIテスト実行時間の短縮ですぐ効果が出る訳ではないと思います。 しかし、CI完了待ち時間のコンテキストスイッチ減少やPRのフィードバック高速化など、間接的に貢献できていると考えています。 本記事が同様の課題を抱える、特にJavaやGitHub Actionsを利用しているチームの参考になれば幸いです。 それでは！

はじめに AI関連の話題 AI活用状況のスナップショット うまくいっていること オンボーディング支援 コードリーディングの支援 ボイラープレートの自動生成 単純で広範な一括修正の自動化 AIによるプルリクの一次レビュー うまくいかなかったこと（限界と落とし穴） 自立型コードエージェントによる実装 非決定性（出力の揺らぎ） コンテキスト忘却 Kotlin×IDEロックイン問題 学んだこと まとめ 参考文献 はじめに 楽楽請求開発チームのkyoshimotoです。 バックエンド開発チームに所属し、開発チームをスケールさせるための開発プロセス整備、チーム内でのAI活用の推進を担当しています。 本記事では、現時点のAI活用状況や、うまくいっている点・うまくいっていない点、学んだことを共有します。 AI関連の話題 AI活用に関する期待を一段と高める話題が増えています。代表例を挙げます。 AnthropicのAmodei氏「3–6ヶ月で90%のコード、12ヶ月で本質的にすべてをAIが書く可能性」に言及（Business Insider, 2025/03） MicrosoftのSatya Nadella氏「社内コードの20〜30%はAIが書いている」（TechCrunch, 2025/04） GoogleのChief Scientist Jeff Dean氏「1年以内にジュニアエンジニア相当の性能に到達し得る」（Business Insider, 2025/05） Windsurfチーム「コードの約95%はCascadeとWindsurf Tabで書かれている」（The Pragmatic Engineer, 2025/07） こうした記事を読むと心が踊る一方で、今後のエンジニアの仕事はどうなるのかと不安になる方もいると思います。とはいえ、商用プロダクトのソフトウェア開発の現場では、直近でエンジニアがAIに置き換わる気配は正直感じていません。 ツール導入の成果は確かに出ていますが、効果が顕著な領域はまだ限定的で、期待値は少し落ち着いたというのが正直な実感です。 AI活用状況のスナップショット 現在、チームで利用・検証している主なツールです。新しいツールが日々リリースされ乱立する中、IntelliJ+GitHub Copilot を標準的な開発環境としつつ、他のツールも試用しながら開発プロセスに組み込んでいます。 なお、バックエンドのプログラミング言語はKotlinがメインとなります。 AIツール 主な用途 ChatGPT ドキュメント作成／コード生成／コードレビュー Claude（検証中） コード生成 Codex コードレビュー Devin コード生成／ロジック調査／CIエラー対応／コードリーディング支援 Gemini ドキュメント作成／コード生成／コードレビュー GitHub Copilot コード補完／コード生成／ロジック調査／コードレビュー／コードリーディング支援 NotebookLM 仕様検索／新規メンバーのオンボーディング支援 うまくいっていること オンボーディング支援 外部設計書をNotebookLMに取り込み、仕様Q&Aを即時化。心理的安全性の高い質問窓口として機能し、新規メンバーの立ち上がりが加速しました。 2025年度はKotlin未経験者が10名以上ジョインしましたが、GitHub Copilotのタブ補完／チャットにより新しいプログラミング言語の習得が障壁になることなく、スムーズに実装タスクを開始できています。 NotebookLMイメージ コードリーディングの支援 IntelliJ＋GitHub Copilotで既存ロジックの理解を効率化。実装から仕様を逆引きして整理でき、質問対応の精度も向上。 処理内容の要約や、UMLやER図の抽出など、コードリーディングの時間短縮やシステム理解に活用できています。 私の担当プロダクトは昨年10月にリリースしたばかりで、自社の別プロダクト（楽楽精算など）の機能実装を参考にする場面が多くあります。そこでDevinを用い、複数リポジトリを横断して実装を調査することで、調査コストを削減できています。プロダクト横断のコードリーディングが格段に楽になりました。 ボイラープレートの自動生成 マスタ系CRUDのAPI実装やValidationなどの定型実装の一部をDevinで自動生成できる成功事例が増えています。現在は、プロンプトのテンプレート化とプロセス組み込みを進めています。 プロンプトイメージ 単純で広範な一括修正の自動化 スキーマ変更に伴うエンティティ／テストデータ更新、APIリクエスト／レスポンス構造変更など、ロジックは単純だが影響範囲が広い作業は、数百ファイル規模でもDevinを使ってワンショットで完了するケースが多く、開発コスト削減の効果が出ています。 AIによるプルリクの一次レビュー PR作成直後にAIがタイポ、コメントの誤り、表記ゆれ、スタイル不一致といった軽微な指摘を先出しします。これにより、レビュアーは設計やロジックなど本質的な論点に専念できています。 （GitHub Copilot Code Review, OpenAI Codexを利用） GitHub Copilot Code Reviewイメージ うまくいかなかったこと（限界と落とし穴） 自立型コードエージェントによる実装 Devin、GitHub Copilot、Cursorを使って、実装タスクの自動化を検証しましたが、成功はボイラープレート生成と単純一括修正にほぼ限定されます。 その他では、以下のような課題が上がりました。 セッション（会話）が長引くほど生成精度が劣化し、生成コードの採用に至らない。 指示の具体化や前提整理に時間がかかり、人が実装した方が速い場面が多い。 非決定性（出力の揺らぎ） 同一プロンプトでも出力がぶれるため、AIツールで生成したコードの比較や精度評価の収束に難航しました。 AIの「非決定性」問題を認識せず、プロンプトやコンテキストに“おまじない”的な調整やハックに頼った結果、再現性のない成功パターン探しに時間を浪費してしまうことがありました。 コンテキスト忘却 プロンプトが長くなると冒頭・末尾が優先され中盤が抜けやすい（Lost in the Middle問題）。さらに、コンテキストウィンドウ上限を避けるためのコンテキスト圧縮過程で重要事項が脱落。結果として、 ガイドラインを与えても全項目の遵守は期待しづらい。 コードレビューもごく一部の規約しか参照されない。 セッションが長くなるほど残り10〜20%の実装をAIで完遂するのが難しい。 指定外リポジトリへのPR作成、プロンプトに明示した指示の無視が散見される（例:「PRを作成しないで」「プロパティファイルの定義は辞書順で」といった指示が無視される）。 Kotlin×IDEロックイン問題 標準の開発環境は IntelliJ＋GitHub Copilotですが、VS Code版と比べて機能提供の遅れや不具合が目立ち、体験品質に課題が残ります。いっぽうでVS Code系（Copilot in VS Code／Cursor）はKotlinの言語サポートやコードジャンプが不十分で、AIツール導入の移行障壁になっています。結果として、Kotlinの採用により、IntelliJへの事実上のベンダーロックインが生じ、AI活用推進のボトルネックになっていると分かりました。 学んだこと 「ボイラープレートの自動生成」「単純だが広範な一括修正」「要約・逆引き」はAIの得意分野です。ここを主戦場に据えると、費用対効果は安定します。 一方で、非決定性と忘却の問題を抑え込めば、AI活用の適用範囲は広がります。プロンプトやコンテキストの小手先の最適化に偏るよりも、静的解析やユニットテストで出力を厳密に検証できる土台の強化に重きを置くべきだと考えます。期待値をコードで固定できれば、エージェントは失敗に一貫して反応し、自己修復ループに乗りやすくなります。 まとめ AIは「補助輪」です。走り出しを助け、速度を上げ、転びにくくし、学びを加速します。ただし、進むべき方向を決めるのは人間です。 できること／できないことをチームで共有し、使いどころを明確にする。こうした地道な運用こそが、いま現場で効いています。次は、この運用を標準化し、対象領域を段階的に拡大していくことが重要だと考えます。 参考文献 www.businessinsider.com techcrunch.com www.businessinsider.com Windsurf「約95%はCascade/Tabで」—LDX3講演スライド Lost in the Middle—TACL/論文（Liu et al., 2023）

はじめに こんにちは。楽楽請求でバックエンド開発を担当しているmarumoです。 楽楽請求は2024年10月にサービスを開始した新サービスで、請求書を一元管理し、経理業務を効率化する請求書受領システムです。 その中で、請求書の内容をデータ化するために OCR エンジンの API を活用し、自動データ化機能を提供しています。 請求書の自動データ化は、楽楽請求の中核を担う機能です。 サービスの価値を支えるこの仕組みを安定かつ効率的に動作させるためには、大量の請求書を迅速に処理できることが欠かせません。 大量の請求書を確実に捌くため、OCR エンジンの API 呼び出し処理は高並列化を前提に構築しました。 しかし、高並列処理の負荷検証中に「CPU やメモリは安定しているのに、スレッド数だけが増え続ける」という現象に遭遇しました。 本記事では、その原因をどのように特定し、どのように解決したのかを紹介します。 はじめに 利用技術 背景：スレッドが増え続ける 調査 解決策：HTTP クライアントの再利用 Before：毎回生成していたケース After：シングルトンで再利用するケース 検証 検証目的 検証方法 検証結果 結論 まとめ 利用技術 本記事で扱う実装は Spring Boot をベースにしています。主に利用している技術スタックは以下の通りです。 アプリケーションフレームワーク : Spring Boot 3.5 HTTP クライアント : RestTemplate（内部実装として Apache HttpClient 4 系を使用） この記事では、これらの技術を前提にHTTP クライアントのライフサイクル管理に起因するスレッド増加問題とその解決策を解説します。 なお、本文中のサンプルコードは Kotlin で記載していますが、問題の本質は言語に依存しません。 背景：スレッドが増え続ける OCR エンジンの API 呼び出し処理の負荷試験として、50 並列で OCR API を呼び出す構成に対して 500 ファイルを同時にアップロードしました。 すると CPU やメモリには大きな問題がないにもかかわらず、JVM のライブスレッド数だけが直線的に増加し、最終的には 1,000 を超える状態に達しました。 調査 最初に疑ったのは外部 API の遅延やハングでしたが、Thread Dump を確認すると RUNNABLE 状態の短命スレッドが大量に存在しており、この仮説は否定されました。 さらに Thread Dump を詳細に解析したところ、 java.net や org.apache.http に関連するスレッドが多数存在していることが分かりました。 これらは HTTP クライアントの内部スレッドであり、RestTemplate の利用に伴うものです。 HttpClient-2-SelectorManager@19,900 in group "main": RUNNING HttpClient-3-SelectorManager@19,902 in group "main": RUNNING HttpClient-32-SelectorManager@19,942 in group "main": RUNNING HttpClient-34-SelectorManager@19,944 in group "main": RUNNING HttpClient-35-SelectorManager@19,946 in group "main": RUNNING HttpClient-36-SelectorManager@19,949 in group "main": RUNNING HttpClient-37-SelectorManager@19,950 in group "main": RUNNING ... ... ... 解決策：HTTP クライアントの再利用 採用した方針は、 HTTP クライアントを再利用可能な形で管理すること です。 具体的には以下を実施しました。 RestTemplate を シングルトン Bean として定義 呼び出し側での build() 呼び出しを廃止し、DI 渡しのインスタンスを利用 Before：毎回生成していたケース この場合、リクエストのたびに HttpClient が新規生成され、内部で SelectorManager や Worker スレッドも作られるため、スレッド数が累積していきます。 class OcrServiceFactoryImpl { fun createRestTemplate(): RestTemplate { // 毎回 build() を呼び出して新しい HttpClient を生成 return RestTemplateBuilder() .setConnectTimeout( Duration .ofSeconds( 5 )) .setReadTimeout( Duration .ofSeconds( 30 )) .build() } fun callOcrApi(request: OcrRequest): OcrResponse { val restTemplate = createRestTemplate() return restTemplate.postForObject( "https://example.com/ocr" , request, OcrResponse :: class .java) !! } } After：シングルトンで再利用するケース この構成では RestTemplate がアプリケーション全体で 1 インスタンス共有されるため、内部の HttpClient も再利用され、スレッド数が増え続ける問題が解消される。 @Configuration class RestTemplateConfig { @Bean fun restTemplate(builder: RestTemplateBuilder): RestTemplate { return builder .setConnectTimeout( Duration .ofSeconds( 5 )) .setReadTimeout( Duration .ofSeconds( 30 )) .build() } } @Service class OcrService( private val restTemplate: RestTemplate ) { fun callOcrApi(request: OcrRequest): OcrResponse { return restTemplate.postForObject( "https://example.com/ocr" , request, OcrResponse :: class .java) !! } } 検証 検証目的 RestTemplate をシングルトンに変更した構成で、HTTP 通信が直列化していないか（並列性を維持しているか）を確認する 併せて、以前発生していた「スレッド数が通信ごとに増加する問題」が解消されているかを確認する 検証方法 以下を観測しました - RestTemplate の通信ログ（DEBUG）によるリクエストの並列性 - Grafana の jvm_threads_live_threads メトリクスによるスレッド数の挙動 - IntelliJ の Thread Dump によるスレッドの状態（処理中と処理完了後の2タイミング） 検証結果 スレッド数の挙動 修正前：アップロードのたびに HttpClient-SelectorManager が増加し、 jvm_threads_live_threads が400超に 修正後： RestTemplate の使い回しにより、スレッド数は一定値（100前後）で安定し、増加し続ける挙動は再現されなかった Thread Dump 通信中は HttpClient-1-SelectorManager が RUNNABLE 状態で非同期処理を担当 通信後も同一スレッドが残存していたが、新規増加は見られず再利用が確認された 並列性 通信ログのタイムスタンプを比較すると、複数のスレッドが同時にリクエストを発行しており直列化はされていない レスポンス順序もランダムで、リクエストが並列で処理されていることを確認 // リクエスト開始ログ 2025-04-15 10:49:26.204 DEBUG 1 --- [pool-5-thread-6] o.s.web.client.RestTemplate : HTTP POST https://example.com/ocr 2025-04-15 10:49:26.204 DEBUG 1 --- [pool-5-thread-7] o.s.web.client.RestTemplate : HTTP POST https://example.com/ocr 2025-04-15 10:49:26.204 DEBUG 1 --- [pool-5-thread-4] o.s.web.client.RestTemplate : HTTP POST https://example.com/ocr 2025-04-15 10:49:26.204 DEBUG 1 --- [pool-5-thread-5] o.s.web.client.RestTemplate : HTTP POST https://example.com/ocr ... // レスポンスログ 2025-04-15 10:49:31.756 DEBUG 1 --- [pool-5-thread-7] o.s.web.client.RestTemplate : Response 200 OK 2025-04-15 10:49:31.929 DEBUG 1 --- [pool-5-thread-5] o.s.web.client.RestTemplate : Response 200 OK 2025-04-15 10:49:32.029 DEBUG 1 --- [pool-5-thread-6] o.s.web.client.RestTemplate : Response 200 OK 2025-04-15 10:49:32.871 DEBUG 1 --- [pool-5-thread-4] o.s.web.client.RestTemplate : Response 200 OK 結論 RestTemplate をシングルトンにしたことで、内部の HttpClient も共有され、 通信スレッドの再利用が有効に働いた その結果、 スレッド数が通信ごとに増加する問題は解消 HttpClient-1-Worker-* および HttpClient-1-SelectorManager のスレッドが再利用されていることが Thread Dump により確認され、リソースの安定性が確保された まとめ 今回の事例、 HTTP クライアントのライフサイクル管理不足がスレッド増加の原因になり得る という点が明らかになりました。 RestTemplate をシングルトン化し用途ごとに分離することで、リソースの再利用・安定性・性能の維持を実現しました。

はじめに こんにちは。メールディーラーAI開発課のmarronです。エンジニアブログ初投稿となります。よろしくお願いします。 私が所属しているメールディーラーAI開発課では、主にメールディーラーに搭載されるAI機能の開発を担当しています。 現在は10月にリリース予定の回答自動生成エージェントの開発を進めています。 この機能を開発するにあたって、新たにベクトルDBを利用したナレッジの検索機能が必要となりました。 本記事では、ベクトルDBでの検索精度を上げるために導入したハイブリッド検索についてご紹介します。 はじめに ベクトルDBの選定 ベクトルDBとは メールディーラーで採用したベクトルDB 密ベクトルを用いた検索 Qdrantでの密ベクトル検索 密ベクトル検索の欠点 疎ベクトルを用いた検索 疎ベクトルとは Qdrantでの疎ベクトル検索 両方の検索結果を組み合わせるハイブリッド検索 密ベクトルと疎ベクトルの両方を活用する Qdrantでのハイブリッド検索 まとめ 参考文献 ベクトルDBの選定 ベクトルDBとは そもそも「ベクトルDBとはなんぞや」という方もいらっしゃると思いますので、簡単に説明させていただきます。 開発中の機能では、過去の対応履歴やFAQをもとに作成したナレッジから問い合わせの回答に必要となる情報を検索します。 ナレッジの検索には全文検索を利用したキーワード検索を用いても良いのですが、キーワード検索の場合は問い合わせに含まれるキーワードがナレッジに含まれるキーワードと少しでも異なると情報がヒットしません。 この問題を解決するために、ナレッジや問い合わせを数値ベクトル化してベクトルの近さによる検索を行います。この数値ベクトルは、文章全体がどういった意味を示しているかを多次元で表したものになります。 検索時はベクトル同士の距離を測ることで、距離が近い = 意味が似ているデータを見つけることができます。ベクトル化（埋め込み表現）については参考文献もご参照ください。 このベクトルデータを保存するのに利用するのがベクトルDBになります。ベクトルDBはベクトルデータを保存することに特化しており、膨大なベクトルデータ同士の距離計算を効率よく高速に行ってくれるものになります。 メールディーラーで採用したベクトルDB メールディーラーでベクトルDBを利用するのは2回目なのですが、前回採用したChromaDBでは今回の機能を提供するにあたってパフォーマンス面で不安がありました。 そのため、別途ベクトルDB専用のサーバを構築することにしました。 利用するDBを選定するために以下のような条件を満たす製品を探すことにしました。 オンプレミス環境で動作すること マルチテナント構成に対応できること 複数台サーバを用いた負荷分散が行えること この条件を満たす製品として「Milvus」「Qdrant」「PGVector」を候補として、パフォーマンスや使いやすさを比較しました。 結論としてはタイトルにもある通り、Qdrantを採用することにしました。理由は下記の通りです。 Rust製で、高速に検索が行えることを謳っている Dockerコンテナだけでなく、単体バイナリとしても配布されており、オンプレミスのサーバに導入しやすい マルチテナントでの運用方法がドキュメントに記載されており、インデックスの最適化方法まで記載されている 簡単な設定で分散環境を構築することができる 利用するベクトルDBが決定したので、実際に利用してみます。 密ベクトルを用いた検索 Qdrantでの密ベクトル検索 最初に説明した文章全体の意味合いを示したベクトルデータを密ベクトル（Dense Vector）と呼びます。まずはこの密ベクトルを利用した検索を行ってみます。 ベクトルデータを投入するためにQdrant上にコレクションを準備します。 今回のサンプルコードはすべてPythonで記載しています。また、Qdrant公式のDockerイメージを利用して環境を構築しています。 from qdrant_client import QdrantClient, models qdrant = QdrantClient(url= "http://localhost:6333" ) qdrant.create_collection( collection_name= "dense_collection" , vectors_config=models.VectorParams(size= 1536 , distance=models.Distance.COSINE) ) size にはベクトルデータの次元数を指定します。今回はOpenAIのEmbeddings APIによるベクトル化を行い、モデルに text-embedding-3-small を利用するため、1536次元を指定しています。 distance にはベクトルデータの距離計算に利用する方式を指定します。今回はテキストの類似度を調べるのに最適とされるコサイン類似度を指定しています。 コレクションが作成出来たら、検索対象のデータを保存します。今回はChatGPTを利用して、5つの猫種の特徴を20件ずつ文章にしてもらい、計100件のデータを投入しました。 アメリカンショートヘアは筋肉質である。 スコティッシュフォールドは耳が折れている猫である。 メインクーンは世界最大級の猫である。 シャムは社交的な猫である。 ペルシャは長毛の猫である。 ... from qdrant_client import QdrantClient, models from openai import OpenAI qdrant = QdrantClient( "http://localhost:6333" ) openai = OpenAI() with open ( "cat.txt" , "r" , encoding= "utf-8" ) as f: for idx, line in enumerate (f): line = line.strip() response = openai.embeddings.create( input =line, model= "text-embedding-3-small" ) vector = response.data[ 0 ].embedding qdrant.upsert( collection_name= "dense_collection" , points=[ models.PointStruct( id =idx, vector=vector, payload={ "text" : line} ) ] ) Qdrantではベクトル以外のデータをpayloadという形式で保持します。今回はベクトル化対象の文章をpayloadに保持するようにしています。 準備が出来たので、投入したデータに対して検索を行ってみます。 from qdrant_client import QdrantClient, models from openai import OpenAI qdrant = QdrantClient( "http://localhost:6333" ) openai = OpenAI() query = "穏やかな性格の猫" response = openai.embeddings.create( input =query, model= "text-embedding-3-small" ) vector = response.data[ 0 ].embedding search_result = qdrant.query_points( collection_name= "dense_collection" , query=vector, with_payload= True , limit= 5 ) for point in search_result.points: print (f "Score: {point.score}, Text: {point.payload['text']}" ) 実行結果がこちらになります。 Score: 0.6045555, Text: メインクーンは落ち着いた雰囲気を持つ猫である。 Score: 0.59054977, Text: ペルシャは優雅な雰囲気を持つ猫である。 Score: 0.565565, Text: ペルシャは静かな生活を好む猫である。 Score: 0.55805016, Text: ペルシャは穏やかな性格である。 Score: 0.5490287, Text: スコティッシュフォールドは静かな環境を好む猫である。 無事似ている文章を検索することが出来ました。 このときのスコアはベクトルの類似度を示しており、コサイン類似度を利用した時は値が大きいものほど似ていることを示しています。 密ベクトル検索の欠点 密ベクトルを利用した検索では文章が似ているかどうかに着目して検索を行います。 このとき、あくまで類似度に着目して検索を行うため、全く同じキーワードを含んでいるかには着目していません。これが弱点となるパターンがあります。 例えば、「○○ではAボタンを決定として使う」と「××ではBボタンを決定として使う」というナレッジがあったとします。 このときに「○○ではどのボタンが決定ですか？」という問い合わせがあった場合に前者の情報を使いたいのにもかかわらず、後者の情報を取得する可能性があります。これでは回答文として利用できません。 そこでキーワード検索と同じ仕組みをベクトル検索でも行えるようにします。 疎ベクトルを用いた検索 疎ベクトルとは キーワード検索を行うためには文章内にどのような単語が含まれているかを知る必要があります。そこで利用するのが疎ベクトル（Sparse Vector）になります。 密ベクトルではベクトル内の値が0以外であることが多いのですが、疎ベクトルでは単語の頻出度や決まった単語との類似度を示すため、ベクトル内の値が0であることが多いです。そのため、値がスカスカのベクトルという意味で疎ベクトルと呼ばれます。 疎ベクトル同士を比較することで単語ごとの頻出度を調べ、検索したいキーワードが多く含まれる文章を取り出すことが出来ます。 Qdrantでの疎ベクトル検索 Qdrantでは1つの文章に対して、密ベクトルと疎ベクトルの両方を保持することが出来ます。 ただし、既存のコレクションに対して、保持するベクトルの個数や形状を変更することができないため、新たにコレクションを作成します。 from qdrant_client import QdrantClient, models qdrant = QdrantClient(url= "http://localhost:6333" ) qdrant.create_collection( collection_name= "sparse_collection" , vectors_config={ "dense" : models.VectorParams(size= 1536 , distance=models.Distance.COSINE)}, sparse_vectors_config={ "sparse" : models.SparseVectorParams()} ) 次に密ベクトルと一緒に疎ベクトルを投入します。 密ベクトルはOpenAI APIを利用することで生成することが出来ますが、疎ベクトルを生成するAPIは提供されていません。 そのため、疎ベクトル化は自ら行う必要があります。 また、今回疎ベクトル化にはQdrantが提供しているライブラリを採用したのですが、このライブラリは日本語のトークン化（文章の単語を切り分ける処理）に対応していません。そのため、トークン化の処理を自前で実装する必要があります。 疎ベクトル化の処理は参考文献を元に実装しています。今回のサンプルプログラムではこの疎ベクトル化の処理については省略させていただきます。 密ベクトルのところで利用した100件のデータから作成した密ベクトルと疎ベクトルを投入します。 from qdrant_client import QdrantClient, models from openai import OpenAI qdrant = QdrantClient( "http://localhost:6333" ) openai = OpenAI() # TextEmbedderの実装については省略 embedder = TextEmbedder() with open ( "cat.txt" , "r" , encoding= "utf-8" ) as f: for idx, line in enumerate (f): line = line.strip() response = openai.embeddings.create( input =line, model= "text-embedding-3-small" ) dense_vector = response.data[ 0 ].embedding sparse_vector = embedder.embed_query(query_text=line) qdrant.upsert( collection_name= "sparse_collection" , points=[ models.PointStruct( id =idx, vector={ "dense" : dense_vector, "sparse" : models.SparseVector( indices=sparse_vector.indices.tolist(), values=sparse_vector.values.tolist(), ) }, payload={ "text" : line} ) ] ) 疎ベクトルだけを使って検索を行ってみます。 from qdrant_client import QdrantClient, models from openai import OpenAI qdrant = QdrantClient( "http://localhost:6333" ) openai = OpenAI() query = "穏やかな性格の猫" # TextEmbedderの実装については省略 embedder = TextEmbedder() sparse_vector = embedder.embed_query(query_text=query) search_result = qdrant.query_points( collection_name= "sparse_collection" , query=models.SparseVector( indices=sparse_vector.indices.tolist(), values=sparse_vector.values.tolist() ), using= "sparse" , with_payload= True , limit= 5 ) for point in search_result.points: print (f "Score: {point.score}, Text: {point.payload['text']}" ) 実行結果がこちらになります。 Score: 2.0, Text: スコティッシュフォールドは穏やかな性格である。 Score: 2.0, Text: ペルシャは穏やかな性格である。 Score: 2.0, Text: アメリカンショートヘアは穏やかな性格である。 Score: 2.0, Text: メインクーンは穏やかな性格である。 Score: 1.0, Text: メインクーンは子どもと仲良くできる猫である。 単語単位で似ている文章が取り出せていることが分かります。 このときのスコアは似ている単語がどの程度文章に含まれているかを示しています。 両方の検索結果を組み合わせるハイブリッド検索 密ベクトルと疎ベクトルの両方を活用する これで文章の類似度による検索とキーワードを利用した検索を行えるようになりました。 この2種類の検索方法は互いの弱点を補うものですので、検索結果を統合することで精度を上げることが出来ます。 問題はこの2つの検索結果をどうやって統合するかです。それぞれの検索結果を元に類似度が高い文章を取り出したいので、それぞれのスコア（順位）から再度スコア計算を行う必要があります。 この仕組みをハイブリッド検索と呼びます。ハイブリッド検索を簡単に行える方法をQdrantが提供していますので、実際に使ってみます。 Qdrantでのハイブリッド検索 Qdrantでハイブリッド検索を行う場合、まず prefetch という機能で先に密ベクトル、疎ベクトルのそれぞれの検索結果を作成しておきます。 その後、検索結果を統合するために検索クエリに fusion を指定します。このとき、統合する方法にはRRF手法とDBSF手法を利用できます。 RRF手法は検索結果の順位に基づいて新しいスコアを計算します。一方、DBSF手法は検索結果そのもののスコアを利用して新しいスコアを算出します。 RRF手法は順位ベースのため、異なる性質を持つベクトル（今回の場合は密ベクトルと疎ベクトル）を比較する際に有効です。そこで今回はRRF手法を採用しました。 逆に、同種のベクトルで内容が異なる複数の検索結果を統合する場合には、DBSF手法の方が適していると考えられます。手法の詳しい内容については参考文献をご参照ください。 では、ハイブリッド検索を実際に行ってみます。コレクションは疎ベクトルの時に作成したものを利用します。 from qdrant_client import QdrantClient, models from openai import OpenAI qdrant = QdrantClient( "http://localhost:6333" ) openai = OpenAI() query = "穏やかな性格の猫" response = openai.embeddings.create( input =query, model= "text-embedding-3-small" ) dense_vector = response.data[ 0 ].embedding # TextEmbedderの実装については省略 embedder = TextEmbedder() sparse_vector = embedder.embed_query(query_text=query) search_result = qdrant.query_points( collection_name= "sparse_collection" , prefetch=[ models.Prefetch( query=dense_vector, using= "dense" , limit= 5 ), models.Prefetch( query=models.SparseVector( indices=sparse_vector.indices.tolist(), values=sparse_vector.values.tolist() ), using= "sparse" , limit= 5 ) ], query=models.FusionQuery(fusion=models.Fusion.RRF), with_payload= True , limit= 3 ) for point in search_result.points: print (f "Score: {point.score}, Text: {point.payload['text']}" ) 検索結果を統合するため、prefetchで取得する件数は最終的に必要な件数より大きくしておく必要があります。prefetchの取得件数が少ないと統合した際にどちらかのベクトルに偏ったデータも取得されてしまいます。 実行結果がこちらになります。 Score: 0.53333336, Text: ペルシャは穏やかな性格である。 Score: 0.5, Text: メインクーンは落ち着いた雰囲気を持つ猫である。 Score: 0.5, Text: スコティッシュフォールドは穏やかな性格である。 文章の類似度と単語単位での類似度を元に文章が取り出せています。 このときのスコアはそれぞれのベクトルでの順位を元に算出されたものとなります。 まとめ Qdrantを利用したハイブリッド検索を活用することで、ナレッジの検索精度を向上させました。 みなさんもRAGのような文章検索を行う場面がありましたら、ぜひハイブリッド検索を利用した精度向上を行ってみてください。 参考文献 atmarkit.itmedia.co.jp qdrant.tech qiita.com dev.classmethod.jp

はじめに こんにちは。楽楽明細開発チームのtkktです。 楽楽明細は2013年のサービス開始以来、10年以上の運用を続け、現在では1万を超えるお客様にご利用いただいています。 しかし、この成長の裏側では、長年の機能追加や複雑化による技術的負債が蓄積し、 新機能追加のたびに調査やテスト工数が増大するなど、サービスの成長スピードを阻害する課題に直面していました。 今回は、その課題を乗り越えるために取り組んだシステム刷新の一部をお話ししたいと思います。 目次 刷新の背景 実際の取り組み リリース後の課題と改善 成果と効果 今後の展望 まとめ 刷新の背景 長年の運用により、システムには以下のような課題が生じていました。 古いフレームワーク利用によるリスク サポート終了が迫り、セキュリティリスクが高まっていた 周辺のミドルウェアやライブラリのバージョンアップも妨げられていた 開発効率の低下 度重なる機能追加によりコードが複雑化 影響調査やテストに多くの工数が必要 本番環境での障害やインシデントも少なくなかった 当初の開発メンバーが離職しており、仕様把握が難しくなっていた 顧客数増加による影響 操作の多様化でこれまで出なかった不具合が顕在化し、障害対応工数が増加 クラスタ数の増加でリリース時間も長くなっていた さらに、手動テスト中心だったため、開発全体の工数に占めるテスト工数の比率が大きくなり、改善活動に時間を割けない状況もありました。 こうした背景から「今後の安全性・開発効率を確保するには刷新が必須」となり、プロジェクトが動き出しました。 実際の取り組み 刷新の第一歩として、利用者が限定的な一部機能を対象にしました。 セキュリティリスクが高く、既存システムからの切り離しが容易だったためです。 移行は二段階で実施しました。 第1弾 ：既存アプリ内の処理を新フレームワークに書き換え、まずは安定稼働を実現 第2弾 ：本体アプリから切り離して独立稼働させ、フロントで受けたリクエストを新アプリに振り分ける構成に変更 段階的なシステム刷新のイメージ この二段構えにより、障害や不具合発生のリスクを抑えつつ、新基盤への移行を進めることができました。 リリース後の課題と改善 第1弾リリース直後には、想定外の問い合わせや不具合対応に苦労しました。 特に、利用者環境に依存する問題（ブラウザ拡張機能やセキュリティソフトの影響など）が発生し、リクエストがアプリに届かないケースでは原因調査に時間を要しました。 チームでは、問い合わせいただいたお客様に協力いただき、スクリーンショットやコンソールログを取得して原因を特定するなど、地道な調査を重ねました。 その経験を踏まえ、以降はフロントエンドの操作状況やエラーを分析できる仕組みを導入。さらに次の段階では、システムの監視基盤を強化し、不具合の早期発見と原因特定をしやすくする取り組みを進めています。 成果と効果 刷新の効果は、コード品質やテスト体制の改善に顕著に表れています。 コードの複雑度が大幅に改善 刷新前は数十クラスで「変更すると誤修正を招きやすい」と評価される状態 刷新後はそうした箇所がほぼ解消され、多くのクラスが低い複雑度に テスト体制の強化 リリース前はテストの大半が手動で、カバレッジは全体で30％程度 刷新部分では自動テストを整備し、カバレッジが80％を超える水準に向上 フロントエンドとバックエンドを分離したことで、テストのしやすさも格段に向上 刷新直後は不具合対応が発生しましたが、マイナーリリースを重ねて早期に収束。現在ではアプリケーション起因の不具合は減り、安定性が高まっています。 今後の展望 刷新はまだ道半ばです。 今後は、サポートが終了していくフレームワークやライブラリを計画的に置き換えるとともに、アーキテクチャの刷新にも取り組んでいきます。 機能や要件によっては、新しいサービス基盤への移行も視野に入れています。 また、アプリケーションの稼働環境についても改善を進め、より柔軟かつ効率的に運用できる仕組みを整備する予定です。 さらに、組織全体としてもAIを積極的に活用しており、刷新の過程でも開発効率化や品質向上に役立てていく方針です。 まとめ 今回紹介した取り組みは、まだ刷新プロジェクトの一部に過ぎません。 今後も継続して改善を進め、お客様により安心して利用いただけるシステムを目指すとともに、開発者にとっても挑戦しがいのある環境を築いていきます。

こんにちは、株式会社ラクスでデザイナーをしているかっつです。 今回は私が所属しているプロダクトデザイン3課でデザインレビューを始めることになった話をご紹介します。 デザインレビューをする文化がなかったところからなぜ始めることになったのか、 上手く行っていること・行かなかったことなどお話しします。 これからデザインレビューをチーム内で始めようとしている方の参考になれば嬉しいです。 1. デザインレビューを始めるきっかけ 2. どう始めたか いきなりレビューではなく、まず輪読会から レビュー用フォーマットの導入 3. 上手くいったこと 議論が建設的になった 副次的にチームの課題を解決できた 4. 課題とこれから 5. まとめ 1. デザインレビューを始めるきっかけ ラクスのデザイナーはそれぞれが担当するプロダクトを持ち、デザインを進めています。 その状況もあり、プロダクトをまたいだレビューの機会はあまりありませんでした。 ただ最近、課内で案件の進捗を共有する時間が設けられるようになり、そこで偶発的に「そのデザイン、こうしたらもっと良さそう」と意見を言い合ったり、議論が生まれるようになってきました。 また、採用が進んでメンバーが増えてきたこともあり自然と「レビュー」の必要性が高まっていきました。 とはいえ、お互いに「レビュー」に対する認識が揃っていなかったので、フィードバックがしづらかったり、受け取り方にズレが出てしまうこともありました。 そこで、私たちは課として「デザインレビュー」を正式に始めることにしました。 目的は大きく2つあり、 1つ目は楽楽シリーズ全体のデザイン品質を高めること。2つ目はレビューを通してお互いに学び合い、スキルを高めていくことです。 2. どう始めたか いきなりレビューではなく、まず輪読会から 「レビュー」に対する認識やお作法をそろえるために、まずは 『みんなで始めるデザイン批評』 という本を使って輪読会を始めました。 みんなではじめるデザイン批評―目的達成のためのコラボレーション&コミュニケーション改善ガイド 作者: アーロン・イリザリー , アダム・コナー ビー・エヌ・エヌ新社 Amazon 輪読会の目的は、本の内容を理解することよりも以下を重要視しています。 みんなが何に関心を持っているか どんなところでつまずきやすいか 「レビュー」という言葉をどう解釈しているか こうした違いを理解して、お互いの認識のズレを解消することを意識しました。 本という共通のオブジェクトがあることで、「Aという事例を見て自分はこう解釈した」と話せるので、議論がとてもスムーズになります。これがないと、同じ言葉を使っていても実は違うイメージで話している…なんてことが起きてしまいます。 輪読会では何を議論したいかをグルーピングして議論していきます 実際に輪読会をしてみると、 「レビューって承認のことだと思っていた」 「人柄がわからない相手には意見しづらい」 「デザインレビューは手段にすぎなく、担当外のスプリントレビューに他デザイナーも入るで良いのでは？」 「ファシリテーションスキルが大事になる。どうしたら伸ばせる？」 など、想定していなかった課題や施策も見えてきました。これらは輪読会の時間の中で一つずつ解決を試みました。 輪読会で議論した様子 ※輪読会の効果や具体的な進め方は別の記事で紹介しようと思います。 レビュー用フォーマットの導入 輪読会を重ねる中で「仕組み化した方がいいよね」という流れになり、レビュー用のフォーマットを作ることにしました。 このフォーマットは、輪読会で出てきた「これだけは大事にしたい」という要素を集めて型化したものです。 レビュールールとフォーマット また運用ルールも作成しました。 事前にNotionに書き込んでチャットで連絡 週2回レビュー用の時間を確保して、利用しても良い時間にする Notionの起票場所 私たちのレビューの特徴は、 承認フローではなく「意見交換の場」として位置づけていること です。 最終的なオーナーシップはあくまでデザイナー本人にあり、レビューはより良くするためのヒントを持ち寄る場としています。 3. 上手くいったこと 実際にデザインレビューを始めるにあたり、いくつかのことが改善されました。 議論が建設的になった 今までは案件の共有の中でデザインレビューが偶発的に行われていたので、論点があっちこっちに行っていました。 それがレビューフォーマットを導入したことや、レビューへの概念が認識統一されたことで、コミュニケーションが建設的になりました。 結果として、レビューを依頼する人は欲しい情報を持って帰れるようになりました。 副次的にチームの課題を解決できた 前述した通り、デザインレビューをする前段の部分である相互理解、そもそものファシリテーションスキルをどう高めるかといった部分まで議論ができ、それに向けてアクションをすることができました。 特に相互理解の部分は、お互いの過去の経験や得意なこと・苦手なことなどを知る良い機会となり、チームで協業する土台を作ることができました。 ※『実際にあなたのチームは機能していますか』という本では、信頼の欠如がチームの機能不全となる要因と書かれており、お互いの歴史や強みを知ることは効果的とされています。 あなたのチームは、機能してますか？ 作者: パトリック・レンシオーニ 翔泳社 Amazon 4. 課題とこれから もちろん、課題もまだあります。 一番大きいのは、 レビューが任意であるため、参加や活用にばらつきがあることです。 困ったときに声をかけやすくなったという良い変化はあるものの、「楽楽シリーズ全体のデザイン品質をどう高めるか」という視点で見ると、デザイナー個人の意思に依存してしまっているのが現状です。 ただし、レビューは「チェックの門番」ではなく、あくまで品質を高めるための一つの手段だと私たちは考えています。 強制力を持たせるとスピードも落ちてしまい、本来の目的からずれてしまう恐れがあります。 だからこそ、課としてデザイン品質をどう担保していくのか方針を決めて、デザインレビューの位置付けを決めていく必要があります。 最終的には、レビューという時間の意識もなくなり、気軽に相互に聞いて改善する意識が根付いていくとより良いなと感じています。 5. まとめ まだ始めたばかりで試行錯誤の連続です。完璧なレビュー文化は一朝一夕には作れませんが、小さく試して改善していくことを目指しています。 課題もたくさんありますが、それも含めてチームで取り組んでいることが、私たちのチームらしさだと思っています。 こういう文化を大切にしているチームで一緒に働きたい人はぜひお声がけください！ career-recruit.rakus.co.jp

こんにちは。40代インフラエンジニアのAと申します。 今回は今さらながら、 Kubernetesを勉強し始めた エンジニアのポエムになります。 あまり技術的な内容はありませんがご容赦ください。 経歴 手作業のインフラの時代 新しい時代の幕開け、そして焦り 重い腰を上げ下げしてようやくKubernetesへ 金はかけるがコスト感をもつ （参考）AWSのマニュアルにあるゲーム（2048）をデプロイしてみる 難しく考えず、実は根本はあまりかわらないよ おわりに 経歴 私はエンジニア歴20年以上の世間では「ベテラン」といわれるインフラエンジニアで 経歴としてはSIerでOSインストールや機器設定を現場でがむしゃらにこなす所から始まり、 SaaS業界で運用を経て、昨今はオンプレ機器の導入・設計をリードする立場で働いてまいりました。 また、現在の会社は在籍年数も10年以上と長く、何やらベテラン臭のする、 「発言ばかりが目立つベテラン社員」に何となく居座っている状況でありました。 手作業のインフラの時代 少し時代をさかのぼりますが、20年前のインフラは手作業と物理作業が当たり前でした。 データセンターで徹夜のサーバチューニング、手動でのシステム再起動、 無駄に長いストレージのビルドを待ちながらの仮眠。 エンジニアのとてつもない長時間労働によって、システムの安定稼働が支えられていた時代です。 しかし、そんな私が長年培ってきた「手作業のインフラの時代」は、 多様な選択肢の中から最適なソリューションを設計することが求められる時代になっていました。 これまで自分が拠り所としてきた経験そのものが、 時代遅れになってしまうのではないかという不安 を抱かせるには十分すぎる変化でした。 新しい時代の幕開け、そして焦り グローバルクラウドが席巻したかと思えばコンテナが時代の旗手となり 世の中はIaC（Infrastructure as Code）の時代の幕開けとなっていました。 作業の自動化、人的ミスのない再現性、バージョン管理、 我々が苦労して手動で支えてきた内容が、 今ではきれいにコードで完結 するようになってきました。 新しく業界に入ってくる若者たちはこれが当たり前かのように周りにある時代、刷新された知識で業務をこなし始めていきます。 そんな中でベテランと名の付く座に安座しているのであれば、 偉そうにこれらの知識も「どや顔」で弁舌しなければメンツを保てないわけで、 ChatGPTとかで非常に表面的に「コンテナのメリットとは？」みたいに調べて知った気になって、 「何となくどこでも動かせるポータブルな技術だよね。お前ら、まだ手動でやってんのか？」 と「どや顔」で言ってはいるものの、 実は自分は何も動かしたことがない虚構の存在になりつつある自分がいました。 そんな自分に嫌気がさし、夜中にふと目が覚めると、「コンテナ 初心者」「IaC やり方」と検索窓に打ち込んでは、溜め息をつく日々。 ただ、物理の世界で生きてきたおじさんにはこのコンテナというものが、 どうにも宙に浮いた、つかみどころのない幻のように感じられたのでした。 重い腰を上げ下げしてようやくKubernetesへ 「石の上にも三年」といいますが、重い腰を上げるのに5年かけてようやくKubernetesを勉強する気になりました。 このきっかけといえば、実は異動になって業務で使うことになったことも大きいですが、何よりも、 自分よりも年上のベテランエンジニアがKubernetesを使っていたことが、大きな精神的な転換点 でした。 若い世代に負けることよりも、自分よりも人生の先輩たちが軽々と新しい技術を使いこなしていることに驚きを覚えたのです。 それは、自分自身が長年の経験に胡坐をかき、新しい時代の変化を傍観していたことへの強烈な否定でした。 いつのまにか、自分の得意なインフラは、主流の座を新しい技術に明け渡し大きく様変わりしていました。 若いエンジニアたちの軽快なフットワークについていけない自分を、心の中では「仕方ない」と割り切ろうとしていたのです。 しかしその先輩の姿は、そんな言い訳を打ち砕きました。 積み重ねた経験からくる自信と、新しい知への探究心がそこには見えました。 その時、私はこのままではいけないなと強く感じたのでした。 重い腰は上がりました。そして、Kubernetesという、今まで手をつけてこなかった新しい世界の扉を叩くことにしました。 別に40代からでも遅くはないのです。今からでも大丈夫。 同じような不安や焦りを抱えている方々にとって、少しでも勇気を与えられる存在になれたら幸いです。 金はかけるがコスト感をもつ 細かい技術の話をしてもあれなので私が今も続けられている勉強方法について記載します。 まずは、多少お金をかけることです。 これはジムと同じ理屈で、無料のサービスだけではどうしても甘えが出てしまいます。 多少でもお金を払うことで、「せっかくお金を払ったんだから、元を取るぞ」という気持ちが生まれるからです。 あと、重い本を何冊も買うよりもマシに思えたからです。 ただし、コスト感は徹底的に意識しています。 無駄な出費は避け、できる限り節約するのが自分のルールです。 そんな中で選んだのが、AWSのマネージドサービスである EKS（Amazon Elastic Kubernetes Service） でした。 グローバルクラウドのサービスに触れられるので、まさに一石二鳥。 EKSの裏側にある難しいコントロールプレーンのことは一旦忘れて、まずはとにかく Deploymentを動かしてみる。 そこに重きを置いて、手を動かして遊んでみることにしました。 ※ちなみに、油断するとすぐに1万円に到達してしまうので、かなりの注意が必要です。 常にコストをモニタリングし、不要なリソースはすぐに削除する癖をつけなければなりません。 手始めにやったのは、「Hello, World」のコンテナを動かすことです。 まずは、シンプルなアプリケーションを動かすための Podと、そのPodを管理する Deploymentを作ってみました。 YAMLファイルにたった数行のコードを書くだけで、いとも簡単に立ち上がる。 その瞬間の感動は今でも忘れられません「おお、動いたわ～・・」。 次に、そのコンテナに外部からアクセスできるように Ingress、Serviceを設定しました。 この一連の流れを体験したことで、これまで漠然と「宙に浮いた話」に感じていたコンテナの世界が、 少しずつ現実のものとして手触り感を持つようになりました。 （参考）AWSのマニュアルにあるゲーム（2048）をデプロイしてみる HelloWorldが動かせたら、次は実際にAWSが公開しているサンプルアプリをデプロイしてみると面白いです。 docs.aws.amazon.com アプリのDeploymentはたったこれだけです。ほかにServiceとIngressはありますが、その十数行でkubernetesで実際にゲームが動きよりリアルなイメージとなってきます。たったそれだけで。 ※読むだけではコードの羅列ですが動かすと世界が変わります apiVersion: apps/v1 kind: Deployment metadata: namespace: game-2048 name: deployment-2048 spec: selector: matchLabels: app.kubernetes.io/name: app-2048 replicas: 5 template: metadata: labels: app.kubernetes.io/name: app-2048 spec: containers: - image: public.ecr.aws/l6m2t8p7/docker-2048:latest imagePullPolicy: Always name: app-2048 ports: - containerPort: 80 resources: requests: cpu: "0.5" このYAMLをapplyすればOKです。 kubectl apply -f 02-deployment.yaml あとはブラウザから確認すればゲームが動きます！ 難しく考えず、実は根本はあまりかわらないよ 物理インフラで培った経験は、決して無駄ではありません 。 なぜなら、目に見える物理的な機器から、コードという抽象的な概念に変わっただけで、 サービスを安定稼働させるという本質は何も変わらない からです。 むしろ「ベテラン」は昔ながらの苦労を乗り越えてきたからこそ、新しい技術の効率性や便利さにより深く感動できる。 そう気づいた時、「 時代遅れになってしまうのではないか 」という焦りではなく、新しい知識を手に入れた喜びで満たされていました。 おわりに ということで終始ポエムな記事で物足りなかったかもしれませんが、たまにはこういう記事もありなのかなと。。 現在はGitHubにソースを上げるとGitHub ActionsでECRにイメージが自動で作成されるようになっており、 次はこれ以降のCICDでも作ろうかなと思っています。 わからないことは今やAIにガンガン聞けますし そして何より、 わからないことを恥ずかしがらずに行動することこそが、これからのエンジニアに必要な姿勢 なのだと、あらためて感じています。 もしこの記事が、 少しでも「やってみようかな」と思っている方の背中を押せたなら 、うれしい限りです。

こんにちは！！ラクス技術広報担当です。 2025年8月7日(木)に、オンラインにて「RAKUS Tech Conference 2025」を開催いたしました。平日にもかかわらず、多くの皆様にご参加いただき、大盛況のうちに幕を閉じることができました。登壇者、関係者の皆様、そして何よりご視聴いただいた皆様に、心より感謝申し上げます。 本イベントの開催目的は、私たちラクス開発本部が最も大切にしている 「顧客志向」 という概念を多くの方に知ってもらうことでした。参加後アンケートの結果から、9割の視聴者の方に「ラクスが顧客志向な開発組織であるという印象が伝わった」という回答をいただき、イベントの目的が果たせたことは大変良かったと思います。 各セッションでは、ラクスのサービスが日々どのように顧客と向き合い、その価値を技術で実現しているのか、7つのセッションを通じて開発の裏側にある「強み」や「想い」をお届けしました。 また、クロージングトークではラクス開発本部のAIの取り組みについてご紹介しました。 本記事では、各セッションで語られた内容をダイジェストでご紹介します。 各セッションの紹介 1. 『楽楽電子保存』開発チームが挑む「AI駆動開発」の全貌 2. 数字と感情で語るスクラム導入効果。『楽楽勤怠』開発チームの変革の軌跡 3. 分割と統合で学んだサイロ突破術—『楽楽販売』開発組織10年の軌跡と持続的成長の仕組み 4. 『メールディーラー』へのAI機能実装─”20年”の歴史を持つ製品への導入プロセス 5. 新サービス『楽楽請求』！何を作るかより“なぜ作るか” 顧客価値から逆算する開発現場のリアル 6. なぜ、成熟市場で”売上120%成長”を続けられるのか？『配配メール』の顧客志向型プロダクト開発戦略 7. 『楽楽精算』15年の進化と未来への挑戦 〜経理の”楽”から、すべての働く人の”楽”へ〜 クロージングトーク：AI開発の最前線と未来 おわりに 各セッションの紹介 1. 『楽楽電子保存』開発チームが挑む「AI駆動開発」の全貌 登壇者：楽楽明細開発部 開発2課 小栗 朗、フロントエンド開発課 伊藤 彪我 電子帳簿保存法の改正により市場が3年で3.5倍に拡大する中、『楽楽電子保存』開発チームは、激化する競争を勝ち抜くために「AI駆動開発」による開発プロセス全体の刷新に挑んでいます。 セッションでは、まず設計フェーズにおいて、PMM・PdM・開発者間で分散していたドキュメントをGoogle Docsに一元化し、AIが読み取りやすいよう構造化。AIに設計ドラフトの作成やレビューをさせることで、設計期間を平均30%以上短縮することに成功しました。実装フェーズでは、DevinやGitHub Copilotといった複数のAIツールをタスクに応じて戦略的に使い分け、平均30%の工数削減を実現。さらに、ラクスベトナムとのグローバル開発体制においても、AIによる翻訳やレビュー支援がコミュニケーションコストの削減や業務のボトルネック解消に繋がり、開発力を大きく向上させている事例が紹介されました。 speakerdeck.com 2. 数字と感情で語るスクラム導入効果。『楽楽勤怠』開発チームの変革の軌跡 登壇者：楽楽勤怠開発部 開発1課 加藤 祐也 働き方改革を追い風に市場が成長する一方、圧倒的なマーケットリーダーが不在で競合がひしめく勤怠管理システム市場。後発サービスである『楽楽勤怠』がシェアを拡大するためには、開発スピードとボリュームの向上が必須でした。 そこで白羽の矢が立ったのが、ラクスではまだ主流ではなかった「アジャイル（スクラム）開発」の導入です。本セッションでは、スクラム導入後の具体的な成果が「数字」と「感情」の両面から語られました。数字の面では、リリース案件数が導入後に大幅に増加し、受注件数も過去最高を記録。感情の面では、エンジニアの満足度は10段階中平均8ptと高く、「コミュニケーション頻度が上がった」「チームで助け合いが出来る」といったポジティブな声が多く挙がりました。プロセスの導入だけでなく、失敗を恐れず変化を楽しむマインドの醸成が成功の鍵であることが示されました。 speakerdeck.com 3. 分割と統合で学んだサイロ突破術—『楽楽販売』開発組織10年の軌跡と持続的成長の仕組み 登壇者：楽楽販売開発部 部長 藤井 高志、同 テックリード 山内 覚 年間売上高55億円を超え、SaaS型販売管理システムでシェアNo.1を達成した『楽楽販売』。そのプロダクトの成長を支えてきたのは、10年間にわたる開発組織の変革の歴史でした。 セッションでは、7名体制だった10年前から24名体制の現在に至るまで、組織がどのように変化してきたかが語られました。当初は全員が全ての領域をカバーしていましたが、組織の拡大に伴い、企画、要件、実装といった職能別のチームに分割。しかし、これがチーム間の連携を妨げる「サイロ化」という新たな課題を生み出しました。この課題を乗り越えるため、再び要件から実装、技術負債改善までを一気通貫で担うチームへと統合。日々の接点が多い作業は同一チームで推進すべきであるという学びや、改善の取り組みをチームで推進し、暗黙知を共有する重要性が共有されました。 speakerdeck.com 4. 『メールディーラー』へのAI機能実装─”20年”の歴史を持つ製品への導入プロセス 登壇者：メールディーラーAI開発課 神山 賢太郎、メールディーラー開発課 廣部 知生 2001年に販売開始され、16年連続シェアNo.1を誇る『メールディーラー』。この歴史あるレガシーシステムに、いかにしてAIという新しい技術を迅速に実装したのか、そのプロセスが語られました。 「世はまさにAI戦国時代」 という市場の変化に対し、ビジネスサイドからは「うかうかしているとディスラプトされる」という強い危機感が示される一方、開発サイドではビジネス価値への懐疑的な見方もあり、当初はスピード感にずれがありました。しかし、展示会でAIエージェントへの注目度の高さを目の当たりにし、危機感を共有。ウォーターフォール型開発が主流だった組織の中で、AI開発に特化した課を新設し、完全アジャイル開発にシフト。PMM、PdM、デザイナーが密に連携し、顧客ヒアリングを週1ペースで行いながら高速でPDCAを回すことで、開発スケジュールを大幅に短縮し、価値提供を早めた事例が紹介されました。 speakerdeck.com 5. 新サービス『楽楽請求』！何を作るかより“なぜ作るか” 顧客価値から逆算する開発現場のリアル 登壇者：楽楽請求開発部 開発1課 巽 隆氏、庄禮 有佑 2024年10月にサービスを開始した新サービス『楽楽請求』。ゼロからイチを創り出す過程で直面した、数々の成功と失敗がリアルに語られました。 リリース当初は、ドメイン知識ゼロの状態から書籍や競合サービスの機能分析を基に仮説を立てて開発を進めました（仮説ドリブン）。しかし、リリース後、実業務にそぐわない仕様や、顧客が本当に求めていた機能とのズレが明らかになりました。この経験から、開発プロセスを全面的に見直し、営業やサポートが収集した顧客の声（VoC）を起点とする「VoCドリブン」へと大きく舵を切りました。現在は、2000件を超える要望DBを基に、「何を作るか」よりも「なぜそれが必要なのか」という顧客課題の深掘りを徹底し、顧客が本当に求める価値を提供できる開発体制を築いています。 speakerdeck.com 6. なぜ、成熟市場で”売上120%成長”を続けられるのか？『配配メール』の顧客志向型プロダクト開発戦略 登壇者：ラクスクラウド開発部 配配メール開発課 西尾 敬太 サービス開始から18年目を迎え、国内市場が成熟期にある中で、年間売上成長率120%超を達成し続ける『配配メール』。その力強い成長の源泉は、徹底した「顧客志向型プロダクト開発戦略」にありました。 配配メールは、単なるメール配信ツールから、リード獲得・育成・商談化というマーケティングプロセス全体をカバーするプラットフォームへと進化を遂げてきました。この戦略を支えるのが、「迅速かつ柔軟に価値を届ける」リリース戦略と、「開発者全員が深く顧客を理解する」ための取り組みです。新機能は価値の単位で分割して段階的にリリースし、顧客からのフィードバックを迅速に反映。開発チーム自らが製品を日常的に利用するドッグフーディングや、PMM主催の勉強会を通じて、全部門一体で顧客理解を深める文化を醸成しています。 speakerdeck.com 7. 『楽楽精算』15年の進化と未来への挑戦 〜経理の”楽”から、すべての働く人の”楽”へ〜 登壇者：楽楽精算開発部 開発2課 課長 高波 顕二郎 15年以上の歴史を持ち、導入社数1.9万社を超えるまでに成長した『楽楽精算』。その成長は、電子帳簿保存法やインボイス制度といった法制度ニーズへの迅速な対応によって加速してきました。しかし、その長い歴史は150万行を超えるコードベースや700以上の画面といった技術的負債も生み出し、開発スピードの低下という課題に繋がっていました。 本セッションでは、これまで注力してきた「経理担当者の楽」の実現に加え、今後は経費精算に不慣れな「申請者の楽」も実現すべくUI/UXの根本的な改善に着手していることが語られました。さらに、AIエージェントが自律的に経費精算を行う未来を見据え、レガシーな開発から脱却するための技術戦略として、モダンな新基盤の構築とAI駆動開発を両輪で進める挑戦が紹介されました。 speakerdeck.com クロージングトーク：AI開発の最前線と未来 登壇者： 大阪開発統括部 統括部長 矢成 行雄、東京開発統括部 プロダクト部 副部長 稲垣 剛之、AIエージェント開発課 課長 石田 浩章 イベントの最後には、AI開発を牽引する3名によるクロージングトークが行われました。 ここでは、各プロダクトへのAI機能の実装や、開発本部全体でのAIツール活用など、セッション本編では語りきれなかったテーマについて深掘りしました。 AI開発の組織体制について、ラクスでは単一の部門が集約的に開発するのではなく、各事業部の事情に合わせて多様なスタイルで取り組んでいることが語られました。 例えば、プロダクトマネージャーとデザイナーが所属するプロダクト部では、複数製品を横断する形でAIのロードマップ策定に関与しています。 一方で、新設されたAIエージェント開発課では、事業部直下に開発・営業・CSが一体となったコンパクトなチームを組成し、意思決定のスピードを重視した開発を進めています。 AIの進化に伴いエンジニアに求められるスキルについて、「審美眼」「適応力」「言語化能力」の3つが挙げられました。 AIが生成したアウトプットが本当に正しいかを見抜く力、変化の早い技術や常識を常にアップデートしていく力、そしてAIが理解できる形でコンテキストを的確に伝える力が、今後ますます重要になるとの展望が語られました。 おわりに 改めて、「RAKUS Tech Conference 2025」にご参加いただいた皆様、そしてご協力いただいた関係者の皆様、本当にありがとうございました。 今回のカンファレンスを通じて、ラクスの各プロダクト開発チームが、それぞれの事業フェーズや市場環境の中で、いかに「顧客志向」を貫き、それを実現するために組織や開発プロセスを柔軟に変化させ、新しい技術に挑戦し続けているか、その一端を感じていただけたなら幸いです。 今後もラクスは、「顧客志向のSaaS開発組織」として、お客様の期待を超える価値を提供できるよう、真摯にプロダクト開発と向き合ってまいります。引き続き、ラクス開発本部の活動にご注目ください！

はじめに こんにちは。新卒3年目のymyhero7です。 メールディーラーという自社開発プロダクトの開発チームに所属しています。 入社してすぐの頃は、実装やテストの工程を担当していましたが、新卒2年目から徐々に要件定義を任されるようになりました。もともと就職活動の面接段階から、「どうすればお客様にとって本当に価値のある機能を作れるか」といった上流工程への関心が強く、そうした業務に携わることを希望していました。 そのため、2年目という比較的早い段階から要件定義に関われるようになったときは、非常に嬉しかったのを覚えています！ しかし、意気揚々と始めた要件定義の業務は、想像以上に難しく、苦労の連続でした。作成した要件定義書はレビューで指摘を受けることが多く、大幅な手戻りが発生してしまうことがしばしばありました。 本記事では、そうした経験を通じて学んだ要件定義の進め方のコツや「顧客理解」の重要性をご紹介します。 はじめに 苦戦した要件定義と、繰り返される手戻り チームで取り組んだ改善 顧客ヒアリングを通じて得られた気づき 実践している3つの工夫 おわりに 苦戦した要件定義と、繰り返される手戻り 私の所属する開発チームでは、製品企画チームが作成した要求定義書をもとに、「要望をどのような機能に落とし込むか」を要件定義で検討します。 要件定義を担当し始めた当初、私は「要求定義書に書いてあることをそのまま機能として具体化していけば問題ないだろう」と安易に考えていました。 しかし、実際に書いた要件定義書は何度もレビューで差し戻されました。 特に多かったのは、 「そもそもその機能、本当に必要？」 「他にもっと良いアプローチがあるのでは？」 といった、本質を問う指摘です。 「確かにその通りだ」と納得する一方で、「なぜ最初から気づけなかったのか」と悔しさが込み上げました。さらに、手戻りによって開発が2週間以上遅れることもあり、チームに迷惑をかけてしまったことへの申し訳なさも強く感じました。 振り返ると、その原因のひとつは、要求を表面的にしか理解できておらず、ユーザの本当の困りごとやユースケースを自分の言葉で説明できない状態だったことにあります。 “何を作るか”ばかりに意識が向き、“なぜ作るのか”という視点が欠けていたのです。 この状態では、いくら丁寧に要件定義書を作成しても、ユーザの課題を解決できる良い機能を作ることはできません。 結果として手戻りが発生し、開発の遅延を招き、ユーザへの価値提供も遅れてしまいます。 チームで取り組んだ改善 そんな中で支えになったのが、周囲のチームメンバーの存在です。 失敗に落ち込んでいた私に対し、先輩たちは「まずは製品企画チームに要求の背景を聞いてみよう」「最初にチーム内で機能の方向性をすり合わせるミーティングを開こう」など、具体的で実践的なアドバイスをくれました。 ある先輩エンジニアからは、「完璧にしてから出すのではなく、途中でもいいから一度レビューを依頼してみよう」と助言をもらい、「しっかり仕上げてからでないと見せてはいけない」と思い込んでいた自分の固定観念が変わりました。 また、チームの振り返りミーティングでは、「どうすれば手戻りを減らせるか」について皆で何度も話し合いました。その中で、要件定義に入る前にチーム内で要求を読み合わせ、疑問点を洗い出したり、要件の方針をすり合わせたりすることが、開発プロセスとして明文化されるようになりました。 顧客ヒアリングを通じて得られた気づき あるとき、特定の機能要望について製品企画チームに質問したところ、「それなら実際にお客様に聞いてみよう」と、要望を挙げてくださったユーザに直接ヒアリングする場を設けてくれました。 普段はユーザと直接やりとりする機会がなかった私にとって、ユーザの声を生で聞くことができるのは初めての経験でした。 直接お話を伺う中で、「ああ、これが本当に困っていることなんだ」と心から腑に落ちました。また、製品に対する強い期待や信頼を寄せていただいていることも実感し、より一層の責任感が芽生えました。 それまで私は、製品企画チームは別部署ということもあり、「どこまで相談して良いのか」と遠慮してしまうことがありました。ですが、こうして顧客ヒアリングに同席させてもらえたことで、「分からないことは積極的に相談して、一緒に解決に向かって進めていけばいいんだ」と認識が大きく変わりました。 実践している3つの工夫 こうした経験を通じて、私は以下の3つのポイントを意識しながら要件定義を進めています。 製品企画チームに質問して、ユーザの解像度を上げる 「なぜこの要望があるのか？」「実際にどんな場面で困っているのか？」といった背景を把握するため、製品企画チームに積極的に質問するようにしています。要求を深掘りし、ユーザの抱えている課題を自分の言葉で語れるようになることを目指しています。 まず方針をすり合わせる 要件定義書を書き始める前に、「こういう背景があって、こういう方針で考えています」とチーム内で方向性を相談しています。すぐに要件定義書を書き始めるのではなくて方針が定まってから手を動かすようにしています。また、要件定義書を書き始めてからも、課題があればその都度相談し、徹底的に認識合わせをするように意識しています。 6割の完成度でレビュー依頼を出す 要件定義書は、完璧を目指すよりも6〜7割程度の段階で一度レビュー依頼を出すようにしています。そのほうが早期に改善点を洗い出すことができ、結果として手戻りを減らすことができます。 おわりに 弊社の開発チームでは、「顧客志向」を非常に大切にしています。ユーザへの理解を深め、どのような機能であれば真に価値を届けられるのかを考えることは、その顧客志向の姿勢そのものだと感じています。 また、ユーザへの理解が深まることで、結果的に要件定義工程での手戻りも減り、早く価値を届けられるという好循環が生まれると考えています。 もちろん、要件定義は今でも難しいと感じることがたくさんあり、すべてが順調に進むことはありません。それでも、一つひとつのユーザの課題に真剣に向き合っていくことが、より良いプロダクトづくりにつながると信じています。 最後までお読みいただき、ありがとうございました。

はじめに こんにちは。フロントエンド開発課でチームリーダーをしています、北嶋です。 私が所属する開発部では、開発の 「スピードUP」と「生産性の向上」 を今年度の大きなテーマとして掲げています。 そこに向けて、私のチームでは開発プロセスの中でAI活用を実践していく 「AI駆動開発」 を推進することに、積極的に取り組んでいます。 本記事では、今年度から本格的にAI活用に取り組み始めた私たちが、どのようにAI活用を進めて、どのような成果や学びを得たのか、具体的な事例を交えながらご紹介できればと思います。 まだまだ発展途上ではありますが、私たちが実践してきた取り組みが、開発業務でAI活用をしていきたい方への、何かヒントになれば幸いです。 はじめに どのようにAI駆動開発を進めてきたか ステップ1：KPIの設定 ステップ2：個人での利用とアイデアの共有 ステップ3：チームでの標準化 例①：DevinのAPIを活用したプルリクエストの自動レビュー 例②：Github Projectsによるプロジェクト管理の効率化 背景 AI連携方法 AI連携を試してみた結果 得られた学び おわりに どのようにAI駆動開発を進めてきたか AI駆動開発と聞くと、何か特別なノウハウや技術が必要だと思われるかもしれませんが、私たちのチームでは比較的シンプルに、以下のステップで取り組んできました。 ステップ1：KPIの設定 はじめに、通期でチームとしてどのような状態を目指すかの、KPIの設定を行いました。 最低限でもAI活用方法がチーム内で共有されている状態、更には開発フローに組み込まれている状態をイメージし、以下のようにKPIを設定しました。 チームとして共通のKPIを設定したことで、AI活用の方針にブレが生じにくくなり、取り組むべきアクションも明確になったため、AI活用するに当たってこのようなKPI設定は非常に重要なステップであると感じました。 ①AIツールによる開発効率化で以下の時間短縮を実現していること ・詳細設計：30%以上短縮 ・実装：30%以上短縮 ・単体テスト：40%以上短縮 ②マージされたプルリクエストの50%がAIエージェントが開発したものになっていること ③AI活用のノウハウを標準化して以下の開発フローにプロセス組み込みできていること ・詳細設計：API仕様書作成、画面仕様書作成 ・実装：コードレビュー ・単体テスト：Unitテスト, Integrationテストのテストコード作成 ・結合テスト：E2Eのテストコード作成 ステップ2：個人での利用とアイデアの共有 次に、開発業務でチームメンバーが個々で様々なAIツールを実際に試すことから始めました。 利用した生成AIやAIツールは、ChatGPT, Gemini, Github Copilot, Codex, Devin, 最近だとClaude Codeなど。 その中で 「こんなことができた」「このツールは〇〇が得意そうだ」「こういうことができたら嬉しい」 といった実例や意見、アイディアが次々に出てきたので、それらをカジュアルに共有する場（チャットツール上にチャンネル作成や、対面でのミーティング）を設けて、積極的に情報交換を行うようにしました。 変化の早いAIの流れについていくために大切なのは、いきなり完璧な活用法を求めるのではなく、 「まずは使ってみる」「それを共有してみる」 という文化を醸成することなのかな思いました。 ちなみに私のチームでは、情報共有する際には以下の共通フォーマットで記載してもらうようにしています。 フォーマットを作っておくことで、人によって情報をブレなく共有できるので、これも効果的な取り組みの一つだと実感しています。 ■試してみたこと ①概要 ②利用したAIエージェント（モデル）は何か ③入力（資料やルール等）は何か ④プロンプトは何か ■結果 ①出力結果はどうか ②実用的か ■工夫した点 ■標準化検討 ■参考記事（あれば） ステップ3：チームでの標準化 個人の試行錯誤から有益なアイデアが生まれてくると、次にそれをチームとして 「標準化」 して運用に載せたいよね、という話が出てきました。 現時点で、実際に運用されている事例はいくつかあるのですが、ここでは2つを取り上げて紹介したいと思います。 例①：DevinのAPIを活用したプルリクエストの自動レビュー 私たちのチームで最初に大きな成功を収めたのが、DevinのAPIを活用したプルリクエストの自動レビューです。 GithubのPR上にUserScriptで 「PRレビューを依頼する」 のボタンを配置し、このボタンを押下するだけで、Devin APIを発火させてコードレビューを依頼できるというものです。 （ボタンを画面上に設置してしまう辺りがフロントエンドチームらしいなと思ったりしました笑） 実際にDevinがレビューコメントを付けてくれた一例が、以下の画像です。 プロンプトを工夫することで、インラインでコメントしてくれたり、imo,mustなどの接頭語も適宜付与してくれたり、修正の提案（suggestion）をしてくれたりと、非常に分かりやすく指摘してくれていることが分かるかと思います。 運用としては、実装者が人にコードレビューを依頼する前に、Devinへのコードレビューを一度挟むことで、実際に人がレビューする工数は大幅に削減できたと感じています。 こちらが上手くいった背景には、 もともと「レビュー観点」や「コメントルール」がある程度明文化されていた ことが大きく影響していると、個人的には考えています。 AIは自然言語化された明確なルールや指示があれば、その能力を最大限に発揮してくれるのだなと実感する、良いきっかけになりました。 また、 開発フローの1つの作業を標準化がすることができた という成功体験が生まれたことで、チームとしてAI駆動開発に取り組もうとする姿勢がより一層高まったように思います。 AI活用によって「こんなに便利になるんだ」という体験を実際にすることが、メンバーのAI活用への積極性を駆り立てる原動力になるのだな、身を持って実感しました。 例②：Github Projectsによるプロジェクト管理の効率化 こちらは私が主導して検証を行い、最近運用に乗せたばかりの、GitHub ProjectsとAIを連携させたプロジェクト管理の効率化についての紹介です。 背景 これまでは、Googleのスプレッドシートでプロジェクト管理を実施していましたが、タスク分割や工数計算などで、多くの手作業が発生していました。 セルの計算式が気付かない内に壊れていることも多く「これをAI活用で楽にできないかな」と考えたのが、この取り組みのきっかけです。 Github Projectsでプロジェクト管理を行う方法は様々あると思いますが、まず作りたい機能の詳細を書いておく親のissueの作成を行い、それを実際に必要な作業ごとに子のsub-issueへと分割し、sub-issueを元に実際の作業を進めるというイメージで考えました。 機能issueの作成 タスクsub-issueへの分割 工数の見積もり入力 実装から単体テストの実施 これらの作業をAIにある程度任せられないかと考え、検証を行っていました。 AI連携方法 この頃には、チームではClaude Codeの活用が進められており、 「標準化できそうな作業が見つかれば、カスタムスラッシュコマンドを作成して共有する」 という流れがありました。 ここでも作業をほとんど、カスタムスラッシュコマンド化しています。コマンドの中身の詳細については、社内の情報もあるため載せられないのですが、以下のような流れで実作業を行なっています。 1. 機能issueの作成 以下のコマンドを実施すると、GitHubプロジェクトに新しい機能issueを作成されます。必要なカスタムフィールドについてもAIが自動で設定を行います。 ※ただし、機能の内容については、今は人の手でissueに詳細に記入を行なっています（ここもいずれAI活用をしたい部分です） /create-main-empty-issue <機能名> 2. タスクsub-issueへの分割 以下のコマンドで、作成した機能issueを元に、調査・実装・テストコード作成といった、具体的な作業タスクをsub-issueとしてAIが自動で切り出します。 この時に、AIが判断した「タスク種別」や「重み」を、カスタムフィールドを自動で設定します。 /create-sub-issues <機能IssueのURL> コマンドを実行すると、機能issueの下にタスクsub-issueが分割されて登録され、以下のような状態となります。 3. 工数見積もり 各sub-issueの「タスク種別」や「重み」を元に、あらかじめ定義したルールに従って作業工数・レビュー工数・総工数を算出し、カスタムフィールドに自動で設定します。 /estimate <機能issueのURL> コマンドを実行すると、以下のように見積もり工数に数字が入力されます。これを利用して、今は人がガントチャートの作成を行なっています。 4. 実装〜単体テスト 最後にissueのURLをAIに渡して、実装と単体テストを実施させるという流れになっています。 （ここのやり方は個々に任せている段階なのですが、今後標準化に向けて動いていきたい部分です） AI連携を試してみた結果 結論から言うと、Github ProjectsとのAI連携は、非常に実用的でした。 手作業でissueを作成したり、ラベルを付けたり、工数を見積り入力する手間は確実に削減できました。 ただし、改善点はまだまだ山積みという状態です。 人の目の介入は不可欠 特に実装フェーズでは、AIが途中で意図しない方向に進んでしまうことがあります。 現状では、大きなタスクを丸投げするのではなく、sub-issue単位で一つずつ実行を依頼し、都度人間が確認する必要がある状態です。 インプット（ルール）の質がアウトプットの質を決める タスク分割や見積もりの精度は、まだまだ粗削りなものでした。これは、私たちがAIに渡しているルールや定義がまだ曖昧だからという要因が正直大きいです。 逆に言えば、ルールが明確に自然言語化・整備されているチームほど、AI活用の恩恵をスムーズに受けられるのだろうなと感じています。 検証が終わって実運用を始めたばかりの段階なので、改善点は多くありますが、プロジェクト管理をAIと連携しやすいGitHub Projectsに移行し、運用するための土台は作れた状態となりました。 得られた学び これらの取り組みを通じて、技術的な知見以上に、チームや文化に関する大きな学びがありました。 AI活用の士気を高めるのは「実用的な成功例」 机上の空論ではなく、「これ、便利だよね」と誰もが実感できる実用的な成功例が一つ生まれると、チーム全体のAI活用に対する士気が一気に高まります。 私のチームでは、PRの自動レビューは、まさにその大きなきっかけとなりました。 AI活用は「ルールを明文化する」絶好の機会 AIにタスクを任せるためには、これまで「暗黙の了解」で済ませていた作業手順や判断基準を、誰もが理解できる自然言語で明文化する必要があります。 このプロセスは、チームの属人性を排除し、開発プロセスそのものを洗練させる良い機会になっていると感じます。 AIはあくまで作業者、判断は人がするべき AIに全てを任せようとするのは時期尚早です。AIが出したアウトプットを鵜呑みにせず、要所要所で人間がレビューし、方向性を修正することが極めて重要です。 AIを便利な「作業者」として活用する姿勢が、現時点では賢明かなと、個人的には考えています。 おわりに 私のチームでのAI駆動開発の推進は、正直まだまだ始まったばかりの段階です。 刺激的なアイデアを次々と試す若手メンバーを見ていると、「AIネイティブ世代」の台頭を肌で感じ、私自身も大いに刺激を受けています。 AIの分野は情報の変化が非常に早いので、 「まず使ってみる」という探究心と、「こんなことに使えるかも」というアイデアが勝負 の世界なのかもしれない、とも個人的には感じていました。 この記事が、皆さんのチームでAI活用を始めるための一歩を踏み出すきっかけになればと思います！

自己紹介 こんにちは、株式会社ラクスでプロダクトマネージャー(以下PdM)をしている 柴 と申します。 楽楽精算のPdMを経て、現在は楽楽精算モバイルアプリ・楽楽明細・楽楽債権管理・AIリーン開発と複数のプロダクトでPdMを担当しています。 （PdM積極採用中です！！） 今回はPdMという役割を経験して私が感じてきたことを記事にしてみます。 PdMを目指している方やPdMという役割にもやもやしている方の参考になると幸いです。 はじめに 「隣の芝が青く見える」——この言葉が、私のPdMキャリアの最初の数年間を象徴していました。 SNSで目にする「戦略を描くPdM像」、イベントで語られる「PMFを達成したPdMの話」、そして「経営に貢献するPdM」の事例。 それらと比較して、私は「自分のやっていることは、本当にプロダクトマネジメントと言えるのだろうか？」と疑問を持っていました。 そんな中でも派手ではないけれど確かに意味のある仕事を続けた結果、今は複数のプロダクトのPdMを担当させてもらっています。 この記事では、過去のモヤモヤや迷いも含めながら、「自信がない中でも前に進み続ける」ためのマインドや行動習慣をお伝えします。 比べることに疲れたジュニアPdMに、ちょっと肩の力を抜けるようなヒントを届けられたら嬉しいです。 1. ジュニアPdMが感じる"理想像"のプレッシャー SNSやイベントで語られる「理想的なPdM像」に圧倒される PdMとしてのキャリアを歩み始めた頃、私はSNSやイベントで語られる「理想的なPdM像」に圧倒されていました。 戦略を描くPdM、PMFを達成したPdM、経営に貢献するPdM——これらの情報を見るたびに、「自分は全然できていない」と感じていました。 外部から得られる情報と自分の日常業務を比較して、いつも「もっと大きなことをやらなければ」と焦っていました。 ただ今振り返るとこれらはすべて結果（成果）であり、そこまでの道のりは皆同じように日々の業務の積み重ねであるということに気づきました。 2. 実録：同じ会社でも、PdMの仕事はこんなに違う 楽楽精算・楽楽精算モバイルアプリ・楽楽明細・楽楽債権管理・AIリーン開発、それぞれでのPdM業務の違い ラクスに入社して、実際に複数のプロダクトを担当したり、他社のPdMと直接交流する中で気づいたことがあります。 それは同じ会社でも・会社によっても、プロダクトによっても、PdMの役割や期待が全く違うということです。 以下が私が各プロダクトの参画当時に求められているなと感じ、実行したことの概要です。 (市場環境やAI技術の発達などの外部環境や内部の組織変革によって常に変化していますのでその点はご留意ください。また現在も携わっているプロダクトもありますが統一感のためにあえて過去形で書いています。) 楽楽精算（経費精算システム） 成熟期を迎えた楽楽精算では、PdM/PMMともに他のプロダクトと比較して人数が多く、役割分担も明確な中で、新規参画したPdMには個別の案件（課題）への深い入り込みと主体的な推進が求められました。各案件は影響範囲や難易度が高く、課題の本質を見極め、進め方を組み立てる力が特に求められる環境でした。複雑な課題を整理し、仕様策定とエンジニア・ビジネスサイドの合意をリードする業務が中心で、この時期は「課題解決と合意形成に徹する日々」でした。 楽楽精算モバイルアプリ 成長期かつ今後重要な成長ドライバーになるべきモバイルアプリでは、課題はあるが、何を優先すべきか、どういった順番で進めるかの整理がされていない状態であり、モバイル開発チームとしてしっかり成果をあげる必要がありました。ビジョンから体制づくりまで支援し、安定した開発を実現することが求められ、この時期は「チーム安定化とビジョン実現に徹する日々」でした。 楽楽明細（請求書発行システム） 成熟期の楽楽明細では、エンジニアのキーマンに様々な業務の推進/意思決定が依存している状態でした。また、ジュニアPdMが先行して参画しており、成果物のレビューや業務のサポートが必要な状態でした。スケールに向けた属人化からの脱却と同時にチームの成果を守ることが求められ、この時期は「チームサポートと成果保護に徹する日々」でした。 楽楽債権管理（債権管理システム） 導入期の楽楽債権管理では、0→1フェーズであり、最速でのPMFを目指すために市場や顧客を深く/広く理解して、優先して解くべき課題を発見する能力が求められる環境でした。役割分担も明確に決まっておらず、自発的かつ積極的に行動することが求められ、この時期は「市場理解とPMF追求に徹する日々」でした。 AIリーン開発 AIリーン開発では、市場ニーズの検証とプロトタイプの作成が主な役割でした。AI技術の検証、プロトタイプの作成・テスト、事業貢献の可能性探索など、将来の事業拡大を見据えた技術検証業務が中心でした。この時期は「技術・ニーズ検証に徹する日々」でした。 上記のようにプロダクトの規模やフェーズによって、ビジネス側との関係性やPdMに特に求められる役割も大きく異なります。楽楽精算・楽楽明細のような大規模(ステークホルダー、売上)プロダクトでは、1人のPdMでは対応しきれません。PdM内でも長期的なビジョンとロードマップを策定や、個別機能の仕様策定・開発管理、ユーザー対応・要望収集を行うというテーマ単位での役割分担が必要になります。 3. 他人比較をやめる：隣の芝は青く見えるけど、それでよい プロダクトのフェーズ・体制・文化で"青さ"の基準は違う 「隣の芝が青く見える」という感覚は、プロダクトのフェーズやチーム体制、組織文化によって生まれています。導入期、成長期、成熟期で求められる役割が違いますし、チームの人数やスキルレベル、経験値でできることも違います。また、組織の意思決定の速さやリスク許容度、イノベーション重視度も影響します。 「今の自分が、目の前のお客様やチームに何を提供できるか」を軸にする 他人と比較するのではなく、お客様にとって今のプロダクトで何が改善できるか、チームにとって今の自分が何をサポートできるか、事業にとって今の状況で何が貢献できるかを考えるようにしました。 「求められていること」に目を向ける 各プロダクトで「求められていること」は異なります。完璧なジョブディスクリプションがある場合はそれに準ずることができますが、多くのプロダクトマネージャーは間に落ちるボールを拾う役割を担うケースが多いと思います。プロダクトの成功のために組織として何が求められているか？に常に目を向けるようにしました。 小さな信用を積み重ねて、信頼を得る 大きな成果を一度に出すのではなく、小さな信用を積み重ねることを意識しました。期限を守ることや品質を保つこと、進捗を共有して課題を早期発見すること、小さな問題も真摯に向き合うこと、分からないことは素直に聞くことなど、一つ一つの行動が信頼につながっていきます。 その信頼によって大きな仕事を任されるようになります。 4. それでも見失ってはいけない"PdMの本質" 各プロダクトでの役割が違っても、目指すべきはプロダクトの成功 具体的には、ユーザーの課題解決や使いやすさの向上といったユーザー価値と、売上向上やコスト削減、効率化といった事業価値の両立を目指すことです。 タスクに追われて目の前しか見えなくなる中でも、定期的に「この仕様が誰の課題を解決して、どう売上につながるのか？」を問い直す 日々の業務に追われていると、目の前のタスクしか見えなくなります。それを防ぐために、以下のような習慣を持ちました。 週次振り返り 今週やったことの意味を考えること、ユーザーにとっての価値を確認すること、事業への貢献を言語化することが重要です。 月次振り返り プロダクトの方向性が正しいか確認すること、優先度の見直しを行うこと、長期的な目標との整合性を確認することが必要です。 PdMの自信は「正しい問いを持ち続けること」からも生まれる 以下のような問いを常に持ち続けることが重要です。ユーザー視点では「この機能は誰の課題を解決するのか？」、事業視点では「この改善はどう売上につながるのか？」、技術視点では「この実装は適切な技術選択なのか？」、チーム視点では「この進め方はチームにとって最適なのか？」といった問いを繰り返し考えることで、PdMとしての自信が育まれていきます。 5. どう育てるか：PdMとしての自信をつくる3つの行動 「誰の役に立てたか」に目を向ける 身近な「ありがとう」を信じることが重要です。 営業からの感謝 「この機能のおかげで商談が進んだ」や「顧客の要望に迅速に対応してくれて助かった」といった声 CSからの感謝 「ユーザーの問い合わせが減った」や「問題の原因を特定してくれて助かった」といった声 開発からの感謝 「仕様が明確で開発しやすかった」や「優先度が明確で計画が立てやすかった」といった声 顧客からの感謝 「使いやすくなった」や「業務効率が向上した」といった声 「プロダクトを前に進めた感覚」を言語化する 小さな進歩でも、それを言語化することで自信につながります。 仕様が決まった 「曖昧だった要件が明確になった」や「関係者の認識が揃った」といった感覚を言語化することで、小さな進歩でも自信につながります。 優先度が決まった 「開発リソースの配分が最適化された」や「ユーザーにとって重要な機能が優先された」といった感覚を言語化することで、プロダクトを前に進めた実感を得られます。 リリースが完了した 「計画通りにリリースできた」や「ユーザーからの反応が良かった」といった感覚を言語化することで、成果を実感できます。 「学んだことを振り返る」習慣を持つ 定期的な振り返りが成長につながります。 週次振り返り 今週学んだことや改善できたこと、次週への課題を整理することで、小さな成長を実感できます。 月次振り返り 今月の成果や学んだスキル、次月の目標を整理することで、より大きな成長を実感できます。 1on1での報告 成長した点や課題となっている点、サポートが必要な点を整理して報告することで、上司との対話がより充実したものになります。 ラクスのPdM組織では各プロダクトのPdMが集まって行う週次・月次の定例会が実施されるともに、上長やビジネスサイドのキーマンとも1on1を実施しており、 上記のような振り返るや課題のすり合わせを行う場が設けられています。 6. おわりに：歩き続けることで育つキャリア 正直に言うと、他人と比較して落ち込むことは、今でもあります。でも、それは自然なことだと受け入れられるようになりました。 プロダクトマネジメントは、常に変化し続ける分野です。完璧な状態は存在せず、常に改善の余地があります。だからこそ、今の一歩に集中することが重要です。 小さな行動でも、誰かのために動いたその行動は、確かに価値を生んでいます。それを信じて、一歩ずつ前に進み続けることが、PdMとしての成長につながります。 今、自分なりに育ててきた芝が、少し青く見えるようになってきた——それが、伝えたかったことです PdMキャリアを通じて、私は自分の足元に目を向けることができるようになりました。 他人と比較するのではなく、自分の現場と向き合い、目の前の課題に真摯に向き合うことの大切さを学びました。 今、自分なりに育ててきた芝が、少し青く見えるようになってきました。 それは、完璧な状態になったからではなく、自分の価値観と向き合い、一歩ずつ前に進み続けた結果です。 まとめ：同じモヤモヤを抱えているPdMへのメッセージ 他人と比較しない プロダクトによって役割が違いますし、フェーズによって求められることも違います。自分の現場に集中することが重要です。 小さな価値を積み重ねる 約束を守ること、コミュニケーションを大切にすること、問題解決に真摯に向き合うことが、小さな価値を積み重ねることにつながります。 定期的に振り返る 週次・月次での振り返りや学んだことの言語化、成長の実感を定期的に行うことで、継続的な成長が可能になります。 正しい問いを持ち続ける ユーザーにとっての価値や事業への貢献、技術的な適切性について、常に正しい問いを持ち続けることが重要です。 隣の芝が青く見える世界で、自分の足元に目を向けられるようになるまで。 それは、他人と比較するのではなく、自分の価値観と向き合い、一歩ずつ前に進み続けることです。 あなたの芝も、きっと少しずつ青くなっていきます。焦らず、一歩ずつ、歩き続けていきましょう。 [Appendix]PdM・デザイナー積極採用中！ ラクスでは様々なフェーズのプロダクトに携わることができます。 興味を持った方は是非カジュアル面談からお申込みください。 カジュアル面談のお申込みはこちら

こんにちは、フロントエンド推進課の水野です。 普段はWebフロントエンド領域を中心に、商材開発や技術支援、開発改善に携わっています。 自動化・標準化、開発プロセスの変遷に関心があり、作るものだけではなくその過程や運用設計を意識して取り組んでいます。 note.com 最近、自分の中でコードレビューのやり方が変わったなと感じています。 GitHub CopilotやClaude Codeのようなツールが当たり前になり、構文エラーやコーディング規約のチェック、命名規則の統一のような作業はほぼ自動化できてしまいます。 成果物の出てくるスピードと規模感も桁違いで、レビューだけで1日が溶ける日もたまにあります。 その中で、改めて「自分は何をレビューすればいいんだろう」「コード以外に見るべきものはなんだろう」と考えることが増えました。 個人的にコードレビューや開発現場に関する話が好きで、ブームが再燃しているからというのもあります。 www.shoeisha.co.jp www.shuwasystem.co.jp 添削作業の消失 答えを出すことによる機会損失 「なんで？」を大事にしている 設計の話 運用の話 開発チームの変化 知見の民主化 非同期で作る 今後 おわり 添削作業の消失 コードレビューにおいて、おそらく以下のようなコメントを見かけたことがあるでしょう。(私は今でも見ます) 「このif文はearly returnした方がよくないですか？」 「命名がcamelCaseではなくsnake_caseになっています！」 「変数名が抽象的すぎるのでもうちょっと分かりやすくしてください」 「外から参照する型定義は *.interface.ts に定義しましょう！」 などなど。 既に答えを知っているメンバーが答案用紙に赤ペンを入れて、実装者がそれに従って修正するという表現が近いかと思います。これはこれで大事で、勿論コードの品質は保たれるのですが、なんだか一方通行だなあと思うことはありました。 今は開発周辺ツールがそこら辺をカバーしてくれます。AIサービス含め、Linter, Formatterがあれば人間の出番はほとんどありません。そうなると、「コードレビューの存在意義って何？」という哲学的な問いに直面することになります。哲学的というか、自分自身の存在に対する危機感でもあるというか...。 答えを出すことによる機会損失 「こう書いてください」ではなく「こういうケースの考慮が必要になりませんか？」と聞いてみることが増えました。直接答えをポンと提示するのではなく、一緒に考える時間を作るように意識しています。とは言っても「なんでこうしたんですか？」「この実装のどこに問題があるでしょうか？」みたいなネチネチした詰め方はしませんが。 APIリクエスト処理を書く時に「リクエスト前後でこういう処理が必要になりませんか？」と聞いてみたり、UIコンポーネントを作る時も「このコンポーネントってどの画面でどういうパタンで使われますか？」と実装前に一度考える時間を作ったり。 そうすると、次に同じような問題が出てきた時や別の人のレビューを行う際に自分で判断したり、別の改善案を考えたりできるようになっていきます。 「なんで？」を大事にしている 機械がコーディングをアシストする場面が増え、構文的には正しく効率的なコードが出てきやすくなりました。しかし、「なんでその設計にしたの？」のような部分の責任は依然として人間にあります。 設計の話 「このコンポーネントの共通化の粒度、後で機能追加する時に耐えられますか？」 「この関数だけ責任範囲が広すぎませんか？」 「これ、3ヶ月後に見てもウッてなりませんか？」 「テスト書きにくくないですか？」 運用の話 「この実装は別のプロダクトでも何箇所か見かけたのでライブラリのAPIに閉じてしまって良さそうですね」 「デザインシステムや他プロダクトとの整合性は取られていますか？」 「前にも似たようなもの作っていませんでしたっけ？」 機能的には問題無くても時系列的な整合性が無かったり客観性に乏しかったりすると、負債になりやすいと考えます。そういうものをまあまあ見落としがちで、後からテコ入れしたり実装背景が後付けされることもありました。 なので、単純に「動くか動かないか」ではなく「長く使っていけるか」「変更に強いか」「チームにとってプラスか」のような視点で話すことが増えました。 AIが生成するコードは特に「なんでこうしたの？」が抜けていることが多いので、「前提条件って何でしたっけ？」「こんなケースは考えました？」を掘り下げてコンテキストを補足する作業が大切だと思っています。 開発チームの変化 知見の民主化 以前は「コードが書ける人」「コードレビューができる人」でなんとなく別れるようなことが多かったのですが、今は流動的になってきたと感じます。コーディングの敷居が下がった結果、より多くの人が実装に参加できるようになり、逆にレビューにおいては各々の専門性・経験値が活かされるようになってきました。 自身の周りの話ですが、業務ドメインに詳しいエンジニアがロジックを実装してアーキテクチャに強いエンジニアが別の観点からレビューしたり、フロントエンドエンジニアが実装したUIコンポーネントをマークアップ・Webアクセシビリティに精通したメンバーがチェックしたりといった協業は自然と生まれてきています。 非同期で作る これまでは「作る→レビュー→直す→またレビュー...」を繰り返していましたが、現在は事前に相談する(相談できるようにする)ことが増えてきました。「なんでこの方法？」「他の選択肢は？」「今後の運用は？」のような話を作る前にしておくことで、実装時のレビューはその確認作業に近くなり、大きな手戻りも発生しにくくなりました。 一人がコンポーネントを実装しながら、別の人がリアルタイムで画面の開発を進める、みたいな動き方も出来るようになってきました。多少複雑なインタラクションや状態管理も非同期で考えながら進められるので、完全に作り終わってからの考慮漏れは格段に減ったと感じています。 今後 生成AI含め、技術の進化は止まりません。近いうちに「なぜこの実装を選んだのか」の前後も含めて実装プロセスが圧縮されるかもしれません。そうなったとき、人間の役割はさらに抽象的、例えば「そもそもこの機能は必要か」「体験として最適なのか」「プロダクトとの親和性は」「人間もAIも守っていない実装ルールは捨てるべきでは」といった、より戦略的な判断軸に移り変わるだろうと予想しています。 だからといって人間の価値が下がるわけではなく、末端実装の細部まで気を払う必要が無くなることで、より本質的な価値創造を追求できるようになったと考えています。 おわり 人間以外にコードを書かせる技術が一般化した今のコードレビューは、表面上の正確性から人間的な洞察へとシフトしています。 単純なコードの良し悪しではなく、実装の本質的な価値と持続可能性を見極めるために、AIが生成したコード含め全てのアウトプットを『人が作り上げるシステム』という文脈で評価し、プロダクトの価値提供への貢献は勿論、開発チームの成長にも結びつける。 ...みたいな思想が当てはまるのだろうと思います。 正直な所、自分がレビューにかける時間は長くなったと感じています。純粋に実装単位のボリュームと実装速度が上がって物理的な負担が上がったのもそうですし、技術的な側面だけではなくもっと広い視点でレビューすることが増えました。 毎回疲弊しないためには、事前の相談を大事にしたり背景をドキュメントにしたりなどの工夫をする必要があります。 その一方で、開発チーム内の知識共有やコミュニケーションが活性化したり、「本来こうあるべき」のような話をやりやすくなったという効果は確実に得られています。 何より、単純作業から解放されて抽象度の高い課題解決に割ける時間が多くなったのは嬉しいことです。まだまだ頑張れることがたくさんありそうで、それはそれで楽しみでもあります。

自己紹介 ラクスでPdMをしております。 @keeeey_m と申します。 現在の担当商材は、楽楽シリーズ(楽楽精算、楽楽明細、楽楽電子保存、楽楽債権管理)を担当しており、個人としては楽楽精算×AIの担当、楽楽明細・楽楽電子保存・楽楽債権管理PdMチームのリーダーをしております。 はじめに 前回までの記事では、ジョブ理論とノーススターメトリックそれぞれの重要性について詳しく解説しました。第1回では顧客の真のニーズを理解する鍵としてのジョブ理論、第2回では組織全体の方向性を統一する鍵としてのノーススターメトリックについてお伝えしました。 しかし、これらを単独で活用するだけでは、真の事業成長を実現することは困難です。本記事では、ジョブ理論とノーススターメトリックを組み合わせることで生まれる相乗効果についてまとめました。 自己紹介 はじめに 相互補完的な関係 単独での限界 相互補完的な役割 相乗効果のメカニズム 因果連鎖の構築 相互依存関係 具体的な相乗効果 市場変化への柔軟な対応 ジョブ理論による柔軟性 Netflixの事例 実際の取り組み事例：両者の組み合わせ効果 顧客と企業双方にとっての持続的価値創造 顧客にとっての価値 企業にとっての価値 相互価値の創出 戦略的示唆と今後の展望 プロダクト開発のパラダイムシフト 今後の展望 まとめ 相互補完的な関係 単独での限界 ジョブ理論とノーススターメトリックは、それぞれ単独でも価値のあるフレームワークですが、単独で活用する場合には限界があります。 ジョブ理論単独の限界 顧客の真のニーズを理解できても、組織全体で追求しにくい 定性的な洞察を定量的な指標に変換しにくい 組織全体の方向性統一が困難 ビジネス成果への結びつきが曖昧 ノーススターメトリック単独の限界 表面的な数値に留まるリスク 顧客の真のニーズを深く理解できていない 指標設定の根拠が曖昧 短期的な改善に終始する可能性 相互補完的な役割 ジョブ理論とノーススターメトリックは、プロダクト開発の成功において互いを補完し合う、不可欠なフレームワークです。 ジョブ理論の役割 顧客の真のニーズ、つまり「片付けたいジョブ」を定性的に深く理解 プロダクトが提供すべき「顧客価値」の核心を明確化 イノベーションの方向性を指し示す ノーススターメトリックの役割 明確化された顧客価値を定量的に測定 組織全体をその目標達成に向けてアライン 継続的な改善の指針を提供 相乗効果のメカニズム 因果連鎖の構築 両者を連携させることで、単独で適用する以上の相乗効果が生まれます。 因果連鎖 ジョブ理論で顧客の真の課題と価値を特定（定性的フレームワーク） 適切なNSMを選定（その価値提供を定量的に測る顧客中心の先行指標） 組織全体がNSMに集中 持続的なビジネス成長が実現 相互依存関係 ジョブ理論とノーススターメトリックは、相互依存的な関係にあります。 ジョブ理論がなければNSMは表面的な数値に留まる NSMがなければジョブ理論の深い洞察はビジネス成果に結びつきにくい 両者が組み合わさることで、定性的な洞察と定量的な測定が統合される 具体的な相乗効果 1. より深い顧客理解 ジョブ理論による顧客の真のニーズの理解 NSMによる顧客価値の定量的測定 顧客の行動と価値の関係性の明確化 2. より効果的な指標設定 ジョブ理論に基づいたNSMの選定 顧客価値を中心とした指標設計 長期的な成長につながる指標の設定 3. より強い組織アラインメント 顧客の真のニーズに基づいた組織目標の設定 全従業員の共通理解の促進 部門間連携の強化 市場変化への柔軟な対応 ジョブ理論による柔軟性 ジョブ理論を基盤とした企業は、市場の変化に柔軟に対応できます。NSMと組み合わせることで、この柔軟性を組織全体で活用できます。 柔軟性の源泉 1. ジョブ中心の視点 製品の寿命に縛られない 顧客の「ジョブ」の変化を捉える 新たな「ジョブ」の出現を発見 2. 継続的なイノベーション 既存製品の改善点を発見 全く新しい製品カテゴリを創出 顧客の未解決のジョブに焦点を当てる 3. 戦略的柔軟性 製品が衰退期に入っても、その背後にある「ジョブ」を解決する新たなソリューションを開発 ビジネスの継続性を確保 長期的な成長軌道を維持 Netflixの事例 Netflixは、ジョブ理論とノーススターメトリックを組み合わせた成功事例として知られています。 不変のジョブ : 「質の高いエンターテイメントコンテンツを手軽に楽しむ」 時期 ビジネスモデル ノーススターメトリック 初期 DVDレンタルサービス 月間レンタル数 中期 ストリーミングサービス 月間視聴時間 現在 オリジナルコンテンツ制作 月間アクティブユーザー数 この事例から分かることは、顧客の「ジョブ」は時代を超えて存在し続ける一方で、それを測定するNSMは技術やビジネスモデルの変化に応じて進化するということです。 実際の取り組み事例：両者の組み合わせ効果 楽楽精算では、ジョブ理論とノーススターメトリックを組み合わせることで、単独では実現できない相乗効果を生み出す取り組みを開始しています。 両者の組み合わせによる実践 1. ジョブ理論による顧客理解 経費精算における顧客の真の「片付けたいジョブ」を深く理解 表面的な業務効率化ではなく、根本的な課題解決に焦点 2. NSMによる定量的測定 理解した顧客価値を「1社あたり申請から承認までの全作業時間」として定量的に測定 組織全体が統一された目標に向かって取り組む 3. 相乗効果の実現 定性的な顧客理解と定量的な測定が統合される 顧客の真のニーズに基づいた組織目標の設定 全従業員の共通理解の促進 取り組みの方向性 この組み合わせにより、楽楽精算では以下の相乗効果を目指して取り組みを進めています。 顧客にとっての価値 : 真のニーズを満たすソリューションの提供 企業にとっての価値 : 持続的な成長と競争優位性の確立 組織にとっての価値 : 部門間連携の強化と効率的なリソース配分 ロードマップ作成への貢献 ジョブ理論で顧客の真のニーズを理解し、それをNSMとして定量的に測定することで、組織全体が統一された方向性で効率的なロードマップを作成できるようになりました。これにより、短期的な機能追加ではなく、顧客価値の向上に焦点を当てた持続的な成長戦略を実現に取り組んでいます。 www.rakurakuseisan.jp 顧客と企業双方にとっての持続的価値創造 顧客にとっての価値 ジョブ理論とノーススターメトリックの導入により、顧客にとっての価値が最大化されます。 顧客にとっての価値 真のニーズを満たすソリューションの提供 機能的価値を超えた情緒的・社会的価値の享受 長期的な関係性と信頼の構築 生活の質の向上 企業にとっての価値 企業にとっても、両者の組み合わせにより大きな価値が生まれます。 企業にとっての価値 持続的な成長と収益の確保 競争優位性の確立と維持 顧客ロイヤルティの向上 イノベーション能力の強化 相互価値の創出 両者の組み合わせにより、顧客と企業双方にとっての持続的価値創造が実現できます。 相互価値の創出 顧客の成功が企業の成功につながる 企業の成長が顧客により多くの価値を提供 長期的なパートナーシップの構築 持続可能なビジネスモデルの確立 戦略的示唆と今後の展望 プロダクト開発のパラダイムシフト ジョブ理論とノーススターメトリックの導入は、プロダクト開発におけるパラダイムシフトを意味します。 項目 従来のパラダイム 新しいパラダイム 開発アプローチ 機能中心の開発 ジョブ中心の開発 価値創造 短期的な売上追求 長期的な顧客価値創造 競争優位性 競合との機能競争 顧客の「ジョブ」解決能力による競争優位性 顧客理解 顧客の表面的な要求への対応 顧客の真のニーズへの深い理解 今後の展望 技術革新との融合 AI・機械学習による顧客行動の深い理解 データドリブンなジョブ特定 リアルタイムでのNSM測定と改善 まとめ ジョブ理論とノーススターメトリックの戦略的な導入と運用は、企業が顧客の真のパートナーとなり、変化の激しい市場において持続的な成長と競争優位性を確立するための、強力な武器となります。 現代の競争が激しい市場において、プロダクト開発の成功には、単独のフレームワークでは不十分です。ジョブ理論とノーススターメトリックを組み合わせることで、企業は 顧客の真のニーズを深く理解し、それを定量的に測定できる 組織全体が統一された方向性で顧客価値の向上に集中できる 短期的思考から脱却し、長期的な持続的価値創造を実現できる この相乗効果により、企業は変化の激しい市場においても確実な成長軌道を確立し、競争優位性を維持することができます。技術革新との融合への配慮など、今後の展望においても、両者の組み合わせは、企業が持続的な価値創造を実現するための基盤として、ますます重要な役割を果たすことでしょう。

はじめに 私たちのモバイルアプリ(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日あたり） CI実行回数の推移（2025年分 iOSのみ） 取り組みの中での失敗 現在取り組んでいる課題 1. 処理速度の最適化 2. 効果測定の精緻化 3. 適用範囲の拡大 まとめ 生成AI活用の文化づくり 生成AI情報共有会の開催 私たちのチームでは「生成AI情報共有会」を隔週で開催しています。この会では以下のような内容を行っています。 新しいAIツールの情報と使用感 効果的なプロンプトエンジニアリングのテクニック 実際の開発での成功事例と失敗事例 AIツール活用のベストプラクティス ツールの使用方法デモ、ハンズオン この定期的な情報共有によりチーム全体のAIリテラシーが向上し、新しいツールや手法の導入がスムーズになっています。 多様なAIツールの活用 現在チームでは以下のAIツールを利用可能な環境が整っており、メンバーそれぞれが利用したいツールを申請して利用している状態です。 Claude Code （メインツール：実装の40〜90%をAIで生成） Cursor GitHub Copilot Devin Codex JetBrains AI Gemini タスクの性質や個人の好みに応じて、最適なツールを選択できる環境を整えることで、開発者それぞれが最も生産的に作業できるようになっています。 また弊社では上記ツール以外でも使いたいと言えば、費用面も含めて検討して下さる開発横断組織もあり、直近だとKiroも連絡して1日後には利用可能リストに入れて下さいました。 このように非常にスピーディに対応して頂けていることも、AIツール活用して生産性向上が出来ている一つの要因となっています。 独自MCPサーバーによる開発環境の革新 MCPとは MCP（Model Context Protocol）は、AIツールに外部システムの情報を提供するためのプロトコルです。 私たちは開発効率を向上させるため、以下の独自MCPサーバーを開発・運用しています。 1. GoogleDrive MCP 機能 要件定義書、設計書、テスト項目書の参照・更新 文言一覧の読み取り（英語文言の自動反映など） 効果 ドキュメントとコードの整合性が向上し、仕様変更時の対応速度が大幅に改善しました。 2. Redmine MCP 機能 Redmineの情報取得、更新の自動化 効果 チケット管理の効率化により、開発者がタスク管理に費やす時間を削減できました。 3. 検証環境 MCP 機能 SQL自動実行による環境設定変更 テスト時の手動設定時間の削減 効果 環境構築やテストデータの準備にかかる時間が大幅に短縮されました。 4. GitHub PR/Issue MCP 機能 PR自動作成 コードレビューの支援 バックログ作成の効率化 AIへのコンテキスト提供 効果 PR作成からレビューまでの一連のプロセスが効率化され、開発サイクルが高速化しました。 5. Figma MCP 機能 デザインデータの読み取り AIへのコンテキスト提供 効果 デザインと実装の乖離が減少し、UIの実装精度が向上しました。 6. ファイル編集 MCP 機能 Claude Codeのファイル編集速度の改善 効果 大規模なリファクタリングや複数ファイルの同時編集が高速化されました。 具体的な活用事例 開発プロセス全体での活用 私たちのチームでは以下のような場面でAIツールとMCPを活用しています。 1. プルリクエスト（PR）作成 コミット内容からPRの説明文を自動生成 変更内容の要約と影響範囲の明記 2. コードレビュー コード差分、PRコメント、影響範囲コードを総合的に分析してフィードバック 潜在的な問題点の事前検出 3. テスト自動化 テスト環境でのSQL実行とcurlを組み合わせた自動テスト 手動テストの工数削減 4. その他の活用場面 脆弱性診断対応 ソースコード、DB定義の検索 Obsidianを使用した情報の記録、検索 マージ済みPRのレビューコメント分析 片手間で新機能PoC作成 要件定義からPBI（Product Backlog Item）作成 実装時のコンテキスト収集（Issue、Figma、Google Drive） ナレッジの蓄積と共有 実装ナレッジの再利用・形式知化 AIとのチャット履歴から有益な情報を抽出 良かった点をMarpでスライド化して共有 アプリ開発用ハンドブックへの記載 AI駆動開発のワークフロー作成 導入効果の測定 PR作成数の推移（1日あたり） AI導入段階 iOSアプリ Androidアプリ AI導入前 0.346 0.221 ChatGPT 0.313 0.487 Copilot（サジェストのみ） 0.638 0.576 Copilot（Edits/Agent）※2月 0.737 0.842 Cursor※4月 1.313 1.506 Claude Code※7月 3.059 2.235 ※1〜2月頃にプロセス改善も実施、3月頃にiOSチームメンバーが1名増員しています。 CI実行回数の推移（2025年分 iOSのみ） 1月：187回 2月：144回 3月：270回 4月：245回 5月：245回 6月：310回 7月：415回 これらの数値はAIツールの導入だけでなく、プロセス改善やチーム体制の強化も寄与した成果です。 取り組みの中での失敗 もちろんこれらの成果は一直線に得られたわけではありません。AIの出力が期待と異なったり、自動化が逆に非効率になったりと大小の失敗は常に経験しています。 小さな仮説検証を高速で回して常に失敗しているような状態ではありますが、チームが進化し続けている証だと考えています。 現在取り組んでいる課題 1. 処理速度の最適化 Claude Codeで時間がかかる部分の改善に取り組んでいます。特に大規模なコードベースでの処理速度向上が課題です。 2. 効果測定の精緻化 AIでのコード生成率の正確な計測 各ツールのROI（投資対効果）の可視化 品質指標との相関分析 3. 適用範囲の拡大 実装だけでなく設計フェーズへのAI活用を検討しています。要件定義から設計、実装、テストまでの一貫したAI支援の実現を目指しています。 まとめ 私たちのモバイルチームでは、AIツールの導入とプロセス改善を組み合わせることで、開発効率の大幅な向上を実現しました。特に独自開発したMCPサーバー群により、AIツールがプロジェクトの文脈を深く理解し、より精度の高い対応ができたり、手動作業を省力化できました。 重要なのはAIツールを単に導入するだけでなく、チームや組織の文化として定着させることです。定期的な情報共有会や独自ツールの開発により、チーム全体でAIを活用する文化が醸成されています。 今後も新しい技術やツールを積極的に取り入れながら、開発者がより創造的な作業に集中できる環境づくりを進めていきます。AIは開発者を置き換えるものではなく、開発者の能力を拡張するパートナーとして、私たちの開発プロセスに欠かせない存在となっています。

自己紹介 ラクスでPdMをしております。 @keeeey_m と申します。 現在の担当商材は、楽楽シリーズ(楽楽精算、楽楽明細、楽楽電子保存、楽楽債権管理)を担当しており、個人としては楽楽精算×AIの担当、楽楽明細・楽楽電子保存・楽楽債権管理PdMチームのリーダーをしております。 はじめに 前回の記事では、ジョブ理論の重要性について詳しく解説しました。顧客の真の「ジョブ」を理解することの重要性と、それが企業にもたらす競争優位性についてお伝えしました。 しかし、顧客の真のニーズを理解したとしても、それを組織全体で効果的に追求していくためには、もう一つの重要な要素が必要です。それが「ノーススターメトリック（North Star Metric: NSM）」です。 本記事では、ノーススターメトリックの重要性と、組織全体の方向性を統一する鍵としての役割についてまとめてみました。 自己紹介 はじめに 従来の指標設定の問題点 短期的思考の罠 楽楽精算での経験 顧客の属性と職種範囲 ノーススターメトリックの本質的な価値 顧客価値を起点とした先行指標としての役割 北極星の比喩が示す重要性 組織全体の目標統一と方向性の明確化 NSMの最大の価値 部門間の連携強化 KGI/KPIとの戦略的関係性 指標の階層構造 3つのバランス 長期的価値創造のアプローチ 短期的思考からの脱却 先行指標としての重要性 変化の激しい市場での成長軌道確立 現代ビジネス環境の特徴 NSMによる成長軌道確立 実際の取り組み事例 まとめ 従来の指標設定の問題点 多くの企業では、従来のKPI（Key Performance Indicator）やKGI（Key Goal Indicator）を設定して事業を推進しています。しかし、これらの指標には根本的な問題があります。 従来の指標の問題点 短期的な売上目標に囚われがち 顧客価値よりも事業価値に偏重 組織全体の方向性が統一されない 各部門が異なる指標を追求する結果、バラバラな方向に進む 短期的思考の罠 多くの企業が短期的な売上目標に囚われ、長期的な価値創造を見失いがちです。 短期的思考の問題 プロダクト価値の向上が後回し 顧客に提供できる価値の総量が変わらない 一度成長が止まってからの立て直しに膨大な時間と労力が必要 持続的な競争優位性を失う このような状況では、企業は「泥沼サイクル」に陥り、持続的な成長を実現することが困難になります。 楽楽精算での経験 楽楽精算では、AI活用の成果指標としてノーススターメトリックを設定することにしました。この導入のきっかけとなったのは、合議で機能仕様を決めていく中で、それぞれの役割において、第一想起するお客様が異なるという事象でした。特にラクスでは機能別組織体制を選択しているため、この事象がより顕著に表れていました。 職種による顧客の時間軸の違い 職種によって顧客と言われて第一想起する属性が異なります。営業部門やマーケティングは未検討・導入検討中の顧客、CSは導入準備中や運用中の顧客、企画部門や開発部門(開発・デザイナー)は未検討・導入検討中・導入準備中・運用中と現在から未来にかけての時間軸が分かれています。 顧客の属性と職種範囲 結果として生じた事象 顧客のペインの本質的な解決にて価値をもたらすのか、それともビジネス的に即効性のあるインパクトを求めているのか、この判断によって解決策が変わってきます。しかし、各部門が異なる指標を追求する結果、顧客像や達成したいことがバラバラになり、仕様決定に何度も苦労する経験をしました。 このような経験を通じて、全員と前提をそろえる指標が必要だと考えるきっかけとなり、ノーススターメトリックの導入を検討することになりました。 ノーススターメトリックの本質的な価値 顧客価値を起点とした先行指標としての役割 ノーススターメトリック（North Star Metric: NSM）は、プロダクトをより確実に成長させるための先行指標として設定されるものです。 NSMの定義 顧客へ提供する価値を明確に表し、かつ計測可能な指標 企業全体の正しい方向性を全部署が把握できる唯一無二の指標 北極星が地上のどこから見ても常に変わらない位置にあり、方向性を示すように機能 北極星の比喩が示す重要性 北極星は、地上のどこから見ても常に変わらない位置にあり、方向性を示す星として知られています。NSMも同様に、組織全体が目指すべき方向性を明確に示す指標として機能します。 北極星の特徴 常に一定の位置にある 誰から見ても同じ方向を示す 迷った時の指針となる 長期的な航海の道しるべ NSMの特徴 顧客価値を中心とした指標 組織全体で共有できる 事業の方向性を明確にする 長期的な成長の指針となる 組織全体の目標統一と方向性の明確化 NSMの最大の価値 NSMの最大の価値は、組織全体の目標を統一し、方向性を明確にすることにあります。 組織統一の効果 企業全体が同じ目線で目標に向かう 全従業員、全部署での目標達成における意識の統一 チーム間やメンバー間の連携の取りにくさを解消 バラバラな方向への進行を防止 部門間の連携強化 従来の指標設定では、各部門が異なるKPIを追求する結果、組織全体としての方向性が曖昧になりがちでした。NSMの導入により、この問題を解決できます。 従来の問題 営業部門：売上目標 開発部門：機能リリース数 マーケティング部門：リード獲得数 カスタマーサクセス部門：解約率 NSM導入後の効果 全部門が顧客価値の向上に集中 部門間の連携が自然と生まれる 組織全体の効率性が向上 顧客にとっての価値が最大化 KGI/KPIとの戦略的関係性 指標の階層構造 NSMは、従来のKGI（Key Goal Indicator）やKPI（Key Performance Indicator）と密接に関連しつつも、異なる戦略的な位置づけを持ちます。 戦略的位置づけ NSMはKGIとKPIの間に設定される傾向 KGIやKPIが経営視点の指標であるのに対し、NSMは顧客視点を取り入れた指標 事業の結果（売上など）に対して「先行指標」として設定 NSMが適切に設定され、改善されることで、遅行指標である成果（売上や利益など）が自然と生まれる 3つのバランス NSMは、以下の3つの要素のバランスを取った指標として機能します。 3つのバランス ビジョン : 企業が目指すべき未来像 顧客価値 : 顧客に提供する価値 事業価値 : 企業が得る価値 このバランスが取れた状態を目指すことで、プロダクトの成功に直結した指標として機能します。 長期的価値創造のアプローチ 短期的思考からの脱却 NSMの導入により、企業は短期的思考から脱却し、長期的なビジネス価値の実現を目指すことができます。 長期的価値創造のアプローチ 顧客の真の価値提供に焦点 顧客価値の向上を最優先 持続的なイノベーションの実現 長期的な顧客関係の構築 先行指標としての重要性 NSMは、事業の結果に対する「先行指標」として機能します。これは、NSMの改善が将来的な事業成果につながることを意味します。 先行指標の特徴 現在の行動が将来の結果に影響する 早期に問題を発見できる 改善の機会を早期に把握できる 長期的な成功の予測が可能 具体例 NSM : 月間アクティブユーザー数（MAU） 結果 : 売上・利益の向上 関係性 : MAUの増加が売上向上につながる 変化の激しい市場での成長軌道確立 現代ビジネス環境の特徴 現代のビジネス環境は、技術革新の加速、市場のグローバル化、顧客ニーズの多様化により、かつてないほどの速さで変化しています。 市場環境の特徴 技術革新の加速 市場のグローバル化 顧客ニーズの多様化 競争の激化 NSMによる成長軌道確立 このような環境において、NSMは企業が確実な成長軌道を確立するための強力な武器となります。 成長軌道確立のメカニズム 1. 戦略的明確性 組織全体の方向性を明確化 リソースの最適配分を実現 顧客価値の向上に集中 2. 実行効率性 無駄な開発を排除 本質的なKPI設定 組織全体のアラインメント 3. 継続的改善 顧客価値の向上を継続 市場の変化に対応 イノベーションを加速 4. 競争優位性の維持 顧客価値の向上を継続 競合との差別化を維持 持続的な成長を実現 実際の取り組み事例 楽楽精算では、ジョブ理論で特定した顧客の真の「ジョブ」を基に、ノーススターメトリックを設定しました。 NSM設定の背景 楽楽精算のAI活用の方針は「経理業務の本質的な課題解決をするためにAIも活用する」ことです。もちろんAIの精度は大事ですが、それに加えAIを活用することで、お客様に本質的な価値を提供できていることを定量的に計測することで、早期に問題を発見し、改善の機会を把握できます。これにより全員が本質を見失うことなく取り組むこともできます。 具体的なNSM設定 ジョブ理論で特定した経費精算における顧客の真の「ジョブ」を基に、「1社あたり申請から承認までの全作業時間」をNSMの実行KPIの一つとして設定しました。プレスリリースでも「1社あたり申請から承認までの全作業時間の約60％削減を目指す」と宣言をしました。 組織統一の効果 このNSM設定により、開発部門、営業部門、CS部門など、全ての部門が「顧客の作業時間削減」という統一された目標を共通認識として持つことができました。 www.rakurakuseisan.jp まとめ ノーススターメトリックの導入により、企業は組織全体の方向性を統一し、顧客価値の向上に集中できるようになります。これにより、短期的思考から脱却し、長期的なビジネス価値の実現を目指すことができます。 NSM導入の効果 NSMの導入により、組織全体の目標が統一され、顧客価値の向上に集中できるようになります。これにより、長期的な成長軌道を確立し、競争優位性を維持することが可能になります。 成功の鍵 NSMの成功には、顧客価値を中心とした指標設定が不可欠です。組織全体での理解と実践を徹底し、継続的な改善サイクルを確立することで、長期的視点での取り組みが実現できます。 次回は、ジョブ理論とノーススターメトリックを組み合わせることで生まれる相乗効果について詳しく解説します。両者を連携させることで、単独で適用する以上の価値を生み出す方法についてお伝えします。

はじめに こんにちは！ラクスの楽楽精算でプロジェクトマネージャーを務めている@rks_bunです。 最近、YouTubeで「1/3の純情な感情」が流れてきて、中学生〜高校生くらいの時にこの曲を聞いていた私は、これが30年近く前の曲だと知って時の速さに驚きました。一緒に見ていた奥さん（私と同年代）が「30年前？最近じゃん」と言っていて、ちょっと共感しちゃった自分にさらに驚きました。 このように時が経つのは早いもので、私がラクスに転職してから半年が経ちました。 この記事は、 ラクスへの転職を迷っている方 、特に 30代〜40代で転職を考えているPMやエンジニアの方 に向けて書いています。 率直に言って、ラクスは 良い会社だと思います 。でも、当然良いところばかりではありません。この記事では、私の実体験を踏まえて、 良いところと悪いところの両方 をお伝えします。 はじめに 転職の背景 転職を決意した理由 ラクスを選んだ決定的な理由 入社半年での率直な感想 良いところ 新しいものの導入に前向き チーム協働の文化が根付いている 本当の意味での顧客志向 悪いところ（覚悟が必要な点） システムの複雑さ 慎重すぎる部分 転職を迷っている人へのメッセージ こんな人にはラクス（特に楽楽精算）がおすすめ こんな人には向いていないかも まとめ 転職の背景 転職を決意した理由 私が転職しようと思った理由は、細かいものも入れるとたくさんあるのですが、大きな理由としては以下の2点になります。 ユーザの役に立ちたい : 前職ではPM業務に特化しすぎて、一番大切な「ユーザの役に立つ」という視点が薄くなっていた もっと開発に関わる仕事がしたい : 前職は開発に関わらない仕事も多く、元々エンジニアだった私には物足りなさがあった ラクスを選んだ決定的な理由 顧客志向が強く伝わってきた ことです。 面接で転職理由をお話しした際、面接官の方がとても共感してくださり、顧客志向を高めるための具体的な施策なども見せていただけました。 私はソフトウェアに関わる者として「人を幸せにする」ことを一番大事にしているので、それを一緒に目指していける会社だと確信できました。 入社半年での率直な感想 実際に入社して半年働いてみて、実感として得られたものをお伝えしていきたいと思います。 ちなみに、入社初日に別部署の方が何人か席まで挨拶しに来てくださって、とても嬉しかったです。良い人が多いのもラクスの特徴だと思っていますが、あまりに主観的な情報なので詳細は割愛します笑。 良いところ 新しいものの導入に前向き AI活用や自動化の提案に対して前向きに検討してくれる 環境があります。 この半年間だけでも、AIを含む様々な技術によりすごいスピードで開発フローや手法が変わっています。ある程度大きな会社なので変化に消極的なのかと思っていましたが、全然そんなことがなくて驚きました。 個人的には、最近はAIを活用した仕事の改善が楽しくて仕方ないです。 チーム協働の文化が根付いている 職種を超えた連携 : 技術者・PM・ビジネスサイドが一体となって課題に取り組む文化 知識共有が活発 : 技術的な知見を積極的に共有できる/してもらえる環境 社内勉強会もかなりの頻度で開催されていて、勉強にも刺激にもなっています。 本当の意味での顧客志向 ユーザーの声を重視 : 実際のユーザーの声を基にした改善が継続的に行われている 現場の課題に直結 : 顧客の業務効率向上に直結する改善に取り組める 悪いところ（覚悟が必要な点） システムの複雑さ 学習コストが高い : 長年運用されてきたシステムの理解には時間がかかる 技術的負債の多さ : 改善したい部分は多いが、影響範囲の評価が困難 ドキュメントの不足 : 古いシステムのため、十分なドキュメントがない場合がある 慎重すぎる部分 リスク回避の傾向 : 本番環境への影響を考慮し、慎重になりがち コミュニケーション不足 : （特に部署を跨いだ）情報が行き渡りづらい 一部レガシーになってしまっているシステム部分に関しては、現在改善取り組み中です。 コミュニケーション不足の部分は、組織の大きさゆえの部分もあるかと思います。部署問わずみんなで話したらすぐ解決した、みたいなシーンは何度かありましたし、私が最近意識的に改善したいと思っている部分でもあります。 転職を迷っている人へのメッセージ こんな人にはラクス（特に楽楽精算）がおすすめ 技術的な挑戦を求めている人 : システム改善や新技術導入に興味がある 継続的に成長したい人 : 年齢に関係なく新しいことを学び続けたい 顧客の課題解決に興味がある人 : 実際の業務改善に携わりたい こんな人には向いていないかも スピード第一の人 : システムの複雑さに耐えられない 最新技術のみを求める人 : 既存システムとのバランスを取りながらの改善になるため、最新技術の導入は段階的 顧客志向を大事に、色々なことに挑戦していきたい人には向いていると思います。楽楽精算はまだまだ挑戦すべき部分がたくさん残っているプロダクトなので、そこに向き合っていきたい方にとっては多くのチャンスがありますよ！ まとめ 私はラクスに入社して良かったと思っています 。AI活用に前向きで、成長を支援する環境があり、経験を活かして活躍できる場所です。 でも、 良いところばかりではありません 。システムの複雑さや組織的な課題もあります。これらの課題を理解し、チャンスと思って取り組める人には、非常に魅力的な環境だと思います。 私は40代で転職しましたが、 転職が遅かったとは感じていません 。むしろ、経験を活かして新しい挑戦ができる貴重な機会になっています。 迷っている方は、まずは話を聞いてみることをお勧めします。 また、文中に出てきた面接官の方も登壇(レガシーシステムの改善についても！)される RAKUS Tech Conference 2025 が8月7日に予定されています。 気になる方は是非参加してみてください！ ここまで読んでくださり、ありがとうございました。 最後に、この半年間で多くの方々にご支援いただき、本当に感謝しています。ありがとうございます。今後ともよろしくお願いいたします。

自己紹介 ラクスでPdMをしております。 @keeeey_m と申します。 現在の担当商材は、楽楽シリーズ(楽楽精算、楽楽明細、楽楽電子保存、楽楽債権管理)を担当しており、個人としては楽楽精算×AIの担当、楽楽明細・楽楽電子保存・楽楽債権管理PdMチームのリーダーをしております。 はじめに 最近、プロダクト開発の現場で事業成長のための指標設計について考える機会がありました。現代のビジネス環境は、技術革新の加速、市場のグローバル化、そして顧客ニーズの多様化と複雑化により、かつてないほどの速さで変化しています。 このような状況下で、単に優れた製品を開発するだけでは持続的な成長を確保することが困難になっていると感じています。従来のプロダクト開発手法では、往々にして市場の要求や顧客の潜在的な欲求を見誤り、結果としてリソースの無駄や競争力の低下を招くリスクが高まっています。 特に気になるのが、多くの企業が陥りがちな短期的な売上（PL）に直結するKPIばかりを追いかける「泥沼サイクル」です。 今回、事業成長のために不可欠な重要な考え方、「ジョブ理論（Jobs To Be Done: JTBD）」について、楽楽精算での実践を元にまとめてみました。 自己紹介 はじめに 従来の顧客分析手法の限界 「泥沼サイクル」のリスク 泥沼サイクルの負のスパイラル ジョブ理論の本質的な価値 「誰が」「何を」から「どんな状況で」「なぜ」への視点転換 従来の手法 vs ジョブ理論の視点転換 顧客の「片付けたいジョブ」に焦点を当てる重要性 予測可能なイノベーション創出のメカニズム 機能競争からの脱却 競争優位性の構築 製品ライフサイクルを超えた持続的イノベーション 市場変化への柔軟な対応 実際の取り組み事例 まとめ 従来の顧客分析手法の限界 従来のマーケティング手法は、年齢や性別といった顧客の属性（デモグラフィックデータ）や心理的特徴（サイコグラフィックデータ）を重視してきました。しかし、このアプローチには根本的な限界があります。 問題点 顧客の表面的な属性に依存している 「誰が」「何を」買うかに注目しがち 顧客の真の動機や状況を理解できていない 短期的な売上KPIに囚われやすい 「泥沼サイクル」のリスク 多くの企業が陥りがちなのが、短期的な売上（PL）に直結するKPIばかりを追いかける「泥沼サイクル」です。 泥沼サイクルの負のスパイラル 泥沼サイクルの特徴 新規獲得ARPU、アップセルによるNRR（Net Revenue Retention：既存顧客からの収益維持率）など短期的KPIの追求 プロダクトの価値向上（貸借対照表に関わる活動）の後回し 顧客に提供できる価値の総量が変わらないまま、短期的な売上の伸び悩み 一度成長が止まってからの立て直しに膨大な時間と労力が必要 特にSaaSのようなビジネスモデルでは、プロダクト価値が上がらなければ遅かれ早かれ売上成長は止まり、持続的な成長が困難になります。 泥沼サイクルの影響 短期的KPIのみを追求した企業は、長期的に見て成長率の低下を経験することが多い プロダクト価値向上に投資した企業は、持続的な成長を実現しているケースが多い 一度泥沼サイクルに陥った企業は、脱却に相当な時間と労力を要することが一般的 ジョブ理論の本質的な価値 「誰が」「何を」から「どんな状況で」「なぜ」への視点転換 ジョブ理論（Jobs To Be Done: JTBD）は、ハーバードビジネススクールのクレイトン・クリステンセン教授が提唱した画期的な理論です。この理論の核心は、顧客が商品やサービスを購入する行為そのもののメカニズムを解き明かすことにあります。 従来の手法 vs ジョブ理論の視点転換 ジョブ理論の基本概念 顧客は単に商品やサービスを購入しているのではない 特定の状況下で「成し遂げたい進歩」、すなわち「ジョブ（用事・仕事）」を片づけるために、その商品やサービスを「雇用（消費）」する 「どんな状況で」「なぜ」買うのかに焦点を当てる 顧客の「片付けたいジョブ」に焦点を当てる重要性 ジョブ理論では、顧客が直面している状況と彼らが目指すべき進歩を深く理解することが重要です。 5つの重要な問い その人が成し遂げようとしている進歩は何か 苦心している状況は何か 進歩を成し遂げるのを阻む障害物は何か 不完全な解決策で我慢し、埋め合わせの行動を取っていないか その人にとって、よりよい解決策をもたらす品質の定義は何か、また、その解決策のために引き換え（トレードオフ）にしてもいいと思うものは何か この視点の転換により、企業は顧客の表面的な要求ではなく、その背後にある根本的な課題や欲求を理解することができ、真に価値あるソリューションの創出へと導かれます。 予測可能なイノベーション創出のメカニズム ジョブ理論は、イノベーションを「予測可能」にする強力なメカニズムを提供します。 予測可能性の理由 一時的な流行や技術の進歩に依存しない 人間の普遍的な「ジョブ」に根ざしている 顧客の「片付けたいジョブ」を発見することで、市場に新たな価値を提供 成熟した業界であっても、顧客に真に支持される新商品やサービスを展開可能 機能競争からの脱却 従来のプロダクト開発では、機能の多さや技術的な優位性を競争の軸としてきました。しかし、ジョブ理論の導入により、企業は機能競争から脱却し、より本質的な競争優位性を構築できます。 機能競争の限界 機能の多さは模倣されやすい 技術的優位性は時間とともに失われる 顧客の真のニーズから離れるリスク 価格競争に陥りやすい ジョブ理論による差別化 顧客の「片付けたいジョブ」を深く理解 機能的価値を超えた情緒的・社会的価値の提供 顧客の状況と文脈に特化したソリューション 競合が模倣しにくい深い顧客ロイヤルティ 競争優位性の構築 ジョブ理論を活用した企業は、顧客の「ジョブ」解決能力そのものを競争優位性として確立できます。 競争優位性の源泉 1. 深い顧客理解 顧客の真の動機と状況を理解 表面的な要求ではなく根本的な課題を解決 顧客の潜在的なニーズを発見 2. 予測可能なイノベーション 人間の普遍的な「ジョブ」に根ざしたイノベーション 一時的な流行に依存しない持続的な価値創造 市場の変化に柔軟に対応 3. 顧客ロイヤルティ 顧客の感情や社会的な欲求を満たす 競合が模倣しにくい深い関係性を構築 長期的な顧客価値の向上 具体例：Appleの競争優位性 機能的価値 : 高品質なハードウェアとソフトウェア 情緒的価値 : 「イケている集団に属している」という感覚 社会的価値 : 自己表現と創造性の実現 競争優位性 : 顧客の多面的な「ジョブ」を包括的に解決する能力 事例についての補足 以下に紹介する事例は、ジョブ理論の概念を基に具体的な状況や成果を説明するために、各企業に適用した二次的な解釈や分析をしてみました。 他の事例 企業 業界 従来の競争 ジョブ理論アプローチ 結果 Tesla 自動車業界 燃費、馬力、価格 「環境に配慮しながら、高性能な車で移動したい」 電気自動車市場での圧倒的なブランド価値 Spotify 音楽業界 楽曲数、音質 「いつでもどこでも、自分の好みに合った音楽を楽しみたい」 パーソナライゼーション機能による差別化 Airbnb 宿泊業界 価格、立地、設備 「現地の人々のように生活し、ユニークな体験をしたい」 体験型旅行という新市場の創出 製品ライフサイクルを超えた持続的イノベーション 製品ライフサイクル理論（PLC）は、製品が導入期、成長期、成熟期、衰退期という段階を経ることを示唆しています。しかし、ジョブ理論の視点から見ると、顧客の「ジョブ」は製品そのものよりも普遍的で持続的です。 製品とジョブの違い 製品の特性 有限な寿命を持つ 技術の進歩により陳腐化する 市場の変化により衰退する 競合により模倣される ジョブの特性 普遍的で持続的 人間の基本的な欲求に根ざす 変化の速度が遅い 時代を超えて存在する 具体例：「移動する」というジョブ 過去 : 馬車 → 自動車 → タクシー 現在 : Uber、Lyft、電動スクーター 未来 : 自動運転車、空飛ぶ車 不変 : 「現在地から目的地に移動する」というジョブ 市場変化への柔軟な対応 ジョブ理論を基盤とした企業は、市場の変化に柔軟に対応できます。 柔軟性の源泉 1. ジョブ中心の視点 製品の寿命に縛られない 顧客の「ジョブ」の変化を捉える 新たな「ジョブ」の出現を発見 2. 継続的なイノベーション 既存製品の改善点を発見 全く新しい製品カテゴリを創出 顧客の未解決のジョブに焦点を当てる 3. 戦略的柔軟性 製品が衰退期に入っても、その背後にある「ジョブ」を解決する新たなソリューションを開発 ビジネスの継続性を確保 長期的な成長軌道を維持 企業 初期 中期 現在 不変のジョブ Netflix DVDレンタルサービス ストリーミングサービス オリジナルコンテンツ制作 「質の高いエンターテイメントコンテンツを手軽に楽しむ」 Microsoft PCソフトウェア クラウドサービス AI・機械学習プラットフォーム 「生産性を向上させ、仕事を効率化したい」 実際の取り組み事例 ジョブ理論の考え方を実際のプロダクト開発に活用した事例をご紹介します。 楽楽精算での実践 昨年度、楽楽精算のAI開発ロードマップを公開しました。製品へAIを活用していく段階で、ジョブ理論に基づき経費精算周辺の不変的な業務を整理しました。 www.rakurakuseisan.jp 取り組みの流れ 1. 業務に関わる人とその工程の整理 経費精算業務に関わる全てのステークホルダーを特定 不変なジョブに目を向けること 2. 重要ジョブの特定 経費精算における顧客の真の「片付けたいジョブ」を深く理解 表面的な業務効率化ではなく、根本的な課題解決に焦点 この取り組みにより、経費精算という業務における顧客の真の「ジョブ」を明確にすることができました。これにより、短期的な機能追加ではなく、顧客価値の向上に焦点を当てた持続的な成長戦略の基盤を構築できています。 しかし、このジョブだけでユーザーをわかった気にならず、一次情報を得ることが重要だと日々痛感しています。 まとめ 現代の競争が激しい市場において、プロダクト開発は単なる機能追加や技術競争に留まるべきではありません。従来の手法では、短期的な売上目標に囚われ、プロダクトの真の価値向上を見失う「泥沼サイクル」に陥るリスクがあります。 ジョブ理論の導入により、企業は 顧客の真の「ジョブ」を深く理解する ことで、 予測可能なイノベーションを創出 し、 持続的な競争優位性を構築 できる。 これこそが、未来のビジネス成長とイノベーションを牽引する鍵となります。 次回は、組織全体の方向性を統一する鍵である「ノーススターメトリック」についてまとめたいと考えております。

1. はじめに こんにちは！配配メール開発チームのos188です。 今回は、 長年動き続けてきたレガシーシステムに向き合い、現実的なリファクタリングに挑戦した 事例をご紹介します。 1. はじめに なぜリファクタリングに踏み切ったのか？ 2. リファクタリング方針と技術選定 既存システムの構成 リファクタリングの主な方針 3. 実践！レガシーコードをモダンに生まれ変わらせるステップ ステップ1：既存ソースの徹底把握 ステップ2：新クラス構成とフォルダ構成の検討 ステップ3：ドメインモデル設計・実装 ステップ4：実装 ステップ5：E2Eテスト・リグレッションテスト 4. 数値で見る劇的改善！PhpMetricsとPHPUnitカバレッジが語る真実 PhpMetricsで見る静的解析と構造変化 PHPUnitカバレッジで見るテスト品質の変化 内部品質の総評 5. 肌感覚で実感する変化 6. まとめ・今後の展望・感想 なぜリファクタリングに踏み切ったのか？ 配配メールは18年続く長寿プロダクトです。 私たちのチームでは「開発速度の向上と、ユーザーへの迅速な価値提供」をテーマに、継続的な改善を推進しています。 長年の開発により、 改修時の影響範囲が把握しづらく、品質維持コストが増大し、開発スピードが低下 するという課題が顕在化していました。 具体的には、クラスの肥大化・複雑化やテストコードの不足によって、リファクタリング自体が進まない状況でした。 この現状を打開するため、まずは1機能に絞って本格的なリファクタリングに挑戦しました。 2. リファクタリング方針と技術選定 既存システムの構成 配配メールにはメインシステムとサブシステムが存在します。 サブシステムはここ3〜4年で構築されており、利用しているフレームワークや設計思想がメインシステムと大きく異なります。 メインシステム ：レガシーなフレームワーク + MVCモデル サブシステム ：Slim + DDD・オニオンアーキテクチャ リファクタリングの主な方針 今回のリファクタリング対象は、メインシステムの1機能です。 新旧で設計思想も技術も異なる中、今回は レガシーなフレームワークは継続利用 サブシステムで実績のあるDDDとオニオンアーキテクチャの思想を取り入れる という現実的な折衷案を採用しました。 本来であればレガシーなフレームワークから脱却したかったのですが、全体への影響が大きいため、現時点では現実的ではありませんでした。 そのため、サブシステムに近い設計思想を取り入れることで、フレームワークの刷新はできないものの、アプリケーション層のモダン化と設計の統一を図りました。 3. 実践！レガシーコードをモダンに生まれ変わらせるステップ ステップ1：既存ソースの徹底把握 まずはリファクタリング対象の現状ソースを徹底的に調査しました。 どこからどこまでが影響範囲か、どのロジックがどこにあるかを洗い出し、リファクタリングのスタート地点を明確にする作業です。 既存ソースは以下のような状態でした。 旧コードの状態 モデルクラス さまざまなビジネスロジックやDB操作が混在している状態 ビュークラス (テンプレートファイル) 今回は手を加えないためスキップ コントローラークラス 本来モデルクラスにあるべきDB操作がこのクラスに書かれている等、責務があいまい ステップ2：新クラス構成とフォルダ構成の検討 ステップ1の調査結果をもとに、構成方針を決定しました。 新コードの構成 コントローラークラスは継続使用 フレームワークを使い続けるため、大きくは変えられない Presentation/配下に配置 アーキテクチャの思想に沿ってクラスごとの責務が明確になるよう修正 モデルクラスは完全に解体 アプリケーション層（Application/）、ドメイン層（Domain/）、インフラ層（Infrastructure/）へ再編成 その他、例外クラスの設計やプレゼンテーション層 <-> アプリケーション層のデータ受け渡しにDTO（データ転送オブジェクト）を利用するなど、細かなルールも定めました。 ステップ3：ドメインモデル設計・実装 ドメインモデルの設計では、必要なクラスを一度すべてドキュメントに書き出し、設計レビュー・認識合わせのMTGを行いました。 設計方針とクラスごとの責務が固まった時点で、ドメイン層の主要クラスの骨組みをまとめて実装しました。 ステップ4：実装 ステップ1~3で決めた設計や方針に従い、ユースケースごとに 実装 ユニットテスト実装 手動の単体テスト 受入 というサイクルを繰り返しながら進めました。 リファクタリングにあたり、テストコードが存在しない状態から、できる限りユニットテストを整備することを当初から目標としていました。 ただし、レガシーな部分を完全に解消できるわけではないため、テスト実装が困難なケースについては、手動による単体テストでカバーする方針としました。 ステップ5：E2Eテスト・リグレッションテスト リファクタリング前後で内部実装が変わっていても、外部から見たふるまいが変わっていないことを確認するため、E2Eテストや、作成されるDBデータを用いたリグレッションテストを実施する方針としました。 E2Eテストは新たにPlaywrightで作成しました。 4. 数値で見る劇的改善！PhpMetricsとPHPUnitカバレッジが語る真実 今回のリファクタリングによる品質変化を、客観的な数値で振り返ります。 従来コードはドメイン分割が不十分かつテストコードも存在せず、内部品質に多くの課題がありました。 再設計とテスト導入を経て、明らかな改善が見られました。 PhpMetricsで見る静的解析と構造変化 PhpMetricsの結果比較 PhpMetrics による静的解析の結果、 全体のコード行数は約1.7倍、クラス数は約4.7倍に増加しました。 これは、単一の大きなクラスに依存していたものを、小さく責務を明確にしたクラスへ分割した結果です。 コード量は増えましたが、 1クラスあたりの平均的な複雑度（循環的複雑度や加重カウント）は大幅に減少 しており、クラス・メソッド単位でシンプルになったことが分かります。 違反数は以下のように変化しています。 Errors：9 → 3 Warnings：2 → 11 致命的なバグや設計上の問題は大幅に整理され、コードの信頼性が向上しました。 Warningsが増加した主な理由は、もともとパッケージという概念がなかったコードに対して、オニオンアーキテクチャやDDDによる層分割を導入したことで、特に既存テンプレート仕様に合わせた複雑なコントローラークラスに警告が集中したためです。 また、HalsteadやKanによる 推定バグ数・欠陥数も大きく減少 し、バグ混入リスクが定量的にも下がったことが示されています。 インターフェース数の増加により、抽象化や将来的な拡張性、テスト容易性も高まりました。 一方で、クラス間の依存関係が増えたことで、システム全体の相対的な複雑度は上昇しています。 これは多層アーキテクチャの特徴であり、拡張性や保守性とのトレードオフなので想定内です。 PHPUnitカバレッジで見るテスト品質の変化 リファクタ後のPHPUnitカバレッジ 旧コード（リファクタリング前）では、リファクタリング対象機能のユニットテストが まったく存在せず、テストカバレッジは0% でした。 リファクタリング後は、Application層・Domain層で一定以上のカバレッジを実現できました。 ビジネスロジックやユースケースのコア部分がしっかりテストで守られるようになり、安心感が格段に高まりました。 一方、Presentation層のカバレッジは約5%と低い水準にとどまりました。 これはフレームワークの制約や、画面に強く依存するロジックが多いことが理由です。 同様に、Infrastructure層もDBアクセスや例外処理の一部が十分にテストできず、クラス単位のカバレッジは約15%にとどまりました。 ただし、これらはE2Eテストやリグレッションテストで補完しています。 内部品質の総評 全体として、 内部品質は確実に向上 したと評価できます。 責務の分割が進み、各クラスがシンプルになり、保守・拡張しやすい構造になりました。 テストコードの整備によって品質を定量的に担保できるようになった点も大きな成果です。 ただし、レガシーなフレームワークを維持しているため、一部既存構造を引き継がざるを得ない部分も残っています。 ここは今後の課題です。 また、テストコードについてもフレームワークとの相性や設計上の制約から全体を網羅するには至りませんでしたが、重要部分は手動の単体テストやリグレッションテストで十分にカバーしています。 5. 肌感覚で実感する変化 今回のリファクタリングで現場がどう変わったか、旧コードを熟知しているメンバーにアンケートを実施しました。 まず「読みやすさ」については、新アーキテクチャに慣れているメンバーから「圧倒的に読みやすくなった」という回答が100%でした。 一方、サブシステムの実装経験がないメンバーからは「旧コードの方が馴染みがあるので初見ではそちらが読みやすい」という正直な感想もありましたが、 “今のコードのほうが可読性・保守性が高い” という評価は一致して得られました。 また、開発や保守に対する心理的ハードルについては、 処理ごとの責務が明確になり、影響範囲が見通せるようになったことで改修への不安が減った、 ユニットテストがあることで品質確保の安心感も向上したと評価されました。 コード構造を把握しやすくなったことで、既存機能のキャッチアップも楽になるかもという声も聞かれました。 6. まとめ・今後の展望・感想 今回のリファクタリングは、まだメインシステム全体のごく一部に過ぎません。 しかし、 「数値で」「肌感覚で」 、確かな手応えを得ることができたと実感しています。 今後は、このリファクタリング手法やノウハウをチーム全体で共有し、リファクタリングの加速を目指していきます。 また、メインシステムの新規実装は依然としてMVCですが、オフショアメンバーも含めてオニオンアーキテクチャの思想がシステム全体に広がっていく日を目指したいと考えています。 最後に、個人的な感想として、新卒3年目でこのような本格的なリファクタリングに挑戦できたことは本当に良い経験となりました。 普段の開発業務と並行しながら、改善活動にも時間を割いて挑戦させてくれるチームと会社には心から感謝しています。 これからも継続的な改善を重ね、プロダクトの価値創造に貢献していきたいです。

mixedbread-ai/ Alibaba-NLP / OpenAI GPTによるリランキング【実装サンプル付き】 はじめに RAGをはじめとする現代の情報検索システムでは、「リランカー（Reranker）」と呼ばれる仕組みが使われることがあります。 検索候補を単にキーワードマッチやベクトル検索でピックアップするだけでなく、さらに高精度なモデル(＝リランカー)で再スコアリング（再ランキング）することで、ユーザーが本当に求めている情報を上位に表示できます。 本記事では、筆者が実際に業務中の検証作業で利用した次の3つのモデル: mixedbread-ai/mxbai-rerank-v2 Alibaba-NLP/gte-multilingual OpenAIのGPT（Chatモデルをリランカーとして活用） を題材に、特徴や実装例を紹介します。 mixedbread-ai/ Alibaba-NLP / OpenAI GPTによるリランキング【実装サンプル付き】 はじめに 1. リランカーとは？ 2. 各リランカーモデルの特徴 mixedbread-ai/mxbai-rerank-v2 Alibaba-NLP/gte-multilingual OpenAI GPT（Chatモデルをリランカーとして利用） 3. 実装サンプル mixedbread-ai/mxbai-rerank-v2 を使ったリランカー Alibaba-NLP/gte-multilingual を使ったリランカー OpenAI GPT（gpt-4.1-mini）を使ったリランカー リランキングの実行 4. まとめ 参考リンク 1. リランカーとは？ リランカーは、情報検索の 「第二段階目」 を担う仕組みです。 一次検索 ： BM25などのキーワード検索やベクトル検索で候補文書を多数ピックアップ リランカーによる再ランキング ： 高度な意味理解や言語能力を持つモデルで、一次検索結果を再評価して順位付け リランカーは、FAQ検索やナレッジベースのチャットボットなど、ユーザー体験の鍵となる部分で利用されています。 2. 各リランカーモデルの特徴 mixedbread-ai/mxbai-rerank-v2 2025年3月に公開された比較的新しめのモデル Apache 2.0で公開されており、商用利用が可能 軽量モデルもありCPU環境でも使いやすい 専用のライブラリ(mxbai_rerank)から手軽に利用できる Alibaba-NLP/gte-multilingual 中国の大企業Alibaba製 Hugging Faceでモデルが公開されており、transformersライブラリから簡単に利用できる Apache 2.0で公開されており、商用利用が可能 70言語以上に対応している(らしい)　※ 日本語と英語に対応していることは確認済 OpenAI GPT（Chatモデルをリランカーとして利用） 専用のライブラリ(opeaai)やlangchainから簡単に利用できる プロンプトによって挙動を柔軟に調整できる 高性能モデルを使う場合、高い精度が期待できる API利用のため運用コスト・レイテンシには注意 3. 実装サンプル 上記3つのモデルを実装してみます。 それぞれのモデルの実装の互換性を保つために最初にデータクラスとリランカーの抽象クラスを実装しておきます。 from abc import ABC, abstractmethod from pydantic import BaseModel, Field class RankResult (BaseModel): index: int score: float document: str = "" class BaseReranker (ABC): @ abstractmethod def rerank (self): pass mixedbread-ai/mxbai-rerank-v2 を使ったリランカー from mxbai_rerank import MxbaiRerankV2 class MxbaiReranker (BaseReranker): def __init__ ( self, model_name: str 　=　 "mixedbread-ai/mxbai-rerank-base-v2" , ): self.model = MxbaiRerankV2(model_name, device= "cpu" ) def rerank ( self, query: str , documents: list [ str ], return_documents: bool 　=　 True , top_n: int 　=　 3 , ) -> list [RankResult]: results = self.model.rank( query, documents, return_documents=return_documents, top_k=top_n, ) return results mxbai_reranker = MxbaiReranker() Alibaba-NLP/gte-multilingual を使ったリランカー import torch from transformers import AutoModelForSequenceClassification, AutoTokenizer class AlibabaReranker (BaseReranker): def __init__ ( self, model_name: str = "Alibaba-NLP/gte-multilingual-reranker-base" ): self.tokenizer = AutoTokenizer.from_pretrained(model_name) self.model = AutoModelForSequenceClassification.from_pretrained( model_name, trust_remote_code= True , torch_dtype=torch.float32, ) self.model = self.model.to( "cpu" ) self.model.eval() def rerank ( self, query: str , documents: list [ str ], return_documents: bool = True , top_n: int = 3 , ) -> list [RankResult]: pairs = [[query, doc] for doc in documents] with torch.no_grad(): inputs = self.tokenizer(pairs, padding= True , truncation= True , return_tensors= 'pt' , max_length= 512 ).to( "cpu" ) scores = self.model(**inputs, return_dict= True ).logits.view(- 1 , ).float() index = 0 rank_results = [] for p, s in zip (pairs, scores): rank_results.append( RankResult( index=index, score=s.item(), document=p[ 1 ] if return_documents else "" , ) ) index += 1 rank_results.sort(key= lambda x: x.score, reverse= True ) return rank_results[:top_n] alibaba_reranker = AlibabaReranker() OpenAI GPT（gpt-4.1-mini）を使ったリランカー import os from langchain_core.output_parsers import StrOutputParser from langchain_core.prompts import ChatPromptTemplate from langchain_openai import ChatOpenAI API_KEY = "XXXXX" os.environ[ "OPENAI_API_KEY" ] = API_KEY RERANK_PROMPT = """queryとなるテキストと複数のテキストを含むtext_listが与えられます。 text_listの中のテキストとqueryの内容を比較し、queryの内容と近い順にtext_listのテキストを並べ替えなさい。 ***条件*** 1. queryとの内容が近い順に並べたテキストのインデックスとスコアのリストを返すこと。 2. スコアは0.0から1.0の範囲で、queryとの内容が近いほど高くなるようにすること。 """ class RerankedIndex (BaseModel): index: list [ int ] = Field( default=[], description= "queryとの内容が近い順に並べたテキストのインデックスのリスト。" ) score: list [ float ] = Field( default=[], description= "queryとの内容が近い順に並べたテキストのスコアのリスト。" ) class OpenaiReranker (BaseReranker): def 　__init__( self, model_name: str = "gpt-4.1-mini" , ): self.model = ChatOpenAI( model=model_name, max_tokens= 1000 , # temperature=0.0, top_p= 0.01 , seed= 42 , ) self.prompt = ChatPromptTemplate.from_messages( [ ( "system" , RERANK_PROMPT), ( "human" , "query: '{query}' \n text_list: '{text_list}'" ), ]) self.chain = self.prompt | self.model.with_structured_output(RerankedIndex) def _rerank_text ( self, query: str , text_list: str , ) -> int : res = self.chain.invoke({ "query" : query, "text_list" : text_list}) return res def rerank ( self, query: str , documents: list [ str ], return_documents: bool = True , top_n: int = 3 , ) -> list [RankResult]: text_list = [f "{i}. {doc}" for i, doc in enumerate (documents)] text_list = " \n " .join(text_list) res = _rerank_text(query, text_list) index_score_pairs = list ( zip (res.index, res.score)) rank_results = [] for idx, score in index_score_pairs: rank_results.append( RankResult( index=idx, score=score, document=documents[idx] if return_documents else "" , ) ) rank_results.sort(key= lambda x: x.score, reverse= True ) return rank_results[:top_n] openai_reranker = OpenaiReranker() リランキングの実行 実行例 test_query = "Give me the first document." test_documents = [ "This is the first document." , "This is the second document." , "This is the third document." , "This is the fourth document." , "This is the fifth document." , ] res_mxbai = mxbai_reranker.rerank(test_query, test_documents, return_documents= True , top_n= 3 ) res_gte = alibaba_reranker.rerank(test_query, test_documents, return_documents= True , top_n= 3 ) res_openai = openai_reranker.rerank(test_query, test_documents, return_documents= True , top_n= 3 ) 4. まとめ 筆者の検証においてリランキングの精度は、 openai (gpt-4.1-mini) > mxbai > alibaba といった結果になりました。 (精度は対象のテキスト群の内容によるところも大きいと思いますが...)、 実行コストが最も高いopenaiを使ったリランカーで最も良い結果が得られるのは妥当なように思います。 リランカーは検索体験の向上に役立ちます。各モデルの特性やプロダクト要件に応じて、最適な選択を検討してみてください！ 参考リンク mixedbread-ai/mxbai-rerank-base-v2 (HuggingFace) Alibaba-NLP/gte-multilingual-reranker-base (HuggingFace)