はじめに 私たちのモバイルアプリ(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)

先日、株式会社ラクス主催の技術イベント「RAKUS AI Meetup」がオンラインで開催されました。本イベントは、ラクスの AI技術 への取り組みや活用事例を社外の方々にも広く知っていただくことを目的としており、当日は多くの方にご視聴いただきました！！ 「楽楽精算」「メールディーラー」といった主力サービスへのAI機能組み込みの裏側から、開発本部全体でのAIツール活用による生産性向上まで、3つの具体的なセッションを通して、ラクスのAI開発のリアルが語られました。 本記事では、各セッションの模様をダイジェストでお届けします！ （記事執筆は当イベントの司会も担当しました、技術広報の川東がお届けいたします） セッション1：AIは精算業務をどう変える？自律型エージェントが実現する未来のワークフロー セッション2：メールディーラーにおけるAI活用事例～クレーム検知機能リリースの舞台裏～ セッション3：自律型AIエージェントDevinを全エンジニアへ展開！！ラクス開発本部のAI駆動開発事例 まとめ RAKUS Tech Conference 2025 開催します！！ セッション1：AIは精算業務をどう変える？自律型エージェントが実現する未来のワークフロー 登壇者：楽楽精算事業統括部 AIエージェント開発課 課長 石田浩章 speakerdeck.com トップバッターは、主力サービス「楽楽精算」へのAIエージェント導入をミッションとするAIエージェント開発課 課長の石田です。発表は、AIエージェント開発課が立ち上がった 「怒涛の1ヶ月」 の裏話から始まりました。 「楽楽精算ってなんですか？」 という衝撃的な状況からスタートし、わずか1ヶ月でチームを組成。しかし、そこには「AIエージェント像の不明瞭さ」「多すぎるステークホルダー」「圧倒的なリソース不足」という大きな壁が立ちはだかっていました。 この困難な状況を打開するために、石田が繰り出した3つの「秘策」が非常に興味深いものでした。 秘策1：LEAN開発で不明瞭なAIエージェント像を発見 従来のウォーターフォール型ではなく、作りながら・聞きながら学ぶLEAN開発を採用。1週間サイクルでモックアップやプロトタイプを作成し、顧客ヒアリングを繰り返すことで、あるべき姿を具体化。 秘策2：チームメンバー全員で臨むオールラウンド型組織 事業責任者とエンジニアが一体となった少数精鋭チームを組成。職能の垣根を越え、全員が「自分ごと」として開発に取り組むことで、スピード感と当事者意識を醸成。 秘策3：「トリAI(アイ)ズム」で足りないリソースを突破 「とりあえずAIを使ってみよう」というスタンスで、Claude CaudeやDevin、MiroのAI機能などを積極的に活用。6人目、7人目のメンバーとしてAIを使いこなし、リソース不足を補いました。 現在は、「経費精算」における 「領収書」を元にした「申請支援」機能 に注力しており、今後は段階的にクローズド版の提供や機能拡大を進めていくとのこと。ゼロからチームを立ち上げる生々しいストーリーに、参加者からも多くの共感が寄せられました。 セッション2：メールディーラーにおけるAI活用事例～クレーム検知機能リリースの舞台裏～ 登壇者：ラクス クラウド事業部 メールディーラー開発課 PdM 神山賢太郎 speakerdeck.com 続いて、問い合わせ管理システム「メールディーラー」のPdM（プロダクトマネージャー）であるメールディーラー開発課 PdMの神山が登壇。ラクス製品の中で 最速でリリースされたAI機能「クレーム検知機能」 の開発の舞台裏が語られました。 この機能は、ChatGPTがメール本文を解析し、クレーム性の高いメールを自動で検知・ラベリングすることで、炎上を未然に防ぎ、迅速な初期対応を可能にするものです。 開発プロセスでは、まず社内で仮説サイクルを回し、その後、顧客を巻き込んで実証サイクルを進めるという2段階のアプローチを採用。 特に興味深かったのは技術調査のパートです。 Pythonライブラリでの感情分析 vs GPTでのクレームスコア付け 当初はPythonライブラリでの感情分析を検討。しかし、ビジネスメール特有の「へりくだった表現」を過剰にネガティブと判定してしまう課題が発覚。 一方、GPTにプロンプトを工夫してクレーム度合いをスコアリングさせたところ、精度が大幅に向上。最終的にGPTの採用を決定しました。 β版の検証では、ToB（法人向けビジネス）では高い精度を発揮した一方、ToC（個人向けビジネス）では誤検知が多いことが判明。この結果を受け、 ターゲットを明確にToBに絞る という戦略的な意思決定が行われました。この結果も 高速にPDCAを回す仮説サイクルによって得られた ものです。 リリース後は、「会議中にクレーム通知を受け、即座に担当者に指示出しができた」「大量のメールの中からクレームを優先的に対応できるようになった」など、顧客から高い評価を得ているそうです。最速リリースを支えた仮説検証と迅速な意思決定のプロセスは、多くの開発者にとって参考になる内容でした。 セッション3：自律型AIエージェントDevinを全エンジニアへ展開！！ラクス開発本部のAI駆動開発事例 登壇者：開発管理部 開発管理課 課長 池田智裕 speakerdeck.com 最後のセッションでは、開発本部全体を横断的にサポートする開発管理課 課長の池田が登壇。「現場が開発に専念できる環境を整える」というミッションのもと、いかにしてAIツールを全社的に推進しているかが語られました。 ラクス全社では 「スピードアップ」と「AI活用による生産性向上」 を重点取組に掲げており、開発本部における推進役を開発管理課が担っています。 発表では、AIツール導入の歴史が第1弾から第4弾まで紹介されました。 第1弾（2023年5月）： GitHub Copilot Businessの導入 検証の結果、平均 12%の稼働削減効果 が見られ、年間 1億円以上のコスト削減効果 が見込めることが判明し、全エンジニアへ展開。 第2弾（2024年2月）： GitHub Copilot Enterpriseの導入 自社のプライベートリポジトリを学習させることで、より精緻な提案が可能に。 第3弾（2025年3月頃）： Devinの導入 「生産性爆上がりですよね？」と期待を寄せ、即座に導入検証を決定し、全エンジニアに開放。 第4弾（近況）： Cursor / Junie / Claude Codeの導入 次々と生まれる新しいツールに対し、エンジニアがチームや自分のスタイルに合ったものを選択できる環境を整備。 ツール導入の大きな課題は、法務やセキュリティの確認に時間がかかること。そこで、「顧客情報を入力しない」というルールを前提に、開発本部内のチェックリスト運用で利用OKとするフローに変更。これにより、検証開始までの期間を数週間から数日へと大幅に短縮しました。 「新しいAIツールが日々生まれる中、組織全体のAIリテラシーを高めていくことが重要」という池田の言葉は、変化の激しい時代を乗り越えるための力強いメッセージとなりました。 まとめ 今回の「RAKUS AI Meetup」では、現場主導のボトムアップな取り組みと、経営層や管理部門によるトップダウンの力強い推進が両輪となって、ラクスのAI開発が加速している様子がリアルに伝わってきました。 各サービスにおける具体的な課題解決から、開発本部全体の生産性向上まで、AIを「使う」だけでなく「使いこなす」ための試行錯誤が随所に見られ、非常に刺激的なイベントでした。 ラクスでは、今後もAIに関する技術イベントを定期的に開催していく予定です。 そこで、皆様へ耳寄りなお知らせ！ RAKUS Tech Conference 2025 開催します！！ techcon.rakus.co.jp 「RAKUS Tech Conference」は、SaaS開発における取り組みや知見を紹介する、ラクス開発本部主催の技術カンファレンスです。 本カンファレンスでは、私たちが24年間で培ってきた技術的な強みと知見、そして現在進行形で取り組んでいる変革へのチャレンジについて、開発現場のリアルな声とともにお届けします。 AI駆動開発、大規模チームのマネジメント、長期プロダクトが向き合う技術的負債、そして新規サービスローンチの舞台裏まで。 ラクス開発本部の"今"と"未来"を、この機会にぜひ体感してください！！ お申込みはこちら https://rakus.connpass.com/event/359025/ 最後までお読みいただき、ありがとうございました。

