本コラムでは、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に関心がある経営者層から専門職の方まで、この機会を是非お見逃し無くご参加下さい。

近年、私たちの社会は急速にデジタル化の波にのまれています。これまでのデジタルトランスフォーメーションは、ビジネスプロセスの最適化や効率化に注力し、多くの組織が成功を収めてきました。しかし、コロナパンデミックやウクライナ危機などの出来事により、私たちのビジネス環境は一変しました。製造業においてはサプライチェーンが壊滅し再構築が必要になりました。またテレワークの普及によって変化した人々の拠点性や働き方に着目し、アフターコロナの地域内外のバリューチェーン構築が、デジタルトランスフォーメーションに新たな側面をもたらしています。 製造業を取り巻く従来のデジタルトランスフォーメーションでは、ビジネスプロセスのデジタル化が中心でした。しかし、社会の変化により、サプライチェーンの脆弱性が露呈し、その再構築が喫緊の課題となっています。ITアーキテクトは、サプライチェーン全体の可視性と透明性を高めるためのデジタルソリューションを設計し、実現する役割を果たします。具体的にはデータ分析、IoT、ブロックチェーンなどの技術を駆使し、リアルタイムの情報共有とリスクの早期発見で経営を支援します。 他業種においてもコロナパンデミックを契機に一気に普及したテレワークに代表される低コストのコミュニケーション技術を活かし、地域を越えた人単位の分業を促進することが求められています。アフターコロナの世界では、バリューチェーンは従来の単線型だけでなく、複線型で捉える必要があります。人々の拠点性が変化した今、地域内外でのバリューチェーンを統合し、地域の資源を活かした付加価値の創造が重要です。ITアーキテクトは、新たなバリューチェーンのデザインと実現において中心的な役割を果たすことで、地域経済の発展を支えることができます。 このようにITアーキテクトは、ITの領域にとどまらず、ビジネス全体の戦略における重要な指針を提供するリーダーとしての役割を果たします。単なる技術の導入に留まらず、ビジョンと戦略の融合が求められ、ITアーキテクトはその架け橋としての活躍を期待されます。 デジタルトランスフォーメーションが新たな局面に突入した今、ITアーキテクトの役割も進化し、サプライチェーンの再構築や複線型バリューチェーン実現に代表される重要な経営課題の解決にチャレンジするリーダーシップが求められています。デジタルアドバンテージを追求し、ビジネスの持続的な成長と競争力を支えるために、ITアーキテクトが果たす役割にますます注目が集まっています。 このような社会情勢を背景に2023年度のアニュアル・カンファレンスは「Beyond Digital Transformation 〜　デジタルアドバンテージへのITアーキテクトの新たな役割　〜」を主題として2023年11月9日に開催することが決定しました。カンファレンス講演の詳細については後日お知らせいたしますが、皆様にとって発見と学びの機会になれば幸いです。

