検索結果

今回のコラムはBTABoKのオペレーティングモデルの " Requirements " について取り上げます。 企業の持続的な成功と競争力の維持には、適切なアーキテクチャ上重要な要求（Architecturally Significant Requirements 以下ASRと略）の識別・管理が鍵となります。 本コラムでは、ASRの概念や識別方法・管理方法について解説させていただきます。 「要求」の大部分は、価値のために必要なものではない。それらは実際には、一人のシステム・ユーザーの好みに関するものなのだ。より良いシステムのために、ユーザーの嗜好よりも価値のマネジメントを今すぐ学び始めよう。【Paul Preiss】 IasaのCEO兼創設者であるPaul Preissが指摘するように、すべての要求が直接的な価値を持つわけではありません。つまり、個々のユーザーの好みを超えて、組織の成長と成功に寄与する要求が価値のために真に必要な要求と言えるでしょう。 では、アーキテクチャ上重要な要求（ASR）とは何なのでしょうか。 ASRはBTABoKで使用されている用語で「組織に対する価値の開発と提供に関連する一連の概念」とされています。少し抽象的なので言い換えると「組織全体の戦略的目標を支え、より大きなビジネス価値を生み出すために欠かせないアーキテクチャに関連する要求」ということです。 アーキテクチャに関連する要求は アーキテクチャ開発ライフサイクル(ADLC) の初期に収集する必要があるため決定することが困難です。組織はプロジェクトが進行するにつれて、初期の要求にさらに詳細な要求を加え、継続的に改善していく必要があります。要求に関するすべての決定が価値を持ち、追跡可能であることがASR管理の大きな目標とされています。 続いて、アーキテクチャ開発ライフサイクル(ADLC)の中でASRはどのように洗練されていくのか見ていきましょう。 イノベーション／アイデア 新しいアイデアや概念がASRとして提案され、ビジネスケースの形成に向けて展開されます。 ビジネスケース プロジェクトの費用と価値創出の可能性が評価され、ASRがより具体的な形で明確化されます。 エピック／ソリューションストーリー 詳細なプロジェクト要件としてのASRが整理され、アジャイルやリーンの手法を通じて実際のプロジェクト計画に統合されます。 詳細要求事項 このレベルのASRでアーキテクチャに関連すると考えられるものは少ないですが、アーキテクチャへの影響を確実に特定するために、アーキテクトが継続的にレビューする必要があります。 この際、アーキテクトは適切なアーキテクチャ要求を決定する必要がありますが、 「適切な」要求とは一体何でしょうか？ アーキテクチャに関連する要求が「適切」とされるのは、以下の要素を持つ場合とされています。 製品やフレームワークに深く影響を与える要求 管理された品質属性に影響を与える要求 組織の能力やロードマップに影響を与える要求 政治的要素や経営層の支持を受けた要求 革新的なビジネスモデルやアプローチを示唆する要求 ここまでASRの識別に関して綴ってきましたが、 ASRは識別して終わりではなく、適切な管理が必要です。 その理由は、適切な管理を通じてのみ、ASRが設計の意図した通りに機能し、システムの性能、安全性、拡張性などの基本的な品質要件を維持し続けることが可能となるからです。 よってASRが戦略的な目標に対して最大の価値を提供するためには、 ASRが以下の基準を満たしているか確認する価値のトレーサビリティが必要となります。 完全性 要件が完全に記録され、情報の漏れがないこと 追跡可能性 要件が利害関係者のニーズを満たすとともに、適切に文書化されていること 現行性 要件が常に最新の状態に保たれ、時代遅れになっていないこと 検証可能性 要件を実施した結果が、検査、デモンストレーション、テスト、分析を通じて客観的に評価されること 有用性 要件が実装されることで、測定可能な価値を組織に提供し、その効果が定量的に示されること これらの基準を確認することで価値のトレーサビリティが可能となり、組織の競争力を維持するための基盤を強化します。 今回はオペレーティングモデルの "Requirements" について紹介させていただきました。 アーキテクチャ上重要な要求（ASR）は企業の戦略的目標達成に不可欠な要素です。 ASRを適切に識別・管理することで、企業の技術的な挑戦に寄与し、持続可能な競争力を維持することができます。ASRの識別と管理には、ビジネスと技術のリーダーシップを連携させることが不可欠であり、アーキテクトはその橋渡しとして重要な役割を果たすのです。 ご一読いただきありがとうございました。 Iasa日本支部では情報交換や勉強会の場を設けており、システムの視覚化についても研鑽を深めていますので、今後のIasa日本支部の活動へのご参加、ご協力をよろしくお願いいたします。