はじめに：1年後の私たち――進化の軌跡と、ささやかな告白 第1章：グローバル開発モデルの進化――オフショア開発とAIの幸福な出会い 1.1 旧来の認識 vs 現代の現実：オフショア開発の再定義 1.2 中核となるアナロジー：優れたオフショア開発プラクティスは、優れたAIプラクティスである 1.3 AIによる認知負荷の軽減とスキルの平準化：言葉の壁を越える力 1.4 代替不可能な「ヒューマン・イン・ザ・ループ」：AIの限界と人間の価値 第2章：絵に描いた餅で終わらせない――現場起点のAI活用、その道のり 2.1 「なぜやるのか？」から始めるデータ駆動アプローチ 2.2 活用のための足場作りと血の通ったフィードバックループ 第3章：チームトポロジーの加速――自律する現場が生んだ「イネイブリングチーム」の新たな使命 3.1 理論から現実へ：私たちの進化の可視化 3.2 ストリームアラインドチームの成熟：オーナーシップの醸成 3.3 イネイブリングチームの新たな使命：門番から成長エンジンへ まとめ：未来へ向けた開発組織の設計図 さいごに はじめに：1年後の私たち――進化の軌跡と、ささやかな告白 2024年9月の前回記事 から約10ヶ月。グローバル開発体制の基盤構築を共有した当時から、私たちのチームは単なる効率化に留まらない質的な変化を遂げました。この記事はその後の物語です。 本題に入る前に、一つ告白と訂正をさせてください。前回の記事で、開発チームを「ストリームアイランドチーム」と記載しましたが、正しくは「ストリームアラインドチーム（Stream-Aligned Team）」です。 この「アイランド（島）」から「アラインド（連携）」への誤記は、今振り返ると私たちの進化そのものを象徴しているようです。かつて物理的にも意識的にも離れたチームが、いかにして真に連携するに至ったのか。この記事では、その過程で紡いだ3つの物語を共有します。 オフショア開発からグローバル開発モデルの進化: RVとの連携が、共に価値を創造する「パートナーシップ」へと深化。 AIの実践的導入: AIを開発ワークフローに戦略的に組み込み、具体的な成果を創出。 チームトポロジーの加速: 上記2つの進化が触媒となり、チームトポロジーの実践が次のステージへ加速。 この進化の軌跡が、強い開発組織を目指す皆様の参考になれば幸いです。 第1章：グローバル開発モデルの進化――オフショア開発とAIの幸福な出会い 1.1 旧来の認識 vs 現代の現実：オフショア開発の再定義 まず前提として、本記事における用語の定義を明確にしておきます。 「オフショア開発」は、主に開発委託型の関係を指し、「グローバル開発」は、役割・責任を共有し価値創造をともに担う統合型の開発体制 を指します。 これらは単なる言い換えではなく、関係性・責任構造・アウトプットの質において異なると考えています。 「オフショア開発」には「仕様書通りに実装だけを依頼する」という旧来のイメージが根強くあります。しかし、一方通行の関係ではプロダクト価値の最大化は望めません。私たちが目指すのは、統合された「ユナイテッドチーム（United Team）」です。 このモデルでは、RVチームは単なる委託先ではなく、プロダクトの成功に共同で責任を負うパートナーです。ビジネス背景を理解し、主体的に改善提案を行い、日本チームと共にプロダクトを育てていく。この「指示されたものを作る」から「何を、なぜ作るべきか」を共に議論する関係への変化が、私たちの進化の核となります。 1.2 中核となるアナロジー：優れたオフショア開発プラクティスは、優れたAIプラクティスである この移行過程で培ったコミュニケーションの規律が、図らずもAI活用の成功に直結しました。 「優れたグローバル開発プラクティスは、優れたAIプラクティスである」 というアナロジーです。 言語や文化、物理的距離が離れたチーム間で誤解なく情報を伝達するには、暗黙の了解を排し、情報を構造化・明文化する必要があります。このプロセスは、AIに的確な指示を与えるプロンプトエンジニアリングそのものです。乱暴で構造化されていないインプットでもAIは一定のアウトプットを出力しますが、形式化／構造化されたインプットがあれば、より良く、期待するアウトプットを生成します。グローバルチームのために整備したドキュメントやテンプレート、形式化したフローが、そのままAIへのインプットとして機能します。 1.3 AIによる認知負荷の軽減とスキルの平準化：言葉の壁を越える力 グローバル開発において、ブリッジSEは重要な役割を担いますが、母国語以外でのコミュニケーションは大きな認知負荷を伴います。ここでAIが、強力な「認知的なイネーブラー（Cognitive Enabler）」として機能しました。 「日本語の細かな表現を気にせず、仕様レビューに集中できるようになりました。AIが要点から自然な日本語を生成してくれます」 「RVメンバーとベトナム語で議論した内容を、AIが日本語の設計ドラフトに変換してくれます。このスピード感は革命的です」 AIが翻訳や表現の洗練を担うことで、彼らは言語の壁から解放され、仕様の妥当性評価など、より本質的な思考に認知リソースを集中できるようになっています。 1.4 代替不可能な「ヒューマン・イン・ザ・ループ」：AIの限界と人間の価値 AIの能力を引き出す一方、その限界も認識しています。特に生成AIの「ハルシネーション（もっともらしい嘘をつく）」を考慮し、最終的な判断を人間が行う「ヒューマン・イン・ザ・ループ」のプロセスを徹底しています。 設計をしたブリッジSEからは下記のようなフィードバックを頂いています。 AIが古い仕様に基づき誤った回答をした事例を報告し、この経験から、「AIの出力を最大限に活かすためにも、今はまだシステムの文脈を理解した人間による検証が必要です」 「AIに対する現状の内部実装・仕様のインプット方法が不十分であるため、AI活用に向けた内部設計資料の集約方法やインプットを見直した方が良いです これらの事例は、AI活用の成熟度が、単にツールとして使う段階から、いかにAIを自律的なパートナーへと育てていくかという課題に移っていることを示唆しています。壁打ちやドラフト作成は入り口に過ぎず、真の目標はAIがシステムの文脈を深く理解し、自律的に判断する未来です。 現状、人間による検証は不可欠ですが、私たちはこのプロセスを単なる「間違い探し」ではなく、AIをより賢く活用するための「教育プロセス」と捉えています。現在のハイブリッドなアプローチは、一つ一つの検証を通じてAIにフィードバックを与え、人間が介入すべき領域を戦略的に減らしていく。このサイクルを回し続けることこそが、自律的な開発プロセスを実現する道筋だと考えています。 第2章：絵に描いた餅で終わらせない――現場起点のAI活用、その道のり AI活用を成功させる秘訣は、トップダウンの号令だけでなく、いかに現場の課題と結びつけ、ボトムアップで改善を積み重ねられるかにあります。「我々の課題を解決するためにAIをどう使うか」という問いからすべては始まりました。 2.1 「なぜやるのか？」から始めるデータ駆動アプローチ 私たちのAI活用は「AIを使おう」という結論ありきではありませんでした。まず開発プロセス全体の「業務棚卸」を行い、データに基づきボトルネックとインパクトの大きい課題を特定しました。 例えば、設計ドキュメントの形式が標準化されておらず手戻りが頻発していたため、AI導入の前に、まず人間が理解しやすいようプロセスを「標準化」することから着手しました。 この地味なステップが後のAI活用の成否を分けます。 2.2 活用のための足場作りと血の通ったフィードバックループ AIの力を組織全体で引き出すには、一部の専門家だけが活躍する状況では不十分です。誰もが一定品質でAIを活用できる「足場」として、マニュアルやテンプレートを整備し、ノウハウを組織の共有資産として形式知化しました。 もちろんツール整備だけでは不十分で、それらが現場でどう使われているか生きた情報を吸い上げる「フィードバックループ」が不可欠です。 現場からは「定型作業が楽になった」というメリットと共に、「AIの出力は鵜呑みにできず、人間による検証が不可欠」というバランスの取れたフィードバックが常に寄せられています。 第3章：チームトポロジーの加速――自律する現場が生んだ「イネイブリングチーム」の新たな使命 グローバル開発体制の成熟とAIによる生産性向上は、私たちの組織構造に影響を与え、チームトポロジーの実践を加速させました。 3.1 理論から現実へ：私たちの進化の可視化 チームトポロジーに基づきチームの変遷を振り返ると、その進化は明確です。 As-Is（かつての姿）: 日本のエンジニアがハブとなり、ほぼ全ての関係者と連携する必要がありました。コミュニケーションが特定メンバーに集中し、ボトルネックとなる構造的な課題を抱えていました。 To-Be（現在の姿）: ブリッジSEとRVチームがプロダクトの特定領域に責任を持つ、自律した「ストリームアラインドチーム」へと変貌。設計からテストまでを一気通貫で完結できる能力を備えつつあります。それに伴い、日本のエンジニアチームは、彼らを支援する「イネイブリングチーム」へと役割を変えました。 3.2 ストリームアラインドチームの成熟：オーナーシップの醸成 「最近では、日本側が気づかなかった仕様の矛盾点を、RVチーム側から指摘してくれることが増えました」。この言葉が示すように、RVチームはもはや単なる「実装部隊」ではなく、プロダクトのオーナーシップを持ち、主体的に開発をリードする存在へと成長しました。 この自律性の獲得は、第1章と第2章で述べた地道な取り組みの結果です。 コミュニケーション基盤の確立 : 構造化されたドキュメントと思考のフレームワークが、コミュニケーションのオーバーヘッドを削減し、当事者意識を醸成しました。 AIによる能力向上と自信 : AIが言語の壁を取り払い、設計品質を向上させたことで日本チームへの依存が低下。成功体験が彼らの自信とオーナーシップを育みました。 プロセス標準化とAI活用への投資は、RVチームを自律させ、組織のスケーラビリティを高めるための戦略的な布石となっています。 3.3 イネイブリングチームの新たな使命：門番から成長エンジンへ ストリームアラインドチームが日々の開発フローを担うようになり、イネイブリングチーム（日本）はより戦略的な活動に注力できるようになりました。 かつての「 門番（ゲートキーパー） 」から、組織全体の能力を増幅させる「 成長エンジン（グロースエンジン） 」へと生まれ変わったのです。 新たな使命は、開発プロセスの軽量化、マインドセット醸成、上流工程への参画、高難易度技術課題への対応など多岐にわたります。 これらは目先の機能開発より中長期的な視点が求められる「イネーブリング」な仕事です。日々の開発フローが自律したチームによって回っているからこそ、イネイブリングチームは高付加価値な業務に集中できます。 まとめ：未来へ向けた開発組織の設計図 この10ヶ月の旅は 「グローバル開発 → AI活用 → チームトポロジー」 というポジティブな連鎖反応の物語でした。 成熟したグローバル開発モデルが、強固なコミュニケーションの土台を築いた。 その土台があったからこそ、AIを効果的に導入し、生産性と自律性を高めることができた。 AIによって得られた効率と自律性が、チームトポロジーを次の段階へと進化させた。 この経験から得られた学びは、強い開発組織を築くための普遍的な設計図となり得ると考えています。 「オフショア」を「統合されたチーム」へ : パートナーシップにより顧客価値を最大化します。 テクノロジーを課題解決の手段とする : 流行ではなく、具体的な課題を解決するためにAIを活用します。 人間とAIの共生関係を設計する : AIの限界を認識し、人間の判断をプロセスに組み込むことが重要です。 効率化で得たリソースを戦略的業務に再投資する : 生産性向上の最終目的は、より付加価値の高い仕事に集中できる組織デザインの実現です。 さいごに 最後までお読みいただき、ありがとうございます！ かつての「ストリームアイランド（島）」が、AIという追い風を受けて大きな「ストリーム（流れ）」へ。私たちのチームの進化の物語、いかがでしたでしょうか。 これは技術で事業課題を解決しようとするラクスの一つの挑戦例です。これからもエンジニアがより創造性を発揮できる環境を追求し、変化を恐れず進化を続けていきます。 ラクスが目指す新しいものづくりに興味を持っていただけたなら、ぜひ一度カジュアルにお話してみませんか？採用サイトでは募集中のポジションも紹介しています。あなたと共に働ける日を心より楽しみにしています。

開発組織の価値観は、社内にあるだけでは届きません。 定義や行動指針を掲げても、それだけで伝わるわけではない。 むしろ、「なぜ、行動したのか？」「どう意思決定しているのか？」という現場の声こそが、その組織の“らしさ”を表すものだと思います。 私たちラクスは、 創業以来大切にしてきた「顧客志向」の価値観 を、外部に伝える活動に本格的に取り組んでいます。 本記事では、ラクスの開発組織がどのように情報発信と向き合い、今のかたちにたどり着いたのか。その背景にある試行錯誤や、ブログ、イベント開催、カンファレンス登壇などの取り組みをご紹介します。 フェーズ①当初の狙いは“認知拡大” フェーズ②「顧客志向」を軸にブランディングへ 情報発信の２つの方向性 １、技術広報による戦略的かつ計画的な情報発信（=組織ブランディング） ２、開発組織による自主的な情報発信（＝文化づくりと学び） 具体的な情報発信活動事例 エンジニアブログ 主催イベント RAKUSTechConference MeetUp 共催イベント TechCafe カンファレンス登壇 次回は、年1回開催のRakusTechConference2025 フェーズ①当初の狙いは“認知拡大” 情報発信を本格的に始めた2020年当初は、開発組織の存在を広く知ってもらうことが主な目的でした。バズワードや注目キーワードを先行させた社内事例の紹介やイベント企画に注力し、PV・SNSシェア・イベント参加者数はいずれも大幅に増加。国内でもトップクラスのリーチを獲得することができました。 しかし、2年間の活動を振り返る中で、私たちは重要な気づきを得ます。 情報発信は「知らない人に届くこと」以上に、「選考に進んだ方がより深く組織を理解し、志望度を高めること」に大きく貢献していたのです。一方で、「私たちの組織は何を大切にしているのか？」という本質的な価値観までは、十分に伝えきれていないことにも気づきました。 フェーズ②「顧客志向」を軸にブランディングへ この振り返りを経て、私たちは2023年から情報発信の軸を転換しました。 開発組織がもっとも大切にしている価値観――「顧客志向」 これを軸に、「顧客志向のSaaS開発組織」として社外に伝えていくことを、ブランディングの柱と位置づけたのです。 情報発信の２つの方向性 当社開発組織からの情報発信は、主に2つの流れで構成されています。 １、技術広報による戦略的かつ計画的な情報発信（=組織ブランディング） 技術広報チームは、年間目標を起点に社外向けの情報発信戦略と方針を策定。 そこから逆算して、各施策・企画の狙いやテーマ、実施スケジュールを設計し、必要なリソースを開発・デザイン組織と調整。企画の2〜3か月前から準備を始め、登壇内容や連携を進めていきます。 この活動は、「顧客志向のSaaS開発組織」としてのブランドを確立し、候補者の惹きつけや信頼形成、ミスマッチの低減につなげる役割を担っています。 ２、開発組織による自主的な情報発信（＝文化づくりと学び） 一方で、開発組織のメンバー自身が主体となって自由に行う情報発信も盛んです。 こちらは「育成」や「学習」といった目的を含みつつ、より自由度の高い形で行われるのが特徴です。 「もっと自分たちの言葉で組織を紹介したい」 「日々の挑戦や工夫をアウトプットしたい」 「学んだことを共有しながら自分も成長したい」 そんな思いから生まれる発信は、自律的な行動の一環として定着しつつあります。 このような活動は、組織の透明性や学習文化を育てるとともに、個人の成長やモチベーションにもつながっています。 具体的な情報発信活動事例 ここからは、具体的な情報発信事例を紹介します。 エンジニアブログ 日々の業務を通じて得た独自の技術的知見や開発組織のカルチャー、開発プロセス、利用技術などを広く社外に発信することを目的としています。 代表的な記事 tech-blog.rakus.co.jp tech-blog.rakus.co.jp 主催イベント イベントは「顧客志向のSaaS開発組織」としての価値観を社外に伝える重要な場です。登壇者自身が現場の第一線で取り組んできた実践をもとに、リアルな知見やカルチャーを共有しています。 RAKUSTechConference 年に一度開催するラクス最大の技術イベント。エンジニア・デザイナーが現場で得た知見を共有し、開発文化・プロセス・利用技術を広く社外に伝えています。 techcon.rakus.co.jp MeetUp 年に2〜4回開催される職種／技術テーマ別の深掘り型イベント。 開催例 rakus.connpass.com 共催イベント SaaS各社様（Sansan、サイボウズ、マネーフォワード、フリー、LayerX、ログラス）を中心に、 エン・ジャパン様、日本経済新聞社様、BuySell Technologies様、ビジョナル様など、多数の企業様と以下のようなイベントを共催いたしました。 rakus.connpass.com rakus.connpass.com loglass-tech.connpass.com freee.connpass.com layerx.connpass.com rakus.connpass.com TechCafe 各組織が自主開催する技術勉強会・交流イベント。 各組織のブランディング強化と、自己研鑽や学習機会を提供し、広く社外にラクス開発組織を知ってもらうことを目的としております。 PdM、デザイナー、モバイル、フロントエンドなどの特定テーマに沿って気軽に語り合うスタイルです。 開催例 rakus.connpass.com rakus.connpass.com カンファレンス登壇 技術課題に対する姿勢、取組をエンジニア自身の視点で社外に伝えることでブランディング強化のほか、スキルアップ、日々のモチベーションアップにもつながっています。特に大阪ではPHPベースのプロダクトが多く、PHP関連のカンファレンス（PHPConference、PHPerKaigiなど）への登壇実績が豊富です。 登壇実績 career-recruit.rakus.co.jp 次回は、年1回開催のRakusTechConference2025 次回のTechConは、2025年8月7日開催です。 今回は、「ラクスのプロダクト開発の強み」の全貌として、 製品へのAI実装事例、AIを活用した開発プロセス改善、AI時代における組織のあり方、取り組み、展望を余すことなく語るイベントです。 techcon.rakus.co.jp AI時代においても、顧客志向にどう向き合うか。 そんな問いに、エンジニアリングマネージャーや現場メンバーたちの生の声でお応えします。 是非ご視聴ください！

