目的と要件の整理でアーキテクチャは見える：現場から見るSEの「地力」（3/3 ページ）

[杉山正二（アールエスコンポーネンツ），ITmedia]

教訓7：ビジネス要件を整理／グルーピングし、アーキテクチャ決定のInputにせよ。

　ただ漠然とアプリケーションの要件や求められる機能を検討していても駄目であり、今回のように、要件や機能をグルーピングすることで、それぞれアーキテクチャ決定の核となるものが見えてくる。

教訓8：システム開発の費用対効果を明確にさせ、導入後、それをモニターせよ。

　効果実現の責任は、本来オーナーであるユーザー側の責任者にあるはずである。このあたりを明確にした上で、ユーザー側責任者を巻き込めば、意思決定も容易になる。もし、それでもユーザー側責任者がオーナーシップをもたないようであれば、責任者失格なので、上長に掛け合うなどの強硬手段しかないかもしれない。

　2回に渡って、弊社のシステム開発の例を基に、いろいろな教訓を紹介してきたが、皆さんのお役に立ったであろうか？　次回は、今回の教訓でも出てきた、ユーザー部門の責任者とのコミュニケーションについてお話したい。

杉山 正二