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

システム開発には、さまざまなステークホルダーが存在する。それぞれまったく立場が異なる各ステークホルダーと、ITアーキテクトはどのようにコミュニケーションをとっていけばいいのだろうか？ そこでは、「2つの見方」の使い分けが鍵になる。

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

アーキテクチャ設計に不可欠な「2つの見方」

　前回「ITアーキテクトは物事をどう見るべきか？」では、アーキテクチャにかかわる決定を各ステークホルダーと調整する際に、おのおのの立場と視点に合った表現にその内容を変換しないと、スムーズにコミュニケーションを取ることができないと述べた。その変換の仕方を、今回のテーマとして取り上げてみたい。

　今回も、簡単な問いから話を始めよう。

機能中心のユーザー視点

［問い］

　「GoogleのWebシステムを簡単に説明してください」

　ほとんどの読者は、いまでは誰もが知っていて、いつも遊び心に満ちた“Google”ロゴが中央に描かれたGoogleのホームページを思い浮かべたのではないだろうか。おそらく、多くの人の答えは次のようなものになるだろう。

［答え］

　「“Google”と書かれたロゴの下にテキストを入力するフィールドが用意されていて、そこに知りたい情報のキーワードを入れる。検索ボタンをマウスでクリックすると、インターネット上にあるキーワードに関係した情報を検索できる。検索結果に表示される情報は、独自の仕組みによって情報収集・蓄積されたデータベースから抽出されたもので、関連性が高いと考えられる順序でリスト表示される。ユーザーはそのリストの中から任意のリンクをクリックすると……」

　こう答えた人にとって、Googleはあくまでもインターネット上の検索エンジンという道具であり、自分自身はGoogleのユーザーである。知らない言葉の意味を調べたいときに、その言葉をテキストフィールドに入力して検索さえすれば、言葉の定義が書かれた幾つかのページに行き当たることを知っている。またこの人は経験上、欲しい物が買えるお店を探すためには、どのようなキーワードを入れたらいいかも知っている。

　上の答えでは、Googleの使い方を簡単に説明しているにすぎない。しかしそう答えた本人は、Googleの機能や使い方など、もっとたくさんのことを暗黙的に認識しているのだ。

実装中心の開発者視点

　それでは、次の問いはどうだろうか。

［問い］

　「あなたが開発しているWebシステムを簡単に説明してください」

　この問いに対する答えは、2つに分かれるだろう。

　1つは先の問いと同じく、自分が開発しているWebシステムの機能を説明する答え方だ。例えば、ブックストアのeコマースサイトを開発している人であれば、次のように答えるかもしれない。

［答え1］

　「私がいま開発しているのは、インターネットで本を売るサイトのためのWebシステムだ。ユーザーが欲しい本の情報を入力すれば、その本の情報（価格、著者、書評）を表示する。また、最近人気のある本を一覧で表示したり、ユーザーごとに関心が高い分野の推奨リストを表示する機能もある。さらに、欲しい本を入れておくショッピングカート機能も用意されている」

　このように答えた方は、あくまでユーザー視点で自分が開発しているシステムを見ることができている人だ。

　一方で、次のように答える人も多いのではないだろうか。

［答え2］

　 「私はいま、Strutsのフレームワークを使ってアプリケーション開発をしている。検索エンジンには、商用のミドルウェアを使っている。そのほかの部分はオープンソースを活用し、LAMJで構築したWebシステムだ。機能としては、ユーザー管理、受発注管理、ブック情報管理などがある。季節によって処理データ量に変動があり、場合によっては大量のトラフィックが想定されることから、Webサーバはスケールアウト構成にして拡張できるようになっている。商品の画像データはNFSサーバでコンテンツ管理しており、Webキャッシュの仕組みも使っている」

　お分かりの通り、これはシステム開発者の立場に立ってシステムの内部の仕組みを説明する答え方だ。

　あなたはどちらの答え方をするだろうか？ もちろん、説明する相手にもよるだろう。しかしシステム開発の現場では、相手にかかわらずどちらか片方の答え方しかできない人が多いのではないだろうか。後ほど述べるように、ITアーキテクトはステークホルダーごとにどんな対象についてもこれら2つの見方を使い分けなければならないのだ。

図1　利用者（ユーザー）視点と開発者視点

機能以外の見えない性質

　先ほど、「Googleの機能や使い方など、もっとたくさんのことをユーザは“暗黙的に”認識している」と述べた。ここでいう“暗黙的に”とは、一体どういうことなのだろうか。

　これは“非機能要求”などと呼ばれるもので、明示的に機能としてうたわれていない品質に対する要求や、前提条件などのことを指している。

　Googleの検索機能の例では、ユーザーのインターネットの通信環境が良好であれば、ほぼ瞬時に検索結果の応答がなされ、端末の画面に表示される。そのことを、ユーザーは当然と考えている。そして、Googleのサイトがほぼ24時間・365日利用可能であることも、またしかりだ。機能の点でも、検索結果として表示されるリストがあくまでインターネット上の情報の一部であって、本当は最適な情報が欠けているかもしれないことも暗黙の前提条件として受け入れている。

　一方で、日ごろから開発者視点でGoogleを見ている人は、その内部構造が独自の分散処理技術を用いていることや、何万台というサーバで世界中からの大量の検索リクエストを処理していることを知っているだろう。

　先の問いで「GoogleのWebシステムを簡単に説明してください」といった場合に、ここに書いたようなことを含めた2つの見方で“GoogleのWebシステム”という概念は認識されるのだ。

　この「2つの見方」は、オブジェクト指向でのカプセル化や、データベースにおける外部／内部スキーマの概念として広く知られているものだ。ただし、どちらも一般的には機能中心であり、さまざまな品質や前提条件まで十分な考慮がなされているとはいえない。

　以降、アーキテクトに求められるこの「2つの見方」の必要性や、アーキテクチャ設計の上での注意点を述べていく。