検索結果

この新コラムのシリーズでは、来たる2019年10月30日より東京で開催する「第８回 BITAS Executive Series 2019」(BITAS: Business and IT Architecture Executive Series) で行われる主要な講演テーマで扱うトピックやキーワードについて先行してご紹介する事を目的としています。第 8 回目を迎えるこのカンファレンスは、日本での開催は 2013 年の大阪開催に続いて 2 回目となり、アジア各国からの来場者も交えたデジタル・トランスフォーメーション (DX) とアーキテクチャに関連するテーマを扱うカンファレンスとして開催します。 この BITAS 2019 カンファレンスのハイライトとして、以下のテーマを予定しています イノベーションを促進し、継続的な変革を推進するための「デジタル・エンタープライズマップ」の紹介と活用 デジタル・エンタープライズ・アジリティを促進するクリティカルスキルの重要性 現実世界のデジタル化のケーススタディ紹介とウォークスルー デジタルビジネスを推進するための、デジタル・カスタマージャーニー・マッピング（このコラムで紹介） ITをビジネスにとって戦略的に重要なものにするビジネス・アーキテクチャ ヒューマン・ダイナミクスの複雑さを管理し、理解する上でのアート（技能）と科学 成功するプロジェクト実施のためのビジネス要件アーキテクチャ デジタルの混乱から競争上の優位性をもたらす、ビジネスチャンスへの変換 日本企業への現地訪問を通してのDXの取り組みと企業文化の理解 他国の参加者とのつながり、ネットワーキングおよび現実世界のシナリオの共有 第３回目となる本コラムでは、デジタル時代のカスタマージャーニーマップとはどういうものなのか考えてみたいと思います。さらに、BITAS のメイン講演者のAaron Tan Dani 氏が紹介する「デジタル・エンタープライズマップ」との関係に触れてみたいと思います。なお、Dani 氏の略歴は本コラムシリーズの第１回「デジタル・エンタープライズマップ」を参照ください。 1. カスタマージャーニーマップとは 最初に、カスタマージャーニーマップの基本をおさらいしましょう。 カスタマージャーニーとは、直訳すると「顧客の旅」、つまり「顧客が購入に至るまでのプロセス」のことです。顧客がどのように商品のことを知り、商品が欲しいと思い、購入や登録をしたのかという一連の行動や思考を旅に例えています。商品によっては、購入後の問い合わせやメンテナンスも含まれるでしょう。こうしたカスタマージャーニーを時系列的にまとめ、可視化したものを「カスタマージャーニーマップ」といいます。 では、カスタマージャーニーマップを作成する目的とは何でしょうか。 その一つには、顧客が企業に期待することが変わってきたということがあげられます。顧客は企業から「特別な個人」として扱われ、どんな顧客接点でアプローチしても一貫性のある体験が得られることを期待するようになりました。こうした期待に対応することが、企業に求められます。また、企業組織の多くはマーケティング、営業、コンタクトセンターなど分業体制をとっています。カスタマージャーニーマップの作成を通じて、顧客の行動や感情が可視化されるので、部署が異なっていても社内で顧客理解を軸にした共通言語が生まれます。共通言語を手に入れることで、異なる部署が連携して施策を打ち立てることが出来るようになります。 カスタマージャーニーマップの作成プロセスには決まったルールはありませんが、概ね次のような流れとなることが多いと思います。 1) ゴールを決定する どういった商品・サービスを対象としますか？今回のジャーニーで取り上げる顧客の行動範囲はどこからどこまでですか？最終的に顧客に取って欲しい行動や、そのジャーニーが終わった時点での望ましい状態とはどのようなものでしょうか？ 2) ペルソナを明確にする メインターゲットとなる顧客像を明らかにします。最もその商品やサービスを使ってほしい人物のライフスタイルがわかるような情報でイメージを膨らませます。より具体的なペルソナを定義することで、次ステップの行動洗い出しの精度が高まります。 3) ペルソナの行動を洗い出しマップを作成する マップのフレームとしてよく使われるのが、顧客行動(プロセス)、顧客接点(タッチポイント)、顧客感情などです。ペルソナに関する情報をリサーチやディスカッション等を通して、フレームにまとめていきます。 4) 施策を検討する マップで洗い出した内容から、多くの問題点が見えてきます。望ましい顧客行動や顧客感情を引き出すためにどのような施策が必要でしょうか？どうすれば、顧客をより喜ばせることができるでしょう？ カスタマージャーニーマップで重要なことは、最初にゴールを明確に定めるということ、作成したマップから具体的な施策を導くということ、そしてその実行結果をもとにマップをブラッシュアップしていくようにフィードバックサイクルをまわすことでしょう。それにより、最適化されたカスタマージャーニーを提供することができ、ビジネス成果につなげ易くなります。 2. デジタル時代のカスタマージャーニーマップに求められること デジタルの時代と言われる現代では、顧客行動に大きな変化が起こっています。例えば、次のようなことがあげられるでしょう。 1) 顧客体験のデジタル化 顧客体験自体がますますデジタライズされ、相互作用の方法が変わってきています。従来のような、顧客担当や営業担当が直接に相対して顧客を獲得するというアプローチから、eメールやFacebookをはじめとする様々なソーシャルメディアプラットフォームを介したやりとりへの変化です。それによって、製品の宣伝や顧客を引き付ける方法も進化しています。 2) 顧客自体のデジタル化 IoTデバイスやRPAの浸透により、もはや顧客側の担当者もヒトであるとは限らなくなりました。機器同士が直接ネットワークで接続し、相互に情報交換をしてさまざまな取引を自動的に行う仕組みとしてM2M(Machine To Machine)というコンセプトがあります。こうしたコンセプトを現実化するエコシステムが広がるにつれて、このエコシステムとつながりを持たない企業は淘汰されていくかもしれません。 デジタル世代のカスタマージャーニーを考えるにあたっては、このような変化を理解する必要があります。大事なことは、顧客対応の取り組みをエンタープライズアーキテクチャの枠組みで捉えることでしょう。顧客対応と関連してどのようなテクノロジーが存在するのか、そのなかで組織的に取り込むべきものはどれか、これらのテクノロジーを取り込んだ結果としてビジネスプロセスをどう変えていくべきか。こうした問いに対して場当たり的に答えていくことはできません。本コラムシリーズの第１回「デジタル・エンタープライズマップ」では、アーキテクチャ上の主な構成要素の相互の繋がりや相互作用の可視化のためのツールとしての、デジタルEAマップとデジタルマップを解説しました。下図は、そこでご紹介したデジタルマップの全体像です。 この全体像には、カスタマージャーニーマップの視点（Customer journey Map Viewpoint） が配置されています。そして、カスタマージャーニーマップの視点とモチベーションの視点（Motivation Viewpoint）が直接関連付けられていることがわかると思います。モチベーションの視点にはステークホルダーの価値・要求や、組織ゴールなどが含まれ、これら構成要素が戦略の視点（Strategy Viewpoint）のインプットとなります。このことからわかるように、モチベーションの視点は、組織のデジタル戦略を考えるうえで非常に重要な役割を果たします。さらに、カスタマージャーニーマップの視点をズームアップしてみましょう。 モチベーションの視点と関連付けられている構成要素は、GoalとRequirementであることがわかります。本コラムの前半で「ゴールを明確に定めること」と「マップから具体的な施策を導くこと」が重要であると説明しましたが、その理由はここにあります。カスタマージャーニーマップのゴールと組織のモチベーションで掲げるゴールとの間には一貫性があるでしょう か（例えば、顧客の高い維持率、マーケットシェアの拡大など)。 マップから導かれた施策は、要求として確実に組み込まれているでしょうか (例えば、業務プロセスや製品コンセプト刷新、非構造データマネジメントやAIテクノロジーへの対応など)。 これら全体の構成要素（顧客、関連する内外の組織、人、情報、プロセス、アプリケーション群、インフラストラクチャ群が含まれます！）の間のギャップをなくし、有機的に連携するための指針として、デジタルマップを活用することが有効であるといえるでしょう。 3. 終わりに 本コラムでは、カスタマージャーニーマップを取り上げました。マーケティングのためのツールというだけの位置づけに留まらず、企業のテクノロジー戦略のなかでますます重要性が増しているということが、ご理解いただけたかと思います。 BITAS2019のプログラムでは、Dani氏の講演に加えパネル・ディスカッションも予定されています。是非、こちらの機会にご参加頂いて先進事例に触れて頂ければと思っております。

