Goエンジニアの参画初月にやること｜現場で信頼される進め方

Goエンジニアの参画初月は、現場の書き方とレビューの決まりを覚え、小さな変更を本番まで一度通し、月末に運用上の気がかりを整理して伝えるところまでを目標にします。最初の1か月で求められるのは、大きな機能を作ることより、このチームのやり方で安心してコードを任せられる人だと示すことです。

参画前の契約や環境の準備は参画が決まってから開始日までにやること、職種を問わない最初の1週間の動き方は参画初日から最初の1週間でやることで解説しています。この記事では、Goのバックエンドや基盤の現場ならではの初月の進め方に絞ります。

初月のゴールを3つに分ける

この3つを、1週目、2週目、3〜4週目の順に重心を移しながら進めます。Goの現場は少人数のチームが多く、一人の振る舞いが全体に響きやすいため、最初の数週間は速さより合わせ方を優先するのが無難です。

1週目：環境を整え、コードと決まりを読む

手元で動かせる状態をつくる

最初の数日は、リポジトリを取得し、手元でビルドとテストが通り、サービスを起動できる状態をつくることに使います。Goはビルドが速く、依存もモジュールで管理されているため、手順書どおりに進めば短時間で動くことが多い言語です。それでも、社内のモジュールの取得に認証が要る、生成コードを作る手順がある、ローカル用のデータベースをコンテナで立てる、といった現場ごとの手順でつまずくことがあります。

つまずいた点は、解決した方法と合わせて書き残しておきます。手順書に足りない部分があれば、そのまま修正の提案につなげられます。後から入る人の助けになるため、初週の貢献として受け入れられやすい仕事です。

読む順番を決めて、コードを読む

Goのコードは、入口から追うと全体をつかみやすくなります。次の順で目を通すのがおすすめです。

1. mainパッケージと起動の流れ：設定の読み込み、依存の組み立て、サーバーの起動と終了の扱い
2. ディレクトリとパッケージの分け方：層で分けているのか、機能で分けているのか
3. エラーの扱い：エラーの包み方、ログに出す場所、呼び出し元への返し方
4. context と並行処理：タイムアウトやキャンセルをどこで設定し、goroutineをどう止めているか
5. テストの書き方：テーブル駆動のテストか、モックの作り方、結合テストの有無

あわせて、直近のプルリクエストとレビューのやりとりを数十件ほど読みます。どんな指摘が多いかを見ると、チームが大事にしている点が分かります。

決まりを書き出す

読みながら、「この現場の書き方」を自分用に書き出します。命名、エラーメッセージの形、ログの項目、設定の渡し方、依存を増やすときの決まりなどです。前の現場と違う点ほど、意識して書いておきます。

2週目：小さな変更を本番まで通す

最初の変更は小さく選ぶ

2週目には、小さな不具合の修正、ログの改善、テストの追加など、影響の小さい変更を一つ選び、本番に出すところまで進めます。窓口やリードに「最初に取り組むのに向いた課題」を尋ねると、ちょうどよい大きさのものを選んでもらえることが多くあります。

ねらいは、変更そのものより流れを一度通すことです。ブランチの切り方、プルリクエストの書き方、レビューの依頼の仕方、CIで走る静的解析とテスト、リリースの手順、本番での確かめ方を、自分の手で経験します。どこで誰の承認が要るかも、このときに分かります。

レビューの指摘は理由まで聞く

最初の数件のプルリクエストでは、指摘が多くなるのが普通です。指摘を直すだけでなく、理由が分からないものは短く尋ね、メモに足していきます。同じ指摘を二度受けないようにすることが、2週目以降の信頼につながります。

報告の形を合わせる

日々の報告や相談をどの場で、どの粒度で行うかも、この時期に合わせます。チャットでの書き方はチャットでの報告・相談の書き方で整理しています。稼働の記録の付け方と提出の形も、初月のうちに窓口と確かめておくと、月末に慌てずに済みます。書き方は稼働報告書の記事をご覧ください。

