|
[復刻版]ソフトウェア再利用ガイドブック
アーキテクチャ、プロセス、組織の変革による再利用ビジネス成功への道
ISBN4-901672-03-7 エスアイビー・アクセス
原書：Addison Wesley「Software Reuse: Architecture,Process,and
Organization for Business Success」 ISBN0201924765
I.ヤコブソン, Ｐ．ジョンソン,
Ｍ．グリス 著
落合 修, 杉本 宣男, 田中 正仁,
吉田 幸彦 訳
レターサイズ 292ページ 本体価格￥8,200 2004年6月21日発売
[内容]
IBM究極の新コンセプト、サービス指向アーキテクチャ（SOA）の源流を辿る。
巨匠Ｉ・ヤコブソンが語るソフトウェア再利用への道程 。
ソフトウェアアーキテクト必読のバイブル。
原書の翻訳書旧版は、解散した株式会社トッパンにより1999年10月5日発行されました。本書はその訳に基づき、監訳者が必要な修正を行って復刻したものです。
復刻版について―監訳者あとがきより
[目次]
序文
はじめに
第1部 再利用主導型ソフトウェア・エンジニアリング・ビジネスの導入
1.ソフトウェア再利用の成功要因
・ソフトウェア再利用は単純なアイデアである
・コンポーネントはアプリケーション開発に大革命をもたらす
・体系的なアプローチは実用的な再利用を可能にする
・Ericsson社とHewlett-Packard社の経験が再利用における共通の原理を明らかにする
・再利用のためにはプロセスの変更が必要である
・再利用には組織の変更が必要である
・再利用を体系的かつ段階的に採用する
・その他の再利用プログラム
・再利用のための原則
・要約
・さらに詳細を知りたい人のために
2.ビジネスとしての再利用主導型のソフトウェア・エンジニアリング
・再利用はあなた自身のビジネスか？
・再利用をコスト的に価値あるものにする
・再利用ビジネスはビジネス特性を持つ
・コンポーネントとアプリケーションのアーキテクチャーを設計する
・ソフトウェア・エンジニアリング・プロセス
・再利用ビジネスを創設し管理する
・要約
・さらに詳細を知りたい人のために
第2部 アーキテクチャー・スタイル
3.オブジェクト指向ソフトウェア・エンジニアリング
・ソフトウェア・エンジニアリングは要件をコードに変換する
・ソフトウェア・エンジニアリングはチーム・プロセスである
・ソフトウェア・エンジニアリングは体系的にモデルを構築することである
・オブジェクトはモデル化プロセスを統一する
・ユースケース・モデルはシステム要求を促える
・分析モデルはシステム・アーキテクチャーを決定する
・設計モデルは実装を定義する
・実装モデルはコードである
・デスト・モデルはシステムを検証する
・要約
・さらに詳細を知りたい人のために
4.アプリケーション開発者はOOSEモデル・コンポーネントを再利用することができる
・アプリケーション・ファミリーでは最大限に再利用される
・アプリケーション・システムは再利用可能コンポーネントから構築される
・コンポーネントをコンポーネント・システムに集める
・ファサードはコンポーネント・システム内部へアクセスを制御する
・ファサードとコンポーネント・システムは特別なパッケージである
・コンポーネント・システムはファサードを介してコンポーネントをエクスポートする
・再利用前のコンポーネント特化
・可変性は変形点で生じる
・何種類かの変形メカニズムを使用する
・アプリケーション・システムを構築するための可変コンポーネントの再利用
・再利用のためのコンポーネント・システムのパッケージ化と文書化
・要約
・さらに詳細を知りたい人のために
5.ユースケース・コンポーネント
・コンポーネントの再利用を確実にするためのユースケースの構造化
・ユースケース・モデルはシステムを形成する
・ユースケース・モデルを構築するためのコンポーネントの再利用
・効果的な再利用のためのユースケース・コンポーネントの設計
・ユースケースはすべて再利用可能コンポーネントであるとは限らない
・具象アクターまたは中傷アクター、およびユースケース・コンポーネントの再利用
・ユースケースの可変性表現
・ユースケース・コンポーネントのパッケージ化と文書化
・要約
・さらに詳細を知りたい人のために
6.オブジェクト・コンポーネント
・オブジェクト・モデルはシステムのアーキテクチャーと設計を定義する
・分析コンポーネントと設計コンポーネントの再利用
・オブジェクト・モデル・コンポーネントにおける可変性の表現
・オブジェクト・モデルに対するユースケース可変性の追跡
・再利用可能な分析コンポーネント
・関連するタイプとクラスをグループ化するサブシステム・コンポーネント
・再利用可能な設計および実装コンポーネント
・オブジェクト・コンポーネントと変形のパッケージ化と文書化・要約
・さらに詳細を知りたい人のために
7.レイヤー・アーキテクチャー
・アーキテクチャーはシステムの構造、インターフェース、および相互作用のパターンを定義する
・良いアーキテクチャーはシステムの完全性を保持する上で重要である
・レイヤー・アーキテクチャーはソフトウェアを汎用性に応じて組織化する
・レイヤー・アーキテクチャーによってソフトウェアの依存性は減少する
・ミドルウェア・レイヤーは分散オブジェクトコンピューティングを支援する
・ビジネス特化レイヤーはラピッド・アプリケーション開発をサポートする
・レイヤー・システム・アーキテクチャーと複数のモデルの使用
・レイヤー・システムを上位のシステムとして表す
・レイヤー・システムに関するユースケース
・アプリケーション・システムやコンポーネント・システムのアクター
・アプリケーション・システムやコンポーネント・システムのユースケース
・レガシー・システムをラッピングすることによってアーキテクチャーに適応させる
・レイヤー・システムにおける分散プロセスとノード
・要約
・さらに詳細を知りたい人のために
第3部 プロセス
8.オブジェクト指向ビジネス・エンジニアリング
・ビジネス・プロセス・エンジニアリングは劇的な改善を実現する
・ビジネス・プロセス・エンジニアリングのための明確なプロセス
・ビジネス・エンジニアリングは将来の計画としてのモデルを生み出す
・ビジネス・アクターとビジネス・ユースケースを使って、付加価値プロセスを表現する
・ワーカーとエンティティ・タイプを使って人と結果を表現する
・スキルに応じてワーカーをコンピテンス・ユニットにグループ分けする
・情報システムはビジネス・ユースケースワーカーを支援しなければならない
・要約
・さらに詳細を知りたい人のために
9.プロセスと組織を定義するためのビジネス・エンジニアリングの適用
・再利用ビジネスのプロセスと組織はアーキテクチャーと一致する
・再利用ビジネスにおけるソフトウェア・エンジニアリング・プロセス
・ワーカーをコンピテンス・ユニットに組織化する
・再利用ビジネス・プロセス間の相互作用
・要約
・さらに詳細を知りたい人のために
10.アプリケーション・ファミリー・エンジニアリング
・アプリケーション・ファミリー向けのアーキテクチャーを開発する
・ユースケースの優先順位に従って、製品計画を立てる
・AFE1:アーキテクチャーに影響を与える要件を収集する
・AFE2：分析を実行する
・AFE3：レイヤー・システムを設計する
・レイヤー・システムとしてアーキテクチャーを実装する
・AFE5：レイヤー・システムをテストする
・アーキテクチャーの変更を管理する
・ワーカーの観点から、アプリケーション・ファミリー・エンジニアリングを表現する
・アプリケーション・ファミリー・エンジニアリングへの簡略化アプローチ
・要約
・さらに詳細を知りたい人のために
11.コンポーネント・システム・エンジニアリング
・柔軟なコンポーネント・システムを構築する
・CSE1：:可変性に焦点を当てて、要件をつかむ
・CSE2：柔軟性を最大化するために分析を実施する
・CSE3：コンポーネント・システムを設計する
・CSE4：コンポーネント・システムを実装する
・CSE5：コンポーネント・システムをテストする
・CSE6：最後に、再利用のためにコンポーネント・システムをパッケージ化する
・ワーカーの観点からコンポーネント・システム・エンジニアリングを表現する
・要約
・さらに詳細を知りたい人のために
12.アプリケーション・システム・エンジニアリング
・再利用可能なコンポーネントからアプリケーション・システムを構築する
・ASE1：要件をつかむ
・ASE2：柔軟なアプリケーション･システムのための分析を実施する
・ASE3、ASE4、ASE5：アプリケーション･システムを設計し、実装し、テストする
・ASE6：単純導入のためにアプリケーション・システム･エンジニアリングを表現する
・要約
・さらに詳細を知りたい人のために
第4部 再利用ビジネスの組織化
13.再利用ビジネスへの移行
・体系的で段階的な移行はリスクをコントロールする
・段階的な移行プロセス
・TRA1：既存のソフトウェア･ビジネスを再構築するための指示書を作成する
・新たな再利用ビジネスの企画
・TRA3：既存のソフトウェア･ビジネスの解析
・TRA4：新たな再利用ビジネスのフォワード・エンジニアリング
・TRA5：再利用ビジネスの実施
・要約
・さらに詳細を知りたい人のために
14.再利用ビジネスを管理する
・たゆまない管理の継続がRSEBに決定的な意味を持つ
・測定は再利用ビジネスを管理するために重要である
・経済モデルと再利用投資への決断
・TRA6：プロセスの継続的な改善
・要員と組織の管理
・要約
・さらに詳細を知りたい人のために
15.最後に―再利用ビジネスの成功へ向けて
・再利用は位置を確立する
・再利用によりビジネス･プロセスの効率を上げる
・よくある誤解
・再利用は難しい
・ビジョンがなければ失敗する
・再利用はアーキテクチャーに依存する
・マネジメントは組織を通じて機能する
・再利用ビジネスは投資に対して利益を生まなければならない
・ソフトウェア･エンジニアリングはプロセスに依存する
・オブジェクト技術はプロセスを支える
・ビジネス･エンジニアリング：ビジネス・モデルをオーバーホールする
・要約
・さらに詳細を知りたい人のために
第5部 付録
A.用語集
B.注釈付き参考文献
・体系的ソフトウェア再利用
・オブジェクト指向技術
・アーキテクチャーとパターン
・ソフトウェア･エンジニアリング
・ビジネス・プロセス・リエンジニアリングと組織的な変更管理
C.RSEBでのUMLの使用
・統一モデリング用語の使用
・UMLタイプ、クラス、およびステレオタイプ
・汎用RSEB構成体
・情報システムのユースケース･モデル
・情報システムの分析モデル
・情報システムの設計モデル
・ビジネス・ユースケース・モデル
・ビジネス・オブジェクト・モデル
D.参照文献 索引 監訳者あとがき[旧版]
監訳者あとがき―復刻版の出版に寄せて ◆◆◆◆◆◆◆◆
［復刻版について（監訳者あとがきより）］
監訳者らは、日本アイ・ビー・エム株式会社に在籍し、情報システムのコンサルテーションやシステム開発ビジネスの最前線に従事するエンジニアである。
1999年10月、「ソフトウェア再利用ガイドブック」の初版が出版された頃、偏狭なソフトウェア再利用論の中で、体系的なソフトウェア再利用を、アーキテクチャー、プロセス、組織の変革による再利用ビジネスと位置づけたI.
Jacobsonをはじめとした著者らの洞察に大きな動機づけを与えられたことを、記憶している。
初版の出版以来、ソフトウェア開発の現場で、いくつかの実践的なアプローチを試行してきたが、その中での個人的なトピックの一つは、設計パターンやアーキテクチャー・パターンの再利用を“one
of a
kind”のシステム開発プロジェクトに適用し、生産性や品質において大きな改善を得たことである。本書に述べられているような体系的なアプローチの中で、そのアーキテクチャーの部分に注力したことになると思うが、パターン適用プロセスの部分にも配慮することにより、前記のような効果が得られたと思う。プロセスの重要性を再認識した次第である。
パターンに関しては、建築物の設計にパターン言語を使用するC.
Alexanderのアイディアのアナロジーが有名であるが、私自身は、10年以上前に、ある金融機関アプリケーションで使用した人工知能領域の推論手法の一つである事例ベース推論に大きなアナロジーを感じる。事例ベース推論は、ill-structuredな問題を解決するために、well-definedな過去事例である事例ベースとのパターン・マッチングにより事例を高速に検索し、現実の問題と検索された事例との差分を分析し、最適な解へとチューニングしていく。この過程はアダプテーションと呼ばれている。Reusable
Asset Specification（RAS）やAsset-based Development（ABD）、Model-driven
Architecture（MDA）のような最近の動向の中で、このアダプテーションのプロセスがどのように位置づけられるのかに強い関心を持っている。
もう一つのトピックは、個人的にはIBM社のRational
Software社買収である。本書の多くの部分が組み込まれたラショナル統一プロセス（RUP: Rational Unified
Process)を、自社のプロセス製品としてビジネスに利用できるようになったことである。必ずしも再利用のためのプロセスがすべて定義されているわけではないが、再利用プロセスを応用問題として実装するには十分な基盤プロセスである。再利用ビジネスを構成する、アーキテクチャー、プロセス、組織の変革など本書の理論を実践する道具立ては整い、ビジネスへの動機づけ十分な今日この頃である。
今回の復刻版は、エスアイビー・アクセスの富澤社長にお願いしたところ、快諾いただき実現できたものであり、感謝の極みである。
杉本宣男
日本アイ・ビー・エムシステムズ・エンジニアリング株式会社
◆◆◆◆◆◆◆◆
第4部で参照されているソフトウェア製品は原著の初版が出版された時点の動向に基づき述べられており、10年近い歳月を経て再評価の必要性が認められるが、本書の本質的部分を損なうものではない。該当部分は、主に第13章6節および第14章1節であり必要に応じて適切な文献を参照されたい。
10年近い歳月とは変化の激しいIT業界においては一時代を画するに足る期間である。この間に、PriseWaterhouse社はIBM社の強力なコンサルティング部門としてIBM
Business Consulting Service株式会社と改名しており、Rational
Software社はIBM社のソフトウェア事業を牽引する主要ブランドとしての位置を築いている。
また、この間の動きとしてEnterprise Architecture（EA）が再利用主導型組織の構築や再利用の組織的実践に関連した動きとして見逃せない。日本でもEAは注目を集め、取り組み始めた企業もでてきているが、その萌芽は1987年にJ.
ZachmanによってIBM Systems Journal誌で提案された「Zachmanモデル」に遡り、現在にいたるまで発展を続けている。
EAは、企業などの組織体全体の活動やITシステムをビジネス、アプリケーション、データ、テクノロジーの各アーキテクチャーの視点でモデリングするとともに、従うべき原則・標準、それらを管理・統制さらに発展させるプロセスを定義したものである。個々のプロジェクトの最適化に囚われずに組織体全体の最適化を目指している点、ITシステム・モデルにより可視化を図っている点、投資決断への説明責任を果たす視点、あるべき組織体とそのITシステム・モデルを定義して移行計画を重視する点、などにおいて再利用主導型組織およびプロセスを構築するにあたりその手法には参考にすべき点は多い。詳細については次に参考文献をあげるにとどめさせていただくが、再利用主導型組織の構築を目指す方々にとって有益な情報となれば幸いである。
［1］J.A. Zachman, “A Framework for Information Systems Architecture,” IBM
Systems Journal, Vol 26, No 3, 1987, G321-5298
［2］日経コンピューター/ITプロフェッショナル編、「EA大全~概念から導入まで」、日経BP社、2004.05、ISBN4-8222-0791-9
［3］“TOGAF (The Open Group Architecture Framework)”、The Open Group、http://www.opengroup.org/architecture/togaf/、2004.05.31
［4］「ITアソシエイト協議会報告書」、経済産業省、http://www. meti.go.jp/policy/it_policy/itasociate/it.associate.htm、2004.05.31
［5］日本IBM編、「特集エンタープライズ・アーキテクチャ」、ProVISION, No.41、Vol11、No.2、Spring 2004
［6］日本IBMビジネス・コンサルティング・サービス・IT戦略グループ編、「エンタープライズ・アーキテクチャ」、日経BP社、2004.01、ISBN4-8222-1873-2
吉田幸彦
日本アイ・ビー・エムシステムズ・エンジニアリング株式会社
◆◆◆◆◆◆◆◆
本書の初版本が出版されたのは1999年10月である。その当時、私は、IBM SanFranciscoフレームワークの技術支援を実施しており、その内容を初版の「あとがき」に紹介した。翌年の2000年にIBM
SanFrancisco技術支援を離れ、それ以降、現在まで、Webに代表されるE-ビジネス・アプリケーション開発プロジェクトにアーキテクトとして参画し、技術支援を実施している。
この間、IT業界では、いろいろなことが起きた。私にとって、最も影響力のあった出来事は、Javaオープン・ソースの隆盛である。ApacheプロジェクトやJakartaプロジェクトに代表される組織から、各種のオープン・ソースが公開されている。現在では、多くのアプリケーション開発プロジェクトに適用され、アプリケーションに欠くことができない解決策となっている。お客様向けのアプリケーションの開発に使われるだけではなく、その基盤となる環境（J2EEアプリケーション・サーバの実装など）にも利用されている。そのような潮流に乗って、私は、お客様のプロジェクトをいくつか支援するにあたり、オープン・ソースの適用を提案し、プロトタイプを開発し、デモや検証を実施し、オープン・ソース・ソリューションの優位性を訴えてきた。振り返って、このようにオープン・ソースに支えられて稼動しているシステムの安定性や開発期間、開発工数について検証してみると、オープン・ソースによる「ソフトウェア再利用」の正しさが証明される。
再利用できるものは「コード」だけではない。デザイン・パターンやアーキテクチャー・パターンも再利用の対象である。プロジェクトでのオープン・ソースの適用の経験について書いたが、実際には、プロジェクトでは、オープン・ソース単体で利用するのではなく、オープン・ソースのAPI層の上に一つ、二つの層を置いて、より使いやすいフレームワークや階層化アーキテクチャーを設計し、実装してきた。そして、このようにコードも設計も含めた成果物を、お客様の複数のプロジェクトに再利用し、プロジェクトを成功させてきた。IT業界では、現在、成果物を再利用する仕組みのための標準仕様に向けて、RASコンソーシアムが作られ、OMGにRASを提起している。さらに、デザイン・パターンやアーキテクチャー・パターンの再利用が可能となる統合開発環境も現れている。Eclipseベースの開発環境がいろいろと製品化され、統一的な開発環境の下で、アプリケーション開発のライフサイクルの全域が網羅されるようになった。このように、再利用の仕組みや仕様、およびツールの面でも、再利用を支える基盤が整備されてきている。今、ABDが注目されるいるが、これを活用してプロジェクトを実践し、結果をフィードバックして、より良い再利用環境の構築に貢献していきたい。ご参考までに関連Webサイトを挙げておこう。
［参照先サイト］
http://www.eclipse.org/
http://www.omg.org/
http://www.omg.org/mda/
http://www.apache.org
http://jakarta.apache.org/
落合修
日本アイ・ビー・エムシステムズ・エンジニアリング株式会社
◆◆◆◆◆◆◆◆
ソフトウェア再利用の考え方や技術について本書が出版された1997年と現在とを比較してみると、中身の洗練はあったものの全体としてはそれほど大きな変化がなかったように感じられる。どちらかと言うと、ここ数年間は当時の考え方をもとに、再利用をいかに実践しそれを継続性のあるものにするかといったことのほうに努力が向けられてきた。
しかし、それらの多くの努力にも拘らず、日本におけるソフトウェア開発組織の中で、再利用を組織的に実践しその効果を享受できているところは極めて少ないのではなかろうか。訳者は、企業におけるソフトウェア開発のコンサルティングを数多く手がけてきたが、その経験から、再利用がうまくいかないのは開発組織の変革をうまく成し遂げられないことに根本的な原因があると考えている。
本書の後半でも詳しく触れられているが、再利用を開発組織の中で成功させるには、技術的な面よりもむしろ再利用のプロセスをうまく回すことのできる組織をいかに作り上げるかが重要になってくる。再利用がうまくいっていない企業では、UML、コンポーネント、ツールといった技術面ばかりに力が入り、現状の組織や仕事のプロセスをできるだけいじらないで再利用を実現しようとしている。もっとも、技術者中心の開発組織では、組織を変革する、いわゆるビジネス・プロセス・リエンジニアリング（BPR）の発想がなかなか出てこないのも事実である。
これを打破するには、ボトムアップではなく上位のマネージメントが強力なリーダーシップを発揮してトップダウンで変革プロジェクトを実行すべきである。企業として、ソフトウェアの再利用を行う目的や狙い、アーキテクチャーを明らかにした上で、それを実現するあるべきプロセスや組織を定義する。そして、現状をあるべき姿に変えるための実行計画を策定し、それを一気呵成に遂行していく。このやり方は、ソフトウェアの再利用を成功に導くためにはなくてはならないものであり、まさに本書で強調したいことの一つでもある。特に、ソフトウェアの再利用がうまくいっていない企業のマネージメントは、本書を熟読し再チャレンジしていただきたい。
田中正仁
IBMビジネスコンサルティングサービス株式会社 
|
