この章では、特注業務プログラムと業務パッケージとを対比させながら、ビジネス分野の業務プログラム開発の実態を見ていく。 その後で､‘ビジネスロジック部品’を用いて開発した業務プログラムの実例を一つご紹介して、これが特注業務プログラムと業務パッケージとの中間に位置することを明らかにする。
この章で業務パッケージを取りあげるのは、本書のメインテーマが部品化再利用であり、業務パッケージは再利用のパイオニア的な存在だからである。 これまで行われていた再利用の単位は、業務パッケージのような大粒の製品か、または汎用サブルーチンのような小粒の機能であることが普通であった。 これらに加えて、この章では、汎用サブルーチンではカバーできなかった領域をカバーする‘ビジネスロジック部品’をご紹介する。 この‘ビジネスロジック部品’は、大粒の業務パッケージとは違って、小粒の部品をいろいろ組み合わせることで完成品に仕立てることができるという妙味をもっている。
ビジネス分野の業務システムは、どのような業務を支援するのかに着目すると、財務会計、販売管理、在庫管理、顧客管理、生産管理などの数多くの種類に分類できる。 ただ、一口に生産管理システムといっても、半導体の生産管理をつかさどる業務システムと自動車の生産管理をつかさどる業務システムではその内容がだいぶ異なる。 したがって、生産管理システムは業種ごとに別ものだと見られることもある。 このような業種や業務の違いを踏まえて業務プログラムの種類を数え上げると、数え方にもよるが、数百種類に及ぶ。
ところが、実際に開発されている業務プログラムの数はこれを大幅に上回る。 その理由は、同じ業種の同じような業務であっても、企業によって業務処理の考え方やその手順の詳細が異なるために、それぞれの企業向けに特注業務プログラムとして開発するケースが多かったからである。
しばしば特注業務プログラムは注文服にたとえられ、業務パッケージは既製服にたとえられる。 特注業務プログラムは特定の顧客（一企業）の業務処理の考え方や手順にぴたりと合わせて開発するのに対して、 業務パッケージは大多数の企業の共通的な業務処理の考え方や手順に合わせることを目指して開発する。 ここが特注業務プログラムと業務パッケージの大きな違いである。
一般に企業の業務処理手順は、共通点も多いのであるが、各社各様の部分もある。 これらの違いは、企業特性および業種特性として理解できる。 すなわち、それぞれの会社の歴史的な経緯、トップの方針、各部門の力関係、特殊な業務遂行方法などの各社の企業特性、およびそれぞれの業種によって取り扱う商品やサービスの種類、業界の慣行、 関心事などが特徴的であるという業種特性、および他社差別化を図るための創造的な活動などによって、実際の業務処理手順には多くのバリエーションがある。 したがって、各企業は自社の業務処理の考え方や手順に合わせた専用の業務プログラムを欲しがるものである。
ところが、業務パッケージはいわば最大多数の最大幸福を目指して開発するので、必ずしもすべてのバリエーションに対応できるわけではない。 したがって、特定の顧客（一企業）に業務パッケージを導入しようとすると部分的に合わない点が見つかるものである。 すなわち、販売管理パッケージのように特定の業務に焦点を定めた業務パッケージには、 業種特性（同じ業務でも業種が異なると内容に違いがあること）や企業特性の違いがからくる何らかの不整合が見つかるのが普通である。 また、病院用パッケージのように特定の業種に焦点を定めた業種パッケージには、企業特性の違いからくる何らかの不整合が見つかるのが普通である。
そこで、いわば仮縫いのように、業務パッケージを特定の顧客（一企業）の業務処理の手順に“適応”させる作業 (カスタマイズまたは仕立て作業になぞらえてテーラリングと呼ぶ) が必要になる。 カスタマイズできない固い作り付けパッケージも存在するが、大抵の業務パッケージは何らかのカスタマイズを考慮した設計がなされている。 つまり、業務パッケージを新たな顧客環境に適応させるためのカスタマイズの仕組みを組み込んでいるのである。
カスタマイズの方式は、本質的に次の２種類に分類できる。
・ パラメタカスタマイズ
・ プログラムカスタマイズ
パラメタカスタマイズは、外部からみて意味の明快なパラメタを指定するだけでカスタマイズ作業が済むので簡便である。 しかし、パラメタカスタマイズを可能にするためには、業務パッケージを開発する際に、あらかじめカスタマイズ可能な範囲を設定して、それに対応できるような作り込みをしておくことが必要になる。 たとえば、在庫の評価法として、最終仕入れ単価法、移動平均法、総平均法、予定原価法という四つのうちのいずれかが使われると想定されるのであれば、このいずれにも対応できるように作り込みをしておく。 そして、業務パッケージに与えるパラメタによって、顧客が実際に採用する在庫の評価法を指定できるようにする。
こういう作り込みをしておけば、カスタマイズ作業は、パラメタを指定するだけで済むので、極めて簡単になる。 ただし、この方法で満たすことができる顧客からの要求は、業務パッケージ開発業者があらかじめ想定してパラメタとして指定可能にした範囲に限られてしまう。
この方式は、いわば、○×形式か択一形式の試験問題のようなものだと言える。
プログラムカスタマイズとは、業務パッケージの中の一部のプログラムモジュールを変更したり、新規に作成したりすることによって、顧客からの要求を満たすことである。 したがって、原理的にはどんな要求にも対応できる。 しかし、カスタマイズ作業は大仕事になりがちである。 なぜなら、パラメタのような外部からみて意味の明快な宣言的な情報を指定するだけではなく、プログラムの内部の手続き部分 (すなわちプロシージャ部分) にメスを入れることになるからである。 いわば内臓の器官を改造する手術なので、その作業量は、パラメタカスタマイズの 100 倍から 10,000 倍にも及ぶ。
もしも顧客からの要求をすべてパラメタカスタマイズだけで対応できれば、作業は非常に簡単に済む。 しかし、残念ながらこれだけでは対応できる範囲が限られてしまう。 いわば、パラメタを調整することだけでは、内臓の器官に新たな機能を創造して付け加えることは無理である。 したがって、どんな要求にも対応できるプログラムカスタマイズの存在意義があるのである。
この方式は、いわば、文章で答える形式の試験問題のようなものだと言える。
二つのカスタマイズの方式の良いとこ取りをしたのが二段構えカスタマイズである。 これは、よくあるタイプのカスタマイズ要求にはパラメタカスタマイズで対応して、それでは対応できないときに、プログラムカスタマイズという奥の手を使う二段構えの方式である。 つまり、ある範囲のカスタマイズは簡単に済ませることができるようにすると同時に、顧客からのどんなカスタマイズ要求にも対応できる柔軟性をもたせるという賢い方法である。
ここで用語に関する注意事項がある。 世の中には､『パラメタ』の指定だけでほとんどすべてのカスタマイズ要求に対応できる、といわれている業務パッケージがある。 そういう業務パッケージの『パラメタ』と本書のパラメタカスタマイズにおける ｢パラメタ｣ とは全く違うものを指しているので、注意が必要である。 本書の ｢パラメタ｣ とは、外部からみて意味の明快な宣言的な情報のことを意味している。 これに対して、もう一方の『パラメタ』とは、業務パッケージの内部構造に依存した情報であり、宣言的な情報以外に手続き的な情報が含まれているのが普通である。 この種の『パラメタ』は、いわばその業務パッケージを記述するための内部言語 (一種のプログラミング言語) なので、本書ではそういった『パラメタ』の設定作業は、プログラムカスタマイズであるとみなすことにする。 実際に、そういった『パラメタ』カスタマイズの作業量は、本書の ｢パラメタ｣ カスタマイズの 100 倍から 10,000 倍にも及ぶことが普通である。 したがって、これらは同じ名前を使ってはいても、その実体は別物だと捉らえるべきである。 簡単だと印象づけようとする『パラメタ』カスタマイズは、簡単には済まないプログラムカスタマイズの仲間なのである。
業務パッケージは、特定の顧客（一企業）ではなく、多くの企業に売ることを目標にしているために、その開発には独特のノウハウや配慮が必要であり、特注業務プログラムよりも開発コストがかさむものである。 したがって、特定の顧客（一企業）にしか売れないような業務プログラムは、わざわざ業務パッケージ仕立てにすることはなく、特注業務プログラムとして開発するのが普通である。
これに対して、数多くの顧客（企業）に売ることができて、かつカスタマイズ要求にバラエティの少ない業種・業務分野の業務プログラムは、パッケージ仕立てにするのが有利である。 もしも個々の顧客（企業）ごとにそれぞれ特注業務プログラムを開発するものと仮定した場合の合計のコストを見積もれば、一つ開発することによって多くの顧客（企業）に使ってもらえる業務パッケージの方が大幅なコストダウンになることは明らかである。
トピック 1： 金の卵を生む業務パッケージへの夢
ビジネス分野の中でも財務会計に関しては後述する理由から特別であり、カスタマイズ要求に関するバラエティが限られている。 こういう応用分野は、業務パッケージに向いており、パラメタカスタマイズだけで大抵の要求に対応できる。
業務パッケージのパラメタカスタマイズ率（パラメタの設定だけで対応できるカスタマイズの割合）を上げるためには、カスタマイズ要求に関する十分な情報を収集することが必須である。 たとえを挙げると、多様な環境に適応可能な生物に進化していく過程においては、それぞれの環境に適応するための遺伝子情報を獲得することが必要になる。 これと全く同様に、多様な環境に適応可能な業務パッケージに進化させるには、カスタマイズ要求に関する情報を必要とする。
実際に、次の情報収集策を用いることで、財務会計パッケージのパラメタカスタマイズ率を９８％ほどに上げた例外的な例もある。 その情報収集策とは、カスタマイズ作業の担当者にはソースプログラムを渡さずに、パラメタの設定だけでカスタマイズしてもらうことを原則とする。 どうしてもプログラムカスタマイズが必要になった場合には、そのカスタマイズ事例に関する詳しい情報と交換に、ソースプログラムを開示することにする。 こうすれば、カスタマイズ要求に関する詳しい情報を広く収集できる。 情報が収集できれば、後は開発資金と開発期間をかけて、業務パッケージをエンハンスして、新たに分かった要求にもパラメタカスタマイズで対応可能なものに進化させることができる。
パラメタカスタマイズ率の高い業務パッケージは、大きな設備投資を必要とする装置だと捉らえることができる。 いわば注文服の自動縫製装置のようなものだから、大きな初期投資を必要とするのだ。 しかし、その装置が有効に働く限り大きな利益を生み出す。 なぜなら、その業務パッケージが適用できるような業務であれば、金の卵を生む鶏のように、次から次へとパラメタの設定だけで業務プログラムを生み出すことが可能だからである。
このような金の卵を生む鶏をつくることは、どんな業務プログラムに対しても可能なのかというと、そうではない。 実は、一般に“創適応の必要性”(第５章に詳説してあるが、とりあえずは ｢本書を理解するためのキーワード｣ の説明をご参照いただきたい) が小さい応用分野に関する業務プログラムの場合に限って可能なのである。 創適応の必要性が大きい応用分野に関する業務プログラムは、いくらパラメタを追加しても、それでは対応しきれない新たなカスタマイズ要求が上がってくるので、パラメタカスタマイズ率を十分に上げることができない。 新たな顧客（企業）との出会いがある度に作り込みが必要になるであろうし、世の中のニーズの変化に対応していくためのメンテナンスも継続的に必要になることだろう。 したがって、金の卵を生む鶏をつくることは、一般には難しいことである。 財務会計パッケージのような、例外的にかなり創適応の必要性が小さい応用分野の場合に限って可能なのである。 財務会計分野は、遵守すべき法律の規定という制約があり、創造的な発展が制約されているために創適応の必要性はあまり大きくない。
なお､‘ビジネスロジック部品技術’を用いると、第５章で説明するように、創適応の必要性が大きいビジネス分野も対しても、金の卵を生む鶏に近い業務プログラム (業務パッケージ) をつくることができる。
これまでは技術的な話を中心にしてきたが、この節では視点を変えて利益を上げることに全力をつくしている開発業者の立場たった議論を展開してみよう。 現実を知るには、こうした見方も重要である。
業務パッケージ開発業者の収益は、業務パッケージの売上本数に大きく影響される。 したがって、数を出すことに力を注ぐし、数の出そうな業務パッケージを主力商品にすえるものである。 また、数が出れば価格を下げることも可能なので、低価格戦略によってユーザをさらに増やす効果も期待できる。
こういった状況において、業務パッケージの売上本数を伸ばすためには、どのような要求にもカスタマイズで対応可能にする柔軟性が重要だと思われるが、現実は必ずしも“そうではない”のである。
様々な顧客からの様々なカスタマイズ要求に対応可能な業務パッケージにするには、二段構えカスタマイズ方式を採用するのが一番である。 しかし、業務パッケージ開発業者がこの方式を主力業務パッケージに採用することはめったにない。 なぜなら、企業顧客の多数派に対しては当然パラメタカスタマイズで対応可能にするので、残りは少数派だということになるからである。 この少数派に対してプログラムカスタマイズを行っても、手間ばかりかかるわりに、期待される売上本数の増加はわずかな場合が多いので、二段構えカスタマイズ方式は採用されないのである。 プログラムカスタマイズの手間は、パラメタカスタマイズの手間の 100 倍から 10,000 倍と桁違いであることを思い出していただきたい。 この落差を考えれば、業務パッケージ開発業者がプログラムカスタマイズを敬遠することを納得できそうだ。
それでは、業務パッケージ開発業者はどのような要求にもパラメタカスタマイズで対応可能にするための作り込みを徹底的にしておくかというと、そうでもない。 作り込みはほどほどのところで打ち止めとなる。 その様子を見ると、新たな作り込みによって恩恵を受ける企業顧客の数が多そうなところ (すなわち売上本数を増やせそうなところ) から始めて、 順に作り込みをしていくので、あるところまで行くと残りは効果の薄いものばかりになってしまう。 こうなると打ち止めである。 ごく少数の売上増しか期待できない要求に、わざわざ手間のかかる作り込みをするようなことはめったにない。
このような長い説明をするよりも、｢パラメタカスタマイズを可能にするための作り込み作業は、 プログラムカスタマイズよりも手間がかかるので、ほどほどのところで打ち止めになる。｣ と短く言う方が分かりやすいかもしれない。
なお、パラメタカスタマイズを可能にするための作り込み作業を徹底的に行わない理由がもう一つあり、 これについては ｢５．１ 実用的で効果的な部品化再利用システムの要件｣ の中で説明する。
以上のように、業務パッケージ開発業者は、あらゆる要求にカスタマイズで対応可能にしようと努力するわけではない。 むしろ“顧客の方をパラメタカスタマイズで対応可能なところに誘導する”という販売テクニックや顧客指導に重点を置くことが普通である。 実際、この誘導策は業務パッケージの数を出すのに大いに効果があるからである。
言い遅れたが、ここまでの議論は、カスタマイズサービスが業務パッケージ価格の中に含まれる場合を想定したものである。 もしも、業務パッケージ開発業者がカスタマイズサービスの料金を別立てにしたら、話しは違ってくるかもしれない。
ただし、業務パッケージ開発業者がカスタマイズサービスの有償化を強く主張し始めると、ぴたりと合うようにカスタマイズされた業務プログラムに対する顧客の期待を助長することになりかねない。 こうなると、カスタマイズサービスの有償化は、カスタマイズを避けて通ろうとする業務パッケージ開発業者の誘導策と両立しないことになる。 したがって、業務パッケージ開発業者がカスタマイズサービスをビジネスにしている例は、めったに見当たらない。 業務パッケージ開発業者は、カスタマイズとは無縁の手離れのよいビジネスを指向しているのである。
企業向けの特注業務プログラムは、その企業が自社開発することもあるが、コンピュータのメーカやディーラが開発して、コンピュータと一緒に納入するのが通例であった。 この場合、開発の料金は、基本的に開発にかかる人件費に依存することになる。 つまり、ある特注業務プログラムの開発を請け負うときの料金は、その開発に何人が何ヵ月かかるのかを“人月”という単位で見積もって、その値を基礎にして決めるのが普通である。
ところが、実際に開発にかかる人月は、各開発者がこなす作業量に大差のあることや、業務プログラムの仕様を定量的に表現することが難しいために、極めて大きなバラツキがある。 したがって、開発の請負い仕事は、リスクが大きい。 持ち出しになることもあれば、思わぬ高利益を上げることもある。 そして、数多くの請負い仕事を平均するとバラツキが緩和されて、何とか利益を生むことができるという難しいビジネスなのである。 ただし、業務プログラムと一緒に納入するコンピュータのハードウェアの売上の方からは、オープン化が進展する前までの間は、安定したかなりの利益を上げることができたので、ビジネスとして十分に成り立っていた。
このような状況では、開発者の数を増やして開発の請負い仕事の量を増やすことが重要だとみなされていた。 そうすれば、統計的にバラツキが緩和されるし、利幅の大きなハードウェアの売上増にも結び付くことになるからである。
このように開発者も仕事も増やすというアプローチ以外に、特注業務プログラムの開発作業を合理化することによって開発者の数は増やさずに仕事の量だけを増やすという省力化戦略もあり得る。 しかし､“人月”という単位で見積もった値が売上に直結する環境では、合理化は進展していない。 特注業務プログラム開発業者には何が何でもコストダウンをしなければならないという意識はないといってよく、たとえ合理化策を練ったとしてもそこには甘さが目立った。 合理化に社運をかけて取り組むようなことは極めてまれだったのである。
一般に、外部からの強い圧力がないと合理化はなかなか進まないものである。 そして、以前までは、何の圧力もない状況だったのである。 ところが、オープン化の進展とハードウェアの低価格化、すなわち利幅の低減という圧力によって、特注業務プログラム開発業者も合理化をせまられるようになってきた。
ちなみに、ここで特注業務プログラムの開発業者をシステムインテグレータ側とその下請けとして開発作業を行う業者に分類して、もう少し詳しく調べてみよう。 特注業務プログラムの開発業者には、コンピュータのメーカやディーラの他に、彼らからの発注を受けて実際の開発を行うソフト開発会社も含まれる。 コンピュータのメーカやディーラは、ソフト開発会社に特注業務プログラムの開発をさせて、自らはシステムインテグレータの役割、すなわちハードウェアと種々のソフトウェアからなるシステムの取りまとめの役割を果たすことが普通であった。
ところで、オープン化が進展する前は、開発に必要な情報がコンピュータメーカからディーラへ、そしてソフト開発会社へと流れていたために、ソフト開発会社は弱い立場にあった。 しかし、オープン化が進展した後は、情報によるコントロールは薄れていった。 このため、力のあるソフト開発会社は、顧客から直接注文を受けることも増えている。 システムインテグレータもソフトウェア開発者も、益々それぞれの力量が問われる時代になってきたのである。
特注業務プログラムの請負い開発においては、思わぬ高利益を上げることがある。 たとえば、同じような業務プログラムの注文をソフト開発会社が受けた場合である。 こういった場合、その仕事に同じ開発者をうまく割り当てると、プログラムの“転がし”とか“転用”と呼ばれる手段をとることができる。 ここで転用とは、ある開発者が A 社向けに開発した特注業務プログラムを再利用して、似たような B 社向けの特注業務プログラムを開発することである。 別名を“流用”とも言うが、どの言葉も良からぬニュアンスが含まれているので、以下ではそうした色の付いていない再利用という言葉を使うことにする。
再利用は、一般に個人ベースで行われる。 ある開発者の開発したプログラムをその開発者が再利用するのが普通である。 もしも再利用を組織的に行うことができれば、開発作業の合理策として立派に通用する。 しかし、一般に他人の書いたプログラムを解読して再利用する手間を考えると、新規に開発した方が得だと考えられている。 一説には、解読をせずにそっくりそのまま利用できる部分が 8 割以上ないと、他人の書いたプログラムは再利用しない方が得だと言われているほどだ。 こうしたことから、再利用を組織的に実施するという合理策は、とことん追求されることはなかった。
業務プログラムの利用者の立場から見ると、業務パッケージを用いるのと新たに特注業務プログラムを注文するのとでは、どちらが得だろうか？ ぴたりと合った業務パッケージを見つけることがでれば断然業務パッケージである。 しかし、そういうものが必ずしも見つかるわけではない。 したがって、何らかのカスタマイズが必要になるもので、その際の費用が曲者だということになる。
これに関係した笑うに笑えない話がある。 あるコンサルタント業者の方は、ある業務パッケージをある顧客（一企業）向けにカスタマイズするために、新規に特注業務プログラムを開発するよりも多くの費用がかかったと言っていた。
一般に業務パッケージはそれ固有の適用範囲をもっており、その範囲を逸脱して適用しようとすると、カスタマイズ費用が途端に大きくなるものである。 この典型的な例は、パラメタカスタマイズでは対応できないためにプログラムカスタマイズに切り換えるような場合である。
業務パッケージを適用するにあたっては、そのカスタマイズ費用を正しく見積もることが肝要で、こうしないと特注業務プログラムか業務パッケージかの選択においてミスを犯すことになる。
結論として ｢特注業務プログラムか業務パッケージか｣ どちらにする方がビジネス上有利かを判断する際には、カスタマイズのコストを考慮に入れて評価することが重要である。 このことは、ユーザの立場に立った結論である。 と同時に、業務パッケージ開発業者と特注業務プログラム開発業者のそれぞれのマーケットが分かれている理由にもなっている。
この節では、特注業務プログラム開発業者の中でも特異な存在であったウッドランド社 (同社は 2007 年からフューチャーアーキテクト株式会社に経営統合されている) の製品をご紹介する。 ウッドランド社は、オフコンのディーラとして万を越える業務システムの納入実績をもっている中堅企業であったが、 他の特注業務プログラム開発業者とは違って、開発作業の合理化に必死になって取り組んだ。 そして､‘ビジネスロジック部品’を用いた業務プログラムを開発した。 それは特注業務プログラムと業務パッケージの間に位置づけられる特注対応業務パッケージと呼ぶべきものであった。 この特注対応業務パッケージにはどんな特長があるのかを調べてみよう。
ウッドランド社は、次の点に問題があると考えて、特注業務プログラムの開発作業を合理化することに取り組んだ。
・ 実際の開発費のバラツキ
・ 人海戦術に頼った開発方式
これまでの開発の経験から、特注業務プログラムには各社各様の部分もあるが共通部分の方が多いことが分かっていたので、何かよい方法があるはずだという直観から研究を進めた。
もしも、共通仕様に関係するプログラム部分は共通にして、各社各様の仕様に関係するプログラム部分だけを各社各様に作成できれば、特注業務プログラムの開発作業を合理化することになる。 しかし、これは ｢言うは易く行うは難し｣ である。 共通部分と各社各様の部分の間に明確な線引きがなされているわけではないし、この線引きが簡単にできるというわけでもない (なお、この線引きは、最近の言葉を使えばフローズンエリアとホットスポットの区分けに他ならない)。 したがって、どこが各社各様の部分だといわれても対処できるような備えが必要であり、プログラムと仕様との対応関係を根本から見直さなければならなかった。
参考のために、個人が自発的に行っている再利用の実態を見てみよう。 たとえば A 社向けの特注業務プログラムを再利用して B 社向けに仕立て直す場合には、 A 社向けと B 社向けとで仕様が異なる部分に着目して、そこに関係するプログラムの変更だけで済ませていることが分かる。 したがって、すべての業務プログラムを新たに開発するよりも格段に簡単に開発できるのである。
この個人ベースの再利用を組織的なものにできれば素晴らしい。 しかし、再利用を組織的なものにするのは簡単ではない。 プログラムと仕様との対応関係は、開発者の頭の中にあるだけなので、他の人にはおいそれと分からないものだからだ。 この対応関係を理解するには、その開発者を師として弟子入りして、隅から隅までそのプログラムを解読することが必要になる。 こうすれば、他人の開発したプログラムであっても、自分で開発したのと同様に、どこをどう修正すればよいのかピンとくるようになるものである。 ただし、プログラムは小説を読むように簡単に解読することはできないので、多大な習熟期間を必要とする。 これを承知の上で、習熟のための投資をするのも一つの合理化策かもしれない。
ウッドランド社は、これでは本質的な解決にならないと考えた。 この合理化策を現状の絡まった糸のような俗にいう“スパゲッティプログラム”に適用しても、いずれ破綻することだろう。 そこで、業務アプリケーションプログラムの構造を工夫することによって、プログラムと仕様とを対応関係を分かりやすくする方向を目指した。
実際は回り道と試行錯誤の連続であった。 しかし、その話をすると分かり難くなるので割愛して、事の本質にせまることにしよう。
1980 年代に日本でも注目されたデータ中心アプローチ (データ項目に重点を置く考え方) に着目しただけでなく、 これまでの開発の経験からも十分にうなずけたので、 プログラムをデータ項目に対応づけて細分化することにした。 これまでの経験では、各社各様の仕様の 8 割以上が何らかの形でデータ項目に関係しているとの感触をもっていた。
データ項目対応の分割を志向したのは、これによってプログラムと仕様との関係が、その開発者だけでなく誰もが分かるものになると考えたからである。 なぜなら、ビジネス分野ではデータ項目名によって仕様変更要求が表現されるからである。 なお、｢付録２．ビジネス分野の業務プログラムの一般的な特徴｣ もご参照いただきたい。
たとえば ｢“商品単価”の割引の算出方法を変更してほしい｣ という具合に仕様変更要求の中には“商品単価”というデータ項目名が出現する。 そして、この例のようなカスタマイズを施すときに、もしも“商品単価”というデータ項目に対応するプログラム部分が切り出されていれば、その部分の修正だけで対処できるはずだ、という点に着目した。
このアイデアを追求して、プログラムの分割方法を模索したところ、データ項目に対応づけることのできない部分も若干あるが、工夫をこらすことによって大方は対応づけに成功した。 各データ項目に対応する部分を切り出したプログラムの断片を集めて、規格化 (ある鋳型に合わせて整形) することによって、アイデアを実現させることができたのである。
この結果、業務に関するプログラムの 7 〜 8 割はデータ項目に対応づけることができ、各プログラムの断片は意図したとおり仕様との対応関係が明快になった。 しかも、各断片はそれだけで意味の分かる閉じた塊になった。 また、そのほとんどは 100 行以下になった。 そして、鋳型に合わせた効果も得られて、各断片は類型的な形態になったために解読しやすいものになった。 さらに、このプログラムの断片の名前を、それぞれのデータ項目名で始まるものにしたことで、簡単に検索できるようになった。 それも、大袈裟な検索システムなどを必要とせずに可能になったのだ。
なお、このデータ項目に対応づけたプログラムの断片は、第５章で述べる‘ビジネスロジック部品’に必要とする性質を備えているので、データ項目部品と呼ぶことにする。
ウッドランド社は、このデータ項目部品という‘ビジネスロジック部品’を使って販売管理業務向けの業務アプリケーションプログラムの合成システムを開発した。 そして、これを SSS (トリプルエス) と名づけた。 このシステムは、本書の定義に合う‘ビジネスロジック部品’で構成されたおそらく最初のものであり、これらの部品を合成することによって、思いどおりの販売管理システムを生み出すことができるものであった。
SSS には粗削りなところがあり､‘ビジネスロジック部品’のセット (集合) と部品合成ツールとが奇麗に分かれていなかった。 しかし、これらは概念的には明確に区別できるので、図1-1 のように、 それぞれ SSS 部品セットおよび SSS ツールと呼ぶことにする。
図1-1: SSS の構成要素と部品合成
初めてこのシステムを見たときに、SSS 部品セットとして提供されていたのは販売管理業務向けのものだけであった。 しかし、他の業務向けにも部品セットさえ追加開発して取り揃えれば、 同じ部品合成ツール (SSS ツール) を使って業務システムを生み出すことができると十分に推測できた。 実際に、この部品化再利用システムは少なくともビジネス分野には有効に働く仕組みだったので、 部品セットを充実させていくことで ERP パッケージ (統合パッケージ) へと発展させることにつながったのである。
これまでの歴史を振り返ると、業務プログラムは特注業務プログラムと業務パッケージとに二極分化する傾向にあった。 そして、二極分化することには次のような問題がある。
業務パッケージは、大量に再利用されるので手頃な価格になるが、カスタマイズを避ける方向に進んでいる。 ぴたりと合う業務プログラムにしようとする力が働かない。 しっくりと納まるものが欲しければ、特注業務プログラムにせざるを得ない。 しかし、特注業務プログラムの方は、再利用という手段をほとんど使わず、一から開発するので、手頃な価格にならない。
そこで、両者の良いとこ取りをした程よい価格でぴったりとという、特注対応業務パッケージと呼べるようなものが欲しくなる。
このようなシステムの構想を練ってみると、二段構えのカスタマイズ方法を採用して、パラメタカスタマイズで対応できないところは、 プログラムカスタマイズによって特注 (特殊な注文) にも対応できるように設計するのが良いと気づく。
ここまではストーリができるのであるが、こうするとカスタマイズ費用が問題となり、リーズナブルな価格範囲におさまらなくなりそうである。 パラメタカスタマイズで対応できないところをプログラムカスタマイズで対応すると、２桁以上も大きなカスタマイズコストがかかるという問題がある。 したがって、プログラムカスタマイズのコストを低くすることが解決すべき課題として浮上してくる。
ウッドランド社の開発した‘ビジネスロジック部品技術’は、この課題に対する一つの答えになっている。 このテクノロジーを用いると、プログラムカスタマイズを行うときに、その作業対象範囲がいくつかのデータ項目部品に限定される。 たとえば、業務アプリケーションプログラムが全部で 100 キロ行あったとしても、合計 1 キロ行ほどのデータ項目部品だけに着目してプログラムカスタマイズをすればよいことになる。 しかも、この作業は、データ項目部品が規格化されているおかげで、通常の 1 キロ行のプログラムをカスタマイズするよりもずっと簡単である。
従来のプログラムカスタマイズ作業においては、100 キロ行のうちの 10 キロ行ほどを詳細に調べた後に、その広い範囲にまばらに手を入れることが必要であった。 このように関係するプログラム行数が多いことに加えて、この種の作業はプログラムの動作に悪影響を及ぼしがちな気を使わなければならない大変な仕事であった。 この従来の作業内容と比較すると､‘ビジネスロジック部品技術’を用いることでプログラムカスタマイズの作業量を桁違いに小さくできるのである。
カスタマイズの作業量が少なくとも 1 桁以上改善されるのだから、 データ項目部品を用いた特注対応業務パッケージのプログラムカスタマイズは、今までのとは違うものだと捉らえるべきだろう。 したがって、これを特別に部品カスタマイズと呼ぶことにする。
表1-1: 特注業務プログラムと業務パッケージと特注対応業務パッケージ
| 顧客の特別な注文への対応 | 顧客の負担するコスト | |
| 特注業務プログラム | プログラムを作り込むのでいかようにも対応できる。 | 開発費用のすべてが一顧客にかかるので負担は大。 |
| 業務パッケージ | パラメタカスタマイズ可能な範囲での対応になりがち。 | 一つを大勢の顧客が再利用するので各顧客の負担は小。 |
| 特注対応業務パッケージ | 部品カスタマイズによっていかようにも対応できる。 | 一つを大勢の顧客が再利用するので各顧客の負担は小。 ただし、部品カスタマイズの費用の負担が必要。 |
この章の締めくくりとして、表1-1 に特注業務プログラムと業務パッケージと特注対応業務パッケージの比較を載せておく。 また、本章で説明したキーワードを使って本章の要旨を述べておく。
業務パッケージには、パラメタカスタマイズと従来方式のプログラムカスタマイズの間にコスト的にあまりにも大きな段差があるために業務パッケージ開発業者はプログラムカスタマイズを避ける戦略をとり、 特注業務プログラムと業務パッケージに二極分化する方向に進んだ。 しかし、部品カスタマイズという方式によって、この段差が緩和されて、いわばプログラムカスタマイズのコストダウンができるので、 特注業務プログラムと業務パッケージが融合した特注対応業務パッケージを生み出すことができる。 そして、特注業務プログラムか業務パッケージは特注業務プログラムと業務パッケージの良いとこ取りをした程よい価格でぴったりとという狙いを満たすことができる。
したがって、特注業務プログラムか業務パッケージかという問いに対する回答は、特注対応業務パッケージが望ましいという結論になる。
アプリテック株式会社
Copyright © 1995-2008 by AppliTech, Inc. All Rights Reserved.