こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） 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

こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） tech-blog.rakus.co.jp 今回は自分がかなり苦手なテーマ 「目標設定と評価は難しい」 について書こうと思います。（カジュアル面談をすると、ここを聞かれることも多いので。） 私は現在、株式会社ラクスでPdMとデザイナー組織を見ていますが、ここに至るまでにSIer、技術サポート、そしてBtoCプラットフォームの企画・開発と、多様な立場で「目標」と向き合ってきました。 いずれの環境においても難しさは感じていますが、現在のラクスでは自分がこれまで経験したことがない状況でしたので、より難しさを感じています。 もし今、あなたが自社の評価制度にモヤモヤしていたり、これからPdMとしてキャリアを積む上で「どう評価されるのか」に不安を感じていたりするのであれば、本記事はきっと何かのヒントになるはずです。 私がラクスで過ごした4年間の試行錯誤と、現在運用している評価の仕組みについて、かなり生々しい部分まで踏み込んでお話しします。 ※本記事は自分のの経験に基づく一例で、制度や運用は組織・フェーズにより異なります 目次 比較してわかる「目標設定」の難易度格差 比較的シンプルだったSIと技術サポート 「全員野球」で乗り切れたBtoCプラットフォーム時代 なぜBtoB SaaS（SLG）の評価は難しいと感じたのか 1. ビジネスモデルの壁（SLG vs PLG） 2. 担当領域の範囲の壁（機能別組織の宿命） 3. 個人目標への落とし込み（MBOの厳格さ） ラクス流：納得感を生む目標設定のアプローチ 「あるべき姿」からのトップダウン設計 評価の「ガイドライン」を作る 具体論：PdMは「何を」目標にするのか？ 1. 事業・プロダクト貢献目標（仮説と品質の評価） 2. 組織貢献・自己成長目標（仕組みと基盤の評価） パフォーマンス評価とコンピテンシー評価の両輪 比較してわかる「目標設定」の難易度格差 まず、前提としてお話ししたいのは、業種や職種によって「目標設定のしやすさとしにくさ」が存在するという事実です。 私が経験したキャリアを振り返ると、その違いは明白でした。 比較的シンプルだったSIと技術サポート SIer時代や技術サポート時代、目標設定にそこまで頭を抱えた記憶はありません。なぜなら、見るべき指標が極めて明確だったからです。 SIer： プロジェクトの売上、利益率、納期遵守。 技術サポート： 問い合わせ対応数、解決までのリードタイム、顧客満足度（CS）。 特に外資系企業にいた頃は、グローバルで定義されたメトリクスが決まっているため、それを達成するか否かという非常にシンプルな世界でした。 「全員野球」で乗り切れたBtoCプラットフォーム時代 前職のファッションEC（BtoC）では、企画・開発・デザイナー合わせて40名弱を管掌していました。ここでは「個人目標」という細かい粒度での設定は行わず、組織全体でのゴールを掲げていました。 BtoC、かつECというビジネスモデル上、ユーザーの行動と売上がダイレクトに結びつきます。 売上直結KPI： 商品ページへの遷移率、カート投入率、購入率。 システム基盤： サイト遅延率、障害頻度。 これらを企画とエンジニアのセットチームに割り当て、 「全員で売上を作らないとサービスが終了してしまう」という危機感（良い意味での当事者意識） を共有できていました。 数字が動きやすく、フィードバックループが速いため、「ざっくりとした方向性」でも組織が機能していました。 しかし、現在私が身を置く「ラクス」のようなBtoB SaaS企業では、この勝手が大きく異なるなと感じています。 なぜBtoB SaaS（SLG）の評価は難しいと感じたのか ラクスに入社し、PdM組織のマネジメントを担うようになって直面したのは、前職までの経験が活用しづらい「3つの壁」を感じました。 1. ビジネスモデルの壁（SLG vs PLG） 最大の違いは、 ラクスがSLG（Sales-Led Growth：営業主導の成長）モデルであること です。 BtoCやPLG（Product-Led Growth：プロダクト主導の成長）のSaaSであれば、「機能改善→ユーザー行動変容→売上増」のパスが比較的短く、KPIツリーも描きやすい。 しかし、SLGモデルの「楽楽シリーズ」では以下の特性があります。 ユーザー ≠ 決裁者： 機能が良くても、導入を決めるのは別の担当者であることが多い。 リードタイムの長さ： 1つの施策をリリースしてから、それが営業活動を経て「受注」という成果になるまでに長い時間がかかる。 因果関係の遠さ ： 受注が増えた要因が、新機能のおかげなのか、営業のトーク力なのか、市場要因なのかの切り分けが困難。 つまり、「購入率＝受注率」「訪問者数＝リード数」といった単純な図式が成り立たず、 「プロダクトの価値づくり」単体での貢献を定量的に測るのが極めて難しい ということを感じました。 2. 担当領域の範囲の壁（機能別組織の宿命） 前職では開発まで含めた全体を見ていましたが、現在はPdMとデザイナーという「企画・上流」に特化した組織を見ています。エンジニアリングは別の本部が管掌しており、私の組織の目標に「開発効率」や「システム安定性」を直接組み込むことはできません。 また、事業戦略そのものは事業部長の管掌であり、PdMはその事業戦略を元にプロダクト戦略や戦術に落とし込む役割が主として担っています。関与できる範囲が限定されている中で、いかに納得感のある目標を立てるかという難しさがありました。 3. 個人目標への落とし込み（MBOの厳格さ） これが最も大きな違いかもしれません。ラクスでは半期に一度、 MBO（目標による管理） によるパフォーマンス評価を行います。つまり、 給与や賞与に直結する評価制度 です。 そのため、「なんとなく頑張った」や定性的なアピールだけでは不十分で、第三者（人事や上位層）が見ても納得できる客観性と公平性が求められます。「恣意性が疑われない」ためにも、しっかりとしたロジックが必要です。 この「担当領域の成果が見えにくい中」で「厳格な個人評価」を行う。これが、私がこの4年間向き合ってきた難題の正体です。 ラクス流：納得感を生む目標設定のアプローチ では、この難題に対して私たちはどうアプローチしているのか。4年間の試行錯誤を経て、現在運用している「型」についてお話します。 「あるべき姿」からのトップダウン設計 戦略が未整理な状態でボトムアップだけに寄せるとブレやすいと考えています。個人の想いは大切ですが、組織としてのベクトルが揃わなければ成果は出ないからです。 私は必ず以下の手順を踏んでいます。 組織目標の策定 ： 半年や1年で終わる数値目標だけでなく、数年先を見据えた「組織のあるべき姿」と言語化された「現状」をセットで定義 マネージャー（私）の目標設定 ： 組織目標を達成するための自身の目標を策定 リーダーへの展開と差配 ： 私の目標を噛み砕き、各リーダーに割り振る メンバー目標への落とし込み ： ここで初めて個人の目標 このプロセスを経ることで、メンバーは「自分の仕事が組織のどこに繋がっているのか」を迷わずに認識できます。 評価の「ガイドライン」を作る メンバーが目標設定に迷う時間を極小化するために、等級ごとの難易度や方向性のガイドラインを策定しました。 事業・プロダクト貢献目標（70-80%） ： いわゆる業務の成果。 組織貢献・自己成長目標（20-30%） ： 採用、育成、仕組み化など。 リーダー層には組織貢献の比重を高めるなど、グレードに応じたチューニングを行っています。これにより、目標設定にかかるコストを下げつつ、質の高い目標設定が可能になりました。 具体論：PdMは「何を」目標にするのか？ ここが皆さんが一番知りたいポイントかと思います。「売上に直結しない」「結果が出るのに時間がかかる」中で、PdMは何を目標に置いているのか。 結論から言えば、私たちは「 アウトカムが出る蓋然性の高いアウトプット」 を評価対象にしています。そして、“アウトカムの蓋然性が高いアウトプット”を評価する狙いは、顧客課題の解像度を上げ続け、提供価値の質を落とさないことにあります。 1. 事業・プロダクト貢献目標（仮説と品質の評価） SLGモデルにおいて、リリース直後の「売上」や「利用率」を個人の短期評価にするのは酷です（前述の通りタイムラグがあるため）。そのため、以下のプロセスを完遂し、その質を担保することを目標とします。 担当重要テーマのディスカバリーと要求仕様策定 ： 顧客課題を深く理解し、解決策としてのPRD（製品要求仕様書）を高い品質で仕上げたか。 デリバリーまでの完遂 ： エンジニアやデザイナーと協働し、仕様を落とすことなくリリースまで導いたか。 次期バージョンの計画策定 ： 確度の高いロードマップを描けているか。 ここで重要なのは、 「アウトカム（結果）」そのものではなく、「アウトカムが出る可能性があるという仮説」の精度と、それを実行する力 を評価している点です。リリースサイクルが1〜3ヶ月かかる環境では、この「仕込み」の質こそが、将来の事業成長を左右するからです。 2. 組織貢献・自己成長目標（仕組みと基盤の評価） こちらは、組織全体の生産性や再現性を高めるための活動です。 共通指標（NSM [North Star Metric：長期的な成長と成功を示す最重要指標]など）の設定 ： 開発・事業が同じ方向を向くための指標作り。 AI活用による業務の標準化 ： 生成AIを用いたPRD作成の効率化など、個人の知見を組織の資産にする活動。 ナレッジシェア ： 勉強会の主催やドキュメント化。 これらは、直接的な売上ではありませんが、 「組織が継続的に勝つための基盤」として明確に評価 します。 パフォーマンス評価とコンピテンシー評価の両輪 ここまでお話ししたのは、半期ごとの「パフォーマンス評価（MBO）」の話です。しかし、ラクスにはもう一つ、「コンピテンシー評価（行動評価）」が存在します。 パフォーマンス評価 ： 「何を」成し遂げたか（What） コンピテンシー評価 ： 「どのように」行動したか（How） note.com たとえ短期的な数値目標が未達でも、そのプロセスにおいて、その等級に求められる再現性のある行動（周囲を巻き込む力、課題発見力など）が発揮されていれば、コンピテンシー評価で報われる仕組みになっています。 この「成果」と「行動」の二軸があるからこそ、難易度の高いPdMという職種でも、納得感を持ってチャレンジし続けられるのです。 最後に：ラクスでPdMとして働くということ 「目標設定が難しい」と嘆くだけでなく、私たちはその難しさを因数分解し、システムとして運用可能な形に落とし込んできました。 もちろん、これが完成形ではありません。事業フェーズの変化に合わせて、組織目標も評価の仕方もアップデートし続けています。 ラクスのPdM組織は、単に機能を作るだけの工場ではありません。 ビジネスの複雑性と向き合い、不確実性の中で仮説を立て、組織全体を巻き込んで価値に変えていく。そのプロセス自体を楽しみ、正当に評価される環境を作ろうとしています。 もしあなたが、 「目標があいまいで、自分の成果がどう評価されているかわからない」 「BtoBの難しさに直面しながらも、より本質的なプロダクトづくりに挑戦したい」 と感じているなら、ぜひ一度カジュアルにお話ししませんか？ ここでは書ききれなかった「泥臭い試行錯誤のリアル」や、あなたのキャリアにおける悩みについても、マネージャー対マネージャーとして、あるいは先輩PdMとして、ざっくばらんにお話しできると思います。私たちの組織は、こうした「難しさ」を一緒に面白がれる仲間を待っています。 ●採用情報 デザイナー career-recruit.rakus.co.jp   └ デザインマネージャー career-recruit.rakus.co.jp ／アシスタントマネージャー career-recruit.rakus.co.jp

