ご存知の方もいらっしゃるかと思いますが、今年の９月１日より日本政府内にデジタル庁が創設され、同時にデジタル社会形成基本法および関連法が施行されます。私自身、データアーキテクチャのコンサルティングを生業としていることもあり、このような動きには大変関心を持っています。今回はデジタル庁で行う数多くの取組みを、「データアーキテクチャ」の視点で考察し、私の所感も交えながら紹介します。 まずデジタル庁の組織体制ですが、内閣の直轄組織として図１のような形で組織化される予定となっています。 また、デジタル庁の役割や取組みについてはデジタル庁のホームページで以下のように記されています。 デジタル庁は、デジタル社会形成の司令塔として、未来志向のDX（デジタル・トランスフォーメーション）を大胆に推進し、デジタル時代の官民のインフラを今後5年で一気呵成に作り上げることを目指します。徹底的な国民目線でのサービス創出やデータ資源の利活用、社会全体のDXの推進を通じ、全ての国民にデジタル化の恩恵が行き渡る社会を実現すべく、取組を進めてまいります。 具体的な取組み及び得られる価値としては、分かりやすい例で言うと、“行政手続きのデジタル化(オンライン化)” により、“役所に行く必要がなくなる”、“ハンコが不要になる”、“手数料が安くなる“ などが期待されます。そのような ”デジタイゼーション“ 施策に加えてさらなる価値を得るための ”デジタライゼーション”、“DX” 施策も多岐に渡って計画されています。詳しくは今年６月に閣議決定されたデジタル社会実現に向けた重点計画＜概要＞を参照ください。 その計画書の中にはデジタル庁が目指す姿(図2)が描かれていますが、今回はその中でも基盤を支える上で特に重要なポイントになるであろう “包括的データ戦略” に注目します。 “包括的データ戦略” の概要は以下の図 3のように「戦略・政策」から「インフラ」そして「人材・セキュリティ」と、レイヤーごとに網羅的かつ具体的に検討されています。詳細については先述の重点計画の別紙で語られています。 その別紙中「p.9 ; (３) 日本全体が参照すべきアーキテクチャ」に以下の記述がありました。 行動指針や業務改革を通じて本戦略のビジョンを実現するためには、データに関わる我が国の全てのプレイヤーが我が国全体のデータ構造＝「アーキテクチャ」を共有し、それぞれの取組の社会全体での位置付けを明確化、連携の在り方を模索するとともに、無駄な重複の排除、欠落部分の補完を行っていく必要がある。アーキテクチャを共有することを通じて初めて有機的・一体的かつダイナミックなデジタル社会を構築することが可能になる。 これはまさに「データ中心アプローチ」を意味しています。日々の仕事や記事などの情報を通じて感じることですが、“デジタルトランスフォーメーション(DX)” を進める上で「データが大事」というのは関係者間の共通認識になりつつあります。ただ、「データが大事」と認識しつつも、システムを構成するデータの洗い出しやデータの構造、データ間の関係性、データのライフサイクルについての課題認識にはまだまだ改善の余地があると感じています。上の記述はそのような点について考慮する必要性を述べています。私自身、その具体的な活動の一つは「データモデリング」であると認識しています。データモデリングの詳細については DMBOK (第５章 データモデリングとデザイン)やITABoK V2 (2.2.2.6 情報モデリング) などを参照いただければと思いますが、ポイントは「モデリング」です。システムの構造が目指す価値を得るのに最適な形になっているかを評価するためには、そのシステムを関係者間で共通認識を持つための「モデル」が必要です。また共通認識が持てるモデルを描くためには、適した「モデリング言語」と「レベル」が必要です。データモデルのモデリング言語には、UML (クラス図)や ER 図などがあります。レベルには、「概念」、「論理」、「物理」があります。 ここで少し視点を変えて、データ活用に向けての各国の取組みを見てみましょう。デジタル・ガバメント閣僚会議のデータ戦略タスクフォースよると、欧州・米国・日本とも各レイヤーで取組みを進めているとのことです。 図 4 を見るとインタオペラビリティ(相互運用性)のレイヤーにおいて、欧州・米国と比較して、日本ではクラス図やBPMN などのモデリング要素の取組みがありません。これは極論すると「モデルを見ながら会話する文化が存在しない」と言えます。もちろん個別システムの物理設計を行うときには何かしらのモデルを描くとは思いますが、それはあくまで実装のための設計書の一部なので、「関係者間で共通認識を持つためのモデル」あるいは「システム構造の妥当性評価などを行うためのモデル」といった目的で使うものとは異なります。 国に限らず、地方自治体や大企業の情報システムのように、取り扱うデータの種類が大量かつ複雑になるケースでは、全体を俯瞰的に把握するための「概念データモデル」を描いた上で、「論理モデル」、「物理モデル」の順に詳細化することが重要です。その意義や描き方についてはIasa日本支部理事、(株)アイ・ティ・イノベーションの中山氏のブログ(ビジネスを表すデータモデル図とは？)を参考にしていただければと思います。 「目に見える成果物」を重視するあまり、物理設計・実装を急ぎたくなることもあるかもしれませんが、共通認識や共感を得ながら進めるためにも「概念」から「論理・物理」、「As-Is」から「To-Be」のモデルを描くことが重要であり、それが結果的に近道になると思います。 モデリングの重要性についてはデータアーキテクチャに限った話ではなく、Enterprise Architecture (EA) でいうビジネスアーキテクチャ、アプリケーションアーキテクチャ、テクノロジーアーキテクチャについても同じことが言えます。 EAに絡めて少し宣伝になりますが、11月開催予定のIasa日本支部アニュアルカンファレンスにて、名古屋国際工科専門職大学情報工学科教授(名古屋大学名誉教授)山本修一郎先生による“EA”, “DX”をテーマとした講演を計画していますので、ぜひご参加ください。開催日程等の詳細についてはメールやIasaホームページ等を通じて改めてご案内します。 今回はデジタル庁の取組みに対して「データアーキテクチャ」の視点で所感を書かせていただきましたが、Iasa日本支部としても、私個人としてもデジタル庁には大変期待しています。デジタル庁の取組みは国を挙げた POC のようにも感じています。中にはうまくいかない施策も出てくるかもしれませんが、それらの取組みを含め、「教訓」として国民にシェアしていただき、他の DX プロジェクトに活かすことによりプロジェクトの成功率の向上、ひいては日本のケイパビリティ向上に寄与するものと考えます。 最後に小ネタです。政府の呼びかけにより今年から毎年 10 月 10～11 日は「デジタルの日」と呼ぶことになったそうです。その日になったのは「0」と「1」で構成される日付だからだそうです。特に「休みになる」というわけではなく、以前話題になった「プレミアムフライデー」のような位置付けのものと思われます。デジタル庁の取組みに対してはデジタルの日に限らず、IT に携わる者として、また一人の国民として応援、または機会があれば積極的に参画していきたいと思います。 ご一読いただきありがとうございました。 以上 Appendix 1 : 図の引用元 Appendix 2 : 用語の引用元

