はじめに

約半年間かけてプロダクトのフルリプレイスが終わりました。

今回はタイトルにもある通り「ユーザーの成功体験のために」を目指すために、技術・組織・文化のすべてと向き合い見直しました。

なぜフルリプレイスすることになったのか。なぜすべてを見直す必要があったのか。それらを今回は書き残しておきたいと思います。

自己紹介

中野区在住の中野です。

最近はパーソナルトレーニングに泣きながら通っています。ジムに行くまでは最高に憂鬱なのですが、トレーニングが終わると最高に清々しい気持ちになれるのが不思議ですね。

さて、現在はベンチャーでVPoEとしてなんでもやるマンをやっています。

担当しているのは技術戦略・技術選定・サービス選定・アーキテクチャ設計・チームビルディング・エンジニア採用・メンバー育成・コーチング・福利厚生の設計・評価制度の運用・1on1・雑務。

強みは、中長期の戦略を描き、それをチームが実行できる戦術に落とし込む力です。そしてどんな状況でも「ユーザーの成功体験」を意思決定の基準にできる、ブレない軸を持っています。

基本的なスタンスは「フェアであること」。誰かを不当に扱ったり、邪悪な選択をして得られる成果には意味がないと思っています。だから、もっとも嫌いなのは、自分の魂を汚すようなことです。

入社理由

なぜジョインしたのか聞かれることがあるので一言で言うと「営業組織をプロダクト組織に変換できたらおもしろそうだ」と思ったからです。

どんな会社なのかと言えば、いわゆる人材業界でほとんどが営業マンやコンサルタントが売上を作っています。そこにお気持ち程度のプロダクトがありました。

この弱小のプロダクトを徹底的に磨き上げて、誰もが諦めていたプロダクトでプロダクト組織に変換させることができたら脳汁が止まらないだろうなと思っています。

課題

さて、弊社のプロダクトの課題は本当に数えきれないほど多くありました。

しかしそれらは恐らく弊社独自のものというよりも、姿形を変えて程度を変えながら多くのプロダクトが抱えている課題と近しいものも多々あります。

その中でも弊社の最大の問題は「ユーザーに価値が届いていなかった」ことです。そこには色々歪な背景があるので、代表的なものを見ていきます。

組織面の課題

弊社にはPdMが存在していました。

しかし、そのPdMは営業マネージャー兼任で、数字責任者でもありました。当然、プロダクトに集中できる時間はほとんどありません。

さらに決定的だったのは、PdMが意思決定の権限を持っていなかったことです。

• 新しい施策を考えても、すべて「お伺い」が必要
• プロダクトの目的や「誰の課題を解決するのか」が曖昧なまま進行
• トップダウンで「作りたいから作って」と依頼され、提案しても「思っていたのと違う」と差し戻される

この状態では、PdMは名ばかりで実質的に存在していないのと同じ。結果として、プロダクトは「中身のないハリボテ」と化し、ユーザー価値を生み出すことができませんでした。

さらに追い打ちをかけたのが、枝葉の議論と短絡的な発想です。

• 上から提案されるものは枝葉ばかり
• 「UIを真似すればUXも再現できる」という浅い議論まで飛び出す
• 誰もユーザーの顔どころか輪郭すら浮かべず、話の軸は「売れるか／売れないか」ばかり

本来であれば、ユーザーの成功体験を作れば数字は後からついてくるはずです。しかし目の前の数字に追われ、小銭を拾うような発想しか出てこない。

わからないものは怖い。知らないものは怖い。勉強不足のまま選択肢が狭まっていく。

すべてが決済者が分かることベースで、ユーザーが主語になることは一度もありませんでした。結果、自分の「わかる範囲」だけでしか決裁できない状態になっていました。

つまりこれらの本質的な課題は権限の移譲に失敗していたこと。この一点に尽きます。

技術面の課題

現在も当時もプロダクトを支えてくださっていた方々に最大の感謝をしています。技術はいつでも最後に帳尻を合わせる場所になりやすいです。

その中で「何に向かってコミットすればいいのか」「本当にこれを今やることが正しいのか」など思うことは多々あったと思います。それでもプロダクトを維持し続けて頂けたおかげで今があると思っています。

しかし、多くの無理と帳尻合わせのツケはしっかりと蓄積しており、非常に多くの技術的な課題を抱えていました。

