「Iasa日本支部アニュアルカンファレンス2021」 講演の主要テーマ 事前のご紹介 2021年10月 Iasa 日本支部 梶川　哲生 シリーズで掲載している今回のコラムでは、来たる2021年11月5日に開催するIasa日本支部主催「アニュアルカンファレンス2021」の講演の主要テーマと関連する背景等について先行してご紹介します。（Iasa日本支部イベントのご案内http://iasajapan.org/anual-conf-2021.html） 社会全体が本格的なデジタル活用と革新の時代を迎えつつある今日、DXの根幹を担う「アーキテクチャ」の理解とその取組み方如何で、DXの取組みを成功裡に継続的に具現化していけるのか、または、期待に反して成果が見えない取組みで終息してしまうのか、その分岐点となる重要な鍵を各方面で活躍されている講演者をお招きし、それぞれの立場でメッセージを発信して頂きます。本コラムでは、公開済みのイベント掲載情報を補足する形で各講演者のプロフィールと講演内容について紹介させて頂きます。 講演１. なぜEAがDXを加速するのか？ 〜 DXの本質とEAによる推進手法 〜 講演者：　山本　修一郎 様 最初に登壇頂く山本様は、現在名古屋国際工科専門職大学 情報工学科教授、及び、名古屋大学 名誉教授を担っておられます。ソフトウェア工学，要求工学，EA, DXなどの研究に基づく独自の知見と経験をお持ちで、政府機関の数々の施策や委員会のDX分野でのオピニオン・リーダーとしても活躍されています。（経済産業省のデジタルトランスフォーメーションに向けた研究会委員（2018年）、デジタルトランスフォーメーションの加速に向けた研究会委員(2020年)、その他多数の要職を歴任） 本講演では，山本様ならではの知見に基づいたDXの取組みに於いて共通する本質的な問いとその見解をご紹介頂きます。最初の論点として、 ① DXでなぜEAが必要なのか ・日本と世界のEAの違い ・デジタルケイパビリティとは何か ・ケイパビリティベースプランニングとは何か ・ダイナミックケイパビリティとは何か についてお話し頂きます。この中で「ケイパビリティ」という言葉は日頃馴染みが薄い読者の方も多いかも知れません。ここでは、DXの取組みを通じてその成果を継続的に創出する上で重要な「企業や組織が持つ、全体的な組織的能力、あるいは、企業や組織が得意とする組織的能力」(Wikipedia)とご理解下さい。ケイパビリティについてDXの観点から山本様の展望は大変興味深いところです。 更に経営者の方々に最も関心のあると思われるDX取組みの際の実際的な課題として、’DX人材の育成’, ’儲かるDX’ の論点に加え、現在世界的に関心が高まっているSDGsイニシアティブとの関連について、’SDGsとの両立’は出来るのか、についても氏の見解をお話し頂きます。 ② DXに取組む上での課題 ・石垣型経営からジョブ型経営への移行をどうするか ・ＤＸ人材の育成をどうするか ・儲かるDXをどうするか ・SDGｓとＤＸをどう両立させるか 最後に、より詳しく探求されたい方向けに氏の著書の紹介の中でその内容と背景等も触れて頂ける予定です。 ③ 著書『DXの基礎知識』（近代科学社Digital）の紹介 山本様にはDXの核心に迫る大変興味深いテーマと論点を取り上げて頂いております。是非当日の講演をご期待下さい。 講演２. 「DX時代におけるCX/UXの重要性と事例紹介」 〜 良いCX/UX、悪いCX/UXとは何か、その違いは利用者中心であるか否かに尽きる 〜 講演者： エスディーテック株式会社CEO 川端　一生 様 ２番目の講演は、エスディーテック株式会社CEO川端 一生 様にご登壇頂きます。川端様が2015年に創業されたエスディーテック社のホームページにはその企業理念として 『「Design Engineering」のプロフェッショナルチームです。デザインとエンジニアリングの分業ではなく、統合された「Design Engineering」により、⻑く愛される「ヒトとモノ」そして「ヒトとコト」のインターフェースを⽬指さしています。』 と記載されています。(エスディーテック社HP https://www.sdtech.co.jp/) 川端様の講演では、以下の要旨でお話し頂きます。 『多くのITシステムの開発において、機能品質だけが追求され、利用時品質は着目されていない。この講演では、CX/UXのベースとなる利用時品質について解説し、利用者中心の開発を行うための考え方である「人間中心設計（ISO9241-210）」の紹介と解説を行い、機能品質と利用時品質を高いレベルで兼ね備えるITシステムを実現するために、上流の企画・設計フェーズにおいて、ITアーキテクトとCX/UXデザイナがチームで取り組む必要性を解説する。』 講演では要所で事例も紹介頂けます。私達Iasa関係者の気付きとしても、従来のEAの視点に加えてCX/UXもアーキテクチャの構成要素として捉え、その設計を意識的に行う事がDXにも必須である、と思っております。まさに「DesignをEngineeringする」が意味している事では無いでしょうか？ Iasa日本支部の掲載済みコラムで、EAとCX/UXの関連性について解説をした記事がありますので、こちらもご覧頂いておくと本講演の理解がより深まると思いますので是非ご利用下さい。。 コラム（vol.23）DX 時代のエンタープライズアーキテクチャを考える～EA がビジネス変革と CX／UX をつなぐ！～ 講演3. 「BTABoKはアーキテクチャの実践にどの様に変化をもたらすか？」 〜 ステークホルダー主導のアーキテクチャの実践のフレームワークBTABok〜 講演者：IasaGlobal ファウンダー兼 CEO Paul Preiss様 (英語による講演) ３番目の講演は、Paul Preiss氏（ポール・プライス氏）による講演です。プライス氏は、世界最大級のエンタープライズおよびITアーキテクト協会であるIasaGlobalのファウンダー兼CEOです。(Iasa日本支部は、IasaGlobalの日本担当地区の支部になります) Iasa Globalは、テキサス州オースティンにあった1つのユーザーグループから、2021年現在は25カ国以上に支部を持つ国際的な組織へと発展しました。プライス氏の創設時からの一貫したビジョンは、’効果的な教育、資格、倫理観を備えた世界で通用する ’アーキテクチャ専門職’ を普及させ、企業の戦略と実現を支援する事’です。自らエンタープライズ・アーキテクトとしても活躍されており、企業の技術戦略の最適化の実践を通じて貢献しています。また、数百ものイベントで精力的に講演し、コロナ禍に置いても世界中のアーキテクトを対象としたカンファレンスやトレーニングを開催しています。(IasaGlobalホームページ: https://iasaglobal.org/) 今回のプライス氏の講演の最大のトピックは、過去10年以上にわたりIasaGlobalが公開し改訂してきた’ITABoK (IT Architecture Body of Knowledge / ITアーキテクチャ知識体系)’ の名称とスコープを変更し、’BTABoK(Business and Technology Architecture Body of Knowledge / ビジネス＆テクノロジー・アーキテクチャ知識体系)’ とリニューアルした事です。対象スコープをIT視点からビジネス視点も包含する内容に明示的に拡大した背景や理由、更に今後の展開についても本講演で紹介されますのでご期待下さい。 今回のプライス氏の講演の要旨としては、以下の内容をお話し頂きます。 『アーキテクトやアーキテクトチームの目標は、ビジネスや顧客に価値を提供することです。BTABoK(旧ITABoK)は、これを可能にする実際のツールとテクニックの大きな飛躍を指し示すと同時に、より成熟したアーキテクチャのプラクティスを開発しています。BTABoKは当初から、プロセスや単なる成果物ではなく、人を中心に設計されています。長い間待ち望まれていた3.0では、ビジネスとテクノロジーの両方の観点から価値を提供するために、アーキテクチャのプラクティス（チーム）を結びつけることができるようになります。これは、あらゆる規模の現代のビジネスにおいて絶対に必要なことです。』 (BTABoK v3英語ドラフト版: https://itabok.iasaglobal.org/) また、以下の実践的な方法についての紹介があります。 企業のアーキテクチャ的に重要な要件からソフトウェアの最小単位の決定まで、設計上の意思決定を最大化する方法 最小限の努力で最大限のステークホルダー・サクセスを実現する方法 統合、リファレンスアーキテクチャー、フレームワークなど、あらゆるレベルのスコープでパターンを適用する方法 共通の価値観や信頼関係の問題に直面せず、成功するアーキテクチャ・チームを計画し、構成し、実現する方法 これらの実践については、フォーチュン100社の多くの企業で採用、適応され始めている事も付け加えておきたいと思います。 終わりに.. 本項では、来たる2021年11月5日に開催するIasa日本支部主催アニュアルカンファレンス2021の３講演のテーマと関連する背景等について補足する形で紹介させて頂きました。 当日の講演は事前登録のみで無料でご参加いただけます。この貴重な講演の機会をご活用頂ければ幸いです。 Iasa日本支部イベントご案内：http://iasajapan.org/anual-conf-2021.html 注記：本コラムで紹介した講演要旨の補足内容と実際の講演内容が若干変わる場合があります。予めご了承下さい。 ー　終わり　ー