2021年12月の本コラムのコーナーにおいて、ビジネスアーキテクチャにおけるビジネスケイパビリティとエンタープライズアジャイルの関係と、ビジネスケイパビリティの重要性についてご紹介いたしました。今回はもう少しビジネスケイパビリティについてご説明したいと思います。 Iasaが提供しているBTABoK（ITABoK）でも示されているアーキテクチャの一つの専門領域としてビジネスアーキテクチャがありますが、この専門領域については、ビジネスアーキテクチャの専門家および関係者から成る国際的なコミュニティであるThe Business Architecture Guild（ビジネスアーキテクチャギルド）が活動しています。本コミュニティからはBIZBOK®(Business Architecture Body of Knowledge)と呼ばれる知識体系が提供されており、そこではビジネスアーキテクチャのコア要素を、ケイパビリティ、バリューストリーム、情報、組織と定義しています。 参照：https://en.wikipedia.org/wiki/Business_architecture ビジネスケイパビリティ（以下、ケイパビリティと呼びます）は、“特定の目的や結果を達成するために、企業が所有、交換できる特定の能力（ability）やキャパシティ（capacity）”と定義されており、ビジネスが何をするかを定義するものです。言い換えると、ビジネスがどこで、なぜ、どのように行われているかを表現するものではなく、「何が」行われているかを表すものと言えます。それゆえ、ケイパビリティは、ビジネスの基本構成単位（ビルディングブロック）を表しているとも表現されます。 ケイパビリティマップの表現 ケイパビリティはボックス型のイメージを一つのケイパビリティとして表現し、それを階層化したマップを作成します。ケイパビリティをカテゴリーに分けて整理するにあたり、例えばレベル１のケイパビリティは、以下の３つのレイヤでパッケージ化することができます。 戦略（Strategic: Direction Setting）レイヤ コア（Core: Customer Facing）レイヤ サポート（Supporting）レイヤ 参照：https://tcbaf.org/wp-content/uploads/2019/12/SSNA_TCBAF2019_BuildingCapabilityModels-1.pdf コアの領域が、そのエンタープライズにおける事業固有のオペレーションを行うためのケイパビリティとして整理されます。戦略領域は、例えば中期計画や投資計画を立てるなど組織や事業のディレクションを決めるケイパビリティです。サポート領域は、例えば各事業部をシェアードサービスのように支援する財務会計や人事などをイメージするとわかりやすいでしょう。 一般に、ケイパビリティは複数のビジネスユニットに共通して存在しえます。例えば、営業部門とカスタマーサービス部門の両方で、新製品についての販売活動を行うのだとすると、この販売活動のケイパビリティは、組織として一つのものとして定義されます。それが異なる組織において、実装されているということになります。ケイパビリティはこのような抽象的な概念のため、「ケイパビリティ・インスタンス」と呼ばれる概念を通して、実効性や自動化レベルなどの固有の属性を、ケイパビリティに関連付けます。ケイパビリティ・インスタンスは、業務プロセス、情報、組織や個人の職務定義や権限やスキル、ITなどによる自動化などが効果的に組み合わさったものとして実装されます。 組織でケイパビリティを用いてビジネスマネジメントしている場合、よく用いるのがヒートマップのテクニックです。ケイパビリティマップの優れたたところは、組織全体で共通言語としてのビジネス構造の理解が持てることと、それに基づいて戦略的な意思決定をすることができるということです。例えば、後者の戦略意思決定には、組織の新しいビジネス戦略方針からみて、現在の組織のケイパビリティのどこに課題があるのかを特定し、それを改革・改善するためにイニシアチブを立ち上げることがあります。そのためには、例えば、各ケイパビリティに対し、戦略に対して非常に有効な状態にある（グリーン）、ある程度の改善が必要な状態にある（イエロー）、大きく改善・改革が必要な状態にある（レッド）といったケイパビリティ評価を行ってヒートマップを作ることで、意思決定者間での共通理解と適切な投資意思決定を支えます。 参照：https://www.iiba.org/knowledgehub/business-analysis-body-of-knowledge-babok-guide/10-techniques/10-6-business-capability-analysis/ ケイパビリティを理解するための主要原則 ケイパビリティは、以下のような特徴を持ちます。 ①ケイパビリティは、ビジネスが何をするかを定義します ビジネスのなぜやどのようにではなく、Whatを定義します。 ②ケイパビリティは、ビジネス用語で名詞の形で定義されるビジネス観点でのビューを提供します 組織全体で共通のビジネス・ボキャブラリーとして定義される必要があります。バリューストリームやプロセスは、“~を~する”という動詞表現を用いますが、ケイパビリティは“何を”を定義するため、通常名詞表現を用います。 ③ケイパビリティは、他のアーキテクチャ要素と比べても比較的安定しています（すぐに変わるものではない） プロセスをどう実行するかは改善活動などを通して継続的に変わっていくことが想像できると思います。ケイパビリティも組織の成長のために改善しつづけるという意味では同じですが、例えばアーキテクチャのケイパビリティマップが頻繁に変わることはありません。各ケイパビリティの実装形態（インスタンス）は、例えばシステムの機能改善などを通して変わっていくと言えます。 ④ケイパビリティは、組織をまたがって、エンタープライズで同じものは一つとして定義します ケイパビリティは同じものは組織で一つ定義します。組織をまたがって共通化される概念であり、ある特定のケイパビリティが複数の組織で用いられているときは、ケイパビリティと組織のクロスマッピングをすることでアーキテクチャ上は表現します。 ⑤ケイパビリティは、構造化（階層化）した形で体系化可能なマップとして表現されます ケイパビリティはビルディングブロックであるため、すでに上で見た通り、入れ子になっていく形で階層化してケイパビリティのマップを作成します ⑥ケイパビリティは、他のビジネスアーキテクチャ要素（バリューストリーム、組織、情報など）と関連性を持ちます ケイパビリティはバリューストリーム上のバリューストリーム・ステージを実行するために用いられますし、どの組織で用いられるのかという関係性も存在します。また、そのケイパビリティがどの情報を用いるのかということを知ることも重要です。モデリング手法はあるビューについて表現するものであるため、他のビューに基づくモデルとの関係性を合わせて理解することで初めてビジネスの全体像が見えることになります。 ⑦ITなどで自動化されたものは、手段としてのシステム機能を通して自動化されたビジネスケイパビリティです デジタルやITを用いてビジネスや業務を実装することで、ビジネスや業務のパフォーマンスを向上させることをよく行っていますが、私たちが理解しないといけないことは、私たちはシステムを作っているのではなく、システムを通してケイパビリティを作っているということです。 ケイパビリティを活用するベネフィット ビジネスのマネジメントやデジタルやITを用いたビジネス改革・改善を効果的におこなうために、ケイパビリティをマネジメントすることで、以下のようなベネフィットを得ることができます。 ①ケイパビリティは、共通のビジネス・ボキャブラリーを提供します ②ケイパビリティは、ビジネス全体で何が共通していて何が異なっているかを確認する方法を提供します ③ケイパビリティは、ビジネスとしてどこに重点的に投資すべきかを検討する視点を提供します ④ケイパビリティは、戦略計画、変革デザイン、変更管理、影響分析などを行うためのベースラインとして役立ちます ⑤ケイパビリティは、変革のデザインとデプロイ可能な実装デザイン（例えばITシステムのアプリケーション機能）を描くための基礎となります 最後に ケイパビリティはグローバルには非常に用いられている概念であり、エンタープライズ/ビジネス・アーキテクチャ、ビジネスアナリシス、プログラムマネジメントなどのフレームワークでも登場しています。ところが日本ではケイパビリティの概念を用いてマネジメントする組織が少ないように思います。特にデジタルやITを用いてビジネスを変革や実現していく時代においては、プロジェクトでアウトプット（システムやプロダクトなど）を作ることをマネジメントしようとする視野だけでは十分ではありません。プロジェクトのアウトプットの構築を通してビジネスのケイパビリティを作り、そのケイパビリティによってビジネス価値（またはベネフィット）を創り出すことをマネジメントしていく必要があります。ビジネス部門の方はもちろんのこと、特にデジタル部門やIT部門の方には、ケイパビリティの創出が自分たちの重要な貢献であるという目線を持っていただくことで、組織におけるより戦略的な役割を果たせるようになると考えます。 BTABOKでは、アウトカムモデルにおいてビジネスケイパビリティが紹介されています。こちらの記事の内容もぜひご覧になってください。 https://btabok.iasaglobal.org/digital-outcome-model/business-capabilities/

