このブログは2015年2月18日に更新を停止しました。すべての記事は https://chroju.github.io へ移行されています。

Software Design 2015年2月号『なぜ「運用でカバー」がダメなのか』読了

読んだ。身に覚えがありすぎるもので(震え声)

そもそもにして「運用でカバー」という言葉自体が思考停止しているというか、その実態は何で何が問題なのよ?というのをよくよく考えもせず「なんとなくまずそうだよね」状態で停まっている気がするのですが、そういうのをきちんと論理的に客観的に解きほぐして脱却していくってのは非常に重要なことだなと、この特集読んで思いました。たぶん、そういうこと他にもいっぱいある。

「運用でカバー」とはすなわち、「仕様外の依頼をなんとなくもやっと渡しても、運用現場の努力でなんかなんとなくやっちゃう」ってやつで、特集内ではその帰結として現場の高負荷、業務の属人化、費用対効果の不可視化といった問題が起きるとしている。これを続けていると正当な評価をしてもらえず、現場が疲弊して結局自分たちの価値を毀損してしまうのでやめた方がいいと。じゃあどうすりゃいいのかというと、いろいろ可視化しましょうよと。運用へ期待されていることの可視化により、やるべきことを明確化すること。運用業務自体を「サービスデリバリ」と捉えることによる、内容の可視化、ドキュメント化。それによる属人化や複雑化の排除。工数や納期も含めたQCDの可視化による客観的な運用成果の評価。そういうのをきちんとやっていこうという話。

実際自分の運用現場を振り返ってみて、これらの事柄をやっていないのかというと、実は結構やってるんですよね。運用業務に費やした工数はカウントして提示しているし、運用設計書を定めてもいる。ただ、確かに明示化がきちんと進められていない部分はあって。例えば運用業務の可視化においては、単なるドキュメントを作るだけではなくて、運用メンバーに求められる「スキルセット」も整備すべきだとあるんだけど、そこはやってないんですよね、弊社の場合。運用メンバー全員が一定のスキルセットを共有してはいないので、特定プロダクトの障害が起こると有識者だけが原因と対策を考え、責任もその人1人が被るような状態になってしまう。たぶん100%「運用でカバー」している現場は少なくて、カバーと言うぐらいだから可視化しきれなかった一部の例外をふちゃふちゃやってるんだと思う。でも、それが結構大きな傷口になってしまったり。

あと、お客さんの無茶ぶりというよりは、案外社内の方に敵がいることも少なくない。無茶ぶりに対して、サービスメニューと契約内容を元に本来は交渉をすべきなんだけど、そこを「仕方ないよね」といって引き受けてしまう風習とか。なぜ無茶ぶりを引き受けてしまうかというと、うちが引き受けなければ別の会社が引き受けてしまう、つまり機会損失になるから。「運用でカバー」が蔓延した結果、それをしないことが競争力の鈍化に繋がるような、ある種理不尽な現状が日本のSIer界隈にはあるような気がしている。そのへんはきちんと交渉して仕事を受けられるような、マネジメントとビジネススキルの世界の話なのかなぁと思うけど。

特に意識したいのは、運用は「サービスデリバリ」であるという視点ですかね。どうしてもシステムリリースが先行して、運用はそれに付随して発生する毎月の収益源みたいな見方をしてしまうのだけど、長期スパンで見れば金額的にも期間的にも運用、というかリリースしたシステムによるサービス提供が本番なわけであって。その「本番」で円滑に収益を上げるためにどうしようか?ってのが開発現場には求められるわけですな。ちなみに自分は運用に片足突っ込んだ開発メンバーなので、上手いこと橋渡しが出来たらいいなーと思います。