非機能要件の中の運用保守の説明（後編）です。
運用と保守は、会社によって境界が異なるので、ここでは境界を気にせず記載します。
４．障害対応
障害を検知した後の運用フローを関係者で合意します。
運用フローは大きくは、営業時間中と営業時間外で分かれます。
特に営業時間外については、ベンダーとの合意に苦戦することが多いです。営業時間外であっても障害対応を正攻法で要求すると、保守費用が非常に高額になります。そもそもベンダーによっては会社として引き受けてくれない場合もあります。
実態は営業時間外の障害でも、駆けつけて対応してくれるベンダーが多いのですが、契約レベルでは営業時間外はサポート対象外となる場合が多く、公式にはサポートしていないのに、非公式でサポートしているという、現場泣かせの要件です。
ベンダーだけでなくユーザーの所管部署も、営業時間外の連絡は嫌がります。エンドユーザーへの連絡は、ユーザーの所管部署が担うことが多いのですが、営業時間外に障害が発生した場合、ユーザーの所管部署は連絡を受けることを嫌がることが多いです。
また障害の種類によって、どこまで連絡をするかが変わるので、これも明確にします。エンドユーザー全員に周知が必要が障害もあれば、システム部門内だけの周知で済ませる障害もあります。それらを分類して、運用フローに反映します。
ステークホルダーとの連絡ルート以外にも、手続きのフローも必要です。品質部門への連絡や上司へのエスカレーション等です。
これらはシステムの実装に影響のあるものではありませんが、保守の費用に直結する要件でもあり、また関係者での合意が不十分だと、実際に障害が発生した際に連絡が不十分だとクレームを受けやすくなります。クレームを受けてから、慌ててフローを決めようとしても、事前に決めておかなかった負い目があるため、ユーザー部門優位のフローになってしまうことがあるので、対等に交渉できる要求定義や要件定義の段階で合意することが重要です。
５．製品保守
スクラッチ開発したアプリケーション以外の製品保守について、ベンダーとの役割分担を合意します。
対象は、サーバーのOS、IISやTomcat、Oracle等のミドルウェア、アプリケーションのパッケージ等、全てのソフトウェアを洗い出し、一つ一つに対して保守の役割を明確にします。
ソフトウェアのアップデートやアップグレードは実施するか？実施する場合には有償か、保守費用に含まれるのか、特にセキュリティーパッチは、情報の入手先や入手頻度、パッチ適用のタイミングまで関係者で合意をします。
また導入した製品のライフサイクルにも注意が必要です。
通常、最新バージョンのソフトウェアは導入せず、品質の安定した一つ前くらいのバージョンのものを導入します。場合によっては諸処の事情でもっと古いバージョンを導入することもあります。その場合、稀にEOLが１年後のような製品を導入しようとするベンダーがいるので、注意が必要です。
ソフトウェア以外にも、ハードウェアも導入しているのであれば、ハードウェアについても保守の役割の整理が必要となります。
６．環境
本番環境以外の環境が必要な場合には、その環境に対しての要件もまとめます。
例えばステージング環境を用意する場合、一日一回、本番環境から全データをコピーする仕組みを作ったり、開発環境もマスターデータだけは本番環境からコピーする仕組みを作ったり、といった要件が考えられます。
特に重要なのは、その環境の用途を明確にすることです。
例えばステージング環境がなく、開発環境だけがある場合、本番開始後は性能試験が困難になります。また本番環境が冗長構成の場合、開発環境はシングル構成の場合が多いので、その場合にも冗長構成に関係するテストはできなくなり、基本的にはアプリケーションのテスト用途だけになります。
そのように本番稼働後にできないことを明確にして、関係者で合意をすることが重要です。
７．その他
時刻同期の方法やサービス提供時間外の画面についても、どのような対応とするか決める必要があります。
サーバーの時刻同期は、どのNTPサーバーを利用するのか、あるいは利用しないのか。OracleRACのようにデータベースのクラスタリングを利用する場合には、クラスタリングのサーバー間での時刻一致が大前提のことが多いので、より慎重な検討が必要です。
また時刻同期の方法が、ミドルウェアやアプリケーションにどのような影響を及ぼすのかも事前に確認し、時刻差によって時刻同期の方法が異なる場合（stepモード／slewモード）には、チューニングも実施します。
うるう秒の扱いについても整理しておくと、本番後に慌てて調査をしなくて済みます。特にタイムスタンプを取得するようなシステムは、時刻認証局側のうるう秒の対応を把握しておく必要があります。
サービス提供時間外にユーザーがアクセスした場合の、応答画面についても考慮が必要です。メンテナンス画面をロードバランサーで出すのか、Webサーバーで出すのか、後者の場合で冗長構成でない場合には、Webサーバーをメンテナンスする場合には、メンテナンス画面はどうするのか、等を決めていきます。
【振り返り】
運用保守の説明（後編）は以上で終了となります。次回は移行の説明をしていきたいと思います。
①可用性
②性能
③拡張性
④運用保守
⑤移行
⑥セキュリティ
⑦ユーザービリティ／アクセシビリティ
⑧システム環境
