検索結果

１．アジャイル開発の利点と問題点 アジャイル開発は、ソフトウェア開発の分野で広く採用されている手法であり、その迅速な対応力と柔軟性が評価されています。アジャイル開発の主な利点としては、短期間でのリリースが可能であること、継続的なフィードバックを受けて改善を繰り返すことができること、そしてビジネスの変化に迅速に対応できることが挙げられます。これにより、顧客満足度の向上や市場への迅速な対応が可能となります。 しかし、アジャイル開発にはいくつかの問題点も存在します。例えば、要求の変動やコミュニケーションの複雑さ、品質管理の難しさなどが挙げられます。これらの問題点は、プロジェクトの進行を妨げる要因となり得ます。本コラムでは、このような問題点に対応する課題を支援するために、ビジネステクノロジーアーキテクチャ知識体系である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日本支部の活動へのご参加、ご協力をよろしくお願いいたします！

明けましておめでとうございます。本年もIasa日本支部をよろしくお願いいたします。さて今回はBTABoKのオペレーティングモデル内にある "Legacy Modernization" を紹介します。 現代のビジネス環境では、技術の進化が急速に進んでおり、企業はその変化に迅速に対応する必要があります。しかし、多くの企業は依然として古いシステム（レガシーシステム）に依存しており、これがビジネスの柔軟性や効率性に制約を与えることがあります。 本コラムでは、レガシーモダナイゼーションの重要性とそのアプローチについて詳しく解説します。企業がどのようにして古いシステムを最新の効率的なソリューションに変えることができるかを探り、具体的な戦略や実施時期、アプリケーションポートフォリオ管理の手法について触れます。これにより、企業が競争力を維持し続けるための実践的な方法を提供します。 レガシーモダナイゼーションとは すべてのシステムにはライフサイクルがあり、システムの構築と開始から始まり、システムの保守を経て、最終的にはライフサイクルの終わりに廃止されます。ライフサイクルの間、システムは組織やその顧客に価値を提供し、その価値提供を維持し、さらに多くの価値を生み出すことが望まれます。システムが適切に保守されていても、周囲の世界は常に変化しています。例えば、新しい技術の発見、法律や規制の変更、ビジネスの進め方の変化などです。 システムの寿命を延ばすために、持続可能性を確保しながら適切な変更を行う必要があります。持続可能性とは、「システムが提供する価値が、財務的なコストや労力に対して大幅に上回ること」と定義できます。 モダナイゼーションは、システムが「目的に適合」し、価値提供とコストのバランスを維持するためにシステムを変更するプロセスです。 レガシーとは、古い技術を使用している既存のシステムや、組織の業務に合わなくなった機能を指します。システムが依然として重要な価値を提供している場合でも、効率的でないことがあります。レガシーモダナイゼーションは、レガシーシステムに変更を加えて、組織にとってより最新で効率的なソリューションを提供するプロセスです。 なぜレガシーモダナイゼーションが必要なのか 高いレベルのアジリティ（機敏性）を持つ組織は、競争上の大きな優位性を持ち、周囲の環境に迅速に対応し、変化することができます。高いレベルのアジリティを達成するためには、組織を支えるシステムも周囲の環境に迅速に対応し、変化する必要があります。レガシーシステムは、変更が難しいことやビジネス活動を効率的にサポートできないことが多いため、アジリティに制約を与えます。システム設計時には存在していた技術的制約が現在は存在しない場合や、もはや関連性のない特定の業務手順のために設計されたシステムということもよくあります。 レガシーモダナイゼーションは、レガシーシステムを変更または置き換えることで、組織をより効率的かつコスト効果の高いものにします。これにより、既存のビジネスプロセスを最適化するだけでなく、新しいビジネスチャンスを開くこともできます。 またセキュリティは、レガシーモダナイゼーションの重要な推進要因です。サイバー攻撃は一般的であり、時間とともに高度化しています。システムのセキュリティは時間とともに低下し、レガシーシステムは現代の攻撃手法を防ぐために必要なサポートや技術を持たないことが多く、ハッカーにとって容易な標的となります。これは組織にとって重大なビジネスリスクを意味します。 レガシーシステムが古くなると、技術的な制約によりパフォーマンスに制約が生じることがよくあります。これにより、システムの処理時間や容量が制限され、組織の価値提供能力に影響を与えます。レガシーモダナイゼーションは、容量を増やしたり、他の非機能的特性（高可用性、回復力など）を改善したりする方法を提供することができます。 レガシーモダナイゼーションのアプローチ １．持続可能性の促進 持続可能性は、システムの寿命を延ばすための重要な品質属性です。アーキテクチャが持続可能であることを保証することは、現在の期待に応えつつ、将来の期待を損なわないことを意味します。これは簡単ではありませんが、適切な技術選択を行うことが重要です。例えば、新しい興味深い機能を持つ最先端技術を選択することは短期的な利点をもたらすかもしれませんが、数年後にサポートがなくなると持続可能性を損なう可能性があります。 ２．価値を見極め、過去の投資に拘らない  システムや技術の価値は、組織がビジネス価値を効果的に提供するのをどれだけサポートするかということです。一部の組織は、システムの開発と保守に多額の投資を行っています（「サンクコスト」とも呼ばれます）。システムがもはや価値提供を効果的にサポートしなくなると、システムに投資された金額のために廃止や移行に対する抵抗が生じることがあります。これは政治的な動機であり、組織内の特定の利害関係者にとってデリケートな問題となることがあります。しかし、システムが期待される価値を提供しなくなった場合、それは過去の投資に関係なく、ビジネスにとって重荷であり、コストでしかありません。 ３．変化を受け入れる  モダナイゼーションは技術やシステムだけでなく、組織内の人々がこれらのシステムに基づいたスキルやプロセスで働いていることも含まれます。これらの人々がモダナイゼーションの計画に参加し、スキルを更新し、新しい方法を学び、新しいプロセスや技術を形成することが重要です。これにより、最新の技術や新しいシステムへの移行が容易になります。これがうまく処理されない場合、人々が排除されたと感じ、抵抗が生じる可能性があります。さらに、モダナイゼーションは既存のプロセスを真に再考する機会を提供します（既存の[レガシー]技術によって制約されることが多い）。既存のソリューションの制約から解放されると、顧客にとってより速く、安価で、効果的な方法や、他の改善を提供する方法が見つけることができるもしれません。 システムがモダナイゼーションを必要とする時期 モダナイゼーションの計画において重要なのは、システムがレガシーと呼ばれる限界に達していることを認識することです。これをできるだけ早く認識することで、リスクを軽減し、行動を起こすための時間を確保できます。以下は、システムがレガシー状態に達し、モダナイゼーションが必要になる可能性が高いことを示すいくつかの指標です。 １．技術サポート  最も簡単に見分けられる属性の1つは、使用されている技術のサポートが終了されていることです。ほとんどの主要な技術には、サポートのロードマップがあり、サポートが終了される予定日があります。これは、技術の特定のバージョンに適用される場合もあれば、技術そのものの完全な終了になる場合もあります。例えば、オペレーティングシステム、データベース、開発プラットフォームのサポートです。技術プラットフォームを選択する際には、この側面を考慮することが重要です。サポートがすぐに失われるプラットフォームを選択すると、モダナイゼーションの必要性が近い将来に発生します。また、市場の技術を常にチェックし、潜在的なモダナイゼーションを適時に計画することも重要です。 ２．スキルの調達  システムをさらに開発または保守するために必要な適切なスキルを持つ人々を見つけるのが難しい場合、これはレガシー技術の指標となることがあります。これは単に、必要なスキルを持つ人々が市場に少なくなっていることを意味し、これによりこれらの人々を雇うコストが非常に高くなります。 技術が古くなると、エンジニアコミュニティは新しい、よりエキサイティングな技術を好み、古い技術のスキル市場は縮小し始めます。多くの企業がこれらの古い技術を使用して重要なコアビジネスシステムを運用しているため、これらの古い技術に対する需要が依然として高いことがよくあります。例えば、多くの組織がコアビジネスサポートの一環としてCOBOLベースのシステムを運用しています。市場が縮小し、限られたリソースに対する需要が続くと、採用やコンサルティングのコストが増加します。組織が使用する技術に対して健全なスキルベースがあることを確認するために市場を監視することは大切です。利用可能性の問題がある場合やコストが大幅に上昇している場合は、モダナイゼーションを計画します。 ３．セキュリティ  古くなるシステムは、年を重ねるごとにセキュリティを確保するのが難しくなります。上記のように、ハードウェア、オペレーティングシステム、アプリケーションのベンダーからのサポートが終了され、セキュリティアップデートやパッチが提供されなくなります。さらに、スキルに関するポイントに関連して、スタッフがシステムを管理し、セキュリティを確保することができなくなると、システムは未知で管理不能な状態に陥る可能性があります。セキュリティリスクレベルを監視し、組織のリスク許容度に沿って緩和策や管理策を講じることができなくなる前に、システムをモダナイゼーションの計画に組み込む必要があります。 ４．業務上の負担 競争力を維持するためには、一定のレベルの価値提供を維持する必要があります。市場は静的ではないため、競合他社は常に価値レベルを引き上げており、組織は市場に適応する必要があります。これには、ビジネスの進め方を変更することが含まれる場合があります。組織内のシステムは、価値提供をサポートし、促進します。システムの寿命がくる前に、組織の業務手続きが変わることがありますが、以前の業務手続きのために設計されたシステムはそのまま残ります。これにより、競争力のある価値提供を確保するために、ビジネスサイドで多大な努力が必要になることがあります。例えば、システムを業務慣行に合わせるためにルーチンや回避策が実行されたり、特定の作業活動が異なる技術でつなぎ合わされたり、手動で計算やレポートをEXCELで実行するなどです。 これは、本来ビジネス価値を生み出す活動に向けられるべき努力を必要とします。ユーザビリティ調査、要件の収集、または定期的なフォーラムを通じて情報を収集することで、業務で負担すべき内容を特定し、システムが組織のプロセスとどれだけ一致しているかを示すことができます。システムがビジネスのニーズと一致していない場合、モダナイゼーションを計画してシステムをビジネスに再調整することを検討しなければなりません。 ５．変化に対応する能力  組織とそのビジネスは時間とともに変化するため、組織内のシステムも変化し、効率的なビジネスサポートを提供する必要があります。システムの変更にかかるコストと時間は、組織にとって重要です。組織のシステムは、ビジネスと同じくらい迅速に変化に適応する必要があります。システムの変更が遅くなったり、コストがかかるようになったりすると、システムがモダナイゼーションの候補であることを示す指標となります。これは、システムのコスト（OPEXおよびCAPEXの両方）を監視することで特定できます。変更の仕様から変更の提供までの時間も監視できます。時には、システムに重いリリースサイクルを強いる制約がある場合があります。例えば、システムは年に1回または2回しかリリースを提供できません。これにより、ビジネスが変化に対応する能力が制限されます。 ６．ボトルネック  システムの全景には多くの現代的なシステムが含まれることがありますが、単一のレガシーシステムが価値の流れやビジネスプロセスにボトルネックを作り出すことがあります。作業の流れの中で、上流のレガシーシステムの存在は、下流のモダナイズされたシステムの利点を妨げるか、減少させる可能性があります。作業と努力がボトルネックに集中し、サポートと性能が優れた他のシステムが利用されなくなります。現代のシステムがその完全な性能で使用されていないことに気付くことは、上流にレガシーの問題があることを示す指標となるかもしれません。これらのボトルネックを特定することは非常に重要です。ボトルネックは、下流のシステムがその完全な潜在能力を実現するのを妨げます。 ７．許容量の制限  技術は急速に変化し、処理能力やストレージの容量に関して技術の許容量は絶えず進化しています。古い技術には、特定のプラットフォームやハードウェア向けに設計されているため、制限がある場合があります。これは、管理できるデータの量や、組織がイベントに対応する速度（例えば、販売注文や販売データの分析）に関して、組織に制限をもたらします。組織が情報をタイムリーに利用できない場合や、作業項目が遅れて処理されている場合、これはレガシーシステムの指標となることがあります。 アプリケーションポートフォリオ管理 アプリケーションポートフォリオ管理の手法は、アプリケーションの状況を監視し、コストと価値を評価するために使用できます。アプリケーションの運用費用（OPEX）と資本支出（CAPEX）を監視することで、アプリケーションの運用コスト（OPEX）と開発などの投資（CAPEX）を比較することができます。コストが価値に見合うかどうかを評価するために、一連の指標を使用して各システムを評価できます。アプリケーションを評価するために使用できる典型的な指標は次のとおりです： 使いやすさ 将来性のある技術 サポートの可用性 スキルの可用性 ユーザー数 ビジネスの重要性 これらの指標で低い評価を受けると、アプリケーションやシステムが寿命に近づいていることを示すことがあります。この情報を使用して、アプリケーションのモダナイゼーションや廃止の計画を立てることができます。レガシーモダナイゼーションの戦略的な監視と計画に使用できる方法の1つが、TIMEモデル（Gartner）です。 TIMEモデルは、ポートフォリオ内のアプリケーションを示し、それらがサポートするビジネス能力に配置します。アプリケーションは次のように分類されます： Tolerate（許容） ：アプリケーションが価値を提供しており、移行や置き換えのコストが高すぎるため許容されるが、投資は正当化されない。これらのアプリケーションは、再設計によるモダナイゼーションの対象となる場合があります。 Invest（投資） ：アプリケーションが高い価値を提供しており、投資の対象となる。 Migrate（移行） ：アプリケーションの機能が価値を提供しているが、もはや効果的でない場合、機能やデータを最新のプラットフォームに移行することでモダナイゼーションを実現できる。 Eliminate（廃止） ：アプリケーションがもはや価値を提供しておらず、廃止される。アプリケーションは完全に別のアプリケーションに置き換えられる場合があります。 以下の図は、Tinkelman Coffee Shopに基づくTIMEモデルの例を示しています。 上記の例では、いくつかのアプリケーションがTinkelmanのビジネスをサポートしています。同じアプリケーションが複数の機能をサポートすることがあることに注意してください。これは、ある機能でアプリケーションを移行または廃止しても、別の機能でアプリケーションに投資を続けることができることを意味します。 COFI-BIZは、いくつかの機能で広く使用されているビジネスシステムです。しかし、COFI-BIZの物流モジュールはもはやサポートされておらず、物流システムLOGI-GOに移行されます。いくつかのコーヒーショップでは、古い会計システムA-COUNTがまだ使用されています。これはCOFI-BIZに移行されます。POS 80の販売時点管理システムは社内で開発されましたが、システムを維持するスキルがもはや利用できないため、SALE-POINTシステムに置き換えられます。ROBO-PACKおよびAD-DESIGNシステムは許容されており、移行や置き換えの投資には値しませんが、ROBO-PACKは一部のモジュールを再設計することでモダナイゼーションが可能です。 TIMEモデルは、アプリケーションポートフォリオを評価し、レガシーモダナイゼーションのための取り組みを計画するために使用できます。このモデルは、ポートフォリオの視覚的なステータスを提供し、レガシーシステムが効果的に管理されることを保証します。 レガシーモダナイゼーションの戦略 【リ・エンジニアリング】  レガシーシステムのリ・エンジニアリングは、システムの大部分を再設計または変更する大規模な技術的改修を伴うことが多いです。システムの機能が依然として組織にとって価値があるが、保守コストが高い場合や技術サポートが不足している場合に有用な戦略です。実際には、以下のような結果が得られることがあります： レガシープログラミング言語を最新のプログラミング言語に移行する 特定の機能やモジュールの完全な再設計 プラットフォームやサードパーティコンポーネントのモダナイゼーション アーキテクチャ層のモダナイゼーション（例：データ管理やプレゼンテーション） リ・エンジニアリングは非常に費用がかかることがあります。自動化ツールを使用してシステムをリ・エンジニアリングすること、例えば、あるプログラミング言語から別のプログラミング言語に変換したり、新しいプラットフォームに移行したりすることができます。自動化ツールの使用はリ・エンジニアリングプロセスを短縮化しますが、実装の品質を向上させる可能性は低いです。 【ラップアップ】  レガシーシステムを完全にリ・エンジニアリングするのは費用がかかりすぎるが、依然としてビジネスにとって価値のあるコア機能やデータを含んでいる場合があります。問題は、レガシーシステムが組織のアジリティに制約を与えていることです。一つのアプローチは、レガシーシステムを最新技術を使用してファサードでラップし、最新技術の相互運用性を利用してレガシー機能やデータにアクセスすることです。 例えば、レガシーシステムをAPIでラップし、レガシーシステムからデータを仲介して最新のアプリケーションに公開することができます。この技術を使用すると、レガシーシステムのデータをAPI経由で使用し、フロントエンドとして最新のアプリケーションを提供することができます。 この戦略には制限があります。特にパフォーマンスや容量が問題となる場合、レガシーシステムをラップすることでパフォーマンスが向上することはなく、追加のオーバーヘッドが発生することさえあります。レガシーシステムとの通信プロトコルも制約され、リアルタイムでの通信が制限されることがあります。 【クラウドマイグレーション】  レガシープラットフォームを改善するための一般的な戦略は、アプリケーションをクラウドベースのプラットフォームに移行することです。ハードウェアや運用担当者に関連するコストを削減することが目的とされることが多いです。クラウド環境でシステムを運用するもう一つの利点は、ニーズに応じて容量を容易にスケールできることです。 クラウド移行の重要な側面は、法的およびセキュリティの影響を考慮することです。組織は、システムに機密データ（例：個人情報、患者記録、財務情報）を保存することがあります。このような情報は、GDPR（EU）などの規制の対象となる場合や、データが発生した国によって法的に管理される場合、または単に組織にとって機密性が高い場合があります。したがって、情報が物理的にどこに保存されているか、クラウドサプライヤーがどの管轄下で運営されているかを把握し、第三者や外国政府によるデータアクセスを防ぐことが重要です。 【データマイグレーション】 一般的なモダナイゼーション戦略は、レガシーシステムを最新のシステムに移行することです。これは、レガシーシステムに含まれるデータが依然として組織にとって非常に価値がある場合に行われます。新しいシステムを購入または開発し、レガシーシステムからのデータを最新のシステムに移行します。この戦略は、レガシーシステムからの貴重なデータを保持しながら、最新の技術を備えた新しいシステムを提供します。 新しいシステムの購入または開発には多額の投資が必要であり、かなりの時間がかかります。レガシーシステムから新しいシステムへのデータ形式を変換するための移行ツールが必要であり、移行はデータの一定の割合でしか成功しない場合があるため、手動での移行が必要になることがあります。また、レガシーシステムと新しいシステムが一定期間並行して稼働する場合があり、これにより二重の保守コストが発生することがあります。 【廃止とリプレース】  場合によっては、レガシーシステムが単に寿命を迎えることがあります。過去に蓄積されたデータはほとんど価値がないと見なされ、システムは組織が必要とする機能を提供する最新のシステムに単純に置き換えられます。レガシーシステムは廃止され、アーカイブされます。レガシーシステムからデータが必要な場合は、アーカイブから取得できます。 この戦略は、レガシーシステムを迅速にリプレースする方法を提供しますが、組織が新しいシステムに適応するまでに時間がかかることがあります。新しいシステムの導入には、担当者の大規模なトレーニングが必要になる可能性があります。初期の期間中、組織はアーカイブと新しいシステムの両方からデータを取得する必要があるかもしれません。これには、時間のかかる手動プロセスが必要になることがあります。   まとめ レガシーモダナイゼーションは、企業が競争力を維持し、効率的にビジネスを運営するために重要です。古いシステムを最新ソリューションに変えることで、柔軟性を高め、セキュリティリスクを軽減し、ビジネスの価値提供を最適化できます。適切な戦略と計画を立てることで、企業はレガシーシステムの制約を克服し、変化する市場環境に迅速に対応できるようになります。これにより、顧客に対してより良いサービスを提供し続けることができるでしょう。 ご一読いただきありがとうございました。Iasa日本支部では情報交換や勉強会の場を設けており、システムの視覚化についても研鑽を深めていますので、今後のIasa日本支部の活動へのご参加、ご協力をよろしくお願いいたします。

