アーキテクトとステークホルダ

アーキテクトの仕事とは何かというと、「ステークホルダの観点を集約し適切なデザインをする」こと。

これはinformation architectだろうが、application architectだろうが同じ事で、デザインの対象が情報設計なのかアプリケーションの設計なのかの違いだけ。

まあ、同一のシステムを対象としてればほとんど同じなんだろうけど。

で、ある事業がコンシューマ向けのWebアプリケーションをローンチしたとして、そのアプリケーションのアーキテクトは何をしなきゃいけないのかということをちょっと整理する。

まず、「第一にアークテクチャとは何の為にあるのかということ。」を明確にすること。

それはほとんどの場合「ステークホルダの利益のため」。

時々アーキテクトの趣味をそのままアーキテクチャに反映させるだけの新規技術オタクがいるけど、それはちょっといただけない。

で、このステークホルダの洗い出しとヒアリングを繰り返して適切なデザインを提案していくのがアーキテクトの仕事になる。

ヒアリングというのは、ある程度の裁量権をもって、方針を決定する事ができる側が行う事であるから「相談」や「お伺い」ではない。

弁護士に法廷戦略について、提案されることはあっても相談される事は無いのと同じで、それだけの信頼関係が要求される。

逆にアーキテクトは、このステークホルダのなかで業務領域をよく知る人に対して十分なリスペクトをもって信頼関係を築いている必要がある。

たとえば、ステークホルダには以下のような部門が考えられる。

などなど。

それぞれのニーズや願望、展望などをヒアリングし設計を行うのだが、残念ながらそれらすべてかなえられる訳ではないし、要求していることが本当に達成したい事とも限らない。

ここで重要なのは、願望や展望から機能要求と非機能要求を見いだし、それをある程度明示的にアーキテクチャ要素に切り出していく事だ。

特に非機能要求は、明示的に要求されなかったり、横断的関心として浮かび上がってきたりする為、意識的／反復的にアーキテクチャ上の非機能要求を精査していく必要がある。

代表的な非機能要求には次のようなものがある：

などなど。

これらのことを一人で出来るのはまあ、理想的なのかもしれないが、こういった要求についても各分野のスペシャリストに委譲していくことも組織としては大事。