今回のコラムはBTABokのコンピテンシーモデルの「Views and Viewpoints」について取り上げます。「コンピテンシー」とは高いパフォーマンスを発揮する人物に共通して見られる「行動特性」を表す言葉で、BTABokのコンピテンシーモデルはその行動特性をモデル化したものになります。ITアーキテクトには幅広い知識とそれを実践する行動力が求められます。そのアーキテクトの「行動特性」を学ぶことでITアーキテクトに必要な知識や行動を理解することができるでしょう。ここではコンピテンシーモデルの中の「Views and Viewpoints」についてみていきます。 基本的にソフトウェアはその構造を物理的に視認することができません。このため構造をステークホルダーに説明するために可視化する必要があり、その可視化によってステークホルダーにソフトウェアがどのような構造をとっているかを理解してもらうためにもわかりやすい可視化のアプローチが求められます。「Views and Viewpoints」は、直訳すると「見解と視点」ですがviewsとviewpointsの原則は異なる場所で若干異なる方法で定義されます。IASA によって採用された定義は次のとおりです。 viewsは、アーキテクチャの 1 つ以上の側面を表現したもので、 1 つ以上の利害関係者が抱く懸念にアーキテクチャがどのように対処するかを示します。 viewpointsは、1 つのタイプのビューを構築するためのパターン、テンプレート、および規則のコレクションです。 それは、その見解を構築するための視点、ガイドライン、原則、およびテンプレート モデルに懸念を反映する利害関係者を定義します。 例えば、ITオペレーションズチーム向けにビューを作成する際には、オペレーションズビューポイントを使用します。このビューポイントは、システムの運用に関する情報が含まれるテンプレートです。オペレーションズビューポイントを使用することでシステムの運用に関係する人々に提供されるビューを作成することができます。 ITアーキテクトは、views、viewpointsの概念を明確に理解し、それらの違いとアーキテクチャを記述する際の連携方法を理解する必要があります。そしてIT開発プロジェクトで典型的なステークホルダーグループを識別し、各グループの典型的な関心事を理解し、特定のプロジェクトの要件を満たすために必要なviewのセットを決定する能力を持っていなければなりません。 「Views and Viewpoints」ではアーキテクトの主要な責任の1つは、関心を持つステークホルダーにシステムのビジョンを提示することと示されています。最も単純なシステム以外では、1枚の図で効果的にこれを示すことは不可能であり、したがってviewsとviewpointsの概念が開発されました。多くのアーキテクチャ記述法は、主要なアーキテクチャ情報を含む一連のviewsとして構成されています。多くのアーキテクチャフレームワークでは、システムの機能構造、主要なデータ構造、ソフトウェア開発方法、およびソフトウェアのデプロイ方法に関するviewpointsが含まれます。 viewpointベースのアーキテクチャフレームワークに多数のフレームワークが存在し、その中にはソフトウェア集中システム向けのものもあります。例えば、Kruchtenの4＋1アーキテクチャビューモデルやV&Bアプローチ、Software Systems Architectureセットなどがあります。 図. 4+1 architectural view model 出典：Wikipedia 以上の図はKruchtenの4+1アーキテクチャビューモデルですが、それぞれのモデルには以下のような関係性があります。 論理ビュー：論理ビューは、システムがエンドユーザーに提供する機能に関係します。論理ビューを表すために使用される UML 図には、 クラス図、 通信図、 シーケンス図などがあります。 開発ビュー：開発ビューはプログラマの観点からシステムを示し、ソフトウェア管理に関係します。このビューは実装ビューとも呼ばれます。 UML コンポーネント図を使用して システム コンポーネントを記述します。開発ビューを表すために使用される UML 図には、パッケージ図が含まれます。 プロセス ビュー：プロセス ビューはシステムの動的側面を扱い、システム プロセスとその通信方法を説明し、システムの実行時の動作に焦点を当てます。プロセス ビューは、同時実行性、分散、インテグレータ、パフォーマンス、スケーラビリティなどに対応します。プロセス ビューを表す UML 図には、 アクティビティ図が含まれます。 物理ビュー：物理ビューは、システム エンジニアの視点からシステムを表します。これは、物理層上のソフトウェア コンポーネントのトポロジと、これらのコンポーネント間の物理接続に関係します。このビューは、展開ビューとも呼ばれます。物理ビューを表すために使用される UML 図には、 配置図が含まれます。 シナリオ：アーキテクチャの説明は、小さな一連の ユースケース、つまり 5 番目のビューとなるシナリオを使用して説明されます。シナリオは、オブジェクト間およびプロセス間の一連の対話を記述します。これらは、アーキテクチャ要素を特定し、アーキテクチャ設計を図示して検証するために使用されます。これらは、アーキテクチャ プロトタイプのテストの開始点としても機能します。このビューは 、ユース ケース ビューとも呼ばれます。 そのほかにもアーキテクチャを具現化、視覚化する「Views and Viewpoints」の解説がIASA GlobalのWebサイトに載っておりますので、原文を参照してみてください。 ITアーキテクトに限らずですが、システムを開発する、運用する、保守する、プロジェクトを推進する等の様々な場面でシステムを可視化した資料は重要になります。システムの視覚化は1つの観点だけでは十分ではなく、さまざまな場面やステークホルダーによっても使い分ける必要があり、あくまでそれを見る人が中心でなければなりません。このため「Views and Viewpoints」では様々な手法や視点を取り上げつつ、それらを組み合わせ、使い分けすることが必要だとしています。 Iasa日本支部では情報交換や勉強会の場を設けており、システムの視覚化についても研鑽を深めていますので、今後のIasa日本支部の活動へのご参加、ご協力をよろしくお願いいたします！

本コラムでは、BTABoKオペレーティングモデルの概念である「ステークホルダー」を取り上げます。 ステークホルダーは、ビジネスやプロジェクトに影響を与える人や組織であり、 その成功に関心や利害関係を持っています。彼らの関与は、プロジェクトの進行や成果に大きな影響を与える可能性があります。そのため、ステークホルダーを適切に理解し、関係を管理することはビジネスやプロジェクトの成功に不可欠です。 BTABOKにおいてもステークホルダーの重要性は記載されており、ITアーキテクトとの関係性やコミュニケーションの取り方について定義されています。以下に関単にその内容を紹介します。 １．ステークホルダーとは？ ステークホルダーとは、特定の目標、ビジネスケース、または課題に対して関心や関与を持つ個人や組織のことを指します。ステークホルダーは、課題の成功に対して既得の利益を持っており、その成功はステークホルダーに対して肯定的、否定的いずれの影響を及ぼします。ステークホルダーは、その影響力を使って課題の解決を促進し、支援することができますし、結果として得られるアーキテクチャがステークホルダーにとって否定的である場合、課題の解決を妨げることもあります。一部のステークホルダーは、イニシアチブに貢献することによって積極的な役割を果たすことがありますが、他のステークホルダーはより受動的な役割を果たすこともあります。 典型的なステークホルダーの例としては、顧客、経営陣、または会社の部門などがあります。 ２．ステークホルダーの重要性 ステークホルダーは重要です。なぜなら、彼らは課題の進行に影響を与え、場合によっては成功と失敗の違いを生むことがあるからです。異なるステークホルダーは、影響力と情報ニーズの度合いが異なります。 「あなたは常に一部の人々を喜ばせることができます、あなたは時々すべての人々を喜ばせることができます、しかし、あなたは常にすべての人々を喜ばせることはできません」 - エイブラハム・リンカーンに支持された詩人ジョン・リドゲートの言葉、 ステークホルダーの管理は多くの労力を必要とし、課題に多くのステークホルダーが関与している場合、これは非常に困難になることがあります。影響力のあるキーステークホルダーが満足していることを確認することで、課題の成功の可能性が大幅に高まります。 キーステークホルダーが課題に対してポジティブな影響を与えると、資金調達、キーパーソンのアサイン、その他のイニシアチブに対する優先度の向上など、大きな利点をもたらすことができます。 一方で、ステークホルダー自身がキーとなり、課題や提案されたアーキテクチャによってネガティブな影響を受けることがあります。例えば、レガシーシステムを置き換えるとき、レガシーシステムのオーナーはデータの移行においてキーとなるかもしれませんが、最新システムへの移行によって、ステークホルダーは影響力や予算を減らすことになるかもしれません。このような場合、否定的な影響を緩和する方法を見つけることが重要です。例えば、アーキテクチャに妥協をすることで、組織の再編や役割の変更など、有利な状況を作り出すことができます。 ３．意見の重要性 ステークホルダーは、自分にとって有利な方向に課題を解決させたいと思うでしょう。その一つの方法は、自分の意見をアーキテクトと共有することです。ステークホルダーからの意見を取り入れることで、課題への関わりを作り出すことができ、これによりステークホルダーの課題成功への関心が高まることがあります。 ステークホルダーは意見が衝突することがあり、多くのステークホルダーがいると、すべての意見に同じ注意を払うことは困難です。どの意見を満足させ、どの意見には少ない注意を払うかを選択する必要があるかもしれません。ここで重要なのは、どのステークホルダーが課題に最も好意的であるかを知ることです（パワー・インタレスト・グリッドを参照してください）。 ４．ステークホルダーとの合意形成 ステークホルダーの関心や関与は、活動動機から生まれます。活動動機とは、ステークホルダーの関心を引き出し、意思決定に影響を与える力のことです。個々の人々にとっての活動動機は、名誉、権力、安定性、スキルの向上などがあります。組織にとっての活動動機は、組織の文化や組織が行うビジネスの種類によります。組織の活動動機の例としては、成長、予算/売上の増加、スキルへのアクセス、コンプライアンス、競争優位性などがあります。 ステークホルダーの動機が何かを知ることで、ステークホルダーと課題との関係が明らかになり、ステークホルダーがアーキテクチャからどのように価値を得ることができるかを示すことが容易になります。ステークホルダーの活動動機は、アーキテクチャのさまざまな側面に対するステークホルダーの関心を評価するための基礎を提供します。ステークホルダーが何に動かされているのかを理解することで、課題やアーキテクチャの推進、およびステークホルダーがどのように価値を得ることができるかを示すことが容易になります。 ５．ステークホルダー間の調整 ステークホルダーの管理はバランスが必要です。ステークホルダー間には複雑な関係があり、ステークホルダーからの影響力と関心を得るためには信頼が鍵となります。これは微妙なバランスを保つ行為であり、一つのステークホルダーへのコミットメントが他のステークホルダーとの関係にネガティブな影響を及ぼす可能性があります。交渉、外交、紛争管理は、アーキテクチャのバランスを保ち、ステークホルダーの信頼を維持するための有用なスキルです。 ステークホルダーを管理するための労力は無限ではなく、ステークホルダーの狭い範囲に焦点を当てることで、いくつかの重要なステークホルダーを満足させることができます。しかし、これは広範なステークホルダーが課題に対する関心を失ったり、アーキテクチャに対するネガティブな傾向を始めたりする問題を引き起こす可能性があります。したがって、ステークホルダーに対する労力の管理において適切なバランスを見つけることが重要です。 ６．重要ステークホルダーの特定 特定のケースでは、特定のステークホルダーが課題の成功にとって重要です。ステークホルダーが特別なスキルやリソースを持っていたり、課題が依存している他のプロジェクト/製品の責任者である場合があります。課題の活動とそのようなステークホルダーとの間のキーとなる依存関係を特定することは、アーキテクチャの成功にとって不可欠です。 ７．ステークホルダーの背景を知る アーキテクチャを伝える際には、ステークホルダーが理解できる形でアーキテクチャが提示されていることを確認することが重要です。ステークホルダーはしばしば異なる背景を持ち、アーキテクチャに対して異なる関心を持っています。例えば、一部のステークホルダーはアーキテクチャの技術的な視点に関心を持つかもしれませんが、他のステークホルダーはビジネスの視点に関心を持っています。適切なステークホルダーに対して適切なアーキテクチャの視点を選択することで、情報が関連性を持ち、アーキテクチャの理解が深まります。 ８．ステークホルダーを味方にする ステークホルダーは強い意見を持つことがありますが、それらの意見に挑戦し、適切な方向性を選択するのはアーキテクトの責任です。意見や提案はすべて、最良の結果を得るために、異なるシナリオや状況でテストする必要があります。これにより、アーキテクトは提案された変更に納得感を得ることができ、単にステークホルダーの指示に従うのではなくステークホルダーの賛同を得ることができます。 ＊＊＊ いかがでしたか？これらのポイントを考慮することで、ステークホルダー管理はより効果的になり、プロジェクトの成功につながる可能性が高まります。ただし、これらはあくまでガイドラインであり、具体的な関係者や状況によっては異なるアプローチが必要となる場合もあります。それぞれのプロジェクトや組織に最適なステークホルダー管理の方法を見つけることが重要です。 Iasa日本支部は、日本国内においても実践力を備えたアーキテクトが広く認知され、活躍できるような業界にしたいと考えています。今回解説したステークホルダ管理は、プロジェクトを成功に導くために重要なスキルです。このようなスキルを有した成熟したアーキテクトが一人でも多くなるよう、これからの価値ある情報を発信していきたいと思います。今後のIasa日本支部の活動へのご参加、ご協力をよろしくお願いいたします。