今回は、BTABoKオペレーティングモデルの概念である「デザイン」を取り上げます。 デザインとは何でしょうか？日本語では「設計」と表現されることもありますが、デザインと設計ではニュアンスが少し違うようにも感じます。例えば工業製品においてデザインと設計の違いは、以下のように説明されることが多いと思います。 デザイン: デザインは、製品の見た目、感じ、ユーザーインターフェースなど、ユーザーとの直接的な相互作用に関連する要素を含みます。デザインの目的は、製品が視覚的に魅力的で使いやすく、理解しやすいものにすることです。また、製品のデザインは、ブランドの個性や価値を反映し、製品自体がどのような価値を提供するかを消費者に伝える役割も果たします。 設計: 設計は製品の機能面に重点を置きます。これには、機械的、電気的、またはソフトウェアの要素など、製品がどのように機能するか、どのように組み立てられるかなどの詳細が含まれます。設計の段階では、製品が安全に機能し、製造コストが抑えられ、目的に合致するように、各部品の形状、サイズ、素材などを選択します。 それぞれ別物のようですが、これら2つのプロセスは互いに影響を及ぼしあいます。それは、アーキテクチャデザインにおいて、特にあてはまると思われます。つまり、アーキテクトはデザイナー視点とエンジニア視点を合わせ持ち、それらの視点を行き来することで製品開発の成功に重要な役割を果たすべきと、私は思います。 BTABoKオペレーティングモデルでは、以下のように述べられています。 「デザインを行う場合、アーキテクトは、利点、機能、品質属性、制約に由来する要件を考慮しなければならない。これらの要件は、設計オプション（技術の広さ、深さ、パターンや参照モデルを適用）を生み出す。これらのオプションからアーキテクトは、価値、リスク、品質属性（フィットネス関数）、設計全体の適合性、および原則（と例外）に影響を与える決定を下すのである。」 図をご覧ください。 これは、オペレーティングモデルで「デザイン」を説明した図です。デザインの中でアーキテクトは、利益、特徴、品質属性、制約（原則も含む）から派生した要件を考慮しなければなりません。これらの要件は、幅広さ、深さ、パターンの適用可能性、参照モデルを持つオプションを作成します。これらのオプションから、アーキテクトは価値、リスク、品質属性（フィットネス関数を通じてテストされる）、設計全体の一貫性、原則（および例外）に影響を与える決定を行います。 また、BTABoKはこうも述べます。 「デザインはアーキテクチャの一部であり、全てのアーキテクチャはデザインの対象になるが、逆に全てのデザインがアーキテクチャになるわけではない。なぜなら、アーキテクチャとはシステムの形状と機能を決定する重要なデザイン決定を表現するものだからである。」 例えば、新しいソフトウェアを開発する際、全体のデザインをするのがアーキテクトであり、そのデザイン全体がアーキテクチャになります。しかし、その中に含まれるUIデザインやロゴデザインなどは、アーキテクチャの一部であるデザインになります。デザインは「名詞」としての成果物（設計図など）だけでなく、「動詞」としての行為（設計すること）も指します。デザインは安全で、経済的で、そしてエレガントな解決策を意図的に創造する行為であり、アーキテクトにとって最も重要なスキルと言えます​​。例えば、アプリケーションのデザインを考える際、ユーザビリティ（安全性）、開発費用（経済性）、見た目の美しさ（エレガンス）を考慮し、これらをバランスよく組み合わせることが求められます。 BTABoKでは、具体的な設計図を描く前に、「最後の責任ある瞬間まで」決定を遅らせるというアプローチが推奨されています​。これは、最終的な設計決定をする際に最も多くの情報を利用できるようにするための戦略です。例えば、新しいウェブサイトを設計する際に、サイトのレイアウトや機能を決める前に、ユーザーニーズや市場の動向、技術のトレンドなど、最も新しい情報を収集 で、過度な先読みによる時間とリソースの無駄遣いをバッド・プラクティスとみなしています。 正解がないと言われる昨今のVUCAの文脈において、デザインとは様々なトレードオフを有する複雑なシステム（特にソフトウェア集約システムではそうです）を最適化する行為であるとともに、実験を促す仮説そのものでもあります。ある仮説にもとづくデザインに従ってソフトウェアを構築し、指定された環境で実行することで予想される結果が得られたかどうかを、定量的に測定されるべきものです。そしてそのフィードバックをもとに、絶え間なくさらなる実験へと進み続けていくことが、これからのソフトウェア開発のあるべき姿なのでしょう。 Iasa日本支部は、日本国内でも今以上に実践力を備えたアーキテクトが認知され、活躍できるような業界にしたいと考えています。今回解説したデザインスキルは、アーキテクトにとって特に重要なスキルです。このようなスキルを有した成熟したアーキテクトが一人でも多くなるよう、これからの価値ある情報を発信していきたいと思います。今後のIasa日本支部の活動へのご参加、ご協力をよろしくお願いいたします！