Goエンジニアのフリーランスがつまずきやすい点と対策

フリーランスのGoエンジニアがつまずきやすいのは、障害対応の待機が契約に書かれていないこと、他の言語の書き方を持ち込んでレビューで食い違うこと、並行処理の不具合を本番で出すこと、版の更新を後回しにすること、障害やリリースで稼働が膨らむことです。どれも、止められないサービスや基盤を外部の立場で担うことから起きます。

対策の基本は、つまずきの種を契約と参画初期の取り決めで小さくし、現場では書き方の合意と記録で守ることです。この記事では、契約・現場・技術・お金の順に、Goならではの場面と対策を整理します。独立前の準備はGoエンジニアがフリーランスになるにはで扱っているので、ここでは参画中に起きやすい場面に絞ります。

契約でのつまずき

障害対応の待機が、契約にないまま当たり前になる

Goで作られるサービスは、止まると影響の大きいものが少なくありません。参画してしばらくすると、「何かあったら連絡が行くので対応してほしい」と頼まれ、夜間や休日の待機が契約に書かれないまま続くことがあります。

対策：参画前に、障害対応の当番があるか、あるならどの時間帯で、待機と対応の時間をどう扱うかを確かめます。契約書の業務範囲に書かれていない対応を求められたときの扱いは業務範囲が変わったときの記事と追加の依頼の断り方をご覧ください。

「API開発」のはずが、インフラまで任される

Goの現場では、アプリとインフラの境目があいまいなことが多く、APIの開発で入ったのに、Kubernetesの設定やクラウドの権限設計、CIの整備まで頼まれることがあります。できる範囲で手伝うのは悪いことではありませんが、責任の範囲が広がったまま報酬や稼働が変わらないと負担になります。

対策：引き受ける作業と引き受けない作業を、参画初期に窓口と言葉で確かめます。インフラの作業が継続的に増えそうなら、契約の見直しの対象として早めに伝えます。

指揮命令の形が社員と変わらなくなる

少人数のチームに深く入ると、勤務時間の管理や作業の手順まで社員と同じように指示される状態になりやすくなります。準委任の契約と実態がずれていないかは、偽装請負の記事で考え方を確かめてください。

現場でのつまずき

他の言語の書き方を持ち込み、レビューで揉める

JavaやPHPから移ってきた人に起きやすいつまずきです。深い抽象化、使う側より先に大きなinterfaceを定義する作り、エラーを握りつぶす書き方などは、Goの現場のレビューで指摘されやすい点です。指摘が続くと、「現場の決まりに合わせない人」と見られてしまいます。

対策：参画した最初の週に、既存のコードとレビューの履歴を読み、エラーの包み方、パッケージの分け方、ログの出し方など、そのチームの書き方を書き出します。前の現場のやり方を勧めたいときは、まず現場の書き方で書いたうえで、理由と一緒に提案します。

設計の合意を取らずに実装を進める

Goは書き始めるのが速い言語です。そのため、サービス間の通信の形やデータの持ち方を相談せずに実装し、レビューで大きな手戻りになることがあります。リモート中心の現場ではとくに起きやすくなります。

対策：一定以上の変更は、短い設計メモを先に書いて合意を取ってから実装します。リモートで進めるときの工夫はGoエンジニアのリモートの記事でも触れています。

障害の場で、原因の切り分けより修正を急ぐ

障害対応では、すぐに直したくなります。しかし、原因を絞り込まないまま修正を入れると、別の不具合を生んだり、発注側への説明ができなかったりします。

対策：影響の範囲、暫定の対応、原因の見立て、恒久の対策を分けて報告します。判断に迷う修正は、発注側の担当者に選んでもらう形をとります。

技術でのつまずき

goroutineの後始末を忘れ、本番で問題が出る

