実務ITインフラ設計① — 要件分析から設計インプット定義書まで

実務ITインフラ設計 ①

要件分析から設計入力定義書まで

顧客の要件を受け取りました。まず何から始めればよいでしょうか？

サーバーを選定するのでしょうか？ネットワーク構成図を描くのでしょうか？それとも、既存システムの構成を把握するところから始めるべきでしょうか？

実際のITインフラ構築プロジェクトでは、技術設計を始める前から数多くの質問に直面します。

• 「システムは絶対に停止してはいけません。」

• 「生産状況をリアルタイムで確認したいです。」

• 「既存のERPとスムーズに連携してください。」

• 「障害が発生してもデータが消えてはなりません。」

顧客には明確な要件のように見えても、設計者にはまだ確認すべきことがたくさんあります。

何が停止してはいけないのか、リアルタイムとは何秒または何分を意味するのか、どのデータをどれくらい保持すべきなのかが定まっていないためです。

このような状態で設計を始めると、設計が進んだ後に要件が変わり、すでに決定した構成や設計方針を再検討しなければならない状況が生じる可能性があります。

この講義は、まさにその問題から始まります。

01. 技術は知っているものの、設計をどこから始めればよいか悩んでいる方へ

サーバーをインストールして運用できることと、顧客の要件を分析してインフラ設計を始められることは、別々の能力です。

実際の設計プロジェクトでは、次のような判断が必要です。

• 顧客が話した内容は、実際の要件なのか、それとも単なる希望なのか？

• どのステークホルダーに会い、何を質問すべきか？

• 要求事項と技術的な解決策をどのように区別すべきか？

• まだ確認できていない内容は、どのように記録すべきか？

• 相反する要件は誰が決定すべきなのか？

• 後続の設計チームには、どのような文書を引き渡すべきか？

この講義では、こうした問いに答える方法を、一連のプロジェクトの流れに沿って学びます。

単に要件分析の概念を説明するのではなく、実際の設計者がどのような根拠で判断し、その判断を文書にどのように残すのかを扱います。

02. 約20年にわたるITインフラの実務経験をもとに

私は約15年間システムエンジニア（SE）として勤務し、その後約5年間、金融業界でテクニカルアーキテクト（TA）業務に携わりました。

システムの構築と運用を経験する中で、技術的に解決できる問題と同じくらい、顧客と設計者の間で要件を正確に理解し、合意するプロセスが重要だと気づきました。

実務では、顧客の要望が常に完璧な文書として伝えられるとは限りません。

要件が曖昧だったり、担当者によって説明が異なったり、まだ決まっていない内容をすでに確定したかのように伝えられたりすることもあります。

このとき設計者がすべきことは、自分の経験だけで答えを決めることではありません。

分からないことを確認し、判断の根拠を残し、決定していない事項を明確に区別すること。

この講義には、こうした実務的な視点を反映しています。

03. 一つのMES構築プロジェクトを最初から最後まで追います

講義では製造業向けMES（Manufacturing Execution System）の新規構築を仮想プロジェクトとして使用します。

顧客から初期要望を受けた状況から始め、ステークホルダーを特定し、要件を収集・分析したうえで、最終的に後続のインフラ設計チームに必要な文書を引き渡すまでのプロセスを段階的に進めます。

講義が進むにつれて、顧客の発言、インタビュー結果、観察記録、文書、確認の質問と回答が蓄積されていきます。

この資料をもとに要件を判断し、必要な成果物を完成させていきます。

STEP 1. 要件抽出の準備

誰に何を尋ねるべきか？

プロジェクトの目的と範囲を理解し、ステークホルダーを特定します。

要求事項の抽出計画を立て、インタビュー、グループディスカッション、観察、文書分析、アンケートなど、状況に応じた抽出方法と質問を準備します。

STEP 2. 顧客の実際の要求事項を収集する

顧客の発言や現場の状況をどのように記録するか？

経営陣、工場長、生産管理、品質、設備、情報システム、ERP担当者、セキュリティ担当者および協力会社の視点から情報を収集します。

顧客が直接話した内容、他者から聞いた内容、設計者の推論、現場で観察した事実を区別して記録します。

STEP 3. 要求事項の分類と分析

何が要件で、何が解決策なのか？

収集した情報を、要求事項、制約、前提、依存関係、解決策の候補に分類します。

機能要件・非機能要件・運用要件および責任に関する要件を分析し、業務への影響や依存関係などを考慮して優先順位を検討します。

設計範囲の内外や、他のシステム・組織との責任境界も整理します。

STEP 4. 要求事項の検証と顧客への再確認

設計に使用してもよい要求事項か？

要求事項の曖昧さ、漏れ、矛盾、実現可能性、検証可能性を確認します。

確認できていない内容を独断で決めず、顧客に改めて質問します。

顧客の回答と決定権者の決定を区別し、状態を変更する際は根拠を残します。

STEP 5. 設計入力定義書の作成

顧客の言葉を、設計者が使える表現に変換します。

「すぐに見たい」「絶対に止まってはいけない」といった表現を、業務基準、測定対象、データの鮮度、通常時・ピーク時の条件、検証方法などの観点から分析します。

これに基づき、設計者の解釈、測定・検証基準、未決定事項、関連する後続設計領域を記録した設計入力定義書を作成します。