本コラムでは、BTABoKオペレーティングモデルの概念である「ロードマップ」を取り上げます。 現代において企業ITシステムのロードマップの重要性は、ますます高まっています。その理由は、ビジネスとテクノロジーの迅速な変化に対応するためです。デジタル変革を進めるには、短期的な対応ではなく、将来に向けた全体的な戦略と計画が必要です。ロードマップは、企業が新しい技術を取り入れ、顧客に価値を提供する製品やサービスを開発する際の指針となります。これにより、計画的にリソースを配分し、優先順位を設定することで、変化に柔軟かつ効率的に対応し、競争優位性を維持することが可能となります。 BTABoKにおいても、長期的なビジネス目標や製品開発の計画を視覚的に示すロードマップの重要性を強調しています。ロードマップは、目標達成の計画を時間軸に沿って描いたものであり、企業価値を提供する大規模な活動の計画に用いられます。特に革新と変革の段階で利用され、新しいイニシアチブの計画、実行の追跡、重要な依存関係の特定に役立ちます。また、ロードマップは、リソースや予算に関する大まかな見積もりを立てる枠組みとしても機能し、ビジネスイニシアチブの実行可能性を評価する前段階として利用されます。詳細は、オペレーティングモデル - ロードマップをご覧ください。以下で、簡単にその内容を紹介したいと思います。 ＊＊＊ 1. ロードマップが必要な理由 企業は戦略的なイニシアチブの多くを長期計画し、ステークホルダー間で共通の理解を促進する必要があります。ロードマップは、それらの依存関係の可視化によりリスクを減らし、優先順位付けを支援し、予算やリソースの概算に役立ちます。進捗の可視化はステークホルダーのモチベーションを高めます。また、アーキテクトにとっては、時間を考慮したアーキテクチャの方向性を示し、代替アーキテクチャの選択肢を評価するツールとなります。 ２．ロードマップアプローチ 良いロードマップ作成のための重要な原則には、ロードマップの範囲を明確にし、ビジネス中心の計画を立てることが含まれます。ロードマップは長期的な視点を提供し、大規模な変化を計画するものであり、プロジェクト計画とは異なります。項目はビジネスの目標や目的に明確に貢献する必要があり、実現可能性の評価はプロジェクト計画で行います。また、ロードマップは範囲外の項目を避け、すべてのステークホルダー間で誤解のリスクを減少させるために、スコープを明確にする必要があります。 ３．戦略的ロードマップと製品開発ロードマップ ロードマップには戦略的ロードマップと製品開発ロードマップがあります。戦略的ロードマップは企業全体や製品ポートフォリオの長期計画を示し、広範囲に渡ります。これは組織の上位ビジネスパーソン向けであり、製品開発に関する成果物を含みます。一方、製品開発ロードマップは具体的な製品に関連する計画です。両者は密接に関連しており、戦略的変更が製品計画に影響を与え、その逆も同様です。この関係性を理解し、効果的に管理することで、リスクや依存関係を早期に特定し、負の影響を軽減できます。 ４．戦略的ロードマップ 戦略的ロードマップは、組織の戦略的目的や目標を達成するために、企業、ビジネス、インフラストラクチャの変化を含む一連の成果物を計画します。これらは、トランジションを通じて組織の初期状態から目標状態への移行を促し、組織内で変化のリンクを作成します。ロードマップ作成のプロセスは、ビジョンとスコープの合意から始まり、ワークショップを通じて目標、目的、期限を明確にし、移行を定義します。このアプローチにより、成果物の優先順位付け、依存関係の管理、ステークホルダー間のコミュニケーションが強化されます。 ５．製品開発ロードマップ 製品開発ロードマップは、特定製品の長期計画を示し、リリース、機能、イベントに焦点を当てます。リリースは製品のバージョンで、明確なスコープと目標が設定されます。このロードマップは、製品管理と開発チームに方向性を提供し、企業戦略との整合性を図ります。また、リリース計画では、開発サイクルの主要イベントやQAを含め、製品の要件を満たす機能（エピックとも呼ばれる）の開発を計画します。 ＊＊＊ 以上、ロードマップの記事の内容を概観しました。実際の記事では、多くの構造化キャンバスも紹介されていますので、みなさんにとって価値ある情報源になると思います。 さて、みなさんにお尋ねします。このようなロードマップが組織的に運用されている企業は、現実にどれだけあるでしょうか？多くの企業にとって、ロードマップを組織的に定義し運用する際の障壁が存在します。まず、明確なビジョンや目標の欠如が挙げられます。ビジョンや戦略的目標が不明確であると、ロードマップの方向性を決定することが難しくなります。次に、組織内のコミュニケーション不足や部門間の調整の欠如も障害となります。異なる部門やチーム間での目標の認識のズレや協力の不足は、組織全体での取り組みの一貫性を損なうことになります。また、適切な技術やツール、スキルの不足も、効果的なロードマップの作成と実行の妨げとなることがあります。これらの障壁を克服するには、組織全体での明確なコミュニケーション、共有ビジョンの確立、適切なリソースとスキルの確保が必要です。そしてアーキテクトこそ、そうした役割を担う最適なポジションにあるといえるでしょう。 Iasa日本支部は、このようなスキルを備えたアーキテクトが一人でも多く活躍できるような業界にしたいと考えています。今回解説したロードマップのスキルは、変化の時代に生きるアーキテクトに不可欠なものです。今後のIasa日本支部の活動へのご参加、ご協力をよろしくお願いいたします！

