検索結果

はじめに Iasa日本支部は来る11月4日にアニュアル・カンファレンスを開催します。このイベントで株式会社アーキテクタス代表取締役の細川様より「クラウド時代のアーキテクチャと人材育成」のタイトルでご講演をいただきますので、ここでもクラウドに関する話題を取り上げてみたいと思います。クラウド・ファーストが常識となってもうずいぶん経ちますが、 他部門、とりわけビジネス部門へのクラウドの説明にはまだまだ多くの方々が苦労されているのではないでしょうか。やはりここはモデルを描いて説明できると良いですね。ただ、おたがいエンジニアであれば、クラウドベンダーオリジナルのアイコンを駆使したカッコよいモデル図で話も進みますが、おなじ図をビジネス部門に見せても、あまりわかってもらえないかもしれません。かといって、ビジネス部門向けに別にモデルを描くのも面倒です。IT部門とビジネス部門、両方で役に立つモデルを描きたいとき、ArchiMateはとても役に立ちます。 実際に描いてみた まずはこちらの図をご覧ください AWSの初心者向けテキストなどでおなじみのサンプルですね。表記が全て英語なのは、以降のサンプル図も含め、たまたま元ネタが英語だっただけで、ArchiMate自体はUnicode対応で日本語も問題なく扱えます。 ArchiMateはデフォルトのノーテーションだと、まず初見のヒトにはすこし抵抗があるかも知れませんし、華のない地味な見た目になりがちですが、こんなふうにArchiMateという本当の姿を隠して、初見のヒトにも抵抗のない、いかにもよくあるAWSインフラアーキのモデルのような見た目も実現できる、ということです。 Archi®の新機能「Specializations Manager」 どうすればこのような見た目を実現できるか、ですが、ほとんどの皆さんはArchiMateを描くのにArchi®をお使いでしょう。Archi®で見た目をデフォルトから変える方法はふたつあります。 ひとつは「Custom Image」で、要素ごとに画像を設定する方法です。これはビューレベルの設定で、モデル本体には影響しません。モデル上の同じ要素から別のビューを起こせば、ArchiMate本来の地味な見た目になります。 もう一つは「Specialization Manager」機能で、ArchiMateの各要素のサブタイプをモデルレベルで定義します。例えば「Amazon EC2はArchiMateのシステム・ソフトウェア要素のサブタイプ」と、Specializations Managerに登録するわけです。上の図ではこれらのAWSサービスを下の図のようにArchiMateの各要素に割り当てています。 それぞれのサブタイプに各AWSサービスのアイコンをセットすれば、要素側のSpecialization属性設定によって。対応するAWSアイコンがデフォルトで表示されるようになります (不要な場合はもちろん個別にアイコンを消すこともできます)。 AWS、Azure、GCPといろいろクラウド使っていて、それぞれの図はあるが全体を描いた絵が無い、とお困りの際は、ArchiMateでひとつにまとめてみてはいかがでしょうか。各社が提供するアイコンセットを使えば、「映える」分散アーキテクチャ図の出来上がりです。 「テクノロジー・プロセス要素」の出番！ ArchiMateで描けるものとして、ほかにもたとえばクラウドには付き物のCI/CDプロセスが挙げられるでしょう。ArchiMateなら、上で描いた「デプロイされる先のインフラ」に「デプロイに至るプロセス」を付け足すことができます。普段はバッチジョブとかバックアップとかアラートとか以外、あまり使い道が思いつかないArchiMateのテクノロジー・プロセスやファンクションの要素がここでは主役になります。たとえばこんなふうに。 「アーティファクト」から生まれるものとは？ CI/CDプロセスを経てクラウドにデプロイされるのが何かというと、それが前回のコラムでも取り上げられた「アーティファクト」ですね。ArchiMateにもアーティファクトという要素があって、そういったCI/CDプロセスでも扱われる、いわゆるビルドやリリース、バイナリと呼ばれるものや、またデータベースの物理エンティティの表現にも用いられます。 CI/CDプロセスを経てプロダクション環境のコンピューティング・ノードにデプロイされたアーティファクトはそこで実行され、アプリケーション・コンポーネントを「実現 (realize)」します。そしてそれはアプリケーション・ファンクションを経て、最終的にビジネス・ファンクションの実現に繋がります。ArchiMateだとこんな絵になりますが、この縦の繋がりが多数集まれば、それを束ねることでビジネス・オペレーションのモデルが出来上がります。テクノロジー・インフラもちゃんとビジネスと繋がっている、ということをこのように可視化すれば、IT部門とビジネス部門の相互理解も進みます。、 ビジネス部門にもArchiMateを教えてあげよう テクノロジー・インフラだけならどんなツールを使っても描けますが、上記のようにそこからさらにビジネス・アプリケーションやオペレーションを書き足していけるのがArchiMateの良いところです。そもそもArchi®で描かれたArchiMateモデルはXMLで書かれたデータなので、物理的な平面に描かれた視覚表現でなければならない、という制約はなく、リモートGitに繋いだりして、アプリやビジネスなどの他の領域のデータを、それぞれのご担当に書き足してもらう、という方法も取ることができます。そして視覚表現は、時と場合に応じた適切な内容を、モデルのデータから書き起こす、というわけです。 ITスキルというとすぐPythonとかのプログラミング、という話になって、今やビジネス・パーソンも言語のひとつくらい、なんて言われかねない昨今ですが、こういうスキルや知識もありますよ、と水を向けてみるのも良いでしょう。ビジネス部門を始め、多くの部門の協力を得ることで、アーキテクチャ・デザインがデジタル・テクノロジーのおかげで全社的にスケールして、それがやがてDXなどの成就に繋がるかも知れませんよ。

バリューモデルとは ITABoK2からBTABoK3で大きく進化したIasaエンゲージメント・モデルですが、バリューモデルはその進化の大きな特徴の一つでしょう。「職業としてのアーキテクトの価値 (バリュー) 向上」は、Iasaの主要な活動目的のひとつであり、今回のエンゲージメント・モデルにおけるアーキテクチャの価値 (バリュー) へのフォーカスも、それに沿ったものといえます。 Iasaエンゲージメント・モデルにおいて、バリューモデルは「明確かつ一貫した一連の意思決定ルールによる価値実現」と定義されています。ここでは、アーキテクチャはつまるところ、何らかの決定の積み重ねである、という、言われてみれば当たり前のことが前提であることにあらためて気づかされます。 昨今多くの企業や組織で、それらの業務システムの過剰な複雑化・硬直化が課題となっていますが、そもそも意思決定が正しくない、あるいは存在しない場合、そうなるのは当然でしょう。それでも景気全体が良かったころはカネ頼みの力業で解決できたでしょうが、今ではそうも行きません。 まずは意思決定に対し、もっと自覚的になること、有体に言えば、体裁だけの意思決定や、ベンダー丸投げに代表される意思決定の放棄といった旧習を見直すこと、というシンプルながら大事なメッセージが、このバリューモデルに込められています。 Iasaエンゲージメント・モデルでは、バリューモデルの内側にピープルモデル、外側にオペレーションモデル、更にアウトカムモデルが配置されていますが、内側から順に見て行けば、正しい人々 (ピープル) が、正しい決定 (バリュー) を下し、それが正しく実行 (オペレーション) され、正しい成果 (アウトカム) を生む、という、エンゲージメント・モデル全体のメッセージ、あるいはストーリーが見えてくるでしょう。 バリューモデルの概要 エンゲージメント・モデルのナビゲーション・マップでは、バリューモデルのリング上に、正午の位置から時計回りに以下の項目が配置されています。 目標 (Objectives) 技術的負債 (Technical Debt) 投資計画 (Investment Planning) スコープとコンテクスト (Scope and Context) 構造と複雑性 (Structure and Complexity) カバレージ (Coverage) 原則 (Principles) アーキテクチャ分析 (Architecture Analysis) バリュー・ストリーム (Value Streams) バリュー・メソッド (Value Methods) リスク・メソッド (Risk Methods) それぞれの項目についての詳細は別の機会に譲りますが、下記のように概要をまとめてみました。 まず「目標」「投資計画」そして「技術的負債」は定量的価値に対する取り組みです。SMART (Specific-Measurable-Assignable-Realistic-Time bound) な目標立案、OKR (Objectives and Key Results) によるアジャイルな目標管理、バリュー・マネージメント・フレームワークを活用した投資計画立案手法などが取り上げられています。 「スコープとコンテクスト」は、アーキテクチャにおける意思決定の影響が及ぶ範囲 (スコープ) のレベル分け、またその意思決定に影響を与える様々な要因 (コンテクスト) についての考察です。 「構造と複雑性」は、アーキテクチャ上の問題解決における複雑性の評価に、CynefinやVUCA (Volatility-Uncertainty-Complexity-Ambiguity) などのフレームワークを活用する方法を紹介しています。 「カバレージ」はアーキテクチャ・タスクの戦術的な選択や優先順位の考え方を論じています。 「原則」「アーキテクチャ分析」は、アーキテクチャ上の重要な判断に関わるステークホルダとの価値基準、評価手法および結果の共有についての考え方が記されています。 「バリュー・ストリーム」「バリュー・メソッド」は、ケイパビリティ、バリュー、(サービス・) プロダクトの間の関係性、「品質」「コスト」「売上」「タイムライン」という4つの観点からの価値評価手法を取り上げています。 「リスク・メソッド」は、一般的に知られたリスクの類型と対応方法をまとめています。 バリューモデルの特徴 このバリューモデルの特長として、まず第一にはその対象の幅広さと多様な切り口が挙げられるでしょう。意思決定というと、まず単一のITプロジェクトの”Go or No-Go”といったシンプルなイベントを想像しがちですが、バリューモデルでは先に挙げたように、エンタープライズという時空間の全体に広がるアーキテクチャを生成・維持するダイナミズムとしての意思決定が、様々な視点から論じられています。 もう一つの特長は、様々なキャンバス・テンプレートの提供です。キャンバスといえばビジネスモデルの開発に向けたものが有名ですが、バリューモデルの一部の項目では、実践に役立つ様々なキャンバスが、その活用方法とともに紹介されています。これらのキャンバスはppt形式のファイルとしてダウンロードも可能です。複数のアーキテクトがチームワークを通じて組織にエンゲージするために、このように予めデザインされたテンプレートが存在することは大きな助けになるでしょう。 バリューモデルの活用 いうまでもなく、アーキテクトは組織の価値実現にコミットする立場であり、そのためには組織の正しい意思決定をリード、あるいはファシリテートすることが一つの重要なアーキテクトの役割となります。逆にいえば、アーキテクトの関与 (エンゲージ) 抜きですでに下されてしまった、ひょっとすると間違っているかもしれない決定をフォローするだけなら、それはもはやアーキテクトとは呼べない、ということになります。そこでどうすべきか、どうすれば「本当の」アーキテクトに近づくことが出来るかを、全てとは行かないにしろ、このバリューモデルから学ぶことが出来るでしょう。 Iasa Globalのホームページでは、BTABoKのコンテンツに関連した解説付きスライドが"Learning Shots”として多数掲載されています。バリュー・フォーカスな意思決定をリードするアーキテクトを指向する皆さんは是非一度覗いてみて下さい。

