これなに
へなちょこ文系エンジニアな自分がチームに入ったらやっていること、やっていないことを紹介していきます。
当たり前のことばかりかもしれませんが、それでも参考になる人はいるかもしれないなと思うのと、あとは未来の自分に向けて「あの時の自分はこんなことを考えてやっていた」ということをメモしておこうと思ってこの記事を書いています。
想定読者
この記事は主に以下のような方を想定しています。
- 新しいチームへジョインした人
- 中途入社した人
- わからんけど何かやってやりたいという人
やっていること
ローカル環境準備
できるだけ3日間以内には終わらせたい気持ちでやっています。
整理された組織は理想ですが実際には多くないので、トライアンドエラーで構築をできるだけ進めます。
開発環境、ステージング環境のアクセス情報の取得
ローカルでの開発ができるようになるだけではなく、dev/staging 環境へのアクセス権限も持ち、本番リリース前まで自分で検証できるように周辺を整備しておきます。
チケットやドキュメントをざーっと眺める
ドキュメントが整備されていることもあるので、色々読みにいきます。
加えてチケットについても読んでおきます。できそうなチケットがあれば引き取ってアウトプットを作りにいきます。
チームメンバーと雑談
ドキュメントだけ読んでいても見えない情報がたくさんあるので、できるだけ雑談しにいきます。自分は多人数での会話が苦手なので、できるだけ少人数で話す機会を作りにいっています。
よく使うのは開発の流れだったり、困っている部分、プロダクトの知識や気をつけていることなどをネタとして挙げて話にいきます。
積極的に巻き込まれにいく
ミーティング、リリース、障害対応などいろいろあれば積極的に巻き込まれにいきます。巻き込まれていくことで情報を得られるのと、そこから自分が動けるキッカケを掴めることもあるので、巻き込まれにいくこと自体は良い戦略なのではと思っています。
PRを何か出す
スクラムやカンバンですでにチケットがあったりするのであればその流れに乗って作業をするのもアリだと思います。
ただ、個人的にはそれに加えて何かしらプラスになりそうなものを作ったりしたいです。
個人的なおすすめはプロジェクトコンテキストとあまり関連性がないものを入れるのは良いかもしれないかなあと思っています。コンテキストはしっかり理解しないといけないので時間をかけないといけないですが、関連性のない話ならリポジトリから読み取れるレベルで良いのでそこまでインプットしないといけないコンテキストが多くないかと思うので。
自分がよくやることとしては CI の速度改善、Slack でやりとりされている課題に対してクイックな修正を行ったり、テキストラベルを修正するだけでも全然良いかなと思っています。
最近だと作られていないようなら agents, skills, hooks を組み合わせてハーネスを作っておくこともありかなと思っています。
このあたりやった方が良いのではないかリストを作って公開する
アウトプットを作ったり情報収集をしていく中で見えてくる課題や改善点などが分かってくるので、それらをもとにしてこういうことをやったらいいんじゃないかなーというものをまとめます。
よくあるのは Slack でざーっとメモしたり、markdown に書いてリポジトリにネタを置いておきます。それをもとにまたチームと雑談するネタにしたりして、可能なら自分がリードさせてもらえるように話していきます。
やっていないこと
ドキュメントを細かく深く読み込むこと
自分の性分として細かいところまで全部読み込むスキルが乏しいののあるかもしれませんが、細かい部分まで読み取って理解するのは難しいのでそこまで深くは読んでいないです。（頑張って理解をしようとするものの、完璧は目指していないという感覚）
実際、自分はざっと読んで手を動かしながら理解をしにいく方が良いかなと思います。逆引きでドキュメントは見にいくことはあるのですが、基本はざーっと読むだけにしています。
本番環境アクセス
最小権限の原則に沿って、いきなりアクセスすることはしていないです。（そもそも本番サーバーでの作業権限があると何か操作ミスした時が怖いのもありますが）
一方で DataDog, Sentry, Rollbar のような監視ツール系は欲しいのでもらいたいですし、可能なら本番アプリを触ったりすることもします。
ただ、状況によっては権限をもらうようにします。例えばチーム人数が1〜2人のような少人数しかいなかったりするような状況では属人化が進んでしまっていることが多かったりするので、その場合は自分ももらいにいき組織課題へのアプローチを行います。
正論パンチ
正論パンチはあまりしないようにしています。
例えば、よく提案されがちなアプローチのひとつが「プロダクトの作り直ししませんか？」なのですが、実際は色々な理由があって選択されていないことが経験上ほぼ100%でした。
データ移行は？サービス移行時期は？誰がやるのか？仕様差分はどう受け入れるのか？などなど考えることが多くあるので、現実的にそのような判断をしなかった、あるいはそもそもそれを議論するに値するような状況ではないということが実際にはあることが多いからです。
ただ、この正論パンチ自体は話のフックにはすることはあります。「作り直しした方が早いという話もあるかもしれませんが、実際には選択されていないのでどういった理由があったんですかね〜」くらいの話題の挙げ方にしています。その話を引き出すと意外といろいろなコンテキスト情報が見えてくるので良い情報収集になります。
さいごに
まずはチームのルール、プロセスに従ってやったらいいじゃないかというのもあると思うのですが、自分の場合は最初の1か月で目指しているのは、動ける状態とチームからの信頼を積みたいな〜という気持ちがあり、こんな感じでやっているなというのを記録してみました。
ちなみにこの記事は遊戯王のマリクvs城之内を観ながら書き殴った雑記なので、すごく雑な記事になっていそうな気がしそうだなあと思いますが、まあ読む人もそんなに多くないのでまあいっか！の気持ちで投稿しました。誤字脱字もろもろあったらごめんね。