2021年11月5日(金)に開催された「アニュアル・カンファレンス2021」の各講演で使用した資料です。 講演 1. なぜEAがDXを加速するのか 〜 DXの本質とEAによる推進手法 〜 名古屋国際工科専門職大学 情報工学科 教授 名古屋大学 名誉教授 山本 修一郎 様 講演資料はこちら 講演 2. DX時代におけるCX/UXの重要性と事例紹介 〜 良いCX/UX、悪いCX/UXとは何か、その違いは利用者中心であるか否かに尽きる 〜 エスディーテック株式会社　代表取締役社長 川端 一生 様 講演資料はこちら 講演 3. BTABoK’はアーキテクチャの実践にどの様に変化をもたらすか？ 〜 ステークホルダー主導のアーキテクチャの実践のフレームワーク BTABoK 〜 Iasa Global ファウンダー 兼CEO Paul Preiss 様 講演資料はこちら

2019年10月30日(水)～11月1日 (金)に開催された「The 8th BITAS Executive Series 2019」の各講演で使用した資料です。 当日参加された方には閲覧用のパスワードをメールにてご案内させていただきましたが、パスワードを紛失された方や当日参加されていない方で資料をご覧になりたい方はこちらのお問い合わせ窓口からその旨ご連絡いただければ閲覧用のパスワードをご連絡させていただきます。

2018年11月30日(金)に開催された「アニュアル・カンファレンス2018」の各講演で使用した資料です。講演１.と講演３.の資料には閲覧用のパスワードを設定させていただいております。 当日参加された方には閲覧用のパスワードをメールにてご案内させていただきましたが、パスワードを紛失された方や当日参加されていない方で資料をご覧になりたい方はこちらのお問い合わせ窓口からその旨ご連絡いただければ閲覧用のパスワードをご連絡させていただきます。 講演 1.『グローバル化 & IT人材育成の取り組み 〜デジタライゼーションに向けて〜 』 日本たばこ産業株式会社 CIO 引地 久之 様 講演資料はこちら 講演 2.『Introduce Recent Trends of DX in Asia』 Iasaアジアパシフィック, ファウンダー兼会長, Aaron Tan Dani 様 講演資料はこちら 講演 3.『より豊かな社会を築くマイクロソフトの最新テクノロジー』 日本マイクロソフト株式会社 CTO 兼 マイクロソフトデベロップメント株式会社 社長 榊原 彰 様 講演資料はこちら

前回に引き続きBITASのハイライトを取り上げたいと思います。今回は、「デジタル・エンタープライズ・アジリティ」について述べていきます。 BITAS に参加するにあたっての予習ということで、ハイライトの２番目に掲げている「デジタル・エンタープライズ・アジリティを促進するクリティカルスキル」の前提知識として位置付けてください。 【参考】 BITASプログラムハイライト イノベーションを促進し、継続的な変革を推進するための方法 デジタル・エンタープライズ・アジリティを促進するクリティカルスキルの重要性 現実世界のデジタル化のケーススタディ紹介とウォークスルー デジタルビジネスを推進するための、デジタル・カスタマージャーニーマッピング IT をビジネスにとって戦略的に重要なものにするビジネス・アーキテクチャ ヒューマン・ダイナミクスの複雑さを管理し、理解する上でのアート (技能) と科学 成功するプロジェクト実施のためのビジネス要件アーキテクチャ デジタルの混乱から競争上の優位性をもたらす、ビジネスチャンスへの変換 日本企業への現地訪問を通しての DX の取り組みと企業文化の理解 他国の参加者とのつながり、ネットワーキングおよび現実世界のシナリオの共有 ビジネスニーズにより迅速に対応するため、システムを構築する現場では、アジャイル開発が普及しつつあります。しかし、企業や事業部レベルでアジャイル開発を行うためには、中長期的な情報戦略や大規模なプロジェクトの管理、PMやアーキテクトの役割など従来手法を中心に体系化されていたものを革新する新たな取り組みが必要となります。 取り組みのひとつとして、「アジャイルプロセスフレームワーク」と呼ばれるものが「エンタープライズアジャイル」という言葉とともに出てきており、その代表的なフレームワークが SAFeとDADのふたつです。 それぞれ、アーキテクトの役槍をどのように捉えているのでしょう。まずは、SAFe についてのアーキテクトの役割について紹介したいと思います。 企業戦略とシステム開発を一体化する枠組みである SAFe (Scaled Agile Framework) は、Dean Leffingwell 氏が中心になって開発したアジャイルプラクティスとリーンプラクティスを企業全体に広げるのを支援する業界標準のフレームワークです。 SAFe の導入によって、企業や事業部は、組織横断的な一貫した戦略を持つことができ、開発メンバーの仕事に関する満足度を高めることができ、より良い品質のシステムを提供することが可能となります。 SAFe では、システム開発における関係者を以下のように定義し、システム・アーキテクトには、ビジネス戦略に基づいた、技術的なビジョンと実装シナリオのディファインを期待しています。 平たく言えば、ステークホルダーが主張するビジネス要求やシステム要求を、業務要件とシステム要件として具体化し、アーキテクチャーをデザインすることであるかと思います。 この定義で登場するアジャイル・リリース列車 (ART) は、SAFe 独特のものです。SAFe ではプログラムレベルでのプロダクトオーナーに相当するプロダクト管理者という役割やプログラムレベルでのスクラムマスターに相当するリリース列車エンジニアという役割を設けています。 メタファーとしての列車は、ダイヤに従って駅を出発し、目的の駅に到着する。この列車が仮想の組織を構成し、必要な資源（プロトタイプ、ソフトウエア、ハードウエア、ドキュメントなど）は貨物として列車に載せられる。最終的には、リリースという形で列車は目的の駅に到着するということになります。 次に、DAD (ディシプリンド・アジャイル・デリバリー) における役割を見ていきましょう。 DADを考案したのは、IBMの Scott Ambler 氏と Mark Lines 氏です。DADにより、2006年に1 年ごとだった製品リリースは、2012年には3ヶ月ごとになり、すべての製品が当初計画の納期を守るといった効果を得ています。 DADフレームワークは、以下のような役割セットを提案しています。 上記にある“主な役割”と”補助的役割”との違いですが、主な役割とは、すべてのDADプロジェクトで、状況にかかわらず現れる役割のことで、補助的役割は、状況に合わせての対応や一時的な局面での対応で、必要とされる役割です。DADの特徴のひとつとして、アーキテクチャの課題を扱っており、それに応じたアーキテクチャオーナーという役割を提示している。(スクラムは、アーキテクチャを扱わないので、そのような役割がない) DADにおけるアーキテクトの立ち位置は、以下のディシプリンドアジャイルのプロフェッショナルの役割から読み取れます。 エンタープライズアーキテクトやポートフォリオ管理者といった、全社レベルのプロフェッショナルと密に協力して働く 全社標準のガイドラインを採用し準ずる。 組織内のアセットを活用する。アセットには既存のシステムやデータソースが含まれる。 組織のエコシステムを、アセットをリファクタリングすることで、拡張する DevOps 文化を適用する 学習したことを他のチームと共有する。 適切なガバナンス戦略を採用する。オープンで正直なモニタリングが含まれる DADでは、エンタープライズ対応に徹し、全社レベルの価値観によって正しい方向に向かうことを良しとしているようです。エンタープライズ・アーキテクトを中心としたアーキテクトチームが、DADの効果を上げる重要な役割をはたすことが求められています。 SAFe も DADにしても、アーキテクトの役割が、重要な位置を占めることが期待されています。いずれにしても、「デジタルエンタープライズアジャイル」の分野は、今後とも発展し、アーキテクトに期待されることも大きくなっていくことが考えられます。Iasa日本支部でもウォッチしていきたいと思います。是非、情報共有のご協力をお願いします。 追記） SAFe は、今後普及が進むと考えられており、ITABoKV3.0 でも紹介しています。参考にしてください。(日本語訳は今秋刊行予定です) https://iasaglobal.org/itabok3_0/engagement-model-overview-3-0/lean-and-agile- adoption/agile-and-architect-roles/roles-and-personas-mappings-to-safe/

