インフラエンジニアの詳細設計とは？基本設計との違いやパラメータシートの作り方を解説【前編】

はじめに
詳細設計とは
基本設計との違い
詳細設計で作成する成果物
詳細設計の中心となるパラメータシート
デフォルト値と設定値を記載する理由
全項目を記載する理由
前編のまとめ

はじめに

前回の記事では、インフラエンジニアが基本設計で実施する内容について解説しました。

基本設計では、要件定義で決定した内容をもとに、システム構成やネットワーク構成、サーバ構成、冗長化方式など、「どのようなシステムを構築するか」という設計方針を決定します。

しかし、基本設計だけではシステムを構築することはできません。

例えば、「Apacheを利用する」と決まっていても、httpd.confのどの設定を変更するのか、「Rocky Linuxを採用する」と決まっていても、sysctl.confやchrony.confにどのような設定を行うのかまでは決まっていません。

これらの具体的な設定内容を決定し、構築担当者が迷わず作業できるレベルまで設計を落とし込む工程が詳細設計です。

この記事では、インフラエンジニアが詳細設計で実施する内容や基本設計との違い、そして実際の現場で最も重要な成果物の一つであるパラメータシートについて解説します。

詳細設計とは

詳細設計とは、基本設計で決定した内容を、実際に構築できるレベルまで具体化する工程です。

基本設計では、「どのようなシステム構成にするのか」「どのような方式を採用するのか」といった設計方針を決定しました。

一方、詳細設計では、「どのファイルをどのように設定するのか」「各パラメータにどの値を設定するのか」を決定します。

例えば、基本設計で「NTPによる時刻同期を行う」と決まっている場合、詳細設計では次のような内容を決定します。

参照するNTPサーバ
chrony.confの設定内容
起動設定
同期確認方法

また、「Apacheを利用する」と決まっている場合は、

httpd.conf
ssl.conf
VirtualHost
ログ出力先
KeepAlive設定

などを具体的に設計します。

つまり、詳細設計は構築担当者への作業指示書とも言える工程です。

設計書を見ながら設定すれば、誰が構築しても同じ環境になることを目指します。

基本設計との違い

詳細設計を理解する上で重要なのが、基本設計との役割の違いです。

簡単に言えば、

基本設計は「何を採用するか」
詳細設計は「どのように設定するか」

を決める工程です。

例えば、DNSを例にすると違いは分かりやすくなります。

基本設計では、

DNSを利用する
Active Directory DNSを採用する
正引き・逆引きを実施する

という方針を決定します。

一方、詳細設計では、

ゾーン情報
Aレコード
PTRレコード
CNAME
TTL
フォワーダ設定

など、設定内容を決定します。

Apacheでも同様です。

基本設計では「Apacheを採用する」と決めますが、詳細設計ではhttpd.confやssl.confの設定内容を決定します。

Linuxであれば、

sysctl.conf
sshd_config
chrony.conf
/etc/fstab

など、各設定ファイルの内容まで設計します。

このように、構成を決めるのが基本設計、設定値を決めるのが詳細設計と考えると理解しやすいでしょう。

詳細設計で作成する成果物

詳細設計では、多くの設計書を作成しますが、その中心となるのがパラメータシートです。

一般的なプロジェクトでは、次のようなパラメータシートを作成します。

クラウド環境（AWS、Azureなど）
仮想基盤（VMwareなど）
OS
Webサーバ
APサーバ
データベース
監視
バックアップ
ジョブ管理
セキュリティ製品

例えばAWSであれば、

EC2
EBS
Security Group
IAM
Application Load Balancer
Route 53

などの設定内容を整理します。

VMwareでは、

vCPU
メモリ
データストア
Port Group
HA
DRS

などを設計します。

OSでは、

ホスト名
IPアドレス
NTP
DNS
カーネルパラメータ
ユーザ
サービス設定

などが対象になります。

プロジェクトによって対象製品は異なりますが、目的は共通しています。

誰が構築しても同じ環境を再現できるようにすることです。

詳細設計の中心となるパラメータシート

詳細設計で最も重要な成果物がパラメータシートです。

現場では設計書よりも、パラメータシートを参照する機会の方が多いと言っても過言ではありません。

構築担当者はパラメータシートを見ながら設定を行い、テスト担当者はその内容が正しく設定されているかを確認します。

さらに、障害対応や保守作業では、「現在どのような設定になっているか」を確認するためにパラメータシートが利用されます。

つまり、パラメータシートは、

設計資料
構築資料
テスト資料
保守資料

という複数の役割を持っています。

そのため、設定値だけを書くだけではなく、「誰が見ても分かる設計書」であることが重要です。

デフォルト値と設定値を記載する理由

設計初心者が最も見落としやすいポイントが、デフォルト値を記載することです。

「変更した設定だけを書けばよいのではないか」と考える方も多いですが、実際の現場ではデフォルト値と設定値を並べて記載することが一般的です。

例えばApacheのKeepAliveを設定する場合、

パラメータ	デフォルト値	設定値
KeepAlive	On	Off

というように記載します。

もし設定値だけを書いてしまうと、

デフォルトから変更したのか
元々その値だったのか

を判断することができません。

レビュー担当者も、「どこを変更したのか」を確認するために設定ファイルを開く必要があり、レビュー効率が低下します。

また、数年後にシステム更改やバージョンアップを行う際にも、デフォルト値が記載されていれば、「当時どの設定を変更したのか」がすぐに分かります。

パラメータシートは構築時だけでなく、保守や更改でも利用されるため、変更内容が一目で分かるように作成することが重要です。

全項目を記載する理由

パラメータシートを作成する際に、もう一つ重要なのが全項目を記載することです。

設計経験が浅いと、「変更する項目だけを記載すれば十分ではないか」と考えがちです。

しかし、多くの現場では、変更する項目だけではなく、変更しない項目も含めてすべて記載します。

例えば、OSのカーネルパラメータやApacheの設定項目が数百個ある場合でも、基本的にはすべてを一覧化します。

その理由は、設計書を「システムの設定情報を管理する台帳」として利用するためです。

例えば障害調査で、

「この設定はどうなっていたか」

という確認が必要になった場合、変更項目しか記載されていない設計書では、実際のサーバへログインして設定ファイルを確認する必要があります。

一方、全項目が記載されていれば、設計書を見るだけで設定内容を確認できます。

また、レビュー時にも「記載漏れ」なのか「デフォルト値のまま」なのかを判断しやすくなり、認識違いを防ぐことができます。

一見すると手間がかかるように思えますが、構築・テスト・保守の効率を考えると、全項目を管理するメリットは非常に大きいと言えるでしょう。

前編のまとめ

詳細設計は、基本設計で決めた内容を、実際に構築できるレベルまで具体化する重要な工程です。

その中でも、パラメータシートは詳細設計の中心となる成果物であり、構築担当者だけでなく、レビュー担当者やテスト担当者、運用担当者まで多くの関係者が利用します。

また、品質の高いパラメータシートを作成するためには、

デフォルト値と設定値を並べて記載すること
変更した項目だけでなく、全項目を管理すること

が重要です。

後編では、さらに実践的な内容として、単体テストを意識したパラメータシートの作り方や、レビューでよく指摘されるポイント、現場で役立つ設計のコツについて詳しく解説します。