書籍情報
書籍名: 運用設計の教科書【改訂新版】 〜現場でもっと困らないITサービスマネジメントの実践ノウハウ〜
著者: 近藤 誠司
著者について
株式会社K-model代表。オンプレからクラウドまで幅広いシステム導入プロジェクトに運用設計担当として参画。運用設計・運用改善コンサルティングを専門とする。趣味は小説を書くことで、第47回埼玉文学賞にて正賞を受賞。
著者の他の著作
著者リンク
読書動機
1. 運用設計の進め方がわからなかった
「運用をちゃんとしたい」という気持ちはあっても、何をどの順番で、誰と合意しながら進めるのかの道筋が見えなかった。体系的に整理されたものが欲しかった。
2. 運用にフォーカスした本が少ない
開発手法やアーキテクチャに関する本は多いが、運用設計にフォーカスした本は珍しい。現場で口頭・経験でしか伝承されてこなかった運用の世界を正面から扱った本として興味を持った。
。
学んだこと
1. 運用設計とはなにか（p13）
運用設計とは、
運用設計を一言で説明すると、運用に必要な作業をとりまとめてルールを決めること（p.13より）
利用者からの申請対応や障害検知時の対処フローなど、システム稼働中に発生するあらゆる事柄について、事前にルールや手順を定めておくことがその本質だ。こうした取り決めがなければ、特に大きな障害が発生したとき、関係者全員が「何をどこまでやればいいか」わからない混乱状態に陥るリスクが高まる。
2. 運用と運用設計の目的（p14）
運用設計の目的は、運用の目的、そしてその先にあるサービスの目的と同一線上にいないといけません（p.14より）。
言い換えると、運用設計はシステムを安定稼働させてサービスを効率的に提供するという運用の目的を達成するための手段であり、最終的にはビジネス上の目的とも一致していなければならない。
3. 運用設計の5つの効果（p15）
運用設計には主に5つの効果がある。運用範囲の決定・サービスレベルの安定・属人化の排除・品質の均一化・運用ドキュメントの可視化だ。なかでも品質の均一化については、
手順書の粒度をそろえるため、だれが作業を実施しても同じ結果が得られる（p.16より）
という整理が印象的だった。障害対応などプレッシャーのかかる局面でも均一な品質を保てるのは、事前に整理された手順書があってこそだと感じた。
4. システムを運用する人の範囲（p17）
役割関連図とは、サービス開始後にシステムについての問い合わせや障害などを解消できる体制の役割を記載した図となります（p.17より）。
誰に何を連絡すべきか、誰がどの役割を担うかを事前に可視化しておくことで、有事の際の混乱を防ぐことができる。
5. 運用設計の目指すレベル（p20）
「COBIT成熟度モデル」を参照すると、社内のITシステム管理がどのレベルに達しているかを客観的に評価できる。レベル0（プロセス不在）からレベル5（最適化）までの6段階が定義されており、
運用管理チームが主体となり、継続した改善活動・他社比較により運用プロセスがベストプラクティスまで最適化されている（p.21より）
状態がレベル5の到達点とされている。レベル0は課題の存在すら認識できていない状態、レベル1は個人が場当たり的に対応している状態で、まず自組織の現在地を正確に把握することが改善の第一歩となる。
6. 運用設計に必要な3つの分類（p22）
運用設計は、業務運用・基盤運用・運用管理の3つに分類される。なかでも、
運用全体を管理して、円滑に行えるように全体のルールとものさしを決めて管理する業務（p.22より）
である運用管理が、全体を束ねる俯瞰的な位置づけを担う。業務運用はアプリケーションや利用者に関わる業務、基盤運用はシステム基盤の維持に関わる業務で、3者が連携することで全体の運用が成り立つ。
7. なぜ運用設計の専門家は少ないのか（p28）
発注者がシステム導入に求めるものと、システム運用に求めるものの間に乖離がある（p.28より）
ことが、運用設計の専門家が育ちにくい構造的な原因だ。安定稼働の重要性は誰もが理解していながらも、それが表立って評価・報酬に結びつきにくい業界慣習が背景にある。
8. 運用設計担当が作成するドキュメント（p35）
プロジェクト内たちとディスカッションで行いながら、導入するシステムの運用方針や手順を確定していきます。（p.35より）
ことが、運用設計担当の核心的な役割だ。合意した文書がそのまま運用ドキュメントとなる。通常運用では、運用設計書・運用項目一覧・運用フロー図・運用手順書・申請書・台帳・一覧といったドキュメント群が必要となる。運用テスト段階では、さらに運用テスト計画書と運用テスト仕様書が用いられる。それぞれのドキュメントが互いに補完し合う構造になっており、どれか一つが欠けても運用全体の質が落ちる設計になっている。
感想
「なぜ運用設計の専門家が少ないのか」という問いに対して、発注者側の意識の問題として説明されていた点が腑に落ちた。現場で運用設計がないがしろにされる理由が、構造的な問題だったと納得できた。
また、開発側の人間であっても運用を意識して設計する必要があると改めて思った。機能を作るだけでは不十分で、その後の運用コストまで考えて設計することが本当の意味での品質につながる。そう考えると、ソフトウェア開発は開発・運用・ビジネスの知識を横断して求められる、非常に難しい業界だと感じた。
実践できること
- 個人開発プロジェクトの運用設計書を書く
- 運用項目一覧を作成する
- 運用フロー図を作成する
定量評価（1年後に記入）
注意: このセクションは読書直後ではなく、1年後など実際の効果が見えてから記入してください。
記入日: YYYY-MM-DD
スキル・知識の評価
| 評価項目 | 評価 | コメント |
|---|---|---|
| 長期的な有用性 | ⭐⭐⭐⭐☆ (4/5) | |
| 実践のしやすさ | ⭐⭐⭐☆☆ (3/5) | |
| 汎用性 | ⭐⭐⭐⭐☆ (4/5) |
スキルスコア: /15点
経済的インパクト
投資コスト
| 項目 | 数値 | 根拠・計算 |
|---|---|---|
| 書籍価格 | ¥X,XXX | |
| 読書時間 | XX時間 | |
| 読書時間コスト | ¥XX,XXX | |
| 総投資額 | ¥XX,XXX |
リターン
| 項目 | 数値 | 根拠・計算 |
|---|---|---|
| 時間削減効果 | XX時間/月 | |
| 時間削減の金額換算 | ¥XXX,000/月 | |
| コスト削減効果 | ¥XXX,000/年 | |
| 年間経済効果 | ¥XXX,XXX |