SES案件参画後30日で信頼を作る行動

Last updated at 2026-08-19Posted at 2026-08-18

はじめに

SES案件へ参画した直後は、次のような迷いが出やすくなります。

何をどこまで質問してよいのか分からない
早く成果を出そうとして、一人で作業を抱え込んでしまう
進捗をどのタイミングで報告すべきか判断できない
現場の用語、役割、完了条件を理解しないまま作業を始めてしまう

案件参画後の30日間で大切なのは、大きな成果を急ぐことではありません。 確認、報告、記録、レビューを安定して行い、安心して仕事を任せられる状態を作ること です。

この記事では、SES案件へ参画したエンジニアが最初の30日で確認したいことを、週ごとの行動と、そのまま使える報告例に分けて説明します。

この記事で分かること

参画後30日間を週単位で進める方法
作業前、作業中、完了時に確認・報告する内容
分からないことを整理して質問する方法
小さな成果をチームで再利用できる形にする方法
30日目に期待値のずれを確認する振り返り方

先に結論

最初の30日で信頼を作る行動は、派手な成果ではなく、次の積み重ねです。

作業の目的と完了条件を確認する
遅れや問題の兆候を早めに共有する
小さな変更に分けてレビューを受ける
調査結果と判断理由を記録する
30日目に期待される役割を確認し直す

この記事の30日計画は、SES現場で実践しやすい形に独自整理した目安です。業界団体が定めた公式の30日ルールではありません。参画先にオンボーディング手順や報告ルールがある場合は、現場のルールを優先してください。

30日間の行動計画

期間	目標	具体的な行動	確認できる状態
1〜3日目	仕事の前提をそろえる	目的、役割、用語、連絡先、セキュリティルールを確認する	困ったときの相談先を説明できる
1週目	小さな仕事を確実に終える	完了条件、期限、確認方法をそろえて着手する	1件の作業を報告・レビューまで完了できる
2週目	進め方を安定させる	進捗、問題、変更内容を短く共有する	状況を聞かれる前に共有できる
3週目	自分で進められる範囲を広げる	事実、調査結果、自分の案を分けて相談する	丸投げせず、判断材料を渡せる
4週目	次の期待値を合わせる	成果、課題、学習項目、次に担当したいことを整理する	31日目以降の優先事項が分かる

1〜3日目は仕事の地図を作る

初日に説明を受けても、すべてを一度で覚えるのは難しいものです。まず、毎日の作業に必要な情報を一枚のメモへ整理します。

確認項目	確認する内容	例
チームの目的	何を提供・改善するチームか	社内申請システムの保守と機能改善
自分の役割	最初に任される作業	問い合わせ調査、軽微な改修、テスト
完了条件	どの状態で完了になるか	テスト成功、レビュー承認、手順書更新
情報の正本	最新情報をどこで確認するか	チケット、Confluence、GitHub
連絡方法	用途ごとの連絡先	通常連絡はTeams、障害は電話と専用チャネル
相談先	技術・業務・勤怠を誰へ相談するか	テックリード、業務担当、所属会社
禁止事項	実行してはいけない操作	本番直接変更、無許可のデータ持ち出し

AtlassianのWorking Agreementsでは、チームで使う連絡手段、情報を残す場所、エスカレーション方法などを明確にし、新しいメンバーの参加時にも見直すことを勧めています。

役割や責任の認識がずれていると、作業の重複や担当漏れが起こります。自分の認識と周囲の期待が一致しているか、最初の数日で確認します。

端末、アカウント、生成AI、セキュリティカードなどの初日確認は、次の記事にまとめています。

1週目は完了条件をそろえてから着手する

最初の作業では、技術的に着手できるかだけでなく、何をもって完了とするかを確認します。

作業前に確認する5項目

以下は、筆者が作業前の認識合わせに使っている確認項目です。

目的は何か
対象範囲はどこまでか
期限と優先度はどうなっているか
完了後に何を確認するか
誰へレビューを依頼するか

【目的】
顧客一覧画面で発生している表示崩れを修正する