自己紹介 こんにちは、 稲垣 です。ラクスの開発組織のプロダクト部 製品管理課の組織のマネージャーをしています。 　└ プロダクト部の紹介は コチラ / 製品管理課の紹介は コチラ / 私自身の経歴は コチラ こんな方におすすめ ・自身の提案が上司や必要な人に届いてないと感じてる方 ・AI時代でも廃れない価値を獲得したい方 ・プロダクトマネージャーとして人としての巻き込み力をあげたい方 目次 はじめに AI時代の「言っていること」は差別化できない PdMの武器は「信頼」 どうしたら「信頼」を得ることができるのか？ 「信頼」があるとどうなるか？ 最後に はじめに 若い頃こう思ってました　 　『自分が言っていること』と『上司が言っていること』と内容はほぼ同じなのに何故？ 自分の意見は採用されず上司が言っていたことが採用されるのか。 自分が一定の立場になったら「誰が」ではなく「何を」言っているかで提案等を採用しよう。 自分が提案する立場となった今、今はどうしているか？そんなことを思ったので、ブログにしました。 AI時代の「言っていること」は差別化できない 情報の精度、論理性、構成力、言語化力──これらはAIが一瞬で整えてくれる時代だなと感じています。 ただ、AIに指示するプロンプトや人によって得られる結果の質は変わります。一方で「正しいこと」を導き出すことが簡単になりました。だからこそ、 「何を言っているか」だけでは差別化がされにくくなった ように思います。 似たような主張が並ぶ会議 AIが書いたと思われる定例レポート 誰が言ったのかわからない実現可能性の考慮が弱い施策の提案 こうした場面で差を生むのは、 その言葉に“人”が宿っているか だと思います。 PdMの武器は「信頼」 PdMの役割は、インタビュー等の一次情報や社内の営業・CSからの情報をもとにPRD（製品要求仕様）をまとめることだけでなく、 チームを巻き込み、実行へ導くこと で、その実行力の源泉は「信用」にあると思っています。 ✅ 信用（しんよう） 意味 過去の実績や客観的な情報に基づいて「この人は大丈夫だろう」と判断すること。 信用は、 外部的・論理的な根拠 に基づいて成り立ちます。 特徴 契約や取引など、 ビジネスシーンでよく使われる 。 数値や履歴（例：返済実績、業績、資格など）で評価されやすい。 「信用スコア」「信用調査」など、定量的な概念として扱われる。 ✅ 信頼（しんらい） 意味 相手の人間性や未来の行動に対して「きっと裏切らない」と期待すること。 信頼は、 主観的・感情的なつながり に基づくことが多いです。 特徴 人間関係において重視される 。 経験を通して築かれ、裏切られると大きく損なわれる。 「信頼関係」「信頼を築く」など、人と人とのつながりを示す文脈でよく使われる。 上記のChatGPTに聞いた「信用」と「信頼」の違いです。 信用は「点」、信頼は「線」や「面」だと思っています。 AIがいくら説得力のある戦略や戦術を出してくれても── 「その人が言うなら信じてやってみよう」という関係性がなければチームは動きません。 つまり、PdMにとっての“最強のツール”は生成AIではなく 「信頼」 だと思います。 どうしたら「信頼」を得ることができるのか？ まず「信用」を得る必要がありますが、その方法です。 信用は 「見える行動」で判断 されるため、まずは 小さな成果を着実に積み重ねる ことが大切です。 1. 約束を守る 納期、時間、返答など、小さな約束を確実に果たす 「言ったことはやる」を積み重ねる 2. 一貫した行動 誰に対しても、どんな状況でも態度や判断がブレない 行動に「安定感」があると評価されやすい 3. 結果を出す 客観的な成果、数字、品質など、外から見える形での実績 失敗しても誠実なフォローがあれば信用は保てる 4. 透明性と誠実さ 都合の悪いことも隠さず報告する ごまかさず、丁寧に説明できる姿勢が評価される そして、これらを「信頼」に変える方法です。 信頼は 「見えない感情的つながり」 であり、 深い人間関係の中で自然と育つもの です。 1. 共感と理解 相手の立場・気持ちを理解しようとする 単なる理屈より「この人は分かってくれている」と感じてもらうことが大切 2. 弱さを見せられる関係性 完璧な姿よりも、「困っている時に助けてくれた」などの経験の方が信頼を育む 自分も相手も「頼り頼られる関係」を目指す 3. 裏切らない姿勢 利害に関係なく、誠実である 信頼は一度失うと回復が難しいため、 誤魔化しや裏切り は致命的 4. 時間をかける 信頼は 時間と経験の共有 から生まれる 話す機会や一緒に何かを乗り越える経験が重要 信頼はAIに代替されない「設計資産」 だと思っています。 ※「設計資産」とは「再利用可能な設計に関する情報や成果物」 信用を積み上げることで信頼を獲得して、それを人間関係まで昇華させることはAIにはできません。 「信頼」があるとどうなるか？ AIが生成したコンテンツは完成度が高いように見えますが、プロダクト開発は「仮説と実験の連続」です。 PdMは、確信のないアイデアを語らなければなりません。不確実性を含んだ提案を、仲間に届けなければなりません。 まだ答えが出ていない 実験段階だけど、見解を持っている 方向性はあるが、議論したい こういった話でも── 信頼されているPdMが言えば「よし、やろう」 信頼されていないPdMが言えば「なぜ？」「今やる意味ある？」となる この差は、ロジックでは埋まりません。信頼があるからこそ、意思決定がスムーズになり、実行力が加速します。 最後に AIは“何を言っているか”を補完し、人は“誰かであること”を磨く」 AI時代における言語化・発信・言葉の価値は、 「内容の質」 から 「発信者の信頼」 へとシフトしています。 これは逆説的に、 あなたの言葉が、あなた自身の信用を映す鏡になる時代 とも言えます。 単なるアウトプットではなく、 「誰が言っているか」を磨くプロセスそのもの 。 だからこそ、PdMやビジネスパーソンは 「正しいことを言う人」 ではなく 「信じて動きたくなる人」 になることが最も強い武器になると思います。 声をかければチームが動く、議論を投げれば前に進む。 そんな「誰が」になるには、普段のふるまいと、信頼を育てる仕組みから見直してみるのが良いかもしれません。

複雑な要件をまとめ、曖昧な仕様を詰め、品質と納期を両立させてプロジェクトをやり切る─。 SIerやSESでの仕事は、常に高い要求と責任の中で鍛えられる挑戦の連続です。 そんな日々の中でも、 「もっと顧客に貢献している実感が欲しい」 「自分たちの手でプロダクトを育てたい」 と感じたことはありませんか？ ラクス大阪開発組織では、まさにそんな思いを胸に、SIer/SESから新しいキャリアを選んだエンジニアが数多く活躍しています。 ラクスの大阪開発組織は、複数の主力プロダクトを担当しながら、 「顧客志向のSaaS開発組織」 としてさらに発展を続けています。 今回はそこに所属する人々の概要のほか、エンジニアたちが 自社プロダクト開発でどのように顧客と向き合い、キャリアを築いているのか をご紹介します。 また先日の記事では、組織の価値観や組織文化、組織としての価値づくりの取り組みについて ご紹介しておりますので、是非ご覧ください。 tech-blog.rakus.co.jp 数字で見る大阪開発組織の「人」 エンジニア数 新卒/中途 中途入社者の出身業態 大阪のエンジニアたちに聞く！キャリアの希望・展望 Mさん （エンジニアリングマネージャー）「新規プロダクトのPMFを目指す」 Tさん　（上流設計担当 → PdM）：「顧客の成長と自分の成長が重なる」 Oさん（開発エンジニア）：「自分のプロダクトがどう使われているか、実感できるように」 Iさん（開発エンジニア）：「顧客要望の背景まで問える環境」 「顧客志向のSaaS開発組織」で、 思いを次のステージへ 数字で見る大阪開発組織の「人」 エンジニア数 サーバサイドエンジニア、インフラ、管理職を合わせて90名弱の組織です。（2025年7月現在） 新卒/中途 中途入社者が約63%、新卒が約37%です。（2025年7月現在） 中途入社者の出身業態 SIer/SES出身者が約65%、事業会社出身が約35％です。（2025年7月現在） このように大阪開発組織は、 SIer/SESでの仕事を経験した中途採用エンジニアが多く活躍 しています。 では、エンジニアたちはなぜラクスを選び、どのような変化を感じ、どのような思いで働いているのでしょうか。 実際に活躍するEM、PdM、開発エンジニアに聞いてみました。 大阪のエンジニアたちに聞く！キャリアの希望・展望 ラクスへ転職してきたエンジニアたちは、それぞれが独自のキャリアを歩み、自社プロダクト開発への情熱を持って活躍しています。ここでは、具体的な声をご紹介します。 Mさん （エンジニアリングマネージャー）「新規プロダクトのPMFを目指す」 SES企業でのPG業務を経て、 製薬企業向けシステムを提供する独立系SIerのPM としてプロジェクトを統括。 転職理由は？ 応募理由は？ 入社の決め手は？ 前職ではプロジェクトを成功に導き、後進の育成や今後の道筋を整えられたことで大きな達成感を得ると同時に、 「次は新しい環境でさらに成長したい」 と考えるようになりました。 特に、 これから組織がスケールしていく企業 で、これまでの経験を活かしながら貢献できるチャンスを求めていました。 ラクスは自分の目指す方向性や価値観に最も合っていると感じました。 新規プロダクトの担当となり、重要な業務を任されているという実感 があり、大きなやりがいを感じました。 前職から変わったと感じることは？ フルスクラッチ開発やカスタマイズで個別顧客の要望に応えていくスタイルから、 多くのお客様に受け入れられる「最大公約数」の機能開発に集中するスタイル になったことです。 今後取り組みたいことは？ 今後の目標は、担当プロダクトである楽楽請求においてプロダクトマーケットフィット（PMF）を達成し、顧客にとって本当に価値のあるサービスを提供することです。その実現に向けて、 チーム全体で顧客志向・顧客視点を徹底し、ユーザーのニーズを深く理解した上で開発を進めていきたい と考えています。 特に、開発メンバーが「顧客目線」を持ち、機能や新規システムを自ら提案できるような状態をつくりたいと考えており、各チームの主体的な意見が反映される環境づくりに取り組みます。 メンバーと「ものづくり」へのこだわりを共有し、高品質で価値あるプロダクトをつくる喜びを実感できる組織にしていきます。 Tさん　（上流設計担当 → PdM）：「顧客の成長と自分の成長が重なる」 中規模SIerでスマホアプリ受託開発やPM/PL業務を経験し、その後 外資系SIerでPM として製造システム開発に携わってきた。 転職理由は？ 応募理由は？ 入社の決め手は？ 当時はSES契約での業務がメインで、自社プロダクト開発に憧れがありました。 直接顧客と向き合って、ビジネスを成長させたい という思いが強くなったためです。 当時からラクスは 幅広い種類のプロダクトで新規リリース を続けており、安心感がありました。 働く人たちの 空気感が良かった のも決め手です。SaaS業界で働くことを考えた後は、ラクス一本に絞っていました。 前職から変わったと感じることは？ 顧客と距離が近く、 自分の仕事がビジネス拡大に直結する実感 があります。 SaaSは固定顧客がいないため、より広い視野で顧客要望の背景を深掘りするようになりました。発案した改善提案も取り入れられる機会が多いですね。 今後取り組みたいことは？ 担当プロダクトの楽楽請求は、請求書受領領域ではまだまだこれからのプロダクトです。 業界トップを目指していきたい ですね。 現在PdMは私一人の体制ですが、今後はチームを拡大してマネジメントにも挑戦したいです。 Oさん（開発エンジニア）：「自分のプロダクトがどう使われているか、実感できるように」 大学卒業後、前職のSIerで 物流システム開発のチームリーダー 等を経験したのち、ラクスに転職。 転職理由は？ 応募理由は？ 入社の決め手は？ 前職では、開発した製品に対する顧客からのフィードバックが少なく、 より顧客に貢献できる実感が欲しい と思っていました。 スカウトを通じて知りました。自社プロダクトかつ、技術的に尖りすぎていない安心感もありました。 面接を通じて、自分の意見も言いやすい雰囲気であることに好感を持ち、入社を決めました。 前職から変わったと感じることは？ 顧客や製品が実際にどう使われているかを知る機会 がとても増えました。 問い合わせ対応やビジネスサイドからの製品へのフィードバック、勉強会を通じて顧客理解を深めています。それをもとに 自分自身で判断し、改善点を見つけて自分で働きかける場面も増えた と思います。 今後取り組みたいことは？ より顧客理解を高めて、上流工程やPdMも経験していきたいです。 Iさん（開発エンジニア）：「顧客要望の背景まで問える環境」 前職では複数の 受託開発プロジェクトを数年間経験。リードエンジニアを務めてきた。 転職理由は？ 応募理由は？ 入社の決め手は？ サービスを作るからには、顧客に便利だと思われるものを作りたいという思いからです。言われたものを作って終わりではなく、運用も重視しエンドユーザーの声を大事にする企業に転職したいと考えていました。 CMなどを通じて、プロダクトについては知っていました。エージェントから声をかけてもらい、大阪の自社プロダクト開発企業として、興味を持ちました。 顧客の業務を楽にするプロダクトづくりができることに加え、自分自身も未知の経験を積めそうだった ことです。 前職から変わったと感じることは？ 要件定義や技術選定に関わるようになったため、 どういう機能を、なぜ作るのか、顧客要望の背景まで問う機会が増えました 。 私は運用歴の長いプロダクトを担当していますが、技術負債対策から製品へのAI導入まで、エンジニアとしても幅広い挑戦ができると感じています。 今後取り組みたいことは？ 前職はAIを使っていませんでしたが、最近は技術調査にも取り組んでいます。顧客がもっと便利に使える機能を開発するため、AI分野は使いこなしていきたいですね。 「顧客志向のSaaS開発組織」で、 思いを次のステージへ ご紹介してきたとおり、当社に転職する人は共通して以下のような思いを抱いていました。 顧客にもっと近い開発がしたい 多くのユーザーに価値を届けたい 自分の判断や提案が活きる仕事がしたい また、転職後はこのような変化を感じているようです。 顧客視点で開発の“目的や背景”を問うようになった ユーザーの反応を肌で感じながら開発できるようになった 役割の幅が広がり、大きなやりがいを感じるようになった ラクス大阪開発組織の現場は、顧客の課題と対話しながら、手を動かし、仲間とワイワイ議論し、より良い価値をつくることを大事にしています。 そしてSIer/SESで培った経験は、SaaS開発でも強みとなります。 要件を詰める力、納期を守る力、チームでやり切る力──すべてが顧客のために活きてくる はずです。 もし今回ご紹介したエンジニアたちの声に少しでも共感いただけたなら、 ぜひ一度、大阪の現場のリアルな声を聞きにきてください。 そしてラクスの仲間と一緒に、顧客の課題解決を目指すプロダクトづくりに挑戦しませんか？