• 小さな修正でも全体に影響し、開発コストが高騰
• アジリティを失い、改善スピードが落ちていた
• 属人化が進み、新規メンバーの学習コストが極端に高い
• バグの温床になるものが多く問い合わせが絶えない
• 必要以上の維持コストがかかっていた
• ビルドトラップに陥っていた

他にもいくつもの課題が組織と技術の両面にありました。こういう状態では部分的な改善では焼け石に水でした。

だからこそ抜本的に技術と組織と文化をすべて見直し、プロダクトをフルリプレイスに踏み切りました。

準備期間（2024後半〜2025年1月）

さて、フルリプレイスすることを決断しても、すぐに作り始められるわけではありません。まずは「何を作るのか／どう作るのか」を整理し、技術と組織の両面で土台を整える必要がありました。

何を作るか

最初に取り組んだのは「指揮系統の整理」でした。これまでのようにPdMが名ばかりで権限を持たない状態では、また同じ失敗を繰り返すだけです。

そこで、事業に深い理解があり、業界についても詳しい上司（CTO）にPO（プロダクトオーナー）としての役割を一本化しました。

POと一緒に「これまでと同じものを技術を変えて作り直す」のではなく、会社のビジョンや実現したい世界に基づいて「何を作るか」を定義していきました。

これによって、意思決定権がなくお伺いをしてブロッキングされるという課題を断ち切ることができました。

どう作るか

次に考えたのはどう作るかです。社内にある既存の技術を踏襲する選択肢もありましたが、今後のことを考えればそれは負債の延命にしかならないと判断しました。

そこで、既存の技術スタックを一度すべて捨て、新しい技術基盤へコンバートすることを選択しました。

技術選定で意識したこと

新しいスタックを考える時に意識したのは、この先このプロダクトを開発するチームの姿です。必要なのは分業ではなく協業です。

メンバーはすべてがスペシャリストであり、スペシャリスト同士のコラボレーションが自然にできていることが、ユーザーに価値を継続的に届け続けるためにもっとも重要だと考えました。

そのためにはフルスタック×フルサイクルで動けるクロスファンクショナルチームが不可欠です。

さらに+αで意識したのは、AI活用とのシナジーと採用力の強化です。

プロダクト開発はやることが多岐にわたり、人がすべてを抱えるのは現実的ではありません。だからこそ「人がやるべきではないことはAIに任せる」という発想を前提に、AIとの親和性が高いスタックを選びました。

また、モダンなスタックを揃えることはエンジニアにとって魅力的な環境をつくり、採用力の向上にも直結すると考え、開発効率だけでなく、文化や人材面でもプラスに作用する選定を心がけました。

選択した方向性

これらを踏まえ、フロントエンドとバックエンドをTypeScriptに統一することを決めました。統一することで、誰もがどのレイヤーにも手を伸ばせるようになり、協業を前提としたチーム体制を実現できると考えました。

採用した技術スタック

すべて「選択と集中」の考えに基づき、コアは自分たちで、非コアはSaaSに任せる方針で揃えました。実際に採用したのは以下の通りです。

• フロントエンド：Next.js / React / Zod（入力バリデーション・型推論） / shadcn/ui（UIコンポーネント） / Storybook + Chromatic（UIカタログ化・自動ビジュアルテスト）
• バックエンド / API：Hono / Supabase（PostgreSQLベース） / Drizzle ORM / Zod（スキーマ・I/Oバリデーション）
• インフラ / デプロイ基盤：Vercel / Turborepo
• 認証 / セキュリティ：Auth0
• 品質 / モニタリング：Sentry / DevCycle
• CI/CD：GitHub Actions
• 開発環境 / コラボレーション：GitHub / Cursor / Claude Code / Devin / Jira / Notion / Figma

技術選定に対するスタンス

技術はあくまで手段でしかないと考えています。

我々が本当にやるべきことは、顧客に価値を届けること。そのために必要ならスイッチングコストを払ってでも選択肢を入れ替える。

逆に「技術的に好きだから」「流行っているから」という理由だけで採用することは絶対にしません。

大事なのは、技術を通じて顧客に価値を届けた事業にコミットすることです。

チームと顧客価値

価値を届ける主体はプロダクトそのものではなく、チームです。そのチームがクロスファンクショナルにワークできることが最も重要です。

だからこそ、今回は「フロントもバックもTypeScriptに統一」という選択をしました。

今後、もし別の技術が本当に顧客への価値提供を加速させるなら、その時は迷わず切り替えればいいと思っています。

人材育成

