「運用でカバー」では、プロジェクトが崩壊する!―運用者よ、上流工程に参画せよ!

いつもサービスを支えてくれているシステム運用の「中の人」たち。企画や開発が作ったシステムを言われたままに守り、何かトラブルが起きたら「運用でカバー」などと丸投げされがちですが、海外では運用責任者の承認がないと、プロジェクトは次工程に進めないのだとか!

妖精「運用☆ちゃん」との出会いがきっかけで、自分の仕事=システム運用の価値がだんだんと分かってきた2年目システム運用担当者 海野 遥子(うんの ようこ)が、体当たりでお伝えします。

海外では運用責任者の承認がないと、次工程に進めない!?



い、いま、なんておっしゃいましたっ!?


ハイ。運用責任者の承認なしに、プロジェクトは次工程には進めませんって言いました。


開発に運用が口を挟む。そんなのって、あり得るんですか!? てっきり、運用のオシゴトって、企画や開発が作ったシステムをそのまま受けて、言われたままに守る役割だと思っていました……(実際、そんな感じだし)


その声、ほんとうによく聞くわね(ニホンの運用現場では特に)


Sounds unreasonable. それは合理的ではないですね。
だって、実際にシステムが価値をユーザに提供するのはリリースしてから、すなわち運用段階でしょう。ユーザに最も近く、かつサービスを提供する当事者が企画や開発にかかわらないって、考えられないです。


ご、ごもっとも!

運用責任者は要件定義やシステム構築レビューにも参加


私たち(ITサービスマネージャ)は、要件定義にも呼ばれますし、システム構築や導入の各工程のレビュー(要件レビュー/設計レビュー/テスト項目のレビュー/運用設計レビュー/変更レビュー/リリース判定など)にも参画します。


ファッ…!? じょ、上流に参画しまくりですね!


レビューのドキュメントには、運用責任者の承認欄があります。ITサービスマネージャがサインしないと、次の工程に進めない仕組みですね。


う、運用、強いっ!


強いとか弱いとかじゃなくて、当たり前の役割責任を公平に果たしているだけなんだけれどね。


要件定義に、サービスデスク/ヘルプデスクのリーダーに同席してもらうこともあります。


要件定義にですかっ!?


そうです。ユーザの声を最も知っているのは、企画担当者でも開発担当者でもない、サービスデスクやヘルプデスクですよね。


確かにっ!


このツクリではこんなクレームが発生しそうだとか、この操作はユーザには高度すぎるとか、こんな補足説明をしたほうがよいとか、要件に対してユーザ視点の意見や提案をもらえますから。


使う人とシステムをつなぐ、それがサービスデスク/ヘルプデスクであり運用の価値よね。


そうか!それに、要件定義段階でシステムの仕様がどうなるか運用が知っていれば、運用設計も先を見越して早めに着手できる。


ヘルプデスクも、ユーザ対応マニュアルやFAQ(よくあるお問い合わせと回答集)を先んじて作っておけるわね。


あらかじめどのような運用が発生しそうかわかっていれば、自動化の検討もしやすくなります。これは、運用エンジニアの技術力の向上にも寄与します。ところがリリース間際だと、そうはいかない。


なるほど。後手後手の「運用でカバー」は運用者やインフラエンジニアの成長機会を奪ってしまうのね……。


これを繰り返すと、IT業界がどんどん疲弊して弱体化するわ!(リリっす!)

ときには「運用でカバー」せざるを得ないケースもある!


とはいえ、システムにはどうしても運用でカバーせざるを得ないケースも存在します。


例外対応とか、年に1回しか発生しないイレギュラーな業務パターンとか、すべてをシステム化していたらキリがないものね。お金がいくらあっても足りない。


運用でカバーする方法を、システムのリリース間際に発覚して考えるのか?上流工程で気づいて阻止する、あるいは早めに運用のプロが知って対応方法を考え始めるのか? この違いは大きいです。企画・開発と運用の信頼関係、コラボレーションにも影響しますね。


