この記事は MOSH Advent Calendar 2025 の21日目の記事です。
こんにちは！勝間（@ryo_katsuma）です。今年の8月にMOSHに入社して、現在は新規機能開発チームでリードを担当しています。
前職のクックパッドには16年ほど在籍していました。大人数の開発チームのリードや、新規事業での開発組織のマネージャーなど、いろいろな経験をさせてもらいましたが、そんな背景もあって、MOSHに入社してまもなく、現在所属している開発チームのリードを任せてもらうことになりました。チームはエンジニア4名（私含む）、PdM1名、デザイナ1名の小規模なスクラムチームです。
入社して4ヶ月ほど経ち、チームにも馴染み、チーム全体での開発も順調に回ってきた感覚があるので、自分なりにどんな工夫をしてきたかを振り返ってみようと思います。
自分の立ち位置を見極める
チームにJoinして感じたことを整理すると、次のようになります。
強み
- メンバーの技術力が高く、実装スピードが早い
- 難易度が高そうな領域の開発もどんどん進める
伸びしろ
- メンバーは性格的に口数が多い方ではなく、議論は非常に穏やか
- チームをまたいだ議論が少なく、組織横断の技術的アプローチがあまりとれていない
前職での経験上、こういった状況には改善の余地がありそうだと感じました。ただ、コードベースの理解は実際にはできていないし、チームメンバーとの人間関係も構築できていない状態です。いきなり「ここはこうすべきだ」のような声を上げるのはやめていました。
逆の立場で考えてみると、いきなり入ってきた人がリードとしていろいろ主張し始めるのは、違和感や抵抗感を持つのが自然です。信頼関係も構築できていない段階で「今までのXXはやめて、YYにしましょう」と言われても、なかなか素直に受け入れにくいはず。
とはいえ、技術的な貢献でいきなり存在感を出すのは難しいかもしれない一方で、議論を促すことや、チームや組織のコミュニケーションを活発化させるアプローチなら、自分にもできることがあるかもしれない。そんな感覚がありました。
こうした所感をもとに、最初はリードとして振る舞うことよりも、まずはチームの一員として信頼を積み重ねていくことを意識しました。
1. エンジニアとして貢献することから始める
その中でもまず意識したのは、あくまで「エンジニア」としてチームに貢献することです。コードを書いて顧客のための新しい価値を生み出す。シンプルですが、この点を一番重要視していました。
コードベースに馴染みがない中なので、当然ながらAIをフル活用しています。CursorやClaude Codeを使って、コードの理解を深めながら実装を進めています。たとえば、既存のコードベースについてAIに質問しながら理解を進め、メンバーに相談するときも丸腰で聞くのではなく「ここまでは理解したけど、この部分からわからない」とフィードバックの質を高めることを意識しました。
もちろんAIに頼りきりではなく、レビューでフィードバックをもらうことや、日常的な会話を通して、チームのコンテキストを吸収していくことも行います。
また、AIのおかげでキャッチアップに使う時間が短縮できた分、メンバーのコードレビューにも積極的に時間を割くことを心がけました。
これらを積み重ねながら、少しずつチーム開発での貢献や、開発環境の改善などを通じて、チームメンバーたちと信頼関係を構築できてきたのかと思います。
2. 苦手なことは認めて頼る
私はアプリケーション開発の中でも、サーバーサイドの経験が中心でした。そのため、Reactを中心とするフロントエンド開発は業務でほとんど経験は無く、趣味の開発での経験程度に留まっていたため、得意ではありません。また、MOSHのプロダクト固有の設計思想やドメイン知識についても、入社直後は経験が浅い部分があります。
こういった苦手な領域については、素直に「ここはわからないので教えてほしい」「この設計は自分だと経験不足で進められないので相談させてほしい」と積極的に頼ることを心がけていました。
1人で抱え込んで時間をかけるよりも、詳しい人に頼ったほうがチーム全体としては生産性は上がります。また、副次的にお互い困ったときは声を上げやすい雰囲気を作ることにも寄与できていたんじゃないかなと思います。
3. 停滞を一番避ける
MOSHは順調に成長しているものの、まだまだスタートアップの組織です。このような組織において、開発が停滞するのは一番避けたいことです。この観点でのトライは技術やコードベースの知識に依存しないので、入社直後であっても比較的貢献しやすいポイントでもあります。
具体的には、以下のようなことを意識しています。
- すぐに意思決定できるものはその場で決める。 持ち帰って検討するほどでもないことは、その場で判断してしまう。
- 30分のミーティングを設定するより、5分話せば済むことはその場で話す。 非同期のやり取りが長引きそうなら、huddleやGatherでさっと話して決める。
- 他のチームに確認が必要だけど、「確認しないとね」で止まりそうなら、その場で動く。 他チームの状況把握が必要だけどチームが止まってしまいそうなときは、「今Slackで聞いちゃいましょう、すぐわかりますよ」とその場で動く様子を見せる。
- 議論の論点を整理してから同期する。 共通技術基盤を利用した実装方法のすり合わせなど、いきなりSlackで話しかけてもコンテキストが伝わりにくい話題は、まずIssueで論点を整理してから同期ミーティングで意思決定する。
- 誰もやらないなら「自分がやる」と宣言する。 ボールが浮くような状況の多くの場合は、誰が担当しても実際は差が無いものが大半です。困ることがあったら質問すればよいので、まず溢れたボールは拾います。
とにかく、停滞する時間を減らし、物事を前に進めることを強く意識しています。これは経験があってもなくても実践できることなので、新しい環境でも早い段階から意識しやすいと思います。
4. 1on1でフィードバックをもらう
チームではスプリント形式で開発を回していることもあり、定期的に振り返りを行っていますが、一方でメンバーがいる場では言いにくいこともあると思います。そこで、1on1の場を使って個別にフィードバックをもらうようにしています。
「最近チームでうまくいっていると思うことは何ですか？それはなぜですか？」「もっとうまく進められそうなものは何ですか？それはなぜですか？」のような質問を投げかけて、チームに対する意見や改善ポイントのヒントを引き出しています。
また、私自身に対するフィードバックも1on1を通じて積極的にもらうようにしています。「僕の動き方でやりにくいところはないですか？」「もっとこうしてほしいということはある？」と聞くと、最初こそ苦笑されて話しにくい雰囲気になってしまいますが（！）「自分自身の認識だとXXはうまくいってる方かと思うのですが、YYはまだ全然できてないと思うんですよね」のように自己評価を伝えると、率直なフィードバックをもらえることがわかってきました。
もらったフィードバックについても、できるだけすぐにアクションを取っていくと、「この1on1の時間は意味があるのかもしれない」と少しづつ感じてもらえているのではないか、、と期待しています。
おわりに
こうした工夫を積み重ねて4ヶ月経ちましたが、だいぶチームでの開発も回ってきた実感があります。メンバーとの信頼関係も少しずつ築けてきて、リードとしての役割も自然に果たせるようになってきました。
転職して新しいチームのリードを任される状況は、なかなかプレッシャーがかかるものです。ただ、まずは基本に忠実に、チームの一員として信頼を積み重ねていくことが大事なのかなと思います。
最初から全部うまくやろうとしない、苦手なことは頼る、わからないことは聞く。その上で、自分がチームに貢献できることに集中する。そのようなことを積み重ねることで、少しずつチームに馴染み、自然とリードとしての役割も果たせるようになるんじゃないかなと考えています。
私のチームは、まだリリースされていない新しいプロダクトを2つ開発中です。ここまでチームが回ってきたのはチームメンバーのおかげですし、早くユーザーであるクリエイターの方々に価値を届けられるよう、チーム一丸となってスピード感をもった開発を進めていきたいです！
さて、明日は私と洋服の好みがかなり近い @miraoto さんの記事です。お楽しみに！
Discussion