オリンピック選手のトレーニングを一般に – Athletes’ Performance –

ロンドンオリンピックも終わり、一時の狂騒も、銀座でのメダリストパレードでようやく一区切りつきました。私はそれほど頑張って見ていたわけではありませんが、特に女子バレーの中国戦。第5セット(^^;)から見た私はそれまでのセットのスコアを見て驚きました。スコアがすべてを語っていたというか…。

ところで、最近のスポーツ界というのは、ITなしでは考えられないようになっていますね。試合などコートの外でもデータ戦と言えるようなバトルが繰り広げられています。

DBオンライン的ロンドンオリンピック評―過去最高メダル獲得数を支えた、さまざまなデータ活用

フィットネスまたアスリートの練習・トレーニングは、最新の科学的見地から、一昔前には考えられなかったような方法が取り入れられていたり、全くノウハウのかたまりといった感がありますね。

スポーツ、未開の大陸

なんていう連載を見ると、ICTの対象としてスポーツ分野は結構これからの分野かも…というわけで、今回も事例を…

IBMのJRulesを用いてアスリート向けのトレーニングプログラムノウハウをルール化し、一般向けにもスケールアウト(スケールアップ?)した話。

BRMSというと、日本だと金融・保険関係の話が多くて…確かに事例は多いのは事実なんだが…何だかなあと思っていたら…IBM JRulesのサクセスストーリーとして、Athletes’ Performance 社の事例を見つけました。

Athletes’ Performance社

米国アリゾナ州フェニックスを本拠とするAthletes’ Performance社は、プロフェッショナルなアスリートや選抜されたアスリート向けに独自の総合的なアプローチで運動機能トレーニング、栄養、理学療法を提供しているパイオニアの企業であり、またこれらのノウハウを一般向けにも提供している。アリゾナ、カリフォルニア、フロリダ、テキサスにトレーニング施設を持つほか、これらメニューのオンサイトでのサービスも行っているとのこと。

ビジネスの要求:
現在、スプレッドシートに散在している専門ノウハウや、行動科学、フィットネス、栄養、理学療法それぞれの第一人者の知識を コストをかけずにコード化・自動化することで、パーソナライズされたフィットネス・プログラム製品を、より大きな健康増進(wellness)のマーケットに投入していきたい。

ソリューション:
IBMのBRMS WebSphere ILOG JRules を用いて、トレーニングや栄養ノウハウをルール化し、個々の顧客に合わせてカスタマイズされた健康増進のためのプログラムを提供する。

結果:
・顧客の定着率が92%にものぼるようになった。
・1人のトレーニングスペシャリストが一度に16人の顧客を相手にできるようになった。
・長年の経験がより多くの人々に提供できるようになった。

もともと Athletes’ Performance 社は、プロフェッショナルやオリンピック級のアスリートにハイレベルな支援を行っていた企業ですが(たとえば、今シーズン、サッカーの英国プレミアリーグのエバートン(←開幕戦で香川のいるマンUと戦いましたね)をサポートしているとのこと)、このハイレベルなトレーニングノウハウを一般向けに普及させ、アマチュアのアスリートたちのマーケットに参入していこうとしたもの。

当然のことながら、そのためには、すでに世間で評価を得ているハイクオリティなトレーニングノウハウを、レベルを落とさずに幅広い層にスケールさせていくことが必要になってきます。そしてトレーニングスペシャリストの数が限られている中、これは既存のトレーニングプログラムの多くは自動化していかなければならないことを意味しています。

この自動化に際して選択されたのが、ルールベースによるアプローチ。専門家たちの高度なノウハウを、ビジネスルールの形式で表現して実装するために IBMのBRMSであるIBM WebSphere ILOG JRules が選択されました。

JRulesによるシステムを配備したことで、すべてのトレーニングメニューの「おすすめ」が直ちに、エクササイズマシンのタッチスクリーンや、モバイル端末、Webを通してアクセスすることができるようになりました。現在、社内のフィットネス専門家により過去編み出されExcelのスプレッドシートに蓄積されてきた知識、経験から、抽出された36000ものルールがJRulesのシステムに実装されています。

