システム開発とシステム運用では少し異なったグラスボックスの仕組みが必要だとお話ししました。

しかし、その根底にある考え方、「発注者が標準を提示し、それに基づいて作業を実施してもらう」という考え方は同じです。

システム開発のグラスボックス化のポイントは、連載第１回でお伝えしたように、(1)やること（プロセス）の標準を持つこと、(2)作るものの標準（成果物の標準）を持つこと、（3）作り方の標準（アーキテクチャの標準・共通化・疎結合）を持つこと、の3つでした。

これに対し、システム運用保守のグラスボックス化には、(1)作業をメニュー化・手順化する、(2)作業に関する役割分担を定義する、(3)作業の管理の流れを定義する、の3つが特に重要です。

札幌市ではこれらの3つの標準について、ITIL(注1)をベースにし、非専門職員が中心の発注者である自治体職員が実際に運用作業を行うベンダーのマネジメントができるよう役割分担や作業の報告・承認などの流れを独自に定めた「運用・保守管理プロセス基準書」を作成しました。

3.1作業をメニュー化・手順化する

完成したシステムを正しく利用するために必要な日々の作業について、その作業全てを洗い出してメニュー化し、そのメニューごとに、初めて作業をする人でも理解できるレベルの手順書を作成します。

また、類似する作業パターンは標準化を行います。システム運用におけるグラスボックス化の第1歩は、いかにこれを徹底して実現できるかにあります。

システム開発のグラスボックス化では、プロジェクトすべてに万能な作業のやり方というのは存在しないため、プロセスレベルでの定義に留めていましたが、システム運用保守は、定型・定期かつ継続して行われる作業が中心であるため、作業の詳細レベルまで予め定義してしまいます。

人によって異なる作業を標準化し、それを手順化することでこれができることで、開発ベンダー以外でも運用保守の作業範囲や作業頻度、１回当たりの作業量、作業に必要なスキルレベルが把握できるようになります。

また、運用ベンダーがどのような作業を行っているかを発注者が常に把握できるようになり、作業にかかった時間の報告を受け、手順を比較することで作業量に関しての妥当性の把握がしやすくなります。

なお、これらの手順化はシステム開発後に作成するのは大変な労力になるので、システムの開発段階で、全ての運用作業をメニュー化して、メニュー単位に手順書を作成するようにします。

札幌市では運用作業として実施する作業を、「運用保守メニュー」という形で一覧化し、一覧化した全ての作業について運用保守手順書を作成しました（図2）。

運用作業の手順化は言うのはたやすいですが、実際にやってみると、手順にどのような内容を記載するかといったことや、どのレベルまで記載するかといったことなど、さまざまな悩みどころがあります。

全般的に手順書の作成はシステム開発者が分かっている前提で作るので、内容が薄くなってしまうといったことが起こりがちです。

必ず開発に関わっていない者が運用テストなどで手順書通り作業ができるかを受入テストなどで確認するといったことが必要です。

運用作業のメニュー化や手順書の作成を行い、実際に運用してみたところ、多くの気づきがありました。ここでは、そのうちいくつかのポイントについてご紹介します。

「メニュー化・手順化のポイント」

(1)作業項目に想定時間を入れておく

運用作業を洗い出して手順化する際に、その運用手順を実施するときに必要となる想定作業時間を洗い出しておくようにします。

想定作業時間がわからないと、全体として運用がいつ終わるのか、作業者はどの程度どの程度の時間まで常駐していなければならないのかといったことが分からず、場当たり的な対応を強いられることになってしまいます。

最初に稼働した住民記録システムの際には想定時間を洗い出しておらず、実際に運用してもてこの問題に気付きました。

そこで、次の税システムの稼働の時には、運用・保守メニュー一覧に運用・保守項目単位で「想定処理（作業）時間」を記載できる欄を設け、想定処理（作業）時間を事前に把握できるようにしました。

なお、想定時間については、想定と言いながらも、開発段階での運用・保守テストなどで時間を測定することで、精度の確保が可能です。

(2)リハーサルもメニュー化する

運用保守作業の中には、長時間のバッチ処理を伴う処理や再度実施するにはデータの復旧などに手間がかかる処理などについて、事前にリハーサルを実施しておくことが望ましい作業があります。

札幌市の一例では、選挙事務のシステムでの選挙人ハガキ作成の処理などについて、日程的にやり直しが利かないものについて、本番処理に作成に先立って事務・システム両面を兼ねたリハーサルを必ず実施しています。

このリハーサルの作業は、本番で実施する作業とは別にメニュー化しておくようにします。

これは、リハーサルの作業を定義しておかなければ、リハーサル、本番の2種類の作業が存在することが漏れてしまい、計画的な作業ができなくなってしまうからです。

(3)予期できる異常終了もメニュー化する

ジョブの異常終了は非定常な業務思うかもしれませんが、予期せぬ事態ではない場合があります。

リカバリー手順を整備しておくことで、手順に沿って回復が行えるケースが存在します。

また、回復に調査が必要な場合も、夜間に異常終了した処理の再実行がどれぐらい急務なのか、緊急連絡を行ってでも即時に対応が必要なものなのか、翌日以降で良いのか、翌日のオンライン開始までに完了しなければならないのか、それらができない場合、どのような対処が必要になるのか。

そういったことを手順書に記載しておくことで、夜間の限られた体制でも手順書に沿って対処が可能となります。

3.2作業に関する役割分担を定義する

誰がどの作業を行うか、誰が対応するかといった役割を定義します。

