最近、日経BP社 ITproのメールマガジンで「最新ITの“古さ”を知らない危険」という記事を読みました。

まとめてしまえば

最新のIT関連キーワードXXは、つきつめてみると昔流行ったキーワードYYの話である

という発言を情報システム部長などのベテランからよく聞くということ。
そしてそれは、

ある意味正しいが、ある意味正しくない

ということ。これは、

確かに最近のIT関連技術のキーワードは、昔の技術キーワードの蒸し返しであることが多く、ベテランの言うことはそういった面で正しいと言えるが、一方で昔のブーム以降のさまざまな(周辺を含めた)技術の進歩を取り込んで、単純な蒸し返しに終わらない再挑戦、再々挑戦となっているという面で正しくない

というわけ。要するに

最近流行の技術は過去に存在した技術の蒸し返しであることも多いが、単純な蒸し返しであるというわけではない。したがって徒に否定してしまうのは正しくないが、一方で最近の技術を過去の経験と照らし合わせもせず無批判に取り入れるのは、過去と同じ失敗をしてしまう可能性があるのでそれもよくない。

ということのようです。

さて、上に挙げた記事では、実例として、

XXが「スマート…」なら　YYが「ユビキタス」「ブロードバンド」「ニューメディア」
XXが「クラウド」なら　YYは「ASP」「VAN」あるいは「仮想化」

が挙げられていましたが、今回の本題の話に入ると、さしずめ

XXが「ビジネスルール管理システム(BRMS)」なら　YYは「エキスパートシステム」

といったところになるでしょう(ちなみにここで言っているBRMSとは例の記事のビジネスルール特化型のBRMSのことなので念のため、XXがオールインワン型のBRMSというのであれば、YYは自動生成???)。

したがって上の記事の主張に沿うならば、BRMSとエキスパートシステムとの対比と、過去の総括をやっておく必要がでてきます。実際、BRMSのことを上司に話したら、「昔のエキスパートシステムやルールベースの言語とどう違うの？」という質問をされた…という話も最近ちらほら耳にしていますし、

また、私が購読している海の向こう(というか言葉の壁の向こう)のブログでまさにこの対比がホットな話題となっていたりもします。

Follow-Up on ‘Harvesting Business Rules’: Business Rules vs. Expert Systems
Response to: Business Rules vs. Expert Systems: Same or Different?
Additional Response to: Business Rules vs. Expert Systems – Same or Different?

実は、かなり前に当ブログでも関連するようなことを話題にしており、

エキスパートシステムの思ひ出１(なぜ今またルールベースに光があたっているのか)
エキスパートシステムの思ひ出２(なぜ今またルールベースに光があたっているのか)

という記事があるのですが、読んでいてわかりにくい部分などもあるので、ここでは再度、ビジネスルール管理システムとエキスパートシステムとを対比しながらまとめておきましょう。

まず、今回のブームでのBRMSと過去のエキスパートシステムとの一番の大きな違いは

１．適用する対象の違い

と言えましょう。　(この項続く)

今月の14日に、Drools5.4.0.Finalがリリースされました。

Droolsの開発は結構活発で、追いついていくのが大変。
久しぶりに新しい機能など、きちんと整理しておかなくてはと
思っている今日このごろ。

スマホ急増にもBRMSが効く

…実は、日本でも通信業界で(ルールエンジンを主体とした)BRMSはそれほど珍しいものではなかったり。

たとえば

日本テレコム、ILOG JRulesを採用 (2006年7月)

は、料金計算にBRMSを用いていますし(ちなみにILOG JRulesは現在のIBMのBRMS)、

Prologベースプロダクションシステムによるクラウドサービスの運用監視

などは通信の監視としてルールエンジンを用いています(Prologをルールエンジンとして使っています)。

なお料金計算にしても、ネットワークアプライアンスの監視にしても比較的ルールエンジンが適用しやすい分野です。たとえば

Cisco Active Network Abstraction Administrator Guide, 3.6.4 – Drools Rules Engine …

というのはご存知でしょうか。

ひとつの記事で、ちょっと引っ張りすぎかとも思いますが、もう少し。

この記事で違和感を感じていたことがもうひとつあります。それは、

「超高速開発」が日本を救う

という見出し。システム開発が速く効率的に進められるに越したことはないのですが、それがそのまま日本を救う…？ もちろん見出し特有の誇張だとは思いますが、一方で裏を返せば、開発が速くできればそれでOKという意識が垣間見られて…ちょっと穿ち過ぎでしょうか。

***

一般的なユーザ企業で利用される(コンピュータ)システムの技術には大きく２つの方向があると私は思っています。

• システム開発ツールや開発方法論などシステムの開発効率をあげる方向。
• システムをどのように使って現実の問題に対処するか、システムをどのように現実の問題に応用していくか、という方向

私も学生時代を含めると30年近くこの分野に携わっていますが、私の見るに日本の企業向けシステム技術の方向が、ここのところ…というかJavaやUMLが出てきた10数年前から開発効率をあげること…開発方法論とか開発ツール、開発言語に偏重しているような気がしています。

もちろん開発効率をあげることは重要であり、未だに企業内の情報化が進んでいない企業などでは、最重要の課題であることもわかります。その上でやはり、世間一般で、「そもそもどんなシステムを作るのか」という議論が少ないように思うのです。

もっとも私自身、開発方法論こそが大事…と思っていたことがありました。そのころは企業内のコンピュータシステムは汎用機全盛の時代。システム全体での新人研修の言語はCOBOL。構造化プログラミングの話とか。学生時代に多少なりとも抽象データ型とかオブジェクト指向とかを齧ってきたものにとっては、…う～ん。という時代でした。

