ITサービスを安定して提供するためには、しっかりとした運用設計が欠かせない。運用☆ちゃんからそう教わった遥子。
─ところで、運用設計って何だ？いつ、誰が、どんなことをすればよいの！？
「運用設計なあなあ」が引き起こす、悲しき景色
運用設計とは、大雑把に言えば「システムでやること」と「業務でやること」を決めておく作業よ。運用設計する時には”3W1H“を意識してほしい。
3W1H…ですか？
そう。
* When：いつ運用設計をするか？
* Who：誰が運用設計をするか？
* What：設計すべき運用項目は？
* How：どのような体制で運用するか？
この4つは絶対ハズしちゃいけない。どの現場でも必ず話し合って、決めてほしいわね。
な、なるほど！（メモメモ）
When：いつ運用設計をするか？
で、運用設計っていつやればいいの？
そうね。残念ながら明確な定義はないわ。
（だからこそ、現場でしっかり話し合って決めてほしいんだけれどね）
ただ、早めに着手するに越したことはないわね。
早めって？
要件定義・設計など、なるべく上流（…って言い方あまり好きじゃないんだけど）でってこと。
なるほど！
一般的に、何を運用項目として設計するかは、要件定義と基本設計によって決まってくる。
確かに！機能とか、機器構成とか、システムフローや業務フローとか、使うパッケージや外部サービス（クラウド等）とかってそこで決まっちゃうよね。
そう。運用できるかどうか見極めるためにも、要件定義や基本設計段階から運用設計に着手しておいたほうがイイってワケ。
ふむふむ。
特に性能や可用性目標、バッチ処理など、いわゆる非機能要件（※）は設計段階でほぼ決まってしまう。そして、後になればなるほど、戻れなくなる！
「運用設計 イコール 非機能要件」を満たすための業務を設計すると言ってもイイくらいだし。
※非機能要件については、第4話（Incident004）を参照してください。
Who：誰が運用設計をするか？
これも答えがないのよね。会社によって、現場によってまちまちだったりする。
結構、アバウトな感じなのね…
だからって、曖昧にしておいてイイってことじゃない。後で泣くのは運用現場であり、お客さんなんだから。
ちなみに、こんなアンケート結果があるわ。「運用設計は開発がやるか？運用がやるか？」
▲（2018年1月4日 作者がTwitterで実施）
おお、見事に割れた！
誰がやるかは、現場の文化や事情によりけりよね。個人的には、運用のプロであるあたしたち運用者がやったほうがイイと思うケド。どの現場でも、誰が運用設計するかは必ず話し合って決めてほしい。
「誰も設計しません」だけは絶対避けたい…。
What：設計すべき運用項目は？
…で、何を設計すればいいの？
よくぞ聞いてくれた、遥子！ これまた、明確な定義などないっ（リリっす！）
答えは自分で体系化するものよ！
なに、その開き直り…。でも、それじゃ私みたいな初心者は困っちゃうんですケド…。
それもそうね。主だったシステム運用項目を挙げておくわ。
監視
* 死活監視
* 性能監視
* セキュリティ監視
【主な監視対象】
サービス／アプリケーション、インフラ（ハードウェア、ミドルウェア、DB、ネットワーク、OS、プロセス、各種リソース（CPU、メモリ、ファームウェア、ストレージなど）
メンテナンス
* パッチ適用
* バージョンアップ作業
* 証明書更新
* ジョブ登録／実行
* セキュリティ対策
* データガベージ
* アクセス制御
* テスト環境の構築／維持
* 各種設定変更
* 機器メンテナンス（ディスク交換、メモリ増強、ネットワーク機器交換）
バックアップ／ログ管理
* データバックアップ／テープ交換
* 媒体保管
* ログ取得
* ログローテーション
* ログデータの圧縮／保管
* 監査対応／モニタリング
報告
* 定例報告
* 臨時報告（トラブル報告など）
ITIL(R)に沿ったサービスマネジメント業務
* インシデント管理
* 問題管理
* 変更管理／リリース管理
* イベント管理
* 構成管理
* ナレッジ管理
* 情報セキュリティ管理
* サービスレベル管理
* 可用性管理／キャパシティ管理
* サービス報告
ほか
運用ドキュメント管理
* 作業手順書の最新化
* 各種運用ドキュメントの改廃
ベンダ対応
* エスカレーションや問い合わせ
* 製品情報収集
改善活動
* 運用ツール作成
* 効率化検討
* 自動化検討
新技術の調査・検証・技術向上
うわぁ、たくさんある！
（こりゃ、取りこぼしたら大変ね）
それぞれ、定期作業（日次／週次／月次…）と不定期作業（アラートや申請ベースで随時対応）に分類して定義する。
また、トリガーを決めておくのも大事ね。
JP1などの監視ツールから挙がってきたアラート起因で作業するのか？
ユーザーや関係者からの申請に応じて対応するものなのか？
運用設計の成果物ってどんなものなのかしら？
いろいろあるわよ。
運用項目一覧、運用フロー、手順書、作業チェックリスト、管理台帳（インシデント管理簿、問題管理簿、入退室記録簿など）、帳票（申請書、作業指示書など）、運用スケジュール、運用報告書 などなど。
ほほう（メモメモ）
現役のITサービスマネージャやインフラエンジニアが書いた書籍やノウハウも出回っているから、遥子も参考にするといいと思うわ。
●運用設計 おすすめ書籍
『みんなが知っておくべき運用設計のノウハウ Kindle版』（JBSテクノロジー株式会社著）
運用設計の観点や設計すべき項目が網羅された、具体的かつ実践的な一冊です。
How：どのような体制で運用するか？
そして、最後は体制。どんなに立派に運用項目を定義しても、実際に運用を回す体制や必要なスキルを持ったエンジニアを揃えられなければ絵に描いた餅。
（もちろん、予算確保も大事！）
そのためにも、システムやサービスの設計段階から、運用設計を始めておかないとダメなのね。
そういうこと！
次回は、業務運用についてたっぷりお話します！
登場人物紹介
運用☆ちゃん
妖精。ある日、遥子のもとにやってきた。システム運用業務の認知の低さ、運用者のモチベーションの低さを嘆き、空から舞い降りた。彼女の使命は、運用のプレゼンス向上、価値向上、そして運用者の誇りの醸成。好きな言葉は「ありがとう」。好物は、かき氷ブルーハワイ（嫌なことがあるとやけ食いする）。
見た目も言動も幼い感じだが、実は65535歳らしい。
海野 遥子（うんの ようこ）23歳
大手製造業 日景（ひかげ）エレクトロニクスの情報システム子会社に勤める2年目社員で、認証基盤システムの運用担当。クラスの端っこで目立たないような女子。今日もサーバルームで、システム監視したりパッチ当てたりと目立たぬ日々を送る。好物はいわた茶。
※この漫画はフィクションです。実在の人物や団体などとは関係ありません。
※本記事は「CodeIQ MAGAZINE」掲載の記事を転載しております。
『運用☆ちゃん』連載はこちら
マンガ：湊川あい（みなとがわ あい）
フリーランスのWebデザイナー・マンガ家・イラストレーター。マンガと図解で、技術をわかりやすく伝えることが好き。
主な著書 わかばちゃんと学ぶ Webサイト制作の基本・わかばちゃんと学ぶ Git使い方入門・わかばちゃんと学ぶ Googleアナリティクス〈アクセス解析・Webマーケティング入門〉
Twitter: @llminatoll
シナリオ：沢渡 あまね（さわたり あまね）
IT運用エバンジェリスト。業務改善・オフィスコミュニケーション改善士。ITサービスマネジメント／プロジェクトマネジメントのノウハウを応用した、企業の働き方改革・業務プロセス改善・インターナルコミュニケーション改善の講演・コンサルティング・執筆活動を行っている。
主な著書：『新人ガール ITIL使って業務プロセス改善します!』、『職場の問題かるた』『働き方の問題地図』『職場の問題地図』『仕事の問題地図』、『チームの生産性をあげる。』、『話し下手のための雑談力』
Webサイト「あまねキャリア工房」 / Twitter / Facebook
8,568通り、あなたはどのタイプ？
グッドポイント診断で、あなたの隠れた強みを診断してみましょう。
診断結果は8,568通り。あなたはどのタイプ？
あなたの新しい可能性が見つかるかも
リクナビNEXTにログインすると、あなたの志向に合った特別な求人一覧を見ることができます。
予想外の求人が、あなたの世界を広げるかもしれません。
