評価されるインフラエンジニアのドキュメント作成術｜設計書・手順書・障害報告書の書き方
現場実践｜インフラドキュメント作成術
評価されるインフラエンジニアのドキュメント作成術｜設計書・手順書・障害報告書の書き方
「ドキュメントを書くのが苦手」「手順書を書いても他の人が理解できない」——インフラエンジニアが現場で評価される設計書・手順書・障害報告書（ポストモーテム）の書き方と構成を解説します。
💡 ドキュメントの質はエンジニアの評価に直結します。「同じ障害を繰り返さない」「新人でも手順通りに作業できる」ドキュメントを書けるエンジニアは現場で非常に重宝されます。
1. 手順書（オペレーション手順）の書き方
1
目的・対象・前提条件を冒頭に書く
「この手順書でできること」「対象サーバー・環境」「実行前に確認すべき前提条件」を必ず冒頭に記載する。読み手がいきなり手順を実行する前に状況を把握できるようにする。
2
コマンドは実行例とそのまま使えるよう記述
「サービスを再起動する」ではなく「sudo systemctl restart nginx」と実行可能なコマンドをコピー＆ペーストできる形で記述する。変数部分は【サーバーIP】のように明示する。
3
実行結果の確認方法も書く
コマンドの次に「実行後は以下のように表示されることを確認する」と期待される出力例を記載する。「成功したかどうか分からない」という状況を防ぐ。
4
ロールバック手順を必ず記載
「作業が失敗した場合の戻し方」を必ず記載する。本番作業では「作業できない→ロールバックもできない」という状況が最悪なケース。
2. 障害報告書（ポストモーテム）の構成
📋 ポストモーテムの標準構成
1. インシデントサマリー：発生日時・影響範囲・解決日時・重大度
2. タイムライン：検知→対応開始→原因特定→解決の時系列
3. 根本原因（Root Cause）：なぜ発生したか（5Whyで深掘り）
4. 影響：ユーザー数・ダウンタイム・ビジネス影響
5. 再発防止策：技術的な対策と期限・担当者を明記
3. 設計書に必ず含めるべき要素
- 構成図（ネットワーク図）：draw.ioやLucidchartで視覚的に表現する。テキストだけの設計書は読まれない
- 設計の根拠（Why）：「なぜその構成を選んだか」を記載する。後から見た人が「なぜこうなっているのか」を理解できる
- 非機能要件：可用性・セキュリティ・パフォーマンス・コストの要件と達成手段を記載する
📌 この記事のポイント
- 手順書は目的・前提条件・実行可能なコマンド・実行結果の確認・ロールバック手順の5点セットで書く
- ポストモーテムはサマリー→タイムライン→根本原因（5Why）→再発防止策の構成で書く
- 設計書には構成図・設計の根拠（Why）・非機能要件の3つを必ず含めることで後から読んでも理解できる
キャリアの疑問、一緒に解決しませんか？
Route Bloomでは、インフラ系ITエンジニアを目指す方への個別サポートを行っています。2026年7月からフリーランス講師として本格始動予定です。
ABOUT ME
