インフラWBSの作り方｜4つの依存関係で遅延をゼロにする工程分解

「自社のキッティングやTerraformコード作成は予定通り終わっていたのに、回線引き込みとクラウドアカウントの払い出しが遅れてサービスインが延期した」

「現地ラックに機器を載せようとしたら、別送のラックマウントレールが届いておらず作業が全停止した」

インフラ案件でPLやPMを任されると、こうしたトラブルに直面することがあります。

アプリ開発であれば、後半にメンバーを増員して力技で挽回できるケースもあります。しかし、物理機器や通信回線、組織統制や顧客の社内申請が絡むインフラ構築では、人月をいくら追加しても1秒も縮まらない「外部リードタイムの壁」が存在します。

「クラウドだから画面ポチポチですぐできるはず」という油断も禁物です。実際には、組織ガバナンス審査、サービス上限緩和、専用線接続など、クラウド特有の新たな待ち時間が現場の進行を阻みます。

オンプレ・仮想化・クラウドが混在する現代のインフラ構築において、手戻りと納期遅れを根本から防ぐWBS（作業分解構成図）の設計手順を解説します。

クラウド・仮想化時代でも納期遅延が「リカバリ不能」になる理由

納期遅延の8割は「実作業時間」ではなく「待ち時間（リードタイム）」

クラウドやIaC（Terraform等）の普及により、仮想マシンのプロビジョニングやOSセットアップといった「実作業工数」は劇的に削減されました。

しかし、いざ構築を始めようとした瞬間、「そもそも前提条件が揃っておらず、コマンドを1行も実行できない」という事態が頻発します。

例として「オンプレミス基幹システムのAWS移行（ハイブリッド構成・本番停止あり）」を想定した以下のプロジェクトを想定してみましょう。

WBSを作成する際、多くのエンジニアが「自社メンバーが手を動かす工数」だけをカレンダーに積み上げてしまいます。

• 移行方式設計・通信要件の策定：5人日
• クラウド基盤（Terraform）展開・FWキッティング：6人日
• 回線疎通テスト・DBデータ同期確立：5人日
• 移行リハーサル検証・本番切替作業：4人日
• 自社実作業の合計工数：20人日（1名稼働で約1ヶ月 / 2名体制なら約半月）

数字の上だけを見れば、「2名体制で進めれば半月〜1ヶ月弱あれば余裕で終わる」と見込めます。しかし、現実のハイブリッド移行プロジェクトは次のように進行します。

自社メンバーの実稼働は合計で20人日程度でも、カレンダー上では3ヶ月近く（約90日）を消費します。

インフラ案件の納期遅延は、「実作業の遅れ」ではなく「WBSに組み込まれていなかった待ち時間と調整期間の累積」によって引き起こされます。

では、なぜこれほどまでに「見えない待ち時間」が発生してしまうのでしょうか？

それは、作業に着手する瞬間だけでなく、構築中、テスト中、そしてリリース直前の移行に至るまで、インフラ構築の全工程が「他者や物理の制約」に縛られているからです。

こうした遅延トラップをWBS上で完全に制御するためには、タスクを単に並べるのをやめ、プロジェクトを停滞させる要因を「4つの型」で捉えることが不可欠になります。

インフラ構築WBSを破綻させない「4つの依存関係」フレームワーク

インフラ構築でスケジュールを破綻させないためには、タスク同士を単に線で結ぶのではなく、その依存関係が以下の4つのどれに該当するかを識別してWBSにプロットする必要があります。

調達（物理・契約リードタイム依存）

【判断基準】 お金や発注書を払って、相手からモノ・権利・工事完了が届くのを待つ関係

自社がどれだけリソースを投入しても、「相手先の製造・手配・工事リードタイム」に拘束される依存関係です。

• ハードウェア・周辺部材： サーバやルータ本体だけでなく、ラックマウントレール、光トランシーバー（SFP+）、専用電源ケーブル等の納期ズレ。
• 回線・物理工事： 光回線の引き込み工事、キャリア局内工事枠、データセンター構内配線（クロスコネクト）、Direct Connect / ExpressRouteのLOA-CFA発行と接続。
• ライセンス・アカウント： 商用ミドルウェアのライセンスキー発行、マルチアカウント環境における新規クラウドアカウント払い出し、仮想基盤（VMware等）のリソース割り当て。