弊社はいわゆるミドルクラスが不在だったため、早急に育成することが急務でした。将来的にチームを技術でリードできるエンジニア、そして欠けていたUI/UXデザイナーの育成を同時に進めることにしました。

人が育つ時に必要なのは、机上の教育ではなく「自らバッターボックスに立ち、思い切りバットを振る経験」だと考えています。そこで、失敗したときのセーフティーネットを整え、フィードバックのサイクルを素早く回す仕組みを用意しました。

私自身が前に立って引っ張るのではなく、あえて多くのチャンスを彼らに回すことで、経験値を横取りせずに成長のサイクルを加速させることができたと思っています。

その結果、リプレイスを終えた今では、エンジニアはテックリードとしてチームを技術でリードできるようになり、UI/UXデザイナーもプロダクト改善やUXの民主化に向けて自らリードできるようになりました。

リプレイス期間（2025年1月〜2025年7月）

準備期間で「何を作るか」「どう作るか」が決まり、チームも立ち上がりました。

最初のメンバーはエンジニア2名とUI/UXデザイナー1名。小さなチームでしたが、スクラムを採用して毎週のスプリントで走り抜ける体制を整えました。

スプリント0では、最初の足並みを揃えるためにインセプションデッキを作成し、ゴールや価値観、ベクトルを一致させました。フルリプレイスの目的は「余計なものを作らず、ユーザーに必要な最低限を届けること」。この共通理解をチームで握ったのが大きかったと思います。

期間中は、プロダクトコードを書くのはもちろん、データベースの再設計とデータ移行も同時並行で進める必要があり、かなりハードな日々でした。それでもこのチームメンバーは毎週スプリントゴールを何が何でも達成し続け、着実に完成へと近づけてくれました。

6月には社内向けにリリースし、オペレーションと教育を回しながらユーザビリティテストを実施。我々の思い込みではなく、ユーザーの声からインサイトを見つけて改善を回すフェーズに移行しました。

そして1ヶ月後、7月にはパブリックリリース。途中で仲間も増えながら、半年間の走り抜けの末に無事フルリプレイスを完了できました。

その結果、私たちは「思い込みと自己都合だけのプロダクト開発」から抜け出し、長年積み重なった負債から解放されました。さらに、新しい文化を根付かせ、新しい技術基盤を築き上げることもできました。

単なるリプレイスではなく、過去を清算し、ユーザーに真正面から向き合う一歩を踏み出せました。

自己組織化されたチーム作り

リプレイスと並行して進めていたのが、自己組織化チームをつくることでした。

HRTを前提にした文化づくり

HRT（Humility / Respect / Trust）＝ 謙虚・尊敬・信頼。

これは自分たちを守るためにあるのではなく、笑顔で殴り合えるための必要な土台です。

「それは本当にユーザーの価値につながるのか？」「その機能は誰を幸せにするのか？」

私たちが投げかける問いは人格への攻撃ではなく、あくまでプロダクトへの問いかけです。意見や考えをぶつけ合える関係性をつくりました。

そして、プロダクトビジョンにそぐわないものには迷わずNOを突きつけます。ユーザーのためにならず、自己都合の開発になるようなことは絶対にやりません。それが誰の発案であっても、です。

我々の存在意義は顧客の成功体験にのみあります。それにコミットできないのであれば、そんなチームは存在する意味がありません。解散すればいいと本気で思っています。

だからこそ、顧客の成功体験に向き合い続けるために、HRTが不可欠なのです。日和ることなく、本気で殴り合える関係性こそが、ユーザーに価値を届け続ける前提だと考えています。

チームに課している制約

スプリントゴールを早く達成できたとき、皆さんのチームはどうしていますか？

多くのチームでは、余った時間でPBIを前倒ししてSBLに持ってきたりします。しかし、我々はそれを明示的に禁止しています。

なぜなら、プロダクト開発は短距離走ではなく長距離マラソンだからです。1スプリントをちょっと早く走ったところで、大局的にはほとんど意味がありません。

むしろ次々と「やること」を詰め込むことで、いつの間にか学びや改善の余白を食い潰してしまう方が危険です。

だから我々は、早く終わった分の時間は「学び」に使うと決めています。未来に備えてスキルを伸ばすことこそが、ユーザーに価値を届け続けるための投資だからです。

もちろん、力技で走り切ったり、とりあえず作り切ったものもあるでしょう。そういう時こそ、AIを活用してリファクタリングしたり、自分たちのプロセスを見直し、単なる余白ではなく、成長と研鑽に転換する仕組みにしています。

