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

システム設計の現場では、基本設計を机上で行う工程として扱うことがあります。要件を整理し、方式を決め、構成図や説明を書き、詳細設計や構築へ渡す。工程管理として見ると、この分け方自体は分かりやすく、必要な場面もあります。

ただし、基本設計を「机上で資料を作るだけの工程」として固定してしまうと、設計の質を落とします。基本設計で本当に行うべきことは、システムとして成立する方式を選び、その判断根拠を明確にすることです。

そのため、設計対象に未知要素や実装差分が含まれる場合、基本設計段階で検証環境が必要になることがあります。これは構築作業を先取りしているのではなく、方式判断に必要な根拠を得るための作業です。

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

まず、基本設計が常に検証環境を必要とするわけではありません。机上で完結できる設計もあります。過去に同等構成の実績があり、製品仕様が安定していて、今回特有の差分が小さい場合は、既存事例や標準構成をもとに方式を決められます。

机上で進めやすい条件	内容
同等構成の実績がある	過去に同じような構成で稼働実績がある
技術要素が枯れている	製品仕様や制約が安定している
構成差分が小さい	今回だけの特殊な条件が少ない
相互作用が限定的	他システム、ネットワーク、認証、運用との複雑な連携が少ない
後工程で修正しやすい	詳細設計や構築で調整しても影響が限定的である

このような場合、基本設計で検証環境を作らないことは自然です。問題は、机上で判断できる設計と、検証しなければ判断できない設計を区別せず、工程名だけで検証不要と決めてしまうことです。

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

基本設計で検証環境が必要になるのは、単に試してみたいからではありません。方式判断に影響する不確実性があり、机上の情報だけでは採用可否を決められない時です。

基本設計で決める内容	机上だけでは不足しやすい理由
ネットワーク構成	経路制御、MTU、NAT、Firewall、IPv6 などで実装差分が出る
冗長化方式	フェイルオーバー時の挙動は仕様書だけでは判断しにくい
認証連携	LDAP、OIDC、SAML などは製品ごとの実装差分が大きい
クラウド接続	サービス仕様、帯域、ルーティング、制限事項の影響を受ける
監視・運用方式	障害時の見え方、通知、復旧手順が机上想定とずれる
性能・容量設計	カタログ値と実効値が一致しない

これらは、詳細設計や構築に入ってから初めて考えればよいものではありません。方式選定そのものに影響するため、基本設計の段階で一定の確認が必要になることがあります。

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

基本設計段階の検証環境は、本番環境を完全に再現するためのものではありません。確認するべきなのは、方式判断に影響する論点です。

確認すること	基本設計への影響
構成が成立するか	採用予定の方式を基本設計に残せるかを判断する
制約がどこに出るか	製品仕様、ネットワーク、認証、性能などの前提条件を明確にする
代替案が必要か	方式 A が成立しない場合に方式 B へ切り替える根拠を持つ
運用手順が成り立つか	監視、復旧、切り戻し、変更作業を設計に含められるかを確認する
残るリスクは何か	未検証事項や後工程で確認すべき事項を明示する

検証しても、本番同等の精度までは分からないことがあります。それでも、何が分かり、何が未確定で、どの条件なら採用できるのかを整理できれば、基本設計の判断材料として意味があります。

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

検証環境が必要かどうかは、「基本設計」という工程名では決まりません。見るべきものは、設計対象に含まれる不確実性です。

観点	机上で足りる設計	検証が必要な設計
技術要素	枯れた技術、実績多数	新規構成、組み合わせが未確認
参考事例	同等構成の実績がある	類似構成が少ない
製品仕様	制約が明確	実装差分や制限事項が多い
影響範囲	単体機能中心	複数システム間の相互作用がある
リスク	既知リスク中心	未知リスク、境界条件、例外系が多い

設計とは、抽象だけで完結する作業ではありません。抽象度の高い判断を行うために、必要な具体を取り出して確認する作業でもあります。この抽象と具体の往復ができていないと、基本設計は単なる机上資料になります。

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

基本設計と詳細設計を考える時に難しいのは、抽象と具体が固定された階層ではないことです。何を主語にするかによって、同じ要素が抽象にも具体にもなります。

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

