JP6152313B2

JP6152313B2 - 仮説検証装置及び仮説検証システム

Info

Publication number: JP6152313B2
Application number: JP2013154898A
Authority: JP
Inventors: 孝文栢
Original assignee: 孝文栢
Priority date: 2013-07-25
Filing date: 2013-07-25
Publication date: 2017-06-21
Anticipated expiration: 2033-07-25
Also published as: JP2015026208A

Description

本発明は、仮説検証装置及び仮説検証システムに関し、特に、体にいいと言われている仮説の妥当性を検証する、仮説検証装置及び仮説検証システムに関する。

従来、健康診断結果に基づいて健康指導を行うシステムが、特許文献１に開示されている。具体的には、健康指導対象者に指導を行った後、一定期間を経過した時に指導内容に効果があったかどうか評価することが開示されており、健康指導における健康状態の判断及び健康指導内容指示時の判断を明らかにし、その判断結果を記録することにより判断のプロセスを再検証することを可能としている。

特開２００７−１９３７１４号

しかし、特許文献１に開示されている発明は、健康指導対象者の各々に対して指導内容に効果があったかどうか評価することはできても、一般的に体によいとされている行動の内容の妥当性については判断のしようがない。このため、このような行動は、体にとって良さそうであるといった仮説をもとに指導を行っている域を脱するものではない。今日においては、健康に関する情報は多いといえるが、正しくないものも存在する。例えば、ある商品を売りたいがために出している誇大な情報が含まれている場合もありうる。

したがって、特許文献１に開示されている発明では、健康指導対象者は指導通りに行動したとしても、その健康指導対象者にとって特段良い行動にはならず、健康状態が向上しなかったり、そればかりか、反対に、健康状態を悪化させたりすることすらありうる。

ここで、健康指導対象者の個体差により、特定の行動が、一の健康指導対象者にとって有益であったとしても、他の健康指導対象者にとっては無益或いは有害であることもありうる。それでも、健康指導対象者の身体的特徴などから、健康指導対象者をグルーピングでき、そのグループの健康指導対象者間では体によいとされている行動が共通する傾向がある。

したがって、当該グループ毎に体によいとされている行動について、その内容の妥当性について判断ができれば、将来的には、そのグループに属する健康指導対象者向けに妥当性のある健康指導を行うことが可能となる。

そこで、本発明は、健康指導対象者であるユーザの個体差を考慮しつつ、健康指導の内容自体の妥当性を検証することを課題とする。

上記課題を解決するために、本発明の仮説検証装置は、
ユーザからの第１問診データに基づく第１ミッションデータを送信する手段と、
前記第１ミッションデータがユーザによって遂行された後に送信される第２問診データ及び前記第１ミッションデータに係るユーザのミッション達成率を受信する手段と、
前記第１問診データと前記第２問診データとにおける属性の変化の有無を前記ミッション達成率を考慮して判定する手段と、
前記判定手段によって属性が変化したと判定された場合に前記第１ミッションデータとは異なる第２ミッションデータを送信する手段と、
前記判定手段による判定結果を表示する手段と、
を備える。

また、本発明の仮説検証システムは、
上記仮説検証装置と、
前記仮説検証装置に対して前記第１及び第２問診データと前記ミッション達成率とを送信するユーザ端末とを備える。

本発明の実施形態の仮説検証システムの模式的な構成図である。図１の問診データ等ＤＢ４００に登録されるグループＡの各ユーザの問診データ等の例を示す図である。図１の作成手段２６０によって作成されるグループＡの各ユーザの問診データ等及び判定結果の例を示す図である。図１に示す管理者サーバ２００の動作を示すフローチャートである。図１に示す管理者サーバ２００の動作を示すフローチャートである。

１００ユーザ端末
２００管理者サーバ
２１０通信手段
２２０グループ特定手段
２３０ミッションデータ選択手段
２４０登録手段
２５０判定手段
２６０作成手段
３００属性−ミッションデータベース（属性−ミッションＤＢ）
４００問診データ等データベース（問診データ等ＤＢ）
５００管理者端末

発明の実施の形態

以下、本発明の実施形態について、図面を参照して説明する。

