2. 望ましい開発方法を目指して
--- 分割専門開発方法 ---
では、これらの問題点をどのように克服していけばよいでしょうか？
各画面の操作性がバラバラになってしまうという問題点のその１について考えてみると､「操作性の標準化規約をつくる」程度では不十分であり､「操作性に関するプログラムを共通にしてしまう」ことが望ましいといえます。操作性に関する規約だけでなくプログラムまでも共通にしてしまえば、操作性がバラバラになることはないはずです。
ここで問題解決の糸口を探るために、画面アプリを構成するプログラムをよく見てみると､“業務仕様を実現するプログラム部分
(赤色の部分)”と“操作等の仕様を実現するプログラム部分 (赤色以外の色の部分)”に大別できることがわかります。これらをうまく分離して、操作等の仕様を実現するプログラムを
“共通”にしてしまえばよいはずです。以下の図のようにすることを目指すのです。
こう説明するのは簡単ですし、図示するのも簡単ですが、現実にはボーダラインのあたりで､“業務仕様を実現するプログラム部分”と“操作等の仕様を実現するプログラム部分”の区別が難しいかもしれません。
しかし、区別を付けようとするのとしないのでは、結果が大いに違ってきます。実際には、かなりきれいに区別をつけることができます。
ですから、開発者Ａ，Ｂ (またはＡ，Ｂチーム)
が“業務仕様を実現するプログラム部分(下図の赤色の部分)”を作成するようにします。
そして、開発者Ｃ (またはＣチーム) が“操作等の仕様を実現するプログラム部分(下図の青色の部分)”を共通に作成するようにします。
このように“業務仕様を実現するプログラム部分”と“操作等の仕様を実現するプログラム部分”を分離して、それぞれを別の開発者に (専門の開発者に) 作成させるようにするという方法 (分割専門開発方法) は、どの程度の解決策になるでしょうか？ 評価してみましょう。
この分割専門開発方法は、画面アプリの操作性がバラバラになりがちという問題点のその１の解決策になっています。
操作性に関する規約だけでなくプログラムまでも共通にしてしまうのですから、操作性がバラバラになることはあり得ません。
この分割専門開発方法は、他人の開発したプログラムをメンテナンスしにくいという問題点のその２のかなりの解決策にもなっています。
少なくとも、操作性に関係するプログラムと業務仕様に関わるプログラムがごちゃまぜにならない分だけ、メンテナンスしやすくなります。
操作性に関係するプログラムは、一般的に開発者の個性が出やすいところですが、そうした個性からくる違いに影響されることなく、業務仕様に関わるプログラムのメンテナンスができるようになるのですから、かなりの解決策だといってよいでしょう。
この分割専門開発方法は、開発作業が効率的でないという問題点のその３のかなりの解決策にもなっています。
操作性に関係するプログラムは、特定の開発者
(またはＣチーム) が専門に共通に作成するようになるのですから、ムダはなくなります。開発者の全員が、かなりの日数がかけて最初の画面アプリを開発するという産みの苦しみを味わうことはなくなるのです。
以上をまとめると、この分割専門開発方法は、上に述べたように単純な開発方法の三つの問題点のかなりの解決策になっているといえます。
ですから、この方法は、実際にいろいろな形態で採用されています。
例えば“操作等の仕様を実現するプログラム部分”を専門チームが開発して、それをひな形として業務プログラム開発チームに配布して、ひな形に手を入れて画面アプリに仕上げるという方法は、分割専門開発方法を具体化した例の一つだということがわかります。
また、4GL(第四世代言語) やデータベース系ツールが高い生産性をあげるというのも、分割専門開発方法を採用しているからに他なりません。即ち、4GLやデータベース系ツールのベンダが､“操作等の仕様を実現するプログラム部分”を開発してしまっているので、4GLやデータベース系ツールの利用者
(アプリ開発者) は“操作等の仕様を実現するプログラム部分”を開発する必要がなくなり、生産性を高めることができるのです。
ただし、ひな形や 4GLやデータベース系ツールは、必ずしも“業務仕様を実現するプログラム部分”と“操作等の仕様を実現するプログラム部分”を分離するのだという思想にピッタリ合わせて設計されているとは限りません。しかし、おおよそ、こういったような区切りをつけて、その一方の開発を肩代わりしていると見ることができます。ですから、ひな形や
4GL やデータベース系ツールの利用者 (アプリ開発者)
は、一部のプログラム (操作等の仕様を実現するプログラムなど) を開発する必要がなくなり、生産性を上げることができるというわけです。
例えば ACCESS を使うと、ACCESS 流儀の操作性になってしまいますが、狙った機能を果たすアプリを比較的簡単に開発できます。なぜ簡単に開発できるのかというと、ACCESS
がかなりの処理を代行してくれるので、その部分のプログラムを開発する必要がないからです。
注意：
ACCESS を使うと、ACCESS 流儀の操作性になってしまいますから、その操作性を変更したいと思っても、おいそれと変更できないことに注意が必要です。
例えば、操作性に関する注文の多いお客様 (最終顧客) から委託された開発に ACCESS を使うと、お客様からの注文に応じることができない危険性があるので、注意が必要なのです。
なお、この問題点を“4GL の歯がゆさ”と呼ぶことにします。
OCX を評価すると
ここで因みに､“業務仕様を実現するプログラム部分”と“操作等の仕様を実現するプログラム部分”の分離という観点から、OCXを評価してみたいと思います。
OCX は､“業務仕様を実現するプログラム部分”と“操作等の仕様を実現するプログラム部分”の分離がしやすい構造にはなっていません。
例えば､“操作等の仕様を実現するプログラム部分”を OCX の内部に閉じ込めて､“業務仕様を実現するプログラム部分”を OCX
のイベントプロシージャとして記述しやすいと (あるいはこの逆の役割にすることができると) 素晴らしいのですが、そのようにすることは困難です。
OCXは、残念なことに“業務仕様を実現するプログラム部分”と“操作等の仕様を実現するプログラム部分”とを分離するのに都合よくできているとはいえないのです。しかし､“操作等の仕様を実現するプログラム部分”の半分くらいならば
OCXの内部に閉じ込めることは可能になっています。
ですから、OCXを使わなかった場合に以下の図のように､“業務仕様を実現するプログラム部分 (赤色の部分)”と“操作等の仕様を実現するプログラム部分 (青色の部分)”のプログラミングが必要だとしたら、OCXを使うことによって青色の部分を半減することができるでしょう。
ただし、青色の部分を半減できたとしても、操作性に関係するプログラム (上図では青色で表現) と業務仕様に関わるプログラム (上図では赤色で表現) がごちゃまぜになってしまいがちであることに変わりはありません。
因みに、なぜ青色の部分を半減しかできないのかを述べておきましょう。OCXは､“操作仕様に関するプログラム”を OCXの内部に閉じ込めることによって共通化できます。しかし、OCX(コントロール) 間にまたがる“操作仕様に関するプログラム”は、OCXの内部に閉じ込めることができませんから、画面アプリ開発者が手作りすることが必要になります。
例えば、OCX(コントロール) 内部のカーソルの移動に関するプログラムは OCXの内部に閉じ込め共通化することができますが、OCX(コントロール)
間にまたがるカーソルの移動に関するプログラムは、どうしても画面アプリ開発者がイベントプロシージャとして手作りすることが必要です。
このように見てくると、OCXは、業務アプリの開発を合理化するものと捉えることができますが、その合理化の程度は、中途半端であると言わざるを得ません。
実は私どもでは､“操作等の仕様を実現するプログラム部分”は、適当なプログラム生成ツールを用いて機械的に生成 (機械的生成) することをお勧めしております。こういった部分は、わざわざ手作りするには及びませんし、手作りするより機械生成の方が品質のよいものを安価に作れるからです。つまり、適当なプログラム生成ツールを用いれば、操作仕様等の部分を共通に作成する開発者
(またはチーム) を不要にすることができるというわけです。
なお、ここまでの説明は、ごく一般的なことを述べたのであって、弊社の宣伝は登場してきませんでしたが、少しだけ言わせてください。実は、弊社は、青色の部分、即ち“操作等の仕様を実現するプログラム部分”を機械的に生成 (機械的生成) するプログラム生成ツール (MANDALA) を開発・販売しております。
ところで、そこまで徹底しなくても、つまりプログラム生成ツールを用いるところまで頑張らなくても、操作仕様等の部分を共通に作成する開発者 (またはチーム) を設けるという合理化策を採用するだけでも、かなりの効果を上げることができるでしょう。
ここで、皆様方がそうなさる際の、いくつかご注意を申し上げておきます。
操作仕様等に関するプログラム部分を共通に作成する際に、OCXという形態だけで済むわけではないことをご理解ください。なぜなら、OCXという形態では、操作仕様等に関するプログラム部分の一部 (半分くらい) しかまかなえないからです。
操作仕様等に関するプログラム部分を共通に作成する際に、ひな形やプレ生成ツールという形態にしないことをお勧めいたします。なぜなら、ひな形やプレ生成ツールでは、操作仕様等に関するプログラム部分を修正しなければならなくなったときに、すべての画面アプリに人手をかけて手を入れることが必要になってしまうからです。
なお、プレ生成ツール(および後述のポスト生成ツール) とは何かについては、この資料の後ろに補足説明がありますので、参照してください。
操作仕様等に関するプログラム部分を共通に作成する際には、ライブラリモジュールや
DLL (ActiveX DLL でもよい) やポスト生成ツールという形態にすることをお勧めいたします。OCXという形態を併用するのは構いませんが、OCXだけでは無理だということは、前述したとおりです。
なお、弊社のプログラム生成ツールは、ライブラリモジュールや DLL を併用したポスト生成ツールという形態にしています。
「プログラム生成ツールを使わずに、先に述べた分割専門開発方法を採用するだけでもかなりの効果を上げることができるでしょう」と述べましたが、そうするにはかなりのノウハウを必要としますし、専門家の育成も必要です。ですからむしろ、相当の覚悟が必要ですがプログラム生成ツールを自社開発するか、または安直に弊社のプログラム生成ツール
(MANDALA)を採用することをお勧めしております。
ところで、弊社のプログラム生成ツールは、単に青色の部分を機械的に生成する役割しか果たさない“やわ”なものではなく、以下に述べるように更に半歩か一歩だけ進んでいます。ここではこの機能を説明するのではなく、これに関係して、部品化アプリ開発方法という究極の開発方法ついてご説明いたします。
|
|
|
|
|
|
|
|
|