11月4日(金)開催予定のIasa日本支部アニュアル・カンファレンスにて、JFrog様より「アーティファクト管理の3つのポイント」と題して講演いただく予定です。 そこで今回のコラムでは講演に先立ち「アーティファクト」について簡単にまとめてみたいと思います。 まず言葉の意味ですが、アーティファクトとは、一般的には「人工物」や「工芸品」を指します。 図1：一般的なアーティファクトの意味 (人工物や工芸品) 一方、ITABoK V2においてアーティファクトという言葉は各所で使用されており、文脈によって様々な意味を持ちますが、用語の定義としては以下になります。 アーキテクチャ・アーティファクトとは モデル、モデルエレメント、または、ドキュメントのような、アーキテクチャ・プロセスの有形な生成物。これには、議事録、ダイアグラム、根拠の説明書、ホワイトボードセッション、意思決定のトレーサビリティを提供する他のあらゆる成果物が含まれる。 なお、概念の混乱を避けるために先に申し上げますが、後述するソフトウェア・アーティファクトはアーキテクチャ・アーティファクトの一部です。 図2：アーキテクチャ・アーティファクトとソフトウェア・アーティファクトの関係 ITABoK V2では、アーティファクト管理の重要性が語られています。それもそのはず、ITABoKはITアーキテクチャの重要性を語ることが主な目的の1つであり、アーティファクトはITアーキテクチャを構成する重要な要素と位置付けられているためです。 ITABoKでは優れたITアーキテクチャによって、最適な品質のITシステムが生まれると述べられています。言い換えるとアーティファクトの品質がITシステムの品質を左右するということです。 図3：ITにおけるシステム、アーキテクチャ、アーティファクトの関係 DXが叫ばれる昨今において、目の前の課題解決のためにデジタルツールを導入することも大事かもしれませんが、最適なITアーキテクチャの検討が不十分なまま導入してしまうと、後々ITシステム全体に悪影響を与えかねません。将来のビジネス環境やニーズ、ITテクノロジーの変化に対する柔軟性を確保するためにもITアーキテクチャデザインを考えることは非常に重要なことです。 またDevOpsが徐々に浸透する中で、ITアーキテクチャの構成要素は多様化および複雑化し、ITシステムはバージョンアップを繰り返しながら進化していきます。そういった中でいかにしてアーティファクトを管理するかが非常に重要になってきます。 特に最近はITの構成要素のうちソフトウェアが占める割合が増加しており、それが変化のスピードを向上させる要因にもなっています。この流れが続くと仮定すると、ソフトウェア・アーティファクトの管理の仕方についての再検討も必要になることがあろうかと思います。 冒頭にご紹介したJFrog様の講演では、ソフトウェア・アーティファクトの具体的、実践的な管理の仕方についてお話いただく予定です。 以前JFrogの方にお話を伺った際に、JFrogというツールは単にバージョン管理やデプロイの自動化といった機能的な話に留まらず、製造業における在庫管理、品質管理といった上位概念に近いコンセプトが実装されたソリューションという印象を持ちました。(図4参照) 図4：アーティファクトのライフサイクル (引用元：JFrog Japan Blog) アーティファクト管理というのは一見地味な活動に見えるかもしれませんが、デジタル社会においてはその品質管理の精度がいろいろなところに影響してくると思われます。 もしご興味ございましたらご参加いただけると幸いです。参加申し込みはこちら。 ご一読いただきありがとうございました！

近年、サイバー空間とフィジカル空間を高度に融合させたシステムにより、経済発展と社会的課題の両方を解決する社会の実現が求められています。 これらシステム全体の構造自体やその運用に関するデジタル技術の革新への変化のスピードが高まる中で、システム全体を把握したエコシステムとしての設計を行う必要性が増大しています。 システム全体を把握し全体の最適化を目的としたアーキテクチャの設計の在り方を極めるためには、その社会実装を後押しするため産学官に働きかけ、フィードバックを元に常にアーキテクチャを改善していくための場が必要不可欠となっています。 この度、Iasa日本支部では、恒例のアニュアルカンファレンスとして「逆襲の日本式経営と実践的アーキテクチャ」をテーマに産学官の識者をお迎えし、来る１１月４日（金）にオンライン開催されることとなりました。 産業分野からは情報システムの開発運用におけるJfrogJapan社の最前線での挑戦、及び官界からは政府CIO補佐官からデジタル庁の最新動向についてご講演頂く予定となっています。 また、学究の世界からは、慶応大学の岩尾俊兵先生にご著書の「日本式経営の逆襲」（2021年6月発刊）に基づいたご講演をいただくことになっています。このコラムでは、「日本式経営の逆襲」を参照する形で、11月4日に開催のカンファレンスの趣旨について述べていきたいと思います。 ご著書では、海外、特にアメリカで評価されている経営手法の源流は日本発であることが多く、日本の経営は「遅れている」と言う言説にとらわれることなく、日本式経営に自信を持つべきだと主張されています。例えば、「リーンスターアップの元はトヨタ生産方式である」、「アジャイル開発は二重三重の意味で日本の経営技術に起源をもつものである」などの興味深いお話しがご著書の随所に出てまいります。 ２００１年のアジャイルソフトウエア開発宣言（マニフェスト）は有名となっていますが、そもそもこの概念自体はマニフェストの発表よりも３年早く１９９８年に日本の研究者から提案されているそうです。同様に、流行しつつあるティール組織は、従業員がカイゼンなど自ら創造性を発揮するとか、幅広く権限が委譲される現場主義とかの日本発のスタイルを取り入れており、トップダウンマネージメントのアメリカ型企業への対案であるとしています。それらの経緯は、「日本式経営の逆襲」に詳しく述べられてます。 ただ、アメリカは、それらの日本発の仕組みをコンセプト化しパッケージ化することに優れており、それらを日本発であることを認識せずに導入する日本企業も少なくないとのことです。しかし、逆輸入された経営手法を安易に取り入れると、すでに自社が保持していた経営技術をおろそかにし、新しい手法などに翻弄されて、結果として現場が混乱して疲弊し、企業が元から持っていた強みを捨てさせてしまうこととなる可能性があると言うのです。その問題と解決への道は、ご著書を購読いただき、１０月２９日のカンファレンスで岩尾先生のお話を聞いていただくことで理解が深まるかと思います。 さて、コラムの筆者は、日本式経営と言えば、経営の神様である松下幸之助を思い出します。また、近年脚光浴びだした出光興産の出光佐三は日本の世界進出を促した英雄とも言われており、京セラの稲盛和夫は、今も日本の産業界での影響力を発揮されていることを思い起こします。 彼らの経営については思想・哲学から逸話や名言まで、あまたの書物が出版されています。その中で、組織論として有名なものに、松下幸之助には「事業部制」が、出光佐三は「組織は無をもって理想とする」、稲盛和夫には「アメーバ経営」があります。 ここで、取り上げたいのが、これらの組織論とビジネスアーキテクチャの関係です。事業部制にしたり、組織を無にすることや、アメーバ経営を追求することで、ビジネスの仕組みも変わります。そうです、ビジネスアーキテクチャをどう描くかは組織に対する考え方が多大な影響を与えることになります。ただ、それは、経営者の経営哲学や理念から生み出された組織論であることは言うまでもありません。 アメーバ経営も稲盛和夫の「会社経営とは一部の経営トップのみで行うものではなく、全社員が関わって行うものだ」という考えを実践したものです。いずれにしても、松下幸之助は「事業部制」をベースに、出光佐三は「組織は無をもって理想とする」ことで、稲盛和夫は「アメーバ経営」で実践的なビジネスアーキテクチャを追求していったように思います。 話は少し脇道になりますが、「マタギ」の世界のリーダーの考え方はご存じでしょうか？以下は、梅原　猛の著書「将たる所以」で述べられている狩猟採集民の「マタギ」の話からの抜粋です。 ＊＊＊＊＊＊＊＊　抜粋　＊＊＊＊＊＊＊＊＊ 民主主義のリーダー、民主社会におけるリーダーは、どのようにあるべきか。ここで私は民主主義というものを明治以後、単なる西洋から輸入されたイデオロギーとは考えない。 これはすでに多くの人から指摘されていることだが、我が国の文化の基層には縄文の文化がある。中略　縄文人は狩猟採取民であるので、その文化伝統を継ぐのは、狩猟採集を行っているマタギである。 このマタギ文化を考察すると、その社会は、はなはだ民主的な平等の原理によって運営されている事がわかる。 例えば、マタギ社会において、もともとマタギ社会に住む人間はすべて平等であるが、猟の時だけは一人のリーダーを親分として選ぶ。リーダーを選ぶにはみんなで集まって、狩りが一番上手人間を選ぶのであり、熊の狩りの時は熊狩りの上手なリーダーを、猪狩りの時は猪狩りの上手なリーダーを選ぶ。そして、熊狩り、ありいは猪狩りの時には、やはりそのリーダの命令に従うのである。しかし、熊狩りや猪狩りが済むと、そのリーダーはリーダーであることを免ぜられ、村人の一人に戻るのである。 そして、獲物は猟に参加することのできなかった老人ばかりの家や未亡人の家にも、ほぼ平等に配られるのである。 ＊＊＊＊＊＊＊　以上　＊＊＊＊＊＊＊＊ このマタギの話しは、システムつくりにおける組織運営においても参考となるかと思います。アーキテクト達が得意分野に特化し、それぞれの分野でリーダーシップを発揮し、全体システムを作り上げていくことが、成功要因のひとつとなるのではないかと考えます。 一方、「日本式経営の逆襲」では、ティール組織のことを以下のよう述べています。 ＊＊＊＊＊＊＊＊　抜粋　＊＊＊＊＊＊＊＊＊（P58から引用） ティール組織では、組織がまるで生命体のように、人が集まって目的を達成してまた分散する。そして、その前提として組織の構成員によるセルフマネジメント（自己決定・自己管理）がおこなわれ、組織の構成員は仕事のつきあいだけでなく人間としての全体が組織に受け入れられ（全体的・ホールネス）、さらに組織はビジョンを進化させ続ける。ティール組織においては、もはやトップダウン型のいわゆる「マネジメント」は必要なくなるという。こういわれるとなんだか高尚なイメージなるだろう。 しかし、よくよくかみ砕いてみれば、従業員が自ら創造性を発揮するとか、自分の職場に責任をもって自分でマネジメントするとか、幅広く権限が委譲される現場主義とか、職務を分担せずにたすけあうとか、必要に応じて人が集まってきてチームになるといったことは、日本の企業では当たり前のことではないだろうか。あるいは、これらのことをあたりまえにこなす日本企業は比較的多いのではないだろうか？（以上P58から引用） ＊＊＊＊＊＊＊　以上　＊＊＊＊＊＊＊＊ いずれにしても、日本の文化や思想を学び、優れた日本の経営技術を参考にしてコンセプト化やアーキテクチャに仕立て上げビジネスシステムを刷新していく中で、日本を取り戻すことが求められているように感じます。 「日本式経営の逆襲」では、「経営技術の逆輸入モデル」や「カイゼンの研究やよみがえらせ方」「日本式経営のこれから」なども語られています。 特に、「日本式経営のこれから」では、日本だから出来ることとして、産業界での経営技術の開発と研究者側の経営理論である経営学とが共同して企業経営に関する統一理論を構築する可能性を官界を含めて取り組むことを提言されています。 産学官からの講師３人をお迎えした11月4日（金）のカンファレンスがきっかけとなって産学官の力で、日本からの逆襲が始まるようなことがあれば、この上ない慶びです。カンファレンスへの参加をお待ちしております。

