😸

現場にアサインされたらまず最初に何を確認する？何が大事？

2024/01/10に公開

新人プログラマ応援

概要

現場、会社によっては、言語、フレームワーク、バージョン、ツールなど様々です。
上の４つは最初は例え未経験でも事前に調べたらわかると思いますが、
現場にアサインされたら「何すればいいの？」という微、未経験の方はいらっしゃると思います。最初は環境構築から入ると思うのですが、それはドキュメントにまとまっていたりします。

次に何を確認するでしょうか。

まずは何を確認する？

まず現場のルールは確認しましょう。
システムの理解も大事ですが、現場のルール確認が優先度高いかなと思います。
この記事ではルール確認について話していきます。

現場によってルールが変わるので、そもそもこれを無視していたら、
どれだけ技術力高くても、現場では相手にされないです。

開発のチーム体制の確認

メンバーの把握

まずはメンバーの確認をしましょう。
1.誰が何の担当か
2.レビュアーは誰か
3.困った時誰に質問すればいいのか
4.誰が忙しいのか、手が空いていることが多いのか
5.メンバーの得意、不得意

特に誰が誰が忙しいのか、手が空いていることが多いのかを把握しないで
自分本意の質問ばかりしていると、相手の時間を奪うのでどう時間を奪わないかも意識しましょう。
また、忙しくなることがわかっている人なら聞けそうな時間を見つけて聞きましょう。

自分本位だけで動かないことが大切です。
僕もこれができていなくて、相手を困らせてしまったことが何回もあります。😅

イベントの確認

定例会、朝会、夕会、お昼のミーティングなど現場によって様々です。
この時間を使って相談したり、提案したり、全体の進捗を確認したりしましょう。

ex)僕の場合

夜回、週１回朝会なし。
夕会(週2,3回)
夜回(週2,3回)

など様々でした。
開発に入る前のインフラのお仕事は週5朝会、週5夕会
テスターをやった時は週３朝会、不定期でお昼のミーティング　でした。

ビジネスサイドの確認

DDDみたいなビジネスサイドの方と連携を取って開発する現場もあったりします。
ビジネスサイドの要求に応じて開発していくこともあります。

例えば野球ゲームを作るのに、どんだけ技術力高いエンジニアがいても、
全員野球のルールがわかりませんだと野球ゲームなんか作れないですよね。
それと同じようなイメージです。

コーディングルールの確認

現場によってコーディングのルールがあったりします。
書き方が統一されていないと可読性(コードが読みやすいか)がめちゃくちゃになってしまいます。
コードは基本自分達が全員現場から離れても、後から入ってきた人がわかるように書く必要があります。

ex)
変数の命名規則など

まずはドキュメントなどにコーディング規約が書かれてあるか確認しましょう。
ない時はコードを読みながら、もしくはプルリクを出した時のレビューで理解していくといいです。
ない時は後から入ってきた人のことを考えてドキュメントにまとめておくといいです。

ちなみにCTOやリーダーの方は議事録やドキュメントで情報共有をすると凄い喜んでくれます。
ぜひ取り組んでみてください。

ブランチ運用確認

これはつまりGitの運用です。たまにRedmineなどGitを使っていない現場もありますが、
基本Gitがメインです。

ブランチは基本Git Flowに沿って運用されます。
そしてGitには基本的には命名規則があります。
しっかり現場に沿ってブランチ名の運用には気をつけましょう。

Git運用の確認

Gitの運用はめちゃくちゃ大事です。

なぜGitは大事なのか。

自分が聞いた話と自分の実体験から話ます。
ex)
自分が最初に入った現場のリーダーの方は、初めて開発に参画した時に、
Gitのことがわからず、会社のシステムを破壊しかけたそうです。

自分もGit push origin main(実際はデフォルトでmainブランチのままだった)を
やってしまったことがあり、厳重注意をされたことあります。
これは幸い研修だったのですが、他の方がブランチを切る時に動作がおかしくなってしまいました。

このようにGit操作をミスると会社に損害を与える危険性があります。
もしユーザーが何万人もいるサービスなら何万人にも迷惑がかかったりします。

developブランチの確認

基本はdevelopブランチをおくことが多いです。
これはmainブランチの緩衝地帯みたいな役割をするブランチです。
３つの案件に関わった中で2つの現場はdevelopmentブランチを置いてました。
１つだけいきなりmainブランチにプルリクを出す現場がありました。(珍しいケースかも)

リリースがいつか確認

まずいつリリースするのかを確認しましょう。

ex)
毎週水曜日反映
月に１回
経営層が随時判断
自社のサービスで納期が決まっていない(無くても会社は回ってしまう)
半年後など

などなどです。

このリリースから逆算していつまでにやるべきかのお見積もりを立てることが大切です。
現場によってはステージング環境(リリース前のテスト)でテストしてからリリースする現場もあれば
ステージング環境無しでリリースする場合もあります。後プルリクが通った翌日にリリースは基本ないです。

ちなみに僕の場合
経営層が随時判断、自社のサービスで納期が決まっていない、ステージング環境なし
という現場でした。

ルール確認終わったら

今回はカットしますが、システムや仕様の理解をしていきましょう。

振り返りをしましょう

本田圭佑さんは必ず一日の振り返りをやっていたそうです。
これはスクールの話ではなくて、実務でも言えることです。

やることは
1.自分のよかったこと
2.指摘されたこと、改善すべきこと
3.2を改善するためにどうするべきか(仕組み化して考える)

の振り返りはやりましょう。
可能ならリーダーや先輩にもレビューしてもらいましょう。