新しい部署へ異動したり社内プロジェクトにアサインされた時には、最初にタスクとして”何を”やるかを知るだけでなく、“なぜ“やるのかを明確にすることが大事だと前記事で書きました。部署やプロジェクトの目指す姿や目的を、上司や顧客を通じて正しく理解し、認識違いを軽減するためです。
本記事では、その次ステップとして、”なぜ”を踏まえ、改めて”何を”やるかを主体的に組み立てるコツを紹介します。ざっくり説明は受けたんだけどそれ以上の指示は受けてないから動けない、だともどかしいですよね。はじめてチームやプロジェクトをリードされる方の参考になればと思います。
ITILというIT運用の方法論から、サービスデザインというステージのタスクを参考にします。
ITILについてはこちらの記事を参照ください。
また、以下の本の解説も多く引用して記事を書いています。さらに詳細を知るにはぜひ書籍を読まれることをお勧めします。
書籍の主人公によるブログのお蕎麦屋さん例え記事も、ITILサイクルを知るには参考になります。
業務のライフサイクルを考えよう！～お蕎麦屋さんにたとえてみる
サービスデザインとは
サービスデザインは、以下の7つのプロセスに分かれます。
- サービスカタログ管理
- サービスレベル管理
- 可用性管理
- キャパシティ管理
- サービス継続性管理
- 情報セキュリティ管理
- サプライヤ管理
前ステージであるサービスストラテジでは、”なぜ”やるのかを明確にします。そのうえで何をどこまでやるのか、何かあった時どうするのかを明確にするのがこのサービスデザインです。
IT業界に属していても用語は独特ですので、汎用的にかみくだくと以下の表現になります。
- サービスカタログ管理 →何をやるのか一覧化する
- サービスレベル管理 →どこまでやるのか明確にする
- 可用性管理 →普段何かあった時どこまで対応するのか明確にする
- キャパシティ管理 →必要なリソースを明確にする
- サービス継続性管理 →災害時などにどこまで対応するのか明確にする
- 情報セキュリティ管理 →情報管理に気をつける
- サプライヤ管理 →自分以外を管理する
最初は上司や顧客などの依頼元から説明を受けますが、説明時間には限りもありますし、説明を受ける側の思考回路に沿って全てを説明することはできません。そこで、説明を受ける側自身で咀嚼し消化していくことが大事になります。
本記事で紹介する枠組みを利用することで足りないものが見えてきます。足りないものを自分なりに考えて提案したり、案を作って検討を持ちかけることで、主体的に業務を組み立てることが可能になります。
何をやるのか一覧化する
サービスカタログ管理では、業務の過不足をなくし優先度を明確にします。
サービスカタログの項目例は以下です。
- 概要
- いつ
- どのくらい
- 誰が
- 何を
- 何を使って
- 誰に
- 関係者は
- どれだけ重要で
これらを、以下のプロセスを通じて行います。
- サービスの洗い出し
- サービスカタログの作成
- 定期的な見直しと最新化
作業内容の引継ぎを受けた後でも、このカタログに情報が埋められるかを確認すると、意外と埋められないものが出てきます。一つひとつを確認することで業務内容とその重要性を可視化できます。
これは、プロジェクト管理におけるスコープ管理のようなもので非常に重要です。抜け漏れなく洗い出すことと同じくらい、このカタログをメンテナンスし最新に保つことが重要です。
どこまでやるのか明確にする
サービスレベル管理では、何をどこまで頑張ればいいかを明確にします。しかし現場ではあまり好まれない言葉かもしれません。
それは、契約や明示的なルールとして決めてしまうと、クレームやペナルティの対象になりうるためです。しかしながら、国をまたいだり価値観の異なる組織同士で業務を行う際は、後で揉めない（揉めた時に困らない）ためにも、SLAを締結しておくことをお勧めします。
サービスレベルの項目例は以下の通りです。
- 目的
- 対象範囲
- 役割と責任
- サービス提供時間
- 連絡先
- 目標処理時間
- 対応可能件数
- 可用性目標値
- サービス復旧目標時間
- サービス継続性の取り決め
- 測定/報告
- SLA見直し周期
プロジェクト管理における品質管理に相当しますが、プロジェクトでは個々のタスクやフェーズを通じて品質を高めるのに対し、ITILでは顧客へのサービス提供が中心になるのが違いです。
普段何かあった時、どこまで対応するのか明確にする
可用性管理では、上記のSLAで約束したレベルの業務を安定して提供するための方法を明確にします。
以下のプロセスを通じて行います。
- SLAの確認
- 可用性の目標値の設定
- 現状把握/リスク分析
- 可用性向上のための活動計画策定と実行
「全部大事」と主張するのは非現実的ですし、それに近づけようとするとコストも高くなります。業務に応じた適切な活動計画を立てることが重要です。
必要なリソースを明確にする
キャパシティ管理では、定義した業務を行うのに過不足ないリソース（ヒト・モノ・システムなど）を準備します。
以下のプロセスを通じて行います。
- SLAの確認
- ビジネス計画の確認
- キャパシティ目標値の設定
- 現状把握/需要分析
- キャパシティ向上/増強のための活動計画策定と実行
プロジェクト管理はそのプロジェクトのサービスインを目指すのに対して、ITILでは、定常的な体制維持や平準化の色が濃くなります。
災害時などにどこまで対応するのか明確にする
サービス継続性管理は、災害時など万が一のときに業務をどのレベルでどのように継続させるかを決めておき、準備しておくものです。これは、全社レベルでBCP（Business Continuity Plan）として災害時の継続の考え方や目標値、体制、運用方法が決まっていることも多いです。個別に考えるというよりは、有事の対応としてどのような方針があるかを確認しておけばよいでしょう。
情報管理に気をつける
情報セキュリティ管理は、業務に必要な情報を安全に利用するためのプロセスです。機密情報や秘匿情報の取り扱い方針を決めておくものです。
意識すべき三要素
- C Confidentiality（機密性）知る権限がある人のみ閲覧可能
- I Integrity（完全性）改ざんできない
- A Availability（可用性）必要なときに利用可能
以下のプロセスを通じて行います。
- 全社情報セキュリティポリシーとビジネスニーズの確認
- 脅威/リスクの特定
- 方針/ルールの策定
- 定常的な運用
- 改善/是正
自分以外を管理する
サプライヤ管理は、外注先（サプライヤ）から約束したサービスが提供されるようにするものです。
以下のプロセスを通じて行います。
- サプライヤ戦略/方針の策定または確認
- 委託要件の定義/サービスレベルの定義
- サプライヤの選定（または見直し）
- 契約締結・SLA締結
- サプライヤのパフォーマンス評価と改善/是正
- サプライヤ情報（契約/評価情報など）データベースの構築と維持管理
おわりに
プロジェクトと定常業務の大きな違いは、プロジェクトが目的の成果物作成完了を目指すのに対して、定常業務は引き受けた業務内容についてサービスレベルを満たし続けるという違いがあります。優先順位や何かあった時の対応を事前に決めておくための参考になれば幸いです。