開発組織の活動を経営に報告するための指標を整理する

こんにちは。

最近、開発組織の活動や成果を、どのように経営に説明すれば良いかに取り組んでいます。

その中で、開発組織の活動を経営の関心事と結びつけて説明するために、COBIT、ITIL、ISO 27001（ISMS）などのフレームワークで整理されている指標を参考に、開発組織の活動を経営に報告するための指標を整理してみました。

例えば Four Keys の計測や障害対応時のポストモーテムの作成など、開発組織では様々な取り組みを定量的・文書化した状態で活動を行なっていますが こうした開発チームの活動を経営に報告する際には、どのようなやり方で説明するのが良いでしょう？

そこで、既存の信頼できるフレームワークで整理されている指標を使用する、というアプローチを取って、ありものを使いつつ説明責任が果たせるような形が良いように思います。

目次

COBIT について

COBIT（Control Objectives for Information and Related Technologies）は、ISACA が提供する、企業や組織の IT ガバナンスおよび IT マネジメントのためのフレームワークです。

企業が IT を活用する際に、IT 投資が事業戦略と整合しているか、適切なリスク管理が行われているか、限られた資源が有効に活用されているか、といったことを評価・管理するために利用できます。 特に上場企業では、IT 投資やリスク管理について、株主をはじめとしたステークホルダーに対する説明責任が求められる場面があり、IT ガバナンスの健全性を評価して説明するための共通の枠組みとして活用することが期待できそうです。

COBIT の特徴として、ITIL や ISO 27001 など、他のフレームワークと組み合わせて利用できる点があります。 例えば、COBIT によって IT ガバナンス全体の目標や管理の仕組みを整理し、その中で IT サービスマネジメントには ITIL、情報セキュリティマネジメントには ISO 27001 を活用する、といった考え方ができます。

COBIT 2019 には 40 のガバナンス・マネジメント目標が定義されており、それぞれの目標に対して、達成すべき成果物や評価指標が整理されています。 全ての目標を一律で導入するのが目的ではなく、組織の状況や目的に応じて、必要な目標を選択して導入することが推奨されています。 COBIT を活用する際は、まず自社の組織がどのような状況にあるのかを整理し、どの目標を導入するのが適切かを検討することが重要なように思います。

以下の記事が分かりやすかったので、合わせてご覧ください： https://www.josis365.com/blog/cobit-it-governance-framework-guide/

ITIL について

ITIL（Information Technology Infrastructure Library）は、IT サービスマネジメントのベストプラクティスを体系化したフレームワークです。 目的は IT サービスをビジネスの目標や顧客のニーズに合わせて適切に提供・管理することです。 例えば、システム障害が発生した場合に誰が対応するのか、どのように復旧するのか、再発防止をどう進めるのかといった、インシデント管理の運用を管理するための考え方やプラクティスが整理されています。

ITIL では 34 のマネジメントプラクティスが定義されており、以下の 3 つのカテゴリに分類されています。

• 一般的なマネジメントプラクティス（例：リスク管理、変更管理、継続的改善など）
• サービスマネジメントプラクティス（例：インシデント管理、問題管理、サービスレベル管理など）
• 技術マネジメントプラクティス（例：ソフトウェア開発・管理、インフラ管理など）

詳細はこちらで参照できますが、その中で個人的に興味深かったのは、インシデント管理と問題管理が区別されていることです。

ITIL 4 as a toolkit, not a rulebook

How I use ITIL 4 in infrastructure teams: the value system, value chain, 34 practices, CMDB, events and improvement, and what ITIL Version 5 changes.

punit.co.uk

インシデント管理は、発生した障害からサービスを迅速に復旧させることを目的としています。 一方で、問題管理は障害の根本原因や再発リスクを管理し、将来的なインシデントの発生や影響を減らすことを目的としています。

つまり、障害からの復旧と、障害を繰り返さないための取り組みは、それぞれ異なる目的を持つ活動として整理されている、ということです。

これは実際に開発組織で障害対応を行う際にも意識できる区分だと思いました。

また、最新版の ITIL 4 ではアジャイルや DevOps、継続的改善といった考え方も取り込まれています。

そのため、従来の古典的な IT 運用に留まらず、現代的なソフトウェア開発のベストプラクティスを組織に取り込んでいく際にも ITIL をフレームワークとして活用できそうです。

ISO 27001 / ISMS について

ISMS（Information Security Management System）は、組織が情報セキュリティを継続的に管理するための仕組みです。 そして、ISO/IEC 27001 は、その ISMS が満たすべき要求事項を定めた国際規格となっています。

