この章では、まず第四世代言語 (4GL) や CASE ツール (ケースツール) などの一般のソフトウェア開発支援ツールを概観した後に､‘ビジネスロジック部品技術’を活用した SSS ツールと一般のツールとを比較してみる。
SSS ツール自体の開発は、世の中のツールの動向をあまり調査せずに行われた。 しかし、今振り返ってみると、一般のツールにあるような機能を作り込みながら、一部の機能を突出させていたことが分かった。 つまり SSS ツールは他と比較できないほど特殊なものではなかった。
そこで、部品化アプリ再利用システムの検討の一環として、世の中のツールを調査し、他のツールの方が進んでいる点は取り入れて、RRR ファミリーを世界で最高の部品化再利用システムにすることを目指した。 なお、RRR ファミリーとは、SSS のリファイン版のことである。
この章を読む際には ｢第４章 ソフトウェア開発の生産性｣ を参照しながら読んでいただくようにお願いする。 この第３章と第４章はどちらを先に配置すべきか迷った結果、この順序になっている。 本来なら並行して読んでいただけるように書くべきだったかもしれない。
ソフトウェアの開発を支援するツールは、どの開発工程を支援するのかによって上流工程支援ツールと下流工程支援ツールの二つに分類できる。 この他に、中流工程支援ツールを含めて三つに分類することもあれば、もっと細かく分類することもある。
開発作業を細分化することは、うまい開発手順を見つけるために有効な手段かもしれないが、開発工程を細かくしすぎるのは問題である。 開発工程を細分化しても、人間がそうした細分化された工程に従うことで作業が簡単になるとは限らないからである。 ｢４．１ ソフトウェア開発の生産性とは｣ で述べるように、ソフトウェアの開発は、ハードウェア (物) をベルトコンベアで製造するのとはわけが違う。 ソフトウェアの開発の中の知的な作業は、切り刻んだからといって簡単になるわけでもない。 そもそも、ソフトウェアの開発の中の機械的に処理できる部分は、コンピュータに行わせることができるのだから、わざわざ人間が行うには及ばない。 したがって、ソフトウェアの開発の中で人間が行うべき作業は知的なものだということになり、こういう部分を細分化することは、ほとんど意味がない。
ただし、開発工程の分類を曖昧のままにしておくと、幻想を生む温床になることもあるので、何らかの分類が必要である。 本書では、単純に上流工程と下流工程の二つに分類して、それぞれを次のように明快に定義する。
｢上流工程とは、人間がコンピュータ処理の対象とする現実世界 (とその周辺) を理解して、業務システムのイメージを要求仕様として明確化する工程であり、下流工程とは、その要求仕様を実現させる工程、すなわちその要求仕様に基づく業務システムを構築するためにソフトウェアを作成する工程である｣ と、本書では定義する。 そして、上流工程支援ツールおよび下流工程支援ツールは、それぞれの工程の作業を支援するツールだと定義する。
この定義では、あくまでも人間が中心にいて仕事を進めていくことを前提にしている。 もしも人間の介在が一切不要なツール、すなわちすべての開発作業を自動化するツールがもしも存在するとすれば、それは、ここで定義した支援ツールよりもはるかに高いレベルにある別物だと考えることにする。
上流工程と下流工程 (注５) の関係をどう捉らえるかに関して、次の二つの提案がなされてきた。
その一つは、ウォータフォールモデル (滝モデル) である。 これは、滝を落ちた水のように、上流から下流へと工程をおって進んでいき逆戻りすることはない、という捉らえ方である。 現実の開発には下流から上流への逆戻りがあることが普通だが、それが無視できるほど少なければ、こう捉らえてよいだろう。
このような開発の捉らえ方から一歩踏み出して、ウォータフォールモデルに基づく開発を理想として、手戻りを発生させるべきでないという考え方もある。 これを理想に掲げるのは、主に大勢の開発者による大規模開発を行う場合である。 仕様変更に対処するための作業量は、開発者の数の二乗に比例して増えるといわれるので、大勢の人間による開発では、特に仕様変更を出さないように気を使うものである。 そこでは、手戻りを撲滅することを追求することになり、上流工程の作業を完璧にすることが重要課題だという考えに傾く。 この結果、上流工程支援ツールが注目される。 なお、上流工程支援ツールについては ｢３．１ 上流工程支援ツール｣ で詳しく説明する。
注５： 上流工程および下流工程という言葉は広く使われているので、本書ではこれらの用語を用いた。 しかし、これらの用語は、ウォータフォールモデルに毒されているし、上流階級をイメージさせ実作業を軽んじるニュアンスを含んでいる。 こうしたニュアンスに影響されないようにするには、要求仕様の明確化工程とその実現 (インプリメント) 工程というような用語を用いるべきかもしれない。
上流工程と下流工程の捉らえ方のもう一つは、スパイラルモデルである。 これは、上流工程と下流工程をぐるぐる回りながら螺旋階段を下降するように、開発が進んで行くという捉らえ方である。 見直して反省することが進歩につながるという考え方なのであるが、実際の開発にはミスによる手戻りとしか捉らえようがない無駄もあるものである。
意外に思われるかもしれないが、このスパイラルモデルに基づく開発を理想だとする考え方もある。 これに対して、｢手戻りを理想にするとは何事ぞ｣ と、ウォータフォールモデルを理想にしている人々からの反発があることだろう。 手戻りを容認するのは仕方ないとしても、それを理想に掲げるのは誤りだというのである。 しかし、スパイラルモデルをかつぐ理由には、人間の特性に合わせることを理想とする人間工学的な発想があってのこと。 このような考え方も十分に成り立ち得る。 そもそも、人間が立派な作品を作るとき、そこには作っては見直すという繰り返しがあるものだ。 したがって、ソフトウェアの開発においても見直しがあってこそ、立派な作品を開発できることになると言えよう。
スパイラルモデルを理想とする開発では、上流工程において、ある程度イメージがまとまったら下流工程に移り、取り敢えずプロトタイプシステムを作る。 この際には、プロトタイピング支援ツール (後述) が大きな役割を果たす。 なお、こういった開発方法は、ラピッドプロトタイピングまたはラピッドプロトタイピング方式による開発と呼ばれている。
最初に作ったプロトタイプシステムの扱い方には、作り捨てにする場合と作った後に改版を繰り返すことで本番システムにもっていく場合の二つがある。 後者の場合の開発の様子を以下に描写してみよう。
初版のプロトタイプシステムがある段階まで作成できたら、それを携えて上流工程に戻る。 今度は最初の場合と異なり、プロトタイプシステムがある程度できているので、それを活用して現実世界との不整合を見つけ、要求仕様をリファインできる。 頭の中だけで考えるよりも目に見えるシステムが存在した方が要求仕様を明確にしやすいものである。 こうして要求仕様が今より明確になったら、また下流工程に移り、最新の要求仕様に基づいてプロトタイプシステムに修正を加える。
このように上流工程と下流工程を行きつ戻りつすることによって、システムを改版していき、たとえば第 100 版ぐらいになると実運用に供する業務システムが完成することになる。
このような表現だと、あたかも上流工程と下流工程がだいぶ離れているという印象を与えるが、画家が一筆入れては見直すような短いサイクルでこれらの工程を繰り返す場合もあるので、上流工程と下流工程の作業が渾然一体としているようにみえることもある。 そういう状況を思い浮かべていただければ、第 100 版という数も言い過ぎではなく極めて控えめな値であることをご理解いただけるだろう。
トピック 4： エンドユーザ開発とスパイラルモデル
エンドユーザ開発とは、開発の専門家 (特注業務プログラム開発業者や企業の情報部門の人) ではなく、業務システムの利用者であるエンドユーザ (実際の業務に携わっている人) が開発作業を行うことをいう。 エンドユーザは、コンピュータ処理の対象となる現実世界とその周辺を既によく理解していることが普通なので、エンドユーザが開発すれば上流工程の大部分を省くことができる。 したがって、エンドユーザ開発は、ウォータフォールモデル的な開発になってよさそうだ。 ところが、むしろスパイラルモデル的な開発になることが普通だ。 なぜなら、業務システムがまだ何もない段階でそのイメージを固めることはエンドユーザにとって非常に難しいためである。 一般に、業務システムができ上がってくると、いろいろと注文が沸き出してくるものである。
あるエンドユーザ開発を経験された方から伺った話では、業務システムが一応完成した後、使い込んでいく中で、真にコンピュータを活用した効果が実感できたとのこと。 それは、顧客から電話で注文を受ける際の支援をするシステムであり、以下のような支援をすることによって、顧客の印象をよくして売上を大いに伸ばすことができたとのことである。
その業務システムは、｢前回のアレは良かったから、この前の倍の数だけもってきてくれ。｣ というような ｢アレ｣ とか ｢コレ｣ とかという注文に即座に ｢ハイ、xx を nn 個ですね。｣ と応答できるように支援したり、｢ところで、yy の評判はいかがですか？ 御社の在庫もそろそろなくなるのではないでしょうか？ ご注文をいただけませんか？｣ などと顧客との会話をはずませたりするための支援をするものである。 この業務システムに機能的なチューニングを施して、誰が顧客からの電話を受けても常に全員がその顧客のことばかり考えていると思わせるようにできたとのことである。
こうするまでには、電話を受けて業務システムを操作するエンドユーザ側の意識の持ち方や使い込みも重要であるが、業務システム側も改版につぐ改版が必要だったとのことである。 電話を受ける要員と業務システムとを一体化させるためには、スパイラルモデル的な開発方法を採用することが必須だといえそうである。
この節では、上流工程支援ツール、すなわち人間がコンピュータ処理の対象とする現実世界 (とその周辺) を理解して、業務システムのイメージを要求仕様として明確化する工程を支援するツールを詳しく調べてみる。
ここで、上流工程がなぜ重要だとみなされるのかをもう一度振り返ってみよう。
業務システムの開発を終える直前のデモンストレーションで、顧客の求めていたものとの隔たりが発覚して、修正しなければならない事態になった場合を考えていただきたい。 少量の修正で済むのなら不幸中の幸いだと、余裕をもって受け止めることもできる。 しかし、最悪の場合には業務プログラムの大幅な作り直しになり、納期に間に合わなくなるかもしれない。 このような経験をすると、ウォータフォールモデルを理想に掲げる人々は、上流工程で完璧に業務システムのイメージ固めをすることが益々重要であると考えるようになるものだ。 これとは対照的に、スパイラルモデル的な開発を推奨する人々は、開発の初期段階では完璧に業務システムのイメージ固めをすることは無理なのだから、早期に見直しを繰り返すことが必要だと主張することだろう。
考え方はいろいろだが、上流工程の重要性の話に戻って、これを特注業務プログラム開発業者の立場にたって考えてみよう。 特注業務プログラムの開発を請け負う場合は、業務システムのイメージをしっかりと固めておかないと、大変な目にあう。 見積もり後に次から次へと出される要求までも当初の請負いの範囲だと顧客に言われて、当初見積もった作業量を超えるオーバワークが必要になり、採算割れになるというおそれがあるからだ。 だから、要求仕様の明確化は、採算が取れるようにするためにも重要なのである。
ところが、業務システムのイメージ固めを完璧にすることは、経験を積んだスキルの高い人にとっても、なかなか難しい作業である。 したがって、これをソフトウェアのツールが代行するなどということは到底不可能に近い。 次のような状況を想像していただければ、それがよく分かることだろう。
そもそも顧客の要求そのものが必ずしも明快とは限らない上に、開発途中で気が変わって変更されることもしばしばある。 また、顧客（企業）の各部門ごとに (価値観に相違があり) 要求が異なっていたりして、要求仕様の取りまとめは一筋縄ではいかない。 したがって、コンピュータの前に座っているよりも、エンドユーザとの話し合いの方がずっと重要だといわれている。 そして、本当に役に立つ業務プログラムを開発するには、通常では聞き出せない本音の仕組み (インフォーマルシステム) を知ることの方が重要だともいわれている。 そのためには、インタビューをするぐらいでは得られる情報に限界があるので、仕事の内容を覚える気になって OJT (on the job training) を受けるべきだとの意見もあるほどである。 要求仕様をまとめ上げる作業は、コンピュータサイエンスよりもむしろ社会科学の色彩が濃い。
この種の一筋縄ではいかない作業をツールで支援することは、果たして可能だろうか？ 真っ向から取り組むことには無理があり、この種の作業をツールが代行することなどは考えられない。 しかし、上流工程の作業の一部を何らかの形で支援するのであれば可能である。 実際に、次のような支援がツールによって行われている。
・ 業務システムのイメージをまとめた要求仕様書を記述する作業の支援 (ワープロ)
・ 各種のダイアグラムを記述する作業の支援 (上流工程 CASE ツール)
・ インタビュー支援 (同種の業務システム開発のノウハウに基づく質問票)
・ 疑似体験支援 (画面や帳票のプロトタイピング支援ツール)
この他にも、コミュニケーションの手段としての電子メールやグループウェアなどがあり、少なくともこれらには間接的な支援効果がある。 しかし、これらにまで言及すると話が発散してしまいそうなので、本書では省略する。 そして、上に挙げた各々のツールによる支援について見ていくことにする。
人間がコンピュータ処理の対象となる現実世界を理解したり、業務システムのイメージをまとめたりする工程の一部には、文章や図表を記述する作業がある。 ものを書くことは、記録を残すために必要であるし、冷静に考えをまとめるためにも有効である。 記述した文章や図表は、正式なアウトプットとして残すものもあれば、作業の過程で一時的に書いてみるだけのものもあるだろう。 いずれにしても、上流工程の何割かは、こういった記述作業である。
文章を記述するときにワープロを用いることは、文の追加・変更・削除などの修正作業が簡単になるので、大きな支援になる。 また、ダイアグラム (設計図の一種) を記述するときに CASE ツールのダイアグラムエディタを用いることは、うんざりするようなダイアグラムの書き直し作業の負荷を軽減するので、大きな支援になる。
支援ツールには、このようなツールのもつ明確な機能による直接的な効能だけでなく、作業を楽しくすることで得られる協調的効果もある。 悪筆の手書きの文章にたくさんの赤 (修正) が入ったものは読むに耐えないが、ワープロの綺麗なアウトプットであれば、推敲も楽しくなるし、不揃いのところを見つけると形式を統一しようという意欲もわくものである。 たとえば、本書はワープロなしには完成しなかったと確信をもって言うことができる。 悪筆で文章の下手な人間にとって、自分の文章を読み直すのは気の重い仕事であるが、ワープロにはそれを楽しい仕事に変える魔力がある。
このように協調的効果は確実にあるのであるが、それをどの程度だと評価するのかは、意見の分かれるところである。 この後で話題にする上流工程 CASE ツールに関する評価のような行き過ぎもあるので、冷静さが肝要である。
なお、ここでは上流工程における記述作業の支援について述べたが、下流工程においても同様の記述支援があり得ることは、言うまでもない。
CASE とは computer aided software engineering の略語であり、CASE ツールとはソフトウェア開発を支援するツールの一般名称である。 したがって、広義の CASE ツールには第四世代言語 (4GL) も含まれる。 ただし、4GL という言葉が何となくビジネス分野に土着した印象を与えるのとは対照的に、CASE という言葉には学問的な裏付けの香りがただよっている。 こういう言葉のニュアンスの差から 4GL は CASE に含まれないと思っている人も多いようである。
ブームが起こると言葉に色が付いてしまうもので、何の修飾語もなしに CASE ツールと言った場合は、1980 年代の後半にツールビジネスとして欧米で成功をおさめた upper CASE ツール、すなわち開発の上流工程を支援する上流工程 CASE ツールを意味することが普通である。 ここでは、その上流工程 CASE ツールに的を絞って、その総括的な評価をしてみる。
CASE ツールの目標は、ソフトウェア開発の上流工程の自動化であり、プログラミングの自動化である。 こういう理想を掲げて、開発の上流工程を支援し始めた上流工程 CASE ツールは、一躍ブームを巻き起こした。 ところが、そのブームは 5 年ともたなかった。 なぜなら、上流工程 CASE ツールはその理想とは程遠いところにあり、理想と現実とのギャップが大き過ぎたからである。 このような否定的な評価を、もしもブームの最中に述べたとしたら、ブームの勢いに押し流されて無視されたことだろう。 しかし、既にブームは去り、いわば古戦場に立ち戻って歴史的な評価を下すのだから、何をいっても銃弾が飛んでくることはなさそうである。 以下の話を冷静に聞いてもらえそうである。
まずは、実際の上流工程 CASE ツールとはどんなものかを見てみよう。
米国では、1970 年代からソフトウェア工学者たちが構造化分析法などに基づくそれぞれの流儀のダイアグラムを提案していた。 これは、データ・フロー・ダイアグラム (DFD) とかエンティティ・リレーションシップ・ダイアグラム (ERD) とかを基本とするもので、業務処理の構造を分析するのに有効であった。
ところがダイアグラムを書いてみると、完成させるまでに何回もの書き直しが必要になる。 きれいに書き上げて完成したと喜んだのも束の間、考え落ちに気づいて全面的に書き直さなければならないという悲劇がしばしば発生する。 これを鉛筆と消しゴムで行うのは面倒であるし、綺麗に仕上がらない。 また、何といってもスマートではない。
上流工程 CASE ツールは、このダイアグラムを記述する作業および書き直し作業を一新した。 パソコンのディスプレイ上にグラフィカルなダイアグラムをマウスによるスマートな操作で書けるように (書き直せるように) 変えたのである。 上流工程 CASE ツールとは、ダイアグラム用のワープロというか、ダイアグラム記述のための CAD (computer aided design) システムというべきか、そういう種類のツールである。 いや、これだけでは少し狭い見方かもしれない。 ダイアグラムの中味の整合性のチェックの一部を自動的に行うものもあった。 ただし、そのチェックレベルは知的なものではなく、目次と本文の対応関係の有無をチェックする程度のワープロにもあるような機能であった。
上流工程 CASE ツールは、確かに記述作業を支援する効果がある。 しかし、要求仕様を明確化する作業をどのくらい支援するのかという観点から評価すると、わずかであるとしか言いようがない。 なお、この支援の程度を評価する方法については、｢付録３．積み上げ方式で生産性の向上率を求める例｣ に例示してあるのでご参照いただきたい。 そもそも、この種のダイアグラムは、仕様の十分性を判定する側のエンドユーザにとって決して分かりやすいものではない。 ただし、欧米では、要求分析を専門に行うアナリストという職種があり、そういう人々は、構造化分析法などに基づきダイアグラムを書いていた。 このダイアグラムは、専門家が業務処理の実態を分析するときに有効なものなのである。 したがって、この種のツールの需要がないわけではない。 でも、それだけではブームになるとは考えにくいのである。
ブームの背景や要因を探ると、業務プログラム開発の生産性向上への潜在的な強いニーズ、グラフィカルな表現を駆使したツールの見栄えの良さ、CASE という先端テクノロジーの響きのよい言葉、ツールベンダの巧みな宣伝、コンピュータジャーナリストやコンサルタント業者の同調的な関わりなどを挙げることができる。
コンピュータジャーナリストなどが見栄えの良さに引かれて CASE ツールを話題にすると、企業の情報部門の関係者はそれについてある程度の知識を得ることが必要になる。 企業のトップから ｢他社は CASE ツールを導入して効果を上げているようだか、当社は何をしているのか？｣ と問いただされるからである。 そこで CASE ツールを買って調べることになる。 しかし、上流工程 CASE ツールなるものは、簡単には理解しにくいものである。 したがって、コンサルタント業者の活躍の場を提供することになる。 こうして、いろいろな人々が関わりをもつ市場が形成されていった。
また、次のようなことも言える。 各企業の中で CASE ツールを調査するのは、開発の実務担当者ではなく長期ビジョンの策定にあたる計画部門の要員であることが普通である。 こういう人々は、CASE ツールが理想を追及しているということを好意的に受け入れる傾向にある。 それはそれで構わないのであるが、その後で現実を無視して過度な期待をふくらませることもあり、その期待が一人歩きをすることもあった。
一度、大げさに取り扱ってしまうと、その後で ｢実はこの程度のものですよ｣ とは言いにくい雰囲気が作られるし、そのビジネスに大勢の人々が参加してくると、おいそれと後に引けなくなるものだ。 前進するしかなくなり、上流工程 CASE ツールはブームにまでなったのである。
やがて、期待したようなものではないことが多くの人々に分かってきて、｢上流工程 CASE ツールは software でも hardware でもなく shelfware (棚に飾っておくもの) である｣ という冗談を言い合うようになった。 そして、1980 年代の終わりごろになって、欧米では上流工程 CASE ツールのブームは下火になった。
上流工程 CASE ツールは、ソフトウェア開発の自動化やプログラミングの自動化という理想とは大きな隔たりのある、要求分析のプロ向けのダイアグラムの記述支援ツールだったのである。 しかも、それを使えば誰もがその道のエキスパートになれるという代物ではなく、構造化分析法などの訓練を積んだ人だけが使いこなせるものであった。 さらに言えば、上流工程の中でこの種のツールが支援するのは一部の作業だけなのだから、大袈裟な言い方は慎むべきだったのである。 もっとも、こういうどさくさに紛れて、一儲けしようと企むのなら話は別であるが、... 。
以上が上流工程 CASE ツールブームのてん末である。 この後に、統合 CASE ツールを引き下げてブームを起こそうとする動きがあったが、あまり成功していない。 なぜなら、すべての開発作業を本当の意味で自動化するツールなどはまだ存在しないことを、大勢の人々が理解してきたからだと思う。 そんなツールは、100 年先ならいざ知らず、当分の間は出現することはないので気にする必要もないのであるが、そんな幻想は確かに存在していたのである。 まだコンピュータが神の座にある名残かもしれないし、ツールベンダの宣伝が巧みすぎたので、そのような幻想をいだかせてしまったのかもしれない。
トピック 5： 大げさなツールの宣伝
一時期、明らかに行き過ぎと思われる数値を挙げて、｢ツールを使うことで生産性が n 倍になった｣ という宣伝がなされていた。 こういう倍率を追求してみると、条件のよい特定の事例だけを取りあげたいわゆる瞬間風速であり、統計的に意味をもつ値ではないことがほとんどであった。 しかも、次のようなご都合主義の比較だといわざるを得ないものもあった。 たとえば、同種の業務プログラムの開発経験をもつ人が開発したので生産性が上がった事例だとか、特別にスキルのある人が開発したので生産性が上がった事例などとかと、通常の開発 (こちらは低く見積もりがち) との比較であったりする。 生産性の倍率を簡単に測定する方法がないために、確かめられないのをよいことに言いたい放題であった。 しかし、行き過ぎはすぐに分かるもので、大袈裟な倍率は単なる宣伝文句だとみなされるようになった。 生産性の倍率の測定方法について納得のいく説明がないものは、客観的な評価ではなく、宣伝文句だとみなすのがもはや常識になってしまった。
なお、生産性の倍率をできるだけ客観的に測定する方法については ｢４．２ ソフトウェア開発の生産性の計り方いろいろ｣ をご参照いただきたい。 また、｢４．３ ソフトウェア開発の生産性は向上しているか｣ の ｢トピック 8： ツールでどれだけ生産性が向上するか｣ も合わせてご参照いただくとよいだろう。
業務システムを開発する際に、顧客から注文されたり気づいたりしたことを基にしてアンケート形式にまとめ上げた資料を、ここでは質問票と呼ぶことにする。 質問票は、業務システム構築のノウハウ集の一つだとも言えるが、顧客へのインタビューをする際のツールだとみなすこともできる。
もしも以前に別の顧客から注文されたことがあれば、それは誰もが望むことかもしれない。 したがって、それらを参考にして作成した質問票に基づいて ｢一般には (つまり別のお客様ではという意味)、... という選択肢があるので、この点に関して、こちら様ではどのようにいたしますか？｣ と顧客にインタビューするのは、なかなか有効である。 顧客がまだ気づいていなかった点にも気が回るようになるからである。 そして、このような質問によって、後になってから顧客に言われそうな要求を事前に把握できる。
ところで、｢１．１ 特注業務プログラムと業務パッケージの違い｣ で述べた業務パッケージのパラメタカスタマイズにおいては、顧客にインタビューをして、その回答に基づいてパラメタの設定するのが普通である。 このパラメタは、その業務パッケージにある性格づけを施して顧客が望む業務システムにするための情報なのだから、業務システムのイメージを固めるための質問票のようなものだといえる。 これを逆方向から見ると、業務パッケージにおけるカスタマイズのパラメタに相当するのが、特注業務プログラムにおいては質問票だということができる。
業務パッケージにおいては、新たなカスタマイズのパラメタを設けようとすると作り込み作業が伴うので、おいそれとパラメタを増やすことはできない。 また、カスタマイズを避けようとする販売政策もあるだろうから、厳選したものだけをパラメタにすることだろう。
これ対して、特注業務プログラムの質問票は、要求仕様をもれなく把握することを目指すものである。 業務パッケージのカスタマイズ用パラメタの数よりもずっと多くの質問が含まれていてしかるべきであるし、この質問に答えてもらうことだけで業務パッケージよりもずっと顧客にぴったりとした業務システムのイメージがまとまるはずである。
後述するようにビジネス分野は“創適応の必要性”(第５章で詳説してあるが、とりあえずは ｢本書を理解するためのキーワード｣ の説明をご参照いただきたい) が高いので、これらの決まりきった質問で分かること以外にも、顧客からのいろいろな注文があって、それらを満たすことが必要になることだろう。 しかし、顧客の要求への第一次近似のための作業として、まずは質問票の答によって業務システムのイメージ固めをするのが合理的な手順だと思う。 そして、この後で第二次近似、第三次近似、... の作業をする中で顧客の要求にぴたりと合わせていくのが効率的だと思われる。
業務プログラムとそのエンドユーザとの接点は、次の二つがほぼすべてである。 これ以外の繋がりはほとんどない。
・ ディスプレイ画面の表示情報や出力帳票を見ること
・ 表示情報を見ながらデータの入力操作をすること
業務プログラムの開発の初期の段階で、エンドユーザに画面のスタイルや帳票のスタイルを示して (できればデータ入力の操作法までも) 疑似体験してもらうことはなかなか有効である。 文字で書かれるだけでは曖昧のままになりがちな要求仕様を現物に近い業務システムを目の前に置いて確認してもらえるからである。 この疑似体験は、コンピュータシステムに不慣れな人々にも分かりやすい確認手段であり、上流工程 CASE ツールの説明の中に登場したダイアグラムよりもずっと分かりやすい (ダイアグラムには別の意義があるのでこのような比較は酷であるが)。 たとえを挙げると、レストランで料理を注文するときに、文字で書かれたメニューよりも料理のレプリカや写真の方が、そのイメージを間違いなく伝えることができるのと同様である。
エンドユーザは完成したかのような業務システムを早めに疑似体験できるので、いろいろな点に気が付いて多くの注文が出てくるかもしれないが、そういった注文に早めに手を打てる。 したがって、後工程での仕様変更の発生を少なくできる。
この疑似体験のためには、それを見たり操作したりできるプロトタイプシステムを作成することが必要である。 このために、画面のスタイルや帳票のスタイルなどのデザインを支援するプロトタイピング支援ツールが使われる。
疑似体験をするタイミングとして、プロトタイプシステムをどの程度それらしく動くようにしてからエンドユーザに見てもらうのか、ということが問題になる。 紙芝居のように動かない画面よりも、コンピュータゲームのように打てば響く画面の方がよいに決まっている。 しかし、そうするにはプロトタイプシステムの作成に時間がかかるので、疑似体験の開始時期が遅れることになってしまう。 そこで、プロトタイプシステムの作成を適当なところで切り上げて、疑似体験をしてもらうのが普通である。
ところで、もしも開発予定の業務システムに近いものが既に開発済みであったとしたら、そのシステムをエンドユーザに疑似体験 (体験) してもらうことは、間違いなく要求仕様の確認に有効である。 張りぼてのプロトタイプシステムよりも実システムの方がよほど実感がわく。 部品化再利用を推進すると、このようなことが現実に可能になるのである。 ただし、既に動作している業務システムが存在することをエンドユーザに示すことになるので、業務プログラム開発業者は新規開発にかかる分だけの開発費を請求しづらくなると文句を言い出すかもしれない。 確かにそのとおりであり、無駄な新規開発が不要になるのである。しかも、変に新規に開発するよりも、再利用開発の方がお客様の納得のいくシステムになる可能性が高い。 開発を行わせて開発費を払い、開発して開発費を得るという構造を変えて、再利用を主体とする方向にしていけば、以前よりも疑似体験を活用することになり、お客様の満足度を向上させることができるに違いない。
プロトタイピング支援ツールには、上流工程支援ツールだとされているものと、下流工程支援ツールだとされているものがあるが、その内容には本質的な違いはない。 ただし、どちらなのかを曖昧にしておくと、ツールベンダの巧みな説明によって、錯覚に陥るので注意が必要である。 すなわち、上流工程を終えると下流工程で開発すべきソフトウェア資産 (画面や帳票やプログラム) がツールによって自動生成されると誤解してしまうことがある。
もしもツールベンダに悪意があれば、詐欺だと言えるが、ひょっとするとツールベンダ自身も錯覚に陥っているのかもしれない。
錯覚しやすいツールベンダの説明とは、以下のようなものである。 なお、錯覚に陥らないように、括弧の中に正しい認識を書いておくが、最初は括弧の部分を飛ばして読むのも一興である。
ウォータフォールモデルに基づく開発の中で、疑似体験によって要求仕様を明確化するのは上流工程の作業なのだから、疑似体験に必要な確認用のプロトタイプシステムを作るのも上流工程の作業である。
(理想形としてのウォータフォールモデルと実際の開発とを混同してはならない。 実際の開発では、上流工程と下流工程を行きつ戻りつするのが普通である。プロトタイプシステムの作成は、下流工程の作業を前倒しにして実施しているのだから、下流工程の作業だとみるべき。)
ウォータフォールモデルに基づく開発の中で、上流工程から下流工程に移るのは疑似体験によって要求仕様を明確化した後である。
(疑似体験に必要な確認用のプロトタイプシステムを作成するときに、一時的に何回も下流工程に移っているのだから、疑似体験によって要求仕様を明確化した後に、初めて下流工程に移るということではない。)
上流工程で行ったプロトタイプシステム作成の成果から、下流工程で開発すべき画面や帳票やプログラムの一部を自動生成できる。
(プロトタイプシステムとして作成した画面や帳票やプログラムをその後の作業に都合がよいように変換することは、自動生成と呼ぶべきではない。 ソフトウェア資産の変換と呼ぶべきである。 しかも、プロトタイプシステムとして作成された成果は、上流工程ではなく下流工程で開発されたものである。)
画面や帳票やプログラムの一部が自動生成されるというような錯覚に陥らないために、再確認の意味で、本書の定義に従った正しい見方を記しておく。
プロトタイピング支援ツールは、下流工程支援ツールとみるべきである。 なぜなら、これはプロトタイプシステムを作成し始めるとき、すなわち前述の定義に従うと下流工程とみなされる工程区分から使用するものであり、広い意味では業務システムの作成のための支援ツールに他ならないからである。 プロトタイプシステムは、作り捨てにする場合と、作った後に改版を繰り返すことで本番システムにもっていく場合がある。 いずれにしてもプロトタイプシステムを作成するということは、業務システムの作成が始まっていることに他ならないので、下流工程の作業だとみるのが妥当なのである。
ところが、疑似体験に支援されて要求仕様を明確化する作業は、正真正銘の上流工程の作業である。 このような言い方は、下流工程と上流工程が入り交じっているかのような印象を与えるが、疑似体験に支援されて要求仕様を明確化する作業は、下流工程の後に上流工程に戻って行われているのだと考えていただきたい。 つまり、スパイラルモデルに照らして、プロトタイプシステムを作った後に、そのシステムを携えて上流工程に戻り、そのシステムを活用して現実世界との不整合を見つけたり、業務システムへの要求仕様をリファインしたりしているということなのだ。
こう考えれば錯覚に陥らないと思う。 これまでは、錯覚に陥って画面や帳票やプログラムの一部が自動生成される、とありがたがっていた人々も見受けられるので注意が必要である。 もしも開発の中間成果物に対して何らかの変換処理が必要であれば、ツールによって変換するのだと説明すべきである｡“変換”だと言わずに、錯覚を生じさせがちな“自動生成”のような言い方がなされることがあるので、注意が必要なのである。
ここで中間成果物の変換処理だという冷静な見方をしてみると、そのような変換処理は本当に必要なのかという疑問がわき、たとえ必要だとしても最小限にしたいと思うはずである。 たとえば、下流工程支援ツールだとして販売されるプロトタイピング支援ツールを疑似体験のために用いれば、変換処理が不要なことが普通である。
なお、これと同様に錯覚を起こしやすい言い方なのだが、疑似コード (シュードコード) からプログラムコードに変換することが自動生成だと強硬に言われることがある。 言葉の魔力に惑わされないように気をつけ、変な誤解や錯覚をしないように注意が必要である。
そもそも上流工程と下流工程の間には大きなギャップが存在する。 そして、上流工程の情報から下流工程のソフトウェア資産を本当の意味で自動生成するようなツールはまだ存在しない。 しかし、そのようなツールへの期待から、幻想が生まれている。くれぐれも注意が必要である。
手の込んだマジックのためだというのは邪推かもしれないが、開発工程を細かく分類する仕掛けもある。 本書では、分かりやすく上流工程支援と下流工程支援の二つに分類したが、工程１、工程２、工程３、... のように数多くの工程区分を設けるのである。 そして、ツールを使うことで、工程１の成果物から工程２に必要なものを生成し、工程２の成果物から工程３に必要なものを生成し、... と生成のシークエンスを強調することによって、強力なツールであることを示そうとする宣伝が行なわれたこともあった。
既に賢明な読者の方々はお分かりのように、その宣伝は上流工程支援と下流工程支援の二つにからむマジックを数多くの工程に応用しただけのことである。 そして、そういった宣伝は、トランプの手品の一つ、カードの数当てシークエンス (注６) を連想させる。 ソフトウェアの開発は、ベルトコンベアのようには進まないので、工程を切り刻んだからといって簡単になるわけではない。 人間が思い付いたり思い浮かんだりする単位よりも小さくしても意味があるとは思えない。 こういう疑問をもって、ツールベンダがなぜそういう工程区分にするのかを考えてみると、彼らにとっての都合がよいからではないかと思えてくる。 いわばゲリーマンダ (Gerrymander) の山椒魚の形に似た選挙区区割のようなもので、当選するのに都合がよいからだというように思われるのである。
実際のソフトウェアの開発は、一人の開発者の頭の中でさえもいろいろな開発作業が並行して進む。 ましてや、複数の開発者がいればもっと複雑な様相を呈するものである。 そうした中で、開発工程ではなく開発作業を分類してうまい開発手順を見つけて、それを活用することは意味があるし理解できることである。 しかし、無理やり特定の開発工程シークエンスに合わせようとしても、うまくいかない。 少なくとも新たな創造を伴うような実際の開発 (注７) においてはそれに合うように進むとは限らないのである。 したがって、そういった開発工程シークエンスは単なる目標か形だけのものになるのが普通である。
注６： 数字が見える方の１枚目のカードを裏返しにして、トランプの束の反対側に乗せて、束の両側のカードの数字が見えるように準備しておき、｢次々とカードの数を当てる｣ と宣言する。 最初に、１枚目のカードをお客様に向けてかざして見せながら、その反対側の (お客様には見えない) カードの数を記憶する。 次に、トランプの束を体の後ろにもっていって、今記憶にとどめたカードを最初にしたように移動してお客様に見せるカードにする (先にお客様に見せたカードの上に乗せる)。 この後、トランプの束を体の前に戻して、お客様にかざして見せると同時に、その数を言い当てる。 こういった動作を繰り返すことで、次々とカードの数を言い当てていくことができる。
注７：‘ビジネスロジック部品技術’を用いた業務プログラムのカスタマイズ作業は、作業方法が分かりやすい分だけ、工程が立てやすいし、その作業量も見積もりやすい。 二番煎じの創造を排除している効果だといえる。 しかし、二番煎じの創造とはいえども、ある種の創造を伴うことの多い従来の開発では、そうは工程どおりに進まないものである。
この節では、部品化アプリ再利用システムの検討の一環として行った下流工程支援ツール (上流工程で明確化された要求仕様に基づいて業務システム構築のためのソフトウェア作成を支援するツール) の調査によって、この種のツール類をどのように捉らえるようになったのかを報告する。
古い話になるが、アセンブラやコンパイラによる生産性の向上は、目覚ましいばかりであった。 インターラクティブ (会話的) なコンピュータ利用も大変に効果的であった。 紙テープやカードを使っていた時代から、ラインエディタを用いるようになり、やがてフルスクリーンエディタが普及した時代へという流れも生産性の向上に大いに寄与した。 そして、この流れの延長線上に、画面や帳票のレイアウトを書くための専用エディタや文章を記述するためのワープロなどが続いてきた。 これらは、コンピュータの歴史が始まってからしばらくの間は、下流工程支援ツールとして、生産性を向上させることに大いに寄与した。
下流工程支援ツールの主なものを以下に挙げてみる。
・ プログラミング言語から機械語への変換支援 (アセンブラやコンパイラ)
・ 設計文書作成支援 (ワープロ)
・ 画面や帳票のレイアウト設計支援 (専用エディタ)
・ 画面や帳票のレイアウトを中心にしたプロトタイプシステムの開発支援
・ ファイルやデータベースの設計支援 (専用エディタ)
・ プログラム記述行数の削減支援 (第四世代言語)
・ プログラムの見やすさの向上 (チャート図エディタ)
・ 部品化再利用の支援 (オブジェクト指向、嵌め込みシステム)
・ インタープリティブな即実行とデバッグ (インタープリタ)
・ デバッグ／テスト作業の支援 (デバッガ)
・ 開発資産の管理支援
なお、ツールとはいえないが、部品として位置づけられる次のようなソフトウェア資産も生産性の向上には重要である。
・ 様々な機能ルーチンの品揃え (汎用サブルーチンライブラリ)
上のツールのリストには設計支援と書かれているところがあるが、下流工程支援ツールのほとんどは、設計らしい作業ではなく、設計作業の中の機械的に処理できる部分を人間に代わって遂行することが中心である。 たとえば、アセンブラは、面倒なアドレス計算や、機械命令の名前から命令コードへの変換を人間に代わって遂行してくれる。 こういった計算や変換の作業は、決して設計の根幹に関わる部分ではないが、普通の人には過酷で面倒な作業であることも事実である。 そして、うまいことに簡単にコンピュータに処理させることのできるものであった。 したがって、真先に注目されツールの機能として組み込まれて、生産性の向上に大いに貢献した。
コンピュータが開発された初期の頃には、コンピュータに処理させやすく、かつ効果の大きなネタ (材料、施策、仕掛け、仕組み) がいくつもあったので、そういうネタをツールに組み込むことで、大いに生産性を向上させることができた。 しかし、効果の大きなネタはすぐに拾い尽くされてしまい、この延長線上では、ほんの少ししか生産性を向上させることができなくなってしまった。 初期の頃の目覚しい進歩に比べて、その後のツールによる生産性の伸びが停滞しているのはこのためである。 なお、さらに踏み込んだ議論は ｢４．３ ソフトウェア開発の生産性は向上しているか｣ をご参照いただきたい。
本来であれば、設計の根幹をなす知的作業の生産性を向上させることに真正面から取り組むべきだろう。 つまり、人間ではなくコンピュータに設計作業の中心部分を実施させるようなツールを開発すべきである。 しかし、残念なことに、これを実現できる目処は全く立っていない。
そこで、下流工程支援ツール、すなわち業務システム構築のためにプログラムの開発を支援するツールは、より生産性に寄与するよりも、むしろ ｢快適なソフトウェア開発環境の提供｣ を目指して開発されるようになった。 これは、車の基本機能が成熟した後に、快適な居住空間の提供という目標を掲げて車が開発されるようになったのと同様である。
部品化アプリ再利用システムの検討の中では、そのような中でも生産性にこだわっている次の二つのツールを取りあげて、詳しく調べてみた。
・ 部品化再利用の支援 (オブジェクト指向技術、嵌め込みシステム)
・ プログラム記述行数の削減 (第四世代言語)
部品化再利用の支援に関係するものとして、オブジェクト指向技術については既に第２章で論じた。 そこで、この項では、ソフトウェアの部品化を目指した嵌め込みシステムについて、部品化アプリ再利用システムの検討の一環として行った調査結果の報告をする。
嵌め込みシステムにおいては、図3-1 のような骨組みとなる骨格ルーチン (スケルトン) とそれに肉付けをする補填ルーチンユニット (フックメソッド) からプログラムを構成する。 つまり、骨格ルーチンの中にスロット (最近の言葉を使えばホットスポット) という挿入口を設けておき、そこに適当な補填ルーチンユニットを嵌め込むことによって業務アプリケーションプログラムを完成させる。 これは、骨格ルーチンや補填ルーチンユニットを部品と見立てて再利用することを狙ったものであり、一種のソフトウェアの部品化再利用システムだとみることができる。
図3-1: 骨格ルーチンと補填ルーチンユニット群 (フックメソッド群)
この嵌め込みシステムは、いかにも部品の合成システムだという感じがするので、日本では同種のものがいろいろなところで発案され、それぞれに名前が付けられた。 テンプレート方式とか、部品合成システムとか、穴埋め方式とか、プログラムパラダイムとか、... である。 そして、SSS もこの種のものの一つだと見ることができる。
ところが、SSS 以外の嵌め込みシステムは、大抵は失敗に終わっている。 というのは、嵌め込みシステムには、いわば二つの分かれ道が待ち受けていて、この種のシステムを開発した人のほとんどは、誤った方向に向かってしまったからである。 なぜ誤った方向に向かってしまうのか、調査結果をご披露しよう。
第一の分かれ道では、嵌め込んで合成するツール (部品合成ツール) に重点をおくのか、部品そのものに重点をおくのかという判断が求められる。 この種のシステムの開発者は、部品そのものの重要性を薄々感じてはいても、ひとたびツールの開発を始めてしまうと、開発の楽しさにのめり込んでしまうものである。 こうして、第一の分かれ道で判断ミスをしてしまう。
実際に、嵌め込んで合成するというツールは多くのところで開発されたが、そのツールを上手に使いこなしたという話は聞いたことがない。 その原因は、骨格ルーチンや補填ルーチンユニットという部品の単位をいか様にもできるので、部品の意味が不明確になってしまう点にある。 様々な大きさの様々な役割を果たすプログラムの断片の山を相手にして、それらを整理することに失敗してしまうのである。 整理されていないものはゴミと同じなので、ほとんど役に立たない。 プログラムの断片を部品と呼んでみてもむなしいだけである。
これではいけないと、ツール開発にこだわった人々の中には、嵌め込みシステムの上に部品検索システムを開発するという打開策をこうじた人もいた。 しかし、この部品検索システムはゴミを検索するシステム以上のものにはならない。 たまにはゴミも役立つことがあるが、それだけのことである。 決して、いつでも役立つというわけではない。
ちなみに、部品検索システムは、嵌め込みシステムとは無関係に、共通サブルーチンなどの部品を検索するために開発されたこともある。 これらを含めて部品検索システム一般が失敗に終わってしまう様子を見ておこう。
たくさんの共通サブルーチンなどの部品セットを蓄積したとしても、欲しい部品があるのかないのかはっきりしなかったり、捜し出せなかったりしたとしたら、それは宝の持ち腐れである。 何とかして簡単に捜し出せるようにしたいものだ。 こう考えると、部品検索システムを開発することが必要だということになる。
そこで、部品検索システムを開発するのであるが、これで問題が解決するとは限らない。 実際に数多くのプログラムの断片を蓄積して、さらに部品検索システムを装備して、｢さあ皆さん使いましょう｣ と開店した部品再利用システムの多くは成功していない。 成功しない理由はいろいろあることだろうが、その主な理由は、利用者が欲しいと思う部品を検索しても見つからないことが度重り、そういう“お店”は見向きもされなくなるからなのである。 辞書から切り取った何ページかを辞書と呼んでも、もはやそれは辞書の役割を果たさないのと同様である。 そこには知りたい言葉が載っているとは限らないので、辞書とはみなされないのである。
“欲しい部品は大抵見つかる”という部品の品揃えが部品システムとしての成功の鍵である。 そこまでがんばるのが無理だとしたら、欲しい部品が部品ライブラリの中にあるのかないのか事前に想像がつくような工夫をすることによって、空振りの検索による失望回数を減らすことは、最低の礼儀だと言える。
失敗の原因がこんなところにあるということはほとんど知られていないが、ツールにこだわって失敗した人々やそうした試みが失敗したという事実を知っている人々は、部品検索システムとか嵌め込みシステムと聞いただけで敬遠するようになった。
ちなみに、ウッドランド社は、宣伝のために SSS が嵌め込みシステムであることを強調したが、こうすることで逆に敬遠されてしまい、また誤解されてしまい、マイナスの宣伝になってしまったようである。
第一の分かれ道で正しい方向に向かうには、ツールに重点をおくのではなく、部品そのものに重点をおくことが必要である。
いくら立派な部品検索システムを開発しても、いくら立派な嵌め込みシステムを開発しても、部品倉庫に存在しない部品は検索できないし、嵌め込んで合成することもできない。 繰り返しになるが“欲しい部品は大抵見つかる”という部品の品揃えの方が重要なのである。
このためには、部品をある形に体系化して、それに沿って必要な部品を開発しておき、いつでも使えるように整備しておくことがどうしても必要になる。 たまたま近くに転がっていた部品をかき集めて部品倉庫に格納したのでは、欲しい部品が見つかるようにはならないものである。
機械の部品も電子機器の部品も、みな用途を考えて意図的に作られたものである。 ソフトウェアの部品も同じである。 用途を考えて部品として認められるべく意図的に作られたソフトウェアでない限り、ガラクタかゴミだと思って間違いないだろう。 部品となるように意図せずに開発されたプログラムの断片を数多く収集しても、そういった部品管理システムがほとんど役に立たないことは、多くの人が経験するところである。
第二の分かれ道では、骨格ルーチンと補填ルーチンユニットのどちらを共通部品と見るのかという判断が求められる。 補填ルーチンユニットの方が粒々しているので、この種のシステムの開発者は功をあせって、こちらを共通部品だと思ってしまうようである。 こうした人々は、第二の分かれ道で判断ミスをすることになる。
補填ルーチンユニットの方を共通部品だと見ることは、サブルーチンを共通部品とすることとほとんど同じであり、従来の方法と比べて何の進歩もない。 骨格ルーチンに補填ルーチンユニットを嵌め込むということは、骨格ルーチンが補填ルーチンユニットを呼び出すことを意味する。 逆方向から見ると、補填ルーチンユニットは、骨格ルーチンから呼び出されて何らかの仕事をするものだと言える。 したがって、補填ルーチンユニットは、共通サブルーチンと等価である。
｢共通サブルーチンとは違うのだ｣ と細かいことを言う人もいるが、それならば、アセンブラやＣ言語のマクロ命令の展開に相当するといった方がさらにぴったりと対応するのかもしれない。 要するに既存の技術であり、そこには何の新規性も見出せない。
広い意味での部品の呼出しには、サブルーチン呼出しやマクロ命令の展開やシステムコール (スーパバイザコール)やメッセージパッシングなどいろいろな手段があるが、この種のものの一つに嵌め込みという古典的な手段が追加されただけのことである。
したがって、補填ルーチンユニットの方を共通部品だと捉らえるのでは、新たな生産性向上効果は得られない。 たとえ補填ルーチンユニットを共通部品にすることによって生産性が向上したとしても、それは従来の部品呼出し方法で得られる生産性向上効果だから、嵌め込みシステムの手柄だと見るべきではない。 つまり、その生産性向上効果は、従来から共通部品にできると分かっている部分を再利用することによる効果に他ならないのである。
嵌め込みシステムは、これらの二つの分かれ道で誤った方向に導かれてしまうので、効果を発揮することなく不成功に終わってしまうのが普通である。 しかし、もしも SSS のように第一、第二の分かれ道で正しい方向に向かえば、それなりの効果を発揮するはずである。 すなわち、骨格ルーチンの方を共通部品だと捉らえると、新たな光が見えてくる。 この捉らえ方は、サブルーチンを呼び出す“メインルーチン”の方が実は共通ルーチンであるということであり、これまでなされなかった見方である。 そして、もしも“共通メインルーチン”(最近はフレームワークと呼ばれる) が存在するのならば、それを共通部品にすることによって、これまで見落としていた部分が再利用できるという道が開けてくる。 つまり、従来とは異なるところで生産性向上効果が得られることになるので、この効果は嵌め込みシステムの手柄だといってよいだろう。
その注目すべき“共通メインルーチン”なるものは、一般になじみが薄いと思うが、実際にはいくつかのところに出現していて、生産性向上に寄与してきた。 狭義のフレームワークと呼ぶと、通りがよいかもしれない。 これは、以前に注目された第四世代言語にも使われていたものなので、｢３．２．２ 第四世代言語｣ の中で詳しく説明する。 ここでは、共通メインルーチンになじむために、また感覚的に理解をしていただくために、｢付録４．ものを認識する際の図と地の分離について｣ という参考資料をご参照いただきたい。
第四世代言語 (以後 4GL と略記する) は、第一世代の機械語、第二世代のアセンブラ言語、第三世代のコンパイラ言語に続く言語だといわれているが、必ずしもその名が体を表わしているわけではない。4GL は、汎用性を追求した言語だと捉らえるよりも、むしろビジネス分野に狙いを定めた生産性を向上させるためのツールまたはフレームワークだと捉らえる方が当たっている。
4GL かどうかの判定基準として、エンドユーザにも使えることとか、何日以内に習得できることなどを挙げる文献もあるが、世間一般が認める判断基準にはなっていない。4GL だとそのベンダが言えば、それは 4GL だということになっている。 こうして 4GL の数は、そのベンダの数だけ存在することになり、優に 100 を越えた。
いろいろな種類の 4GL がある中で、この項では、ビジネス分野の特注業務プログラムや業務パッケージの開発に使えるような基幹業務向けの 4GL に的を絞って、部品化アプリ再利用システムの検討の一環として行った調査の結果を報告する。
最先端の CASE と時代遅れの 4GL という風に対比するのは正しくない。4GL は名目的にもちゃんと広義の CASE に含まれるし、時代を経た現在でも大抵の 4GL は生産性の向上に寄与するものである。 あえていうと、4GL はもっぱらビジネス分野の業務プログラム開発の経験に基づいて設計されたものが多く、そこには必ずしも理論的な裏付けがあるわけではない。 言い換えると、なぜ生産性の向上に有効なのかという理由を曖昧のままにして、実質的な効果を上げることに力を入れている 4GL が多かったといえるだろう。
初期の 4GL は、それまでの COBOL などの第三世代言語に改良を加えて、リレーショナルデータベースをうまく使いこなすための言語として生まれた。
この仕様は各社各様だったが、どれも１〜２行の文で目的のデータを検索できるという意味では同じようなものであった。 COBOL ではどうだったかというと、データ検索をするには 10 行 〜 20 行の文が必要だったから、4GL は確かに効果的であった。
また、4GL はデータベースへのアクセスだけでなく、データベースの定義も簡便にした。 COBOL を使う場合には、プログラム中のデータ宣言とデータベースの各データ項目の定義の両方を行うことか必要だったが、4GL ではこの重複定義を行わなくてもよいようにした。
さらに、4GL はデータベース定義の延長線上に、画面や帳票を簡単に定義できるようにする機能を付け加えていった。 なお、こういった機能は、プロトタイプシステムの作成を簡単にする役割を果たすことにもなった。
ところが、このような初期の 4GL の成果は、徐々に第三世代言語にも取り込まれることになった。 リレーショナルデータベースのアクセス法は、SQL として標準化されて第三世代言語の COBOL からも使うことができるようになった。 さらに、リレーショナルデータベース管理システムの機能のおかげで、COBOL によるプログラミングにおいてもデータ宣言の重複定義が不要になった。 こうして第三世代言語と 4GL の差が少なくなってしまい、4GL の存在意義が希薄になっていった。 そこで、このような状況を打開すべく、4GL はイベント駆動方式を採用して巻き返しを図った。
ここでイベント駆動方式はなぜ生産性を向上させるのかを解明しなければならないが、それにはイベント駆動方式とはどんなものであり、それが採用される以前と比較して何がどう変わったのかを理解することが必要である。
まずは一般的な説明から始めよう。 イベント駆動方式とは、あるオブジェクトに関するあるイベントが発生すると、そのオブジェクトのそのイベント種別に対応するイベントプロシージャを動作させる方式のことである。 よくある例を挙げると、オブジェクトとは、画面や帳票またはそれらの中のデータ項目のことであるし、イベント種別とは、操作者のアクションの種別のことだと考えていただきたい。
たとえば、操作者が画面上のあるデータ項目にデータをインプットしたとか、キーボード上のファンクションキーを押したというようなイベントをきっかけにしてイベントプロシージャが動作するのがイベント駆動方式の特徴である。 このように操作者のアクションをイベントに対応づけることで、プログラムが操作者のアクションに反応できるものになる。
イベント駆動方式を採用すると、プログラムの組み方が伝統的な COBOL のプログラミングスタイルとは異なってしまう。 それぞれのオブジェクトのそれぞれのイベント種別に対応する数多くのイベントプロシージャに分割しなければならない。 そして、伝統的な COBOL は、上から下に流れる“ダラダラ”プログラムを作るものだとすれば、イベント駆動方式を採用すると、お呼びがかかると動作する“ツブツブ”の数多くのイベントプロシージャになることになる。
このような説明では、イベント駆動方式を知っている人以外には理解しにくいかもしれないから、イベント駆動方式が採用される以前と比較して何がどう変わったのかをもう少し分かりやすく説明しよう。 なお、プログラミングに関する知識のない方は、ここで前提知識を仕入れるために ｢付録１．プログラムの実行とは｣ をご参照いただきたい。
COBOL で書いたプログラムは、初期の 4GL と全く同様に、メインルーチンの先頭の文から順に実行していき、メインルーチンの終わりの文で終了するという動き方をするものであった。 そして、この基本的な流れに加えて、時にはサブルーチンを呼び出してそれを実行してから戻ってくるとか、ループを描きながら繰り返し文を実行するとか、文を飛び越して進んだり戻ったりとかというような動き方をするものであった。 プログラムに関して少しでも知識のある方なら、このようなプログラムの実行方法は何の変哲もないごく普通のものであることがお分かりいただけるだろう。
COBOL 言語によるプログラミングとは、このような実行方法を前提にして、メインルーチンを構成する文やサブルーチンを構成する文を記述することに他ならない。 したがって、プログラムを開発するときには、既に開発済みのサブルーチンを除外すると、メインルーチンもサブルーチンも開発することが必要であった。
これに対して、イベント駆動と呼ばれる近代的な動作スタイルを採用した後期の 4GL においては、プログラムの実行方法に関して基本的な違いはないのであるが、プログラムが数多くの断片から構成される点に大きな違いがある。 そして、これに伴い各断片の実行の契機があらかじめ決められているという点も異なる。 ここで各断片とは、正式にはイベントプロシージャと呼ばれるものであり、いわばイベントを契機として呼び出されるサブルーチンのようなものである。 これが呼び出されて実行するのは、たとえば画面上のある項目にデータがインプットされたときというように、ある特定のイベントを契機とするように決められている。 実際に、その決められたイベントが起きると、それを処理する役割のイベントプロシージャが呼び出されて、断片的にチョロッと実行することになる。 このようにイベントプロシージャ (サブルーチン) の呼び出される契機が決められているという点は、従来なかったものである。
ところで、イベントプロシージャが呼び出されるということは、何かがそれを呼び出しているはずである。 この何かのことを 4GL の操作ベースと名づけることにする。 こう命名すると、4GL の操作ベースがイベントプロシージャを呼び出すという言い方ができるし、 4GL の操作ベースが各イベントプロシージャの実行の契機を決めているということができる。
これらを前提にすると、イベント駆動のプログラムを開発するということは、 4GL の操作ベースという共通メインルーチン (狭義のフレームワーク) から呼び出されるイベントプロシージャだけを開発すること、すなわちサブルーチンだけを開発することを意味する。
ここで注目していただきたいのは、従来はメインルーチンもサブルーチンも両方とも開発することが必要だったが、イベント駆動のプログラムではサブルーチンだけを開発することになったという変化である。
そして、この変化が生産性を向上させることになったである。 すなわち、以前までは当たり前のように開発していたメインルーチンが、イベント駆動方式を採用することによって、不要になるので生産性を向上させることになるのである。 なぜ不要になるのかというと、 4GL の操作ベースがメインルーチンの役割を果たしてくれるからである。
4GL、すなわち第四世代言語という名前は、素晴らしい言語仕様を持っているかのような印象を与える。 しかし、その名前に似合わず、後期の 4GL は、その言語仕様にさしたる特徴がない。 市販の 4GL の言語仕様を詳しく調べてみると、COBOL などの第三世代の言語仕様と比べて本質的な違いがないことが分かる。 たとえば、COBOL の IF 文に相当する文が 4GL を使うと簡略化されるわけではない。 逆に、COBOL では１行の CORRESPONDING MOVE 文を記述するだけでたくさんのデータを一括して移動できるのに、このような便利な機能を言語仕様として備えていない 4GL もある。 このような比較検討をすると、市販の 4GL の言語仕様は第三世代言語とそう違いがないという事実を確認できる。
それにもかかわらず、4GL を使うと確かに生産性が向上するのである。 筆者には、これが不思議でならなかった。 この理由は、部品化アプリ再利用システムの検討の中で 4GL と同様の機構を試しに設計した際にやっと分かった。 その理由とは、既にお話したとおり、 4GL の操作ベースのおかげで、メインルーチンを開発しなくて済むようになったからなのである。 4GL の操作ベースを調べてみると、それは操作性に関係する処理を行っていることが分かるから、業務プログラムの操作仕様に関係するプログラムを書かなくて済むために生産性が向上すると言い換えてもよいだろう。 つまり、4GL の操作ベースが共通メインルーチンとなって、操作性に関係する処理を代行してくれるおかげで生産性が向上するのだ。
4GL には、このようなメリットがある一方、その構造からくる次の問題をはらむことになった。 それは、4GL を用いて開発した業務プログラムは、その操作性を少し変えたいと思っても簡単には変えられないことが多いという問題である。
4GL は、もっと広く使われ、主流になっていてよいように思うのであるが、必ずしもそうなってはいない。 この理由を探ってみよう。
市販の 4GL の利用者がしばしば問題にするのは、ほんのちょっとしたところなのであるが“自由がきかない歯がゆさ”である。4GL のサポート範囲からちょっとでも外れた使い方をしようとすると、完全に拒否されてしまう。 このために ｢4GL は懲り懲りだ｣ と嫌われることがしばしばある。 ある開発者が次のように言っていた。
｢4GL を用いて開発した業務プログラムをテスト中に、お客様から操作性を少し変更せよと要求された。 それは、4GL では実現できないものだったので、無理だとお客様に説明した。 しかし、分かって貰えず、結局は要求を満たさざるを得なくなった。 このために、急遽 4000行ほどのプログラムを休日返上で開発しなければならない羽目になった。 最初から COBOL で組んでおけば、こんな目にあわずに済んだのに。｣
この 4GL の典型的な問題点は、｢画面スタイルがその 4GL 固有のものになってしまう｣ と表現されることもある。 画面スタイルには、画面の図柄やそのレイアウトや操作性が含まれるが、特に操作性が固定されてしまう。 これは操作性を統一することになるので良いようにも思われる。 しかし、一般に 4GL は欧米で開発されたものがほとんどで、日本で育まれた木目細やかな操作性を実現できないために、4GL を使って開発した業務プログラムの操作性に違和感を持つ人が多いのも事実である。
なぜ 4GL では操作性を簡単には変えられないのかというと、 操作性に関係するプログラム (すなわち 4GL の操作ベース) は、 4GL の内部のインタープリタまたはプログラムコードの生成部にいわばワイヤードロジックのように固く組み込まれているからである。 これを変更するには、通常は 4GL 自体をプログラムカスタマイズすることが必要である。 しかし、4GL のベンダがこの変更要求にタイムリに応えてくれることはないといってよいだろう。
もう一つの大きな問題点は、4GL の仕様は各社まちまちで、標準化されていない点である。 少なくとも言語仕様だけでも標準化されるべきだと思うのであるが、この常識が通用しない。 バベルの塔の話のように、言語がばらばらにされているのだから、困ったことである。4GL を使用するには、どれか一つの言語を選択して、その新たな言語仕様を覚えなければならない。 したがって、市販の 4GL を採用したいと考えても、非標準の言語仕様に躊躇してしまう人も多いようである。 バベルの塔の罰を受けてまで、混乱した言語を使うという気にはならないものである。
これまでの考察で分かるように、4GL のミソは、操作性に関係する処理を行う 4GL の操作ベースにあるのである。 したがって、それをより良いものにしようとするベンダ間の競争のために仕様に違いが出てくるのは、必要悪だと割り切ることができる。 しかし、IF 文の書き方のような言語仕様までも各社各様にする必要はないはずである。 疑いの目でみると、4GL ベンダは、ユーザを囲い込んで逃げられないようにするために独自の言語仕様を制定しているのだと見ることができる。
コンピュータの世界ではオープン化の波が起こり、ベンダのビジネス上の都合を優先させるだけではいけないといわれる時代になった。 したがって、プロプライアトリな言語仕様にこだわり続けると 4GL は使われなくなっていきそうである。 そこで、オープン化の流れに積極的に沿って、オープンな 4GL にしていく努力が求められる。 そして、オープン性を追求していくと、標準化された言語仕様の上に操作性に関係する処理を行う共通メインルーチン (狭義のフレームワーク) を作ればよいという結論になるはずである。
この件に関して大胆な意見を言わせていただくと、4GL という名前は、言語仕様が優れているという誤った印象を与えるので、よくない。4GL は発展的に解消して速やかに ｢共通メインルーチン (狭義のフレームワーク)｣ へと変身するのがよいと思う。 なお、こうなったとしても 4GL の名はビジネス分野の業務プログラム開発の経験を踏まえて実質的な効果を上げたフロンティアとして歴史に残ることだろう。 したがって、古い名前はきっぱりと棄てて、名実ともに分かりやすいオープンな ｢共通メインルーチン｣ へと変身することを期待する。 そういったフロンティアスピリットこそ尊重されるべきである。
ここで、嵌め込みシステムを思い出していただきたい。 詳しく比較するまでもなく、イベント駆動方式を採用した 4GL と嵌め込みシステムとは、非常によく似ている。 呼出し関係を比較してみると、4GL の操作ベースが骨格ルーチンに対応し、イベントプロシージャが補填ルーチンユニットに対応している。
最も重要な類似点は、これらはどちらも共通メインルーチン (狭義のフレームワーク) を再利用する仕組みであるという点である。 イベント駆動方式を採用した 4GL においては、その 4GL で記述したどのプログラムも、 4GL の操作ベースをメインルーチンとすることになる。 したがって、この種の 4GL は、4GL の操作ベースという共通のメインルーチンを再利用する仕組みであるとみることができる。 嵌め込みシステムにおいても同様である。 繰り返しになるが、嵌め込みシステムは、骨格ルーチンの方を共通のメインルーチン (共通部品) だと捉らえて、それを再利用することによって、生産性を向上させているのである。 つまり、嵌め込みシステムも、共通メインルーチンを再利用する仕組みに他ならない。
共通メインルーチンが果たす役割や機能について見てみると、 4GL の操作ベースは、主に操作性に関係する処理を行っていた。 もう一方の、嵌め込みシステムの中の骨格ルーチンとして広く共通に使われているものを調べてみると、やはり操作性に関係する処理を行っているものが多いことが分かる。 すなわち、役割や機能についても似ている。
なお、共通メインルーチンは、操作性に関係する処理の他にもいくつかの処理をするものがある。 たとえば、イベントプロシージャや補填ルーチンユニットを呼び出す処理は、いうまでもなく共通メインルーチンの役割である。 また、データベースのアクセスを行うものもある。 データベース系ツールと呼ばれているものは、ある限定した使い方をする限り、データベースのアクセスに関するプログラムを手作りしなくて済むようにする。
ところで、GUI アプリケーションプログラム向けのビジュアル開発支援ツールは、イベント駆動方式を採用しているのが普通である。 こうしたものを調査してみると、GUI の操作ベースも 4GL の操作ベースと同じような役割を果たしていることが分かる。
したがって、以下の三つのプログラムは､“共通メインルーチン”であり、その主な役割は操作に関係する処理であるということができる。
・ SSS の中の操作仕様に関係する操作ベース
・ 4GL の操作ベース
・ GUI の操作ベース
RRR ファミリーの開発の前に行った部品化アプリ再利用システムの検討の中では、SSS という嵌め込みシステムを見直して、どこが優れていたのかを再評価した。 そして、4GL やビジュアル開発支援ツールのイベント駆動方式と比較して、それぞれのツールの良いとこ取りをすることにした。 ここでは、これらを詳しく説明する。
嵌め込みシステムには、いわば二つの分かれ道が待ち受けていて、大抵は誤った方向に向かって失敗に終わっていることは既に述べたとおりである。 そして、正しい道に行けばそれなりの成功をおさめる。 ところで、SSS という嵌め込みシステムは幸運にも正しい方向に向かうことができた。 そして、並みの成功ではなく大変な成功をおさめることになる。 何が幸いしたのか、ここで振り返ってみよう。
ウッドランド社が SSS 開発のために行った研究では、同社がオフコンのディーラとして顧客に納入した万を越える業務システムを研究材料にした。 具体的には、その中で最も多くの実績をもつ販売管理システムを題材にして研究したのである。 この研究の状況やその中で生まれたアイデアなどについて述べよう。 これは ｢１．３ 特注対応業務パッケージ｣ の中の次のパラグラフを再度掲載し、その続きとして説明するのがよさそうだ。
もしも、共通仕様に関係するプログラム部分は共通にして、各社各様の仕様に関係するプログラム部分だけを各社各様にできれば、特注業務プログラムの開発作業を合理化することになる。 しかし、これは言うは易く行うは難しである。 共通部分と各社各様の部分の間に明確な線引きがなされているわけではないし、この線引きが簡単にできるというわけでもない。 したがって、どこが各社各様の部分だといわれても対処できるような備えが必要であり、プログラムと仕様との対応関係を根本から見直さなければならなかった。
この見直し作業において、部品合成ツールの検討をしたのではなく、実際に動作する販売管理システムを詳細に調べて、そのプログラムに線引きを施し分割して部品にしようと考えた。 このことによって､“嵌め込みシステムの第一の分かれ道”で、ツールに重点をおくのではなく、部品そのものに重点をおくという正しい道に向かうことができた。
本書では、SSS や RRR ファミリーという製品に代表される部品化再利用システムに部品化アプリ再利用システムという一般名称を付けている。 これは､“部品化アプリを再利用するシステムである”という意味を込めての命名である。 では、部品化アプリとは何かというと、あるアプリケーションプログラムに線引きを施して、切れ切れにされたもののことである。 つまり、切れ切れの部品に砕かれた (すなわち部品化された) アプリケーションプログラムのことを意味している。 そして、うまい具合に切れ切れの部品にできれば、ここが重要なのでなるが、そうした部品化アプリは再利用しやすいものになるはずである。 これが、部品化アプリ再利用システムの命名の由来である。
さて、1988 年に行ったプログラムと仕様との対応関係の見直しの中である線引きのアイデアが浮かんだ。 それは、業務仕様に関係するプログラムと操作仕様に関係するプログラムの間に線引きをしたいという希望から生まれたアイデアである。 もしも、これが実現できれば、SSS 開発のための研究の見通しが良くなるはずだと期待をかけたのである。
操作仕様とは、業務プログラムの操作性に関する仕様なので、A 社向けも B 社向けも基本的に同じにしてよいはずである。 したがって、操作仕様に関係するプログラムは共通にできるはずである。 これに対して、業務仕様の方は、共通部分もあれば各社各様の部分もある。 したがって、業務仕様に関係するプログラムは、カスタマイズの必要性がある部分なのである。
これらを総合すると、この線引きができれば、カスタマイズの可能性が高い部分をある範囲のプログラムだけに絞り込めるはずだという確信が得られた。
ところが実際のプログラムを見ると、業務仕様に関係するプログラムと操作仕様に関係するプログラムはごちゃ混ぜ (混雑) 状態になっている。 したがって、これを分離するには大手術 (最近の言葉を使うとリファクタリング) が必要であった。 この手術では、整形、並べ替え、汎用化などのテクニックを用いた。 この手術は、いわば本書の章建てを何回も変更して少しでもすっきりした形のしようともがいたようなもので、その中身の話をしても面白くないし、細かくなりすぎるのでここでは省略させてもらう。 とにかく手術後の状態を見たところ、操作仕様に関係するプログラムが骨格ルーチンになり、業務仕様に関係するプログラムが補填ルーチンユニットになっていた。
骨格ルーチンの方は、操作関係するプログラムだから、共通にできるはずの部品に当たる。 したがって、骨格ルーチンと補填ルーチンユニットのどちらを共通部品と見るのかという“嵌め込みシステムの第二の分かれ道”で、SSS は図らずも正しい方向に向かうことができたのである。
こうして、嵌め込みシステムの一つであった SSS は、共通メインルーチンを再利用する仕組みを装備するものになった。 すなわち、イベント駆動方式を採用した 4GL と同様に、操作性に関係する処理を行うメインルーチンを再利用することによって、生産性を向上させるものとなったのである。 そして、カスタマイズの可能性が高い部分は、補填ルーチンユニットに書かれる業務仕様に関係するプログラムだけになるように絞り込むことができた。
本書では“欲しい部品は大抵見つかる”という部品の品揃えの必要性を強調した中で、部品をある形に体系化して、それに沿って必要な部品を開発しておき、いつでも使えるように整備しておくことが重要だと述べた。 要するに、何の考えもなく勝手に ｢これが部品だ｣ と決めていったのでは、部品というものをどう捉らえてよいのか分からなくなり、混乱に陥るだけだ。 欲しい部品があるのかどうかも分かり難くなり、大勢の人々にとって使いやすい部品にはならない。 整然と部品を利用できるようにするには、部品を区切る強力な分割指針を打ち立てて、それに沿って部品をある形に体系化して、その体系に沿って必要な部品を開発しておくことがどうしても必要になる。
これに関係して、本書では、部品化再利用システムというものをどのように捉らえているのかという思想のようなもの、あるいは立場というべきだろうか、を明らかにしておきたい。 たとえば、販売管理のアプリケーションプログラムを部品合成できるような部品化再利用システムを設計する場合に、本書では、その部品の元になるものは実際に動作する販売管理のアプリケーションプログラムの中に存在するはずだという考え方をとっている。
ここで誤解のないように注意が必要である。 実際に動作する販売管理のアプリケーションプログラムは、スパゲッティ状態かもしれないから、それに適当な線引きを施して区切られた塊を取り出してきても、とても部品と言えるものにはならないことだろう。 したがって、線引きをして分割するだけでなく、細工・整備・整形・並べ替え・汎用化といった、いわば内臓の器官を器官らしく整える手術 (リファクタリング) が必要になるといって間違いない。 そして、もしも販売管理のアプリケーションプログラムにこのような手術をうまく行うことができれば、奇麗に分割できるようになり、分割されたそれぞれが“部品そのもの”または“部品の元”になるのだ。 つまり､‘ビジネスロジック部品’とは、このようなものだと考えているのである。 さらに付け加えると“部品そのもの”または“部品の元”というあいまいな表現をしたのは、そこには追加の部品が必要だろうし、機能を汎用的にすることも必要だろうし、また部品合成時に何らかの調整処理が必要かもしれないという含みをもたせただけのことである。 基本的には、うまく手術しさえすれば、分割されたそれぞれが“部品そのもの”となり、これが‘ビジネスロジック部品’になるはずである。
要約すると、販売管理のアプリケーションプログラムをうまく手術して奇麗に分割すると、それは販売管理の部品化アプリになり、それをカスタマイズして A 社向けの販売管理システムにしたり、B 社向けの販売管理システムにしたりすることが、すなわち再利用することが、簡単にできるようになるという考え方なのである。 そして、SSS は正にこのような実例に他ならないのであり、この考え方を裏付けるものである。
これと同様に、生産管理のアプリケーションプログラムをうまく手術して奇麗に分割すると、それは生産管理の部品化アプリになり、それをカスタマイズして A 社向けの生産管理システムにしたり、B 社向けの生産管理システムにしたりすることが、すなわち再利用することが、簡単にできるようになるはずである。
本書の考え方はこうなのであるが、これとは別の部品化再利用システムの捉らえ方をするとどうなるだろうか？ たとえば、部品の合成に重点をおくとか、部品の検索に重点をおくとか、前述した失敗事例とは別の何らかの形があり得るかもしれない。 そして、ひょっとすると、そうしたものを追求すれば何か成果が得られるかもしれないが、よく見えない。 見えないものを試すことはできないので、本書では、部品化再利用システムは、部品化アプリ再利用システムという形態にする他はないという立場にたった。 なお、この考え方が実際に効果をあげることは、SSS という事例によって実証されている。
これらを総合すると、少なくとも本書のように捉らえることは意味があり、このように捉らえた場合には、部品を区切る強力な分割指針が部品化再利用システムを出来不出来を左右する重要なキーだと言っても過言ではない。
そこで、部品を区切る分割指針という観点から SSS を評価してみよう。
SSS 部品セットは、二つの分割指針のもとに‘ビジネスロジック部品’の個々の粒々に分割されている。 一つの分割指針は、この手前の ｢SSS という嵌め込みシステムの場合｣ で述べた業務と操作の分離である。 もう一つの分割指針は ｢１．３ 特注対応業務パッケージ｣ の中で述べたデータ項目対応の分割である。 つまり、業務仕様に関係する補填ルーチンユニットをデータ項目に対応づけて分割するという分割指針である。
最初の“業務と操作の分離”という分割指針は、SSS 部品セット独特のものではなく、4GL などの他のツールでも採用されているので、この分割指針の効果は広く認められているといってよいだろう。 この指針によって、共通メインルーチンを再利用して生産性を向上させることができるし、またカスタマイズの可能性が高い部分をある範囲のプログラムに絞り込むこともできる。
もう一つの“データ項目対応の分割”という分割指針は、ビジネス分野ではデータ項目名によって仕様変更要求が表現されるという特徴をうまく捉らえたものである。 本書は、この分割指針によって実用的で効果的な部品化再利用システムを構築する道が開けたということを ｢１．３ 特注対応業務パッケージ｣ の中で強調した。
ここで、その重要部分を繰り返しておこう。 この分割指針に沿って分割したデータ項目部品は、業務仕様との対応関係が明快になり、それだけで意味の分かる閉じた塊になり、ほとんどは 100 行以下になり、類型的で解読しやすいものになった。 そして、それぞれのデータ項目名で始まる名前を付けることで検索しやすいものにすることができた。 これらのことから、アプリケーションプログラムを部品と呼べるような塊、すなわちデータ項目部品に分割できたのである。 これは並みの成功以上の成功であった。
データ項目対応の分割という分割指針は、一見するとビジュアル開発支援ツールも遵守しているように思われるが、肝心な点が今一歩であった。 調査した範囲では、SSS 部品セットのように、この分割指針に、バカ真面目と言えるほど徹底的に従っているものはなかった。 SSS 部品セットは、この点において突出したものだったのだ。 なお、この点は重要なので、この少し後の ｢部品を区切る分割指針に関する改善点その２｣ でさらに詳しく説明する。
ちなみに、部品を区切る分割指針に関係して、再利用のしやすさでは定評のある Smalltalk システムを見ると、階層をなすオブジェクト群の構成を決めるために、MVC (model view controller) の三つに分割するのだという指針を採用している。 そして、この分割指針の重要性がしばしば指摘されている。 この種の分割指針にこそ本質が含まれている。
RRR ファミリーは、SSS の後継製品に位置づけられる部品化アプリ再利用システムとして、1995 年から本格的な開発を行った。
SSS では部品セットと部品合成ツールとが未分化なところがあったという反省から、RRR ファミリーではこれらを明確に分けた。 本書では、前者を RRR 部品セット、後者を RRR ツールと呼んで区別することにする。
図3-2: RRR ファミリーの構成要素と部品合成
図3-2 のように、RRR ファミリーに属する各製品、たとえば RRR 販売管理は、RRR 部品セットの一つ (RRR 部品セット販売管理) と RRR ツールから構成される部品化再利用システムである。 RRR 部品セットは、特定の業務プログラムを構成するために必要な一群の部品セットであり、RRR 販売管理用には RRR 部品セット販売管理を用いるし、RRR 財務会計用には RRR 部品セット財務会計を用いる。 そして、RRR 部品セットのそれぞれの部品は本書で論じる‘ビジネスロジック部品’の代表例になっている。
RRR ファミリーの開発する上では、SSS という嵌め込みシステムと、イベント駆動方式の 4GL やビジュアル開発支援ツールなどとの比較をして、それぞれの優れている点を採用した。 以下では、このような比較をして得られた結果のうちの主な二つ、すなわち部品の呼出し機構と部品を区切る分割指針について説明する。
部品の呼出し機構については、以下のように、イベント駆動方式のツールの方が嵌め込みシステムよりも優れていた。
一般に嵌め込みシステムでは、嵌め込むべき補填ルーチンユニットの個数に依存して、骨格ルーチンの一部を修正することが必要になる。 すなわち、嵌め込むべきユニットが存在しない場合にはスロットを削除したり (あるいはダミーのユニットを嵌め込んだり) することが必要であるし、嵌め込むべきユニットの数が多い場合にはスロットを増設することが必要である。 ところが、イベント駆動方式においては、こういったことが一切不要である。
したがって、この点に関しては、古典的な嵌め込みシステムではなく、より近代的なイベント駆動方式を採用したことは言うまでもない。 なお、イベントプロシージャの呼出しの際のパラメタについては、ビジュアル開発支援ツールでは固定的だったが、これに改良を加えて、RRR ツールでは自由度の高いものにした。
部品を区切る分割指針を見ると、基本的には、イベント駆動方式を採用しているツールも嵌め込みシステムも次の二つの分割指針を採用しているようにみえる。 その一つは業務と操作の分離であり、もう一つはデータ項目対応 (オブジェクト対応) の分割である。 ただし、分割指針にどのくらい忠実に従っているかという点において、部品化アプリ再利用システムの理想とするところと大きな隔たりがあった。
業務と操作の分離という分割指針は、特にビジュアル開発支援ツールはどれも、忠実には守られていない。 ビジュアル開発支援ツールは、業務と操作の分離がかなりあいまいになってしまっていて、むしろハードウェア装置の動作を細かく制御可能にすることの方が優先されている。
たとえば、ビジュアル開発支援ツールのイベントの代表例には、GUI コントロール上でのマウスクリックやキーボードのキーの押下などがある。 これらは、業務と操作の分離というより、ハードウェア装置をアプリケーションプログラムから思い通りに制御するのに都合がよいイベント体系だという方が当たっている。 具体的に言うと、キーボードのキーを押したときと離したときにそれぞれ別の処理を可能にするために、これらの区別ができるような細かなイベント体系になっているし、また１文字インプットするごとに頻繁にイベントが発生するようになっている。 このようなローレベルのイベント体系では、たとえば、キーボードを用いた文字のインプットを主体に取り扱うアプリケーションプログラムを作ろうとすると、イベントプロシージャの中に記述する業務仕様に関係するプログラムよりも多くの行数の操作性に関するプログラムを混在させて記述しなければならないような状態に陥る。 これでは業務と操作の分離という分割指針に従っているとはとてもいえない。
ただし、このようなローレベルのイベント体系であっても、見方によっては、ある程度の分離ができているといえる。 たとえば、扱いやすい GUI 操作のアプリケーションプログラムの開発をとりあげると、操作性に関するほとんどの処理は GUI の操作ベースにまかせることができるので、イベントプロシージャとしては主として業務に関するプログラムだけを記述すればよいようになっている。 一般にビジュアル開発支援ツールは、ユーザの多数派を占めるホビープログラマを対象にした機能を装備して、売上本数をかせいでいる。 こうしたホビープログラマ向けの機能を使うと、｢ボタンをクリックするとハトが出ます｣ というような玩具のようなプログラムであれば、非常に簡単に組める。 したがって、この種の簡単なプログラムに対しては、業務と操作の分離という分割指針が遵守されていることが分かる。
ところが、ビジネス分野ではよくあるキーボードからのインプットの処理を行うプログラムに対しては、上で述べたように業務と操作の分離という分割指針はほとんど無視されている。 たとえば、カーソルの移動を矢印キーで操作できるのが常識だと思うのであるが、こうするには業務処理を記述はずのイベントプロシージャとして、矢印キーの操作に関するプログラムを記述しなければならない状態なのである。
図3-3: ローレベルのイベントと高級イベント
RRR ファミリーは、ビジュアル開発支援ツールの上に構築しようと考えていたので、図3-3 のように高級イベント (ハイベルイベント) と名づけたイベント体系をローレベルのイベント体系の上に構築することにした。 そして、高級イベント体系は、業務と操作の分離という分割指針に忠実に従うようにした。
たとえば、ビジュアル開発支援ツールでは、画面上の項目に１文字でもインプットがあるとイベントが発生するようになっているのに対して、高級イベント体系では、画面上のある項目にインプットされたデータをチェックすべきタイミングをイベント (高級イベント) にした。 こうすれば、どのような場合にデータのチェックが必要かを判断するプログラムが不要になる。 これをわずかな改善だと思われるかもしれないが、こういった判断をするプログラムなどの細々したものを集計すると、これらの操作性に関係するプログラム (狭義のフレームワーク) の行数は、業務処理に関係するプログラムよりも多くなる。 したがって、ハードウェア装置を細かく操作するのに都合のよいイベント体系ではなく、業務処理に都合のよい高級イベント体系にすることは大きな違いなのである。 高級イベント体系を用いることで、業務処理に関係のない部分はプログラミングが不要になり、高級イベントプロシージャのプログラム行数が少なくなるし、分かりやすいプログラムになる。
要するに、ローレベルのイベント体系は、操作性に関係するプログラムと業務に関係するプログラムが混在しがちである。 これに対して、高級イベント体系は、操作性に関係するプログラムが混在しにくいインタフェースであり、操作性に関係するプログラムを記述しなくて済む。 そして、その分だけ、業務に関係する部分のプログラム行数が少なくなる。
こういった効果が得られる理由は、次のように解釈することもできる。 ハードウェア装置に密着したローレベルのイベント体系は、ビジネスシーンに登場するイベントとのギャップが大きいために、これらの間を埋めるためのプログラムを大量に必要とする。 そこで、ローレベルのイベント体系ではなく、ビジネスシーンに登場するイベントに近いところに高級イベント体系を設ければ、ギャップが小さい分だけ必要なプログラム行数が少なくなるし、分かりやすいプログラムになる。
高級イベント体系は、このような効果が得られる反面、ハードウェア装置の細かな制御がしにくくなる。 この点に関しては、ビジネス分野の業務プログラムではほとんど気にしなくてよいのであるが、この点に関係した次の問題がある。 それは、ハードウェア装置の細かな制御を行うプログラムが固定化されることで、操作性などが固定化されてしまうという問題である。 これは、一般の 4GL で“自由がきかない歯がゆさ”と表現されたあの問題に他ならない。 なお、この問題にどう立ち向かったかについては、｢トピック 6： 部品化イベント駆動方式を実現したツール｣ で述べる。
高級イベント体系に関して問題があるかもしれない点としてもう一つ気になったのは、実際のビジネスシーンに登場するイベントへの対応力であろう。 ローレベルのイベント体系は、細かなイベントから構成されているので、それらを組み合わせることで、どのようなビジネスシーンにも対応できることがこれまでの経験で分かっている。 これに対して、果たして、それほど細かくない高級イベント体系でだいじょうぶなのかという点が気になる。 しかし、これに関しては、これまでのところ (初版執筆時点で３年ほどの間、改訂時点では７年の間) 問題にならずに、高級イベントプロシージャの組合せによって、いろいろなビジネスシーンに対応できている。 今後、対応できないようなものに出くわす可能性がゼロとはいえないが、もしも対応できなければ、現状のイベント体系に新たな高級イベントを追加するという方法もとれる。 したがって、ビジネスシーンへの対応力については、問題ないのである。 このことは、高級イベント体系に近い体系が採用されている 4GL において、この種の対応力に関する問題が発生していないことからも、裏付けられる。
業務と操作の分離という分割指針に関する話がだいぶ長くなったので、ここでまとめておく。 ビジュアル開発支援ツールでは、この分割指針が忠実には守られていない。 そこで、RRR ファミリーでは、ビジュアル開発支援ツールのローレベルのイベント体系の上に高級イベント体系を構築して、業務と操作の分離という分割指針に忠実に沿うようにした。
イベント駆動方式を採用しているツールおよび嵌め込みシステムの部品を区切る分割指針を見ると、業務と操作の分離に近い指針の他に、データ項目対応 (オブジェクト対応) の分割という分割指針を採用しているようにみえる。 ただし、分割指針にどのくらい忠実に従っているかという点においては、部品化アプリ再利用システムの理想とするところと大きな隔たりがあった。
一見すると、4GL もビジュアル開発支援ツールも、データ項目対応の分割指針に沿っているようにみえる。 すなわち、あるデータ項目に関するあるイベントが発生すると、そのデータ項目のそのイベント種別に対応するイベントプロシージャが動作するようになっている。 したがって、イベントプロシージャは、データ項目ごとに作成することになっていると。 正確には、データ項目とイベント種別の組合せごとに作成するのであるが、同じデータ項目に関するイベントプロシージャは同じグループに属するものと考えれば、正にデータ項目ごとに分割されていることになる。
ところが、肝心なところが欠けていた。 データ項目部品を形成するための重要なイベント、すなわちアップデートプロパゲーション (更新伝播) に関するイベントが欠落していたのである。 この欠落のために、イベントプロシージャのデータ項目ごとの区切りがぼやけていた。
この具体例として、ビジュアル開発支援ツールを用いて、商品の受注計上データのインプット支援を行うプログラムを開発する場合を考えていただきたい。 すなわち、図3-4 のような画面をもつ業務プログラムを作ろうというのだ。 この画面では商品コードというデータ項目にデータが入力されると、商品コードに関するあるイベントプロシージャが動作することになる。 そのイベントプロシージャの中では、インプットされた“商品コード”が商品マスタファイルにあるかどうかをチェックするだけでなく､“商品名称”や“商品単価”の表示処理を行うのが普通である。 ここで問題なのは､“商品コード”のイベントプロシージャの中で“商品名称”とか“商品単価”のような他のデータ項目の処理までも行ってしまうということである。 したがって、データ項目ごとの区切りがぼやけているのである。
図3-4: ビジュアル開発支援ツールを使った業務プログラム
こうすると、いろいろと不都合がある。 たとえば、商品のキャンペーンのために、ある期間だけ“商品単価”を２割引にするようなカスタマイズを行う場合には、商品コードに関するイベントプロシージャを変更しなければならなくなる。 商品単価に関するカスタマイズなのだから、商品単価に関するイベントプロシージャを変更するようにしたいのであるが、そうはいかないのである。 また、このイベントプロシージャは、商品コードと商品名称と商品単価の三つだけが登場する画面にしか使うことができないので、再利用できる局面が限られている。 できれば、商品コードと商品名称の二つが登場する画面にも再利用したいし、商品コードと商品名称と商品単価と商品賞味期限の四つが登場する画面にも再利用したいのであるが、そうはいかないのである。
これらの不都合は、みなデータ項目ごとの区切りがぼやけているために起きる問題である。 したがって、データ項目ごとの区切りを明確にすることが必要になる。 このためには、商品コードに関するイベントプロシージャの中では、インプットされた“商品コード”が商品マスタファイルにあるかどうかをチェックする以外の他のデータ項目に関する処理をしてはならないのである｡“商品名称”や“商品単価”の表示処理は、それぞれ商品名称や商品単価のイベントプロシージャの中で行うようにすべきなのである。
このためには、他のデータ項目の値の変化を契機としてイベントプロシージャを起動する機構が必要になる。 つまり、アップデートプロパゲーションの機構が必要なのである。 この機構を実現するために、図3-3 のように高級イベントと名づけたイベント体系をビジュアル開発支援ツールのローレベルのイベント体系の上に構築することにした。 そして、高級イベント体系の中に、特別な高級イベントを追加し、アップデートプロパゲーションの機構を利用できるようにした。
この結果、SSS 部品と同様にデータ項目ごとの区切りのよいデータ項目部品にすることができた。 上で述べた不都合がすべて解消した上で、次のようにすることによって開発作業の負荷を軽減した。 すなわち、SSS の場合にはアップデートプロパゲーションの処理を行うプログラムを手作りする必要があったのであるが、RRR ツールではこのプログラムを自動生成するようにした。
なお、このアップデートプロパゲーションの処理を自動化するにあたっては、数学の一分野の有向グラフの理論を活用して、無駄な呼出しが起きない方式 (Width First 方式) を採用した。
4GL やビジュアル開発支援ツールのイベントプロシージャは、データ項目対応の分割という分割指針に忠実に従っていないので、残念ながら部品と言えるようなものではない。 しかし、イベントプロシージャを RRR 部品セットのように忠実にデータ項目対応に分割したものにすると、まとまりがよくなるし、いろいろな局面で再利用できるものになる。 部品としての価値が生じて､‘ビジネスロジック部品’と言えるようなものになる。 そこで、一般のイベント駆動方式を改良して、イベントプロシージャが部品としての価値をもつようにしたものを部品化イベント駆動方式と呼ぶことにする。
4GL やビジュアル開発支援ツールのイベント体系を評価してみると、どんなプログラムでも作れるようにすることを第一に考えるためか、必ずしもイベントプロシージャが作りやすくはなっていない。 これに対して、部品化イベント駆動方式のイベント体系を設計するにあたっては、イベントプロシージャが作りやすく、かつカスタマイズしやすくなることに重点を置いた。 そして、このためには、アップデートプロパゲーションの機構が必要だったということなのである。
トピック 6： 部品化イベント駆動方式を実現したツール
RRR ツールについては、ウッドランド社とアプリテック社とで分担開発した。 すなわち、ビジュアル開発支援ツールに機能をアドオンして、あたかも部品化イベント駆動方式を採用したツールように変身させるところはアプリテック社が開発して、これ以外のデータベースのアクセスに関わる部分などのすべてはウッドランド社が開発した。
ここでは、アプリテック社がマイクロソフト社の Visual Basic というビジュアル開発支援ツールのアドオンツールとして開発した MANDALA (マンダラ) のご紹介をする。
RRR ツールの中核に位置づけられる MANDALA には、上に述べたように部品化イベント駆動方式を採用した。 また、業界標準と言えるような Visual Basic のアドオンツールにすることによって、MANDALA 自体の開発負荷を軽くした。 もしもツールに必要なすべての機能を独自に開発するようなことをすると、開発スピードも落ちるし、環境の変化に素早く対応できなくなる。 生産性を上げるためのツールが、それ自体の開発の重さに失速してしまい、ユーザに対して“はしごをはずす”ことになり、多大な迷惑をかけた事例は数多くある。 したがって、そんなことにならないように、開発の軽いアドオンツールにして、ビジュアル開発支援ツールに欠ける機能だけを開発することにした。
そして、MANDALA を設計するにあたって次の四点に注意を払った。
・ ビジュアル開発支援ツールに含まれていない 4GL の機能をすべて取り込む
・ 操作性の変更要求 (カスタマイズ要求) に対処しやすい構造にする
・ GUI の見栄えの良い操作だけでなく従来どおりのキーボード操作も可能にする
・ 標準となった言語仕様を用いる (ローカルな言語仕様はつくらない)
このようにして、MANDALA に 4GL の有用だと思われる機能はすべて盛り込んでオープンな最高のツールにすることを目指した。 たとえば、これを使って作った画面アプリでは、データベースへのデータの追加だけでなく参照・更新・削除の処理も行えるマルチ機能に仕立てることも可能にした。 特に､“自由がきかない歯がゆさ”と言われて 4GL が嫌われてしまう問題点については、MANDALA をパラメタカスタマイズできるようにして対応した。 しかし、実際にはそれでは対応できないこともあった。 そこで、MANDALA 自体をプログラムカスタマイズしやすくして、開発者の方々からの要求にタイムリに応えるサービスも実施した｡“お抱えツール屋サービス”とは、MANDALA 自体をプログラムカスタマイズする AppliTech サービスの一つであり、既に 10 社以上のお客様に有償でご提供済みである。 なお、一般のツールベンダがツールのカスタマイズサービスに積極的でないのは、第１章で述べた業務パッケージ開発業者と同様に手離れのよいビジネスを好むためである。 しかし、アプリテック社では、このサービスを MANDALA を多様な環境に適応可能にさせるためのカスタマイズ要求に関する情報収集策だと考えて実施している。
それから、MANDALA で開発する業務プログラムの性能などに配慮して、MANDALA はプログラム生成タイプのツールとして開発した。 一般に、プログラム生成タイプのツールは、プレ生成ツールとポスト生成ツールに分類できる。 プレ生成ツールでは、生成処理が先に行われるので、生成結果に開発者が手を入れなければならないが、ポスト生成ツールは、開発者が記述したプログラムを解析して、それにふさわしい生成を行う。 しばしば生成タイプのツールには多くの問題点があると言われるが、それはプレ生成ツールの問題点である。 MANDALA は、そういった問題点のない、業務プログラムの変更や再生成が自由に行えるポスト生成ツールにした。
以下に参考のために、MANDALA で開発する業務プログラムが用いる高級イベントの主なものを載せておく。 各高級イベントの名前は、それぞれの高級イベントプロシージャにおいて、どのような処理をすべきかを表わしている。 これらの中で“派生値”という高級イベントに、注目していただきたい。 これは、アップデートプロパゲーションに関係するものである。
・ 入力チェック (Check) 当データ項目にインプットされたデータのチェック。
・ 派生値 (Derived) 他のデータ項目へのデータのインプットを契機とした、
当データ項目への値の設定。
・ 初期値 (InitVal) 各処理の完了ごとの当データ項目への初期値の設定。
・ 案内表示 (Prompt) 当データ項目に関する促進メッセージの発行。
・ 選択リスト (SList) 当データ項目への入力候補データ一覧 (選択リスト) の表示。
また、以下に参考のために、Visual Basic で使えるイベント (ローレベルのイベント) の主なものを載せておく。 各イベントの名前は、それぞれのイベントプロシージャがどのような契機で呼び出されるのかを表わしている。
これらがハードウェア依存のローレベルのイベントであるのとは対照的に、高級イベントは業務プログラムのビジネスロジックに直結するものであるという違いに注目いただきたい。
・ Change 当オブジェクトの内容が変更されたという契機。
・ Click 当オブジェクトがクリックされたという契機。
・ GotFocus 当オブジェクトにカーソルが来たという契機。
・ KeyPress 当オブジェクトにカーソルがあるときに、
キーボードのキーを押下したという契機。
・ LostFocus 当オブジェクトからカーソル抜けたという契機。
・ MouseUp 当オブジェクトにカーソルがあるときに、
マウスボタンを離したという契機。
なお、ここのオブジェクトとは、画面とか画面の中のフィールド (データ項目) を意味する。
アプリテック株式会社
Copyright © 1995-2008 by AppliTech, Inc. All Rights Reserved.