開発するシステムのアーキテクチャや粒度の規定，図面など標準の整備をどのように進めたのか。今回はその過程を説明する。
実際には，これから説明するようなきれいな概念が初めから分かっていたわけではない。振り返ると何となくこういったことを行ったり来たりしながらやっていたということで，整理している。
多くのソフトウエア開発の現場では，そういったことをSE個人やチームで検討して決めている。BIGLOBEでは，これを組織単位で検討して決めることにした。検討して決めたファクトリーの五つの構造を説明する。
【構造1】四つのアーキテクチャ領域に分ける
【構造2】領域ごとにモデル化する
【構造3】ユースケースをうまく使う
【構造4】ビジネス・ルールの記述方法を決める
【構造5】要件定義をモデル化する
【構造1】四つのアーキテクチャ領域に分ける
システム開発をファクトリー化するために必要な問題領域を，図のように四つのアーキテクチャに分離した（図2）。分離することによって，各領域をそれぞれ独立して高度化させられるようになることを意図した。「業務活動」「ビジネス・ルール」「アプリケーション」「IT/NW」と呼んでいる。一般にいわれているEA（Enterprise Architecture）と同じレイヤー構造である。
 |
| 図2●四つのアーキテクチャ領域 |
四つのアーキテクチャ領域は，それぞれ下記のような役割を持つ。
(1)業務活動：業務活動そのものを記述する。
(2)ビジネス・ルール：業務活動から見たシステムへのユースケースと画面の動き，トランザクション処理の動き，それを管理する伝票や台帳（データ・モデル）を記述する。
(3)アプリケーション：ビジネス・ルールを実現する実装する。また可用性，拡張性，セキュリティなどの非機能要件も実現する。
(4)IT/NW：サーバー，ネットワーク，ストレージ，データベースなどアプリケーションを稼働する。
また，業務活動とビジネス・ルールの関係を明確にし，開発プロセスや図面標準の関係が単純になるよう工夫した。特に業務活動領域とビジネス・ルール領域の関係は，通常仕様を書くときに，よく混同して書いてしまうので，ここをシンプルにしたことが非常に重要だった。
【構造2】領域ごとにモデル化する
四つの領域における要件をどのように記述すれば，余計なものも不足もなくシンプルに記述できるかを考えた。そこで分かってきたのが，最終的に明確にすべきは，システムの業務要件（ビジネス・ルール）だということである。
業務活動領域は，システムと直接関係しないものが多い。システム稼働後に業務フローや利用部門，使い方や入力する内容の変更が頻繁に発生する領域でもある。しかも，必ずしもシステム要件の変更を必要とはしない。業務活動領域の分析は，ビジネス・ルール領域を要件確定させるには必要なものだが，その後システムとは関係なく変化する領域でもあるわけである。
つまり「業務活動領域の要件は，ビジネス・ルールをつかむ上では必要。しかし，業務活動領域の要件の中には，業務フローや利用する部門，使い方など変わるものも少なくない。変わるものも含めて記述してしまうと複雑になってしまうので，ビジネス・ルールに特化した記述ができるような図にしよう」と考えた。
アプリケーション領域は，プログラム実装への変換作業を最小化し，ビジネス・ルールを記述するだけで，そのまま動作する仕組みを実現できないかと考えた。さらに性能，可用性，拡張性，セキュリティをあらかじめ標準化したアプリケーション・アーキテクチャで実現できるようにも考えた。SEがビジネス・ルールを分析することに集中するだけで，システムが作れることを目指したのである。
IT/NW領域は，最新のIT/NW技術を駆使する。サーバー，ネットワーク，ストレージ構成が日々進歩し提供される領域である。
