ITシステム(サービス)の運用設計における最初のステップは、運用設計全体のベース(前提)となる以下の３点を、「グランドデザイン」として検討し、可視化することです。
1.運用体制(組織構造と各グループの役割)
2.規定する管理プロセスの検討
3.作業場所とアクセス経路の整理
なお、運用グランドデザインは、開発チームが実施するシステムの要件定義や概要設計などの上流タスクと並行して行い、開発チームと認識のずれがないようにしておかなければなりません。
また、既存の体制や管理プロセスがある場合でも、新たにITシステム(サービス)を作る際には、運用グランドデザインを必ず実施してください。
運用グランドデザインが無い状態でシステム開発を進めると、システム設計に対するインプットが漏れ、後で大きな手戻りが発生する事につながります。
それでは、運用グランドデザイン内の各項目の詳細についてご説明していきたいと思います。まずは「運用体制(組織構造と各グループの役割)の検討」です。
1.1.運用体制(組織構造と各グループの役割)の検討
IT運用設計において、最初に実施すべき事は運用体制(組織構造と各グループの役割)の検討です。
私の経験上、「運用がうまく回らないんだけど、何から手をつけたら良いか分からない」という組織では、運用体制の組織構造や各グループの役割が曖昧か、実態と大きく乖離している事が非常に多いです。
良くない運用体制図の例を以下にあげてみたいと思います。
以下の図は、私が相談を受けたあるシステムの企画書に「運用体制」として書かれていたものをデフォルメしたものですが、ほぼ会社の組織図ですね…(苦笑)
これはかなり極端な例ですが、「この体制図では誰が何をするのか、全く分からないじゃないか！」というような運用体制図はかなりの頻度で見かけます。
「いい加減な運用体制図が多い」という事に関連して、IT運用に関わる者としてどうしても言いたい事があるので以下の囲みの中に書いていますが、「運用体制図には何が必要か」を早く知りたい方は読み飛ばしてください。
運用体制の検討は、以下の順番で行います。それぞれの詳細についてご説明します。
(1)運用フェーズの作業を「担当するグループ」を意識して分類する
(2)作業実施を承認するグループを意識する(内部統制を意識する)
(3)運用体制図として可視化する
1.1.1.運用フェーズの作業を「担当するグループ」を意識して分類する
運用体制検討の最大の目的は「どんなスキルの人(グループ)が、どんな作業をするのかを定義する」という事ですので、まずは以下の点を意識して運用フェーズの作業を分類します。
- 運用フェーズではどのような作業が発生するか
- その作業をどのようなグループ(チーム)が担当するのがよさそうか
もし、「当初はシステム(サービス)の規模が小さく、作業量も少ないのでグループを分けて役割分担をするつもりはない」という場合でも、作業の分類は必ず行ってください。作業の分類を行わず、開発メンバーがそのまま全ての作業を担当しているようなケースをよくみかけますが、規模が大きくなった時に「要員を入れ替える事が可能か」の判断すらできなくなるという、大きな属人化リスクを抱える事になります。
具体的に例をあげてみます。
一般的なITシステム(サービス)では、以下のように作業を分類し、担当するグループをイメージすると大体あてはまるのではないかと思います。
- 顧客フロント - コミュニケーション作業：サービスデスクグループ(顧客とのIFを、電話・メール・SNS等で行うグループ)
- 顧客フロント - ビジネス作業：営業部門
- バックエンド - システム運用作業(定型)：運用オペレータグループ(手順書に基づいて定型的な作業を実施するグループ)
- バックエンド - システム運用作業(非定型)：保守SEグループ
- バックエンド - システム保守作業：保守SEグループ
1.1.2.作業実施を承認するグループを意識する(内部統制を意識する)
大体の作業分類と、担当するグループについてイメージができたら、次は「内部統制」の観点から運用体制をイメージしてみましょう。
IT運用では「内部統制」という言葉をよく使いますが、「分かっているようでよく分からない」という言葉ですので、少し「IT運用における"内部統制"とは何か」という事を整理しておきたいと思います。
「内部統制」という言葉は、IT運用に関わらず、会社組織などのあらゆる組織に適用される言葉です。以下に、Wikipediaの「内部統制」のページの冒頭の一文をご紹介します。
内部統制（ないぶとうせい、英：internal control）とは組織の業務の適正を確保するための体制を構築していくシステム（制度）を指す。すなわち、組織がその目的を有効・効率的かつ適正に達成するために、その組織の内部において適用されるルールや業務プロセスを整備し運用すること、ないしその結果確立されたシステムをいう。
出典 Wikipedia
WikipediaのこのページはIT運用に関して書かれたものではありませんが、上記の一文はIT運用においてもピッタリとあてはまります。
つまり、IT運用における内部統制とは、「運用体制の内部において、守るべきルールやプロセスを整備し運用すること」と思って頂ければ、明確にイメージを捉える事ができるのではないかと思います。
前置きが長くなってしまいましたが、ここでお伝えしたいのは、「運用全体に責任を持ち、作業実施を承認するグループが必要」という事です。なぜなら、定められたルールやプロセス通りに運用するためには、「承認」というゲートが必ず必要になるからです。
分かりやすい例は、本番環境での作業の申請です。IT運用では、以下のような流れで作業申請・承認・報告を行う事が一般的ですよね。
この例では「運用統括グループ」というグループが運用体制に登場する事になります。
作業を実施するグループが作業申請を行う
↓
運用全体に責任を持っているグループ(運用統括グループ)が承認を行う
↓
作業が完了したら、運用統括グループに作業完了報告を行う
1.1.3.運用体制図として可視する
作業分類・担当するグループ・承認の流れ(内部統制)をイメージできたら、組織構造と役割を運用体制図として可視化します。
以下に、運用体制図の例を示します。
最初にご紹介した「ダメな運用体制図の例」と比べると、「どのグループがどんな作業を実施するのか」、「各グループはどのように統制されるのか」が一目瞭然になっている事が分かると思います。
なお、体制図を描く際には、以下の点に注意してください。
-
「同じ人が担当するから」という理由で安易にグループの箱を減らさない
実際に担当する人を想像した時に、1人の人が複数の役割を持つ事があるかもしれません。
例えば、システム(サービス)の初期稼働時には規模が小さいので、「山田さん」という人が「運用オペレータ」も「AP保守」も「インフラ保守」も全て行うようなケースです。しかし、「同じ人が担当するから」という理由で安易にグループを統合して減らす事は危険です。
この段階でグループを分けているという事は「性質の異なる3つの作業分類が存在する」という事なので、安易にグループを統合すると、規模が大きくなった途端に対応できなくなってしまいます。
このようなケースにおいては、「山田さんを3つのグループにアサインする(3つの役割を兼務する)」と考える事で、グループの箱を減らさずに体制図を描くようにしてください。 -
既存の組織との整合性を優先しすぎない
もしかしたら、あなたの会社にはすでに運用のための組織が存在するかもしれませんが、既に存在している運用組織の構成通りの体制図にする必要はありません。人と同じで、「運用体制図上のグループに、既存組織をアサインする」と考えるようにしてください。 -
運用体制の外部とのIFは明確にしておく
運用体制図上、「運用体制の外部とのやり取りをどのグループが行うのか」は明確にしておきましょう。IFとしての役割を明確にできるだけでなく、考慮漏れを防ぐ事ができます。(外部とのやり取りが、運用体制の考慮から漏れるケースが結構多いです)
以上で、 「1.1.運用体制(組織構造と各グループの役割)の検討 」は終了です。成果物としては、「作業分類・グループ・統制が意識された運用体制図」が作成されているはずです。
1.2.規定する管理プロセスの検討
運用体制図を作成したら、次は規定する管理プロセスの検討を行います。
前章では作業申請の例をあげましたが、適切な運用を行うためには、運用者全員が様々なルールに従わなければいけません。逆に言うと、運用のためのルールを予め規定しておく必要があるのです。
しかし、一言にルールと言ってもいろんなレベルのものがありますよね。例えば、障害発生時の対応だけ考えてみても以下のようなルールが思いつきます。
- 障害対応で実施した作業は全て記録する事
- 手順書に従って障害の切り分けと一次対応手順を実施する事
- 一次対応手順で解決しない場合はエスカレーションする事
- サーバにログインする際は作業申請を行って承認を得る事
このようなIT運用に必要な様々なルールは、「管理プロセス」を軸にしてまとめていく事で、体系的に整理する事ができます。
※「プロセス」とは、「一連の活動の流れをまとめたもの」です
上記の障害対応の例ですと、「インシデント管理プロセス」という管理プロセスで一連の活動の流れをまとめ、各活動の内容を規定するようなイメージです。
上の図は、ITIL®でもおなじみのインシデント管理プロセスの超簡略版です。
「ITIL®4になってプロセスはなくなったのですか？」という質問をよく受けるので、その点について以下の囲みに記載しますが、やや理屈っぽい話になるので、読み飛ばして頂いても結構です。
規定する管理プロセスの検討は以下の順番で行いますので、それぞれの詳細についてご説明します。
(1)ITIL®から必要そうな管理プロセスを選択する
(2)管理プロセス間の関係性を可視化する
(3)運用シーンを想像して作業管理プロセスを追加する
1.2.1.ITIL®から管理プロセスを選択する
IT運用に関わる知識体系としては、ITIL®が非常に有名です。日本のIT業界では「IT運用といえばITIL®一択」と言ってもよいくらいですね。
(最近では、「複数サービスの統合と管理」に重点を置いた「SIAM™」というフレームワークもやや広がっていますが、まだご存じない方も多いと思います。SIAM™については追って別のページでご紹介したいと思います)
私もITIL®は大好きなのですが、多くの会社散見されるのが「IT運用は全てITIL®に準拠すべし」という勘違いです。
この勘違いをしている上層部の方が多い事で、膨大な無理や無駄が発生しています。
以下の囲みの中で「IT運用は全てITIL®に準拠すべし」という事が何故間違いなのかを説明したいと思いますが、やや学術的(理屈っぽい)話になるので読み飛ばして頂いても結構です。
規定する管理プロセスを検討するにあたり、ITシステム(サービス)に関する活動のベストプラクティス(orフレームワーク)であるITIL®を参照する事は非常に有効です。
まずは、IT運用との関連性が深い、サービスオペレーション領域・サービストランジション領域のプロセスを中心に、必要となる(運用設計で規定する)管理プロセスを選択していきましょう。
それぞれの領域毎に、プロセスの実施内容と要否判断のポイントを記載していますので、システム(サービス)の特性に応じて取捨選択してください。
どのプロセスが必要かよく分からないという場合は、とりあえず下表の赤字部分のみを規定するようにしてください。ほとんどのケースでは赤字のプロセスでまずは十分ですし、これらのプロセスを確立しておけば、他のプロセスは後から追加で規定する事も容易です。
■サービスオペレーション領域
・インシデント管理・問題管理・アクセス管理はどんなシステム(サービス)においても必ず必要です。
・要求実現は、利用者からの要求の受付があるのであれば、必要です。
・イベント管理は、情報レベルや警告レベルの通知からインシデントを検出するような活動ですので、そのような活動を想定しないのであれば規定は不要です。
| プロセス名 | 目的と実施内容 | 要否判断のポイント |
|---|---|---|
| 要求実現 | ユーザからの要求を受け付け、効率的かつ迅速に対応する | 問い合わせなど、利用者からの要求受付があるのであれば必要 |
| イベント管理 | イベントを検出し、それが意味するものを判断し、適切な処置を決定する | 情報レベルや警告レベルの情報を分析して利用する想定があるのであれば必要 |
| インシデント管理 | インシデントが発見された後に、可能な限り迅速にサービス運用を通常レベルに復旧させる | 必ず必要 |
| 問題管理 | ・インシデントの根本原因を特定する ・インシデントの再発(or発生)を防ぐための対策を実施する。完全に防止できない場合は影響を最小限に抑えるための対策を実施する |
必ず必要 |
| アクセス管理 | ・許可されたユーザに適切なアクセス権を付与する ・定期的にアカウントの棚卸を実施し、適正な状態を保つ(管理簿と実機情報の突合) |
必ず必要 |
■サービストランジション領域
・変更管理はどんなシステム(サービス)においても必ず必要です。
・変更評価・リリース及び展開管理・サービスの妥当性確認及びテストは、変更管理プロセスによって統制される子プロセスのようなものです。日本では、開発(保守)チームの中でこれらに関する内部ルールが確立している事が多く、変更管理プロセスの中で実施状況を確認すれば十分であるため、一般的には運用設計で個別に規定する必要はありません。
・サービス資産管理及び構成管理は、基本的には必要です。また、グランドデザインの時点で「何を管理するのか」までを決定する必要があります。
・ナレッジ管理の仕組みは、一般的には全社のものがあったりする事が多いので、個別に規定する必要があるかどうかは組織はシステム(サービス)特性次第です。
| プロセス名 | 目的と実施内容 | 要否判断のポイント |
|---|---|---|
| 変更管理 | ITサービスへの影響を最小限に抑えながら変更できるように、変更要求への対応と、展開(リリース)について適切な判断を行う | 必ず必要 |
| 変更評価 | 変更案件に対する全体的な評価計画を立案し、変更に対して適切な評価を行う | 一般的には変更管理の中で確認されるため、特段の事情がなければ個別にプロセスを規定する必要はない |
| リリース管理及び展開管理 | リリースと展開の計画を立案し、リリースと展開をコントロールする | 一般的には、変更管理の中で確認されるため、特段の事情がなければ個別にプロセスを規定する必要はない |
| サービスの妥当性確認及びテスト | ITシステム(サービス)がその設計仕様に合致している事をテストする。 | 一般的にはシステム(サービス)の構築時に「テストルール」として規定されるため、IT運用設計で新たにプロセスを規定する必要はない |
| サービス資産管理及び構成管理 | ・資産や構成情報を適切に管理する ・定期的に棚卸を実施し、適正な状態を保つ(管理簿と実機情報の突合) |
基本的には必要。「何を管理するのか」までこの時点で決定する必要あり |
| ナレッジ管理 | ナレッジを共有し、効率的に利用できるようにする | ナレッジ共有のための何らかの仕組み(ツール)はあった方がよいが、プロセスを個別に規定する必要があるかどうかは組織やシステム(サービス)特性次第 |
■サービスデザイン領域
サービスデザイン領域のプロセスは、システム(サービス)の設計がメインですのでで、一般的にはIT運用設計として新たに規定する事は不要ですが、サービスレベル管理とキャパシティ管理については個別に規定しておく必要があります。
| プロセス名 | 目的と実施内容 | 要否判断のポイント |
|---|---|---|
| サービスレベル管理 | サービスレベルを測定し、利用者への報告・レビューを通じてサービスの改善につなげる | SLAまたはSLOを定義しているのであれば必要 |
| キャパシティ管理 | 容量・性能に関するシステムの状況を測定し、問題の検出や拡張計画につなげる | 容量・性能を意識しなくてよい特段の理由がなければ必要 |
■サービスストラテジ領域
サービスストラテジ領域のプロセスは、全社戦略レベルのプロセスなので、一般的にはIT運用設計として新たに規定する事は不要です。
■継続的改善領域
継続的改善領域の「7ステップの改善プロセス」は、全プロセスで共通的に実施すべき以下の改善ステップ(概念)ですので、個別の規定は不要です。
１．改善の戦略を識別する
２．測定するものを定義する
３．データを収集する
４．データを処理する
５．情報とデータを分析する
６．情報を提示して利用する
７．改善を実施する
1.2.2.管理プロセス間の関係性を可視化する
ITIL®から必要そうな管理プロセスを選択したら、次は管理プロセス間の関係性を可視化します。管理プロセス間の関係性を可視化する事で、運用フェーズにおける管理の流れを俯瞰的にイメージできるようになります。
例として、前章で赤字にした各管理プロセスの関係性を可視化した図を記載します。前章で選択したプロセスに応じて追加・削除を行ってください。
1.2.3. 運用シーンを想像して管理プロセスを追加する
前章までで、ITIL®から必要そうな管理プロセスを選択し、その管理プロセス間の関係性を可視化しました。
しかし、実際に運用をするためには、これらの管理プロセスだけでは足りないので、実際の運用シーンを想像して作業レベルでの管理プロセス(作業管理プロセス)を追加する必要があります。
IT運用において、一般的に必要となる作業管理プロセスには以下のようなものがあります。実際の運用シーンを想定して、規定すべき作業管理プロセスを決定してください。
| 作業管理プロセス | 規定する内容 |
|---|---|
| 作業申請 | 申作業実施にあたり、必要となる申請・承認のルールを規定する |
| 特権アカウント払出申請 | 作業に必要となる特権アカウントの払い出し、返却のルールを規定する |
| データ持出/持込申請 | システムからのデータの持ち出しや、データの持ち込みに必要となる申請・承認のルールを規定する |
| 定例作業管理 | 日次や月次など、定例で実施する作業の管理ルールを規定する |
| 運用アカウントパスワード管理 | 運用アカウントのパスワードの管理方法・定期的な変更・パスワードリセットなどのルールを規定する |
| 証跡管理 | 不正アクセス・不正操作の有無を確認するために定期的に確認を行う対象や、セキュリティ事故発生時の追跡調査を行うためのログを規定し、収集・蓄積・確認のルールを規定する |
| 文書管理 | 管理する文書の登録・変更・廃止に関するルールを規定する |
| 入退室管理 | 運用作業室への入退室の権限付与や入退室監視に関するルールを規定する |
以上で、 「1.2. 規定する管理プロセスの検討 」は終了です。 成果物としては、以下の2点が作成されているはずです。
- 規定するITSMプロセス一覧と、ITSMプロセス間の連携図
- 規定する作業管理プロセス一覧
1.3.作業場所とアクセス経路の整理
運用グランドデザインの最後に、作業を実施する場所・端末・アクセス経路の整理を行います。この整理を行うためには 「作業分類・グループ・内部統制が意識された運用体制図」が前提となりますので、まだ作成できていない場合は「1.1.運用体制(組織構造と各グループの役割)の検討」を参照し、体制図を作成してください。
なお、本章に記載している整理は、システムのNW設計やアクセス制御設計へのインプット(要件)となりますので、必ず開発チームと一緒に整理をするようにしてください。
下表は、クラウド(AWS)上に構築するシステムへの作業場所とアクセス経路を整理した例です。
この例では、専用運用端末(共用物理PC)を運用室に設置し、本番環境/テスト環境へのアクセスは専用運用端末(共用物理PC)から実施する想定としていますが、会社やシステム(サービス)のセキュリティ方針によっては全く違った形になります。
作業場所とアクセス経路の整理は以上となります。
これで、運用グランドデザインは終了です。今後の運用設計のベース(前提)となる以下の成果物ができているはずです。
- 作業分類・グループ・統制が意識された運用体制図
- 規定するITSMプロセス一覧と、ITSMプロセス間の連携図
- 規定する作業管理プロセス一覧
- 作業場所とアクセス経路の整理結果
いかがでしょうか？IT運用設計でやるべき事が、何となく見えてきたのではないでしょうか。
それでは、次のフェーズ(2.運用基本設計)に進んでいきましょう！