ITABoK　V2では、冒頭で下記のように、エンゲージメント・モデル捉え方を述べています。 ITABoKのエンゲージメント・モデルは、人材と結果に基づいており既存のあらゆるエンタープライズ・アーキテクチャのフレークワークと共に機能します。もし他のフレームワークが選択されていない場合には、プロジェクト、もしくは、エンタープライズレベルで使用できるタスク、ロール、アーティファクトの簡略化されたフレームワークも対象に含まれています。しかし、 ITABoKの目的は既存のフレームワークを置き換える事やそれらを超える事ではなく、より一貫性のある専門性重視の方法でそれらを関連付ける事です。(ITABoK p.386) 上記のように少し回りくどい表現となっていますが、「ITABoKのエンゲージメント・モデルはフレームワークではなく、ITアーキテクトの振る舞いとフレームワークを関連付け、フレームワークと共に機能するものである」と要約できるかと思います。 さて、フレームワークでは無いということは、「エンゲージメント・モデル」とは何なのか、を考えていきたいと思います。ITABoK V2では、下記が述べられます。 エンゲージメントは以下について定義します。 ⃝　組織内のアーキテクトのロール ⃝　アーキテクトのプロセスとライフサイクル ⃝　利用されるアーキテクチャのツール ⃝　アーキテクトのバリュー・プロポジション ⃝　アーキテクトチームの配置と、ステークホルダーとの相互作用 （ITABoK p.386） エンゲージメントの定義を確認することにより、ITアーキテクトのエンゲージメント活動における振る舞い方の理解が深まることが考えられます。 注記【「エンゲージ」という用語については、日本語訳しにくく、今一つ腹落ちしない言葉だと言う方もおられるかと思います。以下の記事を参照してみてください】 https://tech.nikkeibp.co.jp/atcl/nxt/column/18/00138/031100250/?P=1 では、最初にある「アーキテクトのロール（役割）」の記述を見ていきましょう。 エンゲージメント・モデルに取り組む際、それが通常どのように行われるのかを把握するのは良い事です。大半の部分で、業界の一般的なロールは企業の外で定義されます。会計士、弁護士、金融やビジネスの人々のロールは十分に記述されており、それらを支える大規模なインフラストラクチャを持っています。しかし、アーキテクチャの場合はロールを定義するのは通常、企業内のHRやIT部門です。(ITABoK p.395) ここでは、一般的に専門職の役割については、企業の外で定義されているが、アーキテクトについての定義は企業内で定義され、専門職としての認知や位置づけが、明確ではないと言っているように思います。 そこでIasaでは、これを定義することで、ITアーキテクトの役割、責務を明確にしようと主張しています。 ロールの記述に関して、Iasaから職務記述書として発表されています。ITABoK Ｖ2では、ビジネス・アーキテクトからインフォメーション、インフラストラクチャ、ソフトウエア、ソリューション・アーキテクトとエンタープライズ・アーキテクトまでの６様の職務記述書が掲載されています（ITABoK p.398-p.409） ここでは、責務や必要な教育や経験が具体的に記述されおり、ロールの定義が理解できるかと思います。 次に、プロセスとライフサイクルの定義です。 プロセスは、エンゲージメント・モデルを構築する際に考慮すべき重要な領域です。例として、アーキテクチャ活動はプロジェクトの正式な開始以前に良く発生します。プロジェクト・ポートフォリオのスケジュールの例で見たように、アーキテクトはプロジェクトの前と後の両方に関与し、全プロジェクトを通じてエンゲージメントを理解する必要があります。 (中略) アーキテクトはプロジェクトに取り組みますが、プロジェクトを超えたテクノロジー戦略に対する責任を担っているといる事を覚えておいて下さい。これが意味する事は、アーキテクトの仕事がプロジェクト終了と同時に完了はしないという点です。(ITABoK p.388) ここで述べられている「プロジェクトを超えた」と言うキーワードがアーキテクトに求められている振る舞いのポイントかと考えます。 また、ライフサイクルについてのIasaのスタンスは、標準的なライフサイクルのフレームワークと共存していくこととしています。その上で、ライフサイクルの理解やそれぞれのフレームワークへの対応について述べています。(ITABoK p.410-p.418) 次にツールに関してですが、V2では記述はなく、V3では、目次としては取り上げられ、今後記述予定であることが伺えます。https://iasaglobal.org/itabok3_0/tools-2/ ITアーキテクトのバリュー・プロポジションについての記述は、ITABoK　V2においては、以下のようなIasaの考え方を記しています。 従来のITアーキテクチャのグループは、その価値を主にコスト削減の活動として見なしており、それ以外のアーキテクチャのフォーカスはエンジニアリング上の卓越性に置かれていました。Iasa のモデルは、従来のアーキテクチャのケイパビリティから作り出される価値を維持しながら、その範囲をはるかに超えてアーキテクチャの価値の概念を拡大しています。 (中略) アーキテクトは自分の価値と進捗を継続的に再評価し、エンゲージメントのアプローチを再調整しながら変化するビジネスに位置付ける必要があります。（ITABoK　P387） 「従来の価値を維持しながら、その範囲を超えてアーキテクチャの価値の概念を拡大しています。」ということが、具体的には、V3のドラフトで「バリューモデル」のカテゴリーを設けて、10のトピックの記述が予定されています。確認してみてください。 https://iasaglobal.org/itabok3_0/value-model/ 最期の「アーキテクトチームの配置と、ステークホルダーとの相互作用」は、V2ではエンゲージメント・モデルの冒頭で以下の記述があり、プロジェクト成功のアーキテクトの配置の比率などが述べられています。 Iasaでは多くの種類の組織にインタビューを行い、成功するエンゲージメント・モデルに繋がる多くの共通する特徴を発見しました。その最初のものは、ITスタッフに対するアーキテクトの比率です。成功を報告している大半のアーキテクチャチームは、以下のパーセント比になっています。例えば、企業IT部門の場合、全ITスタッフに対して5％のアーキテクトの比率が最も成功を収めるものとして報告されています。チームの配置では、ある程度の複雑性を伴うプロジェクト単位にアーキテクト1人を配置する事が成功の鍵であると報告されています。(ITABoK p.386) (注；この比率は欧米の企業のデータであり、日本での適用については議論を要します) いづれにしても、エンゲージメント・モデルのチャプターはV3で大幅に改定されます。 4つカテゴリー（Operating Model、Value Model 、People Model 、Implementing The Engagement Model）を新たに設定して、それぞれトピックを設けて述べています。 Iasa日本支部では、V3のドラフト版の2019年3月現在の英語版で日本語翻訳に着手しており、本年11月までには、少なくとも会員向けにα版をリリースする予定です。 尚、以下の図はエンゲージメント・モデルの概念を表すものです。これを解説できるものとして、ITABoK V3のエンゲージメント・モデルの章が充実していくことになります。 特に、中心に描かれているエンゲージメント・モデルの4フェーズ (①Plan ②Build ③Run ④Manage Value) については、ITABoK V2で唯一ともいえるプロセスモデルであり、その解説の充実も期待したいところです。 ドラフト版では記載のない部分も含め、Iasa日本支部でも、我々なりに議論を重ね、先行して共通認識し、エンゲージメント・モデルのあり方の理解を深めていくことも必要かと考えます。 https://iasaglobal.org/itabok3_0/engagement-model-overview-3-0/the-enterprise-engagement-model-3-0/

今回は、インフラストラクチャ・アーキテクチャの専門領域を取り上げ、そこで求められるケイパビリティについて解説したいと思います。 先進的なITインフラサービスを比較的手軽に外部調達できる時代になりました。例えば、アマゾンAWSが提供するマネージドサービスはその最たる例でしょう。その一方で、ビジネス観点でのITシステムに対する要求レベルはますます高まっており、ITシステムを支えるインフラストラクチャ・アーキテクチャの重要性は今後一層大きくなると思われます。 ITABoKではインフラストラクチャ・アーキテクトの役割をどのように定義しているのでしょうか。一言でいえば「ハードウェアやプラットフォームに関連した資源利用を最適化するためにテクノロジー戦略を作成し、価値ある投資へ組織を導くためにビジネス、インフォメーション、ソフトウェアアーキテクトと連携して専門技能を活用する（註1）」ことが役割であるとしています。例えば、ビジネス・アーキテクチャのケイパビリティである【ガバナンス、リスク、コンプライアンス】との連携において、データセンター、ネットワーク、ストレージと、デバイスセキュリティのようなITの運用上のリスクを分析することが求められます。また、インフォメーション・アーキテクチャのケイパビリティである【情報のオペレーション】と連携してキャパシティ・プランニングを主導することが求められるでしょう。このように他のアーキテクチャ専門領域を実現するための媒介（イネーブラー）としてインフラストラクチャ・アーキテクチャを捉えることが不可欠です。 この専門領域では12のケイパビリティがあげられています。 (現時点で執筆中の段階のものも一部含まれています) 今後ますます「つながるシステム」が拡大するなかで、インフラストラクチャにはより一層の安全、安心が求められます。私の所感ですが、アーキテクトが身に着けるべきケイパビリティとしてこれらが取り上げられている背景には、「安全につながって安心して使い続けることができるインフラストラクチャ」が、あらゆる組織にとって重要になっていることがありそうに思います。皆さんは、どのように感じられたでしょうか。 本コラムでは、（私の独断となりますが）それぞれのケイパビリティを、「安全」「安心」を支えるものに分類してとりあげていきます。 まず、「安全につながる」を支えるケイパビリティです。 「アイデンティティとアクセス・マネジメント」とは、デジタル・アイデンティティを管理し、リソースにアクセスするためにどのように用いられるのかを特定することです。これらは中核的なインフラストラクチャのケイパビリティであり、組織のセキュリティ・インフラストラクチャの最重要構成要素の１つであると同時に、以下のように取り組むべき数多くの課題が存在します（註2）。 コンプライアンス上の規制と法律 財務的な健全性（例：コスト削減）とビジネス要件（例：効率性） セキュリティとリスク 「共通アプリケーション・サービス」とは、インフラストラクチャのサービスを提供するもので、サーバやビジネスアプリケーションの両方が利用する事ができます（註3）。 ディレクトリサービス リソースに固有の名称を割り当てながら数多くの利点を提供。例として、DNSや、Lightweight Directory Access Protocol（LDAP）があります。 アイデンティティとアクセス・マネジメント 例として、シングルサインオンなどの認証システムがあります。 ネットワークサービス ネットワークサービスはあらゆる他のサービスのQuality Of Serviceの土台です。 データベースサービス をあげることができます。 「デバイスマネジメント」はITインフラストラクチャの終着点に位置するデバイスに関わるケイパビリティです。ITABoKでは、IT環境と外部環境との相互作用を可能にするものをデバイスと定義し、データ、ソフトウェア、センサ、アクチュエータなどを含めます（註4）。IoT時代では、組織にとって不可欠なケイパビリティと言えそうです。 次に、「安心して使い続ける」ことに関わるケイパビリティです。 「キャパシティ・プランニング」は、現在大幅な変化を遂げている能力であると言えます。その変化の背景には、クラウドベースシステムの拡大があります。ITABoKでは、こうした変化へのガイダンスとして、ITILで定義されたサービスデザイン段階でのキャパシティ・マネジメントプロセスを取り上げています。このように、他の専門領域で開発されたアプローチを活用する事はITアーキテクトの良い実践であるとしています（註5）。 また、それと同時に「キャパシティ・プランニング」は、全てのアーキテクトにとって基盤となるケイパビリティと言えます。ITABoKは、全てのアーキテクチャレイヤーでキャパシティ・プランニングが実行されるべきとし、それぞれにおけるビューポイントを提供しています（註6）。是非、参考にしてみてください。 「ネットワークデザイン」「オペレーションシステム」は依然として中核的なテクノロジーと言えます。ITABoKでは「今日のインターネットベースに根ざした経済において時間や場所を問わない情報への瞬時のアクセスは、あらゆる規模の組織とその知的労働者の成功にとって極めて重要です。これらの要件と現代の組織におけるITの普及により、適切なアーキテクチャ無しには多数のネットワーキング装置を接続する事はもはや許容されません（註7）」と述べられています。アーキテクトは、これら中核的なテクノロジーとビジネス成功を結び付ける責任を担っていると言えるでしょう。「データセンターのデザイン」においても同じことが言えます。そこでは、サービスレベル合意書（SLA）と運用レベル合意書の設定を支援するためにベンダーと共に活動していくことが求められます（註8）。 「プロビジョニング」は、必要に応じてネットワークやコンピューターの設備などのリソースを提供できるよう予測・準備しておくことを指します。ITインフラストラクチャのプロビジョニングにはサーバ、ストレージ、ネットワークと、ロードバランサ、セキュリティキー、アクセスの手法を含む関連サービス等の導入が伴います。高度なITインフラストラクチャのプロビジョニングには慎重な構築と設計が必要になりますが、その見返りは非常に大きなものとなるでしょう。ITABoKでも「近年のアジャイルプロジェクトのデリバリー方法論とDevopsの革進は、アジャイルなインフラストラクチャのプロビジョニングのニーズを押し進める（註9）」としています。高度なITインフラストラクチャは、開発組織の成熟度を高める媒介（イネーブラー）となるのです。 ITABoKによると、ディザスター・リカバリー (DR) は、設備の障害、火災、サイバー攻撃、台風のような、内因性および外因性の極めて否定的な出来事の影響から組織を保護する事に取り組む、事業継続マネジメントフレームワークの一部となります。ディザスター・リカバリーはあらゆる組織の存続に欠かせない部分であり、ロードマップを見据えた戦略的レベルと特定のイニシアティブやプロジェクトに関連する戦術的レベルで、アーキテクトがその普及に関わっていく事が極めて重要となります。(註10) 今回は、インフラストラクチャ・アーキテクチャの専門領域のケイパビリティを解説しました。これらのケイパビリティを駆使して取り組む対象は、単なる技術上の課題に留まらずビジネス運営に大きく関わるものと言えそうです。よって、コモディティ化が進んだからと言って、これらの技術を軽視するようなことがあってはならないでしょう。 以上は既存事業の継続性という観点からでしたが、新事業 (破壊的イノベーション) 創出の観点でも同様のことが言えそうです。従来からの事業やサービスを漸進的に進化させていくには、顧客への理解・共感を起点としたアプローチが有効とされます。一方で、革新的なものを創出するには、テクノロジーと利用シーン・ニーズとの新結合というアプローチが必要となってくるでしょう。これからのインフラストラクチャ・アーキテクトは、ビジネス変革により一層積極的に関与し、貢献していくことが求められると思います。 皆さんはどうお感じになられたでしょうか。Iasa日本支部では、皆さんが考えるインフラストラクチャ・アーキテクト像について意見交換を重ね、理解を深めていきたいと思います。ご意見お聞かせくだされば幸いです。 註） ITABoK Version2 日本語訳版、「3.3 ロールの記述」P.471 同上、「2.2.3.1 アイデンティティとアクセス・マネジメント」P.356 同上、「2.2.3.3 共通アプリケーション・サービス」P.377 同上、「2.2.3.4 デバイスマネジメント」P.382 同上、「2.2.3.2 キャパシティ・プランニング」P.364 同上、「2.2.3.2 キャパシティ・プランニング」P.366 同上、「2.2.3.5 ネットワークデザイン」P.387 同上、「2.2.3.8 データセンターのデザイン」P.401 同上、「2.2.3.9 プロビジョニング」P.405 同上、「2.2.3.10 ディザスター・リカバリーとバックアップ」P.408

