はじめに

SESの現場では、技術力だけでなく、報告、確認、問題解析の進め方が信頼に直結します。

特に障害調査や疎通確認では、次のような動き方をすると一気に危なくなります。

事実と推測を混ぜて報告する
確認していないことを、確認済みのように伝える
重要な前提を後から出す
作業ログを残さない
目的を理解せず、言われた作業だけを進める
分からないことを「分からない」と言えない

この記事では、特定の誰かを責める話ではなく、SES現場で避けたい仕事の進め方と、信頼を失わないための報告・確認・問題解析の型を整理します。

この記事でわかること

SES現場で信頼を失いやすい報告のパターン
事実、推測、未確認事項の分け方
疎通確認や障害調査で最低限残す作業ログ
外部ベンダー確認を記録するときの観点
そのまま使える報告フォーマット

先に結論

SES現場で一番避けたいのは、分からないことがある状態そのものではありません。

避けるべきなのは、 分からないまま進めること、憶測を事実のように報告すること、確認した内容を記録に残さないこと です。

やってはいけないこと	代わりにやること
憶測で報告する	確認済みの事実、推測、未確認事項を分ける
報告内容を理由なく変える	前回報告との差分と、変わった理由を添える
重要な情報を後から出す	作業前提、実施内容、確認結果を最初から記録する
目的を理解せずに動く	何を、なぜ、どの条件で確認するかを先に確認する
外部ベンダー確認を口頭だけで済ませる	誰が、いつ、何を、どう回答したかを残す
分からないことを隠す	「未確認です」「判断に自信がありません」と早く共有する
条件を揃えずに確認する	送信元、宛先、ポート、時間、環境を揃えて切り分ける

技術力が高くても、報告が不安定だと周囲は判断できません。
信頼される人は、問題を一人で抱え込む人ではなく、関係者が判断できる形で状況を見えるようにする人です。

前提

対象読者: SES現場に参画する新人、若手、障害調査や疎通確認に関わるエンジニア
想定場面: 障害調査、疎通確認、ベンダー確認、運用保守、作業報告、顧客報告前の社内整理
扱う範囲: 報告、確認、作業ログ、問題切り分け、外部確認の記録
扱わない範囲: 個別案件の責任追及、契約判断、法務判断、顧客固有の障害対応手順
確認日: 2026-08-08

この記事では、SESを「外部の開発・インフラ現場に参画し、チームの一員として技術支援を行う働き方」として扱います。
実際の障害対応では、現場の報告ルール、エスカレーションルール、顧客手順を必ず優先してください。

用語の短い説明

用語	短い説明
事実	ログ、コマンド結果、画面、チケット、回答記録などで確認できること
推測	事実から考えられる可能性。まだ確認済みではないこと
未確認事項	まだ見ていないこと、回答待ちのこと、条件が揃っていないこと
疎通確認	ある端末やサーバーから、別の宛先へ通信できるか確認すること
切り分け	問題の原因範囲を、条件を揃えながら少しずつ狭めること
外部ベンダー	ネットワーク、クラウド、製品、回線などを提供・運用している外部の会社や担当者

信頼を失いやすい報告パターン

現場で信頼を失いやすいのは、技術的に分からないことがある場合だけではありません。
むしろ、分からないことの扱い方が悪いときです。

NGパターン	なぜ危ないか
「たぶんDNSです」と断定に近い言い方をする	事実ではない内容が顧客報告に混ざる
「さっきはできていました」と曖昧に言う	いつ、どこから、何を確認したか追えない
「ベンダー側の問題です」と言い切る	外部確認前なら責任範囲を誤って伝える可能性がある
報告内容が何度も変わる	どの情報を信じればよいか分からなくなる
作業ログがない	再確認、引き継ぎ、原因整理ができない
分からないことを隠す	問題が小さいうちに止められない

顧客報告に出る前の社内整理でも、憶測を事実のように話さないことが大切です。
社内で混ざった情報は、そのまま外部への誤報告につながることがあります。

事実・推測・未確認事項を分ける

問題解析では、まず情報を3つに分けます。

区分	書き方	例
事実	実際に確認できたことだけを書く	`AサーバーからBサーバーの443番ポートへ接続できない`
推測	可能性として考えていることを書く	`FWまたは経路設定の影響がある可能性がある`
未確認事項	まだ見ていないことを書く	`外部ベンダー側の許可設定は未確認`

この3つを分けるだけで、報告の質はかなり上がります。

NG報告例

例

たぶんDNSの問題だと思います。
ベンダー側で問題がありそうです。
先ほど確認したときは疎通できていた気がします。

この報告では、何が事実で、何が推測で、何が未確認なのか分かりません。
受け取った側も、次に何を判断すればよいか分からなくなります。

OK報告例

例

