検索結果

2025年10月29日(水)、30日(木)の2日間に渡り開催された「 アニュアル・カンファレンス2025 」の各講演で使用した資料です。

ITサービスやシステムを開発するうえで、最も重要なのは“顧客が使って本当に満足するかどうか”です。どれほど新しい技術や綿密な構造設計があったとしても、実際にユーザが「使いやすい」「仕事が楽になる」「自分のニーズにぴったりだ」と感じる体験を生まなければ、サービスの成功にはつながりません。そのため、設計手法やプロセスを選ぶ場面でも常に「顧客目線」「ユーザ体験」を中心に据えることが不可欠です。 本コラムでは、BTABoKのCompetency Modelの Design の中にある Design Methodologies and Processesの内容をユーザ体験（UX）の向上を観点に解説します。 すべての開発プロセスを“顧客痛点”から始める システム開発を始める際に最初にやるべきはターゲットユーザの業務・生活・感情・習慣等の情報を“本物の声”として拾い上げることです。ユーザインタビュー、現場観察、アンケートを実施して情報吸い上げる試みをしますが、形式的なものではなく顧客が実際に何に困り何に価値を感じているかを“共感を持って深掘りする”ことが重要です。（ここが結構大変だったりしますが） この情報が明確になることで、どの設計手法を選び、どのプロセスに重点を置くかが決まります。 たとえば、ウォーターフォール型など計画型プロセスでは、初期要件定義でユーザの“真の痛点”を徹底的にヒアリングし、ドキュメントに反映させながら“将来の体験”を設計します。アジャイル・反復型の場合なら、短いスプリントやインクリメントごとに「現場で本当に使われているか？」を実地検証し、フィードバックを次サイクルへ素早く取り込むことで体験価値を高めていきます。 顧客体験の“動的設計”——変化と共に進化する手法 設計プロセスは、スタート時点だけではなくサービス提供の全期間で“ユーザ中心”の思考を一貫して持つことが重要です。 現代は顧客のニーズも業務環境も刻々と変化しています。だからこそアジャイル型、スパイラル型、リーン型など“反復・進化”を前提にした設計プロセスが、より良い顧客体験創出に向いています。（ただし業務領域やターゲットデバイス等の制約でこれらのプロセスが適用できない領域も存在するのも現実です） 具体的には、以下のような実践が有効です： ユーザストーリー深化 　設計時に単なる「機能要件」ではなく、「ユーザがこの機能を使って何を実現し、どんな気持ちになるか？」まで意識して文書化。サービスが顧客の日常の“どんな瞬間”を変えるかを設計メンバー全員が共有します。 プロトタイピングとユーザテスト重視 　設計途中でも画面やワークフローのプロトタイプを素早くつくり、実ユーザに使ってもらう。使いやすさや理解しやすさ、楽しさ、不満点などを直接会話・行動の中から収集します。その結果を即座に設計へフィードバックして変更・改良します。 パーソナライズ・カスタマイズ設計 　顧客の業務フローや好みに合わせてUI・機能・通知設定などを柔軟に調整できる設計思想を最初から組み込みます。多様なユーザの体験価値を守り、高めるための“個別最適”の仕掛けを設計思想に盛り込むことが不可欠です。 品質属性と現場の“ユーザ体験”を具体的に担保する ユーザが実際にシステムを使う現場では、「使いやすさ」「アクセシビリティ」「多言語対応」「カスタマイズ性」といった品質属性が体験価値に直結します。以前のコラムで 体験価値（UX）を高める品質とは - Usability, Localization, Accessibility, Personalization/Customizability の解説をしましたが、直接的にユーザが体験価値を感じやすいポイントでもあります。 使いやすさ（Usability）の追求 　直感的な操作、情報の整理、エラーレスな導線。ユーザの作業効率を上げ、“使って気持ちがいい”“すぐに覚えられる”設計を目指します。ユーザテストやA/Bテストで数値指標を使って“本当に使いやすいか”を可視化します。 アクセシビリティ（Accessibility）の徹底 　高齢者・障害者・さまざまな言語利用者など多様な顧客を想定し、誰もが同じレベルでサービス価値を受け取れる設計が必要です。ガイドラインやチェックツールの活用に加え、障害当事者のモニター参加・フィードバックを定期的に受ける仕組み作りがあると効果的です。 ローカライゼーション／パーソナライズ／カスタマイズ性 　ユーザの居住地域や業務内容に合わせて、画面表示やサポート内容、通知方法などを細かく切り替えられるように設計します。ユーザごとに設定できる機能・表示・権限・サポートを強化し、「一人ひとりのためのITサービス」を実現します。 顧客との対話と設計プロセスの融合 顧客体験を設計の中心に据えるには、企画者・開発者・運用担当が“顧客との対話”を設計プロセスに組み込むことが不可欠です。たとえば、設計段階で顧客の現場ワークショップを実施し、使い勝手やコミュニケーションフローの課題を一緒に分解してみます。 設計が進むごとに、「現場で本当にどう使われているか」を定期的にヒアリングし直しましょう。ローンチ後も運用部門やサポート部門が顧客の不満・要望を設計チームへフィードバックする体制を作り続けることで、サービスが“生きた顧客体験”として常に改善されていきます。 設計品質の記録と顧客体験ノウハウの継承 設計手法やプロセスの選択は、プロジェクトごとに異なりますが、“顧客体験にこだわった判断”とその結果は必ず記録・可視化します。設計レビューやユーザテストの記録、仕様変更の理由、リリース後の顧客満足度レポートなど、ノウハウを組織の知識資産として残すことで、次のプロジェクトにも活かせます。 特に「顧客の声にどう応えたか」「期待をどう超えたか」「反省すべき点はどこか」を設計ドキュメント・ナレッジベースに積極的にまとめることで新しいメンバーや後継チームが「顧客体験設計の意味」を理解し、失敗を繰り返さず、成功の型を活用できる組織になっていくでしょう。こうした“知恵の蓄積”こそが持続可能な体験価値の提供につながります。 どんな設計手法も、最終的には「顧客が本当に使って嬉しいか」という一点で評価されます。 顧客目線で設計プロセスを丁寧に選び、使いやすさ・アクセシビリティ・パーソナライズといった品質属性まで細部にこだわり、顧客との対話と記録を通じてノウハウを継承していくこと。これこそが「本当に使われるITサービス」を作り続ける組織に必要な力です。 Iasa日本支部では情報交換や勉強会の場を設けており、システムの視覚化についても研鑽を深めていますので、今後のIasa日本支部の活動へのご参加、ご協力をよろしくお願いいたします！

今年のアニュアルカンファレンスは「秋のアーキテクチャ祭り」と題しまして、10月29日、30日の日程で開催されます。その中でIasaが推進する「BTABoK」の他に「TOGAF®」にも触れるセッション、ワークショップがありますが、本コラムでは、TOGAF®とは何か、その成り立ち、そして最新版のTOGAF®10の特徴と実務上のメリットについて解説します。 企業の変革が加速する中、ITとビジネスの整合性を高める「エンタープライズアーキテクチャ」の重要性はますます高まっています。2022年にリリースされた TOGAF® 10 は、従来のTOGAF®9.2から大きく進化し、より柔軟でモジュール化されたアプローチを提供しています。 TOGAFとは何か？ TOGAF®（The Open Group Architecture Framework） は、企業アーキテクチャを体系的に設計・管理するためのフレームワークです。The Open Groupによって開発・維持されており、世界中の企業や政府機関で広く採用されています。 TOGAF®は、以下のような目的で活用されます：      ・ビジネスとITの整合性の確保      ・複雑なシステムの全体最適化      ・変革プロジェクトのリスク低減と効率化 中心となるプロセスは「ADM（Architecture Development Method）」であり、ビジネス、情報システム、技術の各アーキテクチャを段階的に設計・実装していく手法です。 ＜ TOGAF® の詳細はこちら☟＞ https://www.opengroup.org/togaf TOGAFの成り立ち TOGAF®の起源は1995年、米国国防総省が開発した Technical Architecture Framework for Information Management（TAFIM） にあります。The Open GroupはこのTAFIMをベースに、民間企業でも活用できるようにTOGAF®を策定しました。 その後、TOGAF®は以下のように進化してきました：          TOGAF® 1.0（1995） ：TAFIMをベースにした初期版          TOGAF® 8.x（2003〜） ：エンタープライズアーキテクチャの実務適用が進み、ADMが確立          TOGAF® 9.x（2009〜） ：ビジネスアーキテクチャやコンテンツフレームワークが追加          TOGAF® 10（2022） ：モジュール化・アジャイル対応・DX支援を強化 現在では、TOGAF®は単なるIT設計手法ではなく、戦略的な経営ツールとして位置づけられています。 TOGAF10の主な特徴 1. モジュール化された構成 TOGAF®10は「TOGAF® Standard」と「TOGAF® Series Guides」に分かれており、必要な部分だけを選択して活用できるようになりました。これにより、企業の成熟度や目的に応じた柔軟な導入が可能です。 2. アジャイルとの親和性 従来のウォーターフォール型EAから脱却し、アジャイル開発やDevOpsとの連携を意識したガイドが追加されました。これにより、変化の激しい環境でもEAの価値を維持できます。 3. デジタル・トランスフォーメーションへの対応 クラウド、AI、IoTなどの技術革新に対応するためのガイドラインが強化され、エンタープライズアーキテクチャが単なるIT管理手法ではなく、ビジネス戦略の一部として位置づけられるようになっています。 業種別の活用事例 【製造業】 グローバルなサプライチェーンとスマートファクトリーの統合において、TOGAF®はIT・OT（Operational Technology）間の整合性を確保。製品ライフサイクル管理（PLM）やMES（製造実行システム）との連携をエンタープライズアーキテクチャで整理することで、品質と効率を両立。 【金融業】 複雑なレガシーシステムと新しいFinTechサービスの統合において、TOGAF®はリスク管理・コンプライアンス対応を含めた全体設計を支援。顧客中心のサービス設計やデータガバナンスの強化にも貢献。 【公共機関・自治体】 行政サービスのデジタル化（GovTech）において、TOGAF®は部門横断的な情報共有基盤の設計に活用。住民サービスの向上とコスト削減を両立するためのアーキテクチャ設計が可能。 【小売・流通業】 オムニチャネル戦略や在庫最適化、顧客データ統合において、TOGAF®はシステム間の連携とデータ整合性を確保。リアルタイムな意思決定支援基盤の構築にも寄与。 【医療・ヘルスケア】 電子カルテ、遠隔医療、医療データのセキュリティ管理など、複雑な規制と技術要件を満たすためにTOGAF®が活用されている。患者中心のケアモデルの設計にも有効。 実務上のメリット TOGAF®10の導入は、以下のような実務的メリットをもたらします： 意思決定の質の向上 ：エンタープライズアーキテクチャに基づく情報整理により 　 経営層の意思決定が迅速かつ的確に。      部門間の連携強化　 ：共通のアーキテクチャ言語を用いることで、ITとビジネスの 　　　　　　　　　　　 橋渡しが可能に。      変革のスピード向上 ：アジャイルなエンタープライズアーキテクチャにより変化への 　　　　　　　　　　　 対応力が向上。 まとめ TOGAF®10はこれからの企業の成長や変化に対応できるように、より使いやすく進化したガイドラインです。戦略的な視点を持つエンタープライズアーキテクトやビジネスアーキテクトにとって、TOGAF®10は組織の変革を牽引する強力なツールとなるでしょう。 「秋のアーキテクチャ祭り」は、エンタープライズアーキテクチャやビジネスアーキテクチャの具体的な実践や最新の潮流に触れることができる機会を皆さんにご提供いたします。皆様がたの奮ってのご参加お待ちしております。 ＜イベントページはこちら☟＞   https://www.iasa-japan.org/event-details/annual-conference-2025