確かに「開発がなんか作っているなー。でも何だかわからないし教えてももらえないよなぁ」「どうせまた使えないシステムをマル投げされて、火を吹くんだろなーぁ」ってモヤモヤ、不安だしフラストレーションよね。なんだか、ぞんざいに扱われている感じもしてモチベーションだって上がらない(いまの私?)。


お互いがお互い壁を作って、見えない状態作って、勝手にモヤモヤして…。
でもってリリース間際になって責任の押しつけ合い。暫定運用でナントカする。そして、勝手に仲が悪くなる。誰も得しないわよね。(ぱふぉちゅーん!)


「カオス」は、後工程の生産性もモチベーションも下げます。結果、サービスの品質にも悪影響を及ぼす。良いことはありません。


わかりみ……です。


私たちの現場は、開発と運用が信頼し合っています。お互いがお互いのプロフェッショナリティを認め合い、情報を開示し合って良いサービスを作り上げる、提供する。この関係が築けていますね。


要件定義から参画すると、運用メンバーのシステムに対する愛着も責任感も強くなるわ。これが、他人が勝手に作ったシステムだったら、やっぱり他人事感しか持てないわよ。人間だもの(あたしは妖精だけど)。


そうか……上流に参画できる、情報を早めにもらえる=信頼されているってことよね。そして、人って自分が信頼されているって感じると、頑張りたいって思う!


企画も開発も運用も関係なく、誇りを持って良いITサービスを提供し続ければ、顧客やユーザのシステムに対する信頼も高まるわ。お互い壁作って喧嘩していたら、システムそのもの、IT業界そのもののブランド価値が下がる。


Yokoさんも、運用の立場でどんな価値を出せるか?考えて実践していってくださいね。それが、私「たち」 ITサービスマネージャの価値向上につながります。私たちの日々のPracticeが運用のバリューを創るのですから!


は、はいっ!頑張ります!
(やった、私「たち」って言われた!世界が仲間!)

遥子ついに覚醒!? 次回、未来の運用者の歩き方に迫ります!

—第9話(Incident 009)につづく
『運用☆ちゃん』連載はこちら

登場人物紹介

運用☆ちゃん

妖精。ある日、遥子のもとにやってきた。システム運用業務の認知の低さ、運用者のモチベーションの低さを嘆き、空から舞い降りた。彼女の使命は、運用のプレゼンス向上、価値向上、そして運用者の誇りの醸成。好きな言葉は「ありがとう」。好物は、かき氷ブルーハワイ(嫌なことがあるとやけ食いする)。
見た目も言動も幼い感じだが、実は65535歳らしい。

海野 遥子(うんの ようこ)23歳

大手製造業 日景(ひかげ)エレクトロニクスの情報システム子会社に勤める2年目社員で、認証基盤システムの運用担当。クラスの端っこで目立たないような女子。今日もサーバルームで、システム監視したりパッチ当てたりと目立たぬ日々を送る。好物はいわた茶。

※この漫画はフィクションです。実在の人物や団体などとは関係ありません。

湊川あいマンガ:湊川あい(みなとがわ あい)
フリーランスのWebデザイナー・マンガ家・イラストレーター。マンガと図解で、技術をわかりやすく伝えることが好き。
主な著書 わかばちゃんと学ぶ Webサイト制作の基本わかばちゃんと学ぶ Git使い方入門わかばちゃんと学ぶ Googleアナリティクス〈アクセス解析・Webマーケティング入門〉
Twitter: @llminatoll

沢渡あまね

シナリオ:沢渡 あまね(さわたり あまね)
IT運用エバンジェリスト。業務改善・オフィスコミュニケーション改善士。ITサービスマネジメント/プロジェクトマネジメントのノウハウを応用した、企業の働き方改革・業務プロセス改善・インターナルコミュニケーション改善の講演・コンサルティング・執筆活動を行っている。
主な著書:『新人ガール ITIL使って業務プロセス改善します!』、『職場の問題かるた』『働き方の問題地図』『職場の問題地図』『仕事の問題地図』、『チームの生産性をあげる。』、『話し下手のための雑談力
Webサイト「あまねキャリア工房」 / Twitter / Facebook

Pagetop