前回までの内容
自己組織化されたチーム作り
リプレイスと並行して進めていたのが、自己組織化チームをつくることでした。
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でプロダクトを作っています