前回より柱シリーズから専門領域に踏み込んでいます。ただ、このインフォメーション（情報）つまりデータの分野は底なし沼とも言われており、踏み込むと足をとられることになりかねません。コラムとしては、専門性よりは、少しマネジメント面の方に焦点をあて、綴っていきたいと思います。 まず、ITABoKのP269の以下の記述に対して、言及していきます。 概要 　統合アーキテクチャは多くの熱⼼な統合アーキテクトを持つ専⾨領域ですが、全ての IT アーキテクトはデータ統合に関与する 基本的なデザインのプリンシプルを⼗分に理解する必要があります。 中略 　データ統合の要件に応じて、データは始めに様々なソースから抽出された後に、⼀般的には何らかの⽅法でフィルターされ、集結、集約、変換され、最後にはターゲットとなるユーザーやシステムに提供されなければなりません。 　アーキテクトとして、あなたはキャリアを通じて多くのデータ統合のプロジェクトに必然的に関与するでしょう。⾃社運営型システム、クラウド上のホスト型システム、サードパーティサービス、ビッグデータを含むまでに IT の⾵景が拡⼤するにつれ、データ統合は益々複雑にもなりつつあります。データ統合は、より具体的にサービスや API に取り組むシステム統合と密接に関係しています。 (ITABoK V2 日本語訳P269より) まず、ここで出てくるのが、基本的なデザインのプリンシプルと言う記述です。ラウンドテーブルでも話題となった、５ゲン主義のうちの「原理・原則」です。さらに記述は、ターゲットとなるユーザーやシステムに提供されなければなりません。 となり、このことは、普遍的であり、まさにプリンシプルと言えるでしょう。 ただ、このことを実践するのも、データ統合は益々複雑にもなりつつあります。との記述にあるように、ハードルは高くなる一方です。 解決のためにはどうすれば良いかは、古今東西で言及されてきていますが、ITABoKでは成熟度によりアプローチが異なると主張しています。 ■ 情報マネジメントケイパビリティの成熟度 　効果的な情報マネジメントは⼀度に訪れません。特定のあるアプローチを採⽤する前に、情報マネジメントのケイパビリティの現在の成熟度を評価する事が重要です。 指標（１）ー 未着手状態 公式の情報マネジメントのプロセス/プリンシプルは⼀切存在しない。情報はその場限りか、必要性に応じて対処される 指標（２）ー 初期状態 情報に対する権限が IT には存在するが、ビジネス・プロセスへの影響は限られている（または、その逆） ビジネスと IT のコラボレーションに⼀貫性はなく、それは各 LOB のビジネス内の個々のデータ通のメンバーやインフォメーション・アーキテクトに⼤きく依存している 指標（３）ー 管理された状態 職務や責務が個々の LOB で定義されている可能性がある ⼤まかに定義されたプロセスが LOB 内の主要なアプリケーションの周囲に存在する。⼀般的に、情報マネジメント上の問題 は根本原因への体系的な対処を伴わずに反応的に処理されている LOB の間で標準化のプロセスが初期段階にある 指標（４）ー 標準化された状態 ビジネスが参加して機能横断的なチームが形成され、インフォメーション・アーキテクトには明確な責務が与えられる 標準化されたプロセスと⼀貫性が LOB 全域で確⽴する 中央化され容易に利⽤できる、データ⽅針のレポジトリーが設⽴される。情報の品質が定期的に監視・測定される 指標（５）ー 進化している状態 情報マネジメントに対する組織構造が制度化され、機能全域でビジネスに不可⽋なものとして認識される 情報のコンテンツやポリシーの作成に対する全責任をビジネスが担う プロセスとメンテナンスでの定量的な品質上のゴールが設定される 指標（６）ー 最適化された状態 情報マネジメントは中核的なビジネス・プロセスであり、意思決定は定量的な便益 - 費⽤ - リスク の分析によって⾏われる 組織向けの定量的なプロセス改善上の⽬標が確⽴される。それらは変化するビジネスの⽬標を反映するべく継続的に改定され、マネジングのプロセス改善での基準として使⽤される。 　　(ITABoK V2 日本語訳P277-278より) 冒頭で効果的な情報マネジメントは⼀度に訪れません。と言い切っています。皆さんの所属する組織の成熟度は、どうでしょうか？ 成熟「インフォメーション・アーキテクトには明確な責務が与えられる」という、指標４の標準化された状態まで持っていかなければ、「具体的にサービスや API に取り組むシステム統合」を実現することが難しくなり、公的機関、民間機関ともに競争優位から脱落していくことになるのでしょう。 成熟度のなかで度々登場するLoBは知る人ぞ知る用語かと思いますので、少し説明させてください。LoBとは「Line of Business」の略で、もともとの意味は企業業務に直結するライン部門です。多角経営企業でいうところの、「事業部」にも相当します。 しかし、昨今は拡大解釈されて、「企業が業務をするうえで主要な、基幹アプリケーション」として認知されています。現在ではこちらのほうがLoBの意味としては主流となっています。 ところで、競争優位を確実にしていくにはどのような手立てがあるのでしょう？ IT はデータを作成、更新、蓄積するために⽤いられるシステムを保持するため、ビジネスのリーダー達は、初めは IT を情報の所有者として⾒なしているかもしれません。 　しかし、アプリケーションの全責任が IT からビジネスに移⾏するように、それらのアプリケーションから⽣成される情報も同じ観点から捉えられるべきです。ガバナンスを⽀援するために使⽤されるテクノロジーは、情報マネジメントのケイパビリティと⼀致します。(ITABoK V2 日本語訳P283より) データは誰のもので、ガバナンスの責任者は誰であるかは、成熟度により変遷するとも言え、ＩＴ部門から最終的にはビジネスサイドに落ち着いていくことを示しています。 また、ガバナンスが機能するのは、以下の事項によって達成するとしています。 ・価値を得るためのゴールと⼿段に合意する ・ロードマップと成熟度レベルへの理解 ・ガバナンスグループに対する⽅針、⼿順、情報 ・ガバナンスによって設⽴されたイニシアティブとプロジェクトに資⾦とリソースを供給する　 (ITABoK V2 日本語訳P283より) つまり、タスクフォースやプロジェクトを立ち上げる際に、ガバナンスを機能させるためには、基本的な手順を踏むことが、重要であるとも言えます。インフォメーション・アーキテクチャーについては、泥沼に足を取られないように、道を見極めながら着実に成熟度を上げていくことが肝要であると考えます。