図１は、本発明の実施形態の仮説検証システムの模式的な構成図である。図１には、以下説明する、ユーザ端末１００と、管理者サーバ２００と、属性−ミッションデータベース（以下、「属性−ミッションＤＢ」と称する。）３００と、問診データ等データベース（以下、「問診データ等ＤＢ」と称する。）４００と、管理者端末５００とを示している。

ユーザ端末１００は、ユーザによって操作される端末であり、主として、管理者サーバ２００から送信される、仮説であるところの複数のミッションを含むミッションデータを受信し、ユーザによる当該ミッションの遂行後に、当該ユーザの問診データを送信するものである。ユーザ端末１００は、管理者サーバ２００との間で無線又は有線通信を行うことが可能な、携帯電話機、スマートフォン、パーソナルコンピュータなどとすることができる。ユーザ端末１００は、スマートフォン、ノート型パーソナルコンピュータのような携帯型端末であってもよいし、デスクトップ型パーソナルコンピュータのように据置型端末であってもよい。

管理者サーバ２００は、本実施形態の仮説検証システムの管理者によって管理されるサーバ（仮説検証装置）である。管理者サーバ２００は、以下説明する、通信手段２１０と、グループ特定手段２２０と、ミッションデータ選択手段２３０と、登録手段２４０と、判定手段２５０と、作成手段２６０とを備える。これらの各手段による機能は、たとえば、ＣＰＵとメモリとの協働によって実現すればよい。

通信手段２１０は、ユーザ端末１００から送信される問診データ等の各種データを受信するとともに、ユーザ端末１００に対してミッションデータなどの各種データを送信するものである。なお、問診データとは、病院等においてなされる健康診断或いは初診の際に被験者或いは患者から回答してもらう性別、年齢、体重、飲酒量、喫煙量など、可能であればこれらに加えて血圧、血糖値、更には、目覚めの善悪、頭痛持ちの有無、持病の有無などの種々の属性データを適宜含められるようにしている。

グループ特定手段２２０は、通信手段２１０によって受信された問診データから、当該ユーザの属性に基づくグループを特定するものである。ユーザの属性とは、性別、年齢、体重などのユーザ自身の属性をいい、そのグループとは、例えば、「『やせ型』の『３０代男性』で『一日当たりタバコ１０本程度吸う』、『目覚めの悪さを自覚している』グループＡ」、「『肥満型』の『４０代女性』で『週にビール３本・日本酒３合程度飲む』グループＢ」、「『闘士型』の『２０代男性』で『風邪をひきやすいと自覚している』グループＣ」などに区分けされたグループをいう。

ここで、仮にミッションの妥当性を検証するために、研究者等がモニターを募ろうとしても、通常、上記のような細分化したグループを実現するのに充分な何万人ものモニター数を集めることは非常に困難である。したがって、ここまで細分化したグループを実現できず、「やせ型の３０代男性のグループ」、「肥満型の４０代女性で多少飲酒をするグループ」、「闘士型の２０代男性のグループ」といったグループ分け程度しか行うことができない。

しかし、本実施形態の仮説検証システムの場合には、ユーザ端末１００さえ操作できればよく、今日のネットワークの進歩、ユーザ端末の普及率からすれば、ユーザの総数は非常に大きな数となるので、上記のような細分化したグループを容易に実現することができる。

ミッションデータ選択手段２３０は、グループ特定手段２２０によって特定されたグループ情報に基づいて、属性−ミッションＤＢ３００を参照し、当該グループ情報に対応するミッションデータを選択するものである。また、ミッションデータ選択手段２３０は、ユーザ端末１００からミッション終了後に問診データが送信されてきた場合に、当該問診データに含まれるミッションの達成率、問診データにおける属性の変化等に基づいて、次にユーザに課すミッションを選択するものである。

登録手段２４０は、通信手段２１０によって受信された問診データ等の各種データを、問診データ等ＤＢ４００に登録するものである。具体的には、各々のグループに属するユーザ毎に、相互に問診データ等を経時的に紐づけて登録する。

