はじめに 開発部と事業部では、見ているものが少し違う 開発観点だけで判断を閉じると、議論が進みにくくなる 議論が噛み合わなくなるのは、「必要性」と「実現性」が混ざるとき 要望をそのまま受け取らず、課題として整理する 「やるか・やらないか」ではなく、スコープを分ける 仕様だけでなく、届け方まで含めて考える まとめ はじめに 楽楽勤怠のプロダクトマネジメントをしている @k0First です。 PdMとして仕事をしていると、開発部と事業部の相談MTGで、同じテーマについて話しているはずなのに、少し議論が噛み合わないと感じることがあります。 もちろん、どちらかが間違っているわけではありません。 ただ、議論がうまく前に進まないときは、見ている論点や重視している判断軸が少しずれていることが多いように思います。 そこで、開発部と事業部の相談MTGで扱ってきた相談ごとと、その顛末をまとめたシートをもとに、ChatGPTで内容を整理・分析してみました。 どんな相談があり、最終的にどう着地したのかを振り返りながら、開発部と事業部がそれぞれどのような観点で判断しているのかを見える化した、というイメージです。 その整理を通して見えてきたのが、開発部と事業部では、同じテーマを見ていても重視するポイントが少し違うということでした。 そして、その違いを前提に論点を整理できると、議論はかなり進めやすくなります。 この記事では、シートの分析から見えてきた「開発部と事業部の判断軸の違い」と、そこからPdMとして意識したい論点整理のポイントをまとめます。 開発部と事業部では、見ているものが少し違う 相談内容とその顛末を見返してみると、開発部と事業部では、意思決定の際に重視している観点に違いがありました。 観点 開発部 事業部 基本スタンス 安全に実現できるか 顧客・事業に価値があるか まず見ること 実装難易度、保守性、既存仕様との整合 顧客影響、売上影響、現場運用への効果 重視するリスク 不具合、性能悪化、複雑化、運用事故 顧客混乱、失注、問い合わせ増、周知漏れ 優先順位の付け方 工数対効果、スコープ分割、MVP化 顧客影響度、案件重要度、Must/Better判断 仕様判断の軸 一貫性があるか、例外を増やさないか 現場で説明・運用できるか、売れるか こうして並べてみると、開発部は 実現性・整合性・保守性 を、事業部は 顧客価値・事業インパクト・運用性 を重視していることがわかります。 これは、どちらが正しいという話ではありません。 役割が違えば、自然と重視するものも変わります。 むしろ、この違いがあるからこそ、プロダクトにとって健全な議論ができるとも言えます。 一方で、この違いが言語化されていないまま話し始めると、「なんとなく話が噛み合わない」という感覚だけが残りやすくなります。 PdMとしては、この違いを整理して、議論しやすい形に変換することに価値があると感じています。 開発観点だけで判断を閉じると、議論が進みにくくなる 楽楽勤怠のPdMは開発の近くで仕事をすることが多いため、自然と「安全に作れるか」「既存仕様と矛盾しないか」「保守で困らないか」といった観点で考えやすくなります。 これはとても大事な視点ですし、プロダクトを継続的に育てていくためには欠かせません。 ただ、それだけで判断を閉じてしまうと、事業部が見ている価値が議論から抜け落ちやすくなります。 たとえば、事業部は次のようなことを見ています。 顧客にとって本当に重要か 売上や受注、失注防止にどれくらい効くか 現場で説明しやすいか 運用負荷を下げられるか 周知や移行で混乱が起きないか この観点をどう議論に乗せるかは、PdMの役割のひとつです。 開発部の観点を理解したうえで、事業部が見ている価値も議論の土台に置く。 このひと手間があるだけで、意思決定の納得感はかなり変わります。 議論が噛み合わなくなるのは、「必要性」と「実現性」が混ざるとき シートを見返していて特に多かったのが、必要性と実現性が同時に話されているケースでした。 たとえば、事業部は「顧客に必要だからやりたい」と話しているのに対して、開発部は「そのやり方だと複雑になる」「保守が厳しい」と返す、という場面です。 表面的には反対意見のように見えますが、実際には別の論点を話しているだけ、ということが少なくありません。 そのため、PdMとしては少なくとも次の2つを分けて整理しておくと、議論を前に進めやすくなります。 論点 主な内容 必要性 顧客影響、事業インパクト、売上影響、運用改善効果 実現性 実装難易度、既存仕様との整合、保守性、性能・障害リスク この整理があるだけで、 必要性は高いが、この形だと実現性が低い 実現はできるが、そこまで強い必要性はない といった形で話しやすくなります。 PdMとしては、答えを急いで出すことよりも、まず論点を揃えることのほうが大事だと感じています。 要望をそのまま受け取らず、課題として整理する 相談ごとは、要望や仕様案の形で入ってくることが多いです。 ただ、開発側が本当に知りたいのは「何を作るか」だけではなく、「何を解決したいのか」です。 そのため、PdMとしては要望をそのまま受け渡すのではなく、まず次のような形で整理してから議論に持ち込むようにしています。 誰が困っているのか 何に困っているのか 今はどう回避しているのか Mustなのか、Betterなのか 実現できた場合に何が改善するのか このひと手間があるだけで、開発部は「では別の実現方法もありそうだ」と考えやすくなります。 要望を課題に翻訳することは、PdMが価値を出しやすいポイントのひとつです。 「やるか・やらないか」ではなく、スコープを分ける シートを見返していて、議論が前に進んでいた相談ほど、「全部やるかどうか」ではなく、「どこまでを1stでやるか」が整理されていました。 たとえば、こんな分け方です。 1stリリースで必須のもの あると望ましいが後続でもよいもの 当面は運用回避でしのげるもの 今回はやらないが、将来の検討対象として残すもの この分解があると、開発部にとっては現実的に考えやすくなりますし、事業部にとっても「全部ダメだった」ではなく「何なら今できるか」で話せるようになります。 PdMとしては、この着地点を一緒に探していくことに大きな価値があると思っています。 仕様だけでなく、届け方まで含めて考える 相談の顛末を見ていると、仕様としては成立していても、実際にリリースして現場で回るかまで含めると判断が変わるケースがありました。 たとえば、次のような観点です。 顧客への説明は難しくないか FAQやマニュアル改修は大きくないか CSや導入支援の案内負荷は高くないか UI変更による混乱はないか リリース時期と周知時期は噛み合っているか 「作れること」と「ちゃんと届けられること」は別です。 PdMとしては、この後者まで視野に入れて論点を整理することが、よりよい意思決定につながると考えています。 まとめ 開発部と事業部の相談MTGで扱ってきた相談ごとと顛末を整理してみると、開発部は実現性・整合性・保守性を重視し、事業部は顧客価値・事業インパクト・運用性を重視していることが見えてきました。 PdMとして重要なのは、開発観点だけで判断を閉じないことです。 実現性・整合性・保守性をベースにしながら、事業部ならどう見るかも踏まえて論点を整理することで、議論は前に進めやすくなります。 特に、実務の中では次の4つを意識しています。 要望を課題として整理する 必要性と実現性を分けて考える スコープを分けて提案する 判断材料を揃えて議論に持ち込む 開発部と事業部のあいだで少し噛み合わなさを感じたときこそ、PdMが整理役として価値を出せる場面です。 これからも、こうした違いを前向きに捉えながら、議論を進めやすい形に整えていきたいと思っています。

こんにちは、CTOの公手です。 この4月から、ラクスの新しい中期経営計画がスタートしました。 前中期経営計画の5年間、私たちは「ハイグロース」を掲げ、売上・組織規模ともに約4倍という急成長を遂げました。次なる3年で私たちが目指すのは「クオリティグロース（質の高い成長）」です。AIを駆使して組織をより筋肉質に変え、真の意味で「強い」組織へと進化させるフェーズに入ります。 この方針のもと、次の中期経営計画で開発本部が推進する3つのプロダクト戦略と、それを実現するために不可欠な3つの変革について、簡単ではありますが共有できればと思います。 3つのプロダクト戦略：顧客体験の変革と領域の拡大 1. AI機能実装によるユーザー体験の変革 2. エンタープライズ市場への本格参入 3. 統合型ベストオブブリードへの進化 これらを実現するための3つの変革 AIネイティブ開発プロセスへの変革 クラウドネイティブオンプレミス（CNOP）の強力な推進 グローバルボーダレス開発 変わらない価値観：結局、それを支えるのは「顧客志向」 3つのプロダクト戦略：顧客体験の変革と領域の拡大 1. AI機能実装によるユーザー体験の変革 単なるUIの追加ではなく、AIがユーザーの意図を汲み取り先回りして処理を完結させる 「AIエージェント」 を全主要サービスへ展開します。目指すのは、顧客の業務工数を根本から削減すること。ユーザー操作自体を大幅に削減していく方向へ舵を切ります。また、AIエージェントから利用しやすいようにOpenAPIやMCP（Model Context Protocol）サーバーの展開も進めていきます。必要に応じてAI時代に適した技術刷新を厭わず推進していく方針です。 2. エンタープライズ市場への本格参入 中堅・中小企業市場で培った強みを武器に、大手企業市場へ本格参入します。大規模トラフィックへの耐性、膨大なデータハンドリング、権限管理や監査ログなどの高度なガバナンス要件、エンタープライズ特有の複雑な業務要件に対し、機能レベル、アーキテクチャレベルでもしっかりと対応を強化します。 3. 統合型ベストオブブリードへの進化 楽楽シリーズをさらにシームレスに繋ぎます。前中期経営計画で実現したUI統一や楽楽従業員ポータルの取り組みを、さらに推し進めていきます。従業員ポータルをハブとしたデータ連携を深化させ、顧客が「最高の個別製品（ベストオブブリード）」と「統合された利便性」を同時に享受できる状態を技術的に実現します。 これらを実現するための3つの変革 上記のプロダクト戦略はいずれも難易度が高く、これまでの開発プロセスの延長線上では達成できません。そこで、私たちは以下の3つの変革を断行します。 AIネイティブ開発プロセスへの変革 ここ数年のAI駆動開発の進化はめざましく、単なる補助ツールではなくなりました。すでにラクスでも、チームや機能によってはコード生成率が90％を超える事例が出始めており、平均しても50％程度のコーディング時間の削減は実現できています。しかしながら、生成AIの真価はコーディングの効率化にとどまりません。エンジニア自身がAIの特性と限界を誰よりも理解し、 「生成AIが開発の全プロセス（要件定義、設計、コーディング、テスト、デプロイ）を効率化すること」を前提としたプロセス へと作り変える必要性が出てきています。 まずは、コード生成率を極限まで高め、人間が「ゼロから書く」時間を削減します。これにより、エンジニアの工数を「AIのコントロール」や「より高度な全体設計」、そして「顧客の真の課題解決」へとシフトさせます。AIを活用して開発速度を上げることは、そのまま顧客への価値提供サイクルを速めることに直結します。 クラウドネイティブオンプレミス（CNOP）の強力な推進 私たちが考えるCNOP基盤とは、オンプレミスのコスト効率とパブリッククラウドの技術・思想（コンテナ、K8sなど）を融合させ、高いアジリティを実現するものです。また、パブリッククラウドとのハイブリッド構成も容易にし、ワークロードに応じた最適な環境選択を可能にするものでもあります。 具体的に推進することは、一部のサービスで実現できている、オンプレミスのコストメリットを維持しつつ、Kubernetes（K8s）を中心としたコンテナ基盤運用の全面的な導入です。 さらに、自社製マネージドサービスを構築するなど、パブリッククラウドに匹敵する開発の容易性とリリース速度（アジリティ）の実現を目指します。 自社インフラならではの高品質・高可用性を実現することで、エンタープライズ顧客の高度な要求に応えられるインフラ基盤を提供します。 グローバルボーダレス開発 ラクスには、一つのSaaS企業に匹敵する規模のサービスが複数存在し、サービスの総数は10を超えます。これらのサービス群において、この3つのプロダクト戦略をスピーディに実現するには、必然的に開発ボリュームが増大します。これを国内リソースだけで賄うのは現実的ではなく、海外のエンジニアと「一つのチーム」として機能する体制が不可欠です。 特に、 生成AIの進化により、言語の壁やドメイン知識の壁は劇的に低くなっています 。この技術を最大限に活用し、ベトナムやインドネシアなどの海外拠点を、単なる受託先ではなく、同じ品質基準と設計思想を共有する真のパートナーとして統合していきます。拠点の違いを意識することなく、仕様の同期と開発の加速を可能にする「ボーダレスな共創体制」を実現します。また、多様な視点を持つグローバルな組織力が、この進化の激しい開発現場において、強力な革新性をもって変革を推し進める助けになると考えています。 変わらない価値観：結局、それを支えるのは「顧客志向」 これからの時代、エンジニアの働き方は劇的に変わります。AIネイティブ開発による「超シフトレフト」が進み、技術の自動化が進むほど、エンジニアに求められるのは「何を作るべきか」という判断力と顧客への深い理解です。 ラクスのプロダクトをご利用いただいているのは、日々オフィス業務をこなしている実務担当者の方々です。その方たちが「あ、楽になった」「もっと重要な仕事に時間を使えた」と感じてくれる瞬間のために、私たちは仕事をしています。 どれだけ技術やプロセスが変わろうとも、私たちの根底にある価値観は創業当初から一切ぶれません。それは 「顧客志向」 です。技術はあくまで手段であり、目的は常にお客様のペイン（課題・痛み）を解消することにあります。 このシンプルな原則を胸に、私たちは次の中期経営計画を実現していきます。 今回は概要の説明にとどまり、やや抽象的な内容となりましたが、また機会があれば、それぞれについてより具体的に説明したいと考えています。 AIの台頭に不安を感じる声は、社内でもよく聞かれます。しかし私は、変化の大きい時代だからこそ、「技術の自己目的化を排し、顧客価値を届けることに全力を注げるエンジニア・デザイナー」が最も強いと確信しています。この軸がある人は、どんな新しいツールや手法が出てきても乗りこなせると思っています。ラクスを、そのようなエンジニア・デザイナーが集まる組織にしていきたいと思っています。 まだ完璧ではありませんし、泥臭い課題も山積みです。しかし、その壁を共に壊し、この新しい挑戦に、 一緒に楽しみながら 取り組んでくれる仲間を募集しています。

楽楽明細、楽楽電子保存、楽楽債権管理と複数プロダクトのプロダクトマネジメントを担当しています。 紀井 です。 4月より、この複数プロダクトのプロダクトマネジメントを担う組織の課長に就任しました。所信表明も踏まえて、私がプロダクトマネジメントを意識するようになったきっかけと、今考えていることについてお話しします。 「Whyのない開発」が、私にプロダクトマネジメントを教えた PMFしたら、終わり？違う。そこからが、始まり ラクスのプロダクトマネージャーが目指すこと あなたの原動力は、なんですか？ 最後に 「Whyのない開発」が、私にプロダクトマネジメントを教えた 新卒でエンジニアとしてキャリアをスタートし、プロジェクトマネージャーとして開発を回していた頃、私はずっと「仕様を正確に実現すること」に全力を注いでいました。 品質、コスト、納期。QCDを守ることが仕事だと信じていました。 でも、あるとき気づいたんです。 「なぜこの機能が必要なのか」を誰も説明できないまま、私たちは何ヶ月もかけて開発し、リリースしていた、と。 機能は動く。仕様通りだ。でもユーザーは使っているのか？喜んでいるお客様の顔が、見えない。 仕様通りに作ることは、価値を届けるための手段のはずだった。それがいつしか、目的になっていた。 その事実に気づいたとき、「プロダクトマネジメント」という考え方に興味を持ちました。 2021年にPdMに転身した後は、「Why」を起点にすることを自分の核にしてきました。 インボイス制度対応のような大規模プロジェクトでも、MVPを定義し、「やらないことを決める」ことでチーム全体のリソースを価値に直結させる。 その結果として、お客様の業務が確実に前に進むことを意識してきました。 PMFしたら、終わり？違う。そこからが、始まり この10年、クラウドサービスが業務の当たり前になっていく過程を、最前線で見てきました。 「楽楽精算」が市場に受け入れられ、多くの企業に使われるプロダクトへと成長していく様子を、開発者として、PdMとして、肌身で感じてきました。BtoBプロダクトでシェアNo.1になるというのは、家族や友人、勉強会などで交流した人など、自身の身の回りの人達がプロダクトのユーザーになることが日常になっていきます。街ですれ違う人が、自分が担当するプロダクトのユーザーかもしれない、そんなことを思うようになります。 そんな経験をしながらも、1つ肝に銘じていることがあります。 No.1になっても、解決できていないお客様のペインは、まだ山ほど残っている。 長く使われ続けるプロダクトであるためには、プロダクトマネジメント思考が不可欠です。これは、PdMだけでなく、プロダクト開発に携わるすべての人に必要なものだと思っています。 PMFしたら終わりではない。また新たなフェーズが始まる。 市場も、顧客も、競合も、すべて変わり続けるものです。 ラクスの提供するプロダクトはまだまだ未完成です。 もし「うちのプロダクトは完成されている」と感じているなら、その前提は一度、問い直してみた方がよいでしょう。 AIが業務に溶け込み始めた今、また大きな変化の波が来ています。 「守り」から「攻め」へ。法改正対応から、AIによる業務変革へ。 AIは開発を置き換えるものではなく、お客様の課題の解決を加速させる手段です。 この変化を、チームと一緒に乗りこなしていきたいと考えています。 ラクスのプロダクトマネージャーが目指すこと 顧客・ビジネス・技術、三者の声に等しく向き合い、統合する。 圧倒的な実行力でプロダクトマネジメントを遂行する。 PdMは、誰か一方の代理人であるべきではないと考えています。 エンジニア側の事情をそのままビジネス側に伝えるだけの人でもなく、ビジネスの要望をそのまま開発に渡すだけの人でもない。 顧客の課題を中心に据えながら、ビジネスの論理と技術の現実を、自分の判断で統合できる人間でありたい。 動くものを作る。見せる。試す。 そのサイクルを、AIやツールも使いながら、できる限り速く回す。 そうした動きが自然にできるチームをつくりたいと思っています。 あなたの原動力は、なんですか？ 問題解決を行う手段としてプロダクト開発を生業とするのであれば、スキルと意欲、どちらも大事です。 でも正直に言うと、私が一番気にするのは「原動力」です。 なぜ、プロダクトマネジメントを自分の軸に据えたいのか。 その理由が、自分の中で言語化できている人と一緒に難題を解いていきたい。 「仕様通りに作ったのに、誰にも使われなかった」 「エンジニアとビジネスの間で、何度もすり減った」 「顧客の声が、どこにも届いていないと感じた」 そういう違和感や痛みを、自分の中で放置しなかった人。 複雑な課題に向き合い続けることが難しくなる場面もあります。 原動力はそんな時、踏ん張れる、そして立ち上がる一歩を助けてくれると思っています。 最後に プロダクトマネージャーを募集しています。 ラクスの提供するプロダクトは、まだまだ未完成です。 だからこそ、一緒に磨き続けてくれる方と出会いたいと思っています。 少しでも興味を持たれた方はこちらもどうぞ！ note.com

こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） tech-blog.rakus.co.jp 2027年3月期の初日ということで、自組織でもキックオフMTGを先月実施しました。プロダクト部が組成されてちょうど1年経ちましたので、昨年度の振り返りと今期の取り組みや今後とその先について、今考えていることをまとめてみました。 ※本記事は、プロダクト部の取り組みを紹介する目的で、執筆時点の考えを整理したものです。状況や学びに応じて、方針や進め方はアップデートしていきます。 2026年3月期の振り返り（確かな歩みと見えてきた本質） 組織強化という「Good」な成果 「More」から見えた本質的な課題：製品貢献度確認アンケートの真意 下期表彰：進化を体現したメンバーたち 次中期方針（変わらない軸と、目指すべき組織の姿） プロダクト部のMissionとVision 戦略ゴールのポイント 組織として目指すべき状態：全メンバーの上流への染み出し 【プロダクト部】役割/責務/活動領域と「UX志向の行動」 2027年3月期上期 重点取り組み事項（進化を加速させるアクション） スローガン：「一言」でまとめると 組織体制の大枠 各役割で重要視する「AI×上流シフト」 実現を目指す3つのプロダクト戦略 2026年3月期の振り返り（確かな歩みと見えてきた本質） まずは直近1年間の振り返りです。組織としての成長と、次へ向かうための課題が明確になった期間でした。 組織強化という「Good」な成果 昨年度の最も大きな成果は、なんといっても組織の基盤が強固になったことです。プロダクト部は現在、30名を超える組織へと拡大し、デザイナー、プロダクトマネージャー（PdM）ともに大幅な増員と組織強化を実現することができました。マネジメントやリーダー、シニア層も複数名増え、体制がより盤石になってきています。 この成長は決して自然に起こったものではありません。各マネージャーの献身的な頑張りはもちろんのこと、現場のメンバー一人ひとりが採用活動や社外への発信に積極的に協力してくれた結果です。チーム全員で組織を創り上げているという実感があり、この場を借りてメンバー全員に心からの感謝を伝えたいと思います。 また、スキルや役割の面でも良い変化が起きています。デザイナーはより深いUXの領域へ、PdMはプロダクト戦略やPMM（プロダクトマーケティングマネージャー）の領域へと、それぞれが「上流への領域染み出し」を順調に進めてくれています。単なる「作る人」から「価値を定義し、届ける人」へと、組織全体の意識が確実に変化してきているのを感じています。 「More」から見えた本質的な課題：製品貢献度確認アンケートの真意 一方で、課題（More）も明確になりました。私たちが定期的に実施している「製品貢献度確認アンケート」において、改善傾向は見られた一方で、まだ伸びしろもあります。ただ、点数以上に“定性の声”から重要な示唆が得られました。 ※このアンケートは、点数そのものを結論にするのではなく、「なぜそう感じたのか」の背景（自由記述）から論点を抽出するために活用しています。 メンバーの声を分析すると、全員が「上流工程からの参画」「一次情報の獲得（顧客や営業・CSの声）」「リリース後の効果検証」を強く求めていることがわかりました。これは「もっと手前の課題定義から関わりたい」「自分が作ったものがどう役立っているのかを知りたい」という、非常に健全で高いモチベーションの表れです。 裏を返せば、要件の解像度を早い段階で揃えきれないまま開発に入ってしまうケースがあり、協働の難易度が上がることがありました。これは個人の能力ではなく、プロセス設計で改善できる課題だと捉えています。貢献実感が得られるのは「偶発的にフィードバックが得られた時」に限られてしまっています。これは個人の能力の問題ではなく、プロセスや仕組みの問題です。メンバーが「もっと製品の成長に寄与したい」と熱望しているからこそ、このアンケート結果は組織が次に乗り越えるべき「プロセス改革」という本質的な課題を浮き彫りにしてくれました。 下期表彰：進化を体現したメンバーたち このような環境下でも、圧倒的な成果を出してくれたメンバーがいます。 2名の成果をピックアップします。 ■AI推進の体現者（シニアPdMメンバー） 一人目は、シニアPdMメンバーによる「AI推進」の圧倒的な成果です。 そのメンバーはバイブコーディング（生成AIを活用したプロトタイピング／実装支援）を活用し、「顧客価値の早期検証」と「AIによる営業DX」を見事に両立させました。自律的なプロトタイプ開発を短期間で行い、開発着手前の仮説検証（ディスカバリー）を強力に主導しました。さらに、属人化していた商談ノウハウをAIで可視化・型化し、組織全体の提案スキルを底上げする仕組みまで構築しました。 ビジネスインパクトとプロダクト成長の両面で、まさに私たちが目指すPdMの理想形を体現してくれました。 ■スピードUPの体現者（新卒入社の1年目のデザイナー） 二人目は、新卒で入社して間もないデザイナーによる「スピードUP」への多大な貢献です。 そのメンバーはリリースプロセスの効率化と自動化に果敢に取り組みました。動作確認シナリオの見直しや、並列アップデート化、監視の自動化などを推進し、結果としてマイナーリリース作業全体にかかる時間を約半分まで削減するという驚異的な成果を叩き出しました。 入社年次に関わらず、自らの視点で課題を発見し、プロセスそのものを変革する行動力は、組織全体に大きな刺激を与えてくれました。 次中期方針（変わらない軸と、目指すべき組織の姿） ここからは未来のお話です。2026年4月から2029年3月末までの次の中期方針についてです。 プロダクト部のMissionとVision 次の中期に向けてはこのようなMissionとVisionを掲げています。 Mission： 「プロダクトの機能と活用の価値創出に責任を持つ」 Vision： 「プロダクト連携とAI搭載でプロダクト価値を向上させ、売上成長に直接貢献する」 役割と責務や活動領域についてはこれまで変更はありません。 ※ The Product Management Triangle Posted by Dan Schmidt , Product Logic ラクスのプロダクト部向けにカスタマイズ 戦略ゴールのポイント 2029年3月末に向けてのゴールにおいて、具体的な数値はここでは割愛しますが、重要なポイントは以下の3点に集約されます。 プロダクト間連携の推進 ：単体のシステムではなく、シリーズ全体でお客様の業務を滑らかに繋ぐ体験を提供します。具体的には二重入力や部門間の手戻りが減り、日々のオペレーションが滑らかになると考えています エンタープライズ（大口）顧客向け機能の強化 ：主要サービスにおいて、より大規模で複雑な要件を持つお客様にも満足いただける機能と改善を実現します。 プロダクトへのAI搭載 ：AIを特別なものではなく、当たり前の機能として各プロダクトに組み込み、お客様の業務効率を飛躍的に高めます。 ※詳細は 2026年2月13日 2026年3月期第3四半期決算説明資料 「P.42 次期中計に向けた成長戦略」 を参照ください 組織として目指すべき状態：全メンバーの上流への染み出し これらの戦略を実現するためには、組織のあり方そのものを進化させる必要があります。私たちが目指すのは、以下の状態です。 ※これもプロダクト部 組成時から掲げている ものと変わりはなし まず、 プロダクト戦略の策定と、その実行（戦術）を主導できている状態 です。これは、事業部から降りてきた要件をただ形にするのではなく、デザイナーやPdMが戦略策定の初期段階から関与し、開発組織としての専門的な知見を方針に反映させることを意味します。 次に、 製品に対する「解像度」が全社の中で最も高い状態 です。営業やCSからのまた聞きではなく、自らお客様にインタビューを行い、一次情報を獲得することで、自分の言葉で顧客の課題を言語化できる組織になります。 そして何より、 プロダクト部の全員が製品の成長に寄与していると心から実感できる状態 を作ります。定性・定量の両面から、自分の仕事がどう売上や顧客満足度に繋がったかを語れる環境を整備します。 【プロダクト部】役割/責務/活動領域と「UX志向の行動」 プロダクト部は、第一開発統括部のプロダクトマネジメントと、ラクス全体のプロダクトデザインを担うという非常に重要な役割を持っています。私たちの責務は、社内外の関係者と連携し、製品価値を創出・提供し続けることで、お客様の満足と利益を生み出す「循環」を創ることです。そのために最も重要な行動指針が「UX志向の行動」です。 これは継続して変わらない私たちのコアバリューですが、改めて強調させてください。最高のUXを提供するためには、自身の役割や立場にとらわれてはいけません。 顕在化しているニーズをファクトに基づいて把握することは当然として、市場や競合の動向、そして未来の潜在的なニーズに対しても、仮説検証を繰り返して不確実性に挑戦していく姿勢が求められます。安易なトレードオフ（二者択一）に逃げるのではなく、短期的な成果と中長期的な価値の両立（AND）を泥臭く模索し続けること。これこそが、私たちが体現すべきプロフェッショナリズムです。 2027年3月期上期 重点取り組み事項（進化を加速させるアクション） 最後に、今期（2027年3月期上期）の具体的な重点取り組みについてお話しします。 スローガン：「一言」でまとめると 今期の私たちのスタンスは、この一言に尽きます。 「『確かな手応え』と『スピード感』を持ってのプロダクト強化 〜早く価値のあるものを提供します〜」 どんなに素晴らしい戦略も、スピードが伴わなければ意味がありません。お客様が今直面している課題に対して、最速で価値を届け、かつ「それが本当に役立っているか」という確かな手応え（検証とフィードバック）を得ながら進んでいく。これが今期のテーマです。 ここで言う「スピード」は、作業を急ぐことではなく、お客様の課題仮説を置いてから価値検証までのリードタイムを短くすることです。早く届けるほど学びが増えますが、同時に品質リスクも増えます。だからこそ私たちは、検証サイクルを速めつつ、品質を落とさないための仕組み（テスト/監視/レビュー）もセットで強化します。「早い」と「確かな手応え」を両立させる。これが今期のテーマです。 組織体制の大枠 このスローガンを実現するために、組織体制もアップデートします。プロダクトマネジメント課とプロダクトデザイン課をそれぞれ複数課（1課・2課）の体制とし、専門性とアジリティを高めます。現在30名超の組織ですが、今期は体制をさらに拡充しつつ、体制が大きくなってもスピード感を失わないよう、権限委譲と各課の自律的な運営を推進していきます。 各役割で重要視する「AI×上流シフト」 今期、各役割において特に重要視し、徹底的に強化したいのが以下の2点です。 ■デザイナー：デザインガイドライン×AIで業務の中心をPdM領域へ デザイナーには、単なるUIの作成から「体験の設計者」へと完全にシフトしてもらいます。私たちの社内のデザインガイドラインとAIツール（例：Cursor/Claude等）を掛け合わせることで、UIモックアップの作成などの作業工数を劇的に削減します。そして、そこで浮いたリソースの全てを、UXリサーチ、顧客インタビュー、そしてPdM領域（課題定義や要求整理）への染み出しに投資します。AIを駆使することで、デザイナーが事業の意思決定のど真ん中に立つ組織を作ります。 ※AI活用の基本的な前提 AIの出力は“たたき台”として扱い、最終判断・対外説明は必ず人が責任を持ちます。 個人情報／顧客情報／機密情報は入力しません（必要な場合は匿名化・要約して扱います）。 仕様やリサーチの結論は、一次情報や根拠と突合してから採用します。 ■プロダクトマネージャー：PdM×AIでGTMを前提にしたディスカバリーとソリューション提案 PdMには、仕様を決めるだけでなく「どう市場に届けるか」までを担うPMM（プロダクトマーケティング）の視点を強く求めます。ここでもAIを徹底活用し、PRD（要求仕様書）の作成や仕様検討プロセスを「型化」して圧倒的なスピードアップを図ります。その上で、GTM（Go-to-Market）を前提とした仮説検証（ディスカバリー）を行い、プロダクト開発にとどまらない広範なソリューション提案でお客様の課題解決をリードしてもらいます。 ※PRD生成は「早く書くこと」自体が目的ではなく、論点の抜け漏れを減らし、仮説検証を速く回すための補助線として使います。AIの提案が置いている前提や根拠が妥当かは、必ず一定レベルの人がレビューします。 実現を目指す3つのプロダクト戦略 デザイナーとPdMが上記のようにAIを武器にして上流へとシフトし、組織としての力を最大化した上で、私たちは以下の3つの大きなプロダクト戦略の実現を目指します。 1. 「エンタープライズ（大口）領域の強化」 （企業が大きくなっても長く利用し続けてもらえるプロダクトへ） 私たちのプロダクトを導入してくださったお客様が、事業を成長させ、企業規模が大きくなったとしても「やっぱりこのシステムを使い続けたい」と思っていただける深い価値を提供します。複雑な権限設定や大規模なデータ処理など、エンタープライズならではの高い要求水準に応えるプロダクトへと進化させます。 2. 「プロダクトへのAI標準搭載及びAIからも利用されるプロダクトへ」 AIはもはや特別な機能ではなく、インフラです。ここで言う「AI」は魔法の自動化ではなく、入力補助・要約・確認などの“細かな手間”を減らして、ユーザーが本来向き合うべき業務に集中できる状態を作るための道具だと捉えています。一方で、生成AIには誤りや意図しない出力のリスクもあるため、業務影響が大きい領域ほど「人の最終確認」「権限」「監査」を前提に、段階的に適用範囲を広げていきます。 プロダクト内にAIを標準搭載し、入力補助・要約・確認など日々の“細かな手間”を減らすことで、お客様が本来向き合うべき仕事に集中できる状態を作ります。さらに将来的には、私たちのプロダクト自体が外部のAIアシスタント／AIエージェントから安全に呼び出され、業務の流れに自然に組み込まれる存在（API化・MCP化）になることも見据えています。そのために、権限管理・監査ログ・レート制限など、エンタープライズ品質のガードレールを前提に設計していきます。また、API化・MCP化は“将来的な方向性”であり、お客様のセキュリティ要件や運用実態を踏まえて検証しながら進めます。 　※MCP（Model Context Protocol）は、AIと外部データ／ツールをつなぐための共通規格の一つで、AIエージェントが外部システムを安全に呼び出すためのインターフェースを標準化する動きです 3. 「統合型ベストオブブリード戦略」 （プロダクト間連携によるお客様の便益や価値向上） 単一の優れたプロダクト（ベストオブブリード）を提供するだけでなく、それらがシームレスに連携し合う「統合された体験」を提供します。例えば、あるプロダクトで入力したデータが自動的に別のプロダクトに反映されるなど、システム間の摩擦を極限まで減らし、お客様の業務全体の生産性を飛躍的に向上させます。 おわりに プロダクト部が立ち上がってからの1年間は、ゼロから基盤を作り上げる激動の期間でした。そしてこれからの1年は、その基盤の上に「確かな手応え」と「圧倒的なスピード感」をもって、市場に大きな価値を打ち出していくフェーズになります。 私たちには優秀なデザイナーとPdMが揃っており、さらにAIという強力な武器があります。全員が上流に染み出し、顧客の一次情報に触れながら、最高のUXを追求していく。このプロセスを妥協なくやり抜くことで、日本のクラウドサービスで存在感を高められるよう、挑戦を続けていきます。今のラクスでのプロダクト開発は最高に刺激的で面白いフェーズにあります。これからのプロダクト部の挑戦に、ぜひご期待ください。 私たちと一緒に、数年後、数十年後も顧客に愛され、価値を残し続ける最高のプロダクトを作りませんか？ 皆さんとお話しできる日を、心から楽しみにしています。本記事を読んで興味を持たれた方は、まずはカジュアル面談からご応募ください。 career-recruit.rakus.co.jp

2026年1月、株式会社ラクスに技術広報として入社した髙須賀（たかすか）と申します。 早いもので入社から3か月が経過しました。新年度という区切りを迎え、これまでの振り返りと、これから私たちが目指す姿についてお伝えできればと思います。 1. 自己紹介 2. ラクスの開発組織の魅力について 3. 入社後の取り組みについて ヒアリングと施策立案 顧客志向表彰の実施 ブログの執筆 社内向け記事の執筆 商談動画のまとめ その他 4. 今後の展望：発信を楽にする環境づくり 5. おわりに 1. 自己紹介 私自身はエンジニアとしての経験はありませんが、前職ではITエンジニア向けの技術イベントの企画・運営に従事していました。 当時から大切にしているのは、「ITエンジニアの皆さんと共通言語で会話ができるようにすること」です。 IPA試験の受験、技術書、社外の技術イベントへの参加などを通して技術への理解を深めてきました。 ラクスの技術広報となった今、より深く自社の技術スタックを理解する必要性を感じており、日々学習を続けています。 2. ラクスの開発組織の魅力について 技術広報の重要なミッションの一つは、自社の開発組織の魅力を外部に伝えることです。ここでは、私が実際に勤務して感じたラクスの魅力をご紹介します。 最大の特長は、徹底した顧客志向です。 ラクスではあらゆる役割のメンバーがお客様への価値提供に向けて日々業務に取り組んでいます。 開発組織は主に技術の力を使って価値を生み出しますが、ラクスでは常に「それはお客様のためになるか」を重要な判断軸に置いています。そのため、自分たちの書いたコードが企業の成長を支え、そこで働く方々を「楽」にしているという実感を強く持つことができます。 「楽楽精算」や「楽楽明細」をはじめとするサービスでお客様の業務の課題を解決し、社会の効率化に貢献したい。そんな技術の社会実装に喜びを感じるエンジニアにとって、ラクスの環境は非常に魅力的だと感じています。 3. 入社後の取り組みについて この3か月間、現状の把握と改善に向けて、社内外で様々な施策を実行してきました。 ヒアリングと施策立案 この3か月を通して数十名の社員の方にインタビューをさせていただき、現状感じている課題などをヒアリングいたしました。このインタビューやアンケートの結果をもとに、組織全体をよりよくするための戦略を立てました。 顧客志向表彰の実施 「今期、特に顧客志向を体現した事例は何か？」を開発組織の全管理職から推薦いただき、投票・表彰するイベントを実施しました。 今後も素晴らしい事例が埋もれず、組織の誇りとして可視化される仕組みを目指しています。 ブログの執筆 RAKUS AI Meetup Vol.2のレポート 社内テックカンファレンスのレポート tech-blog.rakus.co.jp 社内向け記事の執筆 開発統括部長へのインタビュー記事 他部門との情報交換会レポート3本 商談動画のまとめ 開発メンバーがお客様への理解をより深められるよう、顧客のリアルな声が分かる商談動画のアーカイブや営業資料、顧客満足度調査などを一箇所に集約・共有しました。 その他 社内交流イベント「ビアバッシュ」の企画運営、エンジニア情報ポータルサイトの更新、外部登壇の支援、社外向けアンケートや社内向けアンケートの集計・分析、生成AIを用いた業務効率化などを実施しました。 career-recruit.rakus.co.jp 4. 今後の展望：発信を楽にする環境づくり 今後は、ラクスの開発組織の強みをさらに高い解像度で整理し、一貫性のあるメッセージとして社内外へ浸透させていきます。なかでも、着実に実績が増えているAI活用の取り組みについては今後力強く発信していく予定です。 情報発信においては、エンジニアの皆さんの力が不可欠です。しかし、日々の開発業務と並行して技術発信を行うことは決して簡単ではありません。 だからこそ、アウトプットしやすい環境を整備し、組織全体の技術発信のハードルを下げ、発信活動そのものを「楽」にしていきます。 また、私自身もブログなどのオンライン施策にとどまらず、オフラインの技術イベントへの参加回数を増やし、コミュニティにおけるラクスの存在感を高めていきたいと考えています。 5. おわりに 技術広報のミッションは、単なる情報発信ではありません。 エンジニア組織の価値を最大化し、その結果として、お客様により良い価値が届くサイクルを加速させることだと思います。 これまでの知見をもとに、ラクス開発組織の魅力をしっかり届けていきます。 イベントや勉強会の会場で見かけた際は、ぜひお気軽に声をかけていただけると嬉しいです。 皆さま、これからどうぞよろしくお願いいたします！

こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） tech-blog.rakus.co.jp デザイナーとプロダクトマネージャー（PdM）が同じ組織になってもうすぐ1年が経ちますので、その挑戦、苦労、変化について書こうと思います。ラクスは3月末決算のため4月には来期に向けて取り組みを書こうと思いますが本記事は厚めに振り返ります。 組織図を書き換え、デザインを解放する なぜ統合が必要だったのか：「上流×一次情報×検証」が欠けると、協働は痩せていく デザインの再定義：それは「問題を解決するための設計」である 壁を壊すだけでは足りない：一次情報・意思決定・効果検証を「仕組み」にする プロセスの磨き込みが、思考の余白を生む（AIは黒子） PdMとデザイナーの共鳴：信頼が戦略を加速させる UX志向のガードレール：越境は「自由」ではなく「責任」 リアルな壁：未経験の荒野と「固定観念」との戦い（アンケートで見えた“本質”） おわりに：各自が「＋1」の越境を止めない 組織図を書き換え、デザインを解放する 「デザイナーとプロダクトマネージャー（PdM）を、同じ組織にする。」 この決断は、単なる管理上の変更ではありませんでした。 それは、プロダクト開発における「役割」という名の聖域を取り払い、全員が「ユーザー価値」という一点に向き合うための、静かな、けれど野心的な挑戦の始まりでした。 これまでのラクスの開発現場では、「仕様を作る人（PdM）」と「形にする人（デザイナー）」という分断が、あたかも効率的な分業であるかのように受け入れられてきました。 しかし、その境界線はときに、情報の劣化や責任の押し付け合いを生む「見えない壁」となって立ちはだかります。 この1年で私たちが目指したのは、デザインを「UI（見た目）を整える業務」から、「事業課題を解決するための設計・計画全般」へと解放すること。 その決断が、いかにしてプロダクトの質と、チームの魂を変えていったのか。今、私たちが感じている「統合の真の価値」を言語化してみたいと思います。 なぜ統合が必要だったのか：「上流×一次情報×検証」が欠けると、協働は痩せていく 先に結論を言うと、統合は“仲良くするため”ではありません。 プロダクト開発に必要な情報と責任が、上流から検証まで一本で繋がる状態 をつくるためでした。 私たちが日々向き合うプロダクト開発は、不確実性の塊です。だからこそ、チームが手応えを感じる瞬間は、完成した成果物そのものよりも、 不確実性が下がった 意思決定が前に進んだ 手戻りや無駄が減った リリース後の反応が見えた ……といった「前に進んだ感覚」に宿ります。 逆に言えば、一次情報に触れられず、上流での仮説設計に関われず、リリース後の効果検証も回らない状態だと、仕事は“調整と吸収”に寄り、協働は痩せていく。 これは個人の能力の問題というより、フィードバック周期が長すぎる設計のサインでした。 だから私たちは、役割の境界線を越える前に、まず 「上流×一次情報×検証」を“チームの標準装備”にする方向へ舵を切りました。 デザインの再定義：それは「問題を解決するための設計」である かつて、デザイナーの仕事の主戦場は「画面の中（UI）」でした。 しかし今、私たちの組織ではその定義が劇的に変わりつつあります。 デザインとは、ユーザーの深層にある痛みを見つけ出し、それを解決するための「設計・計画」そのものです。 この定義の変化を象徴するのが、デザイナーによる「UX領域への染み出し」です。 デザイナーが自らユーザーインタビューの場を設計し、実査を主導する。そこで得た生々しい一次情報をもとに、PdMと肩を並べて「この機能は本当にユーザーのためになるのか？」という本質的な議論を戦わせる。 デザイナーが「体験の責任者」として上流から関わることで、プロダクトの骨格は以前よりもずっと強固になりました。単に「使いやすい画面」を作るのではなく、「なぜそれを作るのか」という問いに対して、デザインの観点から明確な解を持つようになったのです。 そして何より、ここで重要なのは“美しい理想論”ではなく、 顧客価値に直結する現実 です。 インタビューで課題設定がズレていることが分かり、手戻りを未然に防げた。あるいは、現場の声を根拠に提案が通り、商談上の不安材料を消せた。そういう小さな勝利の積み重ねが、プロダクトの勝率を静かに上げていきました。 壁を壊すだけでは足りない：一次情報・意思決定・効果検証を「仕組み」にする 統合して気づいたのは、組織図を変えただけでは、人は簡単に変わらないということです。 必要なのは「気合」ではなく、 情報と責任の流れを変える仕組み だと思っています。 私たちが意識して整えているのは、大きく3つです。 1) 一次情報を“取りに行く”のを、当たり前にする 顧客・営業・CS・現場の声は、伝言ゲームを経由した瞬間に痩せていきます。だからこそ、一次情報に触れることを「一部の職種の仕事」から、「チームの呼吸」へ。デザイナーもPdMも、必要なら自分で取りに行く。その姿勢をチームの文化として育てています。 2) 上流から入る（要求の背景と検討経緯を共有する） 「要求が遅い・曖昧」を開発側が吸収して納期を守る構造は、短期的には優しい。でも長期的には、品質・士気・優先順位付けを劣化させます。そこで、要求の背景（なぜ今これが必要なのか）や検討経緯（なぜこの案を選んだのか）を、できるだけチームに残す。意思決定の“証跡”を共有する。これだけで、同じ議論を何度も繰り返す無駄が減り、腹落ちの深さが変わっていきます。 3) リリース後の効果検証を“デフォルト”にする 作って終わりにしない。 KPIの推移だけでなく、VOCや現場の反応も含めて、どんな変化が起きたのかを回収し、次の意思決定に繋げる。 ここが回り始めると、チームは「前に進んだ感覚」を取り戻し、協働の質が一段上がります。（ここはまだまだできていないことが多い） プロセスの磨き込みが、思考の余白を生む（AIは黒子） もちろん、デザイナーが上流工程に染み出すためには、これまでの業務をどこかで効率化しなければなりません。そこで私たちは、制作プロセスに工夫を凝らそうとしています。 UI制作における細かなルーチンワークや共通パーツの管理、さらにはインタビュー後の膨大な文字起こしや情報の整理といった「作業」の部分に、最新のテクノロジーやAIを黒子として組み込もうとしています。 目的は、デザイナーを「作業」から解放し、その脳を「思考」へとシフトさせることです。 この実現のために「デザインガイドライン」の策定と浸透は重要な役割を担っています。（デザインガイドラインの苦労は以下のnoteをご覧ください） note.com note.com 浮いた時間で、デザイナーはユーザーの隣に座り、感情の機微を読み取る。そして、そのインサイトを戦略へと昇華させる。技術によって生み出された「余白」が、皮肉にも私たちの開発プロセスをより人間中心（ヒューマンセンタード）なものへと変えていければよいなと思います。 PdMとデザイナーの共鳴：信頼が戦略を加速させる この体制が生んだ最大の資産は、PdMとデザイナーの間に生まれた「深い信頼の土壌」です。 デザイナーがUXの解像度を究極まで高め、現場をリードしてくれる。その確信があるからこそ、PdMは現場の細部をデザイナーに「預ける」ことができるように少しずつなってきています。 これはPdMにとって、単なるタスクの委譲ではありません。UXの重責をパートナーに託したことで、PdMは自身の専門領域である「プロダクト戦略」や「GTM（市場投入戦略）」など、事業成長に直結するマクロな動きに全神経を注げるようにするためです。 この「相互の越境」は、目に見える実績としても現れ始めています。 複数サービス利用推進の加速：デザイナーが横断組織になったことで、サービス間の垣根を超えたデザインガイドラインが浸透 コミュニケーションの高速化：別組織ゆえの「合意形成のための儀式」が消え、価値を「ツクル→伝える」までのスピードが上がった ここで大事なのは、スピードそのものではなく、スピードが生む“余白”です。余白があるから、仮説検証ができる。一次情報に触れられる。効果検証まで責任を持てる。結果として、プロダクトが「説明できる意思」を持ちはじめます。 UX志向のガードレール：越境は「自由」ではなく「責任」 一方で、越境は万能薬でもありません。 境界線を溶かすほど、意思決定が曖昧になったり、声の大きい人が勝ったりする危険もあります。だからこそ、私たちは「UX志向」を 行動原則（ガードレール） として明文化し、何度もすり合わせました。たとえば、 製品の本質的価値から逆算して行動する 事実（ファクト）に基づき、仮説検証を繰り返す 提供したUXへのフィードバックを収集し、改善に繋げる 短期と中長期をORにせず、ANDで両立する道を探す ステークホルダーに敬意を払い、説明責任を果たす そして同時に、「やらないこと」も決めます。憶測だけで決めない。フィードバックを放置しない。政治や保身を優先しない。 この“当たり前”を言語化しておくことで、越境は「自由」ではなく「責任」として機能し始めます。 リアルな壁：未経験の荒野と「固定観念」との戦い（アンケートで見えた“本質”） しかし、理想ばかりを語るわけにはいきません。現在進行形の課題も山積みです。 まず、UXを深く担った経験のあるデザイナーはまだ少数派です。UIという安全圏を抜け出し、正解のない「戦略や設計」に踏み込むのは、想像以上に怖いし、体力も要ります。 ここで半期ごとに実施している「製品貢献実感」のアンケートが、壁の正体をはっきり映しました。貢献実感が強い瞬間は、成果物そのものよりも「前に進めた感覚」——認識齟齬を潰して手戻りを減らせた、意思決定が進んだ、リリース後の反応が見えた、といった場面に集まりやすい。逆に言うと、 一次情報に触れられない／上流に入れない／効果検証まで見えない 状態が続くほど、貢献実感は痩せていきます。これは個人の能力ではなく、フィードバック周期が長い（設計されていない）ことが原因になりがちです。 さらに厄介なのが固定観念です。「デザイナー＝UIを作る人」「PdM＝要望を捌く人」という見え方が残ると、一次情報や検証に踏み込もうとした瞬間に、善意の期待で引き戻されます——「いいから早く画面を」「まずは間に合わせて」。 だから私たちは、気合ではなく仕組みで解くことにしました。一次情報・意思決定の背景・効果検証を“標準装備”にし、小さくても「前に進んだ証拠」が返ってくるループを短く回す。固定観念は議論で倒すより、 実績で上書き するほうが早い。未経験の荒野と戦う鍵は、個人の頑張りではなく「前進が可視化される設計」にあると感じています。 おわりに：各自が「＋1」の越境を止めない 私たちが目指すのは、職能というラベルに縛られない、真のプロフェッショナル集団です。 デザイナーはより戦略的に、PdMはより体験に寄り添う。それぞれが自分の領域から「＋1」の越境を続けることで、プロダクトには強い「意志」が宿ります。 組織図の壁を壊し、デザインを解放した先に見える景色。それは、作り手が誰よりもプロダクトの可能性を信じ、楽しみながら価値を生み出し続ける、そんな組織の姿です。私たちの挑戦は、まだ始まったばかりです。 記事を読んでラクスのプロダクト部に興味を持ってくださった デザイナー／PdM の方 は、ぜひカジュアル面談からご応募ください。 ※プロダクトマネージャーのカジュアル面談は、基本的に私（稲垣）が担当します！ ●採用情報 プロダクトマネージャー career-recruit.rakus.co.jp デザイナー https://career-recruit.rakus.co.jp/engineer_jobs/uidesigner_tokyo/ career-recruit.rakus.co.jp