透明性への拘り

我々は「透明性」を単なるスローガンではなく、ユーザーに向き合うための前提条件だと考えています。

情報が閉じていると、判断はどうしても自己都合になってしまう。だからこそ、情報の非対称性を極力つくらないことを徹底しています。

具体的には、まず「スプリントレビューの全社公開」。毎週のインクリメントをリアルタイムで誰もが見られるようにし、普段プロダクトに直接関わらないメンバーも「いま何がユーザーに届こうとしているのか」を共有できる場を開いています。プロダクトを遠い存在ではなく、すぐそばにあるものとして感じてもらうことを狙っています。

次に「情報のフルオープン」。個人情報や1on1を除けば、すべての情報は誰もがアクセス可能な状態にしています。これらは個人のものではなく会社の資産であり、必要な時に必要な人がアクセスできるのが当たり前だからです。

ただし「透明性＝情報を垂れ流すこと」ではありません。透明性と情報の洪水は別問題です。情報に溺れてしまうのは透明性の副作用ではなく、情報の整理不足にすぎません。

そのため我々はプロダクトに関する情報をすべて「Knowledge」というデータベースに一元管理しています。ツリー構造ではなくラベルを用いた横断的な整理を基本にし、検索性とビュー切り替えで誰もが迷わずアクセスできる仕組みにしました。これによって「どこに書けばいいかわからないから書かない」といった属人化や、いわゆる"神ディレクトリ"問題を避けています。

透明性とは「スローガン」ではなく、ユーザーのために正しい判断をし続けるための仕組みです。だからこそ徹底しているのです。

採用（2025年5月下旬〜6月下旬）

リプレイスと自己組織化を走らせながら裏では福利厚生や労働条件の改善活動をしていました。

福利厚生の改善

エンジニアとして魅力が皆無の福利厚生だったので、これを機に一から見直しました。正直、思い出せるのは「社会保険完備」くらいで、あってないような状態だったと思います。

そこで「単なる制度」ではなく、エンジニアが学び・働き・挑戦できる環境をどう作るかを会社として何度も対話しました。

その結果、以下を追加しました。

• フルリモート / フレックス勤務
• 書籍購入手当
• リモート手当
• カンファレンス補助

さらに現在は「特別休暇制度」も協議中です。

これらは単なる福利厚生のアップデートではなく、採用や定着、そして長期的にユーザーへ価値を届け続けるチームを作るための投資だと考えています。

条件面の改善

当時の給与条件は、いわゆる市場相場より安い状態でした。

さらに問題だったのは、既存メンバーよりも新しく入った中途メンバーの方が給与が高いという逆転現象。

これでは「事業に長くコミットしている人ほど報われない」という構造になってしまいます。「気にしない」という声もあるかもしれませんが、それは建前です。人が本気でコミットし続けるには、正当に報われる仕組みが必要です。

そこで、営業組織と同じ給与テーブルを使っていたものを刷新し、エンジニア職に適した新しい給与テーブルを定義しました。

不足していた部分は補填を行い、評価制度についても営業と同じ物差しで測られていた状況を改めました。併せて、給与テーブルを押し下げる要因となっていた等級制度についても見直しました。

現在は新しい給与テーブルを適用できており、今後は技術職の評価制度を適用し、それぞれの専門性に即した正しい評価がされる世界を目指しています。

結果

こうして基盤を整えた上で採用を始めた結果、わずか1ヶ月で採用成功。

これは「運がよかった」のではなく、最初から採用を視野に入れて全部を作り直したからこそ当然の結果でした。

そしてもうひとつ大きかったのは、制度や条件の整備が「採用のため」だけに留まらなかったことです。メンバーが長く安心して学び・挑戦できる環境を用意できたことは、自己組織化チームをさらに強くし、文化を定着させる土台にもなりました。

成果のまとめ

半年間にわたるフルリプレイスと並行した組織改革・採用活動の結果、私たちはいくつもの大きな成果を手にすることができました。

まず、約20スプリントでフルリプレイスを完了し、本番稼働まで到達しました。

長年の負債から解放され、アジリティを取り戻したことで「変化に強く、捨てやすい基盤」を手に入れました。これは単なる技術刷新ではなく、過去を清算し、ユーザーに真正面から向き合うための再スタートでした。

次に、自己組織化チームの確立です。

