明けましておめでとうございます。本年も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" が多くのアーキテクトの一助となることを望みます。
ご一読いただきありがとうございました。