いつもサービスを支えてくれているシステム運用の「中の人」たち。企画や開発が作ったシステムを言われたままに守り、何かトラブルが起きたら「運用でカバー」などと丸投げされがちですが、海外では運用責任者の承認がないと、プロジェクトは次工程に進めないのだとか！
妖精「運用☆ちゃん」との出会いがきっかけで、自分の仕事＝システム運用の価値がだんだんと分かってきた2年目システム運用担当者 海野 遥子（うんの ようこ）が、体当たりでお伝えします。
海外では運用責任者の承認がないと、次工程に進めない！？
い、いま、なんておっしゃいましたっ！？
ハイ。運用責任者の承認なしに、プロジェクトは次工程には進めませんって言いました。
開発に運用が口を挟む。そんなのって、あり得るんですか！？ てっきり、運用のオシゴトって、企画や開発が作ったシステムをそのまま受けて、言われたままに守る役割だと思っていました……（実際、そんな感じだし）
その声、ほんとうによく聞くわね（ニホンの運用現場では特に）
Sounds unreasonable. それは合理的ではないですね。
だって、実際にシステムが価値をユーザに提供するのはリリースしてから、すなわち運用段階でしょう。ユーザに最も近く、かつサービスを提供する当事者が企画や開発にかかわらないって、考えられないです。
ご、ごもっとも！
運用責任者は要件定義やシステム構築レビューにも参加
私たち（ITサービスマネージャ）は、要件定義にも呼ばれますし、システム構築や導入の各工程のレビュー（要件レビュー／設計レビュー／テスト項目のレビュー／運用設計レビュー／変更レビュー／リリース判定など）にも参画します。
ファッ…！？ じょ、上流に参画しまくりですね！
レビューのドキュメントには、運用責任者の承認欄があります。ITサービスマネージャがサインしないと、次の工程に進めない仕組みですね。
う、運用、強いっ！
強いとか弱いとかじゃなくて、当たり前の役割責任を公平に果たしているだけなんだけれどね。
要件定義に、サービスデスク／ヘルプデスクのリーダーに同席してもらうこともあります。
要件定義にですかっ！？
そうです。ユーザの声を最も知っているのは、企画担当者でも開発担当者でもない、サービスデスクやヘルプデスクですよね。
確かにっ！
このツクリではこんなクレームが発生しそうだとか、この操作はユーザには高度すぎるとか、こんな補足説明をしたほうがよいとか、要件に対してユーザ視点の意見や提案をもらえますから。
使う人とシステムをつなぐ、それがサービスデスク／ヘルプデスクであり運用の価値よね。
そうか！それに、要件定義段階でシステムの仕様がどうなるか運用が知っていれば、運用設計も先を見越して早めに着手できる。
ヘルプデスクも、ユーザ対応マニュアルやFAQ（よくあるお問い合わせと回答集）を先んじて作っておけるわね。
あらかじめどのような運用が発生しそうかわかっていれば、自動化の検討もしやすくなります。これは、運用エンジニアの技術力の向上にも寄与します。ところがリリース間際だと、そうはいかない。
なるほど。後手後手の「運用でカバー」は運用者やインフラエンジニアの成長機会を奪ってしまうのね……。
これを繰り返すと、IT業界がどんどん疲弊して弱体化するわ！（リリっす！）
ときには「運用でカバー」せざるを得ないケースもある！
とはいえ、システムにはどうしても運用でカバーせざるを得ないケースも存在します。
例外対応とか、年に1回しか発生しないイレギュラーな業務パターンとか、すべてをシステム化していたらキリがないものね。お金がいくらあっても足りない。
運用でカバーする方法を、システムのリリース間際に発覚して考えるのか？上流工程で気づいて阻止する、あるいは早めに運用のプロが知って対応方法を考え始めるのか？ この違いは大きいです。企画・開発と運用の信頼関係、コラボレーションにも影響しますね。
確かに「開発がなんか作っているなー。でも何だかわからないし教えてももらえないよなぁ」「どうせまた使えないシステムをマル投げされて、火を吹くんだろなーぁ」ってモヤモヤ、不安だしフラストレーションよね。なんだか、ぞんざいに扱われている感じもしてモチベーションだって上がらない（いまの私？）。
お互いがお互い壁を作って、見えない状態作って、勝手にモヤモヤして…。
でもってリリース間際になって責任の押しつけ合い。暫定運用でナントカする。そして、勝手に仲が悪くなる。誰も得しないわよね。（ぱふぉちゅーん！）
「カオス」は、後工程の生産性もモチベーションも下げます。結果、サービスの品質にも悪影響を及ぼす。良いことはありません。
わかりみ……です。
私たちの現場は、開発と運用が信頼し合っています。お互いがお互いのプロフェッショナリティを認め合い、情報を開示し合って良いサービスを作り上げる、提供する。この関係が築けていますね。
要件定義から参画すると、運用メンバーのシステムに対する愛着も責任感も強くなるわ。これが、他人が勝手に作ったシステムだったら、やっぱり他人事感しか持てないわよ。人間だもの（あたしは妖精だけど）。
そうか……上流に参画できる、情報を早めにもらえる＝信頼されているってことよね。そして、人って自分が信頼されているって感じると、頑張りたいって思う！
企画も開発も運用も関係なく、誇りを持って良いITサービスを提供し続ければ、顧客やユーザのシステムに対する信頼も高まるわ。お互い壁作って喧嘩していたら、システムそのもの、IT業界そのもののブランド価値が下がる。
Yokoさんも、運用の立場でどんな価値を出せるか？考えて実践していってくださいね。それが、私「たち」 ITサービスマネージャの価値向上につながります。私たちの日々のPracticeが運用のバリューを創るのですから！
は、はいっ！頑張ります！
（やった、私「たち」って言われた！世界が仲間！）
遥子ついに覚醒！？ 次回、未来の運用者の歩き方に迫ります！
登場人物紹介
運用☆ちゃん
妖精。ある日、遥子のもとにやってきた。システム運用業務の認知の低さ、運用者のモチベーションの低さを嘆き、空から舞い降りた。彼女の使命は、運用のプレゼンス向上、価値向上、そして運用者の誇りの醸成。好きな言葉は「ありがとう」。好物は、かき氷ブルーハワイ（嫌なことがあるとやけ食いする）。
見た目も言動も幼い感じだが、実は65535歳らしい。
海野 遥子（うんの ようこ）23歳
大手製造業 日景（ひかげ）エレクトロニクスの情報システム子会社に勤める2年目社員で、認証基盤システムの運用担当。クラスの端っこで目立たないような女子。今日もサーバルームで、システム監視したりパッチ当てたりと目立たぬ日々を送る。好物はいわた茶。
※この漫画はフィクションです。実在の人物や団体などとは関係ありません。
マンガ：湊川あい（みなとがわ あい）
フリーランスのWebデザイナー・マンガ家・イラストレーター。マンガと図解で、技術をわかりやすく伝えることが好き。
主な著書 わかばちゃんと学ぶ Webサイト制作の基本・わかばちゃんと学ぶ Git使い方入門・わかばちゃんと学ぶ Googleアナリティクス〈アクセス解析・Webマーケティング入門〉
Twitter: @llminatoll
シナリオ：沢渡 あまね（さわたり あまね）
IT運用エバンジェリスト。業務改善・オフィスコミュニケーション改善士。ITサービスマネジメント／プロジェクトマネジメントのノウハウを応用した、企業の働き方改革・業務プロセス改善・インターナルコミュニケーション改善の講演・コンサルティング・執筆活動を行っている。
主な著書：『新人ガール ITIL使って業務プロセス改善します!』、『職場の問題かるた』『働き方の問題地図』『職場の問題地図』『仕事の問題地図』、『チームの生産性をあげる。』、『話し下手のための雑談力』
Webサイト「あまねキャリア工房」 / Twitter / Facebook
8,568通り、あなたはどのタイプ？
グッドポイント診断で、あなたの隠れた強みを診断してみましょう。
診断結果は8,568通り。あなたはどのタイプ？
