いつもサービスを支えてくれているシステム運用の人たち。いったいどんなコトしているんだろう？システム管理者、ヘルプデスク、業務SE、ネットワークエンジニア、サーバ管理者、保守対応者…いろいろな人がいるみたいだけれど、イマイチよくわからない……！
『運用☆ちゃん』では、そもそも運用って何？ 運用の仕事の苦労や醍醐味って？ 価値ある運用者になるためには？ などなど、妖精「運用☆ちゃん」が、2年目システム運用担当者 海野 遥子（うんの ようこ）と体当たりでお伝えします。
目次
DevOpsエバンジェリスト 長沢智治、参上！
従来のシステム運用のあり方に疑問を感じ、社外に出てみた遥子。そこで、運用を中心に、ITサービスを安定して提供するための工夫と改善を繰り返す役割「SRE」なる新たな世界を知る。｢開発と運用の垣根を越える｣。そのためにはどうしたらよいか？遥子の悩みは尽きない……。
Q1.長沢さんはどんなお仕事をされているのですか？
は、はじめまして。海野 遥子です。ところで、長沢さんはどんなお仕事をなさっているのですか？
（突然、この妖精に連れて来られたもんで……）
ははは。一言で言うと、DevOpsのエバンジェリストをしています。
エバンジェリスト……（って、何！？なんか、変身とかしそうな強そうな名前よね）
（エバンジェリスト＝伝道者。技術やカルチャーを広める活動をしている人のことよ）
長沢さんは、日本マイクロソフト、アトラシアンなど数々の企業でDevOpsのエバンジェリストとして活躍されてきたのよ。（リリっす！）
いまはフリーランスで、複数の企業の顧問として組織改革を支援したり、講演や執筆活動を通じてDevOps普及の活動をしています。
す、すごい！
Q2.DevOpsって何ですか？
ところで、DevOpsって何ですか？ 最近よく聞くコトバではあるのですが、いまいちピンと来なくて……。
私はいつも｢ビジネスフォーカスのムーブメント｣と説明しています。
ファー！？ ひじ鉄サーカスのムービー…ですと！？
（それって、格闘コメディの映画ですか！？）
ビジネスフォーカスのムーブメント！ 顧客志向、サービス志向の組織運営手法ってイメージかしらね。
ますます分からなくなってきました。DevOpsって、技術やツールの名前じゃないんですか？
たしかに、DevOpsの文化をうまく定着させるためには技術やツールの導入も大事です。自動化などの工夫も必要でしょう。しかし、DevOpsとは特定の技術やツールや手法を導入して終了！というものではないのです。あくまでムーブメント、言い換えれば文化なのです。
この辺りが、DevOpsを分かりにくくしている要因でもあるかもしれないわね。ただ、長沢さんの仰るとおり、DevOpsは技術でもツールでもないのよ。
自動化すればよいというものでもない。
？？？？ ますます頭が混乱してきました……。
｢Dev（開発）とOps（運用）を明確に分けないカルチャー｣とでも言いましょうか。
それが、ひじ鉄……じゃなかった、ビジネスフォーカスにどう関係するのでしょうか？
いい質問ですね。それにお答えするためには、これまでのビジネスとITの関係から説明する必要がありそうですね。
ビジネスとITの関係！？
Q3.ビジネスとITの関係は？
遥子さん、このスライドをご覧ください。私がよく使っている図です。
おおっ！分かりやすいです！
1990年代、ITは企業にとって便利なツールでしかありませんでした。2000年代もなお、有効なツールくらいの位置づけでしかなかった。
あくまで、既存のビジネスモデルを守り業務効率化を進める程度の立ち位置。
ところが2010年頃から潮目が変わりつつあります。もはやITなしには新たなビジネスモデルは生み出せない。ITを駆使しないと、世界とどんどん差をつけられる。いわば、ITがビジネスのコアになってきたのです。
な、なるほど！最近よく聞く、攻めのITってヤツですね！
クラウドサービスの台頭により、ハードウェアを設計／調達しなくてもスムーズに環境を立ててITサービスを提供できるようになった。Infrastructure as Codeのような概念も普及してきた。いよいよ、ITサービスを作る人、運用する人、使う人の垣根が低くなり、かつ垣根を越えていかないとビジネスそのものが成り立たない時代になりつつあるのです。
だから、DevOpsはカルチャーでありムーブメントなんですね！
DevOpsは、開発と運用がコラボレーションしてビジネス価値を生み出すために、たとえばこんなエッセンスも提示しているわね。まさにカルチャーなのよね。
* 非難のない環境
* 漸進的な改善
* 学習する組織
* 開発と運用の集合知
誤解しないでほしいのが、いままでの運用が決して悪いわけではないのです。あくまで自分たちのビジネスモデルにフィットしているかどうかがポイント。従来の運用と開発が分かれているやり方が、ビジネスモデルに適合しているのであれば続ければいい。無理して、DevOpsを選ぶ必要はないのです。
Q4.DevOpsで、私たちの運用現場の景色はどう変わるんですか？
かつてのビジネスモデルでは、プロダクトを作ってから運用する。この流れが主流でした。この場合は、開発と運用が分かれていたほうが都合がいい。しかし、これからのビジネスモデルではそうとは限りません。
ITサービスがコアになりつつある……。そして、競合他社は次々にサービスをブラッシュアップしてくる。継続的に新しいサービスをデプロイしていかないとマーケットから見放されるわよね。
開発と運用が壁を作っていたら、都合がよくないわね。
…で、でもね。ウチ（当社）みたいな大企業の情報システム会社のように、開発チームと運用チームが分かれている体制の組織ではDevOpsってやりにくいんじゃないかしら……。
確かに、受託開発の形態ではDevOpsは受け入れられにくいかもしれませんね。
（ガーン！）
開発したモノに対して対価を支払って以上。そのモデルでは、ビジネスにフォーカスしにくいですよね。顧客（発注者）のビジネスに貢献した価値に対して対価が支払われるようなビジネスモデルでないとやりにくいでしょう。顧客の理解とチャレンジマインドも重要ですね。
最近では、ソニックガーデン（※1）さんのように、｢納品のない受託開発｣のような新たなビジネスモデルを展開するIT企業も出てきたわ。
やはり、ビジネスモデルチェンジが大事なのよね。
本社：東京都目黒区。｢納品のない受託開発｣を掲げ、開発と運用の垣根のないITサービスを提供。月額定額の顧問スタイルで、顧客のビジネスの成長にコミットする。全社員リモートワークなど、ワークスタイルもユニーク。
Q5.受託開発型のゲンバで、DevOpsをやる余地はないんですか！？
では、私のような受託開発型の会社では、DevOpsは夢物語、絵に描いた餅なのでしょうか？
（諦めて故郷に帰れってことかなぁ……）
ぴんぐぅぅぅ……。
いやいや、諦めるのは早いです。受託開発型でも、DevOpsをはじめている会社はあります。
えっ！？
社内システムで、DevOpsをやってみてはいかがでしょう？
社内システム！ 私も日景エレクトロニクスの社内システム担当です。
社内システムにはこんなメリットがあります。
* 関係者を集めやすい
* エンドユーザとの距離が近く、反応が測りやすい
* 当事者意識を持ちやすい
* 失敗がしやすい
社内システムは絶好の実験場よね。改善にもチャレンジしやすく、改善の成果も見えやすい。あたしも、社内システムで新たな技術を試して成長した運用担当者をたくさん知っているわ。
問題は、DevOpsに取り組むきっかけをどう作るかね……。
まずは、ビジネス、開発、運用それぞれのゴール設定の見直しから始めてみてはいかがでしょう？
ゴール設定の見直し……ですか？
はい。特に大企業では、開発と運用が独自のゴールを持ってそれが相互にコンフリクトを起こしがちです。
開発は新しいサービスをどんどんリリースしたい。一方で、運用はリリースを頻繁にして欲しくない。安定運用を優先させたいから。
あるあるね。
そこで考えてみてほしいのです。そもそもビジネスのゴールは何か？それを支えるために、IT組織が目指す姿は？
ふむふむ（メモメモ）
そうすると、たとえばシステムをリリースするまでの｢リードタイム｣短縮だったり、｢MTTR（※2）｣の向上だったり、開発／運用共有で目指す新たなゴールや課題が見えてくるはずです。
Mean Time To Repair／Mean Time To Recoveryの略。平均復旧時間。システムに障がいが発生してから、復旧するまでの平均時間。
逆の見方で、リードタイムやMTTRが問題になっているゲンバで、｢DevOpsはじめてみましょう！｣って言ってみるの、ありかもしれませんね！
開発と運用のゴールが一人歩きしていても、誰も幸せにならない。そんなことしていたら、社内でのIT組織の価値も下がる。
その通りです！
Q6.DevOpsを始めるために、まず何をしたらいい？
そうですね。大きく2つ。
(1)現状把握
(2)開発と運用の相互理解の促進
ですね。
現状把握？
私は、VSM（※3）を使って、現状のプロセスや判断を明確にし、ムリ・ムダ・ムラを洗い出すことが多いですね。
Value Stream Mapping（バリュー・ストリーム・マッピング）の略。
開発、生産、物流などの工程の現状を把握し、理想像を明確にするために作成されるプロセス図／フロー図。「モノと情報の流れ図」と説明されることも。
そうすると、
｢開発と運用で、インシデントをバラバラに管理している！｣
｢承認者が多すぎる！｣
など、さまざまなムダが見えてくる。
開発メンバーと運用メンバーの相互理解も大事です。
あまり開発の人と会話したことないかも……。
もったいないですね。開発と運用、お互いが持っている経験やノウハウを開示しあうだけでも、相互リスペクトが生まれたり、コラボレーションしやすい風土に変わってきます。強い組織は、個人の暗黙知と、組織の集合知 いずれも大切にしています。相互理解は、いわば屋台骨です。
QA担当者、サービスデスク／ヘルプデスクの知見も宝。軽んじることなく、組織知に育てていきたいわね。
素敵！私もっとDevOpsを勉強したいです。オススメの書籍はありますか？
“Effective DevOps”（※4）と”The DevOps 逆転だ!”（※5）はオススメですよ。
さっそく本屋さんに寄って買ってみます！
長沢さんの講義は、”動画で学べるSchoo“で聴くことができるから参考にしてみるとイイわよ。
Q7.最後に、読者の皆さんへのメッセージをお願いします！
最後に、コホン、読者の皆さんにメッセージをお願いします。
はい。｢自己肯定感｣を大切にしてください。自分たちが世の中に提供しているバリューを把握していない人が多い。
わかる。運用にしても、開発にしても、ビジネスの価値や業務の価値向上のために生かせる経験があるのに、それに気づいてすらいない。本当にもったいないわ。
わ、私もそうかも……。
自分の価値に気づく、自己肯定感を持つ。DevOpsをそのきっかけにしてほしいですね。これからますますITはコアになる時代ですから、IT人材のバリューを最大化していきましょう！
やる気いただきました。長沢さん、ありがとうございました！
次回はITサービスマネジメント（ITIL)を勉強します！
登場人物紹介
運用☆ちゃん
妖精。ある日、遥子のもとにやってきた。システム運用業務の認知の低さ、運用者のモチベーションの低さを嘆き、空から舞い降りた。彼女の使命は、運用のプレゼンス向上、価値向上、そして運用者の誇りの醸成。好きな言葉は「ありがとう」。好物は、かき氷ブルーハワイ（嫌なことがあるとやけ食いする）。
見た目も言動も幼い感じだが、実は65535歳らしい。
海野 遥子（うんの ようこ）23歳
大手製造業 日景（ひかげ）エレクトロニクスの情報システム子会社に勤める2年目社員で、認証基盤システムの運用担当。クラスの端っこで目立たないような女子。今日もサーバルームで、システム監視したりパッチ当てたりと目立たぬ日々を送る。好物はいわた茶。
※この漫画はフィクションです。実在の人物や団体などとは関係ありません。
マンガ：湊川あい（みなとがわ あい）
フリーランスのWebデザイナー・マンガ家・イラストレーター。マンガと図解で、技術をわかりやすく伝えることが好き。
主な著書 わかばちゃんと学ぶ Webサイト制作の基本・わかばちゃんと学ぶ Git使い方入門・わかばちゃんと学ぶ Googleアナリティクス〈アクセス解析・Webマーケティング入門〉
Twitter: @llminatoll
シナリオ：沢渡 あまね（さわたり あまね）
IT運用エバンジェリスト。業務改善・オフィスコミュニケーション改善士。ITサービスマネジメント／プロジェクトマネジメントのノウハウを応用した、企業の働き方改革・業務プロセス改善・インターナルコミュニケーション改善の講演・コンサルティング・執筆活動を行っている。
主な著書：『新人ガール ITIL使って業務プロセス改善します!』、『職場の問題かるた』『働き方の問題地図』『職場の問題地図』『仕事の問題地図』、『チームの生産性をあげる。』、『話し下手のための雑談力』
Webサイト「あまねキャリア工房」 / Twitter / Facebook
8,568通り、あなたはどのタイプ？
グッドポイント診断で、あなたの隠れた強みを診断してみましょう。
診断結果は8,568通り。あなたはどのタイプ？