BTABoKといえば「エンゲージメント・モデル」ですが、その前身であるITABoKといえは「5つの柱と4つの専門領域」でした。もちろん現在もこれらは全て「コンピテンシー・モデル」としてBTABoKに受け継がれ、さらに加筆修正、新たな項目の追加が随時行われています。今回はBTABoKの「インフォメーション・アーキテクチャ」コンピテンシー・モデル、つまりITABoKでいうところの「インフォメーション・アーキテクチャの専門領域」に新たに加わった"Informat ion Usage" (「情報の使用」)を、仮訳のかたちでご紹介します。 情報の使用 解説 情報・ナレッジの管理は、自覚の有無に関わらず私たちが日常的に行っているあらゆるビジネス、職業、仕事の中核をなすものです。探している情報を見つけるのが簡単であればあるほど、顧客へのサポートやビジネスの強化、そして目の前の仕事をこなすことに、より多くの時間を費やすことができます。 インフォメーション・アーキテクト(IA)として、あるいはどの役割であれ、成功のためには誰が顧客なのか、現在、そして今後どのようなニーズがあるのかを知り、理解する必要があります。 これは文字通りすべてのアーキテクチャ分野をつなぐ架け橋たるIAにとって特に重要です。加えて私たちが顧客と向き合っているという事実の重みは、直接的あるいは間接的に顧客に影響を与えかねず、私たちの両肩に重くのしかかっています。しかし私たちはひとりではないことが救いです。私たちはさまざまな部署や顧客との架け橋となっているので、この重荷を背負う助けを得ています。私たちはすべての答えを持っている必要はありません。私たちに必要なのは、情報を分類・保管することで、パートナーが過去、現在、そして未来に生じる疑問や答えを見つける手助けをする司書としての知識と専門性です。最も成功したIAとは、デジタル・ランドスケープ全体のためのデューイ十進分類法のカスタマイズに留まらず、利用者がその分類法を活用し、必要な時に必要な場所で必要なものを、利用者が努力することなく見つけられるようにする能力を持つ現代のライブラリアンです。 「情報の使用」コンピテンシーの概要 「どのように」情報は用いられるか 今日の「do more with less data」という世の圧力と、人間が消費しやすい形へのデータ集約とは最も深刻なジレンマです。もし情報が目の前の問題や疑問の解決に役立たなければ、ステークホルダはその情報には価値がないと思い情報から離れていくでしょう。私たちはADD処理が多すぎる情報過多社会になりつつあり、長々とした説明ではなく即答を求めるあまり忍耐力も低下しつつあります。コンピュータとともに... あなたの役割や専門分野によっては、あなたが育む情報が人間だけでなく機械にも消費されることは驚くに当たらないでしょう。私たちがソリューション・アーキテクチャを考えるとき、もはや人間だけ、あるいは機械だけを顧客とすることはできません。私たちが暮らす電子の世界では、このふたつの境界線はあいまいです。将来的な情報活用の道を阻むことにならないよう、私たちのすることのすべては、その両方を考慮に入れなければなりません。そのためにはどうすれば良いのでしょうか？アーキテクトとしてご存知のように、答えは「何」ではない、「どのような」制約の中「どのような」方法で問題を解決してほしいかということです。アーキテクトとして、問題を「ひとくち大」に分解するのが一番だと私は考えます。それぞれの側面から問題を見て、最終的に両者が満足するようなインターフェースや抽象化レイヤーの存在を確認することです。 「いつ」情報は用いられるか 情報は私たちが思っている以上にさまざまな形で利用されていることがわかりました。今回のレッスンや今後のプロジェクトを通して、情報が「どのように」使われているのかを見逃さないようにしましょう。次に、情報が「いつ」使われるのかを詳しく見てみましょう。情報は私たちの日常生活で常に使われています。そのような内的プロセスは潜在意識が代行するので、私たちはほとんどそのときを意識することはありません。情報は、私たちのさまざまな感覚を通して、継続的なインプットとして、意思決定を行い、事実、仮定、プロセスをサポート・検証し、研究開発で興味深い分析を支援することに使われます。情報が「いつ」使用されるかは、朝の服装を決める、いい匂いのするドーナツを口に入れる、といった基本的なことから外れるとき、私たちのビジネス、そのために私たちが設計するソリューションにも同じことが当てはまるとわかります。 情報をいつ使うかは、アーキテクトとして常に間違いなく答えられる数少ない問いのひとつです。IAとしての私たちの役割は、情報を取得し、保存し、カタログ化し、さまざまな情報源が必要なときに利用できるようにすることです。同様に、情報の消費者がより賢明な決断を下し、彼らのイニシアチブを支援し、また重複作業を減らすことで研究開発を促進し、そして未知なるものへの認識を取り除く、そのような役に立つ情報が入手可能であることを、彼らに教え啓発することが、私たちの正しい仕事のやり方です。 「どこで」情報は用いられるか ここまでが前半です。私たちは情報が「どのように」使われるかをもっと注意深く見るべきです。情報は常に私たちの周りで使われているのでなお更です。それゆえ私たちは、情報を理性的に捉え共有することをより意識する必要があります。ここで、私たちが様々な形で備蓄し、さらに様々な方法で利用可能にしたこれらの情報を、私たちは「どこで」使うつもりなのか、という疑問が生じるはずです。合ってますか？インフォメーション・アーキテクトとして私たちは、すべてのアーキテクチャ・ドメインおよび、それに加えてビジネスのあらゆる側面の橋渡しをコントロールし、構築する責任を負っています。これらの橋は、部署や事業部門、時には国土や別の会社にまでまたがるものです。情報が「どこで」使われるかは、開発者のクリエイティビティによってのみ制約を受けます。情報とは、画家が真っ白なキャンバスに塗る絵の具のようなものだと考えましょう。その情報を使ってデータベースをデザインするアーティストもいるでしょう。 私たちが提供する情報は、DBは構造化・正規化され、水平にも垂直にもスケーラブルで、データをサブコンポーネントに分割でき、DBの消費者が必要なものを迅速かつ合理的に入手できるようにします。 また、私たちの情報がドキュメントの作成に使用される場合もあります。これらのドキュメントは私たちが提供する他のすべてと同様に、無限の形で存在します。あるドキュメントは財務分析用のスプレッドシートかも知れません。そのようなときに私たちが提供する情報は、私たちの資産、特許、著作権、商標を保護する法的な様式や、パートナーや潜在顧客との拘束力のある契約の裏付け資料などかも知れません。その一方で、人事部門が単に従業員の記録を作成するために使われるだけの情報もあるでしょう。 IAとしての役割によっては、情報はウェブベースのサイトやアプリケーションを設計する際のコア・ソースと考えるのが一般的でしょう。人間とのインタラクションのためのサイトやアプリのナビゲーションを、シンプルで楽しく、よく考え構築することや、インターフェイスをガタつきがなく、美的に魅力的に作ることなどです。 「なぜ」情報は用いられるか この時点で、情報がいつ、どこで、どのように使われるかについて、より包括的な認識が持てたことでしょう。でもなぜでしょう？ 私たちが使うものとして情報が重要なのはなぜなのでしょうか？私たちが情報を利用する一般的な理由としては、市場検証、ユーザビリティの実装、知識・コンテンツ・ドキュメントの共有・管理、そして最近取り上げたビジネス・プロセス管理などがあります。 市場検証は、ビジネス・アーキテクチャ・グループとエンタープライズ・アーキテクチャ・グループとの架け橋となる多くの理由のひとつです。あなたが彼らに提供する情報によって、彼らは様々なことを行う、または行わないビジネスケースを提示できます。企業の買収、製品・ソリューションの構築と購入の比較、企業のミッションの調整、新たな収益源への着手、既存の機能や製品ラインの更新や廃止などです。これらはあなたが他に提供した情報が、市場ベースの戦略や意思決定などの検証に使用される可能性がある多くの意思決定のほんの一部に過ぎません。 ユーザビリティはふたつのパスに分かれますが、どちらももう一方に大きく依存しています。どちらか一方を行うか、あるいは両方を行うかは、当然ながらチームや会社の規模や複雑さによって異なります。一方はデザインと実装のUX専門家です。もう一方は、ユーザビリティ・スタディの専門家たちで、ユーザビリティ調査の方法、内容、場所、時期、理由の策定だけでなく、実施された実験の結果を集計し、偏りのない意味が得られるようにします。最終的にこのふたつのグループが一緒になって、内部・外部に関わらず、私たちが提供する製品の使用を通じた、ユーザーの楽しくサクセスフルな経験に関係する情報アーキテクチャの基礎を作り上げます。このふたつのトピックは、それら自体が立派なトレーニングコースになります。 IAとして、当然ではあるものの、時に最も困難な責任のひとつ、そして最大の「なぜ」情報は用いられるかの理由のひとつがナレッジ・コンテンツ・ドキュメント管理です。目的はシンプルで、情報検索のコストを削減しリターンを最大化する一方で、情報作成の労力の重複を削減することです。シンプルですね。でも違います。スープにどんなスパイスを加えたらいい味になるか、それぞれの考えで調理しているコックがキッチンに多すぎることがよくあります。厳格なガバナンスと経営陣の賛同が、IAとしてのこの業務領域での唯一の希望です。営業担当者は自分の連絡先をサイロ化したがり、人事部は機密情報の漏洩を恐れて共有せず、ソフトウェア・エンジニアは「どのように」や「なぜ」を文書化しません。そしてもちろん「誰も私のやり方を知らなければ、私の仕事は安泰だ！」という標準的かつ典型的なメンタリティがあります。残念ながらこれは真実とはほど遠く、ナレッジの文書化や共有がなされていないため、その社員はその特定の仕事をこなせる唯一の人間となり、むしろ昇進やキャリアアップの妨げになります。これは非常に重要なトピックで、IAとしてそのチャンスや機会が与えられたら、この問題にどのように取り組めばより効果的なのか、そのヒントを提供するユースケース・シナリオをのちほど用意します。 ビジネス・プロセス・マネジメントは、ここで取り上げる「なぜ」情報が用いられるかの最後の例です。明らかに、そして願わくば、これまでのカリキュラムを通して、情報が使われる、あるいは使われる可能性がある他の理由をすでに皆さんが考えているように、私たちは十分な種をまいてきました。ビジネス・プロセスの作成、見直し、強化、最適化に情報を活用することで、直感や感覚ではなく、ファクトベースの意思決定を確実に実行できます。脊椎反射ではなく情報を活用し、時折発生する不具合ではなく、現実に基づいた最善のビジネ・プロセスを実現できます。理想的には、フィードバック・ループで不調なプロセスに情報を提供すれば、不具合は説明され、たとえ滅多に起きなくても、あなたや顧客に悪影響を及ぼすようなことはなくなります。 「情報の使用」コンピテンシー・モデル、いかがだったでしょうか。BTABoKをもっと知りたい方のために、IASA日本支部はBTABoK解説セミナーを開催しています。最新の開催予定、参加お申し込みはイベントページをご覧ください。ご参加お待ちしています！

