統合ストレージ調達のRFPをどう作るか

　4. 保守要件

■定期保守の有無の確認

　昨今の統合ストレージ基盤は、定期保守（Preventive Maintenance）と呼ばれる作業をあまり実施しないことが多くなっています。ただし、不定期に予防保守を目的とした、マイクロコードのアップグレードなどが推奨されるケースも多くあります。実際に運用フェイズに入った後に、想定外の保守を実施していくことは望ましい状態ではないため、あらかじめ、どの程度の頻度で保守することを検討すべきか、その際、自社のポリシーを鑑みた場合、業務の停止を前提とするか、活性保守で休日作業とするかなどを概要レベルでは決定できるような、情報提供を受けることをお勧めします。

■ベンダ保守ポリシーの確認

　障害時など、提案機器に対する修復作業の対応は、ベンダにより若干異なります。リモートでの対応を基本としているか、とりあえず、技術員がオンサイトに駆けつけるかなど、ベンダの基本的な保守対応ポリシーを提案時に確認しておくことも有効です。特に、ベンダを変更する場合などは、従来のベンダと異なる対応となる場合もあり、それにより、自社体制などの見直しや、従来のベンダ機器との並行期間における管理の複雑性への対応等をあらかじめ捕らえておくことも必要です。

　状況によっては、ベンダの基本保守ポリシーが受け入れられない場合もあると思います。その場合は、契約後の交渉ではなく、契約前に合意できるレベルまで交渉することが望まれます。

■自社の基盤ライフサイクルとベンダ・サービス提供の保障期間の確認

　提案機器のライフサイクルに関する情報も重要です。各提案機器／ソフトウェアの保証期間（サービス可能期間）や、サービス終了の情報提供のタイミングなどの情報を得てください。自社のほかの基盤のライフサイクルを検討し、運用を継続していく際に考慮すべき事項や、イベントを捉えておくこと、ベンダによる差異なども確認しておいてください。

■機器保守時の影響度合いの確認

　ほとんどの統合ストレージ基盤は、活性保守が主流となっています。ただし、100%既存環境に影響を与えずに保守ができる場合は、そう多くありません。何らかの影響を与えますが、多くの場合は、十分に容認できるレベルの影響です。

　ただし、業務システムの要件によっては、受け入れがたい場合もあるかもしれません。性能への影響、可用性への影響が主な検討項目ですが、自社の業務要件として容認可能なレベルかどうかを判断するための情報を入手してください。

■保守情報の提供内容、および頻度

　提案時の情報は、その時点では正確なことが保証されています（ほとんどの提案書に書かれている文言です）。ただし、運用開始後（数年後）、その情報は正しくない場合があるということをこの文言は伝えています。

　利用者側としては、定期的に、保守情報（サービス期間や、他社障害情報、予防保守情報など）を入手し、運用計画を適宜見直すことが求められます。そのため、必要な情報の種類と内容、およびその提供頻度に関して、提案時にベンダとある程度は合意を得ておくことが望まれます。

■無償保守、有償保守の区別

　ベンダ提供の保守活動の中には、無償作業と有償作業が存在します。昨今の傾向としては、“人が動く場合には必ず費用が発生する“　という基本的な考えがあり、統合ストレージ基盤でも同様です。提案時の契約に含まれる保守費用で、どこまでの作業、対応が含まれるか？ 保守費用の範疇外の作業としては、どのような種類のものがあるか？ などは利用者として把握しておく必要がある項目の1つです。

　5. プロジェクト要件

■構築プロジェクト体制とプロジェクト推進方法の確認

　ストレージ基盤構築プロジェクトの推進体制、方法なども、提示を受けるべき項目の1つです。ベンダによりその特徴は変わってきます。プロジェクト要員がオンサイトに常駐（半常駐）の形式で推進していく場合、必要最低限の会議と作業で対応する場合、管理者（PM）が複数用意される場合、技術者（SE）と管理者（PM）が兼務の場合などです。また、10名程度のプロジェクト体制だった場合でも、ほとんどのプロジェクト要員が、ベンダの協力会社になっているような場合などもあります。

　提案を選択する時点の評価項目の1つにもなります。過剰に重厚な体制をとる場合、費用が高くなっている場合も考えられます。