BTABoK紹介シリーズとして４回に分けて、パブリックレビューで公開中のBTABoKV3.0で新たに追加されたエンゲージメントモデルの中から複数のモデルを紹介してきました。具体的には、下図の４つのサブモデルです。 ・アウトカムモデル ・オペレーティングモデル ・バリューモデル ・ピープルモデル エンゲージメントモデルの全体的な目標とは、ビジネステクノロジー戦略を実現するために、アーキテクトチームの活動を最大限に活用することと言えます。アーキテクトの組織は、これらのモデルを活用して、成熟した価値あるアーキテクチャの実践のための「活動、成果物および作業」を定義することができます。つまり、エンゲージメントモデルの目的は「アーキテクチャの実践」そのものと言えるのです。エンゲージメントモデルの中核にはアーキテクチャ実践モデルがある、というのがBTABoKの考え方です。BTABoKでは5つの節に分けて、アーキテクチャ実践モデルの内容が述べられています。https://itabok.iasaglobal.org/itabok3_0/architecture/ 1.What is an Architecture Practice 　多くの組織における考え方と何が違うか？ 2.Why is a Practice Important to Architects 　アーキテクチャ実践モデルへの転換がもたらす課題とメリット 3.Competencies, Career Path and Advancement 　専門職の基本要素と、コンピテンシーモデルとの関連 4.The Architects Practice in the Enterprise 　アーキテクチャ実践の主要な成功要素 5.Building an Architecture Practice 　アーキテクチャ実践が責任を担うべき活動とは 今回は、このアーキテクチャ実践モデルを見ていきましょう。 1.What is an Architecture Practice 最初にまず押さえておくべきことは、アーキテクチャ実践モデルとは特定の手法やテクニックというよりも、マインドセットそのものであるということです。その背景にある考え方は、「プロフェッショナルとは特定のスキルを学ぶことで成長し、そのスキルを応用して価値あるものを作り上げる」というものです。例えば、医師は医師の、看護師は看護婦の、そして経営陣を含む運営スタッフはスタッフの、教育・スキルの習得・昇進・メンタリングについて、それぞれ異なったモデルに従っています。しかし、多くの組織ではアーキテクトなどの専門職にとってそのようなモデルになっていません。確かに、資格や面接、経験を見て、その人がどのような仕事に適性があるのか判断していることでしょう。しかし、その時々の組織の内部政治、政策、構造にひきずられていることが依然として多いのが現実です。そうではなく、専門職の中で共有される知識群、さらには各専門分野の習得を中心にキャリアを捉えることが実践的な考え方です。学習、指導、能力の向上、資格取得、そして何よりも現代的な知識体系のもとで能力を発揮することが、個人のキャリアを導きます。 2.Why is a Practice Important to Architects この節では、アーキテクチャ実践モデルへの転換がもたらすメリットと課題があげられています。詳細はBTABoKを参照いただければと思いますが、ここでは主なものを抜粋します。そのメリットとして以下のような項目があげられます。 ・最新のメソッドやテクニックの効果的な導入 ・明確な役割分担の相互作用 ・組織横断的な共通コンピテンシー ・より成功したデリバリー ・信頼と倫理 ・体系的なキャリアパス ただ、こうしたメリットは無料で手に入りません。次のような課題に立ち向かう必要があります。 ・人材の確保と定着の難しさ ・価値の理解度の低さ ・技術的負債とレガシーモダナイゼーション このリストは実践モデルに投資することの長所と短所を網羅したものでは決してありませんが、そうすることによって得られる価値を明確に定義しています。 3.Competencies, Career Path and Advancement 「アーキテクトとは何か？」という問いは、これまでにも多く語られてきました。しかし、それは根本的に間違った問いに焦点をあてているとBTABoKは述べます。BTABoKによれば、次の4つの基本要素によってどんな職業も定義されます。 a) 社会に対する価値提案 b) それを実践するために必要な能力 c) 最新の、よく知られた知識体系、 d) 個人がその職業の最高レベルまで昇進するための方法 これらの要素は、自然法則や哲学的な議論によって決定されるものではなく、十分な人数の人々が協力し、それらに同意し、その基準を社内外で実施し、社会、政府、一般人に対して支持することによって決定されるものです。それを決定するハードルは高いでしょう。でも、医師を目指す人にとって大学の医学部での認定の難しさを考えてみてください。人間の安全、アイデンティティ、グローバルセキュリティ、組織の財政的利益にとってそれが重要なものである場合、真の専門的なインフラストラクチャが必要となります。BTABoKは、技術戦略とアーキテクチャがこの重要な段階に達しているという考えに基づいています。 4.The Architects Practice in the Enterprise この節では、エンタープライズにおけるアーキテクチャ実践の成功要素が述べられます。一口にエンタープライズといっても、1人から15人の組織と1000人以上の大企業の間には大きな違いがあるでしょう。しかし、BTABoKで定義される手法は、規模を拡大しても縮小しても対応できます。ただし、エンゲージメントモデルを理解し、実践モデルが組織に適合していることが不可欠です。以下に主要なアーキテクチャ実践の成功要素を列挙します。これら成功要素とアーキテクトの活動を整合させることが基本であると、BTABoKでは述べられています。 ・コンピテンシーと経験に基づくキャリアパス ・成果に基づく価値観 ・ドライバに基づく品質属性 ・実践における成熟度の現状理解と、それを高めるための道筋 特にアーキテクト組織が成熟に向かう初期段階では、「非アーキテクト」でありながらアーキテクチャの仕事をしているようなステークホルダーを、その組織に加える必要があるかもしれません。BTABoKではそうしたアーキテクト組織のことを、拡張チームと呼びます。拡張チームとは、専門職としてのアーキテクト組織が確立されていない環境において、アーキテクトコンピテンシーを発揮するようなチーム構成を作ることです。それは、多くの組織で、プロジェクトや能力のポートフォリオを完全にカバーするのに十分なアーキテクトがいないことから必要とされます。 アーキテクトとしての仕事は一人だけではやり遂げられません。専門家として支えてくれるパートナーとの関係が鍵です。アーキテクトとして成果をあげるために、自分にないスキルを持つ多様な協力者を巻き込んでいきたいものです。そして、彼らと手を組んで成果をあげていくために、アーキテクトとして行うべき活動と身に付けておくべきスキルは何かを定義することは非常に重要となるでしょう。 5.Building an Architecture Practice 最後に、アーキテクチャ実践が責任を担うべき活動です。アーキテクチャ実践は、以下の5種類の活動に説明責任を持たねばならないと、BTABoKは述べます。 ＜運営組織の構築＞ 運営組織の目的は、エンゲージメントモデルを構成する実務、役割、タスク、成果物などを定義することです。その構成メンバーは、小規模で、かつ組織のアーキテクトを代表するのに十分な規模を持ちます。主要ベンダーやサービスインテグレータの代表者、業務の成功に深く関与している「若手アーキテクト」を参加させる必要があります。 ＜人の成長＞ 他のグループや利害関係者との相互関係を明らかにし、彼らとのタッチポイントを理解することが不可欠となります。 ＜成熟度の向上＞ 成熟度は、デジタルアドバンテージの成果への影響を理解することによって測定されます。アーキテクトは、ビジネス部門と連携してデジタルアドバンテージを実現し、これらの目標やその達成状況を設定し測定しなければなりません。 ＜信頼と自覚の向上＞ 雇用主やクライアントから、アーキテクチャの実践が望ましいと思われることが不可欠です。それとあわせて、実践が組織の能力としてどのように認識されているかについて、アーキテクト自身の意識を高めていくことも求められます。 ＜エンゲージメントモデルの管理＞ アーキテクトの業務遂行において使用するプロセス、成果物、およびツールをマネジメントすることです。それは全体からのフィードバック、実験、および成功に基づき更新する必要があります。 ＊＊＊＊ ここ数年でわたしたちの生活も大きく変わりました。その変化のなかで、社会、公共、企業のあらゆるレベルでデジタル技術が不可欠な存在となりました。わたしたちは、このデジタライズされたプラットフォームを活用するだけでなく、その上で多様なステークホルダーとコラボレーションしていく必要があります。これからのアーキテクトは、そうした状況でよりよい実践をし続けるために、エンゲージメントモデルを駆使していかねばなりません。 今回はエンゲージメントモデルの核心ともいうべき、アーキテクチャ実践モデルを解説しました。Iasa日本支部では引き続き、BTABoKをテーマとした勉強会やガイダンスとなる情報発信を行っていきたいと考えています。今後のIasa日本支部の活動へのご参加、ご協力をよろしくお願いいたします！

ピープルモデルの位置付けとその概要 前回までのコラムでは、パブリックレビューで公開中のBTABoKV3.0で新たに追加されたエンゲージメントモデルの中から複数のモデルを紹介してきました。今回は４つ目のピープルモデルの概要を紹介します。ピープルモデルに触れる前に、今一度「エンゲージメントモデル」の意義を振り返ってみたいと思います。 Iasaエンゲージメントモデルは、アーキテクトの組織が成熟した価値あるアーキテクチャの実践を達成するために使用する、活動、成果物、作業を組み合わせたものです。Iasaのエンゲージメントモデルの目標は、アーキテクチャチームを最大限に活用して、ビジネステクノロジー戦略を実現することです。 エンンゲージメントモデルでは、その構成要素として更に４つのモデルが存在し、先のコラムで既にアウトカムモデル、オペレーティングモデル、バリューモデルの３つが紹介されています。今回紹介する４つ目のピープルモデルは、BTABoKの構成では図1の赤い枠に位置付けられています。 図１　BTABoKエンゲージメントモデルにおけるピープルモデルの位置付け では、ピープルモデルとは何か、その概要や特徴、活用について見ていきましょう。 エンゲージメントモデルをその内側から順に見て行くと、アーキテクチャの実践(Practice)に基づいて、適切な人々 (People) が、正しい決定 (Value) を行い、それが正しく実行 (Operation) され、目指す成果 (Outcome) を創る、というインサイド・アウトでの因果関係を表しています。 図2　エンゲージメントモデル全体像とピープルモデルの位置付け この図でお分かりの様にピープルモデルは組織がアーキテクチャ活動を推進し、目指す成果（アウトカム）を継続的に生み出す源泉として位置付けられています。当然の事ながら、様々な知識やベストプラクティスを適切に活用できているか否か、また都度判断を正しく行っているか等、全て個人やチーム、組織の「ピープル」に依存します。ピープルモデルではその中で更に以下の６つの構成要素について相当数のページ（原文）を割いて解説しています。 コミュニティの重要性 (Community) 職務定義書の重要性 (Job Description) 拡張チームの重要性 (Extended Team) 組織の重要性 (Organization) 役割の重要性 (Role) スキルとケイパビリティの重要性　(Skill and Capability) ピープルモデルでは、単に個人やチームがアーキテクチャ活動を推進する際に必要なものは専門知識、スキルやベストプラクティスに留まりません。その組織に最適化された職務定義書や役割のベースラインに加えて、組織や部門、専門領域を超えた横断的な活動とチームの連携が成果（アウトカム）を生み出す上で極めて重要な役割を果たすと言う考えに基づいています。そのため、各領域の専門家やステークホルダーらから構成されるコミュニティや必要に応じて弾力的に拡張されるチームの重要性が解説されています。また、ビジネス環境にあったアーキテクチャチームの具体的な組織モデルとその特徴にも触れています。 ピープルモデルの特徴 ピープルモデルの特徴は、組織が環境に適応しながら活動し変化していく中で、日々アーキテクチャ活動に従事するチームメンバーや社内外のステークホルダーらの「人」にフォーカスした活動を先に紹介した６つの構成要素で捉えている点です。静的な形式的なモデルとしての捉え方ではなく、組織の近未来の活動を支え成果を可能にするアーキテクチャを創り出すアーキテクトの活動に言及しています。この６つの構成要素は、アーキテクト組織を作り活動を維持・推進していく上で具体的で示唆に富むものです。以下、従来のITABoKV2.0ではあまり触れられていない２つの項目を取り上げてみます。 コミュニティの重要性 ピープルモデルでは、コミュニティという言葉を単なる人の緩やかな集まりではなく、組織内と組織外の関与する複数の専門家達（ベンダーやサービスプロバイダーも含む）の生きた集団、という意味で使っており、以下の様に定義しています。 組織内外のアーキテクトと拡張チームメンバーで構成され、その組織のアーキテクチャのケイパビリティを向上させ、ビジネスおよびテクノロジー戦略を実現する目標を共有する集団。コミュニティは、組織内外の複数の専門家とステークホルダーの集合体であり、センター・オブ・エクセレンスやプロフェッショナリズムなどの表現で呼ばれる場合もある。 積極的な解釈としては、組織内外を含むアーキテクトのコミュニティは、組織のアーキテクチャの善し悪しを決定づける可能性がある事、またこのコミュニティがエンゲージメントモデルに基づく実務上の取り決めや個人のコンピテンシーの強化に繋がる事、ステークホルダーを含むコミュニティの運営に効果的な場合はアーキテクチャそれ自体が組織にとって価値あるものと認識され得る事、等の示唆や効果が紹介されています。その他、成果をあげるためのコミュニティの構造や専門家同志の対立、アーキテクトの適切な配置やメンタリングについても解説されています。 組織の重要性 ピープルモデルでは、アーキテクトの組織について以下の様に紹介しています。 組織とは、一般的にはその組織体の構造とキャリアパス等を定義するものであるが、一方でビジネスと連携しアーキテクトのコミュニティが強化されるなど、よく検討された組織は専門的連携が無いグループよりもはるかに効果的な活動に貢献する。 従来の静的な組織モデルではなく、コミュニティとの連携と活動を伴う組織を顧客体験の強化や価値の流れを創る視点から組織モデルが考察されています。また、グローバルな組織におけるシェアード・サービスモデルやコンサルタント会社の例、パートナー会社との連携の例が紹介されています。 更に、組織に必要とされるケイパビリティを特定するツールとして、アーキテクチャ組織のアセスメント用に開発された「アーキテクチャ・ケイパビリティカード」が紹介されています。アーキテクチャ組織によるエンゲージメントのタッチポイントを記述するキャンバスカードのツールについても記載されており、典型的なIT組織内に設置されたアーキテクトチームの形態とその特徴が解説されています。 ピープルモデルの活用 エンゲージメントモデルを俯瞰すると、このピープルモデルはその根源を支える最も重要な基盤の一つと言えます。従来の一般的な静的な職務上の役割や責任範囲やチーム構成に留まらず、顧客体験や成果に結び付いたアーキテクチャ活動を持続的に可能にするためには必須の基盤と言えます。これを参考に要所に適用する事によってエンゲージメントを持続する基盤としてのピープルモデルの形成が可能となります。その形成と共に個人と組織のケイパビリティの底上げとアーキテクチャ活動を通じて、組織の成果への継続的な貢献への道を開くヒントがここにあるのでは無いでしょうか。 Iasa Globalのホームページでは、BTABoKのコンテンツに関連した解説付きeラーニング用コンテンツLearning Shotsが多数掲載されています。アーキテクト組織について興味を持たれた方は、是非こちらのコンテンツから関連するトピックの解説をご覧下さい。 IasaGlobal People Model / Community他、英語原文ページ： https://www.iasa-japan.org/post/btabok-engagement-model-4-people-model

