検索結果

今回は去る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日本支部からも参加、聴講していきたいと思います。 ※ 本コラムについてのご意⾒ご感想お待ちしております。

Iasa 日本支部 理事　塩田 宏治 CITA-A, TOGAF®, DASSM®, SAFe®5 SPC, CBAP®, PgMP® アジャイルのアプローチが普及してきていることは、ITに関わる方であれば多くの方がご存知かと思います。ただアジャイルという言葉で紹介される内容が、１０人以下の１チームによるソフトウェア開発をどう迅速にデリバリーして価値を実現するのかという議論が中心となってきました。こうしたデリバリー中心の議論に対し、エンタープライズ視点から考えているエンタープライズ・アーキテクチャのコミュニティや、ビジネスの視点から考えているビジネスアナリシスのコミュニティなどでは、ビジネスまたは組織のアジリティが重要であるという視点から多くの議論がなされてきています。アジャイル・コミュニティにおいても、エンタープライズ・アジャイルの考え方が広がりつつあり、Disciplined Agile®やScaled Agile Framework (SAFe®)などのフレームワークが、徐々に日本においても関心を呼び始めています。こうしたエンタープライズ・アジャイルのフレームワークもビジネスアジリティを中心的なコンセプトに据えており、“アジャイル“の関心が、手段であるデリバリーから、目的であるビジネス（営利、非営利を問わない）にフォーカスを移しつつあることは意義あることだと考えられます。今回は、ビジネスアジリティという視点を踏まえ、ビジネスアーキテクチャとエンタープライズ・アジャイルの接点について考察したいと思います。 Iasaが提供しているBTABoK（ITABoK）は、エンタープライズ・アーキテクチャについて多くの知見を提供しており、ビジネスアーキテクチャも専門領域として解説されています。以下の図は、ビジネスアーキテクチャを深堀したBIZBOK®(Business Architecture Body of Knowledge)のモデルで、ビジネスアーキテクチャのコア要素を、ケイパビリティ、バリューストリーム、情報、組織と定義しています。コア要素も変化を伴いますが、例えばプロダクト、業務を実際に遂行するビジネスプロセス、施策であるイニシアチブやプロジェクト、さらには戦略と比べても、比較的安定したビジネスの構造として定義されています。 参照：https://en.wikipedia.org/wiki/Business_architecture この４つの要素の中でも、非常に重要な役割を果たすのがケイパビリティです。ケイパビリティは、ビジネスが何をするか(What)を示すものであり、“特定の目的や結果を達成するために、企業が所有、交換できる特定の能力（ability）やキャパシティ（capacity）”とされています。ケイパビリティと等しく重要な要素であるバリューストリームは、“組織がステークホルダ、またはある一連のビジネス活動の状況におけるステークホルダに対して、どのように価値を達成するかを視覚的に示すもの”と定義されています。例えば、資材調達者というステークホルダに対し、資材が調達されるというバリュープロポジションを提供するために必要なEnd-to-Endのバリューストリーム・ステージの流れがデザインされます。情報や組織なども非常に重要ですが、本日はケイパビリティとバリューストリームを中心に扱うことにします。 バリューストリーム エンタープライズ・アジャイルでもバリューストリームは重要なコンセプトとして登場し、エンタープライズ・アジャイルを導入するには、組織がどのようなバリューストリームで構成されているかということを発見するためのワークショップを行います。これは、機能組織単位ではなく、バリューストリーム単位に企業運営することが、ビジネスアジリティにつながると考えているからです。しかしながら、エンタープライズ・アジャイルのフレームワークはビジネスアジリティへのフォーカスを標ぼうしつつも、ソフトウェア・デリバリーに関する議論がまだまだ中心でDevelopment Valuestreamに焦点があたっており、Operational Valuestreamの議論は不十分です。組織としてのビジネスアジリティを達成するには、OperationもDevelopmentもどちらのバリューストリームもアジリティを実現する必要があります。 Operationalなバリューストリームにおけるビジネスアジリティに必要な考え方は、“ビジネスアジリティ・マニフェスト”(https://busagilitymanifesto.org/10-translations/23-bam-japanese)にも示されています。関心ある方はご覧いただければと思います。 ケイパビリティ バリューストリームが“どのように”するかを示しているのに対し、ケイパビリティは“何”をするか、できるかを示しています。バリューストリームの中の各ステージは、ケイパビリティによって機能します。ケイパビリティは部門などの組織に依存せず、組織全体でユニークに定義されるべきものであり、バリューストリームや組織などを超えて呼び出されるものになります。例えば製品を調達するバリューストリームにおいて、“アカウントと協議する”=>“契約を受け取る”=>“適格性を検証する”=>“契約を最終化する”などのバリューストリーム・ステージが想定されます。一方、関連するケイパビリティとして、“契約管理”といったレベル１のケイパビリティの中に、“契約ニーズ決定”、“契約適格性決定”、“契約リスク決定”、“契約条項決定”、“契約価格決定”などのレベル２ケイパビリティが含まれることでしょう。“適格性を検証する”というバリューストリーム・ステージは、“契約適格性決定”および“契約リスク決定”という２つのケイパビリティが発揮されることによって初めて業務として適正に遂行されます。また逆に、“契約適格性決定”ケイパビリティは、“適格性を検証する”ステージだけでなく、“契約を受け取る”ステージを遂行する際にも、受け取る時点での初期検証をするタスクを実施するために必要となるケイパビリティでしょう。つまりビジネスを“賢く”遂行するためには、活動の順番が決まっているだけではだめであり、その活動を実行する能力が何であるかを議論する必要があることを意味しています。 このようなケイパビリティの考え方は、様々なフレームワークでも触れられています。TOGAF®ではCapability-based planningという考え方が強調されています。PMI®のプログラムマネジメント標準では、プロジェクトが生み出すものは所産（result）ですが、プログラムは能力（Ability）とベネフィットを生み出すことをマネジメントすると定義されています。プログラムレベルが、戦略やビジネスで実現したいこととITシステムなどのソリューションで実現することを、間でつなぎ整合を担保する重要な役割となっています。重要なことは、ビジネス戦略を実現するためには、どのようなソリューションが必要かをすぐに考えるのではなく、どのようなビジネスモデルやビジネスケイパビリティが必要かをまず定義する必要があるということです。ビジネス組織は、デジタルやITソリューションそのものが欲しいわけではなく、ビジネス組織が抱えるビジネス課題を解決したいと考えています。そのビジネス課題を解決できるかどうかを判断するには、ビジネスや業務レベルでどのような能力が必要となるかを考える必要があります。なぜならば、ITソリューションが、ビジネス組織が手に入れたいビジネスケイパビリティを100%実現できる場合は、ITソリューションがあたかもビジネス課題をダイレクトに解決するように見えますが、常にそうではありません。ITソリューションでは必要なケイパビリティが十分には獲得できない場合は、ビジネス組織はITではない別のビジネスソリューションも導入し、それによって手に入れたいビジネスケイパビリティ全体を実現するからです。私たちがビジネスの課題を解決しビジネスの価値を生み出すことに焦点を当てるのであれば、どのようなソリューションを提供するかだけを考えるのでは不十分なことが分かると思います。 こうして考えてくると、ケイパビリティとソリューションにおける機能との間に関係があることが認識できます。ソリューションを開発するエンジニアには、機能そのものだけでなく、その機能の“Why”を意味するどのようなケイパビリティを開発しようとしているのかを理解することが求められます。 従来のビジネスとITの関係は、ITはビジネスの写像またはビジネスのイネーブラーであるといった見方でした。これは、あたかもビジネス（例えば業務プロセス）とITシステムが別々にあり、ITシステムは業務プロセスを実行するための道具であるという見方です。そこから、業務プロセスや要求を考える人はビジネス組織の人で、ITシステムを作るのはIT部門の人という無意識の境界が生み出されています。こうした状況に対し、最近のビジネス環境の変化を受けて、ITがイネーブラーではなくビジネスそのものになってきたという言い方も時々耳にします。ITやデジタル技術を用いてソリューションを提供する人のミッションが、ソリューションを作ることではなく、顧客やビジネス組織の人と協働してビジネスを作りビジネスの問題解決を提供することだとするのであれば、技術でどのようなケイパビリティを作ることができ、ケイパビリティの集合としてのビジネスそのものの姿（モデル、アーキテクチャ）についての議論に、エンジニアも参加していく必要があることを意味しています。 一方エンタープライズ・アジャイルのフレームワークでは、ケイパビリティはどのように描かれているでしょうか。SAFe®を例にとれば、ポートフォリオレベルでイニシアチブに相当するエピックを定義し、Agile Release Trainというプログラムレベルのバーチャル組織でフィーチャーを主に扱い、チームレベルでユーザーストーリーを主に扱います。１つのAgile Release Trainでは扱えない大規模なソリューション・デリバリーを行うケースに対し、Large solution configurationという特定の全体像（Big Picture）が描かれており、そのレベルの粒度の要求をケイパビリティと呼び、エピックとフィーチャーの間のレベルとして位置づけられています（https://www.scaledagileframework.com/features-and-capabilities/）。SAFe®の中ではフィーチャーとケイパビリティはセットで説明されていることから、粒度は異なるが同様なものとして定義されていると解釈でき、定義としてはフィーチャーはステークホルダー・ニーズを満たすサービス、ケイパビリティはフィーチャーよりもハイレベルなソリューションの振舞いとされています。つまりSAFe®におけるケイパビリティはソリューションレベルの要求事項として議論されており、ビジネスケイパビリティという視点ではないと言えます。エンタープライズ・アジャイル・コミュニティにおいても、プロダクトマネジメント/プロダクトオーナーがステークホルダと協業して要求をディスカバリーする領域およびアーキテクチャ領域にさらに目を向け、よりビジネスの目線に立ちながらビジネスアナリシスやビジネスアーキテクチャ等の知識体系との融合を深めていくことが有効と考えます。 ビジネスアーキテクチャとエンタープライズ・アジャイル アーキテクチャは、技術やソリューションといった実装レベルと比べると、比較的安定した構造を保ちます。アジャイルの強みが柔軟に迅速に環境変化に対応するといっても、やみくもに変更を部分最適に行っていては、ビジネスや組織全体として最適な状態は作れません。つまりアーキテクチャのマネジメントの上に、それぞれのアジャイル開発が動いていなければ、全体最適な形でビジネス価値を生み出せません。さらに、最適な形でビジネス価値を生むためには、ITのアーキテクチャを見ていても不十分であり、ビジネスアーキテクチャをデザインしマネジメントする必要があります。 ビジネスアーキテクチャについて考えると、ビジネスケイパビリティ・マップのようなケイパビリティの構造は頻繁には変わりません。ビジネスがすでに立ち上がり、既存ビジネスの深化を行うフェーズでは、ケイパビリティの構造はあまり変わらない一方で、各ケイパビリティの詳細な構成（またはさらにブレイクダウンされたケイパビリティ）がビジネスニーズに応じて変更が求められ、そのケイパビリティの変更に対する実装としてのソリューションへの機能要求が、フィーチャーといった形で展開されます。一方、DXの文脈で見られるような大きなビジネスモデル、組織やプロセスの非連続のトランスフォーメーションを目指す場合は、アーキテクチャそのものが大きく影響を受けることになります。例えば３Dプリンタの導入によって、今まで後方の工場においてリペアパーツを需要予測に基づき生産し、それをビジネスの前線に近い倉庫や店舗に配送して在庫を持つサプライチェーンモデルから、当該部品のオーダが来てからビジネスの前線の３Dプリンタで短リードタイムで生産を行うことで、無在庫でのオペレーションを行うモデルの可能性が出てきます。この場合、顧客経験と価値を大きく変える可能性があるだけでなく、企業におけるビジネスケイパビリティもバリューストリームも、大きく変更を伴います。リペアパーツの需要予測ケイパビリティの重要性は大きく低下し、オーダに応じて即時に単品生産し出荷するケイパビリティを新たに構築する必要があります。そしてこれは、３Dプリンタという破壊的テクノロジーが新たに生み出すことが可能なビジネスケイパビリティの可能性について、技術サイドから連想するものです。 こうして考えると、DXに代表されるような大きなビジネス変革のケースにおいては、アジャイルデリバリーのレベルでの検討（例えば、どのようなフィーチャーが必要か）の前に、ビジネスアーキテクチャレベルで、As-IsからTo-Beのアーキテクチャにどう変更するのかのデザインが行われることが先であることがお分かりになると思います。また、企画構想段階で迅速に意思決定を組織が行うには、現在のビジネスアーキテクチャに対し、新しい施策のアイデアがどのようなインパクトをケイパビリティ等に与えるかの影響分析が迅速に行える必要があります。新しい施策のアイデアに対し、その業務プロセスへの影響や既存システムへの影響がすぐには分からず、調査をするのに多くの工数と時間をかける必要があった経験をしたことがある人は少なくないはずです。 ビジネスアジリティを高めたいのであれば、Development ValuestreamだけでなくOperational Valuestreamにも目を向ける必要があるとともに、ソリューションの前にビジネスアーキテクチャを構想することに、一層私たちのフォーカスをあてていく必要があると考えています。そして、エンタープライズ・アジャイル等のアジャイル知識体系と、ビジネスアーキテクチャやビジネスアナリシスの知識体系が一層連携し融合することで、一層ビジネスアジリティを実現するためのフレームワークとして包括的な知見が提供できるのではないかと考えます。

