インフラエンジニアとして経験を積んでいると、
「設計とは何をする仕事なのか」
「設計書を書くことが設計なのか」
「今の仕事は設計につながっているのか」
と考えることがあります。
インフラエンジニアの仕事には、運用、障害調査、構築、設計などがあります。
ただ、工程名だけを見ても、設計という仕事の本質は分かりにくいものです。
設計の本質は、設計書を作ることではありません。
要求や制約、既存環境などを踏まえて、システムをどのような状態にするのか、そのためにどの構成・設定を選ぶのかを判断する仕事です。
そして、設計に近づいているかを考えるときも、経験年数や肩書きだけを見る必要はありません。
重要なのは、
「現在の仕事で、構成や設定についてどこまで判断を任されているか」
です。
結論｜設計は「条件を踏まえて、何をどう作るか」を判断する仕事
インフラエンジニアの設計とは、決められた作業を実行することではなく、
要求・制約・既存環境などを踏まえて、システムの構成や設定を判断する仕事です。
例えば、
- どのような構成にするのか
- どの程度の性能が必要なのか
- 障害時にどのような状態を維持するのか
- どこまで冗長化するのか
- どのようにネットワークを接続するのか
- どのような設定にするのか
- その構成によって何が変わるのか
などを考えます。
設計では、単に「何を作るか」を決めるだけではありません。
実現したい状態を確認し、条件や制約を整理し、選択肢を比較したうえで、構成や設定を決めることが中心になります。
設計書や構成図は、その判断した内容を関係者が確認・共有し、実際の構築や運用につなげるためのものです。
したがって、
設計書を書けることと、設計判断ができることは同じではありません。
また、設計に近づいているかどうかも、「何年経験したか」だけでは判断できません。
「何を任されているか」
「どこまで判断しているか」
を見ることで、自分の現在地を確認できます。
この記事でわかること
- インフラエンジニアの設計とは何か
- 設計では具体的に何を決めるのか
- 何を根拠に構成や設定を決めるのか
- 設計書や構成図は何のためにあるのか
- 基本設計と詳細設計では何が違うのか
- 運用・障害調査・構築と設計では何が違うのか
- 設計につながる経験とは何か
- 自分が現在どこまで設計判断を任されているのか
インフラエンジニアの設計とは何か
設計は、
システムをどう作るかを決める仕事です。
ただし、「サーバーを何台置くか」「どの機器を使うか」といった構成だけを決めるわけではありません。
まず、
「何を実現する必要があるのか」
を確認します。
そのうえで、
「現在の環境では何が使えるのか」
「どのような制約があるのか」
「どのような状態にする必要があるのか」
を整理します。
例えば、新しいシステムを構築する場合でも、
- 必要な性能
- 可用性
- セキュリティ
- 既存システムとの接続
- 運用方法
- 障害時の対応
- コスト
- 将来的な変更
などによって、選ぶ構成は変わります。
つまり、設計では、
要件を確認する
→ 制約を確認する
→ 実現したい状態を整理する
→ 選択肢を考える
→ 比較する
→ 構成・設定を判断する
という流れで考えます。
設計では具体的に何を決めるのか
設計で決める内容は、対象となるシステムによって変わります。
例えばサーバーなら、
- 何台構成にするか
- どの程度の性能にするか
- どのように冗長化するか
- どのネットワークへ接続するか
- バックアップをどうするか
などがあります。
ネットワークなら、
- どの機器を配置するか
- どのように接続するか
- IPアドレスをどう割り当てるか
- 通信経路をどうするか
- 障害時にどう通信を維持するか
などを考えます。
ここで重要なのは、単に選択肢を知っていることではありません。
なぜその構成を選ぶのかを説明できる状態にすることです。
例えば、冗長化を考える場合でも、冗長化すればするほどよいとは限りません。
可用性を高める一方で、構成が複雑になったり、コストや運用負担が増えたりする場合があります。
だからこそ、
「何を優先するのか」
「何を制約として考えるのか」
を踏まえて構成を決めます。
設計書や構成図は何のためにあるのか
設計で決めた内容は、設計書や構成図などに整理します。
これらは、
設計で行った判断を関係者が確認・共有し、構築や運用につなげるための成果物です。
構成図であれば、
- どの機器があるのか
- どのようにつながっているのか
- どのシステムと接続しているのか
などを整理します。
設計書では、
- どのような構成にするのか
- どのような設定にするのか
- どの条件を満たす必要があるのか
- どのような前提で判断したのか
などを整理します。
そのため、
設計書を書くことが設計の本質ではありません。
先にあるのは、
「なぜこの構成にするのか」
「なぜこの設定にするのか」
という判断です。
設計書や構成図は、その判断を他者と共有できる形にしたものです。
設計では何を考えて構成を決めるのか
設計で重要なのは、構成そのものよりも、
なぜその構成を選ぶのか
という判断です。
同じシステムでも、求められる条件が違えば構成は変わります。
要件から実現したい状態を整理する
最初に確認するのは、
「何を実現する必要があるのか」
です。
例えば、
- どの程度の処理性能が必要なのか
- どの程度の可用性が必要なのか
- どのような利用者が使うのか
- どのシステムと接続する必要があるのか
などを確認します。
ここが曖昧なまま構成だけを決めても、必要な状態を実現できません。
既存環境や制約を確認する
新しい構成を考える場合でも、何でも自由に選べるとは限りません。
既存のネットワークやサーバー、利用しているサービス、組織のルールなどによって、選択できる範囲が変わります。
そのため、
何ができるかだけでなく、何ができないのか
も確認します。
この制約を踏まえて、実現可能な構成を考えます。
性能・可用性・セキュリティなどを考える
構成を決める際には、必要な性能だけでなく、
- 可用性
- セキュリティ
- 障害時の状態
- 運用方法
なども考慮します。
例えば、高い可用性が求められる環境と、コストを抑えることが優先される環境では、同じ構成になるとは限りません。
コストや運用負担も含めて選択する
設計では、技術的に実現できるかだけを見るわけではありません。
導入後に、
「どの程度の運用負担が発生するのか」
「構成が複雑になりすぎないか」
「コストが条件に合っているか」
なども考えます。
そのため、設計とは単に最も高性能な構成を選ぶ仕事ではありません。
与えられた条件の中で、必要な状態を実現できる構成を選ぶ仕事です。
選択した構成による影響を確認する
構成を決めると、その判断によって別の部分にも影響が出ます。
例えば、
- 通信経路が変わる
- 障害時の動きが変わる
- 運用手順が変わる
- 将来の変更方法が変わる
といったことがあります。
そのため、
「この構成にすると何が変わるのか」
まで確認します。
ここまで考えて構成や設定を決めることが、設計の判断です。
基本設計と詳細設計では何が違うのか
設計には、基本設計や詳細設計といった区分があります。
ただし、これを単純な上下関係として考える必要はありません。
違いは、
どの粒度で何を決めるか
にあります。
基本設計で決めること
基本設計では、システム全体として、
どのような構成・状態にするのか
を整理します。
例えば、
- 全体構成
- システム間の接続
- 必要な機能
- 可用性
- 性能
- セキュリティ
など、システム全体に関係する事項を整理します。
詳細設計で決めること
詳細設計では、基本的な構成を実際に実現するために、
具体的にどのような設定にするのか
を整理します。
例えば、
- IPアドレス
- 個別の設定値
- 機器ごとの設定
- 通信設定
など、より具体的な内容を決めます。
違いは工程の優劣ではなく判断する粒度
基本設計と詳細設計は、どちらが優れているという話ではありません。
重要なのは、
全体として何を決めるのか
と、
それを実現するために具体的に何を決めるのか
という判断する粒度の違いです。
そのため、基本設計・詳細設計という名称だけで、その人の能力や市場価値まで判断することはできません。
運用・障害調査・構築と設計は何が違うのか
運用、障害調査、構築、設計には、それぞれ異なる役割があります。
ただし、現場によって担当範囲が重なることもあります。
そのため、
工程名ではなく、何を判断することを任されているか
で見ることが重要です。
運用で任される判断
運用では、決められた状態を維持するための対応を行います。
監視や定型対応だけでなく、設定変更や改善対応などを担当する場合もあります。
そのため、運用だから判断がないわけではありません。
障害調査で任される判断
障害調査では、
- どこで問題が起きているのか
- 原因は何なのか
- どこまで影響しているのか
- どう復旧するのか
などを確認します。
構成や通信の関係を理解し、原因や影響を考える経験につながります。
構築で任される判断
構築では、決められた構成を実際の環境へ実装します。
一方で、現場によっては、
「この設定で問題ないか」
「この構成で実現できるか」
などを考えることもあります。
そのため、同じ構築経験でも、任されている判断の範囲は異なります。
設計で任される判断
設計では、
要求・制約・既存環境などを踏まえて、構成や設定そのものを決める
ことが中心になります。
ここでは、実装する前の段階で、
「何を選ぶか」
「なぜそれを選ぶか」
「その選択で何が変わるか」
まで考えます。
工程名だけでは現在地は決まらない
例えば、
「構築経験があります」
というだけでは、どこまで設計判断を経験しているかは分かりません。
設計書どおりに構築している場合と、構成や設定について検討している場合では、任されている判断が異なります。
反対に、運用の中でも改善や設定変更、障害調査などを担当していれば、判断範囲が広がっている場合があります。
だからこそ、
工程名ではなく、実際に何を判断しているか
を見る必要があります。
設計につながる経験とは何か
設計につながる経験を考えるとき、
「その仕事を何年やったか」
だけではなく、
その経験によって何を判断するようになったか
を見る必要があります。
設定変更で影響範囲を考える
設定変更では、変更する項目だけを見ればよいとは限りません。
「この変更でどこに影響するのか」
「変更後に何を確認する必要があるのか」
「問題が起きた場合にどう戻すのか」
などを考えます。
こうした経験は、構成や設定を判断する際の材料になります。
障害調査で原因と影響を考える
障害調査では、単に復旧手順を実行するだけでは原因を理解できない場合があります。
構成や通信、ログなどを確認し、
「なぜこの状態になったのか」
「どこまで影響しているのか」
を考えます。
システム全体の関係を把握する経験は、設計判断にもつながります。
構築で構成と設定を理解する
構築では、設計された内容を実際の環境へ反映します。
その際、
「なぜこの構成なのか」
「なぜこの設定なのか」
を理解していれば、単に手順を覚えるだけでは得られない経験になります。
構成と設定の関係を理解することが、その後の判断につながります。
改善・構成変更で選択肢を比較する
改善や構成変更では、
「現在の状態にどんな問題があるのか」
「変更すると何が変わるのか」
「ほかの方法はないのか」
などを考えます。
つまり、現在の状態を確認し、複数の選択肢を比較して、変更内容を判断する仕事です。
これは設計の判断構造に近い経験です。
ただし、
これらを経験すれば必ず設計を任される
という意味ではありません。
現場の役割や案件によって、任される範囲は変わります。
重要なのは、経験した仕事の名前ではなく、その中で判断する範囲が広がっているかどうかです。
自分はいまどこまで設計判断を任されているか
ここまでの内容を、自分の現在地に当てはめます。
確認したいのは、
「設計を経験したことがあるか」
ではありません。
「現在、どこまで判断を任されているか」
です。
手順を実行する
まずは、決められた手順に沿って作業する段階です。
必要な作業を正確に実行することが中心になります。
状況に応じて対応を判断する
次に、決められた手順だけでは対応できない状況で、
「どう対応するか」
を判断する仕事があります。
変更や障害の影響を考える
さらに、
「この変更によって何が変わるか」
「この障害がどこまで影響するか」
を考えるようになると、システム全体を見る範囲が広がります。
構成・設定を判断する
その先では、
「どの構成にするか」
「どの設定にするか」
そのものを考える仕事があります。
ここでは、要求や制約、既存環境などを踏まえて選択肢を比較する必要があります。
システム全体の構成を決める
さらに、個別の設定だけではなく、
「システム全体をどのような構成にするか」
を考える仕事があります。
ここまで来ると、設計の中心となる判断を担う範囲が広くなります。
ただし、これは優劣を示すものではありません。
すべてのインフラエンジニアが同じ範囲を担当する必要があるわけでもありません。
見るべきなのは、
自分が現在、どの範囲の判断を任されているのか
です。
設計に近づくために必要なのは経験年数ではなく判断範囲
設計に近づいているかを考えるとき、
「何年経験すれば設計を任されるのか」
だけでは判断できません。
同じ5年の経験でも、任されている仕事内容が違えば、経験している判断の範囲も変わります。
反対に、経験年数がそれほど長くなくても、設定変更や障害調査、構築、改善などを通じて判断する範囲が広がっている場合があります。
設計に進むかどうかの違いも、単純な経験年数ではなく、構成や設定について判断する経験をどこまで積んでいるかにあります。
経験年数だけでは設計経験を判断できない
経験年数は、その人がどの程度仕事を経験してきたかを見るための一つの情報です。
ただし、
経験年数＝設計判断の経験
ではありません。
設計に近づいているかを確認するなら、
「何年やっているか」
と合わせて、
「何を任されているか」
を見る必要があります。
現在の仕事で何を任されているかを見る
まず、現在の仕事内容を確認します。
- 手順に沿った作業が中心なのか
- 状況に応じた対応を判断しているのか
- 設定変更を判断しているのか
- 障害の影響範囲を考えているのか
- 構成について検討しているのか
- システム全体の構成を考えているのか
この違いを見ることで、現在の判断範囲を整理できます。
次に必要な判断経験を考える
現在地が分かったら、
「次にどんな仕事を経験すればよいか」
を考えます。
例えば、定型的な作業が中心なら、設定変更や障害調査など、より判断が必要な仕事を経験できるか確認します。
すでに設定変更や障害調査を担当しているなら、構築や改善、構成変更など、より広い範囲を考える仕事につながる場合があります。
重要なのは、
「設計という肩書きを得るには何年必要か」ではなく、「今の自分にどの判断経験が不足しているか」
を確認することです。
自分の現在地を確認する
ここまで整理すると、設計という仕事を、
「設計書を書く仕事」
「上流工程の仕事」
という名称だけで捉える必要がないことが分かります。
見るべきなのは、
- どこまで判断しているか
- どこまで責任を持っているか
- どこまで構成を理解しているか
- どこまで影響範囲を考えているか
です。
Workoutismでは、こうした現在地を確認するために、IRM（Infrastructure Responsibility Model）を使っています。
IRMでは現在地を、
01 監視・定型対応
→ 02 運用
→ 03 障害調査
→ 04 構築
→ 05 設計
という段階で整理します。
ただし、これは「05の設計が最も上で、そこを目指すべき」という意味ではありません。
現在の責任範囲や判断範囲を確認し、
「今の自分は何を任されているのか」
「次にどのような判断経験が必要なのか」
を整理するためのものです。
自分が現在どこまでの仕事を任されているのかを具体的に確認したい場合は、インフラエンジニア現在地診断｜年数ではなく「今任されている仕事」で分かるで確認できます。
自分の現在地を、単なる経験年数ではなく実際に任されている仕事から確認したい場合は、インフラエンジニアの市場価値はどう見る？どこまで任されているかで分かる評価で、任されている仕事の範囲という観点から整理しています。
まとめ｜設計とは構成・設定を判断する仕事
インフラエンジニアの設計は、設計書を書くことだけが仕事ではありません。
設計の中心にあるのは、
要求・制約・既存環境などを踏まえて、システムをどのような状態にするのか、そのためにどの構成・設定を選ぶのかを判断することです。
そのため、設計を理解するときは、
「設計書を書いたことがあるか」
「何年経験したか」
「設計という肩書きがあるか」
だけを見る必要はありません。
重要なのは、
- どのような条件を確認しているか
- どのような制約を考慮しているか
- どのような選択肢を比較しているか
- 構成や設定をどこまで判断しているか
- その判断による影響をどこまで考えているか
です。
そして、自分が設計に近づいているかを考えるときも、
「設計を経験したか」ではなく、「設計で必要になる判断をどこまで任されているか」
を見ることができます。
現在地が分かれば、次に必要な経験も考えやすくなります。
まずは、自分が現在どこまで判断を任されているのかを確認してみてください。
現在の仕事が運用なのか、障害調査なのか、構築なのかを整理する場合は、インフラエンジニアの運用とは？監視・手順書対応の仕事内容と“その後のキャリア差”でも、仕事内容と判断範囲の違いを確認できます。
