本シリーズの第６回目は、ITABoK(Version2)の第２章＜ケイパビリティ・ガイドブック＞から5つ目の基本知識の柱として「デザインスキルの柱」を取り上げます。
先ずITABoK自体の”構造”から「デザインスキルの柱」の位置付けを確認しておきます。
下図はITABoK全体の構成を鳥瞰図に表した図です。デザインスキルは、全てのアーキテクトに共通の5つの基本知識の柱の一つとして位置付けられています。（青い点線部分）
下図はITABoKの特徴の一つになりますが、今回紹介するデザインスキルは、これまでこのコラムで紹介した他の4つの基本知識とスキル同様にITアーキテクトに求められるケイパビリティを高めるために大変重要な知識領域であるとしています。この「デザイン」と言う言葉は「アーキテクチャを設計する」事を意味します。
「デザインスキルの柱」では、ITアーキテクトとして成功するために必要となるデザイン理論、デザイン関連の戦略やテクニックに関する項目を取り上げて解説しています。
デザインスキルに関する具体的なケイパビリティとしては、以下の９つについて紹介されています。(ITABoK V2 日本語訳P121より)
アーキテクチャ記述
要件モデリング
分解と再利用
デザインの手法とプロセス
デザインの分析とテスト
デザインのパターンとプロセス
ライフサイクルにおけるトレーサビリティ
ビューとビューポイント
全体システムのデザイン
ITABoKの定義するITアーキテクトは、上記の項目リストの最後に紹介されている「全体システムのデザイン」が本来の役割とその目的を最も端的に表しており、以下の様に紹介しています。
「アーキテクトとして全体システムのデザインアプローチを採用する事は、人間、インフラストラクチャ、開発環境、組織構造を含む、IT環境全体を理解しなければならない事を意味します。デザインに全体システムのアプローチを取らない場合の結果には、低いデザイン効率（システムの部分的な最適化はシステム全体を最適化しない）、コストの増加、ソリューションの有効性の低下、品質属性サポートの低下が含まれます。」（ITABoK P152より）この本来の目的をITアーキテクトが果たすためには、設計に関する理論や個々のテクニックに関する知識とスキルが必要になるわけです。最初の項目リストにある「アーキテクチャ記述」では以下のように述べています。
アーキテクチャ記述は、テクノロジー・ソリューションが展開される背景（例：ビジネス・アーキテクチャ、ビジネスドライバー、ステークホルダーの関心事）、制約事項とリスク、システムのビジョンと目的、そのゴール、及び、関連する利用シナリオの探求と理解で始まる、アーキテクチャ開発プロセスの最終的な成果物です。アーキテクチャの全般的な「デザインのストーリー」を提供する事に加え、アーキテクチャ記述はモデルだけではなく、モデルに文脈と背景を提供する文書によるアーティファクトやその他のアーティファクトも含んでいます。 (ITABoK P123より)アーキテクトはアーキテクチャ設計の諸々の成果物の作成過程を通じてそもそものビジネスの背景を含む複数のインプットがしっかり反映されている事を確認する必要があります。この過程で上述の情報からモデルに変換し完成度を上げながらアーティファクトを作成する作業は知識とテクニックを要する作業になります。
「要件モデリング」に関しては、ITアーキテクトは様々なビジネス要件や制約を分析した後にドメインモデルやユースケースモデルの作成やレビューを通じてそれぞれの専門領域の立場で関与する事になります。要件モデリングについては次の様に紹介しています。
要件モデリングは、ある領域向けの要件と制約事項が把握され分析された時点で実行されます。これは要件の一貫性と完全性を保証するための重要な活動です。機能、品質属性と制約事項をモデリングするために様々な方法が存在します。取るべき適切なアプローチはシステムや組織のスタンダードに依存し、一部のケースでは使用されるドメイン特有のモデリング言語となります。ここでの重要な観点として１つのタイプのモデルを他のものへと変換する方法があります。トレーサビリティもこの重要な観点になります。(ITABoK P126より)「デザイン手法とプロセス」では、“良いデザインとは？”についての説明があります。この問いに対する回答は立場や置かれている環境によって異なり決して唯一の見解がある訳ではありませんが、ここではITABoKとしての見解をご紹介します。
良いデザインとは正当化、理由、そしてトレードオフの検討そのものです。デザインはモデルやダイアグラムとしばしば混同されていますが、実際にはダイアグラムはデザイン・プロセスの成果物です。多くのソリューションがビジネス・ニーズを満たす可能性があるため、複数の選択肢から１つのデザインを選択する際の背後にある論理的根拠は、アーキテクチャの本当の価値が存在する所となります。（ITABoK P131より）様々な要件、制約、現状などの多様な情報を元に時にはツールやテクニックを使い成果物（アーティファクト）を作成するわけですが、トレードオフの検討の結果とその論理的な根拠、その妥当性に関してのステークホルダーの納得性の高さが良いデザインの判断の目安になるとしています。（もちろん、成果物自体が満たすべき基本的な正確性、網羅性、一貫性等はきちんと満足された品質であるという前提ですが）
「デザインの分析とテスト」では、代替案を検討比較するための分析テクニックやツールを説明しています。更に成果物（アーティファクト）に対してどの様に比較検討とテストを行うのか、またその完成度や正確さ等については修正すべき箇所を特定した上で修復を行うと説明しています。(ITABoK P134より)
「デザインパターンとスタイル」では、建築業界における先駆者が語った「成功を収めるアーキテクチャは再利用可能である」の例を引用してその特徴を説明しています。デザインパターンの重要性についは次の様に続きます。
パターンは特定の背景、問題、ソリューション間の関係を表した３要素の構成のルールです。Christopher Alexander が提案したように、「各パターンは私達の環境の中で繰り返し発生する問題を表現し、私達が同じ解決法を２度と行う事なく100万回繰り返し利用できるような方法で問題に対するソリューションの中核部を描いています」。(ITABoK P136より) ある組織が（または業界が）既に行なっている様々な活動やこれから始まろうとする未来の活動スコープの中から再利用可能なパターンを「アーキテクチャの視点」で見つけ出すためには、それなりの知識や知見、経験と訓練を要する事でしょう。また、パターンの評価については、非機能的要件や品質属性に関連づける事を勧めています。(ITABoK P138より)（現実にはPM担当者やシステム開発部隊の声として「作った方が早い」「私たちは何でも作れるのだが」という声も聞こえて来る場合もあるでしょう）
「ライフサイクルおけるトレーサビリティ」については、既に前の数ヶ所で触れましたが、ITABoKが随所で強調するトレーサビリティの重要性は以下の様に説明されています。
トレーサビリティは適切な要件マネジメントに欠かせない活動の１つです。これにはビジネスの関心事の生涯を文書化するプロセスやその関心事に関連したケイパビリティへの双方向のトレーサビリティを提供するプロセスが含まれます。（中略）
アーキテクトは、ビジネス要件から長期的システムまでの適正なトレーサビリティを確立するプロセスによってプロジェクト・チームをサポートし、「開発段階にあるソリューション」のライフサイクルに関わるトレーサビリティの重要な役割を説明できなければなりません。（ITABoK P141より）ITアーキテクトはこの役割において、ビジネスの関心事と関連するケイパビリティを双方向のトレーサビリティで確保し、分析段階から実装段階、最終的には運用段階に至るまでカバーする重要性を説明しています。
「全体システムのデザイン」は、冒頭でも触れましたが、アーキテクチャの総合的なビューを採用したもので、この中にはシステムサイエンス、システム理論、システム思考を包括しており、またアーキテクトは複雑なシステムの問題を認識しこれらに対処する事も含んでいるとしています。
一方、全体システムの視野を失う事は中長期でのシステム保有コストを増大させ、ビジネス価値に影響を及ぼす事にも言及しています。この例として長年の多くのITプロジェクトの結果、複雑化したスパゲッティ状態のシステム群やソリューション毎に乱立したシステム群の状態を思い浮かべて頂けるとイメージし易いでしょう。
今回は、「デザインスキルの柱」を取り上げました。個別のデザイン方法論やテクニックに関してITABoKではそれ自体の詳細な解説は行なっていません。このデザインスキルの柱は、ITアーキテクトが常に全体システムのアーキテクチャ視野を持ちながら、個別の方法論やテクニックをデザイン本来の目的に活かせる様にガイドしている点が伺えます。
本コラムでご紹介した「デザインスキルの柱」と既にご紹介してきた4つの柱が、ITアーキテクトを目指す方々や育成に携わる方々のアーキテクチャ設計に必要な知識とスキル習得の指針の一助として役立てて頂ければと思います。
このコラムに関して皆様からのご意見や感想、参考になる事例等がありましたら是非お聞かせ下さい。本コラムがITABoKの理解とこれからのITアーキテクトのあるべき姿の一助になる事を願っています。
参考：
アーキテクチャの策定プロセスや成果物（アーティファクト）の業界標準の一つとして、IasaではTOGAFを引用・参照している経緯があります。また、アーキテクチャ用のツールとしてArchiMateをモデリング・ツールとして推奨しています。（これらに限定する訳ではありません）
TOGAF (OpenGroup)について
ArchiMate (OpenGroup)について