知を深め、未来を描く二日間 ― 秋のアーキテクチャ祭り2025 エンタープライズアーキテクチャ（EA）やビジネスアーキテクチャ（BA）という言葉を耳にする機会は増えています。DX（デジタルトランスフォーメーション）の進展に伴い、企業の変革を支えるアーキテクトの役割は、ますます重要性を増しています。しかし、その具体的な実践や最新の潮流に触れる機会は、まだ限られているのが現状です。そこで 「秋のアーキテクチャ祭り」 と題して、今年もIasa日本支部が主催する年次イベントが開催されます。2025年10月29日（水）と30日（木）の二日間、会場（ビジョンセンター品川）とオンラインのハイブリッド形式で行われるこのイベントは、まさにアーキテクトたちの知と経験が集結する「祭り」の名にふさわしい場となるでしょう。 ハイライト１）グローバルの潮流を知る 初日の幕開けを飾るのは、Iasa APAC代表でありATD Solution社を率いるAaron Tan Dani氏と、Iasa日本支部アドバイザリーボードの塩田宏治氏による「グローバルなエンタープライズアーキテクチャ最新動向」です。世界のEAの実践は、日本国内の想像を超えて大きく進化しています。TOGAFの最新版「TOGAF10」や、Iasaが推進する「BTABoK（Business Technology Architecture Body of Knowledge）」がどのように発展し、活用されているのか。グローバルな現場の声を直に聞ける貴重な機会です。 ハイライト２）ビジネスアーキテクト育成の最前線 続くセッションでは、経産省・IPAのデジタルスキル標準におけるビジネスアーキテクト人材の最新動向が紹介されます。登壇するのは、同タスクフォースの主査を務める株式会社エル・ティー・エスの山本正樹氏。国家レベルで議論が進む人材像を直接聞けるのは、本イベントならではの魅力です。 ハイライト３）データと実践を結ぶ 午後には、データ活用の核心を突く講演「次世代EAに必須のデータカタログ」（中山嘉之氏）や、BA（ビジネスアーキテクチャ）とプロジェクトマネジメントとを架け橋する「BAとPMの架け橋」（松井淳氏）が続きます。単なる理論にとどまらず、現場で成果を出すための知見が語られるのは、実務家にとって非常に価値の高いセッションとなるでしょう。 ハイライト４）ロジャー・バールトンの知を読み解く 初日の締めくくりには、グローバルで活躍するロジャー・バールトン氏の著作を題材にした「ビジネスアーキテクチャ」を読み解くセッションが設けられています。翻訳者である塩田宏治氏らが、国際的な文脈と日本における実践をつなぎ、ビジネスアーキテクチャの本質に迫ります。理論と現場、そして国際的視野を統合する濃密な議論が期待できます。 ハイライト５）2日目は実践のワークショップ 二日目は一転して、体験型の学びにフォーカス。AIドリブン・ビジネストランスフォーメーション、TOGAF10、ArchiMate、BTABoKといった重要テーマを扱うワークショップが用意されています。講師との対話や演習を通じて、単なる知識習得ではなく「実践につながる理解」を深められるのが特徴です。オンライン参加も可能ですが、現地参加でこそ得られる濃密な学びがあるでしょう。 終わりに - イベント が示すもの 「秋のアーキテクチャ祭り」は、グローバルな潮流と国内の現場を結び、理論と実務を往復しながら未来を担うアーキテクト像を描き出す場です。EAやBAに関心を持つ人はもちろん、プロジェクトマネジャー、データ活用に関わる実務家、そしてこれからのキャリアを考える若手にも、多くの学びと刺激を提供してくれるでしょう。 祭りの舞台はすでに整いました。あとは参加者自身が、この知の祭典に加わり、自らの未来を描く番です。奮ってご参加ください！ ＜イベントページはこちら☟＞ https://www.iasa-japan.org/event-details/annual-conference-2025

ArchiMate次期バージョンの草案が、" ArchiMate NEXT Specification, Snapshot 1 " (以下スナップショット1) として 2025年7月21日に 公開されたので、さっそく目を通してみました。 以下記事においてはスナップショット1の内容の直接引用は著作権保護の観点から控えておりますので、具体的な記述内容については上記サイトから原本を入手・参照頂ければ幸いです。 バージョン3.2との違い 気になる「今のバージョンとの違い」ですが、これは上記のページにまとめてあります。 コンポジション・リレーションの廃止 ビジネス、アプリケーション、テクノロジーの各インタラクション、制約、契約、ギャップおよびレプレゼンテーションの廃止 振る舞い要素はレイヤーをなくし、サービス、プロセス、ファンクション、およびイベントに統合 実装イベントは、汎用的なイベント要素に置き換え ビジネス、アプリケーション、およびテクノロジーのコラボレーションは、単一の要素に統合 ビジネス・ロールは、任意の内部能動構造要素を割り当てられる汎用ロールに置き換え フレームワークの表現を、従来の「アスペクトとレイヤーのマトリクス」から「ArchiMate Hexagonion」に変更 「レイヤー」という用語は、より一般的な「ドメイン」という用語に置き換え 「Generic Metamodel 」の章は、以前に言及されたすべてのジェネリック要素を説明する第4章に置き換え パスを共通ドメインの要素に変更 パスからテクノロジー内的能動構造要素への集約は、能動構造要素からパスへの実現に置き換え リレーションシップに両端の要素のインスタンスに加えられる制約を表現するカーディナリティの追加 かなり大掛かりな変更、というのが第一印象ですが、こまかな読み解きは別の機会に譲るとして、ここでは個人的に気になるポイントをいくつかピックアップしてみましょう。 シンプルになった？ まず気が付くのは、要素の数がかなり減ったことですね。現行の3.2がArchiのパレットで数えて全部で57個。これに対しスナップショット1では42個で15個減、ざっくり3割も減ったことになります。 3.2では振る舞い要素がレイヤーごとに5種類 x レイヤー3つで計15個もあるのですが、インタラクション要素が廃止され、レイヤーごとの区別もしなくなって4つに集約されたのが大きいですね。 スナップショット1では「レイヤー」は「ビジネス」「アプリ」「テクノロジー」という分類はそのまま、「ドメイン」という呼び名になり、そこにあるのは構造要素 (いわゆるオブジェクト) だけ、ということになりました。 振る舞い要素は他のいくつかの構造要素 (後述のロールやパスなど) と一緒に、新たに加わった「Common」ドメインに属する、という体裁です。 ある振る舞いがビジネスやアプリケーションなど「どこで起きているか」は、それが「誰の」振る舞いなのかという情報をアクターとして「割り当て」てあげればわかるのですから、わざわざ振る舞い要素そのものをビジネスやアプリやらで「レイヤー特化」させる必然性はそもそも薄かったわけで、この見直しは理にかなっていると感じます。ArchiMateはよさそうだけど、なんかいっぱいありすぎて引いてしまう、なんて感じられる向きも減るのではないでしょうか。 また、従来のレイヤーという見方は、ともすろと「縄張り」っぽく、個人的にはあまり好きではなかったのですが、新しいCore Frameworkでは縄張り感が薄まって、ヒトとシステムが協力して何らかのサービスを実現する、といった絵が最初から描きやすそうです。AI-first、あるいはAI-nativeという時流にもマッチした見直し、とも言えるでしょう。 ロールとパスはより汎用的に 要素のリストラ(?)が進んだ一方で、定義と位置づけが大きく見直された要素もあります。現状ではロールはビジネス層、パスはテクノロジ層にそれぞれ属していますが、スナップショット1では名称はそのまま、どちらも「Common」ドメインの要素となっています。 これに伴い、どちらの要素もレイヤーに特化した意味づけが、より汎用的・抽象的なものに見直されました。 まずロールですが、「ヒトや組織の」役割、というところが、任意の能動構造要素の役割を記述できることに定義が見直されています。例えばAIエージェントには当然ロールがあるわけで、そういったことをきちんと表現できるようになります。 またパスについても、物理層の要素として「電気信号、エネルギーや有形の物質の」伝達経路、という定義が、無形の情報や知識といった意味的対象の伝達・伝搬の表現にも使えるように修正されました。例えば相互運用性、いわゆるインターオペラビリティといった概念も、パス要素で直接的に表現できそうです。 レイヤー間の冗長性を排除し要素数を削減する一方、レイヤー固有の要素を汎化・抽象化して使い道を拡大、といういわば両面での見直しが図られているわけですね。よりシンプルで書きやすくなったし、また意味論がヒトとマシンの共有物と化して、そこではアクターはもはやヒトとは限らない、というAI時代にもふさわしくなった感じです。 カーディナリティが書ける！ スナップショット1ではこのようなフレームワークレベルの大きな見直しのほかにも、実用的な機能拡充も図られていて、カーディナリティの追加がそのひとつに挙げられます。 ArchiMateは元々「クラス・インスタンスの区別はしない」というポリシーで、カーディナリティ表記もありませんでしたが、やはりこの点は前々からご不満の向きも多かったようで、今回ついに見直されました。といってもトリの足が書けるわけではなく、リレーションの両端にER図やUMLクラス図でも一般的に用いられる文字表記を入れられる、というものです。 リレーションは「アソシエーション」で、エンティティは「ビジネス・オブジェクト」でそれぞれ表現され、これらは現状から変更はありません。 ビジネス・オブジェクトはドメインモデルを描くのに便利ですが、カーディナリティを加えることで、より概念ERっぽく見せることも出来ますね。 ツールでの実装がどうなるのか気になるところですが、オントロジーモデルとしてmachine-readableであるところが (AI流行りの昨今では尚更)、ArchiMateのいちばんの利点だと思いますので、そこがspoilされないように願いたいと思います。 The Open GroupのArchiMate® Forum Directorである Kelly Canon氏のポスト によると、フォーラムでの最終レビューは8月4日にクローズ予定、スナップショットの紹介ページには「2026年1月31日まで有効」とあるので、そのころには新しいArchiMateにお目に掛かれそうです。人知れず(?)進化を続けるArchiMateを今後もウォッチしてきたいと思います。