並行処理は、手元のテストでは問題が見えにくく、本番の負荷の下で初めて表に出ることがあります。終わらないgoroutineがたまってメモリが増え続ける、contextのキャンセルが伝わらず処理が止まらない、共有したデータの競合で値が壊れる、といった場面です。

対策：goroutineを起こすときは、誰がいつ止めるのかを先に決めます。contextを最後まで渡す、競合の検出を有効にしてテストする、負荷をかけた試験で増え方を見る、といった確認を習慣にします。並行処理の考え方はGoエンジニアに求められるスキルで整理しています。

版の更新を後回しにする

Goの公式のリリース履歴では、各メジャーリリースは、2つ新しいメジャーリリースが出るまでサポートされる方針が示されています。2026年10月時点では、Go 1.27（2026年8月19日リリース）とGo 1.26（2026年2月10日リリース）がサポート対象です。新しい版がおおむね半年ごとに出るため、更新を後回しにすると、気づいたときにはサポートの外の版で動いていることがあります。

対策：参画した現場で使っている版と、依存するモジュールの更新の状況を早めに確かめます。更新を自分の仕事として提案し、テストとCIで確かめる流れを回すと、運用まで担える人として評価されやすくなります。

依存するモジュールを気軽に増やす

便利なライブラリを次々に加えると、更新や脆弱性への対応の手間が増え、後から入る人が読みにくくなります。標準ライブラリを重んじる現場では、とくに嫌われやすい動きです。

対策：新しい依存を加えるときは、標準ライブラリで足りないか、保守が続いているかを確かめ、理由をレビューで説明します。

お金でのつまずき

障害やリリースで稼働が精算幅を超える

障害対応や大きなリリースの前後には稼働が延びやすく、精算幅を大きく超えることがあります。超えた分の扱いを決めていないと、報酬に反映されないまま負担だけが増えます。

対策：稼働を日々記録し、精算幅を超えそうな段階で窓口に伝えます。精算の仕組みは精算幅の記事で解説しています。

置き換えや立ち上げの区切りで契約が終わる

置き換えが終わった、基盤が稼働した、といった節目で契約が更新されないことがあります。フリーランス法では、6か月以上続く業務委託を解除したり更新しなかったりする場合、発注側は少なくとも30日前までに予告することになっています（2026年10月時点、公正取引委員会の案内による）。

対策：契約期間と開発の山の区切りを並べて見ておき、更新の見込みを早めに確かめます。契約期間の考え方は契約期間の記事をご覧ください。

学ぶための費用と時間を見込んでいない

Goの周辺は、クラウド、コンテナ、監視の道具など、手元で試すのに費用がかかるものが多くあります。案件に追われて学ぶ時間も取れないと、次の案件で選べる幅が狭まります。

対策：検証用の環境の費用を経費として記録し、学ぶ時間を月の予定に組み込んでおきます。

よくある質問

レビューで指摘が多く、現場に合っていない気がします。どうすればよいですか？

指摘の内容を分類し、現場の書き方の違いによるものか、Goの考え方の理解によるものかを分けて見てください。前者はチームの決まりを書き出して合わせれば減ります。後者は、指摘された箇所の理由をレビュアーに尋ね、同じ指摘を受けないよう手元にまとめておくと、数週間で落ち着くことが多くあります。

契約にない夜間の障害対応を頼まれました。断ってもよいですか？

契約にない業務は、引き受ける義務があるとは限りません。ただ、サービスの事情もあるため、まずは対応できる範囲と条件を窓口に伝え、続けるなら契約に書き加える形で話を進めるのが現実的です。判断に迷う場合は、紹介を受けたエージェントに確かめてください。

本番で自分が書いたコードが原因の障害が起きたら、損害賠償を求められますか？

準委任契約では、成果そのものではなく、専門家として通常求められる注意を払って業務を行うことが約束の中身です。ただし、契約の内容や落ち度の有無によって判断が変わることがあります。不安がある場合は、契約書の損害賠償の条項を読み、弁護士などの専門家にご相談ください。