明けましておめでとうございます。本年もIasa日本支部をよろしくお願いいたします。 さて今回はBTABoKのオペレーティングモデル内にある "Decisions" を紹介します。 中身に入る前にみなさまはアーキテクチャ設計を行う際に、何を基準に意思決定されていますでしょうか？また、意思決定された記録や根拠はどのように保管されていますでしょうか？ 個人的な印象ではありますが、今回の "Decisions" はそのような問いかけに対する答えを導く上での示唆を与えてくれるものと感じていますので、そのような視点でご一読いただけると幸いです。 "Decisions" の要約 Decisionsでは、アーキテクチャ上の重要な決定 (Architecturally Significant Decisions, 以下ASD) が組織全体に与える影響の範囲と重要性に焦点を当てています。また、決定の管理とその範囲、さまざまなレベルでの決定の種類、効果的な決定管理プロセス、さまざまな決定方法、認知バイアスの影響、決定の特性と方法、そしてプロジェクトライフサイクルにおける決定のタイミングとカスケード効果 (一つの決定が連鎖的に他の決定や出来事を引き起こす現象) について説明しています。これらの要素は、組織においてアーキテクチャの決定がどのように形成され、実行されるかを理解するのに役立ちます。 記載内容を要約したものが以下の表です。 表1：ASDについて アーキテクチャ決定の記録：Architecture Decision Record (ADR) について "Decisions" の中でも個人的に一人のアーキテクトとして重要視しているものの1つにADRがありますのでご紹介します。ADRは、ソフトウェア、データ、インフラストラクチャなどの重要なアーキテクチャ上の決定を文書化したもので、その目的は決定の理由、選択肢、考慮された要因を記録し、将来のプロジェクトメンバーなどの関係者が背景を理解できるようにすることです。 表2：ADRについて 私はITコンサルタントとしてさまざまなIT刷新プロジェクトでITシステムの構成図や仕様書を目にすることがありますが、それらのアーキテクチャの目的や今に至った経緯や背景を知るには、そのシステムの有識者に聞くことが多く、アーキテクチャの変更の影響度を把握する場合に時間を要することがあります。ADRがあればその辺りの時間の短縮も期待できますし、表2に記載のメリットも享受できます。ADRの記載例を表3に示します。 表3：ADRの記載例 (マイクロサービスアーキテクチャの採用) まとめ 今回はオペレーティングモデルの "Decisions" を紹介させていただきました。多くのアーキテクトのみなさんは、ITプロジェクトやビジネス部門からの相談を受ける中で日々奮闘しながら数多くの意思決定をされていると思います。場合によっては時間的・人的リソースなどの制約により必ずしもベストな意思決定ができないときもあろうかと思いますが、アーキテクチャの意思決定はプロジェクトのQCDなどに影響を与えるので制約がある中でもベストな意思決定をしたいものです。アーキテクチャの意思決定のスピードと質を向上させるための道具としてBTABoKの "Decisions" が多くのアーキテクトの一助となることを望みます。 ご一読いただきありがとうございました。 参考 Architectural Decision Records

