超高速開発を支えるビジネスルール管理システム（BRMS）。海外製品が目立つなか、なうデータ研究所の「NaU DSP」は国産勢として孤軍奮闘を続ける。大野国弘代表取締役は恩師の構想を引き継ぎ、NTTドコモなど大手が採用する製品に成長させた。スマートフォンやビッグデータへの対応も急ぐ。
日本でもBRMSを導入する企業が増えています。
BRMSは「人や企業が持つ業務上のルールや専門知識、ノウハウ、法律」といった業務ルールを共有・活用するためのシステムです。現状のシステムの多くは、業務ルールをプログラムに埋め込んで使っています。これをプログラムから引きはがして、別に管理するのがBRMSです。
プログラムはBRMSが自動生成するので開発スピードが高まり、同時に開発や保守のコストを下げる効果があります。
BRMSという考え方はずいぶん前からありますが、日本でようやく盛り上がる時期が来たと感じています。適用して効果が上がる分野は数えきれません。
BRMSの構築を支援する製品の多くは海外製です。
我々が創業したのは1996年ですが、その時点で複数の競合製品が存在していました。そのほぼ全てが海外製品でした。
なので競合製品を研究し、業務ルールの共有に焦点を当てて、より利用しやすく、実用性の高い製品を目指しました。結果的に、海外製品に引けを取らないものができたと自負しています。NTTドコモをはじめ30社以上が製品を使っています。
式で入力し最適解を見いだす
利用しやすさや実用性の高さを、どのように高めたのですか。
既存のBRMS製品は「if-then-else（もし～ならば…せよ、そうでなければ…せよ）」で表した業務ルールを使うか、論理型言語を使うかのどちらかでした。それぞれ一長一短があります。
if-then-else型はルールを入力しやすいのですが、ルールの数が600を超えたあたりから運用が難しくなります。ルール間の矛盾が生じたときに、人手で洗い出し、修正するのは至難のわざです。
論理型言語を使えば、ルールが増えてもルール間の整合性を維持できます。問題は、論理型言語でルールを書くので、使うのが難しいことです。飛行機の運航計画を立てるといった用途には向きますが、企業の業務ルールは通常、そこまで複雑ではありません。
我々のNaU DSPは論理型言語のPrologを使っていますが、ルールの入力を容易にしています。表計算ソフトのシートに似た画面から、「利益＝売上高－原価」といった式の形で入力します。来店者数を予測する場合なら、「休日の来店者＝平日の来店者×2」「雨の日の来店者＝平日の来店者×0.5」といったルールを入力していくわけです。
そのルールを使えば、問題の答えまで導ける、と。
入力したルールを基に、Prologがその時点での最適解を出します。解の複数の候補を導き出すのも可能です。基本的に一つの解を求めるif-then-else型のBRMSとは、この点が大きく違います。
ルールを全て最初から入力しておく必要はありません。作成したルールで運用してみると新たな事実が見えてきます。ルールを共有できると、業務改善や新たなルールの作成につながるわけです。
留年をきっかけに恩師と出会う
そもそもなぜBRMSの世界に足を踏み入れたのですか。
本当に偶然です。お恥ずかしい話ですが、母校の九州工業大学を留年した1996年に、ワーキングホリデーの許可を得るために学部担当だった長澤勲教授（当時）に面会したのがきっかけです。先生はPrologを活用したBRMSのコンセプトを1980年代に描き、NaU DSPの生みの親の一人です。
1996年当時は、製品化したばかりの頃でした。長澤先生は私に、「職人やベテランが持つノウハウや知識を、コンピュータの力を借りれば世の中に流通できる」などと、考えを丁寧に説明してくれました。結果的にワーキングホリデーを取るのは止めて、長澤先生の研究室に入りました。大学院に進学すると同時にここで働きはじめ、そのまま今に至っています。
初めは開発を担当していた？
ええ。まずNaU DSPの機能を汎用化するチームに加わりました。1996年当時は自動製図や設計シミュレーションといった機械製品の設計を支援する機能しかありませんでした。もともと機械システム工学にかかわる研究室から生まれたためです。このときには、ルールをどうモデリングするべきか、ルールの入力画面はどうあるべきかなどを考えました。
その次の機能拡張から、本格的に開発に参加しました。医学知識もNaU DSPで記述できるように拡張するのが目的です。薬の同時服用の禁忌のルールをモデリングするために、物事の相関関係や同期の様子をグラフで可視化する、データの関係をクラス図で表現する、などと試行錯誤を重ねました。
並行して、NaU DSPの導入コンサルティングも担当しており、ルールを解釈・実行するエンジンの機能拡張の企画にも関わりました。NaU DSPが生成するプログラムをJavaから呼び出せるようにしたほか、64ビット対応やマルチスレッド化も担当しました。
そうこうしているうちに、「人と話すのが上手だから」と、気が付くと名刺の肩書きが「営業」に変わっていました（笑）。とはいえ社員20人の会社なので、常に現場の様子は分かっており、製品の設計にも関わってきました。
九州に本社を構える理由は。
BRMSエンジンの開発を九工大の梅田政信准教授の研究室と連携しながら進めているからです。飯塚市がITベンチャー促進に手厚いのも、理由の一つですね。ただ、売り上げの8割以上は東京に本社のある企業から得ています。
今後はスマートシティをはじめ、社会のスマート化に対応できるよう機能拡張を進めます。8月までにスマートフォン上で動作させます。ビッグデータの解析にも役立つと考えており、大量バッチ処理を扱うオープンソースソフトのHadoopとNaU DSPとの連携も試行しています。
同社は1996年、工業機械の設計で使うBRMS製品として最初のバージョンを出荷した。その後、企業情報システムで活用できるように汎用化・高速化してきた。
導入ユーザーは日本で30 社以上。NTTドコモでは携帯電話加入者の料金プランと割引プランの関係性を検証する目的で、筑波大学や福井大学の付属病院では薬物の同時服用の禁忌や副作用を確認する目的でそれぞれNaU DSP を利用している。ほかに、九州でホームセンター「グッデイ」を61店舗展開する嘉穂無線は、勤務シフトを自動生成したり店舗の省エネを管理したりする目的で使っている。
NaU DSPは九州工業大学情報工学部の長澤勲 元教授のアイデアの下、梅田政信准教授がプロトタイプを開発した。なうデータ研究所の社名は両者の姓の頭文字に由来し、現在も密に連携を取りながら産学連携でビジネスを進めている。
なうデータ研究所 代表取締役
