※この記事は「詳細設計で決めること」3部作の前編です。後編①・後編②はnote（有料）で公開しています。
はじめに
基本設計では、要件をシステム構成、処理方式、運用方式に落とし込みます。
では、詳細設計では何をするのでしょうか。
詳細設計と聞くと、サーバのパラメータを決める、ミドルウェアの設定値を書く、クラウドサービスの設定項目を埋める、といったイメージを持つ人もいるかもしれません。
もちろん、それらは詳細設計の重要な要素です。
しかし、詳細設計は、単にパラメータ表を埋める工程ではありません。
基本設計で決めた方式を、実際に構築・設定・テスト・運用できる粒度まで落とし込む工程です。
たとえば、基本設計で「ログを1か月保持する」と決めたなら、詳細設計では、どのログファイルを対象にするのか、どのディレクトリに出力するのか、どの周期でローテーションするのか、圧縮するのか、何世代残すのか、バックアップ対象に含めるのか、容量監視をどうするのかまで具体化します。
基本設計で「7時までに業務を開局する」と決めたなら、詳細設計では、その運用要件をジョブ、スクリプト、監視、起動停止、開局前チェックに落とします。
どのジョブを何時に起動するのか。
どのスクリプトを実行するのか。
どの戻り値を正常とするのか。
終了遅延をどう検知するのか。
開局前チェックで何を確認するのか。
どの監視を再開するのか。
これは一見すると運用設計の話に見えます。
しかし、詳細設計では、この運用要件を実際の製品設定、ジョブ定義、スクリプト仕様、監視設定、手順書の粒度に落とします。ここで落とし込みが甘いと、運用試験や本番移行前に手戻りが発生します。
つまり、詳細設計とは、基本設計で決めた方針を、OS、ミドルウェア、DB、ジョブ、監視、バックアップ、クラウドサービス、運用スクリプト、手順、試験観点へ展開する工程です。
構築担当者が設定値を判断しなければならない。
テスト担当者が期待値を確認できない。
運用スクリプトが作られていない。
ジョブは定義されているが、異常時の分岐が分からない。
監視項目はあるが、閾値や通知先が決まっていない。
バックアップは設定されているが、リストア手順がない。
こうした問題は、詳細設計の時点で「構築できる粒度」「テストできる粒度」「運用できる粒度」まで落とし込めていないことから起きます。
この記事では、基盤SEの目線で、詳細設計で何を具体化するのかを整理します。
この記事で持ってほしい問い
詳細設計書を見るときは、設定値そのものだけを追ってはいけません。
ここで挙げる問いは、記事全体を通して持ってほしい視点です。
各章の末尾では、その領域ごとの確認観点を3つに絞って整理します。
この記事では、次の問いを持ちながら読んでください。
- この設定値は、基本設計のどの方針を受けているのか
- なぜこの値でよいと言えるのか
- 構築担当者が、この設計書を見て同じ設定を再現できるか
- テスト担当者が、期待値を判断できるか
- 運用担当者が、障害時に使える設計になっているか
- 監視、ログ、バックアップ、ジョブ、スクリプト、手順書とつながっているか
- この設計で品質を確保できると説明できるか
詳細設計は、設定値を埋める作業ではありません。
基本設計で決めた方式を、構築、テスト、運用、保守に接続し、「なぜこの設計でよいのか」を説明できる状態にする工程です。
この問いを持って読むと、詳細設計書の見え方が変わります。
詳細設計は基本設計の続きである
詳細設計は、基本設計と切り離された工程ではありません。
基本設計で決めた内容を、実際に構築・設定できるレベルに落とし込むのが詳細設計です。
基本設計では、たとえば次のようなことを決めます。
- システム構成
- 処理方式
- サーバ構成
- ネットワーク構成
- DB構成
- ストレージ方式
- ジョブ・バッチ方式
- 監視方式
- ログ方式
- バックアップ・リストア方式
- セキュリティ方式
- 運用方式
一方、詳細設計では、それらをより具体的な設定、パラメータ、ファイル、ジョブ、スクリプト、手順、テスト可能な期待値に落としていきます。
たとえば、基本設計で「Web/AP/DBの3層構成」と決めたなら、詳細設計では、各サーバのホスト名、IPアドレス、OS設定、導入ミドルウェア、待ち受けポート、接続先、タイムアウト、ログ出力先、起動停止順序を決めます。
基本設計で「監視する」と決めたなら、詳細設計では、監視対象、監視方式、監視間隔、閾値、検知条件、通知先、抑止条件、一次対応手順まで落とします。
基本設計で「バックアップを取得する」と決めたなら、詳細設計では、対象ファイル、対象DB、取得コマンド、実行ジョブ、取得時刻、世代数、保管先、削除条件、リストア手順、戻し先、確認方法まで落とします。
詳細設計は、基本設計で決めたことを「誰が見ても同じ構成で作れる状態」にするための工程です。
詳細設計を、構築担当者向けの設定メモにしてはいけません。
詳細設計書は、構築担当者だけのためにあるわけではありません。テスト担当者、運用担当者、レビュー担当者、障害対応者、後続保守担当者も参照します。
そのため、詳細設計では、単に設定値を書くのではなく、なぜその設定にしているのか、基本設計のどの方針を受けているのか、どのテストで確認するのか、運用上どの手順や監視とつながるのかを意識します。
詳細設計とパラメータ設計・環境定義
開発標準によっては、詳細設計、パラメータ設計、環境定義を分けて整理することがあります。
考え方としては、次のように整理できます。
詳細設計は、基本設計で決めた方式を、製品・ミドルウェア・クラウドサービスの設定や構築単位に落とし込む工程です。
パラメータ設計は、その中でも、OS、ミドルウェア、DB、ジョブ管理製品、監視製品、バックアップ製品、クラウドサービスなどの設定値を具体化する作業です。
環境定義は、実際に構築される環境ごとの設定値を一覧化する成果物です。
ただし、実務上は、詳細設計とパラメータ設計、環境定義を一体的に進めることも多くあります。特に基盤領域では、製品ごとの詳細設計書と、環境ごとのパラメータ一覧を合わせて管理することが一般的です。
ここで押さえるべきなのは、すべての製品パラメータを案件ごとにゼロから検証するわけではない、ということです。
OS、Web/APサーバ、DB、ジョブ管理、監視、バックアップ製品、クラウドサービスには、膨大な設定項目があります。これらをすべて個別に妥当性検証することは、現実的ではありません。
そのため、多くのプロジェクトでは、過去案件で実績のある標準構成や製品デフォルト値をベースにし、基本設計で定めた処理方式、性能要件、運用要件、セキュリティ要件に影響するパラメータを重点的に設計します。
「デフォルトだから見なくてよい」ではありません。
案件固有の要件に影響するパラメータを洗い出し、変更する項目については設定値と根拠を示します。
一方、変更しない項目についても、環境定義として値を明示しておくことで、構築後の確認、障害時の調査、後続保守で参照できる状態にしておきます。
詳細設計とは、全パラメータを網羅的に説明する工程ではありません。基本設計で決めた方式と、実際の製品設定・環境定義をつなぐ工程です。
詳細設計は品質保証ストーリーの一部である
詳細設計は、構築担当者のための設定表ではありません。
基本設計で決めた方式を、構築・テスト・運用へつなげることで、「なぜこの設計で品質を確保できると判断したのか」を説明する材料になります。
特に大規模プロジェクトでは、設計値やパラメータ値に対して、根拠を求められることがあります。
なぜこの値なのか。
なぜデフォルト値でよいのか。
なぜこの監視項目で足りるのか。
なぜこの試験で確認できたと言えるのか。
なぜこの構成で性能要件を満たすと判断したのか。
このとき、詳細設計書に設定値だけが並んでいても説明できません。
必要なのは、次の接続です。
- 基本設計で定めた方式
- 非機能要件
- 製品仕様
- 標準構成・過去実績
- 設定値の根拠
- テスト観点
- 監視・運用での確認方法
一方で、すべての製品パラメータやすべての操作パターンを案件ごとに完全検証することはできません。
製品内部の制御仕様、バージョン差分、特定条件でのみ発生する挙動まで、設計段階で完全に予見することは現実的ではありません。
たとえば、通常利用では問題が出ないものの、特定の処理タイミング、特定の負荷条件、特定の運用操作が重なった場合だけ、製品内部の制御仕様によって処理遅延やエラーが発生することがあります。
こうした事象は、要件や設計から自然に導けるものではなく、製品仕様、バージョン差分、既知不具合、過去事例に依存します。マニュアルやベンダー情報に明示されていなければ、設計段階で完全に予見することは困難です。
だからこそ、詳細設計では、次の項目を重点的に設計します。
- 基本設計で決めた処理方式に影響する項目
- 性能・可用性・運用・セキュリティに影響する項目
- 案件固有要件により変更する項目
- 過去実績や標準構成で注意点が分かっている項目
変更する項目には、設定値と根拠を残します。
変更しない項目については、製品デフォルト値または標準構成を採用し、環境定義として管理します。これは、すべてのデフォルト値を個別に検証したという意味ではありません。構築後の確認、障害時の調査、保守引継ぎのために、実際の設定状態を参照できるようにするためです。
テストも同じです。
テストは、見えない全パターンを無限に洗い出すものではありません。要件定義、基本設計、詳細設計で決めた内容に対して、Vモデルに沿って確認観点を展開するものです。
詳細設計で目指すべきなのは、トラブルゼロを保証することではありません。
要件と設計に基づいて、どこを重点的に設計し、どこを標準値として採用し、どこを試験で確認し、どこを運用監視で検知するのかを説明できる状態にすることです。
これが、詳細設計における品質保証ストーリーです。
詳細設計で見るべきなのは「設定値」ではなく「接続性」である
詳細設計というと、どうしても設定値に目が行きます。
OSのパラメータ。
ApacheやTomcatの設定。
DBの初期化パラメータ。
ジョブ管理製品のジョブ定義。
監視製品の閾値。
クラウドサービスの設定項目。
もちろん、これらは大事です。
しかし、詳細設計で見るべきなのは、設定値そのものだけではありません。
基本設計、構築、テスト、運用がつながっているかです。
たとえば、ログ設計であれば、以下がつながっている必要があります。
- 基本設計：ログを1か月保持する
- 詳細設計：logrotate設定、退避先、圧縮有無、世代数
- 構築：設定ファイルの配置、権限設定、反映
- テスト：ログローテーション確認、容量監視確認
- 運用：ログ確認手順、障害調査手順、バックアップ対象
このつながりがないと、詳細設計書は単なる設定一覧になります。
一見すると設計書は埋まっているのに、後工程で漏れます。
ログ保持期間は決まっているが、ローテーション設定がない。
ログ出力先は決まっているが、容量監視がない。
バックアップ対象に含まれていない。
障害時にどのログを見るのか手順書に書かれていない。
こうした漏れは、詳細設計の段階で「設定値を決めること」だけを目的にしていると起きます。
詳細設計で見るべきなのは、設定値が正しいかだけではありません。
その設定が、基本設計の方針とつながっているか。
構築手順に落ちるか。
テストで確認できるか。
運用手順や監視とつながるか。
障害時に使えるか。
ここまで見て初めて、詳細設計として成立します。
詳細設計は製品・ミドルウェア単位で分かれやすい
基本設計では、処理方式や運用方式の単位で設計することが多くあります。
一方、詳細設計では、製品・ミドルウェア・クラウドサービス単位で設計書が分かれることが多くなります。
たとえば、次のような詳細設計書です。
- OS詳細設計書
- Webサーバ詳細設計書
- APサーバ詳細設計書
- DB詳細設計書
- ジョブ詳細設計書
- バックアップ詳細設計書
- 監視詳細設計書
- ログ詳細設計書
- ストレージ詳細設計書
- ネットワーク詳細設計書
- セキュリティ詳細設計書
- 運用スクリプト設計書
- クラウドサービス詳細設計書
これは、詳細設計が実際の構築対象に近づくからです。
構築担当者は、OSを設定し、Webサーバを設定し、APサーバを設定し、DBを設定し、ジョブ管理製品にジョブを登録し、監視製品に監視項目を設定します。
そのため、詳細設計も自然と製品・ミドルウェア・クラウドサービス単位になります。
ただし、ここで注意が必要です。
製品単位で詳細設計書を分けると、設計対象を管理しやすくなる一方で、処理方式としてのつながりが見えにくくなることがあります。
たとえば、バックアップ方式は、DB詳細設計、ストレージ詳細設計、ジョブ詳細設計、監視詳細設計、運用スクリプト設計にまたがります。
ログ方式は、OS詳細設計、ミドルウェア詳細設計、監視詳細設計、バックアップ詳細設計にまたがります。
ジョブ方式は、ジョブ管理製品の詳細設計だけでなく、実行スクリプト、ログ出力、異常終了時の通知、運用手順、運転スケジュールにまたがります。
つまり、詳細設計では、製品単位で分けることと、処理方式として横断的につなぐことの両方が必要です。
ここを意識しないと、各詳細設計書は存在するのに、全体としてつながっていない状態になります。
ここまで、詳細設計の考え方を整理してきました。
ここから先は、基盤SEが実際に詳細設計で具体化する領域を、OS、Web/AP、DB、ジョブ、監視、ログ、バックアップ、セキュリティ、運用スクリプトに分けて見ていきます。
特に、ジョブ管理規約とスクリプトの戻り値設計、正常系だけで終わらせない単体試験、特権IDや本番作業統制の考え方は、現場でトラブルを起こしやすいポイントです。
詳細設計を「設定表作成」で終わらせず、構築・テスト・運用で使える成果物にするための具体論を整理します。
この先、後編①ではOS・Web/AP・DB・ジョブを、後編②では監視・ログ・バックアップ・セキュリティ・運用スクリプトを扱います。
– OS詳細設計で見るべき観点
– Web/APサーバ詳細設計で性能・運用とつなげる考え方
– DB詳細設計で性能・バックアップ・セキュリティをどう見るか
– ジョブ詳細設計で事故りやすい戻り値設計
– ジョブ管理規約とスクリプトのコーディング規約をそろえる理由
– 監視・ログ・バックアップ設計で後工程に漏れを出さない見方
– セキュリティ詳細設計を技術設定だけで終わらせない考え方
– 運用スクリプトの設計・試験で見落としやすいポイント
– 詳細設計でやってはいけないこと
「前編まとめ｜詳細設計の本質」
前編では、詳細設計を単なるパラメータ表ではなく、基本設計で決めた方式を構築・テスト・運用・保守へ接続する工程として整理しました。
設定値を埋めることではなく、基本設計、構築、テスト、運用がつながっているかを見ること。トラブルゼロを保証することではなく、どこを重点設計し、どこを試験で確認し、どこを運用監視で検知するかを説明できる状態にすること。
これが詳細設計の本質です。
その本質を踏まえて、詳細設計でやってはいけないことを4つ整理します。
基本設計とのつながりを見ない
詳細設計は、基本設計で決めた方式を具体化する工程です。基本設計との対応が見えない詳細設計は、ただの設定メモになります。
製品パラメータを埋めるだけで終わる
詳細設計では設定値を決めますが、それだけでは不十分です。構築、テスト、運用、障害対応までつながる粒度で設計します。
設定値の理由を書かない
なぜその値にしたのかが分からないと、レビューも保守もできません。推奨値なのか、性能要件から決めたのか、製品制約なのか、運用要件なのかを残します。
全パラメータを保証したつもりになる
詳細設計は、すべての製品パラメータやすべての組み合わせ挙動を案件ごとに完全検証する工程ではありません。要件・方式・リスクに影響する項目を重点的に設計し、標準構成やデフォルト値に依拠する範囲を明確にします。
領域ごとの具体的な注意点は、後編①・②で整理します。
後編①ではOS・Web/AP・DB・ジョブを、後編②では監視・ログ・バックアップ・セキュリティ・運用スクリプトを扱います。
扱う論点の多くは、「知っているか、知らないか」で後工程の品質が大きく変わるものです。設計書の体裁は整っているのに、システムテストや本番移行前に手戻りが発生する。その原因の多くは、詳細設計のこの段階で見落とされています。
コメント