インフラ組織を設計と構築で分ける違和感 – 境界で失われる設計情報をどう戻すか

システムインフラの組織を、「設計部門」と「構築部門」に分ける考え方があります。一見すると、分かりやすい分類です。設計部門が設計し、構築部門が構築する。設計書を作る人と、それを実際に構築する人を分ける。工程として見れば、整理されているようにも見えます。しかし、システムインフラの仕事を実際に考えると、この分け方には本質的な違和感があります。問題は、設計部門と構築部門が分かれていること自体ではありません。また、ネットワーク基盤、仮想化基盤、共通プラットフォームのように、対象ごとの組織にすれば自動的に解決するという話でもありません。

工程名で組織を切るか。対象名で組織を切るか。それ自体が本質ではありません。本質は、組織境界によって失われる設計情報を、誰が拾い、どこへ戻し、何を更新するのかが定義されているかです。設計、構築、運用という工程で分けるなら、その境界で情報が失われます。ネットワーク、仮想化基盤、監視基盤という対象で分けても、その対象間の境界で情報は失われます。組織を分けるとは、必ず何らかの境界を作ることです。したがって、重要なのは「どこで分けるか」だけではありません。

分けた境界で何が失われるのか。失われやすい情報を誰が拾うのか。拾った情報をどこへ戻すのか。その情報によって、どの設計成果物、運用設計、標準構成、評価指標を更新するのか。ここまで考えて初めて、組織設計だと言えるのだと思います。

システムインフラにおける設計と構築

まず、システムインフラにおける「設計」と「構築」を確認しておきます。一般的に、システムインフラにおける設計とは、要件や制約をもとに、システムをどのような構成、方式、条件で成立させるかを定義する工程です。たとえば、以下のようなものを決めます。

• 全体構成
• 冗長化方式
• ネットワーク構成
• 認証方式
• 監視方式
• バックアップ方式
• 責任分界
• 性能要件
• 可用性要件
• 保守条件
• 拡張条件
• 移行方式
• 障害時の動作方針

つまり、設計とは単に設計書を書くことではありません。システムが成立するための構造と条件を決める行為です。一方、構築とは、設計で定義された構成、方式、条件を、実際の機器、ソフトウェア、設定、手順として実装し、動作確認する工程です。構築には、以下のような作業が含まれます。

• 機器設定
• OS 設定
• ミドルウェア設定
• クラスタ構築
• ネットワーク設定
• 監視設定
• 自動化スクリプトの適用
• 単体試験
• 結合試験
• 障害試験
• 性能試験
• 移行作業
• 切戻し確認

ただし、構築は単なる作業実行ではありません。構築は、設計で定義された内容が現実の環境で成立するかを確認する工程でもあります。実装して初めて、製品仕様とのずれ、性能上の限界、障害時の想定外挙動、運用上の保守不能性、手順上の危険性が見えることがあります。その意味で、構築は設計の下流にある単純作業ではありません。構築は、設計の実行であると同時に、設計の検証でもあります。

設計には階層がある

インフラ設計には階層があります。一般的には、基本設計、詳細設計、実装設計のように分けて考えることができます。

階層	内容	代表的な成果物
基本設計	全体構成、方式、責任分界、冗長化方針、運用方針を決める	構成図、方式設計書、基本設計書
詳細設計	実際の設定値、パラメータ、IP、VLAN、経路、ACL、監視項目などを決める	詳細設計書、パラメータシート、設定一覧
実装設計	作業順序、設定投入方法、試験方法、切戻し方法を決める	構築手順書、試験仕様書、移行手順書

基本設計は、比較的「設計部門」の仕事として扱われやすい領域です。しかし、詳細設計や実装設計は、構築にかなり近い場所にあります。たとえば、IP アドレス、VLAN、経路、ACL、証明書、監視項目、設定投入順序、切戻し手順、試験項目などは、設計でありながら、構築現場の実装知に強く依存します。つまり、設計と構築は完全に分離された工程ではありません。設計は構築前に一度完成するものではなく、詳細設計、実装、試験、運用を通じて具体化され、検証され、必要に応じて修正されます。

したがって、設計と構築を組織で分ける場合でも、この連続性を切断しない仕組みが必要になります。

ここでいう設計とは何か