今年度の「Iasa日本支部主催のアニュアルカンファレンス2021」は、講演者3名をお迎えし11月5日に無事に終える事が出来ました。昨年に続き今年度もフルオンライン形式で開催しましたが、年々多くの参加者にご視聴頂きIasa日本支部関係者を代表して御礼を申し上げます。 （Iasa日本支部イベント一覧情報：https://www.iasa-japan.org/event） 今回のカンファレンスの主テーマは、「DX時代のエンタープライズ・アーキテクチャ」と題し、各方面でご活躍の講演者3名をお招きし、DX活動を成功裡に導く上で重要な鍵となる「アーキテクチャへの取組み」、「アーキテクチャを担う人材」、取り巻く課題等についてそれぞれの見解と事例等をご紹介頂きました。この振返りレポートでは、各講演者のメッセージと印象に残った点などを部分的に紹介させて頂きます。尚、3名の講演者の方のプロフィール詳細は、既にご紹介しました“「アニュアル・カンファレンス 2021」講演の主要テーマ事前のご紹介”をご覧下さい。 （https://www.iasa-japan.org/column） 講演１. なぜEAがDXを加速するのか？ 〜 DXの本質とEAによる推進手法 〜 講演者：　山本　修一郎 様 講演資料はこちら：https://www.iasa-japan.org/post/annual-conference-2021 最初に登壇頂いた山本様には「何故EA(Enterprise Architecture)がDXを加速するのか？ 〜 DXの本質とEAによる推進方法〜」について講演を行って頂きました。何故DX推進にEAが必要なのか、組織が直面する課題を中心に氏の幅広い知見から解説を頂きました。ここでは、特に印象に残った見解や論点を紹介させて頂き、筆者の個人的な感想も少々加えさせて頂きました。講演スライドの参照ページも付記しましたので必要に応じてご覧下さい。 山本様の講演では以下の題目ついて解説がありました。 DXとEAの関係について：日本と世界の捉え方の違い、主要なEAフレームワークの特徴と比較、EAとDXの相互関係についてその俯瞰的な解説（講演スライド3〜6ページ） → 世界と日本のEAの捉え方の違いは随分開きがある点は改めて認識しました。日本のEAに対する理解が今日何故そうなっているのかは興味がある所です。 デジタル・リーダー像について：DX先進企業における人材に、経営、事業、技術の３つに精通しリーダーシップを発揮できる「八咫烏（やたがらす）人材を有すると言う共通項があるとの調査結果（講演スライド７ページ） →「経営、事業、技術」のそれぞれ３分野に精通する人材は稀有と思われますが、組織的に取り組めば、八咫烏的な個人、または、チームが編成できるのでは、と感じますが読者の皆様の組織では状況はいかがでしょうか？ DXの本質について：“持続可能な企業の発展手段として既存のビジネスモデルからデジタル変革を通じて変化即応性を有するデジタルエンタープライズへ変革させる事“。 そのためにEA手法に対応したDX推進が重要（講演スライドP6〜10ページ） → DX自体は目的では無く、あくまでその手段である事を再認識しました。P10の４つの狙いは、アーキテクチャ活動として継続的に取り組まなければいずれも達成は困難に思えます。 DX推進を阻む７つの壁：DXに取り組む上で組織が直面する課題として、従来の人依存型のメンバーシップ型からジョブ型への経営変革の必要性、IT人材とDX人材の違いなど、DXを成功に導く上で見落としがちな課題（講演スライドP15〜P19） → とかくDXと言う結果イメージとして何らかのソリューションの導入がゴールとして捉えがちになりますが、現在の組織上の前提条件を前もって整備しておく事が重要である事が示されています。 デザインエンジニアリング：DXに必要な知識として開発された名古屋大学国際工科専門職大学向けの新カリキュラムの中で、「デザインエンジニアリング概論」の構成の紹介　（講演スライド21ページ） → “価値創造のためにエンジニアリングをデザインする“観点からアーキテクチャのレイヤー毎に個別の学習テーマがマッピングされている点が大変興味深いと思います。是非ご覧下さい。 → 尚、Iasaが発行するBTABoK（旧ITABoK）では、その知識とベストプラクティスを４つのアーキテクチャ領域と５つの知識体系で網羅しています。（注：BTABoK: Business Technology Architecture Body of Knowledgeの略。（詳しくはこちら https://www.iasa-japan.org/itabok） モデリングツールで視覚化したビジネスモデル例や各社のDX戦略例、SDGsに向けたDXの位置付けの解説、医療SDGsとして戦略マップ例の紹介（講演スライドP22〜P36） → DXをデジタル技術の活用・応用の視点のみで捉えると、関わる事業や経営の何処にどの様なインパクトを与え続けるかの視点が欠落しがちです。単発のプロジェクトの実装や導入で終わってしまう場合の理由はこの辺りにありそうです。 今回の山本様の講演では、DXを継続的な成功に導くために新しいビジネスモデルをEA視点でケイパビリティとして捉えそれをモデルとしてデザインするエンジアリングの重要性と、DXを阻害する課題への取組みについて、様々な事例紹介を通じて講演を行って頂きました。DXの本質に迫る大変興味深い講演を有難うございました。 講演２. 「DX時代におけるCX/UXの重要性と事例紹介」 〜 良いCX/UX、悪いCX/UXとは何か、その違いは利用者中心であるか否かに尽きる 〜 講演者： エスディーテック株式会社 代表取締役 川端　一生 様 講演資料はこちら：https://www.iasa-japan.org/post/annual-conference-2021 ２番目の講演者の川端 一生様には「DX時代におけるCX/UXの重要性と事例紹介」の講演を行って頂きました。当日の講演では以下の議題ついてわかり易い解説がありました。 利用時品質とは？ （講演スライドP5〜P8） →「利用者が実感する利用者を中心とした品質」とは大変明確でわかり易い定義です。一般的には多くのIT関係者は品質属性の一部の一部として捉えられている方が多いと思いますが、それ以上の重要性がと価値がこの領域には有りそうです。それにしても、僅か2年程度で停止されたパスポート電子申請システムの累計利用者が133人、年間運用費が8億円とは大変ショックな事例でした。 UXとCXは異なる？ （講演スライドP22〜23）/ CX/UXを良くするためには？ （講演スライドP24〜25） → UX：ユーザー（利用者）体験、CX：顧客体験の評価は、その良し悪しを決定づけるのは「利用者中心であるか否か」に尽きる、と言うシンプルな説明はわかり易く説得力があります。 人間中心設計の必要性 （講演スライドP29〜32） → 現在の多くの製品は、多機能・高機能・複雑化の道を歩んでいます。「利用者とその環境の理解が不足のまま開発すると、CX/UXは悪化する」の論点は、製品やシステム開発に携わる方々にそのプロセスの在り方や進め方で工夫できる余地が無いか見直す機会になるでのはないでしょうか？ デザインエンジニアリングの重要性（講演スライドP33〜39） →「デザインをエンジニアリングする」には、多様性と多能性を持ったチームが必要であり、職能間（デザイナ、エンジニア、データサイエンティスト、等）の専門家の共感と共創が必要であるとのメッセージは、大変新鮮で説得力があります。DXの推進体制にこの視点が足りない場合は、最適なデザインの創出は困難になる事が予想されます。冒頭の事例紹介であった2年で撤去されたシステムにはこの辺りに原因があったのでしょうか？ 私達Iasa関係者の気付きとしても、従来のEAの４つのアーキテクチャ領域(ビジネス、インフォメーション、ソフトウェア、インフラストラクチャ)に加えてCX/UXもアーキテクチャの一構成要素として捉える必要があり、それを科学的なアプローチでデザインする事がDX活動にも必要とされていると感じています。今回、川端様には「デザインをエンジニアリングする」事の意味とその価値をわかり易い事例を交えて講演を行って頂きました。貴重な講演を有難うございました。 講演3. 「BTABoKはアーキテクチャの実践にどの様に変化をもたらすか？」 〜 ステークホルダー主導のアーキテクチャ実践のフレームワーク"BTABoK"〜 講演者：IasaGlobal ファウンダー兼 CEO Paul Preiss様 (英語による講演) 講演資料はこちら：https://www.iasa-japan.org/post/annual-conference-2021 ３番目の講演は、世界最大級のエンタープライズおよびITアーキテクト協会であるIasaGlobalのファウンダー兼CEOのPaul Preiss氏（ポール・プライス氏）です 。 プライス氏には、「BTABoKがアーキテクチャの実践にどの様に変化をもたらすか？」の講演を行って頂きました。過去10年以上にわたりIasaGlobalが公開してきた’ITABoK ( ITアーキテクチャ知識体系)’ が新しく’BTABoK(ビジネステクノロジー・アーキテクチャ知識体系)’ に改定された点も注目です。(BTABoK v3英語版ドラフト: https://itabok.iasaglobal.org/) 当日の講演は英語による講演であったため、ここでは必要に応じて補足説明をする形式にしています。 現代のEAについて：DXの推進は、DXを駆動する”エンジン”がなければ困難である（講演スライド：P4〜6） → DX推進において、アーキテクチャが重要な役割を果たす中で、BTABoK（旧ITABoK）を活用する事によりアーキテクチャ・チームはより効率的、集中的に活動する事が可能になる → BTABoKは、「評価方法 - 成熟度モデル」、「価値モデル - エンゲージメントモデル」、「オペレーティングモデル - エンゲージメントモデル」、「人材モデル - スキルモデル」の４つから構成されている デジタル化には組織のDNAの変化が必要：新しい取組み方の検討を（講演スライド：P7〜10） → 顧客の環境や課題が変化しており、顧客に関連する「新たなツール、エコシステム、新たなコスト」について情報収集が欠かせない。 → ビジネスモデルの課題：ビジネスエコシステムが深く関与する場合は、複数のプラットフォームの関与と共同作業の重要性が増し、関係者のエンパワーメントが必要になる BTABoKのエンゲージメント・モデル：（講演スライド：P11〜20） → Iasaが提唱するアーキテクトの必要な全般スキルの体系についての解説 → EAの組織について：実戦を通じてビジネス価値のデリバリーにフォーカスする事が重要 → アーキテクトにはDX活動の中心的役割が期待され、アーキテクト、エンジニア、ビジネス関係者は適度な緊張感と役割の基で連携する必要がある アーキテクチャの移行と成果のケイパビリティ：（講演スライド：P21〜22） → 顧客にはビジネス成熟度評価、ビジネスには、技術成熟度評価、社員にはアーキテクチャ成熟度評価を適用する評価方法を推奨 デジタル・エンゲージメント用のツール、カードとカンバス（講演スライド：P23〜30） → エンゲージメント用カードの種類：カスタマージャーニーマップ、ペルソナ・カード、ビジネスモデル・ケイパビリティマップ、戦略スコアカード・カンバス、等ツールを公開 エンゲージメント成熟度モデルについて：（講演スライド：P33〜35） → 成果のデリバリー、アーキテクトがチームとして機能しているか等、各成熟度ゾーンを５つの成熟度レベルで測る事が可能。エンゲージメントを可視化できるモデルは大変興味深いです。 講演の最後に、Preiss氏からIasa Globalが今年度「Architecture & Governance」と言うWebサイト上でマガジンを発行する組織をM＆Aにより統合したとのアップデートもありました。 (https://www.architectureandgovernance.com/) IasaGlobal創立者であるPreiss氏の講演により、今後Iasa Globalが目指しているBTABoKとその内容を垣間見る事が出来ました。Preiss氏にとっては8時間の時差があり早朝の講演になりましたが、貴重な講演を有難うございました。 終わりに... 今回のカンファレンス参加者にご協力頂いたアンケート結果では、今後のBTABoK v3のリリースの期待が最も高い事が示されました。関係者一同、早期のリリースに向けて努めたいと思っております。今回のカンファレンスにご登壇頂いた講演者3名の方にはこの場をお借りして厚く御礼を申し上げます。来年もIasaアニュアル・カンファレンスを開催する予定ですので、是非ともご期待下さい。 Iasa日本支部の新しいWebサイト： https://www.iasa-japan.org/ ― 　終わり　ー

「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を広めるお手伝いに取り組んでいきたいと思います。 以上 ※ 本コラムについてのご意見ご感想お待ちしております。