「運用でカバー」では、プロジェクトが崩壊する!―運用者よ、上流工程に参画せよ!
いつもサービスを支えてくれているシステム運用の「中の人」たち。企画や開発が作ったシステムを言われたままに守り、何かトラブルが起きたら「運用でカバー」などと丸投げされがちですが、海外では運用責任者の承認がないと、プロジェクトは次工程に進めないのだとか!
妖精「運用☆ちゃん」との出会いがきっかけで、自分の仕事=システム運用の価値がだんだんと分かってきた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
関連記事リンク(外部サイト)
エバンジェリスト西脇資哲氏・野水克也氏と学ぶ!ソーシャル時代の動画活用と基礎テクニック
“銀色”からの脱却!個性を出し始めた「電車の色」最新事情
卑怯者は“得てして”こうなる!リスクを取る覚悟がない者の末路とはーーマンガ『インベスターZ』に学ぶビジネス
ビジネスパーソンのための、キャリアとビジネスのニュース・コラムサイト。 キャリア構築やスキルアップに役立つコンテンツを配信中!ビジネスパーソンの成長を応援します。
ウェブサイト: http://next.rikunabi.com/journal/
TwitterID: rikunabinext
- ガジェット通信編集部への情報提供はこちら
- 記事内の筆者見解は明示のない限りガジェット通信を代表するものではありません。