第26回 Webアーキテクトの仕事（前編）

2008.01.17

　これまでの解説を振り返りながら，Webアーキテクトの仕事の基本的なプロセスと成果物，心得を説明します。

仕事のプロセスは3ステップ

　Webアーキテクトの仕事は，突き詰めれば「非機能要件に対する現実解を導き出すこと」です。ただし，この現実解のシステム構成や構造は，Webアーキテクトが1人で導き出すわけではありません。

　例えば，インフラ製品を提供するハードウエア・ベンダーやミドルウエア・ベンダーの担当者，もしくは特定技術分野に精通した社内外のスペシャリストから，情報提供・技術検証・導入コンサルティングなどを適宜受けることになります。また，開発プロジェクトに参加しているPMや技術者たちとも相談しながら，全体の構成と構造を考えなければなりません。

　つまりWebアーキテクトは，システムに対するステークホルダー（利害関係者）の中心となり，技術的な解決策について繰り返し対話・調整・思考する役割を担います（図1）。そのためWebアーキテクトには，技術力に加えて調整能力も必要とされるのです。

図1●Webアーキテクトはステークホルダーの中心にいる
Webアーキテクトは，Webシステムの構成やアーキテクチャを決めるうえでのリーダーである。利用者，ベンダー担当者，プロジェクト管理者，プロジェクト・メンバーといった複数の利害関係者（ステークホルダー）とコミュニケーションし，方針などを明確化する必要がある
[画像のクリックで拡大表示]

　こうしたWebアーキテクトの仕事の基本的なプロセスは，次の三つのステップで表すことができます。

ステップ1：システムの利用者や所有者が漠然と抱える機能以外の要求を抽出して整理する

ステップ2：コストや納期を考慮しながら妥当な範囲で技術的な解決策を洗い出す

ステップ3：解決策についてシステムのステークホルダーの合意を得る

以下，各ステップについて掘り下げます。

ステップ1：非機能要件を抽出して整理する

　非機能要件は，システムの利用者や所有者から明確に示されることは多くありません。漠然と伝えられたり，間接的に表明されたりすることがほとんどです。Webアーキテクトは，想像力を働かせて，言外に隠された要求を読み取ることが欠かせません。

　例えばWebシステムの所有者が，「今回のWebシステムは海外拠点の業務支援を目的に日本の本社に設置します。各国の業務時間内だけ利用できれば十分です」と説明したとしましょう。Webアーキテクトはこの説明から，「システムは止められないかも」とか，「夜間バッチによってオンライン性能が低下するかも」と思いを巡らさなければなりません。

　なぜなら，各国に時差があるからです。拠点が日米だけであれば2拠点とも業務時間外になっている時間帯があるかもしれませんが，拠点が日米欧にあるとそうした時間帯は実質的にほとんどなくなるでしょう。拠点ごとにシステムを独立させられないとすれば，このシステムは計画停止が困難になり，可用性や保守性などの要件が厳しくなります。

　Webアーキテクトはヒアリングしているとき，非機能要件に相当する内容が含まれているかもしれない，と気を配らなければなりません。ヒアリング内容を可用性や運用性などの視点でとらえ，その場で非機能要件なのかどうかを確認します。先程の「各国の業務時間内だけ利用できれば十分」という言葉は，例えば「24時間365日の無停止稼働になる」という可用性の要件や，「複数の機器を順番にアップデートさせることになる」といった運用性の要件にとらえ直します。

　このようにWebアーキテクトは，ヒアリングの対象者が何気なく口にする言葉の中から隠された要求を読み取って，非機能要件を抽出します。具体的な解決策は後から考えることになりますが，予算から考えて明らかに過大・過剰な非機能要件が挙がっている場合には，抽出段階でその旨を説明し，非機能要件の絞り込みや調整を試みるべきでしょう。また，セキュリティ要件はシステムの利用者や所有者が主体的に明示することは難しいので，考えられるリスクを具体的に示しながら，それが顕在化した場合にどう困るのかを確認しつつ要件とするかどうかを判断しましょう。