Iasa 日本支部 理事　塩田 宏治 CITA-A, TOGAF®, DASSM®, SAFe®5 SPC, CBAP®, PgMP® 前回のコラムでは、エンゲージメントモデルの中からアウトカムモデルの紹介がありました。今回は、それに続いてオペレーティングモデルの紹介を行いたいと思います。 オペレーティングモデルは、アーキテクトがアウトカムで示されたような目的を達成するために、実際に実践として取り組む内容になります。図１は、オペレーティングモデルの全体像を示しています。中央の十字になっている領域で４つのアーキテクチャのベースのもとでPlan/Build/Run/Manage Valueのサイクルを回して、ソリューションアーキテクチャを通して価値を実現する構造が記述されています。その周りに、アーキテクトが実行するために必要なオペレーティングモデルの要素が、プロセス、アーティファクト、マネジメント、ピープルの４つの分野に分けながら記述されています。 図１　オペレーティングモデル全体像 現時点でのパブリックレビューとして公開されているオペレーティングモデル要素の目次は、図１の要素名と若干の差異がありますが、以下のような構成となっており、数多くの項目について記述されています。 Product & Project Roadmap Assignment Design Requirements Decisions Deliverables Architecture Description Views and Viewpoints Methodology Innovation Enterprise Engagement Model Annual Activities Architecture Tools Repository 従来のITABoKで示されていたアーキテクトの共通コンピテンシーの５つの柱の中で示されていた要素も多く含まれます。本コラムでは、上記要素の中で、ITABoKの５つの柱の中の要素としては明示的に示されていなかった要素について、簡単に見ていきたいと思います。 Product & Project 従来私たちはプロジェクトを通してプロダクトを作成してきました。その時のフォーカスは、有期のプロジェクトをどのようにマネジメントし、プロダクトをQCDを担保していかに提供していくかでした。しかし近年の不確実性や不透明なビジネス環境では要求を全て最初に定義し一度に全てをリリースする方式ではリスクが大きすぎるようになってきました。継続的にプロダクトを部分的にリリースしてビジネス価値の実現にフォーカスしていくアプローチが増えてきており、こうしたプロダクトマネジメントのオペレーションが有効になってきています。 もう一点重要なことは、ビジネスケイパビリティとの関連です。プロダクトとは、１つまたは複数のビジネスケイパビリティを、顧客に対してどのように提供するかということを示しています。つまりアーキテクチャ観点からすると、プロダクトはHowを意味しているということになります。 Roadmap ロードマップのテクニックは多くの組織で使われています、中期戦略のロードマップやプロダクトのロードマップなど、その計画のホライズンの違いにより、異なるレベルのロードマップが作成されます。典型的に行われているのは、中期計画や年次予算計画の中で、中期以上の時間軸で重要な各イニシアチブがどのようなタイミングで実施されるかを、ガントチャートのようなイメージで示すものです。そして、そこで示されたプログラム／プロジェクトやプロダクトに対して、その単位でのロードマップが作成されます。 注意してほしいのは、ロードマップは具体的な計画ではないということです。Howではなく、何をしたいかというWhatが示されています。またその時間軸は、通常は１年よりも長い中期スパンになります。 Assignment アーキテクチャ・アサインメントとは、アーキテクトチームが顧客や組織とどのように協業して役割を果たしていくかについてのプロセス、手法、ゴールのことをさします。例えば、以下のような観点が含まれます。 アーキテクトがポートフォリオ内のどのイニシアチブに関わっていくか 経験を通して成長し、メンタリングし、成功を確実にするためにどのように協業するか 顧客、PMO、アジャイルチームなどと協業しながら、どのように優先順位付けをするか どのようにロードマップを実現していくか Innovation イノベーションは新しいプロダクトやサービスをイメージするかもしれませんが、それだけではなく、新しい顧客経験、新しいビジネスモデル、新しいオペレーションモデルなど様々な種類が存在します。 アーキテクチャの実践は、組織がとりうるリスクレベル等の範囲の中で、企業のデジタルアドバンテージを活用したイノベーションにおいて、中心的な役割を果たします。 Enterprise Engagement Model Annual Activities この要素では、ビジネス、情報、アプリケーション、インフラストラクチャー、ソリューションの各アーキテクトが年ごとに行う活動の概略が示されています。（本コラム執筆時点では、まだ作成途上のステータス） 例えばビジネスアーキテクトのケースでは、大きく２つのプロセスに分けられています。 年間のビジネスアーキテクチャ・プロセス スコープ特定、ロードマップ修正、ビジネス整合、見積り、優先順位付け、サインオフ プロジェクトの選定と立ち上げプロセス プロジェクトスコーピング、ビジネスケース実現、ビジネスアーキテクチャボード、 ビジネスアーキテクチャからソリューションアーキテクチャへのハンドオフ その他、従来のITABoKの５つの柱の中でも触れられていた以下の内容が含まれています。 Design Requirements Decisions Deliverables Architecture Description Views and Viewpoints Methodology Architecture Tools Repository オペレーティングモデルは、アーキテクトが実際に実践する時の内容を扱っていますので、BTABoK3.0のサイトから詳細を学習してみることによって、是非理解を深めてください。

今回のコラムは前回の第２５回「BTABoKが拓くアーキテクチャ実践の新時代」の続編として、BTABoKの新しいバージョンであるアウトカムモデルのパブリックレビューの記述を見ていきたいと思います。 アウトカムモデル（第２５回コラムより） 円環の外側にあるアウトカムモデルは、ビジネスの全構成員が達成したいことをまとめたものです。これらは、デジタルアドバンテージに関連するビジネス全体の目標です。アウトカムモデルは、デジタルアドバンテージの測定方法であり、アーキテクチャの実践を測定するために使用される成熟度モデルに直接関連しています。各成果は、その影響力のある領域（IBAM領域）に関連します。 アウトカムモデルのパブリックレビューの目次は以下のような構成となっており、数多くの項目について記述されています。 Ecosystem Engagement Journey Strategy Agility Business Capabilities Culture Collaboration Automation Imagine the Digital Customer Digital Business Model Digital Employee Empowerment Operational Excellence Velocity Simplicity これらのうちEcosystem（エコシステム）は、ITABoKでは論述がなく、BTABoKで真っ先に論ぜられている内容でもあります。BTABoKを理解するための前提とも言えますので、当コラムでは、この記述を翻訳し要約するとともに、筆者なりの解釈を加えていきたいと思います。 BTABoKでは「エコシステム」について、以下のように捉えています。 エコシステムとは（BTABoKから抜粋） エコシステムは、組織が参加し、相互作用し、エコシステム内の他の関係者から影響を受ける外部環境を表します。エコシステムの代表的な関係者は以下の通りです。 サプライヤー 顧客 競合他社 政府機関 パートナー エコシステムは、設計されて作られることもあれば、イノベーションの結果として自然に進化・成長することもあります。エコシステムは、適応性、自己組織化、拡張性があり、疎結合で、エコシステム内の関係者の明確なコントロールはありません。本来、生態系は複雑な無秩序システムであり、内外の力によって時間とともに変化します。 エコシステム内の関係者の相互作用やコラボレーションは、機会を提供する価値の流れを作り出します。価値が増加するとエコシステムは成長し、価値が減少するとエコシステムは後退します。この結果、エコシステムはより価値の高い別のエコシステムに追い越されるでしょう。 このように、BTABoKでは、エコシステムの関係者が変化を起こし、価値を増減させることでエコシステムに影響を与えていることについて注目しており、価値を高めることがエコシステムの成長につながることであると強調しています。そのうえで、アーキテクトがエコシステムを理解することの重要性を以下のように述べています。 アーキテクトは、機会を発見し、リスクを軽減するためには、エコシステムを理解することが重要です。組織がどのように顧客に価値を提供しているかを理解することは、イノベーションとオペレーションの最適化のための基礎となります。組織がエコシステムと統合するために行った戦略や決定は、アーキテクチャを形成する上で重要な要素となります。エコシステムを軽視するアーキテクトは、アーキテクチャを開発する際に制約や機会を見逃すリスクがあります。 ここでは、アーキテクチャを開発する上で、エコシステムを軽視できないことを訴えており、アーキテクトは組織の価値の提供についての理解が欠かせないと考えられます。だからこそ、エコシステムを理解することは、以下のような効果があるのだと述べています。 機会を最大化し、リスクを低減する エコシステム内の関係を理解することで、エコシステム内の事象がもたらすマイナス効果、プラス効果を予測するために必要な知識を得ることができます。これにより、組織は機会を迅速に利用することができ、また、リスクを特定し、それを軽減することができます。 では、エコシステムを理解するためにはどうすれば良いのでしょう？ BTABoKではカスタマージャーニーの理解の必要性を述べています。それは、顧客への価値の提供の重要性にあることに他ならないことでもあります。 カスタマージャーニーを理解する エコシステムを理解するためには、組織外部の関係者との顧客とのやり取りを含むカスタマージャーニーを理解することが重要です。これにより、潜在的な協力関係の基礎が得られ、また、顧客により大きな価値を提供するために当事者がどのように協力できるかについて理解することができます。 カスタマージャーニーを理解し、さらに、顧客視点からエコシステムを理解することで、顧客にとってより良い体験を検討することが可能であるとしています。 顧客視点でのエコシステム 顧客の視点からエコシステムを理解することで、アーキテクトは、異なる当事者のサービスを接続する機会や、顧客にとってより良い体験と付加価値を提供するサービスを作成する機会を検討することができます。 また、エコシステムは大きなイノベーションから生まれることもあります。市場や産業を変化させたり、創造したりする破壊的なサービスや製品です。例えば、スマートフォンの登場がそうです。これらのイノベーションは、顧客中心の視点を持っていることが多く、エコシステムを変化させたり、生み出したりした考え方の例として、次のようなものがあります。 ヘンリー・フォード（Ford）は「誰もが自動車を持てるようにするにはどうしたらいいか」と問いかけた。 スティーブ・ジョブズ（アップル）は、「何があれば、誰もがコンピュータを持てるようになるか」と問いかけた。 盛田昭夫（ソニー、ウォークマン）は「何があれば若者が自分の音楽を持てるようになるか」と問いかけた。 ジェフ・ベゾス（アマゾン）「何があれば、人々はオンラインで買い物をするようになるだろうか」。 しかしながら、現実は顧客視点だけでは、エコシステムをデザインしたり、変化に対応したりできません。BTABoKではアーキテクトの考慮すべき視点は、顧客からは見えない当事者にも目を向けるべきであるとしています。。 組織から見たエコシステム 顧客の視点は、顧客の目を通してエコシステムを見るが、多くの組織は、顧客からは見えない当事者と関係を持っています。これらは、組織が価値を提供するために必要なビジネスサービスや製品を提供するエコシステム内の関係者であり、事業運営に不可欠な存在である場合もあります。 ビジネスを継続的に運営し、オペレーションと価値提供を最適化するために、アーキテクトが考慮すべき重要な視点です。エコシステムの変化は、組織が製品やサービスを提供する能力に大きな影響を与える可能性があり、その結果、アーキテクチャに大きな変化をもたらすことになります。 エコシステムの変化がアーキテクチャへ影響を与える具体的な例としては、まさに、コロナ禍の現在において、顕著に表れているかと思います。 テレワークにおける営業活動などの変化にはじまり、製品戦略やサプライチェーンの見直しが必要となり、ビジネスアーキテクチャの改革を迫られており、アーキテクトの出番は益々求められるようになっています。 では、変化していくエコシステムをどのように捉えれば、良いのでしょう。BTABoKではエコシステムの分析をエコシステムマップキャンパスを用いることにより、「エコシステム内の真に重要な関係者に注意を向けることができる」としています。 エコシステムの分析 以下は、エコシステムマップキャンバスです。これは、特定のSubjectを取り巻く様々な関係者の宇宙のようなエコシステムを示しています。 エコシステムは様々な視点から見ることができ、各組織はエコシステムに対して独自の利害関係を持つことになります。したがって、エコシステムを分析するために使用されるモデルは柔軟性があり、異なるタイプの組織や異なるタイプの顧客に対して使用することができる必要があります。エコシステムマップキャンバスは、エコシステムを特定のSubjectの周りに組織されたさまざまな関係者の宇宙のように示しています。 尚、詳細は「Analyzing the Ecosystem」の項の翻訳を別添しますので、「第２６回コラムEngagementModel（１）別紙Analyzing the Ecosystem翻訳」を参照ください。 さらに、BTABoKではこのエコシステムマップの活用方法として、エコシステムマップと戦略の組み合わせを提案しています。 エコシステムマップと戦略の組み合わせ エコシステムマップは、組織の戦略立案で用いられる手法と組み合わせることが可能です。戦略立案でよく使われる手法に、PESTELとSWOTがあります。これら2つの手法のアウトプットは、エコシステムのマップに使用することができます。これらは、PESTELのカテゴリーをDimensionsとして、SWOTのカテゴリーをAspectsとして示すことで、エコシステム上で組み合わせることができます。 戦略立案手法における分析結果をエコシステムマップに使うことが出来るとしています。また、エコシステムマップにより、エコシステム内の関係者とその関係を把握することが、アーキテクチャを決定し、ひいてはエコシステムに影響を与えるとまで指摘しています。 エコシステム内の関係者とその関係を把握することは、重要なビジネスやアーキテクチャの意思決定に役立ち、ひいてはエコシステムに影響を与えることができます。また、規制の変更、市場の変動、新しい法的要件などのイベントの原因と結果を理解することにも役立ちます。これらの事象は、エコシステム内のさまざまな関係者にプラスにもマイナスにも作用します。エコシステムにおける潜在的な影響を評価し、行動を起こす能力は、組織の競争優位につながります。 以上、今回新たになったBTABoKのアウトカムモデルに関するエコシステムについての記述を概観してきました。 原文は、IasaGlobal のホームページに掲載されており、そちらを参照ください。（文末にリンクを記載）Iasa日本支部では、これらを日本語訳して、Iasa日本支部の会員等の皆様にご提供する予定です。 また、BTABoKの理解を深めるためにコミュニティ活動の一環として、「ラウンドテーブル」と称して勉強会を開催しています。 これらの予定はIasa日本支部の支部のホームページに掲載しますので、参照ください。よろしくお願いします。 ◆アウトカムモデルのエコシステムの項 https://itabok.iasaglobal.org/itabok3_0-2/digital-outcome-model/ecosystem/

