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

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

UX志向を“継続的な力”に変える鍵は「製品解像度」だと思う

マネジメント デザイン PdM

こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） tech-blog.rakus.co.jp

社内で口癖のように使っている「製品解像度」と「UX志向」について自分の思考の整理もかねて記事にまとめてみました。

  • はじめに：私たちは「誰」を見ているのか？
  • 「製品解像度」とは何か？
  • まず押さえたい：製品解像度が低いと起きる“あるある”
  • なぜ「お客様解像度」だけでは不十分なのか？
    • 質の高いアウトプットを生む土壌
  • UX志向を支える「意思決定」の力
    • 「OR」ではなく「AND」を模索する
    • 「架け橋」としての役割
    • ラクス プロダクト部としての「UX志向」
  • 製品解像度を高めるために
    • 1. 「越境」を恐れない
    • 2. 「なぜ？」を問い続ける
    • 3. プロダクトの「歴史」と「未来」を知る
  • 製品解像度が上がると何が起きるか：アウトプットの質が変わる
    • 1) 要求仕様が“外れにくくなる”
    • 2) トレードオフの説明責任が果たせる
    • 3) 「事実に基づく」文化が回りやすくなる
    • 4) “作って終わり”から“学習して伸ばす”に変わる
  • おまけ：製品解像度を上げるための「10の問い」（会議で使える）
  • おわりに：最高のUXへの近道
続きを読む

デザイナーと事業戦略をつなぐ UXライティングガイドラインのつくり方

デザイン ツール紹介 フロントエンド

こんにちは。 株式会社ラクスで、楽楽精算のプロダクトデザインチームのリーダーをしているimamuです。

ラクスでは現在、「ベストオブブリード」戦略から「統合型ベストオブブリード」戦略へ進化を目指し、製品開発を進めています。 www.rakus.co.jp www.rakus.co.jp

私たちプロダクトデザイン組織でも、デザインガイドラインの整備やUIリニューアルを行っています。 tech-blog.rakus.co.jp note.com

その一環として、UXライティングガイドラインについても共通化と各製品への浸透を目指して取り組んでいます。

でも実はこのライティングガイドライン、私たち自身が楽楽精算のプロダクト開発に関わる中で感じていた、ごく個人的な実務上の困りごとから生まれたものでした。

この記事では、現場の小さな課題感が、どのように事業戦略をプロダクトに落とす取り組みへと広がっていったのか、そのプロセスをご紹介します。

  • 楽楽精算でぶつかった「言葉」の課題
  • 楽楽精算ライティングガイドラインの立ち上げ
    • なぜライティングガイドラインなのか
    • ライティングガイドラインの判断基準
    • ライティングガイドラインで何が変わったか
  • 共通ガイドラインへの進化
    • 製品戦略とライティングガイドライン
    • 共通化と浸透に向けた取り組み
    • 実務での活用状況
  • おわりに
続きを読む

機能競争から抜け出す！PdMが再定義すべき「3つの戦略」と、持続可能なプロダクトの作り方

PdM マネジメント

こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） 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. プロダクトマネージャーは「機能」ではなく「利益構造」を作る
    • 結論：オペレーショナル・エクセレンスはあらゆる現場で必要である
続きを読む

バックオフィスプロダクトの次の進化系統樹── 基幹システム×AI時代 ビジネスアプローチ整理

AI PdM マネジメント

こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） 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が「働く」ための地図
  • おわりに：バックオフィス・プロダクトの解像度を高める
続きを読む

AIで並列開発に挑んだら、逆に効率を落とした話

AI フロントエンド

こんにちは。ラクス フロントエンド開発課 新卒2年目の持永です。
最近AI活用が進み、コードを書く速度は以前とは比較にならないほど上がりました。

そこで私は、
「AIに並列で実装を任せれば、複数の画面/機能を"爆速"で開発できるのでは？」
と考え、複数画面・複数機能を並列で進めるスタイルに挑戦しました。

並列開発の中で、工夫してうまくいった点もありました。
ただ、期待したほどの効率化には至らず、「手戻りの連鎖」と「レビュー負荷の増大」も招きました。
今回は、並列開発で工夫した点と誤算を整理し、そこから得た気づきを共有します。

  • 1. 試したアプローチと結果
  • 2. 工夫した点①：AI向けの仕様書と計画書を用意した
    • 作成の流れ
    • 効果
  • 3. 工夫した点②：ローカル構成の整理
    • ポイント
    • 効果
  • 4. 誤算①：未確定要素による「手戻りの増加」
    • 何が起きたか
    • なぜ起きたか
    • どうすべきだったか
  • 5. 誤算②：並列ばかり意識して、レビューを含む全体最適を見失った
    • 何が起きたか
    • なぜ起きたか
    • どうすべきだったか
  • 6. まとめ
    • 工夫した点
    • 誤算
    • 気づき
  • さいごに
