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

フリーランスのDevOpsエンジニアがつまずきやすいのは、構築と運用の境目があいまいな契約、権限が渡されずに止まる初期、作った仕組みが使われないことや自分しか直せない状態、そして夜間のリリースや障害対応の稼働の膨らみです。どれも、外部の立場で「組織のやり方を変える仕事」を担うことから起きます。

対策の基本は、範囲と完了の基準を契約と参画初期に言葉で決め、現場では小さく変えて記録を残し、引き継げる形で手放すことです。この記事では、契約・現場・技術・お金の順に、DevOpsならではの場面と対策を整理します。案件を選ぶ段階で確かめる項目はDevOpsエンジニアの案件の選び方で扱っているので、ここでは「参画してから起きやすい場面」に絞ります。

契約でのつまずき

「構築」のつもりが「運用」まで続く

パイプラインやIaCの整備で参画したのに、完成後も問い合わせ対応や不具合の修正、毎回のリリース作業まで期待され続ける、という食い違いはよく起きます。DevOpsの仕組みは作った後も使われ続けるため、構築と運用の境目が契約に書かれていないと、範囲が少しずつ広がります。

対策：参画前に、作るもの（パイプラインの定義、IaCのモジュール、使い方の文書など）と、受けないもの（毎回のリリース作業の代行、アプリの不具合の調査など）を言葉で確かめます。範囲の外の依頼が増えたときの扱いは業務範囲が変わったときの記事をご覧ください。

完了の基準が決まっておらず、終わらない

「CI/CDを整備する」とだけ決めて始めると、どこまでで完了なのかが人によって違います。準委任の契約でも、成果物の完成を約束するように読める書き方になっていると、責任の範囲が広く見えることがあります。契約の形による違いは準委任契約と請負契約の違いで確かめてください。

対策：「対象のサービス」「対象の環境」「引き継ぎの相手」を区切り、どの状態になったら一区切りかを最初の打ち合わせで書き出しておきます。

本番の事故の責任を問われる

自動化した仕組みの不具合で本番に影響が出たとき、「仕組みを作った人の責任」と言われそうになることがあります。

対策：本番に反映する前の承認の流れを発注側と決め、誰の承認で反映したかを記録に残します。契約書の損害賠償の条項は署名の前に読み、上限の考え方は損害賠償の上限の記事と賠償責任保険の記事を参考にしてください。判断に迷う場合は弁護士などの専門家にご相談ください。

作ったモジュールや雛形の権利があいまい

案件で作った共通のモジュールやスクリプトを、ほかの案件でも使えると思い込むのは危険です。権利の扱いは契約によって決まります。考え方は著作権の記事で整理しています。

現場でのつまずき

権限が渡されず、最初の数週間が止まる

外部のDevOpsエンジニアには、最初は読み取りの権限だけが渡され、クラウドやリポジトリの設定の変更は社員に依頼する形になることがあります。権限の申請に時間がかかると、何もできないまま評価の時期が来てしまいます。

対策：権限がなくても進められる仕事（現状の把握、構成図の作成、改善案の比較）を先に進め、必要な権限と理由を一覧にして早めに出します。最初の1か月の進め方はDevOpsエンジニアの参画初月にやることで整理しています。

作った仕組みが開発チームに使われない

よかれと思って作った雛形や決まりが、開発チームに「押し付け」と受け取られ、使われないまま終わることがあります。DevOpsの成果は使われて初めて生まれるため、ここでつまずくと契約の更新に響きます。

対策：最初に一つのチームと一緒に試し、困りごとが減ったことを確かめてから広げます。使い方の文書と、質問を受ける場所を決めておくと、移ってもらいやすくなります。

自分しか直せない仕組みになる

急いで整備すると、構成の理由が自分の頭の中にしかなく、契約が終わった後に誰も手を入れられない仕組みが残ります。発注側にとっては負担になり、引き継ぎの段階で信頼を損ないます。