こんにちは。ラクスの大阪開発組織で統括責任者をしております、矢成です。 私たちラクスは、 「ITサービスで企業の成長を継続的に支援します」 というミッションのもと、BtoB SaaSを通じてお客様の業務課題を解決しています。 開発本部でも 「顧客をカスタマーサクセスに導く圧倒的に使いやすいSaaSを創り提供する」 というミッションを掲げ、「顧客志向」を徹底したプロダクトづくりに取り組んできました。 この開発組織の原点は、実は大阪にあります。 ラクスは大阪で創業し、最初のプロダクト開発も大阪からスタートしました。 現在においても、大阪開発組織は複数の主力サービスを担当しながら、 創業時から大切にしてきた「顧客志向」の文化 を今なお受け継ぎ、さらに発展させ続けています。 こうした背景から、 大阪には単なる「開発拠点」という枠に収まらない、ラクスのカルチャーや開発スタンスの原点が存在 しています。 　 そしてもう一つ、私たちが大切にしているのが、人と人とのコミュニケーションです。 私たち大阪開発組織は70名規模の組織に成長しましたが、ともすればチームの中に閉じてしまいがちな日々のやりとりを細らせず、「隣のチームが何に悩み、どう臨もうとしているか」に自然と目が向くような関係性を持ち続けたいと考えています。 　 プロダクトをつくるのは、チーム。そしてチームをつくるのは、人と人の間にある信頼です。 技術だけでなく、チームワークや対話にも本気で向き合う、良きチームであり続けること。 それが、大阪の開発文化のもう一つの根っこになっています。 　 　 「プロダクトを通じて顧客に価値を届けるとはどういうことか」 「価値を届けるために必要なコミュニケーションや人と人との関係性とは」 　 そうした問いに向き合い、行動に移す文化が、組織の土壌として根付いているのです。 本記事では、そんな大阪開発組織の価値づくりの全体像をご紹介します。 プロダクトや技術領域はもちろん、働くメンバの姿勢や文化づくりの取り組み、そして組織を横断した関係構築など、「大阪開発組織の価値づくり」がどのように行われているのかを、具体的な事例を交えながらお伝えしていきます。 大阪開発組織の概要 組織としての価値をつくる取り組み 外部情報発信 文化醸成 顧客志向ワークショップ CS・営業・開発の情報交換会 テーマ別情報共有会 大阪AI会 組織活性化 ビアバッシュ 部門間交流会 大阪で開発しているプロダクト紹介 楽楽販売 （クラウド型販売管理システム） 楽楽請求 （クラウド型請求書受領システム） メールディーラー（メール共有管理システム） 配配メール（メルマガ配信・一斉メール配信サービス） おわりに 大阪開発組織の概要 　 ラクスの開発組織は東京・大阪に分かれており、 大阪拠点には複数のプロダクト別開発チームとインフラ部門が所属 しています。 主な担当プロダクトは 楽楽販売、楽楽請求、メールディーラー、配配メール の4つ。 　 プロダクト別に開発部・課に分かれており、各課にはエンジニアリングマネージャ、プロジェクトマネージャ、プロダクトマネージャ、バックエンドエンジニアなど、さまざまな職種のメンバが集まっています。 各課の人数は10～20名程度です。（チームの体制・製品フェーズにより差があります）ベトナム拠点と連携して開発しているチームでは、ブリッジエンジニアが在籍しています。 フロントエンドエンジニア、プロダクトデザイナなどの専門領域は、東京拠点の開発組織と協働しています。その他、広報やR&D、SREなど、東京側の部門横断組織と連携することも少なくありません。 組織としての価値をつくる取り組み 　 以下では、大阪のエンジニアが行っている取り組みをご紹介します。 外部情報発信 当社の技術課題に対する姿勢、取組をエンジニア自身の視点で社外に伝える ため、外部イベント登壇や、当ブログでの発信を積極的に行っています。 こうした発信の場は、エンジニア自身のスキルアップはもちろん、日々のモチベーションアップにもつながっています。特に大阪では、PHPベースのプロダクトが多いこともあり、PHP関連のカンファレンス（PHPConference、PHPerKaigiなど）への登壇実績も豊富です。 【昨年の登壇レポート】 tech-blog.rakus.co.jp tech-blog.rakus.co.jp 文化醸成 顧客志向ワークショップ 「顧客志向」という重要な価値観を組織に根付かせる ためには、ディスカッションによる理解の深耕が役立ちます。 プロダクト開発に関わるすべてのエンジニア（東京側の専門組織メンバも含みます）が一堂に会し、顧客像や顧客課題、「顧客志向」の意味について意見を交わします。 これは頻繁に取り組むものではありませんが、顧客やプロダクトの強みを改めて捉え直し、解像度を高めていく機会にもなっています。 CS・営業・開発の情報交換会 CS・営業など、プロダクトに関わる他職種メンバと顔を突き合わせ、顧客の声や製品評価・課題について意見交換します。 エンジニアだけでは知ることの難しい、顧客や製品の「実際」がよりリアルに感じられ、顧客理解が深まります。 また、チャットやメールなど、文字ベースのコミュニケーションでは得られないフランクなやり取りもとても貴重なものです。職種間の信頼関係を育み、継続的に取り組んでいこうという機運につながっています。 詳細はこちらもご覧ください tech-blog.rakus.co.jp テーマ別情報共有会 プロダクトごとの開発チームの枠を超えたナレッジ共有 のため、エンジニア主導で定期的な情報共有会を実施しています。 PHP、Java、上流設計、運用保守など、テーマごとに知見のあるメンバを中心とした分科会的な場を設け、成功事例だけでなく「うまくいかなかった話」も含めて、率直な意見交換を行っています。 チーム横断のこうした学びの継続が、組織全体の技術力と対応力の底上げにつながっています。 大阪AI会 こちらもプロダクトの枠を超えた成功・失敗事例、取組の共有の場ですが、特に最近は AI技術の推進にフォーカスした情報交換の場 として注目を集めています。 Devin、Cursor、GitHub CopilotなどのAIツールの活用・検証に関する情報交換が活発に行われ、各チームでの取り組み → 得られた知見の共有 → 他チームへの還元、というサイクルが、日々進化するAI技術へのキャッチアップ手段として機能しています。そしてもちろん、共有内容は大阪に限定せず、開発組織全体にも展開しています。 組織活性化 ビアバッシュ 業務での取り組み事例やお悩み相談、最近気になっている技術トピック、個人開発のアプリ紹介など、ビール片手に気軽に雑談・相談できるLT＆交流の場です。 ただの交流会にとどまらず、学びの機会 としても好評で、毎月の恒例行事としてすっかり定着しています。 部門間交流会 「エンジニア歴○○年」「○○○に関わりのある人たち」などの共通の切り口をもとに、 チームの枠を越えたコミュニケーションの場 を継続的に設けています。 必ずしも業務で直接つながっていないメンバ同士が交流するきっかけにもなっており、ここで生まれた関係性がきっかけとなり、開発プロジェクトの課題解決につながったケースもあります。 大阪で開発しているプロダクト紹介 　 楽楽販売 （クラウド型販売管理システム） 販売管理・案件管理をはじめとした、あらゆる社内業務をシステム化することができるWebデータベースシステムです。ノーコードでのカスタマイズ機能により、使いながら最善のシステムに改善していけるほか、帳票発行・資料送付といったルーチンワークを自動化することで、業務効率化・コスト削減を実現します。 www.rakurakuhanbai.jp youtu.be 楽楽請求 （クラウド型請求書受領システム） 紙・メール・PDFなどさまざまな形式で届く請求書を、正確に、スピーディーに、安価にデータ化し、一元管理を実現することができます。経理業務で発生する手入力の煩雑さや、ミスの不安から顧客を解放するシステムです。 www.rakurakuseikyu.jp メールディーラー（メール共有管理システム） 顧客からの問合せメールを共有・一元管理し、メール対応業務を効率化するツールです。2001年4月リリースの、ラクスで最も歴史のあるプロダクトで、累計8,000社以上にご利用いただいており16年連続売上シェアNo1となっています。 www.maildealer.jp youtu.be 配配メール（メルマガ配信・一斉メール配信サービス） 中小企業のマーケティング担当者に選ばれる「配配メール」は、成熟したメール配信市場にありながら、リードの創出から商談獲得まで顧客業務の幅広い課題を解決することで、新たな価値を生み出し、高い売上成長を達成しているクラウド型メール配信サービスです。 www.hai2mail.jp おわりに ラクスの大阪開発組織では、 プロダクトだけでなく、組織や文化そのものも“顧客志向” で育て続けています。 仕様どおりに作るだけではなく、 顧客の課題と対話しながら、手を動かし、仲間とワイワイ議論し、より良い価値をつくる。 それが私たちが目指すエンジニアリングです。 そしてチームの中での対話、職種や組織の枠を越えたやり取り──そんな関係性の中にこそ、より良いプロダクトの種があると私たちは信じています。 技術の選択も、設計の見直しも、文化のあり方も。すべての判断の中心には「これは本当にお客様の役に立つのか？」という問いがあり、対話しながらその答えを見つけていきます。 もしあなたが、 「プロダクトと向き合う開発がしたい」 「本当に価値あるプロダクトを届けたい」 「人と人との関係性を大事にしながら開発したい」 そう思ったことがあるなら、ぜひ一度、大阪の現場のリアルな話を聞きに来てください。 “理念・理想”から“実践・行動”へ。対話を重ね、顧客志向を日々かたちにしているチームの一端に、触れられるかもしれません。

こんにちは、デザインマネージャーの青柳です。 あらゆるプロダクトにとって、最良のUXを目指すことは必然だと思います。 私たちもまた、お客様により快適な体験を提供するため、継続的なUX改善に取り組んでいます。 今回ご紹介するのは 勤怠管理システム「楽楽勤怠」のUI/UX改善プロジェクト 。 シリーズを一貫する体験設計と、顧客満足につながる独自性の両立を目指して、プロダクトの体験を一歩進める取り組みに挑みました。 今回はプロジェクトの背景・工夫・成果だけでなく、デザイン組織が実現したい未来像や、そこに挑むデザイナーたちの姿についてもお話しできればと思います。 目指すのは「一貫した体験の提供」と「使いやすさの向上」 視認性と導線改善を支える標準UIの力 限られたスペースに最適な導線を 実際に対応したデザイナーたちからのコメント 「顧客のために」その一言で、私は腹をくくった（デザイナー Aさん） 統一性 vs 独自性──標準UIコンポーネントに宿す、“プロダクトらしさ”のさじ加減（デザイナー Bさん） 「使うのが楽しみになる」プロダクトへ──伸びしろだらけの組織でつくる、UXの未来 目指すのは「一貫した体験の提供」と「使いやすさの向上」 私たちは現在、バックオフィス向けプロダクトである「楽楽シリーズ」（楽楽精算、楽楽明細、楽楽販売、楽楽勤怠、楽楽電子保存、楽楽請求）のUI刷新に取り組んでいます。 バックオフィス業務は複雑で、多くの法令が関係します。そこで、ユーザに対応いただく操作も煩雑になりやすい側面があります。 ユーザに業務をスムーズに進めていただくためには、機能の充実はもちろん、直感的で迷わない操作性が欠かせません。 この目的や方針の詳細は、以下のブログも参照ください。 tech-blog.rakus.co.jp UI刷新には、二つの目的があります。 UI統一による一貫した体験の提供 UIの見直しによる使いやすさの向上 まずは、それぞれの目的についてご説明します。 UI統一による一貫した体験の提供 ラクスのプロダクトは 顧客の業務ドメインにあわせ、深く課題解決に踏み込むベスト・オブ・ブリード型の開発 を行っており、各プロダクトのUIも、各業務ドメインごとに個別性が高いものとなっていました。 Before 今後はお客様が複数のSaaSを利用することも想定し、どのプロダクトを利用しても共通体験を提供できるようにします。 具体的には、同じ機能を持つボタンの形状や位置、コンポーネントの使い方、余白の取り方などをシリーズ間で統一します。ユーザーが 各プロダクト間で感じる「メンタルモデル」の差をなくす ことで、お客様は詳細な説明や長期のオンボーディングの負担なく複数のプロダクトを利用できるようになると考えています。 After UIの見直しによる使いやすさの向上 長い歴史を持つラクスのプロダクトの中には、当時の体験設計が古くなり、UI/UXに課題を抱えるものも少なくありません。 今回UI刷新を行った「楽楽勤怠」についても、レガシーなUI設計を踏襲しており、新機能も既存のUIを延長して実装されている状況でした。 この背景には、お客様の業務課題を確実に解決するために、機能を優先して充実させる戦略をとってきたことが背景にあります。今回のUI統一を機に、残っている古いデザインを進化させることを目指しています。 新しいUIコンポーネントは、 視認性や可読性、アクセシビリティにも配慮し、どのユーザーにとっても直感的な操作ができるよう設計 されています。 視認性と導線改善を支える標準UIの力 今回の「楽楽勤怠」UI/UX改善プロジェクトは、まず第一歩としてログイン画面、ヘッダー、トップページの改修を行いました。主な狙いは以下の通りです。 視認性の向上 直感的な操作性の確保 必要なコンテンツへのアクセス改善 ここで、改修後の変化をご紹介します。 ログイン画面：視認性向上と標準UIコンポーネント適用 （左：Before、右：After） ヘッダー：利用頻度の高いメニューを厳選しデフォルト表示 Before After トップページ：視認性向上と標準UIコンポーネント適用 （左：Before、右：After） この改修はリリースされたばかりですが、 視認性や業務で頻繁に使うメニューへのアクセスが高まり、使い勝手向上への期待感 を持っていただけるような改善を実現できたと考えています。 また「楽楽シリーズ」のプロダクト共通のデザインシステムをベースとして適用したことも、デザイン面の大きな成果です。 今後は、 各プロダクトが持つUXやコンポーネントに関する知識を共有しやすくなった ため、プロダクトデザイナー同士が密に連携しながら、全シリーズのUXをより一層高めていく一歩となりました。 限られたスペースに最適な導線を 顧客に最も使われるメニューを企画・検討 メニュー構成の変更は、現在利用いただいているお客様への影響が非常に大きい改修です。 そこで、どの機能をメニューに掲載すべきかの判断にあたっては、 日々幅広い顧客をサポートしており最適化された視点を持っているCSチーム と、 顧客課題への解像度の高いPdMへの確認・協議 を行いました。 従業員側が使うメニューは比較的少ない一方で、管理者側のメニューは非常に多岐にわたります。CSは、管理者側の複雑な設定メニューに関する顧客からの問い合わせが多く、知見が集約されています。そのフィードバックをもとに整理を進めました。 メニュー実現のため、デザインシステムを拡張 これまでの「楽楽勤怠」では、サイドメニューやハンバーガーメニューの中に多くの項目が並び、スクロールすることでアクセスできていました。 しかし、今回のUI刷新では、ヘッダーにメニューを厳選して配置する必要があります。 限られたヘッダー領域に効率的に収めるため、類似する機能をカテゴリとしてまとめ、デザインシステムを拡張して新しいコンポーネントを開発しました。 実際に対応したデザイナーたちからのコメント 実際に取り組んだデザイナーたちに、改修の実現に向けて挑戦したポイントや、成長できたポイントを聞いてみました。 「顧客のために」その一言で、私は腹をくくった（デザイナー Aさん） 「これまで自身の担当プロダクトである「楽楽勤怠」の開発に閉じていた視座が、UI刷新を通じて大きく高まりました。 『顧客のためになるか？』『なぜそのデザインにするのか？』 他プロダクトのデザイナー、プロダクトマネージャー（PDM）、CS、事業部など多様なステークホルダーとの連携を通じて、判断する影響範囲が広がり、情報収集量も増えました。これにより、デザイナーとしての視座が大きく高まったと感じています。」 また、ステークホルダーが増えると、誰が主体的にボールを持つのか？という状況が発生します。ここでデザイナーとして自ら判断し、対応し、交渉するのは大きな挑戦でした。最初はPdMからの質問に対して回答が難しいこともありましたが、その後、 自ら腹をくくって判断し、対応・交渉するよう動けるようになりました。 」 統一性 vs 独自性──標準UIコンポーネントに宿す、“プロダクトらしさ”のさじ加減（デザイナー Bさん） 「入社して間もなくプロジェクトに関わり、『右も左も分からない状態』でのスタートでした。 UI/UX改善プロジェクトを通じて、デザイナーの視点とフロントエンドエンジニアの視点の違いを理解しデザインに取り組めたことが成長につながりました。 特に標準UIコンポーネントを使いつつも、 勤怠独自の調整をしたい というデザイン面の要望と、 実装面での統一性 も重視する開発側の視点の間で、細かな調整を行う難しさと学びがありました。 今後はデザインシステムにも積極的にかかわり、ルールの作成やコンポーネント設計にも貢献していきたいです。 」 「使うのが楽しみになる」プロダクトへ──伸びしろだらけの組織でつくる、UXの未来 今回の楽楽勤怠のUI/UX改修事例を通じて、ラクスの継続的なUX改善への取り組みをご紹介しました。 今後もお客様にとって本当に使いやすいプロダクトを追求し、継続的にアップデートを重ねることで、 「業務を効率化するだけでなく、使うのが楽しみになる」 存在へと育っていくことを目指しています。 ラクスのデザイン組織は、まだまだ成長途上で、整っていない部分も多くあります。 しかし、それは逆に、 デザイナーが自身の力を発揮し、やりがいのある仕事や成長を目指せる環境を一緒に作り上げていくことができる魅力 でもあります。 新しいことにも積極的にチャレンジできる環境が整っており、実際にUXリサーチやデザインをやる機会も作っていくことができています。ラクスで、顧客志向のプロダクトデザインを共に推進し、ユーザー体験の未来を創造していきませんか？