判定手段２５０は、ミッションデータ選択手段２３０によって選択されたミッションデータの遂行による、ユーザの問診データにおける属性の変化の有無を判定するものである。判定手段２５０は、問診データ等ＤＢ４００に登録されている各種データに基づいて、主として、ユーザの属するグループ毎に、ユーザ毎のミッションの達成率を考慮してユーザの属性の変化の有無を判定する。

具体的には、例えば、ミッションの達成率が７０％以上のユーザのうち、多くのユーザに共通して向上している問診データにおける属性があれば、それには少なくともいずれかの一つのミッション、又は、いくつか組み合わせたミッションが寄与していると考えられる。そこで、それらのミッションのいずれかを削除又は別のものに変更するなどして、効果的な一つのミッション又はいくつか組み合わせたミッションを特定することができる。

作成手段２６０は、判定手段２５０による判定結果を、管理者端末５００のディスプレイに表示させるための各種処理を行うものである。作成手段２６０による処理としては、例えば、判定結果をグラフ化したり、数値化したり、管理者の指示に基づいて加工可能に処理することができる。

属性−ミッションＤＢ３００は、ユーザの属性とミッションデータとが対応して登録されているものである。例えば、グループＡの属性に対しては、
（１）１週間に少なくとも１回はサラダを食べ、
（２）エレベータ及びエスカレータよりも階段を使い、
（３）タバコの本数を１日５本までとする、
といったミッションデータが対応して登録されることが考えられる。この例示のように、本実施形態では、まずは、ユーザに対して、典型的には、その属性に基づいて体に良いと考えられる複数のミッションからなるミッションデータを課すようにしている。

なお、ミッションデータは、一の属性に対して複数用意されており、当該問診データに含まれるミッション達成率に基づいて、段階的に負荷を掛けたり、仮説の妥当性を検証のために変更したりするといった内容としている。また、ミッションを適宜変更することで、ユーザにはゲーム感覚のような達成感を与えて、本実施形態の仮説検証システムを継続して利用させるようにしている。

問診データ等ＤＢ４００は、問診データ等の各種データが経時的に登録されるものである。また、本実施形態の仮説検証システムでは、問診データとは別に、ユーザによるミッションの達成率を、ユーザ端末１００を通じて送信させるようにしており、問診データ等ＤＢ４００には問診データとともに、当該達成率も登録されるようにしてある。

管理者端末５００は、本実施形態の仮説検証システムの管理者によって操作される端末である。管理者端末５００は、これに限定されるものではないが、例えば、デスクトップ型パーソナルコンピュータなどを用いることができる。

なお、例えば、図１には、属性−ミッションＤＢ３００及び問診データ等ＤＢ４００を、管理者サーバ２００の外部に設けている例を示しているが、これらのＤＢ３００、４００は、いずれも又は少なくとも一方を、管理者サーバ２００の内部に設けるようにしてもよい。

図２は、図１の問診データ等ＤＢ４００に登録されるグループＡの各ユーザの問診データ等の例を示す図である。図２には、一例として、「ミッション達成率」、「性別」、「年齢」、「体重」、「血糖値」、「血圧」、「寝付き」の善悪、「目覚め」の善悪、「飲酒量」、「喫煙量」を示している。なお、これらの項目は例示であり、頭痛持ちの有無、持病の有無などを設けてもよい。

本実施形態では、ユーザによる問診データの入力を簡易なものとするために、問診データの解答欄を５つの選択肢としており、それに対応した数値が登録されている例を示している。具体的には、例えば、性別については、「１」を男性、「２」を女性に対応させていて、体重については、「１」を痩せすぎ、「２」を痩せ気味、「３」をふつう、「４」を太り気味、「５」を太りすぎといったような選択肢を用意している。なお、一般的に良い考えられる選択肢ほど数値が高くなるように設定しておき（上記例の場合、「ふつう」が５点、「痩せすぎ」が０点、「痩せ気味」が３点など。）、例えば問診データを１００点満点で数値化するということも、ユーザの数値目標につながり有効である。

図３は、図１の作成手段２６０によって作成されるグループＡの各ユーザの問診データ等及び判定結果の例を示す図である。図３に示す矢印は、図２に示すデータ例の変化に基づいて作成されるものである。ここでは、「達成率」の高いユーザについて「目覚め」の善し悪しが改善したことを示している。

