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

2018/05/24 17:01 リクナビNEXTジャーナル生活・趣味

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

妖精「運用☆ちゃん」との出会いがきっかけで、自分の仕事＝システム運用の価値がだんだんと分かってきた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