続きを読む

モデル学習なしでもここまで読める!? ローカルLLMで挑む書類読取の現在地

AI

はじめに

最近、社内に検証用のハイスペックGPUマシンが導入されました。 このマシンを実際に触ってみると、想像以上に大きなモデルをローカル環境で動作させることができ、 「これまで実現が難しかったことでも実現していけそうだ」という手応えがありました。

これまでAI関連のタスクとしては、書類からの特定項目の読み取りに取り組んできました。 この領域では、学習データを用意してトレーニングした特定タスク特化型のOCRモデルをサーバーに配置し実運用してきた実績があります。

一方で、近年のLLMの進化を見るにつけ、「汎用LLMでもうまく使えば、特化型モデルに近い性能が出せるのではないか」という疑問も湧いてきます。 もしそれが可能であれば、

  • 学習データを大量に用意する
  • モデルを個別に学習させる

といった、これまで当たり前だったモデル開発の考え方そのものが変わってくるかもしれません。 オープンソースのLLMであれば、実行毎にAPIの料金がかかることもありません。

そこで今回は、オープンソースのLLM(→ローカルLLM)を用いた書類の項目読み取りを実際に試し、従来の特化型モデルと性能を比較する検証を行いました。

  • はじめに
  • GPUマシンとAIモデルの概要
    • GPUマシン構成
    • ローカルLLMの概要
    • 特化型AIモデルの概要
  • ローカルLLM（gemma3）の挙動と与えた指示
    • プロンプト設計の工夫
    • コストについて
  • 精度比較結果
    • 処理時間の違い
    • 改善案
  • おわりに
続きを読む

カレーの材料集めで読み解くSaaS戦略 ──「スーパー」か「こだわりの専門店」か

組織づくり PdM マネジメント

こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） tech-blog.rakus.co.jp

これまで組織やマネジメントについて書くことが多かったので、今回はプロダクトマネージャーらしく「プロダクト戦略」について書こうと思います。

ラクスに入社して約4年半。マルチプロダクト展開をしているtoB SaaS企業に入社し、これまでPdMのマネージャーとして複数のプロダクトに携わってきました。自社や競合、市場（国内・海外）を見ていく中で、私なりの理解や整理を言語化していこうと思います。

まだ、業界歴4年と浅く、多分に私自身の解釈が入っているため、一般的な理解との差分があるかもしれませんが、その点はご理解ください。そして本記事の一番の目的は、当社ラクスに興味を持っていただいているプロダクトマネージャー、デザイナー、エンジニアの皆さまにとって、ラクスへの理解を深める一助となればと思います。

※本記事は、公開情報を踏まえた私個人としての理解と将来的な妄想も含んでいます

目次

  • ■プロダクトを取り巻く３つの課題
    • 1.戦略
      • ■ マルチプロダクト戦略
      • ■ ベスト・オブ・ブリード戦略
    • 2.ターゲットとポジショニング
    • 3.国内の社会情勢
  • ■プロダクト戦略
  • ■「カレーの材料」で読み解くプロダクト戦略
    • ●こだわりの専門店 ：ベスト・オブ・ブリード型戦略
      • ① スイート型戦略（＝巨大スーパー）
      • ② ベスト・オブ・ブリード型戦略（＝こだわりの専門店）
    • ●進化した専門店街・マルシェ ：統合ベスト・オブ・ブリード型戦略
    • ●お買い物サポート・代行サービス：AI戦略
      • ① 各プロダクト内のAI化（＝超優秀な専門スタッフ）
      • ② プロダクトをつなぐ「AIエージェント」（＝自律して走る連携役）
    • ●スマートシティ・ビジネスエコシステム （妄想）
    • ●専属シェフと万能翻訳機 (余談)
      • 武器①：FDE（Forward Deployed Engineer） 〜お客様の懐に入り込む「専属シェフ」〜
      • 武器②：オントロジー思考の中間システム 〜システムをつなぐ「万能翻訳機」〜
  • ■ まとめ
続きを読む
ラクスの技術 / デザイン情報サイト
Copyright © RAKUS Co., Ltd. All rights reserved.