⛴️

新しいチームに参加したら最初にやること

2025/01/28に公開

はじめに

こんにちは、koyablueです。

今まで転職したり社内で異動があったりで、既存のチームに途中参加することを何度か経験しています。そのたびに「最初にあれをやっておくべきだったな」と思って後悔することを繰り返してきた結果、新しいチームに参加したら最初にやることの知見が溜まってきたので、記事にまとめます。

この記事の内容は私がこれまで個人的に少しずつ学んできたものですが、決して特殊なものではなく、割と普遍的に役立つtipsだと思っています。なので、新しいチームに参加するときのTODOリストのように使っていただけたら嬉しいです。

よければぜひ参考にしてみてください。

情報収集と整理

オンボーディングの仕組みがバッチリ整っているチームは稀です。新しくチームに参加した直後は必要な情報を自分で集めるようにします。

  • これから開発に携わるシステムはどのようなものか(システムの目的
  • どのような開発フロー

を確認します。

システムの目的を理解する

ざっくり言うと「これから開発するシステムのことを理解する」という当たり前の話なのですが、もう少し具体的に説明します。

自分がこれから開発に携わるシステムが「何を実現するためのものなのか(何を解決するのが目的か)」を理解することが重要です。
Webサービス、社内ツール、その他どんなシステムであっても、基本的に「ある問題を技術で解決するための仕組み」として存在しています。そのため、新機能の実装、既存機能の改修、リファクタリング、別技術へのリプレイス...など、どんな作業であっても程度の差はあれ常にそのシステムの目的が中心に据えられています。
コード内の個々の実装も、もともとはメインの問題を解決するために、より小さな問題に分解された結果として生じたものです。したがって、たとえ些細な実装に携わる場合であっても、周辺のコードや仕組みを理解するだけでなくシステム全体の目的をしっかり理解していることが欠かせません。

具体的な方法としては以下のような手段があります。

ドキュメントを確認する

言われなくても...という感じではありますが、システムの概要がまとまっているドキュメントがあれば、まずは目を通しておきます。
社内向けや開発者向けではなく、ユーザー向けの資料のほうが平易な言葉でわかりやすく書かれている場合もあるので、まずはそちらを確認するのもおすすめです。

チームメンバーに解説を依頼する

自分一人でただ資料に目を通すだけでは理解しづらい場合があります。あるいはドキュメントが整備されていない場合もあります(だいたい情報が古かったり抜けていたりします)。
そういった場合は可能であればチームメンバーに解説してもらったり、質疑応答の時間を取ってもらうのも一つの方法です。
忙しい中手を煩わせたくないと思って遠慮してしまいがちですが、思い切ってお願いしてみてもいいと思います。

ドメイン知識を身に付ける

システムの目的に深く関わる特定の業界や業務、専門分野に関する知識を身に付けることは、開発に携わる上で非常に重要です。
ドメイン知識が不足していると、なぜその機能が必要なのか、なぜそのような処理が実装されているのか、また、どうしてそのような仕様になっているのかを理解することが難しくなります。的外れな実装をしてしまう原因にもなりかねません。
なのでドメイン知識が不足している場合、手を動かす前にできる範囲でキャッチアップしておきます。

ただ、ドメイン知識は開発に携わる過程で徐々に身に付くものでもあります。そのため、最初から多くの知識を習得したり、細部まで深く理解したりする必要はないと考えています。
まずは基本的な知識の習得から始め、実際の開発業務を通して理解を深めていけば十分だと思います。

システムの目的の理解が浅いためにリファクタリングに失敗する例

(普通は発生しないような、ちょっと極端な例ですが...)
 
あるレストランの予約システムでは予約が確定するまでに以下のようなプロセスがあります

  • 予約確定は、顧客が予約をリクエストした後、店舗側が承認した時点で成立する
    • 予約可能な条件であれば自動的に承認される
  • 高需要時間帯(ディナータイムや週末)は自動承認ではなく店舗スタッフの手動確認が必要
    • 空席があっても店の状況によっては予約を受けられる余裕がないかもしれないので、スタッフが確認したい
  • 予約確定の通知は顧客に即時送信される必要がある

この仕様を満たすコードは以下の通り、予約リクエストと予約確定を分けて実装されています

function requestReservation(customerId: string, timeSlot: string, seats: number, date: string) {
    const availableSeats = getAvailableSeats(timeSlot, date);
    if (availableSeats < seats) {
        throw new Error("Not enough seats available.");
    }

    // 予約リクエストを保存(未確定)
    saveReservationRequest(customerId, timeSlot, seats, date);

    // 店舗スタッフへの確認通知を送信
    notifyStaffForApproval(customerId, timeSlot, seats, date);
}

function confirmReservation(requestId: string) {
    // 予約リクエストを取得
    const reservation = getReservationRequest(requestId);
    if (!reservation) {
        throw new Error("Reservation request not found.");
    }

    // 予約を確定
    saveConfirmedReservation(reservation);

    // 顧客に確定通知を送信
    notifyCustomerConfirmation(reservation.customerId);
}

このチームに新しいエンジニアAが加わり、こう考えました。
 
「飲食店の予約業務って、普通は客が予約を入れたら記録して客に通知を送るだけでしょ。追加で今回はスタッフにも通知送るってわけか。え、だったらなんでこんな冗長な書き方してんの(笑)。まとめて書くべきだよね。普通に考えて」
 
そして以下のようにリファクタリングしました。

function createReservation(customerId: string, timeSlot: string, seats: number, date: string) {
    // 席の空き状況を確認
    const availableSeats = getAvailableSeats(timeSlot, date);
    if (availableSeats < seats) {
        throw new Error("Not enough seats available.");
    }

    // 予約を確定し、通知を送る
    makeReservation({ customerId, timeSlot, seats, date });
}

リファクタリングの結果:
この変更により以下の問題が発生しました:

  • 高需要時間帯の承認プロセスが失われた
    • スタッフが手動で確認する仕組みがなくなり、ディナータイムなどで重複予約が発生
  • 顧客に誤解を与える即時通知
    • 承認されていない予約にもかかわらず、通知が送信され、「予約が確定した」と誤解されてしまう
      という欠陥が生じてしまいました。

結末:
結果として、レストランでは以下のような混乱が生じました:

  • ディナータイムの重複予約により店内は大混乱
  • スタッフが対応に追われ顧客対応の質が低下
  • 混乱の様子を見た顧客が動画付きでソーシャルメディアに投稿し、内容が大きく拡散される
  • Googleマップには星1のレビューが連投され、店舗の評判が急落

最悪です。
 
なぜ的はずれなリファクタリングが行われたのか:
直接的な原因は「既存コードの理解が浅かった」ことに見えます。
しかし、根本的な原因は 「どんな問題を解決するためのシステム/実装なのか」を十分に理解していなかったことにあります。
 
まず、このシステムの目的は単なる「予約の自動化」ではありません。
「予約をシステムで管理したいが、忙しい時間帯は店の状況を考慮して予約を受けるかどうかを決めたいため、スタッフが手動で確認できる仕組みが必要」という課題を解決することが目的です。
 
しかし新しいエンジニアAは、このシステムを単純に「レストランの予約システム」として認識していました。
つまり「(利用者目線からの)日常生活で触れる飲食店の予約業務」をモデルに「飲食店の予約業務はこんな感じだろう」という思い込みに基づいて判断してしまいました。
飲食店の予約という身近なテーマゆえに、実際の現場で予約業務を運用する場合の課題について理解が浅いまま、業務について十分理解していると錯覚した結果、このような事態を招きました。

開発フローを理解する

プロジェクトやチームごとに異なる部分も多いですが、以下の項目は最低限押さえておきます。

タスク管理方法を把握する

タスクがどのツール(例: Jira, Trello, GitHub Projects など)で管理され、どのように割り振られているのかを確認します。チケットのステータスやラベルなどの細かい運用ルールも一通り見ておきます。

開発の一通りの流れを理解する

実装に着手してからどのようなプロセスで最終的にリリース用ブランチにマージされてデプロイされるのか、おおまかな流れを把握します。

過去のプルリクエストを確認する

過去のプルリクエストやコードレビューのコメントを読むことで、チームの開発スタイルやレビュープロセスをより具体的にイメージすることができます。
過去に行われた議論にさらっと目を通しておきます。

Gitの運用ルールを確認する

ブランチの命名規則や運用方法、プルリクエストの作成方法(テンプレはあるのか、レビュアーに誰を指定するのか、ラベルやマイルストーンは設定するのかetc)などを確認します。

コーディングルールを確認する

スタイルガイドや設計方針を確認します。
最初から全てのルールを頭に入れる必要はなく、実際にコーディングする際に既存のコードやスタイルガイドを参照しながら、徐々にルールに慣れて把握していければ問題ありません。

デプロイ方法を確認する

CI/CDの設定、手動デプロイであればその手順、デプロイ権限などについて確認します。Slackやその他ツールで通知やフローが組まれている場合もありますので、それらもチェックしておきます。

チームの開発フローを正しく把握していなかったために起こるミスの例

(またちょっと極端な例ですが...)
 
あるWebサービスのフロントエンドチームでは現在、積極的にテストを拡充中です。
今のところCIにユニットテストとE2Eテストが組み込まれています。いずれのテストもモックAPIを使用しており、毎回決まったレスポンスを返す仕組みになっています。
パフォーマンステストをCI/CDフローに追加する案も出ていますが、現状では工数が取れない状態でした。
そのため、暫定的に以下の運用が採用されています:

  • リリース前に開発者がプレビュー用環境で最低限のパフォーマンスチェックを手動で行い、基準を満たしていることを確認する
    補足: (CI/CDプロセスにはプレビュー用環境へのデプロイが含まれており、CIが通過した後に開発者が直接プレビュー環境にアクセスしてチェックを行います。また、プレビュー用環境ではモックAPIではなく実際にバックエンドにリクエストを飛ばします)

しかし、この手動パフォーマンステストのプロセスについては、まだ開発フローのドキュメントに追記されていませんでした。
 
 ・
 
トラブルの発生:
別チームから異動してきたばかりのエンジニアAは、開発フローのドキュメントを一通り読んでいる状態でしたが、手動でのパフォーマンステストの存在についてはまだ把握していませんでした。
 
ある日、Aは特定のページの検索機能に対する小さな改修タスクを任されました。
作業ブランチにコードをpushすると、いつものようにCIが実行され、ユニットテストとE2Eテストは問題なくすべて通過しました。
 
Aは「CIが通ったから問題ないだろう」と判断し、プレビュー環境での手動チェックを行わず、そのまま作業ブランチをリリースブランチにマージしました。
CI/CDの設定により、リリースブランチの内容は自動で本番環境へデプロイされました。
 
 ・
 
問題の発覚:

リリース後、複数のユーザーから「検索結果が表示されない」「ページがずっとロード中のままになる」という問い合わせが寄せられました。
調査を進めたところ、検索APIのリクエストがタイムアウトしていたことが原因であると判明しました。
Aの改修作業によって予期せず大量の検索条件が過剰に追加されており、その結果バックエンドでの検索処理が非効率化し、レスポンスを返すまでに想定以上の時間を要する状態になっていました。


このトラブルは、Aが事前にチームの開発フローを正しく理解していれば防げたトラブルです。
CIに組み込まれているユニットテストとE2EテストではモックAPIが使用されており、毎回決まったレスポンスを返します。なので、今回のようなパフォーマンスの悪化に気付くことができませんでした。
開発フローを正しく把握し、リリース前にプレビュー用環境で確認をしていれば、事前に気付くことができたはずです。

実践的なキャッチアップ

実際に手元の環境にコードがある状態でキャッチアップを行います。

知識が足りない技術スタックの確認

使用されている言語、フレームワーク、ライブラリ、設計方法などの中で知識が足りていないものがあればキャッチアップしておきます。公式ドキュメントを読む、チュートリアルを試す、などのよくある方法と併せて、既存コードでの実際の使われ方を確認します。

システムの主要なフローを試す

実際に動作確認してシステムの理解を深めます。ただ、全ての機能を動かすと時間がかかってしまったり、規模によってはかえって理解が困難になったりします。
なので一旦は主要な機能のみを一通り動作確認します。そうすることにより、全ての機能を動かすことなく効率的にシステムを理解でき、ユーザー視点での動作も把握できます。

コードリーディング

実装するときは既存のコードに馴染むように書いていくことになりますので、実装タスクが割り振られる前に必ず既存の実装を確認します。
このとき、まずは直近で関わるであろう機能やモジュールに絞って、関連部分を重点的に読んでいきます。
設計方法や頻出の実装方法を確認するのはもちろん、コメント、テストの書き方や方針も同時に確認しておきます。
既存の実装方法に違和感を覚えた場合はなるべく質問し、実装に入る前にできるだけモヤモヤを解消しておきます。
違和感を覚えた部分について質問することで、仕様や実装への理解が深まったり、自分の勘違いを事前に気付ける場合があります。また、新しいメンバーからの質問によって既存メンバーが今の実装の問題点に気付けることもあります。

その他

常にメモを取りながら作業する

ここまでにあげた全ての作業は、メモを取りながら進めることをおすすめします。
自分が疑問に思った部分、つまずいた部分、理解に時間がかかった部分などは、ドキュメントが足りていなかったり、チーム内での暗黙知や明文化されていない慣習であったりする場合が多々あります。
後で同じ部分でつまずかないようにメモを取っておきます。

また、自分にとって障害になった部分は、他の新しいメンバーに対しても同じく障害になることがあります。可能であればメモを元にドキュメントを更新しておくと喜ばれるかもしれません。

質問を恐れない

これは新しく参加した時に限らない話ですが、疑問に思ったことは素直に質問した方がいいです。
とくに、新しく参加した直後はいろいろ質問しやすい状態なので、そのアドバンテージをできるだけ活用します。

共有を恐れない

自分の取り組みや考え、状態、反応などを共有することは大切です。
加入直後、チームメンバーは誰も自分のことを知らない状態なので、できるだけ自分を可視化するよう努めます。
進捗報告、プルリクエストの説明やコメント、スタンドアップでの現状共有など、業務の一環としてのいわゆる報連相が大切なのは言わずもがなですが、それに加えて以下のような小さなアクションも効果的です:

  • timesチャンネルがあれば、何でもいいので投稿してみる
  • やりとりはDMではなく、できるだけオープンなチャンネルで行う
  • SlackでDMやメンション以外のメッセージに対してもスタンプで反応する
  • 雑感や所感を書ける場(日報など)があれば積極的に活用する(「特になし」で済ませない)

特に、フルリモートやハイブリッド勤務ではテキストベースのコミュニケーションが主流になることが多いため、何もしないとチーム内で自分の存在が透明になりがちです。このような可視化アクションを行うことでチームとの距離感が縮まったり、働きやすさが向上したりするメリットがあります。

ただ、このあたりは個々の性格や働き方によっても変わってくる部分だと思いますので、無理にやる必要はないと考えています。
自分の性格やスタイルに合わせつつ、できる範囲でやっていくのがいいと思います。

慣れたやり方を押し通さない

会社やチームにはそれぞれ異なる仕事の進め方があります。言語やフレームワーク、ツール、開発対象などによってある程度決まった共通の作法はあると思いますが、基本的には一旦チームのやり方を受け入れてゼロから学ぶようにすべきです(最初から改善要員として参加している場合は例外かもしれません)。
チームのやり方に対して違和感を覚えたり、別の方法を取り入れたいと考えることもあると思います。その場合は後で改善を提案しましょう。
既存のやり方やその背景を知らないまま自分の考えを押し通すことは、避けた方が賢明です。

「とりあえず質問」できる人、場所を確認しておく

チームに参加した直後は小さな疑問や質問が頻繁に出てくるものです。しかし関係者の把握が不十分な状態では、誰に質問すればよいのか分からず迷ってしまうこともあります。
技術的なことでも、それ以外のことでも、 「とりあえずこの人に聞けばいい」 または 「このSlackチャンネルに書き込めば解決しそう」 といった人や場所をあらかじめ確認しておくと安心です。

おわりに

正直なところ、この記事に書いた内容を私自身が毎回完璧に実践できているわけではありません。キャッチアップすることが多く、つい疎かになってしまう場合もあります。また、この記事で紹介した方法が唯一の正解とも思っていません。状況によって適した方法は異なりますし、私自身も毎回試行錯誤しながら取り組んでいます。

もし「自分はこうしている」「こんな方法も役立つよ」など、皆さんの経験や考えがあれば、ぜひコメントで教えてください!

最後まで読んでいただき、ありがとうございました🙌

SocialPLUS Tech Blog

Discussion