そんなときに最初に配属されたのが、人工知能やORを用いて生産計画(などなど)のシステムをつくるようなところ。それこそ「システムをどのように使って現実の問題に対処するか」の技術の部署でした。
最適化手法や人工知能など、技術としてそれなりにはおもしろかったのですが、個人的にはシステム開発の方法論が(生意気にも)あまりにもナイーブだなと思って、オブジェクト指向の勉強(*1)をやっていました。

それが、UMLやJava、そしてデザインパターンなどが出てきて世の中の流れが一気に方法論に傾き始めたように思います(特に日本)。もちろんこれによりさまざまな洗練された開発手法がうまれてきたことは確かですし、それ自体は喜ばしいことではあるのですが、一方でそもそもコンピュータを使って何をやるかというところについては停滞気味になってしまっていったのではないでしょうか(特に日本)。そんな中、ここ10数年インターネットが普及するにつれ、従来の企業のシステムからは考えられないようなインターネット上のサービスがうまれてきています。検索エンジンしかり、SNSしかり、動画共有サイトしかり、ECしかり…これらはいずれも「システムをどのように現実の問題に応用していくか」という問いの上に生まれてきたものです。インターネットの世界では、まず「何をつくるか」があります。

翻って従来からの企業のアプリを考えたとき「何をつくるか」というのはだいたい決まっていて、それを「どう効率的に開発するか」ということが焦点になりがちです(特に日本)。

…そろそろ企業のアプリ開発でも、「何を作るか」ということにもうちょっと重心を移していって良いのではないでしょうか(特に日本)。

私が仕事で生産計画や人工知能をやっていたのは20年以上も前。そのときはコンピュータパワーの貧弱さがひとつのネックとなっていました。しかし現在、iPad2などは、そのころの一般的なスーパーコンピュータのひとつCray2/4と同等だとか。昔を知っている人ならわかると思いますが、あのCray(*2)が街中に、電車の中に、家の中にころがっているのです。

こんな時代に20年前と同じような発想でアプリを考えていてはもったいないでしょう。昔できなかった最適化の計算などは、普通に行けたり^^。最近流行りつつある「ビッグデータ」の分析などは、これからのひとつの方向を示しているのかもしれません。

(また、このコンピュータパワーの飛躍的な増大がなければ、(ビジネスルール特化型の)BRMSは存在し得なかったでしょう。)

***

実は(ビジネスルール特化型の)BRMSの世界では、以前からの謳い文句「ビジネスの変化に合わせてITも変更」というところから一歩進んだところ、たとえばデータ分析とBRMSとを組み合わせた意思決定の最適化という方向に重点がシフトしていきつつあります。つまり、開発・保守のスピードを問題にするのではなく、そのスピードを前提にしてそれらをどう活かしていくということが焦点になってきています(*3)。

***

というわけで、

「超高速開発」

するのはよいのですが、それだけで

日本が救われる

とは思えません(笑)。

今の時代、開発が「超高速」かどうかはともかく、定型的な開発などはできるだけ無駄を減らし、手間をかけずに、自動生成できるところはできるだけ自動生成ですませる。そして、システムを現実の問題の解決のためにいかに適用していくかというところ、システムに「付加価値」をどうつけていくかという部分により注力していかないことには「日本は救われない」のではないでしょうか。

「超高速開発」を前提として、その一歩先の話が議論されていくようでないと「日本を救う」と言えないのではないでしょうか。

***

最後の方はかなり調子が高くなってしまいましたが、前回の記事で自動生成ツールについて使えるところではどんどん使っていけばよいと書いた真意はそこにあります。

過去20年間で、コンピュータパワーは飛躍的にアップし、またシステムを利用する要素技術も格段に進歩しました(たとえば機械学習などを含む統計的な数々の手法など)。一方でこれらを現実に適用していくことに関しては緒に就いたばかりで、これからの大きな発展が期待されています。

いままで仕事として、ユーザの業務にも、システム技術にも向き合ってきたはずのSEは、これからのシステムの応用技術を開拓し、新たなビジネスモデルを考えていくのに恰好な人材だと思っているのですがねえ。

***

*1 : ちなみに、そのころ読んだのは、バートランドメイヤーの「オブジェクト指向入門」の第1版。これはおもしろかったです。私のオブジェクト指向の知識のベースはこの本、類いまれなる名著だと思います。
今は第2版が出ていますが、2分冊になってそれぞれが辞書みたいに分厚いのでさすがに読む気になりません(^^;)・・・でも、たぶん読んだらとても勉強になると思います。その他にはOMTやBooch法、Coad&Yourdonの本などを濫読していました。

*2 : そのころはスーパーコンピュータといえばCray、Crayといえばスーパーコンピュータという時代でした。もちろんNECや富士通など日本勢も健闘してはいましたが、デザイン面でのCrayのインパクトにはかないませんでした。

*3 : この辺は、BRMSの記述はあまりありませんが、ちょっと古いダヴェンポートの本。さらに最近の本としては、James TaylorのDecision Management Systemsとかが参考になるかと思います。

表題の日経記事の「オール・イン・ワン型」自動生成ツール(ＢＲＭＳに分類するのは私としては違和感を禁じ得ないので、あえて自動生成ツールとしておきます)について、前回も書きましたが、私自身は、使えるところであれば積極的に使っていってよいと思っています。ネットを見てみると、否定的か肯定的か極端な意見がわりに多かったですが、現実的に見れば、それほど毛嫌いする理由もないですし、一方で盲信するほど革命的という話でもないでしょう。