皆様こんにちは、伊藤です。

先回までは、障害対応から障害低減への脱皮、開発体制へのフィードバックにつきまして述べでまいりましたが、今回は少し別の視点から、運用設計を考えてみたいと思います。

 

目次

システムの責任者って誰だろう

システムオーナーの役割と責任

運用設計における留意点

次回予告

システムの責任者って誰だろう

我々は日頃からシステム運用を行っているわけですが、そのシステムの「責任者」はどのような人なのでしょうか。私は、システム運用の責任者を努めていたわけですから、システムの責任者かもしれません。

また、システムを開発した責任者（プロジェクトリーダー）もいます。個別のホスト機やサーバーには管理者がいて、稼動状況、アクセス管理を行っています。これらの人も責任者といえるでしょう。

情報システム部全体に責任を持つ、情報システム部長が責任者である。ともいえるでしょう。

それ以外にも重要な責任者がいることをご存知でしょうか。それは「システムオーナー」です。

読者の皆さんは、ＥＵＣ（エンドユーザーコンピューティング）という言葉を覚えていらっしゃるでしょうか。第４世代言語というものと一緒に世の中に広まった考え方です。当時は、パソコンも普及しておらず、システムの利用者はバッチシステムか、ＴＳＯ端末を利用したオンラインシステムを利用していました。従って、処理ロジックのちょっとした変更や、画面見出しの文字変更というようなことでも情報システム部に改善依頼を行う必要がありました。

これらは、処理結果の分析を行うケースが多いので、そのような処理を利用者レベルで簡単に行えることを狙って、第４世代言語（プログラムレス言語とも呼ばれていました）が開発されたのです。

現在は、処理結果をＰＣ内で解析したり、グラフ化するなど、さらに進化した形になっていることは皆さんご承知のとおりです。

少し長くなってしまいましたが、このＥＵＣという言葉は正しい使い方でしょうか。

言い換えると、システム部門にいるとシステムを使う人をユーザーと言ってしまいがちですが、これは正しい表現でしょうか。私は少し違うと考えています。

「システム」を「住宅」に置き換えるとわかり易いのですが、「住宅」は、利用者は所有者であることが多いですね。この場合、メーカーの立場では「ユーザー」という表現も使いますが、「オーナー」と呼ぶこともあります。特に注文住宅では、施主と呼んだりしています。この場合、「オーナー」は、住宅の間取りや窓、玄関などの位置、骨格の選択、仕上げのやり方などなど、様々な要望を住宅業者に伝えます。住宅業者側からは、それを形にした全体図、間取り図などを提示し、やり取りを重ねていきます。

この際、「オーナー」からは、明るいリビングや、落ち着く寝室などの抽象的な要望も出てくるでしょう。例えば、落ち着く寝室とは、遮音性に優れた静かな部屋なのか、照明やカーテンなどで落ち着いた雰囲気を出すのか、ゆったりとした間取りをいっているのか、それこそ様々な要素を含んでいます。これらの要望は、建築業者からの提案や「オーナー」とのコミュニケーションを通じて、より具体的な要件に置き換えて図面に置き換えられていきます。そして、最終的には「オーナー」の要件を、建築業者が全体図、間取り図、建具仕様、仕上げ図、照明レイアウトなどの具体的図面類にするとともに、金額も示して、「オーナー」の承認の上、着工するわけです。

このとき、間取りや、照明などの最終決定は「オーナー」が行っています。つまり、この住宅の仕様は、「オーナー」が責任を持っているのです。

私が申し上げたいのは、「システムも同様である。」ということです。この場合、「オーナー」は、対象となるシステムを使って新しいビジネスを始めたり、自分が責任を持っている業務のやり方を改革しようとする業務部門の責任者です。情報システム部門は、建築業者に相当するわけです。

この業務部門の責任者が、システムの仕様を承認し、スポンサーとなって、システム開発が始まるわけです。この業務部門の責任者を当社では「システムオーナー」と呼んでいます。

つまり、情報システム側から、ひとくくりで「ユーザー」と呼んでいますが、そのシステムを使って業務を改革するため、その仕様に責任をもつ「システムオーナー」と、そのシステムを利用する「ユーザー」がいる訳です。弊社の例では、出張費清算システムは、経理部長が「システムオーナー」で、一般社員が「ユーザー」になります。

 

システムオーナーの役割と責任

ＳＯＸや、日本版ＳＯＸの対象となっている会社の情報部門の方はご承知かと存じますが、財務諸表作成プロセスの統制状況を評価する際、個別業務プロセスに含まれる情報システム処理は、手作業ではなく、自動処理とみなされます。それを担保するために必要な事項を「ＩＴ全般統制」といいます。情報システム部門は、「ＩＴ全般統制」が機能していることを外部監査人から監査されます。（図１参照）

▼図１：財務報告に係る内部統制の構造

一方、業務プロセス自体と、そこに組み込まれる情報システム(アプリケーション)の機能は密接に連携しており、業務プロセスの責任者は、システムの仕様や、運用状況に起因するリスクの認識と対応に責任を持っています。（例えは悪いですが、ユーザーの権限分離ができていないシステムを使用している場合は、システムの外側でその替わりの統制を設定しなければなりません）

そして、これらの統制状況は、業務処理統制状況として外部監査人によって監査されます。

ＳＯＸの場合は、財務に関わる業務に限定されますが、その他の業務プロセスの場合でも、そのプロセスに組み込まれるシステムの仕様は、業務プロセスの責任者（システムオーナー）の責任範囲なのです。

また、システムの運用状況についても、システムオーナーはしっかり状況を知っていなければなりません。情報システムの運用部門内でしか判らないトラブル（バッチ処理がエラー終了し、再実行された　等）の場合、通常とは異なるリスクが存在します。たとえば、再実行に伴うオペレータの介入、各種データベースのロールバックが完全に元に戻らない可能性などです。これらは、システムオーナーに確実に伝えられ、トラブルの内容に応じて業務プロセスの変更指示をおこなわなければ、間違った情報で業務を進めてしまう可能性があります。システムオーナーは、これらをあらかじめ想定して、正しい業務処理が継続できるよう、業務プロセスを設計しておく必要があります。

以上を踏まえ、システムオーナーの役割と責任を以下にまとめてみました。

１．   システムの開発、変更に関するシステムオーナーの役割と責任

①     システムの要件、許容コスト、納期の提示

②     システム仕様、コスト、納期の承認

③     システム導入後の業務プロセスの構築

④     システム利用者の教育、訓練

⑤     実業務を想定した、システムの総合テスト（機能、サービスレベルの確認等）

⑥     実業務への導入の可否判定

２．   システム運用に関するシステムオーナーの役割と責任

①     ＳＬＡ（許容サービスレベル）の設定

②     システムトラブル発生時の連絡体制の構築

③     業務側での間違いなどが発生した場合の連絡体制の構築

 

運用設計における留意点

次回予告

次回は、「運営設計と情報セキュリティ」についてお話をしたいと思います。