この記事は、Merpay Advent Calendar 2021 の17日目の記事です。 こんにちは。メルペイ Payment Platform所属の rossy です。
はじめに
この記事を読んでる方は転職で新しい環境に飛び込んだり、社内の別チームに異動する経験があったりするのでしょうか。僕は職歴こそまだ2年未満ですが、メルカリで社内異動を4回経験しました。
2020年4月にバックエンドエンジニアとしてメルカリに新卒入社してから約2年間、次のようなチーム遍歴を経験しました。
2020年04 – 06月 Payment Core team（決済基盤）
2020年07 – 09月 Credit Design team（与信基盤）
2020年10 – 12月 Payment Core team（決済基盤）
2021年01 – 03月 Balance team（残高管理基盤）
2021年04 – 09月 Settlement team（精算基盤）
2021年10 – 現在 Settlement team（精算基盤, テックリード）
※それぞれのチームに人員不足などの緊急な状況の中で、助っ人（消防隊員）としてAll for Oneに異動した形でした。人気者はつらいですね。
それぞれのチームで扱う業務は大きく違っており、3ヶ月ごとにはじまりの村からスタートするような日々でした。異動を繰り返した中で、チームメイトの予想を越えた速さでキャッチアップし、チームに貢献してる と嬉しい評価を頂くことも増えていきました。初心者から中級者へのスタートダッシュを繰り返した中で、キャッチアップ力が磨かれた結果と思ってます。その中で、自分がやったこと、感じたことを極意としてご紹介します。
極意とは書きましたが、要は習慣と心持ちです。ここからは次のテーマに絞り、新しいチームでパフォーマンスを出すのに必要な取り込みを詳しく説明します。
- ドメイン知識の習得
- アウトプットの出し方
- ドキュメンテーション
- コミュニケーション
ドメイン知識の理解
メルペイではほぼすべてのバックエンドチームはGo、GCP、マイクロサービスなど同じ技術スタックで開発しています。チームが変わっても技術の勉強はその延長線上でやることができて、苦労することはありませんでした。これは最初に技術選定した方やインフラを作っているプラットフォームの方に感謝しかないです。共通化された技術スタックであれば、よりドメイン知識の勉強に集中できます。
システムの開発をする際に、ドメイン知識は非常に大事です。システムはあくまでも現実社会で実現したいことの実装です。なぜその処理が必要なのかはドメインから学ぶ必要があります。システムをより理解するためにはドメイン知識は不可欠です。メルペイではマイロクサービスアーキテクチャーを採用しています。それぞれのチームが自分たちのドメインのマイクロサービスを開発しているため、チームによって必要なドメイン知識は変わります。
では、ドメイン知識をどのように自分の知識にするとよいのでしょうか。僕は次のような手順で取り組んでいます。
(1) チームのドキュメントを読み、自分の言葉に直してメモを取ります。
(2) チームのドキュメントだけでなく、キーワードをもとに、他社の事例を調べ、同じくメモを取ります。以下は、精算チームに異動した際に実際に作成したメモの一部です。
図: 精算チームに所属する際に実際に取ったメモ
余談ですが、エンジニアリングを勉強するにあたって、できれば英語や中国語のような、書き手の母数が大きい言語を勉強しておいた方が得だと感じました。たとえば、精算のドメインは中国では明確に精算と結算に分かれていて、ある程度体系化されており、いろんな記事が公開されています。
図: 中国語の記事を読んだ時のメモ
アウトプットの出し方
既存コードの理解
異動後はすでに運用されているシステムの開発に携わることが多いので、最初はコードを書くよりも読むことの方がはるかに多いです。
それぞれのチームにはオンボーディングドキュメントがありますが、ドキュメントを読んだだけですべてを理解できるわけではありません。最初は手を止めないようにすることです。手を動かせるなら、すぐにレビューを依頼してフィードバックをもらいます。もし手が止まってしまったなら、社内のドキュメントをあさり、それでも解決しないのであれば、素早くチームメイトに相談するようにしています。この際に、後続の人もすぐに手を動かせるようにドキュメントを残すことも大切です。これに関しては後述のドキュメンテーションのセクションで詳しく紹介します。
手を動かすに当って、コードやドキュメントなど目で見える形に落として共有するように心掛けています。新しいメンバーは完璧にできないことが当たり前なので、最初から完璧を目指さずに、自分の中で大体のレベルまで落とし込んだところでレビューを依頼するようにしています。大きな方向転換を避けるために、早い段階でレビューを依頼して、簡単に修正できるようにしてます。簡単な変更タスクはドメイン知識の吸収と並行して行うようにしています。
図: PRの中で自信のないところは自分からコメントをいれて確認するようにしてもらう
システム設計
設計ではドメインと既存の実装を自分なりに解釈することが求められます。大袈裟に言うとコード一行一行までに対してそうした理由付けをする必要があります。
新しい設計に取り込む前に、自分でシステムや機能の理想像を考えます。自分の理想像を材料として、チームメイトと将来的な開発について議論します。議論の中で、理想像の方がいいとなれば、将来的なリファクタリングの仕事になります。理想像に不備があり、既存の方がいいとなれば、学びになります。
図: 再設計することによって洗い出されたタスクの一部例
他によくやっていることは同業他社事例のリサーチです。システム内部の詳細こそ公開されていませんが、提供機能や公開APIなどの使い方から仕組みを推定しながら自分達のシステムに取り入れられるかどうかを考えることができます。
図: 他社のドキュメントを読んだ時のメモ
上記の設計タスクに取り組むにあたって、特に気をつけていることがあります。システム設計には妥当な選択肢が複数存在します。見える選択肢をできるだけ増やして、その中からその時の最適なものを選ぶ方法をとってます。ただし、未来は完璧に予測はできないので、最終的には「未来はどう変化するかは予測できないから、最善かどうかはわからない、でも最悪のケースは避けようぜ」という気持ちで仕事をしています。
異動に伴う違和感の解消法
大体、既存の仕組みにはそうなっている理由があります。しかし、新しいメンバーの経験によっては既存実装が歪に見えていたり、妥当に見えていたりします。違和感を感じた時、早い段階でチームに相談することが大事です。
例えば、僕は異動によっていろんな社内チームの業務プロセスを経験しているため、異動先の業務プロセスに慣れた頃には、自分の経験と見比べて改善点を探せます。改善できそうなポイントが見つかった際に、経験ベースで説明して共感を得ながら、業務プロセスの変更を提案します。既存のプロセスに敬意を払い、チームメンバーでチームをよりよいものにしていく気持ちが大事です。
図: どうしても大きくなってしまったPRのレビューに対する提案
ドキュメンテーション
自分が経験したチームでは、システムの仕様、開発のやり方や運用に関するドキュメントが管理されています。ドキュメントは常にメンテナンスしておく必要があります。しかし、どこにでもある課題ですが、新しい人が入った際には最新版ではないことも多々あります。また、多くのドキュメントはその時その時必要だと感じた人が更新するため、必ずしも新しいメンバーに向けて書いてるものだと限りません。とくにハイコンテキストのものだとチームに入った直後の知識で理解することは難しいです。僕はいろんなチームを異動してきた中で、チームのフェーズや状態によってオンボーディング資料が整備されているチームもそうでないチームもありました。それぞれの場合の仕事の仕方を紹介します。
チーム内にすでにオンボーディングドキュメントがある場合
僕の最初の仕事はそのドキュメントのレビュー及び検証であり、オンボーディング期間が終われば、ドキュメントをよりよくすることも自分の仕事です。ドメイン知識を勉強する際と同じく読んだ資料のメモを残すようにしてます。読んでもすぐには理解できないものは期間をおいてまた読むようにしてます。
図: 古くなったドキュメントを更新した際のPR
オンボーディングドキュメントがない場合
僕の最初の仕事はドキュメントを用意することです。ドキュメントを作る気持ちでオンボーディングを受け、オンボーディング期間中に行ったことを記録しただけでもドキュメントになります。次の人のレベルを想定しながらドキュメントを作ることは難しいですが、自分が経験してきたものをまとめるだけならそこまでコストがかからない上、次の人にとっては同じような状況を経験した資料があるのは望ましいので、非常にオススメです。また、良質なドキュメントが大量にあるとしても、新しいメンバーはわからないことがわからないため、目的のドキュメントにたどり着くこと自体が難しいです。自分の経験では、良質なドキュメントをある程度まとめた資料をメンテナンスしておくと、新しいメンバー側も非常に楽に知識をあさることができます。また、こういった資料はチームにとってもよい関連資料のインディックスになるので、新しいメンバーのみならず、活用幅が非常に大きいです。
図: オンボーディング期間が終了した際に追加したオンボーディングドキュメントの一部
また、新しいメンバーはそもそも何をすればいいのかわからないため、現在ではチェックリストのようなドキュメントに進化してます。（新しい人が参入する前後で更新するようにしてます）
図: 最新版のオンボーディングドキュメント
コミュニケーション
新しいチームに所属してから最初は、日常会話の次に多いコミュニケーションは不明点の質問です。親睦を深めるための日常会話なども大事ですが、質問の仕方に気をつけています。
まずは質問することを恐れないことです。当たり前なことを質問して、相手に嫌な思いをさせてないか心配する気持ちはわかります。しかし、大体のチームでは時間が経つにつれて、相手は理解してるだろう前提で話が進むことが多く、繊細なことに対して確認し合うことが減ります。些細なことで認識違いすることも多々あります。そういった質問を誰でもしあえるように、質問のハードルを下げることも初心者の特権なので、存分に利用するべきです。新しいメンバーを迎え入れる側になった今では、質問は盛大に感謝されるべきだと認識してます。
そして、人から情報をもらうために、先に持っている情報をできる限り提供することが大切です。人に教える側の立場から考えると、質問した人が今どこまで理解しているのかを知れば、何から話を始めるべきか考えやすいです。そういった共通意識を作るために、人に教えてもらう時はできるだけの情報を提供して、教えてもらう人に自分の状況を理解をしてもらった方がコミュニケーションはスムーズです。
ここで散々取ってきたメモが大活躍します。他人に自分の脳内を覗いてもらうのは難しいのですが、自分がまとめた言葉ならレビューができますし、理解度のチェックもできます。当然レビューをしてもらう場合、読み手に対する配慮も必要なので、メモを人が読める形に直してレビューを依頼します。すでにメモとしてある程度言語化されているなら、あとは人が読める形に整形すればいいので、比較的に楽です。また、自分の理解を開示しながらフィードバックをもらうことで、共通意識を作ることにも繋がります。
例えば、チーム内の優先事項は新しいメンバーにとって判断しにくいものです。以下のように自分が思っていることを提示しながら、質問すれば良いと思います。
例: 自分はこう思っているけど、実際どうですか？的な質問をする。
図: レビューを依頼した時のメッセージ
チームの状況によって、レビューするコストを払えない時もあります。その場合はこのやり方だと難しいです。ただ、情報を開示するポーズを取ること自体も大切なので、情報を受け取る側がどう対応してくれるかは別として、やれることはとりあえずやろうという心持ちです。
異動を繰り返した経験について
最後に、短期間でチーム異動を繰り返す人は少ないので、その経験について少し言及します。
結果論ですが、この記事に書いたような内容もこの経験なしでは言語化出来なかったはずです。実際異動を繰り返すことによって、多くのドメインエキスパートと関わりながら開発できたので、経験の浅いエンジニアでありながらも幅広くドメイン知識を学べました。今ではドメイン知識の幅が自分の武器になっています。
しかし、今のチームで半年以上所属したことによって、1つのドメインに多くの時間をかけなければわからなかった、深い知識も身についています。また、開発してから長く運用することにあたって気にしないといけない設計などの知識も蓄積するようになり、同じチームに居続けていたら違う景色も見えるものなのだなと痛感しています。1つのドメインを深く知るには自然と周辺のドメインの知識も学ぶようになるので、ドメイン知識の幅をただ広げるために異動を繰り返すのはベストプラクティスではないと思っています。
初心者になることも別の意味で体力やメンタルを消耗するので、好んで選ぶことはオススメできません。しかし避けねばならないほどの悪い道でもないので、もしそんな状況に置かれていたら、前に進むことだけ考えればいいと思います。
異動先のチームメイトから「技術だけでなくチーム運営などに関しても積極的に改善の提案をしていて、どんな環境でもAll for Oneにチームを前進させていくことができると思います」といった評価も頂けたので、辛いことも多かったですが、いいこともたくさんありました。
終わりに
スゴ技のような内容を期待していた方は、もしがっかりさせてしまったらすみません。やっていることを自分なりにまとめると、知識を自分のものにしながら、テキストベースでチームメイトと共有していくことの繰り返しです。実践するためにチームメイトのサポートも必要なので、今までのチームメイトに感謝の気持ちしかないです。
- 資料をあさる
- 言語化してメモを取る
- メモをまとめてチームメイトに共有する
- フィードバックをもらいながら知識を補完する
- 蓄積した知識でアウトプットを出す
-
- からまた繰り返す
また、大事だと思った心持ちもいくつか残しておきます。
- 人に頼ること
- 人に頼られるようになること
- 下準備をできるだけしておくこと
- 例えば、資料を読むこと、作ること
物事がうまく出来ない時、それはやり方が悪い場合が多いと感じています。自分(や他人)を責めずに、やり方を変えるようにしています。自分に合うやり方をいかにして探すかに注力し、様々な対応テンプレートを作っています。同じことがあったら、過去にうまくいったやり方で進むようにしています（うまくいかない時は改善するようにします）。今回の記事は新しいチームに異動する際のテンプレートを公開出来る形に文章化したものです。その他にコードレビューのテンプレート、チームリードとしてのテンプレートなどいろんなものをテキストにして管理してます。この習慣もオススメなので、よかったら試してみてください。
それでは、ここまで読んで本当に頂きありがとうございました。
明日は ML team @hiroさんの記事です。お楽しみに！
（宣伝）自分が所属する精算チームはやるべきこと、やりたいことが無限にあります。バックエンドエンジニアのポジションとしてオープンしてるので、もし興味ありましたらカジュアル面談、応募をお願いします。皆さんの応募をお待ちしています！
少しでもご興味があれば、下記のリンクからぜひご覧ください。
