Webアーキテクトの成果物と心得

 選択した解決策は「アーキテクチャ説明書(記述書)」にまとめ,成果物として残します。

「視点」を意識した説明書に

 アーキテクチャ説明書はシステム全体の青写真と呼べるもので,家屋の設計で例えれば,基礎構造や柱・梁の設計図に相当すると考えてください。筆者は表1のような構成でアーキテクチャ説明書を作成しています。非機能要件一覧やシステム構成図のほか,アプリケーションのレイヤー図やシーケンス図,ログ出力などの共通設計,認証・権限管理などのセキュリティに関することも記述します。

表1●アーキテクチャ説明書の構成要素
[画像のクリックで拡大表示]
表1●アーキテクチャ説明書の構成要素

 “良い”アーキテクチャ説明書にするには,ステークホルダーの関心事に合わせた「視点(ビュー・ポイント)」を意識しましょう。そうすると,視点に合わせた項目や表現を盛り込むことになり,ステークホルダーに理解してもらいやすくなります。例えば表1の構成にはPMやSEにとっての関心事である,標準化やビルド方法などの項目が含まれていることに注目してください。これらの項目は,実際にはステークホルダーの種類やIT知識に応じて追加または削減します。

技術を知り技術を操る

 Webアーキテクトが目指すべきゴールは,非機能要件の解決策を導き出すことです。若い技術者やITスペシャリストと呼ばれる専門家は,特定の要素技術を習得することが求められます。それに対してWebアーキテクトは,技術に中立な立場で技術の本質を知り,技術を操れるようになることの方が重要です。

 ただし,新技術などが登場した場合,おおよその内容を理解する必要があります。理解している技術が少ないと,不適切な要素技術を選択してしまう可能性が高まるからです。一般に「バズワード」と呼ばれる技術にも興味を持ち,積極的に理解に努めましょう。バズワードの中に,知っておくべき技術や適用方法がないのかを検討するくらいの積極性が必要です。

 要素技術を理解する際には,技術の関連性や位置付けを意識することがポイントです。要素技術の利用局面を判断しなければならないWebアーキテクトは,要素技術を漫然と理解していても仕事になりません。同じカテゴリの他の要素技術と比べ,どのようなメリットやデメリットがあるかを具体的にしておきます。

 そのため,日ごろから要素技術をカテゴリ分けして整理しておくことが大切です。カテゴリの分け方は人それぞれですし,複数の分け方を使い分けることも必要になります。ここでは最も単純な分け方の例を表2に示します。

表2●要素技術を理解・分類するためのカテゴリ
[画像のクリックで拡大表示]
表2●要素技術を理解・分類するためのカテゴリ

 理解した技術は,すぐに使う必要はありませんし,また使えるものでもありません。使えそうな新技術を見つけたら,それと同じカテゴリの技術に強いITスペシャリストに相談し,技術検証してもらいましょう。ITスペシャリストは過去に類似の技術をいくつも見ているはずなので,それらとの比較を含めて実践的な評価をしてくれるはずです。

 自分で見つけた新技術で,システムの利用者や所有者に最適なシステムを実現できたときには,「Webアーキテクトをやっていて本当に良かった」という気持ちになれます。しかし検証結果によっては,システムに採用できないこともあります。その場合,不適切な技術を採用せずに済んだと考え,新技術をきちんと検証したことに誇りを持ちましょう。新技術に固執せず,現実的な解法を探求することが大切です。

 今回で本連載は終了です。既にITスペシャリスト級の知識をお持ちの読者には物足りなく感じたかもしれませんが,「Webアーキテクトに求められる技術力」は要素技術への精通ではなく,幅広い要素技術の本質を押さえ,要件に合わせてそれらを最適に組み上げる力にある以上やむを得ません。言い換えるとWebアーキテクトは「ソリューション・デベロッパー」であるということです。このような力は一朝一夕に身につくものではありません。日ごろの情報収集と思考・経験の積み重ねが必要です。本連載がWebアーキテクトに興味がある読者のお役に立ったら幸いです。

高安 厚思(たかやす あつし) オープンストリーム テクニカルコンピテンシーユニット 主管システムズアーキテクト
銀行系シンクタンクでオブジェクト指向技術の研究に携わった後,大手SI業者でアーキテクチャ構築やプロセス研究を担当。現職ではSOA(Service Oriented Architecture)を中心とする研究開発とアーキテクチャ構築に従事している