今回はBTABoKのオペレーティングモデル内にある " Deliverables " を紹介します。 「成果物（Deliverables）」という言葉を聞いて、みなさんはどんなものを思い浮かべるでしょうか？ 提案書、設計書、ロードマップ……いわゆる「ドキュメント」が最初に頭に浮かんだ方も多いと思います。 しかし、BTABoKが定義する「アーキテクトの成果物」は、それらとは少し違います。いや、かなり違います。 BTABoK「Deliverables」のご紹介 　BTABoKの " Deliverables " では、成果物とは「思考を整理し、他者と対話し、前に進むためのツール」であると述べられています。つまり、形式や体裁ではなく、その成果物が誰のどんな行動を後押しするのかが問われているのです。 　これはとても重要な視点です。現場では、完璧に整えられた資料が共有されたとしても、それを見て誰も行動しなければ意味がありません。一方で、ラフなスケッチや会話のメモがきっかけで、チームが動き出すこともあるはずです。BTABoKが言う「成果物」とは、まさに後者のような、行動の触媒としての役割を持ったアウトプットを指しています。 　また、「ドキュメントだけが成果物ではない」というメッセージも強調されています。モデル、意思決定の支援、ステークホルダーへの助言、さらにはワークショップのファシリテーションまでもが成果物になり得るのです。 　では、どうやってそうした成果物を選べばいいのでしょうか？ BTABoKでは、成果物選定のための実践的なガイドラインも示されています。例えば、、、 チームの目的やブランディングに合致しているか 実際に使われ、認知されているか 作成や管理のコストが高すぎないか チーム規模やスキルに見合った範囲であるか このような視点は、アーキテクトに限らず、プロジェクトに関わるあらゆる人にとって有益です。「成果物」という言葉に含まれたバイアスを解きほぐし、自分たちの目的に照らして最適な手段を選ぶ、これがBTABoKの提唱するアプローチです。 そして最後に、私が個人的に最も印象的だったメッセージをひとつ。 「1年以上使われていない成果物は削除せよ」 　このシンプルで強烈な一文には、成果物が本質的に「生きている道具」であるべきという思いが詰まっています。どんなに手間をかけた資料でも、誰にも見られず使われなければ、それはもはやノイズです。思い切って手放し、次に向かう判断もアーキテクトの大事な仕事です。まぁ、せっかく作ったものを手放すのもそれなりに勇気が必要ですが。。。 　BTABoKの " Deliverables " は、成果物を通じてどう価値を生み出すかを改めて考えるきっかけになります。特に「成果物を作る目的」でお悩みの方には一度目を通していただきたい内容です。 　ご一読いただきありがとうございました。

11月7日(木)に アニュアル・カンファレンス2024 (以下、AC)を開催します。今年のACは企業情報システムの全体像をビジネス、データ、アプリケーション、テクノロジーの4つの視点で俯瞰する、エンタープライズアーキテクチャ(以下、EA)を意識した講演で構成されています。EAの考え方自体は Iasa日本支部のコラム でも幾度となく紹介させていただいておりますが、1枚の絵で表すと以下の図1のような構成になります。 図1：エンタープライズアーキテクチャによるデジタルツインのモデル (引用元：Iasa APAC)) EAレイヤー 講演タイトル ビジネス AI・DX時代の価値実現必須スキルとしてのビジネスアーキテクチャ データ データマネジメント視点によるアーキテクチャ考察 アプリケーション デジタルアドバンテージを強化するクラウドネイティブ技術とAIの融合 テクノロジー データドリブン経営の観点から見たイベントドリブンアーキテクチャの可能性 　個々の講演も非常に魅力的ではありますが、EAを意識しながら視て聴いていただくことにより、その価値は数倍にもなり得ると思います。また、AC終了後には、軽食や飲み物とともに、講演者のみなさまやアーキテクチャに関心をお持ちの方々と直に意見交換できる場を設けておりますので、お時間許す方はぜひ会場までお越しください。 昨年(2023)のACの様子 AC後の懇親会の様子 　みなさまにとってITアーキテクチャの研鑽の場になることは間違いないと思いますので、多数のみなさまのご参加を心よりお待ちしています！

