要件定義（運用保守）タスクの進め方の概要

今回は運用保守の要件定義タスクの進め方について、概要を解説します。

システム構築フェーズの最初の工程は要件定義工程です。

要件定義工程はアプリケーション開発、インフラ構築、ユーザー展開、運用保守、移行、他システム対応、それぞれの観点に対して各種要件を固め、計画を具体化する工程です。
システム構築フェーズの一番最初の工程であり、お客様との密なコミュニケーションが必要で難しい工程でもあります。

今回は要件定義工程の中でも運用保守で実施する要件定義を解説します。

要件定義工程は経験がものをいう上流工程ですので、上流工程に強くなりたいと思うなら、知識を吸収して機会があれば積極的にチャレンジしてみると良いと思います。

運用保守における要件定義では運用要件定義を行う
運用要件定義では運用要件を定義し実現方針を定める
まとめ

運用保守における要件定義では運用要件定義を行う

運用保守における要件定義の作業は運用要件定義であり、運用要件を定義し実現方針を定めることです。

要件定義（運用保守）のアウトプット（成果物）としては、要件定義書の内、運用要件に関するパートになります。

それでは詳しく見てみましょう。

運用要件定義では運用要件を定義し実現方針を定める

運用保守に関する要件全般を運用要件と呼びます。

運用要件は、主にシステムを運用する人の立場から「システムに対して運用上こうあって欲しい」という要望を基にコストや実現性・リスクを鑑みて定めます。

運用要件は非機能要件の一部であり、独立行政法人のIPA（情報処理推進機構）が無償公開している「非機能要求グレード」では「運用・保守性」と分類されています。

非機能要求グレード

システム構築の上流工程強化（非機能要求グレード）紹介ページ | アーカイブ | IPA 独立行政法人情報処理推進機構

情報処理推進機構（IPA）の「システム構築の上流工程強化（非機能要求グレード）紹介ページ」に関する情報です。

主な項目としては以下のとおりです。

運用時間（システムを利用できる時間帯、ユーザーが利用できる時間帯等）
バックアップ・リカバリー運用（対象、方法、頻度等）
監視運用（監視対象、監視方法、通知方法等）
ジョブ運用（バッチジョブの実行管理、障害通知・遅延連絡等）
サーバー運用（時刻同期）
セキュリティ運用（パッチ適用）
運用環境（保守用に開発環境・テスト環境を継続利用など）
運用体制（登場人物、役割、連絡手段など、内部統制を考慮）
インシデント・問題・変更・リリース管理（ITILに準拠）
構成管理（ハードウェア・ソフトウェアの製品名・バージョン・数量・保守期限など）
ログ管理（ログの種類、保管期間など）
ユーザーアカウント管理（ユーザー管理、アクセス権限管理）

「非機能要求グレード」のこれらの項目に対し、まずは今回のプロジェクトで検討すべき項目を選定し、その絞り込んだ項目に対して要件と実現方針の見通しを立てていきます。

運用時間はお客様の一番の関心事項

運用要件の中でシステム利用者に大きく影響するのが運用時間です。

運用時間には、

システムが稼働する時間（例.計画停止を除く24時間365日）
ユーザーが利用可能な時間（例. 平日9:00-22:00）
サポート時間（例. 平日9:00-17:30、その他緊急時は都度対応）

など種類があります。

特に「ユーザーはいつシステムを利用できるのか（いつ利用できないのか）」は業務やシステムの利便性に直結するので、お客様の強い関心事になります。
お客様からは「利用可能な時間帯を長く確保すべきだ」というご意見が大抵出てきます。

むぅさん

経験上、特にユーザー思いの熱い方が声を挙げられ、その声は大きい（強い）傾向にあります

このあたりは運用コストとのバランスになります。
例えば、24時間365日稼働させるシステムでは、平日のみ稼働している場合と比べて土日祝日も日中夜間を問わず何かあれば対応が必要になりますので、その分の作業も増えてコスト増につながるわけです。

むぅさん

業務時間以外に運用保守作業を実施した時は基本的に代休を取得することになりますので、平日日中帯はそれを加味して少し体制を厚くしておく必要があります。そうなるとコスト増につながります。
また、土日祝日の対応は単価が高く設定される契約もあります。

利用シーンを想定して本当に必要な時間帯に限定してコストを抑制するのが個人的には良いとは思いますが、お客様の要望およびその背景を鑑みて臨機応変に対応します。

むぅさん

土日祝日も稼働するシステムは、お休みの日もいつ障害の連絡が来るかヒヤヒヤしますので、コスト増だけでなく運用担当者の気持ちとしてもしんどいです。。
できれば「基本的に平日のみ稼働で、四半期毎の決算期直後だけ休日稼働もあり」ぐらいだと、コスパも心の平穏も高いと思います。

バックアップ・リカバリー運用はインフラ構築と役割分担を明確にする

バックアップ・リカバリー運用については、インフラ構築でも要件定義や設計・実装・テストを進めることがあります。

どちらがメインとなり作業を進めるかや、バックアップ・リカバリーについて作業の全体像を可視化して各作業に対して役割分担をすり合わせることで、作業の重複や抜け漏れを防ぐようにしましょう。

監視運用・ジョブ運用は製品導入とアプリ・基盤と密な連携がキモ

運用作業は全て人手で実施すると、コストの高止まりや作業ミスにつながるため、一般的にツール導入による自動化を検討します。

特に監視運用やジョブ運用については、昼夜問わず常時発生する作業のため、人手でやるのは現実的ではありません。
そのため統合運用管理ツールという製品を導入することが多く、一番有名なのはJP1（ジェー・ピー・ワン）という製品です。

統合運用管理ツールは、あるシステム専用に導入するのはコスパが悪く、企業のシステム全体で利用することが多いので、既に統合運用管理ツールが存在する場合にはそれに相乗りするのが一番良いです。

むぅさん

既存になく新規に導入する場合も、今回のシステム専用ではなく、他のシステムも利用する前提で構築やルールを定めると良いです。

内部統制を意識した運用体制・運用環境・管理方法を定める

ITシステムの運用は、不正によるトラブルを防止する目的で、企業では内部統制によるITシステムの運用のルール化がなされます。

例えば、以下のようなものです。

運用保守する人を管理者・運用者・開発者と3つの役割に分けて、本番環境のサーバーで作業を実施できるのは運用者のみとし、運用者は運用手順書に記載されている操作のみ可能、のような制限を設けます
開発者がアプリケーション保守（アプリケーションの改修やテスト）を行うために、本番環境以外に開発・テスト環境を設けます
運用上発生したことをトレースできるように、インシデント管理、問題管理、変更管理、リリース管理を行い、発生都度記録を残します

企業内に内部統制のルール・ガイドラインがあればそれもインプットにして、条件を全て満たすように運用要件を検討します。

ちなみにITILに準拠してインシデント管理、問題管理、変更管理、リリース管理を行う必要がある場合、Excelによる台帳管理は管理が煩雑でミスも起こりやすくなります。
管理を効率化するためのツールをITSM（IT Service Management）ツールやインシデント管理ツールと呼びます。

むぅさん

この手の製品を導入する場合も、製品コストが増えたり、導入・利用準備作業が増えて作業コストが増えますので、実現方針として決めておきます。