基本設計は机上だけで完結するのか – 検証環境と不確実性で考える

システム設計の現場では、基本設計を机上で行う工程として扱うことがあります。

要件を整理し、方式を決め、構成図や説明を書き、詳細設計や構築へ渡す。工程管理として見ると、この分け方は分かりやすく、必要な場面もあります。

しかし、基本設計を「机上で資料を作るだけの工程」として固定すると、設計の質を落とします。

基本設計で本当に行うべきことは、システムとして成立する方式を選び、その判断根拠を明確にすることです。

基本設計は机上で行える場合もある

まず、基本設計が常に検証環境を必要とするわけではありません。

過去に同等構成の実績があり、製品仕様が安定していて、今回特有の差分が小さい場合は、既存事例や標準構成をもとに方式を決められます。

この場合、机上で判断することは逃げではありません。すでに十分な根拠があるため、改めて検証しなくても妥当な判断ができるということです。

机上で進めやすい条件	理由
同等構成の実績がある	過去の稼働実績を根拠にできる
技術要素が安定している	製品仕様や制約が明確で、実装差分が少ない
構成差分が小さい	今回特有のリスクが限定的である
相互作用が少ない	他システム、認証、ネットワーク、運用との複雑な依存が少ない
後工程で修正しやすい	詳細設計や構築で調整しても影響が限定的である

問題は、机上で判断できる設計と、検証しなければ判断できない設計を区別しないことです。

検証環境が必要になるのは不確実性がある時

基本設計で検証環境が必要になるのは、単に試してみたいからではありません。

方式判断に影響する不確実性があり、机上の情報だけでは採用可否を決められない時です。

ネットワーク構成、認証連携、冗長化、性能、監視、障害時の挙動は、仕様書だけでは分からないことがあります。製品の仕様としては可能でも、実際の組み合わせ、運用条件、既存環境との接続で制約が出ることがあります。

設計論点	机上だけでは不足しやすい理由
ネットワーク構成	経路制御、MTU、NAT、Firewall、IPv6 で実装差分が出る
認証連携	LDAP、OIDC、SAML は製品ごとの挙動差が大きい
冗長化方式	フェイルオーバー時の挙動は仕様書だけでは判断しにくい
監視・運用方式	障害時の見え方、通知、復旧手順が机上想定とずれる
性能・容量設計	カタログ値と実効値が一致しない

PoC と技術検証と基本設計の関係

検証環境という言葉は、PoC と混同されることがあります。

PoC は、Proof of Concept、つまり概念実証です。技術や方式が成立するか、ビジネス上の仮説に価値があるかを確認するために行われます。

一方で、基本設計段階の技術検証は、方式判断の根拠を得るためのものです。本番環境を完全に再現することではなく、設計判断に影響する論点を確認することが目的です。

種類	目的	成果物
PoC	概念や仮説が成立するかを確認する	採用可否、実現性、価値の評価
技術検証	方式判断に必要な不確実性を減らす	制約、採用条件、未確定事項
基本設計	方式を決め、判断根拠を残す	構成方針、責任分界、設計判断
詳細設計	実装に必要な仕様へ落とす	設定値、パラメーター、手順、実装仕様

検証環境で確認するべきこと

基本設計段階の検証環境は、本番環境の完全なコピーではありません。

確認するべきなのは、方式判断に影響する論点です。

構成が成立するか。どこに制約が出るか。代替案が必要か。運用手順が成り立つか。残るリスクは何か。どこまで分かり、どこから先は未確定なのか。

検証しても、本番同等の精度までは分からないことがあります。それでも、何が分かり、何が分からないのかを明確にできれば、基本設計の判断材料になります。

工程名ではなく不確実性を見る

検証環境が必要かどうかは、「基本設計」という工程名では決まりません。

見るべきものは、設計対象に含まれる不確実性です。

工程名だけで判断すると、「基本設計だから検証は不要」「構築工程になってから試せばよい」という話になりがちです。しかし、方式選定そのものに影響する論点を後工程に送ると、あとで設計の前提が崩れます。

基本設計は、抽象的な方針だけを書く工程ではありません。抽象的な判断を正しく行うために、必要な具体を取り出して確認する工程でもあります。

抽象と具体は主語によって変わる

基本設計と詳細設計を考える時に難しいのは、抽象と具体が固定された階層ではないことです。

システム全体を主語にすれば、認証方式やネットワーク構成は比較的具体的な設計要素です。しかし、認証基盤を主語にすれば、LDAP、証明書、通信経路、フェイルオーバー、属性設計のような要素がさらに具体の論点になります。

つまり、基本設計で扱う抽象度は、工程名だけでは決まりません。どの対象を主語にして設計しているのか、その対象に対して何を決める必要があるのかで変わります。

この目線の切り替えができないと、ある人にとっては基本設計の論点であるものを、別の人が詳細設計の話だと誤って扱うことがあります。

検証結果は基本設計に戻す

検証環境を作って確認しただけでは、基本設計としては完結しません。

検証結果は、基本設計の判断根拠として文書へ戻す必要があります。

採用する方式、採用しない方式、採用条件、前提条件、制約事項、残るリスク、詳細設計や構築で確認する事項。これらを整理して初めて、検証は設計判断になります。

検証だけを行って文書に戻さなければ、単なる技術調査で終わります。逆に、検証結果を基本設計へ戻せていれば、検証環境は工程外の寄り道ではなく、基本設計の品質を上げるための根拠になります。

まとめ

基本設計は、机上だけで完結できる場合もあります。

しかし、方式判断に影響する不確実性がある場合、検証環境は基本設計の外にある作業ではありません。設計判断の根拠を作るための作業です。

重要なのは、工程名で考えることではありません。どの前提は机上で判断でき、どの前提は検証しなければ判断できないのかを分けることです。

基本設計は、資料を作る工程ではなく、判断する工程です。その判断を支えるために必要な具体を取り出し、検証し、結果を設計へ戻す。この往復ができて初めて、基本設計は現実に耐えるものになります。