今回はBTABoKのオペレーションモデルでとりあげられているLegacy Modernization(レガシーモダナイゼーション)についての紹介と筆者の思いをコラムにしてみました。BTABoKの記述の中でも、力作と言ってよいかと思いますが、少し長文であり、ここでは一部省略し意訳してお伝えします。全文は下記を参照ください。 Legacy Modernization | IASA - BTABoK   BTABoKでは冒頭で以下のようにLegacy Modernizationを解説しています。 ================================================================== レガシーモダナイゼーションとは アジリティの高い組織にするためには、競争優位性を保ち、変化に迅速に対応することが重要となります。しかし、レガシーシステムはその妨げとなることが多く、モダナイゼーションにより、業務効率やコスト効果を高め、新たなビジネス機会やセキュリティ強化、パフォーマンス向上を図る必要があります。特に老朽化したシステムはセキュリティリスクや処理能力の低下を招くため、早期の対応が重要となります。 モダナイゼーションとは、システムが「目的に適合」した状態を維持し、価値の提供とコストのバランスが保たれるようにシステムを変更するプロセスです。 レガシーとは、古い技術や機能を持つ既存システムの老朽化を指し、もはや組織の業務に適合しなくなっており、システムはまだ価値を提供しているかもしれないが、もはや効率的ではない状態であります。レガシーモダナイゼーションとは、レガシーシステムに変更を加えることで、組織により現代的で効率的なソリューションを提供するプロセスです。 ================================================================== レガシーモダナイゼーションは、多かれ少なかれ、多くの企業・組織で問題となっており、避けて通れない道と言ってもいいでしょう。BTABoKでは、以下にその必要性について言及しています。まずは、その内容を見ていきましょう。 ================================================================== 優れたレベルのアジリティを持つ組織は、実質的な競争優位性を持っています。アジリティによって、組織は周囲の環境に素早く反応し、変化することができます。優れたレベルのアジリティを達成するためには、組織を支えるシステムもまた、周囲の環境に 素早く反応し、変化しなければなりません。 レガシーシステムは、しばしば変更が困難であったり、ビジネス活動のサポートが非効率的であったりするため、アジリティに制約を与えてしまいます。これは珍しいことではなく、システム設計時には、もはや存在しない技術的な制約があったり、もはや適切でない特定の仕事のやり方に合わせてシステムが設計されていたりします。 レガシーモダナイゼーションは、レガシーシステムを変更またはリプレースし、組織をより効率的でコスト効率の高いものにします。これにより、既存のビジネスプロセスを最適化できるだけでなく、新たなビジネスチャンスを開くこともできます。 セキュリティは、レガシーモダナイゼーションの重要な推進要因です。組織に対するサイバー攻撃は一般的で、時間の経過とともに巧妙になっています。システムのセキュリティは時間の経過とともに低下し、レガシーシステムにはもはや最新の攻撃手法を阻止するために必要なサポートや技術がない可能性があります。これは組織にとって重大なビジネスリスクとなります。 レガシーシステムが古くなると、多くの場合、技術の制約によってパフォーマンスに制約が生じます。これは、システムの処理時間と容量が限られているため、組織が価値を提供する能力に影響します。レガシーモダナイゼーションは、性能を強化させたり、その他の非機能的特性（高可用性、回復力など）を改善する方法を提供することを可能とします。 ================================================================== 以上、ビジネスのアジリティを目指すには、レガシーの制約から逃れるとともに、セキュリティ環境の充実の為にも、レガシーモダナイゼーションが必要となっていることを訴えています。近年言われている「ゼロトラストベースのレガシーモダナイゼーションの実現」が求められているのです。また、性能などの非機能要件についてのアップグレイドも、モダナイゼーションの必要性の大きな要因となっています。 次に、BTABoKはレガシーモダナイゼーションを計画するにあたってのポイントと考慮すべき点について述べています。 ================================================================== ◆持続可能性の促進 持続可能性は、システムの寿命を延ばすための重要な品質属性です。アーキテクチャの持続可能性を確保することは、現在の期待に応えつつ、将来の期待を損なわないことを意味します。これは容易なことではありませんが、おそらく適切な技術選択を行うことが鍵となるでしょう。例えば、新しい魅力的な機能を備えた最先端の技術を選択することは、短期的な優位性をもたらすかもしれませんが、数年後にはサポートが終了し、持続可能性を損なう可能性があります。 ◆過去の投資ではなく、価値を測定する システムやテクノロジーの価値とは、ビジネス価値を効果的に提供するために、それが組織をどの程度サポートしているかということです。システムが価値提供を効果的にサポートしなくなっても、システムに投下された投資額のために、財務上の問題が生じ、廃止や移行に躊躇することがあります。しかし、それはビジネスにとって重荷であり、過去の投資にかかわらず、モダナイゼーションすべきであります。 ◆変化を受け入れる モダナイゼーションは、テクノロジーやシステムだけの問題ではありません。これらの人々が近代化の旅に参加し、スキルを更新し、新しいやり方を学び、新しいプロセスとテクノロジーを形成することが重要です。そうすることで、最新テクノロジーや新システムへの移行が容易になります。この扱いが悪いと、人々は排除されていると感じ、保護主義的になる可能性があるため、モダナイゼーションは抵抗にあう可能性が高いと言えます。   ================================================================== 以上、３つのポイント①持続可能性の確保②ビジネス価値の重視③変化への人々の対応について、留意点を述べています。それぞれ、深い考察と慎重な対応が必要かと思います。特に、財務上の問題は経営的観点からの対応が必要となり、減損の取り扱いなどは投資家や金融機関などへの配慮も必要となります。 　さて、実際にレガシーモダナイゼーションを行うとすれば、いつ行うべきなのでしょうか。BTABoKは、以下のような時期が適切であると述べています。 ================================================================== 　モダナイゼーションの計画の重要な要素の一つは、システムが「レガシー」と称される閾値に近づいていることを認識することです。この状況をできるだけ早く認識することで、リスクを軽減し、適切な対応を取るための時間を確保できます。以下は、システムがレガシーステータスに近づいていることを示す指標の一部であり、現代化が必要となる可能性が高い状況です。 おそらく最も簡単に気づける特徴の一つは、その技術がサポートを終了したか、サポートが段階的に廃止されている点です。技術プラットフォームを選択する際は、この点を考慮することが重要です。サポートが急速に失われるプラットフォームを選択すると、モダナイゼーションの必要性が高まるためです。 ◆スキル調達 適切なスキルを持つ人材を、システムのさらなる開発や維持管理に充てるのが困難な状況は、レガシー技術の存在を示す指標となることがあります。技術が老朽化すると、技術コミュニティはより新しい魅力的な技術に傾倒し、古い技術に関するスキル市場は縮小し始めます。組織が使用する技術に対して、健全なスキル基盤が確保されているかどうかを市場動向を監視することは賢明です。可用性問題が発生したり、コストが大幅に上昇したりする場合は、モダナイゼーションの計画を策定する必要があります。 ◆セキュリティ 老朽化したシステムは、年数が経つにつれてセキュリティを確保するのが困難になります。さらに、スキルに関する点とも関連して、スタッフがシステムを管理し、そのセキュリティを確保できなくなり、システムは未知で管理不能な状態に陥った時点で、システムはモダナイゼーションを計画すべきです。 ◆ビジネス価値の提供 組織が競争力を維持するためには、一定の価値提供水準を維持する必要があります。市場は静止したものではなく、競合他社は常に基準を向上させていくため、組織は市場に適応する必要があります。システムのライフサイクルにおいて、組織の業務形態は変化する可能性がありますが、過去の業務形態に合わせて設計されたシステムは残ったままになります。 　これにより、競争力のある価値提供を確保するために、組織は多大な努力を要する可能性があります。システムがビジネスのニーズと一致していない場合、システムをビジネスと再一致させるためのモダナイゼーションの計画が検討される必要があります。 ◆変化への対応能力 組織とその事業は時間とともに変化するため、組織内のシステムも変化する必要があります。これにより、効率的な事業支援を提供できるようになります。システム変更にかかるコストと時間は、組織にとって重要な要素です。 　組織のシステムは、事業と同じ速度で変化に適応する必要があります。システムが変更に時間がかかったり、コストが高くなったりした場合、そのシステムはモダナイゼーションの対象となる可能性があります。 ◆ボトルネックの発生 システム環境には多くの先進的なシステムが含まれる場合がありますが、単一のレガシーシステムがバリューストリームやビジネスプロセスにおけるボトルネックを引き起こす可能性があります。業務の流れにおいて、上流のレガシーシステムの存在は、下流の先進的なシステムのメリットを阻害したり、その効果を低下させたりする可能性があります。 　ボトルネックにおいて作業や努力が集中し、より優れたサポートや容量を有する他のシステムが単純に活用されない状況が生じます。これらのボトルネックを特定することは極めて重要であり、ボトルネックが下流のシステムが潜在能力を最大限に発揮するのを妨げるためです。 ◆容量の制限  技術は急速に進化しており、処理能力やストレージ容量といった技術の容量は継続的に向上しています。古い技術は、特定のプラットフォームやハードウェア向けに設計されたため、制限がある場合があります。これにより、組織が管理できるデータ量や、販売注文や販売データ分析などへの対応速度において制限が生じます。 ================================================================== これらの要因が現れるときは、遅きに失していることも考えられます。サポート切れの時も、人材についても、対応すべき時期はほぼ分かっているですから、モダナイゼーションのプランニングは可能です。 できれば、新システムを構築するときには、そのシステムがレガシーとなることを前提に、モダナイゼーションのプランを考えておくという事も必要ではないでしょうか？ さらに、BTABoKでは、アプリケーションシステムをポートフォリオ管理することで、システムのライフサイクルの終盤を判断することが出来るとしています。指標を設けモダナイゼーションの対象を分類し、GartnerのTIMEモデルを活用してそれぞれの対応の方向付けをすることが出来ます。 ================================================================== 　アプリケーションポートフォリオ管理の手法は、アプリケーションの全体像を監視し、コストと価値を評価するために使用できます。コストが価値に見合っているかどうかを評価するため、各システムを評価するための指標セットを使用できます。アプリケーションを測定するために使用できる一般的な指標は次のとおりです： ・使いやすさ ・将来性のある技術 ・サポートの可用性 ・専門知識の可用性 ・ユーザー数 ・ビジネス上の重要性 これらのメトリクスでの低評価は、アプリケーションやシステムがライフサイクルの終盤に差し掛かっていることを示唆します。この情報は、ポートフォリオからアプリケーションを藻モダナイゼーションのまたは廃止するための活動を計画するのに活用できます。レガシーモダナイゼーションを戦略的に監視し計画するための方法として、GartnerのTIMEモデルが利用可能です。TIMEモデルは、ポートフォリオ内のアプリケーションをビジネス機能ごとに分類します。アプリケーションは次のように分類されます： Tolerate（許容）　大きな問題がなければそのまま使用。 Invest（投資） 　　モダナイゼーションやクラウド移行など、積極的に投資して強化。 Migrate（移行）　他のソリューションやプラットフォームへの移行。 Eliminate（廃止）　コストやリスクに見合わないため、使用停止・廃止・統合。 企業のアプリケーションシステムは、開発し続けて、多様な構造になっています。BTABoKではそれぞれをこのような指標で評価し、GartnerのTIMEモデルにより、モダナイゼーションの優先順位付けを行い、レガシーモダナイゼーション計画の意思決定につなげていくことを勧めています。 それでは、レガシーモダナイゼーションを実現するには、どのように進めれば良いのでしょうか？      BTABoKではそのための戦略を示してくれています。 ◆リエンジニアリング レガシーシステムのリエンジニアリングは、システムの主要な部分を再設計または変更する大規模な技術的改修を伴うことが多くあります。この戦略は、システムの機能が組織にとって依然として価値があるが、メンテナンスコストが高額である場合や、技術的なサポートが不足している場合に有効です。実践では、次のような結果が生じる可能性があります： ・レガシープログラミング言語を現代のプログラミング言語へ移行 ・特定の機能やモジュールの完全な再設計 ・プラットフォームやサードパーティコンポーネントのモダン化 ・アーキテクチャ層（例：データ管理やプレゼンテーション）のモダン化 ◆クラウド移行 組織がレガシープラットフォームを改善するための一般的な戦略は、アプリケーションをクラウドベースのプラットフォームに移行することです。ハードウェアや運用要員に関連するコストを削減することが目的です。クラウド環境でシステムを実行するもう一つの利点は、必要に応じて容量を迅速にスケールできる点です。 ◆データ移行 モダナイゼーション戦略の一般的な手法として、レガシーシステムを新しいシステムに移行する手法があります。これは、レガシーシステムに格納されたデータが組織にとって依然として非常に価値がある場合に実施されます。新しいシステムを購入または開発し、レガシーシステムからデータを新しいシステムに移行します。この戦略は、最新技術を備えた新しいシステムを提供しつつ、レガシーシステムから価値あるデータを維持します。 ◆廃止と置き換え 一部のケースでは、レガシーシステムが単純に寿命を迎えます。歴史的データはほとんど価値がないとされ、組織が必要とする機能を提供する現代的なシステムで置き換えられます。レガシーシステムは廃止され、アーカイブされます。レガシーシステムからのデータが必要な場合は、アーカイブから取得可能です。 ================================================================== このように、BTABoKでは、レガシーモダナイゼーションに関する知見や実現する上での戦略と共に、多くの留意点を示してくれています。実務で対応が必要な際は、是非原文を参照してみてください。 Legacy Modernization | IASA - BTABoK また、これらを含めたBTABoKの理解を深めたい場合は、Iasa日本支部で開催しているセミナーや勉強会に参加ください。直近では、会員向け限定で公開した動画を教材としたオフライン交流イベントも企画しています。近々にご案内いたしますので、是非参加いただければと存じます。よろしくお願いいたします。 以上

