BIGLOBEのファクトリー化には，最初から具体的なシナリオがあったわけではない。最終ゴールとして，ラインでいろいろなサービスやシステムを大量に作る体制や，ノンプログラミングかつ組み立て式で開発しているイメージはあったが，実際に事業活動をする取り組みの過程で，今の形が出来上がってきた。今回は，そういった過去の取り組みの歴史と，実際現場を運営するにあたっての現実問題について説明する。
最初からSOAだった
BIGLOBEは，PC-VANというパソコン通信サービスとmeshというインターネット接続サービスを統合して立ち上げた。既にある会員管理システムや課金請求システムとWebのシステムをつなぐということが必要となった。
問題となったのが，どういう機能分担で，どういうインタフェースでつなげば，うまくいくだろうかということだった。Webサイトを担当している部門は多数あり，個々の部門から「会員情報のこれが欲しい」「これを登録したい」といった要望が次々に上がっていた。
しかも「あまり機能レベルの低いAPIを提供されても，Webサイトを開発する要員には分からないので，なるべく単純にしてほしい」という要望もあった。それら要望を満たした結果，1トランザクション粒度のAPIをコマンド・インタフェースで提供し，各Webサーバーに提供するという方式が望ましいと考えた。そういったAPIを実現するには，個別のWebサイトの仕様に依存しない共通性と，類似の機能を別々のAPIにしないという汎用性を持たせる必要性があった。
つまりSOAで最も重要なサービス・インタフェースでつなぐということが，Webサイトというフロントと会員管理などの基幹システムの間で自然と出来上がっていたわけである。
ハブができ，ESBに進化した
複数のチームと多数の具体的案件を通していろいろなリクエストが来る中で，トランザクション処理をAPIでWebサイトに提供すると，やはりサイトの目的ごとに若干違う部分があり，どうしても少しカスタマイズした版を出さざる得ないケースが増えてきた。ただ，類似のAPIを実現するのにコールしている下位のAPI（M層のAPI）は同じものを使っている。コールする順番もほぼ同じケースが多いということが分かってきた。
そこで次に考えたのが，このM層のAPIを使ってトランザクション処理のAPIを作るのに，個別のWebサーバー上に作るのではなく，大規模なハブを設置して，そこで作れば便利だし，スケーラビリティもあるということである。
さらに，M層APIを組み立てるのに，プログラミング言語を使うほど複雑なことをしていないということが分かってきた。限られたルールを使い，組み立て式でトランザクション処理が作れるということである。その結果できたのが，ビジネス・ルール・エンジンとシナリオという簡易定義言語だった。このようにして，今で言うアプリケーション・アーキテクチャとESBが完成した（図14）。
 |
| 図14●フロントとバックの分業体制から生まれたESB |
分業体制ができてきた
このようにESB（ハブ，ビジネス・ルール・エンジン，開発ツールなど）を作る過程で，全体コンセプトや方式，フレームワーク，エンジンを専門に開発するチームが必要になった。このチームは，実際の開発案件に関与しながら，現場で使う方式やエンジン，フレームワークを徐々に開発する。
その過程で，単なる共通化チームではなく，新しい開発方法と実際に動く基盤や部品を作っていくというミッションに変化していった。彼らは，案件対応と別チームではあるが，案件対応には参加し，納期にコミットメントしながらプロダクトラインをブラッシュアップするというチームとなったのである。
