[書評] システム構築の大前提 - ITアーキテクチャのセオリー -4/4-
前回に引き続き、技術書籍の ITアーキテクチャのセオリー を紹介していきます。この書評は今回が最終回です。
第Ⅳ部｜戦術ソリューション
「複雑系システムにおいては、それ自体を説明する（リポジトリ）システムを保有しなければならない」
大規模システムを保有するユーザ企業において、システム全体のアーキテクチャをしっかり可視化できている企業はかなり少ないかもしれません。個別最適なシステム設計書は充実していても、全体最適なシステムアーキテクチャが存在しないケースがほとんどです。また、システムアーキテクチャが存在していても、ビジネスアーキテクチャと連動していないケースも見受けられます。
このような状況を打破するためには、複雑な大規模システムを説明するための仕組み（システム）が必要です。大規模システムを説明するためには、システムが保有しているデータの品目（メタデータ）を明らかにして、それぞれの関連性を可視化し、誰もが理解できる状態に保ち続けることが重要となります。これを実現する手段として、筆者はシステムのあらゆる仕様を一元管理する仕組み（リポジトリ）の重要性を説明しています。
運用上の注意事項があります。それは、マスターHUBの存在をないがしろにして、データ発生源のシステムから直接インターフェースしてしまう事です。
複数のデータ発生源が存在する大規模システムの場合、この注意事項を守れていないパターンは非常に多く見受けられます。特に全体のアーキテクチャの責任部門が存在しない場合にこのケースが発生しやすく、繰り返されると複雑怪奇なシステムアーキテクチャ（スパゲッティ化）に逆戻りしてしまいます。
マスターHUBはその名の通りデータのマスター（正規版）です。データ発生源の産地直送で得られるデータは、マスター（正規版）ではないという考え方をすべきです。データを利活用する際に、無加工の生データを利用したくなる心理をぐっと堪えて、正しく加工された正規データをマスターから取得する思考を習慣化することが重要です。
コピー&ペーストでイベントデータが散らかっている状態から、トランザクションDWHを元に共有（シェア）する形へと、徐々にアーキテクチャを転換していくのです。
マスターデータだけではなくトランザクションデータもHUB経由でシステム間を連携させることによって、重複したトランザクションデータを各々のシステムで保持する必要がなくなります。また、トランザクションデータHUBを中継することで疎結合なアーキテクチャとなり、他方のシステムをクラウド化したり、旧来のシステムを新しいシステムに切り替えることがやりやすくなります。
ホモジニアスなアーキテクチャでは限界が見えています。是が非でも、ヘテロジニアスなアーキテクチャに移行していく必要があると筆者は考えます。
単独のメーカーの製品で構成されたホモジニアスなネットワークやアーキテクチャは、大規模でグローバルなビジネス環境にいずれ適合できなくなります。そのため、様々なメーカー製品や異業種・異分野のシステム間連携を前提としたヘテロジニアスなネットワークやアーキテクチャを目指す必要があります。
過去の日本の歴史を遡ると、鎖国の時代がホモジニアス、開国後がヘテロジニアスな文化・技術交流でした。グローバルで多様化した時代のビジネスにおいて、ヘテロジニアスを前提としたアーキテクチャが必要とされることは間違いありません。その為には、様々なシステムとの接続や、多種多様なデータのやりとりが実現しやすいアーキテクチャを採用すべきであり、その中心となるのがマスターデータHUBやトランザクションデータHUBです。
移行リスクを最小化し、緩やかなダウンサイジングを達成すると同時に、企業システムをデータ中心アーキテクチャに変えていきます。
ここでは、漸進的に進めるべきアーキテクチャの移行作業を、急ぎ過ぎてはならないという注意を促しています。アーキテクチャ設計・開発に携わる担当者は、コストダウンやTo-Beのアーキテクチャ像の実現を急ぎすぎて周囲の賛同を得ることができずに、アーキテクチャ移行が上手く進められないことがよくあります。
これを回避するためには、As-IsとTo-Beへ段階的に移行するアーキテクチャのプランニング、その移行計画を実現した際のメリットを明確化することが有効です。移行プランニングの際の、優先度はビジネス効果の指標となるROI（Return On Investment：投資収益率）で判断すると良いと筆者は説明しています。
高度情報化社会では、個々人の情報リテラシーに委ねたネットワーク型のN:M情報共有モデルももちろんあり得ますが、大規模組織におけるオフィシャルな情報共有には、未だ一定のルールが必要です。
ここで記載されているネットワーク型の情報共有モデルとは、Web3.0の特徴のひとつである自立分散型のネットワークを指しています。自律分散型のネットワークにおいては個人情報を含めてデータを所有する人がデータを管理することになるため、将来はデータの管理ルールそのものが不要になるという誤解をしがちです。データそのものが分散し個別管理（例えば個人管理）されていたとしても、その分散されたデータ群全体を把握・管理する仕組みが必要不可欠です。これは、人がどれだけ多様化して自立的な情報管理ができる様になったとしても、国が人々の状態を把握（全体管理）しなくなるわけではないことと同じ理由です。
プログラマやSEの作り物のデータを使ったホワイトボックステストに長時間を割くよりも、既存システムの生データに基づくブラックボックステストの方に、できるだけ早く取りかかるべきです。
これは、無機的なテストよりも有機的なテストを重視すべきということに置き換えられます。システムのテストでは、想定されるテストケースを網羅的に行うことで問題個所を洗い出すことが多いと思います。しかし、実際の環境では、テストケース通りの事象が発生せずに、全く違う事象の発生によってサービス障害を起こすことを経験されているエンジニアはかなり多いと思います。テストデータをできるだけリアル環境に近いものを使用することで、このような問題を高確率で回避することができます。
例えは良くありませんが、薬の試験を机上で行うよりも、治験（人体による臨床試験）を行う方がより確かな検証結果を得やすいことに似ています。
特にアジャイル開発のように設計・構築・テストを繰り返す場合は、試験データも本番に近いものにブラッシュアップし続けることが大切です。
https://www.it-innovation.co.jp/2016/07/03-233711/
設計・構築・テストのフェーズにはアジャイル開発を採用します。両端の要件定義と移行フェーズはウォーターフォール型で実施するというハイブリッドな構成です。
ここで書かれたハイブリッド型の開発手法は理にかなっていると思います。事業開発にスピードを求められる昨今、ウォーターフォール型の開発手法の限界が叫ばれて久しいですが、その課題を解決するアジャイル開発の期待感とは裏腹に日本ではまだまだ浸透していません。これまでウォーターフォール型開発で培ってきたシステム開発から、突然アジャイル型の開発に移行したことで、サービス稼働の品質が保てなくなってしまうケースもよく見受けられます。これは、アジャイル型開発を適用するべきシステムの対象を誤っているなど、様々な理由があります。
アジャイル型開発の特徴は小さく設計・開発・テスト・デプロイのサイクルを繰り返す過程で徐々に機能と品質を高めていく事ですが、最初のサイクルの時点で十分に高まっていないサービス品質を受け入れる風土が、提供する企業側にも利用するユーザ側にも備わっていないことが理由のひとつだと私は考えています。
このような状況の中でも、アジャイルの特徴を生かしつつ要件定義とシステム移行フェーズをウォーターフォール型で行うことにより、利用者にとって不完全なサービスが提供されるリスクや、デプロイ時やデプロイ後にサービス品質が不安定になってしまうリスクを最小限に抑えることが可能です。
https://www.it-innovation.co.jp/2016/08/29-004910/
直近の2～3年に関しては、図（アーキテクチャ・ロードマップ）の上部にある個々のプロジェクト・スケジュールとの整合性、即ち、EAがどのような状況にある所で新システムが稼働を迎えるかを、確認しておく必要があります。
アーキテクチャ・ロードマップがビジネス・ファーストである以上は、TOBEのアーキテクチャが『現状課題解決のためだけのプロジェクトに依存すること』を避けなければなりません。アーキテクチャ・ロードマップのTOBEは、現状ではなく将来にありたいビジネスの姿であり、CanBeはTOBEのベクトル上に乗った中間地点（中継地点）になっている必要があります。つまり、ASISの現状課題解決の先にCanBeやTOBEが現れることは絶対にありえません。
プラモデルなどの模型を組み立てる際、しっかりと完成図があって、その完成図に向かって部品同士を組み上げていきます。完成図が無い状態で最初の組み立ての手順や、途中の状態が作れないのと同じです。仮に組みあがったとしても、作りたかった最終的なイメージとは全く異なる完成品が出来上がってしまいます。
一方、ここで筆者が記載していることは、直近の短期的な目線では、実行中または予定されているプロジェクト計画と整合していることが重要であると言っています。個々のプロジェクトがアーキテクチャ・ロードマップのTOBEに寄与するものになっているか、なっていない場合はプロジェクト計画の方を微調整するなどのアクションが必要になります。
AMOの設置で忘れてならないのが、十分な権限の付与です。組織に横串を通すチームには、かなり高位の権限が必要ですから、システム部門長の直轄とするぐらいが好ましいでしょう。
AMO（Architecture Management Office：アーキテクチャ・マネジメントオフィス）の設置が、大規模システム開発において必須であることは本書を読めば自明ですが、ここではAMOの権限について触れています。アーキテクチャ活動において最も難しい点は、企業内の合意形成にあると言っても過言ではありません。アーキテクチャ・マネジメントオフィスの決定事項が、会社のCEO（Chief Executive Officer：最高経営責任者）やCTO（Chief Technology Officer：最高技術責任者）の決定事項と同等に扱えるだけの権限移譲がなされることが理想です。これは、TOGAF🄬のプロジェクト体制においても、承認スポンサーとしてCxO（Chief xxx Officer：xxxの最高責任者）を例示しています。但し、CxOがアーキテクチャ活動をAMOに委任していたとしても、実情としてAMOが最高の権限で活動できるとは限りません。AMO自身が社内の信頼に耐えうるケイパビリティ（能力）を備えていることが重要です。
本書を通読して、私自身のシステムアーキテクチャ活動の再確認をすることができました。アーキテクチャ活動の中心となる人材だけでなく、個々のプロジェクトにおいて、サービスやシステムの設計に携わる人材にもお勧めしたい良書です。
この記事が気に入ったらサポートをしてみませんか？