　調達規模や、ベンダに依頼したい役割、自社の管理体制や習熟度を比較して、最も効率的で効果的な体制で臨んでもらうことが必要です。特に、自社のIT基盤を大幅に変更するような重要な案件の場合は、推進するプロジェクトの体制や実施方法などまで含んだ提案を求め、評価をしていくことが重要です。統合ストレージ基盤であってもその例外ではありません。

■プロジェクト・フェイズの確認

　一般的なプロジェクト管理の話になりますが、調達規模が大きい場合は、基盤構築プロジェクトをいくつかのフェイズに分けることが重要です。場合によっては、フェイズ毎に契約することも有効です。少なくとも、要件定義、論理設計、物理設計、実装、試験、移行、運用引き継ぎ、運用開始などをいくつかのフェイズに分割し、確実なプロジェクト進行が実施できるよう心がけなければなりません。

■必要となる内部工数の確認

　統合ストレージ基盤の構築プロジェクトは、ベンダ要員だけでは完遂しません。特に既存ストレージ基盤からのデータ移行などが含まれる場合はこれが顕著です。自社の要件の伝達や、確認、業務システムとの要件調整、移行スケジュールの調整や、機能テストの確認、納品物の確認、運用設計、運用引き継ぎ、不運にもプロジェクト推進中に障害が発生してしまった場合の対応など、それなりに内部要員の工数が必要となります。

　ベンダとの役割分担を合意し、必要な内部要員の調達を実施することになります。この検討に必要な情報を入手しておいてください。

■プロジェクト完了条件の確認

　統合ストレージ基盤構築プロジェクトの場合、業務プロジェクトとして実施する場合は、包括的にプロジェクト・スコープが定義され、その中の基盤構築プロジェクトとしての完了基準はある程度明確になることが通例ですが、ストレージ・サービス基盤として導入する場合、どの程度、テストをすべきか、範囲をどこまでにするか、などの決定は、提案時、調達時にあまり明確に定まっていない場合も少なくありません。

　機能テスト、負荷テスト、可用性テスト、ユーザー受け入れテスト（UAT）、運用引き継ぎ、納品物の種類と内容レベルなど、あらかじめ可能な範囲で、合意が得られるよう、提案を求めることが肝要です。

　6. 運用管理支援要件

■基盤構築完了後の支援サービスの確認

　運用引き継ぎが行われた後、構築プロジェクトが完了した後、運用が本格的に始まってから、想定していなかったさまざま問題、課題が発生することもあり得ます。バックアップ運用等、自社運用として実施する基盤などでは要注意です。ベンダのヘルプデスクを利用して対応することも可能ですが、基盤構築完了後、一定期間、あらかじめベンダの技術者の支援が仰げるようなサービス契約を検討することも一考の価値があります。

　自社要員への運用引き継ぎ、技術移管が、安全なレベルになったと確認できるまで、ベンダ技術者にその運用の主体を委託することも可能です。基盤の規模、サービスレベル、自社要員（外注要員）の技術的成熟度等を考慮し、効果的、効率的にストレージ基盤の運用ができるよう検討をしてください。

■必要となるトレーニング、自社調達すべき運用管理要員の確認

　自社要員で運用を実施することを想定した場合、必要な技術習得のためのトレーニングの費用、別途、外注要員を調達して運用を委託する場合のスキルセットや人員構成の確認なども検討する必要があります。

　この部分も含めて、ベンダに提案を求めるのも良いですし、必要な情報のみの提供を依頼する形でも良いと思います。いずれにしても何らかの投資が必要となる領域です。

●●●

　これらの内容を、簡潔にまとめてRFPを作成します。ほかの基盤調達や業務システムプロジェクトなどで、自社のRFPテンプレートなどが存在している場合は、それを参考にし、カストマイズをしていくプロセスとなります。

　一度、詳細なRFPを作成していれば、次回もそのフレームを使用できますし、別の担当者が実施する場合もある程度の品質を確保できます。

　今回紹介した項目は、必要項目の100％を網羅している訳ではありませんが、統合ストレージ基盤調達時のRFP作成の際に少しでも参考になれば幸いです。

4/4

Index
統合ストレージ調達のRFPをどう作るか
	Page1 統合ストレージの調達 1. 機能要件
	Page2 2. 運用要件
	Page3 3. 管理要件
	Page4 4. 保守要件 5. プロジェクト要件 6. 運用管理支援要件