【対象】
PC表示のみ。スマートフォン表示の変更は今回の対象外

【完了条件】
対象ブラウザで表示を確認し、テスト結果をチケットへ記録する

【期限】
8月20日 15時

【レビュー依頼先】
フロントエンド担当の○○さん

作業を始める前にこの内容を共有すれば、「修正は終わったが確認方法が違った」という手戻りを減らせます。

2週目は小さな変更と短い報告を繰り返す

最初から大きな機能を一人で抱えるより、確認しやすい単位へ分けた方が、方向性のずれを早く見つけられます。

GoogleのEngineering Practicesでは、小さく自己完結した変更は、レビューしやすく、不具合を見つけやすく、方針が違った場合の手戻りも小さくなると説明しています。

作業中の進捗報告

問題がなくても、長時間かかる作業では節目で状況を共有します。

顧客一覧画面の表示崩れを修正しています。
原因はCSSの幅指定であることを確認し、現在は修正後のブラウザ確認中です。
現時点で期限への影響はなく、予定どおり15時までにレビューを依頼します。

遅れそうな場合の初動報告

期限を過ぎてからではなく、遅れる可能性が分かった時点で共有します。

顧客一覧画面の修正について共有します。
対象ブラウザの一つで追加の表示崩れが見つかり、原因を確認しています。
15時のレビュー依頼に遅れる可能性があります。
14時まで調査し、その時点の結果と新しい見込み時刻を共有します。

報告時点で原因や解決策が確定している必要はありません。 確認済みの事実、現在の対応、次に報告する時刻 を分けて伝えます。

レビューを依頼するときは判断材料を渡す

Pull Requestや成果物だけを渡すと、レビュアーは目的と確認順を一から調べることになります。

GitHub Docsでは、Pull Requestへ背景、変更内容、レビューしてほしい点を示すことで、レビュアーが変更を理解しやすくなると説明しています。

## 目的

顧客一覧画面の表示崩れを修正します。

## 変更内容

- 一覧の幅指定を固定値から可変値へ変更
- 対象ブラウザの表示確認項目を追加

## 確認結果

- Chrome: OK
- Edge: OK
- 既存テスト: 24件成功

## レビューしてほしい点

- 画面幅が狭い場合の折り返し方に問題がないか
- 既存画面へ影響するCSS指定がないか

レビューで指摘を受けた場合は、理由と影響範囲を確認し、修正結果とテスト結果を添えて返します。

3週目は事実・推測・相談を分ける

自分で調べることは大切ですが、長時間抱え込むことが主体性ではありません。関係者が判断できる情報へ整理して相談することも、仕事を進める力です。

質問するときの形式

【やりたいこと】
検証環境から外部APIへ接続したい

【確認したこと】
DNS名前解決は成功しています。
443番ポートへの接続はタイムアウトします。

【未確認事項】
接続先の許可リストと、検証環境の送信元IPは未確認です。

【現時点の考え】
ネットワーク経路か、接続先の許可設定を確認する必要があると考えています。

【相談したいこと】
送信元IPの確認方法と、接続先担当への確認窓口を教えてください。

相談するタイミング

「30分調べたら必ず相談する」のような時間は、すべての現場に共通する規則ではありません。筆者は抱え込みを防ぐ目安として使いますが、次の場合は時間を待たずに共有します。

本番環境や顧客データへ影響する可能性がある
セキュリティ上の懸念がある
障害が発生している
期限やほかのメンバーの作業へ影響する
手順書と実際の環境が異なる

調査結果をチームの資産へ変える

一度解決した問題でも、記録がなければ別のメンバーが同じ調査を繰り返します。

最低限、次の内容をチケットや手順書へ残します。

項目	記録する内容
発生条件	いつ、どの環境で、何をすると起きたか
確認結果	ログ、エラー、画面、コマンドの結果
原因	確認できた原因。推測の場合は推測と書く
対応	変更した設定、コード、手順
確認方法	対応後に何を確認したか
残課題	今回対応しなかった範囲と次の担当

