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.