情報セキュリティというと、脆弱性対応やアクセス制御、暗号化といった技術的な対策を想像しがちですが、ISMS ではそれだけを扱うわけではありません。

情報セキュリティの基本となるのが、次の3要素です：

• 機密性（Confidentiality）：情報が許可された人だけにアクセスされることを保証すること
• 完全性（Integrity）：情報が正確で完全であることを保証すること
• 可用性（Availability）：情報が必要なときに利用可能であること

これらを守ることは重要なのですが、全てのリスクをゼロにすることは現実的ではなく、どのようなリスクが存在し、それが事業にどれほど影響を与えるのかを評価した上で、どこまで対策に投資するかを判断する必要があります。 この判断を行うためには、技術だけでなく当然経営の視点が必要になります。

ISMS では、情報セキュリティのリスクを評価し、適切な対策を講じるためのプロセスが整理されています。 第三者認証を取得することで、組織が情報セキュリティを適切に管理していることを外部に示すこともできます。

ISMS 認証を取得しているからといってセキュリティ事故が起きないわけではありませんが、組織として情報セキュリティを管理するための仕組みを整備していることを示すことができます。

3つのフレームワークをどう使い分ける？

ここまで調べてみると、COBIT、ITIL、ISO 27001 はそれぞれ異なる視点から IT を管理するためのフレームワークであることが分かります。

経営が何を知りたいのか、何を評価したいのかによって、適切なフレームワークを選択して活用することが重要そうです。

COBIT の Goals Cascade という考え方

フレームワークを用いて経営に説明する、という観点で考えた時に、参考になったのが COBIT の Goals Cascade という考え方です。

Goals Cascade では、企業の目標を IT に関係する目標へと展開し、さらにガバナンス・マネジメント目標と結びつけるための仕組みです。

大まかには、次のような関係になります。

flowchart LR
    A["企業目標<br/>Enterprise Goals"]
    B["IT整合目標<br/>Alignment Goals"]
    C["ガバナンス・<br/>マネジメント目標<br/>Governance and<br/>Management Objectives"]
    D["具体的な活動・<br/>測定・改善"]

    A --> B --> C --> D

例えば、企業として「新しい機能を迅速に市場へ投入し、事業成長を加速させたい」という目標があるとすると、その目標に対して、開発組織では「変更のリードタイム短縮」や「デプロイ頻度の向上」といった取り組みが考えられます。 さらに、そのための具体的な施策として「CI/CDの改善」「テスト自動化」「開発プロセスの見直し」などがあげられます。

Goals Cascade という考え方を用いることで、開発チームの活動を単に技術的な改善として報告するのではなく、事業目標から逆算して位置付けることができるようになります。

まず最初に活用できそうな COBIT の項目

COBIT 2019 には 40 のガバナンス・マネジメント目標がありますが、開発組織の活動を経営に説明するという観点では、特に以下の項目が活用できそうに思いました。

例えば開発生産性の向上を経営に説明するのであれば、 EDM02 価値提供の確保、APO05 ポートフォリオ管理、MEA01 パフォーマンス・適合性の監視 などの指標を組み合わせて説明することができそうです。 また、障害対応や品質改善であれば APO11 品質管理、DSS02 サービス要求・インシデント管理、DSS03 問題管理 などの指標を組み合わせて説明することができそうです。

ITIL のプラクティスの活用

ITIL についても、開発組織の活動と結びつけて活用できるプラクティスがいくつかあります。

実際に使用するならどうするか？

ここまでの学びを踏まえて、経営への説明では、フレームワークの項目をそのまま並べるのではなく、まず経営が何に関心を持っているのかを整理しながら使っていく必要がありそうです。

目的によって追うべき指標は変わるため、経営が何を知りたいのかを整理しながら、COBIT、ITIL、ISMS の中から適切な指標を選択して説明することが重要そうです。

まとめ

今回は、開発組織の活動を経営に説明するためのフレームワークとして、COBIT、ITIL、ISO 27001について調べてみました。

それぞれの目的は異なりますが、共通しているのは、ITを単なる技術的な活動として捉えるのではなく、事業に必要な価値を提供し、リスクを管理し、継続的に改善するための仕組みとして考えていることだと思います。

特に COBIT の Goals Cascade という考え方は、開発組織の活動を経営目標と結びつける上で参考になりました。

一方で、フレームワークを使うこと自体が目的になってしまうのも避けたいところです。経営の目的ベースで何が活用できるのかを考えていくことが重要だと思いました。

今回学んだ内容を踏まえて、実際の開発組織の指標や改善施策をこうしたフレームワークと結びつけて整理し、経営への説明責任を開発組織としてより一層果たせるようにしていきたいですね。