診断士コラム

診断士コラム

システム的な視点によるTALONのコンセプト。

ある書籍にTALONを紹介する事になり、記事を執筆しました。書きながら、そもそもTALONはどういう目的で作ったのかなどを久しぶりに振り返って考えることが出来ましたので、今回はその辺りを書きたいと思います 。( かなりシステム寄りの話になります)

業務システムの開発、その中でも要件定義など所謂上流工程を行うようになって10年以上が経ちますが、徐々にある思いが強まっていきました。それは、データベース操作言語であるSQLのSELECT文と複雑なデータ加工処理の作りこみだけでシステムが作れないものか、という思いです。それ以外を自動で作ってくれるツールがあれば打ち合わせ中に機能が作れると考えたのです。

業務システムとは何かと考えてみると一番根幹にあるのは、「業務に即したデータを効率良く入力・加工・出力することで、効率的な業務運営を実現し、溜まったデータを経営判断の材料として活用する」だと思っています。平たく言うと「データベースデータをどのように入力・加工・出力するか」です。要素としてはユーザインタフェース、データ構造&データ操作に分かれます。

ユーザインタフェースに関しては、企業内で利用するシステムの場合、BtoCのECサイトなどのように凝ったものはあまり求められず、入力効率や見間違えの少ない画面デザインが要求されます。その為、トレンドに左右されるような変化はあまりなく、むしろシステム全体で統一した操作性、イメージが求められるため定型化が比較的容易です。(もちろんAjaxなどによるリアルタイム応答技術などは取り込んでいく必要はありますが)

データ構造&データ操作に関しては、企業ごと、システム領域ごとに千差万別になります。業務パッケージとして例えば生産管理システムであれば業界別などでそれぞれ特化した物が存在していますが、実態としてはパッケージをそのまま企業に導入して稼働できるケースは非常に稀だと思います。なぜそのまま適用できないかというと、同じ業務・業界でも慣習やビジネスモデルは違うので、パッケージが想定している業務の流れと合わないことが多いためです。

つまり、私の認識では、業務システムとはデータベースのモデリングと、そのデータをどのように入力・加工・出力するかという部分が適切に構築出来るかどうかで品質が決まります。

この部分以外は出来る限りノンプログラミングで完成してほしいと考えたのがTALONの始まりです。

データモデリングを適切に行い、そのデータをどのように入力・加工・出力するかという仕組みは人間の知恵を使って作る必要がありますが、それ以外の画面・帳票デザインや、データを取得して画面にセットする処理や、入力された情報をデータベースに登録するなどの処理はプログラミングせずに済ませたいと考えました。

ここで、冒頭に書いたSELECT文とデータ加工処理だけでシステムを作れないかという問いへの答えとなるツールが作成されることになりました。

画面・帳票に表示するデータをSELECT文、もしくはウィザードでどのテーブルのどの項目から取得するかを選択して、レイアウトや業務ロジック、登録・更新・削除する項目の設定などをWeb設定画面で行うだけで業務機能が完成します。また、複雑な業務ロジック(データ加工処理)に関してはプラグインとして外部プログラムを呼び出して処理を実行します。

システム的な目線で書くと、入力と出力のコア部分をSELECT文で作り、複雑な加工にあたる部分を外部プログラムで作る。それ以外の全てはツールが自動生成します。

画面・帳票の表現としてSELECT文を自由に使えるのでどんなに複雑なデータモデル構造でも表現させることが可能になります。(ちなみに、SELECT文では表現が難しいようなデータでも、プロシージャを呼び出して画面表示するデータを作成する事も可能となっています。)

基本的にTALONはノンプログラミングツールですので、プログラミングを全く行わずにシステムを構築することが可能ですが、ある程度規模が大きくなってきて、データベースモデルが正規化されて複雑になっているようなケースの場合は、画面表現用のSELECT文と複雑な業務ロジックへのプログラミングを行います。

これにより、小規模なシステムはノンプログラミングで超高速な開発を行い、規模の大きなシステムは一部プログラミングする事で本当に使える業務システム構築を可能にしています。

ここが非常に重要なのですが、画面設計時にデータベースを作成し、内包する形で業務機能を作るツールの場合、1画面で1データベーステーブルという形での表現が基本となります(手を掛ければ表現可能なツールもありますが)。これですと台帳管理のような簡単なシステムであればシステム的な知識は何も無くても可能ですが、正規化を行い、リレーションが複雑に張り巡らされたデータベースの場合表現の制約が非常に多くなってしまいます。その為、TALONはデータベースの構築は画面設計処理と連動しないという選択をしました。データ構造の定義(データベーステーブル、項目の作成)は先に行い(TALONで作成可能です)、その後に画面デザインや業務ロジックの構築を開始するイメージです。また、複雑な業務ロジックとしてデータ加工を行う処理に関しても、ツール側で無理に設定させるのを止めて、外部プログラムを簡単に呼べる仕組みの提供を行うという選択をしました。これは、複雑な業務ロジックを記入するようなシステムを構築する場合、ツール独自の簡易言語的なもので作りこむより、システム専門家であれば慣れているプロシージャやJava言語で作成した方が生産性が高いと考えたからです。この2点は一般的にはツールの弱点と捉えられるかもしれませんが、これにより簡単なシステムは簡単に、複雑なシステムは人が手を掛けないとどうしようもない部分にだけ手を掛けて、あとは自動作成するということが可能になります。また、ツール自身をシンプルに保つ事が出来ますので、習得が容易になります。

現在RADツールとしてノンプログラミングや超高速開発を謳ったツールは数多く存在しますが、TALONの特徴はここに記した、ノンプログラミングとプログラミングが必要な領域のバランスにあると考えています。その結果、本当に使える業務システムが構築出来ると考えています。

それでは今回はこの辺で。

文=古関 雄介

検索

アーカイブ


PICK UP

お問い合わせ