今回はBTABoK 3.0のコンピテンシーモデルについて、私の解釈も踏まえながら紹介します。コンピテンシーについてはITABoK 2.0と比較して表現の仕方は違えど、大きな変更点はないと感じています。ただ、「コンピテンシーモデル」という形で「コンピテンシー」に特化した形で記載されているので、少し読みやすくなった印象を受けます。それでは中身をみていきましょう。 BTABoKではコンピテンシーについて以下のように説明されています。 (BTABoKより抜粋) ● 特定の責任範囲または領域に関して十分な知識、判断力、スキル、強みを持っている 状態、またはその質を維持している状態 ● 規定上の権限、力量、または許容性があること 　コンピテンシーは、アーキテクトおよび個々の実務を行う専門家にとって最も重要な要素です。これには、一般的にアーキテクトとして必要なすべてのスキルが含まれ、具体的には、価値を提供するためにアーキテクトを採用する組織の状況や目的に応じて決まります。BTABoKでは、スキルとコンピテンシーは同じ意味で使用されますが、正式には次の階層を使用します。 a. コンピテンシーの柱 　ビジネステクノロジー戦略、設計、ヒューマンダイナミクス、IT環境、品質属性など、アーキテクトのコンピテンシーの5つの柱の1つ。 b. コンピテンシー 　投資計画、システム全体設計、アプリケーション開発など5つの柱に含まれる42の項目。 c. スキル 　学習目標、成長レベル、および学習教材も付いた、コンピテンシーを支える特定の実用的なスキル。サブコンピテンシーと考えることも可能。 　したがって、コンピテンシーとは、アーキテクトがキャリアを通じて磨き、開発し、成長し、成功するアーキテクトになるために必要なスキルの組み合わせとなります。 上記の説明をコンピテンシーに関する構成要素とその関係性を表した概念モデルが図1になります。 このようにアーキテクトが持つべきコンピテンシーに関する構成要素を整理・把握することで、以下のようなメリットが得られると考えられます。 なおコンピテンシーの説明にあった「アーキテクチャの5つの柱」はITABoK 2.0 のときのものと同じです。(表1 参照) 表1 アーキテクチャの5つの柱 また、アーキテクチャの専門領域もITABoK 2.0と同様です。(表2 参照) 表2 アーキテクチャの専門領域 なお、このようにコンピテンシーやスキルを体系化したフレームワークとしては、以下のようなものがあります。(表3 参照) 表3 その他のスキルフレームワーク いずれも網羅的、汎用的で、広い意味での“IT技術者”を対象としたフレームワークです。個人的にはさまざまな領域に興味があるので、網羅的に理解するための読み物としては非常に参考になります。ただ、“アーキテクト”や“実践的”観点からすると、これらを導入しようとする組織にとってはテーラリング作業に労力を割く必要が出てくるかもしれません。 一方、BTABoKのコンピテンシーモデルは“アーキテクト”および“実践的”を売りにしているので、アーキテクト育成を目的とする場合などは、BTABoKのコンピテンシーモデルを活用することで、人財育成のスピードおよび精度向上につながることが期待されます。 私自身は「インフォメーションアーキテクチャ」領域を中心に仕事をすることが多いので、自分の仕事を俯瞰的に見たいときにITABoK 2.0の「2.2.2 インフォメーションアーキテクチャの専門領域」を参照し、思考の抜け漏れの有無などを確認することに使ったりします。そこからさらに深い知識を得る必要がある場合は、DMBOKや他の専門書を参照したりしています。 これは私の持つ、BTABoK 3.0に対する印象ですが、ITABoK 2.0に比べると、よりビジネス価値を得るために必要な知識体系をよりわかりやすく、実践的なものにまとめようとしていると感じています。まだドラフト版ではありますが、アーキテクトに必要なコンピテンシーを俯瞰的に把握するための参考にしていただければと思います。 ご一読いただきありがとうございました！ 以上

今回のコラムでは、BTABoKにおける全体像（下図参照）のうちPeople Modelにあるコミュニティについて紹介します。（文中の太字部分は、BTABoK原文に準拠した和訳になります。） コミュニティとは？ BTABoKでは、「コミュニティ」を、組織内外のアーキテクトや拡張チームメンバーからなる協働するグループと定義しています。このグループは、最善のビジネスおよびテクノロジー戦略を実現するために協力します。コミュニティは、人々が単なる緩やかな集まりではなく、組織内外のさまざまな専門家（ベンダーやサービスプロバイダーも含む）が協力し、センターオブエクセレンスやプロフェッショナリズムを具現化するために結びつく役割を果たします。 なぜコミュニティが重要なのか？ BTABoKでは、継続的なアーキテクチャの推進と実践に於いて、組織や部門、専門領域を超えた横断的な活動とチームの連携が非常に重要であるとの考えに基づいています。その理由は、様々な専門知識やスキル、ベストプラクティスに基づく成果は、横断的なチームとしてのコミュニティの連携によって生み出されるからです。（コミュニティは、別コラムで紹介したピープルモデルの構成要素6つのうちの一つです。） では、アーキテクトの活動に於いてコミュニティの重要性とその役割について、その基本的な理念の説明をもう少し詳しく見ていきましょう。 BTABoKの理念として以下の４つのコミュニティの基本的アプローチが紹介されています。 コミュニティは、 アーキテクトの能力を最大限に引き出すための基盤の役割を担う エンゲージメントモデルに基づく価値、目的、ミッションを共有し継続する アーキテクチャの価値や品質を決定付ける 同意されたエンゲージメントモデルに基づいて価値を向上させるために積極的に取り組む これらのアプローチは通常の組織内の階層によるガバナンス的な考え方とは異なるため、参加者はこの理念や違い、基本的なアプローチを予め理解しておく必要があります。原文では、ステークホルダードリブン、オープンで革新的なオーナーシップ、賛同されたエンゲージメントモデルなどの用語を使って解説しています。 コミュニティとしてのアプローチの勘所 次に、BTABoKが提案するコミュニティの具体的なアプローチを見てみましょう。 「実践的コミュニティ」と「センターオブエクセレンス」 BTABoKでは、「コミュニティ」という用語は、医師や建築家などの専門職が使用する際の実践モデルを指しており、実践的コミュニティ、または、センターオブエクセレンスとして捉えるのが適切、と述べています。更に、コミュニケーションや知識の共有が格段に向上し、チーム全体の責任感や目標の共有につながるメリットがあるため、コミュニティの捉え方を進化させることが重要、と述べています。 成果を上げるコミュニティの構造化について ITアーキテクトのコミュニティを効果的に構築する際に考慮すべき要素として、リーダーシップ、メンタリング、経験値などのソフトスキルに焦点を当て、以下の4つを紹介しています。 コミュニティの構築には、組織の報告ラインと役割と実践のリーダーシップの2つの側面があり、アーキテクトの成熟度が不十分な場合は、十分なサポートが必要 BTABoKの定義に沿った役割、メンタリング、エンゲージメントに基づく成果に焦点を当てたリーダーシップの実践では、状況に応じて柔軟に適用が可能 シニアとジュニアのアーキテクトを選別する際は、経験年数よりも能力と成果が重要であり、コンピテンシーに基づいて行う必要がある。メンタリングや役割上の指針にもなるCITA-P/D認定試験を通じての認定試験実務経験レベルを問うことで、適切な判断を下すことが可能 アーキテクチャ実践を目指すコミュニティの実際の運営では、アーキテクトの成熟度に応じて適時必要なサポートやメンタリングが必要になる事もあるため、メンバーの積極的な働きかけが重要です。 専門分野とコミュニティの対立 BTABoKでは、コミュニティ内の運営時の際に異なる専門家同士の間で対立が生じるケースも想定され、その対処法について述べています。BTABoKには、こういった人や役割に絡む人同士の摩擦や対立に関する解説も含まれており、これはBTABoKが持つピープルモデルの特徴の一つになっています。 対立については、次の様に述べています。専門性の高い活動や役割については、エンゲージメントモデルの初期段階で専門家の対立に対処する必要があります。 医学の領域で見られる専門医同士の立場の違いや区別の例は、ビジネス・アーキテクト、ソリューション・アーキテクトやソフトウェア・アーキテクトらが効果的に協働できるようなアーキテクチャの実務設計に役立ちます。 この実務設計の段階で、予めアーキテクトや専門家の役割や成果物の範囲等を明確にしておき、課題や命題の判断基準や解決のプロセス等も取り決めておく事も有用と思われます。 続いての解説で、2つの質問に答えています。 質問1：アーキテクチャの実践には専門家は必要か？ 必要となる専門家の数を特定する際の判断や方法をいくつか述べています。 大規模なチームや非常に複雑なドメイン：複数のビジネス、情報、インフラ、ソフトウェア、ソリューション・アーキテクチャの専門家が参加し、その数も多くなる可能性がある ビジネスモデル、製品の種類、その業界へのデジタル浸透度：専門家が必要かどうかの判断材料となり得る アーキテクチャチーム・キャンバス：適切な数のスペシャリストとジェネラリストを特定する際に利用して、採用、トレーニング、指導を行う 質問2：各専門家はどのように配置すべきか？ 専門家の配置のために詳細なガイダンスとツールが提供されており、配置の際にはいくつかの特別な注意が必要である、と述べています。 ソリューション・アーキテクト：他の専門家やアーキテクトと連携してバリューストリームを確実にする役割を担う 大規模で複雑なプログラム：上級スペシャリストがリードを務める アーキテクチャ活動のリーダー：知識や経験が必ずしも豊富でないアーキテクト以外のメンバーがアサインされる場合には留意が必要。（コンピテンシーの5つの柱を参照する） 拡張されたチーム：メンタリングとリーダーシップ 続いて、コミュニティや組織でのメンタリングとリーダーシップのソフトスキルについて、以下の3点を述べています。 サーバントリーダーシップ：コミュニティの活動は全体的にこの能力に応じて決まる傾向があり、最も習得が困難なソフトスキルである メンタリングとリーダーシップのスキル：アーキテクトのキャリアの初期に学ぶべき、反復が必要な実践的なスキルである リーダーシップとメンタリングのプログラム開発と維持：継続的な活動として拡張チームや参加メンバーの理解が必要である ここでも、「人」にフォーカスしたソフトスキルと継続的なコミュニティとしてのサポートの必要性に触れています。アーキテクチャ実践のコミュニティの活動レベルの維持と底上げに重要な役割を持つスキルである事が示唆されています。 人事・キャリアへの示唆 BTABoKは、アーキテクトのキャリアと成長にも言及しており、その活用方法が述べられています。 アーキテクトのキャリアアップには、コンピテンシーと経験が重要。BTABoKは汎用的なコンピテンシーモデルであり、多様なテクノロジー環境への適応が可能 専門家の経験値の指標としては、関連する専門家協会の認定が重要。組織やコミュニティ内で認定資格の整合性を図ることが推奨される また、大規模チームのエンゲージメントモデルを維持するには、横断的なステアリングコミッティの運営が必要、と述べています。このコミッティはチームの方向付けや活動の調整、コミュニティの成長を推進します。興味ある方は是非原文もご覧下さい。 終わりに： 今回は、BTABoKのピープルモデル内のコミュニティを取り上げてみました。組織の内外のアーキテクトや専門家から構成されるコミュニティの運営の際の具体的なヒントを紹介しました。ご一読頂き、有難うございました。読者の皆さんに何かしら今後の活動に参考になれば幸いです。今回のコミュニティについてご意見、コメントがありましたら、お聞かせください。

