システム設計書の読み方・書き方完全ガイド｜新人インフラエンジニアが最短で成長する4ステップ

配属初日に手渡される、鈍器のような厚さのPDFファイルや、無数に並んだExcelシート。

「とりあえず今の作業に関係がありそうなパラメータシートから見よう」

その気持ち、痛いほど分かります。しかし、その読み方は「最も効率が悪く、かつ一生役に立たない」読み方かもしれません。

今回は、インフラ運用エンジニアとして「現場で本当に使える知識」を最短で身につけるための、システム設計書の攻略法を伝授します。

また、良い読み方をマスターすることは、そのまま「読みやすい設計書の書き方」を理解することにも繋がります。現場で「お、この設計書わかりやすいね」と言われるためのポイントも併せてお伝えします。

そもそも「設計書に何が書かれているべきか」という全体像を知りたい方は、先にこちらの記事をチェックしてみてください。

なぜ「パラメータシート」から読んではいけないのか？

多くの新人が、IPアドレスやホスト名が羅列された詳細設計書（パラメータシート）に真っ先に飛び込みます。しかし、ここには運用現場ならではの「大きな罠」が2つあります。

情報は「腐る」が、思想は「腐らない」

現場のパラメータシートは、往々にして更新が漏れています。「設計書にはAと書いてあるが、実機はBになっている」というのは、残念ながら珍しくありません。対して、「なぜこのシステムをこう作ったか」という設計思想や統一方針は、一度決まれば運用フェーズで変わることは滅多にありません。

「点」の知識は応用が効かない

「IPアドレスが192.168.1.10である」という知識は、その現場を離れればゴミになります。しかし、「なぜこのセグメントに配置し、どういう方針で採番したか」というルールを知れば、他のどんな現場でも通用する一生モノのスキルになります。

攻略の黄金ルート：全体から細部、論理から物理へ

設計書を1ページ目から読む必要はありません。以下の4ステップで、効率的に解像度を上げていきましょう。

ステップ1：システムの「外枠」と「規模感」を掴む

まずは対象のシステム全体を俯瞰します。

• プラットフォーム： クラウド（AWS/Azure等）か、オンプレミスか、その併用か。
• 環境構成： 本番、開発、検証、DR（災害復旧）環境がどう分かれているか。
• 規模感： サーバーは何台あるか。ストレージの容量は。ここを確認するだけで、「このシステムがどれくらい複雑か」という肌感覚が手に入ります。

ステップ2：「データの通り道」を把握する（論理構成）

システムの概要を掴んだら、次に、システムの中を流れるデータにフォーカスします。ユーザは最初にどのサーバへアクセスするのか。そのサーバはどこのデータを参照するのか。データや処理の流れを追うことで、システムの処理フローの全体像を把握することができます。

• エンドポイント： ユーザーの入り口はどこで、データはどこに保存されるか。
• 通信フロー： FW（ファイアウォール）やLB（ロードバランサー）をどう通過するか。
• 急所の把握： 「ここが壊れたらサービスが止まる」という単一障害点（SPOF）を見定めます。

ステップ3：レイヤーを「上から下へ」降りる

インフラエンジニアこそ、実は「アプリケーション」から順に読み解くべきなのです。

システムの価値はアプリケーションが提供します。そして、アプリケーションの処理はインフラが提供し、インフラの実態は物理（クラウド）が提供します。

そのため、まずはアプリケーションに着目し、インフラ、物理（クラウド）構成へと、視点を移動させ、それぞれのレベルごとに全体像を改めて把握します。

1. アプリケーション： 何を実現するためのシステムか。
2. ミドルウェア： Web、DB、キューなど、何を動かしているか。
3. OS： リソース（CPU/メモリ）の割り当て方針は。
4. ハードウェア： どのラックに配置され、どの物理ポートに刺さっているか。「何を支えるためのインフラなのか」を理解することで、設定値の重要度が変わって見えてきます。

ステップ4：詳細パラメータは最後にさっと目を通す

ようやく最後に詳細パラメータを確認します。ただし、このパラメータは、必要になった場合に詳細に確認すれば良く、最初に設計書を手にする際は、さっと一通りパラメータに目を通す程度で問題ありません。

インフラ運用の生命線「非機能要件」を狙い撃て！