今回はBTABoKのオペレーティングモデルの層にある品質保証 (Quality Assuarance) について、見ていきたいと思います。 以下にBTABoKの品質保証の章立てと内容のサマリを示します。 品質保証は言葉はシンプルですが、業種業界ごとの法的要求事項や求められる専門知識も多岐に渡ります。そのため、アーキテクトは1人または複数の品質保証の専門家や第三者のアーキテクトと協調しながら検証と妥当性の確認 (Verification & Validation, 以下 V&V) 実施することが求められます。 ITプロジェクトの場合、ソフトウェアの単体テストや結合テスト、総合テストなどを経て運用開始されますが、品質保証はテスト段階で確認するのではなく、設計段階から作り込むことが必要です。その考え方としてV&Vは有効ですし、その中で用いられるツール (例：トレーサビリティマトリクス) などを活用することで要求者と提供者のコミュニケーションも円滑に進み、要求変更の影響度も把握しやすくなります。 私自身、以前はIT構想企画から要件定義、設計、実装、テスト、運用開始後のフォローまでを担当することが多く、品質保証を意識する機会は多くありましたが、ここ最近はIT構想企画に軸足を置いて仕事をしていることもあり、品質保証の重要性に対する意識が薄まっているように感じます。 今回のコラムを書くにあたって品質保証について改めて見つめなおすことができました。品質保証に関する専門書を読むのは大変ですが、BTABoKは網羅的かつ簡潔にまとめられているのでアーキテクトとして理解を深める第一歩としてはちょうどよいと思います。 ご一読いただきありがとうございました！

今回はBTABoKのオペレーションモデルのひとつであるアーキテクチャライフサイクル（Architecture Lifecycle）についてのコラムです。 BTABoKでは冒頭で以下のようにArchitecture Lifecycleを紹介しています。 アーキテクチャのライフサイクル、つまりアーキテクチャ開発ライフサイクル (ADLC) は、アーキテクチャがその開始から廃止までを通過する段階です。 ADLC は、アーキテクチャ開発のためのガイド プロセスを提供し、アーキテクトがアーキテクチャの状態を理解し、伝達するのに役立ちます。 上図はADLCの段階を示しています。ADLCは、アーキテクチャが周囲の環境に合わせて発展・進化するための反復サイクルです。 ADLCのステージを以下に示します： 【イノベーションサイクル】 - ビジネスを変化させ、価値を得るための価値主導のアイデアの継続的なサイクル。これが継続的にアーキテクチャの進化を促します。 【戦略】 - 長期的なアーキテクチャの方向性を描き、ビジネスケースと課題の評価と優先順位付けを行う。その結果、アーキテクチャを開発するための要件が示されます。 【計画】 - 課題とアーキテクチャに関する要件が与えられ、アーキテクチャの基本的な設計図が作成されます。また、アーキテクチャ実務やチームは、アーキテクチャ変革を実現するために何が必要かという観点から評価されます。 【変革】 - 製品やソリューションなどの成果物を作成する際にアーキテクチャを使用し、スポンサーに期待価値を提供すること。これには、製品又はソリューションの開発中にアーキテクチャを改良することも含まれます。 【活用と測定】 - 成果物の配備後の実践におけるアーキテクチャの使用。これには、アーキテクチャがスポンサーに期待される価値を提供したかどうかを評価するための測定が含まれます。 【廃止】 - アーキテクチャの利用が一巡し、スポンサーに価値を提供しなくなった場合、アーキテクチャは廃止されるか、別のアーキテクチャに置き換えられます。 ADLCは、アーキテクチャの継続的な改善を目指すサイクルであり、アーキテクチャの測定がさらなる革新のためのフィードバックを提供します。 さて、ここで登場する「スポンサー」とはだれを指すのでしょうか？ 組織によりケースバイケースで、特定の人物ではないのでしょうが、その中のひとりはCIOと呼ばれる経営ボードでしょう。 CIOは情報システムのあるべき姿を維持、成長させることが使命のひとつとされています。そのためのアーキテクチャの継続的な改善を支えるADLCは、CIOにとっての有効で重要な手段となるでしょう。 また、スポンサーは、システムを設計し、構築するエンジニアたちでもあります。アーキテクチャの価値を一番身近に感じるのは彼らであり、ADLCはそのスポンサーであるエンジニアたちにも貢献することが求められます。 いづれにしても、ADLCを適用する際には、スポンサーの定義から行うことが重要となります。 さて、ADLCのステージの説明において、味わうべきは、アーキテクチャの【廃止】（廃止もしくは置き換え）のフェーズであります。 「当社にはアーキテクチャが無い」となげくCIOなど経営ボードがいますが、実際にはアーキテクチャが無いのではなく、良否はともかく描かれていないというのが実態と言えるでしょう。 現行AsIsのアーキテクチャを描いてみて、改善のサイクルを回すべきか、新たなイノベーションを起こし、現行のアーキテクチャは廃止し、新たなアーキテクチャに置き換えるべきかの決断から始めることが、求められます。そのうえで、ADLCを回していくことで、あるべきアーキテクチャに近づくことが出来るとBTABoKは主張しています。 BTABoKは、ADLCの必要性を以下のように述べています。 ライフサイクルが必要な理由 ADLCは、アーキテクトが高品質のアーキテクチャを開発するためのツール、成果物、プロセスを含む手法を提供します。ライフサイクルに標準的な段階を設けることで、アーキテクチャの開発におけるアーキテクト間の共通プロセスを提供します。アーキテクトがアーキテクチャの状況を伝え、ライフサイクルの各段階でアーキテクトに何が求められているかを知るのに役立ちます。 ライフサイクルは、アーキテクトがライフサイクルの適切な段階において、順序立ててアーキテクチャ活動を行うことを支援し、アーキテクチャ開発におけるプロセスの伝達方法を提供します。 ADLCそのものを開発することで、アーキテクチャ業務にアーキテクチャ開発の標準的な作業方法を取り入れることができます。これは、アーキテクチャ実務の反復的かつ継続的な改善を促進し、ガバナンスの基盤にもなり得ます。 ADLCを適用することで、自社のアーキテクチャをあるべき姿にし、そして情報システムを優位性のあるものとし、経営基盤を支えていくことになるでしょう。 自社のアーキテクチャの存在があいまいな状態の組織においては、道は遠いとも感じるかも知れません。しかし、まずは、あるがままに現行システムのアーキテクチャを描き、客観的に評価し、ADLCによりアーキテクチャを管理していくことで、情報システムの見える化が実現されます。重ねて申し上げますが、これが、経営戦略に基づいた情報システムとなり、いわゆるDXの実践に向かうことを可能にするのではないでしょうか？ ADLCは、活用してこそ価値があるものです。是非、原文を参考に適用を検討してみてください。 BTABoK／Architecture Lifecycleの原文は以下のサイトを参照ください。 Architecture Lifecycle - BTABoK (iasaglobal.org) IASA日本支部では、BTABoKの解説セミナーなどを定期的に行っています。 詳細については、https://www.iasa-japan.org/eventを参照ください。 奮ってご参加されることを願っております。よろしくお願いいたします。 以上

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

