このシリーズの第３回目は、ITABoK(Version2)の第２章＜ケイパビリティ・ガイドブック＞からITABoKの５つの基本知識の柱の一つである「ビジネス・テクノロジー戦略(BTS)」を取り上げます。
読者の皆様の中でITABoKにはまだあまり馴染みのない方がいらっしゃるかもしれませんので、ITABoKの特徴について先ず簡単にご紹介します。過去のセミナーでも良く質問が出た点です。
ITABoKはITアーキテクトに必要とされる「知識とスキル要件」を取り纏めた体系(BoK)である（アート（技能）とサイエンス（科学））
ITアーキテクチャ設計に必要となるプロセスや成果物、ツール等を体系化した「アーキテクチャ・フレームワーク（TOGAF, ザックマン、FEAFフレームワークなど）」とは目的とスコープが異なり、これらとの共存を前提としている
という点です。従ってITABoKが記述しているITアーキテクトの知識とスキル要件は汎用的なものとして、ITアーキテクトとして成長しレベルアップするための「ケイパビリティの指針」とする事が出来ます。ITABoKでは、アーキテクチャ・フレームワークやツールに関する知識もITアーキテクトが理解しておくべき知識要件の一つとして捉えています。
■ 「ビジネス・テクノロジー戦略(BTS)」の位置付けは？
先ずITABoKに書かれている内容を鳥瞰図的に見てみましょう。（右図参照。ITABoK入門セミナー資料より）ITABoKの構成は、基本となる５つの「知識体系」と、４つの「専門領域」の２つの部分から成り立っています。
今回取り上げる「ビジネス・テクノロジー戦略」は、ITABoKの５つの知識体系の一つで、ITABoK後半に解説されている４つの専門領域の一つ「ビジネス・アーキテクチャ」に引き継がれより深く展開されています。
■ 何故「ビジネステクノロジー戦略(BTS)が必要なのか？
少々ユニークな概念でもあるこの「ビジネス・テクノロジー戦略」は、一般的に国内で定義されている「ITアーキテクト」に必要とされるITエンジニアリング系中心の知識要件のイメージとは少々異なった印象を持たれる方も多いかと思います。では、ITABoKでは、何故これを重要な構成要素として位置付けているのでしょうか？
その一番の理由としては、Iasaが定義するITアーキテクトとしての役割定義そのものにあります。「その事業会社や組織のビジネス戦略を実現する「ビジネス・モデル」を正しく経済的に駆動する最適な「テクノロジー・モデル（構造）」を設計・導入・維持するためには、ITアーキテクトはそのビジネス構造の正しい理解と分析によって２つのモデル間の橋渡しを通じてギャップを埋める必要がある」という考え方に基づいています。（註1. ITABoK 2.2.1 P220より抜粋加筆）
本来ある新システムを導入したり既存システムを再構築する目的は、ITのためのITエンジニアリングではなく、改良されたテクノロジー・モデル（構造）を通じて意図したビジネス効果を発揮させる事にあります。しかも、単一のプロジェクトによる効果だけではなく、長期間に亘る様々な種類のプロジェクトを通じて、２つのモデル間に構造上のギャップが常に無い最適なテクノロジー・モデルを対応させるべく努力を継続する必要があります。そのためにITアーキテクトはビジネスの構造とその環境要因を深く理解しておく必要がある訳です。
では、「ビジネステクノロジー戦略(BTS)」では、具体的にどの様な知識とスキル要件を提唱しているかを見ていきましょう。
■ ビジネス・テクノロジー戦略(BTS)のケイパビリティ
ITABoKでは、知識とスキル要件をまとめて「ケイパビリティ」として呼んでいます。日本語では少々馴染みが薄い用語かもしれません。知識として持ち合わせるだけではなく実際に「活用出来る能力」という意味で使われています。
では、ITABoKでビジネス・テクノロジー戦略(BTS)のケイパビリティとして取り上げている主なテーマを見て見ましょう。(註2. ITABoK 2.1.1 P24)
ビジネスの基本
戦略の開発と適正化
業界分析
ビジネスの評価
投資の優先順位付けとプランニング
要件の探求と制約分析
コンプライアンス
アーキテクチャ方法論とフレームワーク
リスク・マネジメント
これらのテーマについて具体的にどの程度の知識やスキルを身につけておけば良いのでしょうか？ 「ビジネスの基本」と「投資の優先順位付けとプランニング」の２つの例で見てみましょう。
先ずは「ビジネスの基本」についてです。事業会社が属するある業種の主要な業務系を中心にそのプロセスや処理、情報の流れや情報の意味、用語等を一般的な業務系アプリケーション担当者と同等レベルの理解をしていれば良いかと言うとそうではありません。Iasaの定義するITアーキテクトは、独自の視点でそのビジネスがどの様な構造を持っているかを捉え、それを必要なドキュメントに落とし込み、論理的に説明出来る必要があるからです。
具体的には「ビジネスの基本」ではITアーキテクトによって次の様な活動とアウトプットが期待されています。(ITABoK 2.1.1.1 P26〜)
ある組織の実体（エンティティ）の内部環境はどの様に組織化されているか、意志決定者とそのビジネスのゴールや動機、相互の依存性を分析する
組織を形成する主なドライバーを特定する
組織の主要ドライバーに密接に取り組むステークホルダーのゴールとKPIを特定する
これらのゴールやKPIで、テクノロジーが最も影響を及ぼせるものを特定する
望まれるTo-Beのターゲット状態を定義するために、ゴールやKPIに関わるステークホルダーを引き入れる
変化を実現するようなプログラム／ポートフォリオへとビジネスの願望を変換する方法を特定・採用する
多くの場合、会社組織は複数の部門で組織が構成されています。例えば、製造業系の場合は、マーケティング、セールス、財務管理・会計、各種オペレーション/サービス、製造、製品管理、人事、IT部門等が代表的なものでしょう。ITアーキテクトは、これらの各部門のゴールやKPI、その相互作用を可視化して把握した上でテクノロジーが貢献出来る潜在的な機会や課題が何処にあるかを指摘できる必要があります。
次に、「投資の優先順位付けとプランニング」でITアーキテクトに期待される活動の例を見てみましょう。(ITABoK 2.1.1.5 P61〜)
この活動は、投資の優先順位付けとプランニングを通じて、資産とポートフォリオのライフサイクルのマネジメントに焦点を当ててプランニングと投資の管理を行うものです。 プロジェクトのポートフォリオにテクノロジー戦略がどの様に関係するかの理解と洞察が必要になります。
IT投資案件で提案された内容に関して、ITプロジェクトの根本的な課題と機会を理解するために、ITアーキテクトには次の様な情報収集とアウトプットが期待されています。
全般的に、私達はITプロジェクトにどれ程投資すべきか？
どのITプロジェクトに資金を供給すべきか？
どのプロジェクトが必須で、また完了しなければならないか？
どのプロジェクトがオプショナルか？
各プロジェクトに期待される投資対効果（ROI）はどれ程か？
ポートフォリオ全体に期待される投資対効果（ROI）はどれ程か？
どのプロジェクトが最大のリスク調整後にリターンをもたらすか ?
各プロジェクトが意図する根本的な運営上の課題は何か ?
どのようにすれば書かれているプロジェクトの利益が実現することを保証できるのか？
どのようにすれば約束されたコスト、品質、スピードに対するITの説明責任を持つ事が出来るのか ?
(以下、省略)
即座には回答出来ない類の問いかけもいくつかあるようです。 一般的には上記の質問に対するアウトプットは、アーキテクト主体で導き出すのか、または財務部と協力して算出するのか等の選択肢はあるでしょう。 重要な事は、これらの情報を全プロジェクト共通のスコアリングに照らし合わせて共通の評価を行う事で透明性と一貫性のある優先順位が特定される事です。 また、その基準となるスコアリングのための共通の評価項目には、一般的には「ビジネス価値」、「リスク」、「戦略的価値」、「義務的または法的な取組み」の４項目が含まれます。
投資案件としての複数プロジェクトの優先順位の評価は、PMO組織を中心に行なっている場合も多いと思われます。この様な場合は、ITアーキテクトはPMOと協働でこの評価を行う事で冗長なプロセスとならない様工夫する事が肝要です。
以下、筆者からの追加コメントです。
■ 「ビジネスの基本」等の実体験を通じたITアーキテクトの育成
ある企業では、若手ITアーキテクトの育成手段として実際のビジネス部門の現場を経験させています。本籍はIT部門に置いたままビジネス部門に席を移し、部門担当アーキテクトとしてIT部門とのパイプ役を担いながら重要課題の解決や各種の新規案件を通じて、実践的なビジネスの視点と経験を体得する機会を積極的に創っている企業が在ります。この活動はビジネス部門からも大変好評であると聞いています。
ビジネスとテクノロジーを「最適な構造」で繋げるためには、多角的な視点（ビュー）で切り替えながら組織の活動を観察してその構造を洞察出来る事が重要である事を示唆しています。
■ 終わりに
今回は、「ビジネス・ストラテジー戦略（BTS）」を取り上げました。このコラムに関して皆様からのご意見や感想、参考になる事例等がありましたら是非お聞かせ下さい。本コラムがITABoKの理解とこれからのITアーキテクトのあるべき姿の一助になる事を願っています。
Comments