ここでいう設計とは、単なる判断一般ではありません。作業中にどのコマンドを先に実行するか。一時ファイルをどこに置くか。誰に確認するか。こうした判断まで、すべて設計と呼んでしまうと、設計という言葉は広がりすぎます。それでは、「構築にも運用にも判断がある。だから構築にも運用にも設計がある」というだけの話になってしまいます。ここで問題にしたい設計とは、もう少し限定されたものです。システムインフラにおける設計とは、後続工程、運用状態、障害対応、拡張性、保守性に制約を与える構造的判断です。

たとえば、以下のような判断です。

• どの構成で可用性要件を満たすのか
• どこを冗長化し、どこを単一障害点として許容するのか
• どの性能経路を使うのか
• どの制約を運用で吸収し、どの制約を構成で解決するのか
• 障害時にどの状態を正常とし、どの状態を異常とみなすのか
• どこまでを自動化し、どこを手順で担保するのか
• 将来拡張時に何が制約になるのか
• 切戻し不能なポイントをどこに置くのか

これらは単なる作業判断ではありません。後続の構築、試験、運用、障害対応、拡張、保守に影響を与える判断です。したがって、ここでいう設計とは、単に「設計書を書くこと」ではありません。また、判断一般を雑に設計と呼ぶことでもありません。設計とは、システムの将来の振る舞いと制約条件を決める構造的判断です。

構築部門にも設計はある

組織上は「構築部門」と呼ばれていても、その中には当然ながら設計行為があります。ただし、それは「構築中にも判断があるから設計だ」という意味ではありません。構築部門には、上位設計を現実の機器、ソフトウェア、設定、手順、試験に接続するための構造的判断があります。たとえば、以下のようなものです。

構築部門内の設計	内容
実装設計	基本設計を実際の機器・ソフトウェア・設定値に落とし込む
詳細設計	IP、VLAN、経路、ACL、証明書、パラメータなどを決める
手順設計	どの順序で作業すれば安全に構築できるかを決める
試験設計	何を確認すれば構築が完了したと言えるかを決める
移行設計	既存環境への影響、停止時間、切戻し方法を決める
ロールバック設計	失敗時にどの状態へ戻すかを決める
自動化設計	Ansible、スクリプト、IaC、CI/CD などの実装方式を決める

構築とは、設計書を読んで手を動かすだけの作業ではありません。構築とは、上位設計が現実に成立するかを具体化し、検証し、必要に応じて修正すべき情報を発見する工程でもあります。たとえば、構築や試験の中で以下のようなことが分かる場合があります。

• 実装上、その構成が成立しない
• 製品仕様上、想定した動作にならない
• 性能が要件を満たさない
• 障害時の挙動が設計と異なる
• 手順上、切戻しが現実的ではない
• 運用上、保守できない構成になっている

これらは単なる「構築上の問題」ではありません。多くの場合、上位設計の前提を修正すべき情報です。たとえば、構築中に「この冗長構成ではフェイルオーバー時に想定通り切り替わらない」と分かった場合、それは単なる作業ミスではありません。それは、上位設計が前提としていた「この構成で可用性要件を満たせる」という仮定を否定する情報です。つまり、構築部門にある設計行為は、設計部門の下請けではありません。上位設計を現実に接続し、その妥当性を検証し、必要であれば上位設計を更新するための設計行為です。

運用部門にも設計はある

同じように、運用部門にも設計があります。運用は、完成したものをただ維持するだけの仕事ではありません。運用部門には、システムを現実世界で生かし続けるための構造的判断があります。

運用部門内の設計	内容
監視設計	何を、どの粒度で、どの閾値で監視するかを決める
アラート設計	どの状態を通知すべきか、どのノイズを抑えるかを決める
障害対応設計	一次切り分け、復旧手順、エスカレーションを決める
保守設計	パッチ適用、証明書更新、EOL 対応、定期作業を設計する
容量設計	リソース増強の判断基準、閾値、限界値を決める
権限設計	誰がどこまで操作できるかを決める
変更管理設計	変更の粒度、承認、影響確認、戻し方を決める
改善設計	障害や運用実績から次の改善方針を決める