記録は長さより、次の人が同じ条件を再現し、結果を確認できることを優先します。顧客情報、秘密情報、認証情報は残さず、現場の情報管理ルールに従ってください。

4週目は30日間の成果と期待値を確認する

30日目は、自分だけで評価を決める日ではありません。認識している役割と、現場が期待している役割にずれがないかを確認するタイミングです。

振り返りメモ

【担当したこと】
- 問い合わせ調査 5件
- 画面改修 2件
- 手順書更新 1件

【できるようになったこと】
- 開発環境での調査からPull Request作成まで
- 障害時のログ確認と一次報告

【まだ支援が必要なこと】
- 本番作業の変更手順
- 外部ベンダーとの確認方法

【改善したいこと】
- 見積もり時にテスト時間を含める
- 調査の途中経過を早めに共有する

【次の30日で担当したいこと】
- 小規模改修を一人で完了まで進める
- 既存の運用手順を一つ改善する

件数だけを成果にすると、難易度やチームへの貢献が見えません。担当した作業に加えて、問題を早く共有したこと、手順を残したこと、レビューで改善したことも整理します。

毎日と毎週の確認リズム

タイミング	確認すること
始業時	今日の優先順位、期限、待ちになっている作業
作業前	目的、対象範囲、完了条件、確認方法
作業中	問題、遅延の兆候、追加で必要な情報
完了時	実施内容、確認結果、残課題、記録先
週末	今週できたこと、繰り返した問題、来週の優先事項

毎日の報告方法や頻度は、現場のルールに合わせます。報告を増やすこと自体が目的ではなく、関係者が状況を判断できることが目的です。

信頼を急ぐほど避けたい行動

避けたい行動	起こりやすい問題	代わりに行うこと
分からないまま作業を始める	目的と違う成果物になる	完了条件と確認方法を先に聞く
遅れを解決してから報告する	対応を選べる時間がなくなる	遅れる可能性が出た時点で共有する
大きな変更をまとめて出す	レビューと手戻りが大きくなる	確認できる小さな単位へ分ける
分かったふりをする	誤った前提で判断が進む	確認済み、推測、未確認を分ける
現場の依頼を一人で抱える	残業や負荷が増え続ける	負荷が高くなりそうな時点で相談する
認証情報を個人メモへ残す	情報漏えいにつながる	承認された保管方法だけを使う

現場から追加作業を依頼されたとき、すぐに応えたい気持ちは自然です。ただし、現在の作業や期限に影響する場合、残業が増えそうな場合、継続的な役割になりそうな場合は、一人で抱えず現場の責任者や所属会社へ共有してください。

30日目のチェックリスト

チームの目的と自分の役割を説明できる
作業の完了条件を確認してから着手している
通常時と緊急時の相談先を把握している
遅れや問題の兆候を早めに共有できる
確認済みの事実と推測を分けて報告できる
小さな単位でレビューを依頼できる
調査結果を再利用できる場所へ残している
現場のセキュリティルールを守っている
負荷や残業が増えそうなときに相談できる
次の30日で伸ばすことを一つ決めている

参考資料

以下の資料は、2026年8月18日に内容を確認しました。

まとめ

最初の30日で重要なのは、目立つことではなく、確認、報告、記録、レビューを安定して続けることです。

1〜3日目は仕事の地図を作り、1週目は小さな作業を完了させます。2週目は報告とレビューを安定させ、3週目は調査結果を整理して相談できる範囲を広げます。4週目には成果と課題を振り返り、次に期待される役割を確認します。

この積み重ねが、安心して次の仕事を任せてもらう土台になります。

おわりに

参画直後は大きな成果を急がず、まず一つの作業で、目的確認、途中報告、レビュー、完了報告までを通してみてください。同じ進め方を繰り返せるようになると、担当できる範囲を無理なく広げられます。

Wealthy Designでは、エンジニアが現場で力を発揮し、継続して成長できる会社づくりに取り組んでいます。会社の取り組みや採用情報は、会社サイトにまとめています。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up