このシリーズの第9回目は、ITABoK(Version2)の第２章＜ケイパビリティ・ガイドブック＞の後半で取り上げている４つの専門領域の中の「ソフトウェア・アーキテクチャの専門領域」を取り上げます。 1月より新しくラウンドテーブルに参加された方もあるので、ITABoK Version２に於ける「ソフトウェア・アーキテクチャの専門領域」の全体の中での位置付けを確認しておきたいと思います。 右図はITABoK全体の構成を鳥瞰図に表した図です。上部の４つのの専門領域の一つとして「ソフトウェア・アーキテクチャ領域」が位置付けられています。（右の図の青い点線部分） 既に他の２つの「専門領域」と図の下部の「５つの知識体系」は既にこのシリーズでご紹介した領域になります。 今回の「ソフトウェア・アーキテクチャの専門領域」ではその知識/専⾨領域の主なカテゴリーの理解と、専⾨領域間の共通性を⽐較対照する能⼒を以下の７項目について説明していますが、今回は特に太字の3つについて取り上げます。 ソフトウェア・アーキテクチャケイパビリティ 開発、⽅法論、プロセス ソフトウェア・アーキテクチャのツール アーキテクトのためのソフトウェア・エンジニアリング サービス、ワークフロー、メッセージング 高水準の品質属性 テクノロジー、プラットフォーム、フレームワーク データ/情報/知識の管理 (ITABoK V2 日本語訳 印刷版 p.351, デジタル版 p.412より) ITABoKがソフトウェア・アーキテクチャの専門領域の中で注目すべき箇所を取り上げる前に、先ずソフトウェア・アーキテクチャの検討段階ではそもそも何の目的で行うのかを確認しておきたいと思います。 私達はこのソフトウェア・アーキテクチャを検討する過程に於いて、特に特定のプロジェクト案件を視野においている場合は、非公式な形で特定のソフトウェア・ソリューションやパッケージ・ソリューション、または、その組み合わせをイメージする方も多いのではないでしょうか？ しかしながら、アーキテクチャの「プロセスと成果物」を定義する事を目的とする代表的なアーキテクチャ・フレームワークの一つである「TOGAF Verion9 (日本語訳)」では、「第11章 情報システム・アーキテクチャ – アプリケーション・アーキテクチャ」でアーキテクチャの設計の目的について以下の様に述べています。 ここでの目的は、データ（インフォメーション）・プロセスとビジネス・サポートに必要な主要なアプリケーション・システムを定義する事である。 　ここでは、アプリケーション設計の作業に触れるのが目的ではないことに注意しておくことである。ゴールは、どんな種類のアプリケーション・システムがエンタープライズに関係するのか、それらのアプリケーションがデータを管理するために、そしてエンタープライズ内の人やコンピュータ・アクターに対して情報を提供するために何をする必要があるかを定義することである。 　アプリケーションは、コンピューター・システムとして記述されるのではなく、データ（インフォメーション）・アーキテクチャのなかのデータ・オブジェクトを管理し、ビジネス・アーキテクチャの中のビジネス機能をサポートするケイパビリティの論理的なグループとして記述される。 「TOGAF Version9 日本語訳版 p.127より。括弧内()はITABoK内の用語」 上記の下線部分の記述にある様に、この段階ではアプリケーションの設計作業に触れるのが目的ではない事、またインプットとしてデータ（インフォフォメーション）・アーキテクチャとビジネス・アーキテクチャの情報を前提としている事が示唆されています。 従って、ソフトウェア・アーキテクチャの検討では、既に紹介した他のアーキテクチャ専門領域の確実な理解も必要になります。通常のプロジェクト案件ライフサイクルの視点で見ると、特定の実装やソリューションに依存しない論理構造や論理コンポーネントを分析・定義した上で、物理構造や物理コンポーネントに落とし込むプロセスは時間の制約などで冗長に見える場合が多々ある事でしょう。ただ、同時にこの様な特定のソリューション在りきの導入プロセスの積み重ねが招く結果は容易に想像がつくところです。目指すべアーキテクチャが維持されないのです。 さて、ソフトウェア・アーキテクチャ　ケイパビリティで着目する１つ目は、「ソフトウェア・アーキテクチャ開発の方法論とプロセス」についてです。 概要 手法の主な焦点（アーティファクト、ユースケース、属性、ドメイン）に関係なく、アーキテクチャのデザイン・プロセスには以下の観点が含まれます。 1. アーキテクチャ要件の分析、関⼼事の特定、及び、プロセスを通した意思決定への背景の提供 2. システムとその進化の望ましい特性と補助的原則の⽂書化、及びシステムのステークホルダーへの、それらの伝達の促進 3. 一貫した⽅法での、アーキテクチャの代替案の評価と比較 4. 実際のシステムの導⼊がアーキテクチャ記述に準じているかどうかの確認 　 (ITABoK V2 日本語訳 印刷版P352, デジタル版 p.413より) ここで、アーキテクチャ要件の分析については以下の様に説明しています。 アーキテクチャ要件の分析とは、システムのゴールと期待される品質属性を特定するプロセスです。その要件はビジネスやミッションのゴールと直結し、システムのステークホルダーと明確に関与していなければなりません。分析で最も重要なステップの１つは、デザインへの関連（最終的に実現されるシステムが現在の運⽤環境に適合する場所）を明確にする事です。 (ITABoK V2 日本語訳 印刷版 p.353, デジタル版 p.414より) アーキテクチャ要件の分析には、期待される品質属性の特定や現在の運用環境への適合評価を明確にする活動が含まれている事に注目します。 更に、アーキテクチャの代替案の分析については、いくつかの評価手法によって潜在的なリスクを特定する事だと説明しており、評価の手法としてソフトウェア・メトリクス、シナリオ、属性モデルベースの３種類を簡単に紹介しています。 アーキテクチャのコンプライアンスの評価の説明には以下の記述があり、読者の中には過去に思い当たる点がある方もいらっしゃるのではないでしょうか。　これらの逸脱は特に何らかのガイドラインが存在しない場合には、放置され蓄積され続けるでしょう。 システムの導⼊と進化の期間中、たとえ最初のリリースの場合でも、定義されたアーキテクチャからの逸脱を観察するのは⼀般的な事であり、それらの逸脱は開発者の認識の欠如、矛盾する要件、遅い段階での要件の変更、技術的困難や締め切りや予算上のプレッシャーに起因しています。このような逸脱は⼤抵の場合時間と共に蓄積され、アーキテクチャの浸⾷として知られる現象を招きます。 (ITABoK V2 日本語訳 印刷版 p.354, デジタル版 p.416より) 更にアーキテクチャのコンプライアンスについては、「ソースコードで実装されたアーキテクチャが定義されたアーキテクチャに準じる程度を測るための評価基準です。」と説明しています。実践に於いては、アーキテクチャのコンプライアンス準拠のレベルを個別のプロジェクト案件で実装された各ソリューションに対して評価を行い、特定されたギャップは記録した上で必要な対処を検討する事になります。 ２番目に着目した点は、「アーキテクトのためのソフトウェア・エンジニアリング」についてです。 概要 あらゆるエンジニアリングの活動と同様に、ソフトウェア・エンジニアリングは「問題の定義付け」で開始され、「問題へのソリューション」を獲得するためにツールを適⽤します。しかし他のエンジニアリングとは異なり、ソフトウェア・エンジニアリング(SWE)はソリューションを獲得するための⽅法論や⼿法に重点を置いているように思われます。 (ITABoK V2 日本語訳 印刷版 p.357, デジタル版 p.418より) ここでは「ソフトウェア・アーキテクチャ」と「ソフトウェア・エンジニアリング」の主たる違いについては以下の様に説明しています。 Iasa の定義では、アーキテクチャとはテクノロジー戦略の応⽤を通じた、ビジネス、組織、クライアントの利益の獲得の実践であり、目指すのはビジネスに対する価値の実現です。他方、ソフトウェア・エンジニアリング（SWE）は特定の目的のソリューションを獲得するための⽅法論や⼿法に重点を置いている、と説明しています。実際の検討段階では双方の異なる視点から同じ対象や問題点についての分析や評価もある事でしょう。しなしながら、その本来の目的と重点が異なると解説しています。 3番目に着目した点は、「高水準の品質属性」についてです。 説明 品質属性 (QA) は⾮機能的な要件ですが、機能的要件なしにはそれを説明する事は出来ません。要件は同⼀であるにもかかわらず、品質属性に対する異なるフォーカスによってソフトウェア・アーキテクチャ内の差異が⽣じるため、これらの「⾮機能的」要件を「特別な機能」要件と呼ぶ事には⼤きな意味があります。 概要 要件は、アーキテクチャ的に優れたソフトウェアを作成するのに⼗分なものではありません。異なるアーキテクト達は、同⼀の要件に対して異なるアーキテクチャを作成するでしょう。 （中略） 　アーキテクトにはステークホルダーからの情報を獲得する必要があります。ステークホルダーは、⼤抵要件の観点から物事を考慮しますが、アーキテクトは現在の実装と将来の拡張の観点から思考しなければなりません。ステークホルダーの主たる関⼼事はコストですが、アーキテクトの主な関⼼事は不可⽋なQA（注：品質属性）を特定して、それらをステークホルダーが満⾜するように導⼊する事です。 (ITABoK V2 日本語訳 印刷版 p.379, デジタル版 p.443より) これらを実践するにあたっては、ITABoKではステークホルダーをまじえた品質属性ワークショップ（QAW）、品質属性シナリオ、品質属性のテスト、パフォーマンス、セキュリティ、品質属性の評価、品質属性の経済分析などを通じ、高水準の品質属性を確保する事が可能となると説明しています。高水準の非機能要件を長期に亘りアーキテクチャで担保するには、それなりの工夫、努力と活動の継続が必要であり、その上に実装されるソリューション群の安定性と必要となる多様なパフォーマンスを発揮できるアーキテクチャ基盤の維持に貢献する事に繋がります。 (ITABoK V2 日本語訳 印刷版 p.379〜p.382, デジタル版 p.444〜p.447より) ■ 終わりに 今回は、「ソフトウェア・アーキテクチャの専門領域」の中の３つのケイパビリティについて取り上げました。ソフトウェア・エンジニアリングと被るトピックも多い領域ですが、アーキテクトはエンジニアリングの知識や知見も活用しながら最適なソリューションを導き出し、該当システムの長いライフサイクルに亘って目指すべきアーキテクチャ（ケイパビリティの実現）を維持する責務を負っている点が他の各専門的エンジニアと異なる役割と言えます。 このコラムに関して皆様からのご意見や感想、参考になる事例等がありましたら是非お聞かせ下さい。本コラムがITABoKの理解とこれからのITアーキテクトのあるべき姿の一助になる事を願っています。 参考： アーキテクチャの策定プロセスや成果物（アーティファクト）の業界標準の一つとして、IasaではTOGAFを引用・参照している経緯があります。 TOGAF (OpenGroup)について http://www.opengroup.or.jp/togaf.html ArchiMate (OpenGroup)について https://en.wikipedia.org/wiki/ArchiMate http://www.opengroup.or.jp/archimate.html

