検索結果

—　　Iasa Global WEBサイト掲載記事の紹介　第2回　　— Iasa日本支部では、ITアーキテクトとアーキテクチャに一層の関心を持って頂くため、Iasaグローバル（本部米国）のWEBサイト上に掲載されている有用と思われる投稿記事の日本語訳を今年2月から配信しています。今回はその第２回目の翻訳記事になります。 この配信にあたり、読者の皆様に予め翻訳品質の点でご了承頂きたい点があります。 翻訳にあたっては、英語原文をGoogle社提供の無料翻訳機能を利用し、日本語訳の用語の間違いと読みづらい個所を中心に校正と編集を行なっています。従って、翻訳文は原文の主旨が理解出来るレベルの翻訳である点を了承の上ご利用下さい。 Iasa Global米国本部のWEBサイトには、皆さんにご紹介したい投稿記事も多くあるためこのシリーズを楽しみにして頂ければと思います。 【第２回目の投稿記事サマリー】 アーキテクトでもあり、アジアの国々のマーケットとグローバルでのアーキテクチャ関連の動向とアーキテクト育成に詳しいAaron氏による「デジタル・トランスフォーメーション」についての記事です。 今日のほとんどあらゆる業界での急速なデジタイゼーションの中で、現在のIT組織が作りあげてきたITシステムの問題点と課題に言及しています。その課題を打開するための方法としてデジタル・トランスフォーメーション力、IT組織のコスト・センターからの脱皮の取組みの重要性、アーキテクトの役割とその重要性が紹介されています。 原文著者紹介：Aaron Tan Dani氏はデジタル変革のEA分野において特にアジア地区で広く尊敬されているリーダーであり、デジタル変革EAの採用を積極的に推進しています。現在はシンガポール・コンピュータサイエンスEA-SIG会長、Iasa Asia地区会長、及び、ATDソリューション社のCEO兼チーフアーキテクトを担っています。 ■ デジタル・トランスフォーメーションには何故エンタープライズ・アーキテクトが必要か？ Why Do We Need Enterprise Architecture in Digital Transformation? 記事原文ソース：https://www.iasaglobal.org/why-do-we-need-enterprise-architecture-in-digital-transformation/ ■　ITの進化：あの頃、そして今日 1980年代から、IT部門は労働者の生産性を向上させ、電子メールからインターネットに至るまでPC化へと全てがスムーズに使える様にする事しか期待されていませんでした。その当時はまだコンピュータ化や自動化の範囲の時代であり、プロジェクトと言えば技術に重点を置いていました。新しいアプリケーションが登場するたびに、新しいハードウェアとソフトウェアが購入され、また、ビジネス達成したい事をITが尋ねる前に既に時間、リソース、予算も決定され割り当てられていました。 ITとビジネスの間に大きな隔たりがあり、ビジネス目標を達成できないITプロジェクトは60％以上存在していました。IT予算の90％がこれらの高価なITシステムを維持するために費やされたため、ITはコスト・センターとしての評判を得るようになりました。長年にわたり、各アプリケーションはハードウェアとソフトウェアの独自のシステムを必要としていましたが、これらのシステムはそれぞれ何百人から数千人のビジネスユーザーが利用しており、想像される通りあらゆる方向に様々なアプリケーション導入の流れが発生してしまいました。 時間の経過と共に経形成されたこれらの相互の依存関係のネットワークをトレースしたり管理したりしたことは無く、やがてITはビジネスに支障をきたすという評判を得るようになりました。IT全体への影響とビジネス継続性に影響を及ぼす可能性があるため、アプリケーションをアップグレードしたり変更したりする事がほぼ不可能な状況になってしまいました。 でも特に、「専門職の定義」これはレガシー・アーキテクチャの複雑さに起因します。維持管理が非常に困難でコストもかかりました。組織内の各ITリソースの可視性やトレーサビリティも無いため、ビジネスの要件に対するアジリティ（俊敏性）とビジネスへの即応性が欠如していました。 その結果、ビジネスは素早く対応する必要があるため、シャドーITと言う形でビジネス自らが問題解決にあたりクラウドストレージやソーシャルメディア・アプリケーション、クラウド・アプリケーション等のビジネス独自のソリューション調達するようになってしまいました。ビジネスはもうIT部門を待つことが出来なくなったのです。 残念な事にこれらのその場限りの努力は全て複雑で難解な毛玉の様なアーキテクチャを更に悪化させ、デジタル・エンタープライズに変身したいと望む企業が増えているにも関わらず、この複雑さの傾向が消滅する兆しはまだ見えていません。 ■　デジタル・トランスフォーメーション力 今日、ますます多くの企業がその顧客や視聴者にサービスを提供する際にはデジタル戦略が必要であるという事実に気付き始めています。 デジタルプランニング、デジタル戦略、デジタルツール、デジタルサービス、デジタル導入、更に魅力的な事も含むこれらすべての期待 – 即ち、デジタル・トランスフォーメーションは、繰り返しになりますがデフォルトではCIOとIT組織が先ずは担当する事になります。 デジタル・トランスフォーメーションがITイニシアチブであるという考え方は、真実からそれ程遠いものではありません。デジタル・トランスフォーメーションはビジネス主導のイニシアチブであり、テクノロジーはビジネスの目標を促進するためにのみ存在します。 企業は、今日のデジタル・ビジネス分野で競争力を維持するために、デジタル・トランスフォーメーションの力を活用する必要があります。このような現実とビジネスがITに対してこれまでかってなかった程の高い期待が寄せられている事からすると、企業のITはこれまでとは異なったどんな方法で行うのでしょうか？ ある一つの事が言える事は確かです。 それは、ITプロジェクトの予算と期限を設定した過去のやり方はもはや通用しないという事です。そうする事は、質の低いデータをインプットしてそのアウトプットを得る効果しか得られません。適切に把握されていないビジネス要件は、価値をもたらさない浪費となるITプロジェクトに繋がります。 私「火災」という別の問題を引き起こす「企業の火災消防団」として機能させることを止め、変革するデジタル能力とベネフィットを企業にもたらす最も戦略的な利点となるようにする必要があります。ビジネス・レイヤーからテクノロジー・レイヤーまでの双方向の完全なトレーサビリティを備えたトラブルシューティングを可能にするデジタルエンタープライズ・アーキテクチャマップの作成が必要です。エンタープライズ・アーキテクチャのプロセス全体は、ビジネスの価値創造と効率向上の領域を特定します。 これは、デジタルエンタープライズ・アーキテクトの任務の1つです。ビジネスにIT価値をもたらすためです。この任務はエンタープライズ・アーキテクチャ・オフィス（EAO）内のグループのアーキテクト達が協力して作業する必要があります。 実際、今日のデジタル時代を乗り越えることが出来る企業や政府機関の機能が欠けているのは、エンタープライズ・アーキテクチャ・オフィス（EAO）です。このEAOは、企業のデジタル化の取り組みの一環として理想的にITプロジェクトの実施につながるプログラム/プロジェクト・マネジメント・オフィス（PMO）へのインプットを提供する重要な役割を担っています。 私の意見では、EAOはビジネスアーキテクチャ、情報アーキテクチャ、ソフトウェアアーキテクチャ、インフラストラクチャー・アーキテクチャ、ソリューション・アーキテクチャの各ドメインの専門領域において、その適性を持っている有能なエンタープライズ・アーキテクトのスタッフが揃っている必要があります。 ■　プロフィット・センターへの転換 これまでにITがコスト・センターとしての評価から変えて行く必要がある事は非常に明白です。この評価は良いことよりも害を及ぼすことが多く、ITは通常経済の停滞期に最初に大幅な予算の削減をされると同時に、「より少ない資源でより多くを行う」と事を期待されています。 EAOの基に適性なエンタープライズ・アーキテクトを持つことによって、ITに対するこの認識はプロフィット・センターに変わります。事実、情報技術によって可能になる革新的なビジネスモデルの例が数多くあります。そして、これらの革新的なビジネスモデルはそれぞれの業界を混乱させており、より多くの確立された従来のビジネスがどの様にテクノロジーを活用しているのかを再考しなければなりません。 明らかにITは実際のビジネス価値を生み出しつつ、他のビジネスが反応するべきレベルにまで影響を与えています。もちろん、多くの人がITを他のセールス、製品、マーケティングなど既存のビジネスの機能と同じようにプロフィット・センターにする方法を尋ねる事でしょう。 この質問に対する答えは、エンタープライズ・アーキテクチャ・オフィスがエンタープライズ・アーキテクチャ開発プロセスの中で、関連するフレームワーク、表記法、および方法論を使用して、あらゆるIT投資の真のビジネス価値を実証するその能力にあります。 幸いにも、組織のための新しい革新的なビジネスモデルを可能にすることは、必ずしもより多くの資金を捻出することを意味するものではありません。企業が必要としているのは、効率向上の領域を特定して既存のIT資源を最適化することです。 エンタープライズ・アーキテクトは、戦略的に計画されたIT投資を通じてより多くのビジネス価値を提供しながら、その組織が現在の場所から将来のあるべき状態へ成し遂げなければならない旅 − それは俊敏で、効率的で、生産的で、企業の成熟度に於いて発展をしている状態 — の地図を描く事なのです。 ■　今日特にエンタープライズアーキテクトが必要な理由 エンタープライズ・アーキテクトは、企業の設計図とブループリントをビジネス価値の実現に向けてマッピングを行います。エンタープライズ・アーキテクトは、もし問題や課題が発生した場合はいつでもデジタル・エンタープライズ・アーキテクチャ・マップを使用して問題の原因を追跡し、調整の効果を可視化することができます。 この驚異的なデジタル時代のチャンスと挑戦の中で、特に適切さと競争力を維持するためには、企業はエンタープライズ・アーキテクチャを独自の「デジタル文化」として取り入れ、継続的かつ戦略的なデジタル・トランスフォーメーションを行う必要があります。 今日どのビジネスに於いても、これはエンタープライズ・アーキテクトにとっての仕事であり今日のエンタープライズ・アーキテクチャ・オフィスの目的でもあります。 著者について：Aaron Tan DaniはデジタルEAのリーダーであり、デジタルEAの採用を積極的に推進しており、現在はシンガポール・コンピュータサイエンスEA-SIG会長aarontan@scs.org.sg、Iasa Asia会長Pacific aarontan@iasahome.orgとATDソリューションのチーフアーキテクトaarontan@atdsolution.com 原文記事：　https://www.iasaglobal.org/why-do-we-need-enterprise-architecture-in-digital-transformation/ 記事英語原文： By Aaron Tan Dani