対策：構成を選んだ理由をプルリクエストや文書に残し、社員のメンバーにレビューや変更を担ってもらう機会を早くから作ります。引き継ぎの進め方は引き継ぎの記事をご覧ください。

技術でのつまずき

stateの置き場所と適用の流れを決めずに始める

IaCを導入するとき、stateの置き場所や、誰がいつ適用するかを決めないまま進めると、手元での適用が重なって環境が食い違うことがあります。Terraformの公式ドキュメントでは、stateをローカルに置くと共同作業が難しくなり失う危険もあるとして、HCP Terraformやリモートのバックエンドでの保管を勧め、ロックやアクセス制御のない保管は秘密情報の漏えいにつながるおそれがあると注意しています（2026年10月時点）。

対策：取り込みを始める前に、stateの保管場所、ロック、適用する人と手順を決めて合意します。既存の環境を取り込むときは、範囲を小さく区切って進めます。

パイプラインに強すぎる権限と長期の鍵を置く

自動化を急ぐと、パイプラインに広い権限や長期の認証情報を持たせがちです。GitHubのドキュメントでは、ワークフローのトークンの権限を必要最小限にし、外部のアクションは完全なコミットSHAで固定すること、クラウドへの認証にはOpenID Connectで短期のトークンを使うことを勧めています（2026年10月時点）。

対策：権限の範囲と秘密情報の置き場所を、構築の最初に設計の一部として決めます。前任者の設定を引き継ぐ場合も、権限が広すぎないかを最初に見直します。

一度に移行して、全チームを止める

古いCIツールからの移行やリポジトリの構成の変更を一度に行うと、問題が出たときに全チームの開発が止まります。

対策：一つのチーム、一つの環境から移し、元に戻す手順を用意してから次へ進みます。切り替えの日は発注側の業務の予定と合わせて決めます。

お金でのつまずき

夜間のリリースや障害対応が精算されない

業務時間外のリリースへの立ち会いや、仕組みの不具合で開発が止まったときの呼び出しが続くと、稼働が精算幅を超えることがあります。待機の扱いを決めていないと、報酬に反映されないまま負担だけが増えます。

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

検証のクラウド費用を自分で持つ

案件の検証のために、自分のクラウドのアカウントで環境を立てると、費用を立て替えたまま精算の決まりがないことがあります。業務の情報を個人の環境に置くこと自体が、契約上の問題になる場合もあります。

対策：検証は発注側が用意した環境で行うのを基本とし、費用の扱いが分からない場合は始める前に窓口に尋ねます。

整ったところで契約が終わる

移行や整備がうまく進むほど、外部の人の役目は小さくなります。フリーランス法では、6か月以上の業務委託を解除したり更新しなかったりする場合、発注側は少なくとも30日前までに予告することになっています（2026年10月時点、公正取引委員会の特設サイトによる）。

対策：引き継ぎの時期が見えたら、契約の更新時期の1〜2か月前には次の案件の相談を始めます。終わりが近づいたら、作った仕組みと成果を、守秘義務の範囲で一般化してスキルシートに書き足しておきます。

よくある質問

参画してから、聞いていた範囲よりも運用の仕事が多いと気づきました。どうすればよいですか？

何が範囲の外なのかを具体的に書き出し、契約で決めた業務範囲と照らし合わせます。そのうえで、紹介を受けたエージェントや発注側の窓口に早めに伝えてください。我慢して続けると、運用の代行が当たり前になり、後から戻しにくくなります。

自分が作ったパイプラインが原因で本番に障害が出たら、賠償を求められますか？

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

前任者の仕組みに問題が多いとき、どう伝えればよいですか？

前任者を否定する言い方は避け、事実として起きていることと、そのままにした場合の影響、直す順番の案を並べて示します。どこから直すかは発注側に選んでもらう形にすると、現場の協力を得やすくなります。