STEP 6. トレーサビリティ・ベースライン・後続設計チームへの引き継ぎ

どの要求がどこから来て、どの設計につながるのか？

顧客の生の要求から要求事項、設計インプットへとつながる関係を確認します。

決定事項と未決定事項を区別してベースラインと未解決項目を整理し、後続の設計チームに引き継ぐ文書を準備します。

04. この講義を修了すると身につく実務能力

① 要求事項を引き出す能力

プロジェクトに必要なステークホルダーを特定し、適切な要求抽出手法や質問を選択できます。

② 要件を分析する能力

顧客の要望を、要求・制約・前提・依存関係・解決策の候補に分類し、その判断根拠を説明できます。

③ 不明確な要求を検証する能力

曖昧な点や不足している内容を見つけ出し、確認の質問を通じて必要な情報を得る方法を学びます。

④設計範囲と責任の境界を整理する能力

今回の設計で扱う内容と、他の組織やシステムとどの部分で連携するのかを文書化できます。

⑤設計入力定義書を作成する能力

顧客の業務上の言葉を、後続のインフラ設計者が理解できる設計インプットに変換する方法を学びます。

⑥ 後続の設計チームに成果物を引き渡す能力

要件の出所と決定状況を追跡し、未決定事項と今後の対応を明確にして、設計チームに伝えることができます。

05. 概念の説明だけで終わりません。実習資料も用意しています。

このコースは全14講義で構成されており、各講義の実習テンプレートと完成例を活用して学習します。

主な学習成果物は以下のとおりです。

区分　主な成果物 要求事項抽出の準備　ステークホルダー一覧、抽出計画、質問 要求収集　インタビュー・観察・文書分析の記録、未加工の要求一覧 要求事項分析　要求事項一覧、制約・前提・依存関係の一覧 優先順位と範囲　優先順位の判断記録、範囲・境界の定義書 品質検証　品質レビュー記録、顧客確認用質問書 設計インプット　設計インプットの草案、設計インプット定義書 設計への引き渡し　要求事項トレーサビリティ表、ベースライン、未解決項目一覧、後続の設計チームへの引き継ぎメモ

単に空の文書に内容を埋めることが目的ではありません。

なぜこの要件をこのように分類したのか、なぜこの値は未定のままにしておくべきなのか、なぜ設計者が独断で解決策を決めてはいけないのかを理解することが重要です。

実習テンプレートと完成例を比較しながら、判断のプロセスと文書の作成方法を併せて学べます。

06. こんな方におすすめです

ITインフラの運用から設計へと業務領域を広げたいSE

サーバー・ネットワーク・システムの運用経験はあるものの、顧客の要件を分析し、設計書を作成する経験が不足している方。

テクニカルアーキテクト（TA）の業務を初めて担当するエンジニア

顧客とのミーティングで何を確認し、どのような判断を下し、どのような成果物を作成すべきかを体系的に学びたい方。

新規システムの構築・高度化プロジェクトの参加者

RFPや初期要件が不明確で、追加確認事項や設計範囲、責任境界を整理するのが難しい方

設計文書の作成能力を高めたい実務者

要件定義書、設計入力定義書、トレーサビリティ表など、実際のプロジェクトで活用する文書の作成方法を身につけたい方。

技術要件をレビューするPM・PL

設計チームと顧客の間で、要件の確認状況、依存関係、未決定事項を管理する方法を理解したい方

07. 受講前にご確認ください

推奨される事前知識

サーバー、ネットワーク、ストレージ、データベース、仮想化など、ITインフラの基本概念を知っていると役立ちます。

実務での構築・運用経験があれば、講義内容の理解に役立ちます。

技術アーキテクト業務の経験や、製造業のMESプロジェクト経験は必須ではありません。

【実習環境】

一般的なPCと文書・スプレッドシートの編集環境があれば十分です。

別途、実習用サーバーやネットワーク機器、プログラミング環境は必要ありません。

この講義で扱わない内容

このコースは、インフラ設計全体ではなく、要件の抽出・分析および設計インプットの文書化に焦点を当てた独立モジュールです。

サーバー・ネットワーク製品の選定、物理・論理構成図の作成、詳細な冗長化方式の決定、容量の算定などは含まれません。

以降の設計段階は、別の後続モジュールで扱う予定です。

08. リバランスの中級ITインフラ設計シリーズ

Rebalanceの中級コースは、必要な実務設計のテーマを選んで学べるモジュール型の教育プログラムとして企画しました。

Module 01では、要件を設計への入力として整理する方法を学び、後続のモジュールでは構成図やフロー図など、次の段階のインフラ設計テーマを扱う予定です。

すべてのモジュールを必ず受講する必要はありません。

すでに知っている内容は飛ばし、自分の業務に必要な設計スキルを選んで学べるように構成することを目指しています。

まとめ

優れたインフラ設計は、機器を選ぶ瞬間ではなく、何を設計すべきかを正確に理解する瞬間から始まります。

顧客の曖昧な要望をそのまま書き取るのではなく、根拠を確認し、判断を記録し、後続の設計に必要なインプットを明確に整理する能力。

この講義を通じて、そのプロセスを最初から最後まで体験してみてください。

リバランス（Rebalance）

実務から始まり、設計へとつながるITインフラ教育