今年度の「Iasa日本支部主催のアニュアルカンファレンス2022」は、講演者3名をお迎えし11月4日に無事に終える事が出来ました。昨年に続き今年度もフルオンライン形式で開催しましたが、今回も多くの参加者にご視聴頂き御礼を申し上げます。（Iasa日本支部イベント情報：https://www.iasa-japan.org/event-details/anual-conference-2022) 今回のカンファレンスの主テーマは、「逆襲の日本式経営と実践的アーキテクチャ」〜ビジネス改革とデジタル化への挑戦者たち〜」を主題に、豊富な知見と実績をお持ちの講演者をお招きする事ができました。社会全体が本格的なデジタル活用と革新の時代を迎えている今日、経営や最新テクノロジーの理解、それを橋渡しするテクノロジーモデルやアーキテクチャへの取組みはその重要性を増しています。今回のカンファレンスでは、これらの関連する分野で活躍されている3名の方から講演を頂戴しました。この振り返りレポートでは、各講演者の主要なメッセージと印象に残った点などを部分的に紹介させて頂きます。尚、講演資料は近日公開予定です。 講演１. 日本企業復活のために必要なマネジメントの民主化 講演者：慶応義塾大学准教授 　岩尾　俊兵 様 最初に登壇頂いた岩尾様には、「日本企業復活のために必要なマネジメントの民主化」と題する講演を行って頂きました。日本社会は「より多くの人への経営教育を行う事によってより豊かになれる」というメッセージを中心にこれまでの研究成果と国際比較の観点から解説を頂きました。ここでは、主な論点にコメント添えて振り返らせて頂きました。 主要メッセージ 経営学者としてのこれまでの研究成果の一部として、「経営教育の最大の間違いを正せば経営者も従業員もより豊かになれる」、また、「経営教育は少人数に深くではなく、多人数に浅くが正解」の論点が３冊の著書と共に紹介されました。 日本復活のための武器としての具体的策について 「13歳からの経営の教科書」にも纏められている「対立解消思考」の例としてペットボトル商品の価格設定の事例紹介があり、子供達が身近なテーマを通じて経営を学ぶ機会が重要である事 日本では対立解消思考の観点から互いに高次の目的を捉えて抽象化する力が不足している傾向があり、物事の議論や検討の際により高次の目的（例：豊かな社会、利用者の拡大、会社の成長、利益確保に繋がるか、等）を意識する事が重要 また、私達日本人は逆輸入された方法論等を抽象化できず個別の方法論として捉え吸収しようとした例が過去にいくつかあり、抽象化の作業が出来ていればその独自性や価値を逆輸入の前の段階で認識できていた、との指摘 経営教育を広く浅く普及させる氏の提案として、著作権放棄の上で経営の学びの資料の無償配布を行っている実践的な取組み 起業促進の国際比較で見た日本と突破口の可能性 人口1000万人あたりのユニコーン企業数の国別比較についてチャートの紹介があり、そのデータに基づいて日本で新しい企業が如何に生まれていないかの現状とその阻害要因について （筆者注：一般的にユニコーン企業とは創業して10年以内に評価額が10億ドル(約1,400億円)を超える非上場のベンチャー企業の事を指す） ユニコーン企業数1位のイスラエルと日本の違いの分析によると、12項目の観点のうち大きな違いは僅か１つのみ、それが「社会制度と風土」である事 （出典: https://gemconsortium.org/report/gem-20212022-global-report-opportunity-amid-disruption） 日本生まれのユニコーン企業数がイスラエルに比べて約1/25、対米国で約1/24、対韓国で1/6, 対中国で1/3と言う統計データを見ると背景には複数の要因がある様に想像していました。然しながら、イスラエルとの比較においてはその阻害要因が「社会制度と風土」のみとの事なので、日本での起業促進の突破口の可能性を大いに感じた次第です。 本講演では、「日本企業復活のために必要なマネジメントの民主化」のための戦略的で実践的な普及への取組みについて紹介頂きました。「マネジメントの民主化」は大変大掛かりなテーマに聞こえますが、岩尾様により紐解かれた説明を聴くと突破口は既に見えている様に思えますが、視聴者の皆様はどの様に感じられたでしょうか？ 講演２. アーティファクト管理の重要な3つのポイント 〜 ビジネス改革をアーティファクトとアーティファクト管理から考える〜 講演者：JFrog Japan株式会社 デベロッパー・アドボケイト　佐藤　由久 様 ２番目の講演者の佐藤様には「アーティファクト管理の重要な3つのポイント」と題する講演を行って頂きました。システム開発・運用に従事されている方、またはその管理者の方向けの講演内容でしたが、現場で課題に直面されている方以外の方にも参考になったのではないでしょうか。本講演では以下の議題に沿って解説頂きました。 アーティファクトとは？ アーティファクトの特徴 アーティファクトの管理方法 開発/運用におけるアーティファクト管理の重要性 まとめ 会社紹介 以下、ビジネス改革への貢献の観点に絞って取り上げています。 アーティファクトの管理方法 - 増え続けるアーティファクトをどう管理すべきか？ オープンソース化の進化と共に対象となるアーティファクトとその組み合わせの数は肥大化し続けており、ツールを利用した適切な管理手法が必要 ３通りの管理手法があるが、「バイナリー・リポジトリによるアーティファクトの一元管理」が推奨される バイナリー・リポジトリ採用のメリットとして以下の３つが挙げられる。そのいずれも「ビジネス変化に対応するアジリティ向上」に繋がる 1) バージョン管理機能による煩雑な管理からの解放と自動化 2) キャッシュ機能による外部アーティファクトの高速な提供による効率アップ 3) メタデータの紐付けによるトレーサビリティの向上と信頼性の確保 結果として開発と運用の現場に「品質向上」、「効率向上・ミス軽減」、「セキュリティ向上」、「脆弱性に対するリスク軽減」に寄与する効果が期待できる アーティファクト管理の効果的な活用 アーティファクト管理導入には主に３つのメリットがある - エンジニアの負荷軽減、システム開発におけるコンプライアンス向上、全体を通じた情報共有の容易化 開発〜運用プロセス全体を通じた関係者間のコミュニケーション・ギャップが解消され、情報共有化が促進される。DevOpsの第1歩に繋がる アーティファクト管理ツールの新規の導入時の予算取りの際には、導入後の具体的なビジネス的効果を定量化する等、紹介のされた「効果的な活用」がヒントになりそうです。 筆者は開発・運用の現場を離れて随分年数が経ちますが、今回の講演ではツールやテクノロジー、その導入によるビジネス的効果の繋がりを大変分かりやすく解説頂いて大変有難うございました。 講演3. 「クラウド時代のアーキテクチャと人材育成」 講演者：株式会社アーキテクタス 代表取締役　 細川　努 様 ３番目の講演者の細川様には「クラウド時代のアーキテクチャと人材育成」と題する講演を行なって頂きました。細川様にはIasa日本支部のアドバイザリー・ボードメンバーも担って頂いており、また、アーキテクチャ・デザインにおいては現場の課題解決から大規模システム設計、グローバルなトレンドや事例まで精通されており、アーキテクトとして第一線で幅広く活躍されています。 本講演では以下の点についての解説とデジタル人材像に対する展望を紹介頂きました。 クラウドでありがちな問題 ５つの代表的な問題事例の紹介。塩漬けクラウド（レガシーをスパゲッティ状態のままクラウドに移行）、部門毎のSaaSサービスの乱立のため連携が出来ない、期待した効果（アジリティ）が得られない、現場の負荷が減らない、いずれの課題も解決されずコストだけは上がった、等 これらの根本原因は、クラウドに最適化されたアーキテクチャの不在のままクラウド化を行なった結果である アーキテクチャのトレンドと特徴 ４種類のアーキテクチャの代表例について、５つの観点（ビジネスロジック、データベース、デプロイメント、可用性、アジリティ）から比較があり、クラウド環境にはマイクロサービス・アーキテクチャとの親和性が高い どのアーキテクチャを採用するかは、業務分類と関連システムの現状整理を行なった上でIT部門と業務部門が認識を合わせ、どの様な構成がビジネスに役立つのかの全体アーキテクチャ(To-Be)を描く事が重要 適切なアーキテクチャを実現する設計論とは？ ドメイン駆動設計の特徴として、業務毎の特性と役割を整理した上で全体をシンプルなサービスの集合体として最適化させる設計手法である ドメインとサブ・ドメイン、境界づけられたコンテキスト、コンテキスト・マップを通じて業務間の関連性と独立性、対応関係が整理された設計が可能になる マイクロサービス実現のアーキテクチャ マイクロサービスの特徴として、複数のサービスが分散環境で連携しながら全体サービスを実現しているため、従来のモノリシックな単一なアーキテクチャ内でサービスが完結する点が大きく異なる 分散システム環境は、CAP定理によって「一貫性、可用性、分断耐性の３つを同時に満たすことは出来ない」という前提の上で成り立っており、マイクロサービス・アーキテクチャでは一貫性を妥協し可用性と分断耐性を重視する傾向がある （筆者注：CAP定理：分散システムは「一貫性、可用性、分断耐性」の3つの保証のうち、同時に2つの保証を満たすことはできるが、同時に全てを満たすことはできないという定理） 現行システムからどの様な移行ステップを経てどのアーキテクチャを目指すのか、移行パスの選択肢と検討すべき課題 クラウド時代のデジタル人材像 IT部門にありがちな悩みの事例紹介 業務にもデジタルにも強い二刀流人材を目指そう」とのテーマの基、次の３つの具体的な提言 1) 現場部門でアーキテクトを育成する 2) IT部門だけでなく、現場部門を含めたデジタル教育 3) エンジニア以外もクラウド認定資格を取得する クラウド時代のアーキテクチャと題する講演をその周辺の課題や移行パスを含めて解説頂きました。その中で「アーキテクチャの採用についてはIT部門だけではなく業務（経営）との認識合わせを通じて全体アーキテクチャの共有が大切」が印象に残りました。 デジタル人材育成については、ITと業務部門関係者の両者が「業務とデジタルの二刀流を目指す」に取り組む事によって、その組織ではDXの取組を加速する機会と場が広がり全体として大きな原動力になるのではと感じた次第です。 3名の講演者による貴重な講演に続いて、Iasa日本支部代表理事・松井よりIasa日本支部の活動紹介がありました。出版、啓蒙セミナー、勉強会、アニュアルイベント等を通じてBTABoK（旧ITABoK）の普及と専門職としてのITアーキテクト育成支援の活動概要の紹介がありました。 終わりに.. 今回のカンファレンス参加者のアンケート結果では、今後のBTABoK （旧ITABoK)の啓蒙やセミナー開催、ITアーキテクト育成・教育コンテンツの提供への期待が高い事が示されておりました。アンケートへのご協力有り難うございました。 今回の講演者3名の方にはこの場をお借りして厚く御礼を申し上げます。2023年度もIasa日本支部アニュアルカンファレンスを開催する予定ですので、ご参加をお待ちしております。 Iasa日本支部のWebサイト： https://www.iasa-japan.org/ ― 　終わり　ー

