はじめに
本記事はUzabase Advent Calendar 2025の20日目の記事です。
ユーザベースに入社して半年。私が入らせていただいたチームは、リリース前のAIプロダクト、Speeda AI Agent の開発チームでした。
入社前のチーム選びで説明してもらった言葉が、今でも耳に残っています。
「チームには関数型の神ともう一人、開発チームの中でも特に強い人がいる。」
「作るものが難しい、最近はコードを書くよりも議論している時間の方が今は長い。」
「強い人に揉まれ、正解のないハイレベルなプロダクトを作りたい」と思っていた私にとって、それは最高の環境に思えました。しかし、そのチームに入る決断がとてもありがたくも大変な日々の始まりでした...。
その中で大変だったこと、ありがたいと感じたことがいくつかあったので半年間を振り返りながら書いていきたいと思います。
大変だったこと
1. 強すぎるメンバーとの差が大きすぎた
Speeda AI Agentは、参考にできる前例がありません。そのため、チームの業務は「コードを書くこと」以上に「問いを立て、本質を議論し続けること」にあったように感じました。
しかし、その議論に参加するためには、膨大なビジネスドメインの知識と、高度な設計知識が不可欠でした。当初の私はその両方が圧倒的に不足しており、1時間議論を聞いているだけで、脳のキャパシティが限界に達して何も考えられなくなるほどでした。
何より辛かったのは、地頭の差を痛感したことです。メンバー全員が猛烈なスピードで話し合い、瞬時に理解を深めていく。そのスピード感についていけない自分への不甲斐なさに、毎日帰り道はぐったりと疲れ果てていました。
2. ペアプログラミングが全くうまくできない
Speeda Product Teamで経験した「ペアプログラミング」は、私にとって非常に大きな壁でした。
ペアプロでは、実際に手を動かしてコードを書く「ドライバー」と、一歩引いた視点でナビゲートする「ナビゲーター」に役割を分担します。現場ではこの役割を都度スムーズに入れ替えることが求められますが、当時の私はそのリズムに全く対応できませんでした。
特に困難だったのが、「状況を理解できていない側が積極的にドライバーを奪う」という振る舞いです。本来、わからない側が手を動かすことで認識の齟齬を防ぐべきなのですが、ペアの思考スピードに圧倒されるあまり、自分の思考が追いつく前にコードが進んでいく。「今のどういう意味ですか？」と止める勇気が出ず、わからないことが多すぎて作業を止めてはいけない、相手に任せたほうがスムーズだという思い込みに囚われていました。理解が曖昧なままナビゲーターに頼り切り、本来奪うべきドライバーの役割を放棄してしまう。そんな自分への焦燥感だけが募る日々でした。
さらに、1日に数回行われるペアチェンジが追い打ちをかけます。交代のたびに全く異なる文脈へ飛び込み、即戦力として貢献しなければならない環境。コンテキストの誤認から適切な共有ができなかったり、理解不足のまま進めてはチームに何度も迷惑をかけてしまいました。
平日は常に、持てるすべてのキャパシティを使い切ってギリギリ食らいついているのかついていないのかの状態でした。一週間を終える頃には心身ともに完全に空っぽになってしまい、土日はただ泥のように眠って回復に充てるだけ。たまに旅行に出かけても、疲れのせいで心の底から楽しむ余裕すらありませんでした。焦りから「勉強しなければ」と思っても、机に向かう体力が全く残っておらず、一日中眠ることでしか翌週の準備ができない。それは単に「仕事で少し疲れた」という次元ではなく、全エネルギーを使い果たして燃え尽きてしまうような、過酷な日々でした。
3. わからないことがとにかく多すぎた
Speeda Product Teamでは、アジャイル、TDD、クリーンアーキテクチャ、そしてモデリングといった技術が、単なる知識ではなく「実戦で当たり前に使える基本スキル」として深く根付いています。
この半年間、私はバックエンド、フロントエンド、ツール、そして仕様を表現し、かつ品質を担保するためのE2Eテストの実装まで、計4種類のプログラミング言語に触れてきました。新しい言語仕様を覚えるだけでも必死な毎日でしたが、本当に大変だったのはその先にありました。領域や言語が変わっても、チームが追求する設計の質には一切の妥協がなかったからです。言語ごとの特性を理解しつつ、いかに保守性の高いコードに落とし込むか。日々の議論を通じて、なぜ目の前のプロダクトのコードのほとんどが綺麗で読みやすいのか、その裏にある圧倒的な思考の量と意思決定の重みを学ばせていただきました。
特に衝撃を受けたのは、設計議論の深さです。単に「仕様通りに動くものを作る」ための議論ではなく、「このドメインモデルは現実を正しく表現できているか？」「この責務分割は将来の変更容易性を担保できているか？」といった抽象度の高い対話が、ペアプロ中もそれぞれのチームでの話し合いでも絶え間なく飛び交います。
これまで私は、特定の言語の書き方さえ知っていればエンジニアとしてやっていけると思っていました。しかし、この半年で痛感したのは、言語やツールはあくまで手段に過ぎないということです。本当に重要なのは、その根底にある「ソフトウェアをどう設計し、どう育てていくか」という哲学を理解することでした。強いエンジニアの設計思想をその都度インプットし、自分の中に落とし込んで、実務のあらゆる局面でその再現を試みる。そのサイクルを回し続けた時間は、間違いなく人生で最も技術と真剣に向き合った大切な時間になりました。
ありがたかったこと
1. 成長を本気で支えてくれる
Speeda Product Teamには、実力者が多数在籍しています。しかし、それ以上に驚いたのは、「誰かの成長を助けることに一切妥協しない」という文化です。
クリーンアーキテクチャの責務の切り分けや、ドメインモデリングで悩んでいるとき、チーム内外を問わず誰に聞きに行っても、皆が手を止めて熱心に、かつ丁寧に教えてくれます。仕事中だけでなく、仕事終わりでも疑問を投げれば、理解できるまで解説してくれる。
「誰かが急に抜けても止まることなく、高いレベルで開発が進んでいく」。そんな強靭な組織のパワーを肌で感じ、これほどまでに頼りになるメンバーと一緒に仕事ができることは、私にとって何よりの救いでした。
2. エンジニアリングが生きがいに変わった
正直に言うと、プログラミングを学んだ当初は「フリーランスになって年収1000万稼ぎたい」という世俗的な動機が強かったです。
しかし今は、そんなことはどうでもよくなりました。純粋に技術力を高め、より良いプロダクトを作りをしたい心から思えるようになりました。
自分の至らなさを突きつけられるからこそ、成長への渇望が生まれ、勉強が全く苦ではなくなりました。ソフトウェアエンジニアという仕事が、本当の意味で好きになり、生きがいになったと感じています。
3. 人格者ばかり
実際に中に入って感じたのは、ユーザベースの人たちの技術力の高さはもちろん、それ以上に皆さんの謙虚さと人格の素晴らしさです。
私は少し人見知りなところがあるのですが、そんな温かい皆さんに助けられ、最近では真面目な設計議論だけでなく、冗談を言い合えるメンバーも増えてきました。自分のダメなところを素直に認め、「次はもっと良くしよう」と前向きに思わせてくれる。そんな心理的安全性の高い雰囲気に、日々支えられています。
4. 組織全体でプロダクトを育てる一体感
ユーザベースに入って感動した一つにビジネスメンバーの熱量があります。 営業、マーケティング、CSの方々が、プロダクトの価値を届けるために泥臭く努力し、ユーザーからのフィードバックを届けてくれる。
ビジネスメンバーがこれだけ頑張っているんだから、自分も最高の開発で応えたいと最近は特に強く思っています。
プロダクトは作って終わりではない。組織全体の努力を肌で感じることで、プロダクト開発がより自分ごとになりました。この環境があるからこそ、自分自身の勉強も楽しくできているんだと思います。
終わりに
正直に言って、入社前の自分は、胸を張って「プロのソフトウェアエンジニア」と呼べるレベルではなかったと痛感しています。
当時は、テストも書かず、設計も学ばず、ただ「なんとなく動くもの」を実装する日々でした。保守性、特に「理解容易性」「変更容易性」「テスト容易性」といった、長くプロダクトを育てるために不可欠な視点がすっぽりと抜け落ちていたのです。適切な意思決定を積み重ねるという、プロとして当たり前の難しさを知らずにいました。
半年経った今も、まだまだできないことばかりで、圧倒される日々は続いています。部屋に積み上がっていく技術書を前に「自分はまだスタートラインに立ったばかりだ」と実感する毎日です。
しかし、今は明確に自分はどうなりたいかが見えています。積まれた本を一つずつ血肉に変え、理論と実践を繋ぎ合わせることで、1日も早く1人前としてチームに貢献できる存在になりたい。
これからもチームメンバーからのフィードバックを真摯に受け止め、着実に歩みを進めていこうと思います。また、開発だけでなく、まだあまりお話しできていない社内の皆さんとも積極的にコミュニケーションを取り、この素晴らしい環境をもっと深く知っていきたいです。
半年間、本当に疲れましたが、この環境にいれたからこその成長が多くあったんじゃないかなと思います。これからもこの環境に感謝して頑張ります。
その他資料
この半年間に読んだ本 (途中までの本もあり)
一回読んで理解できていない、または忘れている本もあるため、再読したいと思ってます。