ここで、グループＡに対して、
（１）１週間に少なくとも１回はサラダを食べ、
（２）エレベータ及びエスカレータよりも階段を使い、
（３）タバコの本数を１日５本までとする、
というミッションを与え、その結果として、達成率の高いユーザの多くが図３に示すような「目覚め」の善し悪しが改善したとする。この場合には、これらのミッションのうち少なくともいずれかが寄与していると判定されることになる。

したがって、この場合には、管理者は、ミッション選択手段２３０による選択対象が、１回目のミッションの達成率が高いユーザに対しては、例えば、
（１）１週間に少なくとも『２』回はサラダを食べ、
（２）エレベータ及びエスカレータよりも階段を使い、
（３）タバコの本数を１日５本までとする、
という２回目のミッションとなるような選択条件を設定する。

また、その後、更に、管理者は、ミッション選択手段２３０による選択対象が、２回目のミッションの達成率が高いユーザに対しては、例えば、
（１）１週間に少なくとも２回はサラダを食べ、
（２）エレベータ及びエスカレータよりも階段を使い、
（３）タバコの本数を１日『３』本までとする、
という３回目のミッションとなるような選択条件を設定する。

この結果として、仮に、達成率の高いユーザのうち、多くのユーザについて「目覚め」が２回目のミッション後に劇的に変化しなかったが、３回目のミッション後に劇的に変化したような場合には、グループＡに属するユーザに対しては、一週間あたりにサラダを食べる回数よりも、タバコの本数を減らすことが寄与しているではなかろうかという判定結果が得られることになろう。

さらに、管理者は、３回目のミッションの達成率が高いユーザに対しては、例えば、
（１）１週間に少なくとも２回はサラダを食べ、
（２）エレベータ及びエスカレータは『原則的に一切使用せず』、
（３）タバコの本数を１日３本までとする、
という４回目のミッションとなるような選択条件を設定する。

この後の問診データで、達成率の高いユーザの多くの「目覚め」が更に改善されたとするならば、グループＡに属するユーザに対しては、適度な運動量を増やすことで、「目覚め」が良くなるということを結論付けてよいということになろう。このような作業を繰り返すと、やがてはミッションの各々が、どのようなユーザにとって好ましいかということが非常に高確度でわかるようになり、これにより、ユーザにおいてもミッションを遂行しようというインセンティブが働くことになるという効果もある。

もっとも、上記の１回目〜４回目のミッションは例示であり、例えば、「エレベータ及びエスカレータよりも階段を使い」といったミッションに代えて、「週に１回はランニングし」といったミッションを含むミッションデータが選択される内容となるようにミッションの選択条件を設定してもよいし、このミッションデータが、その後の５回目に選択される条件として設定してもよい。なお、ミッションの数は３つであることが必須ではなく、５つ程度としてもよい。ただし、あまりに多くなると、ミッション達成率が低下してしまうので、３つ〜５つ程度とすることが好ましい。

これにより、相対的に負荷のかかる運動を週に１回行うことと、相対的に負荷のかからない運動を日常的に行うこととのいずれが「目覚め」等に寄与しているか分かることにもつながる可能性がある。

仮に、５回目のミッションを
（１）１週間に少なくとも２回はサラダを食べ、
（２）週に１回はランニングし、
（３）タバコの本数を１日３本までとする、
というものにした場合に、達成率の高いユーザの多くの「目覚め」が良くなっていないとしたら、「目覚め」については、ランニングのような相対的に負荷のかかる運動よりも、相対的に負荷のかからない運動を毎日継続的に行うことが好ましいという判定がされることになろう。

また、仮に、５回目のミッションを行った結果、達成率の高いユーザの多くの「寝付き」が良くなったとしたら、週に１回程度のランニングは「寝付き」の良さに寄与すると仮定することができよう。

したがって、この場合には、６回目のミッションを
（１）１週間に少なくとも２回はサラダを食べ、
（２）週に『２』回はランニングし、
（３）タバコの本数を１日３本までとする、
といった内容となるように選択条件を設定してもよい。