Analyzing the Ecosystem（翻訳） エコシステムは様々な視点から見ることができ、各組織はエコシステムに対して独自の関心を持っていることでしょう。したがって、エコシステムを分析するために使用するモデルは、さまざまなタイプの組織やさまざまなタイプの顧客に適合するように、柔軟でなければなりません。 以下は、エコシステムマップキャンバスです。これは、特定のSubjectを取り巻く様々な関係者の宇宙のようなエコシステムを示しています。 エコシステマップは、4つのコンセプトから構成されています。 サブジェクト ： これは、例えば顧客、組織、または組織の一部など、エコシステムに関心を持つ側の視点である。 パーティ：実際の企業、顧客、サプライヤーなど、エコシステムの中で活動するさまざまな関係者です。 ディメンジョン ： 産業や市場分野など、共通の特性に基づいて当事者をグループ化したもの。 アスペクト： これは図の輪の部分であり、例えば、提供者、消費者、パートナーなど、サブジェクトが当事者をどのように認識しているかを示しています。リングは、最も内側のリングから順に関係の強さを示すために使用することができる。 エコシステムは、顧客や組織をサブジェクトにして、顧客の視点、あるいは組織の視点から分析することができます。分析を始めるには、まずサブジェクトを選択する必要があります。 エコシステムについてどれだけの情報が知られているかによって、このキャンバスで作業するいくつかの異なる方法があります。マップに当事者を配置する前に、アスペクトを決定するのは良い方法です。アスペクトこそが、サブジェクトにとってエコシステムを意味のあるものにし、どのパーティをエコシステムに表示するかを決定するのです。アスペクトの良い出発点は、次のとおりです。 これらの側面は完全なものではなく、パーティが供給者と消費者の両方になったり、必須と望ましいサービスを提供したりする可能性があります。パーティを最も適したアスペクトに配置するのは、参加者の経験次第です。 エコシステムマップにパーティを配置する前にディメンジョンを追加することも、エコシステムにパーティを追加してからディメンジョンにグループ化することも可能です。ディメンジョンは、パーティに共通する属性であり、分析の目的によって取り組み方が一部異なる場合がある。例えば、特定のディメンジョンのパーティを見つけるため、あるいは既存のパーティをディメンジョンにマッピングするためなどです。組織と顧客の両方の視点からは、例えば、産業部門と連携することが良い出発点となります。 小売 製造業 政府機関 ホスピタリティ 物流 輸送 ディメンジョンは、その組織が扱うビジネスの種類や、顧客のシナリオに特化したものになると思われます。 アスペクトやディメンジョンの場合、使用するディメンジョンやアスペクトの数を決めるのは参加者次第である。ただし、多数のアスペクトやディメンジョンをマッピングすると複雑なモデルになってしまうので、1つのマップに使用するアスペクト（最大4.）とディメンジョン（最大8）の数を限定し、必要に応じて異なる視点からのマップを複数作成するとよいです。 パーティは、アスペクトとディメンジョンに配置されます。パーティは、顧客または組織が相互作用する実際の実体です。これらは、企業、政府機関、NGO、または利益団体であるかもしれません。 エコシステムをマッピングし、分析することで、関係、サービス、機会に対する貴重な洞察を得ることができます。それは、コラボレーションの可能性を強調し、エコシステム内の真に重要な関係者に注意を向けることができます。 エコシステムマップキャンバスをさらに説明するために、以下の例では、顧客の視点と組織の視点からのマップを示しています。 ティンクルマンのお客様 次の例では、架空の会社「ティンクルマン・コーヒー・ロースターズ」を使い、対象者はティンクルマン・コーヒー・ショップの顧客であることを想定しています。このエコシステムでは、顧客にとって当事者がどれだけ重要であるかを示すために、essential、valued、desirableというアスペクトが使用されます。顧客がティンクルマンコーヒーを飲みたいときに、サービスや製品を提供するエコシステムのいくつかのディメンジョンが特定されました。 上の地図では、タクシー会社「TAXI-HI R」を利用してコーヒーショップまで行くお客様や、「DELIVER 2 U」というオーダー＆コレクト会社でコーヒーを自宅まで届けてもらうお客様がいることに注目してください。また、ABC大学の学生は、学業中にティンクルマンコーヒーを利用するため、キャンパスの近くにあることが望ましいと考えます。近くのスーパーホテルの顧客は、会議や打ち合わせのためにコーヒーを注文することが多く、複合施設「シネマ1」に映画を見に行く途中でコーヒーを手にする顧客もいます。この例では、ティンクルマンがエコシステムの他の当事者と協力することによって、顧客への価値を高める機会が数多くあることがわかります。 ティンクルマン・カンパニー 次の例では、「ティンクルマン・コーヒー・ロースターズ」社をサブジェクトにしています。このエコシステムでは、ティンクルマンと関係者の関係を示すために、パートナー、プロデューサー、コンシューマーというアスペクトが使用されています。エコシステムではいくつかのディメンションが特定されており、それらはおそらくビジネスのタイプを表していますが、ティンクルマンにとって関心のある能力を表している可能性もあります。 このエコシステムの中で、コーヒー豆を提供するBIG BEANS、焙煎施設からコーヒーショップまでの物流を担うLBN GOODS、法務をサポートするHOLBY PARTNERSなど、複数の企業とパートナーシップを結んでいるのです。 人材派遣会社のKOPE HRは、ティンクルマンにバリスタの人材紹介サービスを定期的に提供している。タクシーハイRは、ティンクルマンのスタッフと顧客のためにタクシー予約サービスを提供し、XPRESSはリクエストベースでロジスティクスサービスを提供しています。スーパーホテルは、ティンクルマンコーヒーの消費者であり、会議のために利用されています。 この例では、組織の運営を改善する機会があります。例えば、KOPE HRとパートナーシップを組み、採用活動を行ったり、スーパーホテルで行われる会議でのコーヒー注文を自動化したりすることができます。 エコシステムマップと戦略の組み合わせ エコシステムマップは、組織の戦略立案で用いられる手法と組み合わせることが可能です。戦略立案でよく使われる手法に、PESTELとSWOTがあります。これら2つの手法のアウトプットは、エコシステムのマップに使用することができます。これらは、PESTELのカテゴリーをディメンジョンとして、SWOTのカテゴリーをアスペクトとして示すために、生態系上で組み合わせることができます。例えば、環境NGOからの圧力は脅威とみなされ、パートナーからの新技術はチャンスとみなされるかもしれません。 これにより、戦略的な観点からエコシステムを検討します。 エコシステムに影響を与える エコシステムを理解することは、組織がエコシステムを自分たちのために、そして顧客のために利用するのに役立ちます。例えば、戦略的提携やパートナーシップの構築、新規市場へのジョイントベンチャーなど、エコシステムを最大限に活用するために、組織はビジネスモデルを適応させることができます。 デジタル技術の進歩は、プラットフォームビジネスモデルを最前線に押し上げました。直線的なサプライチェーンではなく、複数の関係者間で価値の交換を促進するプラットフォームが提供されます。これらの関係者は、生産者であったり消費者であったりします。プラットフォームビジネスモデルを採用している企業の例としては、AirBnB、Amazon、AliBabaなどがあります。 エコシステム内の関係者とその関係を把握することは、重要なビジネスや建築の意思決定に役立ち、ひいてはエコシステムに影響を与えることができます。また、規制の変更、市場の変動、新しい法的要件などのイベントの原因と結果を理解することにも役立ちます。これらの事象は、エコシステム内のさまざまな関係者にプラスにもマイナスにも作用します。エコシステムにおける潜在的な影響を評価し、行動を起こす能力は、組織の競争優位につながります。 www.DeepL.com/Translatorで翻訳したものを修正しました。 （2022年1月30日　Iasa日本支部　理事　西山達也）