● 飯島先生　「エンタープライズオントロジーの勧め」 ＜講演概要＞ ・狭義のデジタルトランスフォーメーション（DT）はデザインの変革を言う ・DTには企業活動の本質を捉えるエンタープライズオントロジー（EO）が有効 ・EOの代表的理論（PSI理論、OMEGA理論、ALHA理論）の紹介 ・EOの実務的有効性についてモデリング方法論DEMOを用いた事例の説明 ＜感想＞ ・細部のITではなくビジネスシステムに向き合った芯を捉えた内容であった ・かねてからビジネスモデルの俯瞰図を模索してきたが間違いではなかった ・EOのモデル表記について2006年頃から世の中にあった事が興味深い ・“Ｘ線写真で皮膚を透過して骨格が見えるが如く”の比喩がたいへん絶妙 ・反面、抽象化度合いの高さに日本の企業人が追い付いていけるかが課題か ● 濱田さん　「システムアーキテクトの重要性とその育成について」 ＜講演概要＞ ・システムアーキテクト（SA）とは、経営、事業、技術の八咫烏的スーパーマン（IPA） ・SAに求められるスキルは、洞察力、コンセプチュアル、ヒューマンスキルが重要 ・SAに求められる考え方は、仮説推論、抽象化思考、アナロジーがポイントとなる ・SAが果たす役割は、業務要求からシステム要件に転換しビジネスアジリティに応える ・システムアーキテクトを育成する為には、コーチングとJOBローテーションが必要 ＜感想＞ ・社内のアーキテクト養成講座を担当されており、実践的な現場感が満載 ・一貫して「自分の頭で考える習慣をつけること」の重要性を訴えた点が印象深い ・現場30年の経験により培われたアーキテクト論は地に足のついたものであった ・所々に盛り込まれた隠し味的フレーズ「分業が分断を生む」がとても頭に残った ● 松井さん　「新時代のアーキテクトが拓くデジタルアドバンテージへの道」 ＜講演概要＞ ・アーキテクトの役割は曖昧さへの対処、創造性の発揮、複雑性のコントロールにあり ・近年、新たなアーキテクトの価値としてビジネス貢献、DXへの貢献が叫ばれる ・BTABOKのエンゲージメントモデル（個ではなく組織の力）の説明 ・BTABOKデジタルアドバンテージへの道（個からエコシステム）の説明 ＜感想＞ ・BTABOKがコンピテンシーからエンゲージネントへとスコープが拡大された点は納得 ・BTABOKの3層エンゲージメント「アーキチーム⇔組織⇔顧客」は分かり易かった ・アーキテクチャコンピテンシーを発揮する“チーム構成”に言及するに至った点を評価 ・アーキテクチャのビジネス効果測定の為の各種バリューモデルが興味深い ・顧客への価値提供などBTABOKモデル抽象度がかなり高いので今後具体例が望まれる ● パネルディスカッション　「デジタル変革の真実 ～ アーキテクトが果たす役割とは？」 ＜モデレータ＞小北 洋史 Iasa日本支部 理事 ＜パネリスト＞飯島 淳一 氏、濱田 潔 氏、中山 嘉之 Iasa日本支部 理事、末永 貴一、Iasa日本支部 理事 ■デジタル変革が企業にどう影響しているか、その真実 ・デジタイゼーション、デジタライゼーションはコロナ禍でAR、VRを用いて進んだ ・狭義のDXは、一部の企業では進んだ企業もあるが、進んでいかない企業も多い ・大企業は既得権益者が足かせになって進んでいないという面がある ■アーキテクトが果たすべき役割と、求められるスキルセット ・ビジネスドメイン知識とIT知識の両方を知ってソリューションを導くことが役割 ・日本の大学教育では情報系と業務系の分断が欧米より大きいという感じがする ■成功するために必要な人材の育成及び獲得方法 ・ITと業務がお互い分からないことは構わないが、知ろうとする意欲が必要 ・抽象化スキルをもってすれば知らない業務をモデル化することで知る事ができる ・スタートアップ企業の末永さんはデジタルが当たり前なのであえてDXと言わない 質問）CEOがビジネスアーキテクトであることが、日本と欧米との大きな違い？ ⇒建築系のCEOの場合は構造的に物事を捉えるのでDXが上手くいく事がある 質問）アーキテクト育成し継続する為には？ベンダーとユーザの関係はいかに？ ⇒アーキテクトを育成する人事制度、ベンダー⇔ユーザ企業が混じる流動化が必要 ★ 総合的な感想 ・それぞれ立場が異なる発表者からの講演は、どれもが今回のテーマ「Beyond Digital Transformation」に相応しい、視聴者にとって有意義な興味深いものであった。 ・2023年現在、DX推進が進んでいる企業とそうでない企業が二極化してきた感はあるも のの、一方でユーザ企業の人材流動化の兆候も出始めており、企業システムにおけるアー キテクチャの重要性、有能なアーキテクトの必要性についての認知度が高まる気配も感じられる。今後の産学でのアーキテクチャの取り組みに期待したい。 ・IASA-JAPANは引き続き日本企業のアーキテクチャ活動を支援していきたい。 以上。