こんにちは、ラクスの技術広報です。 2026年2月20日（金）、ラクスの社内テックカンファレンス「Rakus Tech Conference for Us 2026」 を開催いたしました。 組織が拡大し、それぞれのプロダクトや職種の専門性が高まる中で、いかに「横の繋がり」を強め、新たな価値を生み出すか。熱気に包まれた当日の様子をレポートします。 開催の背景とテーマ：『Synergies』（シナジー） 多彩な8セッション：技術の先にある「協働」を語る 発表内容 【セッションラインナップ】 イベント後に寄せられた感想（抜粋） アフターイベント：東京・大阪の2拠点で同時開催 開催を終えて 開催の背景とテーマ：『Synergies』（シナジー） 今年のカンファレンスのテーマは 『Synergies』（シナジー） 。 コンセプトとして 「境界を越え、相乗効果を生み出す」 を掲げました。 現在、ラクスでは『楽楽精算』や『楽楽明細』をはじめとする数多くのプロダクトを展開しています。事業の拡大に伴い、多様な技術スタックや専門知が組織内に着実に蓄積されているという手応えがある一方、組織が大きくなるにつれ、隣のチームの知見が届きにくくなるリスクも大きくなっていました。 そこで、エンジニア、PdM、デザイナー、SRE、QAといった職種の壁、そしてプロダクトの壁を越えて進められた 実プロジェクトの成果や知見を共有し、 互いの強みを知り、頼り合える関係性をさらに広げる場として、本カンファレンスを企画しました。 多彩な8セッション：技術の先にある「協働」を語る 本編では、合計8つのプロダクトチームから登壇者が集結しました。 今回の発表基準は、単なる技術解説に留まらず、 「Context & Collaboration（背景と連携）」 に焦点を当てることです。 発表内容 今回のテーマである職種の壁を越えたシナジーを軸に、顧客志向、スピードアップを体現した素晴らしい事例が共有されました！ どのセッションも、「自分たちの業務にも活かせそう！」「あのチームのあの人に後で詳しく聞きに行こう」と思わせる、実践的な知見が詰まった内容でした。 さらに、今回は「AIネイティブ」な開発姿勢を象徴する事例も数多く共有されました。 AIツールを前提とした開発フローの最適化や、プロダクトへのAI組み込みにおける試行錯誤など、AIをエンジニアの強力なパートナーとして使いこなすための具体的なナレッジが飛び交っていたのが非常に印象的でした。 【セッションラインナップ】 ※公開にあたり、一部タイトルを調整しています。 ウォーターフォール開発からアジャイル開発へ～○○案件の知見共有 「1機能」から変える。○○が○○を呼び起こす「○○」の始まり 「楽楽債権管理」開発スピードUPのために、○○と○○を変えてみた 「楽楽販売」 ○○プロジェクト：デザイナーと開発者の協業モデル 「楽楽明細」○○機能開発 挑戦と学びの記録 「楽楽請求」への○○導入の裏側 〜SREチームが支える社内プラットフォーム〜 「阿吽の呼吸」をアップデートせよ。10人の壁を越え、チーム全員で「○○」を共有する挑戦 ○○を振り切る。社内資産を活かして辿り着いた、最速の新機能開発 イベント後に寄せられた感想（抜粋） 他のプロダクト開発チームが直面している課題やその解決の取り組みについて、生々しい情報を解像度高く得られ、大変有意義でした。 担当中のプロジェクトの課題に対して、解決策のヒントを得ることができました。 同じような悩みを抱えてるなという部分と、商材が変わるとそんな苦労があるのか！という発見があった 既存の枠組みに囚われないチャレンジの重要性を認識した。 アフターイベント：東京・大阪の2拠点で同時開催 カンファレンス終了後は東京拠点と大阪拠点でビデオ会議でつないでアフターパーティを開催！ 「Ask the Speaker」 ブースでは、登壇者を囲んでさらに深い技術議論や裏話が交わされ、耳までチーズが入ったピザやビールを片手に部署を越えた交流が夜まで続きました。 開催を終えて ラクスでは、こうした社内交流を通じて、個々の技術力だけでなく、組織としての解決力を高める文化を大切にしています。 今回の『Synergies』で生まれた繋がりが、より高速で高品質な価値をお客様に届けるためのエンジンとなり、今後のプロダクト開発において大きな相乗効果を生み出すことを確信しています。

目次 目次 0. はじめに 1. レビューされる側だった頃の問題点 2. レビューと設計の関係性 2.1 なぜレビューが必要なのか 2.2 なぜ「設計」が関係するのか 3. コードレビュー指摘の傾向から学んだこと 3.1. 様々な設計原則 3.2. 設計指摘を具体的に理解する 3.3. 設計指摘をものにするためには？ 4. before / after で見る設計指摘の具体例 4.1. SRP: 「責務が多い」と言われたケース before: 1つのクラスに複数の責務がある after: 責務ごとに分離する 4.2. OCP: 「将来増えそう」と言われたケース before: 条件分岐で処理を切り替えている after: 振る舞いを分離する 4.3. DRY: 「共通化できそう」と言われたケース before: 同じコードが複数箇所にある after 其ノ壱: 知識を一箇所に集約 after 其ノ弐: 処理を一箇所に集約 4.4. before / after から学んだこと 5. 実装時に持つべき視点 6. 同じ立場の人たちへ 7. まとめ 0. はじめに はじめまして。新卒一年目の楽楽販売開発エンジニアです。 ほとんど開発経験がない状態で入社し、数ヶ月の研修を経て実務に入りましたが、最初はコードレビューで受けた指摘の意図や直し方が分からず戸惑うことばかりでした。 例えば、コードレビューでこんな指摘を受けたことはないでしょうか。 「このクラス、責務が多くないですか？」 「将来 if が増えそうですね」 「共通の処理が他にもあります」 私はまさにこのようなコードの設計に関する指摘をたくさん受けてきました。 ただ当時は「これらはなぜ必要なのか？結局どう直せばいいのか？」と思っていました。 私が書いたコードは要件通りに動くし、これらの指摘はどこか抽象的で、実装とどう結びついているのかが分からなかったからです。 それでもレビューで指摘を受けては実装を直し、学習を重ねるうちに、次第に なぜその指摘が出てくるのか どこを直せばよいのか が、以前よりもはっきりしてきました。そこから実装やレビューの時に意識するべきポイントを見出すことができました。 この記事ではコード設計に関する指摘に焦点を当て、これまでの私の変化と学びを元に 実装やレビューの時に気をつけると良いこと について述べます。 ここで紹介されるポイントを理解し実践することで、実装やレビューの質を上げていってほしいです。 コーディング経験が浅い人やこれからレビューを受ける人、これからレビューを始める人の参考になれば嬉しいです。 1. レビューされる側だった頃の問題点 最初の頃の私は、個人でコードを書いている感覚のまま、チーム開発をしていました。 とりあえず要件を満たして動けばOK 保守性・可読性は「なんとなく」意識する程度 それに加えて重要な設計原則を知らず、気にしていなかったです。 このような状態だったので、レビューで多くの指摘を受けていました。 今だからこそ言えることですが、以下のような具体的な観点を実装時に持っていなかったことが原因の1つでした。 どこまでを1つの責務と考えるのか 将来どんな変更が入りそうか 他の人が読んだときに意図が伝わるか いつも一貫した考えのもとで実装をしていなかったため、「指摘されてはその場で修正する」の繰り返しでした。 つまり、 再現性のある判断基準を持てていなかった のです。 なお、上記のような観点の詳細やその重要性については 3 節以降で述べます。 2. レビューと設計の関係性 2.1 なぜレビューが必要なのか ここで「レビューの必要性」について少し述べておきます。当初の私は、「レビューはバグを見つけるためのもの」だと考えていましたが、実際は違いました。 一般に、バグを見つけるのはテストでできるからこそ、中長期的な品質や保守性を担保するためにレビューを行います。 チーム開発には、 自分以外の人がコードを読む 複数人で継続的に機能追加や修正を行う という特徴があるため、できるだけ早い段階で複雑さが増えにくい形にコードを整えておくことが重要になります。 これを実現するためにレビューが必要なのです。 つまりレビューは、 「今の正しさ」だけでなく「将来も扱いやすいか」 を確認するためにあると言えます。 また、結果としてそれは お客様に価値を早く、継続的に届けるための投資 になります。 2.2 なぜ「設計」が関係するのか レビューが「将来の扱いやすさ」を見る場だとすると、「では、その扱いやすさは何で決まるのか？」と疑問に感じるでしょう。 そこで出てくるのが「コード設計」です。 責務の分け方 変更理由の整理 依存関係の持ち方 etc. レビューでコード設計の話が出てくるのは、それが中長期的な保守性を大きく左右するからです。 3. コードレビュー指摘の傾向から学んだこと ここではレビューで多かった指摘を振り返り、設計原則との関係を見ていきます。 また「コード設計に関する指摘」をもう少し具体的にします。 当時よくもらっていたのは、例えば次のような指摘です。 責務が多い 同じような処理が増えていきそう 同じような処理が他にもある 変更時の影響範囲が広そう これらを別々の指摘として受け取っていた当初は、「なぜ指摘されるのか」「どうすれば指摘されなくなるか」を根本から理解できていませんでした。 後から整理すると、表現は違えど、これらはどれも 将来の変更に弱い ことを指摘していました。 これがまさに将来の扱いやすさに言及する「コード設計に関する指摘」（以降「設計指摘」）だったのです。 したがって、設計指摘とは「将来困りそうか？」を様々な観点から判断してなされる指摘だと言えます。 3.1. 様々な設計原則 設計指摘を具体的に理解するために、まずは私が受けた設計指摘に大いに関係していた設計原則を3つ紹介します。 SRP（Single Responsibility Principle: 単一責任原則） 1つのクラスやメソッドには1つの責務のみを与えるべし OCP（Open-Closed Principle: 開放閉鎖原則） 既存コードの修正なしで拡張可能にするべし DRY（Don't Repeat Yourself） 重複を排除するべし 設計原則はどれも、将来の変更に対して壊れにくく、修正しやすく、ミスが入りにくい構造をあらかじめ作るための考え方です。 つまり、レビュワーが考えることはまさに設計原則そのものなのです。 それゆえ、レビューでは設計原則に基づいた指摘、すなわち設計指摘が頻出します。 3.2. 設計指摘を具体的に理解する 設計原則を知るともらった指摘の根底にある考えが分かるので、それらをより具体的に理解できます。 例えば、 「責務が多い」 → SRP の観点で、変更理由が増えそう 「同じような処理が増えそう」 → OCP / DRY の観点で、修正漏れが起きそう 「影響範囲が広い」 → 依存関係が整理されておらず、防御しにくい。あるいは DRY を守れていない こうして、当時は抽象的に思えた指摘をやや具体的に理解することができました。 3.3. 設計指摘をものにするためには？ 設計指摘の根底にある考えは「このままでは将来が不安である」というものでした。 これだと抽象的に思えますが、実はある程度定まった基準が存在しており、それが設計原則でした。 設計原則を知り、実際のコードに応用できるようになれば、設計指摘で悩むことはなくなると思っています。 そういうわけで、次節では設計指摘を受けるコードとはどんなものなのかを見ていきます。 設計指摘を受ける理由やどのように直せば良いのかをまとめ、更に理解を進めます。 4. before / after で見る設計指摘の具体例 ここまで読めば、設計指摘の意味やその根底にある考えが分かってきたと思います。 4 節ではサンプルコードを用いて、実際にどんなコードがどんな理由で指摘され、どう直すべきなのかを before / after の形で見ていきます。 4.1. SRP: 「責務が多い」と言われたケース まずは SRP（単一責任原則） の例です。 当時の私は以下のように、1つのクラスで色々な処理をしようとしていました。 before: 1つのクラスに複数の責務がある public class UserService { public void register(User user) { validate(user); save(user); sendNotification(user); } private void validate(User user) { // 入力チェック } private void save(User user) { // データベースに保存 } private void sendNotification(User user) { // 通知メール送信 } } このコードの問題点は、「ユーザー登録」というユースケースの中に、複数の責務が押し込まれていることです。 以下のような別々の変更理由によって、コードの同じ箇所が変更される可能性があります。 入力チェックの仕様が変わる データベースへの保存方法が変わる 通知手段が増える / 変わる after: 責務ごとに分離する public class UserService { private final UserValidator validator; private final UserRepository repository; private final NotificationService notificationService; public void register(User user) { validator.validate(user); repository.save(user); notificationService.notify(user); } } 処理の流れ自体は変わっていませんが、 入力チェック データベースへの保存 通知 が、それぞれ独立した責務として切り出されています。 この変更によって、 仕様変更時の影響範囲が限定される テストしやすくなる 実装意図が読み取りやすくなる といった効果があります。 「責務が多い」という SRP に基づく指摘は、 将来の変更理由が1箇所に集まりすぎている 、すなわち 一人で色々やりすぎ という意味であると理解できます。 4.2. OCP: 「将来増えそう」と言われたケース 次は OCP（開放閉鎖原則）の例です。当時は以下のように、分岐を増やして処理を追加していました。 before: 条件分岐で処理を切り替えている public class PriceCalculator { public int calculate(Order order) { if (order.getType() == OrderType.NORMAL) { return order.getBasePrice(); } else if (order.getType() == OrderType.DISCOUNT) { return order.getBasePrice() * 9 / 10 ; } else if (order.getType() == OrderType.SPECIAL) { return order.getBasePrice() * 8 / 10 ; } throw new IllegalArgumentException(); } } このようなコードは「将来 if が増えそうですね」などと指摘を受けるでしょう。 そして当時の私なら「今はこれで動くし十分では？」と思ったに違いありません。 このコードの問題点は、 注文種別が増えるたびに if が増える 修正のたびにこのクラスを触る必要がある 変更漏れのリスクが高くなる 「今動くかどうか」ではなく「将来どうなり得るか」が問題です。 そもそも設計指摘とはそういうものでした。 after: 振る舞いを分離する public interface PriceStrategy { int calculate(Order order); } public class NormalPriceStrategy implements PriceStrategy { public int calculate(Order order) { return order.getBasePrice(); } } public class DiscountPriceStrategy implements PriceStrategy { public int calculate(Order order) { return order.getBasePrice() * 9 / 10 ; } } public class PriceCalculator { private final PriceStrategy strategy; public int calculate(Order order) { return strategy.calculate(order); } } この形にすると、 新しい価格計算ルールを追加しても既存コードをほぼ触らない 条件分岐が増えない 振る舞いごとに責務が分かれる という状態になります。 「将来増えそう」という OCP に基づく指摘は、将来変更が入る時にコードがどう修正されるかを見ていたのだと分かりました。 変更する時に既存のコードは変更せず、新たにコードを追加するだけで対応できるようにするべきである という OCP の意味が理解できました。 4.3. DRY: 「共通化できそう」と言われたケース 次は DRY の例です。当時は以下のように、コードの複数箇所に同じことを書いていました。 なお DRY には "知識" と "処理" に注目する2パターンがあるので、それぞれ紹介します。 before: 同じコードが複数箇所にある public class OrderService { public int calculateTotal(Order order) { int subtotal = order.getSubtotal(); int tax = subtotal * 10 / 100 ; return subtotal + tax; } public int calculateRefund(Order order) { int subtotal = order.getSubtotal(); int tax = subtotal * 10 / 100 ; return subtotal - tax; } } このコードの問題点を "知識" に注目して挙げると、 税率10%という "知識" が二箇所に書かれている 税率変更時に両方修正が必要 これにより修正漏れのリスクが高くなっています。 after 其ノ壱: 知識を一箇所に集約 public class TaxCalculator { private static final int TAX_RATE = 10 ; public static int calculate( int amount) { return amount * TAX_RATE / 100 ; } } public class OrderService { public int calculateTotal(Order order) { int subtotal = order.getSubtotal(); return subtotal + TaxCalculator.calculate(subtotal); } public int calculateRefund(Order order) { int subtotal = order.getSubtotal(); return subtotal - TaxCalculator.calculate(subtotal); } } こうすれば、例えば税率を8%に変える時、 TaxCalculator の冒頭一箇所のみを修正すれば済みます。 元のコードに比べて修正漏れのリスクが低くなっています。 一方で元のコードの問題点を "処理" に注目して挙げると、 税金計算ロジックが二箇所に書かれている 変更時に両方修正が必要 これらを解決するには、"知識" の場合にならって "処理" を一箇所にまとめれば良いです。 after 其ノ弐: 処理を一箇所に集約 public class OrderService { public int calculateTotal(Order order) { int tax = calculateTax(order.getSubtotal()); return order.getSubtotal() + tax; } public int calculateRefund(Order order) { int tax = calculateTax(order.getSubtotal()); return order.getSubtotal() - tax; } private int calculateTax( int subtotal) { return subtotal * 10 / 100 ; } } 重複していた税計算処理が一箇所のみになるので、この場合も元のコードに比べて修正漏れのリスクが低くなります。 DRY 原則を守るとは、 同じコードをまとめ、修正箇所を減らす ことだと分かりました。 4.4. before / after から学んだこと これらの例から、設計指摘を受けるコードの特徴や改善方法がイメージできたと思います。 またコードの問題点を before / after を通して見ることで、設計が、2 節で述べた「中長期的な保守性」に大きな影響を与えることも分かったと思います。 このような経験から、私は設計指摘が出てしまう原因には実装者とレビュワーの視点の違いがあると考えています。 実装者としては、 仕様を満たしているか テストが通っているか に目が行きがちです。 実際、before のコードはどれも「今の要件」だけを見れば問題ありません。 一方レビュワーは、 機能追加や仕様変更 別の人が触る未来 を考えています。設計指摘はこれらを事前に想像したうえで出されていました。 この視点の違いこそ、レビューで指摘が出る理由です。 それゆえ実装時には 1.2 節で述べたような観点を持つことが重要なのだと思います。 5. 実装時に持つべき視点 設計指摘の意味が分かると、以前とは異なり、実装時点でレビュー視点を持てるようになりました。 実装中に自然と次のような問いを立てるようになりました。 このクラスは、何のために存在しているのか 変更理由は1つに収まっているか 将来どんな仕様変更が入りそうか そのときどこを直すことになりそうか これらは全てこれまでレビューで指摘されてきたポイントであり、別の言い方をすれば、設計原則が言おうとしていることでした。 その結果、レビューで指摘されそうな点に早い段階で気づけるようになりました。 こうして実装時に色々な観点を持てるようになりました。 自分の実装の良し悪しを常に同じ判断基準で考えることができるので、実装のたびにブレることが少なくなったと思います。 もしレビューで設計指摘を受けたときは、これらの観点で一度コードを見直してみてください。 「今動くか」ではなく「将来どう変わるか」を考えるだけで、見えるものが大きく変わると思います。 また、最近から私はレビューする側にも回っています。 レビューされる側として多くの指摘を受けてきた経験は、レビューをする時でも大いに役立っていると感じます。 自分なりに着眼点を持ち、「今の実装が動くかどうか」だけでなく、将来のことを考えてレビューをしています。 6. 同じ立場の人たちへ 実装時あるいはレビュー時に、本記事で挙げたような観点を持っているのといないのでは差があります。 おさらいすると、 クラスや関数の責務は1つか 将来どんな変更が入りそうか そのときどこを直すことになりそうか 修正する箇所は少ないか 他の人が読んだときに意図が伝わるか などであり、重要なのは、これらはどれも「今」ではなく「将来」を見ているということです。 常に同じ判断基準を持ち、経験とともにそれを磨き、増やしていけば、実装やレビューの質は確実に上がると思っています。 7. まとめ この記事では、 なぜレビューやコード設計が重要なのか 抽象的に思える設計指摘の意味や直し方 を、私自身の変化を軸に整理してきました。 コード設計が中長期的な保守性に大きな影響を与えるので、 将来の変更に耐えられるか という視点から設計指摘がなされるのでした。 そして具体的なコードを見て設計への理解をより深め、実装やレビューの時に持つと良い視点としてまとめることができました。 レビューで設計指摘を受けている人やこれからレビューを始める人にはぜひ意識してもらいたいです。 この記事がそのような人の助けになれば嬉しいです。

こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） tech-blog.rakus.co.jp お客様を知らないといけないので、「もっと深く考えて」と言われた瞬間に、急に手が止まることがあります。 フレームワークや知識は増えているのに、いざ実務だと「機能の足し算」しか出てこない——。 これ、能力の問題というより “鍛え方の種類” の問題だと思っています。 今日提案したいのは、名作を使った超シンプルな思考トレーニングです。 同じ作品を「読む→聴く→観る」の3回、メディア違いで摂取する。 それだけで、ユーザー理解に必要な「論理／情緒／直感」を行き来できるようになります。 この記事で得られること なぜ「同じ作品を3回」なのか 実践：3メディア分解（所要：合計2〜4時間） 1回目：読む（活字）—「構造」を立ち上げる 2回目：聴く（音声）—「温度」を拾う 3回目：観る（映像）—「引き算」を学ぶ 深掘り：強いプロダクトは「80%で止める」 余白設計のコツ このトレーニングを「ユーザー理解」に接続するコツ（仕事への落とし込み） もう一段伸ばす：あえて「アウェイ」に行く AIで“振り返り”を加速する（※安全に） 結び：日常のすべては、思考の実験場 参考：このトレーニングをする時のおすすめ作品 海外の作品 日本の作品 この記事で得られること ユーザーが 言語化できる情報 と 言語化できない感情 を分けて捉えるコツ 画面を「足す」よりも、価値を「残す」ための 引き算の設計 思考が詰まった時に、発想を動かす 具体的な手順 なぜ「同じ作品を3回」なのか 脳はラクをしたがるので、つい “慣れた窓” から世界を見ます。 ビジネス書ばかり読んでいると、何でもビジネスロジックの窓で解釈してしまう。 すると、ユーザーの温度感や迷い、言葉にならない「違和感」を取りこぼしやすくなります。 そこで効くのが、 同一題材のメディア切り替え です。 同じ物語でも、活字・音・映像で、脳に届く情報の種類が変わる。 ＝思考の筋肉を、強制的に“別の角度”から使えるようになります。 実践：3メディア分解（所要：合計2〜4時間） 題材は何でもOKですが、最初はメディア展開が豊富な作品がやりやすいです（例：『 星の王子さま 』）。 ※作品名・サービス名はあくまで例です。特定の企業やサービスを推奨する意図はありません。入手しやすい方法（紙・電子・図書館・音声・配信など）でOKです。 1回目：読む（活字）—「構造」を立ち上げる 狙い：論理構築力／情報設計（IA）寄りの筋肉 読みながら、次のメモだけ取ります（全部書かなくてOK）。 登場人物（または要素）の関係は？ 物語の転換点はどこ？ “作者が言ってないこと”は何？（空白はどこ？） ここでやっているのは、文章から「骨格」を立てる練習です。 プロダクトで言えば、ユーザー行動の前後関係や、要件の構造化に近い。 2回目：聴く（音声）—「温度」を拾う 狙い：共感／リズム感／体験設計（UX）寄りの筋肉 オーディオブックや朗読、ラジオドラマなどで聴きます。 ポイントは「意味」ではなく「揺れ」を拾うこと。 どこで声が強くなる？ どこで間が空く？ 自分の感情が動いたのはどの場面？ “言葉にできない”けど残った余韻は？ ユーザーインタビューでも、言葉より 間・言い淀み・声のトーン に価値が乗ることがあります。 聴く練習は、そこを拾う感度を上げます。 3回目：観る（映像）—「引き算」を学ぶ 狙い：直感／審美眼／表現の取捨選択（UI）寄りの筋肉 映像は情報量が多いぶん、作り手の“選択”が見えます。 何を見せ、何を見せなかった？ 1秒で伝えるために、何を捨てた？ 「正解」を提示しすぎていない？ ここで得たいのは、 足し算ではなく“残し方” の感覚です。 深掘り：強いプロダクトは「80%で止める」 私も経験が浅い頃ほど、不安から「全部説明したくなる」瞬間がありました。でも、体験が強いプロダクトほど、実は 余白 があります。 余白設計のコツ 説明を 80%で止める 残り20%を、ユーザーが「自分の言葉／自分の意味」で埋められるようにする ユーザーが“自分でわかった”瞬間、プロダクトは「誰かのもの」から「自分のもの」になります。 この手触りが、継続利用や愛着（ブランド）につながります。 このトレーニングを「ユーザー理解」に接続するコツ（仕事への落とし込み） 3回やったら、最後にメモを1枚にまとめて、次の3つだけ作ります。 ユーザーの“言語化された要望”（読むで拾った骨格） ユーザーの“温度・揺れ”（聴くで拾った違和感） 体験としての“残し方”（観るで見えた取捨選択） そして、プロダクト改善の形に変換します。 「ユーザーは何に迷っている？（迷いの正体）」 「その迷いを減らす“最初の一歩”は何？（オンボーディングの1手目）」 「説明を増やす代わりに、何を消せる？（余白設計）」 この3つが揃うと、「機能の足し算」ではなく 価値の設計 に思考が寄ります。 もう一段伸ばす：あえて「アウェイ」に行く 3メディア分解に慣れたら、次は 自分が避けがちなジャンルで同じ実験をします。違和感が強いほど、思考の回路が増えます。 ロジック派なら：感情や熱量が主役の作品（例：『火花』） リアリストなら：抽象度が高い作品（例：『銀河鉄道の夜』） AIで“振り返り”を加速する（※安全に） AIは答えを出す道具というより、思考の壁打ち相手にすると効きます。 各回のあと、メモを短く貼って以下を聞くだけでもOKです。 「この作品の論点を3つに要約して。根拠になった描写も添えて」 「反対意見（別解釈）を2つ出して」 「プロダクト改善に置き換えるなら、どんな仮説と検証案になる？」 結び：日常のすべては、思考の実験場 「思考力が弱い」と落ち込む必要はありません。 鍛え方を少し変えるだけで、視点はちゃんと増えます。 まずは手元の作品を、これまでと違うメディアで1回だけ。思考のOSは、そこから静かに更新され始めます。 参考：このトレーニングをする時のおすすめ作品 ※「音声化／映像化されているとやりやすい」という観点の例です（特定サービス推奨ではありません）。 海外の作品 『ハリー・ポッターと賢者の石』（J.K.ローリング）— Audibleあり／映画化（2001） 『指輪物語 旅の仲間』（J.R.R.トールキン）— Audibleあり／映画化（2001） 『アルジャーノンに花束を』（ダニエル・キイス）— Audibleあり／映画化『まごころを君に』（1968） 『三体』（劉慈欣）— Audibleあり／Netflixドラマ化（2024） 『ダ・ヴィンチ・コード（上）』（ダン・ブラウン）— Audibleあり／映画化（2006） 『そして誰もいなくなった』（アガサ・クリスティ）— Audibleあり／ドラマ化（2015） 『サピエンス全史（上）』（ユヴァル・ノア・ハラリ）— Audibleあり／ドキュメンタリー化（制作進行中） 日本の作品 『こころ』（夏目漱石）— Audibleあり／映画化（1955） 『人間失格』（太宰治）— Audibleあり／映画化（2010） 『雪国』（川端康成）— Audibleあり／映画化（1957） 『沈黙』（遠藤周作）— Audibleあり／映画化『沈黙 -サイレンス-』（2016） 『銀河鉄道の夜』（宮沢賢治）— Audibleあり／映画化（1985） 『ノルウェイの森（上）』（村上春樹）— Audibleあり／映画化（2010） 『白夜行』（東野圭吾）— Audibleあり／映画化（2011） 『告白』（湊かなえ）— Audibleあり／映画化（2010） 『嫌われる勇気』（岸見一郎、古賀史健）— Audibleあり／ドラマ化（2017） 『火花』（又吉直樹）— Audibleあり／Netflixドラマ化（2016） 『屍人荘の殺人』（今村昌弘）— Audibleあり／映画化（2019） 『かがみの孤城』（辻村深月）— Audibleあり／アニメ映画化（2022） 記事を読んでラクスのプロダクト部に興味を持ってくださった デザイナー／PdM の方 は、ぜひカジュアル面談からご応募ください。 ※プロダクトマネージャーのカジュアル面談は、基本的に私（稲垣）が担当します！ ●採用情報 プロダクトマネージャー career-recruit.rakus.co.jp デザイナー https://career-recruit.rakus.co.jp/engineer_jobs/uidesigner_tokyo/ career-recruit.rakus.co.jp

こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） tech-blog.rakus.co.jp マネージャーの役割を一言で言うなら、私は「管理」ではなく “支援” だと思っています。 現場の専門性を信じ、意思決定の質を上げ、チームが成果を出しやすい状態をつくること。 この記事では、そのために私が意識している2つの視点を紹介します。 コト（成果・意思決定）には解像度を上げる支援 人（成長・キャリア）には未来を描く支援 ※前提として、最適な距離感はチームの成熟度・状況・業務特性で変わります。ここでは「私の経験ではこうすると機能しやすかった」という一例として読んでください うまくいっている“ように見えた”チームで、手戻りが起きた話 コトの解像度を上げる＝「詰める」ではなく「迷いを減らす」 1) “目的” をそろえる支援（何のためにやるのか） 2) “事実” を共有しやすくする支援（いま何が起きているのか） 3) “意思決定” を軽くする支援（決めるのが怖くない状態） 「現場を分かれ」ではなく「現場が強くなる」ための関わり方 人には「未来」を：日々のフィードバックを“支援”に変える 未来が共有できると、指摘が「評価」ではなく「投資」になる 情報の流れを整える：支援が届きやすいチームにする AIで解像度を上げる（ただし守るべきものは守る） まとめ：解像度は、現場への敬意を形にする手段 うまくいっている“ように見えた”チームで、手戻りが起きた話 以前、関係性が良く、議論も穏やかで、進捗も「順調」と共有されているチームを見て、私は安心していました。 「信じて任せよう。口を挟みすぎないようにしよう」と。ただ、あるタイミングで出来上がったものを見て、違和感が残りました。 仕様は満たしている。でも「なぜこの形なのか」の説明が弱い トレードオフが曖昧で、「誰の課題をどう解いたか」が語れない 結果として、手戻りの議論が後ろ倒しになる 原因は、メンバーの能力不足ではありませんでした。 “支援の仕組み” が足りていなかったのだと思います。 私は、任せることに意識が向きすぎて、 「何を事実として見て、どこで意思決定し、何を残すか」という “解像度を上げる支援” を設計できていませんでした。 そこから考え方を変えました。 現場を疑うのではなく、現場が強くなるために “解像度を上げる支援” をする。 その支援があると、任せることがむしろ加速します。 コトの解像度を上げる＝「詰める」ではなく「迷いを減らす」 解像度を上げるというと、「細かく口を出す」「監視する」と誤解されがちです。 私がやりたいのは真逆で、 チームの迷い・手戻り・不毛な摩擦を減らす ことです。 そのために、私がよく使うのは次の3つの支援です。 1) “目的” をそろえる支援（何のためにやるのか） プロダクト開発では、判断が割れた時に「どっちが正しいか」になりがちです。 でも本質は「目的に照らすとどっちが良いか」です。 だから私は、最初にここを揃える支援をします。 今回の変更で、ユーザーの何が楽になる？（誰のどんな負担が減る？） それを “良くなった” と判断する指標は何？（完了率、離脱、問い合わせ等） 今回は “何をやらない” と決める？（守る範囲を明確にする） 目的が揃うと、現場の議論は速くなり、任せやすくなります。 2) “事実” を共有しやすくする支援（いま何が起きているのか） 「順調です」という共有自体は悪くありません。 ただ、意思決定を強くするには、順調の“根拠”が必要です。 ここでも私は「見せてください」ではなく、 “一緒に見よう” のスタンスを取ります。 今回の仮説を裏付けるログや数値はどれ？ 逆の可能性（失敗パターン）を疑うなら、何を見れば早く気づける？ 定量だけで見えないなら、ユーザーの声・問い合わせ・営業/CSの肌感も合わせてみよう ポイントは、現場の専門性を奪わないことです。 私は答えを決めにいくのではなく、 判断材料が揃う状態をつくる ことに集中します。 3) “意思決定” を軽くする支援（決めるのが怖くない状態） 現場が抱えがちなストレスは、「決めたあとに責められること」だったりします。 ここを放置すると、合意形成が過剰に重くなり、前に進まなくなります。 だから私は、意思決定の仕組みをできるだけシンプルにします。 決める人（Decision owner）を明確にする 迷ったときの判断軸（優先順位）を先に置く 決めた理由を短く残す（後で責めるためではなく、学ぶため） こういう “支援の設計” があると、現場は安心して攻められるようになります。 「現場を分かれ」ではなく「現場が強くなる」ための関わり方 ここまでの話は、現場の仕事に介入したいからではありません。 むしろ逆で、 現場が自分たちで決めて進められる状態を増やしたい からです。 私が自戒しているのは次の2つです。 マネージャーが「正解」を持っている前提で話さない 現場の専門性に敬意を払い、判断に必要な材料を揃える側に回る 解像度を上げる支援は、現場を縛るためではなく、現場の裁量を増やすためにあります。 人には「未来」を：日々のフィードバックを“支援”に変える コトの解像度だけを上げると、どうしても「厳しい人」に見えやすいです。 だから私は、必ず “人の未来” とセットで扱うようにしています。 月1回、進捗ではなく「未来の話だけ」をする 私は、業務の進捗とは別に、月に1回はキャリアの話だけをする時間を取ります。 ここでは「今のタスクが遅い/早い」みたいな話はしません。 代わりに、次の3つをゆっくり話します。 いま気になっていること（興味・違和感でもOK） できるようになりたいこと（3ヶ月〜1年くらいの距離感でもOK） そのために、次に経験したいこと（挑戦したい役割・場面） 未来は固定しません。変わっていい。 ただ、言語化の回数が増えるほど、本人も周囲も支援しやすくなります。 未来が共有できると、指摘が「評価」ではなく「投資」になる たとえば設計の議論で深掘りする時も、 「詰める」ではなく「あなたの未来にとって重要だから一緒に考えたい」という形に変わります。 将来こういう領域をやりたいなら、今この視点は武器になる そのために、この判断のトレードオフを言語化してみよう 私も責任を持って一緒に腹落ちさせたい こうなると、コトの解像度を上げる関わりは、監視ではなく 伴走 に近づきます。 情報の流れを整える：支援が届きやすいチームにする 最後に、やり方の話です。 支援のつもりでも、マネージャーが“都度呼び出す”形だと、結局重たくなります。 だから私は、情報の流れをこう整えるようにしています。 「私への報告」ではなく「チームに共有」する（事実が溜まる場所を作る） 早めに共有すると得をする（手戻りが減る/調整が早い/判断が速い）体験を作る 報告を義務にしない。 支援が早く届く “仕組み” として設計する。これだけで、現場のストレスはかなり減ります。 AIで解像度を上げる（ただし守るべきものは守る） 最近はAIで、情報整理のコストを下げられるようになりました。たとえば、 議事録や議論ログの要約（論点・未決・次アクション） 問い合わせ/不具合の一次分類（まず「何が起きているか」を掴む） 判断材料の洗い出し（見るべきログ・指標候補の列挙） 一方で、個人情報やセンシティブな情報は扱いに注意が必要です。 AIを使う場合は、社内ルールに沿った範囲で、秘匿情報を投入しない前提で運用します。 まとめ：解像度は、現場への敬意を形にする手段 コトには、迷いを減らすために解像度を上げる支援をする 人には、未来を言語化して支援が届く状態をつくる この2つが揃うと、マネージャーの関わりは「管理」ではなく「支援」になります。 現場の専門性を信じることと、解像度を上げることは両立できます。 むしろ、支援の設計があるほど、現場はより自由に、より強く動けるようになります。 また、記事を読んでラクスのプロダクト部に興味を持ってくださった デザイナー／PdMの方 は、ぜひカジュアル面談からご応募ください。 ●採用情報 プロダクトマネージャー career-recruit.rakus.co.jp デザイナー career-recruit.rakus.co.jp

こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） tech-blog.rakus.co.jp 社内で口癖のように使っている「製品解像度」と「UX志向」について自分の思考の整理もかねて記事にまとめてみました。 はじめに：私たちは「誰」を見ているのか？ 「製品解像度」とは何か？ まず押さえたい：製品解像度が低いと起きる“あるある” なぜ「お客様解像度」だけでは不十分なのか？ 質の高いアウトプットを生む土壌 UX志向を支える「意思決定」の力 「OR」ではなく「AND」を模索する 「架け橋」としての役割 ラクス プロダクト部としての「UX志向」 製品解像度を高めるために 1. 「越境」を恐れない 2. 「なぜ？」を問い続ける 3. プロダクトの「歴史」と「未来」を知る 製品解像度が上がると何が起きるか：アウトプットの質が変わる 1) 要求仕様が“外れにくくなる” 2) トレードオフの説明責任が果たせる 3) 「事実に基づく」文化が回りやすくなる 4) “作って終わり”から“学習して伸ばす”に変わる おまけ：製品解像度を上げるための「10の問い」（会議で使える） おわりに：最高のUXへの近道 はじめに：私たちは「誰」を見ているのか？ 「UX（ユーザーエクスペリエンス）志向」 「ユーザー中心設計」 「顧客視点」プロダクト開発の現場にいると、これらの言葉を聞かない日はありません。私たちプロダクトに関わるメンバーは、常にお客様のことを考え、彼らの課題に寄り添い、最高の体験を届けようと日々奮闘しています。しかし、ここで一度立ち止まって考えてみたい問いがあります。 「お客様のことさえ深く理解していれば、本当に優れたプロダクトは作れるのだろうか？」 という問いです。自分としての結論は“お客様理解だけでは足りない”です。 もちろん、お客様を理解することは不可欠です。しかし、それだけでは「良いプロダクト」を継続的に生み出し、育てていくことはできません。 時に「お客様のため」を思うあまり、ビジネスとして成立しない機能を作ってしまったり、技術的に無理のある実装を強いてプロジェクトを破綻させてしまったりすることさえあります。 では、私たちには何が必要なのか？ そこで私が提唱したいのが、 「製品解像度」 という概念です。 今回は、単なる「お客様解像度」を超え、真の意味でプロダクトを成功に導くための「製品解像度」について、その定義となぜそれが不可欠なのかを紐解いていきます。 「製品解像度」とは何か？ まず、「解像度」という言葉についてです。自分の中では解像度は写真の比喩が一番しっくりきます。ピントが合っていない写真は、全体の雰囲気はわかるけれど、重要なディテール（表情・文字・境界線）が見えません。プロダクトでも同じで、解像度が低いと、議論が抽象的になり、判断が“気分”や“声の大きさ”に引っ張られます。逆に解像度が高いと、論点が具体になり、仮説と事実が整理され、意思決定が速くなる。 この「ピントの合い方」を、製品を取り巻く全体に広げたものが“製品解像度”として自分は定義しています。具体的には、次のような観点です。 お客様：誰が、どんな状況で、どんな目的で使っている／使おうとしているか （運用中・導入準備中・導入検討・未検討といったフェーズも含む） システム：制約、データの流れ、既存アーキテクチャ、運用条件 UI/UX：主要導線、つまずきポイント、体験の一貫性 ドメイン：業務知識、法令、慣習、現場の「当たり前」 自組織／他組織：意思決定構造、責任分界、依存関係、コミュニケーション経路 事業戦略：何を伸ばし、何を守り、何を捨てるのか（優先順位） 市場：競合、代替、ポジショニング、差別化要因 未来：中長期の方向性、ロードマップ上の“意味” 開発プロセス／役割：どう作り、どう届け、どう改善していくか 製品解像度とは、 プロダクトを取り巻くエコシステム（生態系）全体に対する理解の深さ を意味します。これら全てを網羅し、それぞれの要素がどう絡み合っているかを理解している状態こそが、「製品解像度が高い」状態と言えます。 まず押さえたい：製品解像度が低いと起きる“あるある” 製品解像度が低い状態は、努力不足というより「見えていないから判断できない」状態です。現場でよく起きる症状を挙げます。 顧客要望をそのまま機能要件に翻訳してしまい、根っこのジョブや制約を見落とす 「これが良さそう」という仮説だけで意思決定してしまい、後から前提が崩れて手戻りする “十分な検討のないトレードオフ”になり、関係者の納得が得られない リリース後、成果が測れず、改善が続かない（やりっぱなしになる） 部署間の認識がズレて、会議で「それは誰が決めるの？」が発生する どれも、個人の能力というより「判断材料が揃っていない」ことが原因です。だからこそ、解像度を上げることが、チームの再現性をつくります。 なぜ「お客様解像度」だけでは不十分なのか？ 「お客様第一」は美しい言葉ですが、プロダクトマネジメントの現実はもっと複雑で泥臭いものです。なぜ「お客様解像度」だけでは戦えないのか、その理由を構造的に解説します。 The Product Management Triangle Posted by Dan Schmidt, Product Logic ※ラクスのプロダクト部向けにカスタマイズ プロダクト開発には有名な「プロダクトマネジメント・トライアングル」という概念があります。これは、プロダクトが以下の3つの要素のバランスで成り立っていることを示しています。 開発者（Developers） お客様（Customers） ビジネス（Business） この3つの頂点を繋ぐ辺（関係性）を見てみましょう。 お客様 × 開発者 ＝ UX（ユーザー体験） お客様のニーズを技術でどう解決するか。ここから優れたUXが生まれます。 お客様 × ビジネス ＝ 価値交換（収益） お客様への価値提供が、いかに対価としてビジネスに還元されるか。ここから利益が生まれます。 3. 開発者 × ビジネス ＝ 実現可能性（デリバリー） ビジネスの要求を、限られたリソースと技術でどう実現するか。ここから製品が世に出ます。 もし、あなたが「お客様解像度」しか持っていない場合、見えるのは「1. UX」の領域だけです。 「お客様がこう言っているから機能を追加しよう」と提案しても、それがビジネス的に採算が合わない（2の視点の欠如）ものであれば却下されるでしょう。また、技術的に莫大なコストがかかる（3の視点の欠如）ものであれば、開発チームとの信頼関係を損なうかもしれません。 「製品解像度」を持つということは、このトライアングル全体を俯瞰し、3つの辺すべてを 健全に機能させる視点を持つ ということです。 質の高いアウトプットを生む土壌 「アウトプットの質」とは何でしょうか？ 単に「見た目が美しいUI」や「バグのないコード」のことでしょうか？ プロダクト開発における「質」とは 、「実現可能性（Feasibility）」と「事業性（Viability）」と「有用性（Desirability）」が高い次元で融合していること です。 お客様の要望（顕在ニーズ）に応えることは重要です。しかし、プロフェッショナルであるならば、その要望をそのまま形にするのではなく、「技術的に最も効率的で」「ビジネスとして持続可能で」「かつユーザーの課題を根本から解決する」ソリューションを導き出さなければなりません。 システム構造を知らなければ、非効率なUIを設計してしまうかもしれません。 事業戦略を知らなければ、来年には不要になる機能を作り込んでしまうかもしれません。製品解像度を高めることは、これら「見落とし」をなくし、手戻りを防ぎ、最初から精度の高いアウトプットを生み出すための必須条件だと考えています。 UX志向を支える「意思決定」の力 プロダクト開発は「意思決定」の連続です。 「Aという機能を優先するか、Bという改善を優先するか」 「リリースを早めるか、品質を高めるか」 こうした岐路に立ったとき、製品解像度の差が如実に現れます。 「OR」ではなく「AND」を模索する 解像度が低いと、安易なトレードオフ（ORの決断）に逃げがちです。 「ビジネス側の要求だから、UXは諦めよう（Business OR UX）」 「技術的に難しいから、仕様を落とそう（Tech OR UX）」 しかし、製品解像度が高い人は、各要素のつながりが見えているため、「AND」の解を模索できます。 「技術的にはこの制限があるが、UIの工夫でユーザーの負担は減らせるのではないか？」 「ビジネス目標のKPIは、この機能を少し簡略化しても達成できるのではないか？」 ビジネスの制約（利益・コスト）、技術的な制約、そしてお客様のニーズ。これら全てを深く理解しているからこそ、単なる妥協ではない、創造的な第三の案を生み出すことができるのです。 「架け橋」としての役割 プロダクト部のメンバーには、ビジネスチームと開発チームの「架け橋」としての役割が求められます。 通訳をイメージしてください。英語しか話せない人と日本語しか話せない人の間に入る通訳が、片方の言語しかわからなかったらどうなるでしょうか？ 会話は成立しません。 これと同じです。 ビジネスサイドの言語（売上、KPI、市場シェア）と、開発サイドの言語（アーキテクチャ、工数、技術的負債）。そしてお客様の言語（使いやすさ、課題解決）。 これら全ての「言語」を理解し、翻訳できるのが「製品解像度が高い人」です。 ビジネスチームには「なぜこのUX改善が将来の売上につながるのか」をロジカルに説明し、開発チームには「なぜこのビジネス要件が重要で、どう実装するのが最適か」を技術背景を踏まえて相談する。 この動きができる人材こそが、組織の中で真に信頼されるプロダクトパーソンとなれるのです。 ラクス プロダクト部としての「UX志向」 プロダクト部では本組織が組成される前（PdM組織の頃）から、以下を提示して、メンバーや自分自身もこれに従うようにしています。 製品解像度を高めるために では、どうすれば製品解像度を高めることができるのでしょうか？ 明日からできるアクションをいくつか提案します。 1. 「越境」を恐れない 自分の担当領域の外に出ましょう。デザイナーなら、売上の数字を見てみる。エンジニアなら、営業に同行してお客様の声を聞く。プロダクトマネージャーなら、システム構成図を書いてみる。 「それは私の仕事ではない」と線を引いた瞬間、解像度の上昇は止まります。 2. 「なぜ？」を問い続ける 仕様書や要件定義書を見たとき、そこに書かれていることの背景を想像してください。 「なぜこの機能が必要なのか？（ビジネス背景）」 「なぜこの実装方法なのか？（技術背景）」 「なぜ今なのか？（市場背景）」 わからないことは、その領域のプロフェッショナル（営業担当やエンジニア）に質問しましょう。彼らは自分の領域に関心を持ってくれる人を歓迎するはずです。 3. プロダクトの「歴史」と「未来」を知る 過去の意思決定の経緯（なぜこの機能があるのか）を知ることで、現在の制約の意味がわかります。そして、ロードマップ（未来の構想）を知ることで、今作るべきものの優先順位が見えてきます。点ではなく、線でプロダクトを捉えましょう。 製品解像度が上がると何が起きるか：アウトプットの質が変わる 製品解像度の価値は、抽象論ではなく、アウトプットに表れます。具体的には次の変化が起きます。 1) 要求仕様が“外れにくくなる” 解像度が高いと、論点の抜け漏れが減り、前提が揃うので、要求仕様（PRD）やデザインが当たりやすくなります。組織の重点取り組みでも「製品を取り巻く解像度を向上し、外れのない要求仕様を策定して開発に提供できる状態」を目指す、と明確に言語化されています。まさにここが、製品解像度が“成果”に変わる瞬間です。 2) トレードオフの説明責任が果たせる UXは必ずトレードオフの連続です。どれを捨て、どれを採るか。その判断が“十分な検討のないトレードオフ”になってしまうと、ステークホルダーは納得しないし、ユーザーも幸せにならない。製品解像度が高いチームは、制約を含めて説明できるので、合意形成が進みます。 3) 「事実に基づく」文化が回りやすくなる お客様の声、利用データ、市場情報、開発・運用の実態。これらを同じテーブルに乗せられるようになると、仮説と事実が区別され、議論の質が上がります。「なんとなくこう思う」から、「この事実があるからこう判断する」へ。UX志向の行動原理と相性が良いのはここです。 4) “作って終わり”から“学習して伸ばす”に変わる 解像度が高いチームは、指標（NSMや関連指標など）を置き、リリース後に成果を回収し、開発にも共有して次に活かします。改善が単発のイベントではなく、学習ループになります。 おまけ：製品解像度を上げるための「10の問い」（会議で使える） この問いは、答えを完璧に揃えるためというより、「ピントが合っていない領域」を早めに炙り出すために使ってもらえればと思います。 おわりに：最高のUXへの近道 「製品解像度を持つべきだ」という主張は、一見するとUX志向とは対極にある「ビジネス寄り」「システム寄り」の話に聞こえるかもしれません。 しかし、逆です。 本当に優れたUXを実現したいのであれば、製品解像度を高めることが一番の近道 なのです。 お客様のことしか見ていない「優しさ」は、時にプロダクトを脆弱にします。 ビジネスと技術という現実の厳しさも含めてプロダクトを愛し、理解する「強さ」こそが、長く愛され続けるサービスを育てる土壌となります。 私たちプロダクト部のメンバー一人ひとりが、お客様解像度だけでなく、この「製品解像度」という武器を持ったとき。私たちの組織は、ビジネスの要請にも、技術の進歩にも、そして何よりお客様の期待にも、かつてない高いレベルで応えられるようになるはずです。 まずは今日、隣の席の別職種のメンバーに、彼らが見ている「製品の景色」について聞いてみることから始めてみませんか？ 製品解像度を上げることは、意思決定の質を上げるだけでなく、結果として“お客様の業務が止まらない/迷わない”体験に直結すると自分は思っています。 記事を読んでラクスのプロダクト部に興味を持ってくださった デザイナー／PdM の方 は、ぜひカジュアル面談からご応募ください。 ※プロダクトマネージャーのカジュアル面談は、基本的に私（稲垣）が担当します！ ●採用情報 プロダクトマネージャー career-recruit.rakus.co.jp デザイナー career-recruit.rakus.co.jp

こんにちは。 株式会社ラクスで、楽楽精算のプロダクトデザインチームのリーダーをしているimamuです。 ラクスでは現在、「ベストオブブリード」戦略から「統合型ベストオブブリード」戦略へ進化を目指し、製品開発を進めています。 www.rakus.co.jp www.rakus.co.jp 私たちプロダクトデザイン組織でも、デザインガイドラインの整備やUIリニューアルを行っています。 tech-blog.rakus.co.jp note.com その一環として、UXライティングガイドラインについても共通化と各製品への浸透を目指して取り組んでいます。 でも実はこのライティングガイドライン、私たち自身が楽楽精算のプロダクト開発に関わる中で感じていた、ごく個人的な実務上の困りごとから生まれたものでした。 この記事では、現場の小さな課題感が、どのように事業戦略をプロダクトに落とす取り組みへと広がっていったのか、そのプロセスをご紹介します。 楽楽精算でぶつかった「言葉」の課題 楽楽精算ライティングガイドラインの立ち上げ なぜライティングガイドラインなのか ライティングガイドラインの判断基準 ライティングガイドラインで何が変わったか 共通ガイドラインへの進化 製品戦略とライティングガイドライン 共通化と浸透に向けた取り組み 実務での活用状況 おわりに 楽楽精算でぶつかった「言葉」の課題 楽楽精算は17年以上の歴史を持ち、400画面以上、2万社以上のお客様に使われているプロダクトです。その時々のユーザーニーズや業務環境、技術的な制約、組織体制に合わせて、数多くのエンジニアやデザイナーが文言の決定に関わってきました。 そうした積み重ねの結果、機能や画面ごとに似た意味でも異なる用語が使われている、トーンが異なっているといった状況が多く発生していました。 表現揺れの例 〇〇をご確認のうえ、もう一度〜〜してください。 〇〇をご確認の上、再度〜〜して下さい。 〇〇を確認してから、改めて〜〜してください そのため、新しく文言を検討する際、どの表現を正として判断すれば良いのかが不明確で、担当者の経験や感覚に頼った議論となりがちでした。 このような状況が生み出すのは、単に検討や合意に時間がかかるという問題だけではありません。プロダクトとしてどんな体験を提供したいのか、ユーザーにどんな状態になってほしいのかといった意図を表現するという、デザイナーの価値提供そのものを難しくさせていると感じました。 そして、まずはプロダクトとして一貫した言葉を使える体制を作ろうと考えました。 楽楽精算ライティングガイドラインの立ち上げ なぜライティングガイドラインなのか 一貫した言葉を使うために、まず整理したのは既存文言の調査手法の確立でした。当時は現在のようなAIツールもなく、過去にどんな表現が使われているのかを確認するだけでも手間がかかり、デザイナー自身で完結できない場面も多くありました。その結果、十分に調べきれないまま判断せざるを得ないこともありました。 そのため、まずは私自身でコードを調べ、デザイナー自身が文言を調査できるよう、調査手順や資材の整備を行いました。 それにより文言検討のスピードや精度は一定改善しましたが、それだけでは根本的な解決にはなりませんでした。 過去の文言を参照できるようになっても、「これからどういう言葉を使っていくべきか」「どんな基準で判断するのか」は、依然として属人性が高いままでした。 そこで次に取り組んだのが、UXライティングガイドラインの策定です。当時、私はUI刷新プロジェクトの立ち上げと並行して携わり、チームメンバーと分担して検討を進めました。 ライティングガイドラインの判断基準 ライティングガイドラインの目的は、属人性の排除と品質の担保です。 それにより、デザイナーの検討コストを下げるとともに、サポートサイトを作成しているCSとの合意形成をより納得感を持ってスムーズに行える状況をつくりたいと考えていました。 そのため、ガイドラインは抽象的な指針ではなく、誰が見ても判断の拠り所として使えることを意識して信頼性の高いリソースを参照しました。 具体的には、社内のコミュニケーションガイドラインや、以下をはじめとした複数の書籍や公的機関によるガイドラインを参照しています。 書籍 UXライティングの教科書 日本語スタイルガイド(第3版) 公用文用字用語例集 ガイドライン 文化庁 公用文作成の考え方 文化庁 常用漢字表 この時点ではプロダクト横断で使うことを明確に見据えていたわけではありませんでしたが、結果として他のチームやプロダクトとも共有しやすい基準になりました。 初版はスプレッドシートでした ライティングガイドラインで何が変わったか ガイドラインを使い始めてまず変わったのは、文言検討やレビューの進め方でした。「この表現が正しいかどうか」を感覚で考えたり、過去事例を探し回ったりするのではなく、ガイドラインを参照しながら理由を説明できるようになりました。 その結果、レビューや議論の焦点が「わかりやすそう」といった個人の感覚から、「ガイドラインの考え方に沿っているか」「なぜわかりやすいと判断できるか」といった論点に移っていきました。特にCSとの文言調整においては、判断の根拠が明確になったことで、合意形成にかかるコストが大きく下がったと感じています。 また、デザイナー自身にとっても、毎回ゼロから考えなくてよくなったことで、検討のスピードが上がりました。文言に悩む時間が減った分、UIや体験の設計といった本来注力すべき検討に時間を割けるようになり、結果として担当できる案件や工程の幅が広がっていきました。 共通ガイドラインへの進化 製品戦略とライティングガイドライン ちょうどこの頃、会社としての製品戦略も「統合型ベストオブブリード」へと舵を切りました。その結果、プロダクト単体ではなく、シリーズ全体で一貫した体験を提供することが、より強く求められるようになっていきました。 それに応えて、UI刷新や共通デザインガイドラインの立ち上げといった取り組みもはじまり、UIコンポーネントやレイアウトについては一定の一貫性を担保できる仕組みができあがっていきました。 こうした中、次に課題として浮かび上がってきたのが「言葉」の扱いでした。UIの構造や使われ方が共通化されていく一方で、文言だけが個別最適のままでは、体験としての一貫性を保つことが難しくなります。 そこで、共通のライティングガイドラインを組み込み、UIコンポーネントやデザイン原則、デザインパターンと合わせて参照できる状態を目指しました。 共通化と浸透に向けた取り組み まず行ったのは、各製品におけるライティングの扱われ方や、ガイドラインの有無、運用状況を整理することです。製品ごとに歴史や体制、課題感が異なる中で、どこまでを共通化できそうか、どこは個別性を残すべきかを整理しました。また、共通化を進めるうえで、検討フローをどう設計すべきかも把握する必要がありました。 そうした整理を進める中で、楽楽精算のライティングガイドラインをベースとして選びました。信頼性の高いリソースに基づいていること、他職種との合意形成を前提にしていること、安定した運用実績があったことが理由です。 楽楽精算のガイドラインをたたき台として、プロダクト固有の要素を分離し、共通化できる観点や考え方を抽出しました。そして、各プロダクト固有の用語や言い回しは禁止するのではなく、それぞれ固有のガイドラインとして参照できる仕組みを作りました。 また、UI/UXの共通化をより組織に浸透させるため、楽楽精算のライティングガイドラインやデザイン原則、UIコンポーネントの策定に直接関わっていないメンバーにもライティングの共通化を推進してもらいました。 現在はさらにデザイナー全員が参照しやすいよう、AIによる可読性の向上やツール整備を進めています。 実務での活用状況 こうした取り組みの結果、楽楽従業員ポータルに代表される新規プロダクトでは、共通のガイドラインに基づいたコンポーネントやレイアウト、用語やトーンを使用し、統一感のある体験を提供できるようになりました。 今後はさらに既存プロダクトについても、既存の体験の良さを活かしつつ、統一感のある使いやすい体験を提供できるよう取り組みを進めています。 おわりに 振り返ってみると、この取り組みは最初から「事業戦略に貢献しよう」と考えて始めたものではありませんでした。出発点は、楽楽精算の実務の中で感じていた、言葉に関する小さな違和感でした。 デザイナーが事業戦略に関わる方法は、必ずしも大きな意思決定の場に直接参加することだけではありません。日々の実務で生まれる判断を構造化し、再現できる形にしていく。その積み重ねが、結果として事業戦略をプロダクトに落とし込むことにつながっていくのだと思います。 この記事で書いた取り組みや判断が、UI/UXデザイナーの事業的価値を考える際の参考になれば幸いです。 もしこの記事を読んで、ラクスでのプロダクトづくりやデザインの関わり方が気になったら、採用情報も覗いてみてください。まずは気軽に、カジュアルにお話しできたら嬉しいです。 career-recruit.rakus.co.jp

こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） tech-blog.rakus.co.jp 昨年、「 オペレーショナル・エクセレンス――業務改革（BPR）の理論と実践 」を読み、2026年に入り、たまたまイベントで同じ話題があったので、自分なりに整理するために記事を書こうと思います。 www.docswell.com 1. はじめに 2. 優良企業が持つ「3つの価値基準」 1.プロダクト・イノベーション（Product Innovation） 2.カスタマー・インティマシー（Customer Intimacy） 3.オペレーショナル・エクセレンス（Operational Excellence） なぜ「3つ全て」を目指してはいけないのか 3. なぜPdMは「オペレーショナル・エクセレンス」を軽視するのか オペレーショナル・エクセレンスは「守り」ではなく「最強の攻め」 4. PdMが再定義すべき3つの戦略アプローチ ① オペレーショナル・エクセレンス戦略： ② カスタマー・インティマシー戦略： ③ プロダクト・イノベーション戦略： 5. プロダクトマネージャーは「機能」ではなく「利益構造」を作る 結論：オペレーショナル・エクセレンスはあらゆる現場で必要である 1. はじめに アメリカのコンサルタントであるマイケル・トレーシー氏とフレッド・ウィアセーマ氏が1995年に著書『 ナンバーワン企業の法則 』の中で提示されている、優良企業に共通する3つの戦略的指標として以下を挙げています。 カスタマー・インティマシー　良い顧客をつかむ プロダクト・イノベーション　良い製品を生む オペレーショナル・エクセレンス　業務で利益を生む 「プロダクトマネージャー（PdM）」という職種において、自分として憧れるのはいつだって「 プロダクト・イノベーション 」です。 iPhoneのような革命的なデバイス、あるいはChatGPTのような世界を変えるAI。誰も見たことのない機能を実装し、技術力で市場を圧倒する──。そんな「製品の力」で勝つストーリーは魅力的ですし、PdM冥利に尽きると感じています。しかし、あえて厳しい現実を直視するところから始めたいと思います。 今の日本の市場環境において、「プロダクト・イノベーション」だけで勝ち続けられる企業がどれだけあるでしょうか？ 機能はすぐに模倣され、技術的な優位性は瞬く間にコモディティ化します。初期の先行者利益は、後発の大資本や、より効率的な組織にあっという間に差を詰められてしまうのが常です。 私はこれまでの経験を通じて、感じていることがあります。 事業を継続的に存続させ、さらに成長させるために真に必要なのは、派手なイノベーションよりも、「オペレーショナル・エクセレンス（業務の卓越性）」である、と。 今回は、書籍『 オペレーショナル・エクセレンス 』（田中陽一 著）などで語られる「3つの価値基準」というフレームワークを補助線に、これからのPdMが持っているとよいのでは？という考え方についてまとめます。 2. 優良企業が持つ「3つの価値基準」 まず、企業の競争優位性を語る上で欠かせない「3つの価値基準（The 3 Value Disciplines）」について整理してみます。マイケル・トレーシーらが提唱したこの理論では、市場のリーダー企業は以下の3つのうち「どれか1つ」に卓越しており、他の2つでも「業界平均以上の水準」を維持しているとされます。 1.プロダクト・イノベーション（Product Innovation） 価値: 「製品」そのものが最高であること。 特徴: 最新技術、革新的な機能、デザイン性。他社には作れない製品を市場に投入し続ける力。 2.カスタマー・インティマシー（Customer Intimacy） 価値: 「顧客との関係」が最高であること。 特徴: 顧客ごとの個別ニーズへの対応、手厚いサポート、長期的なパートナーシップ。「私のことを誰よりもわかってくれる」という信頼。 3.オペレーショナル・エクセレンス（Operational Excellence） 価値: 「業務プロセス」が最高であること。 特徴: 低コスト、便利、早い、正確、ストレスフリー。購入から利用までのプロセスが極限まで効率化・標準化されている状態。 なぜ「3つ全て」を目指してはいけないのか 「最高の製品を、最高のサポートで、最安値で提供する」。 一見理想的に見えますが、リソースが分散し、全てが中途半端になる「スタック・イン・ザ・ミドル（どっちつかず）」の状態に陥ります。ここで重要なのは、「自分たちの勝ち筋はどれか？」を明確に定義することだと感じています。 そして、多くのWebサービスやSaaS、B2Bプロダクトにおいて、最も再現性が高く、かつ強固な競合優位性となり得るのは「 オペレーショナル・エクセレンス」 なのではと感じています。 3. なぜPdMは「オペレーショナル・エクセレンス」を軽視するのか 多くのPdMは、どうしても「①プロダクト・イノベーション」にリソースを割きたいと感じますし、自分もこれまでそうでした。「新機能」「AI活用」「特許技術」といった言葉は魅力的です。 一方で、「オペレーショナル・エクセレンス」は地味です。 業務フローの標準化、マニュアルの整備、オンボーディングの自動化、問い合わせ削減、API連携の強化……。これらは「機能」としてプレスリリースを出しにくく、ユーザーの目にも止まりにくい。 しかし、顧客がサービスを選ぶ理由を因数分解してみます。 特にB2Bや実用系サービスの場合、顧客の本音はこうです。 「すごい機能はいらないから、迷わず使いたい」 「担当者と仲良くしたいわけじゃなく、面倒な業務を早く終わらせたい」 「導入コストが安くて、社内稟議が通りやすいものがいい」 これらは全て、製品の「革新性」ではなく、 提供プロセスの「卓越性（オペレーショナル・エクセレンス）」 に対するニーズです。 オペレーショナル・エクセレンスは「守り」ではなく「最強の攻め」 オペレーショナル・エクセレンスを「コスト削減（Cost Cut）」と混同してはいけないと感じています。オペレーショナル・エクセレンスとは、 「競合が模倣できない仕組み」 そのものです。 例えば、ある企業が素晴らしい新機能をリリースしたとします。競合他社は、その機能を3ヶ月あればコピーできるかもしれません。 しかし、その企業が持つ「誰が売っても売れる営業プロセス」「問い合わせが来ないほど洗練されたUI」「ミスが起きない開発フロー」といった 裏側のオペレーションをコピーするには、数年単位の組織変革が必要 になります。つまり、 オペレーショナル・エクセレンスこそが最も深い「Moat」 になるのでは？と思います。 4. PdMが再定義すべき3つの戦略アプローチ では、オペレーショナル・エクセレンスを軸に据えたとき、PdMは具体的にどう動くべきか？ 「3つの価値基準」を再解釈し、PdMのアクションプランに落とし込んでみます。 ① オペレーショナル・エクセレンス戦略： テーマ： 「摩擦ゼロ（Frictionless）」と「標準化の強制」 ここでのPdMのミッションは、 「顧客が製品を知り、使い始め、定着するまでのコスト」を極限まで下げる ことです。 徹底した標準化（Config, not Custom）： 顧客の「あれもこれもできる」という要望に応えるのは、一見親切に見えて、実はオペレーショナル・エクセレンスを破壊します。PdMは勇気を持って「No」と言わなければなりません。「業界のベストプラクティスはこれです」と提示し、顧客の業務をプロダクトに合わせて変えてもらう（標準化する）。これにより、開発・保守・サポートのコストを劇的に下げ、その分を価格や品質に還元するのです。 「自走型プロダクト」の実現： 営業やCSが説明しなくても使えるUI/UXを目指します。マニュアルを読まなくても直感的に操作できること。これが究極のオペレーショナル・エクセレンスです。「サポートが手厚い」ことよりも、「サポートがいらない」ことの方が、現代においては価値が高いと感じます。その状態において＋αのサポートこそ武器となると感じています。 ② カスタマー・インティマシー戦略： テーマ：「スケーラブルな親密さ」 オペレーショナル・エクセレンス重視の場合、一対一のベタ付き対応（ハイタッチ）はコスト構造上できません。しかし、インティマシー（親密さ）を捨てるわけではありません。「データと仕組み」で代替するのです。 データドリブンな先回り： 「最近ログインしていない」「特定の設定で詰まっている」といった状況をデータで検知し、自動でフォローメールを送る、あるいは画面上にガイドを出す。人間が電話をかけるのではなく、プロダクトが「あなたのつまずきに気づいていますよ」と語りかける設計です。 コミュニティの活用： 顧客同士が助け合う場を作ること。これも、企業の工数をかけずに顧客満足度（所属感）を高める高度な戦略です。 ③ プロダクト・イノベーション戦略： テーマ：「入力ゼロ（Zero Input）への進化」 ここでのイノベーションは、「新しいことができる」ではなく「やらなくていい」を作るために使います。 「作業の消滅」を目指す： AIや新技術を導入する目的はただ一つ。「ユーザーの作業を減らすこと」です。 例えば、精度の高いAI-OCRを入れるのは、「すごい技術」を見せるためではなく、「手入力」という不快な作業を消し去るためです。 UXのモダナイゼーション： 機能表には載らない「サクサク動く」「スマホで見やすい」といった品質（非機能要件）への投資です。これは地味ですが、レガシーな競合に対する強力なイノベーションとなり得ます。 5. プロダクトマネージャーは「機能」ではなく「利益構造」を作る これからのPdMに求められるのは、単に「仕様書を書くこと」でも「アジャイル開発を回すこと」でもありません。 「プロダクト、顧客対応、業務プロセス、これら全て（End-to-End）を含めた『勝てる仕組み』を設計すること」 です。プロダクト・イノベーションだけで勝てる企業は、私が知る限りでは少ないように感じています。 一方で、オペレーショナル・エクセレンスを極め、そこに適切なインティマシーとイノベーションを組み合わせている企業は、不況下でも強く、利益を出し続けているように感じます。 結論：オペレーショナル・エクセレンスはあらゆる現場で必要である 「うちはイノベーションで売っているから関係ない」 そう思う現場こそ、私の経験上では危険なように思います。イノベーションで一時的に注目を集めても、それを顧客に届けるプロセスが非効率であれば、利益は出ません。サポートがパンクし、開発がバグ修正に追われ、やがて組織が疲弊します。 逆に、オペレーショナル・エクセレンスという強固な土台があれば、そこで生まれた余剰リソース（金・人・時間）を、次のイノベーションへの投資に回すことができます。オペレーショナル・エクセレンスは「守り」ではなく、 「次の攻め」を生み出すためのエンジン なのです。 もしあなたが今、PdMとして「次にどんな機能を作るべきか」悩んでいるなら、一度視点を変えてみるのもよいかもしれません。 「どうすれば、顧客がこの機能を『説明なし』で使えるようになるか？」 「どうすれば、社内の開発・運用プロセスがもっと『ラク』になるか？」その問いの先にこそ、持続可能なプロダクトの未来があるはずです。 地味で泥臭い「オペレーション」の中にこそ、プロダクトマネジメントの本質が眠っているように思います。 記事を読んでラクスのプロダクト部に興味を持ってくださった デザイナー／PdM の方 は、ぜひカジュアル面談からご応募ください。 ●採用情報 プロダクトマネージャー career-recruit.rakus.co.jp デザイナー career-recruit.rakus.co.jp

こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） tech-blog.rakus.co.jp 以前は自社の戦略について書きましたが、今回は視点を変えてみます。 これまで大手・ベンチャー・外資など様々な企業で社内システムに触れてきたユーザーとしての経験、そして現在バックオフィス系SaaSに携わっている提供者としての知見。 これらを踏まえて、自分なりに整理してみました。 目次 はじめに：SaaSの普及と、残された「巨大な壁」 第1章：前提となる「企業の基幹システム」4つのアーキテクチャ 1. Fit to Standard（ERP一本足打法） 2. Two-Tier ERP（2層構造：ERP × SaaS） 3. Composable ERP（レゴブロック型） 4. SaaS Unbundling（脱SaaS・完全内製回帰） 第2章：なぜ「SI」や「AI × BPO」だけでは届かないのか SI（システムインテグレーション）の課題 ── 「要件定義」の壁 AI × BPOの課題 ── 「ブラックボックス化」の壁 第3章：現場を変える「専属シェフ」 ── Forward Deployed Engineer (FDE) 第4章：システムをつなぐ「万能翻訳機」 ── 中間システムとOntology 「データ」に「意味」を与える (Ontology) 異なる言語を翻訳する「万能翻訳機」 第5章：AI時代の新しいアーキテクチャ ── 「自律的AI」への道 AIが「働く」ための地図 おわりに：バックオフィス・プロダクトの解像度を高める はじめに：SaaSの普及と、残された「巨大な壁」 ここ10年で、日本のSaaS市場は劇的な進化を遂げました。クラウド上の優れたツールを契約し、IDを発行すれば、その日から最新のUI/UXで業務ができる──。これが「当たり前」となり、多くの企業で生産性が向上しました。しかし、この成功法則が通用しない領域が依然として存在します。それが、巨大な歴史と複雑な業務構造を持つ「エンタープライズ企業」の基幹業務領域です。 「SaaSを導入したけれど、既存の基幹システムとデータがつながらない」 「現場独自の複雑なオペレーションが、標準機能ではカバーしきれない」 「結局、CSVデータを手作業で加工してアップロードする業務が残った」こうした声は、SaaSベンダーとエンタープライズ企業の双方が抱える深い悩み（ペイン）です。なぜ、便利なSaaSが増えても、現場の苦しみはなくならないのか。その解像度を高めるためには、まず現在企業が置かれている「システム・アーキテクチャの現在地」を知る必要があると思っています。 本記事では、企業の基幹システムが辿ってきた自分なりに整理した「4つのアーキテクチャ」と、既存の「SIやBPO」が抱える課題を整理した上で、その全てを突破するために現れた新しいアプローチ──「専属シェフ（FDE）」と「万能翻訳機（中間システム）」について自分なりに市場の状況を踏まえて解説をまとめてみました。 これは単なるツールの話ではなく、これからのバックオフィスプロダクトが向かうべき、ひとつの進化系統樹の話と思ってもらえればと思います。 第1章：前提となる「企業の基幹システム」4つのアーキテクチャ 「専属シェフ」や「万能翻訳機」という新しい概念を理解するために、まずは現在、エンタープライズ企業がどのようなシステム構造の上に成り立っているのか、その類型を見ていきましょう。大きく4つのパターンに分類されます。 1. Fit to Standard（ERP一本足打法） 最も伝統的かつ、かつての「理想形」とされたモデルです。SAPやOracleといった巨大なERPを導入し、会計・人事・販売・在庫など、企業のあらゆるデータを一つの巨大なシステムで管理します。 特徴： 「業務をシステムに合わせる」思想。データが一元管理されるため、経営層には理想的です。 課題： 現場にとっては「使いにくさ」が壁になります。UI/UXよりもデータ整合性が優先されるため、単純な経費精算にも多大な工数がかかります。また、日本固有の商習慣に合わせるための追加開発（アドオン）により、保守コストが高騰しがちです。 2. Two-Tier ERP（2層構造：ERP × SaaS） 現在、多くの日本企業が採用している現実解です。「本社やコア業務（会計など）は重厚なERPで守り、現場業務（労務、SFAなど）は軽快なSaaSで攻める」というハイブリッド構成です。 特徴： 守りと攻めのバランス型。現場はモダンなSaaSを使えるため、生産性が上がります。 課題： 「データの分断」が最大のネックです。社員マスターがERPにもSaaSにも点在し、それらをつなぐために「月末にCSVを吐き出し、手加工して取り込む」というアナログ作業が残ります 3. Composable ERP（レゴブロック型） Two-Tierをさらに推し進め、巨大なERPを置かずに「各業務における最強のSaaS（Best of Breed）」をレゴブロックのように組み合わせてシステム群を構成する考え方です。 特徴： 「会計はfreee」「人事はSmartHR」「営業はSalesforce」のように最適解を選べ、変化に強い構成です。 課題： インテグレーションの難易度が極めて高い点です。API連携がうまくいかないとデータがサイロ化（孤立）し、全体が見えなくなります。強力な情シス（コーポレートエンジニア）組織が不可欠です。 4. SaaS Unbundling（脱SaaS・完全内製回帰） AIの進化により、近年テック企業を中心に注目され始めた「揺り戻し」です。「SaaSは機能過多で高い。AIを使えば自分たちで必要なシステムを安く作れるのではないか？」という発想です。 特徴： 汎用SaaSを使わず、自社DBの上にAI支援で独自アプリを構築します。コスト削減と業務への完全適合がメリットです。 課題： 「作った人しか直せない」という属人化リスクと、セキュリティや品質保証をすべて自社で担う重責が発生します。 欧州フィンテック大手Klarnaが有名な例です kigyolog.com 第2章：なぜ「SI」や「AI × BPO」だけでは届かないのか 上記の4つのアーキテクチャには、それぞれ一長一短があります。「あちらを立てればこちらが立たず」の状況です。 この課題を解決しようとする際、企業が次に検討するのは、 伝統的な「SI（システムインテグレーション）」か、あるいは近年台頭してきた「AI × BPO（AIを活用した業務委託）」 だと思います。しかし、エンタープライズの「ラストワンマイル」においては、これらもまた決定打になり得ない現実があるように思います。 SI（システムインテグレーション）の課題 ── 「要件定義」の壁 SIは「建物を建てる（＝システムを作る）」ことには長けています。しかし、SIモデルの前提は「要件が固まっていること」です。 「今の業務をそのままシステム化してください」と依頼しても、現場の業務は複雑怪奇なマクロや暗黙知で動いており、誰も正解を知りません。結果、要件定義に半年かかり、完成した頃にはビジネス環境が変わっている──。これが「ウォーターフォール型の限界」です。 AI × BPOの課題 ── 「ブラックボックス化」の壁 一方で、「AIを使って業務ごとアウトソースする（AI × BPO）」というアプローチも増えています。これは即効性がありますが、本質的には「人の作業をAIに置き換えただけ」です。 業務プロセス自体がブラックボックス化し、社内にデータ資産やノウハウが蓄積されません。また、AIが誤った判断（ハルシネーション）をした際、背後にあるデータ構造（オントロジー）が整備されていないため、原因究明が困難になります。 「SIのように外から作る」のでもなく、「BPOのように外に出す」のでもない。 既存のSaaS群も、SIも、BPOも解決しきれなかった「断絶」。これを埋めるために必要なのが、 「内側に入り込み、業務を回しながらシステムを進化させる」 という、第3のアプローチがでてきています。 第3章：現場を変える「専属シェフ」 ── Forward Deployed Engineer (FDE) そこで登場するのが、 FDE（Forward Deployed Engineer） という概念です。 彼らは「SIer」とも「BPOスタッフ」とも異なります。あえて言うなら、 「エンジニアリング能力を持った、現場専属の解決請負人」 です。「調整」ではなく「実装」で解決する。 SIerが「仕様書」を作る間に、FDEは「プロトタイプ」を作ります。 BPOが「マニュアル通り」に作業する間に、FDEは「マニュアルを不要にする自動化」を行います。彼らは顧客のオフィスの最前線（Forward）に入り込み（Deployed）、以下のように動きます。 APIがない？ → 「ならDBのダンプから直接データパイプラインを作ります」 現場のエクセルが複雑？ → 「そのロジックをPythonで解析し、システムに移植します」 SIのような「納品して終わり」ではなく、BPOのような「作業代行」でもない。 既存の冷蔵庫（レガシーシステム）にある食材（データ）を、その場で極上の料理（モダンな業務フロー）に調理して提供する「専属シェフ」。このアジャイルなアプローチは、全体最適の大改修ではなく“詰まりやすい部分”から小さく改善を重ねることで、エンタープライズの組織・プロセスの制約下でも変革を進めやすくします。 第4章：システムをつなぐ「万能翻訳機」 ── 中間システムとOntology FDEという高度人材が活躍するためには、彼らが振るう「包丁」となるシステム基盤が必要です。それが「中間システム」であり、その核となる「Ontology（オントロジー）」です。 「データ」に「意味」を与える (Ontology) 従来のデータベースは「行と列」の羅列に過ぎません。SIで開発するシステムや、AI × BPOで使うツールも、往々にして「その業務専用のデータ定義」になりがちです。 しかし、中間システムにおけるOntologyは、データそのものではなく「業務の実体（Concept）」を中心にデータを再定義します。 従来： Table_A.col_1 と Table_B.id を結合（人間が都度判断） Ontology： Customer has many Contracts（データ自体が意味を持つ） 現実世界の業務の関わり合い（コンテキスト）をそのままデータ構造として定義することで、システムは裏側の複雑なDB構造を知らなくても、「顧客の契約状況を教えて」と問うだけで正しいデータを引き出せるようになります。 異なる言語を翻訳する「万能翻訳機」 エンタープライズには、SAPやOracle、野良エクセルなど、異なる言語（プロトコル）で話すシステムが乱立しています。 ここに「 中間概念（データやシステム）」を配置することで、レガシーとモダンをつなぐ「万能翻訳機」 としての役割を果たさせます。 入力（レガシー）： 古いシステムからFDEがパイプラインでデータを吸い上げる。 処理（翻訳）： 吸い上げたデータをOntologyに基づいて「意味のある情報」に変換・統合する。 出力（モダン）： AIエージェントやSaaSが、整理されたデータにアクセスする。 この「中間概念(データやシステム)」が存在することで、企業は巨大な基幹システムをリプレイスすることなく（＝冷蔵庫を買い替えることなく）、最新のAI活用（＝プロの料理）を享受できるようになります。 第5章：AI時代の新しいアーキテクチャ ── 「自律的AI」への道 この 「FDE × 中間概念（Ontology）」 という構造は、これからのバックオフィスプロダクトにおいて、AIを活用するための必須条件となります。 AIが「働く」ための地図 生成AIやAIエージェントが実業務で機能するためには、コンテキスト（文脈）が必要です。単にマニュアルを学習させるだけでは不十分で、「今、この瞬間の会社の状態」を正確に把握していなければなりません。 中間システム上のOntologyは、まさに 「AIにとっての地図」になります。 「A社の請求書が遅れている」という事実だけでなく、「A社は重要顧客であり、過去に同様のケースでは担当者が電話でフォローしていた」という文脈をAIが理解できて初めて、AIは単なるツールを超え 、「自律的なエージェント」として機能します。 つまり、中間システムを構築することは、単なるデータ統合ではありません。 SIのように「箱」を作るのでもなく、BPOのように「人」で埋めるのでもなく、「企業そのものをデジタルツイン（デジタルの双子）化し、AIが自律的に働ける環境（ワークスペース）を整えること」なのです。 おわりに：バックオフィス・プロダクトの解像度を高める 「Fit to Standard」から「SaaS Unbundling」まで、企業のシステムは揺れ動いてきました。しかし、どの時代、どのアーキテクチャにおいても、「データをつなぎ、業務を流す」という本質的な課題は残されたままでした。 「専属シェフ（FDE）」と「万能翻訳機（中間システム）」のアプローチは、既存のSaaS群やSIモデルを否定するものではありません。むしろ、過去の遺産（レガシーデータ）と未来の技術（AI/SaaS）を、技術と泥臭さで接着する新しいアプローチなのではと思っています。 古い文字コードとの戦い、複雑怪奇な勘定科目のマッピング、例外だらけの承認フロー......。 そうした「泥臭い現実」を、高度な抽象化技術（Ontology）と実装力（FDE）で包み込み、ユーザーには「魔法のようなシンプルさ」として提供する。これこそが、この領域のプロダクトマネジメント、エンジニアリングの真の面白さであり、深淵なる魅力ではないでしょうか。 それを支える中間概念（Ontology）思考。 これらはまだ耳慣れない言葉かもしれませんが、数年後には企業のバックオフィス構造を支える、当たり前のインフラになっているかもしれないと感じています。 もし、こうした「複雑さを技術で解きほぐす」アプローチや、社会の基盤となるバックオフィスプロダクトの進化に興味を持っていただけたなら、ぜひこの広大なフィールドを一緒に探求していければと思います。 この記事を読んで、現在の場所を飛び出そうと思った方やラクスのプロダクト部に興味を持ってくださった デザイナー／PdM の方 は、ぜひカジュアル面談からご応募ください。※プロダクトマネージャーのカジュアル面談は、基本的に私（稲垣）が担当します！ ●採用情報 デザイナー career-recruit.rakus.co.jp   └ デザインマネージャー career-recruit.rakus.co.jp ／アシスタントマネージャー career-recruit.rakus.co.jp

