ここまでお伝えした実績は、私たちが今回の再構築で、システム開発にグラスボックスの仕組みを導入したことで実現できているものです。

しかし、再構築により確立したグラスボックスの仕組み、発注者主導は、それを継続していくためのスタートラインに過ぎません。

システムの維持管理作業である運用保守の中でしっかりと維持していかなければ、せっかく中身を見えるようにしたシステムも、再びベンダー依存のブラックボックスのシステムに戻ってしまいます。

システムの運用保守は、長期にわたりその作業を担当する人間が固定化される傾向にあるため、手順などが人によってバラつきやすく、手順もドキュメント等に残されないことが多くあり、作業が属人化しやすいという特性があります。

発注者視点だけでなく、受託しているベンダーでさえも作業を担当しているエンジニア以外は中身がわからないという状態まで陥ることもあります。

運用保守がブラックボックス化していくのは、大きくは以下の3つ問題に起因します。

(1)作業の手順が標準化されていない

運用保守の作業について、作業が標準化されていないため、作業者によって作業のやり方が異なり、また、作業手順もドキュメント化されていない。
そのため、他の人が作業内容を把握するための労力が大きく、特定の作業者しかその作業が実施的できない状況になっている。

(2)作業に関するプロセスが曖昧

作業そのものだけでなく、その作業にあたっての実施時期や、実施した作業の結果について、発注者側に報告や確認が行われない。
ベンダーから突然作業結果の報告だけが行われることや、システムトラブルが起きた際の報告があってはじめて作業が行われていたことを認識したといったことが起こったりする。

(3)作業に関しての役割分担が曖昧

発注者と受託者の間やベンダーの間で役割分担があいまい。
トラブルが起きた場合に「自分の担当ではない、ネットワークが悪い、サーバが悪い」といったようにたらい回しになり、トラブル対応が遅延してしまったりする。

システム運用保守は、さまざまな役割分担が行われるため、役割間でその分担が曖昧になりがちです。

運用保守がマルチベンダーの場合はそれが顕著に発生します。

特に予期せぬシステム障害で手順では対応できないようなケースの場合は、役割分担が曖昧なことにより対応遅延が発生する危険があります。

運用保守がブラックボックス化すると、慣れや思い込みによるミスが発生するようになります。

場合によっては、そのミスによってシステムの処理が異常終了してしまうことや、異なる処理結果が出力されてしまうような事態も招くようになります。

また、システムの運用保守ではプログラムソースやドキュメントの構成管理が行われますが、この作業が形骸化すると、プログラムソースがデグレードを起こして不具合を生じさせたり、ドキュメントが実態とかい離し、仕様を把握するために都度プログラムを調査しなければならなくなったりしてしまいます。

このような状況では、競争入札はおろか、日々の運用もままならなりません。

そして、ミスを改善しようにも「なぜその作業が必要なのか」や「どうやって作業しているのか」が発注者はおろか受託ベンダーさえも分からず、どこに問題があり、どう改善すれば良いか、対応策の検討や妥当性の判断がつかなくなってしまいます。

自治体のシステム運用保守の場合は、発注者が非専門職員であり、自らが作業者としての技術を持たないことも多いため、ブラックボックス化した時の状況はより酷いものとなります。

このような状態に陥るのを避け、中身が見えるようになったシステムの状態を稼働後も長期的に維持し、維持管理を競争入札し続けるためには、システムを維持管理するための運用保守の作業についても発注者がベンダーをコントロールできる仕組みが必要です。

新築してピカピカの建物の輝きを維持しつづけるように、中身が見えるようになったシステムを磨き続ける仕組みを作り、いつまでも快適に利用できるようにするのです。