書籍情報
書籍名: 運用設計の教科書【改訂新版】 〜現場でもっと困らないITサービスマネジメントの実践ノウハウ〜
著者: 近藤 誠司
著者について
株式会社K-model代表。オンプレからクラウドまで幅広いシステム導入プロジェクトに運用設計担当として参画。運用設計・運用改善コンサルティングを専門とする。趣味は小説を書くことで、第47回埼玉文学賞にて正賞を受賞。
著者の他の著作
著者リンク
読書動機
1. 運用設計の進め方がわからなかった
「運用をちゃんとしたい」という気持ちはあっても、何をどの順番で、誰と合意しながら進めるのかの道筋が見えなかった。体系的に整理されたものが欲しかった。
2. 運用にフォーカスした本が少ない
開発手法やアーキテクチャに関する本は多いが、運用設計にフォーカスした本は珍しい。現場で口頭・経験でしか伝承されてこなかった運用の世界を正面から扱った本として興味を持った。
学習メモ
学んだこと
1. 運用設計とはなにか（p13）
運用設計とは、運用に必要な作業をとりまとめてルールを決めること。
- 利用者から申請を受けた場合にどうするか
- 障害を検知したときにはどうするか
といったシステム運用中に出てくる様々な事柄について、事前に運用ルールや作業手順を取り決めておくことが運用設計の本質。
正しい運用設計がされていないと、システムに関わる人たちは「何をどこまでやればいいか」わからない状態になる。何事もなくサービス提供できているときはよいが、ルールの決まっていない運用現場で大きな障害が発生すると混乱が生じる。
2. 運用と運用設計の目的（p14）
運用の目的: システムを安定稼働させて効率的にサービスを提供すること
運用設計の目的: 運用の目的、そしてその先にあるサービスの目的と同一線上にあること
3. 運用設計の5つの効果（p15）
| # | 効果 | 内容 |
|---|---|---|
| ① | 運用範囲の決定 | プロジェクト期間中に関連システムを調整するため、どこまでが自分たちの運用範囲なのかわかる |
| ② | サービスレベルの安定 | 障害や故障が発生した場合の連絡先と方法が整理されているため、システム停止時間を最小限にできる |
| ③ | 属人化の排除 | 運用に必要な手順書や台帳を作成するため、スキルに大きく左右されない |
| ④ | 品質の均一化 | 手順書の粒度をそろえるため、誰が作業しても同じ結果が得られる |
| ⑤ | 運用ドキュメントの可視化 | 運用改善を行った場合、修正対象となるドキュメントが明確になる |
4. システムを運用する人の範囲（p17）
役割関連図とは、サービス開始後にシステムについての問い合わせや障害などを解消できる体制の役割を記載した図のこと。
5. 運用設計の目指すレベル（p20）
参考になるのが「COBIT成熟度モデル」。社内でITシステムがどのくらい適切に定着・管理されているかを客観的に測定する手段として、レベル0〜5の段階が定義されている。
| レベル | 名称 | 内容 |
|---|---|---|
| 0 | プロセス不在 | 運用プロセスが全く存在せず、解決すべき課題・問題があることすら認識できていない |
| 1 | 個別対応 | 課題・問題があることは認識できているが、まとまった運用プロセスは存在せず、個人が場当たり的に対応している |
| 5 | 最適化 | 運用管理チームが主体となり、継続した改善活動・他社比較により運用プロセスがベストプラクティスまで最適化されている。IT全体の統合が行われ、品質を担保しながら効果を最大化するツールが提供されている |
6. 運用設計に必要な3つの分類（p22）
| 分類 | 内容 |
|---|---|
| 業務運用 | システムを活用してサービスを提供するアプリケーションと利用者に関する業務 |
| 基盤運用 | システムを維持してアプリケーションが問題なく動作するためのシステム基盤に関する業務 |
| 運用管理 | 運用全体を管理して円滑に行えるよう、全体のルールとものさしを決めて管理する業務 |
7. なぜ運用設計の専門家は少ないのか（p28）
発注者がシステム導入に求めるものと、システム運用に求めるものの間に乖離がある。システム運用に求められているのは安定稼働と効率的なサービス提供だが、その重要性が認識されにくいことが背景にある。
8. 運用設計担当が作成するドキュメント（p35）
プロジェクト内でのディスカッションで確定した運用方針・手順をドキュメントとして残し、関係者と合意する。合意した文書がそのまま運用に必要なドキュメント（運用ドキュメント）となる。
通常運用で使うドキュメント
| ドキュメント | 内容 |
|---|---|
| 運用設計書 | 運用項目ごとの方針・概要を記載。方針の理由やあえて採用しなかった方針も記載する |
| 運用項目一覧 | 導入するシステムで実施するすべての運用項目・作業項目・役割分担・関連ドキュメントを記載 |
| 運用フロー図 | 複数の役割が情報をやりとりする運用項目について、情報伝達方法・タイミングを図で表す |
| 運用手順書 | 運用項目一覧の作業・運用フロー図内の処理プロセスを実施するために必要な手順をまとめたもの |
| 申請書 | 運用フロー図内で情報連携するために必要な項目をまとめたドキュメント |
| 台帳 | 運用中に定期的に変更するデータを集めたドキュメント。主に手順書実施後に更新される |
| 一覧 | 運用中によく参照されるパラメーター値などをカテゴリーごとに集めたドキュメント。主に手順書から参照される |
運用テストで使うドキュメント
| ドキュメント | 内容 |
|---|---|
| 運用テスト計画書 | 運用テストの目的・実施日・スケジュールなどを取りまとめて記載 |
| 運用テスト仕様書 | 運用フローテスト・運用手順書テストの実施項目を記載 |
感想
「なぜ運用設計の専門家が少ないのか」という問いに対して、発注者側の意識の問題として説明されていた点が腑に落ちた。現場で運用設計がないがしろにされる理由が、構造的な問題だったと納得できた。
また、開発側の人間であっても運用を意識して設計する必要があると改めて思った。機能を作るだけでは不十分で、その後の運用コストまで考えて設計することが本当の意味での品質につながる。そう考えると、ソフトウェア開発は開発・運用・ビジネスの知識を横断して求められる、非常に難しい業界だと感じた。
実践できること
- 個人開発プロジェクトの運用設計書を書く
- 運用項目一覧を作成する
- 運用フロー図を作成する
定量評価（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 |