こんにちは、3回目の登場です！ YOUTRUST で Web エンジニアをしている林（YOUTRUST）です。
今月末で入社してからちょうど1年になります！🎉
前回の記事 を書いたのがちょうど入社半年後だったので、半年ぶりの登場です！
あっという間に1年が経ってしまいました。
前職は受託開発が中心で、書いてきた言語はほぼ PHP（Laravel）。YOUTRUST のメイン技術スタックである Rails / React についてはほぼ未経験の状態からのスタートでした。
そんな状態から1年、振り返ってみるとこの1年で「開発者」と「リーダー」という2つの役割を経験しました。
役割が変われば、やることも学ぶことも大きく変わります。それぞれで何をやって何を学んだのかを、順に振り返ってみます。
YOUTRUST での1年がどんな感じか、少しでも伝われば嬉しいです！
開発者としてやってきこと・学び
YOUTRUSTにはUnitと呼ばれるチームの単位がいくつかあり、自分はこの1年で複数のUnitを経験しました。まずは開発者として駆け抜けた前半を、Unitごとに「やってきたこと」と「そこで学んだこと」をセットで振り返ります。
企業Unit（入社直後）── コードベースとドメインのキャッチアップ
入社直後は企業Unitに配属され、社内管理画面（admin）のReact化タスクからスタートしました。 入りやすいタスクから順にこなしながら、RailsとReactのコードベースに慣れていきました。
この時期に特に苦戦したのが、コードベースとドメインのキャッチアップ です。
YOUTRUSTはtoC向けSNSに加えてtoB側のTALENT・SALES・Adminなどサービスが多岐にわたり、最初から全体を把握するのはかなり難しいなと感じました。
ここは、
- AIに概要を整理・図解してもらう
- ローカルやdev環境で実際に触る
- Notionの社内ドキュメントを読む
- 有識者に素直に聞く
の4つを意識的にやってきました。
1年経った今も全てを完璧に把握まではできていませんが、「どこに何があるか」が頭に入る速度はだいぶ上がった気がします。
送受信Unit ── タイピングインジケーターと Redux との格闘
その後は送受信Unit（メッセージ機能を中心に担当するチーム）に異動し、細かい修正・調査タスクや、タイピングインジケーター（メッセージ画面で相手が入力中の時に「・・・」を表示する機能）の新規実装を担当しました。
タイピングインジケーターについては別途技術記事を書いているので、興味のある方はぜひこちらもお読みください！
この時期に一番苦戦したのはフロントエンドの Redux でした。
コードを追うのも難しく、何度も詰まったのですが、ペアプロで丁寧に教えてもらえたおかげで、なんとか乗り越えることができました。
今振り返ってもこのペアプロは本当にありがたく、「分からないことは一人で抱え込まず、人に頼る」ことの大切さを実感した時期でもありました。
打開Unit ── 1 → 10 のプロダクト開発の難しさ
その後体制が変わり、打開 Unit（既存ユーザーへの価値提供を中心に担当するチーム）の所属となりました。
Unitの目標としてリリース目標であったこともあり、様々な種類のタスクを数多く経験することができました。
- ログやSEO 関連の改修
- 経歴入力 UI の変更
- 「AI らくらくプロフィールビルダー」という新機能のフロントエンド実装
- ユースタへの「いいね」機能の新規実装
- 企業名義投稿のデータ移行
- push 通知の改善 等
「AI らくらくプロフィールビルダー」*1の 0 → 1 開発、データ移行など、それまでやったことがないタイプの開発をたくさん経験でき、エンジニアとしての引き出しが大きく増えた実感があります。
特にフロントエンドのタスクが多く、React に対する経験と知見をたくさん吸収できた時期でもありました。
この時期に学んだReactについて、公式ドキュメントの輪読会を社内で行いました。 こちらについても、別途記事にしているのでよければこちらも！
そしてこの時期に強く感じたのが、すでにユーザーが一定数いるプロダクトに、機能追加・修正をしていく難しさ、いわゆる 1 → 10 の難しさでした。
前職では受託開発が中心で、いわゆる 0 → 1 の新規開発の機会の方が多くありました。
0 → 1 では既存機能の整合性担保という観点がなく、作ろうとしている機能にのみフォーカスしていれば良かったのですが、
YOUTRUST では：
- 今回の変更による既存機能の整合性担保
- データ変更を行う場合には、既に DB にある既存レコードとの整合性考慮
- Web だけでなく、モバイルアプリ側のバージョン差も考慮する必要がある（特に API 設計）
といったように、考慮すべき軸が一気に増えました。
特にアプリ側の考慮は、自分にとって新鮮でした。
Web と違って、リリースしたコードに全ユーザーが同時に切り替わるわけではないので、旧バージョンのアプリも動き続ける前提で実装をしないといけません。
「強制アップデートをかけるまでは旧コードを残しておく」「新旧両方のレスポンスを返せる API にしておく」といった判断は、Web だけ触ってきた身からするとなかなか馴染みがなく最初は戸惑いましたが、こうした考慮事項と向き合いながら設計・実装を進める経験は、自分にとって本当に大きな学びになりました。
リーダーとしてやってきたこと・学び
オポチュニティUnit ── リーダーとして役割の変更
4月からはオポチュニティUnit（ユーザーへの様々な機会提供の機能を開発するチーム）に異動し、同時に リーダーを任せてもらえることになりました。
このタイミングで目標がリリースから数値目標へと変更になりました。
そのため、いくつか機能追加や改修の実装も担当しましたが、4月以降の業務全体を振り返ると実装者としての時間よりも リーダーとして「チーム運営」や「Unit の目標達成のために何をどうやるかを決める」 ことに使っている時間の方が圧倒的に多くなりました。
具体的にはやることが、
前） 実装中心
後） 目標数値責任 / データ分析 / 方向性・施策決め / デリバリー管理
と変化し、プレイヤーとして実装する側にいた頃と、Unit の方針を決めてメンバーに動いてもらう立場とでは、考えるべきことも、難しさのポイントもまったく違いました。
手探りの連続でしたが、その分この 2ヶ月で学んだことも多かったです。
1. データを見て "仮説" を立てる難しさ
リーダーになってから、施策を考える前段としての「データ分析」の比重が一気に増えました。
最近は社内に整備された BigQuery MCP サーバー にとても助けられていて、AI 経由で BigQuery に素早くアクセスできるので、「数字を出す」こと自体はかなり手軽になりました。
ただ、やってみて痛感したのは、その数字からどんな仮説を立てるか、そもそもどの数字を見るべきか、という判断はまだまだ人間の仕事だということです。 ツールが進化して数字を出すのが簡単になったぶん、むしろ使い手側の仮説思考が問われるなと感じています。
この 2ヶ月、ファネル分解 → レバー選定 → 動かすレバーに対する施策出し、という型に沿った分析が少しずつできるようになってきました。とはいえまだまだ改善の余地はあるので、ここは引き続き磨いていきたいところです。
そしてもう一つ、データ分析をやる中で改めて気づいたのが ログの重要性 です。 前職の受託開発では、エラーやアラート用のログは入れていたものの、「ユーザーの行動を分析するためのログ」という発想がそもそも自分の中にありませんでした。 このあたりも、自社開発でプロダクトを長く改善していく環境ならではの学びだなと感じています。
2. "選択と集中" ──「やらないこと」を決める
オポチュニティUnitは対象範囲がとても広く、限られた人数で全部に手を出すことはできません。
だからこそ「やらないことを決める」「やる範囲を絞る」ことの大切さを学びました。
そしてこれは、チームだけでなく自分自身についても同じでした。
1人の開発者だった頃と違い、数値責任・分析・施策決め・デリバリー管理と一気にやることが増え、マルチタスクでパンクしそうになることもしばしばありました。
この経験から、日・週単位で「今週は何をやって、何をやらないか」を決めること、そして一人で抱え込まずに適切にメンバーに任せることが、仕事を前に進めるうえで本当に重要なんだと改めて痛感しました。
AI のおかげで作業スピードは格段に上がり、何でも並行して進めやすい環境になりました。ただ、だからこそ気をつけたいのが、あれもこれもと同時に手をつけてしまうことです。 結局どれも中途半端になり、最後まで終わらない、ということが何度もありました。一つずつ確実に終わらせていく ことの大切さを、この2ヶ月で改めて実感しています。
3. "進捗感" をつくること
上の「一つずつ終わらせる」とも繋がるのですが、個人としてもチームとしても 進捗感 がすごく大事だと感じています。
一つ終わらせたという感覚がないまま並列でいろいろ進めていると、「結局何も進んでいないのでは」という感覚に陥り、負のループに入ってしまいます。
チーム全体でも同じで、施策をリリースして終わりにせず、分析して効果があったかを確認し、効果がなければ「次はこう改善しよう」とサイクルを回すことで、進捗感が生まれます。
このサイクルがあるかないかで、チームの空気は大きく変わります。なければ「リリースはしたけど、これって意味あったんだっけ？」と手応えのないまま進み、いつのまにか「言われたことをやるだけ」のチームになってしまいます。
逆にサイクルが回っていれば、一つひとつの施策に意味を感じながら前に進むことができます。この差を生む "動き方"を設計することが、UL の大事な役割だと学びました。
4. "正解" を求めず、決めたことを正解にしていく
最後に、これが一番大きな学びかもしれません。
プロダクト開発に「これをやれば絶対うまくいく」という 正解はありません。やってみないと当たるかどうか分からないことばかりです。
だからこそ、正解を探して立ち止まるより、仮説を立てて決めて、決めたことを正解にしにいく方が大事ということを肌で感じました。 以前の自分は「正解を見つけてから動きたい」タイプだったので、ここはこの2ヶ月でだいぶ意識が変わった部分です。
これから
振り返ると、開発者と UL という立場の違う2つの役割を経験できた1年でした。
どちらも初めてのことも多く、成長できた部分もあれば、うまくいかなかったことや「もっとこうすればよかった」と思う場面も少なくありません。
ただ、その一つひとつが今の自分の引き出しになっているのは確かで、課題が見えたこと自体も含めて、得るものの多い1年だったと感じています！
2年目以降は、この1年で学んだことを活かして、一開発者としての技術スキルの向上と、リーダーとしてチームを前に進める力の両方を磨いていきたいです。
ここまで読んでいただき、ありがとうございました！
YOUTRUST ではエンジニアを募集しております！ 一緒にプロダクトをより良くしていきたいという方はぜひご応募ください！！
*1:職務経歴書やwebサイトからプロフィールを自動作成する機能。今は登録後7日以内のユーザーに提供しています。