HRTを前提にした文化、透明性の徹底、余白を「学び」に変える仕組み。これらを組み合わせることで、マネージャー不在でも価値を届けられるチームへと進化しました。いまではテックリードやUI/UXデザイナーが自ら意思決定し、プロダクト改善をリードできる状態に育っています。

さらに、採用と制度の刷新にも成功しました。

福利厚生や給与テーブルを一から見直し、エンジニアが長期的に学び・挑戦できる環境を整備。結果として、わずか1ヶ月で採用成功。これは偶然ではなく、最初から採用を視野に入れて制度や基盤をつくり直した必然の結果でした。

こうして、技術・組織・文化・採用はそれぞれ独立した施策ではなく、すべてが「ユーザーの成功体験」という一本の線でつながっていたことを証明できたと思っています。

おわりに

この道のりを走り切れたのは、私ひとりの力ではありません。

最後まで私の言葉を信じてくれた上司と、ハードな要求に応え続けたチームメンバーがいないと絶対に実現することができなかったと思っています。

本当にありがとうございました。

ただ、ここで終わりではありません。我々はようやくユーザーに価値を届けるというスタートラインに立っただけに過ぎません。

引き続きユーザーの成功体験を届ける挑戦は続いていきます。これからも「ユーザーの成功体験」を軸に、技術も組織も文化も問い直し続けます。

最後にtimesチャンネルで流した自分のポエムで締めようと思います。

自分が普段思っていることや考えていることの一部をざっと書きましたw 自分にとっても最も大事なのはユーザーです。そしてそのユーザーに価値を届けられるのはチームです。あとはすべてオマケです。 我々の意思決定の軸はユーザーがどうなれるのかです。我々の都合なんてユーザーからしたらどうでもいいのです。 常に「ユーザーを見ろ」と自分が言うのは我々の中に答えはないからです。間違えたならわかった時点ですぐに来た道を戻ればいいです（アジリティって大事でしょ？こういうのに技術が活きるのです）。 誰も未来を見通す力なんて持っていないので人は間違える生き物です。その中でチームメンバーに迷惑をかけることもありますが、お互い様です。自分は生き恥を重ねて生きています。だいたいそんなもんです。 我々はなぜここにいるのか。すでに共通認識があるはずです。そして目指しているビジョンがありますよね。そのために1日8時間以上仕事して仕事後研鑽をしているのです（今はまだ自分のためかもしれませんが）。 我々はチームメンバーのために仕事していないですし（結果的に早く価値を届けようとするとチームのパフォーマンスを上げるために色々することになりますが）、我々は社内の誰かの顔色を見て仕事しているわけではありません。 我々はユーザーを見るべきであり、ユーザーがどんな状態になれるかに向き合うべきです。我々が遠慮し合ってもユーザーには何もメリットはないのです。 常にユーザーを見てユーザーに向き合い、今我々ができる意思決定をすればいいのです。あとは思いっきりバットを振り切るだけです。 自分は「許可を求めるな、謝罪せよ」を大事にしています。 皆さんはこれからより高みを目指していきます。それはきっとスキル面において自分よりも先にいくことになります（行ってもらわないと困ります）。 その時に意思決定者が理解できていない、わからない時に許可を求めるとどうなるか知っていますか。多くの場合はわからないから怖いから拒絶をします。 でもそれをやる価値を知っているのは最前線でフルコミットしている皆さんだけです。1から全部説明して許可もらう必要よりも、やってうまくいけばいいし、やってだめだったら何事もない状態にリカバリーすればいいんです。 そこで得た経験値はより皆さんを強くします。そしてこの言葉より皆さんの自己組織化の力になってくれるはずです。 みなさん知っていますか？プロダクトには人格があります。その人格を形成しているのは我々です。 この一面では寄り添ってくれるが、この一面では自己中で邪悪な人と仕事をしたいですか。当たり前ですがユーザーは気づきます。黙って離れて愛想を尽かされます。ユーザーは賢いです。 ただプロダクトを作るだけではなく、ユーザーに向き合いたいですね。プロダクトの人格も作り、常に誰かに必要とされているプロダクトでありたいです。 そして継続的にプロダクトを通して誰かを幸せにしているチームでありたいですね。

最後までお付き合い頂きありがとうございます。

yutanakano

WEBエンジニア

大阪生まれのゆとり世代です

趣味はバイクでツーリングに行くこと

愛車は Ninja ZX-25R SE KRT EDITION

Expoでプロダクトを作っています