運用のプロは、設計書の「非機能要件」を特に入念に確認します。ここには「どう動かし続けるか」という、運用のエッセンスが詰まっているからです。

項目	運用担当者がチェックすべき理由
可用性（Availability）	故障時にどう自動切り替え（フェイルオーバー）するかを知るため。
運用・保守性（Maintainability）	監視のしきい値や、バックアップの戻し方（リカバリ手順）を知るため。
セキュリティ（Security）	誰が、どの踏み台サーバーから、どの権限で作業できるかを知るため。
性能・拡張性（Performance）	アクセス急増時に、どうやってリソースを増設できるかを知るため。

特に「監視方針」と「バックアップ方針」、「冗長化方針」は、トラブル時にあなたの身を守る盾になります。真っ先に確認しましょう。

バックアップの基礎を知りたいからは以下の記事も確認してみてください。

逆転の発想！「読みやすい設計書」を書くための3つのコツ

ここまで「読み方」のコツを解説してきましたが、実は「良い読み手」になることは、「良い書き手」になるための最短ルートでもあります。

自分が設計書を読み解く際に苦労したポイントは、そのまま「他の人が書くときに改善してほしいポイント」だからです。現場で「この設計書、すごく助かる！」と評価されるための書き方のコツを3つに凝縮して紹介します。

パラメータには必ず「なぜ（Why）」を添える

詳細設計書（パラメータシート）を書く際、設定値だけを並べていませんか？ 読み手が本当に知りたいのは「なぜその値にしたのか」という意図です。

• NGな書き方： Timeout: 30s（値のみ）
• 喜ばれる書き方： Timeout: 30s（※アプリ側のリトライ処理が20sで走るため、重複を防ぐ意図で30sに設定）

このように、「設計上の根拠」や「制約事項」を備考欄に一言添えるだけで、運用フェーズでのトラブル対応のしやすさが劇的に変わります。

構成図に「データの通り道」を可視化する

ステップ2で解説した「論理構成」を、読み手に推測させてはいけません。構成図を作る際は、以下の要素を意識的に盛り込みましょう。

• 通信フローに番号を振る： 「①ユーザーアクセス → ②LBで振り分け → ③Webサーバ」と順序を書く。
• プロトコルとポート番号を明記： 矢印のそばに「HTTPS/443」などと記載する。

「図を見れば、パケットがどこを通ってどこで止まる可能性があるか一目でわかる」状態を目指すのが、プロの書き方です。

非機能要件を「運用シーン」と紐づけて具体化する

「可用性：99.9%」といったスペック上の数字だけでなく、「で、何が起きたらどうなるの？」という運用者の不安に応える内容を盛り込みます。

• 保守の視点： 「バックアップは〇時〜〇時の間に実行され、その間はスナップショット取得のため一時的にディスク負荷が上がる」
• 障害の視点： 「サーバAがダウンした場合、仮想IPがサーバBに30秒以内に切り替わる（その間、既存のセッションは切断される）」

このように「運用中に起こりうる事象」を先回りして書いておくことで、設計書は単なる「記録」から、現場を守る「武器」へと進化します。

まとめ：設計書は「答え」ではなく「意図」を拾うもの

設計書は、単なる設定値のメモ帳ではありません。「設計者が何を考えて、そのシステムを構築したか」という意図が詰まった地図です。

1. パラメータという「点」に飛びつかない。
2. 設計思想・統一方針という「線」をまず引く。
3. 非機能要件という「面」で、守り方を理解する。

この読み方を意識するだけで、半年後のあなたは「ただ値を調べる人」ではなく、システム全体の挙動を予測できるエンジニアへと成長しているはずです。

そして、それは、「伝わる設計書の書き方」が身についていることと同じです。まずは今日、手元の設計書の「目次」から読み解いてみてください。

まずは今日、あなたの手元にある設計書の「目次」を開いて、「バックアップ方針」や「冗長化方針」のページをじっくり読んでみてください。そのシステムの「作り手の意図」が、少しだけ見えてくるはずです。

---

設計書を読み解く力がつくと、大規模なシステム変更も自信を持って進められるようになります。

その代表的な実戦例が、仮想化基盤のライフサイクル管理です。18年の現場経験をもとにまとめたESXiアップデートの記事を参考に、設計書から得た知識を実際の運用現場でどう活用するかを学んでみてください。