本日はご視聴いただきありがとうございました。JMPについてお話しますが、Amirysにおける分析ワークフローの自動化にJMPを活用している点に特化しています。また、より複雑なプロセスや、JMPネイティブプラットフォームを用いた自動化、あるいはデータ自動化の一般化についても触れていきます。本題に入る前に、簡単に自己紹介をさせてください。私はStefanです。Amirysのデータサイエンス担当アソシエイトディレクターを務めており、ライフサイエンス業界で15年間の経験があり、実に多様なバックグラウンドを持っています。化学ラボ、発酵ラボ、ハイスループットスクリーニングチームなど、様々な分野で働いてきました。品質管理、統計、データ分析、そして今はデータサイエンスに携わっています。データの保存方法から、人々がデータを利用し、アクセスする方法まで、データに関するあらゆることに興味があります。現在は、AMRAの科学コミュニティ全体に対し、独自のツールや分析手法を通じてサポートを提供しています。今日は、主に3つのパートについてお話しします。これから使用するケーススタディの背景とコンテキストを少し説明し、それに基づいて自動化の例をいくつか見ていきます。まずはシンプルなものから始めましょう。
JMPを使ってランオフ分析ワークフローを自動化するにはどうすればよいでしょうか？これは、日々行っている分析の効率化を図るものです。最後に、より高度な自動化、つまりより複雑なワークフローについて見ていきます。より広範な技術チームで使用されているこれらのワークフローをどのように分析するか、そしてそれをデータ処理と取り込み、そして分析部分の両方をサポートするためにどのように一般化するかを検討します。今日のケーススタディは、私が勤務するAmirys社の事例です。Amirys社について少し説明します。Amirys社は合成生物学の会社で、酵母のプログラミングと工業発酵を専門としており、酵母に糖を与え、その糖を純粋な原料や化学物質に変換しています。カリフォルニア州エメリービルに拠点を置き、製造の大部分をブラジルで行っています。今日のケーススタディは、製造側ではなく、研究側です。エメリービルには、スクリーンおよび分析ラボと呼ばれる高度に自動化されたラボがいくつかあり、そこでは 96 枚のウォールプレートで毎月数十万の菌株をふるいにかけます。
プレートのバーコードの写真がありますね。これはスケールダウン発酵槽として使用しているものです。これらの菌株がどれだけの量を生産しているのか、何を生産しているのかを確認するための最初のテスト場所です。私たちはこれらの菌株の特定の表現型を探しています。これらの96ウェルプレートで培養し、様々な分析手法を用いて測定値を生成します。多くの場合、これらのプレートウェルで多次元の測定値を生成します。また、社内に多くのデータベースがあり、多くのデータと関連メタデータがアプリケーションデータベースとデータウェアハウスに保存されており、JMPなどのツールでアクセスできます。ここでJMPが役立ちます。もちろん、このスクリーニングの最終段階では、多くの菌株をスクリーニングし、大量のデータを生成します。次に、そのデータを理解し、どの菌株をリアクター発酵装置の購入に、そして場合によってはブラジルでの製造に促進するかを決定する必要があります。
まずはJMPを使った簡単な自動化から始めましょう。今日は、JMPを使った自動化をまだやったことがない方、あるいはこれらのプラットフォームを使ったことがない方のために、分かりやすく、比較的コードレスで、これらのプラットフォームがどのように構築されているか、そして私がこれらの自動化プラットフォームを使う中で独学や他の人たちから学んだことなど、基本的な理解をお伝えしたいと思います。
何かを10回以上行うなら、自動化する価値があるとよく言います。自動化が初めての方は、まずは自分自身の分析から始めるのが最適だと思います。分析の良いところは、自分自身にフィードバックを与えられることです。もちろん、大規模なチームでより広範な分析を行うよりも、通常は簡単です。今回の例では、非常にシンプルな測定、つまりプレート上での1回の測定です。前培養から生産段階まで、プレートを連続的に増殖させています。2枚目のプレートで1回の測定を行います。この模擬実験では、「全く同じ種類の実験を何度も繰り返している」と仮定します。この実験を行うたびに、データをJMPに取り込み、計算列を追加します。そして、その列でフィルター処理を行い、意思決定を支援するための視覚的および統計的なテストを生成します。一度やる分には大した時間はかからないが、毎日何度も繰り返してやると、だんだん時間がかかってくる。
自動化の解説に入る前に、まず構造化データについて簡単に触れておきたいと思います。これは自動化の必須条件です。データの標準化と構造化が上流工程、つまりデータ収集とデータベース（あるいはCSVファイル）への取り込み段階で行われていれば、作業ははるかに楽になります。私たちの場合、データベースは既に構造化されています。もちろん、こうしたデータ処理の多くはJMPで実行できますが、多くの場合、アプリケーションや実行しようとしている分析に依存することになります。しかし、データのソースが何なのかを本当によく考えてみてください。上流工程で対処できるほど、より良い結果が得られます。データベースデータを使用する場合は、クエリビルダーの使用をお勧めします。今日はそこまで詳しく説明しません。これが私の一般的な推奨事項です。JMPのスクリプトの根幹、そして真の基盤となるのはログです。ご存知の通り、JMP はデフォルトで、UI 上のクリック操作で実行されている操作、つまり JSL やスクリプトの実行内容を常に記録しています。「表示」メニューの「ログ」をクリックしてログを表示すると、実行した操作のほとんどがそこに記録されています。
いずれかのステップをクリックすると、そのステップの実行に使用されたJSLが表示されます。この例では、計算列を追加する最初のステップを実行しており、それをクリックしてJSLをハイライト表示しています。これは、ステップで実行されているJSLを素早く確認するための最初の方法であり、ログからそのコードを直接実行したり、以前のコードを再実行したりできます。ただし、ログは真の自動化を行うためのツールとしてはお勧めしません。ログは、コードの発生源に関する情報が多数含まれているだけです。ログからデータを抽出して、例えばデータテーブルに取り込む方法の一つは、データテーブルスクリプトを使用することです。これは長年、JMPでステップごとの自動化を行うための方法でした。この例では、このデータ テーブルに移動し、小さな赤いホットスポットをクリックして、新しいスクリプトを生成しました。空のウィンドウが表示されるので、ログから 2 つのコード ステップを直接貼り付けます。1 つは新しい列を作成するステップ、もう 1 つはその列の数式を設定するステップです。
さらにコードを整理することもできます。これは完全にオプションです。しかし、後のセクションでより複雑な例について説明する際に、どうすればコードを最も保守しやすく、最もクリーンにできるかを考えてみるのも良いでしょう。今回のケースでは、2段階のクリーンアップを行いました。最初のステップでは、冗長なデータテーブル参照を削除しました。2番目のステップでは、列名（列21）を変更せずに、その後変更することで、さらにコードを圧縮しました。最初から適切な名前を付けているだけです。これらのボックスはそれぞれ正常に機能し、全く同じことを行います。今回のケースでは、パフォーマンスの違いは感じられないかもしれませんが、よりクリーンで保守性の高いコードにつながります。JSLを初めて使う方がこのコードを見ると、「一体何をしているんだ？」と思うかもしれません。これらのコードを、お気に入りのLLMに貼り付けることができます。私たちはCopilot、ChatGPTなどを使っています。 JMP 学習ボットにアクセスできる場合は、「このコードは何をしているのですか?」と説明を求めると、通常、そこで何が行われているのかがよくわかります。
ログからデータ、あるいはデータではなくコードを抽出し、データテーブルスクリプトに貼り付けました。これはJSLを自動生成する最も手動的な方法です。ここで確認できます。ステップ1で「計算列の追加」と名付けました。ほとんどのプラットフォームでは、テーブルスクリプトを生成し、特定の出力を生成したスクリプトを保存する簡単な方法がいくつかあります。多くのプラットフォームでは、赤いホットスポットの下にこれらのオプションがあります。赤いホットスポットの下まで見てください。「スクリプトの保存」オプションがあり、いくつかのオプションがあります。クリップボードに保存したり、データテーブルに直接保存したりすることもできます。これは私たちがこれから行う方法ですが、他にもオプションがあります。これは、UIから直接JSLを自動生成する非常に簡単な方法になります。データテーブルに保存しました。この場合、スクリプトの名前を変更しただけです。ステップ2でデータフィルターを追加し、分析を続行しました。ここで、最後のステップである Y by X プロットの生成でこれを実行できます。また、参照グループを使用した Dunnett 検定も適用します。
もう一度、赤いホットスポットに移動し、「スクリプトを保存」を選択してデータテーブルに保存します。作成したのは擬似ワークフローです。3ステップの自動化です。このテーブルに計算列を追加し、データフィルターを追加するか適用し、ダネット検定を用いた一元配置分析を実行します。これはテーブルスクリプトの使用領域に繋がり、JMP 16か17の頃、ワークフローが登場するまで長い間使用されていました。ワークフローによって、これらのテーブルスクリプトに追加機能を追加することでレベルアップできるようになりました。ワークフローは新しいプラットフォームです。JMPのスタンドアロンプラットフォームです。「ファイル」→「新規」→「ワークフロー」からアクセスできます。ワークフローには、ワークフローの開発を容易にするだけでなく、エンドユーザーのワークフロー使用体験を向上させる機能が多数あります。例えば、ボタンをクリックするだけで、ワークフローのすべてのステップを実行できます。ステップ記録機能があり、JMPでの操作を記録してワークフローに自動的に追加します。ワークフロー内でスクリプトに直接注釈を付けたり、ロジックゲート、インタラクティブ機能、ユーザープロンプトなどを追加したりすることも可能ですが、今日はそれら全てを説明する時間がありません。
いくつか例を挙げてみます。特に高度なバージョンです。これらのテーブルスクリプトを使って擬似ワークフローを作成できます。これはワークフローが存在する前に作成したもので、JMPがワークフロープラットフォームを追加し、それをワークフロービルダーに追加したものと考えられます。ここで行ったのは、3つのステップを追加しただけです。各ステップのJSLを貼り付けてみました。データテーブルスクリプトと同じ3つのステップがワークフローに含まれていることがわかります。実際のデータ、つまりデモデータでどのように見えるか、簡単なデモをお見せします。最初の例では、構造化データがあります。測定値がいくつかあり、それらの測定値があります。ここでもう一度やりたいのは、これらの3つのステップを実行することです。このデータテーブルスクリプトのアプローチでは、1つずつクリックするだけです。これをクリックします。計算列が追加されました。データフィルターを適用すると、ポップアップが表示され、フィルターが適用されます。そして、この特定の実験に対する一元配置分析が生成されます。
本当にシンプルですよね？これでうまくいきます。このようなシンプルな処理には最適です。ワークフローに移行する必要がありますか？もっと複雑な処理が必要ですか？必ずしもそうではありません。もしこれがうまくいけば素晴らしいです。これをリセットすることもできますが、ここでは手動で行う必要があります。行の状態をクリアし、データフィルターが閉じていることを確認し、ワークフローを確認します。これも3つのステップです。ここでより便利なのは、コードが自動的に表示されることです。ここではそれができません。ここでは、右クリックして「編集」に移動し、新しいウィンドウで定義を確認する必要がありました。一方、この別のオプションでは、各ステップのコードが表示されています。ここで実行ボタンを押すと、3つのステップがすべてまとめて実行されます。エラーなく実行されたことを示す小さな緑のチェックマークが表示されました。新しい列が作成されました。フィルターを適用すると、同じ分析が開きます。少しすっきりしました。次のセクションでは、ワークフローを使用することで得られるその他の機能について、もう少し詳しく説明します。
デモで少しだけ触れておきたいのは、記録ボタンです。これは非常に便利です。特にJSLに慣れていない方、あるいはコーディングに全く精通していない方でも、独自の自動化を始める最も簡単な方法です。ここでできることは、記録ボタンを押すだけです。これで、このプラットフォームで行ったすべての操作がワークフローに記録されます。ダミーの例を見てみましょう。測定値の分布を描画し、ここに何らかの分布を生成します。これは何か意味のあることを意味していると仮定します。ワークフローに戻ると、ここに新しいステップが追加されていることがわかります。ここにJSLスクリプトがあります。名前を変更したり、メモを追加したり、修正したりできます。ワークフロービルダーの非常に便利な機能が、この記録ボタンです。もう少しレベルを上げてみましょう。ソファなどの特定の用途向けに自動化したことがあるかもしれません。ある実験タイプでうまく機能しているかもしれません。それをより複雑なプロセスに適用するにはどうすればよいでしょうか？それが私たちの疑問でした。
Amirysでは、実情として様々な実験タイプがあり、理想的にはそれらを可能な限り少ないワークフローでサポートしたいと考えています。あらゆる反復ごとに独自のワークフローを作成することは避けたいと考えています。そうすると、維持が不可能になり、開発が非常に困難になるからです。より高度な開発に取り組む際には、JMPコミュニティのどこかの動画で見つけたのですが、JMPプロジェクトを使用して、いわゆる開発環境を整理することをお勧めします。こうした複雑な作業を自動化しようとすると、データテーブルやウィンドウなどが次々と表示され、管理が困難になることがあります。プロジェクトを使用すれば、開発環境のラッパーとして使用できます。また、最終的にはJMPプロジェクトをツールとして利用できるようになります。
ここでは、ワークスペースやコンテンツなど、デフォルトのプロジェクトプラットフォームがいくつか開いています。プレースホルダーとしてジャーナルを追加しました。ワークフローで開かれるすべてのもの、つまり新しいウィンドウは、デスクトップ上の新しいウィンドウではなく、新しいタブとして開きます。もちろん、このジャーナルはドキュメントや手順の説明にも使用できます。右側には、実際に構築したワークフローが表示されています。下部には、ログも追加しました。
トラブルシューティングやエラーメッセージの詳細確認が必要な場合、ログがすぐに表示されるので、単一のウィンドウから直接操作できます。このワークフローのデモも、このプロジェクト内で行っています。ユーザーからいただいたフィードバックは、表やビジュアルが乱雑にならない点が非常に好評です。自動化の一般化について話すとき、私たちは影響力の大きいアプリケーションをターゲットにしたいと考えています。なぜなら、データ自動化であれ、物理的な自動化であれ、ラボや製造現場で自動化を実施したことがあるかどうかに関わらず、自動化の一般化は決して容易な作業ではないからです。多くの労力、費用、労力、そして時間がかかります。一般的に、データワークフローの自動化を検討する場合は、ワークフローの標準化にそれらを適用すること、または標準化を推進する手段としてそれらを使用することを優先してください。「ほら、これを標準化すれば、毎日行っているこの非常に面倒なデータ処理も自動化できますよ」と伝えましょう。
データワークフローには、プロセスそのもののためであれ、人々がデータをどのように見ているかのためであれ、柔軟性が求められることがよくあります。そこで、段階的に自動化を進めることができます。これがJMPの真に強力な点です。自動化するなら、なぜPythonを使わないのか、純粋にコードベースのプラットフォームを使って自動化しないのかと聞かれることがあるからです。問題は、何かを純粋にコードベースにしてしまうと、すぐにユーザーにとって大きな参入障壁ができてしまうことです。エンドツーエンドで自動化できなければ、ある程度の段階まで来てユーザーが操作を引き継ぐ必要が生じ、さらに「Pythonを使いこなせるようにしてほしい」と要求されるような状況では、私が共に仕事をしている科学者のような非常に技術的なコミュニティであっても、大きな参入障壁となってしまいます。
JMPは本当に素晴らしいです。最初の部分だけを自動化すれば、あとはエンドユーザーがJMPを操作できるのです。UIがあるので、それを自由に操作できます。好きなように操作でき、自由度が高く、自動化を活用できます。もちろん、労力がかかるので、大きな効果が得られる機会を特定したいと考えています。私たちのケースでは、プレート実験を見て、科学者たちに「このデータを取得するのにどれくらいの時間をかけていますか？」と尋ねました。すると、人々がコピー＆ペーストなどの反復的な手順を非常に手作業で行っていることに気づきました。
チームには17人の科学者がいました。ちょっとした調査を行った結果、これらすべてを行うのに、一人分の、かなり高価な人数分の時間をかけていると推定しました。これは私たちにとって、「これは手作業で繰り返し行われていて、自動化できそうに見える」と言い出す機会となりました。さあ、やってみましょう。間違いなく直面する最大の課題は複雑さです。自動化を考える際、2つの軸があります。1つはワークフロー全体のステップ数、もう1つは各ステップにおけるバリエーションの数です。バリエーションとは、まさに道の分岐点です。右の図が気に入っています。なぜなら、特定のプロセスにおいて、あまりにも多くの反復やバリエーションを解決しようとすると、あっという間に指数関数的な問題になってしまう可能性があるからです。まず、自分自身に問いかけましょう。「これは管理可能か？」そして、もし管理不可能なら、どうすれば管理可能になるか？前述のように、標準化によって変動を排除するか、「このコーナーケースはこのデータ分析ではサポートされません」と言うことができます。
ワークフローに表示されるエラーメッセージを追加することもできます。また、自動化のオフランプを使用してステップを削減することもできます。これは先ほども述べたように、ユーザーに作業を任せることです。非常に職人技を要する独自の品質管理ステップがある場合は、ワークフローを一時停止し、ユーザーに必要な作業を行わせてから、そこからワークフローを再開することができます。検討すべきオプションはいくつかありますが、自動化を検討する際には、綿密な計画が不可欠です。今回のケースでは、プレートプロセスを検討していました。これは私が最初に示した例です。単一のプレート伝播があり、単一の測定を行います。このプロセスを「伝播プロセス」と呼びます。
実験ごとにどのように異なるのかを調べ始めたとき、「実は、このプレートから1回だけでなく、2回測定することもあるんだ」と気づきました。実際には、連続伝播の最初のプレートからも測定している場合もあります。両方で2回測定する場合もあります。プレートを分割する場合もあります。1対1だけでなく、1対2、あるいは1対多の測定をすることもあります。
これらを測定しています。時には分割して、それぞれ異なる測定を行うこともあります。皆さんにこれを正確に把握していただく必要はありませんが、ここで示したいのは、私たちのプロセスには多くのばらつきがあるということです。ここではいくつか例を挙げているだけです。私たちのプロセスには数十種類のバリエーションがあります。ここでは、データを生成するラボのプロセス自体の複雑さについて検討しました。人々がデータを見て分析する方法がどれほど標準化されているのか、どのような統計検定を使用しているのか、要約指標を使用しているのか、中央値や平均値を使用しているのかなど、まだ考えていません。
複雑さはすぐに手に負えなくなる可能性がありますが、事前に十分な調査を行うことが重要です。私たちが取り組んでいるのは、現在進行中の作業です。すでにデプロイされていますが、継続的に改善を続けています。もう一つお勧めしたいのは、最低限何が役立つのかを把握し、エンドユーザーから頻繁にフィードバックを得ることです。私たちは、飛行機の分析のために、この一般的なアプローチを考案しました。
より複雑なワークフローは以下のようになります。ここでは、データベースからのデータを調整し、ユーザーが探している特定の実験に基づいてデータをフィルタリングするよう直接促しています。大量のデータ処理、データ型の修正、命名規則の調整など、一貫性の確保を行っています。このプロセスに基づいてデータを分割しています。シリアル伝播を確認しました。どの測定がどのプレートに関連付けられているかを理解する必要があります。いくつかチェックを行い、これが私たちがサポートしていないプロセスではないか、この自動化でサポートされていない測定ではないか、といった点を探ります。エラーをスローしてユーザーにメッセージを表示します。ピボットを中心にさらにデータ処理を行います。オフラインデータを追加するオプションもユーザーに提供します。ユーザーは自分の遺伝子型に手動で注釈を付けている可能性があります。最後に、デフォルトの視覚化と分析のセットを生成します。
これをもう少し詳しく説明すると、どのように見えるかお見せします。先ほどお見せしたように、プロジェクト内にあります。ワークスペースの内容、ジャーナル、そしてログがあります。ログはデモでは必要ないので閉じておきます。画面上で貴重なスペースを占領しているからです。
ここにワークフローがあります。各ステップをできるだけ人間が読めるように記述したので、各ステップの機能が理解できます。また、今回の会議では、ステップを有効化または無効化できます。社内データベースに接続して実際の実験データを取得する予定はないため、静的データのみをインポートしています。ここには生のデータがネイティブに用意されています。また、ここには論理ゲートがいくつかあることにお気づきでしょうか？if/out文を使って論理スイッチや異なるパス、異なる分岐を設定することで、「データがこの状態ならこうする。そうでなければこうする」といった処理を実行できます。
さあ、実行してみましょう。データをインポートしています。少し受動的で攻撃的な言い方かもしれませんが、ちょっとした…ユーザーフィードバックのために小さなポップアップを表示できます。「素晴らしい。PCプレートの測定値はBメジャーのみですよね？それが唯一許可されている値です」と私は言いました。よくできました。ユーザーは「OK」をクリックしました。処理は続行されます。今度はプロンプトを表示します。「手動で作成されたメタデータを結合しますか？」と尋ねています。
これは、このデータセットに共通する遺伝子型データです。最初の実行では、ただ「いいえ」をクリックします。実際には、ここにはデータがありません。「よし、とりあえず実行してみよう」という感じです。これで、すべてのデータが生成され、実行が完了しました。すべて緑色のチェックマークが付いています。左側には、いくつかのデータテーブルと、パフォーマンスのデフォルトの視覚化、そして株選択のためにプレート上で行っている正規化が表示されています。
ここでもワークフローの本当に素晴らしい点は、このボタン、つまり「リセット」をクリックすると、ワークフローが開いたすべての内容が閉じられ、最初にリセットされることです。これでリセットが完了しました。ジャーナルと最初の小さな矢印に戻っているのがお分かりでしょう。これをもう一度実行してみましょう。同じプロンプトで「はい」と答えます。すると、少し異なるパスに進みます。「はい、手動データを追加します」と答えます。すると、データの結合に使用する列を尋ねる別のプロンプトが表示されます。このX番号、つまり一意の識別子を使用します。
4つの株を使用します。「OK」をクリックします。すると、「このデータはあなたのデータセットには見当たりません」というメッセージが表示されます。もちろん、これは私のオフラインデータなので、表示されません。自分のコンピューターでそのデータがある場所を探します。今回はCSVファイルに保存してあるので、それを結合してスクリプトを実行します。この時点で、実際には同じ結果になります。正規化が行われています。グラフビルダーで測定結果をボックスプロットで視覚化しています。さらに、プロモーター変異などの列も追加しました。これらの列は、オフラインデータに含まれていた情報で、メインデータに結合しています。これらの情報は、他の方法では追加されていません。
これらの汎用化されたワークフローは非常に強力になります。公開する際には、これもプロジェクトに保存します。これはプロジェクト内のワークフローです。ここにユーザードキュメントと、関連する可能性のある他の社内ドキュメントへのハイパーリンクを追加します。ユーザーがここにアクセスし、再生ボタンを押してプロンプトを表示し、実験IDを入力します。これにより、取り込まれるデータが動的に変更され、このプロセスが実行されます。
ここでエラーをスローするといった項目もいくつかあることにお気づきでしょう。これは、サポートされていない特定のケース、あるいは想定外の実験タイプの場合に使用します。一般化する場合、もう一つヒントがあります。一般化しようとする場合、多くのテーブルと列の参照はデフォルトで自動生成されます。記録ボタンを使用する場合でも、プラットフォームの赤いドロップダウンを使用する場合でも、これらは通常明示的に指定されます。データテーブルの名前、列の名前などが表示されます。一般化しても、必ずしもスケールするとは限りません。
JSLを手動で修正する必要があると気付くことの一つは、列とデータテーブルの参照、それらの管理方法、そしてそれらを動的にする方法です。インポートする列の数は、ユーザーが取り込む内容によって変化する可能性があるため、それに対応する必要があります。この領域に入ると、ほぼ確実にJSLを記述し、JSLのコードを作成する必要があります。しかし、繰り返しになりますが、JMPはワークフローの記録、ログ、そして赤いホットスポットやスクリプトの保存オプションなど、作業の90%を自動で行ってくれます。
JSLを書かなければならなくなったら、どうすればいいでしょうか？私はこれまで様々なデータツール、データソフトウェア、コーディング言語を使ってきました。JMPの学習リソースは本当に素晴らしいです。アプリケーション自体にスクリプトインデックスが最初から備わっています。最近では、JSLのトラブルシューティングや生成にLLMアシスタンスを利用できます。Pythonのような言語ほど優れているとは思いません。トレーニングデータセットがPythonよりもはるかに小さいからですが、それでも十分に役立ちます。
JMPコミュニティこそが、まさに比類のない存在です。フォーラムを活用してください。今年初めの具体的な例を挙げましょう。私はこの質問を書いたのですが、まさに「時間」と呼べるでしょう。午後7時15分に投稿しました。伝説のジムは、同日午後9時45分に返信してくれました。翌朝、マークは約12時間後に返信してくれました。24時間以内に、専門家から2件の回答をいただきました。これは私がフォーラムに投稿するたびに経験していることです。
皆さん、特にマークとジムに感謝します。皆さんの名前はいつも目にしますが、フォーラムでは皆が使っています。皆さんの学習にとって、皆さんの貴重な情報です。それでは最後に、組織内、チーム内、ラボ内など、どんな仕事であっても、汎用的な自動化を適用できる大きなインパクトのある機会を探してみてください。私たちのケースでは、1ヶ月間で50件以上の実験を実行し、1回の実験につき何時間も費やしていた領域がありました。これは、1人の担当者が実際にそのデータ処理に費やした時間すべてでした。
一旦その点に取り組み、複雑さを管理・計画すると、実験設計とプレートスクリーニングプロセスには大きなばらつきが生じてしまいます。そこで、ユーザーオプションを用意し、サポートするレポートを限定すると同時に、JMP UIを活用して「ここからはあなた次第です」と伝えることで、この課題に対処しました。JMP UIは、ユーザーが望む方法で視覚化できます。これにより、高度なワークフローを実装することができ、反復的な作業を削減できるだけでなく、分析を標準化する手段としても活用できます。私がよく目にするのは、物事を標準化したいと思っても、データ分析となると、職人技のように捉えてしまうというケースです。
確かにその通りですが、ベストプラクティスを確立できる要素もあります。このデータをどのように分析すべきでしょうか？このデータの特性に適した統計検定は何でしょうか？こうした点をJMPワークフローのようなものに体系化できる機会が生まれます。