こんにちは、配配メール開発チームの id:takaram です。 毎年11月ごろに新しいメジャーバージョンがリリースされるPHPですが、今年2025年11月（予定）にリリースのPHP 8.5に新機能「 パイプ演算子 」が導入されることが決まりました🎉 リリースはまだ先ですが、8.5の目玉となるであろうこの機能を一足早く紹介していきます！ ⚠️この記事の内容は、2025年6月現在開発中の仕様に基づいています。PHP 8.5リリースまでに変更になる可能性がありますのでご了承ください。 パイプ演算子の基本 パイプ演算子の活用法を考えてみる 高階関数を利用した活用例 今後の展望（Future scope） まとめ パイプ演算子の基本 新しい演算子 |> が導入されます。左辺の値を引数として右辺のcallableを実行します。 <?php // この2行は同じ意味 $ result = "Hello World" |> strlen ( ... ) ; $ result = strlen ( "Hello World" ) ; 右辺は引数1つの callable であれば何でもOKです。 関数名 "strtoupper" 第一級 callable strtoupper(...) 無名関数 fn($x) => ... オブジェクトとメソッド名の配列 [$obj, 'method'] __invoke メソッドを持つクラスのインスタンス など 2つ以上の引数が必要な関数は、無名関数でラップして呼び出します。 <?php // NG: str_replace は引数 3 つ 'foo' |> str_replace ( 'o' , 'a' , ... ) ; // Error // OK: 無名関数でラップ 'foo' |> fn ( $ s ) => str_replace ( 'o' , 'a' , $ s ) ; その他細かい仕様については、RFCを参照してください。 wiki.php.net 日本語訳 qiita.com 未リリースの機能ですが、今すぐ試したい場合は 3v4l.org で実行バージョン git.master を選択すると実行することができます。 実行例： https://3v4l.org/NeE79/rfc#vgit.master パイプ演算子の活用法を考えてみる ここまでパイプ演算子の機能を紹介しましたが、では実際我々がコーディングを行うにあたって、どのように活用できそうでしょうか？ 高階関数を利用した活用例 パイプを生かすために、まず高階関数を4つ作ります。 これらは全て「関数 (callable) を受け取って関数を返す」関数になっています。 <?php /** * `$pred`が`true`を返す要素だけを抽出 */ function filter ( callable $ pred ) : Closure { return function ( iterable $ it ) use ( $ pred ) : Generator { foreach ( $ it as $ k => $ v ) { if ( $ pred ( $ v , $ k )) yield $ k => $ v ; } } ; } /** * `$f`を各要素に適用した結果を返す */ function map ( callable $ f ) : Closure { return function ( iterable $ it ) use ( $ f ) : Generator { foreach ( $ it as $ k => $ v ) { yield $ k => $ f ( $ v , $ k ) ; } } ; } /** * 副作用を実行し、値はそのまま次へ */ function tap ( callable $ side ) : Closure { return function ( iterable $ it ) use ( $ side ) : Generator { foreach ( $ it as $ k => $ v ) { $ side ( $ v , $ k ) ; yield $ k => $ v ; } } ; } /** * `$f`を使って要素を累積的に処理し、最終結果を返す */ function reduce ( callable $ f , mixed $ initial = null ) : Closure { return function ( iterable $ it ) use ( $ f , $ initial ) { $ acc = $ initial ; foreach ( $ it as $ v ) { $ acc = $ f ( $ acc , $ v ) ; } return $ acc ; } ; } 上記の関数を使って、「請求済み注文の平均金額を出しつつ高額注文を拾う」というのを実装してみます。 <?php // ダミーデータ $ orders = [ [ 'id' => 101 , 'status' => 'paid' , 'total' => 1200 ] , [ 'id' => 102 , 'status' => 'cancelled' , 'total' => 800 ] , [ 'id' => 103 , 'status' => 'paid' , 'total' => 1500 ] , [ 'id' => 104 , 'status' => 'pending' , 'total' => 600 ] , [ 'id' => 105 , 'status' => 'paid' , 'total' => 900 ] , ] ; $ paidCount = 0 ; $ bigOrders = [] ; $ sum = $ orders |> filter ( fn ( $ o ) => $ o [ 'status' ] === 'paid' ) // 請求済み注文のみ |> tap ( function ( $ o ) use ( &$ paidCount , &$ bigOrders ) { // 高額注文だけ保存 $ paidCount ++ ; if ( $ o [ 'total' ] > 1000 ) { $ bigOrders [] = $ o ; } }) |> map ( fn ( $ o ) => $ o [ 'total' ]) // 金額を取り出す |> reduce ( fn ( $ acc , $ yen ) => $ acc + $ yen , 0 ) ; // 合計金額を計算 $ average = $ paidCount ? $ sum / $ paidCount : 0 ; printf ( "請求済み注文数: %d 件 \n " , $ paidCount ) ; printf ( "平均金額: ¥%d \n " , ( int ) $ average ) ; echo "---- 高額注文一覧 ---- \n " ; foreach ( $ bigOrders as $ o ) { printf ( "注文ID=%d 金額=¥%d \n " , $ o [ 'id' ] , $ o [ 'total' ]) ; } 実行結果: https://3v4l.org/V8Ttj/rfc#vgit.master 請求済み注文数: 3 件 平均金額: ¥1200 ---- 高額注文一覧 ---- 注文ID=101 金額=¥1200 注文ID=103 金額=¥1500 このように、パイプ演算子と高階関数を組み合わせるととてもスッキリとした実装ができそうですね。 今後の展望（Future scope） RFC の中には、今回はまだ実現しないが将来やりたい機能拡張のアイデアがいくつか記載されています。 これらが実現するかは未知数ですが、どんなことが検討されているのか見てみましょう。 関数合成演算子（候補は + ） |> が「その場で実行」なのに対し、合成演算子は <?php $ upperThenReverse = strtoupper ( ... ) + strrev ( ... ) ; // 実行はまだしない echo 'hello' |> $ upperThenReverse ; // => OLLEH のように “クロージャ同士をくっ付けて、あとで呼べる 1 つの関数を返す” イメージです。 部分関数適用（Partial Function Application） 関数の引数の一部を ? にすることで、その部分を引数で受け取るクロージャになります。 <?php // 'foo' |> fn($s) => str_replace('o', 'a', $s) と同じ echo 'foo' |> str_replace ( 'o' , 'a' , ? ) ; オブジェクト呼び出しの短縮記法 パイプ左辺のオブジェクトのメソッドを呼ぶ $$->foo(123) のような簡易シンタックス <?php new DateTime ( '2025-06-11' ) |> $$ -> modify ( '+1 day' ) |> $$ -> format ( 'Y-m-d' ) ; // => "2025-06-12" イテレータ用の標準関数セット この記事で紹介した map や filter を、PHPの標準関数として用意する構想もあります。毎回自前で定義しなくてよくなるとありがたいですね！ まとめ パイプ演算子は「一時変数でつなぐコード」を「読みやすいパイプライン」に置き換えてくれます。小さな関数を作って組み合わせる関数型的なスタイルも書きやすくなりますので、PHP 8.5がリリースされたらぜひ試してみてください。

自己紹介 ラクスでPdMをしております。 @keeeey_m と申します。 現在の担当商材は、楽楽シリーズ(楽楽精算、楽楽明細、楽楽電子保存)を担当しており、個人としては楽楽精算×AIの担当、 楽楽明細・楽楽電子保存PdMチームのリーダーをしております。 きっかけ：毎日のテキストコミュニケーションでの葛藤 日々、業務でチャットツールを使い社内の人とテキストコミュニケーションをすることがほとんどです。ちょっとした雑談からタスクのやり取りまで、様々な情報が飛び交います。あれほど毎日テキストコミュニケーションをしていても、はっきり伝えようとすると直接すぎ、配慮して丁寧に説明しようとすると長い文面になり形式ばったものになったりと、自身が書いた文面を読み直し手が止まることがしばしばあります。 本来手軽で便利なはずなのに、なぜこうなるのか？と気になり、この事象を考察してみました。 こんな方におすすめ テキストコミュニケーションが苦手な方 ：チャットやメールで意図が伝わらず悩んでいる 人数の多い組織で働く方 ：様々な人とのやり取りで温度感の調整に困っている AI利用が増えている職場の方 ：AIとのやり取りと人間とのやり取りの使い分けに関心がある コミュニケーション改善を検討中のマネージャー ：チーム内のテキストコミュニケーション効率化を目指している 目次 対面とテキストコミュニケーションの決定的な違い：情報が欠落する 日本特有の事象：表現が難しい言語かつ文化 現在のベストプラクティス：具体的なテクニック AI時代の新たなリスク：自然言語での対応が可能、新しい懸念要素 考えられる対策：使い分けが重要 まとめ 対面とテキストコミュニケーションの決定的な違い：情報が欠落する 問題の根本は、対面コミュニケーションとテキストコミュニケーションの圧倒的な情報格差にあると、考えることができます。 感情・態度の表現 対面：声のトーン、表情、身振り手振りで「優しく言っている」「心配している」が伝わる テキスト：文字情報のみで推測するしかない 緊急度・重要度の伝達 対面：話すスピード、声の大きさ、間の取り方で「急いでいる」「じっくり考えてほしい」が分かる テキスト：同じ文面でも受け手によって解釈が変わる 確信度・断定度の表現 対面：声の強さ、頷き方、目線で「確信がある」「迷っている」が伝わる テキスト：語尾や表現に頼るしかない 関係性・距離感の調整 対面：物理的距離、姿勢、アイコンタクトで適切な距離感を保てる テキスト：敬語レベルのみで判断される これらの情報が完全に欠落するため、送り手の意図と受け手の解釈に大きなズレが生じるのです。 日本特有の事象：表現が難しい言語かつ文化 日本のコミュニケーション文化は、テキストでの表現を特に困難にします。 「察して文化」の複雑さ 「空気を読む」「言わなくても分かるでしょ」が前提 直接的表現を避ける傾向 相手に配慮した遠回しな表現が好まれる 複雑な敬語システム 尊敬語・謙譲語・丁寧語の使い分け 相手との関係性や立場による表現の変化 「です・ます」だけでは不十分な場面の多さ 文脈依存の高さ 前後の会話や状況に依存する表現 省略が多い日本語の特性 同じ言葉でも文脈で意味が変わる これらの特徴がテキストになると一気に崩れ、誤解の温床となってしまいます。 現在のベストプラクティス：具体的なテクニック 組織的にテキストコミュニケーションを改善するために、対面での豊かな表現力をテキストで再現してみても良いのかもしれません。 重要度・温度感の明示 【重要】【相談】【共有】【雑談】などの記号を活用 「心配になったので確認したいのですが」 「冗談半分ですが」 「真面目な話として」 緊急度の明確化 「急ぎ：今日中に」 「緊急ではありませんが」 「時間をかけて検討してください」 「確認だけで返信不要」 確信度の表現 「確信を持って言えるのは」 「個人的な推測ですが」 「感覚的には」 「間違いないと思います」 関係性の調整 前置き：「お疲れ様です」「心苦しいのですが」 後置き：「ご理解いただければと思います」「引き続きよろしくお願いします」 AI時代の新たなリスク：自然言語での対応が可能、新しい懸念要素 しかし、AIとの自然言語でのやり取りが可能になったことで、新たな懸念が考えられます。 AIとのコミュニケーションの特徴 ストレートな表現で十分に意図が伝わる 相手の感情や反応を気にする必要がない 察する・察してもらう必要がない 効率重視で結果が出る 一定した反応で感情の波がない 人間とAIのやり取りを変える必要性 AIとの自然で効率的なコミュニケーションに慣れることで、以下のリスクが考えられます。 察る能力の衰退 ：AIとの「察しなくていい」やり取りに慣れ、人間同士で必要な察する能力が低下 直接的表現への偏り ：AIとのストレートなやり取りに慣れ、人間相手でも配慮に欠ける表現をしてしまう 期待値のミスマッチ ：AIの「完璧な理解」に慣れ、人間が理解してくれないことへのイライラが増加 感情への対応力低下 ：AIの一定した反応に慣れ、人間の気分や状況の変化に柔軟に対応できなくなる 考えられる対策：使い分けが重要 この新たなリスクに対する対策として、使い分けの重要性が浮き彫りになります。 意識的なコミュニケーションスタイルの使い分け AI向け：効率重視、ストレート、結果志向 人間向け：配慮重視、関係性考慮、感情も含めた総合的なやり取り 具体的な対策 コンテキストスイッチの習慣化 AIとのやり取り後、人間とのコミュニケーションでは意識的にトーンを調整 定期的な振り返り テキストコミュニケーションで誤解が生じた事例の共有と学習 成功事例の蓄積と横展開 ハイブリッドアプローチ 重要な案件は対面またはビデオ通話を併用 テキストだけに依存しないコミュニケーション設計 継続的なスキル維持 人間らしい配慮や察する能力を意識的に使い続ける AIに任せられることと、人間が担うべきことの区別 まとめ 難しいテキストコミュニケーションに加え、さらに自然言語でのAI利用が伴い、今後コミュニケーション力は重要な要素になり得ると考えられます。それと同時に、AIを活用することと本質は同じであるとも言えます。コミュニケーションも、AIもシンプルに考えると、情報の量と質が肝になるのは共通することです。 AI時代だからこそ、人間らしいコミュニケーション力がより価値を持つのかもしれません。効率性を追求するAIとの使い分けを意識しながら、人間同士の豊かなやり取りを大切にしていきたいものです。 AIの業務活用とかけまして、コミュニケーションととく。その心は、どちらも情報の質と量が結果を左右します。 お後がよろしいようで。