今回のコラムはBTABoKにおける“Repository“について取り上げます。 https://iasa-global.github.io/btabok/repository.html ビジネスやシステムを説明するメタデータを格納するリポジトリは古くからその必要性が説かれてきましたが、複雑化、巨大化するエンタープライズアーキテクチャにとって、益々その重要性が高まっている今日です。本コラムではこのリポジトリの目的にはじまり、リポジトリの構造、ツール要件、さらにはその運用保守について、BTABoKの詳細な解説を紹介します。 サマリー：一般的にリポジトリは文書化ツールとみなされることが多いと思われます。技術の観点からはそうかもしれませんが、リポジトリの目的はアーキテクチャチームに2つの基本的な要素を提供することです。 アーキテクチャリポジトリ アーキテクチャリポジトリには、必要不可欠なアーキテクチャ成果物や情報を保管するためにアーキテクチャチームが使用する手法、ツール、テクニックが格納されます。アーキテクチャリポジトリはチームにとってのシステム、プログラム、ビジネスエンティティの構造に関する知識体系を示します。 エンゲージメントの原則：リポジトリはまずアーキテクトのためにあり、次に企業のためにあります。 リポジトリには、アーキテクチャの決定が記述され、これが影響を与えるすべての成果物が含まれます。 実践 アーキテクチャリポジトリは、非常に単純な文書や成果物のセットから、非常に複雑な企業全体のシステムのセットまで、幅広い範囲に及ぶ可能性があります。このレベルの複雑さは、産業に大きな混乱をもたらします。 エンゲージメントの原則：アーキテクチャはドキュメンテーションではない リポジトリはとかく文書化ツールとみなされます。テクノロジーの観点からはそうかもしれないが、リポジトリの目的はアーキテクチャチームに2つの基本的な要素を提供することです。第1に、デジタル戦略におけるより良い意思決定の支援。2つ目は、アーキテクチャと他のメンバー間の迅速で透明性のあるコミュニケーションの支援です。 まずアーキテクトを大切に 最初のエンゲージメント原則では、リポジトリはまずアーキテクトのためにあるとしています。つまり、アーキテクチャ実務が最初に目標を達成できる必要があり、リポジトリにはそのために必要なものだけ、そしてアーキテクトが「エバーグリーン」（常に最新であるべき成果物を意味する）に保つことに同意したものだけが含まれるべきだということです。 アーキテクチャリポジトリの難しさは、ステークホルダーに対しての成果物と、他のアーキテクトが容易に識別できる重要な要素とを区別するのに苦労することが多いことです。 エンゲージメント・モデルの開発プロセスの一環として、チームは、最新状態を維持し保存しなければならないアーキテクチャの要素と、どの要素を標準的なエンタープライズ・コンテンツ管理システムに保存するかを特定しなければなりません。 実際、ほとんどのアーキテクチャチームは、チーム内のアーキテクチャを記述するためのドキュメントをほとんど必要としませんが、チームにとって必要なものと、企業全体にとって望ましいものの判断を織り込むべきです。 例えば、多くの組織ではケイパビリティモデルを使用してエンタープライズを記述しており、アーキテクチャチームがモデルの導入と保守を担当しています。このようなモデルは、ステークホルダーにとってもアーキテクチャの決定にとっても非常に有用です。 しかし、一般的には、アーキテクチャチームはケイパビリティモデルの非常に最小限のバージョンを必要とするのに対し、エンタープライズではより堅牢でよく保守されたバージョンを必要とします。このシナリオでは、チームはまず、その用途に応じたケイパビリティモデルを設計し、そのモデルを企業に導入します。他の利害関係者がこのモデルに価値を見いだした場合、彼らは進んでこのモデルを維持しますが、そうでなければ、チームはアーキテクトにとって有用な元の維持しやすいバージョンに戻します。 リポジトリの構造のデザイン リポジトリは少なくとも、どのような種類のものをどのように格納すべきかを導くために柔らかな構造を持たなければなりません。アーキテクチャリポジトリの構造モデルとして最もよく知られているのは、おそらくTOGAFのアーキテクチャリポジトリでしょう。この標準は、アーキテクチャリポジトリのエンタープライズの記述を提供します。 メタモデルの要素 以下の表はリポジトリに保存されている主要な要素と、それらが互いにどのように関連しているかを強調しています。 トップダウンローディングとボトムアップローディング “バックパックを軽くしましょう…動きが遅いほど、早く死にます”　George Clooney, Up in the Air （ジョージクルーニー主演の映画からの引用） BTABoK は、アーキテクチャ リポジトリが軽量でありながら、アーキテクチャ チームの最低限の目標を満たしていれば、ツール、ドキュメント、モデルが少なくなり、チームの負担が軽減され、よりアジャイルな状態を維持できると示唆しています。 これはまた、完全なリポジトリ（事実、チームを後ろに引っ張る）など存在しないことを示唆しています。トップ・ローディングとボトム・ローディングの選択肢は、そのほとんどがチームの好みと、チームとその利害関係者のエンゲージメント・モデルに対する理解の質に基づいて決定されます。 ボトムアップローディングは、主に、製品／プロジェクトレベルから作成されるアーキテクチャの収集に依存します。これは、アーキテクチャモデルや記述、ビューやビューポイント、重要な意思決定記録などです。この方法のリスクは、質の低い詳細な成果物をリポジトリに入れすぎてしまい、すぐに有用性の低い成果物でいっぱいになってしまい、長期間使われずにメンテナンスされないままになってしまうことです。 トップダウンローディングは、チームが実践に必要な成果物の厳密なセットを定義し、階層の「トップ」からそれを投入し始めることを提案します。これは、ビジネスモデル・キャンバスやケイパビリティモデルのような、ビジネスに焦点を当てた成果物ではよくあることです。これらの多くは、アーキテクチャチームにとって非常に有益なものですが、しばしばそれ自体が一人歩きし、本来のケイパビリティである価値提供からチームを引き離します。トップダウンモデルの本質は、アーキテクチャチームが他のグループのドキュメントを保守せず、まずデジタル戦略を伝える要素のみを必要最小限の範囲で考慮する必要があります。 アーキテクト・エンゲージメント・ワークショップ - リポジトリ ワークショップの目標は、リポジトリの運用面を定義し、アーキテクチャ開発ライフサイクル（ADLC）と統合できるようにすることです。エンゲージメント・モデル運営グループ活動の一環として取り組む必要があります。 ステップ 1：エンゲージメント範囲の決定 エンゲージメント範囲は、アーキテクトの人数、企業内での関わり方、ステークホルダーコミュニティのレビュー、そしてチームの目標に基づいて定義されます。200人のアーキテクトからなる専任チームは、小規模なスタートアップ企業の2人のアーキテクトよりもはるかに広範囲に関与することになります。 ステップ2：ライフサイクルにおけるインタラクションポイントを定義 ライフサイクルの各フェーズを、インタラクションの種類、対象範囲の観点から考察します。フェーズについては、a) アイデアが生み出され取り込まれる場所、b) それらのアイデアがどのように比較され投資されるか、c) チームやグループがプロダクトにどのように割り当てられるか、d) どのように提供されるか、e) どのように最適化され測定されるか、という観点から考察します。 ステップ3: 保存の必要がある成果物を定義 アーキテクトが各フェーズで使用したいツール、テクニック、成果物、タスクに関する情報を特定します。 ステップ4：含める必要のあるリポジトリ要素を特定 以下の表は、リポジトリに重要な要素を示しています。 エンゲージメントの原則： リポジトリ管理は、チームのすべてのアーキテクトの責任であり、職務記述書とチームのパフォーマンスレビューの一部であるべきです。 ナレッジマネジメントプロセスを運用できるようにする必要があります。成果物の廃棄期限を設定し、リポジトリを維持する役割を割り当てることで、ITアーキテクトはリポジトリの鮮度と最新性を保つことができます。その結果、知的財産の再利用が促進され、情報を単一のストアに保存する傾向が強まります。 ＜訳者所感＞ 本セクションを和訳し最も痛感した点は何と言っても、海外の有識者においては、リポジトリの重要性はもはや当然のこととして、アーキテクト集団での利用に留まることなく、ビジネス価値向上への支援に至るまで、非常に広い範囲を包含するものとしてリポジトリの存在を位置付けていることでした。 翻って、我が国のリポジトリに対する認識は未だに低く、目の前のITシステム構築と人海戦術の保守に明け暮れている現状を見るにつれ、さらなる周回遅れに拍車がかかる懸念が強まった次第です。 よく考えれば、「巨大化、複雑化した企業システムは、これを維持管理、拡張するためには、“企業システム全体を管理するシステム“（すなわちリポジトリ）を、リファレンスモデルやフレームワークに基づいてきちんと設計、構築し、これを運用保守すること以外にはない」ということは至極当然のことです。日本企業も、早いうちに人海戦術から脱しリポジトリの構築に向かうべきでしょう。 ところでこのような悲観的な我が国の状況にも、少なからず明るい兆しも見えてきたので、少し紹介したいと思います。近年、AI活用も含めたデータ分析業務が、DWH＆BIツール、その利用者“データサイエンティスト”ともに脚光をあびてきました。データサイエンティストがデータ分析するためには、企業のメタデータを可視化＆格納するリポジトリ（データカタログ）が必要不可欠です（近年のDWHツールにはカタログ機能も附帯されている）。このような直接的目的からリポジトリを導入する先進的企業が出始めています。 未だデータ分析基盤構築の一環としてのリポジトリですが、（何年かかるか分かりませんが）本コラムにあるように、将来はその範囲がエンタープライズレベルでのビジネス価値向上に至るまで拡大されることを期待したいところです。また、とかくツール導入が目的となり運用、保守の観点を忘れがちですが、本コラムにあるように“リポジトリがエバーグリーンな状態であること”が重要であり、これが損なわれたリポジトリはやがて使われなくなるということを肝に銘じなければなりません。