振り返ると、ここ数年で皆様の生活も大きく変わったかと思います。まず何よりも、長引くコロナ禍。しかし、その大変さを少しでも軽減してくれたのはテクノロジーでした。テクノロジーに支えられた研究は、記録的な速さでワクチンの発見、供給、製造を可能にし、同時に、他の方法では不可能な自由を私たちに与えてくれました。オンラインやチャットによるコミュニティは、私たちの孤立感を和らげてくれました。数え上げればきりがありません。このことは、テクノロジーがもはや裏方の仕事ではないことを世界に示したと言えるでしょう。テクノロジーは、人々、実際の顧客、社会、世界にとって、最前線かつ中心的な存在となっています。一方で、情報の絶対量の増大、スピードの変化、新しい環境への対応といったようにテクノロジーは複雑化しています。企業にとっても大きな機会とリスクの両方をもたらすことはあらためて言うまでもないでしょう。かつて、これほど「ビジネスのためのテクノロジーの戦略家」が求められる時代はなかったと思います。そうしたニーズに対応し、あらゆるアーキテクトが誇りを持ってその専門性を発揮するために、Iasaはできる限りのことを行ってまいりました。その一つの成果が、BTABoK(Business Technology Architecture Body of Knowledge)です。本コラムでは、BTABoKの概略を紹介したいと思います。 1. ITABoKからBTABoKへ Iasa GlobalのCEOであるPaul Preissは、BTABoKの着想を得た時のことをこう述懐します。「何年か前、ルーマニアで親友と一緒に会議で話していたとき、あるアイデアが浮かんだのです。『アーキテクチャの概念を結びつけるものがない。自分の仕事を結びつけ、それを採用し、他のアーキテクトと共有する方法が必要だ』。既に世の中には多くのフレームワークに満ち溢れていました。例えば、エンタープライズアーキテクチャの世界ではTOGAFがあります。エンタープライズアジャイルの世界ではSAFeがあります。ビジネスアナリシスの世界ではBABoKがあります。それぞれの世界のアーキテクトがこうしたフレームワークを使って仕事をしています。それぞれは有用で素晴らしいものですが、それらを繋ぐものはまだありません。それぞれのアーキテクトが協業するためのものが必要です。ただ、フレームワークをつなげるためにフレームワークを作っても、別のフレームワークができて問題が悪化するだけです。その時、どういうものが必要となるかの最初のイメージが私の頭に浮かんだのです。段階的に採用することができる、真に前向きでつながりのある一連の概念をまとめ、知識体系という形をとることができると気づいた瞬間でした」 これがITABoKとして最初にまとめられたものでした。その目指したことは、共通の知識体系と言語を創出し、ITアーキテクトの専門職を正式なものとすることでした。プロセスや方法論の標準ではなく人々のフレームワークと位置づけ、ITアーキテクトの育成にフォーカスするものでした。それが今、BTABoKとして進化しました。下図をご覧ください。ITABoKとBTABoKの主な変化点をあらわしています。大幅に拡張されたことがわかるでしょう。 その進化のポイントとして、ここでは２つ取り上げてみましょう。 ・エンゲージメントモデルベースへの進化 重要なことは、様々なタイプのアーキテクトを分断するのではなく結びつけることです。さらに重要なことは、アーキテクトと組織の全ての人々とを結びつけることです。これをエンゲージメントと呼んでいます。BTABoKの大きな進化は、ITアーキテクトのケイパビリティモデルを包含した、より広いエンゲージメントモデルベースへと進化したということです。その中心にあるのが「価値提供にフォーカスする」ということです。あらゆるアーキテクトはビジネス価値の提供にフォーカスすべきというのが、BTABoKのメッセージです。それはデジタルアドバンテージという言葉で表現されています。 ・デジタルアドバンテージの追求 デジタルトランスフォーメーションとは、何かに変わることです。なぜ、トランスフォーメーションすることが必要なのでしょうか？BTABoKが主眼に置くのはそこではありません。主要ポイントはトランスフォーメーションから得られる価値である、というのがBTABoKのメッセージです。デジタルアドバンテージとは、組織がデジタルトランスフォーメーションによって実現したいことです。アーキテクチャの取り組みがここにフォーカスすることで、変化を測定することだけに重点が置かれることはなくなり、組織の中で何が変わったのか、どれだけ早く変化しているのかがより重視されるようになります。BTABoKの目標は、成果重視の測定可能なデジタル投資に特化した専門家としてのアーキテクトコミュニティを作ることです。 2. BTABoKの核心：エンゲージメントモデル 下に示すナビゲーションはBTABoKの全体像を表現しており、IasaGlobalのサイトでも公開しています。中央にあるエンゲージメントモデルが主要なダイアグラムで、それに関連する成熟度モデル、コンピテンシーモデル、トピックエリア、構造化キャンバスが横に並べられています。ここでは、エンゲージメントモデルの概略を順番に見ていきましょう。 IBAM BTABoK全体では、Digital Advantageを4つの領域であらわし、そこで成果を上げることに重点を置いています。デジタルな顧客を想像し(Image)、デジタルなビジネスになり(Become)、デジタルな従業員を実現し(Achieve)、デジタルなオペレーションを最大化する(Maximize)ということです。その領域につながりのある概念がアイコンで配置されています。 継続的なイベント（ダイヤモンド） BTABoKでは、革新(Innovate)、変革(Transform)、活用(Utilize)、測定(Measure)の各ダイヤモンドを、組織内外の継続的なイベントや活動として扱っています。それは企業全体、および業界、アナリスト、パートナー、顧客などの外部で継続的に起こっています。アーキテクトも組織もそれを制御できないですが、利用しできるだけ早く活用するか、理解し可能な限り最大化することが望まれます。 アウトカムモデル 円環の外側にあるアウトカムモデルは、ビジネスの全構成員が達成したいことをまとめたものです。これらは、デジタルアドバンテージに関連するビジネス全体の目標です。アウトカムモデルは、デジタルアドバンテージの測定方法であり、アーキテクチャの実践を測定するために使用される成熟度モデルに直接関連しています。各成果は、その影響力のある領域（IBAM領域）に関連します。 オペレーティングモデル 円環の1番目にあたるのがオペレーティングモデルです。ここに含まれるのは、アーキテクチャの実践における主要な活動、技術、ツール、手法です。ロードマップ、要件、意思決定など、アーキテクトがIBAMやデジタルアドバンテージを実現するために使用する手法やテクニックとなります。 バリューモデル 円環の2番目がバリューモデルです。これは、アーキテクチャ活動における品質、価値、成果を理解するための手法から名づけられました。これは、オペレーティングモデルとピープルモデルをつなぐものです。バリューモデルは、ビジネスとエンジニアリングの両方の用語で成果を測定するという共通の概念をもたらします。 ピープルモデル 3番目のピープルモデルとは、主にアーキテクト自身を扱うモデルです。これは、アーキテクト個人の能力（専門性を含む）に関する知識体系であるコンピテンシーモデルとは異なりますが、この2つの知識体系を結びつけるのは「ピープルモデル」です。アーキテクトの組織化方法、役割の説明、コミュニティの方法、大規模な領域へと成長するための貴重なツールも含まれています。 そして最後に、エンゲージメントモデルの中核に配置されているのがアーキテクチャの実践です。 3. 実践的アーキテクトを目指して BTABoK の基本的なスタンスは、エンタープライズアーキテクチャとは肩書や名ばかりの職種が幅を利かせるような権威的な専属組織のものではないということです。そうではなく、実際にはジュニアからシニアまでのすべてのアーキテクトの努力の結集である、ということです。そして、技術戦略の実現に主体的に関わるために、自身のコンピテンシーやスキルを適用できなければなりません。真のプロフェッショナルであり続けるためのガイドラインを1つあげるとするなら、コアスキルと最新のアプローチは実践を通して常に維持されなければならないということです。エンゲージメントモデルを支えるのは、真のプロフェッショナルとしての卓越した実践力であるということが言えると考えます。 Iasa日本支部は、日本国内でも今以上に実践力を備えたアーキテクトが認知され、活躍できるような業界にしたいと考えています。また、多くの方々からIasa日本支部への期待として、BTABoKを広く啓蒙することを求められています。今年はこうしたことに応えていくため、まずは本コラムシリーズを通してBTABoKをわかりやすく解説していく予定です。また、BTABoKの日本語化と解説セミナーの準備も進めていきたいと考えています。今後のIasa日本支部の活動へのご参加、ご協力をよろしくお願いいたします。

来たる2021年11月5日に、「DX時代のエンタープライズアーキテクチャ」と題してIasa日本支部アニュアルカンファレンスを開催します。10回目となる本カンファレンスは、コロナ禍もあり前年に引き続きオンラインとなりますが、国内外から有識者をお招きしてデジタル・トランスフォーメーション(DX)の時代に即した最新のトピックが学べる機会をご提供します。 本カンファレンスの講演タイトルは、以下のラインナップとなります。 なぜEAがDXを加速するのか　〜　DXの本質とEAによる推進手法　〜 DX時代におけるCX/UXの重要性と事例紹介　〜　良いCX/UX、悪いCX/UXとは何か、その違いは利用者中心であるか否かに尽きる　〜 ‘BTABoK’ はアーキテクチャの実践にどの様に変化をもたらすか？　〜　ステークホルダー主導のアーキテクチャの実践のフレームワーク BTABoK ここで目を引くのは、CX/UXというキーワードでしょう。いまやCX/UXという言葉を目にしない日はありませんが、それがEA(エンタープライズアーキテクチャ)とどう関係するのか？とお思いの方もおられるでしょう。一般的にEAの文脈でCX/UXが語られることは、まだまだ少ないようです。しかしDX時代と言われる今だからこそ、その関係は強まっていかなければならないと考えます。ということで、本コラムで考察していきたいと思います。 1. UX (ユーザーエクスペリエンス) とは UXと類似する言葉でUIおよびユーザービリティデザインがあります。似て非なる言葉ですが、その概念をしっかりと説明できる人は少ないようです。そしてもう一つ「CX (顧客体験)」という概念があり、どんどんわかりにくい状況となっています。最初にまず、UXとUIの違いを考えてみます。UIとは、ユーザーインターフェース (User Interface) の略で、Interfaceは「接点」を意味します。つまりUIは、ユーザーと製品・サービスの接点、つまり「ユーザーに見えて触れるすべての場所」を指しています。 例えばWebサイトであれば、画面デザインや、ボタン、遷移テキストなどがUIに相当します。そして、ユーザービリティデザインとは、ユーザーが操作を間違えたりつまずいたり、または、やるべきことを誤解しないように、製品・サービスの品質を改善してその機能を十分利用してもらえるようにする設計行為といえます。一方、UXはユーザーの「体験」そのものを指します。とはいえ、UXという概念に定まった定義はなく、様々な専門分野や立場ごとで異なった意味で使われています。ここでは、その概念を考えるうえでUX白書を見てみます。これはUXの専門家がその概念を議論しまとめたものです。その抜粋を以下に記載します。 UXには以下の特徴があります。 UXは一般的な概念としての経験の一部です。UXはシステムを通じた経験であるため、より限定的です UXはシステムとの出会いを含みます。積極的利用、個人的利用だけでなく、例えば他者がシステムを利用するのを観察するなど、より受動的にシステムと関わることも含みます UXはある個人に固有のものです UXは過去の経験とそれに基づく期待に影響されます UXは社会的、文化的な文脈に根ざしています それでは、UXではないものとはどういったものでしょうか? UXは人間に焦点を当てており、技術主導のものではありません UXはあるシステムを単独で利用する個人だけに関するものではありません ユーザーが感じるユーザビリティは UX全体に影響を与える典型的な側面ではありますが、ユーザビリティとUXは同義ではありません UXデザインは、インターフェースデザインより広範囲なものです UXはブランド経験・消費者経験・顧客経験とお互いに影響を与え合うものの、それらの概念と同義ではありません 「ユーザエクスペリエンス」という言葉は「経験」よりも適用範囲が狭いですが、ユーザエクスペリエンスに関するいくつかの概念を包括した用語です。 引用：UX白書(日本語訳版), http://site.hcdvalue.org/docs つまり、UIはユーザーと製品・サービスとの「接点」を扱い、UXはユーザーの内的で主観的な「経験」を扱うものという違いがあります。そして、UXのデザインは製品・サービスを提供するうえで考慮すべき重要事項となってきました。その理由としては、テクノロジーの発達に伴う情報流通の変化や、ユーザーの抱く価値観の変化などがあげられるでしょう。大量のモノがあふれ、どのサービス・製品も似たような機能を持つようになった現在、サービス・製品を差別化できる要因が「ブランドイメージ」や「体験」です。この状況はBtoC業界で顕著ですが、BtoB業界でも大きな関心ごととなっています。一昔ならば、企業同士の取引を中心に考えておれば良かったかも知れませんが、DX時代はその先の「真のユーザー」にターゲティングしていくことが求められるからです。つまり、多くの企業にとってUXに取り組むことは、重要なビジネス命題となってきたといえます。 2. CX（カスタマーエクスペリエンス）とは 次に、CXを考えてみましょう。ちなみに、CXとUXの境界線は曖昧です。しかし、あえてその違いを強調するなら、CXとは「顧客 (＝カスタマー) としてのあらゆる体験」を指す概念といえるでしょう。つまり、サービス・製品を認識してから購入を検討、購入した場合はそれを使用するという一連の流れのすべてにおける体験のことを意味します。一般的に、カスタマーとは「サービス・製品に関わる全ターゲット」を指します。一方で、ユーザーは「特定のサービス・製品の利用者」を指します。そういう意味で、カスタマーのほうがユーザーより広範囲となり、よってCXはUXを包含する概念と見ることもできます。ただ、CX/UXの概念については様々な考え方があって語り尽くせないので、ここではその一つを示すに留めます。 引用：UXデザインとCXデザインの違いとそれぞれの役割, https://blog.btrax.com/jp/ux-cx/ ここで理解いただきたいのは、より良いCXを提供するにはデザイナー視点だけでなく、ビジネスの仕組みやプロセスをデザインする視点が必要になるということです。それに加えて、あらゆるターゲットとつながっていくことから、高度なセキュリティや新しいデバイスへの対応といったテクノロジー面や、それらターゲットから収集したデータをどう利活用していくかといった情報アーキテクチャ面でのデザインが求められます。ビジネス、テクノロジー、そして体験、これらはつながっているということです。つまり、真のCXは「ビジネス」「テクノロジー」「UX (顧客視点)」の重なるところに生まれるといえるでしょう。 3. エンタープライズアーキテクチャとCX／UX あらゆる企業にとって、CX/UXが重要なケイパビリティとなってきたという「意識」は広がってきている一方で、効果的な実践に落とし込めている組織は少ないのが現状です。その要因は大きく2つあります。1つは、現場の担当者レベルがCX/UXの意義や手法を十分に理解できていないことがあげられます。これについては、メディアで多くの実践事例が露出してきていることが好材料です。2つ目は、全社的にCX/UXに取り組める体制になっていないことです。担当者レベルのリテラシーは上がってきている一方で、ビジネスやテクノロジー観点との連携と、それを推進する人材の育成はこれからといえます。では、どのような人材と体制が必要でしょうか。2007年に経済産業省が「今後のIT人材像」を公開し、変革をリードする人材として「基本戦略系人材」「ソリューション系人材」「クリエーション系人材」をあげました。 「基本戦略系」は、“ITを活用したビジネス価値の増大をリードする人材”で、主にストラテジストが相当します。「ソリューション系」は、“ビジネス戦略に対して最適なシステムをデザインする人材”で、アーキテクトをはじめプロジェクトマネジャーやテクニカルスペシャリスト等に相当します。最後の「クリエーション系」は、“社会・経済にイノベーションをもたらす人材”であり、クリエータやデザイナーが含まれるでしょう。なお、ビジネスとテクノロジーのギャップをなくしていくことの重要性の認識は、既に広く認知されているところです。結果として、戦略人材とソリューション人材の領域は重なり、協調する機運は高まっています。近年のエンタープライズアーキテクチャ（EA）という文脈でも、「基本戦略系人材」と「ソリューション系人材」の溝は埋まりつつあると感じています。これが、EAというパラダイムの意義です。一方で、「クリエーション系人材」とのギャップは未だ手つかずではないでしょうか。しかし、DX時代ではこうした人材を育てるとともに、繋がりあうような組織が求められます。私たちIasa日本支部は、個人のスキル育成について積極的に取り組んできましたが、今後はより一層CX/UX領域とのコラボレーションも推進していきたいと考えています。高いケイパビリティを備えた個人を育て、さらには彼らがギャップをなく協調できる、そういうフレームワークへトランスフォームすることこそが、DX時代のエンタープライズアーキテクチャの一つの姿だと考えます。いかがでしょうか。ぜひ、皆様のお考えをお聞かせいただければと思います。 4. 終わりに 本コラムでは、CX/UXを取り上げました。私たちアーキテクトは、今後ビジネス領域のみならず、デザイン領域の専門家とより一層協調していくということをお伝えしました。そのためには、それぞれの専門領域に閉じるのではなく、お互いが対話し理解し合うことが大切です。まず、その第一歩を踏み出しましょう。Iasa日本支部カンファレンス2021では、エスディーテック株式会社代表取締役の川端様をお招きし、ITアーキテクトとCX/UXデザイナーがチームで取り組む必要性について解説いただきます。是非この機会にご参加頂き、共に「DX時代のエンタープライズアーキテクチャ」に思いを馳せていただければ幸いです。