この結果、達成率の高いユーザの多くの「寝付き」が更に良くなったとしたら、「週に『２』回はランニング」を「週に『３』回はランニング」と変更した７回目のミッションが与えられるようなミッションの選択条件を設定してもよい。この結果、達成率の高いユーザの多くの「寝付き」に変化が見られなくなったら、「寝付き」向上のためにランニングを行う場合には、週に２回でよいといった判定がされることになろう。

なお、ここでは、本明細書では説明の理解容易のために、比較的ラフなミッション例を示しており、もちろん、この程度のミッションとすることでもよいし、例えば、ランニングについてみれば、毎回ジョグ程度の速さで２０分程度行うといった比較的細かいミッションとすることもできる。

図４，図５は、図１に示す管理者サーバ２００の動作を示すフローチャートである。図４，図５に基づいて、ユーザ端末１００として、スマートフォンを用いる場合を例に、図１に示す仮説検証システムの動作について説明する。

まず、ユーザは、ユーザ端末１００を操作することによって、仮説検証システム用のアプリケーションソフトウェアをダウンロードして、それをユーザ端末１００にインストールする。その後、ユーザが当該アプリケーションソフトウェアを起動して、氏名、性別、年齢、メールアドレスなどの通信情報等を入力して送信ボタンを押下するなどすれば、管理者サーバ２００に対して問診票の送信依頼が行われる。

管理者サーバ２００では、通信手段２１０によって、ユーザ端末１００からの問診票の送信依頼が受信されると（ステップＳ１１）、予め用意してある問診票データが問診票の送信依頼元のユーザ端末１００に対して送信される（ステップＳ１２）。

その後、ユーザ端末１００において、その問診票データが受信され、ユーザがユーザ端末１００に自己の問診データを入力して送信ボタンを押下するなどすれば、ユーザ端末１００から管理者サーバ２００に対して、問診データが送信される。

管理者サーバ２００では、通信手段２１０によって、問診データが受信されると（ステップＳ１３）、グループ特定手段２２０によって、その問診データの内容に基づいて、そのユーザの属性に基づくグループが特定される（ステップＳ１４）。

つづいて、管理者サーバ２００では、ミッションデータ選択手段２３０によって、そのグループ情報に基づいて属性−ミッションＤＢ３００が参照され、当該グループ情報に対応するミッションデータが選択される（ステップＳ１５）。当該ミッションデータは、通信手段２１０によって、ユーザ端末１００に対して送信される（ステップＳ１６）。

その後、管理者サーバ２００では、ユーザ端末１００から送信された問診票の送信依頼時にユーザ端末１００から送信された氏名、性別、年齢、メールアドレスなどの通信情報等を、問診データとともに問診データ等ＤＢ４００に登録する（ステップＳ１７）。

以上の処理によって、本実施形態の仮説検証システムにおける会員登録など初期処理が完了する。

その後、ユーザが、管理者サーバ２００から与えられたミッションを遂行し、新たに問診データをユーザ端末１００に入力して、管理者サーバ２００に送信したとする。係る場合には、管理者サーバ２００では、通信手段によって、問診データが受信されると（ステップＳ２１）、ミッションデータ選択手段２３０によって、属性−ミッションＤＢ３００が参照され、当該問診データとともに送信されるミッション達成率に基づいて、次のミッションデータが選択される（ステップＳ２２）。

具体的には、本実施形態では、例えば、ミッションの達成率が５０％以上であれば、次のミッションをユーザに与え、一方、ミッションの達成率が５０％未満であれば、引き続き同じミッションをユーザに与えるようにしている。したがって、ここでいう次のミッションは、例えば、ミッションの達成率が５０％未満であるような場合には、直前にユーザに与えたミッションと同じミッションとする場合、或いは、それよりも前にユーザに与えたミッションと同じミッションとする場合も含むものとする。また、次のミッションの例は、既述のように、例えば、ミッションの一つについて負荷をかけたような内容のものとすることができる。

これは、後述の作成手段２６０によって作成され、管理者端末５００のディスプレイに表示される内容に基づいて、管理者が属性−ミッションＤＢ３００に設定できるようにしてある。当該次のミッションデータは、通信手段２１０によって、ユーザ端末１００に対して送信される（ステップＳ２３）。