１．アジャイル開発の利点と問題点 アジャイル開発は、ソフトウェア開発の分野で広く採用されている手法であり、その迅速な対応力と柔軟性が評価されています。アジャイル開発の主な利点としては、短期間でのリリースが可能であること、継続的なフィードバックを受けて改善を繰り返すことができること、そしてビジネスの変化に迅速に対応できることが挙げられます。これにより、顧客満足度の向上や市場への迅速な対応が可能となります。 しかし、アジャイル開発にはいくつかの問題点も存在します。例えば、要求の変動やコミュニケーションの複雑さ、品質管理の難しさなどが挙げられます。これらの問題点は、プロジェクトの進行を妨げる要因となり得ます。本コラムでは、このような問題点に対応する課題を支援するために、ビジネステクノロジーアーキテクチャ知識体系であるBTABoK（Business Technology Architecture Body of Knowledge）をどのように活用できるかについて考察します。 ２．アジャイル型システム開発での具体的な問題点 アジャイル型システム開発は、その柔軟性と迅速な対応力が評価される一方で、いくつかの問題点や困難な事項も伴います。以下に、アジャイル開発における具体的な問題点を挙げます。 (1) 要求の変動 アジャイル開発では、プロジェクトの進行中に顧客やステークホルダーからの要求が頻繁に変わることが一般的です。これは、ビジネス環境の変化や新たな市場機会に迅速に対応するために必要なことですが、開発チームにとっては大きなチャレンジとなります。具体的には、以下のような問題があります。 スケジュールの変更 : 要求の変動により、プロジェクトのスケジュールが頻繁に変更されることがあります。これにより、開発チームは計画の再調整を余儀なくされ、進行中の作業に影響を及ぼすことがあります。 リソースの再配分 : 新たな要求に対応するために、リソース（人材、時間、予算）の再配分が必要となることがあります。これにより、他のタスクやプロジェクトに影響が出る可能性があります。 優先順位の変更 : 要求の変動により、タスクの優先順位が頻繁に変更されることがあります。これにより、開発チームは常に優先順位の見直しを行い、最も重要なタスクに集中する必要があります。 (2) コミュニケーションの複雑さ アジャイル開発では、チーム内外のコミュニケーションが増えるため、情報の共有と理解が難しくなることがあります。特に、リモートワークや多国籍チームの場合、コミュニケーションの問題はさらに顕著になります。たとえば、以下のような具体的な問題が発生することがあります。 情報の一貫性 : チームメンバー間で共有される情報が一貫していない場合、誤解やミスコミュニケーションが発生する可能性があります。これにより、プロジェクトの進行に遅れが生じることがあります。 タイムゾーンの違い : 多国籍チームの場合、タイムゾーンの違いにより、リアルタイムでのコミュニケーションが難しくなることがあります。これにより、意思決定や問題解決に時間がかかることがあります。 文化の違い : 異なる文化背景を持つチームメンバー間でのコミュニケーションは、誤解や摩擦を引き起こす可能性があります。これにより、チームの協力体制が弱まることがあります。 (3) 品質管理 アジャイル開発では、短期間でのリリースが求められるため、品質管理が難しくなることがあります。品質管理面では、以下のような具体的な問題が発生する可能性があります。 テストの時間不足 : 短期間でのリリースサイクルにより、十分なテスト時間が確保できないことがあります。これにより、バグや不具合が発見されずにリリースされるリスクが高まります。 テストの自動化 : 品質を維持するためには、テストの自動化が重要ですが、初期の設定やメンテナンスに時間とリソースが必要です。これにより、他の開発作業に影響が出る可能性があります。 継続的な改善 : 品質を維持するためには、継続的な改善が必要ですが、短期間でのリリースサイクルにより、改善のための時間が不足することがあります。 (4) スコープの管理 アジャイル開発では、プロジェクトのスコープが曖昧になりがちで、計画通りに進めることが難しい場合があります。具体的には、以下のような問題が発生することがあります。 スコープの変更 : 要求の変動により、プロジェクトのスコープが頻繁に変更されることがあります。これにより、計画通りに進めることが難しくなり、プロジェクトの進行に遅れが生じることがあります。 スコープの拡大 : 新たな要求や機能追加により、プロジェクトのスコープが拡大することがあります。これにより、リソースの不足やスケジュールの遅延が発生する可能性があります。 スコープの明確化 : プロジェクトのスコープを明確に定義し、チーム全体で共有することが重要ですが、要求の変動によりスコープの明確化が難しくなることがあります。 このように、アジャイル型システム開発には多くの問題が存在しますが、これらの問題に対する課題を支援するための方法として、BTABoKを活用することで、より効果的な開発プロセスを実現することができないかを考えてみます。 ３．アジャイル型システム開発の課題への対応におけるBTABoKの活用 BTABoKは、ビジネステクノロジーアーキテクチャの知識体系ですが、アジャイル型システム開発の課題に対応するためにも有効なツールです。ここでは、アジャイル開発における課題に対して活用できるBTABoKで提示されているモデルや手法について紹介します。 (1) 要求の変動への対応 BTABoKでは、ビジネスの変化に対応するためのフレームワークを紹介しており、要求の変動に柔軟に対応することができます。具体的には、以下のようなモデルや手法が活用できます。 ビジネスモデルキャンバス ビジネスモデルキャンバスは、アーキテクチャとイノベーションに使用されるビジネスモデルを提供します。一般的には、顧客と価値提案から始めたいキャンバスを使用し、その後、他の領域に移ります。ビジネスモデルキャンバスは、ビジネスモデル全体を 1 つのビジュアルシートに凝縮する強力な戦略ツールです。それは単なるアーキテクチャではなく、イノベーションを刺激し、ビジネスのあらゆる側面が整合するようにすることです。ビジネスモデルキャンバスは、顧客とそのニーズを優先します。価値提案(提供する中核的なメリット)から始めることで、運用、リソース、財務を調整して、優れた価値を提供することができます。ビジネスモデルキャンバスを用いて、ビジネスの全体像を視覚的に把握し、要求の変動に対する影響を評価します。これにより、ビジネスの変化に迅速に対応するための戦略を立てることができます。 ⇒  参考サイト:   https://iasa-global.github.io/btabok/business_model_canvas.html バリューストリームキャンバス バリューストリームキャンバスは、顧客から制御、サプライヤー、運用を通じて推進される組織内のどこで価値が生み出されるかを理解するために使用されます。バリューストリームキャンバスを用いて、ビジネスプロセスの流れを可視化し、どの部分が要求の変動に影響を受けるかを特定します。これにより、変動に対する迅速な対応が可能となります。 ⇒  参考サイト:  https://iasa-global.github.io/btabok/value_stream_canvas.html アジャイルインパクトキャンバス アジャイルインパクトキャンバスは、アジャイル手法が企業、チーム、またはドメインに与える全体的な影響を説明するために使用されます。キャンバスは、ビジネスモデル、組織構造、文化などへの影響について考えるためのツールです。これは、組織でアジャイルを機能させるための最善の方法をブレインストーミングしている多面的なチームによるファシリテーションツールとして使用すると、最も効果的です。 ⇒  参考サイト:  https://iasa-global.github.io/btabok/agile_enterprise_impact_canvas.html (2) コミュニケーションの改善 BTABoKでは、ビジネスとITの間のコミュニケーションを促進し、ステークホルダーの共通の理解を深めるためのツールを提供します。具体的には、以下のようなモデルや手法が挙げられます。 ビジネスケイパビリティキャンバス ケイパビリティモデルは、組織が顧客に価値を提供するために必要な基本的なスキルとリソースを構造化して分類したものです。バリューストリーム (価値創造のエンドツーエンドのプロセス) に統合されると、機能モデルは青写真のように機能します。これは、潜在的なボトルネック、冗長性、および的を絞った投資によって価値の流れを大幅に改善できる領域を特定するのに役立ちます。これにより、効率が向上し、リソース割り当ての理解が深まり、イノベーションが結果を出す可能性が最も高い場所を特定する能力が得られます。ビジネスケイパビリティキャンバスを用いて、ビジネスの主要な機能や能力を明確にし、ITとの連携を強化します。その結果、ビジネスとITの間で共通の言語を持つことができ、コミュニケーションが円滑になります。 ⇒  参考サイト:  https://iasa-global.github.io/btabok/business_capability_canvas.html アーキテクト組織キャンバス アーキテクト組織キャンバスは、組織のアーキテクチャ能力を理解し、向上させるために特別に調整された一種のビジネス能力カードです。アーキテクトが組織全体にどれだけ関与しているか、ビジネスからソリューション(戦略から実行まで)の有効性、重要な意思決定の割合、および全体的な利害関係者の関与に関連する指標を定義するチームの範囲に重点が置かれています。 ⇒  参考サイト:  https://iasa-global.github.io/btabok/architect_organization_canvas.html ステークホルダーマネジメントプラン ステークホルダーマネジメントプランは、あらゆるイニシアティブに影響を与えるグループと個人のリストを提供し、ステークホルダーテンプレート、カード、キャンバスの中核を形成します。このリストの目標は、利害関係者のグループに管理計画を提供することです。このリストは、追加のリンクされた利害関係者カードとキャンバスのセットを使用して作成されます。ステークホルダーマネジメントを通じて、関係者とのコミュニケーションを計画的に行い、情報の共有と理解を促進します。これにより、プロジェクトの進行がスムーズになります。 ⇒  参考サイト:  https://iasa-global.github.io/btabok/stakholder_management_plan.html (3) 品質管理の向上 BTABoKでは、品質管理のプロセスを標準化し、継続的な改善を促進する、以下のようなモデルや手法を活用することができます。 品質アシュアランスアプローチ 品質保証は、開発プロセス全体を通じて行われるものです。品質保証を早期に開始し、アーキテクチャを継続的にチェックすることは、非効率的な設計を検出することにつながります。開発プロセスの早い段階でエラーや問題を発見することで、修正にかかる費用が安くなります。品質アシュアランスフレームワークを導入し、品質管理のプロセスを標準化します。これにより、品質の一貫性が保たれ、バグや不具合の発生を防ぐことができます。 ⇒  参考サイト:  https://iasa-global.github.io/btabok/quality_assurance.html 　 DevOps アーキテクチャ DevOpsとは、ソフトウェア開発(Dev)と情報運用(Ops)を組み合わせて、組織のこれら2つの伝統的に別々の領域間のギャップを埋める一連のプラクティスを指します。これは、アジャイルの原則を従来の品質保証 (QA) 手法と統合することで、コラボレーションを改善し、プロセスを自動化し、効率を向上させることを目的としています。DevOps の主なコンポーネントであるContinuous Integration（CI:継続的インテグレーション）により、テストとビルドのプロセスを自動化できるため、一貫した品質を確保し、バグを早期に検出できます。また、Continuous Delivery（CD:継続的デリバリー）により、迅速な修正と迅速な反復が可能になり、チームは変更を迅速に展開してテストできます。CI/CDパイプラインを構築し、コードの変更を自動的にテスト・デプロイすることで、品質を維持します。DevOps プラクティスを採用することで、組織は、反復的なタスクの自動化、ワークフローの合理化、部門横断的なチーム間のコラボレーションの促進により、市場投入までの時間を短縮し、欠陥を減らし、顧客満足度を高めることができます。 ⇒  参考サイト: https://iasa-global.github.io/btabok/dev_ops.html テスト自動化 製品の品質を評価し、欠陥や問題を特定することで改善する活動であるテストは、実行領域テストから選択された有限のケースセット(通常は無限)に対するプログラムの動作の動的検証で構成され、予想される動作に関連し、見つかった欠陥の観点から機能システムと非機能システムを測定します。組織内でテスト自動化ツールを適切に使用することにより、反復的なテスト作業を効率化できます。これにより、テストの時間を短縮し、品質を高い水準で維持することができます。 ⇒  参考サイト:  https://iasa-global.github.io/btabok/tmtt.html 　 (4) スコープの管理 BTABoKでは、プロジェクトのスコープを明確に定義し、計画通りに進めるためのガイドラインとして、以下のような手法が提示されています。 スコープとコンテキスト スコープとは、アーキテクチャに関する一連の決定によって影響を受けるビジネステクノロジ戦略の量を指します。スコープとコンテキストは、アーキテクチャエンゲージメントをその影響のレベルとそれが発生する環境に基づいて理解するための2つの側面です。スコープとコンテキストの明確さは、アーキテクトやチームを大幅に節約でき、ドキュメントやテクノロジー手法と同じくらい重要です。スコープマネジメントプランを策定し、プロジェクトのスコープを明確に定義します。これにより、スコープの変更が発生した場合でも、計画通りに進めることができます。 ⇒  参考サイト:  https://iasa-global.github.io/btabok/scope_context.html 　 ASRカード ASR(Architecturally significant requirements)カードは、アーキテクチャ上重要な要件を定義するためのツールです。アーキテクチャ的に重要な要件 (ASR) は、アーキテクチャのライフサイクル全体を通じて主要な考慮事項である必要があります。戦略計画の初期段階では、ASR を特定して、アーキテクチャの選択と長期的なビジネス目標の整合性を確保することが有益です。これにより、テクノロジーの選択からリソースの割り当てまで、プロジェクト全体の方向性が導かれます。ASRは、適切に構造化されたアーキテクチャの基盤となり、システムのコンポーネントがどのように相互作用するか、およびスケーラビリティやパフォーマンスなどの側面をどのように処理するかに関する決定を促進します。設計段階では、技術チームが設計のビジョンに沿った選択肢を確保するための絶え間ないチェックとして機能します。要件の変更や新しいテクノロジーを検討する場合でも、ASRは不可欠です。これらの変更が既存のアーキテクチャ上の決定に与える潜在的な影響を迅速に評価し、システムの整合性を損なわない適応を導くのに役立ちます。 ⇒  参考サイト:  https://iasa-global.github.io/btabok/asr_card.html 　 アーキテクト エンゲージメント キャンバス アーキテクト エンゲージメント キャンバスは、アーキテクチャプラクティスによって、そのエンゲージメントモデルを理解し、計画するために使用されます。これは、より優れたアーキテクチャの成果をサポートまたは提供するための成果物、タスク、およびツールを定義するために使用されます。アーキテクト エンゲージメント キャンバスを利用して、プロジェクトガバナンスを強化することにより、スコープの変更に対する承認プロセスを明確にでき、スコープの管理が徹底され、プロジェクトの進行がスムーズになります。 ⇒  参考サイト:  https://iasa-global.github.io/btabok/architecture_process_engagement.html このように、BTABoKのモデルや手法を活用することで、アジャイル型システム開発の課題に対処し、より効果的な開発プロセスを実現することができると考えられます。 実際にアジャイル型システム開発の問題点を解決するためには、BTABoKのモデルや手法の理解を深める必要がありますので、BTABoK解説セミナーへの参加などもご検討ください。BTABoK解説セミナーについては、以下のIasa日本支部のイベントのサイトをご参照ください。 https://www.iasa-japan.org/event ご一読いただきありがとうございました。 Iasa日本支部では情報交換や勉強会の場を設けており、アーキテクチャの実践的な活動についても研鑽を深めていますので、今後のIasa日本支部の活動へのご参加、ご協力をよろしくお願いいたします。