こんにちは。ラクス フロントエンド開発課 新卒2年目の持永です。 最近AI活用が進み、コードを書く速度は以前とは比較にならないほど上がりました。 そこで私は、 「AIに並列で実装を任せれば、複数の画面/機能を"爆速"で開発できるのでは？」 と考え、複数画面・複数機能を並列で進めるスタイルに挑戦しました。 並列開発の中で、工夫してうまくいった点もありました。 ただ、期待したほどの効率化には至らず、「手戻りの連鎖」と「レビュー負荷の増大」も招きました。 今回は、並列開発で工夫した点と誤算を整理し、そこから得た気づきを共有します。 1. 試したアプローチと結果 2. 工夫した点①：AI向けの仕様書と計画書を用意した 作成の流れ 効果 3. 工夫した点②：ローカル構成の整理 ポイント 効果 4. 誤算①：未確定要素による「手戻りの増加」 何が起きたか なぜ起きたか どうすべきだったか 5. 誤算②：並列ばかり意識して、レビューを含む全体最適を見失った 何が起きたか なぜ起きたか どうすべきだったか 6. まとめ 工夫した点 誤算 気づき さいごに 1. 試したアプローチと結果 使用したAIツールはCodexとClaude Codeです。 私が担当しているプロダクトのフロントエンド開発チームは二人体制で進めていました。 試したアプローチとしては、約1ヶ月半の実装期間で主に画面単位（一覧画面、詳細画面、編集画面など）でコンフリクトが起きない範囲を見極めつつ、4〜5画面を並列で進めました。 結論から言うと、直列で進める前提で立てていた見積もりを約1週間ほどオーバーしてしまいました。 2. 工夫した点①：AI向けの仕様書と計画書を用意した AIに正確に実装させるかつ人間側が進捗と作業範囲を把握することを目的に、AI向けの仕様書と実装計画書を用意しました。 作成の流れ 1. フロントエンド向け仕様書の作成 案件の情報（要求仕様や概要設計などの上流仕様書、Figmaのリンク、API定義）を材料に、フロントエンド実装に必要な情報だけを抽出した仕様書をAIで作成 2. 仕様書のレビュー・修正 AIが出力した仕様書を自分でレビューし、不足や誤りがあれば修正を指示して内容を整形 3. 実装計画書の作成 整形した仕様書をもとに、実装計画書をAIと共に作成 4. 計画書に沿った実装 実装計画書に沿って、AIに実装を進めてもらう 実装計画書(イメージ) - [x] 1. コンポーネントの基本構造を作成 - [x] 2. API呼び出し処理を実装 - [ ] 3. バリデーションロジックを追加 ← 今ここ - [ ] 4. エラーハンドリングを実装 - [ ] 5. ローディング状態の表示を追加 効果 計画書をチェックリスト形式にしたことで、AIが今どこを実装しているのかが一目でわかるようになりました。 並列で複数の機能を進めていても、それぞれの計画書を見れば「機能Aは3番目のステップ」「機能Bは5番目で完了間近」といった進捗を把握しやすくなりました。 結果として、作業を切り替えるたびに私が進捗を思い出したり確認したりする手間が減りました。 3. 工夫した点②：ローカル構成の整理 AIへの参照範囲の説明コストを下げつつ、並列開発の作業切り替えを分かりやすく素早く行うことを目的に、ローカルの資材配置を整理していました。 git worktree などで複数ブランチを同時に触ると、作業ディレクトリが増えていきます。 その状況でAIに、「案件や機能ごとに、現状のフロントエンド実装がバックエンド実装やAPI仕様と整合しているか」を確認させるとき、参照させる範囲や前提（どのブランチ/どの資材なのか）を的確に渡すための手間が増えてしまいます。 そこで、案件/機能ごとにフロントエンド/バックエンド/API仕様の資材をひとまとまりにしつつ、別途「バージョン確定時点の固定セット」も置く、という形にしていました。 この構成自体もAIに指示して組んでもらいました。 ローカルディレクトリ構成(イメージ) ＊ 担当プロダクトはポリレポ構成（フロントエンド・バックエンド・API仕様がそれぞれ別リポジトリ）で開発されています。 workspace/ ├── vX.Y.Z/ │ ├── epic-1/ # 案件ごと │ │ ├── feature-a/ # 主に機能/画面ごと │ │ │ ├── AGENTS.md # ブランチ指定、役割等の説明 │ │ │ ├── CLAUDE.md # ブランチ指定、役割等の説明 │ │ │ ├── plan.md # 実装計画書 │ │ │ ├── frontend/ │ │ │ ├── backend/ │ │ │ └── api-spec/ # API定義 │ │ ├── feature-b/ │ │ │ └── ... │ │ └── spec-epic-1/ # 案件の仕様 │ └── fixed-vX.Y.Z/ # 確定資材（ブランチ/コミット固定） │ ├── frontend/ │ ├── backend/ │ └── api-spec/ └── templates/ └── spec_template.md #仕様書のテンプレート ポイント 各feature直下に配置したAGENTS.mdやCLAUDE.mdにて、「このブランチで作業すべき」「このディレクトリ内のapi-specは今回開発したい案件の確定済みのAPI定義である」といった前提情報をAIに伝えるようにしていたことで、AIによる意図しないブランチ変更や誤った参照を減らすことができました。 効果 この構成にしたことで、AIに依頼するときに「どこを見てほしいか」を一言で指定しやすく、横断的な参照もしてもらいやすくなりました。 例えば「このバージョンのこの範囲で、フロントエンド/バックエンド実装とAPI仕様の不整合箇所を見てほしい」といった依頼を、細かいブランチなどの指定を毎回することなく依頼できるようになりました。 結果として、開発中のAPI仕様や実装との整合性チェックや、バージョンごとの不具合調査における原因切り分けといった場面での横断的な分析で、この整理が役に立ちました。 4. 誤算①：未確定要素による「手戻りの増加」 開発段階では、画面の文言や共通仕様が完全には確定していないこともあります。 その状態で複数の機能を並列で進めていき、次のような事態が起きました。 何が起きたか 実装途中で「文言の変更」や「仕様の微調整」が発生 文言が少し変わるだけでも、実装計画書の該当箇所をすべて修正する必要があった 並列で実装していた他の機能にも同じ変更が関係する場合、そちらの計画書も修正が必要に 「資料の修正 → AIへの再依頼 → 生成物の差分確認」という往復が複数の作業で同時に発生し、手戻りが連鎖していきました。 なぜ起きたか AIになるべく正確に実装させようと実装計画書をAIと共に調整していく際に、細かく書きすぎていたことが主な原因でした。 並列で動かしているほど、確定していない要素の影響が広がりやすくなります。 細かすぎる実装計画書を作成したために小さな変更が入るだけで周辺資料の調整コストが積み上がり、結果として全体の効率が落ちてしまいました。 どうすべきだったか 並列開発そのものが悪いのではなく、「後で変わりやすいもの」と「早めに固めたいもの」を切り分けるべきだったと考えます。 具体的には、以下の点が挙げられます。 文言のように後で直せるものは差分を小さく保つか、Figma上の文言を正として計画書にはリンクのみを記載して参照先を分離しておく。 変更されやすい要素を最初から細かく指定しすぎず、揺れにくい部分（ロジックや設計）から先に積み上げる計画にする。 5. 誤算②：並列ばかり意識して、レビューを含む全体最適を見失った もう一つの問題は、並列で進めることに意識が向きすぎて、レビューまで含めた「全体としての進めやすさ」を考えきれていなかった点です。 何が起きたか 複数を並行して進めていたため、最初のPRを出すまでに時間がかかった その間、レビュワーはレビューできる対象がない状態が続いた 複数のレビュー依頼がほぼ同時期になり、レビュワーへの負荷が集中 指摘対応も同時期に重なる 自分以外から見ると進捗が把握しづらい状態に なぜ起きたか 自分としては「手を止めない」ことを優先して作業を積み上げがちになっていました。 AIを活用することで自分の実装ペースだけは維持できてしまうため、レビュワーとのペースのズレに気づきにくくなっていました。 どうすべきだったか 並列で進めるなら、なおさらPRの粒度・順番・レビュー依頼のタイミングを「自分の都合」だけで決めず、レビュワーと認識合わせした上で進めるべきでした。 具体的には、以下の点が挙げられます。 先に固めたいロジックや設計だけを小さく切って早めに見てもらうことを留意して、並列で進める優先順位を決める。 レビューが走っている間に次の作業を進めつつ、指摘対応が滞らない余白も確保する。 6. まとめ 工夫した点 AI向けの仕様書と計画書（チェックリスト形式）を用意したことで、並列で進めていても各機能の進捗状況が一目で把握できた。 AIが参照しやすいようにローカル構成を整理したことで、開発中のAPI仕様や実装との整合性チェックや、不具合の原因切り分けがやりやすくなった。 誤算 細かすぎる実装計画書を作成して並列で進めた結果、「資料修正 → AIへの再依頼 → 差分確認」の往復が連鎖した。 PRの粒度やタイミングが極端になり、レビュー負荷と待ちが増えた。 気づき 今回の経験を振り返ると、「手戻りを減らす計画」「レビュワーとの連携の意識」といった内容は、基本的なことばかりでした。 AIによって上がった実装スピードを過信して、その「当たり前」を見失っていたことに気づきました。 今回の挑戦を踏まえた反省点は以下の通りです。 計画書に変わりやすい要素を細かく書きすぎない 文言はFigmaを参照させるように指定したり、仕様に絡む部分は仕様書側に記載することで、仕様変更時の「資料修正 → 再依頼 → 差分確認」の往復を減らす。 並列で進める上での優先度を留意する レビューも含めて、どの粒度・順序で進めるべきかを着手前に計画/認識合わせしておく。 さいごに AIのおかげで、実装自体は確かに速くなりました。 ただ、「速く作れる」ことと「全体が早く終わる」ことは別だと、今回改めて実感しました。 仕様が揺れやすい部分は揺れる前提で切り分け、レビューが滞らない粒度と優先度で小さく出して、確実にマージしていく。 結果的にチーム全体の進みが良くなるような進め方を考える力は、AIで開発を行っていく上でも変わらず求められていくものだと考えます。 同じようにAI活用×並列開発を試している方の参考になれば幸いです。

はじめに 最近、社内に検証用のハイスペックGPUマシンが導入されました。 このマシンを実際に触ってみると、想像以上に大きなモデルをローカル環境で動作させることができ、 「これまで実現が難しかったことでも実現していけそうだ」という手応えがありました。 これまでAI関連のタスクとしては、書類からの特定項目の読み取りに取り組んできました。 この領域では、学習データを用意してトレーニングした特定タスク特化型のOCRモデルをサーバーに配置し実運用してきた実績があります。 一方で、近年のLLMの進化を見るにつけ、「汎用LLMでもうまく使えば、特化型モデルに近い性能が出せるのではないか」という疑問も湧いてきます。 もしそれが可能であれば、 学習データを大量に用意する モデルを個別に学習させる といった、これまで当たり前だったモデル開発の考え方そのものが変わってくるかもしれません。 オープンソースのLLMであれば、実行毎にAPIの料金がかかることもありません。 そこで今回は、オープンソースのLLM(→ローカルLLM)を用いた書類の項目読み取りを実際に試し、従来の特化型モデルと性能を比較する検証を行いました。 はじめに GPUマシンとAIモデルの概要 GPUマシン構成 ローカルLLMの概要 特化型AIモデルの概要 ローカルLLM（gemma3）の挙動と与えた指示 プロンプト設計の工夫 コストについて 精度比較結果 処理時間の違い 改善案 おわりに GPUマシンとAIモデルの概要 GPUマシン構成 検証に使用したGPUマシンは、次の構成です。 NVIDIA GB10 搭載デスクトップPC ローカル環境とはいえ、LLMを動かすにはそれなりの計算資源が必要になりますが、このマシンであれば比較的大きなモデルも動かせました。 ローカルLLMの概要 今回利用したローカルLLMは googleのgemma3です。 huggingface.co テキストと画像を入力できるマルチモーダルLLM パラメータサイズは 27B Hugging Face からモデルをダウンロードして利用 量子化は行わず、フル精度モデルを使用 ロードには Hugging Face の pipeline を用いました。 pipe = pipeline( "image-text-to-text" , model= "google/gemma-3-27b-it" , device= "cuda" , ) 最新のGPT系モデルと比べると性能は控えめですが、gemma3-27Bモデルはローカルで動かせるモデルとしては高性能な方だと思います。 特化型AIモデルの概要 比較対象として用いたのは、これまで実運用してきた従来型の特化モデルです。 LLMではない、いわゆる従来型のAIモデル 書類を入力すると、あらかじめ定義した項目を読み取る 特定タスク向けのデータで学習済 他タスクへの転用はほぼ不可 特定タスク向けに学習を行っており、プロダクト水準の高精度を出せる点が強みです。 ローカルLLM（gemma3）の挙動と与えた指示 gemma3を実際に使ってみると、以下のような特徴が見えてきました。 推論能力や指示理解力はそれなりに高い 一方で画像からの文字認識精度はそこまで高くない (キリル文字が出現したりします) そのため、比較的精度の良いOCRの結果を別途用意し、LLMに補助情報として与える 形を取りました。 今回は、以下の理由から easy-ocr を利用しました。 pypi.org pipインストールだけで手軽に使える オープンソースで、追加コストがかからない ローカルマシン上で処理を実行できる Google Vision API など高精度な有料OCRを使う選択肢もありましたが、 今回は、 API利用コストが発生しない 一連のOCR処理を完全にローカルで完結させられる という条件を重視して、オープンソースOCRを採用しました。 プロンプト設計の工夫 汎用的なシステムプロンプトに加えて、読み取りたい項目ごとに専用のプロンプトが与えられるよう、ソースコードを作成しました。 複数項目をまとめて読み取らせるプロンプトも試しましたが、その場合は精度が安定せず、1項目ずつ質問する方式が最も結果が良さそうでした。 プロンプト例 system_message = "You are a helpful assistant who analyzes images and answers questions about their content." task_message = """ You will be given an image and a question. Your task is to analyze the image and provide an answer to the following question based on the content of the image. Do not include any information that is not explicitly present in the image. You can refer to the OCR results from the image to help answer the question. Instructions: * You should be careful to use the OCR results as the OCR results may not be accurate. * Do not use the OCR results when the OCR results do not seem to be correct and rely on your visual analysis of the image instead. ... """ ※ OCR結果はあくまで参考情報として扱わせ、OCR結果が誤っていると思わしき場合はgemma3自身の読み取り結果を優先するよう指示しています。 項目毎の質問は、次のように追加指示を与えています。 q_message_issue_date = "When is the issue date of this document?" \ " \n Extra instructions:" \ " \n * The issue date must be in a format like 'YYYY-MM-DD'." コストについて 今回の検証で発生したコストは、主に以下の通りです。 機器代：約70万円〜 OCR：オープンソースモデルを利用しているため、実行毎のコストはなし gemma3をプロダクトレベルでデプロイすることを考えると、 GB10マシンを複数台用意する もしくは EC2 の「p5.48xlarge」などのハイスペックなGPUインスタンスを利用する (p5.48xlargeの場合、1年間継続で利用すると1月あたり31,641ドルくらいかかりそうです) といった構成が必要になりそうですが、このあたりはまだ詳しい調査が必要そうです。 精度比較結果 gemma3 と特化型モデルについて、同一書類から 4項目を読み取るタスクで精度を比較しました。 特化型モデルの精度(正解率)を 1 とした場合、gemma3 の結果は次の通りです。 項目1 項目2 項目3 項目4 0.83 0.91 0.78 0.7 書類読み取りに特化していない汎用モデルでありながら、特化型モデルの7〜9割程度の精度が出ているのは、なかなか健闘していると言えそうです。 ただし、特化型モデルがプロダクト水準の精度を実現しているのに対し、gemma3はこのままではプロダクト利用には厳しい印象です。 処理時間の違い 1書類あたりの処理時間にも大きな差がありました。 特化型モデル：1〜2秒程度 gemma3：3〜4分程度 精度だけでなく、処理時間の面でも現状ではプロダクト利用は難しいというのが現状です。 改善案 gemma3はオープンソースのモデルのため、ローカル環境で精度改善を行う余地があります。 とはいえ、27Bクラスのモデルをフル精度でファインチューニングするのは、計算リソース的に厳しいです。 次のようなアプローチで精度改善を検討するのが現実的だと思います。 LoRA などのアダプター学習 プロンプト設計のさらなる改善 OCRとの連携方法の工夫 このように現状でそこそこの精度があり、精度改善の余地も残されています。 「学習データを大量に集めて専用モデルを作る」以外の選択肢が、少しずつ現実味を帯びてきているのを実感できた検証でした。 おわりに 今回の検証を通じて、ローカルLLMでも工夫次第で、従来の特化型モデルに迫る精度が実現できるとわかりました。 現状ではローカルLLMで特化型モデルを代替するような段階ではありませんが、将来のモデル設計やシステム構成を考えるうえで、大きなヒントになる結果だったと思います。 ローカルで大きなLLMを動かせる環境が整いつつある今、 「まずはLLMで試してみる」 そんな選択肢が、これから少しずつ現実的になっていくのかもしれません。

こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） tech-blog.rakus.co.jp これまで組織やマネジメントについて書くことが多かったので、今回はプロダクトマネージャーらしく「プロダクト戦略」について書こうと思います。 ラクスに入社して約4年半。マルチプロダクト展開をしているtoB SaaS企業に入社し、これまでPdMのマネージャーとして複数のプロダクトに携わってきました。自社や競合、市場（国内・海外）を見ていく中で、私なりの理解や整理を言語化していこうと思います。 まだ、業界歴4年と浅く、多分に私自身の解釈が入っているため、一般的な理解との差分があるかもしれませんが、その点はご理解ください。そして本記事の一番の目的は、当社ラクスに興味を持っていただいているプロダクトマネージャー、デザイナー、エンジニアの皆さまにとって、ラクスへの理解を深める一助となればと思います。 ※本記事は、公開情報を踏まえた私個人としての理解と将来的な妄想も含んでいます 目次 ■プロダクトを取り巻く３つの課題 1.戦略 ■ マルチプロダクト戦略 ■ ベスト・オブ・ブリード戦略 2.ターゲットとポジショニング 3.国内の社会情勢 ■プロダクト戦略 ■「カレーの材料」で読み解くプロダクト戦略 ●こだわりの専門店 ：ベスト・オブ・ブリード型戦略 ① スイート型戦略（＝巨大スーパー） ② ベスト・オブ・ブリード型戦略（＝こだわりの専門店） ●進化した専門店街・マルシェ ：統合ベスト・オブ・ブリード型戦略 ●お買い物サポート・代行サービス：AI戦略 ① 各プロダクト内のAI化（＝超優秀な専門スタッフ） ② プロダクトをつなぐ「AIエージェント」（＝自律して走る連携役） ●スマートシティ・ビジネスエコシステム （妄想） ●専属シェフと万能翻訳機 (余談) 武器①：FDE（Forward Deployed Engineer） 〜お客様の懐に入り込む「専属シェフ」〜 武器②：オントロジー思考の中間システム 〜システムをつなぐ「万能翻訳機」〜 ■ まとめ ■プロダクトを取り巻く３つの課題 1.戦略 ラクスは「マルチプロダクト戦略」をとっています。 この戦略は、 多くの企業が採用してきた王道の戦略 であると理解しています。一方で昨今、 Rippling （米国の急成長SaaS）などが提唱する新しいスタイルとして、 「コンパウンド戦略」 という考え方が登場しています。 blog.allstarsaas.com これは、 「創業時から複数のプロダクトを同時に展開し、共通の基盤やデータ、UX（ユーザー体験）で連携させることで、顧客の複合的な課題を一気に解決し、市場での競争優位性を高める戦略」 を指します。 国内でも、この戦略を採用する企業が増えています。 それぞれのプロダクトづくりの観点で比較すると、以下のようになります。 そして、ラクスは 「ベスト・オブ・ブリード戦略」 も取っています。この名称、自分がラクスの特徴を紹介する時にも使っています。耳馴染みのない言葉だと思います、自分もラクスに入社して初めて知りました。 「特定のドメイン領域の課題に特化し、お客様のペインを解消する戦略」 と理解してもらえればと思います。 この言葉は、情報システム部門の方が社内ツールを導入する際に、どのような戦略を取るかを語る文脈でよく使われます。対比される戦略としては、 「スイート戦略」 があります。 両者を比較すると、以下のようになります。 ここまでを整理すると、ラクスは 「マルチプロダクト戦略」 と 「ベスト・オブ・ブリード戦略」 を取っています。これまでの比較表をご覧いただくと分かるとおり、それぞれを お客様視点 で見た場合、以下のような課題があります。 ■ マルチプロダクト戦略 プロダクトごとにUXが異なり、学習コストが高くなりやすい ■ ベスト・オブ・ブリード戦略 ツールごとにデータが分断されがちで、API連携やiPaaSなどによるつなぎ込みが必要になる ツールごとに操作感が異なるため、ユーザーが慣れるまでに時間がかかる場合がある 複数ベンダーとの契約が必要となり、更新時期やID管理が複雑になりやすい 2.ターゲットとポジショニング 日本国内のIT投資に関する調査を見ると、以下のような傾向があります。 国内の IT投資額の約80％はエンタープライズ企業 によるもの 国内の IT支出の成長率は、エンタープライズが約＋8％ （SMBは約＋6％） 従業員1,000名以上の企業数は、国内で数千社程度 にとどまっている これらを踏まえると、日本のIT投資市場は概ね次のような構造になっていると言えます。 3.国内の社会情勢 2030年には、以下のような状況が予測されています。 人口の3人に1人が高齢者 　　　　国民の約31.8％が65歳以上になります。 働く人の減少 　　　　生産年齢人口（15〜64歳）がさらに減少し、多くの産業で人手不足が深刻化します。推計では、2030年には約644万人の人手不足が発生すると言われています。 ■プロダクト戦略 ここまで、3つの課題について整理してきました。ラクスでは、これら3つの課題を解決していくために、現在、そして次期中期経営計画において、これまでのプロダクト戦略を大きく進化させていきます。 その方針は、以下のようなイメージです。 以下は「 2026年3月期 第2四半期決算説明資料 」になります。 ■「カレーの材料」で読み解くプロダクト戦略 ここまで、当社のプロダクトを取り巻く課題と戦略について、できるだけ分かりやすく整理してきました。ここからは、さらにイメージしやすくするために、身近なシチュエーションに置き換えつつAIに作成してもらった画像を使って説明していきます。 テーマは、 「今夜の夕食（カレー）の材料を、どうやって買い揃えるか？」 で考えてみてください。 ●こだわりの専門店 ：ベスト・オブ・ブリード型戦略 ① スイート型戦略（＝巨大スーパー） イメージ： 巨大なスーパーマーケットに行き、野菜、肉、スパイスを一つのカートに入れて、レジでまとめて買うスタイル。 メリット： とにかく楽です。移動も会計も一回で済みます。 デメリット： 「お肉はもっと上質なものがいいのに、ここには普通のしか売っていない…」というように、個々の品質に妥協が必要な場合があります。 ② ベスト・オブ・ブリード型戦略（＝こだわりの専門店） イメージ： 街を巡り、「野菜はあの八百屋」「肉はあの老舗精肉店」と、それぞれのプロがいる専門店で最高の一品を買い集めるスタイル。 メリット： 出来上がるカレー（業務効率）は最高品質になります。現場の社員が「使いやすい！」と感動するのはこちらです。 デメリット： 3つのお店を回って、3回会計をする必要があります。導入や管理の手間がかかります。 私たちはこれまで、後者の「専門店スタイル」を貫いてきました。 なぜなら、日本のバックオフィス業務（経費精算、メール配信、明細発行など）は非常に細かく、 「スーパーの標準品」では現場の不満が解消できないから です。 「経費精算の領収書チェックが面倒くさい」 「インボイス制度に対応した細かい処理がしたい」 こうした現場の深い悩み（ペイン）を解決するには、汎用的なツールではなく、その業務に特化した 「切れ味鋭い専門ツール」 が必要でした。だからこそ、「楽楽精算」や「楽楽明細」といった専門店（プロダクト）を磨き上げてきたのです。 ただ、これにも「1.戦略」で紹介したような課題があります。そこで私たちが目指すのが、 「進化した専門店街・マルシェ」（統合ベスト・オブ・ブリード型） への進化です。 ●進化した専門店街・マルシェ ：統合ベスト・オブ・ブリード型戦略 「専門店の品質はそのままに、裏側で手をつなぐ」 これは、巨大スーパーマーケット（スイート型）に戻るということではありません。 「専門店の最高品質」は維持したまま、「バラバラで不便」という弱点だけを解消する アプローチです。 イメージしてください。 「八百屋」と「精肉店」と「スパイス屋」が、実は裏口で繋がっていて、お互いに連絡を取り合っている状態です。 お客様にとって：  最高品質の材料（機能）が手に入るのに、まるで一つの店で買い物をしているかのように、データ連携やセキュリティ管理がスムーズに行えます。これを実現できると 『ベスト・オブ・ブリード型』でありながら『スイート型』のようなメリットをお客様に提供する ことができます。 また、「2. ターゲットとポジショニング」で挙げた課題である 「エンタープライズ領域をより強化する」 ことにも、大きく貢献できるポテンシャルを秘めています。 エンタープライズ企業には、創業以来使い続けている巨大な基幹システムや、複雑な組織構造があります。そこにバラバラの「専門店」を持ち込むと、「データのつなぎ込みが大変」「管理が煩雑になる」といった壁に直面します。 一方で、 「スイート型」では、大企業の多様なニーズに応えることが難しくなるケースもあり ます。 「統合ベスト・オブ・ブリード型」であれば、すべて当社ラクスの製品を使ってもらうのが理想ではありますが、そうでない場合でも、お客様は別の製品（別の専門店）を併用することが可能です。 これが、 当社ラクスが挑戦している「統合ベスト・オブ・ブリード型」の考え方 です。 ●お買い物サポート・代行サービス：AI戦略 これと並行して取り組んでいるのがAIの活用です ① 各プロダクト内のAI化（＝超優秀な専門スタッフ） まずは、それぞれの「専門店」の中に、AIを搭載します。 これは 、「その道のプロである、超優秀なスタッフ」を雇う ようなものです。 経費精算のAIスタッフ： 領収書をパシャっと撮るだけで、「これは交際費ですね」「金額はこれですね」と、面倒な入力を全て代行してくれます。 問い合わせ管理のAIスタッフ： お客様からのメールを読んで、「この件なら、こういう返信案が良いですよ」と自動で下書きを作ってくれます。 これにより、各業務の「面倒くさい」が徹底的に削減されます。 ② プロダクトをつなぐ「AIエージェント」（＝自律して走る連携役） そして次に目指すのが、この 専門店同士をつなぐ「AIエージェント」 の開発です。 これが、 統合ベスト・オブ・ブリード戦略の真骨頂 です。 これまでは、人が「経費精算のデータをダウンロードして、会計システムにアップロードする」といった作業をしていました。 これからは、 AIエージェントが自律的に動き、ツール間を走り回り ます。 シーン： 「楽楽精算」で交通費が確定した瞬間、AIエージェントがそれを検知します。 ↓ AIエージェントが勝手に「楽楽販売」の担当AIに連絡します。 ↓ 「この交通費はA社への訪問分だから、A社の原価データに紐付けておきますね」 このように、 人が指示しなくても、AIエージェント同士が会話をして、裏側で業務を完結させてしまう。 大企業の複雑な業務フローであっても、AIエージェントが潤滑油となって、システム全体を滑らかに動かしていくのです。 ●スマートシティ・ビジネスエコシステム （妄想） ここからは、私の妄想ですが 進化した専門店街・マルシェ（統合ベスト・オブ・ブリード型戦略） お買い物サポート・代行サービス（AI戦略） といった取り組みをここまで実現できた暁には、以下のような世界が実現できるのではないかと考えています。 もはや、個人や家族のためのカレーではなく、 街全体の人々に対して、一人ひとりの好みに合わせたカレーを、好きなときに供給できる そんな未来が来るといいな、と思っています。 ●専属シェフと万能翻訳機 (余談) 「統合ベスト・オブ・ブリード型」は、 エンタープライズ企業にも寄与できる可能性があると前段で述べましたが、おそらくそれだけでは十分ではない とも感じています。 大企業には、何十年もかけて継ぎ足されてきた レガシーシステム（巨大な冷蔵庫） 複雑な社内政治（キッチンのルール） が存在しているからです。 こうした「壁」を突破するために、昨今では 新たな武器を持つ企業 が現れ始めています。ここでは、その話にも触れていこうと思います。 昨年から、アメリカの Palantir（米国発の急成長AI／データ分析企業） が注目を集めています。彼らが実際に取り組んでいる内容については、こちらをご覧ください。 submarine-c.com note.com ここからは私なりの理解での内容となります。 武器①：FDE（Forward Deployed Engineer） 〜お客様の懐に入り込む「専属シェフ」〜 一つ目は、 FDE という特別なエンジニア部隊の投入です。大企業への導入は、ただソフトを渡して「あとは説明書を読んでね」では成功しません。 FDEは、お客様の現場の最前線（Forward）に配備（Deployed）されます。 彼らは、お客様の複雑なデータ構造や業務フローを解析し、 「お客様専用のつなぎこみ」をその場で調理 します。 「データが汚くてつながらないなら、私たちが整備します」 そう言って泥臭い課題を技術で解決する、 FDEのようなプロフェッショナル集団 が、導入を成功に導きます。 武器②：オントロジー思考の中間システム 〜システムをつなぐ「万能翻訳機」〜 二つ目は、技術的なアプローチである「オントロジー（概念モデル）」の活用です。 大企業の基幹システムと、最新のSaaSを直接つなごうとすると、言葉が通じずにスパゲッティのように絡まってしまいます。 そこで私たちは、間に「中間システム（オントロジー層）」を構築します。 役割： 基幹システムが話す「古い独自言語」を、一度この中間システムが受け取り、「誰でもわかる共通言語（オントロジー）」に翻訳します。AIエージェントたちは、この整理された言葉だけを見て仕事をします。 これにより、 大企業の重厚な基幹システムには指一本触れずに、最新のAIエージェントたちが走り回る環境 を作ることができるのです。 ■ まとめ ここまで、ラクスのプロダクトを取り巻く課題と今後の戦略、そしてそれをかみ砕いた内容に加え、後半ではやや妄想や余談も交えながらまとめてきました。いかがでしたでしょうか。 この記事を読む前よりも、ラクスのプロダクトを取り巻く環境や、私たちがどんな未来を目指しているのかについて、少しでも理解が深まっていれば嬉しいです。 非常にチャレンジングではありますが、だからこそ取り組む価値のあるテーマであり、今後のラクスの成長、そして日本の業務を前に進めることにつながる挑戦だと考えています。 もしこの記事を読んで、 プロダクト戦略を本気で考えたい 複雑な課題に向き合いながら、長期的な価値をつくりたい PdM、デザイナー、エンジニアとしてプロダクトづくりに深く関わりたい と感じていただけたなら、ぜひこちらもご覧ください。 note.com note.com 一緒にこの挑戦を進めていける仲間と出会えることを、楽しみにしています。 デザイナー／PdM の方 は、ぜひカジュアル面談からご応募ください。※プロダクトマネージャーのカジュアル面談は、基本的に私が担当します！ ●採用情報 デザイナー career-recruit.rakus.co.jp   └ デザインマネージャー career-recruit.rakus.co.jp ／アシスタントマネージャー career-recruit.rakus.co.jp