こんにちは、AIエージェント開発課 課長の石田です。 「ITサービスで企業の成長を継続的に支援します」 これが私たちラクスのミッションです。 私たちはBtoB SaaSの提供を通じて、企業の成長につながる業務効率化や生産性向上に向き合ってきました。 そのために、開発生産性向上はもちろんのこと、顧客の体験価値向上や顧客の業務効率化を目的とした機能開発にも組織を挙げて取り組んでいます。 その最も新しい取り組みが、 2025年5月に設立した専門組織「AIエージェント開発課」 です。 www.rakus.co.jp AIエージェントはユーザーの指示がなくとも自律的に目的を理解し、最適なタスクを実行することが可能です。 複雑な業務フローを持つBtoB領域においても、非常に大きなインパクトが期待でき、ラクスが最も注力していく領域の一つです。 そこで本記事ではラクス初・AIエージェント専門組織の挑戦についてご紹介したいと思います。 経費精算 × AI には圧倒的な顧客貢献余地がある 公開中のAI機能と、今後のAIエージェント機能の役割例 最速で価値提供できる組織へ向けた3つのポイント 1. AIエージェント時代に応える、スピードと探究で価値を生む開発スタイル 2. ユーザーの声を開発に直結 3. 16年分・延べ18,000社分の多彩な業務データを活用 最初に取り組むのは、「経費申請ワークフロー」 AIエージェントを通じて、仕事の意味も変えていきたい 経費精算 × AI には圧倒的な顧客貢献余地がある 経費精算という、企業のあらゆるバックオフィスに存在しながら、いまだに紙・Excel・メールといったアナログな処理が根強く残る業務領域に、更なる楽を実装していきます。 そこで我々が最初に取り組むのは、「楽楽精算」でのAIエージェントの提供です。 「楽楽精算」でも、経費申請の申請やチェックなどはできましたが、人の手で行っている処理が多かったです。 例えば、申請書の入力やサービス区分の選択、紐づけるクレジットカード利用明細を探したり、それらの確認です。 この業務は、申請ミスや差し戻し、手入力の負担といった “ノンコア業務”に工数が偏りがちな構造的課題を抱えており、自動化・最適化の余地が非常に大きい領域 です。 www.rakus.co.jp tech-blog.rakus.co.jp すでに公開しているAI機能と合わせて、申請者のワークフロー全体の「めんどくさい」「煩わしい」「いい感じにしてくれないかな」を、AIエージェント機能により解決しようとしています。 公開中のAI機能と、今後のAIエージェント機能の役割例 最速で価値提供できる組織へ向けた3つのポイント AIエージェント開発課は 「顧客に価値を最速で届けられるAI組織」 として、以下を強みとしていきたいと考えています。 1. AIエージェント時代に応える、スピードと探究で価値を生む開発スタイル ラクスの開発は、「熟考を重ねた綿密な設計と開発」を得意としています。法要件への正確な対応に強みを持っていますが、変化の速いAI領域では高速な試行錯誤が必要です。ラクスでは、目的に応じて柔軟に開発プロセスのあり方を変化させています。 意図的に、ＡＩエージェント開発課では、「楽楽精算」の開発チームとは異なった組織として立ち上がりました。この中には、エンジニアだけでなくUXデザイナーや営業メンバーなども内在します。 また、エンジニアメンバーは得意領域を持ちつつも、プロダクト開発に必要な業務は、だれであれ、参加します。例えば、 顧客からヒアリングした結果を、全員で議論し、UI/UXを含めた改善案を出し合うなども、全員参加します。 これにより、会社としては前例がないほど、高速に検証サイクルを回しており、組織立ち上げ１ヶ月経たずして、モックアップを３つ作り、それを用いたお客様ヒアリングを開始し始めました。 引き続き、AIエージェントという未知の領域に対し、既存の楽楽精算に縛られることなく、新しい顧客体験をゼロベースで探索しています。 2. ユーザーの声を開発に直結 ラクスのプロダクト開発チームは通常、「開発本部」という開発専門組織に所属します。しかし、AIエージェント開発課では あえてビジネスサイド直結の組織 としました。 これは私たちが 一次情報への近さを優先 したためです。顧客ヒアリング等を柔軟に行えるチームとし、プロダクト仮説と技術検証のループを高速化することが目的です。 立ち上がって１ヶ月と経っていませんが、作成したプロトタイプをもとに顧客ヒアリングを開始し、実際に顧客からの声を頂いております。 また、その声をすぐにエンジニア・デザイナーがキャッチアップできる体制が整っています。 3. 16年分・延べ18,000社分の多彩な業務データを活用 「楽楽精算」はこれまで18,000社に導入され、経費精算システム累計導入社数No.1となっています。 蓄積された16年分の業務ログや申請傾向など、多様な業種・業態のリアルなデータに基づいた開発 が行えます。この“豊富なリアルデータ”と“多様なステークホルダー”を活かして、リアリティのあるAIエージェントサービスを作っていきたい考えです。 最初に取り組むのは、「経費申請ワークフロー」 初期スコープとして注力しているのが、経費精算の中でも手間の大きい「経費申請ワークフロー」です。 領収書をアップロードすると、AIエージェントが内容を解析・構造化し、関連のあるデータ（例えば、事前申請やクレジットカード利用明細など）を探し出します。 それらのデータを活用して、申請用データを提案します。これにより、現在は申請者が自ら考え入力していた負担を軽減します。 当社プレスリリースより https://www.rakus.co.jp/news/2025/0501.html 　　 技術的な方針としては、顧客の業務課題を最も早く解決できること としています。 そのため「過去の履歴からの推論」や「定型処理のルールベース自動化」など、最適な技術要素を段階的に組み合わせながら構築することとし、必ずしも（現時点では）汎用的なAIエージェントを目指さない判断をしました。 経費精算業務は定型化・構造化されている部分も多く、LLMが事前定義されたタスクを実行する 「エージェンティック・ワークフロー」 を採用しています。この延長で、AIエージェントに即したUIUXの導入も検討していきます。 AIエージェント技術を使えば、申請から承認までの一連の経費処理を完全に自動化できるかもしれません。しかし私たちは、 申請者や経理担当者が「自分は内容を理解し、きちんと確認した」という安心感と納得感 を得られることを最優先に位置づけました。そこで、 エージェントを“代行者”ではなく“支援者”として設計 しています。 AIエージェントを通じて、仕事の意味も変えていきたい AIエージェント開発課はまだ始動したばかりですが、経費申請ワークフローを皮切りに、今後も積極的に周辺領域へと広げて参ります。 そのために、 最新のAI/AIエージェント技術を探求しつつ、お客様の体験価値を追求する「顧客志向」 を大切にしています。 最終的には、「ヒトとAI」が相互助力により、より心地よい業務体験を実現・提供していくことを目指しています。そんな未来に向けて、システムをご利用いただいているお客様の声を原動力としながら一歩ずつ進んでいきます。 まだ始まったばかりのAIエージェント開発課ですが、プロジェクトの進行や技術的な実装が進展したらまたのブログでもご報告していきます。楽しみにお待ちいただければ幸いです。

自己紹介 ラクスでPdMをしております。 @keeeey_m と申します。 現在の担当商材は、楽楽シリーズ(楽楽精算、楽楽明細、楽楽電子保存)を担当しており、個人としては楽楽精算×AIの担当、 楽楽明細・楽楽電子保存PdMチームのリーダーをしております。 こんな方におすすめ プロダクトマネージャーとして孤独感を感じている方 プロダクトマネージャーをマネジメントする立場の方 プロダクトマネージャーを目指している方 組織開発やチームマネジメントに携わる方 目次 はじめに：PdMの孤独という普遍的な課題 PdMが感じる孤独の本質 孤独と向き合う：個人としてのアプローチ 組織として何ができるか まとめ：孤独と健全に向き合う「場」を作る はじめに：PdMの孤独という普遍的な課題 先日、メンバーからのとある声を知り、プロダクトマネージャー（PdM）の孤独について深く考える機会がありました。この投稿は、私自身の経験とも重なり、多くのPdMが感じている普遍的な課題ではないかと感じました。 PdMという役割に就く人が感じる孤独感は、単なる職場での寂しさとは質が異なります。それは、役割の本質に根ざした、より深い次元の孤独です。 PdMが感じる孤独の本質 組織における立ち位置の特殊性 PdMは開発チーム、デザインチーム、マーケティング、営業、経営陣など様々なステークホルダーの間に立つ「ハブ」的な役割を担います。しかし、どの部門にも完全には属さないため、帰属意識を感じにくく、自分の居場所を見つけるのに苦労することがあります。 意思決定の重圧と責任 PdMは製品の方向性や優先順位等について重要な判断を下す必要があります。会社や製品のフェーズによってPdMの役割は異なったりするものの、PdMが下すその決定は往々にして誰かを失望させたり、トレードオフを伴います。最終的な責任を負う立場にいながら、直接的な権限は限られているというジレンマも抱えています。 解像度の格差による孤独 プロダクトマネジメント、プロジェクトマネジメント、さらに開発の設計部分まで理解できるPdMは、誰よりも早く問題や危機感を察知します。しかし、その複合的な視点から見えてくる問題を、特定の専門領域に特化した視点を持つ人に理解してもらうのは困難です。 孤独と向き合う：個人としてのアプローチ 孤独を力に変える この孤独感は必ずしも解決すべき問題ではないと、私は考えています。なぜなら、それは責任ある意思決定の証でもあるからです。重要な決断を下す時、最終的には一人で判断し、その結果に責任を持つ必要があります。他人の意見に左右されず、データと自分の信念に基づいて決断する瞬間には、必然的に孤独感が伴います。これは逃げられない、そして価値のある経験です。 客観性を保つための距離感 あらゆるステークホルダーと適度な距離を保つことで、どこかの部門に偏った判断をすることなく、プロダクト全体の最適化を図ることができます。この「中立的な立場」は、時として孤独を感じさせますが、PdMの重要な強みでもあります。 組織として何ができるか とはいえ、プロダクトマネジメント組織を率いるリーダーとして、適切なサポート体制を整える必要があると考えています。 実際に効果があったこと、試行錯誤しながら取り組んでいることです。 複数名体制による物理的・精神的な負荷の分散 私の経験では、PdMを複数名体制にすることで、孤独問題が大きく解消されました。同じ立場・役割で協業できるメンバーがいることで、物理的にも精神的にも負荷が下がります。特に、意思決定の重圧を共有できることは、大きな安心感につながります。 早期発見と迅速なサポート 過去の失敗経験から、メンバーが一人で問題を抱え込んでしまう前に、早期に気づき、サポートすることが重要だと学びました。 定期的な1on1ミーティングでの状況確認 普段の会話の中での変化の察知 「できない」という現状の言語化を促す 段階的なアプローチ 組織として以下のような段階的なアプローチを実践しています。 こまめな壁打ちの時間の確保 共感と理解を示すコミュニケーション メンバーからのアクションベースでの対応（マイクロマネジメントを避ける） 外部イベントのレポート共有など、情報共有の機会創出 実践的なアドバイス これらの取り組みを実施する上で、以下の点に注意しています。 過度な介入を避け、メンバーの主体性を尊重する 問題の早期発見のための観察力を磨く 共感を示しつつも、具体的な解決策を提示する 組織の規模や状況に応じて、柔軟にアプローチを調整する まとめ：孤独と健全に向き合う「場」を作る 私自身もPdMとして、複数の視点から同時に物事を見ることで生まれる内的葛藤や、解像度の高さゆえの孤独を経験してきました。その中で、理解を示してくれる人が一人でもいることの大切さも痛感しました。 だからこそ、組織としては孤独そのものを「悪」として排除しようとするのではなく、孤独と健全に向き合える場を用意することが重要だと考えています。これは単なる愚痴の吐き出し場ではなく、孤独感の意味を理解し、それを力に変えていくためのスペースです。 PdMという役割の本質を理解した上で、孤独を完全に取り除こうとするのではなく、それと健全に共存する方法を組織として支援する。これこそが、真にPdMを理解したリーダーのアプローチだと考えています。 PdMが「一人で戦っている」のではなく「組織に支えられながら、時には一人で決断する」という状態を作り出すこと。それが、プロダクトマネジメント組織のリーダーとして目指していることです。