はじめに こんにちは、ヤマウチです。 担当しているサービスではサーバ認証に加えてクライアントの認証も行う相互認証(mTLS)も使えるようになっています。相互認証を使う場合、Webサーバにサーバ証明書、クライアントにクライアント証明書を設定することになりますが、証明書の有効期間が切れる前に証明書の更新を行う必要があります。 この記事では、クライアント証明書の更新作業を具体的な設定例を交えて説明します。また、相互認証のうちクライアントの認証を行う部分の処理をクライアント認証と呼ぶことにします。 目次 はじめに 目次 サーバ認証とクライアント認証の比較 表1. サーバ認証とクライアント認証の比較 クライアント証明書の更新作業 クライアント証明書の更新作業の例 サーバ証明書の作成 クライアント証明書の作成 nginxにサーバ証明書と新旧のCA証明書を設定 curlによるアクセス確認 終わりに サーバ認証とクライアント認証の比較 サーバ認証とクライアント認証を比較することでクライアント証明書の更新で気をつけるべきポイントが分かりやすくなると思いますので、両者を比較した表を示します。 表1. サーバ認証とクライアント認証の比較 項目 サーバ認証 クライアント認証 認証される対象 サーバ クライアント 証明書を提示する側 サーバ クライアント 証明書を検証する側 クライアント サーバ 証明書・秘密鍵の設定場所 サーバ クライアント 証明書の更新作業 サーバ クライアントとサーバ サーバ認証では証明書をサーバに設定するため、証明書を更新する場合にクライアント側の作業は必要ありません。一方、クライアント認証ではクライアントとサーバ両方の作業が必要となります。 また、対象のクライアント数が多くなるとクライアント証明書の更新を一斉に行うことが難しくなるため、新旧のクライアント証明書を使える並行運用期間を設ける必要があります。その期間中は両方のクライアント証明書を検証できるようにサーバを設定しておく必要があります。 クライアント証明書の更新作業 クライアント証明書に署名したCA証明書の有効期間により必要な作業が変わるため、長い場合と短い場合に必要な作業を説明します。 ※2026/01/01時点の状態として説明します。 (1) CA証明書の有効期間が長い場合 CA証明書の有効期間が2年残っているため、既存のCAで新しいクライアント証明書を発行します。 (2) CA証明書の有効期間が短い場合 CA証明書の有効期間が残り半年のため新しいCAを作成し、そのCAで新しいクライアント証明書を発行します。 グラフではCA証明書の有効期間を3年、クライアント証明書の有効期間を1年というイメージで記載していますが、実際の有効期間は運用ポリシーに合わせる必要があります。 クライアント証明書の更新作業の例 「(1)CA証明書の有効期間が長い場合」の新クライアント証明書の発行とWebサーバの設定方法は通常のクライアント認証を設定する場合と変わらないため、「(2)CA証明書の有効期間が短い場合」の新クライアント証明書の発行とWebサーバの設定方法を説明します。 また説明では以下のツールを使用します。 作業 ツール 証明書の作成と署名 OpenSSL Webサーバ nginx クライアント curl サーバ証明書の作成 検証用にlocalhostというサーバ名でWebサーバを立てるため、プライベートCAでサーバ証明書を発行します。 1.作業ディレクトリの作成 mkdir -p server_ca server 2.プライベートCAの秘密鍵と証明書を作成 # 秘密鍵を作成 openssl genrsa -out server_ca/ca.key 4096 # CA証明書を作成 openssl req -x509 -new \ -key server_ca/ca.key \ -days 1095 \ -sha256 \ -out server_ca/ca.pem \ -subj "/C=JP/O=Local Dev/OU=Dev CA/CN=local-dev-ca" 3.サーバの秘密鍵とサーバ証明書のCSRを作成 # 秘密鍵を作成 openssl genrsa -out server/localhost.key 2048 # CSRを作成 openssl req -new \ -key server/localhost.key \ -out server/localhost.csr \ -subj "/C=JP/O=Local Dev/CN=localhost" # SAN定義ファイルを作成 cat > server/server_san.ext <<'EOF' subjectAltName = DNS:localhost,IP:127.0.0.1 EOF 4.プライベートCAでサーバ証明書を発行する openssl x509 -req \ -in server/localhost.csr \ -CA server_ca/ca.pem \ -CAkey server_ca/ca.key \ -CAcreateserial \ -out server/localhost.crt \ -days 365 \ -sha256 \ -extfile server/server_san.ext クライアント証明書の作成 既存のCA証明書の有効期間が残り半年のため新しいCAを作成するというシナリオを再現するため、有効期間が半年と3年のCAを作成します。また、それぞれのCAでクライアント証明書を発行します。 1.作業ディレクトリの作成 mkdir -p client_ca client 2.新旧のCAの秘密鍵と証明書を作成 旧CAの秘密鍵と証明書を作成 - 証明書の有効期間は半年(180日) ※検証用に「残存期間が半年のCA」を再現するため、この旧CA証明書は -days 180 で作成します。 # 旧CAの秘密鍵を作成 openssl genrsa -out client_ca/old_ca.key 4096 # 旧CAの証明書を作成 openssl req -x509 -new -key client_ca/old_ca.key \ -days 180 -sha256 \ -out client_ca/old_ca.pem \ -subj "/C=JP/O=Example Inc/OU=Client CA/CN=example-client-ca-v1" 新CAの秘密鍵と証明書を作成 - 証明書の有効期間は3年(1095日) # 新CAの秘密鍵を作成 openssl genrsa -out client_ca/new_ca.key 4096 # 新CAの証明書を作成 openssl req -x509 -new -key client_ca/new_ca.key \ -days 1095 -sha256 \ -out client_ca/new_ca.pem \ -subj "/C=JP/O=Example Inc/OU=Client CA/CN=example-client-ca-v2" 3.クライアントの秘密鍵とクライアント証明書のCSRを作成 # 秘密鍵を作成 openssl genrsa -out client/client.key 2048 # クライアント証明書のCSRを作成 openssl req -new \ -key client/client.key \ -out client/client.csr \ -subj "/C=JP/O=Customer A/CN=customer-a" # SAN定義ファイルを作成 cat > client/client_san.ext <<'EOF' subjectAltName = URI:urn:customer:a EOF 4.新旧のCAでクライアント証明書を発行する 旧CAでクライアント証明書を発行する - 有効期間は半年(180日) # シリアルファイルを作成 echo 01 > client_ca/old_ca.srl # クライアント証明書を作成 openssl x509 -req \ -in client/client.csr \ -CA client_ca/old_ca.pem \ -CAkey client_ca/old_ca.key \ -CAserial client_ca/old_ca.srl \ -out client/old_client.pem \ -days 180 -sha256 \ -extfile client/client_san.ext 新CAでクライアント証明書を発行する - 有効期間は1年(365日) # シリアルファイルを作成 echo 01 > client_ca/new_ca.srl # クライアント証明書を作成 openssl x509 -req \ -in client/client.csr \ -CA client_ca/new_ca.pem \ -CAkey client_ca/new_ca.key \ -CAserial client_ca/new_ca.srl \ -out client/new_client.pem \ -days 365 -sha256 \ -extfile client/client_san.ext nginxにサーバ証明書と新旧のCA証明書を設定 サーバ認証用にサーバの秘密鍵と証明書を設定します。また、新旧のクライアント証明書を検証できるように新旧のCA証明書も設定します。 1.秘密鍵と証明書を配置するディレクトリを作成 mkdir -p /etc/nginx/tls 2.サーバの秘密鍵と証明書を配置する cp server/localhost.key /etc/nginx/tls cp server/localhost.crt /etc/nginx/tls 3.新旧のCA証明書を配置する nginxの ssl_client_certificate にはCA証明書を1つしか設定できないため新旧のCA証明書を結合したファイルを作成します。 cat client_ca/old_ca.pem client_ca/new_ca.pem > /etc/nginx/tls/old_new_ca.pem ※ Nginx(OpenSSL)は、ssl_client_certificate で指定されたファイルの中に、提示されたクライアント証明書の署名元(Issuer)と一致するCA証明書が含まれているかを順番にチェックします。そのため、新旧のCA証明書を結合したファイルを指定すると新旧のクライアント証明書を検証できるようになります。 4./etc/nginx/nginx.confを作成する cat > /etc/nginx/nginx.conf <<'EOF' user nginx; worker_processes auto; include /usr/share/nginx/modules/*.conf; events { worker_connections 1024; } http { server { listen 443 ssl; server_name localhost; # サーバの秘密鍵を設定する ssl_certificate_key /etc/nginx/tls/localhost.key; # サーバ証明書を設定する ssl_certificate /etc/nginx/tls/localhost.crt; # CA証明書を設定する ssl_client_certificate /etc/nginx/tls/old_new_ca.pem; # クライアント認証を有効にする ssl_verify_client on; location / { return 200 "ok\n"; } } } EOF ※既存の nginx.conf がある場合は、http コンテキストや server コンテキストの中に、ssl関連の各ディレクティブを追記してください。 5.nginxを起動する systemctl start nginx curlによるアクセス確認 クライアント証明書を指定せずにWebサーバにアクセス curl -s -o /dev/null -w "%{http_code}\n" \ --cacert server_ca/ca.pem \ https://localhost 400 ※ サーバ証明書の検証のために --cacert オプションでサーバ証明書に署名したCA証明書を指定しています。 レスポンスコードが400となりクライアント証明書を指定しないとアクセスに失敗します(設定によってはレスポンスコードが400以外になる場合があります)。 旧クライアント証明書を指定してWebサーバにアクセス curl -s -o /dev/null -w "%{http_code}\n" \ --cacert server_ca/ca.pem \ --cert client/old_client.pem \ --key client/client.key \ https://localhost 200 レスポンスコードが200となりアクセスに成功します。 新クライアント証明書を指定してWebサーバにアクセス curl -s -o /dev/null -w "%{http_code}\n" \ --cacert server_ca/ca.pem \ --cert client/new_client.pem \ --key client/client.key \ https://localhost 200 レスポンスコードが200となりアクセスに成功します。 上記の結果から新旧のクライアント証明書の並行運用ができていることが分かります。 終わりに ユーザの認証強化では多要素認証やパスキーを使った認証の方が便利なため、相互認証(mTLS)を使う機会は減っていると思います。 一方、システム間の連携やデバイス認証では今後も相互認証は使われていくと思いますので、相互認証を使用した運用の参考になれば幸いです。

