超高速開発ではRDBMSの位置付けも変わっていく

さった2月9日に開催された「超高速開発コミュニティ モデリング分科会」は、RDBMSのエキスパート達による、RDBMSの位置付けの見直しに関する刺激的な議論が展開されました。参加いただいた皆様、おつかれさまでした。

当日は座長の渡辺幸三さんを中核に、「超高速開発 x モデリング」という分野に興味を持った20名前後の方が集まって議論しました。このブログでは、"業務ロジックはどのように仕様化され、実装されるか。" という切り口から開始された一連の議論をまとめてみました。

RDBMS に業務ルールをもたせてはならない

RDBMSのエキスパートであれば、DDLを縦横無尽に使いこなしたいと考えるのは当然でしょう。しかし現場視点では、RDBMSで記述できる業務ルールは残念ながら中途半端です。

  • DDLでは、フィールドに初期値が書けるが、これは使えない。初期値には条件式を伴うことが多いが、DDLに式は記述できない。
  • DDLに参照関係を記述するのは一般的と考えられているが、条件によって参照先のテーブルを変えたい、という要件を満たせない。

この詳細については、渡辺さんのブログに詳しいです。

「テーブル操作と業務ロジックの連動制御」
http://watanabek.cocolog-nifty.com/blog/2016/02/post-8c04.html

このブログでは次のように説明されています。

RDBMSによって提供される外部キー制約やカスケードオプションのような「気の利いた機構」を、私はよほどのことがない限り使わない。ユニークキーやインデックスキーの設定程度を除けば、テーブル定義はほとんど「素」のままである。

では RDBMS が提供するトリガやストアドプロシージャを使うのはどうでしょうか。これならプログラムですので、制御は可能になります。

実はトリガやストアドプロシージャによる業務ロジックの実装は、まったく超高速開発的ではありません。プログラムが増えるほど、どこにどのようなロジックがあるかが追いにくくなり、保守性が低下します。加えて、RDBMSによって互換性がないことも問題です。

超高速開発 x モデリング、という視点

超高速開発では、ツールが提供する「基盤部分」に、ドキュメントとして性格付けられた「仕様」を与えることで動作します。「仕様」にはテーブル定義や業務ロジックが含まれますが、これまでのプログラムと異なり、「初期値の設定はここに書く。」「モデル間の参照はここに書く。」というように書く場所が固定されています。自由度が制限される分、記述のためのルールがしっかりするため、プログラムとはいってもドキュメントの意味合いが濃くなります。

これまでのモデリングは静的構造(ER図)で記述できなかったもの - つまり動的な部分については、個々のRDBMSの拡張機能を用いるか、あるいは汎用プログラミング言語に吸収させていました。しかし超高速開発時代のモデリングは、動的部分の多くを基盤への仕様記述ということで吸収できることを前提に考え直します。

一言で表現すると、

(超高速開発ツールによって)モデリングの範囲が拡張され、動的部分の多くも表現できるようになった。

ということです。この視点は、これまで学んできたモデリングの知識体系を解体し、再構築します。モデリングは次の段階へ進む、ということです。

それはツールへのロックインではないのか

ロックインについては分科会でも丁寧な検証がなされました。RDBMSに定義するテーブルが簡素化され、個々の違いをツールが吸収するというのは、ツールへのロックインになっているだけではないのか。ツールへのロックインは否定しないが、次の点で従来方式より改善されている、というのが参加者の意見として集約されました。

従来開発では、トリガやストアドプロシージャを多用した成果物に対して、RDBMSを変更するというのは事実上、不可能であった。一方、超高速開発ツールが提供する基盤部に与えるプログラムは(従来よりも)ドキュメンテーションの性格が強い。そのためツールが変わっても「仕様」の把握が行いやすい。このメリットは軽視すべきではない。従来のシステム開発は再構築の都度、現行仕様の把握に相当の工数を費やしてきた。超高速開発ツールを使えば、現行仕様の把握のしやすさが著しく向上する。実際、これは基盤となるツールを変更する、という場合にも使える。

私見ですが、ロックインには「強いロックイン」と「弱いロックイン」があるのではないかと考えています。超高速開発ツールは後者ですので、この点でも改善がみられます。

それでも、RDBMSのトリガやストアドプロシージャとの差がわからない、という反論に対しては、次の意見が出ました。RDBMSが管理する変数と、UI部の変数は、はっきりと分かれている。エラーになったとき入力欄を反転させる、というようなプログラムはRDBMS単体で書くことはできない。超高速開発ツールでは「テーブルの機能拡張と UI 操作」が継ぎ目なく *仕様として* 管理できる。プログラムの書き方の問題ではなく、プログラムではなく仕様として管理するという視点が(従来とは)異なる、というものです。

ツールがカバーできる業務ロジックの限界について

とはいえ、超高速開発ツールを使って記述した条件文が、10,000行を超える if 文になった、では、やはり辛いところです。そのため、ルール記述を得意とする BRMS と呼ばれる分野との連携は有用です。また、業務がワークフローと連携するということも求められます。ワークフロー機能が備わっていない超高速開発ツールであれば、別途、ワークフローエンジンとの連携となりますが、業務の密接度を加味すると、ワークフローエンジンを同梱する方が有利です。これは仕様記述が一箇所にまとまることで、よりドキュメントとしての価値が高まるためです。

まとめ:超高速開発時代のモデリングとは何か

超高速開発ツールがリポジトリ中心であるというのは、モデリング中心という意味を内包しています。起点はモデリングですが、これまでと異なる「拡張モデリング」と捉えることができます。つまり旧来のモデリング技法と、超高速開発時代のモデリング技法はカバーできる範囲が異なります。そこを理解することで、超高速開発のメリットを活かせるモデリングを実践できます。ただし「カバーできる範囲」および「仕様の記述方法」はツールによって異なります。そのためツールの能力を知らないモデラーは超高速開発に対応しているとはいえません。一方で、一人で複数のツールを使えるというモデラーも登場することでしょう。

"設計書を書けば(プログラムを書かなくても)アプリケーションが動作する” という表現は、一見うさんくさいのですが、その技術的枠組みを理解すれば、決して誇張ではないことがわかります。ながながと書きましたが、私のこれまでの説明を要約すると「仕様 => リポジトリ(設計情報)=> 抽象度が上がったプログラム(ドメインに特化したプログラミング言語; DSL)=> ドキュメント」ということを伝えたかったのです。この全体をモデリングというならば、モデリングという言葉の意味もまた深化しているといえます。

興味のある方は是非とも次回のモデリング分科会にご参加いただければと思います。多くの方との議論を重ねる中で、いろいろと見えてくるものがあります。