【対策】
WBS上では「工数＝0人日」「期間＝カレンダー日数（例：30日）」として配置し、型番や構成が確定した瞬間に仮押さえ・先行手配をかけます。

処理待ち（組織プロセス・承認依存）

【判断基準】 書類や申請を出して、組織のハンコ（決裁・承認）が押されるのを待つ関係

技術やモノの問題ではなく、「社内・顧客・第三者の意思決定と回付フロー」による依存関係です。

• セキュリティ審査・CAB： 顧客のセキュリティ変更審査会（月1回開催など）によるFW穴あけ・VPN接続の審議待ち。
• 発注・決裁稟議： 設計FIXから顧客側の稟議ルート（課長→部長→役員）を通過し、正式発注書が届くまでのタイムラグ。
• 作業申請・審査： データセンターへの事前入館申請（5営業日前厳守など）や、特権IAMアカウント発行の社内承認待ち。

【対策】
申請書類を提出する日ではなく、「審査会が開催され、承認が下りる日」を着手トリガーとしてマイルストーン設定します。

調整（ステークホルダー・日程枠依存）

【判断基準】 自社の一存では日時を決められず、相手のスケジュール枠に合わせる関係

自社の都合だけでは日時を決められず、「関係各所との合意形成や専用ウィンドウ」に縛られる依存関係です。

• システム停止枠（メンテナンスウィンドウ）： 本番環境や共通NWの切替に伴うサービス停止日時の調整（夜間・休日枠、大型連休等の制約）。
• 外部・対向システムのテスト枠： 決済代行、金融共同センター、対向先EDIとの接続テスト可能期間（例：特定週の深夜のみ）。
• 第三者脆弱性診断： 外部セキュリティ診断業者の診断実施枠の予約と拘束期間。
• 業務変更凍結期間（ブラックアウト）： 四半期決算期末やEC大型セール期間など、システム変更が禁止される期間の回避。

【対策】
調整枠から逆算して構築完了日をデッドライン設定し、万一の遅延に備えて予備枠（第2希望日程）をあらかじめ押さえます。

処理順番（技術的・論理的シーケンス依存）

【判断基準】 アーキテクチャの構造上、下から順に積み上げないと動かない物理・論理関係

インフラのアーキテクチャ上、「前の層が正しく動かないと、次の層の作業に物理的に入れない」という順序関係です。

• レイヤー間の階層順序：
  • 物理配線/L2・L3 ➔ 仮想化/クラウドIaaS ➔ OS/ストレージ ➔ ミドルウェア ➔ アプリケーション
• 名前解決と証明書：
  • ACM等のマネージド証明書DNS検証レコード追加 ➔ 証明書発行 ➔ ロードバランサー（ALB等）へのアタッチ
• 移行シーケンス：
  • 切替7日前のTTL短縮（300秒化） ➔ 切替当日のDNS変更・データ同期 ➔ 安定稼働後のTTL復元

【対策】
各レイヤー完了時に「単体検証・エビデンス採取」の完了条件（DoD）を設定し、中途半端な状態での上位引き渡しによる手戻り連鎖を防ぎます。

【早見表】インフラ依存関係4分類マトリクス

手戻りを防ぐインフラWBSの作り方｜実践的な工程分解5ステップ

ここからは、実務で使える堅牢なWBSを組み立てる5つの手順を解説します。

Step 1: 成果物（Deliverables）から逆算したワークパッケージ分解

WBSを展開する際、「設計」「構築」「テスト」といった動詞（アクション）で分解すると、作業の抜け漏れが発生しやすくなります。

必ず「基本設計書」「Terraformコード」「疎通確認エビデンス」といった名詞（成果物）を起点に分解します。

• ×（動詞思考）：クラウド環境を構築する
• ◯（成果物思考）：
  • クラウド設計書（VPC/サブネット/ルーティング設計）
  • アカウント権限マトリクス（IAMポリシー/ロール定義）
  • 通信要件定義書（セキュリティグループ/NACL/FW設計）
  • インフラ構成コード（Terraform / CloudFormation / Ansible）
  • 環境受入・疎通確認完了報告書

成果物を定義することで、「何が提出されたらそのタスクが本当に完了なのか」の判定基準が客観的になります。

Step 2: 「自社稼働タスク」と「外部依存タスク」を完全に分ける

すべてのワークパッケージを洗い出したら、担当区分（オーナーシップ）を厳密に分けます。

