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

明けましておめでとうございます。 こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） tech-blog.rakus.co.jp 私は2014年から、仕事・プライベートを問わず、毎年個人で目標を立て、その目標をさらに3カ月単位に分解して取り組むことを続けてきました。大きな方向性を定め、短いサイクルで振り返り、修正しながら前に進む。このやり方は、今のプロダクトづくりや組織づくりにも強く影響しています。 新年最初の記事ということで、今回は昨年度の簡単な振り返りと、2026年に向けた抱負を書こうと思います。 はじめに 2025年に新しく始めたこと 2024年から継続して強化してきたこと 『穏跳』に込めた意味 PdMとして担うべきこと 1. 統合型ベストオブブリード戦略の実現 2. エンタープライズ強化 3. AIの製品活用 デザイナーとして担うべきこと 2026年に個人として取り組む目標 1. プロダクト成長・貢献 2. 組織強化・認知 穏やかに整え、次の3年へ跳ぶ はじめに 2025年のキーワードは『変革』でした。プロダクトと組織の両面で、これまでの前提を見直し、作り直す一年でした。振り返ると、主に以下のような取り組みを行ってきました。 2025年に新しく始めたこと YOUTRUSTの発信開始（フォロワー1,800突破） note「Rakus ProductManager」開始（全体20本／個人14本） デザイナー組織とPdM組織を統合し、プロダクト部へ再編 新規サービス「楽楽債権管理」を担当 2024年から継続して強化してきたこと Xフォロワー数：約1,800増、投稿数：約3,000投稿 登壇・記事露出：2024年比で約2倍（pmconf 東京・大阪に各1名登壇） PdM採用：2025年に3名採用、組織を2つに分割し新マネージャーが誕生 なお、ラクスの決算期は3月末のため、ここから書く2026年のキーワードや挑戦は、 あくまで私個人としての考え・目標 として受け取っていただければ幸いです。 2026年は、ラクスにとって 現在の中期計画から、次の中期計画（3年）へと切り替わる節目の年 です。 前回の中期計画策定時、私は入社直後ということもあり、十分に関与することができませんでした。ただ、プロダクトと組織がどのような意思決定で形づくられていくのかを、外側から見てきた3年間でもありました。 そして今回、 中期計画の策定に関与し、リードしていける立場 になりました。これは役割上の変化であると同時に、自分自身の覚悟の変化でもあります。 その決意を込めて、2026年のキーワードとして掲げるのが 『穏跳（おんちょう）』 です。 『穏跳』に込めた意味 穏やかであることと、跳ぶこと。 急激な変化や過度なジャンプは、短期的な成果は出せても、組織やプロダクトに歪みを残します。一方で、整えることだけに終始すれば、成長は止まります。『穏跳』は、 基盤を整えながら、跳ぶべきところでは確実に跳ぶ という姿勢です。 2025年の「変革」が作り直すフェーズだったとすれば、2026年は、 次の3年を見据えて、整え、意思を持って前進するフェーズ です。 PdMとして担うべきこと 次の中期計画において、PdMとして特に注力したいテーマは以下の3つです。 1. 統合型ベストオブブリード戦略の実現 単一プロダクト最適ではなく、 複数プロダクトが連携し、全体として最適な価値を提供する状態 を目指します。 それぞれが尖り続けながら、使う側から見たときには「一つの体験」として成立している。そんな統合を、戦略として実装していきます。 2. エンタープライズ強化 中堅・中小向けで培ってきた強みを活かしながら、 より複雑な業務・組織構造にも耐えられるプロダクト へと進化させます。 これは機能追加の話ではなく、 情報設計 権限設計 運用負荷の低減 といった、プロダクトの“設計思想”そのものを問う挑戦だと考えています。 3. AIの製品活用 AIを「試す」フェーズは終わり、 製品価値として組み込むフェーズ に入ります。 PdMとしては、 どこに使えばユーザー価値が最大化されるのか どこは人がやるべきなのか その線引きをし、継続的に改善できる形でプロダクトに落とし込むことを担います。 デザイナーとして担うべきこと デザイナーとしては、 UXを担い、より長く利用し続けてもらえるプロダクトづくり を担っていきたいと思います。見た目を整えることや、一時的な使いやすさだけではなく、 使い続けるほど理解が深まる 組織に定着し、業務の一部になる そんな体験を設計することが、次の3年でより重要になります。PdMと並走しながら、 課題設定 仮説検証 プロダクト全体の体験設計 に深く関与できる環境を作っていきます。 2026年に個人として取り組む目標 1. プロダクト成長・貢献 製品貢献実感：70%以上   ※アンケート内容や詳細については「 （2）製品貢献実感は、まだまだ伸びしろあり 」を参照してください。 プロダクト間連携リリースによるお客様への付加価値向上を複数件実現する 2. 組織強化・認知 社外認知 Xフォロワー数（個人）：3,500 YOUTRUSTつながり数（個人）：2,500 note公開数（プロダクト部）：50本 社外登壇・外部媒体記事（プロダクト部）：30件 穏やかに整え、次の3年へ跳ぶ 2026年は、「変革」で整えた地盤の上で、心は穏やかに、視座は高く。 闇雲に動くのではなく、静かなる自信と確固たる戦略を持って、大きく跳躍する。 組織体制やプロセス（AI活用など）で足元を「穏」やかに盤石にし、その上でプロダクトの連携や新規領域へ果敢に「跳」ねていければと思います。 一緒にこの 「穏跳」 の景色を見たい方、少しでも興味を持ってくださった  デザイナー／PdM の方 は、ぜひカジュアル面談からご応募ください。 ●採用情報 デザイナー career-recruit.rakus.co.jp   └ デザインマネージャー career-recruit.rakus.co.jp ／アシスタントマネージャー career-recruit.rakus.co.jp

こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） tech-blog.rakus.co.jp おそらくこれが2025年最後の記事になるので、まずはこの一年を振り返ってみようと思います。 🗓 2025年の振り返り ■ 組織・採用まわりの変化 ■ 発信・外部登壇 外部登壇（モデレーター含む） note／ブログ記事 🏛 「文化」を構成するものは何か ハイレイヤーの意思決定の優先順位 なぜ「文化」が重視されるのか 🗣 文化は“言葉”に表れる ■ ラクスのカルチャー 🎁 採用で工夫している「4P」の話 📝 最後に 🗓 2025年の振り返り ラクスに入社して4年半。毎年さまざまな変化がありましたが、2025年は特に大きな転換点の年になりました。 ■ 組織・採用まわりの変化 デザイナー／プロダクトマネージャーが所属する プロダクト部が誕生 PdM組織が 1課→2課体制 へ、稲垣以外のPdMマネージャーが初めて誕生（内部昇格） 2025年採用（＝入社） PdM ＋3名（リーダー・シニアクラス含む） デザイナー ＋7名（リーダークラス含む） ■ 発信・外部登壇 外部登壇（モデレーター含む） 稲垣単体：16回 組織全体：19回　 自分はEMconfへ登壇 当社から2名が大阪・東京のpmconfへ登壇 note／ブログ記事 稲垣単体：12本（組織全体：25本）　 ※2024年はほぼゼロからのスタート その他、取材対応の記事なども増加 このまま終わるのはさすがに寂しいので、「文化（カルチャー）」について、少し掘り下げて書きます。 🏛 「文化」を構成するものは何か 「文化（Culture）」＝組織に根付いた考え方や行動の型。これをさらに分解すると、 風土 ：文化が行動や感情レベルでどう体感されているか 人材 ：文化・風土を形成する主体 この2つに行きつきます。 採用に長く関わってきましたが、特にエンジニア・デザイナー・PdMのハイレイヤーほど、 文化・人材・課題の3つ を重視し、しかもその優先順位は次のようになります。 ハイレイヤーの意思決定の優先順位 1. 誰がいるのか（People） 2. どんな課題があるのか（Problem） 3. どんな文化なのか（Culture） しかもレベルが上がるほど、 Culture ＞ Problem ＞People の重み付けになっていきます。より「文化」が重要視されます。 なぜ「文化」が重視されるのか 採用の現場で多くの方と話す中で、次の理由が大きいのではと感じています。 一人では変えられない 変えるには年単位の時間がかかる 人や課題の進め方に強く影響する 文化は「知ってから入る」だけではなく、「入社してから痛感する」ものでもあります。 🗣 文化は“言葉”に表れる 私自身、これまで6社のIT企業で働いてきましたが、会社ごとに文化は全然違いました。長く働いた会社は、自分と価値観が近かったのだと思います。 tech-blog.rakus.co.jp そして文化は、 役員・マネージャーの発言、社員の口癖、日々の判断基準 に現れます。 たとえば、自分がいた会社でよく飛び交っていた言葉としてはこんなものがあります。 その目的は？ 誰のため？ 成果に対してやり切った？ お客様はどう考える？ Unless you know a better one Working Backwards 仕組化できる？誰でもできるようになってる？ One-Way Door？Two-Way Door？ Dive Deepしてる？ Have Backbone; Disagree and Commit ラクスでも、同様に文化が明文化されており、役員やマネージャーだけでなく、社員一人ひとりが日々体現しています。 ■ ラクスのカルチャー ※ラクスの成長の源泉、「ユニークネス」・「リーダーシッププリンシプル」  career-recruit.rakus.co.jp より その中でも開発組織では「顧客志向」を価値観としておいています。 これを体現できるようにするために様々な取り組みがありますので、興味がある方は是非『「顧客志向」を実践する開発本部の取組み 』のnoteをご覧ください note.com 🎁 採用で工夫している「4P」の話 最後に、私が採用のオファー面談で意識していることを書いて締めようと思います。 面談で使う資料は、「 採用の4P 」（＝ 『THE TEAM 5つの法則』 にある「エンゲージメントの4P」） をベースに作っています。 Philosophy（理念・目的） People（人材・風土） Process（仕組み・方法） Performance（成果・実績） この中で「文化」は、 Philosophy と People の両面で表現できるため、明文化している内容をしっかり伝えるようにしています。 この構成に変えてから、 内定承諾率も少し向上した ように感じています。 もし採用に携わっている方がいれば、この「4P」をアジェンダとして使うのはおすすめです。 📝 最後に 本記事を読んでラクスのプロダクト部に興味を持ってくださった デザイナー／PdM の方 は、ぜひカジュアル面談からご応募ください。 ※プロダクトマネージャーのカジュアル面談は、基本的に私（稲垣）が担当します！ それでは、良いクリスマスをお過ごしください！ ●採用情報 デザイナー career-recruit.rakus.co.jp   └ デザインマネージャー career-recruit.rakus.co.jp ／アシスタントマネージャー career-recruit.rakus.co.jp

こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） tech-blog.rakus.co.jp はじめに 1. 成果の大きさに限界がある 2. 成果を出すための「筋力」がつかない 【1年目：インプット期】「やり方」を学ぶ 【2年目：実践・改善期】「自分で回す」 【3年目：成果・貢献期】「型」ができる 3. 年収の伸びは“過去3年の積み上げ”で決まる 4. 採用側からの見え方がポジティブに映りにくい とはいえ、「無理に3年働くべき」と言いたいわけではない はじめに 今回のテーマはすごい反響のあるこの noteのテーマについて書こうと思います。 ※本記事は筆者個人の経験・価値観に基づくものであり、ラクスの評価制度やキャリア方針を示すものではありません。 note.com 自分もかなりうなずきながら読ませてもらいました。 このnoteを読んで思い出しました。 そう言えば自分は前職で、新卒や若手メンバーにたびたび 「3年は一つの場所で成果を出すべき」 伝えていました。 もちろん、世の中には本当に劣悪な環境もあるので「逃げるな」と言うつもりはありません。ただ、一般論として“3年はやってみるべき”という考えが自分のキャリア感にも強く根付いています。 なぜかというと、初期キャリアで以下のような価値観に触れて育ってきたからです。 「石の上にも三年」という日本的価値観 自分が入社した最初の会社でも、この価値観を強く求められた（同期200人中、3年で3割が離職） 当時は「長く働く＝誠実」「短期離職＝忍耐不足」という評価軸が強く、今とは少し状況が違います。 それでも今、自分は 「3年間で“成果”を出す経験はキャリアの基盤になる」 と感じています。ここからは、3年未満で転職したときに起こりやすいデメリットを、自分の経験も踏まえて整理します。 1. 成果の大きさに限界がある 先の note でも触れられていますが、「主体的に動いて実績を出す」には最低でも数年単位の時間が必要です。 偉そうに書いている私自身、実は過去に3年未満で2社を辞めています。 その2社でも「自分はこれをやったぞ！」という仕事はありましたが、正直かなり小粒でした。 その後の採用面接で「こんなことを成し遂げました」と胸を張って言えるレベルかというと、疑問が残ります。 特に入社時の職能や立場にもよりますが、 製品づくりや事業成長に携わる職種において、短期間で大きな成果を出すことは構造的にかなり難しい と感じています。 2. 成果を出すための「筋力」がつかない ここで言う「 成果を出す筋力 」とは、 仕事を構造化して進める力 課題の真因を特定する分析力 関係者を巻き込み、調整する力 自ら改善点を見つけて回すPDCA力 継続して成果を出すための習慣・再現性 こうした“型”のことです。 これらは本や研修では身に付かず、実務で失敗や改善を重ねながら形成されるもの。しかも、その形成スピードは 環境 × 個人の適性 × 労働条件 × マネジメント品質 によって大きく変わります。 とはいえ、平均的にはこんなイメージになるのではと思っています。 【1年目：インプット期】「やり方」を学ぶ 業務の全体像やルール、仕組みを覚える。 基本的には先人に教わりながら動く段階。 まだ「自分で考えて成果を出す」フェーズではない。 【2年目：実践・改善期】「自分で回す」 任される仕事が増え、失敗と改善のサイクルが回り始める。 ステークホルダーとの関係構築が進む。 ようやく「再現性のある成果」への第一歩を踏み出す。 【3年目：成果・貢献期】「型」ができる 自分の強みを活かした成果が出る。 年度をまたいだ継続的な改善が見える。 * ここで初めて「再現性のある価値提供」ができるようになる。 自分自身、3年未満で辞めた2社からは学びも成長も得られました。ただ、いま振り返ると 「成果を出すための筋力」までは育っていなかった と感じます。 3. 年収の伸びは“過去3年の積み上げ”で決まる これは完全に持論ですが「 今の年収は、3年前の努力の結果 」だと思っています。多くの企業では、評価や給与改定は過去の実績をベースに決まります。 スキルや実績には「蓄積効果」があり、行動してからそれが数字としての成果になり、評価され、給与に反映されるまでには1〜2年のラグが生まれます。 つまり、 年収の本質は「現在の価値 × 過去の蓄積」。 今の年収は、 過去3年（またはそれ以上）の投資に対するリターン なのです。だからこそ「短期間で転職を繰り返す＝積み上げが途切れる」ことになり、年収の伸びを自ら止めてしまうリスクがあります。 また、同じ会社に5年以上いると“ 在籍ボーナス ”が効いてくるのも事実です。おそらくこれは以下のような“ 無形の価値 ”が積みあがるからです。 業務知識の深さ 上司からの信頼の積み重ね 高難易度の仕事のチャンス 組織内での reputational capital これらは「社内」では強力な武器になりますが、転職市場にそのまま持ち出せるわけではありません。 ちなみに私は、転職時の最低希望年収を「当時の年収の2-3年前の金額」に設定するようにしています。 新しい環境で、今の年収に見合う価値をすぐに出す自信がないからです。（エージェントには「実際に下がると税金面で苦労しますよ」とかなり止められますが……） 4. 採用側からの見え方がポジティブに映りにくい 最後に、採用する側（面接官）としての客観的な視点です。 書類選考で3年未満の退職が連続している場合、どうしても以下のような懸念を抱いてしまいます。 仕事や会社を理解する前に辞めているのでは？ 本人側に理由があるのか判断しにくい 入社してもすぐ辞めるリスクがある スキルの積み上げが十分ではない可能性がある もちろん面接で事情を聞けば納得できるケースも多いのですが、複数回続くとポジティブには見られません。キャリアの一貫性がない場合は、さらに印象が悪化しやすいです。 とはいえ、「無理に3年働くべき」と言いたいわけではない ここまでデメリットについて書きましたが、3年未満で転職すること自体を否定したいわけではありません。無理に3年働こうとすることで、逆に以下のようなリスクも生じます。 合わない環境で心身をすり減らす キャリア最適化は早いほどよい（特に20代は貴重） 3年後には市場の状況が変わっている可能性がある つまり、 「3年未満で辞めるデメリット」と 「無理に3年を目指すリスク」 この両天秤をしっかりと理解した上で、ご自身の「3年間」をどうデザインするかを考えるきっかけになれば幸いです。 この記事を読んで、現在の場所を飛び出そうと思った方やラクスのプロダクト部に興味を持ってくださった デザイナー／PdM の方 は、ぜひカジュアル面談からご応募ください。※プロダクトマネージャーのカジュアル面談は、基本的に私（稲垣）が担当します！ ●採用情報 デザイナー career-recruit.rakus.co.jp   └ デザインマネージャー career-recruit.rakus.co.jp ／アシスタントマネージャー career-recruit.rakus.co.jp

