インフラエンジニアのための設計書入門【基本設計編】〜「何を」作るかの骨格を固める〜

みなさんはシステムの設計書というと何を思い浮かべますか？

ソフトウェアのインストール情報や複雑なパラメータなどが詳細に記載されたドキュメントを想像するのではないでしょうか。

例えば建物の設計図など、設計書というと詳細な情報が記載されている書類というイメージがあると思います。たしかに、実際のサーバなどに設定されたパラメータについてもドキュメントで管理していますが、もう一つ、重要なドキュメントがあります。

それは、そもそもシステムの構築方針や制限事項などが記載されている「基本設計書」です。

今回は、設計の第一段階である「基本設計書」について、その重要性と決めるべきポイントを解説します。

はじめて設計書を読む場合に気をつけること、システムの詳細な設定を記載した詳細設定書に興味のある方は、以下の記事もチェックしてみてください。

📢 現場で使える「インフラ設計書 完全版」を公開しました

ネットに転がっている無料のテンプレートを見て、「項目がスカスカで実務で使えない…」と頭を抱えた経験はありませんか？

そんな若手・中堅エンジニアの方や、チームの標準化に悩むリーダー向けに、私が大規模システムの運用経験をすべて詰め込んだ「インフラ基本設計書＆詳細設計書（パラメータシート全19シート）」のリアルな実例入りテンプレートを有料記事として、Noteでリリースしました。

構築だけでなく、セキュリティ監査、障害初動、EOSLまでを見据えた「現場のプロの思考」がそのままデータになっています。購入者は記事内からテンプレートをダウンロードいただけます。

まずは、無料部分だけでも読んでみてください！

基本設計書とは

インフラ構築における設計書は、建築でいうところの「設計図」です。

もし設計図なしに家を建て始めたら、途中で「やっぱりトイレはここがいい」「実は3階建てにしたかった」と言われても、土台から作り直すことになり（手戻り）、莫大な時間とコストが無駄になります。

インフラも同じことが言えます。設計書がないと以下のようなトラブルが必ず起きます。

• 「言った・言わない」の対立： 顧客やアプリ担当者との認識がズレる。
• 行き当たりばったりの設定： 構築の途中で「あ、このセグメントじゃ足りない」と気づき、最初からやり直す。
• 将来の負債： 構成がバラバラで、後から拡張やトラブルシューティングができない。

これらを防ぐために、まずは「どんなインフラを作るのか」という方針を文書化して合意を得る必要があります。それが基本設計の役割なのです。

基本設計の目的： 「何を作るか（What）」を定義する

基本設計の主な目的は、「顧客や他チーム（アプリ開発者など）と、インフラの完成イメージを握ること」です。

ここでは「IPアドレスを何にするか」といった細かい数字はまだ必要ありません。それよりも「クラウドを使うのか」「絶対に止めてはいけないのか」といった、システムの骨格を決めていきます。

基本設計では、細かな数値よりも『絶対に止めてはいけないのか』といった骨格を決めます。これらの指針を漏れなく洗い出すためのヒアリング術については、こちらの記事（「非機能要件」ヒアリングの極意）を参考にしてください

3. インフラ基本設計書で決めるべき「5つの柱」

一般的に、基本設計書には以下の要素が含まれます。

① システム構成・プラットフォーム設計

オンプレミスかクラウドかといった基盤の選定と、ネットワークの論理構成を定義します。

• 全体構成図： サーバー、ネットワーク機器、ストレージの繋がりを俯瞰。
• ネットワーク分離： 本番・開発・管理用などのセグメント分けの方針。

基本設計では、細かな数値よりも『絶対に止めてはいけないのか』といった骨格を決めます。これらの指針を漏れなく洗い出すためのヒアリング術については、こちらの記事（「非機能要件」ヒアリングの極意）を参考にしてください

② 可用性・災害対策（BCP/DR）設計

システムがどれだけ止まらずに動くか、そして災害時にどう対応するかを定義します。ここで重要な指標となるのが RTO と RPO です。

• RPO（目標復旧時点）： 「いつの時点のデータまで戻すか」。前日のバックアップでよければ24時間、一瞬の欠損も許されないならリアルタイム同期が必要です。
• RTO（目標復旧時間）： 「障害発生から何時間で復旧させるか」。1時間以内なのか、1日以内なのかを合意します。
• BCP（事業継続計画）： データセンターが被災した際、遠隔地の拠点に切り替えて業務を継続する仕組み（DR：ディザスタリカバリ）を検討します。

③ バックアップ・リストア設計

データの「最後の砦」をどう守るかの方針を決めます。

• バックアップ方式： フル、差分、増分の組み合わせ。
• 取得・保管方針： 保存期間（例：30日分）、世代数、保管場所（別サイト、クラウドなど）。
• リストア方式： 単なる取得手順だけでなく、「誰が、どのような判断で、どの手順でデータを戻すか」という復旧の道筋を定義します。

④ ログ取得・管理方針

トラブル時の原因究明や、不正アクセスの証拠（監査）として、ログをどう扱うかを決めます。

• 取得対象： OS（Syslog/EventLog）、ミドルウェア、ネットワーク機器の通信ログなど。
• 保管方針： サーバー内に置くのか、専用のログ管理サーバーに集約するのか。
• 保存期間： 法的要件やセキュリティポリシーに基づき、「1年間保管」「5年間保管」といった期間を定めます。

⑤ 監視・メンテナンス設計

「正常に動いていること」をどう確認し、異常をどう検知するかを定義します。

• 監視方針：
  • 死活監視（Ping）： 機器が動いているか。
  • リソース監視（CPU/メモリ/ディスク）： 性能に余裕があるか。
  • サービス監視（HTTP/DB）： アプリケーションが応答しているか。
  • ログ監視（Syslog/EventLog）： システムログに出力される「Error」「Critical」といった特定のキーワードをリアルタイムに検知し、重大な障害の予兆を捉えるか。
• 通知方針： 異常検知時に誰にメールやチャットを送るか。
• 保守方針： 定期的なパッチ適用（アップデート）や再起動の運用ルール。

サーバー、ネットワーク機器、ストレージが、論理的にどう繋がっているかを示す図です。これが「設計書の顔」となり、関係者全員が同じ完成イメージを持つための重要な地図になります。

基本設計の「読者」は誰か？

ここが重要なポイントですが、基本設計書の主な読者は「構築担当者だけではない」ということです。

• お客様・PM： 要件（やりたいこと）が満たされているかを確認する。
• アプリ開発者： インフラがアプリの動作条件を満たしているかを確認する。

そのため、専門用語ばかりを羅列するのではなく、「なぜこの構成にしたのか」という理由・意図を論理的に説明することが求められます。

まとめ：基本設計は「合意」のプロセス

基本設計は、技術的な作業というよりも、関係者全員の「認識のズレをなくす作業」です。

強固な「骨格（基本設計）」があって初めて、その後の具体的な「数値（詳細設計）」が決まります。まずは「何を作るべきか」という全体像をドキュメントに落とし込むことから始めましょう。

---

インフラエンジニアについて、興味はありませんか。インフラエンジニアの一日の流れに興味のある方は、以下の記事もチェックしてみてください。