現時点で確認できている事実は、AサーバーからBサーバーの443番ポートに接続できないことです。
DNS名前解決は成功しています。
ただし、外部ベンダー側のFW設定は未確認です。
次に、ベンダーへ送信元IPと宛先ポートの許可状況を確認します。

この形なら、確認済みの事実、未確認事項、次のアクションが分かります。

作業前に目的を確認する

作業に入る前に、次の3つを確認します。

確認すること	理由
何を確認するのか	作業の対象を間違えないため
なぜ確認するのか	目的に合わない確認を避けるため
成功条件は何か	何をもって「できた」と言えるかを揃えるため

例えば「疎通確認してください」と言われた場合でも、確認すべき内容は1つではありません。

送信元はどこか
宛先はどこか
ポート番号は何か
プロトコルはTCPかUDPか
確認する時間帯はいつか
どの環境で確認するのか
成功条件は接続成功か、HTTPステータス確認か、アプリ応答確認か

目的を確認しないまま動くと、「作業はしたが、必要な確認になっていない」という状態になります。

条件を揃えて問題を切り分ける

問題解析では、条件を揃えずに確認すると原因が分かりにくくなります。

疎通確認なら、最低限次を揃えます。

観点	例
送信元	`10.0.1.10`、Aサーバー、検証端末
宛先	`example.internal`、Bサーバー、外部API
ポート	`443`、`22`、`3306`
プロトコル	TCP、UDP、HTTP、HTTPS
時間	`2026-08-08 10:15 JST`
環境	本番、検証、ステージング
結果	成功、タイムアウト、名前解決失敗、認証失敗

「何となくつながらない」ではなく、条件をそろえて「どの条件で失敗したか」を残します。

作業ログを必ず残す

作業ログは、自分を守るためだけのものではありません。
チームが状況を引き継ぎ、顧客へ正しく説明し、次の対応を判断するための材料です。

最低限、次を残します。

項目	内容
日時	いつ確認したか
実施者	誰が確認したか
対象	どのサーバー、URL、ポート、チケットか
確認方法	コマンド、画面、ログ、ベンダー回答など
結果	成功、失敗、エラー内容
解釈	事実から何が言えそうか
未確認事項	まだ見ていないこと
次のアクション	誰が、何を、いつまでに確認するか

作業ログテンプレート

work-log-template.md

## 作業ログ

### 基本情報
- 日時: 2026-08-08 10:15 JST
- 実施者: 自分の名前
- 対象: Aサーバー -> Bサーバー
- 目的: AサーバーからBサーバーの443番ポートへ接続できるか確認する

### 確認条件
<!-- 条件を揃えないと、あとから同じ確認を再現できない -->
- 送信元: 10.0.1.10
- 宛先: b-server.example.internal
- ポート: 443
- プロトコル: TCP
- 環境: 検証環境

### 確認結果
<!-- コマンド結果や画面結果を、事実として残す -->
- DNS名前解決: 成功
- 443番ポート接続: タイムアウト
- アプリ応答: 未確認

### 推測
<!-- 事実と混ぜず、可能性として書く -->
- FW、セキュリティグループ、経路設定のいずれかで遮断されている可能性がある。

### 未確認事項
<!-- 次に見るべきことを明確にする -->
- 外部ベンダー側の許可設定
- Bサーバー側の待ち受け状態
- 同時間帯のネットワーク変更有無

### 次のアクション
<!-- 誰が何をいつまでに確認するかを書く -->
- 11:00までに外部ベンダーへ送信元IPと宛先ポートの許可状況を確認する。

作業ログにパスワード、アクセストークン、個人情報、顧客名、契約情報などを書かないでください。
必要な場合は、現場で定められた安全な管理場所に分けて保管します。

報告内容を変えるときは理由を添える

調査が進むと、最初の見立てが変わることはあります。
見立てが変わること自体は悪くありません。

問題は、理由を説明せずに報告内容だけが変わることです。

悪い変え方

例

さっきはDNSと言いましたが、やっぱりベンダー側っぽいです。

良い変え方

例

前回はDNSの可能性があると共有しました。
その後、Aサーバーから宛先FQDNの名前解決が成功していることを確認しました。
そのため、現時点ではDNSよりも、443番ポートの通信経路または許可設定を優先して確認します。

前回との差分、追加で確認した事実、見立てを変えた理由。
この3つを添えると、報告の信頼性が保ちやすくなります。

外部ベンダーとの確認は記録する

外部ベンダーとの確認は、口頭だけで終わらせると危険です。

誰に確認したのか
いつ確認したのか
何を質問したのか
どのような回答だったのか
回答の前提条件は何か
次に誰が何をするのか

これらを残しておかないと、あとから確認内容を説明できません。

ベンダー確認メモの例

vendor-confirmation-note.md

## 外部ベンダー確認メモ

### 確認日時
2026-08-08 11:20 JST