この JRules によるシステムは、オープンソースベースの SOA/REST の基盤にのっており、ルールの修正反映・デプロイを迅速に行うことができます。日々の評価から、ひとりひとりの顧客の情報を収集し、会社独自の方法論、コア・パフォーマンス・トレーニングメソッド(Core Performance training methodology) に照らし合わせて、それぞれカスタマイズされたプログラムを作成します。この コア・パフォーマンス処方箋エンジン(Core Performance Prescription Engine – CPPE -) は、身体の状態やペース、スケジュールを考慮に入れ実際のトレーニング方法に対してリアルタイムで修正をかけます。

また、このシステムによって、フィットネス・スタッフが常時トレーニング情報に磨きをかけていくことが可能となりました。一人のITスタッフの支援のもと、専門のトレーナーたちのチームがルールの修正をすばやく行い、その結果をただちに世界中の顧客に向けて展開することができるようになりました。

このCPPEは最適で一貫した身体トレーニングを世界中にリアルタイムで届けることのできる世界で最初のルールベースのシステムであり、またこのことにより顧客は、Athletes’ Performance 社のどの施設でも同じ、高品質で一貫したサービスが受けられるようになりました。

また、通常フィットネスクラブの顧客定着率は年間で60%程度を行ったり来たりしているものなのですが、Athletes’ Performance 社は、何と年間で92%を誇るようになっています。

さらに、このシステムにより健康増進(wellness)のガイダンスが自動化されたことで、一人のトレーナーがクオリティを落とさずに一度に16人までの顧客に対応できるようになりました。

以上、見てきてみると最近の保険などでの事例とくらべ、何というか…オーソドックスなエキスパートシステム…的な…事例です。

このシステムがうまくいっているというのは、私の想像するに

・ルールの数は多いが、それぞれのルールは単純であり(たとえば脈拍が○○以上だからちょっとペースダウン云々?) 、他のルールに長く連鎖して動く(条件が○○だからゆえに××、××だからゆえに△△、△△だから結果□□…など)部分がない。

→したがって、ひとつひとつのルールが独立していて修正変更がしやすい。

・さまざまなケースで同じルールが適用できる。

→したがって、ルールの適用できる部分については自動で処理でき、人間の専門家は、ルールに当てはまらない例外的なケースへの対応に集中できる。機械的に対応できる部分を自動化されたルールに任せることで、いわばレバレッジの効果が生まれてくる。

・現場を知っているトレーナー自身でルールを変更できる仕組みを作った。

→ルールによって自動化ができると言っても、ルールそのものが最適な結果を導いているかは今までの経験や理論以上の保証がない。したがって、その結果はサンプリングするなりして常にルールに磨きをかけていく必要があります。その際、ITの専門家を通していると変更のスピードが落ちるだけでなく、仕様の伝達ミスなども発生しかねず、いろいろな意味で変更のコストが大きくなってきます。現場の専門家自身が変更できるようになり変更がより容易に行えるようになります。

さて、こんな事例が出てくるようになると、センサーデータを駆使してリアルでアドバイスをするようなCEPを使った事例などでてきそうな気もしますね。CEPではないですが、

などの事例も出てきています。
ヘルスケアなどは今後伸びていく分野だと言われています。そしてそのヘルスケアにBRMSが活用されてきています…ちょっとおもしろいと思いませんか。

ビジネスルール管理システムとエキスパートシステム(4)

(前項に続く)

さて、次の違いを見てみましょう。これはむしろ周辺環境の時代変化による違いだとも言えますが、

3.エキスパートシステムが流行っていた時代と比べて、コンピュータの性能が格段にアップし、メモリなどのリソースも潤沢となっている。