前回まで、アーキテクチャの5つの柱を解説しました。今回からはアーキテクチャの専門領域に踏み込みます。ITABoKには次の4つの専門領域が定義されています。 ビジネス・アーキテクチャの専門領域 インフォメーション・アーキテクチャの専門領域 インフラストラクチャ・アーキテクチャの専門領域 ソフトウェア・アーキテクチャの専門領域 これらの専門領域で求められるスキルの多くは、5つの柱をさらに深化または拡大したものとなります。今回は、ビジネス・アーキテクチャの専門領域を取り上げ、そこで求められるケイパビリティについて解説したいと思います。 ビジネス・アーキテクトの役割とは何でしょうか。ITABoKには以下の記載があります。 「ビジネス・アーキテクトは、特定のビジネス・ゴールを達成するためのビジネス戦略の作成に参加する事で、テクノロジー戦略を通じてビジネス・イニシアティブにおいてリーダーシップを発揮します。ビジネス・アーキテクトは、事業部内でのイノベーションと機会の特定を可能にします」（註1）。 また、その活動に関しては「ビジネス・アーキテクトは困難なビジネス関連プロジェクトの領域内で、ソリューション・アーキテクトとしての役割を果たす場合もあれば、現在の企業内での一般的なロールで活動する一員として活動する場合もあります。しかし、ビジネス・アーキテクトの主たる責務はビジネスシステムそのものにあり、それはデリバリー関連の職務機能ではありません」としています（註2）。 ここから伺えることは、ビジネス・アーキテクトの役割はビジネス活動そのものを変革することに焦点があてられているということです。そのためのビジネス・ゴールやビジネス戦略の策定に深く関与し、その策定においてはステークホルダーや他の専門領域のアーキテクトと協調しながら、変革活動を主導することが期待されていると言えそうです。 次に、ビジネス・アーキテクチャについて見ていきましょう。ITABoKが述べているのは、ビジネス・アーキテクトというロールのスキル要件とその役割です。 ですので、ここではBusiness Architecture Guildが公開するBIZBOK®ガイド(A Guide to the Business Architecture Body of Knowledge®)からビジネス・アーキテクチャの定義を引用します。 BIZBOK®ガイドでは「ビジネス・アーキテクチャとは、ケイパビリティ、エンド・ツー・エンドでの価値提供の流れ、情報、および組織構造に関する包括的で多次元的なビジネス・ビューおよび、これらのビジネス・ビューと戦略、製品、ポリシー、イニシアチブ、ステークホルダーとの関係をあらわしたもの（註3）」と定義しています。下図をご覧ください。 この図は、ビジネス・アーキテクチャを構成する個々のドメイン（個別の領域知識）をあらわしています。企業はビジネス・ゴールを達成するために、これらのドメインに着目して変革のための活動を推進していくことが求められます。「ビジネス・アーキテクチャは、戦略を実行可能なイニシアチブに変換するための効果的なコミュニケーションおよび分析フレームワークとしての価値を提供する」と述べられています（註4）。 さて、ここでITABoKに戻ってケイパビリティを見ていきたいと思います。 最初にあげられるケイパビリティは「ビジネス・マネジメント」です。ITABoKによると、アーキテクトがよく直面する主な課題の１つは「テクノロジー」と「ビジネス」の不一致であり、従って、アーキテクトは組織の概要、特にそのビジョン、ミッション、ゴール、目的に関する深い理解をする必要があるとしています。加えて、ビジネスプロセス・マネジメント（BPM）に対する幅広い知識が極めて必要であることを強調しています。注意しなければいけないのは、ここでいうBPMとは戦略を実現するためのあるべきビジネスプロセスの姿が対象となり、日本で一般的にイメージされる現場レベルの詳細な業務フローが中心課題ではありません。ビジネス・アーキテクトは、組織の目的を高め達成するために、いかに組織のプロセスを変更できるかにフォーカスすることが求められます（註5）。 続くケイパビリティは「ビジネス戦略」です。戦略とは、不確定な状況の下で１つまたは複数のゴールを達成するための高いレベルの計画を指します。ビジネス戦略は、戦略的マネジメントフレームワークや、戦略マップ等の形で表現される場合があります。ここでビジネス・アーキテクトが担う最も重要な役割は、組織への投資の価値を実現するためにビジネス戦略で規定された、テクノロジー投資からビジネスの成果までのトレーサビリティのマトリクスを作成することであると述べられています（註6）。 世界的なプロジェクトマネジメント組織であるPMI（Project Management Institute）によると、組織におけるすべての変革はプロジェクトやプログラムを通じて実現されます。Iasaもこうした考え方を支持しているようです。「ポートフォリオとプログラム・マネジメント」を3つ目のケイパビリティに含めている点は、非常に好感が持てます。 ビジネス・アーキテクトは、ビジネスが直接引き起こす潜在的な変化が、財務パフォーマンス指標とどのように関連するかを理解することが求められます。また同時に、ビジネスの変化全般を評価して、それを支援するために必要なIT投資を特定することができる独自の立場にいます（註7）。こうした理由から、ビジネス・アーキテクチャにおいては「財務的手法」「テクノロジー投資」に関わるケイパビリティが必要となります。 ビジネス・アーキテクトは「テクノロジーの戦略とイノベーション」に関する動向へのチャネルや技術的知見を有していることが期待されます。本来、アーキテクトが得意とするIT技術の目利き力を発揮できる領域ですね。これらに関連する特定のスキルや知識の活用し、ビジネスや組織のゴールと目標を達成することで、ITやビジネスの価値に貢献することができます（註8）。 言うまでもなくビジネス・アーキテクチャは、関係する全てのステークホルダーに理解されなければなりません。そこで求められるケイパビリティが「ビジネスのビューとモデル」です。モデリングすべきビューを決定する際に、ビジネス・アーキテクトの知性と経験が活かされます。例えばITABoKでは、主に以下のビューをあげています（註9）。 戦略 価値 サービス ケイパビリティ プロセス 財務 BIZBOK®ガイドのモデルとは異なるビューもあります。このようにフレームワーク間で必ずしも整合性が取られているわけではありませんが、重要な点はビジネス・アーキテクトがそのイニシアチブにとって、どんなビューが必要か決定できることにあると思います。 最後に、ビジネス・アーキテクトは「ガバナンス、リスク、コンプライアンス」のケイパビリティを発揮しながら「組織の変化を先導」していくことが求められます。 先述したように、アーキテクトが解決しなければならない主な課題の１つが「テクノロジー」と「ビジネス」の不一致です。ビジネス・アーキテクトはその不一致を解消する任務を担っています。彼らは変化にとって重要なエージェントであり、現在のアーキテクチャ、移行中のアーキテクチャ、及び、「目標とされる」アーキテクチャを創出するべく（内部および外部の）全ステークホルダーと緊密に活動しながら、組織変化の成功に不可欠な存在であらねばならないのです（註10）。 今回は、ビジネス・アーキテクチャの専門領域のケイパビリティを解説しました。ビジネス・アーキテクトという名称は、国内ではまだ馴染みのないものかもしれません。一方で、その活動内容を考えた時、皆さんの組織においてもビジネス・アーキテクトに相当する人材がおられるかもしれません。そうした人材は、何という名称で呼ばれ、どのようなケイパビリティを発揮されているのでしょうか。ビジネス・アーキテクトの活動において、今回解説したケイパビリティがどう位置付けられるか、私の理解を図にしてみました。 皆さんはどうお感じになられたでしょうか。Iasa日本支部では、皆さんが考えるビジネス・アーキテクト像について意見交換を重ね、理解を深めていきたいと思います。ご意見お聞かせくだされば幸いです。 註） ITABoK Version2 日本語訳版、「3.3 ロールの記述」P.398 ITABoK Version2 日本語訳版、「3.3 ロールの記述」P.398 BIZBOK®ガイド Version7 、「What is Business Architecture?」P.2 BIZBOK®ガイド Version7 、「What is Business Architecture?」P.3 ITABoK Version2 日本語訳版、「2.2.1.1 ビジネス・マネジメント」P.220 ITABoK Version2 日本語訳版、「2.2.1.2 ビジネス戦略」P.225 ITABoK Version2 日本語訳版、「2.2.1.4 財務的手法」P.236 ITABoK Version2 日本語訳版、 「2.2.1.6テクノロジーの戦略とイノベーション」P.245 ITABoK Version2 日本語訳版、「2.2.1.8 ビジネスのビューとモデル」P.260 ITABoK Version2 日本語訳版、「2.2.1.9 組織の変化を先導する」P.263

第４回は ITABoKにおけるアーキテクチャーの5つの柱「ビジネス・テクノロジー戦略」、「IT環境」、「デザイン・スキル」、「ヒューマン・ダイナミックス」、「品質属性」のうちの「IT環境」に関するコラムです。 「IT環境の柱」のカテゴリーは、以下の文章から始まります。 IT環境は、ソリューションが稼働するように設計されなくてはならない領域を解説し、提供する対象物へ多くの制約事項を設定します。これらのスキルは重要度の点で一般的に低く見られ、最も評価の低いものはITオペレーションとガバナンスでした。 　これは、芳しくないプロジェクト成功率の「as is」（現在の状態）の状況を示しています。IT環境に対する知識がなければ、ソリューションのコストは組織に提供できるビジネス価値を打ち消してしまいます。（ITABoK P158） ここでは、IT環境のスキルの評価は一般的には低く見られているとされています。しかし、その良否によって、情報システムのビジネス価値への影響に大きく左右されることをメッセージしています。 ＩＴ環境に対するケイパビリティには、以下に示すように多岐に亘ります。 「技術的プロジェクト・マネジメント」 「資産管理」 「変更管理」 「インフラストラクチャ」 「アプリケーション開発」 「ITガバナンス」 「テストの手法、ツール、テクニック」 「ナレッジ・マネジメント」 「意思決定支援」 「プラットフォームとフレームワーク」 「IT環境」のカテゴリーのIasaにおける定義の広さに驚かされた方も少なくないかと思います。また、これらの遂行能力を身に着ける時間と努力は計り知れないと感じられた方もおられるかと思います。 ITABoKでは解決策のひとつとして、「インフラストラクチャ」の説明で以下のことが述べられています。 アーキテクトに対する主な抵抗力や課題 　アーキテクトはITインフラストラクチャの全ての局面に取り組む機会を得た経験がない可能性があり、組織内のエンジニアリングやオペレーションのステークホルダーとの信頼できるアドバイザー／メンター関係を築く必要がある場合もあります。 　これは、アプリケーション開発のスキルセットからインフラストラクチャ・デザインへと移行中のアーキテクトに特に当てはまります。 　最後にITインフラストラクチャの展望は自社運用型、他社運用型、ハイブリッドのクラウドソリューションの導入と共に変化しており、これらはネットワーキング（レイテンシー）、データセキュリティ、アクセスと認証に対する更なる品質上の関心事をもたらすでしょう。（ITABoK P171） このアドバイザー／メンター関係を築くことは、どのような局面でも有効となり、またアーキテクト活動を効率的にするものです。メンターに関しては「アプリケーション開発」の説明でも述べられています。 大規模組織には、大体の場合アプリケーション開発に対する最終的な責任を担う開発マネジャーが存在します。この場合、アーキテクトはアプローチの定義付けと、それがプロジェクトでどのように機能するかに関する専門的な見解を提供します。 　小規模組織では、アーキテクトはアプリケーション開発に対するより多くの責任を担うかもしれません。 　アーキテクトはプロジェクトプランニングと各種のミーティングの構成においてインプットを求められ、プロジェクトマネジャーによって作成されたプランのレビューを求められるでしょう。 また、アーキテクトはプロジェクトを担当するアーキテクトのドキュメントに1つの見解として開発環境を文書化し、開発チームをコーチし、彼らのメンターとなるでしょう。（ITABoK P175） ここでは、アーキテクト自身が、開発マネジャーを支援し、開発チームをコーチするメンターとなることを述べています。 しかしそのためには、アーキテクトに対するアドバイザー／メンターの存在が大きく左右します。アーキテクトはアドバイザーやメンターの良否により成長の度合いは変わります。良きアドバイザー、メンターとの出会いを大切にしたいものです。 その出会いを大切にしたうえで、それぞれのスキルの成長により、開発チームをコーチし、彼らのメンターになることで、アーキテクトとしての地位を揺るぎないものとすることが出来ると考えます。 アドバイザーやメンターが身近に存在するとは限りません。コミュニティへの参加や外部の人とのネットワークの重要性を再認識される事かと思います。アーキテクチャーラウンドテーブルのコミュニティ活動が、このネットワークつくりに役立つことを願っております。 最期に、「スキルについての問い」でコラムの締めにしたいと思います。 問い　「スキルとノウハウの違い」は何でしょうか？ 色々と定義や比喩はあるかと思いますが、ひとつの考えを以下に記載します。 皆さんの考えやご意見も、いただきたいと思います。よろしくお願いします。 スキル（技術力）とは、人に備わった技量のことで、何かを実際にやり遂げる力のこと ノウハウ（知識・方法）とは、伝聞や経験から、何かが出来る知識や方法のこと。 プロ野球の野手に例えれば、野球のバッターがヒットやホームラン実際に打てることがスキル、ヒットやホームランはどのようにして打てば良いかを知っており教えることが出来るのがノウハウ、と例えることが出来ます。 ノウハウとスキルが揃って、それぞれが一定レベルの人が現役で稼ぐことが出来、引退後も、監督やコーチとして球界で長く活躍できるのです。スキルはあっても、ノウハウがない場合は、現役引退後は球界から離れていくことになるのでしょう。 ITに関しては、ノウハウはWebサイトや巷の本屋にもあふれている状況です。これからはスキルを身に着けることが、これからはますます重要になるかと思います。問題はどんなスキルをどのように身に着けるかですが、Iasa日本支部としては、アーキテクトに求められるスキルを身に着けることに支援し、バックアップしていきたいと思います。コミュニティへの積極的な参加をお願いいたします。