3〜4週目：運用を知り、気がかりを整理する

監視と障害の履歴を見る

3週目からは、本番の運用に目を向けます。ダッシュボードやアラートの設定、ログの検索の仕方、トレースの見方を覚え、直近の障害の振り返りの記録があれば読みます。障害対応の当番がある案件では、手順書と連絡の流れを確かめ、当番に入る時期と、待機や対応の扱いを窓口と言葉で合わせておきます。

気がかりを集めて、優先度をつける

1か月の間に気づいた点を、次のような観点で並べます。

• 版と依存：使っているGoの版がサポートの範囲にあるか、古いままのモジュールがないか
• 並行処理：止める仕組みのないgoroutine、タイムアウトのない外部呼び出し
• 監視：障害に気づけない処理、ノイズの多いアラート
• テストとCI：テストのない重要な処理、時間のかかりすぎるCI
• 手順書：手元の環境づくりやリリースの手順で足りなかった点

一覧にしたら、影響の大きさと直す手間で優先度をつけ、リードや窓口に共有します。直すかどうか、いつ直すかを決めるのは発注側です。初月は見えるようにすることまでを自分の役割と考えると、出過ぎた提案と受け取られにくくなります。並行処理や版の更新で起きやすいつまずきはGoエンジニアのフリーランスがつまずきやすい点と対策で詳しく扱っています。

案件の型によって初月の重心は変わる

同じGoの案件でも、型によって初月に力を入れる場所が違います。

置き換えの案件では、元のコードの読み解きに時間がかかるのが普通です。初月の成果が見えにくくなるため、どこまで読めたか、どの単位で移せそうかを週ごとに短く報告すると、進み具合が伝わります。リモート中心の現場では、こうした報告がとくに大切になります。進め方の工夫はGoエンジニアのリモートの記事でも触れています。

初月に避けたい動き

範囲外の依頼が増えてきたときの扱いは作業範囲が広がったときの記事で整理しています。

1か月の終わりに振り返ること

1か月が過ぎたら、次の点を自分で振り返ります。

• 自分の変更を、レビューからリリース、本番での確認まで通せたか
• この現場の書き方のメモがまとまり、レビューの指摘が減ってきているか
• 監視とログの見方を覚え、障害が起きたときの連絡の流れを知っているか
• 気がかりの一覧を、リードや窓口と共有できたか
• 契約で決めた業務の範囲と、実際に担っている仕事がずれていないか
• 稼働の記録が残り、精算幅との関係を把握できているか

稼働が精算幅を超えそうな場合の扱いは精算幅の記事で解説しています。ずれている点があれば、2か月目の早い段階で窓口と話しておきます。

よくある質問

手元の環境づくりに数日かかってしまいました。遅れと見られますか？

社内のモジュールの取得や生成コードの手順など、現場ごとの事情で時間がかかることは珍しくありません。どこでつまずき、どう解決したかを記録し、手順書の修正として提案すれば、後から入る人の役に立つ仕事として受け止められやすくなります。

初月から大きな機能の担当を任されたら、どうすればよいですか？

断る必要はありませんが、最初に設計の方針を短いメモにまとめ、リードと合意を取ってから実装に入ることをおすすめします。あわせて、小さな単位でプルリクエストを出し、早い段階でレビューを受けると、現場の書き方とのずれを小さいうちに直せます。

レビューの指摘が多く、自信をなくしています。どう受け止めればよいですか？

参画直後に指摘が多いのは、現場の書き方を知らないことによる部分が大きく、能力の評価とは別のことが多くあります。指摘を内容ごとに分けてメモにまとめ、同じ指摘を繰り返さないようにすると、数週間で落ち着いていくのが一般的です。考え方の違いによる指摘は、理由をレビュアーに尋ねてください。