はじめに こんにちは！ エンジニア３年目のTKDSです！ 今回はメタデータ管理をPostgresqlやMySQLなどのSQLデータベースが担う新しいOSSのLakehouseフォーマット、Ducklakeについて試してみました！ 今回はPostgresql+s3(minio)+DuckDBで構築してます。 はじめに Ducklakeの概要 準備 1. composeでPostgresqlとminioを起動 2. minioでバケットを作成する 3. DuckDB側の準備と起動 試す まとめ Ducklakeの概要 Ducklakeは公式HPの一文によるとSQLデータベースをカタログ置き場に、データをparquetファイルに保存する形式のLakehouseフォーマットだそうです。 DuckLake delivers advanced data lake features without traditional lakehouse complexity by using Parquet files and your SQL database. It's an open, standalone format from the DuckDB team. （Google翻訳） DuckLakeは、ParquetファイルとSQLデータベースを使用することで、従来のレイクハウスの複雑さを排除しながら、高度なデータレイク機能を提供します。DuckDBチームが提供するオープンなスタンドアロンフォーマットです。 簡単にLakehouseを使えると解釈しておきましょう！ では早速準備して使っていきます。 準備 今回、Postgresqlとminioをcomposeで建て、それぞれカタログ置き場、データ置き場として使います。 環境構築後、DuckDB CLIからクエリを打って操作していく形です 。 1. composeでPostgresqlとminioを起動 まず.envファイルにパスワード等を記載しておいてください。 Minioのパスワードは短いと以下のエラーでコンテナ起動できないので注意。 MINIO_ROOT_USER length should be at least 3, and MINIO_ROOT_PASSWORD length at least 8 characters MINIO_ROOT_USER=root-minio MINIO_ROOT_PASSWORD=root-minio POSTGRES_USER=postgres POSTGRES_PASSWORD=postgres POSTGRES_DB=postgres ディレクトリを作っておきます。 mkdir ./data/minio mkdir ./data/postgres 以下の内容でcomposeファイルを書きます。 services : minio : image : quay.io/minio/minio:RELEASE.2025-05-24T17-08-30Z container_name : minio command : server /data --console-address ":9001" environment : MINIO_ROOT_USER : ${MINIO_ROOT_USER} MINIO_ROOT_PASSWORD : ${MINIO_ROOT_PASSWORD} volumes : - ./data/minio:/data ports : - "127.0.0.1:9000:9000" - "127.0.0.1:9001:9001" healthcheck : test : [ "CMD" , "mc" , "ready" , "local" ] start_period : 10s interval : 30s timeout : 20s retries : 3 postgres : image : postgres:17.5-bookworm container_name : postgres environment : POSTGRES_USER : ${POSTGRES_USER} POSTGRES_PASSWORD : ${POSTGRES_PASSWORD} POSTGRES_DB : ${POSTGRES_DB} volumes : - ./data/postgres/init.sql:/docker-entrypoint-initdb.d/init.sql:ro ports : - "127.0.0.1:5432:5432" healthcheck : test : [ "CMD-SHELL" , "pg_isready -U ${POSTGRES_USER}" ] interval : 10s timeout : 5s retries : 5 networks : default : name : ducknet init.sqlには以下を記載します。 CREATE DATABASE ducklake; docker compose up で起動します。 2. minioでバケットを作成する 今回GUIから作りました。 http://localhost:9001/ にアクセスしてください。 ログインして、左側のCreate Bucketからバケットを作ります。 今回名前はducklake-pocにしました。 3. DuckDB側の準備と起動 DuckDBをインストールします。 今回はCLIのDuckDBを使います。 HPにあるコマンド curl https://install.duckdb.org | sh インストールできたか確認 $ duckdb -version v1.3.0 71c5c07cdd DuckDBに必要な拡張機能をインストールします。 duckdbコマンドでCLIを起動して以下のコマンドを打ってください。 INSTALL ducklake; INSTALL httpfs; INSTALL postgres; LOAD postgres; LOAD ducklake; LOAD httpfs; postgres、httpfsはDucklakeのドキュメントには書いてなかったですが、とりあえず関係してそうなのでインストールしておきました。 Postgresqlとオブジェクトストレージに接続し、アタッチしたカタログデータベースを使用状態にします。 まずs3接続用シークレットを作ります。 create secret (type s3, key_id 'root-minio', secret 'root-minio', endpoint 'localhost:9000', use_ssl false, url_style 'path'); では接続します。 ATTACH 'ducklake:postgres:dbname=ducklake_catalog host=localhost user=postgres password=postgres' AS postgres_ducklake (DATA_PATH 's3://ducklake-poc'); USEしたときにエラーでなければ成功です。 USE postgres_ducklake; Attachしたタイミングでテーブルが作成されます。 publicスキーマに作られてます。 $ docker exec -it postgres psql -U postgres -d ducklake psql (17.5 (Debian 17.5-1.pgdg120+1)) Type "help" for help. ducklake=# \dt Did not find any relations. ducklake=# \dt List of relations Schema | Name | Type | Owner --------+---------------------------------------+-------+---------- public | ducklake_column | table | postgres public | ducklake_column_tag | table | postgres public | ducklake_data_file | table | postgres public | ducklake_delete_file | table | postgres public | ducklake_file_column_statistics | table | postgres public | ducklake_file_partition_value | table | postgres public | ducklake_files_scheduled_for_deletion | table | postgres public | ducklake_inlined_data_tables | table | postgres public | ducklake_metadata | table | postgres public | ducklake_partition_column | table | postgres public | ducklake_partition_info | table | postgres public | ducklake_schema | table | postgres public | ducklake_snapshot | table | postgres public | ducklake_snapshot_changes | table | postgres public | ducklake_table | table | postgres public | ducklake_table_column_stats | table | postgres public | ducklake_table_stats | table | postgres public | ducklake_tag | table | postgres public | ducklake_view | table | postgres (19 rows) ducklake=# \dt public.ducklake_column; List of relations Schema | Name | Type | Owner --------+-----------------+-------+---------- public | ducklake_column | table | postgres (1 row) これで使う準備は完了です。 試す Introduction のサンプルを元に試しにやってみます。 Postgresqlとminioで環境構築してるので、一部を改変して実行してます。 ※色々横道それながらやってたので、一部オブジェクトファイルのファイル名違ったりしますが気にしないでください。 CREATE TABLE nl_train_stations AS FROM 'https://blobs.duckdb.org/nl_stations.csv'; これでCSVファイルからデータを読み込みテーブルが作成されます。 DBを見てみるとテーブルの情報が作成されてます。 ducklake=# select * from ducklake_table; table_id | table_uuid | begin_snapshot | end_snapshot | schema_id | table_name ----------+--------------------------------------+----------------+--------------+-----------+------------------- 1 | 01974993-3ba1-7505-b4bf-eecff46886e0 | 1 | | 0 | nl_train_stations (1 row) ducklake=# select table_id,column_name from ducklake_column; table_id | column_name ----------+------------- 1 | id 1 | code 1 | uic 1 | name_short 1 | name_medium 1 | name_long 1 | slug 1 | country 1 | type 1 | geo_lat 1 | geo_lng (11 rows) オブジェクトストレージ側にもparquetファイルが作成されます。 では続きをやっていきます。 以下コマンドはparquetファイルの情報を取得しています。 D FROM glob('s3://ducklake-poc/*') ; ┌─────────────────────────────────────────────────────────────────────────┐ │ file │ │ varchar │ ├─────────────────────────────────────────────────────────────────────────┤ │ s3://ducklake-poc/ducklake-01974989-7208-7460-964d-c17d34b116c7.parquet │ └─────────────────────────────────────────────────────────────────────────┘ D FROM 's3://ducklake-poc/*.parquet' LIMIT 10; ┌───────┬─────────┬───┬─────────────────┬─────────────────┐ │ id │ code │ … │ geo_lat │ geo_lng │ │ int64 │ varchar │ │ double │ double │ ├───────┼─────────┼───┼─────────────────┼─────────────────┤ │ 266 │ HT │ … │ 51.69048 │ 5.29362 │ │ 269 │ HTO │ … │ 51.700553894043 │ 5.3183331489563 │ │ 227 │ HDE │ … │ 52.4091682 │ 5.893611 │ │ 8 │ AHBF │ … │ 50.7678 │ 6.091499 │ │ 818 │ AW │ … │ 50.78036 │ 6.070715 │ │ 51 │ ATN │ … │ 51.921326524551 │ 6.5786272287369 │ │ 5 │ AC │ … │ 52.2785 │ 4.977 │ │ 550 │ EAHS │ … │ 52.079796120944 │ 7.0163583755493 │ │ 12 │ AIME │ … │ 45.55438 │ 6.64869 │ │ 819 │ ACDG │ … │ 49.004048 │ 2.571133 │ ├───────┴─────────┴───┴─────────────────┴─────────────────┤ │ 10 rows 11 columns (4 shown) │ └──────────────── チュートリアルの通りに変更を加えます。 UPDATE nl_train_stations SET name_long='Johan Cruijff ArenA' WHERE code = 'ASB'; 変更を加えるとファイルが増えてるのがわかります。 FROM glob('s3://ducklake-poc/*') ; ┌──────────────────────────────────────────────────────────────────────────────┐ │ file │ │ varchar │ ├──────────────────────────────────────────────────────────────────────────────┤ │ s3://ducklake-poc/ducklake-01974993-3ba1-7387-ac08-101cab81f9f7.parquet │ │ s3://ducklake-poc/ducklake-01974994-9e69-7177-a6e5-253d9cf9d4af.parquet │ │ s3://ducklake-poc/ducklake-01974994-9e83-7c25-b00b-1f41f679902e-delete.par… │ └────────────────────────────── 過去のデータの状態を記憶したsnapshot一覧も見ることができるようです。 FROM postgres_ducklake.snapshots(); ┌─────────────┬────────────────────────────┬────────────────┬─────────────────────────────────────────────────────────────────────┐ │ snapshot_id │ snapshot_time │ schema_version │ changes │ │ int64 │ timestamp with time zone │ int64 │ map(varchar, varchar[]) │ ├─────────────┼────────────────────────────┼────────────────┼─────────────────────────────────────────────────────────────────────┤ │ 0 │ 2025-06-07 17:43:15.138+09 │ 0 │ {schemas_created=[main]} │ │ 1 │ 2025-06-07 17:47:54.805+09 │ 1 │ {tables_created=[main.nl_train_stations], tables_inserted_into=[1]} │ │ 2 │ 2025-06-07 17:49:26.108+09 │ 1 │ {tables_inserted_into=[1], tables_deleted_from=[1]} バージョンごとに内容を確認可能です。 SELECT name_long FROM nl_train_stations AT (VERSION => 1) WHERE code = 'ASB'; nl_train_stations AT (VERSION => 2) WHERE code = '┌─────────────────────────┐ │ name_long │ │ varchar │ ├─────────────────────────┤ │ Amsterdam Bijlmer ArenA │ └─────────────────────────┘ SELECT name_long FROM nl_train_stations AT (VERSION => 2) WHERE code = 'ASB'; ┌─────────────────────┐ │ name_long │ │ varchar │ ├─────────────────────┤ │ Johan Cruijff ArenA │ └────────────── カタログからデタッチするには以下のコマンドを使います。 USE memory; DETACH postgres_ducklake; ここまでで色々試すことができました！ まとめ 今回はDucklakeをPostgresql + s3(Minio) + DuckDBで構築しました！ インターネット上に情報が少なくかなり苦労しましたが、動かせてよかったです！ データ本体はオブジェクトストレージに置く形式なので、低コストで大量のデータをおけるのではないでしょうか？ これからもちょくちょく触ってみたいと思いました。 ここまで読んでいただきありがとうございました！