はじめに こんにちは！ エンジニア３年目のTKDSです！ 今回はLLMアプリケーション開発におけるプロンプトの取得と管理について書きました。 LLMを利用したアプリケーションのプロンプト管理は多くの方が悩んでる問題だと思います。 そこで、開発中や運用時に重要となるプロンプト配信の可用性、プロンプト切り替えのしやすさ、何が今動いているか把握のしやすさの観点などから管理方法と取得方法を整理してみたいと思います。 個人の意見ですので異論は認めます。 はじめに プロンプトの管理方法 管理方法 プロンプトの取得方法 取得方法 管理方法x取得方法の組み合わせ 　組み合わせの上で考えること 組み合わせ例 まとめ プロンプトの管理方法 バージョニングやプロンプトの保存場所など、プロンプトを保管・管理する方法について考えていきます。 今回はスプレッドシートなどで管理、git管理、プラットフォームで管理3パターンを想定しました。 ここでいうプラットフォームはLangfuseなどのプロンプト管理機能があるソフトウェアを指しています。 管理方法 スプレッドシートなどで管理 メリット 管理が楽 見やすい リアルタイムでの更新が可能 共同編集しやすい コメントなどで意見など書き込みやすい 非エンジニアにプロンプトを見てもらう場合にも共有しやすい デメリット コピペが必要 誤爆編集などがある アプリ側からの参照が面倒 アプリに埋め込む仕組みは別途考える必要がある git(github)管理 メリット PRなどで管理すれば変更履歴やコメント内容を追える 使い慣れたツール タグなどを活用して特定バージョンのプロンプトの組み合わせを固定できる ビルドパイプラインから利用しやすい デメリット 共同編集しにくい github上などでコメントを募集する場合、アカウントが必要。非エンジニアに見てもらう場合、アカウント発行が必要で余計な費用がかかる プラットフォームで管理 メリット 専用ツールなのでプロンプト管理に特化してる バージョニングに対応してる APIがあるので、CDパイプラインから利用しやすい プレイグラウンドが付属してる場合もあるので、試行錯誤がしやすい デメリット 高度な権限管理は有償プランだったりする場合が多い プラットフォームの維持コストがかかる バックアップ・レストアの方法を整備しておく必要がある プロンプトの取得方法 次はビルド時やアプリデプロイ時のプロンプトの取得方法についてです。 こちらも3つ考えてみました。 リアルタイム取得方式、事前埋め込み、後から環境変数やファイルで注入の３つです。 取得方法 リアルタイム取得方式 メリット 変更をすぐに反映できる デメリット リクエストごとに取りにいくのか、一定時間で更新するようにするのかなどアプリ側で考慮事項が増える 実現可能な手段（例） プラットフォームからAPI経由で取得 ファイルをオブジェクトストレージなどにホスト 事前埋め込み メリット ビルド時にプロンプトが固定されることによって、コンテナイメージが同じ間は変更によって動作が変わらない コンテナイメージを変えればすぐに切り戻せるので運用が楽 デメリット 変更に毎回ビルドが必要（これは工夫によってある程度解決できる） コンテナレジストリにイメージがたくさん溜まってしまう（これは工夫によってある程度解決できる） 実現可能な手段（例） ビルド時にプロンプトをプラットフォーム、オブジェクトストレージ、gitリポジトリなどから取得して埋め込み コードに直書き 後から環境変数やファイルで注入 メリット 簡単に変更できる バージョニングは別手段でやる必要がある。 コピペしてこないといけない デメリット シークレット経由で埋め込む場合、環境変数を変えたらPodの再起動が必要 実現可能な手段（例） (k8sの場合) ボリュームマウントやconfigmap経由で渡す ３つともメリット・デメリットがあります。 個人的にはコンテナイメージの不変性が確保できるため、事前埋め込みが良いと思っています。 特に本番環境以降は開発エンジニアが一切触れない場合、インフラエンジニアにコンテナイメージのタグ差し替えだけ依頼すれば良いので、新たに習得してもらうことがなく運用がまわりやすいイメージを持っています。 ここまで管理方法と取得方法を列挙したので、組み合わせを考えていきます。 管理方法x取得方法の組み合わせ 　組み合わせの上で考えること これまで列挙した内容から、プラットフォームで管理が一見良さそうに見えますが、開発中に頻繁更新する場合に手間だったり、本番では誰が変更するのか、どこまで触っていいのかなど判断が難しいところです。 また、プラットフォームについて十分に耐障害性を考慮しないと単一障害点になりえます。 そこで現状の考えとして開発・運用工程を考慮した上での使い分けを考えてみました。 （あくまで個人の意見でこれで運用しているわけではありません。） 前提として、コンテナイメージをビルドしてアプリをデプロイしていることとします。 組み合わせ例 最初にあげた開発中や運用時に重要となるプロンプト配信の可用性、プロンプト切り替えのしやすさ、何が今動いているか把握のしやすさの観点も加えて組み合わせとその理由を考えていきます。 工程はローカルで開発中、ステージング環境、本番環境の３つに分けてます。 ローカルで開発中 開発中の試行錯誤 スプシ管理 x アプリ稼働、後から環境変数やファイルで注入 考慮観点 プロンプト配信の可用性 開発環境なので考慮外 環境でのプロンプト切り替えのしやすさ コピペするだけなので簡単 何が今動いているか把握のしやすさ アプリが参照してるファイルや.envをいじるので基本的に一意になるはずなため把握しやすい 変更時のホットリロード等の仕組みを用意しておくともっと間違えにくくなるかも ステージング環境 評価中 プラットフォーム x アプリ稼働、後から環境変数やファイルで注入 結合テストなど 本番と同等（後の項目で記載します） 考慮観点 プロンプト配信の可用性 開発環境なので考慮外 環境でのプロンプト切り替えのしやすさ プラットフォームで配信するプロンプトを切り替えるだけなので簡単 何が今動いているか把握のしやすさ ログなどで担保する。開発環境よりは一定下がる 本番環境 簡単に変更できることを重視する場合 組み合わせ プラットフォーム x アプリ稼働後から環境変数やファイルで注入 備考 プラットフォーム自体をHA構成にする 取得できなかった場合にコンテナイメージ内にあるプロンプトにフォールバックするなどの対策をする 考慮観点 プロンプト配信の可用性 プラットフォームが単一障害点になりうるので備考にあるような対策を行う 環境でのプロンプト切り替えのしやすさ プラットフォームで配信するプロンプトを切り替えるだけなので簡単 何が今動いているか把握のしやすさ 開発環境よりは一定下がる、ログなどで可視性を担保する 不変なことを重視する場合 組み合わせ git管理 x 事前埋め込み 備考 管理自体にはプラットフォームを使うのもあり、ビルドパイプラインでコンテナイメージにバンドルして作成する コンテナイメージごとに何が入ってるかわかり管理が簡単 簡単に切り替えができないのはデメリットだが、開発者が簡単に挙動を変えられてしまうのは問題なので、許容すべき バージョンごとにイメージビルドせずに切替したい場合、まとめてバンドルしてビルドし、環境変数などで使用バージョンを切り替えるのもあり 考慮観点 プロンプト配信の可用性 事前にバンドル済みなため、本番で取得できないことはない 環境でのプロンプト切り替えのしやすさ コンテナイメージを差し替えるだけなので簡単 複数バージョンをバンドルする場合は環境変数などを書き換えるだけなので簡単 何が今動いているか把握のしやすさ コンテナイメージごとに一意になるので把握しやすい。ただし、イメージタグ名などで工夫すべき 複数のバージョンを入れてバンドルする場合は組み合わせ間違いなどが起こらないように注意すれば大丈夫そう 以上が個人的な開発・運用工程ごとのプロンプト管理・配信方法の使い分けの案でした。 基本的には変更のしやすさと間違ったプロンプト変更がされないようにすることのトレードオフで、開発中は変更のしやすさ・本番環境ではコンテナイメージの固定による不変性の安定を重視してます。 あとは地味にプロンプト取得方法のところで書いてる「インフラエンジニアにコンテナイメージのタグ差し替えだけ依頼すれば良いので、新たに習得してもらうことがなく」の部分が大事だと思ってます。 新たに習得してもらうのはドキュメント作成や相手の学習用の工数などがかかるため、できるだけ今まで通りの手順でシンプルに運用できる方法が望ましいです。 まとめ 今回はLLMアプリケーションにおけるプロンプトの扱いについて検討してみました！ プロンプトの管理・運用に悩んでる方はぜひ参考にしてみてください！

2026年1月21日（水）、ラクス主催のテックイベント 「RAKUS AI Meetup Vol.2」 をオンライン開催いたしました。 ラクスの開発組織では、「顧客志向」を大切にしています。 新しい技術を導入すること自体を目的とするのではなく、「この技術が、誰のどんな業務をどれだけ楽にできるのか」を起点に、日々の開発や改善に取り組んでいます。 RAKUS Meetupは、そうした顧客志向の開発実践から得られた知見を、エンジニア自身の言葉で共有する場として開催しています。 今回の「RAKUS AI Meetup Vol.2」では、ラクスが全社を挙げて取り組んでいるAI活用について、「プロダクトAI実装」「AI駆動開発」「AI組織体制」の3つの観点から発表しました。 本記事では、当日の発表内容をダイジェストでお届けします。 1. 全エンジニアのAI活用状況を可視化する～Lookerを用いたアンケート分析と今後の推進策～ セッションのポイント AI活用によって生まれた価値 2. 仕様駆動開発の組織的定着に向けた取り組み セッションのポイント AI活用によって生まれた価値 3. 出してみてわかったAIエージェントプロダクトの舞台裏 セッションのポイント AI活用によって生まれた価値 まとめ 1. 全エンジニアのAI活用状況を可視化する～Lookerを用いたアンケート分析と今後の推進策～ 登壇者：野間 由貴（開発管理課） 最初のセッションは、ラクス開発本部全体でAI活用をどう推進しているかという組織的なアプローチについてのお話です。 speakerdeck.com セッションのポイント AI技術の進化が速く「理想」の定義が困難であるため、無理に理想を追わず、全エンジニア300名超の「現在地」を可視化することに方針転換した。 「人・こと・気持ち」の3軸でアンケートを設計し、Looker Studioを用いて誰もが使える分析基盤を構築した。 可視化により各チームごとの活用度合いの違いが明確になり、マネジメント層が優先順位を決定するための判断材料として機能した。 AI活用によって生まれた価値 開発組織全体のAI活用レベルを底上げすることで開発効率が高まり、お客様への価値提供のスピードと質が向上した。 2. 仕様駆動開発の組織的定着に向けた取り組み 登壇者：小栗 朗（開発課長） / 山田 智史（バックエンドエンジニア） 続いては、「楽楽電子保存」開発チームによる、開発プロセスそのものをAIに適応させた事例です。 speakerdeck.com セッションのポイント 実装フェーズにおいて、レイヤーごとに13種類のカスタム指示を用意することで実装品質の標準化とハルシネーションの抑制を図った。 オフショア開発（ベトナム）との連携において、AIでPRの説明文やアーキテクチャ図を自動生成することで、日本側のレビュー負荷を大幅に軽減した。 これらの取り組みにより、PRのサイクルタイムを約1/3に短縮し、開発量自体も170%増という大幅な生産性向上を実現した。 「要件定義~設計～実装」を分断しない世界観を目指してプロセス改善に取り組んでいる。 AI活用によって生まれた価値 AIによる開発効率の向上や開発量増加により、お客様が求める機能や改善をよりスピーディかつ大量にお届けできるようになった。 3. 出してみてわかったAIエージェントプロダクトの舞台裏 登壇者：石田 浩章（AIエージェント開発課 課長） 最後のセッションでは、2025年にリリースされた「楽楽AIエージェント for 楽楽精算」クローズドβ版の運用知見が共有されました。 speakerdeck.com セッションのポイント AIエージェント機能により、従来の経費精算業務の30%~50%の工数を削減した。 開発中に「LLMコスト」「精度」「応答速度」という3つの壁を乗り越えた。 コストの壁：過去の経費精算書を活用してLLMの推論量を大幅に削減し、コストを数十分の一まで削減した。 精度の壁：企業ごとに異なる複雑な経費精算ルールに対応するため、AIは高速なドラフト作成に特化し、正当性の担保は既存の「規定違反チェック機能（ルールベース）」に任せるハイブリッド構成を採用した。 応答速度の壁：お客様ヒアリングの結果をもとに、フローの一部を非同期処理に変更することで体感速度の課題を解消した。 AI活用によって生まれた価値 AIエージェント機能によりお客様の経費精算の手間を削減できるようになった。 まとめ 今回のミートアップでは、ラクスにおけるAIの取り組みを 「プロダクトAI実装」「AI駆動開発」「AI組織体制」の3つの観点でご紹介しました。 ご紹介した取り組みはいずれも、AIを導入すること自体を目的としたものではなく、 「お客様の業務をどうすればもっと楽にできるか」という顧客志向の視点から生まれたものです。 ラクスでは、働く人をもっと「楽！」にするため、 これからも顧客志向を軸に、AIの活用と開発プロセスの進化に取り組んでいきます。

こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） tech-blog.rakus.co.jp 「HORIZON OF KHUFU　古代エジプトへの旅」というVR作品を体感してきました。 immersivejourney.jp の方も感想を掲載していますが、非常に素晴らしい体験ができました。 note.com 自分はコロナ禍前の2019年11月エジプトのカイロへ旅をして、ピラミッドやスフィンクスを見てきました。 そんなつながりもあって、世界最大の建造物やその中を見ながら、自分の仕事と紐づけて少し書いてみようと思います。 それは『ピラミッド』を『プロダクト』として捉えて色々考えてみようという試みです。 目次 ピラミッドは史上最大のプロダクトだった ピラミッド建設における役割分担は、驚くほど現代的だった ピラミッドは「超巨大ウォーターフォール型プロジェクト」だった スクラムでピラミッドは作れたのか？ プロダクトマネージャーへの最大の学び ――「完成」ではなく「残る価値」を見る AIが発達した今、ピラミッド作成はどう変わるか？ おわりに ピラミッドは史上最大のプロダクトだった エジプトのピラミッドは、「なぜ作れたのか」「どうやって作ったのか」という技術的な驚きと同時に、 なぜ4500年以上経っても価値を失っていないのか という問いを私たちに投げかけてきます。 私は現在、ラクスというSaaS 企業で、プロダクトマネージャーとプロダクトデザイナーが所属するプロダクト部のマネージャーを務めています。 プロダクト開発に携わる立場としてピラミッドを見たとき、それは単なる古代建築ではなく、 史上最大級・最長寿命の「プロダクト開発事例」 に見えてきました。本記事では、 ピラミッド建設における役割分担 作成工程・プロセス スクラムは適用できるのか AI時代にどう変わるのか を整理しながら、 現代のプロダクトマネージャーに向けた学び としてまとめてみます。 ピラミッド建設における役割分担は、驚くほど現代的だった ピラミッドは「王の命令で人が動いた」という単純な話ではありません。実際には、明確な役割分担と責任構造が存在していたようです。 諸説ありますが、現代のプロダクト組織に当てはめると、次のように整理して捉えると学びがあります。 プロダクトオーナー ：ファラオ（王） なぜ作るのか、何を象徴するのかを決める存在 プロダクトマネージャー ：宰相（ヴィジエ） 国家全体のリソースを動かし、成功責任を負う プロジェクトマネージャー ：王の建築家・建設監督官 工程・品質・リスクを管理する実務責任者 専門職チーム ：測量官、石工、運搬班 PMO / 管理 ：書記官 人数、資材、配給、進捗を記録し「見える化」する 重要なのは、 「ビジョンを守る役割」と「現実を成立させる役割」が分離されていたこと です。これは現代の プロダクトマネージャー（価値・WHYを守る） プロジェクトマネージャー（納期・実行を守る） という関係性と、本質的に同じだったのではと思います。 ピラミッドは「超巨大ウォーターフォール型プロジェクト」だった ピラミッド建設は、現代で言えば典型的なウォーターフォールだったように思います。 高さ・方位・形は最初に決まっている 途中での作り直しはほぼ不可能 完成しない限り価値が出ない 王の治世という明確なデッドラインがある 一方で、完全な一発勝負でもなかったのでは？とも思います。 小型ピラミッドでの試行 途中で角度を変えた「屈折ピラミッド」 失敗の学習を次世代に引き継ぐ つまり、 全体はウォーターフォール、部分は反復的改善 これは現代の大規模プロダクト開発と非常によく似ています。 スクラムでピラミッドは作れたのか？ 結論から言えば、 スクラム「だけ」でピラミッドを作ることは不可能 だったのではと自分は思っています。 要件変更が許されない 失敗コストが致命的 インクリメント単位で価値を出せない ただし、 スクラム的な考え方がなければ、現代では確実に失敗する とも言えます。スクラムが有効なのは、 工法・設計の検証 精度・安全の実証 デジタルツインや管理システム といった 不可逆性の低い領域 です。 本体はウォーターフォール、「考える・試す」部分はアジャイル。 これはtoB SaaSにおいても、 コア価値・約束は固定 体験・実装は反復改善 という構造と重なります。 プロダクトマネージャーへの最大の学び ――「完成」ではなく「残る価値」を見る クフ王の大ピラミッドは、 当時のKPI（王の復活・権威の象徴）を満たし 4500年後の私たちにとっても価値を持ち続けています プロダクトマネージャーは、 今四半期のKPI 今月のリリース 直近の改善要望 に引っ張られがちです。しかし同時に、 「このプロダクトは、数年後にも意味を持つか？」「社会や顧客の前提が変わっても、価値は残るか？」 という問いを、誰よりも引き受ける役割でもあります。 私たちのBtoB SaaSでも、“社内都合のKPI”ではなく、“お客様の業務がどう良くなるか”を起点に、数年後も残る価値を選び続けたいなと思います。 AIが発達した今、ピラミッド作成はどう変わるか？ もし現代でピラミッドを作るなら、AIは確実に「PjM・PdMの仕事」を変えます。 構造解析・設計シミュレーションの高速化 スケジュール・リスクの自動最適化 進捗・品質・安全のリアルタイム監視 過去プロジェクト知見の即時活用 一方で、AIが代替できないものも明確です。 なぜ作るのかを定義すること どの価値を守り、何を捨てるか決めること 社会・顧客にとっての意味を言語化すること AIは「どう作るか」を加速するが、「なぜ作るか」は人間にしか決められない おわりに ピラミッドは、史上最大級の建築物であると同時に、史上最長寿命のプロダクトでもあります。 プロダクトマネージャーという仕事は、「作ること」よりも 「価値を未来まで運ぶこと」 に本質があります。 4500年前の人類がそれを成し遂げた事実は、現代のプロダクト開発に携わる私たちにとって、非常に示唆的ではないでしょうか。 この記事を読んで、やラクスのプロダクト部に興味を持ってくださった デザイナー／PdM の方 は、ぜひカジュアル面談からご応募ください。 ※プロダクトマネージャーのカジュアル面談は、基本的に私（稲垣）が担当します！ ●採用情報 デザイナー career-recruit.rakus.co.jp   └ デザインマネージャー career-recruit.rakus.co.jp ／アシスタントマネージャー career-recruit.rakus.co.jp