今回は去る4月30日から5月1日にかけて行われたIasaグローバルのオンライン・イベント「April Web Summit」の概要をお伝えします。Iasa日本支部松井理事との連携により、全24セッション中、21のプレゼンテーション・デッキが、サイボウズのファイル管理上の共有資料として会員の皆さんにシェアされていますが、お忙しい皆様に代わり、私のほうでセッション紹介文やプレゼンデッキをざっと流し読みしましたので、「どんな話が有ったか」をざっくりとご紹介したいと思います。 なお、7月30日から31日にかけて同様のイベントが予定されていますので、このコラムを読んでご関心を持たれた方はイベント紹介ページ https://iasaglobal.org/Public/events/july-web-summit.aspx もぜひ覗いてみて下さい。ちなみにイベントの名称はこの回からThe Business Innovation Leadership and Technology (BILT)となるそうです。 1. モダンEA: 最前線からの教訓 (Modern EA: Lessons from the front lines) Iasa Globalのメディアチャネルである”Architecture & Governance Magazine”の編集者お二人によるプレゼンです。タイトルの「最前線からの教訓」を一部ご紹介します。 EAはコーディネートするがトランスフォーメーションやイノベーションのオーナーシップを主張しようとはしない 戦略的方向性の充足に必要なケイパビリティの変化を特定せよ コンテンツこそキングである！各オーディエンスにそれぞれ特化したビューを作成せよ 効果的なエンタープライズ・アーキテクチャ（EA）プログラムを確立するためのアプローチは一つではない 各企業とその文化とニーズがアプローチを決定する。タイミングが全て! 企業の急速な変化に対応するために、アダプティブEAのコンセプトが再浮上してきた “Architecture & Governance Magazine”では投稿も募集しています。まずはこちらをご覧になってみて下さい。面白いコンテンツが見つかるかも知れません (少し古い記事も混じっていますが)。 2. ガバナンス・リスク・コンプライアンス (GRC) とサイバーセキュリティ：ベスト・プラクティス 　(Governance, Risk and Compliance (GRC) and Cybersecurity: Best Practices) LAにある“Framework Security”という会社のプレゼンです。セールス・マテリアルとして一般的な内容。ITABoKもセキュリティについてのコンテンツはまだまだなので致し方ありませんが。 3. レジリエントでサスティナブルな組織構築のためのビジネス・アーキテクチャの活用 (Leveraging Business Architecture to Build a Resilient and Sustainable Organization) BAのビッグネームであるWhynde Kuehnのプレゼンです。生物学のアカデミック・バックグラウンドをお持ちで、自然環境との対比から組織のBAを語る趣向です。自然から組織は何を学ぶべきか、BAはそれにどう関われば良いのか、なかなか鋭い見解をわかりやすく説明していてお勧めです。個人的にはBAの役割の一つに「共通語彙 (common vocabulary) をつくる」ことを挙げている点が気に入りました。最後のスライドで、著名な建築家バックミンスター・フラーの箴言が紹介されていますが、EAとして持つべきマインドセットそのものだと思います。 4. COVID-19時代のEAへの認識と今後の道筋 (Perception of EA & Way Ahead in Age of COVID-19) TOGAFのコントリビューターであるSteve Elseのプレゼンです。タイトルにCOVID-19と入ってはいますが、EAの社会的な認知度の低さに対する嘆きが大半を占めています。但しここで彼がEAと呼んでいるのは”Everything Architecture”で、政府や産業界のトップがアーキテクチャ的なアプローチを理解していれば、様々なビジネス主体が異なる時間軸で協業して問題解決出来ただろう、という、よりハイレベルな課題認識です。もちろんその対策も提言されていて、大学院レベルでのカリキュラム、CxOのオリエンテーション・プログラム、ITスタッフのワークショップなどにEAを含めること、などが挙げられています。ひょっとすると日本ではエンタープライズ (企業) としてのEAはもうスキップして、最初から”Everything Architecture”あるいは”Eco-System Architecture”としてプロモートした方が良いのかもしれないと感じました。 5. イノベーションとレジリエンスのためのモダンEA 　(Modern EA for Innovation and Resilience) おなじみIasa GlobalのPaul Preiss会長のプレゼンです。フォーカスはアーキテクトのコンピテンシーやエンゲージメントモデルで、つまり同じEAでもヒト、またはプロフェッションの方の話題を取り上げています。アーキテクトとエンジニアとが、役割のオーバーラップを通じて生み出す健全な緊張感が、DXには欠かせない、といったことが述べられています。一つ前のSteve Elseのプレゼン同様、やはりEAでは繋がりと協力で全体価値を発揮することが何より重視されていることが分かります。余談ですが、Paulは”chef of still”とか”skin in the game”といった難しい表現を使いがちで、彼の文書は翻訳が大変です。 6. あなたの統合戦略 (インテグレーション・ストラテジー) はなぜ真のデジタル・アドバンテージ獲得に失敗するのか 　(Why your Integration Strategy will Fail to Achieve Real Digital Advantage) 先のセッションに続いてIasa Globalのリーダーシップチームの一人であるBrice Ominskiの登壇です。タイトルにある「デジタル・アドバンテージ」は、「デジタル・トランスフォーメーション」の対立概念で、アドバンテージは「状態」ですから、トランスフォーメーションという「イベント」よりもアーキテクチャ的で個人的に気に入りました。同じくタイトルの「インテグレーション・ストラテジー」は、APIにフォーカスしたEA戦略といったところでしょうか。プレゼンにはキーワードしか書かれていないので、特にテクノロジーに関する内容はつかみにくいですが、孤立したメソッドとしてのAPIではなく、かなりハイレベルなビジネス・コンテキスト上でAPIインテグレーションのアンチパターンとその回避方法を語っています。テクニカルな知識をお持ちの方にはさらに多くの発見が得られるかも知れません。 7. ヘルスケアITの複雑性についての議論 　(Complexity in Health IT, a discussion) 本講演のプレゼンのコピーは未入手なので、内容はセッションの紹介文からの推測ですが、本質的に分散型かつ複雑である医療システムが、コロナ禍という突発事象に対処することが、アーキテクチャ無しではいかに困難か、また、将来の課題に対応するためにアダプティブなシステム思考・デザイン思考がいかに大切か、などが論じられたようです。先の6番目もそうですが、かの地における「アジャイルでアダプティブなアーキテクチャ」への関心の高さがうかがえます。 8. 実際的な未来主義者 (フューチャリスト) としてのエンタープライズ・アーキテクト 　(Enterprise Architects as practical futurists) ITABoK「ビューとビューポイント」の執筆者のひとりでもあるTom Gravesのプレゼンです。タイトルにあるように「実践的未来主義者」として未来に挑むアーキテクトの役に立つツールとして、15ものフレームワークを紹介しています。またいかにもプロフェッショナルなEAらしく切れ味鋭い言葉も随所に見られます。個人的には”Enterprise architecture is all about change ”、”‘Futures’ is a plural, not singular”、そして”Reduce uncertainty in Plan; resolve uncertainties in Action”などがお気に入りです。いろいろなフレームワークのリファレンスガイドとしても実用的で、是非ご一読をお勧めします。 9. 戦略から実行へ – ミッシング・リンクをマスターする 　(From Strategy to Execution - Mastering the Missing Link) Business Architecture GuildのMike Rosenのプレゼンです。冒頭にミンツバーグやマイケル・ポーターと並んで、何やらカッコいい英文が引用されていて、何かと思ったら宮本武蔵の五輪書の一文でした。タイトルにもあるように”Strategy to Execution (‘S2E’)”、つまり「戦略から実行」のポイントを、Business Architecture Guildのテキスト”BIZBOK Guide”も引用しながら解説しています。戦略が上から下に2～3段降りると、その意図やコンテキストは半分くらい失われてしまう、というシチュエーションは、日本だと中期計画などの「ポンチ絵」と、その実行の「現場に丸投げ」という形でよくみられるのではないでしょうか。プレゼンの締めはケインズの箴言で、「難しいのは新しい発想ではなく、古い発想から逃れることだ」というのは、まさに今の日本の状況に当てはまるものと感じます。 10. エンタープライズ・アーキテクチャをビジネス戦略に基づかせること：アーキテクトのための4つの教訓 　 (Basing Enterprise Architecture on Business Strategy: 4 lessons for Architects.) メルボルン大学の教授によるリサーチ結果の発表です。EAはビジネス戦略に基づくはずなのにどうして失敗するのか、というシンプルな疑問に端を発し、当事者へのインタビューなどを通じて、戦略がEAの役に立たない原因が4つ特定できたそうですが、その中身を見ると、戦略が1) 漠然、未確認、または存在しない、2) ITの方向性を明確に示せない、3) 不安定で頻繁に変わる、4) 戦略に特化した再利用不能なITシステムを要求する、という、割と普通な内容にとどまっている感じではあります。9番の講演内容にも相通ずるものが感じられますが、こちらの方は実行以前にそもそもポンチ絵がダメ、というケースですね。4)もユーザー企業とベンダーの役員同士で仲が良かったりするときによく見られるケースでしょう。 11. 複雑なシステム：医薬品業界のためのAIデータ・プラットフォームのアーキテクチャ構築 　 (Complex Systems: Architecting an AI Data Platform for the Pharma Industry) AI/MLについて多数の著作をもち、複数の企業で様々なAI関連ビジネスに携わるRaj Ramesh博士の講演です。残念ながらプレゼンのデッキは未入手なので、内容の手がかりは紹介文のみになりますが、なんでも現在構築中なのは、「(医薬品ビジネスに関する)データ駆動型の価値あるインサイトを、インジェスト、処理、変換、レポートアウトすることができる」「エンタープライズクラス、スケーラブル、マイクロサービスベース、サーバーレスのクラウドプラットフォーム」だそうで、そこで直面したテクノロジー、ビジネス両方のいくつかの課題について知見がシェアされる、という、AIご専門の方のみならず、EAにご関心のある方にとっても結構興味深い内容だったのではないかと思われます。博士はこのイベントのほかにも様々なコンテンツをYouTubeをはじめとする様々なプラットフォーム上で展開されているようなのでご覧になってみてください。 12. エンタープライズ・アーキテクチャの働き方(WoW)改革 (Modernizing Your Enterprise Architecture Way of Working (WoW)) PMIではディシプリンド・アジャイル(DA)のチーフサイエンティスト、またArchitectural Thinking Associationのアドバイザリーを務めるScott Amblerによる「DAツールキット」と「アーキテクチャ・シンキング・フレームワーク (ATF)」の紹介です。DAは様々なプラクティスの乱立に至ったアジャイルに秩序をもたらすべく生まれ、その際アーキテクチャに関係する概念も取り入れられたようで、例えばアーキテクチャ・オーナー(AO)、バリューストリーム・アーキテクト、エンタープライズ・アーキテクトといったロールが定義されています。そしてアーキテクチャを「資産(asset)」と捉え、丁度良いバランスで「ぎりぎり満足できる (just barely good enough=’JBGE’)」資産を作ることがポイントであるようです。ところでモデリングについては特に触れられていませんが、そういうプラクティスが元々無いのか、それともたまたま紹介されていないだけなのかは若干気になるところではあります。 13. 社会システムのアーキテクチャ構築 　 (Architecting Social Systems) オーストラリアはアデレードに拠点をおくコンサルのプレゼンです。紹介文にはアーキテクチャには生物的なもの（会社、社会）と無生物的なもの（ITシステム）があって、それらの特徴を実例を交え解説、とあります。デッキの方は情報量がミニマム、かつふんわりとした内容で、これだけではどのような話だったかは何とも分かりませんでした。 14. デジタル・トランスフォーメーションの落とし穴はどこか? (What are the failure points of Digital Transformation?) タイムゾーンの関係でオーストラリアが続きます。デジタル・トランスフォーメーション専業のコンサル会社による、何がデジタル・トランスフォーメーションで、その典型的な実現プロセスはどうなっているか、そのどこに失敗ポイントがあるか、EAの適用がどのようにその成功率を高めるか、などについての話だったようですが、これも残念ながらデッキ未入手です。プレゼンターは博士号とTOGAFやArchiMateの資格持ちで、もしモデルなどが紹介されていればぜひとも見たいところです。 15. ビジネスモデル・イノベーションのイネーブラーとしてのアーキテクチャ 　 (Architecture as an enabler of business model innovation) Jalapeno (ハラペーニョですね) なるITツールを出しているCapsifiという、こちらもオーストラリアの会社です。単なる商品紹介と思いきや、なかなか良いことが書いてあります。今日の「不幸な真実」の一つとして、ビジネス知識はトランスフォーメーション活動(というワンタイム・イベント)「のため(だけ)に」作られ、プロジェクトとともに寿命が尽きる、というのは鋭い指摘ですね。プレゼンではEAを殊さら強調しているわけではありませんが、イベントよりステートを重視するマインドはまさにEAです。余談ですが、デッキの前半にはデジタルによる爆発的なビジネス環境の変化を示すグラフ類がまとめて多数掲載されていて、DX絡みの提案書などを作るとき、リファレンスとして持っておくといろいろ便利かも知れません。 16. エンタープライズ・クラウドの変革パターンと落とし穴 　(Enterprise Cloud Transformation Patterns and Pitfalls) クラウド・エンタープライズ・アーキテクトなる方のプレゼンですが、どうやらオーストラリアの役所関係にどうやってクラウドサービスを売り込むか、という話で、コモディティ化した様々なクラウドプロダクトから、オーダーメード (tailored) サービスを作る、とか、ベンダー管理をどうするとかいった内容が、ビジュアル・ファシリテーションぽい絵や、ビジネスモデルキャンバスなどを使って語られています。EAの観点からは、正直あまり得るものは無さそうです。 17. 問題の種類がそれに対するコントロールの期待値を左右する 　 (The type of problem you are facing steers how much control you can expect) 朝を迎えたヨーロッパ組の最初は、イケアのビジネス・アーキテクトHenrik Ekstamによるプレゼンです。EAはストラテジー、テクノロジーの両方をカバーしますが、ストラテジーは”complex / obvious”、テクノロジーは”complicated / chaotic”という、それぞれ異なる評価軸を持っていて、これらで四象限のマトリクスを成すそうです（※これはCynefin Frameworkという名前であることを、このあとの他のプレゼンで知りました）。問題がどの象限にあたるかによってどれだけコントロールできるかが決まる、というのがタイトルの意味です。EAのコンテキストにおいては、問題課題はかならずしも最初から「これはテクノロジーの問題」とか、「これはストラテジーの問題」とかに一刀両断出来るわけではないでしょうから、このようなフレームで問題を位置付けてみるのは有用かもしれません。ストラテジー的な問題課題はタクティクスに落として解決するのですが、そこではcomplexityやadaptationのためのデザインが、efficiencyのそれより重要だ、と説いています。 18. エンタープライズ・アーキテクチャの利点と課題を探る 　 (Exploring Enterprise Architecture Benefits and Challenges) メルボルン大学の准教授によるプレゼンです。18人のエンタープライズ・アーキテクトへのインタビュー結果に基づき、EAプラクティスにおける8つの主要プロセスおよび、各プロセスの主要な活動、成果物、便益および制約をわかりやすくまとめています。ただし個人的には、これを読んでEAを「フォーマルな手続きの集まり」と誤解してしまう人が出てこないか少々心配になります。それはプロジェクトであってEAでは無いでしょう。リサーチの結果の一つとして”No ‘general purpose’ EA artifacts are identified’→“と書いてあるのも気になります。ArchiMateなどはその解決のために作られたはずですが、このリサーチでは状況は変わっていないようです。エンタープライズ・データモデルが主要なアーティファクトに挙げられているのがせめてもの救いです。 19.「マイクロチーム」はコラボレーションのやり方を「再び」どう変えるのか （How MICROTEAMS Change the Way We Collaborate. AGAIN. オランダのQubyという、IoTやAIで省エネソリューションをB2B/B2Cに提供するという、非常にモダンな企業でCIOを務めるSander Hoogendoornのプレゼンです。ダンレポを見たら、なんとultimate parent companyにDiamond Chubu EUROPE B.V.とあり、それで検索したら「三菱商事と中部電力がEneco買収」という、今年3月25日のニュースに突き当たりました。Enecoは彼の地ではガス電力の小売事業者として知られていますが、Qubyはそこの子会社と思われ、そうするとダンレポの「100人、10億円」というのは末端のグループ会社としては有り得る規模でしょう。この規模であれば、プロジェクトマネジメントどころかSAFeまで全否定して、究極のアジャイルに向けて突き進む姿勢も、またアーキテクチャについても、逆コンウェイの法則で、ビジネスアーキをテクノロジーアーキに合わせる、という考えも理解できます。今は100人10億円ですが、これがスケールしてGAFAのようになれば本物でしょう。しかしこういうビジネスもちゃんと日本企業が買っているというのも新鮮な驚きです。余談ですが、このスライドでもcomplex/chaotic/complicated/obviousのフレームが登場します。Cynefin Frameworkというのですね。日本語ではクネビンとかカネヴィンとかの読みが当てられているようです。課題分類のフレームワークとして様々な分野で使われ、アジャイル開発でも良く知られてたフレームワークだそうで、一つ勉強になりました。 20. アーキテクトとして複雑性に対峙すること 　 (Facing Complexity as an Architect) イギリスのコンサルタントによるプレゼンです。紹介文によると、テクノロジー・システムが今までの「経験的行動の自動化」から「予測可能性を組み込むことによる結果の導出」に用いられるようになった現在、そのシステムが安全で信頼でき長期の使用に耐えるものとするために、そのシステムやソリューションの複雑性にアーキテクトが向き合う方法について語られているようです。複雑性に関するフレームワークとして、ここでもCynefin Frameworkが取り上げられています。また、「ブラック・スワン」「アンチフラジャイル」「デザイン・ストラクチャ・マトリクス(DSM)」などの理論が紹介されています。講演ではおそらくより実践的なテクニックなどが語られたのではないかと察しますが、「文字数少な目」なデッキからは、アーキテクトという仕事でもやはりその土台となるのは思想や哲学といった教養、素養であることが伺えます。 21. エンタープライズ・アーキテクトにとっての感情的知性の重要性 　 (The importance of Emotional Intelligence for Enterprise Architects) エンタープライズ・アーキテクトに対し、専門的なコーチング・プログラムを提供しているオランダの方のプレゼンです。これまでから一変したソフトな話題です。内容は紹介文によると、組織に対するアーキテクトの影響力の乏しさがまず課題としてあり、それはスキルなどよりも仕事のエモーショナルな側面における低評価に起因するものである、として、エモーショナルな面での能力開発の重要性を説く、というものです。能力開発のアプローチとして、自分自身もアーキテクチャ的にとらえるのは非常に面白いアイデアです。全体に「文字数少な目」なスライドですが、訓練する対象がいろいろ列挙されています。20番でFBIの交渉テクニックとして紹介されていた「偏桃体ハイジャック (amygdala hijack)」も挙げられています。最後のスライドはコンタクト情報で、彼らのサービスを買えばエモーショナル・インテリジェンスの具体的向上が図れます、というご紹介でした。 22. スピーディーなEA：「ミルキーウェイマップ」と「エンタープライズ・デザイン・スプリント」で飛び越える 　 (EA on Speed: rapid leaps with a Milky Way Map and Enterprise Design Sprints) スウェーデンのirmなるコンサル会社のプレゼンです。デザインシンキングに基づくチームコラボレーションでのエンタープライズ・デザイン・ワークショップと、そこで用いられる独自ツールとメソドロジーの紹介です。ホームページでスターターキットを無償で提供しているので、気になる方はどうぞ。(https://www.enterprisedesign.io/) 23. パニックで反射的に行動してはならない。経済危機の際の削減施策におけるデータドリブンなアプローチ 　 (Don't Panic and React. A Data-Driven Approach to Making Those Cuts During Crises) 舞台はアメリカに戻り、アトランタからのプレゼンです。プレゼンターは目下の危機について、過去にも何度も危機的状況は起きていて、それに対しパニックに陥り反応(react)するのではなく、評価(evaluate)し対処(respond)することが重要だと説きます。そして具体的なプロセスとして、デマンド、キャパシティ、コスト、バリューに関する正確なデータを集め、それらに基づく構想をフレームワークを活用して立案し、そこからデータドリブンなストリーテリングのナラティブを書き上げる、という手順を紹介しています。エンタープライズ・アーキテクトは、プロジェクト・ベースではなく、自社のEAと日常的に向き合い、ストラテジーからオペレーションを経てテクノロジーに至るまで、自分の会社の全てを知っていることが強みですが、それは事業成長だけに限らず、危機的状況でのダメージ軽減にも役に立つという、とても重要なポイントに改めて気付かされました。 24. 開発組織のアプリケーション・セキュリティ成熟レベルの向上 　 (Maturing Application Security in Development Organizations) 24時間ウェビナーのトリを務めるのは米国アトランタ在住のプレゼンターです。世界中に拠点をおくオランダWolters Kluwerの税務・会計部門のチーフ・アーキテクトで、長年にわたるIasaフェローでもあります。ウクライナ出身でアメリカの大学で博士号をとり、様々な企業でキャリアを積んでこられたようです。ここではマイクロソフトでの6年間のアプリケーション・セキュリティ・プログラムでの経験に基づき、開発組織にセキュリティに関するプロセスやプラクティス、ツールセット、スキルとコンピテンシーをビルトインし、成熟度を高めるステップを紹介しています。これまでのプレゼンテーションとは異なり「文字数多め」で、トピックにご関心のある向きには読み物として有益でしょう。 以上全24セッションの非常にざっくりした概要のご紹介でした。全体的な印象として、「アジャイル/アダプティブ/レジリエントなEA」が最大の関心事 (セッション1、3、6、7、8、12、14、15、17、19、20)で、これには「複雑性を増していく世界」という状況認識(セッション1、3、7、11、17、19、20)が関連しているようです。これらに「EAのプロフェッションとしての認知度向上」 (セッション4、5、23) が続いているようです。ビジネスとテクノロジーどちらのマネジメントによりフォーカスしているかについては、ビジネスが13 (セッション1、3、4、5、8、9、10、17、18、21、22、23)、テクノロジーが7 (セッション6、11、12、14、15、19、20)、不明が4といったところでしょうか。コロナ・パンデミックの話題は4、7、23の3つのセッションで取り上げられていました。 この24時間ウェビナーは、EAの世界で今どんな議論が起きているのかを知るのに絶好の機会だと思います。Iasa Globalでは今後も同様のイベントを引き続き年2回開催する予定とのことで、Iasa日本支部からも参加、聴講していきたいと思います。 ※ 本コラムについてのご意⾒ご感想お待ちしております。