つまり、基本設計で扱う抽象度は、工程名だけでは決まりません。どの対象を主語にして設計しているのか、その対象に対して何を決める必要があるのかで変わります。この目線の切り替えができないと、ある人にとっては基本設計の論点であるものを、別の人が詳細設計の話だと誤って扱うことがあります。

基本設計は書く工程ではなく決める工程である

基本設計で重要なのは、文書を作ることではありません。何を採用し、何を採用しないかを決めることです。その判断には根拠が必要です。

• 公式仕様
• 既存事例
• 過去の実績
• ベンダー回答
• 技術検証
• 性能測定
• 障害時挙動の確認
• 運用手順の成立性確認

既存事例や過去実績で十分に判断できる場合、検証環境は不要です。しかし、未知要素がある場合、技術検証は基本設計の根拠になります。ここを誤ると、基本設計書にはもっともらしい構成図や説明が並びますが、実際には成立性が確認されていない設計になります。

それは設計ではなく、想定の文書化です。

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

検証環境を作って確認しただけでは、基本設計としては完結しません。検証結果は、基本設計の判断根拠として文書へ戻す必要があります。

• 採用する方式
• 採用しない方式
• 採用条件
• 前提条件
• 制約事項
• 残るリスク
• 詳細設計や構築で確認する事項

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

基本設計と詳細設計は一体である

基本設計と詳細設計は、工程管理上は分けて扱われます。基本設計で方式や全体構成を決め、詳細設計でパラメータ、設定、手順、実装単位へ落とし込む。この分け方自体は必要です。

しかし、設計行為として見ると、基本設計と詳細設計は完全に別物ではありません。基本設計は抽象度の高い判断であり、詳細設計はその判断を具体化する作業です。具体化した時に前提の不足、制約、矛盾、運用上の難しさが見えることがあります。

そのため、詳細設計で見つかった問題は、単に詳細設計の中だけで処理すればよいとは限りません。方式判断そのものに影響するなら、基本設計へ戻して考える必要があります。基本設計と詳細設計は、上下に分断された工程ではなく、抽象と具体を往復しながら一体で設計品質を作る関係です。

もちろん、無制限に基本設計へ戻ればよいわけではありません。変更管理、影響範囲、合意形成は必要です。ただし、工程を守るために現実を無視するのは本末転倒です。詳細化によって基本設計の前提が崩れたなら、設計として正しく扱うべきです。

設計レベルの差はどこに出るのか

設計レベルの差は、資料の見た目や工程定義だけには出ません。本質的には、次の区別ができるかどうかに出ます。

区別すべきもの	内容
既存パターンの適用	過去事例をもとに再利用できる設計
新規性を含む設計	未確認要素を含み、検証が必要な設計
仕様書の転記	製品説明を並べただけの文書
アーキテクチャ設計	制約・相互作用・運用・リスクを含めて方式を決める行為

既存パターンの適用であれば、机上中心でも成立します。しかし、新規性を含む設計では、検証を通じて不確実性を潰す必要があります。この区別ができないと、「基本設計だから机上」「詳細設計だから具体」「構築工程だから検証」という固定的な理解になります。

まとめ

基本設計は、机上で完結する場合もあります。しかし、それは設計対象が既知であり、参考事例や標準構成が十分に存在する場合です。

未知要素、実装依存、相互作用、性能制約、運用制約が含まれる場合、基本設計段階でも検証環境が必要になることがあります。重要なのは、工程名ではありません。設計対象にどの程度の不確実性があるかです。

基本設計は机上資料を作る工程ではなく、方式判断を確定する工程です。方式判断に未知要素が含まれるなら、検証環境は基本設計の外部作業ではなく、基本設計の判断根拠になります。

設計に必要なのは、工程表への依存ではありません。抽象と具体を往復し、成立条件を見極め、必要なら基本設計と詳細設計を行き来しながら、現実に成立する方式へ近づけることです。

関連する記事

• 自宅のマイクロデータセンター – 自宅サーバーを超えたインフラ設計の実験場
• クラウドという言葉の本質 – 場所ではなく運用モデルと責任分界で考える
• AWS だけでクラウドを理解しない – パブリッククラウドと運用モデルを分けて考える
• VMware と OpenStack の違い – 仮想化基盤とクラウド基盤を同じものとして扱わない
• Kubernetes を前提とした仮想化アーキテクチャ – VM とコンテナの責務を分ける