### 確認先
<!-- 個人名を公開記事や不要な共有範囲に出さない。社内記録では現場ルールに従う -->
ネットワーク運用ベンダー 担当窓口

### 質問内容
<!-- 質問が曖昧だと回答も曖昧になる -->
送信元 `10.0.1.10` から宛先 `b-server.example.internal` のTCP 443番ポートが許可されているか確認したいです。

### 回答内容
<!-- 事実として受け取った回答をそのまま残す -->
ベンダー側FWでは、該当の送信元IPから宛先443番ポートの許可設定は登録済みとの回答。

### 未確認事項
<!-- 回答だけで原因確定にしない -->
許可設定の反映時刻、ログ上の許可/拒否結果は未確認。

### 次のアクション
ベンダー側ログで、10:00〜11:30の通信が許可または拒否されているか確認を依頼する。

外部確認は、責任を押しつけるためではありません。
関係者が同じ事実を見て、次の判断をしやすくするために記録します。

分からないことは早く言う

SES現場では、「分かりません」と言うことを怖がる人がいます。

しかし、分からないことを隠して憶測で進める方が大きな問題です。

使いやすい言い方は、次のような形です。

例

現時点では原因を特定できていません。
確認済みの事実は○○です。
未確認なのは△△です。
次に□□を確認し、15時までに状況を共有します。

「分からない」で終わらせるのではなく、確認済み、未確認、次のアクションをセットで伝えます。

障害・疎通確認時の報告フォーマット

障害調査や疎通確認では、最低限この形で報告します。

trouble-report-template.md

## 目的
<!-- 何を確認するための作業かを書く -->
AサーバーからBサーバーの443番ポートへ接続できるか確認する。

## 現在の状況
<!-- 確認済みの事実だけを書く。推測はここに混ぜない -->
AサーバーからBサーバーの443番ポートへの接続がタイムアウトしている。
DNS名前解決は成功している。

## 実施した確認
<!-- いつ、どこで、どう確認したかを書く -->
- 日時: 2026-08-08 10:15 JST
- 対象: Aサーバー -> Bサーバー
- 確認方法: 名前解決確認、TCP 443番ポートの接続確認
- 結果: 名前解決は成功、TCP接続はタイムアウト

## 未確認事項
<!-- まだ確認できていないことを書く -->
- 外部ベンダー側FWの許可設定
- Bサーバー側の待ち受け状態
- 同時間帯の経路変更有無

## 推測
<!-- 事実とは分けて、可能性として書く -->
FW、セキュリティグループ、経路設定のいずれかで通信が遮断されている可能性がある。

## 次のアクション
<!-- 誰が、何を、いつまでに確認するかを書く -->
11:00までに外部ベンダーへ、送信元IPと宛先ポートの許可状況を確認する。

## 支援が必要なこと
<!-- 自分だけで判断できない点を書く -->
ベンダー回答後、通信経路側のログ確認を進めてよいか判断をお願いします。

このフォーマットを使うと、報告を受けた人が「何が分かっていて、何が分かっていないか」を判断しやすくなります。

顧客報告前のセルフチェック

顧客や外部へ報告する前に、次を確認します。

事実と推測を分けている
未確認事項を隠していない
前回報告と変わった点がある場合、理由を書いている
作業日時、対象、確認方法、結果がある
外部ベンダー確認の記録がある
顧客名、個人情報、Secret、社内事情を書いていない
誰が、何を、いつまでに行うかが明確
自分だけで判断できない点を相談している

このチェックは、若手だけでなく、経験者にも有効です。
忙しいときほど、報告の型に戻ることで事故を減らせます。

まとめ

SES現場における報告・確認・問題解析では、次の行動が重要です。

事実、推測、未確認事項を分けて報告する
作業前に目的、確認条件、成功条件をそろえる
作業ログを残し、あとから説明できる状態にする
報告内容を変えるときは、変わった理由を添える
外部ベンダー確認は、口頭で終わらせず記録する
分からないことは早く共有し、次の確認を明確にする

分からないことがあるのは問題ではありません。
問題なのは、分からないことを隠し、憶測を事実のように扱い、関係者が判断できない状態にしてしまうことです。

参考・確認先

確認日: 2026-08-08
この記事は、SES現場での報告・確認・問題解析の進め方を一般化したものです。
個別案件の障害対応では、顧客手順、現場のエスカレーションルール、契約上の公開範囲を優先してください。

おわりに

報告・確認・問題解析は、性格や経験だけに任せるものではありません。
型を決めておくと、問題が起きたときでも、関係者が同じ事実を見て判断しやすくなります。

Wealthy Designでは、エンジニアが現場で安心して力を出せるように、技術教育と現場での動き方の言語化にも取り組んでいます。

会社の取り組みは、会社サイトにまとめています。

AWS・Web開発・AI活用のご相談や、採用・カジュアル面談については、Wealthy Design公式LINEでもお問い合わせいただけます。