品質の重要性は、システムやソフトウェアの開発では大変古くから議論されてきました。DX（デジタルトランスフォーメーション）の時代と言われる近年、ますますその重要性は高くなる一方といえます。IPAが発行する「つながる世界のソフトウェア品質ガイド」では、その背景として３つの要因をあげています。 １．多様化する利用者の期待(註1) 機能を正しく動かすことが主要な品質という従来の考え方から、安全性やセキュリティはもとより、快適さや楽しさ、高度なビジネス貢献というように多様化しています。 ２．多岐にわたるステークホルダー(註2) 製品そのものが複雑化かつ高機能化したことで、その製品に関わる多様な利用者の存在など、考慮すべきステークホルダーは確実に増えています。 ３．つながるシステムの拡大(註3) 「つながるシステム」として利用者に価値を提供するような形態が増えていることで、関連する全ての要素が確実に品質要求を満たしている必要があります。 また同時に、システムの複雑さも高まる一方といえます。このように複雑化するシステムの品質を考えたとき、全ライフサイクルに適用される多様な品質要求をシステム要件としてとりまとめ、その効果と経済性のバランスをとりつつ具現化していくことには、極めて高い専門性が求められます。ここに、品質属性への高い専門性を備えたITアーキテクトが必要となる理由があります。 さて、「品質属性の柱」を見ていきましょう。ITABoK全体に目を通してまず気づくのは、「アーキテクチャの5つの柱」とそれに続く「アーキテクチャの専門領域」のほぼ全ての広範な範囲に「品質属性」という言葉が登場していることです。「品質属性の柱」はITアーキテクトの活動全般において必要となる横断的なスキルといえそうです。 ITABoKであげられている「品質属性の柱」を構成するケイパビリティは次の7つです。 品質属性の調整と最適化 マネージャビリティ、メンテナンス性、サポート性、拡張性、柔軟性 モニタリングとマネジメント パフォーマンス、信頼性、可用性、拡張性 セキュリティ ユーザビリティ、ローカリゼーション、アクセシビリティ、パーソナライズ/カスタマイズ性 パッケージング、提供、ポスト・デプロイメント 特にセキュリティに関して多くのページを割いている点は興味深いです。ITABoKによると、セキュリティは「普遍的な」品質特性の１つであり、たとえ小規模でシンプルなものでも全てのシステムに存在しています（註4）。冒頭で述べた「つながる」システムへの潮流から、今後ますます重要性が高まる品質属性といえるでしょう。 また、利用されないシステムは、ビジネスにとってはもとよりシステム運用にとっても大きな負債となります。よって、パフォーマンスやユーザビリティのようなシステムの利用者にとっての品質も重要な品質属性であり続けるでしょう。 パッケージング、提供、ポスト・デプロイメントは、近年のDevOpsの潮流によって大きくクローズアップされた領域といえます。ビジネスの俊敏性を高めていくために、欠かせない品質となってきたという認識が必要です。 経験あるITアーキテクトなら十分理解されていると思いますが、場合によっては品質属性の定義は非常に困難を極めるものとなります。しかしながら、品質属性を定義することはITアーキテクトにとって重要な責務であることを、強調しておきたいと思います。 続いて、上位３つのケイパビリティを掘り下げてみます。 最初にあげられるケイパビリティは「品質属性の調整と最適化」です。ITABoKでは、『ITプロジェクトから最適なパフォーマンス、ユーザー・エクスペリエンス、投資対効果を提供するために必要となる、基本的な戦略と戦術の適用』と説明されています（註5）。ITアーキテクトが品質を定義するとき、制約のない理想的な状況が与えられることはまずありません。そこには必ず、組織面や財務面での制約や前提があります。また、品質属性間のトレードオフも意識すべきです。よって、このケイパビリティなくしてITアーキテクトの定義する品質属性がステークホルダーの承認を得られることはないでしょう。 ITABoKによると、『この課題を成功裏に進めるための鍵の１つは、いかに良くITアーキテクトがサービスレベル要件を把握したかに依存する』とされています（註6）。多様なステークホルダーから、いかにして真の要求を引き出すか。「ヒューマン・ダイナミクスの柱」のスキルとあわせて活用することがITアーキテクトに求められると考えられます。 次にあげられるケイパビリティが「管理容易性、メンテナンス性、サポート性、拡張性、柔軟性」です。この品質属性は、運用のためにデザインされたソリューションがシステムに組み込まれることを保証します。ITABoKによると、ソリューションのコストの20％がデザインとデリバリーの期間に生じ、残りの80％がソリューションの生涯を通してのメンテナンスに費やされます（註7）。「運用期間にわたって費用対効果の高いシステム」であることは、ビジネスの視点から不可欠といえます。ITアーキテクトが説明責任を果たす際に、経営者やユーザーに理解できる言葉で、開発の初期コストだけでなく長期的なランニングコストの妥当性を語れることは、強固な信頼関係を築く上で必要なことといえます。 テクノロジーの視点で見ても、この領域はクラウド技術を中心に新しいソリューションが日進月歩で進化しており、企業にとって選択肢は広がってきています。しかし、こうしたソリューションを実際に導入することに、ハードルの高さを感じる組織は多いのではないでしょうか。その理由として、システム運用、ビジネス／業務や開発の一体となった理解と協力が必要にも関わらず、これらの橋渡しの役割を果たす人材があまりにも少ないように思います。その点を考えると、本ケイパビリティを備えたITアーキテクトが活躍できる機会は、今後ますます広がっていくと考えられます。 「モニタリングとマネジメント」について考えてみましょう。ITアーキテクトは品質属性を定義することと同様に、品質属性をモニタリングし、マネジメントすることの重要性を認識する必要があります。ITABoKでは、『品質属性に関しては、私達は特定の品質属性を自らのソリューションに組み込む事に神経を使っていますが、それらがどの様にモニターされるかには強い関心を抱いていない様に見えます。一般的に、私達はソリューションがどの様に管理、維持され、終了を迎えるかにはあまり関心を向けません。』と書かれています（註8）。マネジメントされない品質属性は、評価することも改善することもできません。品質属性が最終的にビジネス要求を満たせているかどうかを追跡できるメカニズムを導入し、監視、評価、そして改善していくサイクルをまわすための仕組みを作っておくことは、ITアーキテクトの責務であるといえるのではないでしょうか。 今回は「品質属性の柱」を取り上げました。皆さんも日々の実践において、品質の重要性と難しさを感じておられるのではないでしょうか。最後に、皆さんへの質問で本コラムを締めたいと思います。 獲得／表現／合意されない要求は実現されることはありません。皆さんの開発組織では、品質要求は表現できていますか？「誰から」「どのタイミングで」「どういう品質要求」を獲得すれば、必要十分なシステム要件として取りまとめることができるとお考えでしょうか？さらにこうした品質要求の適切な表現方法とはどういったものでしょうか？ 皆さんの意見やコメントをお聞かせください。 註） つながる世界のソフトウェア品質ガイド、「1.1 多様化する利用者の期待」P.8 つながる世界のソフトウェア品質ガイド、「1.2 多岐にわたるステークホルダー」P.9 つながる世界のソフトウェア品質ガイド、「1.3 つながるシステムの拡大」P.11 ITABoK Version2 日本語訳版、「2.1.5.4 セキュリティ」P.208 ITABoK Version2 日本語訳版、「2.1.5 品質属性の柱」P.199 ITABoK Version2 日本語訳版、「2.1.5.1 品質属性の調整と最適化」P.200 ITABoK Version2 日本語訳版、「2.1.5 品質属性の柱」P.199 ITABoK Version2 日本語訳版、「2.1.5 品質属性の柱」P.199

このシリーズの第３回目は、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アーキテクトのあるべき姿の一助になる事を願っています。

