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

DevOpsエンジニアの参画初月は、パイプライン・IaC・権限・リリース手順の現状をつかみ、使う人と決める人を知り、小さな改善を一つ届けたうえで、月末に「現状の見立て」と「改善の順番」を出して合意を取るところまでを目標にします。初月に求められるのは大きな仕組みを作ることより、この人に開発の流れを任せて大丈夫だと発注側が判断できる材料を示すことです。

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

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

この3つを、1週目、2週目、3〜4週目の順に重心を移しながら進めます。

1週目：仕組みと人から現状を集める

最初に読むもの

DevOpsエンジニアは、資料より実物を読む比重が大きくなります。次の順で目を通すと、全体像をつかみやすくなります。

1. リポジトリとブランチの運用：どこで開発し、何をきっかけにパイプラインが動くか
2. パイプラインの定義：テスト、ビルド、成果物の保存、デプロイの各工程と、かかっている時間
3. IaCのコードとstateの置き場所：どの環境がコードで管理され、どこが手作業のまま残っているか、誰が適用しているか
4. 権限と秘密情報の扱い：パイプラインに渡している権限と、認証情報の置き場所
5. リリースの手順書と直近の障害の記録：手作業が残る工程と、過去に失敗した場面

読みながら、「仕組みではこうなっているが、実際は手で補っていそう」という点を書き留めておきます。この段階では結論を出さず、仮説としてためておきます。

開発者と短く話す

仕組みの困りごとは、使っている人に聞くのが一番早く分かります。開発チームのリーダー、よくリリースを担当する人、インフラの担当者と、それぞれ短い時間で話す機会をもらいます。聞くことは次の3つに絞ると、相手の負担になりません。

• 開発やリリースで一番時間を取られていること
• 今の仕組みで助かっていること
• 外部のDevOpsエンジニアに期待すること

同じ質問を複数のチームにすると、困りごとの重なりと違いがはっきりします。

今の状態を測っておく

改善の効果を後で示すために、最初の状態を測っておきます。DORAは、ソフトウェアの届け方の指標として、変更のリードタイム、デプロイの頻度、失敗したデプロイからの復旧時間、変更の失敗率、本番の障害が原因で行う計画外のデプロイの割合（デプロイの手戻り率）を挙げています（2026年1月更新の公式ガイドによる）。すべてを正確に測る必要はありません。パイプラインの実行時間や、直近のデプロイの回数など、記録から拾えるものだけでも控えておくと、月末の見立てに使えます。

2週目：小さな改善を一つ届ける

権限が要らない、または小さい改善を選ぶ

2週目には、影響が小さく、効果が分かりやすい改善を一つ選んで届けます。たとえば、遅い工程のキャッシュの見直し、失敗しやすいテストの切り分け、パイプラインの失敗時の通知の整理などです。最初の改善は、プルリクエストとしてレビューを受け、現場の変更の流れに乗せて出します。

変更の流れを体で覚える

最初の改善を出すことで、レビューの決まり、誰が承認するか、本番に反映するまでの手順が分かります。ここで分かった流れは、3週目以降の大きな変更の計画に使います。

必要な権限を一覧にして出す

初月のうちに必要になる権限と、その理由を一覧にして窓口に出します。権限は必要な範囲に絞って求めるのが基本です。GitHubのドキュメントでも、ワークフローのトークンの権限を必要最小限にすることが勧められています（2026年10月時点）。自分の権限も同じ考え方で求めると、発注側も判断しやすくなります。

3〜4週目：見立てを出し、改善の順番に合意を取る

現状の見立てをまとめる

1〜2週目で集めた情報をもとに、現状の見立てをまとめます。中身は次のとおりです。

• 手作業が残る工程と、そのために起きていること
• コードで管理されていない環境と、食い違いの危うさ
• 権限や秘密情報の扱いで直したほうがよい点
• 開発チームの困りごとと、その原因の見立て

改善の順番は選択肢で出す

改善が必要な点が多い場合、一つの案だけを出すと、「今の仕組みを否定された」と受け取られやすくなります。効果、手間、止めてはいけない業務への影響を並べ、どれから手を付けるかを発注側に選んでもらう形にします。推す順番があれば、その理由を添えます。

次の1〜2か月の計画を引く

合意した順番をもとに、次の1〜2か月の計画を引き、関係するチームに共有します。移行を伴う場合は、どのチームから移すか、元に戻す手順をどうするかも書いておきます。

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

新しい基盤を立ち上げる案件

まだ仕組みがない段階で入る場合は、現状の把握より、使うチームの要望と、決まりや統制の条件を言葉で合わせることが中心になります。月末には、構成の骨子と、決めきれていない論点の一覧を出せることを目指します。

古い仕組みから移す案件

手作業のリリースや古いCIツールからの移行では、止めてはいけない業務と、移す順番の見立てが初月の中心です。最初の移行は、影響の小さいサービス一つに絞って計画します。

複数チームの標準をそろえる案件

チームごとに違うやり方をそろえる案件では、技術より合意の取り方が大切です。初月は、各チームの今のやり方と、そろえたときに困ることを聞き取るのに時間を使います。

運用を引き継ぐ案件

前任者が作った仕組みを引き継ぐ場合は、作り直しを考える前に、今の仕組みを動かし続けられる状態をつくることを優先します。引き継ぎの資料が少ないときの進め方は引き継ぎの記事も参考にしてください。

初月に避けたい動き

範囲外の依頼が増えてきたときの扱いは業務範囲が変わったときの記事、DevOpsエンジニアがつまずきやすい場面はDevOpsエンジニアのフリーランスがつまずきやすい点と対策で整理しています。

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

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

• 決める立場の人に、現状の見立てと改善の順番を伝えられたか
• 小さな改善を一つ、現場の変更の流れに乗せて届けられたか
• 最初の状態を、後で比べられる形で記録できているか
• 契約で決めた業務の範囲と、実際に担っている仕事がずれていないか
• 時間外の作業を含め、稼働時間の記録が残っているか

ずれている点があれば、2か月目の早い段階で窓口と話しておきます。

よくある質問

初月はほとんど権限がもらえません。何から始めればよいですか？

読み取りの権限で見られる範囲から、構成図と課題の一覧を作るのが近道です。改善案はプルリクエストの形で用意し、反映は社員のメンバーにお願いする形にすれば、権限がなくても成果を見せられます。必要な権限は理由と一緒に早めに出しておきます。リモートの案件での進め方はDevOpsエンジニアのリモート案件の記事でも触れています。

前任者の仕組みが複雑で、全体がつかめません。

一度に全体をつかもうとせず、よく使われるパイプラインから順に、きっかけ、工程、反映先を書き出していきます。分かっていることと分かっていないことを分けて報告し、残りをいつまでに確かめるかの予定を示すほうが信頼されます。

社員のDevOps担当やSREがいる現場で、どう振る舞えばよいですか？

最初の週のうちに、どの仕組みを誰が持ち、どの変更を誰が承認するかを確かめておきます。担当を仕組みごとに分けておくと、同じ箇所を二人で直す食い違いを防げます。SREとの役割の分け方はSREの参画初月の記事も参考にしてください。