—　　新しくWEBサイト掲載記事の紹介を始めます　　— 読者の皆様、 Iasa日本支部では、ITアーキテクトとアーキテクチャに一層の関心を持って頂くため、Iasaグローバル（本部米国　）のWEBサイト上に掲載されている記事・投稿の一部の日本語訳を定期的に発進していく事にしました。今回はその第1号になります。 現在Iasaグローバル（https://www.iasaglobal.org/）上には、実践で活躍中の世界中の多くのアーキテクト達からの新しい投稿や見解が毎月掲載されていますが、現在は英文のみで日本語訳は提供されておりません。（注：2017年末まではIasa日本支部が提携する外部の自動翻訳サービスを利用していました） 日本の皆様にも感心が高いと思われる英文記事をいくつか選んで日本語訳を定期的に配信していく事にしました。 この配信にあたり、読者の皆様に予め翻訳品質の点でご了承頂きたい点があります。 翻訳にあたっては、英語原文をGoogle社提供の無料翻訳機能を利用し、日本語訳の用語の間違いと読みづらい個所を中心に校正と編集を行なっています。従って、翻訳文は原文の主旨が理解出来るレベルの翻訳である点を了承の上ご利用下さい。 皆さんにご紹介したい投稿や記事も大変多くあるため、このシリーズを楽しみにして頂ければと思います。 ■ 【第1回目の投稿記事サマリー】 第１回の記事の紹介は「ITアーキテクト、エンタープライズ・アーキテクト、それともデジタルアーキテクト？」という題で、ITアーキテクトの役割や種類、これから益々加速するデジタル化社会のニーズが高まる中、ITアーキテクトがどの様な貢献をする機会があるかをアジアの国々のマーケットと動向に詳しいAaron氏による展望を紹介します。 原文著者紹介：Aaron Tan Dani氏はデジタル変革のEA分野において特にアジア地区で広く尊敬されているリーダーであり、デジタル変革EAの採用を積極的に推進しています。現在はシンガポール・コンピュータ・サイエンスEA-SIG会長、Iasa Asia地区会長、及び、ATDソリューション社のCEO兼チーフアーキテクトを担っています。 ■ IasaのITアーキテクチャ／ITアーキテクトの定義 Iasaは、ITアーキテクチャを「テクノロジー戦略の適用を通じて得られるビジネス、組織、クライアントによる利益の獲得の実践」「価値のあるテクノロジー戦略のデザインとその実現のアート（技能）、もしくはサイエンス(註4)」と定義しています。Wikipediaによるとアーキテクチャには「建築学、建築術、構造」といった意味がありますが、このうち建築術のニュアンスに近いと思われます。構造（モノ）としてよりも、専門職による術（コト）として定義している点がIasaらしいと感じます。 ITアーキテクトの定義を見てみましょう。Iasaは、ITアーキテクトの役割を「ビジネスのテクノロジー戦略家(註5)」と定義しています。多くの方にとってこれは抽象的な表現かもしれません。ですので、ITアーキテクトの役割についてもう少し考察してみましょう。 ■ ITアーキテクト、エンタープライズ・アーキテクト、それともデジタルアーキテクト？ （An IT Architect or An Enterprise Architect or a Digital Architect?） 記事原文ソース： https://www.iasaglobal.org/an-it-architect-or-an-enterprise-architect-or-a-digital-architect/ 私の様に、もしあなたがこの「業界」に長い間いるとしたら、ITとビジネスの世界の両方を跨ぐ必要がある「人」に出会った事がきっとある事でしょう。 訳注：（訳注：「デジタルアーキテクト」は、組織のデジタル変革（トランスフォーメーション）を担うアーキテクトという意味で著者が使っています。） ■その「人」とはどんな人？ その「人」がビジネスについて会話をする場合、多分その「人」の名刺には「エンタープライズ・アーキテクト」または「ITアーキテクト」または「デジタルアーキテクト」という役職名が付いている可能性が高いでしょう。もしくは、公であれ非公式であれ、正式な名詞の役職名以外に「ビジネス・アーキテクト」、「情報/データ・アーキテクト」、「アプリケーション/ソフトウェア・アーキテクト」、「テクノロジー/インフラストラクチャー・アーキテクト」、「ソリューション・アーキテクト」等、２つの役割を兼務する場合があります。 今日多くの場合、「アーキテクト」としての仕事の範囲や内容を深く理解した上で関連する資格を持っていない場合でも多くの人が「アーキテクト」の役職名を与えられているため、この事がアーキテクトが行うべき作業を困難にしている場合が見受けられます。今日、大変多くの組織があらゆる所で「デジタル化」を推進しており、「アーキテクト」に対してもっと前進する様に圧力をかけたり、アーキテクト達が組織と共に前進する事は、これまでは滅多に見られない事でした。 この様な状況を考慮した上で、Iasa本部による「すべてのITアーキテクトのためのグローバルな協会」（Global Association for All IT Architects）は、エンタープライズ・アーキテクト(EA)の役割の「標準と認定」を正式化するべく努めています。この活動を通じて、しっかり定義された持続可能なキャリアパスを有する業界のエンタープライズ・アーキテクチャーの専門家として正式に認知される事に繋がります。 ■歴史 エンタープライズ・アーキテクトの人達はかなり以前からこの業界で活動しています、他の多くの専門的な職業に比べると比較的新しいものです。その結果、エンタープライズ・アーキテクチャーに関わる専門的職種についての正式な標準や職種の定義やスコープは、ずっと最近になるまで普及しませんでした。 幸い、ザックマン・フレームワークのジョン・ザックマン氏によって、1990年代初めにエンタープライズITの初期の採用者の間で「エンタープライズ・アーキテクチャ・フレームワーク」という用語が普及しました。これに続き、1990年代半ばにはEA開発方法論を強調したThe Open Group Architecture Framework（TOGAF）が続きました。 （参照リンク：　https://ja.wikipedia.org/wiki/TOGAF） その後、私達Iasa（Iasa Global）では、2000年後半にITABoK（IT Architecture Body of Knowledge）を紹介しました。これは専門のトレーニングと認定プログラムの一環として提供したアーキテクトに必要な「スキルセットの要件」を通じて、「エンタープライズ・アーキテクト」を正式な専門的な職業とするためのものです。 次の図は、Zachmanフレームワーク、TOGAFフレームワーク、およびIASAのITABoKを示しています。 左図 (出展：ザックマン・インターナショナル社)、中央 (出展：オープン・グループ資料)、右図 (出典：Iasa ITABoK) この記事では主にIasaのITABoKのスキルセットに焦点を当てます。このスキルセットは、広く認識され持続可能なキャリアパスを持ち成功するアーキテクトになるためのコンピテンシーの要件を定義する事を支援します。 上の図で説明したITABoKの5つの柱は、5つの基礎スキル分野に焦点を当てており、「ビジネス・テクノロジー戦略」、「ヒューマンダイナミクス」、「IT環境」、「品質属性」、そして「デザイン（設計）」で構成されています。 この中の「ビジネステクノロジー戦略」は、「アーキテクト」をその他のITの専門家と差別化する点が特に綿密に位置付けられており、全ての各種のアーキテクトの活動を関連するビジネスに結びつけるという非常に重要な役割を担っています。 ■現在は... エンタープライズ・アーキテクトは、ビジネスとITの両方を担わなければならず、IT部門がどんな事を実施しようとそのビジネス戦略を実現しなければなりません。したがって、エンタープライズアーキテクトは、戦略計画委員会等に参加して支援する必要があります。 また、企業全体に及ぶすべてのビジネス領域とITの取り組みの溝（トラブルシューティング）、及び完全なトレーサビリティを容易にする「デジタルエンタープライズ・マップ」の作成をする必要があります。とりわけ、「アーキテクチャレベルのソリューション」を通じて、高度なビジネス戦略の間のギャップを埋める必要があります。 IasaのITABoKでは、5つのEA専門分野を定義しています。 即ち、「ビジネス・アーキテクチャ」、「情報アーキテクチャ」、「ソフトウェア・アーキテクチャ」、「インフラストラクチャ・アーキテクチャ」、「ソリューション・アーキテクチャ」です。 ビジネス・アーキテクトは、ビジネス戦略の中でテクノロジー戦略を支援するためにビジネスがどのように構成されているかを文書化するための共通のエンタープライズレベルのビジネス言語とフレームワークに焦点を当てます。 情報アーキテクトは、情報の保管、回収、配信、分類、利用などの情報リソースのマネジメントに注力し、株主価値を最大限に引き出すとともにテクノロジー戦略をサポートします。 ソフトウェア・アーキテクトは、ソフトウェアとソリューションの実装に関する技術戦略の提供と開発に重点を置いています。 インフラストラクチャ・アーキテクトは、開放型システム間相互接続（Open System Interconnection）、またはOSIの7層モデルの最下位4層に重点を置いており、運用、ネットワーク・エンジニアリング、サーバーサイジング、ストレージ管理、バックアップ＆リストア技術、ディザスター・リカバリー、および物理的なデータセンターの設計を支援します。 ソリューションアーキテクトは、ビジネス/情報/ソフトウェア/インフラストラクチャ・アーキテクチャからの情報に基づいてソリューションを提供することに重点を置いており、PMO（プログラムマネジメント・オフィス）が実施するITプロジェクトを通じてアーキテクチャを実現します。 しかし確かな事は、今日のエンタープライズ・アーキテクトは、従来の狭い領域のスコープや役割からより広いエンタープライズレベルの役割を持つべく変遷しています。この変遷の中には、ビッグデータ分析、IoT, クラウドの仮想化テクノロジー等の最近のデジタルテクノロジーのトレンドが含まれます。 ガートナー社は、2025年までに、エンタープライズ・アーキテクトは、組織内でプロセス、ネットワーク、依存関係を設計するだけでなく、所属する組織の外部を含むエコシステムを組み込むことになると予測しています。 (出展：https://www.gartner.com/doc/2867418/future-ea--evolving-enterprise) （訳/編集者注）　上の右の日本語訳はガートナー社による正式な翻訳ではありません。 あくまで本記事の参考情報として掲載しています。 ■今後に向けて... 今日のデジタル化の環境は、デジタルを中心に置くエンタープライズ・アーキテクトの役割に新たな次元を加えました。デジタル・エンタープライズ・アーキテクトは、エンタープライズ・アーキテクチャの取り組みを通じて組織内のデジタル変革をリードする事を担っているのです。 デジタル・エンタープライズ・アーキテクトの役割はこれまで以上に重要になりつつあり、どの業界のどんな組織や企業、政府機関であれ、チーム内にいなければ誰かがエンタープライズ・アーキテクトとしての役割を果たす必要があると強く確信しています。 実際のところ、今日多くの組織はこの役割をまだ持っておらず、急速に変化するデジタル時代に生き残りと競争に日々予測できない混乱に直面しているのです。 実際、アーキテクトを採用し、組織内に正式なEAO組織（Enterprise Architecture Office）を設置する事の緊急性は、このデジタル時代に勝つためにその組織に大変戦略的なアドバンテージを与える事でしょう。 デジタル・エンタープライズ・アーキテクトは、モチベーション＆戦略レイヤーからビジネスレイヤー、アプリケーションレイヤーからテクノロジーレイヤー、実装の移行レイヤー、またはその逆の複数のレイヤーにわたるデジタルEAマップの作成を通じて、ビジネスとITの統合を担います。 その上で、適切な投資プロジェクトのポートフォリオは、ITリソースを最大限に活用し計画されたビジネスの結果を達成すべく、ITプロジェクトを通じてPMOによって計画的され実行する事が可能になるのです。 組織のデジタル化の支援に留まらず、デジタル・エンタープライズ・アーキテクチャマップを活用して全体のトレーサビリティを可能にし、エンタープライズレベルのギャップの修正機能を有効にすることが出来るという点が、私がエンタープライズ・アーキテクトの役割が非常に重要であると考える理由です。 記事英語原文： By Aaron Tan Dani