ルールエンジンというものは一般的に通常のアプリケーションよりメモリを食います。以前、ルールエンジンのコアアルゴリズムとして一般的なReteアルゴリズムについて書きましたが、このReteアルゴリズムではデータとルールの条件部分とのマッチング速度を稼ぐために、ルールとデータの部分的なマッチング状態もメモリ上に保持しているので、メモリを食わないわけがないというわけです。
この問題、昔は結構制約となる問題で、そのおかげでエキスパートシステムはリソースの豊富なワークステーションでしか動かせなかったりしたものでした。しかし現在はPCでも普通にギガレベルのメモリを積みCPUの速さも格段に速くなったので、それなりの大きさの問題をPC上で動かせるようになっています。PCが開発環境や運用環境に利用できるようになったことで、ルールエンジンは、以前に比べずいぶんと身近になったと言えましょう。
そんな身近になったルールエンジンですが、このルールエンジン、アルゴリズム上、比較的単純なことを行うにもメモリやCPUパワーなどのリソースを通常のアプリよりも贅沢に使います。これに関して、そんなにメモリを消費して如何なものか?という意見も聞こえてきそうですが、これはルールエンジンに限らず、WindowシステムなどのGUIやRDBMSなども昔の技術に比べればパワーを贅沢に使っているものではないかと・・・人間にとって扱いやすくすることと引き換えに、リソースを贅沢に使うようになるというのは時代の常なのかもしれませんね。

また周辺環境の時代変化による違いとしてもうひとつ

4.システム間でのデータの受け渡しが容易になってきている。

エキスパートシステムが流行っていた時代、企業の基幹システムが汎用機上で動いている一方、エキスパートシステムは、それらシステムとは切り離されたワークステーション上でスタンドアローンで動いているのが一般的でした。前にも書いたと思いますが、エキスパートシステムを動かすための基礎データを入力するために、汎用機とワークステーションの間で、フロッピーでデータをやりとりしていたこともあります。
ところが、現在のBRMSは、基幹システムなどの他のシステムとは、たとえばWebサービス、EJBなどを用いて以前に比べればずいぶんと容易にデータの受け渡しが可能となっています。
このシステム間でのデータのやりとりの障壁が劇的に低くなったことのおかげで、ルールエンジンの適用分野もぐっとひろがりました。そもそもルールエンジンがスタンドアローンでクローズなコンピュータの上に載っている時代に、ルールで一般的な業務システムの入力の相関チェックをやろうという発想が出てくるとも思えないでしょう。

以上、ビジネスルール管理システム(BRMS)とエキスパートシステムという題で書き続けてきました。エキスパートシステムはIT技術の表舞台から去って20年あまり経ちます。ところが、まあ20年も経つとコンピュータの周辺環境も大きく変わって、以前大きな制約となっていたリソースやデータの受け渡しなどの問題が飛躍的に改善されてきた…というか制約として認識されない程度にまで環境が改善してしまいました。それにともない以前は応用人工知能という枠の中に収まってしまっていたルールエンジンも、利用する上での敷居が大幅に低くなり、「BRMS」として新たな開発環境、運用環境、方法論をともなって適用分野を広げ再生してきています。

さらに最近では「ビジネスルール」の管理システムというところから、「デシジョン」管理システム(意思決定管理システム)、「ナレッジ オートメーション」という方向に進んできています。デシジョン管理という言葉は、もともとFICOが「Enterprise Decision Management」と言いだしたのがはじまりですが、最近ではIBMなども、ツールの名称を IBM WebSphere Operational Decision Management と改称したり、時代の流れとしてはそういった方向に行っています。
いずれそういったところもブログで書いていこうかと思っておりますが、ひとまずは参考文献として、

サイト
ビジネスルール管理からデシジョン管理の時代へ

デシジョンについて

文献
Decision Management System (2011)

Knowledge Automation (2012)

Smart Enough Systems (2008)

をあげておきます。

ビジネスルール管理システムとエキスパートシステム(3)