プロジェクト・アプローチとプロダクト・アプローチ 今回はBTABoKのオペレーション・モデルから、Products & Projects (以下P&P) のご紹介です。プロダクトとプロジェクトとならべたとき、プロジェクトの帰結がプロダクト、という関係がまずは思い浮かびます。これは、世の中に存在しないプロダクトは買えませんが、それを生み出すためのプロジェクトは買うことが出来る、ということにもなります。ありていにいえば、まだ無いプロダクトが欲しいときの「おカネを出す理由」がプロジェクト、ということもできるわけですね。P&Pはこのような、ビジネスケースで一時的な支出を正当化する方法を「プロジェクト・アプローチ」と呼んでいます。本文中リンクで紹介されている記事では「プロジェクト・モード」とも呼ばれています。 プロジェクト・アプローチは、有形のプロダクトに対しては必須です。ITでもプロジェクト・アプローチはおなじみで、特にITを有形のモノ、つまり償却資産に対する設備投資として扱うケースでは良い結果が得られるでしょう。P&Pでは、かつてプロジェクト・アプローチがITでも上手く行っていた理由を「多くのシステムがよく理解されていて、進化が遅い手動のビジネスプロセスをデジタル化していたから」と述べられています。ひとくちにビジネスプロセスといっても様々で、制度会計のように時代が変わっても変えられない、または変えてはいけないものも多く、それらをいちどにデジタル化するケース、たとえばERP導入などではプロジェクト・アプローチが現在でも主流であると言えます。 もちろん一方で、カスタマー・エンゲージメントのように変えることができる、また変えなければならないビジネスプロセスも存在します。さらにはこれだけテクノロジーが進歩、普及してくると、デジタル・マーケティングのように、そもそもデジタルでないと成り立たないビジネスプロセスも必要とされるようになってきます。しかもテクノロジーは進歩し続けるので、これらのビジネスプロセスも絶えず変化してゆきます。こういった状況では「プロジェクト・アプローチによって出来るプロダクトの償却期間」＞「プロダクトの経済寿命」ということになってしまい、これでは商売に勝てません。それで代わりに普及してきたのが「アジャイル・アプローチ」です。プロジェクト・アプローチでは、プロジェクト・チームはプロダクトが出来たらそこで解散ですが、アジャイル・アプローチではアジャイルチームは最初のプロダクトを生み出した後も、ビジネスやテクノロジーの進化に合わせて、プロダクトの経済価値を継続的に高めていきます。また、ソリューションに対するそもそものニーズが消失するなどして、プロダクトの存在意義自体が無くなったときは、そのようなプロダクトは早々に引引き揚げて、別のプロダクトを用意することになります。 プロダクト・オーナーとアーキテクト P&Pでは、アーキテクトの責任はアジャイル・アプローチによるプロダクトの継続的進化と「自然に一致」する、と述べられています。なぜならアーキテクトは「アーキテクチャ上の決定において、移行、総所有コスト、品質属性、システムの寿命などについて常に考えなければならない」ためです。 特に大きな、あるいは複雑なビジネスになればなるほど、アーキテクトの役割はますます重要になります。アジャイルチームが直接生み出すのはテクノロジー・プロダクトで、小さな、または単純なビジネスであればテクノロジー・プロダクトは同時に、直接ビジネス価値を生み出すビジネス・プロダクトでもありますが、大きな、あるいは複雑なビジネスとなると、ビジネス・プロダクトとテクノロジー・プロダクトとの関係は複雑になります。その例としてP&Pでは、「ビジネス・プロダクトを構成するビルディング・ブロックとしてのテクノロジー・プロダクト」「ひとつのテクノロジー・プロダクトの複数のビジネス・プロダクトによる共有」「ビジネスおよびテクノロジー・プロダクト間のライフサイクルの差異」の3つが挙げられています。 テクノロジー・プロダクトとビジネス・プロダクトとが常に1対1の関係であるなら、アジャイルチームにとってはアジリティの観点からは理想的ですが、ビジネスが拡大するにつれて膨大な重複が生じ、無駄なコストが膨らんで (これも有る意味複雑化と言えるでしょう)、結局ビジネスとしての競争力を失い、やがて立ち行かなくなってしまいます。そうなるとビジネス・プロダクトのライフサイクルもそこで終了することになります。 テクノロジー・プロダクトを生み出すアジャイルチームを指揮するのはプロダクト・オーナーですが、彼らと共同作業でアーキテクト上の正しい判断を導き、このような複雑性を減らし続け、プロダクトのビジネスバリューを高め続けて行くことが、アーキテクトの責任の一つであるといえます。 ビジネス、テクノロジーを問わず、プロダクトは「立ち上げ」「成長」「成熟」「衰退」の4つのフェーズをたどることがP&Pでも示されています。アーキテクトはまず、各プロダクトがそれぞれどのフェーズにあるのかを見極め、また異なるフェーズにあるさまざまなプロダクトに対し、フェーズごとにことなるフォーカス (例えば立ち上げフェーズなら提案されたイノベーションの受容度、成長フェーズなら技術負債の返済見込みなど) に基づいて、さまざまな助言をプロダクト・オーナーに与え、また異なるプロダクト間のトレードオフや利害関係、優先順位などを複数のプロダクト・オーナーの間で調整するといった重要な役割を担います。 事業はプロダクトかプロジェクトか P&Pではあまりプロジェクトについてはふれられておらず、実質的には「プロジェクトよりプロダクト」といった内容になっていますが、そもそも事業 (エンタープライズ) という概念は、両方の側面を含むものです。エンタープライズは「継続的なプロダクトの集合体」「プロジェクト・イベントの連続」どちらにも見立てることが出来ます。あるいはそれらが組み合わさって一体化したものがエンタープライズ、と捉えるのがより正確なのかも知れません。いずれにせよ一つだけ確実に言えるのは「プロダクトの集合」も「イベントの連続」も、放置すればやがて「発散」するものなので、それをエンタープライズという一定の構造に収束させ続けるには、アーキテクトという仕事が必要、ということだと思います。 Iasa日本支部は、このようにビジネスに欠かせない役割であるアーキテクトのコミュニティとして設立されました。プロのアーキテクト、これからアーキテクトを目指される方、アーキテクチャに興味がある方はぜひ info@iasa-japan.org にお問い合わせください。

