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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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