こんにちは！スマートキャンプでWebアプリケーションエンジニアとして働いている中川です。
さて、唐突ですがみなさんは別の開発チームに異動した経験はありますか？
いくつかプロダクトを抱えていたり受託開発をしている会社では割とよくある現象なので、少なくない数の方が経験されたことがあるかなと思います。
と、この書き出しで察しの良い方はお気づきかと思いますが、かくいう自分もこの度チームを異動して、6月からBOXIL開発チームで働いています。
今回の記事では、自分が新しいチームに参加することになったときにどういうキャッチアップを行っているかについてご紹介していこうと思います！
また、今回の記事で前提としているのは異動のシーンですが、転職でも通ずるような内容は多いと思っています。
キャッチアップする目的を考える
まずはキャッチアップしていった末にどういう状態になるとよいのか、その目的について整理します。
今回は以下に挙げたことがこなせるようになることと定めました。
- 複雑な設計が必要ない機能を設計・実装できるようになること
- 実装からリリースのフローが理解できており、実践できること
- プロダクトのドメインと提供している機能群のなかでもコアなものは把握できていること
- 開発チームと滞りなくコミュニケーションができること
究極的にはどんな機能でも設計出来るようになりたいですし、ソースコードの細部まで認識している状態になれれば理想なのですが、
あくまでもキャッチアップとしては上記のようないわゆる「一人前として立ち上がっている」状態を目的とし、
だいたい3ヶ月程度を目安として実行することにしました。
なにをキャッチアップしていくか考える
さて、前項でキャッチアップによってどうなりたいかについては考えたので、ここでは何をキャッチアップするかについて詰めていきます。
前項の箇条書きを抽象化して整理すると、ここには大まかに2つの軸が存在していることがわかります。
軸の1つは当然ですが技術的な要素である「プロダクト」、もう1つは見逃されがちですが日々のコミュニケーション面として「チーム」の2つです。
というところで、「プロダクト」と「チーム」についてキャッチアップ、つまり「慣れる」ためにそれぞれの要素を出していったものが以下の箇条書きになります。
- プロダクトに慣れる
- ビジネスモデルを知る
- 使われている技術を知る
- ソースコードを知る
- データとその構造を知る
- アーキテクチャを知る
- チームに慣れる
- コミュニケーションスタイルに慣れる
- チームのイベントごとを把握する
- カルチャーに慣れる
- 自分の立ち位置・求められている役割を把握する
それぞれの要素の下にもさらに子要素・孫要素が連なっていくとは思いますが、方針としてある程度網羅性のあるものにはなっていそうなのでこの各要素を実施していくことにしました。
ここからは、異動から2ヶ月弱経過した現在時点までに実際に各要素の打ち手として何を実行してきたかについて書いていこうと思います！
プロダクトに慣れる
ビジネスモデルを知る
まずはそのプロダクトがどのようにしてマネタイズしているのか、そのビジネスモデルを理解しにいきます。
プロダクトを成り立たせている収益構造・参入障壁などについて、開発チームメンバーや関係する人々に教えを乞います。
これは世界観を身につけるようなもので、プロダクトに登場する人物の種類（ユーザー・アドミン等）や、何が大事とされているのか・その逆はなにか、といったプロダクトがまとう一種の雰囲気をつかみにいくようなイメージです。
また、ここで出てくる収益構造のキーとなる単語（商品・プラン・ユーザー・リード等など）は後々 「データとその構造に慣れる」の章でデータの関係性を理解するうえでも役立ってきます。
使われている技術を知る
プロダクトで使われている技術要素を俯瞰します。
ここで見るポイントとしては、使われている言語やフレームワークで自身の経験がないものを炙り出すだけでなく、それが一体どれほど使われているのか・どれほどの頻度で修正が起こり得るかにも注目することです。
つまり、そのプロダクトにおいてメインとなる言語・FWであればキャッチアップの必要性は高いですが、その逆であれば優先度は下げられると考えています。
当然セキュリティ上クリティカルな部分であったりビジネスのコアロジックが書かれている場合は一読する必要があるとは思いますが、そういったロジックは概して修正頻度も低いので、一読できるレベルにまでキャッチアップできればあとは他要素のキャッチアップを優先しています。
今回の異動においてはRailsのフロントエンド部分（slim, CoffeeScript, gon, ahoyなど）が未経験だったため、そちらのキャッチアップを行いました。
また、現在プロダクトではこういったslim + CoffeeScriptの部分をVue.jsに置き換えていく動きが進行しているタイミングということに便乗して、そちらのタスクを通じてシンタックスや挙動の理解を捗らせることが出来ました。
（移行の経緯や概要については以下の記事をご覧ください）
https://tech.smartcamp.co.jp/entry/frontend-improvement
ソースコードを知る
普段の開発で関わることになるソースコードについてキャッチアップしていきます。
ここでキャッチアップの手段や手順といった概要に関するお話は以下の記事に詳しく、素晴らしい内容ですのでそちらに譲りたいと思います。（ありがとうございます！）
ソースコードを読むための技術(チートシート) - Qiita
余談ですが、上記の記事のなかでもソースコードの処理の流れをメモしていくことがキャッチアップにおいて有用であることが説明されていますが、今回のキャッチアップにおいては、それを効率化する以下のVSCodeプラグインが非常に活躍しました。
VSCodeのエディタ上でソースコードの行単位でメモを簡単に取ることができるプラグインなのですが、「コードを読む」＆「メモを取る」という2つの作業がシームレスに行えて体験が良かったので、コードリーディングのお供としてオススメです！
データとその構造を知る
ここではアプリケーションが持つデータとその構造をキャッチアップします。
具体的に表すと、データベースのスキーマと、そのなかの実際のレコードを見ていきます。
といっても、GUIで闇雲にaからzまで順番にテーブルを見たとしても要点を理解することは難しいです。
そのため、ここではER図を生成することでその整理を通して重要なモデルやその関連を学びます。
Railsアプリケーションにおいては、rails-erdというER図を生成するためのgemが存在しているので、こちらを使用します。
GitHub - voormedia/rails-erd: Generate Entity-Relationship Diagrams for Rails applications
すでに運用されているアプリケーションで生成した図を見てみると、いくつものモデルから関連されているモデルや、逆にどこからも関連されていないようなモデルがおそらく発見出来るかと思います。
図をただ眺めるというと、実のない行為に思えてしまいますが、ここで得られる発見は実際にその後の設計や実装において精度の高いものを作るために確実に寄与してくるため、図の大小にもよりますが私の場合は1時間程度は時間をかけて、眺めたり気になるところは実際のレコードをSELECTしてきてどういった値が入っているのか確認したりしています。
アーキテクチャを知る
プロダクトのアーキテクチャをキャッチアップします。
いわゆるインフラ的な要素もそうですが、連携やバッチなどのメインとなるアプリケーション外でどういった要素が動いているのかであったり、デプロイにまつわるリソースに関してもここで確認しておきます。
チームに慣れる
コミュニケーションスタイルに慣れる
チームに慣れるために最も不可欠なのがこのチームのコミュニケーションスタイルを把握するという点です。
チームが違えばそのコミュニケーションの形態も千差万別で、社内の別チームであってもまったく異なるという場合も多いかと思います。
かくいう弊社もそのうちのひとつです。
前チームにおいてはチャットやドキュメントを通した非同期的なコミュニケーションをチームとして推奨しており、極力同期的な場を設けずに各々の業務スタイルに一任するやり方でした。
具体的には、日々の朝会や企画のMTG、振り返りなどをZoomで行いつつも、日中は各自で業務にあたり、確認点・不明点が発生したタイミングでSlackでコミュニケーションを図るような動き方です。
これに対して、現チームでは常時接続の同期的なコミュニケーションを良しとしており、それに伴って非同期的なコミュニケーションはあまり取られない（常時接続なのでする必要性に駆られない）ような、真逆のコミュニケーションスタイルです。こちらはDiscordのボイスチャンネルに各自が常駐する形となっています。
こういったスタイルの違いは、チームメンバーの特性やプロダクトのフェーズによるものが大きいのでどちらが良いというものではないのですが、コミュニケーションスタイルに大きな違いがあるという前提を持ち、慣れる必要性があると自認することが大事だと思っています。
今回の異動でもこのコミュニケーションスタイルの違いによっていつものように仕事を進められないことに苦労しましたが、慣れる必要性があると認識をしていたおかげで焦らずに適応していく気概を持つことができました。
チームのイベントごとを把握する
定期・不定期に関わらず、チームにはイベントごとがつきものです。
1on1をしているチームであればその相手や頻度を確認しますし、スクラムをやっているチームであればリファインメントやプランニング、スプリントレビューなどの定常的なイベントのタイミングを確認します。
また、たいていのチームはそのチーム独自の施策を行っていたりするものかなと思います。
現チームでは開発チームで雑談する時間や最近の業務内容を共有する時間が隔週で取られていたりしました。
こういったイベントごとを把握し、体内時計をそのスケジュールにあわせていく動きが必要です。
カルチャーに慣れる
「郷に入っては郷に従え」という言葉にもある通り、共同体（チーム）は「何をよしとするか」の価値観がそれぞれ違うものだと思います。
上述のコミュニケーションスタイルひとつをとっても大きく異なるように、場面場面でチームがどういった選択をしているかを観察し、必要であればその選択に至った理由を深堀りすることで価値観を吸収していきます。
自分の立ち位置・求められている役割を把握する
チームに慣れるという文脈とは少し逸れるのですが、チームにおける自分のポジションを把握することはその後の自分の動き方を考えていくうえで有用なためこのタイミングで確認します。
チームにおける自分の立ち位置というのは周囲との差異によって規定されることが大きいのですぐに把握することは難しいですし、主観なので精度も高くはないのですが、チームの誰が何を得意で、その集まりに対して自分のこのスキルや特性は希少性が高くて活かしやすそうだな、といった具合に考えていきます。
これは一見打算的な考えかもしれませんが、チーム内における自分のバリューを高めることはそのままチームの穴を埋めて全体のパフォーマンスを上げることにもつながるので、必要なステップだという考えです。
まとめ
今回の記事ではチーム異動に際して自分がキャッチアップしていることをご紹介しました。
異動というのは大きな環境の変化で、流されるままにタスクに取り掛かっては右往左往するということも多い（自分もそうでした）かと思いますが、このように何をやるべきか準備しておくだけでも日々の仕事に翻弄される可能性を下げられるのではないかと考えています。
今回の異動では、5年以上運用されている大規模サービスという異動先のプロダクトの特性もあってER図を眺めてデータとその構造を知ることと、メモを書きつつのコードリーディングが特に役立ちました。
最後になりますが、この記事でご紹介した内容以外でもみなさんがオススメするキャッチアップ手法があればぜひSNSなどで教えてください！
それでは！
