システム停止を前提に業務/サービスを考えるならば、どの程度ならシステムを止めても業務に影響しないか、経営層や利用部門との合意が必須だ。それには、システム停止が業務に及ぼす影響を把握し、ランク付けするとよい。
予算が許す限りできるだけシステムの可用性を高めるべき――。多くの経営層や利用部門はこうした認識を持っている。可用性の適正レベルに対する認識がズレているまま要件定義を進めると、必要以上に“手厚い”システムが求められる。
認識のズレをなくすために有効な方法として推奨したいのがシステムのランク付けだ。IT部門から稼働率や停止時間で定義したランクを示し、経営層や利用部門とともに検討して適切なレベルに落とし込む。要件定義の段階で、プロジェクトマネジャーが主導して合意形成していく。
経営層や利用部門に納得してもらえるランク付けの例として東京海上日動システムズの取り組みを紹介しよう。同社の平川 歩氏(ITサービス第一本部 ITSM推進部 兼 調査企画部 兼 経営企画部 担当部長)は「システムの可用性をAからDの4段階でランク付けしている」と言う(図1)。
最も停止時の影響が大きいシステムは「A」。稼働率(SLA)99.9%を保証し、停止許容時間は30分だ。一方、停止時の影響度が小さいシステムは、SLAが99.7%で、停止許容時間が約半日の「C」や「D」に分類される。CとDの差は、復旧の優先順位にある。
これらを基に、東京海上日動システムズでは、「非機能要件確認会議」を実施する。システム構築の要件定義段階で、非機能要件について利用部門とIT部門で合意を取る会議だ。「AからDのランクを示した上で、当事者である利用部門の要望を聞く。IT部門は過去の経験から、客観的に適切と考える可用性を提示する。そして、両者の合意が取れるまで協議する」(平川氏)。
難関となる合意形成をスムーズにするため、東京海上日動システムズは二つの点を工夫した。
一つ目は、ランク付けの項目を稼働率と停止許容時間のみとシンプルにしたことだ。RPO(目標復旧時点)やRLO(目標復旧レベル)は入れていない。その理由を「システムに踏み込んだ概念は、利用部門を混乱させてしまうから」と平川氏は説明する。
二つ目は非機能要件確認会議の段階では、可用性を高めるための詳細なコストを出さないことだ。「システム停止がビジネスに与える影響のみを考え、あるべき論で可用性を考える」(平川氏)。合意した可用性を「非機能要件リスト」に記載し、実際のシステムの設計・開発に入っていく。
簡単に決まらない非機能要件
システムの要件は業務処理を担う「機能」と、可用性や性能などの「非機能」に分かれる。非機能要件は技術的な要素が強く、経営層や利用部門に分かりづらい。十分な合意形成ができないまま、開発が進んでしまいがちだ。
可用性は「稼働率○%、許容停止時間△時間」と数字で提示しても、経営層や利用部門はピンとこない。そこで、ランク付けという分かりやすい手段を使って、「システムの停止がどの程度業務に影響するか」という観点で合意しやすくする。