「運用中心プロセス」という考えかた～モノ作り中心から動くサービスを中心に据えることへのパラダイムシフト ＠ Social Change!
運用と一言で言っても、業務的な運用とシステム的な運用に分けられたりもしますけど、システム開発の位置づけの中でこれらの領域は結構置いてきぼりになりがちだったりもします。
それは、サービスというものを考えたときに、その利用者に重きを置いているので仕方が無いことかもしれませんが、サービスを使う立場と支える立場を考えると、両者とも利用者であることに変わりありません。
企業にとって利益を生むため注力していきたい表のユーザー機能と、それを支えるために必要なものではあるものの企業としてはそこにかけるコストをできるだけ抑えたい裏の管理機能を考えたら、どちらにリソースをつぎ込みたいかという判断が偏るというのはプロジェクトの現場ではよくありがちな罠になっていたりもします。
「運用でカバー」で片付けられる業務運用
業務運用では、そのサービスを担当する企業や部署が提供サービスを裏で管理するための機能を使って仕事をするわけですが、その機能そのものがサービスのリリース段階でうまく組み込めていなかったり、後回しにされたりします。
取り合えずユーザーが使えるサービスを優先させたいということから、重要度のランク付けが逆転してしまうわけですが、業務系のシステムではむしろこっちがメインであったりもします。
自分たちの業務を効率化するためのシステム化施策の中で、ユーザー機能に注力するばかりに結局効率化が果たせないばかりか、余計なシステムが増えてむしろ仕事が増えるとか。
この辺は業務プロセスの中での出口にあたったりするので、取り合えず入り口を作らないことには始まらないとか、実際にその業務を行う側も取り合えずリリースしないといけないわけで、本来の目的を忘れて「その機能は手運用しながらカバーします」とかって本末転倒な結果になったりもします。
これは、その担当企業や部門に負担がかかるだけでなく、それを運用することになるシステム部門だったりにも大きく負荷がかかります。
機能を作ってないばかりに、依頼都度DBを操作することになったり、求められるデータを加工して提出するということになったり。
まぁ、この辺は要件とスケジュールの問題であったりもするわけですが、ありがちなのは効果測定の機能が用意されていないため、ユーザーからのフィードバックをうまく受け取れなかったり、改善結果がどれほどあったのかがわからず、費用対効果もはっきりしないで運用を強いられるというものがあったりします。
結局のところ、サービスインした後の運用の中でそのサービスの利益を最大化するための次の一手が全く読めない状態に陥ったりするわけですが、取り合えずスタートさせたい気持ちがはやりこの辺は当初の置いてきぼりです。
しばらく運用した後で効果が上がらないといって次の改善施策が持ち上がったりもしますが、それも付け焼刃的な対応に陥って延々と無駄なことを繰り返すばかりか、返ってシステムのライフサイクルを縮める結果にもなったりするわけです。
テンプレに当てはめがちなシステム運用
システム運用は、そのサービスを安定して提供するために必要な業務となるわけですが、それに求められる機能は他のシステムとも共通点が多かったりします。
監視やバックアップとリカバリ、検証やメンテナンスのために必要になるデータのパージ、ジョブ管理など他のシステムでも使うような機能も多く、請け負っている運用システムが多ければ何も考えずに予め決められた運用ツールが選定されていたりしているのではないでしょうか。
この辺は、スクラッチで作るにはコストがかかりすぎるので、商用やOSSも含めて著名な運用ツールを適用していくやり方が一般的でしょうけど、構築の段階で既存の運用ツールが適用可能かやそれにあわせたインフラ設計をしておかないと運用後（または直前）に痛い目にあったりもします。
運用ツールは導入だけでなく、それを操作する人への教育も必要になるので、運用メンバーが普段から慣れ親しんでいるものを適用したり、運用システムを一括で管理できる仕組みがあったほうがコストを抑えることができます。
ただ、この辺は結構既存の運用システムに乗せるということで片付けがちで、新しいサービスに必要なシステム運用をよく吟味するということをしなかったりもします。
一般的なシステム運用というのは既存の運用ツールに載せることでも問題ないでしょうが、そのサービスに特化したシステム運用というものもでてくるわけで、単に他のサービスのシステム運用をテンプレートのように当てはめるだけだったり。
また、システム構築とシステム運用を別々のチームで行う場合は、事前に運用として必要な要件をヒアリングして取り込んでおかないと、「これじゃ運用できない」ってトラブルにもなったりして、運用には運用を行ううえでのポリシーがありますし、取り合えずユーザー機能優先で作ったものに後付で加えるとなると、適用が難しかったりシステム設計が根底から違ってくるために力技をせざるを得ないということにもなったりもします。
このあたりは、運用を初めてわかることも多いため、それを検知するための仕組みが必要になってきます。
そもそも、サービスを安定化するための業務がシステム運用であるならば、それが安定しているかどうか判断できる材料を集められる仕組みが必要になってくるわけで。
まとめ
その他にも運用の中でユーザーからフィードバック事項を取り込んでいく際の保守のしやすさというものもあります。
コードのシンプルさであったり、拡張性であったり、バグ管理であったり、そのリリース管理であったり。
このあたりの事も、目の前のことにいっぱいいっぱいになっている構築フェーズの中ではなかなか手が付けられないと後回しになりがちですが、その後の運用を考えたら当然前もって考えておく必要のあるものです。
こういったことを考え出すと、取り合えず動くものを作るという目の前の視点から、もう少しその先の突っ込んだ視点で考えるべきことも多いのだと感じます。
運用はサービスを提供するうえで基礎となるものなので、それを開発プロセスの中心におくというのは理にかなっていることかもしれません。
関連記事
初めからやっておけばよかったとあとで思うシステム構築に関する10のこと
サービス構築の実行コストは構築側より提案側のほうが上回ってるんじゃないかって話
トラブル時のシステムエンジニアと非システムエンジニアの焦りの違い