• 自社内部タスク： パラメータ設計、Terraformコード作成、OS設定、疎通テスト
• 外部依存タスク： クラウドアカウント払い出し待ち、Direct Connect開通待ち、FW申請承認待ち、DNS検証レコード反映待ち

WBS上では、外部依存タスクに対して「工数＝0人日（自社の作業工数は発生しない）」としつつ、「期間＝14営業日（カレンダー上の占有期間）」として設定します。これを明確に分けることで、「工数消化率は順調なのにスケジュールだけが破綻している」という事態を防げます。

Step 3: 先行後行関係（FS/SS/FF）を繋ぎ、クリティカルパスを可視化する

各タスクをカレンダーに並べる前に、タスク同士の結合条件（依存関係）を定義します。

• FS（Finish-to-Start）： 前のタスクが終わったら、次のタスクが始まる（基本形）
  • 例：クラウドアカウントが受領（F）されたら、Terraform適用を開始（S）できる
• SS（Start-to-Start）： 前のタスクが始まったら、次のタスクも同時に始められる
  • 例：Direct Connectの回線手配を開始（S）したら、並行してオンプレ側BGPルータのコンフィグ作成を開始（S）できる
• FF（Finish-to-Finish）： 前のタスクが終わるときに、次のタスクも同時に終わる
  • 例：アプリ結合テストが終了（F）するまで、クラウド監視アラートのチューニングを継続（F）する

これらを正しく紐付けることで、「プロジェクト全体の最短終了日を決定づけている一本の線（クリティカルパス）」が浮き彫りになります。

Step 4: 「見えないバッファ」を排除し、「プロジェクトバッファ」を一元配置する

各エンジニアが自分のタスクにこっそり「2日間の安全余裕（バッファ）」を乗せるやり方は厳禁です。

「学生症候群（期限ギリギリまで着手しない）」や「パーキンソンの法則（与えられた時間いっぱいまで作業を引き延ばす）」が働き、個別のバッファはほぼ100%使い切られてしまいます。

• 個別タスク： 無駄を削ぎ落とした「最頻値（順調にいった場合の工数）」で見積もる。
• プロジェクトバッファ： 削った余裕を集約し、各マイルストーンの直前やプロジェクト全体の末尾に「全体バッファ：10日」として堂々と配置する。

バッファの消費状況をPMが一元監視することで、「プロジェクトの危険度」がひと目で把握できるようになります。

Step 5: アプリ引き渡し・サービスインに向けた「受入完了条件（DoD）」の定義

インフラ構築フェーズから次工程（アプリデプロイ、結合テスト、本番運用）へ引き渡す際のチェックリストを事前に合意します。

インフラ引き渡し判定チェックリスト（DoD）

• [ ] 踏み台（SSM Session Manager / Bastion等）経由でのログイン・作業権限が整っているか
• [ ] 指定されたセキュリティグループ/FWでアプリに必要なポート疎通が確認できているか
• [ ] DB（RDS等）への接続文字列・認証情報（Secrets Manager等）が安全に引き渡されているか
• [ ] VPCエンドポイント（S3, ECR等）経由のプライベート通信が正常に通るか
• [ ] CloudWatch / Datadog等の監視エージェントが導入され、メトリクス収集と発報テストが完了しているか
• [ ] バックアップポリシー（AWS Backup / スナップショットライフサイクル）が有効化されているか

この条件を満たさない限り「次工程に進めない（ゲートを通過できない）」ルールを設けることで、後工程での手戻りを完全に遮断します。

ガントチャートを形骸化させない！インフラWBSの進捗管理ルール

どれだけ美しいWBSを引いても、作った瞬間からプロジェクトの現実はズレ始めます。WBSを「生きた進捗管理ツール」として機能させる運用ルールが必要です。

① 「着手トリガー」と「完了条件」をセットでチケット化する

WBSは大日程・中日程のロードマップとして使い、日々の実務管理は課題管理システム（Jira、Redmine、Backlogなど）にブレイクダウンします。

チケットを作成する際は、タイトルだけでなく「何が揃ったら着手できるか（着手トリガー）」を明記します。

• チケット名： 開発環境VPC・RDS構築
• 着手トリガー：
  • 顧客CCoEからのAWSアカウントID受領（処理待ち完了）
  • 開発用IAMロールの権限付与完了（処理待ち完了）
  • 通信要件定義書（v1.0）のFIX（調整完了）