自己紹介 ラクスでPdMをしております。 @keeeey_m と申します。 現在の担当商材は、楽楽シリーズ(楽楽精算、楽楽明細、楽楽電子保存)を担当しており、個人としては楽楽精算×AIの担当、 楽楽明細・楽楽電子保存PdMチームのリーダーをしております。 きっかけは交流セッションのオファー 先日、アシスタントマネージャー（AM）へのステップアップを目指す女性社員向けの社内研修で話をする機会をいただきました。東京拠点で研修を受けている17名に向けて、マネジメント職として経験してきたことをざっくばらんに話してほしいとのこと。開発部門でマネジメント職として働く私の話が、彼女たちに新たな視点や気づきを与え、今後のキャリアを考える上での貴重なヒントになればという趣旨でした。 このオファーをきっかけに、自分自身のキャリアを振り返る良い機会となりました。マネジメントキャリアに前向きな気持ちがある一方で、自身が職責を果たせるのか、ライフプランと両立できるのかといった不安を感じている方々に向けて、ささやかながら私の経験をシェアしたいと思います。 自己紹介 きっかけは交流セッションのオファー 偶然の積み重ねが道になる 一人では解決できない課題 マネジメントとやりがい 強みと成長領域 ラベリングとの向き合い方 キャリアは一方通行ではない 偶然の積み重ねが道になる 2013年、新卒エンジニアとして入社してから10年余り。気がつけば製品管理課でチームを率いる立場になっていました。「マネジメントを目指そう」と決意した瞬間があったかと問われれば、そうではないと答えるでしょう。日々の業務に向き合い、少しずつ責任範囲が広がり、いつしかマネジメント層になっていました。 マネジメントという選択肢に興味を持ったきっかけは、ある気づきからでした。「自分が実現したい（達成したい）状態が、一個人の能力だけでは解決できない事象もある」という現実に直面したときです。 一人では解決できない課題 ラクスベトナムの立ち上げ初期、現地エンジニアの離職率の高さに悩まされていました。新たな開発拠点の構築のため、現地メンバーへのレクチャーや一緒の開発を通じて貢献しようとしましたが、教えては離職するという負のサイクルが続きました。当時は自分の能力不足を感じ、何ができたのか自問自答していました。 しかし1〜2年後、ラクスベトナムの現地マネジメント体制や採用方法が変わると、離職率は大幅に下がりました。そのとき気づいたのです。これは個人レベルでどうにかなる問題ではなかったということを。組織的な課題解決には、マネジメントという手段も必要だと考え始めたのです。 マネジメントとやりがい 「マネジメントとは、組織の目標達成のために、経営資源（ヒト・モノ・カネ・情報など）を効率的かつ効果的に活用し、組織の運営を最適化すること」。これを実感できるのは、一人の力では到底できないプロジェクトを成功に導けたときだと考えています。 現在進行中の楽楽精算のAI機能開発プロジェクトは、まさにその例です。自部署だけでなく部署を横断して経営資源を効率的に活用しています。何を目指しているのかを各開発部門や関連部署に説明し、理解と協力を得る。このプロセスを経て、最終的には記者会見やプレスリリースの内容にも携わるまでになりました。まだまだ始まったばかりですが、一人では決して達成できなかった成果の一つです。 強みと成長領域 ラクスには評価軸として全職種においてパフォーマンスに加えコンピテンシー（行動特性）評価があります。 ラクスのコンピテンシー 思考力（課題設定力・分析力 /状況判断力） 行動力（段取力・課題実行力/率先性・イニシアチブ） 人間関係力（折衝・交渉力/コミュニケーション力） 組織推進力（リーダーシップ・フォロワーシップ/チームワーク/人材育成） AMやマネジメントとしての私の強みは、「思考力（課題設定力・分析力）」「行動力（段取力・課題実行力）」「コミュニケーション力（折衝・交渉力）」が挙げられます。現場で一つひとつステップを上がってきたからこそ、実務の解像度が高いのも強みです。 これらの強みは、不確実性の高い状況での意思決定と、それへのコミットメントを繰り返してきたことで培われました。意思決定をする際、必要な情報が全て揃うことはありません。それによって思いもよらぬことが起きることもあります。その結果を振り返り、「予防線は張れなかったのか」「リスクとして検討できなかったのか」「見落としていた予兆はなかったのか」と内省する。この量を繰り返し、質を上げることで、結果的に思考力と行動力が磨かれました。 また、思考力（課題設定力・分析力）と行動力（段取力・課題実行力）を活かして、折衝・交渉力にも良い影響を与えています。関連部署にはその部署の目標などがあり、どのような事業KPIを持っているかなど相手の置かれている状況を理解することで、取り組むことができています。 一方で、今後さらに成長させたい点もあります。 コミュニケーション力 : メンバーへの情報開示と正確な伝達 施策や新たな取り組みにワクワクしてもらえるような伝え方 伝えにくいことでも事実と解釈を区別し、誤解なく伝える力 組織推進力 : リーダーシップとフォロワーシップ チームワーク 人材育成 ラベリングとの向き合い方 実は、AMになることにはかなり抵抗がありました。AMになれば、いずれマネジャーへの話は避けては通れなくなり、「女性管理職」というラベリングがつくことに違和感があったのです。ジェンダーに関係なく、一人のエンジニアとして、一人の人としてキャリアを歩み、ものづくりや課題解決に取り組む人として見られたい。 しかし、同様にラベリングに対して違和感を感じていた人の言葉を目にしました。 「いつかそういうラベルがビジネスの世界に存在しなくなってくれたらいいと思うけど、それが実現する日はきっととても遠いから、存在する前提の中でできることをやろうと思った。」 私は喜んで前に出る。 いつかそういうラベルがビジネスの世界に存在しなくなったらいいと思うけど、それが実現する日はきっととても遠いから、存在する前提の中でできることをやろうと思うに至った次第。 — Aki (@LoveIdahoBurger) July 22, 2023 そういう考え方もできるなと思い、捉え方を徐々に変えました。まだ「誰かの一歩踏み出す勇気になったら、喜んで引き受ける」という境地には至っていませんが、自分ができることをやろう、と考えるようになりました。 キャリアは一方通行ではない キャリアは「One Way Door（一方通行）」ではありません。マネジメントにチャレンジしてみて、専門性を追求したくなったら、また意思決定すればいい。自分自身と向き合い、自分自身で意思決定をすることが大切です。 周囲の考えを汲み取る必要もなければ、無理にロールモデルを見つける必要もない。生きていく上で、世の中の様々な人の考えに触れ、自分に合うものをちょっとずつ拝借する、それだけで十分なのではないでしょうか。 日々の業務に向き合い、「もうちょっとだけやってみよう」という姿勢。そして、やるだけやってみて、また次の選択をする。そんな一歩一歩が、結果的に自分だけのキャリアを形作っていくのだと思います。

はじめに こんにちは。楽楽販売開発課のkananpaです。 今回は、私が所属しているサポート対応チームにて、NotebookLMを使ってナレッジ検索用の問い合わせBotを作成した取り組みについてご紹介します。 「ナレッジはたくさんあるけど、活かしきれていない…」 そんな課題を解消すべく、AIツールを導入してどのようにナレッジを整理・活用したか、その作成過程と課題を素直にまとめました。 はじめに ナレッジは溜まっているのに、活用できていない現状 NotebookLMでナレッジ検索用Botを構築 NotebookLMを選んだ理由 データの準備とインポート 異なるデータ形式をどう扱ったか 実際の変換処理 CSV ➡ Markdownの変換 HTML ➡ Markdownの変換 Markdown変換で工夫したポイント プロンプトの設定 実際に使ってみた感想と効果 問い合わせ対応での活用事例 利用者の声 見えてきた課題と今後の展望 おわりに ナレッジは溜まっているのに、活用できていない現状 私たちが提供している「楽楽販売」は、カスタマイズ性が非常に高く、機能や設定も多岐にわたるサービスです。　 それに伴って手厚い顧客サポート体制も魅力の一つとなっています。 そのため、CS（カスタマーサクセス）チーム、開発チーム一丸となって、より良いサポート対応を行おうと改善を続けてきた結果、以下のような豊富なナレッジが蓄積されています。 顧客向けマニュアル（機能説明、設定方法など） 過去の問い合わせ対応履歴 CSチームが管理しているナレッジ しかし、それらが点在していたり、表記揺れがあったり、情報量が多すぎるなどで、必要な情報にたどり着くのに時間がかかっていました。 こうした課題を解決し、お客様からのお問い合わせに対して、より早く適切な回答ができる環境を整えるために、AIサービスを活用したナレッジ検索用Botの構築に取り組みました。 NotebookLMでナレッジ検索用Botを構築 以下では、NotebookLMを選定した背景と、その具体的な構築プロセスについて説明します。 NotebookLMを選んだ理由 ナレッジ検索用Botを導入するにあたり、まずは以下の要件を満たすAIサービスである必要がありました。 全社員が利用可能であること 社外秘情報も扱えること（※前提：内部利用に限る） コストを低く抑えられること ChatBot形式で質問できること 任意のドキュメントを学習できること これらの条件を踏まえ、候補として次の3つのAIサービスを比較しました。 ツール名 特徴 ChatGPT ・ファイルの対応形式が広い ・ウェブ検索が可能 NotebookLM ・資料の学習に特化させたAI ・基本的に資料に書かれていないことは回答しない ・回答時にソースの箇所を表示 Gemini ・プライバシー重視の設計 ・画像やコード、音声、動画など多様な形式に対応 この中で、特に重要視したのは次の3点です。 リサーチ用途に特化していること 資料に基づく正確な回答が得られること 回答時に出典を明示できること これらの点より、 NotebookLM がナレッジ検索用途に最適と考え、採用を決定しました。 データの準備とインポート 利用するAIサービスが決定し、次にナレッジ検索に必要なデータの整備とインポート作業に取りかかりました。 しかし、実際に蓄積されていたナレッジは、管理場所も形式もバラバラ、以下のように出力形式も統一されていませんでした。 顧客向けマニュアル（機能説明、設定方法など） ⇒ HTML 過去の問い合わせ対応履歴 ⇒ CSV CSチームが管理しているナレッジ ⇒ Markdown 異なるデータ形式をどう扱ったか そこでまず、これらの資料をMarkdown形式に統一する作業を行いました。 統一形式にMarkdownを採用した理由は、次のような利点があるためです。 Q&A構造をわかりやすく表現できる 見出し、箇条書き、リンクを使って構造的に整理できる NotebookLM上での表示が整いやすく、読みやすい 原文リンクを埋め込むことで、元資料に簡単にアクセス可能 これにより、質問と回答を明確に区別して学習させることが可能になり、誤った理解を防げるだけでなく、利用者にとっての可読性やナビゲーション性の向上にもつながります。 実際の変換処理 Markdownへの変換には、PHPで提供されているライブラリを使用しました。 CSV ➡ Markdownの変換 まずCSV形式の資料については、PHPの組み込みクラスである SplFileObject を使ってCSVデータを配列に整形し、Markdown形式に変換しました。 CSV ➡ Markdown変換イメージ図 HTML ➡ Markdownの変換 また、HTML形式の資料については HtmlConverter ライブラリを使用し、特に表形式データなども正確に変換できるよう TableConverter も併用しました。 HTML ➡ Markdown変換イメージ図 ※上記の画像は本ブログ用に作成したサンプル図であり、楽楽販売の実際の仕様とは一切関係ありません。 Markdown変換で工夫したポイント Markdown形式への変換にあたっては、上記添付画像の通り以下のような工夫を行いました。 元データの表示構造を極力再現（見出し・箇条書き・表など） NotebookLMのファイル数制限に配慮し、関連情報を1ファイルに集約 原文リンクをMarkdownに明記し、出典へのアクセス性を確保 プロンプトの設定 最後にプロンプトの設定を行いました。 NotebookLMではデフォルトであらかじめ用意されプロンプトを使用することもできますが、 今回は以下添付画像のように「カスタム」で設定し、回答の長さも「短め」に設定しました。 プロンプトの設定例 回答の長さに関して、ナレッジ検索用としては端的にまとまった内容が確認できた方が適切だろうと判断し、「短め」に設定しました。 「短め」でも重要な情報が漏れずにピックアップされており、十分に内容を把握できます。 実際に使ってみた感想と効果 問い合わせ対応での活用事例 実際に作成したBotに質問している様子が以下になります。 Bot活用事例 具体的な内容はお見せ出来ませんが、関連するナレッジに基づいた内容が返ってきており、回答内の「参照元リンク」をクリックすると、Markdownで整形された読みやすい資料がそのまま表示されました。 検索結果と資料の見やすさが直結している点は、運用上の大きなメリットです。 利用者の声 実際にCS・開発メンバー数名に使用してもらったところ、以下のようなフィードバックが得られました。 調査のヒントとなる情報が得られる あいまいな質問でも関連情報が整理されて表示される ナレッジ検索工数を削減できた 回答文を作成する際の素材集めとして活用できる 現時点では、そのまま回答として使えるレベルではないものの、調査の方向性を掴むには十分有効です。 また、解決のヒントを与えてくれることから、まだサポート業務を行って間もない新人メンバーのオンボーディング支援にも、活用が期待できます。 見えてきた課題と今後の展望 ただ、現場での試験導入を通じて、まだまだ以下のような課題もあることがわかってきました。 回答が微妙にずれていることがある 資料に記載があるはずなのにうまく回答されない 表などの構造化データの読み取りが弱い 検索ワード次第で該当なしとなることも 顧客環境依存の質問には対応が難しい 特に、「資料に記載があるはずなのにうまく回答されない」といったケースは、精度改善の重要なポイントと感じています。 今後は、以下のようなアプローチで改善を進めていく予定です。 学習対象データの選別 　→ ナレッジとなりえそうな情報を全て学習データとしていましたが、ナレッジとして効果の薄いものは対象外とすることで、より的確な回答が得られるよう見直しを検討しています。 学習対象データのファイル分割粒度最適化 　→ 大きなファイルをそのまま扱うのではなく、適度な単位でまとめ直してNotebookLMへ登録することで、より正確に該当情報を引き出せる可能性が高まります。 FAQ形式への変換ルールを整備 　→ ナレッジを単純にMarkdown化するのではなく、「Q:」「A:」などの明示的な構造を定義し、Botが文脈を正確に把握しやすいように整形します。 よくある表現の揺れに対応 　→ ユーザーが使いがちな用語や表現揺れのパターンを収集し、検索しやすい文言への補正やタグ付けを検討中です。 表や表現の多いHTML資料の事前変換 　→ 表組みデータや特殊レイアウトの資料は、事前にプレーンテキストへ変換＋注釈を付加して、構造が壊れないように工夫します。 まずは、「必要なナレッジに迅速かつ確実にアクセスできる」状態を整えることを重視しています。 情報が点在していたり、見つけづらかったりする状況を改善し、必要なときに、迷わず情報にたどり着ける仕組みを整備することで、対応スピードや業務効率の向上を図ります。 こうした積み重ねが、結果としてお客様へのより正確でスピーディーな対応にもつながると考えています。 おわりに 本記事では、「ナレッジはあるのに使えない」というよくある課題に対し、NotebookLMを活用してナレッジ検索Botを構築した実践例をご紹介しました。 蓄積されたナレッジを構造化し、誰もが必要な情報にすぐアクセスできる環境を整えることは、サポート品質の向上にとどまらず、チーム全体の生産性向上にもつながります。 さらに今後は特定のチームにとどめず、他業務への展開も視野に入れながら、ナレッジをもっと有効に活用できる仕組みへと育てていきたいと思います。