アプリテック株式会社
Copyright © 1995-2008 by AppliTech, Inc. All Rights Reserved.
ここまでは、生産管理や販売管理などのビジネス分野の業務プログラムに的を絞って、実用的で効果的な部品化再利用システムとはどのようなものなのかを論じてきた。 この章では、適用分野を限定せずに一般化して、実用的で効果的な部品化再利用システムとはどのようなものなのかを探求する。
ソフトウェア開発を経験された方々の一部には、ソフトウェア部品 (ビジネスロジック部品を一般化したものをこう呼ぶことにする) への強い不信感がある。 その背景には、ソフトウェア部品に対する大きな期待が多くの人の心に秘められていたのに、その期待を裏切られたり、あるいは部品化の試みがうまくいかなかったりしたからだろう。 こうした経験から、不信感が募っていったのだと思う。
部品化再利用システムの一般化した構成法を追求していくと、それを効果的なシステムにすることは金鉱を掘り当てるように難しいことが分かってくる。 したがって、これまで実現できなかったり、不可能だとみなされたりしたのも無理のないことである。 そして、SSS (トリプルエス) の研究開発において、金鉱への突破口を開くことができたのは、非常に幸運であったと思えてくる。
このことが分かるように、それからまとめの意味を込めて、この章では、部品化再利用システムの一般化した構成法に関する少しばかり抽象的な理論を展開する。 そして、第３章で述べた‘ビジネスロジック部品’の具体例 RRR ファミリーをこの理論に照らしてみる。
これまでにも小粒の汎用サブルーチンやら大粒の業務パッケージとして、ソフトウェアの部品化再利用は実施されてきた。 また、大抵のソフトウェア資産に対して個人ベースでの部品化再利用は盛んに行われてきた。 このように部品化再利用は実施されているのだという認識に立った上で、もっと効果を上げることのできるシステムにするには、どのような部品化再利用システムであるべきなのかを探ると、次の三つの要件が浮かび上がってくる。
・ 部品を組み合わせるだけでソフトウェア製品ができあがるものであること
(汎用サブルーチンと同様に可能ならば再利用するというだけでは適用範囲が狭い)
・ どんなカスタマイズ要求にも対応できるものであること
(通常の業務パッケージと同様のあらかじめ想定された要求への対応だけでは不十分)
・ 大勢の開発者が組織的に部品化再利用の恩恵にあずかれるものであること
(部品化再利用を従来と同様に個人ベースで行うだけでは大きな効果は得られない)
これら三つの要件を満たすことの意義とこれらの要件を満たすことの難しさなどは、これから一つ一つ説明していく。 これらの説明を読んだ後に、もしもこれらすべての要件を満たすことができれば、多くの人々の期待に応える部品化再利用システムになると言えるかどうかをご判断いただくようにお願いする。
ビジネス分野の業務プログラム向けのライブラリ整備に熱心な経験者の話では、汎用サブルーチンは 400 個ぐらい取り揃えると飽和してしまい、それ以上追加しても追加分は極めてまれにしか使われないとのこと。 そして、プログラムコードの 4 割を汎用サブルーチンでまかなうことを目標にしているが、なかなか到達できないとのことである。まとまりをもつ汎用機能の抽出というサブルーチン化には限界があるようである。
一般に汎用サブルーチンを単に組み合わせるだけでは、思いどおりの業務アプリケーションプログラムにはならないことは、多くの人々が経験するところであり、この点に部品化の限界を感じる方も多いことだろう。
汎用サブルーチン (およびその組込み呼出し機構) という一種の部品化再利用システムを乗り越えるには、部品でカバーできる割合をもっと大きくしたくなる。 そこで、望ましい部品化再利用システムの要件その１は、適切な部品が見つかれば使うという消極的なレベルを超えるために、部品を組み合わせるだけでソフトウェア製品ができあがるものであることだと考えるべきである。 つまり、業務プログラムのプログラムコードを 100 ％部品で (すなわち部品だけで) 構成しようというのである。
この要件を満たすことの難しさは、これに挑戦した事例がほとんど報告されていないことをみても、くどくどと説明する必要はないだろう。 この要件は厳しすぎるので、実現不可能な目標だと考える人もいるほどである。
しかし、部品と呼べないような悪貨が混入しているので、部品化可能な部分までも悪貨による悪影響で再利用がしにくくなっていると考えることもできる。 悪貨を取り除くなどして、ぜひともこの要件を実現させたいものである。
あらかじめ想定されたカスタマイズ要求への対応だけでよければ、業務パッケージを開発して、パラメタカスタマイズで対応するのが一番である。 業務パッケージとは、ソフトウェアを製品という単位、すなわち“部品 ＝ 製品”と考えて、部品化再利用を行うシステムだといえる。
業務パッケージという部品化再利用システムを乗り越えるには、特注業務プログラムのようにどんな要求にも対応できるようにしたくなる。 そこで、望ましい部品化再利用システムの要件その２は、あらかじめ想定されたカスタマイズ要求だけでなく、どんなカスタマイズ要求にも対応できるものであることだと考えるべきである。 つまり、特注業務プログラムを開発できるような部品化再利用システムを目指すことにするのである。
この要件を満たすことの難しさは、創適応の必要性 (注10) という概念を使うと簡単に説明できる。 ひとまずこの言葉の説明は後にして、とりあえず論旨だけを先に言うと、ビジネス分野は創適応の必要性が大きいので、新たなプログラムを創造して解決すること、すなわちプログラムカスタマイズが必要になるために、この要件を満たすことは難しいのである。
注10： 創適応は、創造的適応 (creative adaptation) を省略した言葉である。
創適応とは、ある応用分野または領域に関するいろいろな要求に対応する際に、用意されたパラメタの設定という非創造的な手段ではうまくいかず、新たなプログラムを創造して対処することを意味する。
創適応の必要性が小さい領域ではパラメタカスタマイズによって要求に対応できるが、創適応の必要性が大きい領域はそうはいかず、新たなプログラムを創造して適応させることが、すなわちプログラムカスタマイズが必要になる。
なお、ここでパラメタとは、パラメタカスタマイズのパラメタと同様に、外部からみて意味の明快な宣言的な情報のことを意味する。
業務パッケージを調べると、どの業種のどのような業務向けかによって、そのカスタマイズ要求がバラエティに富むものであったり、そうでなかったりという差があることが分かる。 たとえば、財務会計には遵守すべき法律の規定という制約があるので、カスタマイズ要求の種類も限られるが、生産管理は自由競争の世界で様々な可能性を追求するためか、カスタマイズ要求もバラエティに富む。
なお、こういったことに関係した話題として ｢１．１ 特注業務プログラムと業務パッケージの違い｣ の中の ｢トピック 1： 金の卵を生む業務パッケージへの夢｣ の内容を思い出していただきたい。
適応のしやすさの差を単純に捉らえると、次のような誤解が生じるかもしれない。すなわちカスタマイズ要求がバラエティに富むような応用分野に対しても、パラメタの数さえ増やせばパラメタカスタマイズで十分に対応できるものだと。 しかし、そのように単純に考えてよいかどうかは、その応用分野の創適応の必要性によって決まる。 創適応の必要性が大きいと、いくらパラメタを追加してもきりがないことになる。 誇張した表現をすると、新たな顧客（企業）との出会いがある度に新たなカスタマイズ要求が発生してくることだろう。しかも、その新たな要求はどんなものか想像がつかないのである。
したがって、カスタマイズ要求がバラエティに富むかどうかによって、それに対応するためのパラメタの数がたくさん必要であったり、少なくても構わなかったりというように単純にはかたづかないのである。 むしろそうした違いを発生させる根源的な性質に目を向けることで、その応用分野の創適応の必要性が大きいか小さいかを問題にしなければならなくなる。 ちなみに、ビジネス分野の業務プログラムの多くが業務パッケージではなく特注業務プログラムとして開発されていたし、いまだにそのように開発されているのは、ビジネス分野は基本的に創適応の必要性が大きいためだと言える。
個人的な部品化再利用は、自然発生的になされるものである。 画家の中には、あらかじめ花や鳥のスケッチを描いておき、本格的な絵を描くときにはそのスケッチ集を参照する人もいるし、その時の記憶をよみがえらせる人もいる。 ソフトウェアの開発においても、仕様書やプログラムコードなどあらゆるソフトウェア資産に対して、個人ベースの部品化再利用はごく普通に行われている。
このような部品化再利用の実態を踏まえて、個人ベースのいわば１本のパイプから得られる部品化再利用の恩恵よりも、もっと多くを得ようとすると、効果を得るためのパイプの数を増やしたくなる。 そこで、望ましい部品化再利用システムの要件その３は、個人ベースで得られる恩恵だけでなく、大勢の開発者が組織的に部品化再利用の恩恵にあずかれるものであることだと考えるべきである。
この要件は、ビジネスロジック部品を開発する人とそれを再利用する人 (たとえば、特注対応業務パッケージを開発する人と部品カスタマイズを施す人) が別でもよいことを保証するものであり、この要件が満たされればこのような分業化が可能になる。 つまり、これは、特注対応業務パッケージのカスタマイズを大勢の開発者が実施できるようにするための重要な要件なのである。
この要件を満たすには、次のような難しさがある。
大勢の開発者が組織的に部品化再利用を始めようとすると、ソースプログラムコードに関する面倒な解読作業が大きな問題になる。 まず解読すべきモジュールを探す際にプログラムと仕様との対応関係が複雑であったり、開発者の気ままなモジュール分割に出くわしたりして、解読すべきか個所を見つけ出すまで一苦労である。 そして、解読を始めるとプログラムそのものがスパゲッティ状態で暗号解読の様相を呈したり、解読が進むにつれて解読すべき範囲がズルズルと増えたり、などなどの困難が付きまとう。 一般に、他人の開発したソースプログラムコードを再利用するのは一筋縄ではいかない。 この問題の解決をせまられることになる。
ここまで、実用的で効果的な部品化再利用システムにするための三つの要件について詳細に説明してきた (これを示した図5-1 参照)。
・ 部品を組み合わせるだけでソフトウェア製品ができあがるものであること
・ どんなカスタマイズ要求にも対応できるものであること
・ 大勢の開発者が組織的に部品化再利用の恩恵にあずかれるものであること
図5-1: 実用的で効果的な部品化再利用システムにするための三つの要件
これまでの説明によって、この三つの要件のすべてを満たすことができれば実用的で効果的な部品化再利用システムになると判断していただけたことと思う。 そして、このシステムによってビジネス分野の特注業務プログラム開発業界や業務パッケージ開発業界を根本から合理化できそうである。 しかし、そうするのは相当な難問を解決しなければならないことがお分かりいただけたと思う。
三つのうちのその１の要件、すなわち部品を組み合わせるだけでソフトウェア製品ができあがるものであることという要件を満たすには、ビジネスロジック部品とは何かという見直しが必要である。 なぜなら、汎用サブルーチンがカバーしているのは創適応の必要性が小さい領域だけであり、これだけではビジネス分野の業務プログラムを構成できないからである。
そこで、何種類かの“部品”を組み合わせて用いることで、ソフトウェア製品を構成することを考えなくてはならない。 そして、創適応の必要性が大きい領域をカバーするために、新種の‘ビジネスロジック部品’を登場させることが必要になるのである。 いわば、ハードディスクの中に形をなしていなかった‘ビジネスロジック部品’の形を整え、表舞台に引きずり出すことによって、各種の‘ソフトウェア部品’オールキャストの登場が求められるのである。
三つのうちのその２とその３の要件、すなわちどんなカスタマイズ要求にも対応できるものであることと大勢の開発者が組織的に部品化再利用の恩恵にあずかれるものであることという要件については、どちらか一方を満たすだけの方法ならば比較的に簡単にみつかることだろう。 しかし、これらを両立させるのは非常に難しい。 なぜなら、この問題を整理すると、以下に説明するように ｢あちらが立てばこちらが立たず、こちらが立てばあちらがたたず｣ という関係になるからである。
大勢の開発者による組織的な部品化再利用を目指すと、プログラムを解読しなくても再利用ができるようにすることが必要だという考えに傾く。 しかし、もしもこうすると、業務パッケージをパラメタカスタマイズするのと同程度のことしかできなくなる。 したがって、あらかじめ想定したカスタマイズ要求だけにしか対応できなくなってしまう。
どんなカスタマイズ要求にも対応できるものであることを目指すと、どうしてもプログラムの解読が必要になる局面が現れる。 そして、大勢の開発者による組織的な部品化再利用に支障をきたすことになりそうである。
実用的で効果的な部品化再利用システムにするための三つのうちのその２の要件に関係する重要事項があるので、それをここで説明しておこう。
業務パッケージがカバーする領域の創適応の必要性と同様に、汎用サブルーチンがカバーする領域の創適応の必要性に関しても同様の議論を展開できる。 つまり、カスタマイズ要求への対応のしやすさは、業務パッケージの場合その応用分野全体にわたる創適応の必要性に依存するが、これと同様に汎用サブルーチンの場合はそれがカバーする問題領域の創適応の必要性に依存する。 両者は、領域そのものの大きさに違いがあるにもかかわらず、その内容は全く同じである。 ここで同じ説明を繰り返す必要はないだろう。
ここでお話したいのは、少し観点を変えて、汎用サブルーチンがカバーする領域に関する重要事項である。 すなわち、｢汎用サブルーチンを単に組み合わせるだけでは思いどおりの業務アプリケーションプログラムにはならない｣ と言われているが、なぜそうなのかという理由を説明しよう。
汎用サブルーチンではなく、一般のサブルーチンについて考えてみると、サブルーチンを作ってそれらを組み合わせることによって、思いどおりの業務アプリケーションプログラムを構成することができる。 したがって汎用サブルーチンと一般のサブルーチンには、何らかの違いがあるはずである。 そこで、何が違うのかを考えながら、以下を読んでいただくと、理解が深まることだろう。
あるサブルーチンを提供してユーザに使ってもらうと、いろいろな機能追加要求が出されることがある。 そういった要求を満たすために、新たなサブルーチンを作成して一式のサブルーチンセットにすることがある。 たとえば、外税計算サブルーチンしかないところに内税計算サブルーチンを追加すれば、今まで以上のカバー範囲になる。 また、最初から外税計算と内税計算があることが分かっていれば、消費税計算サブルーチンにパラメタを設けて外税と内税の両方に対応できるようにするのも良いだろう。
いずれにしても (サブルーチンセットで対処するにしろ、パラメタで対処するにしろ)、サブルーチンがカバーする領域というものが、たとえば消費税計算という領域をカバーするというような具合に、厳然として存在する。
サブルーチンを開発して提供すると、その領域をきちんとカバーしているかどうかが問われる。 きちんとしていないと、そのサブルーチンのユーザはカバーの程度が不十分だと言い出すことだろう。 そして、そのサブルーチンに対して、たとえば簡易課税を選択した場合の消費税計算も可能にしてくれというように要求を出してくるかもしれない。 消費税計算という領域は創適応の必要性が小さい方なので要求も限られている。 しかし、創適応の必要性が大きい領域をカバー範囲にしたサブルーチンの場合には、次から次へと際限なく要求が出されてくるかもしれない。 こうしたやっかいな問題が発生することになるのである。 こうなると、事態を収拾するには、その都度そのサブルーチンに手を入れるか、またはそのソースプログラムを要求元のユーザに渡して、｢勝手に直して使ってください｣ と頼むしかなくなる。 つまり、プログラムカスタマイズに切り換えざるを得なくなるものだ。
このような状態に陥ると､「サブルーチンの設計が悪い」とその開発者は非難をあびせられる。 したがって、サブルーチンの開発者は、創適応の必要性が小さい領域を慎重に選んで、そういう領域だけをカバー範囲にした開発をすることになる。 つまり、サブルーチンセットとパラメタの組合せというパラメタカスタマイズ的な手段で、その領域を隅から隅までカバーすることを目指すことになるものだ。 実際に、創適応の必要性が小さい領域をうまく切り出すことができ、かつその領域に関する知識や経験が十分にあれば、その領域をくまなくカバーすることが可能である (注11)。 こうできれば、後からプログラムカスタマイズに切り換えなければならないというような屈辱を受けることはない。 つまり、際限のない要求に悩まされることはないのである。 しかし、そうではなく、もしも創適応の必要性が大きい領域をカバー範囲にすると、数多くのパラメタを用意して、上手に設計したとしても、パラメタの設定ではカバーできないユーザ要求が発生してくる可能性が高いのである。
こういうわけで、サブルーチンの中でも特に汎用サブルーチンについては、そのカバー範囲は、創適応の必要性が小さい領域だけであり、創適応の必要性が大きい領域は、汎用サブルーチンのカバー範囲から外されて手つかずのまま残ることになる。
言い換えると、このことは、汎用サブルーチンだけではカバーできない領域が存在することを意味する。 これは、多くの人々が経験するところの ｢汎用サブルーチンを単に組み合わせるだけでは思いどおりの業務アプリケーションプログラムにはならない｣ という実感を裏付けるものである。
見方を変えると、創適応の必要性が小さい領域ならば、もともと汎用サブルーチンを組み合わせるだけで、どんなカスタマイズ要求にも対応できるはずである。 しかし、実際には、ビジネス分野では ｢そうは問屋が卸さない｣ のである。 なぜなら、創適応の必要性が大きい領域が存在するからなのである。
注11： 創適応の必要性が小さい領域についても、何も考えずにサブルーチンを作成するといろいろな問題を起こすことがある。 これはサブルーチンの作り方が悪いからそうなるのであって、本文で述べていることとは別の問題である。
この節では、前述の三つの要件をすべて満足する部品化再利用システムを構成するにはどのようにすればよいのかを考察してみる。
部品化再利用システムには、いろいろなタイプがあり得るのかもかもしれないが、本書では､“部品化アプリ再利用システム”という形態の部品化再利用システムに焦点を絞って論じている。 すなわち、ある分野のアプリケーションプログラムを部品合成できるような部品化再利用システムを構築する場合に、その部品の元になるものは実際に動作するその分野のアプリケーションプログラムの中に存在するはずだという考え方をとっている。 そして、実際に動作するアプリケーションプログラムを“うまく”手術して切れ切れの部品に分割することで (すなわちリファクタリングして部品化することで)、そうしたアプリを再利用しやすい部品化再利用システム (部品化アプリ再利用システム) に変身させることができるのである。
このような考え方に基づいて、この節では前述の三つの要件をすべて満足する“部品化アプリ再利用システム”にスポットライトをあてる。 まずは“部品化アプリ再利用システムの一般化した構成法”を提示することから始めよう。 次に、それを部品化再利用システムの具体例である RRR ファミリーの構成法と比較してみる。 これらの後で、この“部品化アプリ再利用システムの一般化した構成法”に関する評価を行うことにする。
“部品化アプリ再利用システムの一般化した構成法”とは、ビジネス分野以外にも適用できるように一般化した部品化アプリ再利用システムの構成法のことであり、その内容は以下に示すとおりである。
部品化アプリ再利用システムの一般化した構成法:
・ ソフトウェア製品がカバーする領域を創適応の必要性が小さい領域と大きい領域の二つに分割する
・ 次の性質 (すなわち‘ブラックボックス部品’に求められる性質) を備えた‘ビジネスロジック部品’または‘ソフトウェア部品’によって創適応の必要性が小さい領域をすべてカバーする
- カバーすべき領域に想定されるどんな要求にも部品セットからの部品選択やパラメタの指定によって対応できる (汎用性)
・ 次の四つの性質 (すなわち‘ホワイトボックス部品’に求められる性質) をすべて備えた‘ビジネスロジック部品’または‘ソフトウェア部品’によって創適応の必要性が大きい領域をすべてカバーする
- 目指す部品が簡単に捜し出せる (検索性)
- 修正すべき部品の数が限定される (局所性)
- 一つ一つの部品のサイズが手頃である (手頃な大きさ)
- 一つ一つの部品が解読しやすい (読みやすさ)
この一般化した構成法は、前述の三つの要件を整理してブレークダウンすることによって導き出したものである。 これを導き出した過程については、｢付録５．部品化アプリ再利用システムの一般化した構成法｣ をご参照いただきたい。
なお、付録５には、あるソフトウェア製品をこの一般化した構成法に従って部品化アプリとして構成できれば、すなわちこの一般化した構成法に従った部品化アプリ再利用システムが存在すれば、そのシステムは確かに三つの要件を満たしているという定理の証明がある。
この一般化した構成法の中では、ブラックボックス部品とホワイトボックス部品という用語を使っているので、これらの説明をしておく。
ブラックボックス部品とは、その中身のプログラムを解読せずに利用する (利用できる) 部品のことである。 本書では用語の意味を明確にするために、上記の性質 (汎用性) を備えたブラックボックス部品については特別に‘ブラックボックス部品’のようにシングルコーテーションで括った表記にしてある。 後で明らかにするように､‘ブラックボックス部品’は‘ソフトウェア部品’の一種である。 なお、ブラックボックスとは、一般に、内部の構造などを知らなくても自由に使えるものという意味である。
ホワイトボックス部品とは、それを利用するのに、中身のプログラムの解読が必要になる場合のある部品のことである。 本書では用語の意味を明確にするために、上記の四つの性質 (検索性、局所性、手頃な大きさ、読みやすさ) をすべて備えたホワイトボックス部品については特別に‘ホワイトボックス部品’のようにシングルコーテーションで括った表記にしてある (図5-2 参照)。 後で明らかにするように､‘ホワイトボックス部品’は‘ソフトウェア部品’の一種である。 なお､‘ホワイトボックス部品’だからといって、解読が必須ということではなく、解読せずに使えるところにも大いに使って構わない。
図5-2:‘ホワイトボックス部品’に求められる性質
ここで注目いただきたいのは､‘ホワイトボックス部品’に求められる性質の一つとして、読みやすさを要請していることである。 解読を必要としない‘ブラックボックス部品’に対しては、こういう要請はない。
なお､“読みやすさ”は、構造化プログラミングよる“見やすさ”を含むだけでなく、(これらの発音「ヨミヤスサ」と「ミヤスサ」の包含関係と同様に) より多くのことを、たとえば意味が把握しやすいという性質なども含んでいる。
部品化アプリ再利用システムの一般化した構成法の紹介が済んだので、ここで RRR ファミリーの構成法をこの一般化した構成法に照らしてみよう。 RRR ファミリーの構成法がこの一般化した構成法に沿っているかどうかをチェックするのである。 こうすることによって、一般化した構成法が単なる抽象的な言葉の遊びではなく、実体を伴っていることが明らかになる。 そして、RRR ファミリーという実例によって、具体的なイメージをふくらませることができる。
最初に、一般化した構成法の中の次の文について、その具体的な意味を探ってみよう。
・ ソフトウェア製品がカバーする領域を創適応の必要性が小さい領域と大きい領域の二つに分割する
RRR ファミリーにおいては、業務と操作の分離という分割指針によって、プログラムカスタマイズの可能性が高い部分を抜き出した。 すなわち、カスタマイズの可能性が高い部分は業務仕様に関係するプログラムだけに限定されるよう絞り込んだ。 したがって、この分割指針によって、創適応の必要性が小さい領域と大きい領域を先ず大雑把に分割していると見ることができる。
こうして分割した操作仕様に関係するプログラム部分は、A 社向けも B 社向けも基本的に同じにしてよいはずであり、プログラムカスタマイズが必要なことはめったにないと考えることができる。 したがって、この部分は創適応の必要性が小さい領域だと言える。
これに対して、業務仕様に関係するプログラム部分は、共通部分もあれば各社各様の部分もあり、カスタマイズの可能性が高い部分である。 したがって、この部分は創適応の必要性が大きい領域であるか、または創適応の必要性が大きい領域と小さい領域が混ざっているところだと考えることができる。
ここで、もしも業務仕様に関係するプログラム部分が創適応の必要性が大きい領域と小さい領域が混ざったものだとすると、この混合領域の中の創適応の必要性が小さい領域に焦点を合わせて、汎用サブルーチンとして括り出すことができるはずである。 このことは、従来から一般に行われていた業務仕様に関係する汎用サブルーチンを括り出すことに他ならない。
以上の考察によって、RRR ファミリーに関して、創適応の必要性が小さい領域とは、操作仕様に関係するプログラム部分および業務仕様に関係する汎用サブルーチンのことであり、創適応の必要性が大きい領域とは、業務仕様に関係するプログラム部分の中から汎用サブルーチンを除いた部分であるということが分かる (図5-3 参照)。
白い部分は、創適応の必要性が大きい領域であり、ホワイトボックス部品によってカバーされる。
黒い部分は、創適応の必要性が小さい領域であり、ブラックボックス部品によってカバーされる。 たとえば、業務仕様に関係するプログラム (一般には創適応の必要性が大きい) のうち黒い楕円は、汎用サブルーチン (ブラックボックス部品) でカバーできる創適応の必要性が小さい領域である。
図5-3: 創適応の必要性が大きい領域と小さい領域
このように理解すると、一般化した構成法の次の第二文についての具体的な意味が分かってくる。
・‘ブラックボックス部品’に求められる次の性質を備えた‘ビジネスロジック部品’または‘ソフトウェア部品’によって創適応の必要性が小さい領域をすべてカバーする
- カバーすべき領域に想定されるどんな要求にも部品セットからの部品選択やパラメタの指定によって対応できる (汎用性)
RRR ファミリーでは、汎用メインルーチン (注12) によって操作仕様に関係するプログラム部分をカバーし、汎用サブルーチンによって業務仕様の中の部分的に創適応の必要性が小さい領域をカバーしている。 すなわち、汎用メインルーチンおよび汎用サブルーチンによって、図5-3 の黒い部分をカバーしているのである。
注12： 共通サブルーチンを汎用化すると汎用サブルーチンになるのと同様に、共用メインルーチンを汎用化すると汎用メインルーチン (狭義のフレームワーク) になる。 なお、汎用化とは、そのルーチンがカバーする領域に対して、想定されるどんな要求にも部品セットからの部品選択やパラメタの指定によって対応できるようにすることをいう。 すなわち、汎用化することは‘ブラックボックス部品’に求められる性質をもたせることに他ならない。
したがって、汎用メインルーチンおよび汎用サブルーチンが ｢‘ブラックボックス部品’に求められる性質｣ を備えていれば、上記の第二文を満足することになる。 つまり、｢RRR ファミリーは一般化した構成法に沿っている｣ というための必要条件の一つを満たしていると言えることになる。そこで、果たしてこれらの部品が汎用性をもつ‘ブラックボックス部品’と言えるかどうかその実態を調べるのがよさそうだ。
汎用メインルーチンであっても汎用サブルーチンであってもよいのだが、もしも‘ブラックボックス部品’に求められる性質をもつように完璧に作り込むことができれば、この部分に関するどんなカスタマイズ要求にもパラメタカスタマイズ的な手段で対応できるはずである。だから、このように対応できているかどうかを調べればよいのである。正直に言うと、完璧に対応できるとは言いにくい点も若干あるが、RRR ファミリーでは、おおよそパラメタカスタマイズ的な手段で対応できていると言える。 この部分のプログラムを修正しなければならないことは稀なのである。 したがって、汎用メインルーチンも汎用サブルーチンも実質的に‘ブラックボックス部品’だといってよいだろう。
さらに、一般化した構成法として示した第三文 (次の文) についての具体的な意味も理解できるようになる。
・‘ホワイトボックス部品’に求められる次の四つの性質をすべて備えた‘ビジネスロジック部品’または‘ソフトウェア部品’によって創適応の必要性が大きい領域をすべてカバーする
- 目指す部品が簡単に捜し出せる (検索性)
- 修正すべき部品の数が限定される (局所性)
- 一つ一つの部品のサイズが手頃である (手頃な大きさ)
- 一つ一つの部品が解読しやすい (読みやすさ)
RRR ファミリーでは、データ項目部品によって創適応の必要性が大きい領域 (すなわち業務仕様に関係する領域の中の創適応の必要性が大きい部分) のほぼすべてをカバーしている。 すなわち、データ項目部品によって、図5-3 の白い部分をカバーしているのである。 したがって、データ項目部品が ｢‘ホワイトボックス部品’に求められる性質｣ を備えていれば、｢RRR ファミリーは一般化した構成法に沿っている｣ というための必要条件である上記の第三文に合致する。
この点について果たしてどうかとその具体的な意味を調べてみると、データ項目部品は、次のように‘ホワイトボックス部品’に求められる性質を備えていることが分かる。
目指す部品が簡単に捜し出せるという性質 (検索性) は、データ項目部品の大きな特長の一つである (これは繰り返し説明してきたとおりである)。 すなわち、ビジネス分野ではデータ項目名によって仕様変更要求が表現されるという特徴があるために、データ項目部品にそれぞれのデータ項目名で始まる名前を付ける決まりにしておけば、自ずと検索しやすくなるのである。 ここでご注目いただきたいのは、こうして得られる検索性は、部品検索システムを用いて力ずくで検索するのと異なり、自然に備わった部品の性質であるという点である。
修正すべき部品の数が限定されるという性質 (局所性) は、カスタマイズ要求に対処する場合に解読や修正を要するデータ項目部品の数が少ないかどうかについての性質である。 この数が少ない方が当然のことながら都合が良いわけである。 RRR ファミリーのカスタマイズにおけるこれまでの経験では、大抵は影響範囲が一つか二つの限られたデータ項目部品になり、100 とか 200 の部品を修正しなければならないことはめったになかった。 どうしてこういう性質をもつことになるのか、一つにはビジネス分野ではデータ項目名によって仕様変更要求が表現されるという特徴に関係している。そして、もう一つはこの n 個のデータ項目からなる n 次元空間の直行座標系に沿って部品を切り出した成果だといえる。 もしも仕様変更要求の座標系とは異なるものを部品切り出しの座標系として採用したとすれば、こうはいかずに、数多くの箇所の解読と修正を要することだろう。
一つ一つの部品のサイズが手頃であるという性質 (手頃な大きさ) を満足するには、ずばり 100 行以下であることが必要だろう。 これ以上の大きさだと解読しやすいとは言いにくくなる。 RRR 部品セットでの実績では一つの部品の大きさが、平均 55 行である。 そして、一つのデータ項目部品の内部は、二・三個の高級イベントプロシージャ (フックメソッド) から構成されているので、20 行前後の塊に分割されていることになる。
一つ一つの部品が解読しやすいという性質 (読みやすさ) は、部品の意味が明快か、その内容が単純かどうか、類型的かどうか、他の部品と独立に理解可能かどうかなどによって決まる。 また、構造化プログラミングよる“見やすさ”も含まれる。 データ項目部品は、型に嵌まっていて類型的で、その意味が明快なので、10 個ぐらいを解読すると、後はすらすらと解読できるようになる。 そして、他のデータ項目部品のことを一切知らなくても、それだけを解読すれば理解できる。 したがって、データ項目部品は解読しやすいと言える。
この四つの素晴らしい性質をすべて備えているので、つまり解読すべき箇所がすぐ見つかり、それは限られた一つか二つの部品に限定され、読みやすいので、大勢の開発者による組織的な部品化再利用が実現している。 実際に、300 人以上のカスタマイズ専任者が RRR ファミリーや SSS のカスタマイズ作業を行っている。これらの人々は、RRR ファミリーの開発関係者ではないのである。
こうしたことが実現できているのは、部品を区切るための分割指針の一つとしてデータ項目対応の分割を採用したことが功を奏した結果である。 つまり、データ項目対応の分割によって、‘ホワイトボックス部品’に求められる性質を完備させることができたためだと言える。
以上の三点から、｢RRR ファミリーは部品化アプリ再利用システムの一般化した構成法に沿っている｣ と言える。
トピック 10： ビジネスロジック部品の大きさ
ビジネスロジック部品 (またはこれを一般化したソフトウェア部品) の大きさ（粒度）は、手頃な扱いやすいものであることが求められる。
極端な話としてプログラミング言語の“一つ一つの命令文（またはデータ）がプリミティブなソフトウェア部品である”という立場もあり得るが、これでは何の恩恵もない。 ある考え方に従って作ったソフトウェア部品がたまたま一つの命令文で実現できたということはあり得るだろうが、一般にソフトウェア部品は複数の命令文から構成されなければ、生産性の向上に役立たないのは明らかである。
かといって、あまり大き過ぎるのでは手頃でない。 それだけで一つの業務プログラムになるほど大きなもの (業務パッケージ) は、部品と呼ぶよりも完成品と呼ぶべきだろう。 複数のビジネスロジック部品から完成品が構成される形でなければ、半完成品を組み合わせるという妙味が生まれない。
一つの画面または一つの帳票に関するプログラムは明確に半完成品と呼ぶべきだが、これをビジネスロジック部品だとする立場もある。 この立場は納得できるかにみえるが、画面や帳票に付きもののカスタマイズへの対応法を考えていないので問題である。 ここでは、画面や帳票がいくつかの小さなビジネスロジック部品から構成されていて、カスタマイズがしやすくなっていることが求められる。 つまり、小さなビジネスロジック部品が画面や帳票を構成して、画面や帳票が業務プログラムを構成するという形態の階層構造になっていなくてはならない。こうなっていれば、画面や帳票は半完成“部品”だといってよいだろう。そうでなければ、単なる半完成品に過ぎない。
ソフトウェア部品は、その中身をみせないブラックボックス部品と、中身を見せるホワイトボックス部品（ソースプログラム開示タイプ）に分類できる。 ブラックボックス部品は中身を解読することがないので、幾ら大きくても構わない。 しかし、ホワイトボックス部品は簡単に解読できるように、大きくても 100 行ほどに納まるのが手頃だと思う。
このように具体的に言い過ぎると、単なるサイズの問題ではなく、その内容を吟味すべきとの意見があるかもしれない。 ホワイトボックス部品を使う立場に立つと、一つの部品を取り出した場合に、あまり軽くて役に立たない中身の薄い部品でも困るし、役には立っても複雑で理解困難な部品では扱い難くて困る。 ビジネスロジック部品の内容は“手頃な重さ”をもっていて、かつ“手頃な扱い易さ”であるというバランスが大切だと言えよう。
RRR ファミリーが“部品化アプリ再利用システムの一般化した構成法”に沿っていることは前述のとおりである。 このことから、RRR ファミリーは“効果的なシステムにするための三つの要件”を満たしているということができる。 なぜなら、付録５に証明されている定理を使うと三段論法でこのことを推論できるからである。 具体的に言うと、あるソフトウェア製品がこの一般化した構成法に従って部品化アプリとして構成できれば、そのソフトウェア製品は確かに三つの要件を満たすという定理を使って推論できる。
これを再確認することは、説明の繰り返しになってしまう。 そこで、ここでは RRR ファミリーが三つの要件を満たしていることを一つ一つ再確認しながら、何か問題点はないかを考えてみることにする。できるだけ厳しい目で見てみるのである。
・ 部品を組み合わせるだけでソフトウェア製品ができあがるものであること
この要件を満たすには、少なくとも汎用サブルーチンだけでは不足である。 そこで、これだけでなく、操作性に関係する処理などの役割を果たす汎用メインルーチン、および創適応の必要性が大きい領域をカバーするデータ項目部品を組み合わせて用いることで、RRR ファミリーはこの要件を満たしている。
実際に、RRR ファミリーの主要部分は、汎用サブルーチン、汎用メインルーチン、データ項目部品という三つの構成要素から成り、それぞれの構成要素は正に‘ソフトウェア部品’なのであるから､‘ソフトウェア部品’だけでソフトウェア製品が構成できているといえる。
ただし、厳密に言うと、データ項目部品については、蓄積された部品だけではまかなえずにいくつかを新規に開発しなければならない場合もある。 それから、一つのデータ項目オブジェクトに対応するデータ項目部品の他に、複数のデータ項目に対応する関係チェック部品および画面オブジェクトに対応する画面部品などが少しばかりあり、これらが‘ソフトウェア部品’と言えるかどうかという点には若干の議論が必要であろう。
これらを総合的に判断すると、この要件を“おおよそ”満たしているというべきかもしれない。
・ どんなカスタマイズ要求にも対応できるものであること
この要件を満たすことは、プログラムカスタマイズを覚悟するデータ項目部品に関するかぎり問題はない。 しかし、プログラムカスタマイズを許さない汎用サブルーチンおよび汎用メインルーチンについては重点的にチェックすべきだろう。 そこで、これらを詳しく調べると、完全ではないが‘ブラックボックス部品’に求められる性質を基本的には備えていることが分かる。 したがって、大抵のどんなカスタマイズ要求にも対応できると言える。
しかし、まれには‘ブラックボックス部品’の中身を修正しなければならない場合もある。 たとえば､‘ブラックボックス部品’になることを目指して作成したはずの部品が現実には十分な汎用性を備えていない場合もあるし、また創適応の必要性が小さい領域といえどもまれには創適応が必要になることもあるからである。
このように‘ブラックボックス部品’の中身の修正が必要になることがあるが、もともとこの領域はカスタマイズの頻度が少ないこともあり、実用上は問題のないように対処できる。 具体的には、これらを担当する専門の開発者を確保しておき、対応させることにすればよいのである。 しかも、このような対応が必要になる頻度は少ないので、比較的に少数の専門家で済む。 しかし、もしも何も手を打たないとすると、4GL の問題点として紹介した“自由がきかない歯がゆさ”などの問題を発生させるので注意が必要である。
・ 大勢の開発者が組織的に部品化再利用の恩恵にあずかれるものであること
この要件を満たすには、プログラムカスタマイズを許さない汎用サブルーチンおよび汎用メインルーチンに関するかぎりは問題ない。 しかし、プログラムの解読を必要とするデータ項目部品については重点的にチェックすべきだろう。 そこで、これを調べると､‘ホワイトボックス部品’に求められる性質をすべて備えていることが分かる。 だからこそ、大勢の開発者による組織的な部品化再利用が可能になっているのである。
ただし、データ項目部品以外に関係チェック部品や画面部品などが少しばかりあり、これらが‘ビジネスロジック部品’と言えるかどうかという点に若干の議論があることは、既にお話したとおりである。
実用的で効果的な部品化再利用システムにするための三つの要件を取りあげて、4GL やビジュアル開発支援ツールがこれらを満たしているかどうか調べてみると RRR ファミリーの優位性が確認できる。
4GL もビジュアル開発支援ツールも、三つの要件をすべて満足しているわけではない。｢部品を組み合わせるだけでソフトウェア製品ができあがるものであること｣ という要件は半分ぐらいしか満たしていない。 そして ｢どんなカスタマイズ要求にも対応できるものであること｣ という二番目の要件はほぼ満たすことができるが、そうすると三番目の ｢大勢の開発者が組織的に部品化再利用の恩恵にあずかれるものであること｣ という要件が満たせなくなる。 つまり、三つの要件の二番目と三番目の二つを両立させることが困難なのである。
これまでの調査では、SSS ツールを参考にして開発したもの以外に、この三つの要件のすべてを満たすような部品化再利用システムは見つかっていない。 したがって、RRR ファミリーは部品化再利用システムの最先端にあると考えている。
部品化再利用システムの歴史を振り返ると、図4-2 のように‘ソフトウェア部品’のカバー範囲が広がってきたということができる。
最初は、サブルーチンを活用することから始まった。 第一段階では、汎用サブルーチンという形態の‘ビジネスロジック部品’が使用されただけで、その他に‘ソフトウェア部品’と呼べるようなものは存在しなかったのである。 したがって、部品化再利用の対象は狭い範囲に限られていた。
次に、嵌め込みシステムや第四世代言語やビジュアル開発支援ツールは、新たにメインルーチンを再利用する道を開き、部品化再利用が容易に行える範囲を大いに広げた。 これを第二段階と呼ぶことにする。 ただし、4GL やビジュアル開発支援ツールのイベントプロシージャについては‘ソフトウェア部品’と呼べるようなものではなかった。
そして、今後は、データ項目部品を付け加えた三つが活躍する第三段階に進むことになる。 たとえば、RRR ファミリーでは、部品化イベント駆動方式を採用することによって、汎用メインルーチンがカバーする範囲を広げるとともに、データ項目ごとに奇麗に区切られたデータ項目部品 (すなわち部品化イベントプロシージャ) という‘ソフトウェア部品’を使えるようした。 このことによって、ソフトウェア製品の全体に対して部品化再利用が容易に行えるようになるのである。
この節では､‘ビジネスロジック部品’の意味や意義について、技術的な観点から述べるだけでなく、特注業務プログラム開発業に与えるインパクトについても考えてみる。 また､‘ビジネスロジック部品技術’は、カスタマイズ作業だけでなく、一般のメンテナンス作業にも有効なことを明らかにする。
最初の (狭義の)‘ビジネスロジック部品’は、SSS 部品セットの開発の過程でうまい具合にモジュール分割でき整備できたときに生まれた｡‘ビジネスロジック部品’という命名の理由は、機械の部品とのアナロジーで、問題箇所が一目で分かり、問題箇所は特定の部品に限定されていて、その部品を取り出してみると問題の内容がよく分かるということを表現したかったからである。
当初､‘ビジネスロジック部品’とはこのように極めて具体的なものを指していた。 したがって実物を示して ｢これが‘ビジネスロジック部品’であり、他のものとはここが違う｣ と主張し､‘ビジネスロジック部品’を広めることに努めた。
一般に何かハードウェア装置のような機械を発明したときには、その実物を示すのが一番だと思われる。 こう考えて‘ビジネスロジック部品’についても実物を示したのである。 ところが、｢これこそが‘ビジネスロジック部品’だ｣ という言い方は、はなはだ不本意ながら、独善的だとみなされてしまった。 せっかく示した実物、すなわちソースプログラムは、素直に理解していただけなかった。 開発の管理をする立場の人は、プログラムを読む習慣がないためか評価していただけないし、開発者は自らの力でプログラムを開発できることを誇っているので、プログラミングを不要にするようなアプローチに興味をもっていただけない。
そこで、プログラムを見なくても分かるように、理論的な考察を行ってそれを説明することにしたのが本書である。 そして、本書では‘ビジネスロジック部品’を定義づけるに当たり、それを構成する際の条件を以下のように明確にした。 こうしても、SSS 流の‘ビジネスロジック部品’以外にそれらしいものが見つかる保証はないが、そういうものを発見する道が開かれたのである。 したがって、条件を明示する形の‘ビジネスロジック部品’の定義であれば、独善的だという非難をまぬがれて、何らかの評価をしていただくことができるのではないだろうか。是非とも評価していただくことを切望する。
本書の‘ビジネスロジック部品’の定義は以下のとおりである。 これは、既にお馴染みになった“部品化アプリ再利用システムの一般化した構成法”を基にして若干の修正を加えたものである。
‘ビジネスロジック部品’とは、ある領域をカバーするソフトウェア製品を次の三つの条件を満たすように分割し整備した断片 (モジュール) のことである。
条件１：その領域の中の創適応の必要性が小さい領域をカバーするモジュール (これを‘ブラックボックス部品’と呼ぶ) のいくつか、および創適応の必要性が大きい領域をカバーするモジュール (これを‘ホワイトボックス部品’と呼ぶ) のいくつかに分割する。
条件２：‘ブラックボックス部品’については、次の性質を備えるように機能の整備や充実を図る。
- カバーすべき領域に想定されるどんな要求にも部品セットからの部品選択やパラメタの指定によって対応できる (汎用性)
条件３：‘ホワイトボックス部品’については、次の四つの性質をすべて備えるように分割の調整と整備 (すなわちリファクタリング) を行う。
- 目指す部品が簡単に捜し出せる (検索性)
- 修正すべき部品の数が限定される (局所性)
- 一つ一つの部品のサイズが手頃である (手頃な大きさ)
- 一つ一つの部品が解読しやすい (読みやすさ)
‘ビジネスロジック部品’かどうかという議論を突き詰めていくと‘ビジネスロジック部品’の定義の問題になる。 そして、その定義を妥当なものと思うかどうかは、最終的にはそれぞれの人の主観や感性で判断することになってしまう。
でき得るならば、ここで定義したものが､“本書の定義によると”という断り書きを付けなくても、世間一般が ｢ビジネスロジック部品｣ であると認めるようになることを希望している。
以下では、上記の定義が妥当かどうかを少しばかり吟味してみる。
上記の定義は、部品化アプリ再利用システムの一般化した構成法と本質的に同じなので、この定義からこの章の最初で取りあげた“三つの要件”を満たすことが導き出せる。 これが分かれば、この定義を妥当なものだと思っていただけるに違いない。
ひょっとすると、この定義に対して条件が厳しすぎるとの意見が出るかもしれない。 すなわち、ビジネス分野に SSS 流の‘ビジネスロジック部品’が存在するのは分かったが、他の分野には‘ビジネスロジック部品’のようなものは存在しないかもしれないし、ビジネス分野には SSS 流の‘ビジネスロジック部品’だけしか存在しないかもしれないとの批判である。 まるで大組織が特定の会社の商品を購入したいときに使う常套手段のようなもので、それ以外の商品を排除するための条件になっているのではないかと疑われるかもしれない。 こう言われても困るのであるが、少しでもこのような嫌疑を少なくするには､‘ビジネスロジック部品’を構成する際の条件を示す形の定義ではなく、要件を示す形の定義にするのがよいかもしれない。 そして、もしも厳しすぎるというのなら、その後で要件をどれだけ甘くできるのかを検討すればよいだろう。
このような考えで、要件を示すことによって‘ビジネスロジック部品’の定義をしてみた。 それを以下に示す。
次の三つの要件を満たす部品化再利用システムによって合成されるソフトウェア製品の構成要素を‘ビジネスロジック部品’と呼ぶ。 次の三つの要件とは、既にお馴染みになった“三つの要件”そのものであり、これを使って‘ビジネスロジック部品’を定義しようということである。
・ 部品を組み合わせるだけでソフトウェア製品ができあがるものであること
・ どんなカスタマイズ要求にも対応できるものであること
・ 大勢の開発者が組織的に部品化再利用の恩恵にあずかれるものであること
このように定義しても、前の定義とほとんど同じだと思われるが、漠然となる分だけ‘ビジネスロジック部品’の範囲が広がるようにみえるかもしれない。
本書で述べた SSS の流れをくむ‘ビジネスロジック部品’は上記のどちらの定義にも当てはまる。 また、この要件をさらに甘くした定義に対しても、当然のことであるが当てはまる。
ここで、もしもお望みならば、要件を適当に甘くすることもできる。
たとえば、三つの要件が適用対象をソフトウェア製品全体ではなく、ソフトウェア製品のある部分だけに限定してみよう。 すなわち、以下のように変えてみるのである。 このように変えることは意味がありそうである。
・ 部品を組み合わせるだけでソフトウェア製品のある部分ができあがるものであること
・ ソフトウェア製品のその部分については、どんなカスタマイズ要求にも対応できるものであること
・ ソフトウェア製品のその部分については、大勢の開発者が組織的に部品化再利用の恩恵にあずかれるものであること
こう定義した上で、そのソフトウェア製品のうちの‘ビジネスロジック部品’でカバーできる部分を部品化可能部分と呼ぶことにする。 こうすれば、どのような応用分野でも多かれ少なかれ部品化可能部分をもつことだろう。 そして、ビジネス分野は、部品化可能部分がほぼ 100 ％であるという言い方ができる。 さらに、部品化再利用を推進するということは、それぞれの分野で部品化可能部分を最大にするようにすることだといえそうである。
要件を甘くする例として、三つの要件の適用対象をあるソフトウェア製品のうちの汎用サブルーチンでまかなえる部分だということにしてみよう。 こうすると、当然のことであるが、従来からビジネスロジック部品だと考えられていた汎用サブルーチンが‘ビジネスロジック部品’だということになる。 定義をこんなに甘くしてしまうと、従来と同じなので何のありがたみもなくなってしまう。 ただし、こうしてみることで ｢元の厳しい要件を要請する定義は、汎用サブルーチンを‘ビジネスロジック部品’の中に含んだ上で、より効果的にするために拡張した形になっている｣ ということが確認できる。 ただし、このように要件を甘くしていくと、役に立つ局面が限られて、実用的でなくなっていく。 したがって、甘くしすぎないようにしたいものである。
このような考察によって、さらに理解が増まったことと思う。 上記の条件を示す形の定義、あるいは要件を示す形の定義、あるいは部品化可能部分を最大にすることを要請する定義は、｢ビジネスロジック部品｣ に対する一般的な定義として確かに納得できると、ご賛同していただけただろうか？
トピック 11：‘ビジネスロジック部品’はモジュールか
本書の草稿を読んでいただいた方から､‘ビジネスロジック部品’とはプログラムモジュールのことかと質問された。 どちらもプログラムを分割した断片のことなので、一応そのとおりであると答えた。 もともとモジュールなるものは、それを組み合わせて積み木細工のようにソフトウェアを作ることを目指していたはずである。 そして、実際にソフトウェアはいくつかのモジュールから構成されている。 したがって、本書の‘ビジネスロジック部品’は、モジュールの一種に間違いない。
この逆も真かと言うと、モジュールは‘ビジネスロジック部品’だとは限らない。 一般にモジュール分割は自由度が大きい。 何をモジュールにするのかは、基本的に開発者にまかされていて、いわば気ままな開発の結果としてモジュールが生まれてくる。 これに対して､‘ビジネスロジック部品’の方は、それにふさわしい厳しい条件を満たすようにうまく分割され整備されたものである。 だれがモジュール分割をしたとしても、その条件を満たすのならば、同じに塊になるはずである。これほどモジュール分割の条件は厳しく、厳然とした存在なのだ。 したがって、自由に分割したモジュールが‘ビジネスロジック部品’と同じになるとは考えにくいのである。
ところで、モジュール分割を各開発者の気ままにまかせるのはよくないという反省から、たとえば開発プロジェクトの開始時に分割の指針が作られたりしている。 そこで、本書の‘ビジネスロジック部品’の性質を指針として採用した上でモジュール分割をすれば‘ビジネスロジック部品’になるといえそうである。 しかし、モジュール分割の作業は、一般的に言って、これまでいい加減に行われていたために、その狙いどおりになるとは思えない。 このことが分かるように、モジュール分割の作業指示をする様子を想像してみよう。 読者の方は、開発管理者または開発者の立場に立ったとして、どのような結末になるのか以下の順を追って想像していただきたい。
その前に、まずは指針を明確にしておこう。本書の‘ビジネスロジック部品’の特徴は、創適応の必要性が大きい領域を‘ホワイトボックス部品’でカバーするところにある。 もう一方の‘ブラックボックス部品’については、従来の汎用サブルーチンを抽出する際の分割方法と特に変わりない。 したがって、ここでは‘ホワイトボックス部品’を取りあげて、その指針を決めることにする。 すなわち、以下の四つが‘ホワイトボックス部品’に求められる性質だから、これを指針にするのである。
- 目指す部品が簡単に捜し出せる (検索性)
- 修正すべき部品の数が限定される (局所性)
- 一つ一つの部品のサイズが手頃である (手頃な大きさ)
- 一つ一つの部品が解読しやすい (読みやすさ)
指針が決まったので、開発管理者の立場の方がこの四つの性質を開発者に示して、｢カスタマイズ作業が楽にできるように、これらすべてを満たすことをモジュール分割の指針にせよ｣ と指示するシーンを想像してみよう。 この際に一つ大切なことがある。 それは、単なる分割ではなく細工というか整備というか (リファクタリングというか)、そういった工夫も重要だと示唆しておくべきだろう。 このことは重要な意味をもつにもかかわらず、しばしば軽んじられるからだ。
この指示に対する開発者からの“最もありそうな反応”は ｢そんな理想をいわれても、うまく分割できる自信はないけれども、とにかく努力してみます｡｣ という答えだろう。 実際にこの四つの性質のすべてを満たすのは大変に難しい。 一般的に言うと、これを満たす分割が可能であると保証されているわけではない。 したがって、実現性の薄い単なる理想だとみなされそうである。 そして、｢努力してみましたが無理なので、こんなところで勘弁してください｡｣ と適当なところでお茶をにごすことになる可能性が大である。 指針はあくまでも指針である。 厳密に指針に従うという開発習慣がなかったところに、不可能だと思われる指針なのだから、結果は想像できようというものである。
そもそも上記の指針に従うには、カスタマイズ要求に関する経験や知識を必要とする。 したがって、そういう経験のない大抵の開発者にはお手上げだろう。 無理難題を突きつけられて、いじめられているとみなされるかもしれない。
しかし、上記の指示に対して“全くありそうにない反応”なのであるが、開発者がこの四つの性質をすべて満たすようなモジュールに分割し整備して ｢できました｣ と結果をもってくるかもしれない。 もしも、その結果が上記の指針を満たしていれば、それは‘ホワイトボックス部品’に他ならないというのが本書の立場である。
実際には、この指針を満たす分割法が１種類だけ見つかっているが、それは SSS 部品セットの開発の中で部品らしさをもたせようと１年以上にわたり試行錯誤を繰り返した末に得られた結果である。 これは発見できないかもしれない金脈を当てたようなものである。 この適用範囲はビジネス分野だけかもしれないが、まさに大当たりだといえよう。
上に述べたような指針を満足する理想的なモジュール分割をするのはどれくらい難しいかというと、少なくとも１年ぐらいかけて、じっくり考えないと良い方法を見つけられそうにない。 したがって、モジュール分割を各業務システムの開発の度に行う習慣は間違いである。 理想的なモジュール分割の解が得られたら、その解を再利用すべきである。 このような考えから、本書で‘ホワイトボックス部品’だとしているのは、モジュールの分割と整備の作業が既に済んだものを指している。 したがって､‘ホワイトボックス部品’の品揃えを充実させるには、その分割方法に沿って‘ホワイトボックス部品’を作ればよいだけである。 したがって、特別に難しいことはない。 理想的なモジュール分割の方法を考え出すのは難しいのであるが、その方法を再利用するのは簡単なのである。
以上のことから､‘ホワイトボックス部品’は、特別なありがたみを持たないモジュールとは一線を画すものだと捉らえた方がよいだろう。 比較をするのなら、イベントプロシージャを取りあげた方がずっと類似点が多い。
イベントプロシージャは、オブジェクトとイベントの種類という組合せによってモジュールの分割方法が決まっている。 したがって、この点は‘ホワイトボックス部品’と同様である。 また、イベントプロシージャの品揃えを充実させるには、特別に難しいことはなく規定の分割方法に沿ってイベントプロシージャを作ればよいだけで、この点も‘ホワイトボックス部品’と同様である。 しかし、一般のイベントプロシージャは､‘ホワイトボックス部品’に求められる性質を完全には備えていない。 ここが‘ホワイトボックス部品’との相違点であり、再利用性を上げることができていない。
なお、イベントプロシージャのイベント体系を見直し、アップデートプロパゲーションの機構を組み込むことにすれば、イベントプロシージャの上に‘ホワイトボックス部品’の層を設けることができる。 つまり、部品化イベント駆動方式にすることができるのである。
ちなみに、RRR ツールの中核である MANDALA (マンダラ) とは、前述したとおり‘ホワイトボックス部品’を結合・合成して実際に動作するプログラムに仕上げる部品合成ツールである。
業種や業務の違いを踏まえてビジネス分野の業務プログラムを数え上げると数百に及ぶかもしれないが、それぞれの応用分野ごとに少なくとも一つずつ特注対応業務パッケージを開発すれば、特注業務プログラム開発業や業務パッケージ開発業を根本から合理化することになる。 そして、顧客（各企業）ごとに業務の処理手順に微妙な差異があるなどという理由で、それぞれの企業向けに特注業務プログラムを開発することが許されなくなってしまう。 なぜなら、適当な特注対応業務パッケージを部品カスタマイズすれば済むようになり、ぴたりと合う業務プログラムが程よい価格で供給できるようになるからである。
いや、これまで以上にぴたりと合う業務プログラムが求められるようになるものと思われる。 第３章の ｢トピック 4： エンドユーザ開発とスパイラルモデル｣ で述べたように、真にコンピュータを活用した効果を上げるには、業務システムを使い込んでいく中で機能的なチューニングを施すことが必要になる。 これまでは、重複した無駄な開発のためにそうしたチューニングまで手が回らなかったのであるが、今後はこれを行う余裕が生まれる。 こう考えてみると、カスタマイズ業は、チューニング業として大々的に発展して新たな市場を形成することが予測できる。
こうなるためには、まず特注対応業務パッケージの品揃えが必要である。 品揃えとは業務プログラムを‘ビジネスロジック部品’で構成し直す作業である。 この作業は、数百の業務プログラムを対象にしなければならないので大事業にみえるかもしれないが、次の三点から思ったよりも早く品揃えが完了しそうである。
第一に､‘ビジネスロジック部品技術’によって開発が必要なプログラムの大きさが従来よりも小さくなる (半分以下になりそうである)。 従来の COBOL のプログラムの中には操作に関係する部分と業務に関係する部分が混ざっているのが普通であった。 したがって、汎用メインルーチンを利用することによって、操作に関係するプログラムが不要になり、業務に関係する部分だけをプログラムとして用意すれば (すなわち、既に開発済みのものを集めて組み込むか、新たに開発すれば) 済むことになる。 すなわち、市販の 4GL を用いるのと同様に開発スピードが上がることになる。
第二に､‘ビジネスロジック部品’の一部は各応用分野にまたがり共通に使える。 従来からサブルーチンライブラリの一部は財務会計にも生産管理にも販売管理にも使えたのと同様に、業務に関係するデータ項目部品の一部もいくつかの応用分野で共通に使うことができ、各分野への進展を加速することができる。
第三に、これが一番効くかもしれないが、数多くのプロジェクトが先を争って開発することが予想される。 日本には必要な業務プログラムの種類よりもずっと多くのソフト開発会社があるので、一社が一つ開発すれば１〜２年で品揃えが完了してしまう。
これらの三点によって、意外に早く特注対応業務パッケージの品揃え完了して、特注業務プログラム開発業や業務パッケージ開発業を根本から合理化することになると考えられる。 実際には、それぞれの応用分野ごとに一つではなくいくつかの特注対応業務パッケージが開発されることになるだろう。 そして、特注対応業務パッケージの中でも競争が始まるので､‘ビジネスロジック部品技術’を用いないと競争に参加することすらもできなくなるのではないだろうか？
主に技術的な観点から考えると、急速にこうなることが予測される。 しかし、ソフトウェア開発の合理化に対する反感があるのも事実である。 これは、産業革命の初期に生じた機械化への反対運動のように表立っているのではなく、多くの人々の深層心理に入り込んでいる分だけ扱い難いものである。 したがって、実際には穏やかな変化になることだろう。 特に、業務プログラム開発業の経営者や管理者の意識は、変化のスピードを決める重要なキーである。 彼らが、人を集めて仕事を取ってくるだけでは駄目だと思うようにならないと変化は加速されないかもしれない。
このように変化のスピードを予測することは困難であるが、いずれにしても合理化が進んでいくことは確かである。 そして､‘ビジネスロジック部品技術’をいち早く取り入れる方が、高収益や高成長に結び付くことも確かである。
本書のこれまでの説明では､‘ビジネスロジック部品技術’の恩恵を受けるのは、ビジネス分野の特注業務プログラム開発業や業務パッケージ開発業における広い意味でのカスタマイズ作業だと明言してきた。 ところが、一般のメンテナンス作業においても全く同様に、この恩恵を受けることができる。
大きな企業がかかえるソフトウェア資産は、メガ (百万) という単位で計るような莫大な行数であり、そのメンテナンス作業の負荷は定常的な問題になっている。 メンテナンス作業は外部に委託しにくいという理由から社内で行われているとも多く、一説によると情報部門の社内要員の 7 割がメンテナンス作業に従事するほどだということである。 あるいは、関係したソフト開発会社を繋ぎ止めるための費用が固定費として大きな割合を占めるようになっている。 メンテナンス地獄とは、企業の情報部門のこのような行き詰まり状態を表現した言葉である。 なお、メンテナンス作業には、バグ修正、業務内容の変更に伴う修正、もろもろの改善などがあるが、ここでは主にバグ修正以外のメンテナンス作業を取りあげる。
ある業種・業務分野の業務プログラムをカスタマイズして A 社向けや B 社向けにするのと、ある企業の業務プログラムをメンテナンスして A 月版や B 月版にすることは、極めて似ている。 前者のカスタマイズは空間的な広がりをもたせるためであり、後者のメンテナンスは時間的な広がりをもたせるためであり、空間か時間かの違いだけで、本質的には同じことである。
カスタマイズという言葉をメンテナンスと読み替えることで、本書を ｢メンテナンス地獄の解消の書｣ に変えることができる。 いろいろなカスタマイズ要求に対応しようと大勢の開発者が組織的に取り組む際の問題点と解決策は、いろいろなメンテナンス要求に対応しようと原作者 (原開発者) 以外の人が取り組む際の問題点と解決策にもなっている。
ただし､‘ビジネスロジック部品技術’の恩恵を受けるには､‘ビジネスロジック部品’という洗練された資産体系に乗り移ることが必要である。 したがって、残念ながら現状のメンテナンス地獄の“即効薬”にはなり得ない。 そうでなく、現状の体質改善と将来のメンテナンス地獄を予防するための“特効薬”なのである。 だから、計画中の開発から順次‘ビジネスロジック部品技術’を適用していくのが現実的だろう。 たとえばオープンシステムへの移行と合わせて適用することお勧めしたい。
最後に、空間と時間を交換することに絡んで“創適応の必要性”の話にふれておこう。 情報部門では ｢どうしてこうメンテナンスが多いのだろう｣ との嘆きの声が聞かれる。 実はこれも“創適応の必要性”に関係している。 創適応の必要性が大きいと、業務パッケージにとって新たな顧客（企業）との出会いがある度に新たなカスタマイズ要求が発生すると説明したのは、空間的に捉らえた場合である。 時間的に捉らえると、創適応の必要性が大きいと時間の経過とともに新たなメンテナンス要求が発生するということになる。競争の激しい業界や合理化対象の業務に見られる現象である。 本書の‘ビジネスロジック部品技術’は、いわば創適応の必要性が大きい領域に分け入り‘ホワイトボックス部品’を用いて治めるところに特長がある。 そこで、メンテナンスの嘆きに対する“特効薬”として、長期的な視野のもとにこのテクノロジーを処方することを強くお勧めしたい。
アプリテック株式会社
Copyright © 1995-2008 by AppliTech, Inc. All Rights Reserved.