• 完了条件（DoD）：
  • Terraform apply完了ログの採取
  • 踏み台経由でのRDS接続テスト完了

着手トリガーが満たされていない作業に手を付けさせないことで、仕掛かり中のタスクが宙に浮くのを防ぎます。

② 週次定例ではなく「クリティカルパスのイベント日」でアラートを鳴らす

毎週金曜日の定例ミーティングで進捗を確認していると、水曜日に発生した「専用線工事の遅延連絡」や「クオータ審査の差し戻し」への初動が2日遅れます。

定例会議のサイクルとは別に、クリティカルパス上にある外部イベントの「事前確認日（リマインド日）」をWBSにマイルストーンとして埋め込みます。

• Direct Connect開通日（Day X）の5営業日前：キャリア側工事体制、構内配線工事の完了確認（調達確認）
• アカウント受領予定日（Day Y）の3営業日前：CCoE部門へ進捗状況のリマインド（処理待ち確認）
• DNS切替日（Day Z）の7日前：TTL値短縮（300秒化）の実施確認（処理順番確認）

「当日になって初めて申請が止まっていたことを知る」という事態を、先行リマインドによって仕組みで排除します。

③ 遅延の兆候が出た瞬間の「エスカレーション3択」

クリティカルパス上の外部要因が遅延した場合、現場レベルの残業ではリカバリできません。遅延が確定した瞬間、PMは関係各所に対して「3択のトレードオフ」を即座に提示します。

1. 構成・手段の変更（暫定バイパス）：
   • 例：Direct Connectの開通が遅れるため、一時的にインターネット経由の「Site-to-Site VPN（IPsec）」を即日敷設し、アプリチームの疎通確認を先行させる。
2. スコープの調整（段階的リリース）：
   • 例：一部インスタンスタイプのクオータ緩和が間に合わないため、検証フェーズは別リージョンまたは下位スペックのインスタンスで先行検証する。
3. リリースタイムラインの変更（正式な期日変更）：
   • 例：顧客側のセキュリティ審査・承認遅延に起因する場合、自社努力での吸収が不可能な理由と影響範囲をロジカルに示し、サービスイン日程のリスケジュールを正式合意する。

品質を削って無理に帳尻を合わせようとするのは最悪の悪手です。代替バイパスや客観的な選択肢を早期に示すことこそが、エンジニアとしての信頼を守る道です。

明日から使える「インフラ工程管理チェックシート」

WBSの作成時、およびプロジェクト進行中に以下の項目をセルフチェックしてください。

【計画・WBS作成フェーズ】

• [ ] すべてのタスクは動詞ではなく「成果物（名詞）」で定義されているか？
• [ ] 「自社作業（工数）」と「外部待ち時間（リードタイム）」が明確に分離されているか？
• [ ] 【調達】 ハード本体・周辺部材、回線引き込み工事、クラウドアカウントのリードタイムを確保したか？
• [ ] 【処理待ち】 社内決裁、顧客稟議、セキュリティ審査（CAB）の開催日と承認リードタイムを組み込んだか？
• [ ] 【調整】 システム停止メンテ枠、対向先テスト可能ウィンドウ、ブラックアウト期間をカレンダーに固定したか？
• [ ] 【処理順番】 L1〜L7の階層順序、DNS切替前のTTL短縮（切替7日前・300秒化）が直列に結合されているか？
• [ ] 個別タスクの隠れバッファを排除し、プロジェクトバッファを一元管理しているか？

【進行・運用フェーズ】

• [ ] 各タスクの「着手トリガー」が満たされていることを確認してから作業に入っているか？
• [ ] クリティカルパス上の外部イベント（アカウント受領・回線開通）の数日前にリマインドを行っているか？
• [ ] アプリチームへの引き渡し条件（DoD）を満たしているエビデンスを揃えたか？
• [ ] 遅延が発生した際、暫定VPN敷設などの「代替バイパス」を即座に提案できているか？

インフラのWBSとは、単なる自社の作業予定表ではありません。クラウドベンダー、通信キャリア、社内セキュリティ部門・CCoE、そして顧客を巻き込んだ「システム稼働までの合意形成ロードマップ」です。

仮想化やクラウドの利点を活かしつつ、「調達・処理待ち・調整・処理順番」の4つの依存関係を先回りしてWBS上に可視化することで、「待ち時間」に振り回されない堅牢なプロジェクトマネジメントを確立していきましょう。