第２回は「サービス・ポートフォリオ管理」について考えてみたいと思います。
　ITサービスが企業の活動基盤になってきた今、企業内にどんなサービスがあって、誰によって管理されていて、どのようなツールで運用が行われているのかを管理するのは非常に重要なことになります。

目次

全社横断でサービスを管理する

サービス・ポートフォリオでサービスのライフサイクルを管理する

ステータス変化と活動内容をまとめる

全社横断でサービスを管理する

　これからの運用ではこれまでのオンプレミスで提供されているシステムやサービスの管理と合わせて、クラウドサービスなどを含めたサービス全体を管理するという考え方も必要となってきます。
　サービス管理は、企業で利用しているサービスのリソースを最大限に活用するのが目的です。リソースを最大限に活用していくためには、サービス全体に対する運用改善が求められます。視座を高くして企業全体のサービスを見渡し、まったく管理されていないサービスや一部の担当者しか運用ルールがわからないサービス、異なる運用ツールを利用しているサービスを見落とさないようにしなければなりません。

　そのためには、企業全体のサービスに何があるのか、だれが管理しているのかなどを把握する必要があります。そのための考え方がサービス・ポートフォリオ管理です。

サービス・ポートフォリオでサービスのライフサイクルを管理する

　サービス・ポートフォリオとは、企業が保有しているサービスを一覧化したリストのことで、優先度や目標などに合わせて適切な投資ができるようにするために活用されます。具体的には以下の目的のために利用されます。

• ・それぞれのサービスが提供している価値を明確にする
• ・サービス同士の関連性を明確にする
• ・サービスに対する投資と成果のバランスを可視化する
• ・サービスの責任者を明確にする

　本来は、サービスに関するリスクとコストを管理してサービスの価値を最大化する、という経営的な目的で利用されます。管理しているサービスの中で、投資対効果が高いサービスには積極的に投資し、逆に投資対効果の低いサービスは移行、統合、集約、廃止を検討していきます。
　経営層が戦略を練るために使われるサービス・ポートフォリオですが、運用者がサービス全体を管理するためにもたいへん役立ちます。今回は運用者の視点からサービス・ポートフォリオ管理を考えていきます。
　サービス・ポートフォリオ管理では、サービス・パイプラインとして「検討中」「開発中」、サービス・カタログとして「提供中」「廃止予定」、廃止されるサービスとして「廃止」という3つのプロセスと5つのステータスを管理します。
　各プロセスの概要は以下となります。

・サービス・パイプライン
　 導入を検討中や開発中のサービス群。この段階ではまだサービスを提供するとは確定していない。

・サービス・カタログ
　 稼働直前、稼働中、もしくは廃止予定のサービス群。ユーザーが把握したほうがよい情報のため、サービス・カタログ部分だけを一覧として公開することもある。

・廃止されるサービス
　 何らかの理由で統合や廃止となり、利用されなくなったサービス群。完全にサービスが廃止となった場合は、ユーザーに公開する必要がなくなるためサービス・カタログから外される。

　これらのステータスを管理するために、情報システム部門が管理しているサービスを台帳にまとめていきます。サービス管理台帳の代表的な項目は以下となります。

　これはベースになる項目です。この表にサービスごとに利用しているツール類をマッピングしたり、管理している組織をマッピングしていくことにより、企業全体のリソースを可視化していくこともできます。

ステータス変化と活動内容をまとめる

　サービス管理台帳でサービスの状態が可視化できるようになったら、各ステータスについてのルールを決めていきましょう。
　検討中から開発中へステータスを移行させるためにはどのような作業が必要なのか、提供中になるには何が必要なのか、廃止にするためにすることは何かを具体的に考えていきます。

①検討中としてサービス管理台帳へ登録
　サービス開発部門がサービスを台帳に登録する段階です。会社全体としてアイデアやリソースの統合／集約を行うことで、より効率的なサービス開発をすることができます。具体的にどの段階になったらサービス管理台帳に載せるかは企業文化が影響しますが、基本的にはサービス企画が部門などで内部承認された段階で記載するのがよいかと思います。なお、サービス検討段階から管理を始める理由としては、他部署が同様のサービス開発を行っていた場合、コラボレーションしてより良いものを生み出せないか検討するためです。

②検討中から開発中へ移行
　検討中の段階ではまだ予算やITリソース、人的リソースもついていない状態でしたが、承認されて開発中へ移行する段階で、サービス開始に向けてスケジュールなどが固まってきます。
　プロダクトを導入する際は、外部のベンダーやSIerへ依頼を出す場合もあるかと思います。運用としては、社外とのコラボレーションに備えて、開発初期段階で運用受け入れ基準や必要となるドキュメントの連携、運用ルールのインプットなどを行っておくとよいでしょう。
　運用受け入れ基準としては、おもに以下のことを連携します。

• ・共通となる運用ルールやセキュリティポリシーなどの運用設計の前提条件
• ・運用受け入れ時に必要となる運用ドキュメントの種類と概要
• ・共通で利用する運用ツール（パッチ適用、バックアップ、監視など）の情報
• ・ユーザー申請に利用するワークフローシステムの情報
• ・共通で利用する自動化ツールなどの情報

　開発中は、開発構築チームと運用チームで定期的に情報共有会を開催すると、スムーズな運用開始が可能になるでしょう。

③運用が開始されて提供中へ
　運用テストや運用引き継ぎを経て、サービスは運用チームへ引き渡されて提供中のステータスになります。提供中になってからは、運用チームによってサービスの維持管理が行われます。具体的には、サービス継続に必要な作業や障害対応、開発チームから引き継がれた構成情報の管理などを行います。

④サービスの廃止予定が決定
　サービスが役割を終えてサービスの廃止が決定します。代表的な廃止パターンは以下となります。

• ・導入している製品がEOS（End Of Service）を迎えて後継機種などに更改する
• ・他サービスに同様の機能があり、そちらに統合される
• ・導入してみたけれど、思った成果を発揮せずランニングコストがかかりすぎるため廃止する

　更改や統合の場合には、これまで使っていた運用ドキュメントは次のサービスの運用設計前提資料となるので、必要に応じて開発チームへ連携しましょう。

⑤廃止予定から廃止へ
　運用のコスト最適化の観点から、サービスが廃止されたらデータの破棄や運用ドキュメントの整理などを行い、管理対象から外すことが大切です。ただし、サービスによっては廃止後もドキュメントやデータの長期保管が必要な場合があります。そういった場合は、媒体へ書き出して保管するなど、事前に対応を決めておくとよいでしょう。

　サービス・ポートフォリオ管理でサービスのステータス管理を行うことで、サービスライフサイクルを管理することにもなります。
　運用改善の下地として、まず必要なことは「運用プロセスの整理／合理化／可視化」です。それが整ってきたら、次に「運用業務のデジタル化、ワークフロー化、自動化」によってリードタイムの短縮や運用工数の削減、作業ミスの軽減などを行っていくことになります。
　次回は自動化の種類と、自動化が運用に与える影響について説明します。

図の出典：『運用改善の教科書　～クラウド時代にも困らない、変化に迅速に対応するためのシステム運用ノウハウ』