生活の中の運用
運用とは、簡単にいえばルールに沿って作業し、サービスを提供することです。人の作業が発生するところすべてに運用があります。たとえば学校の給食当番であれば、次のようなルールで給食を提供するサービスを運用している、ということができます。
- 給食当番はクラスの班単位で行う
- 当番は1週間ごとに交代する
- 順番は、1班、2班……の順に、6班のあとは1班に戻り、以降はこれを繰り返す
- 祝日による週の日数の多寡は考慮しないものとする
- 給食当番は規定の白衣を着用する
：
これはITシステムについても同様です。サービスを快適に提供するために、日々の利用をサポートしたり、システムに不調があればメンテナンスを行います。昨今、AIが急激な進化を遂げていますが、完全自律型のシステムが完成する日がくるまで、運用がなくなることはありません。壊れた部品を自分で交換するコンピュータの姿は、まだ想像できませんものね。
あとは運用でカバーしてよ
日常生活の運用は、なにか困ったことがあっても、お互いの常識や暗黙の了解、経験値で切り抜けられることが多いでしょう。ところが、ITシステムでとなると、さまざまな要因で人々は簡単にこう口にするのです。
運用は人の手で柔軟に対応できる、超便利な最後の砦なのです。しかし、ものには限度があります。
- 「開発が間に合わなかったから、当面は運用でカバーして！」
- 「このシステム、昔から動いてるけど誰がなんのために使ってるんだろ」
- 「例の機能付けといた、使いみちは運用で考えて」
1つ目は、開発の現場ではよくある話です。時間とお金とマンパワーを整えられるかどうかの問題です。
2つ目は、代々受け継がれるなかでドキュメントの管理が悪かったのか、あるいは最初からそんなものはなく、担当者の記憶頼りだったか。こんなシステムに限って、停止すると障害が起こすので、中身のよくわからないものを面倒見続けることになります。
3つ目は、そもそも運用で考えることではありません。こういうことをやるのは、たいていは偉い人です。だれも逆らえず、逆らわず、お金も時間もかけて目的も用途も不明な機能が実装されていきます。
開発段階から使われ方を意識すればみんな幸せ
死屍累々の話をしましたが、当然ながら正常に運用されているシステムも数多くあります。これらの、うまく回っているシステム運用のノウハウを、開発の早い段階から作り込んでいこうというのが、運用設計の考えになります。
運用設計に取り組むと、開発者、利用者、運用担当者に繰り返しヒアリングを行うので、システム完成後のイメージを全体で共有できるメリットもあります。
同じ「運用でカバー」でも、計算尽くで運用にバトンを渡せるようになりたいものです。