はじめに 今回のコラムでは、BTABoKにおけるバリューモデルの一つである " Value Streams " について取り上げます。Value Streamsは、組織が提供する価値の流れを明確にする概念です。本コラムでは、Value Streamsの基本概念から、ITアーキテクトがどのようにValue Streamsを活用すべきか解説します。 Value Streamsとは BTABoKにおけるValue Streamsとは「組織がビジネス能力をどのように構成して、内部又は外部の利害関係者（通常は顧客）に価値を提供するかを示すもの」を意味します。 ITアーキテクトの役割は、単なる技術の実装にとどまらず、ビジネス目標を達成するための戦略的な意思決定を支援することにあります。そのため、ITアーキテクトは、データやシステム、インフラの構造を設計するだけでなく、価値の流れを最適化して組織全体のパフォーマンス向上に貢献する必要があります。ここで重要になるのが「Value Streams」の概念です。 Value Streamsは、組織のビジネス能力を通じて、どのように価値を創出し、その価値を提供するためにどのようなサービスが関わっているのかを明確にする手法です。ビジネス戦略と技術戦略を統合し、最適な価値の流れと価値の構成を理解するために、ITアーキテクトはValue Streamsを活用することが求められます。 Value Streamsがもたらす効果 組織が市場で競争力を維持し、持続的な成長を実現するためには、価値の流れを適切に理解し、最適化することが不可欠です。新しい製品やサービスの市場投入、合併・買収、調達先の変更、デジタル化、新規市場への参入、業務の最適化など、ビジネス環境の変化に適応するには、価値がどのように顧客・その他のステークホルダーへ流れているのかを把握する必要があります。 Value Streamsは、価値の流れを明確にし、最適化するための手法であるため 、組織はビジネスの変化に迅速に対応し、構造的な無駄や非効率を削減しながら、新たな市場機会を創出できます。 より具体的に述べると、Value Streamsを活用することで以下の効果があります。 顧客セグメントの差別化 能力の依存性と関連性の理解 規制や法改正の影響の理解 構造的無駄と非効率の特定 製品・サービスの国際化とカスタマイズ 既存の能力を活用した新しい価値の流れの創造 サービス指向と疎結合システムの設計 Value Streamsを活用するステップ Value Streamsを活用するためには、以下のステップを踏むことが重要です。 価値の流れの特定 まずは、価値の流れを特定する必要があります。 価値の流れを特定するための起点としては、顧客視点以外にも、お金の流れ、業務の流れ、ルールやポリシーの影響といったステークホルダー視点を起点とする方法があります。 【顧客視点】 製品・サービス（Products/Services） ⇒最も直接的な方法。顧客が認識する具体的な価値（＝製品やサービス）を起点に、価値がどのように流れるかを特定 ビジネスモデル（Business Model） ⇒製品・サービス単体ではなく、企業全体の価値提案を整理し、価値の流れを特定 付帯サービス（Ancillary Business Services） ⇒製品やサービスそのものではなく、関連する前後の活動（返品、故障対応、苦情、請求、情報提供など）を起点として価値の流れを特定 【ステークホルダー視点】 財務（Financial） ⇒売上、コスト、投資、利益などの財務データを基にバリューストリームを特定 運用（Operational） ⇒組織の活動（業務の流れ）の中でどのプロセスが価値を生み出しているのかを特定 ガバナンス（Governance） ⇒法規制、社内ルール、経営方針などがどのように価値提供に影響を与えるのかを特定 ビジネス能力のマッピング 価値の流れに沿って必要なビジネス能力をマッピングします。 価値の流れの視覚的マッピング 各ビジネス能力の接続関係の明示 サービスの相互作用の特定 価値の流れのパフォーマンス分析 価値の流れの効果を評価し、課題を特定します。 各能力のパフォーマンス評価（効率・有効性） 主要なペインポイントの特定 情報ギャップの特定と解消 価値の流れの貢献度分析 価値の流れが戦略や財務に与える影響を評価します。 戦略的影響と財務的影響の評価 価値提案のインパクトの分類（アドバンテージ、戦略的サポート、ビジネス上の必要性） 価値の流れの最適化 価値の流れを改善し、より高い価値を生み出すための調整を行います。 サービスの境界の明確化と最適な配置の検討 財務的影響の評価とコスト削減・収益最大化の施策検討 規制の影響分析とリスク対応策の策定 Value Streamsは、ITアーキテクトがビジネス目標を達成するために不可欠な概念です。Value Streamsを活用することで、価値の流れを最適化し、ビジネス戦略と技術戦略の整合性を確保することが可能となります。組織の競争力を高めるために、ITアーキテクトは価値の流れを理解し、価値の流れを最適化することが求められています。 ご一読いただきありがとうございました。 Iasa日本支部では情報交換や勉強会の場を設けており、システムの視覚化についても研鑽を深めていますので、今後のIasa日本支部の活動へのご参加、ご協力をよろしくお願いいたします。