このコラムでは、Iasa日本支部が標榜している「DX時代のエンタープライズアーキテクチャ」について、いくつかの見識を紹介し、考えていきたいと思います。 まず、デジタル時代のアーキテクチャをどうイメージするかですが、IBM社が提示した以下のチャートが参考になるかと思います。 図１：https://bp-affairs.com/news/2018/08/20180827-7910.html　より デジタルテクノロジーの進展は、従来の業種、業態の枠を破壊し、テクノロジーを戦略的に活用していかにビジネスモデルを変革できるかが、重要な課題となっています。ここでは、ビジネスモデル変革を考える上で、従来のフィジカルな顧客接点と、デジタルな顧客接点の双方を最適化していくことが不可欠だとしています。 このデジタル時代の次世代アーキテクチャは、企業が自社だけでなく外部との連携による新たなデジタルビジネスを実現する「デジタル変革」へと進化するためのロードマップを提示しています。 また、このチャートでは、顧客視点でのデジタル化と事業体におけるデジタルサービスが連携し、ビジネスサービスとデータサービスに繋がっています。このアーキテクチャを絵にかいた餅ではなく、実現性のあるものとして描くことが出来たときから、その企業でのDXは始まるのではないかと考えます。 さて、アーキテクチャをデザインするためのアプローチですが、その指針が、デジタルトランスフォーメーション研究会委員も務められた名古屋大学の山本修一郎教授が以下の図で示されています。 以下、「1. DX戦略をどうするか（1）－DXの目的と定義－」　山本修一郎から抜粋。 以下、抜粋ですが、詳しくは以下を参照ください。 https://www.bcm.co.jp/solution-now/cat-solution-now/2020-03_2539/ 現在の企業をデジタル企業に変革することがDXである。そこで経営、事業、ITシステムに分けてDXをみてみると、上記のようにDXを分解できる。すなわち、DXには、経営変革、ビジネス変革、IT変革がある。経営変革では組織、文化・風土ならびにビジネスモデルを変革することによりデジタル経営を実現する。 　ビジネス変革では、業務プロセスならびに、事業能力をデジタル化することにより、デジタルビジネスエコシステムを実現する。ここで、事業能力はビジネスケイパビリティのことである。ビジネスケイパビリティは欧米では企業が提供するビジネスを明確化するために用いられる基本的な考え方であり、事業能力をマップ化することにより、創出価値の大小で優先順位付けることができる。現行の事業能力マップが定義されていれば、デジタル化の脅威を受けるのはどこか、デジタル化による創出価値が高いのはどこかを明確にでき、優先順位の高い事業能力からDXを推進することで、DXロードマップを作成できる。 　IT変革では、現行のITシステムのモノリスアーキテクチャをマイクロサービスアーキテクチャによる適応型ITシステムに刷新することにより、データとデジタル技術を活用できる変革即応アーキテクチャを実現する。マイクロサービスアーキテクチャは、事業能力と対応する独立性の高いマイクロサービスを疎結合することにより、事業能力の変化に際して対応するマイクロサービスだけを変更できる。これに対してDXの足枷になっている老朽システムは機能要素が複雑に密結合しているモノリスアーキテクチャで構築されているため、特定の機能変更が老朽システム全体への影響を探索して確認する必要があり、ビジネス変化に即応できない。ITシステム刷新が必要な理由はここにあり、単に老朽システムをクラウドに移行すればいいというような単純な話ではない。 文中の事業能力（ビジネスケーパビリティ）とは具体的にどんなものでしょうか？それぞれの組織が定義していくものでありますが、定義するうえでは、ITABoKのビジネスアーキテクトのケイパビリティ定義が参考になるかと思います。ITABoK　V2デジタル版（P218～P267）を参照ください。 では、アーキテクチャを企業の財産として、整備し維持していくには、どうすれば良いのでしょうか？以下のような推進体制を構築し、アーキテクチャを進化させている事例を紹介します。それは、AMO（アーキテクチャ・マネージメント・オフィス）を組織して推進してする事例です。 AMOは、アーキテクチャマネージャーを中心として、ユーザー代表、ビジネスアーキテクトなどの専門領域アーキテクトで組織され、コラボレーションポータルサイトにメンバーが登録されます。 AMOにより、レビュー・承認されたアーキテクチャはポータルサイトに公開され、システム開発、運用、ユーザ等のプロジェクトにかかわるステークホルダーが参照することが出来ます。またＡＭＯは、常に数年先のアーキテクチャ青写真を描き、詳細な落とし込みは各現場組織に委ねるといった振る舞いも必要となります。 詳しくは、Iasa日本支部の中山理事のブログ「アーキテクチャ・マネジメント・オフィス（ＡＭＯ）」　https://www.it-innovation.co.jp/2016/08/29-004910/　参照ください。 アーキテクチャを描くには色々な方法がありますが、Iasa日本支部では、ArchiMateによる可視化を推奨しています。ArchiMateはThe Open Groupによって開発・維持管理されているエンタープライズ・アーキテクチャを記述するためのグラフィカルな言語であり、オープンな標準です。さまざまなプロジェクトやビジネスの利害関係者に関連するさまざまな視点を作成するために使用することができます。 ArchiMateは、AMOによるレビューやアーキテクチャの改善・維持に適しており、ステークホルダー間の共有が可能となると考えます。Iasa日本支部では、１回／月の勉強会を開催しています。Zoomでの参加となりますので、気楽に参加できるかと思います。詳しくはIasa日本支部　ArchiMate　勉強会　zoom_admin@iasajapan.orgＸまでお問い合わせください。 以上、筆者の「DX時代のエンタープライズアーキテクチャ」への思いと一にする考えのご紹介というコラムになりました。 まとめますと、 現状を把握し、アーキテクチャを描くとことから始まり 経営改革、事業改革、IT改革と進めながら AMOなどの体制の整備を並行して進めていくなかで 「ビジネスモデルの変革を起こし、エンタープライズアーキテクチャを進化させる」 ことになるかと思います。 ビジネスモデルの変革を伴う改革となり、その壁は高いですが、１年前のコラムで紹介した「今すぐにデジタルトランスフォーメーションの旅に乗り出さない組織は、混乱して取り残される危険性があります。」というアーロン（Chairman of Iasa Asia Pacific）の主張にあるように、事態は待ったなしの状況です。 カンファレンスや勉強会の開催などIasa日本支部の活動が、この「DX時代のエンタープライズアーキテクチャ」への道を切り拓くための一助となるよう努めていきたいと思います。何卒、よろしくお願いいたします。