(前項の続き)
1番目は対象分野の違いと書きましたが、その違いによって開発ツールの力点の違いがでてきます。

2.開発ツールの力点の違い

・BRMSは、比較的単純で明確なルールを容易に書け、ビジネスユーザ自身でもルールを記述できることを目指している。
・一方で、エキスパートシステムは、専門家の知識をきちんと表現できるように、複雑なルールも書きやすくしているかわりに、ルールの記述はツールの使い方を習得した専門の担当者でないと難しいようになっている。

(もっとも今のBRMSでも昔のエキスパートシステムシェルでも使っているルールエンジンのコアアルゴリズムはそれほど変わっていないのでルールの記述力としては同じです)

実際、昔のエキスパートシステム開発ツール(シェル)のいくつかは、生のLispやPrologが垣間見えるところがあったりして、さすがにこれを使ってユーザが直接ルールを直すというのはちょっと…という感がありました。しかし、最近のBRMSでは簡単なルールを簡単にわかりやすく記述するというところが徹底されて(もしくは徹底しようとして)いて、さらに、それを前提としたルールのリポジトリや容易なデプロイのしくみなど、まあ言ってみれば至れり尽くせりの方向に進んでいます。

この方向性というのは、結局のところBRMSの概念のもうひとつのルーツである、ビジネスルールアプローチの影響かと思います。

実は、ビジネスルールアプローチについても前に書きかけていたり(^^;)したのですが

ビジネスルールアプローチ(1)

これは、そもそもIBMのGUIDEの1993年に始まる Business Rules Project の中から生まれてきたものです。それまで企業をモデリングするというと、データの側面からや機能の側面からのモデリングは試みられてきたものの、企業が日常のオペレーションを行っていく上での制約といった側面は看過されておりモデリングされてきていませんでした。以上の反省から、このプロジェクトでは、企業のオペレーションのコントロール、構造といった部分をビジネスルールを用いてモデリングすることを目指しました。ちなみにこの辺は、Business Rules Groupのサイトにある

Defining Business Rules ~ What Are They Really?

を見ていただくとわかるかと。ちなみにこのプロジェクトのメンバーを見てみると、E.F. Codd とか John Zachman などといった錚々たる顔ぶれが並んでいてちょっとびっくりします。また、のちにビジネスルールアプローチを推進していく中心的な人物 Barbara von Halle や Ronald Ross の名前も見えます。

(ちょっと脱線しますが、このようにビジネスルールの考え方は、関係データベースやEAの祖を含めた人々が集まって作られてきました。データベースの教科書で有名な C.J.Dateもルールに関する本を書いています。)

さて、メンバーであった Barbara von Halle は、その後2001年にビジネスルールアプローチの具体的な開発方法論を次の本にまとめています。

Business Rules Applied: Building Better Systems Using the Business Rules Approach

この中で、Barbara Von Halle は、BRAの原則としてSTEPということを言っています。詳しくはすでに上記にあげた記事の中で書いているのでそちらを参照するとして、原則だけ列挙しておきましょう。

Separate rules(ルールを分離せよ)
Trace rules(ルールがトレースできるようにせよ)
Externalize rules(ルールを外部化せよ)
Position rules for change(変更を前提にルールを配置せよ)

最近のBRMSはまさに上の原則を満たすような形につくられています。
最初にエキスパートシステムの中で実装レベルであらわれた「ルール」の考え方は、ここにいたってビジネスルールアプローチであらわれてきた概念レベルの「ビジネスルール」とドッキングして、BRMSというツールが生まれたわけです。
(この項続く)

(補足)
私が日経コンピュータの例の記事の「ビジネスルール特化型」のBRMSと「オールインワン型」のツールとをしつこく区別しようとしているのは、記事ではBRMSの背景にあるこういった考えをまったく無視しており、自動生成のツールを十把一絡げに「BRMS」という言葉でくくってしまっているからです。たとえば、RDBMSとNoSQLのDBMSを同じDBだからと言って「RDBMS」という言葉でくくってしまっているようなもので、さすがに乱暴すぎるだろうということ…芸人ではないのだから、あまりに ワイルド にすぎるかと。