運用設計が弱いシステムは、構築できても維持できません。監視が不適切であれば、障害は検知できません。アラートが雑であれば、通知はノイズになります。手順がなければ、夜間障害時に復旧できません。保守設計がなければ、証明書更新やパッチ適用のたびに危険な作業になります。運用中に見つかる問題も、単なる運用上の工夫として処理すべきではありません。たとえば、運用中に「この監視閾値では異常を検知できない」と分かった場合、それは単なる閾値調整の話ではありません。

それは、設計上の「このシステムは異常状態を識別できる」という前提が不十分だったことを示しています。また、「この手順では夜間障害時に復旧できない」と分かった場合、それは単なる運用手順の不備ではありません。それは、システムが運用可能な形で設計されていなかった、という情報です。運用は、設計の答え合わせでもあります。したがって、運用部門にある設計行為も、上位設計から切り離してはいけません。運用で得られた知見は、次の設計へ戻す必要があります。

なぜフィードバックループが必要なのか

構築部門や運用部門に設計行為があるからといって、単に「各部門にも設計がある」と言うだけでは不十分です。重要なのは、それらのローカルな設計判断が、上位設計の前提条件を更新する情報になるという点です。上位設計は、必ず何らかの前提に基づいています。

• この構成で性能要件を満たせる
• この冗長化方式で可用性要件を満たせる
• この監視方式で異常を検知できる
• この手順で安全に移行できる
• この運用体制で保守できる
• この製品仕様で必要な機能を実現できる

しかし、これらの前提は、構築、試験、運用の中で否定されることがあります。そのとき、構築部門や運用部門で見つかった事実が上位設計に戻らなければ、上位設計は誤った前提を持ち続けます。つまり、フィードバックループがない組織では、設計が体系的に間違い続けます。構築で見つかった制約が設計に戻らない。運用で見つかった障害傾向が設計に戻らない。監視で見つかった検知不能状態が設計に戻らない。保守で見つかった更新不能ポイントが設計に戻らない。この状態では、設計部門がどれだけ設計書を書いても、設計は現実から切断されます。

したがって、必要なのは単なる部門分担ではありません。必要なのは、構築・試験・運用で得られた事実が、上位設計を更新する構造です。

境界設計にはチャネルとインセンティブが必要である

組織を分けるなら、境界設計が必要です。ここでいう境界設計とは、組織境界で失われやすい情報をどう扱うかを、あらかじめ設計することです。そのためには、少なくとも二つの条件が必要です。一つは、情報を戻すためのチャネルです。構築中に発見された制約を、どこへ戻すのか。試験結果によって、どの設計成果物を更新するのか。運用中に発見された監視不能性、保守不能性、復旧不能性を、どの標準構成や次期設計へ反映するのか。部門間の境界で失われる情報を、誰が拾い、誰が判断し、誰が設計へ反映するのか。

こうした経路がなければ、現場で重要な情報が見つかっても、上位設計には届きません。もう一つは、情報を戻すことが評価されることです。チャネルがあっても、それを使うことが評価されなければ機能しません。設計部門が、設計書の完成やレビュー完了だけで評価されるなら、構築側から戻ってくる制約は単なる手戻りとして扱われます。構築部門が、予定通りの作業完了だけで評価されるなら、設計不備を指摘して作業を止めるより、設計書通りに作業を進める方が合理的になります。

運用部門が、障害を表面化させないことだけで評価されるなら、設計上の問題を明文化して上位設計へ戻すより、現場で吸収する方向に流れます。つまり、境界設計には、チャネル設計とインセンティブ設計の両方が必要です。経路がなければ届きません。評価されなければ使われません。フィードバックループは、ただ存在すればよいものではありません。構築制約を設計へ戻すこと。試験結果によって設計成果物を更新すること。運用中に見つかった保守不能性を次期設計へ戻すこと。

障害対応から得た知見を監視設計や標準構成に反映すること。これらが、組織にとって合理的な行動になっていなければなりません。

責任対象が曖昧だと、成果物責任にすり替わる

