皆さん、こんにちは。本日はご参加いただきありがとうございます。本日は、私が携わったプロジェクトについて講演させていただきます。タイトルは「開発からテストへ：JMPアドインの作成と検証の道のり」です。
少しだけ自己紹介をさせていただきます。まずは自己紹介をさせてください。私は現在、アメリカのクレムソン大学で数理科学の博士号取得を目指して大学院生として学んでいます。研究分野は幅広く、実験計画法と選好学習です。2024年の夏からJMPのDOE & 信頼性チームでインターンシップをしています。インターンシップ中は、離散選択実験とソフトウェアテストの両方に関連するプロジェクトに携わってきました。この2つは全く異なる分野です。自己紹介はこれくらいにして、この辺で。
本日の講演の概要をご説明いたします。まず、講演の最初のセクションでは、夏に開発したこのアドインを作成した理由についてお話しします。JMPのプログラム「Easy DOE」のユーザビリティ調査を実施し、ユーザーベースの様々な人口統計グループに属する個人のユーザーインターフェースの嗜好を把握しようとしたのがきっかけです。その後、このアドインを作成した理由をお話しした後、実際にアドインについて説明し、デモを行います。最後に、作成したアプリケーション、つまりアドインを検証するために、JSLユニットテストフレームワークを使ってアドインをテストした方法について少しお話しします。
最初のセクションです。アドインを作成した動機についてご説明します。ご存知の方もいらっしゃるかもしれませんが、JMPにはEasy DOEというプログラムがあります。このプログラムは、実験の設計と分析のプロセス全体を通して、ユーザーを支援するために使われます。Easy DOEのワークフローは、いくつかの異なるコンポーネントで構成されています。実験者はまず、関心のある因子と反応を定義します。次に、収集するデータを分析するために使用するモデルを選択します。モデルを選択したら、そのモデルに基づいて実験を計画します。
実験を設計したら、実験を実行し、収集したデータをデータ入力タブに入力します。データが収集されたら、モデルを分析できます。データを分析し、モデルを適合させます。最後に、そのモデルを使用して予測を行い、必要に応じて最適な因子設定を選択します。最後に、モデルの概要レポートを確認できます。
本日特に注目していただきたいのは、この「分析」タブです。Easy DOEをご利用いただいた方ならご存知のとおり、分析タブは図2に示すような外観です。夏の間、私たちは「分析」タブの特定の部分にどのような変更を加えることで、Easy DOEを使用する実験者やユーザーにとってより使いやすくなるかを検討していました。最終的に、ユーザーに表示されるUIのバージョンをいくつか提案し、どのバージョンが最も好まれるかを把握したいと考えました。
このUIデザインは、因子構造に基づいて設計されました。UIの中で特に注目したのは、このホバーヘルプです。このホバーヘルプには、モデルの統計特性についてユーザーに通知するいくつかの異なるメッセージが表示されます。ホバーヘルプ設定のメッセージには、モデルに用語が入力されたかどうかを示す「入力メッセージ」などがあります。このメッセージには2つのバージョンがあります。「有意性メッセージ」は、用語が有意であるかどうかを示します。「遺伝メッセージ」は、ある用語が有意ではないにもかかわらず、なぜモデルに含まれているのかを示します。
多くの場合、遺伝と呼ばれる特性があり、交互作用項が有意であっても主効果が有意でない場合、主効果をいずれにせよ含めます。最後に、このホバーヘルプ設定の最後の要素は、ホバーヘルプの位置です。信頼区間内に含まれるのか、それともプレビュー列上に表示されるのか、どちらでしょうか？
これらの設定のうち、ユーザーが最も好むのはどれなのかを知りたかったのです。先ほども申し上げたように、4つの要素がありました。そのうち2つ、あるいは3つは2段階、そして1つは3段階でした。つまり、ホバーヘルプ設定のユーザーインターフェースには、24通りのバージョンが存在する可能性があるのです。
もう一つの点は、Easy Doeのユーザーの多くは、実験計画法の初心者か、あるいは中程度の経験しかないということです。しかし、実験計画法の経験が豊富なユーザーもEasy Doeを利用しており、個人で使用したり、他の人に教えたりしています。Easy Doeには様々なユーザー層が存在します。そこで、それぞれのユーザー層がどのようなホバーヘルプの設定を好むのかを把握し、それぞれのユーザー層に合わせたホバーヘルプのデザインをカスタマイズしたいと考えました。
この問題へのアプローチとして、私たちはコンテキスト離散選択実験という枠組みを用いました。この枠組みについて少しお話しします。まず、データ収集プロセスについてお話しします。コンテキスト離散選択実験では、参加者グループと、参加者の共変量情報（例えば、共変量情報やコンテキスト情報など）が存在します。多くの場合、これはユーザーに関する人口統計情報となります。
このフレームワークでは、様々な参加者にアンケートを実施します。各質問において、2つ以上の代替デザインを比較し、より好ましいと思う方を選んでいただきます。データ収集プロセスは非常に直感的で、人々が現実世界でどのように選択肢を選ぶかを反映しています。
ここで、文脈的離散選択実験のモデリングと分析について少しお話しします。データを収集したら、そのデータに効用モデルを当てはめることができます。このモデルには、調査対象の要因（今回の場合はホバーヘルプの設定）だけでなく、参加者から得られる文脈情報も含まれています。これら2つを組み合わせることで、異なる人口統計グループの異なるユーザーにとって、異なるホバーヘルプ設定がどのような選好度を持つのかを把握することができます。最終的に、この効用モデルを当てはめることで、各人口統計グループにとってどのホバーヘルプのデザインが最も好まれるかを学習したり、特定したりすることができます。
文脈的離散選択実験の重要な要素の一つは、実験の設計です。参加者に提示する質問をどのように選ぶのでしょうか？通常の離散選択実験に慣れている方ならご存知でしょうが、離散選択実験を適切に設計するには、ユーザーの好みに関する事前情報が必要になることがよくあります。
文脈的離散選択実験では、まずいわゆるスクリーニング調査を実施します。まず、一定数の参加者からコンテキスト情報または人口統計情報を取得し、その後アンケートに回答して選好データを収集します。このスクリーニング調査から、スクリーニング調査におけるユーザーの選好を特徴付けるモデルを構築します。このモデルを用いることで、異なる人口統計グループにおける選好を理解することができます。
したがって、このモデルを用いてベイズ事前分布を作成し、アンケートのベイズD最適設計を作成することができます。これを用いて、各人口統計グループを対象としたアンケートを作成し、そのグループからより効率的に統計情報を取得できるようになります。これが、私たちが目指した方法論、つまりこの問題へのアプローチです。参加者に配布する非常に統計的に効率的なアンケートを作成し、より効率的に情報を収集し、異なる人口統計グループ間の好みを把握したいと考えました。
ここで、このアドインの実際の作成方法について少しお話しします。まず、JSLとはJMPスクリプト言語のことです。JSLを使うと、JMPの機能を拡張することができ、例えば、定型的なマルチステップ分析を実行したり、毎日生成されるデータに特定のモデルを当てはめたりといった様々なことが可能になります。JSLはまさにJMPの機能を拡張することを可能にします。JMPアドインとは、JMPの機能を拡張するJSLスクリプトであり、他のJMPユーザーがダウンロードして使用できるものです。
なぜ私たちは特定の問題に対してJMPアドインを作成したのでしょうか？まず、私たちは複数のユーザビリティ調査を実施していました。ホバーヘルプ設定に関する同じユーザビリティ調査を、異なる時期に実施していました。時間の経過とともにデータが蓄積され、それを基に実験設計やユーザーに送付するアンケートを改良していました。また、ユーザーインターフェースの様々な要素が変化する可能性のある、異なるユーザビリティ調査も実施しています。例えば、あるユーザビリティ調査では、「分析」タブの通知メッセージの配色と配置について調査しました。
このアドインを作成したもう一つの理由は、文脈依存の離散選択実験の作成が面倒になる可能性があるためです。各グループのベイズD最適計画を作成するために、事前平均と共分散行列を計算する必要があることが多々ありました。私たちは、これをJSLスクリプトで自動化できることを発見しました。
最後に、この文脈的離散選択実験のフレームワークは、非常に幅広い選択タスクに活用できます。ユーザビリティ調査に限らず、ユーザーに複数の選択肢の中から好みを表明してもらう必要があるあらゆる種類の調査に活用できます。このアドインは、私たち自身のために開発するだけでなく、他の人々もこのアドインを使って問題を解決できるようにしたいと考えました。
コンテキスト離散選択アドインのワークフローについて少しお話しします。まず、ユーザーまたは実験者はスクリーニング調査からデータを収集する必要があります。スクリーニング調査には、参加者にどのような質問をしたか、どのような属性があったか、プロファイル属性、研究対象となった要因、被験者の共変量などの情報が含まれている必要があります。
これらのデータを入手したら、データにスクリーニングモデルを当てはめます。スクリーニングモデルでは、実験者はプロファイル効果の両方を指定する必要があります。今回の設定では、ホバーヘルプの設定と被験者効果の両方を指定しました。これにより、実験者は効用モデルを作成できます。そして、この効用モデルはJMPの選択分析プラットフォームを用いて推定されます。
入力が完了すると、ユーザーはさらなる研究を行う人口統計学的グループを選択します。これは、被験者効果または文脈的要因のそれぞれのレベルを選択することで行います。これらのレベルの組み合わせによって、さらなる研究を行うグループが特定されます。グループを選択すると、そのグループに対してベイジアンD最適設計またはベイジアンD最適質問票が作成され、実験者は統計的に効率的な方法でそのグループをさらに研究することができます。
それでは、コンテキスト離散選択実験アドインのデモをご覧ください。JMPを開いて「アドイン」に移動し、データテーブルを選択します。このデータテーブルには、ホバーヘルプに関して実施された過去のユーザビリティ調査の情報が含まれています。ユーザーがどのオプションを選択したか、どのようなオプションが提示されたか、といった情報が含まれているのがわかります。実験計画法の経験レベルや、Easy DOEを使用する理由（個人使用か、それとも他の人に教えるためか）といったユーザーに関するコンテキスト情報も含まれています。
ここを開いてみます。まず、ユーザーが行った選択であるレスポンスインジケーターを入力し、選択セットIDとサブジェクトIDを設定します。次に、プロファイル効果を入力します。この設定では、ホバーヘルプの位置にある3つのメッセージです。必要であれば、インタラクション効果も追加できますが、今は主効果モデルのままにしておきます。また、経験レベルや、ユーザーが他の人に教えるか、Easy DOEを個人で使用しているかといったサブジェクト効果も追加できます。
ここに示されている多くの情報は、Choice Analysis Platform の設定とよく似ていることがわかります。「実行」をクリックすると、バックグラウンドでChoice Analysis Platform が起動し、スクリーニング研究のスクリーニングモデルが分析されます。もちろん、Choice Analysis Platform と同様に、このプラットフォームを操作することもできます。例えば、ユーティリティプロファイラーを起動して、例えば、他のユーザーに指導している経験豊富なユーザーが、遺伝情報メッセージに関して特定の選択肢（ここでは2番目の選択肢）を非常に好んでいることを確認できます。
これを確認すると、このコンポーネントが表示され、さらに調査する人口統計グループを選択できます。例えば、私がこれらの調査を実施していて、Easy DOEの熟練ユーザー、つまり実験計画法に経験のあるユーザーを調査したいとします。そして、彼らがどのような場合に他者を指導しているのかに関心があります。他者を指導する熟練ユーザーの好みを知るためのアンケートを作成したいのです。「設計を作成」をクリックすると、Choice Designプラットフォームが起動し、Choice AnalysisステージまたはScreening Studyステージで既に入力した情報が自動的にChoice Designプラットフォームに取り込まれます。
属性と、この特定のグループに対するモデル（指定した主効果モデル）があります。ここで最も重要なのは、スクリーニング研究のモデル、つまりスクリーニングモデルを用いることで、研究対象とした特定のグループの事前平均値と事前分散のベイズ事前分布を計算できたことです。
事前分布を作成したら、「設計を作成」をクリックして、いわゆるベイズD最適設計を作成できます。すると、調査対象の特定のグループに合わせて調整された設計が作成されます。この設計の構築には、このグループの嗜好に関する事前情報が考慮されています。これで、この設計は今後さらに調査したいグループに合わせて調整されています。これが、コンテキスト離散選択実験アドインのデモです。いくつか説明を終えて、元のスライドに戻ります。
最後に、JSLユニットテストフレームワークを使ったアドインのテストについてお話しします。ユニットテストとは、ソフトウェアアプリケーションの個々のコンポーネントをテストしてエラーを特定することです。特に、自動化されたユニットテストでは、ソフトウェアアプリケーションに対して頻繁にユニットテストを実行し、開発プロセスを通じて新たに発生したエラーを特定して修正することができます。
特に、JMPにはJSLアプリケーション向けにカスタマイズされたJSLユニットテストフレームワークが搭載されています。このフレームワークの中で最も重要な機能はut assert関数で、これを使用することでJSLアプリケーションの特定のコンポーネントをテストできます。ユーザーは、正しいと思われる出力（つまり、正しいはずの出力）を期待値として取得します。これをアプリケーションの実際の出力と比較テストします。結果が一致すればテストケースは成功し、一致しなければ失敗となります。ユーザーがこれらのut assert関数を含むスクリプトを作成して実行すると、すべてのテストケースが成功したか、失敗したかを示すレポートが返され、ユーザーはこれらのテストケースをさらに調査することができます。
コンテキスト離散選択実験アドインでは、かなり多くの項目をテストしました。例えば、インタラクション効果を追加するためのクロスボタンもテストしました。これは正しく機能しているでしょうか？特定の選択肢を2つ選んでクロスボタンを押すと、どのような結果になるかが分かっていたので、実際の出力結果と比較することで、システムが正しく動作していることを確認しました。
もう一つの重要なテスト項目は、さらなる調査のために人口統計学的グループを選択する際に、実験者がいずれかの選択肢を空白のままにした場合にエラーメッセージが表示されるようにすることです。テストを行い、このエラーメッセージが要求通りにポップアップ表示されることを確認しました。
最後に、これは重要な点です。選択肢デザイナーに読み込む事前情報が正しいことを確認したかったのです。そこで、選択肢分析プラットフォームの出力と比較テストを行いました。両者が一致すれば、選択肢デザイナーに事前情報を正しく読み込んでいると判断でき、不一致があれば何か問題があると判断できました。幸いなことに、正しい事前情報が正しく読み込まれていることが確認できました。
さて、この自動ユニットテストにおいて最も重要なことの一つは、コードをリファクタリングするタイミングです。自動ユニットテストでは、コードをリファクタリングし、エラーが発生していないかどうかを確認できます。ここで言うコードのリファクタリングとは、開発プロセスを通じてコードに変更を加えることを意味します。コードに変更を加えた場合、変更内容とは関係のない別の部分に問題が発生していないかどうかをどのようにして確認すればよいでしょうか？
ある例で、このアドインのテストユーザーの一人が、コンテキスト要素の1つに値ラベルが付いていると、そのコンテキスト要素のリストが正しく表示されないことに気づきました。実際には全く表示されませんでした。
戻ってそのエラーを修正しました。しかし、そのエラーを修正することで、他の何かに支障をきたしていないか確認したかったのです。それは可能でした。ユニットテストスクリプトを再実行することで確認しました。幸いなことに、ユニットテストスクリプトを実行した後、新たなエラーは発生していなかったため、他の何かに支障をきたしていないことが確認できました。この画像の右側に示すように、値ラベルの問題に対する修正案は正しく機能しました。
このユニットテストが重要なのは、1つ目に、コードにエラーがあるかどうかを確認できるからです。2つ目に、コードをリファクタリングして、他のエラーが発生していないことを確認できるからです。3つ目に、JMPのアップデートに伴い、JMP内部の特定の機能やプラットフォームが変更される可能性があります。このユニットテストスクリプトがあれば、JMPのアップデート時にアドインをいつでもテストし、JMP内部の変更がアドインに影響を与えていないか、あるいは影響を与えたかを確認できます。
本日の講演の締めくくりとして、Easy DOE のユーザーインターフェースの好みを、ユーザーベースの様々な人口統計グループにわたって学習するために、文脈的な離散選択実験を設計するという課題について紹介しました。次に、JSL スクリプトを使用して、これらの離散選択実験を作成するための非常に便利な JMP アドインを作成する方法を示しました。最後に、開発プロセス中および開発プロセス後にエラーを検出するために、ユニットテストを実行することの重要性について説明しました。
本日の講演はこれで終了です。ご質問はありますか？