その後、管理者サーバ２００では、ユーザ端末１００から送信された問診データを、問診データ等ＤＢ４００に登録する（ステップＳ２４）。つぎに、管理者サーバ２００では、前回の判定処理から所定期間が経過しているかを確認する（ステップＳ２５）。確認の結果、所定期間が経過していない場合にはステップＳ２１へ移行し、所定期間が経過している場合には、判定手段２５０によって判定を行う（ステップＳ２６）。

具体的には、判定手段２５０は、問診データ等ＤＢ４００に登録されている各種データに基づいて、例えば、ユーザの属するグループ毎に、本仮説検証システムの使用開始から３ヶ月以上経過しており、かつ、直近の３ヶ月のミッションの達成率が７０％以上の問診データだけを抜き出し、問診データにおける属性の変化の有無を判定する。

これにより、ミッション開始直後の問診データであることでまだ改善が見られない問診データの影響や、ミッションの達成率が低くて改善が見られない問診データの影響を排除することができる。

そして、抜き出した問診データのうち、既述の矢印が、その項目で例えば７０％を超えるものについては、複数のミッションのうち、少なくともいずれかの一つのミッション、又は、いくつか組み合わせたミッションが寄与しているという判定結果となるようにしている。

つづいて、作成手段２６０は、判定手段２５０による判定結果を管理者が閲覧出来るように、管理者端末５００のディスプレイに表示させるための各種処理を行い、表示用データを作成する。また、管理者は、判定結果を閲覧することで、新たなミッションを作成することもできるようになる。

本実施形態では、ユーザ端末１００としてスマートフォンを用いる場合を例に説明したが、パーソナルコンピュータを用いる場合には問診データ等はブラウザを通じて管理者サーバ２００に送信するようにすればよい。

Claims

複数のミッションを含むｎ回目のミッションデータを複数のユーザ端末に対して送信するとともに、当該ｎ回目のミッションデータを遂行したユーザから各々送信されるｎ回目の問診データ及び前記ｎ回目のミッションデータに係るユーザのミッション達成率を受信する手段と、
前記ｎ回目のミッションデータに係るユーザのミッション達成率を考慮して前記ｎ回目の問診データで改善が見受けられる問診事項が存在する場合に、前記複数のミッションのうち少なくとも一のミッションの負荷を高めたｎ＋１回目のミッションデータを前記ユーザ端末に対して送信するとともに、前記ｎ＋１回目のミッションデータを遂行したユーザから各々送信されるｎ＋１回目の問診データ及び前記ｎ＋１回目のミッションデータに係るユーザのミッション達成率を受信する手段と、
前記ｎ＋１回目のミッションデータに係るユーザのミッション達成率を考慮して、前記ｎ＋１回目の問診データで前記問診事項に更なる改善が見受けられる場合に前記一のミッションが当該問診事項の改善に寄与していると判定する手段と、
を備える仮説検証装置。
前記ｎ＋１回目のミッションデータに係るユーザのミッション達成率を考慮して、前記ｎ＋１回目の問診データで前記問診事項に更なる改善が見受けられない場合に、前記複数のミッションのうち前記ｎ＋１回目のミッションデータにおいて負荷を高めたミッションとは別のミッションの負荷を高めたｎ＋２回目のミッションデータを前記ユーザ端末に対して送信するとともに、前記ｎ＋２回目のミッションデータを遂行したユーザから各々送信されるｎ＋２回目の問診データを受信する手段と、
前記ｎ＋２回目の問診データで前記問診事項に更なる改善が見受けられる場合に前記別のミッションが当該問診事項の改善に寄与していると判定する手段と、
を備える請求項１記載の仮説検証装置。
前記判定の結果を表示する手段を備える請求項１又は２記載の仮説検証装置。
前記判定の結果をグラフ化、数値化、又は、管理者の指示に基づいて加工可能に処理する、請求項１又は２記載の仮説検証装置。
請求項１記載の仮説検証装置と、
前記仮説検証装置に対して前記各問診データと前記各ミッション達成率とを送信するユーザ端末とを備える、仮説検証システム。