原文:　Iasa global HP掲載記事 https://iasaglobal.org/Public/TOPICS/Becoming-Digital-Transformers.aspx 日本語訳について：英語原文のDeeple翻訳を行い、Iasaの文脈と背景から一部捕捉、訳註を付け加えました。出来るだけ原文の意図を反映する様努めました。 今、私たちの専門的な職業には多くの恐れと不確実性がありますが、それは当然のことです。過去10年から15年の間に行われたアーキテクチャの実践、特にエンタープライズ・アーキテクチャは死も同然でした。私の観察では、アーキテクチャは実際には活動しておらず、まるでゾンビのように人の脳を探して組織をうろついていたのだと確信しています。"エンタープライズ・アーキテクチャー”とEAのガバナンス思考、そして場合によってはビジネス・アーキテクチャーやアジャイル・トランスフォーメーションからの発想が、世界中のアーキテクトの従来の価値観を打ち砕いてしましました。そして、一方でCIO、CTO、その他のエグゼクティブ達は、意思決定を支援するための企業の包括的なイメージではなく、今すぐに何らかの価値を提供することを求めています。 個人的な話になりますが、私はEAチームをケイパビリティ向上や業務に関連したデリバリーの役割にアサインした20数社を超える組織に会ったことがあります。その組織は競争に勝つための人材を求めています。彼らが求めているのは、「推進のためのオーナー」であり、「ゲームに精通している人」、「リーダー」であり、真の変革を実現できなければ解雇されることを厭わない人材です。アーティファクトが価値のあるツールではないと言っている訳ではなく、それだけなのです。 これらの点は概ねIasaが過去15年間にわたって広めて来た事に準じています。認定されたEAプログラムを持っていないのには理由があります。正直な所、今まで言われてきたようなEAが実際のところ可能なものかどうか少々疑問に思っています。某病院の医局長は今でも患者さんを見ています。そうでなければ、患者からすると長く医局長をやっていて欲しくないでしょう。では、10年間、顧客への何らかのインパクト、収益へのインパクト、運用面での測定可能なインパクトをほとんど何も提供してこなかったアーキテクトがいた場合、どうすべきでしょうか？私個人の考えでは、そのようなアーキテクトをデリバリーの役割に移動し、デリバリーができない場合は他の役割を検討して貰うのが良いと思います。デジタルトランスフォーメーションはここから始まり、私たちはここに到達する必要があり、また今回もその枠組みに留まる必要があります。しかし、世界に50万人から100万人の様々なアーキテクトがいる中で、どうやってこれを行えば良いのでしょうか？ アーキテクチャの本質は’文書化’ではなく、’変化させる事’と言えます。チームとして最も重要な事を見つけ出し、自分自身と組織や顧客に対して「私はこれを実現させます」と宣言する事です。もし、それが実現したなら、私達は何かしら報いられ、そうで無い場合は何らかの責任を負う事になるでしょう。 アーキテクチャとは、実践であり、スキル・セットであり、その組織にとって最も重要で価値のあるデジタル・イニシアティブ (取組み) を見つけ出し、それを実現する事でその組織は貢献の評価を得る事ができるのです。私達Iasa Globalは、これらのスキルを学び、実践し、強化し、認定するためにIasaのカリキュラムを構築しています。 ここからは、あなたがデジタル変革者になりたい場合は、何をすべきか (そして何をすべきでないか) を説明します。 1. すべてのプロジェクトに取り組もうとするのをやめる。 私は自分自身の記事を盗作していると感じるほど多くの記事でこれを書いてきました。あなたのチームは、明らかに価値がある事を示すことができるプロジェクト/製品にのみ関与すべきであり、EAも同様です。将来的にEAの役割があるとすれば、かなり大きな割合の時間が実際のデリバリーに費やされるでしょう。おそらく、より大きなものに限定されるかもしれませんが。 2. ガバナンスではなくメンタリングを重視する。 ガバナンスはガバナンスであるべきです。アーキテクトは、ガバナンスを管理するのではなく、ガバナンスに従うべきです。チームで仕事をするのであれば、チームの成功の一端を担い、ゲームに参加すべきです。 3. 成功の第一の尺度を、再利用の度合いやコストではなく、利益、顧客、良き市民、またはミッションの測定に置く。 もしコスト削減の価値について語る場合、革新を行っているのではなく、財務チームの一員でしかない発言です。あなたの組織を成長させましょう。実際の顧客に影響を与えましょう (組織内には、実際の顧客というものは存在せず、それらは従業員と呼ばれています。彼らはチームのメンバーであり、真の顧客ではありません) 4. 組織の中で最高のエンジニアになろうとするのは止めましょう。 組織の中で最高のエンジニアになろうとするのは止めましょう。エンジニア達には良きも悪しきも担って貰い、その信用栄誉や責任も取って貰いましょう。(訳註：デジタル変革者を目指すなら、自身が優秀なエンジニアとして切磋琢磨するのではなく、エンジニア達にしっかり責務と責任を取って貰いましょう、と言う原文筆者の論点です。) 5. 最初に顧客や製品に直接触れるチームに焦点を当てましょう。 あなたのチームは、顧客や市民にフォーカスした活動にできる限りの時間を費やすべきです。イノベーションは常に顧客の近くで起こるのですから。 6. もしあなたのチームがビジネスケース (またはそれに相当するもの) を書いていなければ、あなたは変革者とは言えません。 アーキテクチャ・チームがイノベーションに焦点を当てているか、エンジニアリングに焦点を当てているかを見分ける最良の方法の1つは、彼らが書いた (他の影響を受けていない) ビジネスケースの数を尋ねることです。イノベーターはアイデアを持っていて、それを実現しています。今日からビジネスケースの執筆を始める事を薦めます。 7. 分野に関わらず、チームに必要なビジネススキルを身につけさせよう。 フレームワークやツールは忘れて下さい。デジタルビジネスモデルのビジネスケースを書けるようになり、それを提供したことによる顧客への結果を測定した人は、それが実践出来ています。最も安い労働力に頼っている場合は、細かいところまで交渉します。デジタル戦略を推進するにあたり、未熟な人材に頼っているのであれば、すでに失敗の道を歩んでいます。先ずは必要なスキルを身につけて貰いましょう。それはやや利己的に聞こえるかもしれませんし、そうかもしれませんが、我々(Iasa Global)はこのような事を伝え、時に組織を指導しています。私達に連絡下さい。(訳註：コンサルティング事業は、北米IasaGlobalで行なっています。) 8. データと情報からの示唆や発見を大切にする。 変革者は新しいビジネスに触れ、顧客、プログラム、イニシアチブ、戦略、製品、人、文化、そしてデータ、データ、データの中に身を投じます。これらをあなたの骨まで染み込ませて下さい。もしあなたがアイデアを思いつくために「ビジネス」の人が必要なら、あなたはビジネスパーソンではなく、「末端のスタッフ」の一部に過ぎません。私達はデータにアクセスする必要があり、それが最も難しい部分です。しかし、本当にそうしようと思えば、そこに到達することができます。持っているヒューマン・ダイナミクス (訳註：人間力学。ITABoKで定義するアーキテクトに必須の５つの柱の１つ) スキルを使用して取り掛かります。私の個人的なキャリアの中で最高のプロジェクトは、毎日営業チームとランチをしていたからこそ成功しました。ある日アイデアが浮かび、ビジネスケースを書き、それが採用された事でなんと私はチーフ・アーキテクトになった経緯があります。 9. 技術者であること、技術フォーカスである事、技術主導型である事を躊躇するのは止めよう。 世の中には、物事がどのように動くのか、なぜ動くのかを知りたがる人やそうでない人もいます。営業、財務、マーケティングに「ビジネス」がある理由の一つは、技術を理解したくなかったからという理由もあるでしょう。今日では、営業、マーケティング、財務、オペレーションはテクノロジーなのです。自分が本質的に技術者ではないと思わせようとするのは止めましょう。私の勘ですが、この記事を読んでいる人は多分誰もが家族が集まった際にはラップトップやタブレット、または他のデバイスのサポートを求められる人でしょう。私の勘では、あなたが家族のWiFiの設定を行い、クリスマスのためにAmazonやGoogleで買い物をする人です。おそらく、ラスベリー・パイのスタックを持っている事でしょう。ファイナンスの人は、ファイナンスがビジネスの成功を助けるための主要な手段であることを恥じていません。変革者になりたければ、デジタルの部分も含めてやる事です。もしあなたの組織で「我が組織では、アーキテクチャはテクノロジーの事ではない」という人の話を耳にしたら、(アーキテクトとして) それを正すか、次の雇用機会を速やかに検討した方が良いでしょう。 10. 誇大広告はでたらめだ。 マイクロサービスがSOAより優れているわけではありません。クラウドはデータセンターより優れているわけでもありません。Webベースはメインフレームより優れているとは断言できません。AIや機械学習はあなたのビジネスそのものを救うことは出来ません。購入は構築よりも優れている訳ではありません。Javaは.NETよりも優れている訳でもありません。アジャイルはウォーターフォールよりも優れている訳でもありません。テクノロジー、プロジェクト管理プロセス、トレンドはあくまでツールです。それらはある状況には適用されますが、別の状況には適用されない事もあります。楽観的な悲観論者になるか、もしくは悲観的な楽観論者になる必要があります。選択肢が数字でより良いことを示すことができなければ、それはあくまで一つの見解に過ぎません。そして、私達はどの意見に価値があるかを知っています。 11. あなたのRFPおよびあなたの仕事の記述書を変えよう。 アーキテクチャの専門職を価値のクリエーターに変換する最も簡単な方法は、調達時のRFPを見直し、関わるすべてのプロジェクト、プログラムまたは取組みの一部として、複雑さや契約の価格に基づいて経験を有した認定されたアーキテクトを要求することです。これを行う事であなたの組織には基本的なRFPの記述の変更以外に何らコストは発生しませんが、結果はどうなるでしょうか？もし、すべてのベンダーが、あらゆるプロジェクトに高度なスキルを持ったデジタルビジネス・ストラテジストを派遣したとしたら一体どうなるでしょうか。ここからが本当の変化の始まりであり、真の専門家と一緒に仕事をすることで取り巻く業界が変わる事でしょう。 最後の注意点として、EAチームがデジタル・トランスフォーメーション・チームとして再編成を始めている際には、最新の注意が必要です。ビジネス、情報、インフラストラクチャ、ソフトウェア、ソリューション・アーキテクチャを実際に行うことに集中する必要があります。もっと重要なことは、もし彼らが何か価値あるものを提供することにコミット出来ていないとすると、その場合は先に述べたIasaが推奨するような事を行なっていないという事になります。 もしかしたらTOGAFに基づく事は行っているのかもしれませんが。(これは少々言い過ぎですが) (訳註：IasaはTOGAFを主要なフレームワークとして参照、推奨しています) SOAプラットフォームをマイクロサービスプラットフォームとして再分類したり、ホスティングサービスをクラウドサービスとして再分類したりしているベンダーを知っています。テキサスでは、これを「豚に口紅を塗る」と呼んでいます。(訳註：IasaGlobal本部はテキサス州に在ります) 彼らの仲間入りをしてはいけません。企業を変革する前に、自分自身を変革する必要があるのです。ガバナンス、ドキュメンテーション、企業や組織のアーキテクチャの設計を行なっているだけでは、変革者としての成功は望めないのです。 (日本語訳終わり) 記事紹介＆訳者コメント：現在、市場にはトランスフォーメーション (DX) の取り組み方やソリューションの事例紹介、関連の情報やセミナーが数多く存在しますが、今回ご紹介した記事のIasaGlobalの筆者の論点は、先ずは自身の意識と行動の変革を行わずして、DXに貢献出来るアーキテクトを目指しDXの具現化に貢献することは難しい、とのメッセージを発しています。DXに参画する「人」がそのケイパビリティを持たずしてどうやって実際のビジネスに貢献できるのかを論じています。本文の後半にある11箇条を読まれた方は、何かしら思い当たる考え方や振る舞いもあったのでは無いでしょうか？然しながら、それは当然の事と思われます。 と言うのも、私達の組織や環境のみならず、既存のスキルセットや個人のマインドセットを持ってしても、テクノロジーの進化のスピードとその先にあるデジタル化されたエコシステムが秘めた組織と社会へのインパクトの可能性を十分に捉え切れていない訳ですから。本当の変化は一見破壊的に見える事も含めて、まだ始まったばかりの夜明け前の状況にも思えます。皆さんはこの「デジタル変革者になるためには」の記事からどの様な事を思い描かれたでしょうか？　コメントや感想などお寄せ頂ければ幸いです。

