前回，プロダクトに着目した要件，ビジネス・ルール，アプリケーションのアーキテクチャを明確にすることで，何をどう作るかということを明確にした。今回は，そのアーキテクチャに基づいて，プロセスの整備や分業体制をどうしたか，すなわちどのような手順でファクトリー化を進めたかを説明する。

【手順1】SEとBEとDEを区別する
【手順2】開発プロセスと工程と図面を関連づける
【手順3】プロダクト開発とプロダクトライン開発を分ける
【手順4】要求分析の達人を育てる

【手順1】SEとBEとDEを区別する

　BIGLOBEの情報システムを支える我々の仕事は，ソフトウエアを作るだけではなく，プロバイダとして，サービスを作って提供することである。要求者は事業部門に当たり，事業部門と共同で新しいサービスや業務を検討するというスタイルを取っている。

　サービス企画や業務プロセスを考える人たちを「ビジネス・エンジニア（BE）」，要望を要求分析しシステムとして形にする「システム・エンジニア（SE）」，実際にアプリケーションを作る要員を「開発エンジニア（DE）」と三つに分業定義をしている（図9）。こういった分業体制は，一般のユーザーを相手にシステムを開発するSIベンダーでは，難しい面があるかもしれないが，自らプロバイダ業としてサービスという製品を開発する会社においては有効な分業体制となっている。

図9●分業体制
図9●分業体制

【手順2】開発プロセスと工程と図面を関連づける

　開発プロセスは，アーキテクチャと対応して決めている。業務活動そのもの（あるいはサービス仕様そのもの）を描くことを「ビジネス・モデリング」，そこから，ビジネス・ルールを切り出し詳細までを記述することを「要求分析」，あらかじめ決めてあるアプリケーション・アーキテクチャに基づき，ビジネス・ルールをコンポーネントの組み合わせに転換することを「システム分析」，コンポーネントの具体的な動きを詳細ビジネス・ルールで実現することを「設計」「実装」としている。

　BIGLOBEはユースケースと伝票台帳を基本としたシステム・アーキテクチャを採用しているので，ビジネス・ルールをデータ項目単位で詳細まで記述すればシステムを稼働できる。だが実際には，ユースケースや状態遷移を要求分析した段階で，どのコンポーネントをどう組み合わせればトランザクション処理を実現できるかということが分かるため，要求分析も詳細になってくるとシステム分析や設計と並行して進めるようにしている（表2）。

工程 説明 分担
(1)ビジネス・モデリング ビジネスの全体像，組織や業務の種類を把握し，BPR，BPMを企画推進する。具体的に現場で生産性が向上するBPと業務フローを設計し，現場の合意を得る 主：BE
副：SE
(2)要求分析 ビジネス・ルールを見える化し，コスト，納期，機能のバランスをBEおよびDEと合意，調整しながらシステム化範囲を明らかにする（WBS，状態遷移） 主：SE
副：BE
(3)システム分析 概要設計する。ビジネス・ルールをコンポーネントでどう組むかを決定する（アクション・パターン表） 主：DE
副：SE,BE
(4)設計 詳細設計する。コンポーネント間の接続とその時のデータ・チェックや導出を詳細設計する（データ・マッピング表，データ加工表） 主：DE
副：オフショア先
(5)実装 実装する。設計情報をエンジン定義に変換する。オフショア開発コンポーネントの受入検査も含む 主：DE
副：オフショア先
(6)テスト 設計図を基にシステムテストをする。要求書を基にシステムテストをする 主：DE
副：オフショア先
(7)移行 システムのバージョンアップ作業および実業務環境に移行する 主：SE
副：BE,DE
表2●開発プロセス

　また各工程と成果物である図面類も図10のように明確に定義することで，何をもってその工程を完了とするかが明確になり，漏れや行き違いがなくなる。また，工程ごとの進捗管理上も，成果物が明確なのではっきりする。

図10●プロセス標準/作業工程と成果物の関係
図10●プロセス標準/作業工程と成果物の関係