ある企業では，設置以来丸5年を経過したシステムが，サーバ150台を数えるほどになっていました。そこで，ハード，ミドルウェア等を最新版へアップグレードし，さらにVMwareなどの仮想化ソフトウェアの採用を検討しながら，サーバ群を一気に13台に集約させようと考えました。

今回は，ユーザ企業はいかにして事業要件からプロジェクト発足のための未来図を作り，予算を確保し，案件化していくのかをストーリーをわかりやすくするために，架空のプロジェクトを利用して，案件の定義付け，ハード，OSの選択，プロジェクト化まで凝縮して紹介したいと思います。

案件の誕生まで

あるユーザ企業が，この連載の第1回に記載したポリシーで事業サービスを提供していましたが，システム的には丸5年目を迎え，Webサーバが100台と，Webサーバが参照するためのDBサーバが50台を数えるまでに増大。これらの設置，監視，保守に関しては全て外部委託されていました。

ここ数年はシステムとして安定期に入っているため，サービス施策に対応したプログラムの改修を行うといった運用的な局面でした。しかしながら，ハードウェアに関しては，同型サーバの販売打ち切りや，導入されている商用ミドルウェアバージョンのEOSL（End Of Service Life：サービス提供終了）等を迎えはじめてきたのをきっかけに，ハード，ミドルウェア共に最新版へアップグレードすることにより，保守の延命，スペック向上による台数の削減ができるのではないかと考えました。

そこで「今のシステムは何台に集約できるか？」「⁠業務アプリケーションの改修対応は必要なのか？」「⁠運用は変わってしまうのか？」等といった疑問に，どのように対応していくのか検討しました。

①大義名分を明確に

これはどのようなプロジェクトでも行っているように「目的」を明らかにする事にします。今回は，以下のように定義付けます。

• 事業（サービス）要件としては，提供サービス機能，応答などのSLAを共に現行踏襲とする。
• 運用要件としては，上記対象のすべてのサーバ／ミドルウェアを最新機器に置き換え，保守期間の延命を実現させる。
• 努力目標として，初期投資より性能向上が実現された分の台数を減少（集約）させ，運用費用軽減より費用の回収を実現させる。

②プロジェクトを進めるために

上記のような要件から予算を確保してプロジェクトをスタートさせるための資料に記載する内容を検討します。 これは，上記のような状態で，既存ベンダやSIerに向けて「弊社でサーバの入れ替えを行うことになったが，何台くらいになる？ 見積もりはくらいかな？」等と言っても，予算確保できるような実現的な計画，見積もりが出てくることはなかなか難しく，経営側へ説明をしても理解を得られない可能性があるためです。そこで，以下のように検討してみます。

・現行踏襲の定義を行う。

サーバのロードアベレージが高い状態でない場合は，上限のセッション数等，現行システムが保証できるであろう数値の明確化を実施する。

・5年前と直近のハードウェアはシステム係数を利用して性能向上を仮定する。

今回はわかりやすくするため，一律5倍の性能向上としました。

・ミドルウェアの検討は，現行プロダクトのバージョンアップと，同等のオープンソフトウェアの両方を検討する。

・上記の検討結果を検証する期間を設け，何を検証し，どのような結果を提出するか定義する。

これを元に机上にて検討を行い，結果については集約の目標に関する概算見積もりとともに，いったん本番対応までの全てを計画予算としてユーザ企業の経営側の承認を仰ぎ，プロジェクト開始とします。またこの際，集約後の運用費用軽減から損益分岐を割り出し，投資回収等も明記できればなお良いでしょう。

計画予算から実行できる部分は，机上の検討の裏付けとして，最小構成での検証を行い，本番対応部分として残分対応の信憑性を結果として取得することと，本番対応部分の再見積もりまでとします。

最悪，机上の計算に謝りがあった場合等は「最新ハードウェアでも思いのほかパフォーマンスが出ずに集約ができなかった」「⁠ミドルウェアのバージョンアップにより，業務アプリケーション側にクリティカルな対応が必要になった」といった場合の判断を行うべく，リカバリ可能にする必要があります。