また、曖昧な場合は誰が判断するかということもあわせて定義しておきます。

主な役割として、運用保守担当者（業務）、運用保守担当者（基盤）、業務運用保守業者、基盤運用保守業者、オペレータといったものがあります（図3）。

札幌市の役割分担の定義では、運用作業のなかで、どの役割が作業を担うか曖昧となるケースが発生した場合は、運用保守担当者（基盤）が対応者を判断することになっているのが特徴です。

また、判断には技術的な要素が含まれるケースがありますが、その判断に必要な技術的な支援を運用保守業者（基盤）が行うようにしています。

「運用保守体制における役割」

運用保守担当者は、運用保守の業務の主体者となる情報システム部門の職員です。

このうち、運用保守担当者（基盤）は、システム基盤の運用・保守業務遂行の主体者で、基盤運用業者への指示や作業結果の確認を行います。

運用保守担当者や運用保守の委託先をまとめ、運用・保守業務の現場統括も行う立場です。外部システムやネットワーク担当との連携・調整も行います。

また、運用保守担当者（業務）は住民記録システムや住民税システムなど各業務システムの運用保守の主体となる職員です。

運用保守担当者（基盤）との連携・調整を行いながら、業務運用業者へ指示や作業結果の確認を行い、業務主管課との連絡窓口も担います。

運用業者は、運用保守メニューに記載された作業を実施、障害トラブル対応、ドキュメント管理などを行う受託業者です。

このうち、基盤運用業者は、システム基盤の運用業務の一部を委託された業者。運用保守担当者（基盤）の指示に従って業務を行い、その結果を報告します。

業務運用業者およびオペレータをまとめ、運用・保守委託先の統括も行う立場です。基盤保守業者はシステム基盤で仕様しているAIST-FWの保守業務を実施します。

業務運用業者は、各業務システムの運用業務の一部を委託された業者で、基盤運用業者やオペレータとの連携・調整を行いながら運用保守担当者（業務）の指示に従って業務を行い、その結果を報告します。

オペレータは、運用業務の一部を委託された業者で、主に監視業務やマシンルームでの定型的な作業を行います。運用保守担当者（基盤)の指示に従って業務を行い、その結果を報告します。

3.3運用作業の管理の流れを定義する

作業者と発注者の間で、作業の実施予定、実施結果などについて、どのようなやり取りを行うかなど、運用作業を管理するための流れを定義します。

札幌市では、実施者、実施日時が予め明確になっている定期作業の流れを定義する「作業スケジュールの管理」と、それ以外の、情報システムで発生する障害や改善すべき事象などについて、受付・記録・連絡・解決するための一連の活動を定義する「インシデント管理」の大きく２つの流れがあります。

(1)定型作業だからこそ確実に実施するための管理

「作業スケジュールの管理」が対象とする作業は、運用・保守メニュー一覧に記載された作業のうち、作業指示の要否欄が「要」となっている、実施者、実施日時が予め明確になっている定期作業です。

一方、これらの作業は定型的な作業であるからこそ、実施日の認識違いや作業の実施漏れなどが発生する危険があります。

そのため、これらの作業の流れは、インシデント管理の流れと比べて、実際の運用を効率的に行うことができるようにしつつ、「いつどのような作業が行われるのか」、「作業を実施した結果どうだったのか」について、発注者が日々把握できるように確認や報告を受けることができるようになっているのが特徴です。

バッチ処理のスケジュールや、運用保守メニューで定義されている作業の実施スケジュールに基づき、翌月、翌週、翌日の運用保守の作業の一覧をリスト化しています。

現在これらはシステムに登録された処理スケジュールなどから自動的に生成され、毎日、運用チェックリストとして帳票出力されるようになっています。

運用保守担当者は運用チェックリストを確認し、いつどのような作業が行われるか、実施して問題ないかの確認を行います。

運用保守担当者の確認が終わったリストは、運用保守作業の実施計画として運用保守業者に渡されます。

運用保守業者はチェックリストに基づき作業を実施し、リストを消し込む形で結果を記入していきます。

全ての作業が終了したら、その日の作業の概要を報告書にまとめ、翌日の朝に運用保守作業の実施報告として運用保守担当者に返却します。

１枚のリストが運用保守担当者と運用保守業者の間で、確認資料となったり、実施計画となったり、報告書となるようになっています（図4）。

実は、これらの運用を行うための仕組みの一部は、これまでの汎用機のシステムで行っていた温故知新の仕組みです。

再構築最初の住記システムが稼働したときに、これまでの運用に実は優れていた面があったと感じ、次の税システムの稼働にあわせてチェックリストの自動出力などの機能を充実させました。

(2)曖昧な作業に迅速対応するための管理

作業スケジュールの管理に含まれない、障害対応やデータの調査などの作業、運用保守作業を実施した中で発生した改善が必要な要素など、予め手順書で定義できないような作業は全て、発生したタイミングで全て「インシデント」として管理を開始します。

変更・リリース管理のような他の管理プロセスも定義していますが、他のどの管理プロセスで扱う内容についても、はじめはインシデント管理で扱われます。

インシデントは発生したものを漏らさず管理することと、確実にクローズに持っていくことが重要です。

そこで、定期的に関係者で棚卸会議を行い、対応状況の確認を行います。特に重要なのは、誰が対応者になるか曖昧な作業に関し、次の作業をだれが行うかを決めるということです。

役割分担が曖昧なものについては、運用保守担当者（基盤）が対応者の「指さし」を行うようになっています。