組織名が設計部門であれ、構築部門であれ、運用部門であれ、ネットワーク基盤チームであれ、仮想化基盤チームであれ、それ自体が決定的な問題ではありません。重要なのは、その組織が何の成立性に責任を持つのかです。責任対象が曖昧なままでは、責任は分かりやすい成果物へすり替わりやすくなります。設計部門は、設計書に責任を持つ。構築部門は、作業完了に責任を持つ。運用部門は、引き継がれたものを止めないことに責任を持つ。しかし、本来責任を持つべきなのは、設計書でも、作業完了でも、引き継ぎでもありません。

システムが成立していることです。運用できること。障害時に復旧できること。将来変更できること。保守できること。性能要件を満たせること。監視できること。異常を検知できること。責任対象が明確でなければ、組織は成果物に逃げます。設計書は完成した。構築は完了した。運用へ引き継いだ。監視設定は入れた。手順書は作った。しかし、それでシステムが本当に成立しているとは限りません。現代インフラでは、複数の技術ドメインが強く結合しています。仮想化基盤、クラウド、Kubernetes、高速パケット処理、監視、自動化、セキュリティ、運用設計が相互に絡みます。

そのため、単一の成果物だけを見ても、システム全体の成立性は判断できません。だからこそ、組織には明確な責任対象と、それに対応した評価指標が必要です。

古典的ネットワーク設計構築では、なぜ分業が成立しやすかったのか

ただし、古典的なネットワーク設計構築であれば、設計部門と構築部門の分離は、ある程度成立しやすかった面があります。ここで重要なのは、「古典的だから簡単だった」という話ではありません。BGP、OSPF、STP、非対称経路、MTU、NAT、FW、冗長化、移行設計など、古典的ネットワークにも難しさはあります。ただし、案件によっては、考慮すべき技術ドメインが比較的限定され、成果物にも分解しやすかった。たとえば、従来型のネットワーク案件では、主に考える対象は以下のようなものでした。

領域	主な設計対象
物理構成	拠点、ラック、機器、回線、ケーブル
L2	VLAN、STP、LAG、冗長構成
L3	IP、ルーティング、VRF、経路制御
セキュリティ	FW、ACL、NAT、ゾーン
冗長化	HSRP、VRRP、HA、経路切替
移行	切替手順、切戻し、停止時間
監視	Ping、SNMP、Syslog、Trap、閾値

もちろん、これらも相互依存します。NAT とルーティングは干渉します。FW のセッション維持と経路切替は関係します。MTU や MSS はアプリケーション通信に影響します。LACP や MLAG は対向機器の実装に依存します。したがって、古典的ネットワークが完全に閉じていたわけではありません。それでも、現代的な仮想化基盤、クラウド、Kubernetes、高速パケット処理基盤のような領域と比べると、設計対象の中心が比較的明確で、技術ドメインの数も限定されている場合が多かった。

そのため、基本設計書、詳細設計書、パラメータシート、コンフィグ、試験項目表、移行手順書のように成果物を分解しやすかった。この分解可能性が、設計と構築の分業を成立しやすくしていたのだと思います。

分業が成立していたもう一つの条件

ただし、古典的ネットワークで設計と構築の分離が成立していたように見えた理由は、それだけではありません。もう一つ重要なのは、人的な補完です。組織上は設計と構築が分かれていても、実際には構築側の熟練者が設計レビューをしていたことが多かったはずです。たとえば、構築側の人が以下のように気づく。

• この設計だと切替時に危ない
• この ACL 順序はまずい
• このルート設計だと戻り通信が怪しい
• この FW 構成だと片系障害時に通信が切れる
• この手順では現地作業で詰まる
• この設定投入順序では通信断が長くなる

これは単なる構築上の注意ではありません。構築側にある設計知です。つまり、分業が成立していたように見えたのは、対象領域が比較的分解可能だったことに加え、その分解で失われる情報を熟練者の暗黙知が補っていたからです。したがって、古典的ネットワークで設計と構築を分けても回ったように見えたとしても、それは「設計と構築が本質的に分離可能だった」という意味ではありません。分離しても破綻しにくい条件があり、さらに人的な設計知が境界をまたいでいたから、なんとか成立していたのだと思います。

暗黙知に依存した境界補完は、組織能力になりにくい