Iasa日本支部 理事 中山 嘉之氏が自著「 DXの大前提―エンタープライズアーキテクチャのセオリー 」 について解説する会員限定スペシャル動画 5回 シリーズの第5回(最終回)です。もう本を読まれた方、これから読まれる方、どちらも必見です！

2024年11月7日(木)に開催された「 アニュアル・カンファレンス2024 」の各講演で使用した資料です。

Iasa日本支部 理事 中山 嘉之氏が自著「 DXの大前提―エンタープライズアーキテクチャのセオリー 」 について解説する会員限定スペシャル動画 5回 シリーズの第4回です。もう本を読まれた方、これから読まれる方、どちらも必見です！

デジタル変革が企業活動の中心的課題となる中、情報処理推進機構（IPA）が提唱する デジタルスキル標準 をご存じの方も多いでしょう。それには、ビジネスアーキテクトやデータサイエンティスト、デザイナーなど、さまざまな類型のスキルを有する人材が組織の競争力を支える存在として位置付けられています。これらの人材が専門的スキルを発揮しつつ、横断的なチームとして協働することで、企業の技術戦略や業務プロセスを高度化することが求められています。 今回紹介する「 拡張チーム（Extended Team） 」の考え方は、BTABOKピープルモデルの主要な概念であり、デジタルスキル人材の活用にも寄与すると考えます。拡張チームとは、正式なアーキテクチャチームの枠組みを超えて、開発リードやビジネスアナリストなどの役割を巻き込み、組織全体でアーキテクチャ実践を推進する手法です。このモデルは、スキルや知識を持つ個々の人材が、より広い視点で組織の技術的および業務的課題に取り組む場を提供します。 ＊＊＊ 拡張チームとは 拡張チームとは、正式なアーキテクチャチームに限定されず、組織全体のさまざまな役割を活用してアーキテクチャ実践を推進する取り組みです。このモデルは、開発リード、ビジネスアナリスト、プロジェクトマネージャーなど、他部門のメンバーを含め、組織全体の視点で課題解決と戦略実行を目指します。拡張チームは、アーキテクチャチーム以外の人材を含め、組織全体でアーキテクチャ戦略を形成し、実行するための取り組みです。これによって、次の利点が期待できます。 組織全体のカバレッジ向上： 専門チームのリソースを補完し、プロジェクトや能力ポートフォリオの広範囲なサポートを実現。 意思決定の分散化： 各部門やプロジェクトにおける迅速で適切な技術的意思決定を可能に。 自己指向型チームの育成： メンバーが自身の役割を超えて戦略的な視点を持つよう奨励。 拡張チームの重要性と課題 拡張チームモデルの重要性には、特に以下の点があげられます： リソースの不足に対応する柔軟性： 多くの組織ではアーキテクチャチームの規模が小さく、すべてのプロジェクトや活動をカバーするのは難しいのが現状です。拡張チームは、組織内のさまざまな役割を活用することで、リソース不足を補い、プロジェクトや能力ポートフォリオ全体を効果的にサポートします。 分散型意思決定の推進： アーキテクチャに関する意思決定を特定のチームや個人に集中させるのではなく、拡張チームを通じて分散化することで、迅速で適切な意思決定が可能になります。これにより、現場に近い視点を活かした判断が実現します。 統合的なアプローチの促進： 拡張チームモデルを導入することで、組織全体がアーキテクチャ実践に統合的に取り組む姿勢が育まれます。これにより、部門間の連携が強化され、デジタル変革の実現に向けた一致団結したアプローチが可能となります。 戦略的価値の最大化： 拡張チームにより、戦略的なアーキテクチャ能力を広範囲に展開し、技術投資や業務プロセス改革の優先順位付けを全社的な視点で最適化することができます。 拡張チームは、プロジェクトや能力ポートフォリオ全体をカバーするのに十分な数のアーキテクトがいないため、多くの組織で形成されます。特にアーキテクチャ成熟モデルの初期段階では、多くの組織が拡張チームモデルを採用しています。それにより、拡張チームとして課題を抱える可能性もあります。例えば、これらの組織では開発リードやアジャイルチームがプロジェクトのための技術投資を決定することがよくあります。局所的に最適化された成果物が生まれ、組織内で他の投資と重複したり、さらには同じような取り組みが繰り返されることもあります。その結果、膨大な作業の重複、複雑すぎるシステム、そして不適切な投資決定が発生することがあります。さらに、ほとんどの開発チームは、組織にとって何が最適かを正確に判断するためのビジネススキルに欠けています。他の拡張チームの役割も同様の課題に直面しています。例えば、PMO（プロジェクト管理オフィス）は、技術的な深みが乏しい個人によって決定されたビジネス目標に基づいてプロジェクトを優先する傾向があり、その結果、多くの重要な要素がロードマップから外されてしまうことがあります。 したがって、拡張チームモデルを成功させるには、組織がかなり高い成熟度に達していることが必要です。例えば、以下のような観点での成熟度が求められるでしょう。 分散型意思決定の観点： 意思決定をエンタープライズの末端に近づけることで、市場変化への迅速な対応や顧客ニーズへの適合が可能になります。ただし、従来のエンタープライズレベルでの説明責任や最適化が犠牲になるリスクもあります。拡張チームでは、パートナーがトレーニングや指導を通じてアーキテクチャスキルを習得し、迅速な対応と全社的な最適化を両立させる仕組みが求められます。 カバレッジとエンタープライズの観点： すべての重要な投資について情報に基づいた価値ある意思決定を行う能力が必要です。エンゲージメントモデルでは、意思決定プロセスを追跡可能にし、アーキテクチャ的な判断を組み込むことが目標となります。 ジャスト・イン・タイム・アーキテクチャの観点： 意思決定を可能な限り遅らせ、客観的証拠に基づいた選択を行う実践です。これにより迅速なシステム提供が可能になりますが、大規模なプロジェクトでは慎重な管理が必要です。経験豊富なアーキテクトをフルタイムで配属することが成功の鍵となります。 パートナーロールのエンパワーメントの観点： 成熟したアーキテクチャプログラムでは、他の役割を支援し、競争関係を排除します。このアプローチは、デジタル戦略やデリバリーへの集中を補完し、エンタープライズ全体の価値管理やイノベーションを強化します。 拡張チームへのアプローチ 拡張チームを構築する第一歩は、アーキテクト自身の実践者から始まります。そしてその一歩を拡張チームにつなげるためのアプローチを紹介します。 信頼性の構築： 拡張チームをチームの一部として扱い、組織内で信頼性と合意を構築する必要があります。信頼性が欠ける場合、隠れた敵意や対立が生じる可能性があります。リーダーを特定し、適切にトレーニングや指導を行うことが重要です。 構築し、所有し、統治しない： アーキテクチャは創造的な機能であり、監督プロセスではありません。拡張チームはイノベーションとデリバリーに集中し、ガバナンスやレビューの役割を最小限に抑えるべきです。 「Yes」を基盤とした文化の構築： 組織に対して「No」と言う場面を減らし、「Yes」と言える分野に焦点を当てることが重要です。信頼性と価値が認識されれば、投資と優先順位のバランスを取ることが可能になります。 アジャイルチームとの協働とデリバリー中のアーキテクトの役割： アジャイルとアーキテクチャは相互補完的であり、アーキテクトがチームに深く関与することで、デリバリーと価値創出の最適化が可能になります。価値あるアジャイルアーキテクチャ実践の条件とは以下のようなことです。 　- チームがアーキテクチャの価値を理解していること。 　- アーキテクトがデリバリーに深く関与していること。 　- アジャイルリーダーがアーキテクチャスキルを習得していること。 　- アーキテクトのプロジェクトや製品への明確な割り当て。 　- 強力な指導やパートナーシップモデルの存在。 　- エンゲージメントモデルの適切な成熟度。 拡張の原則： アーキテクチャは他の役割の上にあるのではなく、異なる機能を持つものです。エンゲージメントモデルでは、十分なスキルを持つ他の役割が責任をカバーする必要があります。 ＊＊＊ まとめ 拡張チームは、限られたリソースを補完しつつ、より多くの人材を巻き込み、戦略的なアーキテクチャ実践を実現します。組織がこのモデルを効果的に採用することで、技術革新と業務プロセスの高度化が促進されるでしょう。Iasa日本支部は、アーキテクト人材のスキル啓蒙やコミュニティ活動の拡大に積極的に取り組んでいます。このような活動を通じて、拡張チームモデルを導入する組織への具体的なサポートにも貢献できればと思います。このようにIasa日本支部の活動が、アーキテクト人材の育成とデジタル変革の加速に大きく寄与することをご期待ください。