前回までのコラムでは、BTABoKにおける全体像（下図参照）のうち最も外側にあたる層（アウトカムモデル）のエコシステムやエンゲージメントなどについて解説してきましたが、今回はオペレーティングモデルの層にあるガバナンスについて、見ていきたいと思います。 BTABoKではガバナンスを以下のように定義しています。 "ガバナンスとは、組織を管理するための枠組みを提供するシステムである。誰が意思決定を行い、誰が組織を代表して行動する権限を持ち、組織とその人々がどのように振る舞い、実行するかについて誰が責任を負うかを明らかにするものである。 ガバナンスとは何かについては多くの定義がありますが、ここでは、組織が一連の規範、価値観、および方針に従って運営されることを可能にする構造とプロセスの枠組みであるとしています。 さらに、ガバナンスを強める必要のある組織について述べており、強さによってアーキテクチャのあり方が影響されるとしています。 これらの規範、価値観、方針は、組織や組織が関与する産業部門に特有のものである可能性があります。例えば、規制の厳しい事業分野の組織は、ガバナンスの枠組みも強固である可能性が高いのです。なぜなら、不適切な業務や意思決定の結果が深刻なものになる可能性があるからです。 医療、製薬、原子力、銀行などの分野を考えてみると、不適切な意思決定の結果、人命が失われたり、多額の金銭的損失が生じたりして、より高い範囲の経済問題につながる可能性があります。 ガバナンスは同じ理由でアーキテクチャにも適用され、組織におけるガバナンスの強さは、事業分野とリスクによって決定されると思われます。また、アーキテクチャがしっかりしている組織はガバナンスがしやすいので、アーキテクチャの良し悪しもガバナンスにとって重要であります。 そして、良きアーキテクチャが、組織そのものをしっかりしたものにするとも述べています。アーキテクトが組織やそのガバナンスにも大きな影響を与えることとなるのです。もう少し、ガバナンスとアーキテクチャについての論述を見ていきましょう。 アーキテクチャの実践においては、優れた倫理観とプロフェッショナリズムの文化を推進するために、効果的なガバナンスが重要です。良いガバナンスを実行することで、ステークホルダーが期待する水準で業務を遂行する信頼できるアーキテクチャを実践することができます。 ガバナンスは、アーキテクトがアーキテクチャを開発する際の意思決定を支援するものであります。ガバナンスは、アーキテクチャに関する与件の理解を容易にし、アーキテクトが重大な悪影響を及ぼす誤った意思決定をしないように支援します。 ガバナンスが、アーキテクトが守るべきレギュレーションを示してくれ、正しい方向に導いてくれると述べています。BTABoKでは、ガバナンスはステークホルダーのビジネスに合わせ柔軟に発展させる必要があるとも述べています。 ガバナンスの枠組みは、確固たる基準と原則を促進するだけでなく、ガバナンスが実用的であることを保証するために、ステークホルダーからのフィードバックに基づいて、柔軟に発展させる必要があります。早い段階からステークホルダーと関わることで、より押し付けがましくないガバナンスが形成され、より広く受け入れられるようになります。 アーキテクトの役割は、アーキテクチャがガバナンスを考慮し、ビジネスの目的と一致するようにすること、そして結果として実装がアーキテクチャに準拠するようにすることです。 ガバナンスの必要性についての論述を見てきましたが、ガバナンスの行き過ぎにより、組織が"警察国家 "のような状況となることについて警告を発しています。 ガバナンスは、組織が適切な意思決定を行うために利用されます。しかし、ガバナンスの実践が不適切だと、「警察国家」のような文化が形成される可能性があります。 ステークホルダーは管理されていると感じ、なぜポリシーやプロセス、アーキテクチャに従わなければならないのかがわからなくなる可能性があります。 良いガバナンスを実践するには、組織がガバナンスを伝え、動機付けする必要があります。これは、メンタリングとトレーニングによって実現できます。 ところで、ガバナンスはアジリティにおいては、足かせとなるとの言説もありますが、逆にBTABoKでは、役立つと考えられています。 アジャイルの実践では、ガバナンスがマイナスとみなされることがあります。これはおそらく、意思決定をできるだけアジャイルチームに近いところに置くという原則に反するからでしょう。しかし、ほとんどの業界では、各チームが組織全体に影響を与える決定に責任を持つと考えるのは非現実的です。 ガバナンスがうまく機能すれば、意思決定プロセスにおいてチームを支援し、コミュニケーションのための構造とプロセスを提供することで、アジリティを促進することができるようになります。 ここまで、ガバナンスとアーキテクチャについての関係を中心に見てきましたが、ガバナンスにおける主体と客体の構造を明確にすることと責任の所在の重要性について述べています。 どのような組織においても、戦略や目標を、ソリューションアーキテクチャや全社的なアーキテクチャなど、組織内のさまざまなアーキテクチャと整合させることが重要です。これを促進するためには，誰が意思決定を行い，誰が責任を負い，誰が実行に責任を持つかについて，明確な構造が必要です。 これがないと、アーキテクチャ作業を主導し、一連の首尾一貫したアーキテクチャを提供することが困難になる可能性があります。また、責任と説明責任に関する明確な仕組みがなければ、利害関係者の信頼を得ることが難しく、意思決定を本来の動機まで遡ることが難しくなるかもしれません。 組織のガバナンスが良い状態に保もたれていることは、アーキテクトにとっても必要条件となります。より良くするには企業単独では限界があり、業界としての基準や規範も必要となります。BTABoKでも以下のように指摘しています。 ガバナンスでは、アーキテクチャの開発における作業の指針として、基準や規範を示すことができます。たとえば、倫理的基準、環境基準、技術基準などです。これらは組織に固有のものではなく、業界標準とみなすこともできます。 規制のある業界では、規制への準拠がビジネス上重要であることが多いため、これらの基準や原則は厳しいものになる可能性があります。したがって、アーキテクトがアーキテクチャのガバナンスの意味を理解することは、非常に重要です。 以上のようなことからも、アーキテクトはガバナンスの観点からも所属する組織を越えて、知見を広げることが求められています。そのひとつとして、Iasa日本支部の活動に参加いただき、各方面の方々との交流を深めて頂ければと思います。昨年度から継続しています「ArchiMate」の勉強会や2023年度から予定しています「ビジネスアーキテクチャ」や「UI/UX」についての勉強会への参加をお待ちしています。最後までお読みくださりありがとうございました。

