はじめに こんにちは。フロントエンド開発課でチームリーダーをしています、北嶋です。 私が所属する開発部では、開発の 「スピード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)

先日、株式会社ラクス主催の技術イベント「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エージェント開発課ですが、プロジェクトの進行や技術的な実装が進展したらまたのブログでもご報告していきます。楽しみにお待ちいただければ幸いです。