さる11月7日、品川シーズンテラス・カンファレンスにて、「デジタル時代の融合アーキテクチャ」〜　ビジネス、データ、テクノロジーが創る未来　〜」と題し、Iasa日本支部のアニュアル・カンファレンスが開催されました。各界から有識者による４つの講演に、オンライン・オフラインとも多数ご参加された今年のイベントの様子をお伝えします。 講演 1. AI・DX時代の価値実現必須スキルとしてのビジネスアーキテクチャ IIBA日本支部理事、KITネットワークス株式会社代表取締役 藤重 茂 様 株式会社クリエビジョン　代表取締役 塩田 宏治 様 最初の講演はビジネスアーキテクチャがテーマ。前半は塩田様、後半は藤重様のお二人でのご講演でした。AIの進化に伴い、ビジネスアーキテクチャが今後ますます重要になる、というのが塩田様のメッセージです。 クラウドやAIの進展によって、エンタープライズ・アーキテクチャにおいても、プロジェクト・ライフサイクルにおいても、クリティカルパスはビジネスアーキテクチャへシフトしていきます。 つまり「AIが高度化するほど、コンテキストとしてのアーキテクチャが重要になる」と塩田様。まさにおっしゃる通り。AIで代替できない役割、それがビジネスアーキテクトですね。 続く藤重様のご講演は、ビジネスアーキテクチャの様々なドメインから、今回はケイパビリティとバリューストリームにフォーカスします。プロセスを実行するためには、それに対応するケイパビリティが不可欠です。ケイパビリティのオーケストレーションが、ビジネスの成功を左右する鍵となります。 ケイパビリティは中々日本語にしにくい概念ですが、最近ではジョブ型雇用も普及が進んでいることですし、そういうところからでも今後日本のビジネス社会のなかでも一般化が進んで行くと良いなあ、とこれは個人的な期待。 講演 2.　 データマネジメント視点によるアーキテクチャ考察 DAMA日本支部 理事、KPMGコンサルティング リードスペシャリスト 吉村 泰生 様 ビジネスに続いて次はデータがテーマです。データマネジメントの観点から、アーキテクチャ設計の重要性を吉村様に語っていただきます。 データは企業の重要な資産ですね。資産ですから価値があります。それを左右するのはその構造と意味、というところまではどなたもお分かりですが、問題はそれをどうやって行動に繋げるかですね。 そのような課題の解決に活用できるのがDMBOK。コンテンツはDAMAのホームページからダウンロードでき、引用を明記すれば商用利用も可、とのことなので、どんどん広めて活用をお勧めしたいと思います。 同音異義とか異音同義なんてどこでもお困りの方は多いでしょう。そこでデータモデルを描いてみることで、データの「構造と意味」を明らかにすることで「データで稼ぐ」ことが比喩ではなく現実に可能になるわけですね。AIのビジネス活用などでも正にそう。この辺りは先の塩田様のクリティカルパスにも通じるところがあります。 講演は吉村様の「データの名称と意味の定義に敏感であること」というメッセージで締めくくられます。私もおもわす「そうだ、そうなんだ！」とこぶしを握り締めてしまいました。 講演 3.　　　デジタルアドバンテージを強化するクラウドネイティブ技術とAIの融合 フェンリル株式会社 シニアクラウドコンサルタント 　　日置 幸宏　様 3番目はアプリケーションを取り上げます。クラウド技術、生成AIといった技術トレンドから、そのような昨今の状況におけるITアーキテクトの立ち位置、そしてその実行に求められるスキルセット (ケイパビリティと呼んでも良いかもしれませんね)と、日置様の博覧強記に裏打ちされた行動力には敬服することしきりです。 RAG (検索拡張生成) は吉村様も取り上げられていましたが、ガートナーによるともうハイプサイクルの頂点だそうで、世の中早く変わり過ぎですね。個人的にはArchiMateでグラフRAGやりたいなあ、なんて思ってましたが、やらないうちにRAGが死語になってしまうかも。でもグラフデータが無くなることはないし、もっとすごい技術がすぐにやって来るのでしょう。それもより安価で。 モノゴトの表層ではなくファクトに基づいて、本質を理解することこそが価値に繋がる。この「ファクトを知りたい・本質を理解ししたい」という内発的要求が大事なんですね。なんといってもここだけはAIでは代替出来ません。 個人的に一番刺さったのは、最後に照会された「新技術の情報収集を止めた途端に老害化が始まる」というモヒカンSlackからのメッセージでした。日置様のおっしゃる通り、いつまでも「変化を楽しむ」心を忘れないようにしたいものです。 講演 4. データドリブン経営の観点から見たイベントドリブンアーキテクチャの可能性 Solace Corporation カントリーマネージャー 山口 智之 様 最後の講演はテクノロジーがテーマ、イベントドリブンアーキテクチャを実現するソリューションのご紹介です。 お話を伺うにつれ、自分の考えはなんと呑気なんだろう、と何だか恥ずかしくなってきました。新入社員のエンロールメントに1日2日掛かる、それって意味有るのか？と言われても、「え、ダメなの？」と思ってしまう自分が居るわけです。 日本で失われた30年と呼ばれている年月に、欧米のビジネスは無形の資産からどう価値を生み出すかにこれほど真剣だったのか、と思い知らされますね。無形の資産とは「データ」だけじゃない。もうひとつ「時間」もそうだ、ということに気づかされました。 イベントはIasa日本支部の松井代表理事のご挨拶で締めくくられました。イベントのテーマである「ビジネス、データ、テクノロジーが創る未来」は、アーキテクチャを通じた融合によって実現する未来ですね。ビューポイントの違いは色々あれど、「よりよい未来」という思いは共通。なんといっても「アーキテクチャ」は「何らかの意思を以て作られた人工物の内部構造」ですからね。Iasa日本支部が、そんなアーキテクトが流派を超えて交流出来る場になれるよう、精進を続けていきたいと思います。

Iasa日本支部 理事 中山 嘉之氏が自著「 DXの大前提―エンタープライズアーキテクチャのセオリー 」 について解説する会員限定スペシャル動画 5回 シリーズの第3回です。もう本を読まれた方、これから読まれる方、どちらも必見です！

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

Iasa日本支部 理事 中山 嘉之氏が自著「 DXの大前提―エンタープライズアーキテクチャのセオリー 」 について解説する会員限定スペシャル動画 5回 シリーズの第2回です。もう本を読まれた方、これから読まれる方、どちらも必見です！