これまでBTABoK解説シリーズとして、エンゲージメントモデルを構成するサブモデルを解説してきました。まずはおさらいを兼ねて、それぞれのサブモデルの概観を振り返ってみます。 アウトカムモデル 円環の外側にあるアウトカムモデルは、ビジネスの全構成員が達成したいことをまとめたもので、デジタルアドバンテージに関連するビジネス全体の目標です。 オペレーティングモデル アーキテクチャの実践における主要な活動、技術、ツール、手法です。アーキテクトがより良い仕事をするための有用な情報源となります。 バリューモデル 価値分析や測定に関するビジネスとエンジニアリング双方の共通概念を扱います。 ピープルモデル アーキテクト個人の能力（コンピテンシーモデル）を組織化するための手法、役割定義、ツールです。 アーキテクチャ実践 価値あるアーキテクチャの実践を定義します。エンゲージメントモデルの中核思想そのものです。 これらを昨年1年を通して見てきたわけですが、それぞれのサブモデルとその諸概念（プロセス、手法、ツールと技術）の情報量は膨大なので、より深く理解するにはさらなる学習と実践が必要となるでしょう。また、膨大な知識体系であるがゆえに、途方に暮れてしまう方もおられるかもしれません。Iasa日本支部では定期的に勉強会を開催し、参加者の皆さんとエンゲージメントモデルを学んでいますので、是非参加いただければと思います。一人だけでBTABoKのサブモデルや諸概念をバラバラに眺めていても見えてこないこともあります。本コラムでは、多くの方にとってのハマリポイントを解説したいと思います。具体的には以下の2つです。 ・エンゲージメントとは、結局何なのかよくわからない ・多くの概念（プロセス、成果物、手法、ツールなど）があるが、どうつながるのかわからない あらためてエンゲージメントモデルを俯瞰し、それぞれの問いを考察してみたいと思います。 ＊＊＊＊ １．結局、エンゲージメントモデルとは何なのか エンゲージメントモデルの目標とは、「ビジネス技術戦略を実現するためにアーキテクトチームの活動を最大限に活用すること」でした。扱われているのは、「アーキテクトチームの役割」「アーキテクトチームの活動、成果物、ツール」「その実行によってもたらされる企業が達成する成果」です。 ここで重要なことは、アーキテクトチームがデジタルトランスフォーメーションの主要な推進者ではありますが、唯一の当事者ではないという点です。デジタルトランスフォーメーションとは、組織レベルでの総合力戦です。少数の優秀なアーキテクトチームだけで、そのような変革を進められません。協調こそが必要です。そして、協調はエンゲージメントなくして成り立ちません。エンゲージメントとは、何かに対する参加や関与、信頼関係の構築、またはそのような関係を維持することを指します。BTABoKでは「エンゲージメントは、従業員や顧客など、さまざまなグループとの関係において重要である」と述べられています。エンゲージメントが高いグループは、より満足していると感じることが多く、その結果、より多くのエネルギーを注いで仕事やビジネスに取り組むことができます。また、エンゲージメントが高いグループは、より信頼関係が築けるため、協力関係を円滑にすることができます。 BTABoKはこういうことも述べています。「成熟度の低いアーキテクトチームはビジネス・リーダーとの関わりが薄く、ほとんど読まれたり参照されたりしないドキュメントや成果物を作成し、アーキテクト自身もビジネスとの接触が限られていることが多いことがしばしばである」。これは、国内組織の多くにもあてはまるのではないでしょうか。私自身も今まで多くの「孤立するアーキテクト」を見てきました。こうした歪みは、デジタルトランスフォーメーションを阻害します。 「エンゲージメントとは共感すること」「エンゲージメントの第一のルールは人に関わるということ」とBTABoKは述べています。逆の見方をすれば、エンゲージメントを声高に強調しないといけないくらい、多くの組織でエンゲージメントが危機的な状況にあるのかもしれません。 組織のあらゆる階層に、エンゲージメントは存在します。左図はあくまで私のイメージですが、BTABoKエンゲージメントモデルを俯瞰すると、３つのレベルでエンゲージメントを捉えているように思います。アーキテクトチームのレベル、組織全体のレベル（ex.ビジネス部門とテクノロジー部門）、対顧客のレベルです。ピープルモデルは第1のレベルであり、主要な概念に「Extended Team」があります。バリューモデルは第2のレベルが対象となり、「Objetives」「Value Methods」などで組織の共有価値を形成します。こうしたレベルのエンゲージメントが出来ていてこそ、オペレーティングモデルのアーキテクト手法やプロセスが組織全体のビジネス価値を志向し、その結果として顧客エンゲージメントを中心としたアウトカムモデルが具現化できます。BTABoKエンゲージメントモデルからこうしたエンゲージメントの連鎖を理解することが重要と考えますが、皆さんはいかがでしょうか。 ２．諸概念（活動、成果物、ツールなど）を、どう組み合わせればいいのか？ エンゲージメントモデルには、アーキテクトがケイパビリティを開発し、成長するために役立つ多くの実践的な活動が含まれています。では、これらの活動の全てを実践する必要があるのでしょうか？ BTABoKはそれを推奨していません。BTABoKの考え方は極めてアジャイルであり、「Think Big, Start Small, Move Fast（大きく考えよ、小さく始めよ、早く行動せよ）」というアプローチを推奨しています。必要最低限な活動から開始すれば良いのです。とは言え、必要最低限な活動とはどこまでを含めるのでしょうか？結局は自分の頭で考える必要はあるにせよ、手引きは欲しいところです。 BTABoKでは、エンゲージメントモデルの特定の活動をThe Red Threadで例示しています。小規模なソリューションや製品の場合、製品が価値を提供し組織の技術戦略や成果と整合していることを確認するには、一般的にこの程度で十分と述べられています。ここではシーケンシャルなフローのように表現していますが、決してウォーターフォール型の活動と考えているわけではありません。これらの活動の多くは、複数のチームメンバーが指導・参加し、同時進行、反復的に行われると理解してください。以下で、それぞれの活動を簡単に説明します。 The Red Threadの導入 Threadは、トレーサビリティ、厳格な意思決定、実際のビジネス成果に対する価値管理を提供する最小限の活動のステップです。これは、最小限のサイズ/複雑さの要件をもつ企業内のすべての製品/プロジェクトに適用される最小限のアーキテクチャであるべきです。 OKRs 特定のケイパビリティと企業に関する成功と目標の測定値を導き出すために使用される手法です。 BusinessCase 製品/プロジェクトのメリット、コスト、考慮事項を体系化したものです。ITABoKでは、NABC（ニーズ、アプローチ、ベネフィット、考慮事項）と呼ばれるLeanなビジネスケースを使用しています。 Requirements アーキテクトが関心を持つのは、構造的な問題（主に品質属性）、価値（測定可能な利益とコスト）、制約（標準、コンプライアンス、リスク）に影響を与える要件です。 Options BTABoKでは、設計に役立つオプションと技術的な影響を与える領域を含むモダンアーキテクチャランドスケープを用意しています。 Decision 意思決定はアーキテクチャの核心です。BTABoKは、意思決定をより簡単に、より適切に、よりタイムリーに行うことに重点を置いています。意思決定は、要件、品質属性、ビュー、構造、複雑さ、およびアーキテクチャの記述に関連します。 Quality Attributes アーキテクチャの構造と品質属性要件に関連する、アーキテクチャの横断的な関心事です。 Viewpoints アーキテクトが意思決定や設計パラダイムを変えてアーキテクチャを見るための、さまざまな方法を提供します。ビューの利用は、優れたアーキテクチャ思考とコミュニケーションの特徴です。 アジャイルDevOps BTABoKはアーキテクトが設計の前段階だけではなく、デリバリー時に積極的に関与することを推奨します。アーキテクトはビジネスチーム、プロジェクト、製品、価値の流れに積極的に関わるべきです。 Usage and Value BTABoKでは、システム展開後の振り返りにおいて、OKRに対するダッシュボードで測定された使用状況情報を評価することを推奨しています。 ＊＊＊＊ 昨年末の日本経済新聞で「エンタープライズアーキテクトが米国の人気職業として急上昇」という記事が掲載されました。また、IPAから公開のデジタルスキル標準では主要な人材類型としてビジネスアーキテクトがあげられています。このように世の中ではアーキテクトに対して、期待と注目が集められつつあります。アーキテクトはその期待に応えるべく、エンゲージメントを育み、ステークホルダーとの協働活動を充実させていきたいものです。Iasa日本支部では引き続き、BTABoKをテーマとした勉強会やガイダンスとなる情報発信を行っていきたいと考えています。今後のIasa日本支部の活動へのご参加、ご協力をよろしくお願いいたします！

