ようやく最近はじめてのサービス入ったときとか新しい言語を勉強するときの自分の中のお作法が言語化できた。
これはあくまで自分の場合であり全員には当てはまらない。
頭の中に地図を作る
まずは大きくざっくりと地図を描く。
サービスにジョインして開発をキャッチアップすることを想定して色々と書く。適宜自分の環境に読み替えてほしい。
まずはコードの全体感とサービスの概要や関わる人を知る。
この作業はエンジニアリング２割：雑務８割になる（肌感）
ここでの目的は３つで
1. 社内の関係者に顔と役割を覚えてもらう
2. サービスの使命や使われ方を知る
3. 実際にどんなコードで動くのかをなんとなく把握する
自分がよくやることは以下
1のためにまずは社内の関係者とランチや飲みに行く。特に営業や運用、業務委託など非エンジニアに顔を売ることをする。
誘い文句は「最近入ったばかりで色々とご迷惑かけると思うので前借りでランチおごります」てきな自虐をしつつ誘う。
（特に意味はないが）営業の資料見たいとかこつけて営業に関わりに行き、雑談をする。
2のために実際に自分もインストールしたりユーザー登録する（もちろん許可を取った上で）
また近くに使ってる人がいたらそれとなく聞いてみたりする。
アナリティクスやBIツールにアクセスできるのならなんとなくメトリクスに目を通しておき関係者に質問に行く。
事業部長とか数字周りの決済を持ってる人に20分くらい時間もらってどういう思想のサービスなのかを聞いておくといい。
3は一番簡単でgithubにあるコードを読むだけ。
それもしっかり読み込むというよりはどのパスで何してるとかこんなバッチがあるんだ！とか構成だけなんとなく把握するに留める。電車とか空き時間にできる。
一連の作業をしながらサービスの地図の輪郭やレイヤーを作っておく。
これがないとエラー対応などがめちゃくちゃ大変。あと新規開発のときも誰のためのどういものなのかみたいなのがわからなくてゴミを作るのを避けられる。
検索のためのインデックを張り巡らせる
地図の全体像ができたら次は地図の精度と地図へのアクセスのしやすさを固める。
検索のためのインデック強化には色々と方法はあるが自分はまずはエラー対応を先輩と一緒にする。
どこでどんなエラーが起こるのかわかるし、ログの置き場や対応方法などプロジェクトごとにお作法があったりするのを把握する。
そして運用上の問題なのかインシデントなのかを突き止めたりログをみてコードを読むことで機能と実態（コード）の理解を深める。
ある程度エラー対応できるようになったら担当領域を問わず小さい改修などに参加させてもらう。
フロントなら文言変更、バックエンドならCSV吐き出す周り、インフラならBIの設定とかメトリクス書いたりするのがおすすめ。
この辺ができるとある程度の問題が起きても自分が窓口となって対応できることが増えるしどこで起きてる問題なのかを把握するスピードが上がり対応属度が高くなる。
普段の開発でもバックエンドの特性や、フロントエンドの台所事情を知った上で開発ができより開発がスムーズになる。
『フロントエンドエンジニアなのにインフラなんて見たくねーよ。』
『SQLわからん。』
って意見もあると思うけどフロントエンドスペシャリストでバックエンドとは無縁でR＆Dしてるならまだしもまあ大体はサーバーサイドもわからんときついのでやったほうがいいぞ？（老婆心）
タグをつける
問題やルールなどごとに自分の中でタグを付けてメモや個人Slackなんかに流しておくといい。一つを詳細に知っているよりも高速に必要なことにアクセスできる状態を作るのが大事。
エラーメッセージ覚えたりとかするレベルになるとさすがの一言。
定期的に引き出す
定期的に引き出さないと情報が枯れる。 なので定期的に関係者とランチしたり、普段はフロントエンドでもバックエンドのチャンネルや会話を聞いておくのは大事だ。
あと、『何をなすべきか』がずれると開発もサービス運営も精神的にも肉体的にもきついので事業部長クラスの人と何をなすべきかをすり合わせて置く必要がある。
まあこのへんは僕の所属組織だと月末に飲み会があったりするのでやりやすい。ないなら自分が幹事をすればいいだけだ。
まとめ
僕自身も完璧なチームフィットを早急にするのって難しいとおもってきたのでこんな記事を書いた。
これからプロジェクトとかに配属になると思う新人の助けにちょっとでもなれたらいいなと思う。
