【実録】ITインフラ担当が依頼を受けたら「最初の半日」で確認すべき6つのこと〜致命的な事故を防ぐチェックリスト〜

はじめに

ITインフラの現場では、一行のコマンド、一つの設定変更がサービス全体の運命を左右します。アプリケーションエンジニアや顧客から「これお願い」と依頼が来た際、すぐに作業の準備に取り掛かっていませんか？

実は、作業そのものよりも「着手前のヒアリング」にこそ、インフラエンジニアの命運がかかっていると言っても過言ではありません。

本記事は、日々アプリチームや顧客からの依頼に追われ、『作業ミスが怖い』『認識齟齬でいつも苦労している』というインフラエンジニアの方に向けて書いています。

今回は、私が過去に数々の冷や汗をかきながら学んだ、「依頼を受けた直後（遅くとも半日以内）に、文面で確認すべき6つの必須項目」を、恥を忍んで失敗談とともに紹介します。

インフラ作業は人と人とのやり取りです。認識に齟齬があれば、最悪の場合、サービス停止という致命的な事故を招きます。
「わかっているはず」を捨て、「言語化して合意する」ことが、自分とシステムを守る唯一の手段です。

依頼内容（What）だけを聞くのではなく、その裏にある目的（Why）を確認します。

「どの環境の、どのリソースか」「本番環境（Production）か、検証環境（Staging）か」など、一文字の疑いもなく特定します。
相手によっては、ホスト名だけでなくIPアドレスやURLなど、客観的に一意に特定できる情報を文面に含めるようにしましょう。

確認する理由: 対象の取り違えは即事故に繋がります。例えるなら、「リフォームを依頼された古い空き家と間違えて、隣の新築の家を解体してしまう」ようなものです。
私の失敗談:「開発中のECサイトの調子がおかしいからDBを再起動して」と言われ、確認せずに作業。しかし、実はその時操作していたのは「本番環境」のコンソールでした。結果、1時間のサービス停止と数十万円の機会損失。ホスト名を一言確認するだけで防げた事故でした。

単に「いつまで」だけでなく「なぜその日なのか」まで踏み込みます。

確認する理由: 理由を知ることで、優先順位の調整や、周囲への協力要請が必要かどうかの判断材料になります。
私の失敗談: 期限が書かれていない依頼を「急ぎじゃないだろう」と勝手に判断し、3日後に着手。しかし、実は翌日のプロモーションに必須の設定だったことが判明し、大クレームに。勝手な推測は最大の敵です。

依頼内容をざっと確認し、完了までに必要なステップを洗い出します。

工数を見積もる際は、『バッファ（余裕）』を含めた時間を考えるのがコツです。
例えば1時間で終わる作業も、切り戻し（ロールバック）の可能性を考慮して1.5時間〜2時間と伝えておくと、万が一の際も焦らずに対応できます

確認する理由: 「自分の作業時間」だけでなく「他部署への依頼」や「承認待ち」の時間を早期に見積もるためです。
私の失敗談: 納期3日前に着手したところ、他部署の firewall 変更が必要だと判明。その部署の申請ルールは「5営業日前」。どう足掻いても納期に間に合わず、プロジェクトの足止めをしてしまいました。

作業によって「誰に」「何が」起きるかを、相手の言葉で伝えます。

確認する理由: 「Apacheを止めます」と言っても、非インフラ担当にはリスクが伝わりません。
OKな伝え方の例:
- 「Apacheを再起動するため、Webサイトが1分間閲覧不可になります」
- 「LBで切り離すのでサービス停止はありませんが、一時的にサーバーの負荷耐性が半分になります（縮退運転）」

最終的な日時の確定の前に、大枠のスケジュール感・タイミングを合意します。

確認する理由: 「影響があるなら深夜、ないなら平日日中」といった体制構築が必要だからです。
私の失敗談: 「不要になった機器の停止」の依頼。期限は1週間後。「今のうちにやっておこう」と即座に停止したところ、実は撤去作業は3日後まで待つ必要があり、利用中の本番機器を止めてしまうという大失態を演じました。

これら6項目を、口頭だけでなく必ずチケットやチャット、メールなどの「文面」で残してください。

「ちょっと細かすぎるかな？」と思うくらいが、インフラエンジニアとしてはちょうど良いのです。最初の半日のコミュニケーションが、その後の安心安全を守ってくれます。

インフラエンジニアは「疑う」のが仕事です。
「多分大丈夫だろう」を捨て、「本当にこれで合っていますか？」と優しく疑うこと。それが、あなたと、あなたのシステムを守る最大の防御策です。

インフラエンジニアは、技術力と同じくらい『聞く力』が武器になります。
筆者自身まだまだ力不足を日々痛感しているので、これからもヒアリング力を向上したい所存です。