2020年10月8日(木)に開催された「アニュアル・カンファレンス2020」の各講演で使用した資料です。なお資料には閲覧用のパスワードを設定させていただいております。 当日参加された方には閲覧用のパスワードをメールにてご案内させていただきましたが、パスワードを紛失された方や当日参加されていない方で資料をご覧になりたい方はこちらのお問い合わせ窓口からその旨ご連絡いただければ閲覧用のパスワードをご連絡させていただきます。 講演 1. デジタルIT時代に適応するデジタル・アーキテクチャと世界の最新動向 〜デジタル時代のアーキテクチャ・フレームワーク AIDAF、 エコシステム構築の時代へ〜 慶應義塾大学大学院 政策メディア研究科 特任准教授 兼 米国カーネギーメロン大学院Visiting Research Fellow 増田 佳正 様 講演資料はこちら 講演 2. 産業アーキテクチャの重要性について 〜「デジタルアーキテクチャ・デザインセンター」設立の背景と今後の展望について〜 IPA 社会基盤センター アーキテクチャ設計部 河野 孝史 様 講演 3. ビジネスアジリティをスパイラルアップ 〜幸せのためにビジネス・アジリティを高めるエコシステム〜 デジタルビジネス・イノベーションセンター(DBIC）ディレクター 鹿嶋 康由 様 講演資料はこちら

今回はIasa APAC (アジア・パシフィック) のウェブ・コンテンツをご紹介します。Iasa APAC代表で、Iasa日本支部会員の皆様にもおなじみのアーロン・タン・ダニ氏が、エンタープライズ・アーキテクチャ (EA) の概要を5つの問いに答える形で解説しています。5回にわたる連載の最後の公開から一年を過ぎていますが、ITとあまり関わりのない専門外の方々などにもEAの意義を広く知っていただく上で参考になりますので、各回のエッセンスを私のコメントも交えご紹介したいと思います。 1. “What is Enterprise Architecture?” (EAとは何か?) ITABoKではITアーキテクチャを、「価値のあるテクノロジー戦略のデザインとその実現のアート(技能)もしくはサイエンス(科学)」と定義していますが、ここではアーロン氏はEAをオーケストラに例えています。総譜(スコア)はフレームワーク、楽器はテクノロジー、演奏家や指揮者はスキル、記譜法はノーテーションです。 ここでは、フレームワークにはザックマンやTOGAF、スキルにはITABoK、記譜法にはArchiMateがそれぞれ例として挙げられています。 EAとは何か、と尋ねられたとき、オーケストラのようなものである、というのが良い答えかどうかは難しいところでしょう。質問者のバックグラウンドにもよりますが、例えば「フレームワークは総譜にあたる」と説明されても、そもそもフレームワークを知らない人にはあまり意味が有りません。少なくとも専門外の方々に対する説明としてはあまり気の利いた説明の仕方では無さそうです。 しかしながら、個人的にはアーキテクチャの要素としてノーテーション、その例としてArchiMateが挙げられている点には注目したいと思います。「百聞は一見に如かず」で、まずはArchiMateビューのサンプルを見せて、「これは楽譜のようなものだ」といった説明をするのが良いのかも知れません。もちろんEAの広大且つ奥深い世界は一つのArchiMateビューだけでは表現できませんが、だんだんとそこから広げたり、掘り下げたりしていけばよいのです。 2. “Who needs Enterprise Architecture?” (誰がEAを必要とするのか?) この問いに対するアーロン氏の答えは比較的単純明快で、彼が挙げるところの5つの過ち、すなわち① ITとビジネスのコミュニケーション不全、② バラバラのシステム、③ 自動化への時代遅れなこだわり、④ ITとビジネスとの戦略不整合、⑤ ROIの対象ではなくコストセンターと見なされるIT部門の、どれか一つでも犯した人々は、誰でもEAの恩恵を受ける、というものです。 このうち、③ 自動化への時代遅れなこだわりは中々示唆に富んでいます。興味深いのは、これを「プロジェクト第一主義」と結びつけ、その「過ち」を、ざっくりとした「自動化」の要件に基づいて、スタート時点で既に予算やスケジュールを限定してしまうこと、と指摘している点です。 これは多くの企業ITが抱える問題の核心に触れた指摘ではないでしょうか。ITといえば自動化ということで、毎年様々な目的や種類の自動化ソリューションを買い集め、やがてシステム間連携ソリューションも買ってシステム間をメッシュ状に繋ぎ、挙句にそれらの経済寿命が次から次へとやってきて、技術的負債の増大が止まらなくなる、というのが多くの日本企業が陥っている現状ではないでしょうか。 恐ろしいことに、最初にソリューション・プロダクトを買ってしまい、あとで辻褄合わせに多額の費用を投じても、二進も三進も行かなくなったりするプロジェクトは、今日でも少しも珍しくありません。それが「プロジェクト第一主義」に因るものだと分かったとき、EAがその解決策となるとアーロン氏は主張しています。つまりEAの恩恵を受ける人とは、「ITプロジェクトが炎上したり失敗したりしたことがある人」だということです。そして世の中にはそのような人々は沢山おられるのではないでしょうか。 3. “When to implement Enterprise Architecture?” (EAをいつ導入するべきか?) ここでは「適応能力(“Readiness”)」および「成熟度(“Maturity”)」の二つの尺度が取り上げられています。 とはいえ文中では「図を参照」と書かれてはいるものの、その図は見当たりません。元記事を探してみるとアーロン氏の会社であるATD Solutionのブログ記事にたどり着きます。 記事によると、適応能力は複数の要素(“factor”)からなり、それぞれの要素は5段階の数値スコアで評価されます。全体評価はおそらくはスコアの平均で、0～1なら”Not Ready”、1～2.5なら”Partially Ready”、2.5～5なら”Ready”となるようです。 成熟度の尺度としてはTOGAFにも載っているACMMが紹介されています。「存在しない」「導入中」 https://iasa-apac.org/resources/ https://www.atdsolution.com/enterprise-architecture/article/when-to-implement-enterprise-architecture/ 「定義されている」「管理されている」「最適化されている」の、CMMIと同様の5段階評価です。 結論から言えば、タイトルとは全くかみ合っていません。どちらも既にEAプロジェクトが存在している前提での、その成果に対する評価です。成熟度モデル以前に、EAがそもそも普及していない現在の日本に当てはめてもあまり意味が無さそうです。 日本の場合、先の「EAは誰に必要なのか？」で挙げられた5つの「過ち」のいずれか一つにでも気づいたら、すぐに始めればよい、というのが答えになるでしょう。そもそもEAを始める上で費用は前提にならないので、たとえ疑心暗鬼でもとりあえず始めてみれば良いのです。 4. “Why Enterprise Architecture?” (なぜEAなのか？) 日本の端的に言えば「デジタル・トランスフォーメーションに不可欠だから」というのがこの記事の結論です。これだけならネットによくある紋切り型の謳い文句ですが、そこに至るまでの議論には注目すべき点があります。 まずアーロン氏は、ITベンチャーなどの「デジタル・ネイティブ」との対比として、普通の会社を「デジタル移民 (immigrants)」というユニークなことばで表現しています。「デジタル・トランスフォーメーション」とは「デジタル・ネイティブの生息域 (アーロン氏ではなく私の造語ですが、デジタル・ランドとでも呼びましょう)への移住、入植」といったイメージになるでしょう。一方、普通の会社の現在の生息域は、(これも私の造語ですが)、マテリアル・ランドとでも名付けてみます。マテリアル・ランドの住人が、デジタル・ランドに移住し、更にそこで成功をおさめれば、それが「デジタル・トランスフォーメーション」になるわけです。 問題は、マテリアル・ランドでの適応と進化に適していたやり方は、デジタル・ランドでは通用しないことで、それをアーロン氏は移民という比喩を用いて表現しているものと考えられます。何よりデジタル・ランドでの一番の価値は「知」であり、なんでもカネで買うことが出来たマテリアル・ランドの流儀は通用しません。マテリアル・ランドがかつてのように巨大な経済規模を誇っていれば「知」を買うことも出来たでしょうが、いまとなってはそれも叶いません。 つまり私たちにとってデジタル・トランスフォーメーションとは、必ずしも夢と希望に溢れた新しい「機会」を意味するとは限らず、むしろ慣れ親しんだ価値観や習慣から如何に脱することが出来るかという「試練」と捉えるべきなのかもしれません。 日本のアーロン氏はもう一つ、”Treating the enterprise (…) like a living organism”、つまり「企業は生き物のように扱え」と述べています。これも目からうろこで、アーキテクチャは静物画のように不変ではなく、生き物のように姿かたちを変えていくものだ、というわけです。 つまり、マテリアル・ランドに適応していた資産目録のようなアーキテクチャは、デジタル・ランドでは通用せず、デジタル移民は生き物のように柔軟で迅速なアーキテクチャを身に付ける必要がある、というわけです。 先述の「プロジェクト第一主義」こそ、「マテリアル・ランドの流儀」であり、それを捨てることなくデジタル・ランドに向かっても、成功どころか生存さえも危うくなりそうです。 5. Where to Start with Enterprise Architecture? (EAはどこから始めるか？) 先述の連載記事の最後です。どこから、という問いに対して「上から(トップダウン)のアプローチ」または「下から(ボトムアップ)のアプローチ」さらにはこのふたつを組み合わせたアプローチ、という3つの切り口で解説していますが、これもなかなか参考となる内容です。 トップダウンの出発点は「将来 (To-Be、またはターゲットとも呼びます)」です。一方ボトムアップは「現状 (As-Is、またはベースラインとも呼びます)」からスタートします。 トップダウン・アプローチは分析的、論理的で、一貫性、整合性の高い組織全体の構造をシームレスにデザインすることができますが、一方でハイレベルな戦略についての合意形成という時間のかかるプロセスが必要となること、現実にそぐわない、実現可能性の低いデザインになる恐れがあること、各専門領域を担当するドメイン・アーキテクトの創造性が損なわれる可能性があることなどの欠点の存在が指摘されています。 対してボトムアップ・アプローチでは、目下の課題に即応するための創造的、革新的かつ実用的なソリューションに取り組む機会をドメイン・アーキテクトに提供でき、その結果スモール・ウィン、クイック・ウィンが期待できます。但しそのスモール・ウィンが組織や企業全体の構造と、またクイック・ウィンが長期的な戦略やビジョンと、それぞれ整合しているかは事後に検証されるべきで、結果として大きな解離が認められれば、相応の時間やコストを掛けて是正措置を講じなければならず、全体で要する期間は結局トップダウンとあまり変わらない、という結末も有り得るでしょう。 アーロン氏はこの両方を組み合わせた「複合的なアプローチ」を用いることで、シームレスでアジャイルかつスピーディなアプローチによるデジタル・トランスフォーメーションが実現可能であると主張し、それをデジタルEAと呼んでいます。簡単にいえば、巨視的な構造はトップダウンで押さえ、微視的な構造はボトムアップで対処するアプローチ、ということになります。ここでも前項の「なぜアーキテクチャなのか？」で紹介された、ある種オーガニックな存在としてのアーキテクチャのイメージが連想されます。巨視的な構造はいわば「体幹」であり、その組織の「ストラテジックな特徴」を、また微視的な構造は「手足や感覚器」で、その「オペレーショナルな特徴」をそれぞれ示しているわけです。何しろ「デジタル・ランド」では環境変化が激しいので、「巨大な一枚岩の密結合システム」や「個別最適システムの寄せ集め」では進化どころか生存さえも覚束ない、と言えるでしょう。 6. EAの意義を伝えよう ご存じのとおり、アーロン氏は自社のブログやリンクト・インなどで活発に執筆活動を行っています。時折読んでみると、なかなか良いことが書かれていているのでお勧めです。 この記事ではつまるところ、企業や組織にとって、アーキテクチャといういわば形式知の方が、償却資産としてバランスシートに載っているITシステムよりも重要だ、ということを伝えています。 また、デジタル・トランスフォーメーションといった喫緊の課題は、IT資産の取得という旧来の方法では解決しない、ということを明らかにしています。 オールド・エコノミーでは資産の大小がビジネス規模を左右するので、時価の大きな企業の多くは資産規模も大きかった訳ですが、GAFAの時価が大きいのはIT資産を沢山持っているからだ、と考える人はいないでしょう。彼らの持つ知恵や知識と、それらを将来現実にする能力に価値が付けられているのであって、しかもそれらは彼らのバランスシートには載っていません。 アーロン氏を始め海外のEAコミュニティリーダーの多くにとっては、「自分の属する組織の未来を保証するのは、他者から買う償却資産ではなく、自分で描くEAである」ということは、既に「自明の理」なのかもしれません。 日本でも組織や企業のIT部門でも、将来それが同様に「自明の理」となるように、私もEAを広めるお手伝いに取り組んでいきたいと思います。 以上 ※ 本コラムについてのご意見ご感想お待ちしております。

Iasa日本支部では、これまで14回にわたり情報提供の一環としてコラムを配信してきました。今回からは、多くの皆様からの「米国本部のコンテンツを翻訳紹介してほしい」という声に応えるため、本部コンテンツを取り上げていきたいと思います。 Iasa米国本部はIasa Globalとしてホームページを開設しており、そこで多様なコンテンツを公開しています(註1)。コンテンツとして公開されているものは、カンファレンスの講演スライド、有識者へのインタビュー動画、技術記事やエッセイ等と多種多様です。 初回となる今回は、IasaのThought Leader（思索的リーダー）でもあるニック・ロザンスキー氏のインタビュー記事(註2)を取り上げます。彼は世界的に著名なアーキテクトであるとともに、日本語訳として出版されている「ソフトウェアシステムアーキテクチャ構築の原理」の著者でもあるので、ご存じの方は多いでしょう。 本稿はインタビュー内容を翻訳したものです。世界的な思索的リーダーが考えていることを少しでもお伝えできればと思います。 （インタビュー始まり） ■ あなたとあなたの仕事について教えてください 私の名前はニック・ロザンスキーです。この20年ほどアーキテクトとして働いています。 その長いバックロググラウンドには、1980年代半ばに開発者としてITの仕事を始めたことがあります。私は開発者として、（もちろん）設計者または要件アナリストとして、少しばかりプロジェクト管理の仕事をしてきましたし、アーキテクトとして約20年間働いてきました。 私がアーキテクトになることを決心したのはIT部門で出世し続けたかったからですが、多くの同僚みたいにマネジメント職志向ではいたくありませんでした。私の技術のバックグラウンドには、コンピューター科学の修士号とMSC（Master of Science）があります。 私はさまざまなテスト技術に取り組んできましたが、小さなシステムだけでなく大きなシステムや、企業規模のシステムで仕事をしてきました。ですので、専門家というよりゼネラリストです。数多くのことを少しずつ知っているといった感じです。まぁ、より多くのことを知っている領域が1つか2つありますが、いわゆる専門家ではありませんね。 ■ 最初にアーキテクチャについて考え始めたのはいつですか？ 1990年代後半、Sybaseプロフェッショナルサービスで働くことができたのは幸運でした。当時、SybaseとOracleでDBMS市場全体の約50%を占めていました。Sybaseには大規模なプロフェッショナルサービス組織があり、その中にアーキテクチャプログラムがありました。このプログラムには、アーキテクトのトレーニングや、アーキテクチャ関連の作業に使用できるさまざまな資料が含まれていました。 私はどういったキャリアに進むべきか考えていた頃、自身の仕事においてはテクノロジー的な要素に重きを置き続けたいと思っていたので、同僚のほとんどがプロジェクト管理に従事していましたがそれをしたくありませんでした。そこで、Sybaseを使用しているアーキテクチャプログラムのことを聞いたときそれに飛びつきました。そして私はSybaseの認定アーキテクトになりました。 Sybaseで取り組んだ仕事の多くには、アーキテクチャ的な側面がありました。今にして思えばアーキテクトと必ずしも言えるものではなかったかもしれませんが、システムの主要なコンポーネントがどのように連携しているか、そしてもちろんSybase技術を使ってクライアントの問題を解決するにはどうすればよいか、といった大きな概念を理解しました。 ■ ベンダーに所属するアーキテクトの倫理的側面をどうお考えですか？ それは非常に興味深い質問です。それに対する唯一の答えは、あなたが信じている製品のベンダーで働いているということだと思います。Sybase製品は非常に強力な製品セットでデータベースが非常に強力であり、他の関連するテクノロジーも強力だったため、Sybaseをソリューションとして顧客に推奨することについて何の懸念もありませんでした。もし、あなたが信じていないことを推奨するようにプレッシャーをかけられているなら、それを跳ね返さなければなりませんが、実際にはそれはとても難しいことですね。そのベンダーがあなたの日々の賃金を支払っているのですから、それに従う必要があります。 そう、それは興味深い質問です。もし自分が推薦している製品を信じていないのだとしたら、別の誰かのために働かなければならないのだろうと思います。 ■ 専門家としてのアーキテクトとはどの様な人とお考えでしょうか？ それは私はいつもこの質問を恐れています。しっくりくる答えを出すのはとても難しいです。外科医とは何か、エンジニアとは何かと尋ねられたらその質問に答えることができるでしょう。アーキテクトとしてそれをするのはとても難しいです。 システムのアーキテクチャは何か、という問いに対しての形式的な答えはあります。「システムを構成する要素とそれらの間の相互作用と情報の流れ」です。ほとんどの場で使われている形式的な定義ですが、人々が共感できるようなものではありませんね。 アーキテクトとは何か？アーキテクトとは、白紙の状態からシステムのアーキテクチャの定義をする人です。これも人の心に響く定義ではありませんね。外科医でしたら「病気を治し、死を免れるための手術を誰かの心臓に対して行います」と言えるわけですが、アーキテクトではそのようにはいきません。私がよくやるのは、“私がしていること”や“なぜ私がしていることが役立つのか”を説明し、最終的にアーキテクトとは何かを人々が理解してくれることを願うことです。 ■ では、何をしていて、なぜそれが役立つとお考えですか？ アーキテクトは何をするのか？アーキテクトはごく初期の段階で関わっています。ここでは、ソリューション・アーキテクチャに焦点を当てます。必要ならば、エンタープライズ・アーキテクチャについても説明します。 アーキテクトはプロジェクトのごく初期の段階に関与しており、また関与すべきです。初期段階では問題を抱えている上級の利害関係者がいます。解決する必要があるビジネス上の問題があります。彼らはそのソリューションがどのように見えるかについての考えを持っているかもしれません。アーキテクトが守らねばならない制約があるかもしれません。 私たちはMicrosoft WindowsやSAPを使用しています。それが何であれ、あなたができることを制限します。また、ソリューションがどのようなものになるかについてアイデアを持っているかもしれません。しかし、これらのアイデアは検証されておらずステークホルダーが利用できる状況にありません。アーキテクトが行うことはそこに到達することです。 利害関係者を特定します。ソリューションに対する彼らの関心ごとを特定します。利害関係者と協力し、プロセスへの参加を確実にするために何が必要か理解してもらいます。彼らの要求を確実に把握していることを確認し、ソリューションに向けて動き始めます。大きなホワイトボードを使って、ホワイトボードに枠や線を描き、最終的にはそれをソリューション・アーキテクチャにするのです。 しかしこれは問題の半分に過ぎません。すべての利害関係者に説明する必要があるからです。彼らがそれを理解し受け入れたことを確認してください。もちろん、それは反復的なプロセスです。なぜならあなたが知らなかったことを発見したり、あるいは利害関係者の1人がその方法で受け入れてはならないといったことを発言することもあるからです。もう一度戻って周りを見回し、最終的にはシステムのアーキテクチャが合意され、開発者や他の人に引き渡すことができるレベルまで文書化されるでしょう。これは、延々と続くアーキテクトの道です。 ■ アーキテクチャが継続的な開発作業としたならば、それにどのように対応しますか？ あなたの質問の意図に全く同意します。実際には、他の誰かが何かを始める前に、ある程度のアーキテクチャの基礎を作る必要があります。 ですから、少なくとも概要レベルのソリューション・アーキテクチャの骨組みのようなものを設計する必要があります。その中に主要な要素を含めます。そうしないと意味をなさないものをコーディングしてしまうからです。開発者はそれを使って作業を開始することができます。アーキテクトは、アジャイルかウォーターフォールかを問わずそのプロセスに関与し続けます。提案されたアーキテクチャのようなものを提供すると、開発者はコード、モジュールや構造などの観点からどのようなものになるかを考え始め、そのプロセスの一環としていくつかのものを構築したり、ステークホルダーとの継続的な関わり合いを始めたりします。 実際のところ、あなたはさまざまな方面の人たちと仕事をしているので、開発プロセスに関与し続けることはとても難しいことです。でも、あなたがそれに関与し続け、アジャイルなプロセスで対処し、リファクタリングや再設計などを行うといったことができるので、私はアーキテクトがプロジェクト全体を通して関与すべきであることに全面的に同意します。 ■ アーキテクチャの実践において、開発への関与がより増えると思いますか？ それはビルドの設計に移ったあと、あなたがアーキテクトとして何をしているかによります。私は、最近はそれほどでもないかもしれませんが、昔は設計やアーキテクチャにも関わっていました。そうでない場合、私はアーキテクチャを設計開発チームに任せます。 あなたは関与し続けなければなりません。それは個人的な関係がとても重要になるところです。ですので、私はアーキテクトとして多くの時間を会議や人との1対1のセッションに費やしました。ある領域で仕事をする時に私が望むことの一つは、主要な利害関係者全員と定期的なミーティングを設定することです。相手が誰であるかに応じ、週に1回、2週間に1回などです。彼らと一緒に座り、彼らが直面している問題にどう取り組んでいるかを話します。それはしばしば、あなたの注意を惹かねければならないようなアーキテクチャ上の問題点を、彼らとあなたが共有する瞬間となります。人と面と向かって接触し続けるのでなければ手遅れになるまで何かを発見することはできず、彼らが何かを作ってからそれが間違いであることを発見するだけとなります。 私にとっての課題は、今は開発者ではないということです。以前はかなり優秀だったのですが。最近では実際のところ深く技術に傾倒していません。JavaやC#のコードを書くよう頼まれることはありません。そこにおいて私に何ができるかという点、その状況における技術的な価値ということに関しては少し課題があります。これはすべてのアーキテクトが直面する課題だと思います。 ■ エンタープライズ・アーキテクトとソリューション・アーキテクトの関係を説明していただけますか？ 最も単純なレベルで言えば、エンタープライズ・アーキテクトとソリューション・アーキテクトの関係は、扱っている対象の範囲に過ぎません。つまり、ソリューション・アーキテクトとしては一貫性のあるソリューションを形成するシステム、あるいは2つか3つのシステムを扱うことになります。エンタープライズ・アーキテクトとしてはビジネス部門や組織の一部、あるいは組織全体を扱いますが、その場合アーキテクチャのコンポーネントは通常システムそのものであり、データ・ストアやその他の性質を持つシステムです。 あなたの質問に対して饒舌な答えをするならば、実際には両者はかなり違います。エンタープライズ・アーキテクトは明らかに、担当するステークホルダーのレベルがシニアとなる傾向があります。したがって、シニアIT管理者であるCIO、ビジネス・ステークホルダーはCEO、ユーザーはスポンサーのシニア・マネジメントである可能性があります。したがって、より抽象的なレベルで作業する傾向があり、受け答えする質問はより広範でかつ技術に特化されない傾向となります。ですから、エンタープライズ・アーキテクトとしては、ある特定の技術的な質問に対して答えを求められることは稀です。 もう一つの違いは相手の優先順位が違うことです。エンタープライズレベルでいえば、それは企業の戦略とビジョンに関することです。クライアントや顧客、ビジネスユーザーへのデリバリーに関することことです。予算や支出などの大きな問題に関することです。 私が思うに、エンタープライズ・アーキテクトの世界の方がソリューション・アーキテクトの世界よりもずっと大きな問題があると思います。より戦略的になる傾向にあります。つまり、エンタープライズ・アーキテクチャは、戦略的に優れた方向に組織を導くということです。一方、ソリューション・アーキテクトはより焦点を絞っています。システムを提供する必要があり、それを来年までにする必要があります。 ■ これから将来に目を向けたとき、アーキテクトはどこに向かうと思いますか？ いままで目立つこともなくあまり理解されてこなかったアーキテクトというものが、この10年ほどの間で変わってきているのを見て、私は非常に勇気づけられています。私が5年間携わってきたすべてのプログラムやプロジェクトにはアーキテクトがいて、最近も多くの採用活動をしてきました。ですが、すべてのプロジェクトがこれに取り組むには変化が必要であり、まだまだ長い道のりがあると思います。 この広い業界では、アーキテクトが何をするかについてほとんど意見が一致していないと思います。2人のアーキテクトにどんな仕事をしているのか聞いても、いく通りもの答えが返ってきます。私が見てきたような組織はそれを実現しようと懸命に努力しているので、アーキテクトが役割としてもっと確立され、アーキテクトが何をしているのかについてもっと明確で一貫性があるようにしたいと思います。そうしなければならないと私は確信しています。アーキテクトに対して本当に何を求めているのか分からないため、アーキテクトを募集するのはとても難しいのです。「私こそがアーキテクトだ」と言う人もいれば、「もっと広い範囲のことをしている」と言う人もいて非常に多様です。プロジェクトマネージャやC#の開発者やテスターを雇うのも難しいですが、合理的なコンセンサスがありますよね。それは変わらなければならないと思いますしきっと変わると思います。アーキテクチャは組織におけるキャリアパスとなり、人々がそこでキャリアを積むことに対して不安を感じなくなると確信しています。昔でしたら、人々の多くはこの役割を引き受けたくないと思ったでしょう。なぜなら、それがどこに向かうのかわからなかったからです。それは変化しており、今後も変化していくと思います。 テクノロジーが急速に変化しているのは明らかであり、インターネットやIOT、クラウドはその類のものです。この数年に気づいたことですが、古き時代にはソリューション・アーキテクトは全てのこと、サーバやネットワークやデータベースについて考えなければなりませんでしたが、現在ではそこにインフラストラクチャがあると仮定したうえで、専らアプリケーションとデータアーキテクチャに焦点を当てています。これは今後も続くと思いますし、その基準(bar)はさらに上がっていくでしょう。 次の10年で明らかに状況が変化すると思います。 （インタビュー終わり） いかがでしょうか。インタビューから伝わってくるのは、自ら推奨するソリューションやテクノロジーに対する彼自身の深い愛着、そしてアーキテクチャによって顧客の課題を解決するアーキテクトとしての信念と自負です。アーキテクトとして歩む道のりは、決して平坦なものではありません。プロジェクト初期のカオスな状況において、多くのステークホルダーと対話し、アーキテクチャデザインで秩序をもたらし、組織を前進させることにアーキテクトは関与し続けていくことが求められます。であるからこそ、深い愛着や強い信念と自負が不可欠なのだろうと考えます。また、全てのアーキテクトが直面する課題として、自らの役割や提供価値を変革していくことを常に意識していかないとならないでしょう。インタビューで語られるように、次の10年も変化の時代であり続けるでしょうし、その変化を牽引するのはアーキテクト自身なのですから。 今回はIasa米国本部コンテンツから、ニック・ロザンスキー氏のインタビュー記事をご紹介しました。本記事についてのご意見・ご感想をお聞かせください。 註） 1.“Videos,Articles,Content”,Iasa Global, https://iasaglobal.org/Public/Public/News/News.aspx 2.“Software systems Architecture with Nick Rozanski”,Iasa Global, https://iasaglobal.org/Public/News/Articles/Software-systems-Architecture-with-Nick-Rozanski.aspx

この新コラムのシリーズでは、来たる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/