インフラプロジェクト入門~全体概要編~

【はじめに】
 インフラ構築プロジェクトは、システムやアプリケーション開発と違い、基本的に機器(サーバ、
ルータ、スイッチ等)のEOS(End Of Service)が起因で発生することが多いです。
  システムやアプリケーション開発の一部としてサーバ数台やルーター2台(メインと
バックアップ各1台)の手配が発生する小規模な場合、システムやアプリケーション開発で要件は
決まっていることがほとんどです。サーバ、ルータ、スイッチ等のEOSによる周辺機器も含めた
一斉更改という大規模な場合、本稿で全体の流れと概要の理解にお役立て頂けますと幸いです。

下記が一般的なプロジェクトでの工程分類になります。

インフラプロジェクトの場合、工程分類や実施内容が異なりますので、
以下で説明をさせていただきます。

【業務要件定義】
 利用部門へのヒアリングになります。インフラプロジェクトの場合、全システムへの影響が
 あるため、主にボードメンバーやシステム部内で同期を取り、今後計画している
 他プロジェクトと平仄を合わせ、サーバやネットワーク機器の台数、回線速度を定義します。

【開発要件定義】
 ROI(Return Of Investment)を考慮し、機能、性能、運用、コストを軸に要件を定義します。
 何を優先するかで非常に意見が分かれますので、PM、PL、PMOの調整力が問われます。
 またRFP作成の元ネタになります。

【RFP(Request For Proposal:提案依頼書)】
 RFPを作成し、ベンダー選定を実施します。サーバ、ネットワーク機器、データ回線、
 音声回線等で別々のRFPを作成し、別々のベンダーを選定するか、
 全部纏めて提案ができるベンダーを作成するか、プロジェクト内容によって
 依頼方法が変わります。提案内容も重要ですが、
 時間とコストを軸にベンダー選定が必要です。

【システム化設計】
 ベンダー選定後に、社内稟議用にシステム化の要件を具体化します。
 スケジュール、コスト、ROI等を考慮し、どれだけBenefitがあるかをドキュメント化します。
 稟議が通れば関係者を招集し、KickOff会議を実施します。
 スケジュール、連絡体制を周知し、正式にプロジェクトがLaunchされます。

【基本設計】
 要件を実現する処理機能の設計書を作成します。また運用設計書も合わせて作成します。
 基本設計書の中には、運用設計の概要を明記し、運用設計書の中で方針や体制等を明記します。
 運用手順書等の詳細は、ユーザーテスト(UAT)工程以降で作成します。

【詳細設計】
 インフラプロジェクトの場合、ネットワーク機器のコンフィグやサーバのクラスタ構成、
 バッチサイクル等の詳細が明記されることになります。機器仕様書、
 IPアドレス一覧、物理/論理構成図等の別紙が作成されます。

【プログラム製造(単体テスト)】
 インフラプロジェクトの場合、単体テストになります。導入する機器の稼働確認や、
 不具合がないかの確認がメインになります。

【結合テスト(ITa)】
 インフラプロジェクトの場合、サブシステム単位で行うテスト工程は、ほぼ無いため、
 結合テスト(ITb)と合わせて、結合テスト(IT)としたほうがベストです。

【結合テスト(ITb)】
 上記の通り、結合テスト(IT)とし、機能、正常性、障害、結合、負荷テストを実施します。

【システムテスト(ST)】
 他システムを繋いだテストと運用テストを実施する工程です。疑似環境では再現できないテストを
 本番、UAT環境で週末や深夜帯に実施する工程になります。

【ユーザーテスト(UAT)】
 インフラプロジェクトの場合、ユーザーは主にシステム部内の人間になります。
 プロジェクト内容によっては、導入・移行工程を合わせても問題ありません。
 またプロジェクト完了に間に合うように、運用手順書作成を開始する必要がありますし、
 導入・移行審査会を実施し、問題ないことを確認する必要があります。

【導入・移行】
 構築したシステムの本番リリースのための導入・移行工程になります。
 コアのL3SWやFirewallをいきなり更改することはできませんし、
 配下に色々ば機器が繋がっています。データセンターに設置されている本番機器の
 メンテナンス時間は決まっていますので、他のプロジェクトやチームとの調整が必要です。

【Tips1】
 プロジェクトの品質とベンダー管理の目的で以下の工程では、
 開始基準と終了基準を実施してください。
  基本設計
  詳細設計
  プログラム製造(単体テスト)
  結合テスト(IT)
  システムテスト(ST)
  導入・移行

スケジュール、成果物、達成度等の何をもって開始し、終了とするかの基準(Criteria)を
予め決めておき、プロジェクトの手戻り防止策、またIT監査の証跡としても必要になります。