かつては、熟練者が設計と構築、構築と運用の境界で失われる情報を暗黙に拾っていました。この暗黙知による越境は、分業が機能していたように見えた重要な理由です。しかし、それを個人の経験や勘に依存したままにすると、組織知になりません。優秀な人がいる間は回る。その人が気づけば問題は表面化する。その人がいなければ、同じ問題が見逃される。これは組織能力ではなく、属人的な補完です。現代インフラでは、誰がその情報を拾い、どこへ戻し、何を更新するのかを明示的に設計する必要があります。

つまり、人的統合と制度的統合は対立するものではありません。人的統合とは、境界で失われる情報を発見する能力です。制度的統合とは、その発見を設計成果物、標準構成、運用設計、評価指標に戻す仕組みです。設計と構築の両方が分かる人材は重要です。しかし、その人材の知見が設計成果物や標準構成に戻らなければ、組織知にはなりません。逆に、フィードバックルールだけがあっても、境界で何が失われているかを発見できる人がいなければ、制度は形骸化します。必要なのは、境界で失われる情報を発見できる人材と、その情報を組織の設計に戻す仕組みの両方です。

ただし、中心にあるのは「両方が大事」という一般論ではありません。重要なのは、組織境界で失われる設計情報を、個人の暗黙知に閉じ込めず、組織の設計能力へ変換することです。

コンポーネントの集合が、能力の集合になっているか

もう一つ重要なのは、組織を対象別に分ける場合でも、その単位が意味のある集合になっているかです。ネットワーク、仮想化基盤、Kubernetes、監視、自動化、セキュリティのように名前を並べるだけでは、よい組織境界にはなりません。いくつかのコンポーネントを同じチームに持たせたとしても、それらが利用者に対して一つの成立した能力として提供されていなければ、結局は別の形の縦割りになります。

たとえば、DNS、LB、FW、証明書、Ingress、監視、接続申請、IPAM は、それぞれ別の技術要素です。しかし利用者から見ると、それらは「安全にサービスを公開する」「名前解決できる」「通信経路を制御できる」「異常を検知できる」という能力の一部です。したがって、組織境界を考えるときは、コンポーネントの近さだけではなく、どの能力を成立させるための集合なのかを見る必要があります。

この視点がないまま対象別組織を作ると、「ネットワークっぽいもの」「サーバーっぽいもの」「クラウドっぽいもの」を集めただけになります。その場合、チームは存在していても、利用者に対する入力、出力、保証範囲、例外処理、責任分界が曖昧なまま残ります。部門間を API 的に接続するという考え方も、この前提があって初めて機能します。API とは単に窓口を作ることではなく、何を受け取り、何を返し、どこまで保証し、どの例外をどう扱うのかを定義することだからです。

つまり、組織を分けるなら、まずその組織が何を成立させる能力なのかを定義しなければなりません。部品を集めただけではプラットフォームにはなりません。利用者から見て、意味のある入力、出力、保証、運用、改善の単位になって初めて、組織境界は設計されたものになります。

問題は時代ではなく、結合度である

ここで注意すべきなのは、「古典的ネットワーク」と「現代インフラ」という時代区分そのものが本質ではない、ということです。本質的な違いは、時代ではありません。相互依存する技術ドメインが増える。一つの設計判断が他領域へ波及しやすくなる。仕様書や机上設計だけでは妥当性を判断しにくくなる。実測、PoC、障害試験、運用実績への依存度が上がる。構築や運用で得られた事実を設計へ戻す必要性が高まる。この因果構造が重要です。現代的なインフラでは、この構造が発生しやすくなっています。

仮想化基盤、クラウド、Kubernetes、高速パケット処理、監視、自動化、セキュリティ、コスト、運用設計が相互に絡むからです。

領域	絡んでくるもの
仮想化基盤	CPU、NUMA、メモリ、ストレージ、仮想 NIC、ハイパーバイザ
高速パケット処理基盤	SR-IOV、DPDK、HugePages、PMD、NIC 性能、CPU pinning
Kubernetes	CNI、Service、Ingress、Pod 配置、Node 障害、StorageClass
クラウド	IAM、ネットワーク、コスト、リージョン、可用性、マネージド制約
監視	メトリクス、ログ、トレース、SLO、アラート設計
自動化	IaC、GitOps、CI/CD、変更管理、差分管理
運用	障害対応、証明書更新、パッチ、容量予測、保守期限