2023年11月9日に「Beyond Digital Transformation」と題してアニュアル・カンファレンス 2023を開催致します。今回は対面参加とオンライン参加（Zoom）でのハイブリッド形式で開催致します。 本カンファレンスの講演タイトルは、以下のラインナップとなります。 Beyond DT～エンタープライズ・オントロジーの勧め～ システムアーキテクトの重要性とその育成について 新時代のアーキテクトが拓くデジタルアドバンテージへの道 企業の更なるデジタル変革に向けて様々なデジタル人材の重要性が高まる中、ITアーキテクトという言葉を耳にする機会が増えたと思います。ではITアーキテクトに対してどんなイメージや理解をお持ちでしょうか。実はITアーキテクトに対するイメージは組織や人によって異なり、役割やスキルに対する理解も様々であるのが現状です。アニュアル・カンファレンス 2023では豊富な知見と実績をお持ちの方々にITアーキテクトに関してご講演いただきますが、本コラムでは先立って「ITアーキテクトとは何か」について考えてみようと思います。 アーキテクトを直訳すれば「建築家」を意味します。ではITアーキテクトは「ITの建築家」となります。いまいちピンとこないですね。では直訳から離れて意味を定義してみましょう。 筆者が納得できるITアーキテクトの定義は「ゼロベースで抽象化した全体構想を考えて具体的な戦略に落とし込める人」（註1）それを端的な単語で表すのであれば「全体構想家」（註2）或いは「戦略家」といったところでしょうか。IasaではITアーキテクトを「ビジネスのためのテクノロジーの戦略家」と位置づけています。 ITアーキテクトの定義は上記だとして話を進めると、 なぜ、今の時代ITアーキテクトが必要なのでしょうか。それはビジネス環境の変化が加速する現代で企業が成長を遂げるためには、テクノロジーの進化とビジネスの変化に適応する必要があるからです。変化の激しい時代では、既にある問題を1つずつ解決するのではなく、ゼロベースで新たな全体像を構想して本質を捉えた戦略を実行しないと変化に適応できません。（註2） イメージとしてボーリングのピンを浮かべてみてください。右端の10番ピンを狙っても1本しか倒せませんが、1番ピンを狙えば1度に10本倒せます。（註3）それは1～10番ピンの全体像が見えているからこそ、1番ピンを狙う行動に移せるのです。ITアーキテクトは全体像を視覚的に整理し、第三者でも理解しやすい形で示すことで、効率的にステークホルダーとコミュニケーションを取りながら最適な戦略を立案する役割を担います。 ではITアーキテクトは何ができる必要があるのでしょうか。それはアニュアル・カンファレンス 2023にて講演が行われますのでぜひご参加ください。ひとつ挙げるとしたらITアーキテクトは「具体と抽象を行き来できる」必要があります。実現不可能な全体構想や戦略を考えてしまい絵に描いた餅となっては意味がないからです。つまり、実現可能かどうかを見極めて具体と抽象を行き来しながら全体構想と戦略を考える力が必要となります。よって、ITアーキテクトに必要なスキルは多岐にわたります。 Iasaが提唱しているスキルを挙げると以下(5つの柱)となります。（註4） ビジネス・テクノロジー戦略スキル(ビジネスとテクノロジーのギャップを埋めるスキル) ヒューマンダイナミクススキル（ステークホルダーのマネジメント、交渉、プレゼンスキル） IT環境分析スキル（ITオペレーションとガバナンスを実現するために必要なスキル） デザインスキル（データモデリング、全体システムの構想スキル） 品質属性の分析スキル（品質属性の調整と最適化を行うスキル） こんなスーパープレイヤーはいないと思われるかもしれませんが、あくまで全体や幹を捉えるために必要な分だけ押さえればよいのです。各スキル全てのスペシャリストにならなければいけないというものではありません。ITアーキテクトの道は限られた人しか歩めないものではなく、どんな方でも新たな視点を楽しむことで歩んでいける道なのです。 その第一歩として、先にも触れましたが2023年11月9日のアニュアル・カンファレンス 2023にご参加していただけますと幸いです。今回は「Beyond Digital Transformation」〜デジタルアドバンテージへのITアーキテクトの新たな役割〜を主題に豊富な知見と実績をお持ちの方々にご講演していただきます。DXに関心がある経営者層から専門職の方まで広くご参加いただけますので、新たな発見と学びの機会にお役立ていただければと存じます。ぜひ、皆様のご参加をお待ちしております。 註） 構想力が劇的に高まる アーキテクト思考、「はじめに」P4 構想力が劇的に高まる アーキテクト思考、「はじめに」P1 構想力が劇的に高まる アーキテクト思考、「第3章.1 アーキテクトのミッション」P91 ITABoK Version2 日本語訳版、「2.1 アーキテクチャの5つの柱」P25

今年2023年の11月9日に「Beyond Digital Transformation」と題してアニュアル・カンファレンス 2023を開催致しましす。今回は久しぶりに会場での対面参加とZoomでのオンライン参加のハイブリッド形式で開催致します。 本カンファレンスの講演タイトルは、以下のラインナップとなります。 Beyond DT～エンタープライズ・オントロジーの勧め～ システムアーキテクトの重要性とその育成について 新時代のアーキテクトが拓くデジタルアドバンテージへの道 中でもITアーキテクトの育成はDX推進をする中で重要な課題の1つとなるでしょう。ITアーキテクトは単にITスキルを身につけるだけでアーキテクトになれるわけではなくビジネス要求に対しても応えていけることが求められています。このためITスキルだけではなく他の要素も身につける必要があります。本コラムではその中で昨今よく目にするようになった「デザイン」という要素について考えてみたいと思います。 ・デザインという言葉について デザインという言葉は最近だと様々な場面で登場します。BTABoKオペレーティングモデルの概念にも「デザイン」という要素がありますが、業界・業種・職種等でその意味や意図するところが異なるように思えます。一方で根本的に共通している部分もあるように思えます。それほど「デザイン」という言葉が表す概念がある種の観念的に使われる多様な時代なのかもしれません。 ITの世界の中でもやはり「デザイン」という言葉は様々な観点で用いられているように思います。システム開発の観点で語られる「デザイン」という言葉の中には設計、アーキテクチャ等の意味が含まれる要素が強いように思われますが、グラフィックス技術が絡むような特にUI（User Interface）となると「デザイン」という言葉は絵やビジュアルの要素を強く含むように感じます。もちろんビジュアルデザインも「デザイン」の1つなのですが、ビジュアルデザインはあくまで「デザイン」した結果であって、表層的なものです。見た目が綺麗、かっこいい等というのはもちろん「美的ユーザビリティ効果」という言葉があるようにユーザビリティ向上に貢献する重要な要素です。しかしその根底には価値を定める戦略、価値に必要な要件、要件を実現する構造、それを使うためのタッチポイントや得られる体験価値を定める等を「デザイン」してその上にビジュアルの「デザイン」があるということを理解する必要があります。UIといったビジュアルデザインにフォーカスされがちなものを「デザイン」する上においてもオペレーティングモデルの「デザイン」の考え方は非常に参考になるでしょう。 ・人間中心設計 少し話は変わりますが、「デザイン」には人間中心設計（HCD＝Human Centered Design）という考え方があります。これまでは製品やサービスを高機能化することや品質を高めることが製品やサービスの価値に直結していましたが、モノが溢れた現代ではモノからコトへと「人」が感じる価値が移り変わり、よく言われるUX（User Experience）という体験価値を高めることが製品やサービスの価値となるという方向に市場が変化しています。モノからコトへ価値が移り変わるとその価値を体験する「人」が中心であるべきである、という考え方が重要になります。その「人」が将来何を求めるか、何に価値を感じるのか、この予見を正しく定め、その確からしさを評価した上で仕組みを作る人間中心設計が今後の「デザイン」という言葉に含まれる意味になっていくと思います。 ・DX推進とデザイン 昨今叫ばれているDX（Digital Transformation）はデジタル技術で社会の人々の生活をより良いものへと変革することですが、これまで言われていたIT化をさらに進めた考え方です。IT化は例えば紙をデジタル化するとか旧来のアナログ作業をデジタル化するような取り組みが実態でしたが、DXではわざわざ「変革」という言葉が用いられています。DXを推進する過程でIT化を行うため、DXの中にIT化が含まれると言えます。その意味では混同されがちですが単にIT技術を導入することが目的ではなく、デジタル技術を用いてビジネスをいろんな意味で変革することが目的です。このため、何のために何をデジタル化しそれによって何が変革されるのかをしっかり「デザイン」し、その上で具体的にどういうことを行なっていくかを「デザイン」することが重要ではないでしょうか。そしてITアーキテクトも「デザイン」スキルを身につけることによって、よりDX推進に貢献できると考えます。 先にも触れましたがIsaa日本支部は、2023年11月9日にアニュアル・カンファレンス 2023 を開催いたします。今回は「Beyond Digital Transformation」〜デジタルアドバンテージへのITアーキテクトの新たな役割〜を主題に企業の真のデジタル変革に向けて、デジタル人材 (特にITアーキテクト) の重要性とこれから求められるスキル、育成について豊富な知見と実績をお持ちの講演者をお招きしておりますので、DXに関心がある経営者層から専門職の方まで、この機会を是非お見逃し無くご参加下さい。