本シリーズの第６回目は、ITABoK(Version2)の第２章＜ケイパビリティ・ガイドブック＞から5つ目の基本知識の柱として「デザインスキルの柱」を取り上げます。 先ずITABoK自体の”構造”から「デザインスキルの柱」の位置付けを確認しておきます。 下図はITABoK全体の構成を鳥瞰図に表した図です。デザインスキルは、全てのアーキテクトに共通の5つの基本知識の柱の一つとして位置付けられています。（青い点線部分） 下図はITABoKの特徴の一つになりますが、今回紹介するデザインスキルは、これまでこのコラムで紹介した他の4つの基本知識とスキル同様にITアーキテクトに求められるケイパビリティを高めるために大変重要な知識領域であるとしています。この「デザイン」と言う言葉は「アーキテクチャを設計する」事を意味します。 「デザインスキルの柱」では、ITアーキテクトとして成功するために必要となるデザイン理論、デザイン関連の戦略やテクニックに関する項目を取り上げて解説しています。 デザインスキルに関する具体的なケイパビリティとしては、以下の９つについて紹介されています。(ITABoK V2 日本語訳P121より) アーキテクチャ記述 要件モデリング 分解と再利用 デザインの手法とプロセス デザインの分析とテスト デザインのパターンとプロセス ライフサイクルにおけるトレーサビリティ ビューとビューポイント 全体システムのデザイン ITABoKの定義するITアーキテクトは、上記の項目リストの最後に紹介されている「全体システムのデザイン」が本来の役割とその目的を最も端的に表しており、以下の様に紹介しています。 「アーキテクトとして全体システムのデザインアプローチを採用する事は、人間、インフラストラクチャ、開発環境、組織構造を含む、IT環境全体を理解しなければならない事を意味します。デザインに全体システムのアプローチを取らない場合の結果には、低いデザイン効率（システムの部分的な最適化はシステム全体を最適化しない）、コストの増加、ソリューションの有効性の低下、品質属性サポートの低下が含まれます。」（ITABoK P152より） この本来の目的をITアーキテクトが果たすためには、設計に関する理論や個々のテクニックに関する知識とスキルが必要になるわけです。最初の項目リストにある「アーキテクチャ記述」では以下のように述べています。 アーキテクチャ記述は、テクノロジー・ソリューションが展開される背景（例：ビジネス・アーキテクチャ、ビジネスドライバー、ステークホルダーの関心事）、制約事項とリスク、システムのビジョンと目的、そのゴール、及び、関連する利用シナリオの探求と理解で始まる、アーキテクチャ開発プロセスの最終的な成果物です。アーキテクチャの全般的な「デザインのストーリー」を提供する事に加え、アーキテクチャ記述はモデルだけではなく、モデルに文脈と背景を提供する文書によるアーティファクトやその他のアーティファクトも含んでいます。 (ITABoK P123より) アーキテクトはアーキテクチャ設計の諸々の成果物の作成過程を通じてそもそものビジネスの背景を含む複数のインプットがしっかり反映されている事を確認する必要があります。この過程で上述の情報からモデルに変換し完成度を上げながらアーティファクトを作成する作業は知識とテクニックを要する作業になります。 「要件モデリング」に関しては、ITアーキテクトは様々なビジネス要件や制約を分析した後にドメインモデルやユースケースモデルの作成やレビューを通じてそれぞれの専門領域の立場で関与する事になります。要件モデリングについては次の様に紹介しています。 要件モデリングは、ある領域向けの要件と制約事項が把握され分析された時点で実行されます。これは要件の一貫性と完全性を保証するための重要な活動です。機能、品質属性と制約事項をモデリングするために様々な方法が存在します。取るべき適切なアプローチはシステムや組織のスタンダードに依存し、一部のケースでは使用されるドメイン特有のモデリング言語となります。ここでの重要な観点として１つのタイプのモデルを他のものへと変換する方法があります。トレーサビリティもこの重要な観点になります。(ITABoK P126より) 「デザイン手法とプロセス」では、“良いデザインとは？”についての説明があります。この問いに対する回答は立場や置かれている環境によって異なり決して唯一の見解がある訳ではありませんが、ここではITABoKとしての見解をご紹介します。 良いデザインとは正当化、理由、そしてトレードオフの検討そのものです。デザインはモデルやダイアグラムとしばしば混同されていますが、実際にはダイアグラムはデザイン・プロセスの成果物です。多くのソリューションがビジネス・ニーズを満たす可能性があるため、複数の選択肢から１つのデザインを選択する際の背後にある論理的根拠は、アーキテクチャの本当の価値が存在する所となります。（ITABoK P131より） 様々な要件、制約、現状などの多様な情報を元に時にはツールやテクニックを使い成果物（アーティファクト）を作成するわけですが、トレードオフの検討の結果とその論理的な根拠、その妥当性に関してのステークホルダーの納得性の高さが良いデザインの判断の目安になるとしています。（もちろん、成果物自体が満たすべき基本的な正確性、網羅性、一貫性等はきちんと満足された品質であるという前提ですが） 「デザインの分析とテスト」では、代替案を検討比較するための分析テクニックやツールを説明しています。更に成果物（アーティファクト）に対してどの様に比較検討とテストを行うのか、またその完成度や正確さ等については修正すべき箇所を特定した上で修復を行うと説明しています。(ITABoK P134より) 「デザインパターンとスタイル」では、建築業界における先駆者が語った「成功を収めるアーキテクチャは再利用可能である」の例を引用してその特徴を説明しています。デザインパターンの重要性についは次の様に続きます。 パターンは特定の背景、問題、ソリューション間の関係を表した３要素の構成のルールです。Christopher Alexander が提案したように、「各パターンは私達の環境の中で繰り返し発生する問題を表現し、私達が同じ解決法を２度と行う事なく100万回繰り返し利用できるような方法で問題に対するソリューションの中核部を描いています」。(ITABoK P136より) ある組織が（または業界が）既に行なっている様々な活動やこれから始まろうとする未来の活動スコープの中から再利用可能なパターンを「アーキテクチャの視点」で見つけ出すためには、それなりの知識や知見、経験と訓練を要する事でしょう。また、パターンの評価については、非機能的要件や品質属性に関連づける事を勧めています。(ITABoK P138より) （現実にはPM担当者やシステム開発部隊の声として「作った方が早い」「私たちは何でも作れるのだが」という声も聞こえて来る場合もあるでしょう） 「ライフサイクルおけるトレーサビリティ」については、既に前の数ヶ所で触れましたが、ITABoKが随所で強調するトレーサビリティの重要性は以下の様に説明されています。 トレーサビリティは適切な要件マネジメントに欠かせない活動の１つです。これにはビジネスの関心事の生涯を文書化するプロセスやその関心事に関連したケイパビリティへの双方向のトレーサビリティを提供するプロセスが含まれます。（中略） 　アーキテクトは、ビジネス要件から長期的システムまでの適正なトレーサビリティを確立するプロセスによってプロジェクト・チームをサポートし、「開発段階にあるソリューション」のライフサイクルに関わるトレーサビリティの重要な役割を説明できなければなりません。（ITABoK P141より） ITアーキテクトはこの役割において、ビジネスの関心事と関連するケイパビリティを双方向のトレーサビリティで確保し、分析段階から実装段階、最終的には運用段階に至るまでカバーする重要性を説明しています。 「全体システムのデザイン」は、冒頭でも触れましたが、アーキテクチャの総合的なビューを採用したもので、この中にはシステムサイエンス、システム理論、システム思考を包括しており、またアーキテクトは複雑なシステムの問題を認識しこれらに対処する事も含んでいるとしています。 一方、全体システムの視野を失う事は中長期でのシステム保有コストを増大させ、ビジネス価値に影響を及ぼす事にも言及しています。この例として長年の多くのITプロジェクトの結果、複雑化したスパゲッティ状態のシステム群やソリューション毎に乱立したシステム群の状態を思い浮かべて頂けるとイメージし易いでしょう。 今回は、「デザインスキルの柱」を取り上げました。個別のデザイン方法論やテクニックに関してITABoKではそれ自体の詳細な解説は行なっていません。このデザインスキルの柱は、ITアーキテクトが常に全体システムのアーキテクチャ視野を持ちながら、個別の方法論やテクニックをデザイン本来の目的に活かせる様にガイドしている点が伺えます。 本コラムでご紹介した「デザインスキルの柱」と既にご紹介してきた4つの柱が、ITアーキテクトを目指す方々や育成に携わる方々のアーキテクチャ設計に必要な知識とスキル習得の指針の一助として役立てて頂ければと思います。 このコラムに関して皆様からのご意見や感想、参考になる事例等がありましたら是非お聞かせ下さい。本コラムがITABoKの理解とこれからのITアーキテクトのあるべき姿の一助になる事を願っています。 参考： アーキテクチャの策定プロセスや成果物（アーティファクト）の業界標準の一つとして、IasaではTOGAFを引用・参照している経緯があります。また、アーキテクチャ用のツールとしてArchiMateをモデリング・ツールとして推奨しています。（これらに限定する訳ではありません） TOGAF (OpenGroup)について http://www.opengroup.or.jp/togaf.html ArchiMate (OpenGroup)について https://en.wikipedia.org/wiki/ArchiMate http://www.opengroup.or.jp/archimate.html

