アプリケーション設計と標準化
アプリケーション・アーキテクチャを固めたら,それに基づいて設計方法や実装方法の標準化を図ります。一般に標準化はプロジェクト管理者(PM)の仕事と考えがちですが,Webアーキテクチャとアプリケーション・アーキテクチャの両設計に関与したWebアーキテクトは,標準化のうえでもプロジェクト管理者を支援する立場にあります。
アーキテクチャにかかわる書き方に気を配る
Webアーキテクトとして特に気にかけたいのは,アプリケーションの書き方に関する標準化です。例えばデータベース(DB)アクセス処理で,ある個所はDBアクセスに特化した「DAO(Data Access Object)」クラス経由としているのに,別の個所ではMVCモデルの「Controller」から直接アクセスしているとしたら,書き方がそろっているとは言えません。
このようなケースでは,DAOはともかく,Controllerという汎用的なクラス内にDAOと同様のDBアクセス機能が実装されていることは,開発した本人以外は気付きにくいので,保守性が下がってしまいます。DBアクセス処理は,システム基盤で採用したミドルウエアや,アプリケーション・アーキテクチャで採用したフレームワークとも深くかかわる部分なので,Webアーキテクトがアプリケーションの書き方を統一するよう目配りすることが欠かせません。
標準化というと,分厚いドキュメントの作成を想像するかもしれませんが,簡単なメモ書きで構いません。一貫性を保てることと,担当者が入れ替わっても標準が失われないように形に残すこと,の2点を満たせれば十分なのです。
標準化と前後して,プロジェクト管理者はプロジェクト内のメンバーのチーム編成(担当の決定)を進めるはずです。Webアーキテクトは,この作業においてもプロジェクト管理者の補助的な役割を果たします。プロジェクト管理者は,アプリケーション・アーキテクチャの内容に基づいてチーム編成を検討することが多いからです。チーム編成はチームに属するメンバーが保持する技術セットや納期などの諸要因を勘案しながら決定しなければなりません。Webアーキテクトは,プロジェクト管理者の決定が容易になるように,Webアーキテクチャとアプリケーション・アーキテクチャに関する情報を的確にプロジェクト管理者に伝達する必要があります。
* * *
今回,説明の中心にしたアプリケーション・アーキテクチャは,すでに「IEEE Std 1471-2000」として規格化されています。この規格では,アプリケーション・アーキテクチャを「ソフトウエア・アーキテクチャ」として一般化し,図1のような関係図にまとめています。
この図の中で,「システム」-「ステークホルダー」-「視点」-「モデル」-「アーキテクチャ(の記述)」が連携していることに注目してください。アーキテクチャの記述は複数のモデルを含んでいますが,そのモデルはシステムのステークホルダーの視点に応じて方式が決まります。つまり,視点に合わせてモデルを選び,アーキテクチャの記述も書き分けなければなりません。
例えばアプリケーションSEの視点では,各レイヤーの実装形式(実装形式の標準化)が重要になりますが,運用SEの視点ではディレクトリ構造やライブラリの依存関係の方が重要です。PMの視点では,レイヤーの実装に必要なメンバーのスキル・セットを知りたいでしょう。このように,アプリケーション・アーキテクチャは多面的に見ることが求められますから,文章で延々と説明するよりも,図解で表現した方が分かりやすく誤解が生じないことを忘れないようにしましょう。
ステークホルダーごとにアプリケーション・アーキテクチャを記述・分析する考え方を「視点(ビュー・ポイント)」と呼びます。視点を意識しながらステークホルダーの関心事をうまく分解・整理できれば,ステークホルダーに提示する情報を最小限に絞り込むことができます。不要な情報が減る分だけステークホルダーの判断・意思決定は容易になり,合意形成しやすくなります。結果的に,プロジェクトも推進しやすくなるでしょう。Webアーキテクトは,視点に基づいてステークホルダーごとに最適な方法で図解し,プロジェクトの推進を下支えしなければなりません。これは,システム基盤の設計図を描く以上に重要な,Webアーキテクトの仕事の一つです。
今回説明したアプリケーション・アーキテクチャは,ある一面だけを説明しています。特に,ログ出力,メッセージ管理といった共通設計などについては,説明が複雑になるので割愛しました。これらの部分はプロジェクトに依存する部分も大きいため,個別のプロジェクト単位でほかのステークホルダーを交えて検討してください。
|