デジタル製品やサービスが日々進化する中で、ユーザーにとって体験価値を高める品質の高さがとは何かを考えることがますます重要になっています。品質というと故障が少ない、性能が良い等の機能的な観点で語られることが多いですが、それだけではユーザーの体験価値を高める 品質的要素 として不足しており、 体験価値（UX）を高める品質的要素として「使いやすさ（Usability）」「ローカライズ（Localization）」「アクセシビリティ（Accessibility）」「パーソナライズ／カスタマイズ（Personalization/Customizability）」の4つを機能的品質に加えて考慮する必要があります。これらの概念を適切に設計に取り入れることで、より多くのユーザーに価値ある体験を提供し、競争力を高めることができます。BTABoKではこれらの要素をCompetency ModelのQuality Attributesで取り上げており、Quality（品質）というものを機能的な観点だけではなく、様々な要素により高められるものと捉えています。本コラムでは、BTABoKのCompetency ModelのQuality Attributesの中にあるUsability, Localization, Accessibility, Personalization/Customizabilityそれぞれの要素が持つ役割や実践方法について解説します。 使いやすさ（Usability）: ユーザー中心のデザインとは？ ユーザビリティとは、「製品やシステムがどれだけ簡単に、効率的に、満足のいく形で利用できるか」を指す概念です。ISO 9241-11では、ユーザビリティを「特定のユーザーが特定の目標を達成する際の有効性、効率性、満足度」と定義しています。 ユーザビリティの重要性を考えてみるとデジタル製品が溢れる現代において、直感的に操作できないサービスはすぐにユーザーから敬遠されてしまいます。たとえば、ナビゲーションが分かりにくいアプリや、情報が整理されていないウェブサイトは、競合他社の製品に比べて不利になります。 ユーザー中心設計（UCD）のアプローチ ユーザビリティを向上させるためには、「ユーザー中心設計（User-Centered Design: UCD）」が不可欠です。UCDでは、以下のような手法を用いて設計を行います。 ユーザー調査（インタビュー、アンケート、行動分析） プロトタイピング（ワイヤーフレーム、モックアップの作成） ユーザーテスト（A/Bテスト、ヒューリスティック評価） 使いやすさを向上させた成功事例として、AppleのiPhoneは、直感的なインターフェースとシンプルな操作性で世界中のユーザーに受け入れられています。また、Googleの検索エンジンも、ユーザーが最小限の手間で情報を得られるように設計されています。 ローカライズ（Localization）: グローバル展開の鍵 ローカライズとは、特定の地域や文化に適した形で製品やサービスを最適化するプロセスを指します。単なる言語翻訳だけでなく、文化的・法的な適応も含まれます。 世界市場で成功するためには、ローカライズが不可欠です。たとえば、以下のような点に注意する必要があります。 言語の違い（直訳では伝わらないニュアンスを考慮する） 通貨・単位の変更（米ドルから円、華氏から摂氏への変換） 文化的な配慮（色やシンボルの意味、宗教的な要素） 法規制の順守（GDPRなどのデータ保護法に対応） 以上のことから単純に言語を現地の言葉に翻訳する対応だけではないことがわかりますが、これらの要素を後付けで実装するにはソフトウェア構造を大きく修正する必要が出てくる可能性があり、ソフトウェア・ウェブサービス等では上流段階でローカライズ戦略の是非を考慮しておく必要があります。例えばローカライズ戦略として以下のような項目が考えられます。 インターナショナルデザイン：最初から多言語対応を考慮する 柔軟なインターフェース：言語によって文字の長さが変わるため、適応可能なデザインを採用 ローカライズテスト：ターゲット市場でのユーザーテストを実施 ローカライズ戦略の成功事例としてはNetflixは、各国のユーザー向けにローカライズしたコンテンツを提供し、世界中で成功を収めています。また、Airbnbも、現地の文化に配慮したユーザーインターフェースを提供することで、グローバルな展開を成功させています。 アクセシビリティ（Accessibility）: すべての人に優しい設計 アクセシビリティとは、障がいを持つ人々を含むすべてのユーザーが、製品やサービスを利用できるようにすることを指します。特に、視覚・聴覚・身体的な制約を持つ人々への配慮が重要です。これらはウェブコンテンツのアクセシビリティに関する国際基準であるWCAG（Web Content Accessibility Guidelines）や米国におけるアクセシビリティの法律であるADA（Americans with Disabilities Act）等で定義されています。 PCのOS等でも標準機能として実装されていますが、以下のようなものがアクセシビリティの代表的な実装といえます。 スクリーンリーダー対応（音声読み上げ機能の実装） 高コントラストモード（色覚障害のある人向けに適応） キーボード操作の最適化（マウスを使えないユーザーへの配慮） パーソナライズ/カスタマイズ: ユーザー体験の最適化 パーソナライズとカスタマイズは一見すると似たような意味合いに取られる場面がありますが、以下のような違いがあります。 パーソナライズ：システムが自動的にユーザーの行動を学習し、最適な体験を提供する（例：Amazonのレコメンド機能） カスタマイズ：ユーザー自身が設定を変更して最適な環境を作る（例：ダークモード、フォントサイズ調整） 上記の定義で考えるとシステムが自動的に行うものなのか、ユーザー自身が行うものなのかという部分に違いがあります。特にパーソナライズに関してはシステムが自動的に行うものであるため、AIというコンテキストで語られることが多く、実際にAmazon、Netflix、Spotify、その他様々なサービスでAIを活用してユーザーの嗜好に基づいたコンテンツを提供する企業が増えています。 「使いやすさ」「ローカライズ」「アクセシビリティ」「パーソナライズ/カスタマイズ」は、現代のデジタル製品の成功を左右する重要な要素です。これらを適切に取り入れることで利用時品質というユーザー（利用者）が直接感じる品質を高めることができ、より多くのユーザーに価値を提供し、企業の成長を加速させることができます。今後も、ユーザー体験を向上させるための技術や手法は進化し続けるでしょう。デジタル製品を開発する際には、これらの要素を意識し、より優れたサービスを提供していくことが求められていくでしょう。 Iasa日本支部では情報交換や勉強会の場を設けており、システムの視覚化についても研鑽を深めていますので、今後のIasa日本支部の活動へのご参加、ご協力をよろしくお願いいたします！