ソフトウエア・ファクトリーをどのように作ればよいか。その成功要因を(1)外部からのサービスの調達，(2)エンジニアの役割，(3)ファクトリーを動かすチーム，(4)ファクトリーのアーキテクチャという四つの観点から考える。

(1)外部からのサービスの調達

　即席開発では，業務部門の担当者がシステム開発の当事者となる。彼らは「どのようなサービスを外部調達できるか」を考える必要はない。必要とするサービスを要求するだけでよい。実際に外部調達をするのは，後述する「ソフトウエア・ファクトリー生産セル」である。

　例を挙げよう。業務担当者である太郎君は，次のような要求を出した。

1.旅程作成サービス：あらかじめ定めた表形式に必要事項を入力（または改訂）すると，自動的に旅程表や旅費の仮払い申請書などを作成する。

2.予約マッシュアップ・サービス：業務担当者が入力したデータを使って，インターネット経由で利用できる社外サービス（航空券の予約，ホテルの予約，レンタカーの予約など）にアクセスし，必要なすべての予約を行う。旅程の提案書の作成や料金の計算なども行う。

3.旅程異常処理サービス：予約マッシュアップ・サービスの中には，次に乗る航空便がキャンセルになったといった異常があった場合，それを予約したユーザーに知らせる機能を持つものがある。旅程異常処理サービスはこのようなときに，再登録を行うサービスである。旅程異常処理サービスは以下のような一連のプロセスをまとめて提供する。
（1）異常が発生したとき，太郎君の旅程データの中に影響がないかを調査する
（2）旅程の修正案をいくつか作成した上で，太郎君に通知する
（3）太郎君が修正案の中から一つを選ぶと，このサービスは，影響を受ける予約をキャンセルしたり更新したりする

4.旅行案内サービス：予約したホテルや，訪問しようとする顧客企業のオフィスの場所を示す地図を作成するサービス。作成した地図に関連する情報も提供する。

5.出張報告書作成および精算サービス：太郎君が帰国後に作成する必要がある，業務報告書および支払い実費報告書を作成するサービス。太郎君がデータを入力した後，社内の必要部署に送付する機能も備える。

　太郎君は，異常処理プロセスを，必ずしも一律に定義できるものではないと考えている。出張のたびに，異常処理プロセスを変更したい。このような要求に応えるために，素人でも描けるような簡単な流れ図によってプロセス定義を画面で作れるようにする。これが即席開発である。

　これらのサービスが内部で管理するデータは，それぞれ独自のスキーマ（データベースで扱うテーブル名やデータ項目の属性，テーブル同士の構造を決めた文書データ）を持ったデータベースで管理されている。また，各サービスが外部とやり取りする際に採用するプロトコルやメッセージ形式は異なることが多い。従って，各サービスのデータベースのスキーマ同士の関連をまとめた「メタデータ」や，プロトコルやメッセージ形式を変換する機能を利用して，上記の五つのサービスを統合する上位サービスを開発する。

　このようなサービス統合は，SaaSベンダーが担っていくことになるだろう。太郎君のような出張をする社員が多い企業では，SaaSベンダーに開発を委託し，年間使用契約をして利用するといった方法が考えられる。

　注意したいのは，太郎君の外国出張に関する要求がこれまで説明してきた方法で解決できたとしても，必ずしもすべてをSaaSで解決できるわけではないということだ。定型化できる業務はSOA，SaaS，Webサービスから調達可能であるが，企業の基幹業務まで外部から調達するわけにいかない。

　太郎君の会社では，自動化したい様々なビジネス・プロセスがある。それらは，アプリケーション・プログラムを開発することになる。ただし，このアプリケーション・プログラムは，さまざまな外部調達サービスやSaaSと連携しながら稼働させる必要がある。どこをサービスにしてどこを独自に開発するかを切り分けなければならない。

　どのように切り分ければよいか。今のところ，一般的な解決策は見つかっていない。これを可能にするソフトウエア・アーキテクチャを，マイクロソフトはS＋S（Software plus Service，注1）と呼んで，アーキテクチャの構想を検討している。S＋Sは，SOA，SaaS，Webサービスなどをソフトウエアと組み合わせて，ユーザーに業務を遂行するための機能を提供する考え方である。

(2)エンジニアの役割

　エンジニアは，企業の戦略や戦術，執行，情報システムの決定に参加する責任を負っている。さらに，戦略や戦術，執行を適切に支援する情報システムを企画し，ソフトウエアを開発・保守する役割を担っている（図3）。

図3●ITエンジニアの役割
図3●ITエンジニアの役割

　エンジニアは，業務の責任者が決定した事業戦略や事業運営を「プロセス・パック」を組み合わせて実現する。プロセス・パックとは，個々のビジネス・プロセスをソフトウエア・サービスとして資産化し，いつでも使えるようにした開発仕様書のようなものである。

　プロセス・パックの中には様々なものが含まれる。「対象とするビジネス・プロセスを定義したメタデータ」「プロセスを実現するのに必要なソフトウエア・コンポーネント」「コンポーネントの組み合わせ方を示したテンプレート」「プロセスに含まれるアクティビティとそのフロー」「他のプロセス・パックとデータをやり取りするためのインタフェース」などである。

　例えば「太郎君の外国出張」に必要なビジネス・プロセスは，一つのプロセス・パックである。「多くの社員が共通で必要とするビジネス・プロセスなので，社内イントラネット向けサービスの一つにしたい」と決まったとき，エンジニアは「外国出張業務支援プロセス」をプロセス･パックとして定義する。