この世界では、ネットワークだけを設計してもシステムは成立しません。サーバだけを設計しても成立しません。仮想化基盤だけを設計しても成立しません。クラウド構成だけを設計しても成立しません。監視を後から追加しても成立しません。それぞれが強く相互依存しているからです。特に高速パケット処理基盤のような領域では、SR-IOV ひとつを取っても、NIC、BIOS、PCIe、IOMMU、ハイパーバイザ、VM、NUMA、CPU pinning、VF 数、DPDK、アプリケーション、監視、障害時切替まで関係します。

このような構造では、設計部門が上位設計を書き、構築部門がそれを実装する、という単純な分離では足りません。実装、検証、性能測定、運用設計から得られる情報が、そのまま上位設計を更新する材料になるからです。

設計と構築は直列ではない

古い工程分業の発想では、以下のように考えがちです。設計↓構築↓運用この図だけを見ると、設計が先にあり、その後に構築があり、最後に運用があるように見えます。しかし、実際のシステムインフラでは、これだけでは不十分です。現実には、以下のような往復が必要です。仮説としての設計↓構築・検証↓設計修正↓運用設計↓実運用↓障害・性能・保守の知見↓再設計設計は、構築前に完全に完成するものではありません。構築と検証によって、設計の妥当性が確認されます。運用によって、設計の実用性が確認されます。

障害や性能問題によって、設計の限界が見えます。つまり、設計は構築や運用から切り離された机上作業ではありません。設計とは、構築、試験、運用、改善を通じて確定し、更新されていくものです。

現代的なエンジニア組織に必要なもの

現代的なエンジニア組織では、単に工程ごとに人を分けるだけでは不十分です。必要なのは、組織境界そのものの設計です。組織を分けるなら、最低限、以下を考える必要があります。

• 各組織は何の成立性に責任を持つのか
• その責任は、設計書や作業完了ではなく、システムの運用可能性に結びついているか
• 構築や試験で得られた事実を、どの設計成果物へ戻すのか
• 運用で得られた知見を、どの標準構成や監視設計へ戻すのか
• 境界で失われる情報を、誰が拾うのか
• 情報を戻すことが、評価される行為になっているか

情報を戻す経路がなければ、現場の知見は届きません。情報を戻すことが評価されなければ、その経路は使われません。設計書を完成させた人が評価されるのか。設計の誤った前提を発見し、修正した人が評価されるのか。予定通り作業を終えた人が評価されるのか。構築中に設計不備を見つけ、手戻りを発生させても止めた人が評価されるのか。障害を表面化させずに運用で吸収した人が評価されるのか。運用で発見した設計不備を明文化し、次期設計へ戻した人が評価されるのか。この違いは大きいです。

組織は、評価されるものに最適化されます。だから、組織境界を作るなら、その境界をまたいで情報が戻るチャネルと、その情報を戻すことが評価される仕組みを設計しなければなりません。

まとめ

システムインフラの組織を、設計部門と構築部門に分けること自体が、常に間違いだとは思いません。また、対象ごとの組織にすれば自動的に解決するとも思いません。問題は、工程名で切るか、対象名で切るかではありません。問題は、組織を分けた境界で失われる設計情報を、誰が拾い、どこへ戻し、何を更新するのかを設計していないことです。そのためには、情報を戻すチャネルと、情報を戻すことが評価されるインセンティブの両方が必要です。チャネルがなければ、現場の知見は上位設計に届きません。

インセンティブがなければ、チャネルは使われません。現代インフラでは、複数の技術ドメインが強く結合しています。構築中に見つかる制約、試験で見える性能限界、運用で露出する保守不能性が、そのまま上位設計の前提を更新します。そのため、設計、構築、運用を直列工程として扱うだけでは足りません。必要なのは、各工程に存在する構造的判断を見える化し、それを設計成果物、標準構成、運用設計、評価指標へ戻すことです。設計部門だけが設計する。構築部門は作るだけ。

運用部門は回すだけ。そのような理解で組織を作ると、システムインフラの複雑性には対応できません。組織を分けるなら、分けた境界そのものを設計しなければなりません。そこを考えずに、設計、構築、運用という言葉だけで組織を切るのであれば、それは現代インフラの複雑性に対する十分な組織設計とは言えないと思います。

関連記事