ITABoKは、ITアーキテクトが備えるべきスキル要件を網羅した知識体系として、様々な専門領域を対象としております。よって、独力で学習されている方が、全ての内容を理解することにはハードルがあると思われます。また、ITABoKに書かれているトピックを他人はどう理解し、実践しているのかを知ることは非常に有意義と考えます。 こうした点を踏まえ、Iasa日本支部理事が持ち回りで、ITABoKの各章を解説していきます。また、単なる情報発信に終わるのではなく、それをきっかけに皆様からコメント・意見をいただき、活発な議論に広げられればと思います。気軽にフィードバックください。 1回目は、ITABoKの冒頭から＜1.ITABoK＞を取り上げます。＜1.ITABoK＞では、「1.1なぜITABoKか？」「1.2アーキテクチャとは？」「1.3アーキテクチャの価値」という章立てで、ITABoKの目的や位置づけ、アーキテクチャやアーキテクトに対するIasaの定義が述べられています。これらと絡めて、アーキテクトの役割定義というテーマにも触れてみたいと考えています。 ■ ITABoKの目的 ITABoKに書かれている内容は、大きく分類すると次の3つがあります。 ITアーキテクトとしての専門職の定義 ITアーキテクトの活用とエンゲージメント キャリア・パス この中でも特に、「専門職の定義」（スキルとケイパビリティの記述）に相当のボリュームが割かれています。これは、Iasaが「共通の知識体系と言語を創出し、ITアーキテクトの専門職を正式なものとする(註1)」ことをゴールとしており、ITABoKをプロセスや方法論の標準ではなく人々のフレームワークと位置づけていることによります(註2)。よって、ITABoKはITアーキテクトの育成に焦点をあてて書かれています。 また、ITABoKの表現自体は記述的で、特定の価値観や思想を押し付けていません。これは、十分なスキルをもつITアーキテクトの裁量を優先しているからです(註3)。そのため、ITABoKをどう活用すべきか戸惑われる方がいるかもしれません。一方で、効果的に活用されている方もいるでしょう。ここに、実践を共有することの重要性があります。 ITABoKの存在意義は、「より良い実践の検討のための共通言語を提供する」という点にあると私は思います。ITABoKを共通言語とし、議論と実践を重ねて共有することで、ITアーキテクチャに対する私たちの知見やスキルを、一層高めていくことができるでしょう。 では、ITアーキテクトの役割とはどのようなものなのでしょうか。 ■ IasaのITアーキテクチャ／ITアーキテクトの定義 Iasaは、ITアーキテクチャを「テクノロジー戦略の適用を通じて得られるビジネス、組織、クライアントによる利益の獲得の実践」「価値のあるテクノロジー戦略のデザインとその実現のアート（技能）、もしくはサイエンス(註4)」と定義しています。Wikipediaによるとアーキテクチャには「建築学、建築術、構造」といった意味がありますが、このうち建築術のニュアンスに近いと思われます。構造（モノ）としてよりも、専門職による術（コト）として定義している点がIasaらしいと感じます。 ITアーキテクトの定義を見てみましょう。Iasaは、ITアーキテクトの役割を「ビジネスのテクノロジー戦略家(註5)」と定義しています。多くの方にとってこれは抽象的な表現かもしれません。ですので、ITアーキテクトの役割についてもう少し考察してみましょう。 ■ これからのITアーキテクトの役割 ITアーキテクトに何を期待するかは組織によって様々でしょう。皆さんの組織・プロジェクトではステークホルダー間で、ITアーキテクトの役割が共有されているでしょうか。例えば、私があるITプロジェクトにソリューション・アーキテクトとして参画した際の、ITアーキテクトの役割は以下の通りでした。 お客様が抱える課題を理解して、あるべきITシステムの全体像を構想する お客様が求める品質要求を満たす、適切なIT技術／製品を選定する 開発全体を統制し、プロジェクトマネジャーを技術面で支援する ここにあげた役割はIPAのシステム・アーキテクトに近いものです。多くの組織・プロジェクトでもこれと似た役割かもしれません。ITアーキテクトがこうした役割を果たし続けていくことの重要性は、今後も変わらないと思います。同時に、私は次の3つの理由から、求められる役割の広がりを感じています。 ・アーキテクチャデザイン対象の変容 ITの世界では、もともとアーキテクチャという言葉は、IBMがSystem/360の設計思想を表現するために使ったのが始まりだそうです。それがITシステムの設計思想にも使われ、今やビジネスの視点でもこの言葉が使われるようになりました。変化の時代といわれる昨今、アーキテクチャデザインに関する多くの課題は、ビジネス視点に関わるものとなってきています。ITアーキテクトは、アーキテクチャデザインによって課題を解決する専門職です。よって、IT視点にとどまらずビジネス視点でアーキテクチャ対象を捉え、デザインできることの重要性が増してきています。 ・アジャイルへの対応 私は自身の経験上からも、組織やITの変革を成功させるにはアーキテクチャ活動へ十分なリソースと時間をかけることが重要と考えています。大規模で複雑な場合は、特にこのことが顕著です。その一方で、テクノロジー視点、ビジネス視点のいづれにおいても、アジャイルであることが求められてきています。こうしたアジャイルへの対応においてアーキテクチャ活動が、オーバーヘッドとみなされることがあるのも事実です。ITアーキテクトの役割を果たしながらも、組織のアジリティをどう高めていくか。大きなチャレンジですが、テクノロジーの目利きとしての専門知識と、ステークホルダーへの影響力を兼ね備えたITアーキテクトに期待される役割と考えます。 ・アーキテクチャスキルを備えるべき人材の広がり ITABoKに書かれているスキルは、ITアーキテクト専門職だけが備えておれば十分でしょうか？私はそう思いません。アーキテクチャはあらゆるステークホルダーの協調によって作り上げていくものです。よって、アーキテクチャに関わる全ての人が、ITABoKに書かれているスキルを理解することが望ましいと考えます。特に、Iasaの5つの柱が重要です。そのためには、ITアーキテクトは専門職として自らのスキルを高めることはもちろん、組織の基本スキルとして啓蒙していく「伝道師（エバンジェリスト）」の役割を担っていくことが求められます。 ITアーキテクトに求められる新たな役割に思いを馳せた時、私自身は「ビジネスのテクノロジー戦略家」というIasaの定義に共感できるように感じます。皆さんはいかがですか。 よろしければ、Iasaの定義に対するご意見・ご感想や、皆さんの組織でのITアーキテクトの役割定義についてお聞かせください。一緒に議論していきましょう。 註） ITABoK Version2 日本語訳版、「1.2 アーキテクチャとは？」P.18 ITABoK Version2 日本語訳版、「1.1 なぜITABoKか？」P.11 ITABoK Version2 日本語訳版、「1.1 なぜITABoKか？」P.11 ITABoK Version2 日本語訳版、「1.2 アーキテクチャとは？」P.10 ITABoK Version2 日本語訳版、「1.2 アーキテクチャとは？」P.18 以上 引用などがある場合は、下記に入れてください。

第2回は Iasa 日本支部の理事たちも、口をそろえて重要であるとする「ヒューマン・ダイナミックス」のことを取り上げてみたいと思います。 他者を説得したり、交渉し協力関係を築いたりすることを「人間力」の要素のひとつであり、IT 技術者に不足している能力とされる方もおられます。この能力は持って生まれたものであったり、個々の経験により得られる抽象的なものであり、訓練して獲得できる具体的なスキルとは一線を画したものと考えられているかと思います。 しかしながら、ITABoK では、明確にスキルと捉え、「ヒューマンダイナミックス」と命名し、訓練すれば、身に着けることが出来るものとしてとらえています。 ITABoK ではヒューマンダイナミクスを以下のようにとらえています。 ヒューマン・ダイナミクスの柱で表現されるスキルは、成功を収めるアーキテクトとなるために必要な全スキルの中で最も重要と言えます。 ヒューマン・ダイナミクスのスキルは、プレゼンテーション、ライティング、顧客との関係、リーダシップ、同僚との関係、カルチャーマネージメント、コラボレーション、ネゴシエーションと多岐にわたります。 その中でも、コラボレーションとネゴシエーションが最も高く評価されてきました。ユニークなスキルとも言えますが、このスキルを身に着けるか否かで、アーキテクトの価値の評価が変わってきます。ビジネスの方向性とそのニーズを最大限に満たすには、ステークホルダーとの協働が必要となり、しばしばタフな交渉力が必要になります。 高く評価されるコラボレーションとネゴシエーションのスキルを身に着けることは、難易度が高いとも言えます。難易度が高いからこそ、評価も高くなるのです。では、どんなスキルを、どの程度、身に着けることが求められているのでしょうか？ITABoK では、以下の「2.1.2.5 コラボレーションとネゴシエーション」にその記述があります。参照ください。 2.1.2.5　コラボレーションとネゴシエーション説明 アーキテクトは彼らのコミットメントを実現すべく多様なステークホルダーと交流する必要があります。一般的に、アーキテクト自身の成果物は同僚（他のアーキテクト、プロジェクトマネジャー、開発チームなど）の成果物に直接依存しています。 同様に、アーキテクトのアウトプットが同僚のアウトプットに影響する可能性もあります。そのため、アーキテクトは自ら目指す活動項目を実現するためにステークホルダーと共に活動したりコラボレーションを行う必要があります。しかし、全てのステークホルダーが共通のプライオリティーを持っているとは限らず、彼ら自身のタイムラインによって拘束されている可能性もあります。同様に、アーキテクトのビジョンを共有するとも限りません。 しかし、製品を実現するための数多くのタイム・クリティカルな状況で、全ステークホルダーからの情報が必要となります。よって、ステークホルダーを納得させて最適なソリューションに到達し、目指している活動項目に対して継続的なコミットメントを確保するべく、ステークホルダーと交渉することがアーキテクトの責任となります。 概要　なぜアーキテクトにはこのスキルが必要なのか？ アーキテクトのミッションは多様なソースからのインプットを収集しており、裏を返せば、これには、顧客、開発チーム、異なるレベルの管理者、成果物が左右される他チームの同僚のアーキテクト等の、幅広い領域のステークホルダーと連動することが関係しています。 成果物は以下を満たす必要があります。 顧客のニーズ 必要とされる適応可能な標準 期待されるパフォーマンス要件 以下 略 ここでは、アーキテクトは、デザインするだけではなく「最適なソリューションに到達」することへの責任を担うことを求めています。それには、顧客、他のアーキテクト、プロジェクトマネジャー、開発チームなどと協働し、「動くシステム」を実現する必要があります。 デザインしたアーキテクチャーが「絵に描いた餅」であってなりません。繰り返しになりますが、「最適なソリューションに到達」するために、ITABoK では、コラボレーションとネゴシエーション力の必要性を強調しています。 さて、この能力を高めるには、コミュニケーションの原理原則を知り、多様なステークホルダーのニーズを引き出し、その上でコラボーレーションやネゴシエーションを行うことが有効です。少し、そのTips(コツらしきもの)を以下に示します。皆さんの Tips もコメント頂き共有できればと思います。 １．もう飲みにいったか？ コミュニケーションを円滑にするためには「ノミニケーション」と言われるものがあります。お酒を飲む場だけとは限りませんが、色んなシチュエーション（できればオフサイト）でコミュニケーションを図り、コラボレーションやネゴシエーションしやすい環境を事前に構築しておくことも効果的です。 ２．協力会社を外注・業者扱いしていないか？ ステークホルダーのモチベーションが、成果を左右することが大いにあり得ます。互いにリスペクトすることで、コミュニケーションのベースとなり、切磋琢磨につながります。 ３．プロジェクトは一つの社会という認識をしているか？ 仕事と遊び・先輩と後輩・分担と協調・ルールと自由度などを認識し、良きコミュニケーションを図り、２~３か月に一度は目標の再確認と親睦を図るイベントを開催することで協調性が生まれます。 まだまだあるかと思いますが、オンサイト、オフサイトにかかわらず、場づくりやその中での立ち振る舞いにおいても、ステークホルダーとのコラボレーションが求められます。特に PM との連係は重要になります。また、若手にイベント幹事を担当してもらうことで、その訓練と実践の場とすることも一考ではないでしょうか？ 註） ITABoK Version2 日本語訳版、「2.1.2 ヒューマン・ダイナミクスの柱」P.105 ITABoK Version2 日本語訳版、「2.1.2.5コラボレーションとネゴシエーション」P.133