ビジネスルール管理システムとエキスパートシステム(2)

(前回の続き)
ビジネスルール管理システム(BRMS)とエキスパートシステムとの違いとして、前回あげたのは適用する分野が違うということでした。まずは、その説明から

1.適用する例が違う

現在BRMSが使われている事例としては、入力データの相関チェックとか、保険などの査定などが多く見られます。これらは、処理そのものはそれほど複雑ではありません。また実装されるルールも規程などですでに明文化されていたり、仮に明文化されていないものであっても明確に表現することが可能なものであり、根拠がはっきりしていることが特徴です。

一方エキスパートシステムの事例は、医療診断や生産計画など、いわゆる専門家と呼ばれる人々の知識をルールの形で実装していくものであり、処理が一般的に複雑です。また、実装されるルールの多くはエキスパートの頭の中だけに存在する暗黙知であり、知識を引き出すのが難しいうえ、その根拠も不明瞭なケースが多々あります。

たとえばこんな感じ・・・
PETボトルの原料であるPET樹脂はさまざまなところで使われており、溶かしてフィルム上に加工し、ポイントカードのベースや、コンデンサーの絶縁体等々に使われていたりします。こういったフィルムに加工するラインの生産計画を立案するエキスパートシステムでは、たとえば以下のようなルールがありました。

「濃色の品種のあとに、ライン洗浄せずにより淡色の品種を生産してはいけない」

(フィルムには、透明なもの、淡色のもの、濃色のものなどがあり、またラインも定期的に洗浄したりします)

このルール、常識的に考えれば素人でも理解はできる当たり前のルールですが、必ずしもMUSTの条件ではありません。納期や生産量の都合と品質上の歩留まり等をてんびんにかけてあえて破ったりすることもあります。この、さまざまな状況を勘案してあえて破ることができる能力を持つというのが専門家の専門家たる所以なのでしょうが、この「さまざまな状況を勘案する」というところの知識を専門家から引き出してルールに落としていく・・・
そうしてできたシステムがエキスパートシステムになります。

こういった知識を引き出してくるのが簡単なことでないことは容易に想像のつくところ。実際エキスパートシステムが流行っていたころは、知識獲得という技術を持ったナレッジエンジニア(KE)という言葉があったものでした。

それに比べ、BRMSが対象とするルールは、

入力された銀行コードが銀行マスタになければエラーを出す
最高血圧140以上、最低血圧100以上なら血圧の評点が50
業種が建設業の企業の保険料率は○○

など、いわゆる普通の業務システムの仕様に書かれていてもおかしくないようなルールです。

以上のことをまとめると、

  • BRMSが対象としているのは、普通の業務システムが普通に実装しているようなビジネスロジックをもつ分野
  • エキスパートシステムが対象としているのは、通常の業務システムの手法ではおよそ対応ができないような複雑なビジネスロジックを持つ分野

ということになります。
ところで、BRMSが普通の業務システムが普通に実装しているようなビジネスロジックを対象としているというのだったら、これからわざわざBRMSを導入する必然性がないではないかという疑問がでてくるでしょう。これに対する回答は今回の記事の趣旨からはずれるので別途あらためて記事にしようかと思っていますが、簡単に言うと

  • ビジネスロジックの変更のしやすさ
  • ビジネスロジックの見える化

ということになるかと思います。ビジネスロジックをルールの形でシステムの他の部分から切り離して外部化することにより、上に書いたように、変更のしやすさ、ロジックの見える化が実現できます。

上記の対象の違いによって、次にあげる

2.開発ツールの力点の違い

もあらわれてくることになります。(この項続く)

ビジネスルール管理システムとエキスパートシステム(1)

最近、日経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?

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

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

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

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

1.適用する対象の違い

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