今回のコラムでは、BTABoKの成熟度モデルについてご紹介します。 成熟度モデルは、組織のアーキテクチャ・プラクティスと、デジタル・アドバンテージに対する影響を評価するために、BTABoKにおいて新しく盛り込まれました。成熟度モデルは、アウトカム、エンゲージメントの成熟度およびアーキテクチャ実践者（チーム）の能力の３つの観点の理解からとらえることができます。 本コラムでは、特に価値ベースの成熟度モデルについて、その成熟度の評価項目および成熟度レベルの概要を概説します。 本成熟度モデルでは、価値のデリバリーの観点から組織を見ており、アーキテクトがチームとして機能し、アーキテクチャのフェーズを経ながらプログラムが成長することを評価しています。以下に評価項目の概要を示します。 エンゲージメント アーキテクトとエンタープライズの相互作用。アーキテクトの専門領域やその活動の適用。 シェアホルダにおける投資 プロフィットセンタとしての技術への投資の認識と実際の投資。 シェアホルダ価値 創り出されたシェアホルダにとっての価値。 技術コスト 技術の価値のためのすべての要素における新規開発及びメンテナンスのコスト。 技術の価値 技術がどれくらいシェアホルダ価値に対して貢献するかの算出、総額、レポーティング。 プロジェクト＆プログラムの成功 プロジェクトの成功と技術の価値との関連に関する測定方法。 戦略との統合 戦略の計画とデリバリーに、アーキテクチャとITがどれくらい含められているか。 パートナー・エコシステム パートナーにとっての価値とその統合において、技術がどれくらい、またどのような形で含められているか。 組織の満足度 ビジネス目的に向けた技術への支援やアーキテクト等の役割への支援に対する認識や評価。 ガバナンス 戦略ゴールに向けた継続的な実行マネジメント。 本成熟度モデルは、全体的な成熟度レベルに対し、これらの評価項目それぞれがどのような成熟度を示すかが具体的に示されています。 まず、低い成熟度であるレベル１の場合だと、各項目がどのような成熟度になるか、見てみましょう。 図１　価値ベース成熟度モデル　レベル１ 一方、高い成熟度を示すレベル３では、各項目はどのような成熟度を示すでしょうか。 図２　価値ベース成熟度モデル　レベル３ BTABoK3.0のサイトでは、レベル１と３の間のレベル２における成熟度も解説があり、より詳細な学習をされたい方は、是非以下のサイトへアクセスして内容をご確認ください。 https://btabok.iasaglobal.org/maturity-model/

2022年11月4日(金)に開催された「アニュアル・カンファレンス2022」の各講演で使用した資料です。

はじめに 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”として多数掲載されています。バリュー・フォーカスな意思決定をリードするアーキテクトを指向する皆さんは是非一度覗いてみて下さい。