2017年11月29日(火)に開催された「アニュアル・カンファレンス2017」の各講演で使用した資料です。なお資料には閲覧用のパスワードを設定させていただいております。 当日参加された方には閲覧用のパスワードをメールにてご案内させていただきましたが、パスワードを紛失された方や当日参加されていない方で資料をご覧になりたい方はこちらのお問い合わせ窓口からその旨ご連絡いただければ閲覧用のパスワードをご連絡させていただきます。 講演 1. APIエコノミー実現のための現実解 株式会社アーキテクタス代表取締役 細川 努 様 講演資料はこちら 講演 2. 「ディジタル・レディネス」実践能力の評価と改善 東京工業大学工学院経営工学系教授 飯島 淳一 様 講演資料はこちら 講演 3. ITアーキテクトの分類と融合 Iasa日本支部理事　中山 嘉之 ( 株式会社アイ・ティ・イノベーション BTS部長 ) 講演資料はこちら

１．はじめに EA（Enterprise Architecture)とサービスデザイン思考の関係について、考えていきたいと思います。 EA とは、政府機関や企業などの組織体において、組織構造や業務手順、情報システムなどの標準化、最適化を進め、組織の効率よい運営を実現するための方法論です。 良く知られた EA に 1999 年に策定されたアメリカ連邦政府の「FEAF」（Federal Enterprise Architecture Framework）があります。この FEAF は、Business Architecture、 Data Architecture、Application Architecture、Technology Architecture という４つの層で定義されています。この 4 つの中でとりわけBusiness Architecture の層とサービスデザイン思考は関係が深いと思われます。 Business Architecture では、組織全体の業務を明確に分析し、現状(AsIs)モデルを作成した後、理想 (ToBe)モデルを作成します。理想 (ToBe)モデルを作成する際には、現状の組織や業務処理の方法にこだわらず、本来組織が果たすべき機能や提供すべき情報をもとに考えます。本来組織が果たすべき機能や提供すべき情報は、その提供を受ける側、仮に企業ならば顧客が受け取るものです。「鍵は顧客が握っているのだから顧客のニーズを聞き出せば良い。」として多くの企業が顧客志向をうたっています。 しかし社会にモノやサービスがあふれ多種多様の選択肢が与えられると顧客は自分が本当には何が欲しいか分からなくなることさえあります。こうなると、顧客のニーズを捉えることは困難です。顧客のニーズは、EA による全体最適を考える場合の重要なインプットの１つであり、これを間違えれば、EA の前提が崩れることになりかねません。 この顧客自身も自覚していないニーズを捉える方法として、サービスデザイン思考が有用であると注目されています。 ２．EA とサービスデザイン思考の関係 最近 EA とサービスデザイン思考の関係について、あちこちで言及がされるようになってきています。 2013 年には、サービスデザインで有名な ENGINE 社のディレクター Joe Heapy 氏がロンドンでの、Forrester Enterprise Architects Council event において、『Design Thinking Reshapes Enterprise Architecture』と題した講演を行っています。※1 問題解決へのoutside-in(顧客からの視点)アプローチを可能にするために、デザイン思考のプラクティスが利用できるという内容です。 また、EAC（Enterprise Architecture Conference Europe）でも 2013 年ごろから、EA とデザイン思考との関係がたびたび取りあげられています。顧客中心のビジネスアーキテクチャが求められているのでしょう。2013 年の EAC では、eda.c のMilan Guenther 氏がJPMorgan 社の副社長Mike Clark 氏と共同で「Designing and Modelling the Future of Your Business」と題する講演を行っています。「戦略→アーキテクチャ→実装」という従来の流れに加えて、アーキテクチャと並行してデザインを考慮に入れることで、イノベーションや変革を伴い、企業における戦略の実装を行うというものです。Guenther 氏は、2014 年、2015 年にもワークショップや講演を行い、「Enterprise Service Design」というフレームワークを紹介しています。※2※3 また 2015 年には英国ガスがデザイン思考と EA を繋ぐ「Architecture Thinking」を提唱しています。EA とデザイン思考の融合が見られます。 このように、現在提唱されている EA とサービスデザイン思考との関係は、ビジネスアーキテクチャの上流にサービスデザイン思考を入れる、あるいはビジネスアーキテクチャの中にサービスデザイン思考のプラクティスを導入するという形をとっています。 ３．サービスデザイン思考とは サービスデザイン思考とは、「顧客の視点から問題点を見つけ出し、顧客にとって好ましく、価値があるアイディアを発想し、検証し、提供者の視点から、全体のサービスをデザインし、ビジネスとして提供すること。」です。 企業においては、マーケティング、営業、製造、保守など様々な部署が、顧客とやり取りを行います。それぞれの部署においては、顧客に対して、最善を尽くしていると思います。しかし、顧客はそれぞれの部署とばらばらにやり取りしているように感じているのでしょう。もし顧客志向を唱えるならば、顧客から見てそれらは一連の１つのサービスとして、提供されるべきです。この考え方は、2004 年に Vargo and Lusch※4 によって提唱されたサービス・ドミナント・ロジック(Service-Dominant Logic)がベースとなっています。 ちなみにグッズ・ドミナント・ロジック(Goods-Dominant Logic)というのが従来からある考え方で、こちらは製品や狭義の意味でのサービスを貨幣と交換することが可能かなど、交換価値を重視したものです。 それに対して、今主流になりつつあるサービス・ドミナント・ロジックは、製品や狭義の意味でのサービスを含めて、１つの包括的な広義の意味でのサービスとして捉える考え方です。 『THIS IS SERVICE DESIGN THINKING』※5 では、サービスデザイン思考の５原則を次のように定義しています。 ①で真っ先に「ユーザー中心」といっているように、「顧客の立場から」が出発点です。ただ顧客自身も気が付いていないこともあるので、すべてのステークホルダーに参加してもらいます。（共創） サービスは一連のインタラクションとして捉え、目に見える形にします。（カスタマージャーニーマップなど） そして、サービスは目に見える（気が付く）ようにしておく必要があります。（物的証拠） ここまでは、outside-in(顧客からの視点)を強調していると思われます。 ⑤のホリスティック(全体的）な視点でサービスを取り巻く環境全体に目を配るというのは、inside-out（提供者側の視点）も含めて考えるので、EA の考え方ともつながるところです。 ４．サービスデザイン思考のステップ サービスデザイン思考の手順には次の４つのステップがあります。 DISCOVER DEFINE DEVELOP DELIVER それぞれのステップでは。行動観察やカスタマージャーニーマップなどのツールを必要に応じて組み合わせて使用します それぞれのステップについて説明します。 4.1.　DISCOVER（探究） DISCOVER では、顧客自身さえ気が付いていないニーズ、すなわちインサイト（洞察） を見つけ出します。具体的には、デプスインタビューや行動観察を通して、顧客のインサイトを明らかにしていきます。通常のインタビューでは、本音を引き出せれば成功と言えますが、デプスインタビューのゴールは、顧客自身も気が付いていないことまでも引き出すことです。そのため重要になるのが、共感（Empathize－心の中に入り込み、自分のものとして感じる。）です。まず、少なくとも顧客自身と同じように考えたり、感じたりするレベルになり、それを自分自身が客観的に観察することで、顧客のインサイト（洞察）を探っていきます。 行動観察も効果的な方法です。顧客自身あまり自覚せずにとっている行動というのがあります。観察することでそういった行動を見つけ出し、それを糸口にインサイト（洞察）に近づくわけです。 このステップで見つかったインサイト（洞察）らしきものは、顧客自身も気が付いていないので仮説になります。 4.2.　DEFINE（設計） 顧客さえ気が付いていないニーズを仮説として立てた段階で、そのニーズを満たすアイディアを考えます。 ブレインストーミングなどで課題解決のためのアイディアを出します。ブレインストーミングは、参加者やファシリテーターにより成果が大きく変わります。 アイディア出しには、参加者の集合知が発揮される必要があります。志村正道氏※6 によれば、集合知が発揮されるには、多様性、独立性、分散性、集約性が不可欠です。多様性の確保には、男女、年齢、職業、人種などの異なる背景の人を集めることです。独立性には、上司部下の関係があるなど、個人の意見が他者に影響を受けないようにすることです。分散性については、問題を抽象化しないで、各個人が直接得られる情報に基づいて判断する必要があります。そして最後に、多様性、独立性、分散性の 3 つを集約する集約性が必要になります。 図 3 は、多様性とイノベーションの関係です。※7 縦軸は、イノベーションのレベルです。上に行くほど、ブレイクスルーしている画期的なイノベーションということになります。横軸はメンバーの均質性です。右にいくほど均質性が低い、すなわち多様性がある、ということになります。 横軸の左側でメンバーの均質性が高いと（多様性がない）イノベーションの度合いは、真ん中に集中しています。極端に悪いものもありませんが、極端に良いものもありません。横軸の右側でメンバーの均質性が低いと（多様性がある）極端に悪いものも増加しますが、ずば抜けて良いものもいくつか出てきます。このようにイノベーションをもたらすアイディアには多様性が必要ということが分かります。 図 3 Going for Breakthrough※7 しかし多様な背景の人をそろえたくても、企業内の機密保持のため外部の人間を入れることが許されないことも多いでしょう。 同じ環境の人が集まると、アイディア出しも、バイアスがかかり、偏ったものになりが ちです。それを避けるためにはどのようなバイアスが存在しているのかを明確にしたのち、そのバイアスを破壊することで、これまでの傾向とは異なるアイディアを強制発想すると いう方法があります。こうすることで、多様性の確保ができない場合でも、イノベーティ ブなアイディアを得られる可能性があります。 4.3.　DEVELOP（再構成） このステップでは DEFINE で考えたアイディアのプロトタイプを作成して、顧客に現実に近いイメージを膨らませてもらいます。また、ときにはプロトタイプを使用して実際の利用場面をアクティングアウト（寸劇）で表現してみます。DISCOVER でとらえたインサイト（洞察）は、顧客自身も分かっていません。そのため、DEFINE で出たアイディアを説明されてもまだ、ピンときません。製品ならば手に取って使ってみて、サービスならば体験してみて、初めて自分が求めていたものだと気が付くことができます。 しかし、実際の製品やサービスを作るにはコストがかかりすぎます。そこで、プロトタイプを作成し、アクティングアウトをすることで、顧客のニーズを確かめるわけです。そのため、初期のプロトタイプほど単純なもので、時間にして１０分から２０分程度で作成できる簡単なものを用います。 4.4.　DELIVER（実施） いままで、顧客のインサイト（洞察）について考えてきました。顧客のニーズを満たせるアイディアができたところで、今度は、提供者側の視点で、そのアイディアがビジネスとして成立するかを考えます。 このステップではビジネスモデルキャンバス、サービスブループリント、ピクト図解などを使用します。 サービスデザイン思考に続いて、EA におけるビジネスアーキテクチャにつながっていきます。 ５．まとめ サービスデザイン思考では、顧客との一連の関係を１つの大きなサービスとして捉え、まずは顧客視点から考え、その後提供者視点で考えていきます。顧客視点は、単にアンケートなどによる表面上のものではなく、顧客自身気が付いていない深い部分を捉える必要があります。 EA において、業務からシステムへ全体最適を検討するときに、サービスデザイン思考のステップを取り入れることで、EA はより柔軟ものになるのではないでしょうか？ ※1 http://enginegroup.co.uk/news-and-views/design-thinking-reshapes-enterprise-architecture ※2 http://intersectionbook.com/materials/eda.c_enterprise-design-canvas.pdf ※3 http://www.ogis-ri.co.jp/rad/webmaga/rwm20140701.html ※4 Vargo, Stephen L.; Robert F. Lusch (2004) “Evolving to a new dominant logic for marketing.”, Journal of Marketing, Vol. 68, No.1. ※5 Marc Stickdorn ; Jakob Schneider(2012) “THIS IS SERVICE DESIGN THINKING”, Wiley 長谷川敦士 (監修), 武山政直 (監修), 渡邉康太郎 (監修), 郷司陽子 (翻訳) (2013)翻訳版 ※6 志村正道 “集合知とウェブ” http://www.yc.tcu.ac.jp/~kiyou/no10/1-04.pdf ※7 Lee Fleming(2004) “Perfecting Cross-Pollination” , Harvard Business Review http://hbr.org/2004/09/perfecting-cross-pollination/ar/1

■ 【物理的建造物とは違う】 ここのところ「アーキテクト」というのが、私の周囲でホットな話題になってきている。外来語なので和訳すれば「建築家」ということになり、実際に、構造物を組織的に役割分担して構築することが目的であり、システムやソフトウェアの世界でもその物理的建造物としてのメタファで語られることが多い。 かつて PMBOK（Project Management Body of Knowledge）が注目されていた時も、建築のメタファが使われ、段取り工学的な側面が強調されてきた。初期の頃には、「ソフトウェア開発のスコープ記述は WBS(Work Breakdown Structure)を描くことだ」とまで解説されていたこともあり、腰を抜かすほど驚いた記憶がある。しかし、創造的なシステムづくりであらかじめスコープを決めることはできないし、まして、仕様を明確にしてベンダに発注するといった行為が一朝一夕にできるわけ もない。 ■ 【アジャイルの本質は、リスクを減らすこと】 筆者は、今世紀に入った頃、従来のソフトウェアづくりが急激に変貌していくのを肌で感じ、Kent Beck 氏の招聘を皮切りにアジャイルプロセスの啓発活動に着手し、2003 年には仲間とともにアジャイルプロセス協議会を設立した。軽量マネジメント、俊敏な開発など、ビジネスの変化に対応していく取り組みに重点を置いてきた。 アジャイルプロセスの核心を一言で言うと「（ビジネス上）明確になった事項を、明確になった時点で、迅速につくる」ということに尽きる。しかしながら、このことをよく考えて見れば、コミュニケーションと確認を繰り返しながらシステムの構築を図っていくことであり、要求されているものを、与えられたリソースを使って開発を進め、期間内に納めるというプロジェクトマネジメント上の「リスクを減らす」行為に過ぎない。 リスクを減らすことによって犠牲になっていることは、失敗によって得られる知 見が少なくなるということで、このことがもたらす弊害も考慮しなくてはならない。 ■ 【世界の創造へ】 アジャイルプロセスの先に何があるのか？ という問題設定のもとに、2009 年より知働化研究会の活動を開始した。ソフトウェアに関する取引が、未だに「人月（にんげつ）」中心で、価値主導になっていないため、これを「人道説から知働説へ」というキャッチコピーで活動をしている。 知働化研究会の中でも、創造的なソフトウェアづくりはどうすればよいのかという探求が進められ「アーキテクト」像についても議論が重ねられてきている。リスクを減らすことよりも、価値を生み出すことや創造性に重点が移ってきているのだ。 ■ 【言葉の整備】 一方、筆者が副委員長をつとめている P-sec（実践的ソフトウェア教育コンソーシアム）のソフトウェア社会の将来像研究会（通称：みらい研）でも、次世代を担う人材についての議論の中心の一つが、やはり「アーキテクト」である。先月の同研究会で合宿討論をした時のテーマは、第１が「SWEBOK(Software Engineering) と SEBOK(System Engineering)との活用」と第２が「ソフトウェアアーキテクト」であった。 ■ 【アーキテクトの人材像】 みらい研合宿第２のテーマは、まさに「アーキテクト」の人材像についての議論であった。そこで提示されたいくつかの見解が、とても興味深いものなので、以下に掲げておく。 アーキテクトの仕事は、Why と What を普遍的に定めること アーキテクトの仕事は、新たな法（法則・法律）をつくり、人々や社会含めてのシステムという実行可能な世界を生み出すこと アーキテクトの仕事は、概念操作・創出によって、新たな世界観を生み出し、実行・進化する計算可能な理論体系を構築すること アーキテクトの仕事（ソフトウェアづくり）は、能動的認知機能、「知る」という働きを通じて、コトバという材料によって現実感を構成していくこと これ等は、いずれも第一線のいわゆるアーキテクトの役割を担っている（いた）人の言葉である。「ビジネス」「マネジメント」「戦略」といった言葉は一切でてこない。筆者は、これを『認知的転回』と名付けている。創造性を追求する領域では、＜個人＞の認識や知の部分に焦点をあてていく必要があるのだ。 かつて話題になったSF 映画 the MATRIX の最後にでてくる the Architect は、まさに MATRIX という世界を創造した「アーキテクト」の役割を果たしている。哲学や信仰を含めてリアルとバーチャルの世界の在り方を含めた世界を創造する＜マシン＞を設計・開発した人物として描かれている。 ■ 【人材の二極化】 無論、システムやソフトウェアづくりは、創造性がすべてではない。ある程度手順化できる部分もある。みらい研の予想では、今後、ソフトウェア技術者の世界は二極化が進んでいくとみなしており、一方を「創造的カテゴリー」、もう一方を「技能的カテゴリー」と呼んでいる。上記のアーキテクト像は、創造的カテゴリーの人材像である。おそらく、人材数比率で、創造的カテゴリー：技能的カテゴリー＝1： 100 程度ではないかと予想している。 創造的カテゴリーのアーキテクトについては、IASA でのアプローチとは異なった意味での組織化、人材発見、評価、支援の仕組が必要と考えており、今後、各コミュニティの協力を得て構築していく予定である。 ■ 【ITアーキテクトの定義】 Iasaは、ITアーキテクチャを「テクノロジー戦略の適用を通じて得られるビジネス、組織、クライアントによる利益の獲得の実践」「価値のあるテクノロジー戦略のデザインとその実現のアート（技能）、もしくはサイエンス(註4)」と定義しています。Wikipediaによるとアーキテクチャには「建築学、建築術、構造」といった意味がありますが、このうち建築術のニュアンスに近いと思われます。構造（モノ）としてよりも、専門職による術（コト）として定義している点がIasaらしいと感じます。 ITアーキテクトの定義を見てみましょう。Iasaは、ITアーキテクトの役割を「ビジネスのテクノロジー戦略家(註5)」と定義しています。多くの方にとってこれは抽象的な表現かもしれません。ですので、ITアーキテクトの役割についてもう少し考察してみましょう。 ■ 【IASA への期待】 ソフトウェアづくりに携わる多くの人々が協調・コミュニケーションを行っていくためには、共通の言葉や概念基盤が必要になり、そのために知識体系や標準化の役割がある。しかし、それ等とて社会の変貌、人々の認識の変化によってダイナミックに変わっていく。つまり、そういう変化対応の仕組みを知識体系の整備や標準化活動は備えていなくてはならない。今後、IASA、あるいは、その日本支部が展開していく活動で、この技能的カテゴリーの整備が進められていくことを期待している。 世の中には、BOK が溢れている。SWEBOK, SEBOK(INCOSE), ITIL, COBIT, BABOK, PMBOK, そして、ITABOK。BOK は、ビジネス上の実践や先端的な取り組みの結果、多くの人々が多様に関わっていく普及フェーズに至ってから整備が試みられる。標準の宿命である。しかも、世の流れは、それぞれの知識体系の領域間の壁が無くなり、個別BOK としてのアイデンティティが希薄になってきている。 BOK は、言葉や概念で一つの世界を創るという意味で、ソフトウェアに似ている。その体系がどのように使われ、どのような価値を生み出すのかを明確に示すことが要請されているように思える。そう、IASA にとっては、「ア—キテクト」を中心とした新しい世界を創造していくという問題なのだ。 主要リンク： アジャイルプロセス協議会：http://www.agileprocess.jp 知働化研究会：http://www.exekt-lab.org P-sec（実践的ソフトウェア教育コンソーシアム）：http://p-sec.jp 大槻 繁（おおつき しげる） 株式会社一（いち） 代表取締役社長otsuki.s@1corp.co.jp http://1corp.co.jp アジャイルプロセス協議会 フェロー知働化研究会 運営リーダ P-sec ソフトウェア社会の将来像研究会 副委員長

Enterprise Architecture as a foundation for Healthcare Transformation 医療変革の基盤としてのエンタープライズアーキテクチャ Part One: Enterprise Architecture Realization パート１：エンタープライズアーキテクチャの実現 I wrote this article based on presentations that I had made this year during the BITAS series in Malaysia, Singapore and Indonesia. The presentations aim was to share my experience in the implementation of an Enterprise Architecture initiative at the Institute Jantung Negara (National Heart Institute) in Kuala Lumpur since late 2014. The first iteration is due to be completed in December 2015 to be handed over to the hEArt@IJN Office for the second iteration. この中でも特に、「専門職私は、今年マレーシア、シンガポール、インドネシアで行われた BITAS カンファレンスで行ったプレゼンテーションに基づいて、本記事を書いています。プレゼンテーションは、クアラルンプールにある Institute JantungNegara（国立心臓病機関）において、2014年から行っているエンタープライズアーキテクチャ施策の導入に関する私の経験を共有すること を、目的としています。最初の活動サイクルは、2015年12月に、2つ目の活動サイクルを回すために、hEArt@IJN Officeに役割を移管しなければならないことでした。 Here, Enterprise Architecture is defined as: a coherent whole of principles, methods, and models that are used in the design and realization of an enterprise’s organizational structure, business processes, information systems, and infrastructure, according to Lankhorst (1). Figure 1 shows the history and the progressof Enterprise Architecture from 1987 to 2015. ここでエンタープライズアーキテクチャについて定義いたしますと、Lankhorst によれば、エンタープライズの組織構造、ビジネスプロセス、情報システム及びインフラストラクチャをデザインし実現するために利用される一貫した原則、手法及びモデルであると定義されています。図１に、1987 年から 2015 年までのエンタープライズアーキテクチャの歴史と進展について示します。 The experience that I had gained was both on the personal and organizational level. First, the personal level, I came from the operational side of the hospital as I am a consultant Anesthesiologist with special interest in Critical Care, Pain Management and mechanical heart assistance. In the course of discharging my duties as an Anesthesiologist, I was involved in the Joint Commission International Accreditation exercise, which includes the management of information related to the quality of care received by IJNs patients. In one of the standard it is stated that “appropriate staff members are educated and trained in the principles of information management.” and as a physician I will need to be credentialed and privileged to carry out tasks related to my work as per IJNs policy. 私が経験したものは、個人レベルのものと組織レベルのものの両方でした。まず最初に私はオペレーション側の人であり、かつ指導的立場にある麻酔専門医で、特に救命緊急診療、疼痛処理、メカニカル心臓アシスタンスに関心を持っています。麻酔専門医としての責務を離れて、私は認定合同審査会の訓練に参画しましたが、そこでは、UN の患者が受けるケアの品質に関連する情報マネジメントも含まれていました。標準の一つに、“適切なスタッフメンバーは、情報マネジメントの原則について教育され、トレーニングを受けていること”というものがあります。また医師として、私はIJN の原則により、自分の業務に関するタスクを実行する資格と特権を持つ必要があります。 My first journey began when I took the CPHIMS certification by HIMSS in the United States in 2011 that culminated in the review and formulation of the Strategic Information System Plan from 2013 to 2020 for IJN. The execution of the Strategic Information System Plan lead to the certification from IASA and the Open Group for the CITA-Foundation through Associate and the TOGAF 9.1 respectively. The certification addresses the competency gap that I had as a Clinician that had no training or experience in Management and Information Systems. In combination it allows me to have the viewpoint to play an active role in building and guiding the team that will be managing the initiative. It also allows me to present the views to address stakeholders concerns and pain points. 私の最初の旅は、2011 年にアメリカの HIMSS による CPHIMS の資格を取得したときに始まり、2013-2020 年の UN の戦略的情報システム計画の見直し・構築までです。戦略的情報システム計画の実行は、IASA とオープングループから、CITA-Foundation の資格とTOGAF9.1 の資格をそれぞれから取得することにつながります。資格は、臨床医としてマネジメントと情報システムについてのトレーニングと経験をもっていないという能力ギャップに対する対応となります。それと共に、資格は、私にイニシアティブをマネジメントしていくチームを作り、ガイドしていくという積極的な役割を担うための視点を与えてくれます。また、それは、ステークホルダの関心ごとと満足していない事柄に対応するための方法を提示できるようにもしてくれます。 On the organizational level there was a need to review the Strategic plan as the system implemented from the first Strategic Plan did not achieve the adoption needed to make the investments worthwhile and there were many unresolved issues that need to be catered for. On the other hand there is a marked change in the landscape of healthcare delivery that needs to be taken into account to ensure sustainability of the institute. 組織レベルにおいては、最初の戦略的計画において導入するシステムが投資効果に見合うようにする必要から採用に至らなかったとともに、対応する必要がある多くの未解決課題があったため、戦略的計画を見直す必要がありました。その一方で、機関の継続性を担保するために考慮にいれなければならないような、医療デリバリーにおける顕著な環境変化があります。 The changes were in the delivery of medicine and in the enterprise IT. In his book Eric Topol wrote about the creative destruction of the old dumbed down medicine due to super convergence of ubiquitous technology in ICT (i.e. information systems, wireless sensors, mobile connectivity and bandwidth- to name a few) to the new, individualized medicine that is enabled by digitizing humans. Figure 2 illustrates the concept of creative destruction by multiple technologies. These changes brought unprecedented challenge to any healthcare organization (HCO) to adapt to the new needs of the patients and stakeholders. 変化は、医術の提供とエンタープライズの IT に起きました。Eric Topol は、彼の本の中で、ユビキタスな ITCT のテクノロジー（２，３例をあげると、情報システム、無線センサー、モバイル接続など）が集約されることで、低レベルの医術の創造的破壊がおき、デジタル化された人によって可能になる新しい個別医術へとつながっていくことを書いています。こうした変化は、患者とステークホルダの新しいニーズへ対応するために、あらゆる医療組織（HCO）に前例のない挑戦をもたらしました。 The next change was in the context of the enterprise IT. Now Enterprise IT has entered the 3rd era (according to Gartner) as shown in figure 3, where the theme is Digitalization with focus on Business Models, Digital Leadership capabilities, engagement of colleagues as partners, engagement of external customers and digital business innovation with new types of values. On top on this was the fact that many healthcare related IT projects are failing at an alarming rate with low adoption rates. This bring about many pain points for the IT management that leads to a gap between what IT can deliver to the needs of the business of the enterprise. 次の挑戦は、エンタープライズの IT の文脈においてありました。今やエンタープライズのIT は、図３に示すように第３の時代に入ってきています（ガートナー）。そこでのテーマは、ビジネスモデル、デジタルリーダシップ能力、パートナーとしての同僚のエンゲージメント、外部顧客のエンゲージメント、新しいタイプの価値を伴うデジタルビジネスイノベーションに焦点を当てたデジタイゼーションです。さらに、多くの医療関連の IT プロジェクトが警戒すべき割合で失敗し、低い普及率にとどまっているという事実があります。このことが、IT ができることとエンタープライズのビジネスニーズとの間のギャップが引き起こす IT マネジメントの多くの課題をもたらしています。 The above facts created a multitude of challenges that needed a new way of approaching the delivery of ICT healthcare in the future. To quote Einstein; “We can’t solve problems by using the same kind of thinking we used when we created them.” So a different approach needed to be sought. However the principles such as healthcare should be safe, effective, patient centered, timely, efficient and equitable must be maintained. 上記の事実により、将来 ICT医療の提供への新しい手法が必要となるような、多くの挑戦が生み出されました。 Therefor a methodology that looks at ICT as a tool that supports patient care based on the clinical care processes, that can be used for communication to multiple stakeholder, execute the strategic plan at strategic, tactical and operational level across the enterprise, caters for design and modelling of clinical care processes are sought. The Enterprise Architecture as a discipline was deemed the most optimal methodology available for use by the initial team. This was the decision to pilot the competency building for IJNs Enterprise Architecture. Several IJN staff was send for training and one was certified and was tasked to guide and form the core team with a consultant that was chosen by IJN. This paved the way for the team competency development that form one work packages stream. Next the capabilities was defined and signed-off. The capability increments was defined according to the finding of the maturity assessment and it was divided into multiple work streams based on three dimension. The dimension are People, Process and Materials. This section can be assigned to the capability based planning in TOGAF 9.1. それ故、診療プロセスに基づく患者ケアをサポートするツールとして ICT を見なし、複数のステークホルダとのコミュニケーションに利用でき、戦略的計画をエンタープライズの戦略レベル、戦術レベル、実行レベルにまたがって実行でき、診療プロセスをデザインしモデリングするために資するような方法論が求められています。原則としてのエンタープライズアーキテクチャは、最初のチームが利用できる最も適切な方法論と考えられます。UN のエンタープライズアーキテクチャの能力形成を先導することが決定されました。複数の UN スタッフがトレーニングに送られ、一人が資格取得をし、UN の選んだコンサルタントとともにコアチームを作りガイドするタスクが与えられました。これにより、一つのワークパッケージストリームを形成するための、チームのコンピテンシー開発を進める準備ができました。次に、能力が定義され、サインオフされました。能力強化は、成熟度評価からの明らかになった事項により定義され、3つの軸に基づく複数のワークストリームに分割されました。軸は、人、プロセス、マテリアルです。この部分は、TOGAF9.1 の能力ベース計画に該当します。 The work stream to measure the maturity of the organization across ten dimensions for Enterprise Architecture have two aims. First to review the current state and to set the future state and second to define the capability increments that will form the basis for the architectural work packages. Figure 4 shows an example of the spider diagram for the visualization of the current to futurematurity. This was presented and signed-off by the stakeholders. 10個の組織の側面の成熟度を測定するワークストリームは、2つの目的を持っています。一つが現在と将来の状態をレビューすることと、もう一つがアーキテクチャ・ワークパッケージの基礎となる能力強化を定義することです。図4は、現在と将来の成熟度を可視化するレーダーチャート(Spider diagram)の例を示しています。これは、ステークホルダに示され、サインオフされます。 The next work stream was created to design and implement the governance system for the initiative referenced to both TOGAF 9.1 and the COBIT 5. The artefacts from this work stream include the governance system and structure, management matrixes including the monitoring and control mechanism as an example. A work stream to realize the Enterprise Architecture that is referenced to the TOGAF ADM cycle. As shown in figure 4: the capability and capability increments forms the deliverables building blocks and the ADM Phases A through F, delivering the Architecture and Solution Building Blocks that forms the basis for the capability Increments solution that is executed as portfolios of corporate projects. The ADM phases created many artefacts and are stored and managed in a repository that serve as the focal point of the Enterprise Architecture. In it the architecture and solution building blocks are clustered in a continuum that define both the IJNs architecture landscape and the transition architectures. Figure 5 shows the generic repository component based on TOGAF 9.1. The implementation of the repository tool was treated as a work stream. 次のワークストリームは、TOGAF9.1 と COBIT5 を参照したイニシアティブに対するガバナンスシステムの設計と導入のために作られました。このワークストリームからの作成物（Artefacts）は、ガバナンスの仕組みと構造、例えばモニタリング＆コントロールメカニズムを含むマネジメントメトリクスを含んでいます。エンタープライズアーキテクチャを実現するためのワークストリームは、TOGAF ADM サイクルを参照しています。図4で示したとおり、能力と能力強化は、成果物のビルディングブロックと A から F までの ADM フェーズを形成します。そこで、アーキテクチャ及びソリューションのビルディングブロックをデリバリーし、それらはコーポレートプロジェクトのポートフォリオとして実行される能力強化のソリューションの基礎を形成します。ADM フェーズは、多くの作成物を作成し、それらはエンタープライズアーキテクチャの中心として寄与するリポジトリに保存され、管理されま す。その中で、アーキテクチャとソリューションのビルディングブロックは、IJN のアーキテクチャランドスケープとその移行アーキテクチャを定義するコンティニュームの中で配置されます。図５は、TOGAF 9.1 に基づいた一般的なリポジトリの要素を示しています。リポジトリツールの導入は、ワークストリームの一つとして扱われました。 Figure 6 was adapted from Lank horst and defines the communication role of the architecture teams and the relationship to the stakeholder in delivering value to the organization. The architecture team works on models (which are the viewpoints) and communicates with the stakeholders using views as part of presentation and analysis of questions from multiple stakeholders. This will put the EA work into the real world and deliver value to the enterprise. 図6は、Lanhorst のものに手を加えたものですが、組織に価値をデリバリーするときの、アーキテクチャチームのコミュニケーションの役割やステークホルダとの関係を定義しています。アーキテクチャチームは、モデル（それはビューポイントのことです）に基づき仕事をし、プレゼンテーションのための部分としてのビューと複数のステークホルダからの質問の分析を使って、ステークホルダと会話をします。これにより、EA 業務を現実世界に適用し、エンタープライズに価値を届けます。 In summary, part one of this article shares the initial experience of competency buildingthe team of architects and the relationship with the enterprise stakeholders. It then describes how the TOGAF 9.1 and COBIT 5 was used as a reference to realize the EA of the hospital in question. In part two, the healthcare transformation using the EA as a foundation will be shared. 要約すれば、本記事のパート１はアーキテクトチームとエンタープライズステークホルダとの関係を築く能力の初期の経験を共有することでした。そして次に、課題となっている病院の EA を実現するためのリファレンスとして、TOGAF 9.1 と COBIT 5 がどのように利用できるのかを述べています。パート2においては、EA を基盤として活用した医療の変革について、共有をいたしました。 1.Enterprise Architecture at Work. Marc Lankhorstet al. Modelling, Communication and Analysis. ThirdEdition. 2013. Springer. Berlin Heidelberg. 2.Topol E. Creative Destruction of Medicine. How the Digital Revolution Will Create Better Health Care.Basic Books. New York 3.The Open Group Architecture Framework (TOGAF)9.1. The Open Group.