ユーザー視点と開発者視点を使い分けよう：ITアーキテクト的発想のススメ（2）（2/2 ページ）

[東山 靖弘（NTTデータ），＠IT]

ITアーキテクトに求められる抽象化スキル

　近年、オープン系技術が普及し、情報システムがモジュール化され、垂直・水平方向に階層化・分散化される傾向にある。前回、階層化・分散化された情報システムのアーキテクチャを設計するうえでは、全体を広くとらえ、かつポイントとなる部分を深く把握することがITアーキテクトには求められると述べた。対象や尺度を変えた複数の視点でアーキテクチャを見るときに、この「2つの見方」が大切になるのだ。

　なぜなら、より広く全体をとらえようとするときには、どんな部分もそれが担う機能をユーザー視点で見ることになる。一方、より深く部分を把握しようとするときには、逆にその内部構造を実装者の視点で理解しなければならないからだ。

　ITアーキテクトは、システム全体を部分となるモジュール（サブシステムなど）に分割し、その部分の役割を定義する。その際に、2つの見方から役割を確認し、「全体との整合性」と「部分としての妥当性」を1つ1つ検証していかなければならない。これが、アーキテクチャ設計の要となるプロセスである。「2つの見方」ができなければ、アーキテクチャの検証が不十分になってしまうのだ。

　すべてのITアーキテクトに共通する課題は、「2つの見方」でどこまで広く、深く見ることができるかという点にあると筆者は考える。「ITアーキテクトには抽象化スキルが必要だ」といわれることが多い。その場合、あらゆる対象を今回取り上げた「2つの見方」で把握するスキルを指していることが多い。

　ここでは、抽象化を行う際に筆者が心掛けているポイントを述べておきたい。

　ユーザー視点で対象を記述する際は、全体の中でその対象が担っている目的・役割をはっきりとさせたうえで、あくまでも「道具」としてできること・できないことを考えていくとよい。一方、実装者視点で記述する際には、具体的なデータ構造、アルゴリズム、ハードウェア／ミドルウェアのコンポーネントを念頭に置く。

　その際に、あまり言葉だけで考えないことだ。言葉だけの表現では、非機能面の品質や、インターフェイスの在り方などを見落としがちになる。言葉、数字、イメージ図などさまざまな表現方法を駆使してイメージをつかみやすくするとよいだろう。複数の表現方法の中から適切なものを選ぶことで、対象を単純化しつつ、より正確にとらえることができるからだ。

　ここまで述べてきた内容のポイントをまとめると、以下のようになる。

［ポイント1］

ITアーキテクト自身が、2つの見方を使い分けること

［ポイント2］

言葉、数字、イメージを駆使して、抽象的に対象をとらえること

変化に対応するため「見続ける」ことが大切

　ITアーキテクトにとって、企業システムの全体を広くとらえる際の障壁の1つは、企業のビジネスアーキテクチャ、およびその上で行われているビジネスフローがなかなか見えないことだ。近年、そういった課題に対して、各企業がEA（Enterprise Architecture）の考え方を採用し、ビジネスアーキテクチャの見える化に取り組んでいる。また、そういった企業に情報システムを提供するベンダ側も、見える化されたビジネスアーキテクチャをモジュール化する手法の策定に取り組んでいる。

　例えば通信業界では、通信事業者とベンダが参画した業界標準団体（TMF）によって、ビジネスアーキテクチャの標準化への取り組みが進められている。また、SAPに代表されるERPパッケージベンダは、ベストプラクティスとされるビジネスアーキテクチャを実装した製品の導入を各企業に提案している。

　一方で、業態を超えた企業の合併や、新しいビジネスモデルの登場により、こういった標準化されたビジネスアーキテクチャでは対応できない分野も次々と現れている。また、技術革新により従来とは異なる概念のモジュール化製品も日々新たに登場している。

　ITアーキテクトはこのような変化に対して、常に全体と部分を「2つの見方」で見つめ直していかなければならない。そのうえで、最適なアーキテクチャを追求し続けていくことが必要だ。こうした変化への対応については、次回詳しく扱いたい。

モジュール定義に必要な「遊び」

　実際にアーキテクチャを設計し、実際の開発に着手する際には、これまで述べてきた「2つの見方」でとらえたシステムの全体と部分の関係を記述し、開発プロジェクトのステークホルダーで共有する。

　そこでは、「全体を部分となるモジュールに分割し、そのモジュールを2つの見方で記述する。そして、またそのモジュールを部分に分割し……」というように、段階的に詳細化していくことになる。

　その際、「モジュールをあらかじめ正確に定義しなければならない」ということがよくいわれる。分業が進むシステム開発プロジェクトにおける手戻りを避ける意味では、モジュールの正確な定義は大切である。しかし、筆者はここであえて、その定義に若干のあいまいさを織り込ませることの重要性を指摘しておく。

　定義しようとする対象について、ユーザー視点と実装者視点が正確に一致することはまれ である。それは、ユーザーと開発者が認識するものが異なっていることに起因する。機能性のように正確さを検証できるものは一部だけであり、そのほかの非機能面の品質を「2つの見方」で一致させることは困難を伴う。どこまで行ってもズレが存在していると考えた方がよい。

　そのときに、モジュールの定義に若干の「遊び」を織り込んでいくことが大切になる。ユーザー視点で求めるものと、実装者視点で実現するものとの間に発生するズレを吸収する「遊び」の存在は不可欠なのだ。

　例えば、システムの機能をモジュールに配置する際、特定の機能をどのモジュールに配置するべきか、判断に迷うことがよくある。システム全体から見るとモジュールAに配置するべきだが、実装時のことを考えるとモジュールBに配置した方がよさそうだ……といったケースだ。このような場合には、その時点ではその機能の配置を決定せずに、モジュールA、Bのどちらにも機能を配置する可能性を残しておくのだ。

　木造建築で建材を組み立てていく際、よく「遊び」を作っておくという。そして、こうした「遊び」部分が後工程で全体の品質を高めていく武器になるのは、建築もシステム開発も同じである。ITアーキテクトにとって、この「遊び」をどの部分にどう織り込ませておくか、それを見極めるスキルも大切なのだ。

筆者プロフィール

東山 靖弘（ひがしやま やすひろ）

株式会社NTTデータ 基盤システム事業本部

通信事業者向け基幹システムの企画・開発を経て、現在は上流工程におけるアーキテクチャ設計支援とともに、開発方法論の整備やナレッジマネジメントに取り組んでいる。

「ITアーキテクト的発想のススメ」バックナンバー

• アーキテクチャの評価は何でする？
• そのシステムの将来の姿、見えますか？
• ユーザー視点と開発者視点を使い分けよう
• ITアーキテクトは物事をどう見るべきか？