はじめに こんにちは。楽楽販売の開発を担当しているuemuraです。 楽楽販売では11月に、初のAI機能をリリースしました。 楽楽販売をご契約いただいたお客様が導入準備をスムーズに進められるように支援する、チャット形式の機能となっています。 プレスリリースはこちら 。 本機能の開発PJは楽楽販売にとって（また私自身にとっても） 初のAI機能開発 、 初のアジャイル×スクラム開発 となっており、新しいこと尽くめでした。 AI機能を開発する難しさもさることながら、アジャイル×スクラム開発にもなかなか苦戦したため、その学びを残しておこうと思います。 目次 体制紹介 どのような流れで開発が進んだか フェーズ1：立ち上がり フェーズ2：仮説ドリブンの機能開発 フェーズ3：品質改善とリリース準備 良くなかった点 自転車操業に陥った インクリメントの品質を担保できていなかった 生成AIによるコーディングとの付き合い方 それでもスクラム開発して良かったポイント 最後に 体制紹介 従来の楽楽販売の開発の流れはいわゆるウォーターフォール型です。 プロダクトサイド（組織図の"事業本部サイド"）から要求が下りてきて、エンジニアがそれを実現します。 プロダクトサイドとエンジニアは組織構造的にも離れています。 関連部署だけを抜粋した組織図 ただ、市場に対して開発スピードのUPを図るためにも、本開発ではプロダクトサイドのメンバーとエンジニアで以下のようなクロスファンクショナルなスクラムチームを組みました。 プロダクトオーナー プロダクト戦略から1人 カスタマーサクセス（CS）から1人 エンジニア4人（私はココ） スクラムマスター（所属はエンジニアサイド） ※プロダクトオーナーが2人いる体制はスクラムの原則からズレているのでオススメしません どのような流れで開発が進んだか 開発期間は2か月半ほどでしたが、ざっくりと3つのフェーズで開発は進みました。 フェーズ1：立ち上がり ターゲット顧客の設定 楽楽販売はご利用いただいているお客様の業種や企業規模が多岐にわたります。 AI機能を開発するにあたって、全てのお客様に届く機能を作るというよりは、価値を提供したいメインターゲットを決めそのお客様に使っていただくことを第一に想定して開発を進めました。 CS業務の理解 ターゲットとなるお客様群に対して、楽楽販売の契約～導入までの間にCSがどんな支援を行っているのかをエンジニアがキャッチアップしました。 主に導入支援時のCSとお客様のやり取りの録画を確認することで、ターゲット顧客への解像度も上がりましたし、導入支援時のお客様、CSのペインを知ることができました。 とりあえず動くもの作成 ターゲット顧客にどんな体験を提供するかはこの段階では未定でしたが、まずはステークホルダーにこれから作ろうとしているAIチャット機能のイメージを持ってもらうために、最低限の会話と導入支援ができるシンプルなチャットを作ることを最優先しました。 フェーズ2：仮説ドリブンの機能開発 ターゲット顧客にどんな体験を提供すればいいかは探り探りだったので、主にCSの現場目線から必要な機能の仮説を立てプロダクトバックログ化していました。 エンジニアは仮説に対するフィードバックを高速にもらうために、バイブコーディング的にとりあえず動くインクリメントを毎スプリント積み重ねてスプリントレビューで披露しました。 ステークホルダーやCSの方々、実際のお客様からもフィードバックをいただき、実運用で課題になりそうな点を集め改善を繰り返しました。 最初は順調に進んでいるように見えていましたが、だんだんと、 プロダクトオーナーは集めた課題や新たな仮説のバックログ化 エンジニアはできたてのバックログを次のスプリントレビューに間に合わせるための短納期な開発作業 に追われることになりました。 このフェーズで高速にサイクルを回したおかげで探り探りだった機能のスコープを定めることができましたが、一方で開発内部ではバイブコーディングを繰り返したことによる負債がどんどんたまっていくことになりました。 フェーズ3：品質改善とリリース準備 これまでの負債を返すように、終盤はリリース品質の確保が中心になってしまいました。 フェーズ1,2と「スプリントレビューに間に合わせるためにとりあえず動くもの」を優先したことで、リリース品質に満たないインクリメントが積み重なってしまっていました。 そういった品質負債を解消し、リリースできる品質まで持っていくことに終始することになりました。 （スクラムを始める段階で、品質改善の予定は確保していましたが、当初の計画よりずっと大きなボリュームとなってしまいました。） 品質改善に追われつつも、何とかリリースを迎えることができました。 良くなかった点 開発を進める中でいかにもスクラム初心者がハマってしまう落とし穴にハマってしまったので、簡単に改善点を振り返ってみます 自転車操業に陥った 要件が探り探りだったため、開発期間中に 仮説⇒実装⇒検証 を繰り返すことになりました。 その結果、各スクラムイベントとスクラムメンバーは互いに首を絞め合うような負のサイクルに陥ってしまいました。 プロダクトオーナーは、 毎スプリント出てくるフィードバックの整理や新たな仮説のバックログ化に追われました。 結果、 将来のための計画や先を見据えたプロダクトバックログの整備ができない状態に陥りました。 スプリントプランニングでは、 整理され切っていないプロダクトバックログがスプリントゴールに入りました。 結果、スプリントバックログも具体性に欠けたものになってしまい、スプリントが始まってからプロダクトバックログを具体化する必要がありました。 エンジニアは、 「まず動くものを作らないとレビューに出せない」という意識のもと、短期開発に追われました。 結果、品質が犠牲になり インクリメント と リリース可能な品質 の乖離 が広がっていきました。 また、エンジニアはプロダクトオーナーへの支援として技術的な面からプロダクトバックログの整理を手伝うべきだったのですが、そこまで意識や手が回っていませんでした。 結果、未整理のプロダクトバックログが積み重なったまま次のスプリントへ…という負のスパイラルに陥ってしまいました。 原因と対策 PJ終了後にスクラムチームで振り返りを行ったのですが、いくつかの原因と対策が挙がりました。 要求があいまいだった アジャイル開発という名のもと、仮説と検証を繰り返す前提で要求があいまいなままスクラムが始まりました。 プロダクトオーナーは要求の整理をしつつも、エンジニアにバックログを用意しないといけないので将来よりも目先のことに時間を使わざるを得ない状況が続きました。 アジャイルとはいえ、スクラム開始前にターゲット顧客や届ける価値の方針を固めておき、スクラム中は方針実現のための仮説・検証に注力できるようにするべきでした。 1スプリントの期間が短すぎた 1スプリントを1週間で回していましたが、一度負のスパイラルに入ってしまうとリカバリーが難しかったです。 プロダクトオーナーやエンジニアに時間的な余裕を生むためにも次回以降は1スプリントの期間をもう少し長めに置くことを検討しています。 インクリメントの品質を担保できていなかった PJ終盤はインクリメントの品質向上に追われてしまいました。 これの原因は 完了の定義 を用意していなかったことに尽きると考えています 完了の定義とは 何をどこまでやれば「プロダクトバックログを完了とする」かを定義したリストです。 具体的には、以下のようなものが挙げられます コードレビュー 機能テストに合格 単体テスト合格 統合テストに合格 リグレッションテストが作成され合格している テスト環境にデプロイされている POはユーザーストーリーの完了を確認している 引用元: スクラムにおける完了の定義（Doneの定義）とは？ 完了の定義を置いておくことでリリース可能な品質を保ちながらインクリメントを重ねる効果が見込めます。 今回のPJでは「とりあえず動くものを作ってスプリントレビューに臨んでいること」にエンジニアが疑問を持つこともできていなかったので、 そういった意識レベルの改善のためにも完了の定義は必要でした。 生成AIによるコーディングとの付き合い方 上記2点の改善点の根本的な原因は アジャイル×スクラム に対する知識や準備不足であることは間違いありませんが、 個人的には、そこに 生成AIの活用方法の未熟さ も重なり、結果として課題が大きくなったと感じています。 生成AIによるバイブコーディングは「とりあえず動くもの」を作るのには強力です。 今回のPJでは 仮説⇒実装⇒検証 を繰り返すタイミングでバイブコーディングの力を借りることで、 高速にサイクルを回し、探り探りだった機能要件を定めることができました。 一方で、高速に実装できてしまうが故に負債もどんどんたまってしまったとも言えます。 どこかのタイミングでバイブコーディング的なAI活用から 「リリースを見越し、仕様や内部設計をしっかり固めながら実装するAI活用（強いて名前を挙げるなら、仕様駆動開発が近いでしょうか？）」 に切り替えるべきでした。 今回はそういった生成AIの活用方法の未熟さもあり、結果的に開発の負荷を高めてしまったと感じています。 （ただし、 仮説⇒実装⇒検証 を十分繰り返せていなければ、そもそも未だにリリースできていたかどうかも怪しいので、バイブコーディングしたこと自体が間違いだったとは思っていません） それでもスクラム開発して良かったポイント 何かと大変な点もありましたが、クロスファンクショナルなチームによるスクラム開発には明確に良かった点もあります 顧客志向が付いた ビジネスサイドの方と同じチームで働くことで、ビジネス課題や中長期の市場への向き合い方、またお客様や導入プロセスへの解像度が上がりました。 AI機能を開発をする。と最初に聞いたとき、自分のエンジニア的好奇心から「いかにもAIっぽい機能を作りたい」気持ちも生まれたんですが、スクラムチームの人と会話し、顧客の解像度を上げることで、「作りたいものを作る」ではなく顧客の困りごとを解決するための手段を考えるマインドにシフトできました。 スピード感をもってリリースできた 初の アジャイル×スクラム に苦労はしましたが、楽楽販売の従来の開発スタイルではもっとリリースまでに時間がかかっていたと思います。 世に出さないと価値は生まないので、これからもスピード感は大事にしていきたいです。 最後に この文章を書きながら 追加機能のリリースも先日行いました 。 追加機能の開発の中でも新たな課題も生まれましたが、一方で上記に挙げていた課題を一定解消することもできました。 この記事が、スクラム開発を始めようとしている人に少しでも役立てば幸いです。