目次 目次 1. はじめに 解決したかった課題 2. アーキテクチャ 3. プレビュー環境の作成・更新・削除 作成・更新フロー 削除フロー パターンA: PRクローズ or ラベル削除 パターンB: TTLによる定期クリーンアップ プレビュー環境へのアクセス PRコメント例 4. 実装のポイント Pull Request Generator の実装 PRごとに異なるValuesの命名規則 GitHub Actions Argo CD 再コミット時の自動イメージ更新 仕組み 環境数の上限制御 ResourceQuota によるリソース使用量の制御 5. おわりに 参考 1. はじめに こんにちは！SRE課のモリモトです。 今回は、 プレビュー環境基盤 をKubernetes上に構築した話をご紹介します。 解決したかった課題 弊社のあるサービスでは、フロントエンド開発において以下のような課題がありました。 現状では、ある程度修正がまとまったタイミングでないと検証環境に上げることが難しいため、ローカル環境以外で気軽に動作確認できる環境がない デザイナーや企画/要件を詰めるチームに画面仕様を確認してもらうのに検証環境にデプロイする必要があるが、上記の理由からリードタイムが発生している 検証環境にデプロイせずに確認してもらうためには画面のスクショを送ったりする必要があるが、それだと正確な仕様を把握してもらいにくい PRレビュー時に、レビュアーがローカルでアプリケーションを起動して動作確認する必要があり、無駄な時間が発生している そこで、 PRにラベルを付けるだけで自動的にプレビュー環境がデプロイされる 仕組みを構築することにしました。 具体的には以下のような体験を実現しています。 開発者がPRを作成し、PRに対して preview ラベルを付与 数分後、PRにプレビューURLがコメントされる そのURLにアクセスすると、PRの内容が反映されたUIを確認できる PRをクローズすると、環境が自動削除される 2. アーキテクチャ アーキテクチャ図 本構成では、PRを起点にGitHub ActionsとArgo CDがそれぞれ独立して動作します。 GitHub Actionsはイメージの生成と通知を、Argo CDはKubernetesリソースの生成と削除を担います。 両者を疎結合にすることで、責務を明確に分離しています。 ポイントは、Argo CD ApplicationSetの Pull Request Generator を活用している点です。 ApplicationSet は、同一構成の Argo CD Application を動的に複数生成するための仕組みです。 Pull Request Generator を使うことで、GitHub の PR 情報を元に Application を自動生成できます。 これにより、 preview ラベルが付いたPRを自動検知し、対応するKubernetesリソースを動的に生成・削除できます。 3. プレビュー環境の作成・更新・削除 すべての操作がPRに連動しており、開発者が意識的に環境管理を行う必要がないように設計しました。 作成・更新フロー 作成・更新のシーケンス図 作成・更新の流れは以下のとおりです。 開発者がPRを作成し、 preview ラベルを付与 GitHub Actionsがワークフローを起動 まず、すでに作成済みのプレビュー環境数（ preview ラベルが付いたPR数）を確認します 上限（1リポジトリにつき最大10環境）に達している場合は、その旨をPRにコメントし、 preview ラベルを自動で外します 並行して2つの処理が実行 GitHub Actions側: コンテナイメージをビルド・プッシュし、プレビューURLをPRにコメント Argo CD側: preview ラベルの付いたPRを検知（3分おきにポーリング）し、プレビュー環境のNamespaceとリソースを自動作成 同一PRに対して再コミットが行われた場合は、GitHub Actions側で再度イメージがビルド・プッシュされ、Argo CD側でデプロイされるイメージタグが自動更新されるため、 追加の操作なしでプレビュー環境が最新化 されます。 削除フロー 削除は2つのパターンがあります。 パターンA: PRクローズ or ラベル削除 Argo CDがPRのクローズまたはラベル削除を検知し、Namespaceごと環境を自動削除します。 パターンB: TTLによる定期クリーンアップ プレビュー環境が溜まり続けることを防ぐために、TTLを設けて更新から10日間経過した環境を削除するようにしています。 削除のシーケンス図 GitHub Actionsのスケジュール実行（毎日0:00）で以下を実行します。 preview ラベルの付いたPR一覧を取得 最終更新日から10日以上経過したPRから preview ラベルを削除 不要になった古いコンテナイメージも合わせて削除 Argo CDがラベル削除を検知し、Namespaceごと環境を自動削除 プレビュー環境へのアクセス プレビュー環境のURLは以下の形式で動的に発行され、PRにコメントされます。 https://pr<PR番号>-<サービス名>.preview-example.com 例): PR #123 の場合 → https://pr123-serviceA.preview-example.com なおプレビューURLは社内ネットワークの範囲でのみアクセス可能とし、外部公開はしない前提で運用しています。 PRコメント例 PRコメント例 4. 実装のポイント Pull Request Generator の実装 Argo CD ApplicationSetでPull Request Generatorを使用することで、 preview ラベルが付いたPRを自動検知し、動的に環境を作成できます。 apiVersion : argoproj.io/v1alpha1 kind : ApplicationSet metadata : name : serviceA-preview-applications-applicationset namespace : preview-applications spec : goTemplate : true goTemplateOptions : [ "missingkey=error" ] generators : - pullRequest : github : owner : "my-org" repo : "serviceA-frontend-repo" appSecretName : app-secret # GitHub Apps認証用のSecret名 labels : - preview # previewラベルがついたPRのみを対象にフィルタリング requeueAfterSeconds : 180 # イメージビルドに3~4分かかることを考慮して３分に設定 template : metadata : name : 'pr{{ .number }}-serviceA-preview-applications' spec : project : preview-project source : repoURL : https://github.com/my-org/manifest-repo.git path : preview-frontend targetRevision : develop helm : releaseName : 'preview-frontend' valueFiles : - "values/develop.yaml" valuesObject : namespace : "pr{{ .number }}-serviceA" image : repository : 'ghcr.io/my-org/serviceA-frontend' tag : 'preview-pr{{ .number }}-{{ .head_sha }}' ingress : app : hosts : - host : 'pr{{ .number }}-serviceA.preview-example.com' paths : - path : / pathType : Prefix destination : name : "dest-cluster-name" namespace : "pr{{ .number }}-serviceA" syncPolicy : automated : prune : true selfHeal : true preview-frontend/ に汎用的に利用できるフロントエンドのhelm chartを実装し、それをプレビュー環境としてPRの数だけ複製するようなイメージになります。 その際に、イメージタグやプレビューURLなど、PRごとに異なるValuesを渡したくなりますが、 valuesObject から {{ .number }} や {{ .head_sha }} などの値を渡すことでPRごとに別々の値をhelm chartに渡すようにしています。 PRごとに異なるValuesの命名規則 命名規則は以下のようにしました。 イメージタグ： preview-pr<PR番号>-<コミットSHA> Namespace名： pr<PR番号>-<サービス名> ドメイン： pr<PR番号>-<サービス名>.preview-example.com 特にイメージタグとドメインについては、GitHub Actions側とArgo CD側で整合性を保つためにルールを決めておく必要があります。 このルールに沿って、GitHub Actions側でのイメージビルドやPRコメント、Argo CD側でのアプリケーションデプロイを実施しています。 GitHub Actions # イメージタグ生成側の例 - name : Set up parameters id : set-params run : | IMAGE_TAG=preview-pr${{ inputs.pr-number }}-${{ inputs.pull-request-head-sha }} # PRコメント時のプレビューURL生成の例 - name : Comment preview URL on PR env : GH_TOKEN : ${{ github.token }} run : | PREVIEW_URL="https://pr${{ inputs.pr-number }}-serviceA.preview-example.com" Argo CD # イメージタグ使用側の例 valuesObject : image : repository : 'ghcr.io/my-org/serviceA-frontend' tag : 'preview-pr{{ .number }}-{{ .head_sha }}' # プレビューURL指定の例 valuesObject : ingress : app : hosts : - host : 'pr{{ .number }}-serviceA.preview-example.com' 再コミット時の自動イメージ更新 同一PRに再コミットした場合、同一URLのままで自動でプレビュー環境が更新される仕組みになっています。 仕組み 再コミットすると、GitHub Actionsが新しいイメージをBuild&Push（タグ: preview-pr<PR番号>-<新コミットSHA> ） Argo CD ApplicationSetが {{ .head_sha }} を参照しているため、新しいコミットSHAでDeploymentのイメージタグが自動更新され、新しいPodがデプロイされる これにより、開発者は再コミットするだけで最新の変更がプレビュー環境に反映されます。 環境数の上限制御 1リポジトリあたりの環境数を10に制限し、環境が作られすぎないようにしています。 制御はGitHub Actions側で行い、上限に達した場合はPRにコメントで通知し、 preview ラベルを自動で外すようにしています。 # GitHub Actions Workflow内での制御イメージ - name : Check preview environment count limit id : check-limit env : GH_TOKEN : ${{ github.token }} run : | # previewラベルが付いているオープンPRの数を取得 PREVIEW_PR_COUNT=$(gh pr list \ --repo ${{ github.repository }} \ --state open \ --label preview \ --json number \ --jq 'length' ) echo "プレビュー環境数:" echo " - 現在: $PREVIEW_PR_COUNT" echo " - 最大値: ${{ inputs.max-preview-environments }}" # 上限チェック if [ "$PREVIEW_PR_COUNT" -gt "${{ inputs.max-preview-environments }}" ] ; then echo "[FAIL] 環境数上限に達しています。" echo "should-continue=false" >> $GITHUB_OUTPUT else echo "[PASS] 環境数は上限内です。" echo "should-continue=true" >> $GITHUB_OUTPUT fi - name : Comment on PR if limit reached if : steps.check-limit.outputs.should-continue == 'false' env : GH_TOKEN : ${{ github.token }} run : | gh pr comment ${{ inputs.pr-number }} \ --repo ${{ github.repository }} \ --body "## ⚠️ **プレビュー環境数の上限に達しています！** 現在、プレビュー環境の最大数（${{ inputs.max-preview-environments }}環境）に達しているため、新しいプレビュー環境を作成できません。 他のPRのプレビュー環境が不要になった場合は、そのPRから \`preview\` ラベルを削除してください。" - name : Remove preview label if limit reached if : steps.check-limit.outputs.should-continue == 'false' env : GH_TOKEN : ${{ github.token }} run : | gh pr edit ${{ inputs.pr-number }} \ --repo ${{ github.repository }} \ --remove-label preview ResourceQuota によるリソース使用量の制御 プレビュー環境は多数同時に立ち上がる可能性があるため、 ResourceQuota でリソース使用量を制限しています。 これにより、1つのプレビュー環境が過剰にリソースを消費することを防いでいます。 apiVersion : v1 kind : ResourceQuota metadata : name : preview-frontend-resource-quota spec : hard : requests.cpu : 20m requests.memory : 64Mi limits.cpu : 100m limits.memory : 128Mi pods : 2 # (...省略...) 5. おわりに GitHub ActionsとArgo CDのApplicationSetを活用することで、 ラベル付与だけで自動的にプレビュー環境が立ち上がる 仕組みを構築できました。 本記事では詳しく説明できませんでしたが、GitHub ActionsのワークフローをReusable Workflow化するなど横展開が容易な形で設計しているため、社内にどんどん展開して 複数チームで共通利用できる基盤 となっています。 現在はNginxを前提にプレビュー環境の仕組みが構築されていますが、今後の展望としては他のミドルウェアにも対応を広げていきたいと考えています。 プレビュー環境の構築を検討されている方の参考になれば幸いです！ 最後まで読んでいただき、ありがとうございました。 参考 tech-blog.monotaro.com

こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） tech-blog.rakus.co.jp これまで組織やマネジメントの話を書くことが多かったのですが、以前から少し気になっていたことがあります。 年末年始の休みに買い物をしている際、やはりそのことが気になったので、今回はそれについて書いてみようと思います。それはセルフレジについてです。 目次 「セルフレジのUIは、なぜあんなに不自由なのか？」 リアルUIとWEB UIは、そもそも戦っている場所が違う 利用者の「状態」の違い コンビニのセルフレジUIに見る「運用者優先」の設計 ファーストフードのセルフオーダーUIが示す別の最適解 なぜリアルUIでは「運用者視点」が強くなるのか この構造は、そのまま toB SaaS に当てはまる toB SaaSでよく見る失敗 セルフレジUIと toB SaaS UI の対応関係 プロダクトチームとして、この話をどう使うか AIが入ることで、ネットのUI/UXはどう変わるのか UIから「操作」を減らし、UXを「対話」に移す それでも消えない「運用者視点」 toB SaaSにおけるAI時代のUI/UX AI時代だからこそ、セルフレジの学びは生きる おわりに 「セルフレジのUIは、なぜあんなに不自由なのか？」 初めてセルフレジを使ったとき、そう感じたことがある方は多いと思います。操作の順番は決められていて、戻ることはできず、選択肢も少ない。 WEBサービスやアプリに慣れているほど、この不自由さは違和感として強く残ります。しかし、この違和感こそが、 toB SaaSのUI/UXを考える上で極めて重要なヒント になるのではと思っています。 私は現在、ラクスというSaaS 企業で、プロダクトマネージャーとプロダクトデザイナーが所属するプロダクト部のマネージャーを務めています。日々の業務の中で繰り返し立ち返る問いがあります。 それは、 「良いUI/UXとは誰にとってのものなのか」 という問いです。 プロダクト開発の現場では、UI/UXという言葉がしばしば「使いやすさ」「分かりやすさ」「シンプルさ」と同義で語られます。しかし、toB SaaSにおいてそれだけを追い求めると、運用が破綻する、問い合わせが増える、結果として顧客価値を下げてしまう──そんな経験をした方も多いのではないでしょうか。 今回、セルフレジやファーストフードのセルフオーダーといった リアルのUI/UX を整理して、私は「これはそのまま toB SaaS に当てはまる構造だ」と強く感じました。本記事では、セルフレジUI/UXの具体例を交えながら、 リアルUIとWEB UIの違いがどこから生まれ、なぜ toB SaaS のUI設計にとって重要なのか を整理していきます。 リアルUIとWEB UIは、そもそも戦っている場所が違う セルフレジやセルフオーダー端末に触れると、WEBやSaaSとは明らかに違う設計思想を感じます。この違いは、UIデザインのトレンドやデザイナーの好みではありません。 UIが置かれている環境と、背負っている責任構造の違い から必然的に生まれています。 利用者の「状態」の違い リアルUI（セルフレジ・飲食店端末）の利用者は、次のような状態に置かれています。 立ったまま操作している 後ろに行列ができている 周囲が騒がしく、集中しづらい 初見利用者が多い 操作ミスが即トラブルにつながる 一方、WEBやSaaSのUIはどうでしょうか。 座って操作できる 基本的に一人で使う 自分のペースで進められる 戻る・やり直しが可能 学習しながら使う前提 この違いが、設計思想を真逆の方向へ引っ張ります。 リアルUIは「考えさせない・迷わせない」ことが最優先 であり、 WEB UIは「ある程度の自由や探索」を許容 します。ここを混同すると、UIは破綻します。 コンビニのセルフレジUIに見る「運用者優先」の設計 セブンイレブン  セルフレジ ローソン  セルフレジ ファミリーマート  セルフレジ コンビニのセルフレジには、実は複数のUIパターンが存在します。 レジ袋選択 → 商品スキャン → ポイント → 決済 決済方法選択 → レジ袋 → 商品スキャン → 完了 一見すると「なぜこんな順番なのか分かりにくい」と感じる方も多いでしょう。しかし、これらはすべて 運用上の事故を防ぐための設計 のように思います。 例えば、 レジ袋を最後に聞くと、袋代金の取り忘れが発生する 決済直前に袋選択を挟むと、操作ミスが起きやすい ポイント提示を忘れると、店員呼び出しが発生する セルフレジでは、 一人の迷いが行列全体を止める という前提があります。そのため、UIは「直感的であること」よりも「事故が起きないこと」を優先します。これは決してユーザー軽視ではありません。 店舗全体のUXを守るための設計 だと思います。 ファーストフードのセルフオーダーUIが示す別の最適解 一方、ファーストフードのセルフオーダー端末では、ほぼ例外なく次のような流れが採用されています。 商品選択 セット・サイズ・カスタマイズ 注文内容確認 決済 ここで重要なのは、 決済が必ず最後に来る という点です。なぜなら、飲食においては 「何を食べるか決めるプロセス」そのものが体験価値 だからです。 マクドナルドのセルフオーダーを思い浮かべてください。画面には大きな写真、セット提案、期間限定商品が並びます。これはUXのためだけでなく、 客単価を最大化するための設計 でもあります。しかし同時に、 カスタマイズは段階的にしかできない 戻り操作は最小限 注文確定後の変更は難しい といった制約も多く存在します。ここでも、 運用者視点（厨房・提供フロー） が強く効いているように思います。 なぜリアルUIでは「運用者視点」が強くなるのか セルフレジやセルフオーダーは、UXツールであると同時に業務装置です。1人の操作ミスは、 行列停止 店員の割り込み対応 提供遅延 クレーム といった形で即座に表面化します。そのためリアルUIでは、 操作順序の固定 選択肢の制限 確認ダイアログの多用 が「正義」になるのでは推測しています。WEBの世界で嫌われがちなこれらの設計は、リアルでは 現場を守るための合理 です。 この構造は、そのまま toB SaaS に当てはまる ここで話を toB SaaS に戻します。toB SaaS もまた、 日々オペレーションを行う利用者 全体を管理する管理者・組織 という 二重構造のユーザー を持っています。 toB SaaSでよく見る失敗 「利用者にとって分かりやすいUI」を優先しすぎる 設定の自由度を上げすぎる 業務フローを柔軟にしすぎる 結果として、 管理画面が複雑化 設定ミスが多発 問い合わせが増加 運用ルールが守られない これは、 セルフレジにWEB的UI思想を持ち込んだ時と同じ失敗構造 ではと思っています。 セルフレジUIと toB SaaS UI の対応関係 ここで重要なのは、 制限＝悪ではない ということです。制限は、運用を守るためのUXです。 セルフレジのUI/UXを観察して得た最大の学びは、UXとは「画面を触る個人」だけのものではないという事実です。 toB SaaSにおけるUXは、 その画面を触る人 そのデータを管理する人 その業務を回す組織 全体最適として成立して初めて良いUX になります。 UIを改善するとき、「もっと分かりやすく」「もっと自由に」と言いたくなったら、ぜひセルフレジを思い出してほしいと思います。その不自由さには、必ず理由があります。 プロダクトチームとして、この話をどう使うか ここまでセルフレジのUI/UXを題材に、リアルUIとWEB UI、そしてtoB SaaSの共通構造を整理してきました。最後に、プロダクト組織の責任者という立場から、この話をどう使ってほしいかをまとめます。 UXは「画面単体の使いやすさ」ではなく、「業務が止まらないこと」まで含めて考える 制限はUXの敵ではない。むしろ運用を守るためのUXであることが多い 利用者視点と運用者視点のどちらを優先しているのかを、常に言語化する これらは、UIレビューや仕様議論の場で、必ず立ち返るべき問いなのかなと思いました。 AIが入ることで、ネットのUI/UXはどう変わるのか 最後に、ネットのUI/UXにおいて AIが入ることで何が変わるのか について触れておきたいと思います。これは、セルフレジや toB SaaS の話とも深くつながるテーマです。 これまでのWEB UI/UXは、「人が画面を操作する」ことを前提に設計されてきました。ボタンを押し、入力欄に文字を入れ、選択肢の中から選ぶ。そのためUIは、 どの順番で操作させるか どこまで自由を与えるか どこで制限をかけるか を画面上で細かく設計する必要がありました。しかしAI、とりわけ生成AIや対話型UIが入ることで、この前提が少しずつ崩れ始めています。 UIから「操作」を減らし、UXを「対話」に移す AIが入ることで、ユーザーは必ずしも画面構造を理解する必要がなくなります。「こうしたい」「これをやってほしい」と自然言語で伝えれば、AIが裏側の操作や設定を肩代わりしてくれるからです。 これは、WEB UIを 画面中心のUX 手順中心のUX から、 意図中心のUX 結果中心のUX へと変えていきます。 それでも消えない「運用者視点」 ただし、ここで重要なのは、 AIが入っても運用者視点は消えない という点です。むしろ、AIが自由度を一気に引き上げるからこそ、 何をAIに任せてよいのか どこは人やルールで縛るのか AIの判断をどう制御するのか という設計が、これまで以上に重要になります。これは、セルフレジで「自由を削ることで現場を守ってきた」構造と非常によく似ています。AIはWEB UIを一気に自由にしますが、その裏側では 運用を守るための強いガードレール が必要になります。 toB SaaSにおけるAI時代のUI/UX toB SaaSにおいては、AIによって 設定画面が不要になる 操作フローが短縮される 専門知識がなくても使える といった変化が起きていくでしょう。一方で、 誤った設定をAIが自動でしてしまう 誰がどこまで責任を持つのか分からなくなる 組織ルールが崩れる といった新しいリスクも生まれます。だからこそ、これからの toB SaaS のUI/UXでは、 AIに任せる自由 人が守る制約 を意識的に分離して設計する必要があります。 AI時代だからこそ、セルフレジの学びは生きる AIはUIを消し去る存在ではありません。むしろ、UI/UX設計の難易度を一段階引き上げます。自由度が増えるほど、運用を守る設計が重要になる。この構造は、セルフレジやセルフオーダーがすでに私たちに示してくれています。AI時代のUI/UXを考えるときこそ、 誰のUXを守るのか どこまでをUXの責任範囲とするのか を問い続ける必要があります。 セルフレジ → toB SaaS → AI時代のUI/UX これらは別々の話ではなく、 同じ構造の延長線上にある と、私は考えています。 おわりに リアルのUI/UXは不自由です。しかしその不自由さは、現場を守り、業務を成立させるための合理です。セルフレジやセルフオーダーを観察すると、 なぜ手順が固定されているのか なぜ自由度が低いのか が腹落ちします。そしてそれは、そのまま toB SaaS のUI/UXにも通じます。UXを語るとき、「誰のUXか」「どこまでをUXの範囲とするか」を誤ると、プロダクトは壊れます。画面を触る人だけを見て設計すると、現場や組織が苦しみます。 セルフレジは、toB SaaSを作る私たちにとって、 現場視点と組織視点を同時に学べる、非常に優れた教材 です。もし今後、UI/UXの議論で迷ったときは、ぜひ近くのコンビニやファーストフード店に立ち寄ってみてください。その不自由なUIの中に、プロダクト設計の本質が詰まっています。 この記事を読んで、やラクスのプロダクト部に興味を持ってくださった デザイナー／PdM の方 は、ぜひカジュアル面談からご応募ください。 ※プロダクトマネージャーのカジュアル面談は、基本的に私（稲垣）が担当します！ ●採用情報 デザイナー career-recruit.rakus.co.jp   └ デザインマネージャー career-recruit.rakus.co.jp ／アシスタントマネージャー career-recruit.rakus.co.jp

こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） tech-blog.rakus.co.jp PdM（プロダクトマネージャー）って、企業によってやることがバラバラですよね。 「仕様書を書く人」みたいになってる会社もあれば、 「戦略を決める人」だったり、「なんでも屋」だったりする。その中で、よく出てくるモヤモヤがこれです。 顧客インタビューをしていないPdMって、本当にPdMなの？ 逆に言えば、 エンジニアやデザイナーでも、顧客理解しながら動いていたらPdM的じゃない？ この記事では、toB SaaS という文脈に絞って、この疑問をカジュアルに掘っていきます。 こんな方が対象： PdMを目指している人 いま PdM をやっているけどあまり顧客に会えていない人 「自分はPdMと言えるのか？」と不安になっている人 ✋ 結論から言うと… 🧩 PdMの仕事って結局こういう構造 💡 toB SaaSではなぜ顧客インタビューが必須級になるのか？ 🧩 顧客理解なしのPdMが陥る罠 👀「インタビューをしているエンジニア/デザイナーはPdM行為をしている」という話 🧩 肩書きPdMと実質PdMの違い 🤔 では「なぜ顧客に会わないPdM」が生まれるのか？ 🧩PdMの価値が最大になるポイント 🌱 とはいえ、「PdMが必ずインタビューすべき」とも限らない 👉私の経験上、国内toB SaaSでは“仕組みが成熟していてPdMが会わなくても回る”ケースはまだ多くありません。 🔚 最後に：PdMとは「顧客理解から逃げない人」 🧩 PdMとは何か？（一言で） 🌟 最後に PdMを目指すあなたへ ✋ 結論から言うと… toB SaaSでは、顧客接点がないと、PdMとしての意思決定が難しくなりやすい／PdM的になりづらい これは辛口でもなんでもなく、 プロダクトマネジメントの本質が “顧客理解に基づいた意思決定” だから です。 じゃあこれで決まり？ いや、もちろん例外もあります。 ちゃんと後半で書きます。 🧩 PdMの仕事って結局こういう構造 上の段に行くほど “PdMである必要性が高まる” のですが、意思決定の源泉が 顧客の一次情報 である以上、 一次情報を持っていないPdMは、そもそも材料不足で判断できない。 となるわけです。 💡 toB SaaSではなぜ顧客インタビューが必須級になるのか？ toCと違って、toB SaaSは 業務の中に深く入り込むタイプのプロダクト です。 つまり、顧客側の現実がめちゃくちゃ複雑。 ① 顧客の業務は会社ごとに全然違う フローも違う。 権限も違う。運用ルールも違う。 机に向かって仕様を書くより、5分の会話のほうが100倍早い。 ② 営業やCSの声は貴重だが「偏り」がある 営業：売りたい人  /  CS：困りごとを聞く人 なので、本質はその奥にあることが多い。 ③ 機能の一つが全体の業務に影響する toB SaaSでは、以下みたいなことがよくある。 承認フローが変わる 会計処理に影響する セキュリティに関わる 別部署の仕事まで変わる つまり、 「ちょっとした仕様判断」が全社レベルの業務変更につながる。 これは顧客理解なしには危険すぎる。 🧩 顧客理解なしのPdMが陥る罠 はい、負のスパイラルのできあがりです。 👀「インタビューをしているエンジニア/デザイナーはPdM行為をしている」という話 これも多くの現場で起きています。 デザイナーがユーザーに話を聞いて課題を整理してる エンジニアが仕様理解のために顧客にヒアリングしてる CS が課題を深掘りして問題の本質に迫ってる これ全部、PdMの本質的な行為です。 肩書きがなんであれ、 顧客理解を元に意思決定に影響を与えているなら、それはPdM的な動き です。 逆に、肩書きがPdMでも顧客理解がなく、意思決定していないなら、 PdM行為をしているとは言えない 。 🧩 肩書きPdMと実質PdMの違い 【肩書きPdM】 社内調整 仕様書作成 会議進行 タスク管理 → 顧客理解なしでもできてしまう 【実質PdM】 顧客理解（一次情報） 課題定義 仮説検証 優先順位の意思決定 → 顧客理解がないと成立しない あなたが見てきた「名ばかりPdM」が前者であることは多いです。 🤔 では「なぜ顧客に会わないPdM」が生まれるのか？ 理由はいくつもあります。 ● PdMのロール定義が曖昧（仕様担当にされがち） ・PdMの歴史が浅い会社でよく起きる。 ● 組織として顧客インタビューの文化が薄い ・営業主導企業だと、とにかく営業が顧客を抱え込みがち。 ● 社内会議が多すぎて外に出られない ・PdMが“社内の渋滞ポイント”になっているケース。 ● リサーチャー不在でPdMが全部やる必要がある ・でも仕組みがないから後回しになる。これ、PdM個人の怠惰というより構造の問題です。 🧩PdMの価値が最大になるポイント 顧客理解 × 課題の定義 × 意思決定の責任 この3つの重なる部分が、PdMが最も価値を出せるゾーン。 顧客理解が抜けると、一気に価値が落ちます。 🌱 とはいえ、「PdMが必ずインタビューすべき」とも限らない 少し補足しておくと、例外は存在します。 ■ 顧客理解の仕組みが成熟している場合 UXリサーチャーが常に一次情報をとってくれる データ分析基盤が整っていて行動が全部見える CS Ops が定性情報を構造化してくれる こういう企業では、PdMは意思決定に集中できる。ただし、 👉私の経験上、国内toB SaaSでは“仕組みが成熟していてPdMが会わなくても回る”ケースはまだ多くありません。 だから、PdMが顧客に会う価値はやっぱり高い。 🔚 最後に：PdMとは「顧客理解から逃げない人」 肩書きがPdMかどうかより、 顧客を理解しているか 課題から逃げていないか 一次情報に触れているか 仮説と学習を回しているか ここがPdMを定義します。 🧩 PdMとは何か？（一言で） PdM ＝ 顧客理解を起点に意思決定する人 だからこそ、 顧客に会うデザイナーはPdM的 顧客に会うエンジニアはPdM的 顧客に会わないPdMはPdM的ではない という状態が生まれる。 🌟 最後に PdMを目指すあなたへ 最後に一言だけ。 顧客と話すこと。それが PdM への最短ルートです。 経験年数より、肩書きより、スキルセットより、 一次情報に触れて意思決定していく行為こそが あなたをPdMにします。 以前にイベントで以下のような話をしましたので合わせて見てもらえればと思います。 speakerdeck.com この記事が、あなたの「PdMとは何か？」を考えるきっかけになれば嬉しいです。 ラクスの開発組織では『顧客志向』を大切にしています。 PdMはもちろん顧客を向いて業務をしていた方はラクスはオススメです。 また、本記事を読んでラクスのプロダクト部に興味を持ってくださったデザイナー / PdM の方は、ぜひカジュアル面談からご応募ください。 ※プロダクトマネージャーのカジュアル面談は、基本的に私（稲垣）が担当します！ ●採用情報 プロダクトマネージャー career-recruit.rakus.co.jp デザイナー career-recruit.rakus.co.jp   └ デザインマネージャー career-recruit.rakus.co.jp ／アシスタントマネージャー career-recruit.rakus.co.jp