　抽出した非機能要件は，情報システムに求められる品質特性について定めた標準規格「ISO9126-1」に基づいて整理します。要件をISO9126-1の品質属性に分類することで，解決策を考えやすくなります。

ステップ2：解決策を洗い出す

　次に，整理した非機能要件ごとに解決策を洗い出します。解決策は最終的に，次のステップ3で各ステークホルダーの意見を聞きながら合意・決定しますので，この段階で一つに絞り込む必要はありません。むしろ，多様な選択肢を漏れなく洗い出すことを意識しましょう。

　解決策を考えるアプローチは複数あります。Webアーキテクトは，与えられた予算と納期を考慮しながら，いろいろなアプローチを複合的に検討し，実効性のある解決策を導き出さなければなりません。

　代表的なアプローチは，この連載で多く採り上げた“システム的”に解決策を探る方法です。「可用性」「パフォーマンス」「セキュリティ」「運用性」といった要件ごとに，要素技術や適用方法を考えていきます（表1）。一般に若い技術者はシステム的な解決策にとらわれがちですが，実際にはすべての非機能要件にシステム的な解決策を適用できるわけではありませんし，システム的な解決策の効率がよいとも限りません。

表1●非機能要件を満たすための要素技術やプロセスの例

　例えば運用性の一部として，「障害時に原因の判別や修正個所の特定が容易であること」といった要件や「稼働後の修正や変更が容易であること」といった要件を求められた場合には，要素技術やその適用方法を検討するよりも，一貫性を保ったアプリケーション構造にする方が重要になってきます。この場合には，前回「アプリケーション・アーキテクチャ」で説明したように，構造化や標準化などを徹底することが肝心です。これは，システム的な解決策というよりも，“アプリケーション的”な解決策です。

　“開発プロセス的”な解決策もあります。パフォーマンスの要件であれば，設計フェーズで「キャパシティ・プランニング」を，テスト・フェーズで「負荷テスト」を，それぞれタスクとして追加すれば，要件を満たしたかどうかを確認できます。「使いやすいシステムにしてほしい」といったユーザビリティの要件が示された場合には，設計フェーズではインタラクション・デザインやペーパー・プロトタイピングを，テスト・フェーズでは利用者による操作検証を，それぞれ実施することを考慮します。

　Webアーキテクトは，短期間で実効性を上げられるように，臨機応変に解決策を検討することが欠かせません。そのためにはシステム技術以外の技術・手法を理解することが肝要です。

ステップ3：解決策に対して合意を得る

　ステップ2で考えた解決策を各ステークホルダーに示し，どの解決策を採るのか合意・決定します。Webアーキテクトはこのとき，解決策ごとのトレードオフを十分説明しなければなりません。

　例えばAPサーバーの可用性の要件に対して，ステップ2で「HA（High Availability）クラスタリング」と「スケールアウト」の2種類の解決策を考えたとします。スケールアウトは，拡張性が高く，専用のクラスタリング・ソフトがいらないというメリットがあります。ですがサーバーの台数が増えると，APサーバー・ソフトのライセンス料がかさんでコストが上がりかねないというデメリットもあります。

　こういったメリットとデメリットをステークホルダーに十分に示し，デメリットについてはさらに解決策を考えることが重要です。例えば，ライセンス料によるコスト増大を避けるために，無償のオープンソース・ソフトを利用することが考えられます。ただしオープンソース・ソフトは，一般に商用製品と同等のサポートを期待しづらいので，ステークホルダーの意向を十分に考慮し，どの解決策をどのように組み合わせるかを調整します。

　最終的に，選択した解決策を組み合わせたとき，全体のバランスが取れているどうかを確認します。例えば図2左のような構成は，負荷が増大してサーバーを増設するたびにファイアウォールの設定を変更しなければならず，運用後に問題を起こしやすい悪い設計と言えます。Webアーキテクトは全体に与える影響に配慮しなければなりません。図2左の例は同右のように，APサーバーを増設してもファイアウォールの設定を修正しなくてよい構成にすべきでしょう。