#007 【Domain1深掘り】COBIT 2019の「設計因子」とは何か？提案書に落とし込む実践的な使い方
📌 このテーマのCGEITドメイン：Domain 1（ITガバナンスの枠組み・配点40%）
#006 実務活用編①はこちら
「このIT戦略、うちの会社の状況に合っていますか？」
クライアントからよく受ける問いだ。ITガバナンスの強化や、DX推進の構想を一緒に考えている場面で、こう返ってくる。
答えは「それはあなたの会社次第です」だ。しかしそれでは説明になっていない。実務でこの問いに答えるとき、私が拠り所にしているのがCOBIT 2019の「設計因子（Design Factors）」という考え方だ。
クライアントに「COBIT」という言葉を使うことはほとんどない。しかし「御社の規模・戦略・リスクの特性に応じて、優先すべきITガバナンスの領域を絞り込む」というアプローチは、まさにこの設計因子の考え方を実務に翻訳したものだ。
今回はCGEITのDomain 1で最も重要な概念の一つである設計因子を、実務での使い方とともに整理する。
1．COBIT 2019が「設計因子」を持つ理由
COBIT 2019の前身であるCOBIT 5では、すべての企業に同じフレームワークを適用することが前提だった。しかし現実には、大企業と中小企業、製造業と金融業、上場企業と非上場企業では、ITガバナンスに求められるものが全く異なる。
この反省を踏まえてCOBIT 2019が導入したのが「設計因子」という考え方だ。組織の特性に応じてガバナンスシステムを調整（テーラリング）するための判断軸として機能する。
ISACAの定義では、設計因子とは「ガバナンスシステムの設計に影響を与え、組織に適したシステムをカスタマイズするために使用される要素」だ。
2．11の設計因子とは何か
COBIT 2019では以下の11の設計因子が定義されている。
企業の特性に関する因子
企業の規模（Enterprise Size）
エンタープライズ戦略（Enterprise Strategy）
企業の目標（Enterprise Goals）
リスクプロファイル（Risk Profile）
IT関連の課題（IT-Related Issues）
外部環境に関する因子
コンプライアンス要件（Compliance Requirements）
企業の役割（Enterprise's Role in the ICT Supply Chain）
IT活用に関する因子
ITソーシングモデル（IT Sourcing Model）
IT実装方法（IT Implementation Methods）
テクノロジー採用戦略（Technology Adoption Strategy）
IT部門の規模と能力（IT Department Size and Capabilities）
これらを評価することで「自社にとって優先すべきガバナンス・管理目標」が絞り込まれ、フレームワーク全体の中から自社に適した部分を特定できる。
3．設計因子を提案書に落とし込む実践例
設計因子は概念として理解するだけでなく、実際のコンサルティング提案に活用できる。以下に実践例を示す。
ステップ①：クライアントの設計因子を評価する
例えばあるクライアントが「DX推進のためのITガバナンス強化」を求めてきたとする。まず以下を確認する。
企業規模：従業員1,000名規模の製造業
企業戦略：デジタル化による新規事業創出
リスクプロファイル：製造ラインのシステム停止リスクが高い
コンプライアンス要件：ISO 27001取得済み
ITソーシングモデル：基幹系は自社運用、周辺系はクラウド活用
ステップ②：優先すべきドメインを特定する
上記の評価から、このクライアントに優先されるCOBITの管理目標が絞り込まれる。
新規事業創出という戦略から→ベネフィット実現（Domain 3）を重視
製造ラインのリスクから→リスク最適化（Domain 4）を重視
クラウド活用の拡大から→IT資源の最適化（Domain 2）のベンダー管理を強化
ステップ③：提案書に「なぜこの優先順位か」を書く
設計因子を使うことで、「一般的なITガバナンスの強化」ではなく「御社の状況に合わせたITガバナンスの設計」として提案できる。これがCOBIT 2019の強みであり、コンサルタントとしての付加価値になる。
4．よくある誤解と注意点
誤解①：設計因子を全部評価しなければならない
11の設計因子をすべて詳細に評価する必要はない。クライアントの状況に応じて、影響が大きい因子に絞って評価する方が現実的だ。
誤解②：設計因子の評価は一度やれば終わり
企業の戦略や外部環境は変わる。M&Aや規制変更があれば設計因子の評価も見直す必要がある。ガバナンスは静的なものではなく、継続的に調整するものだ。
誤解③：フレームワークを入れれば問題が解決する
設計因子はあくまでも「何を優先すべきか」を判断するための道具だ。フレームワークを導入することが目的ではなく、ビジネス目標の達成が目的だということを忘れてはならない。
締め：フレームワークは「選ぶ」ものではなく「調整する」もの
「このIT戦略、うちの会社の状況に合っていますか？」という問いへの正しい答えはこうだ。
「合うように調整するものです。御社の規模・戦略・リスクの特性に応じて、優先すべき領域が見えてきます。」
設計因子はフレームワークを絵に描いた餅にしないための実践的な道具だ。CGEITの試験でもDomain 1の中核概念として出題されるが、それ以上に実務での提案の説得力を高めるための武器になる。
あなたの組織では、ITガバナンスの優先事項をどのように決めていますか？
次回：#008【実務活用編②】IT投資の「見える化」だけでは足りない理由。
この連載の全記録はマガジン「誰も書かなかったCGEIT挑戦記」にまとめています。参考になったらシェアやフォローで広めていただけると嬉しいです。
