756669_ja-JP

liliconcom

データキュレーションワークフローの自動化（2021-EU-45MP-737）

ジョーダン・ヒラー、SAS JMP シニア システム エンジニア
ミア・スティーブンス、SAS JMP 主席製品マネージャー

データ分析タスクの多くは、データのインポートと分析準備に多くの時間を費やします。私たちは定期的に更新されるデータセットを扱うことが多いため、スクリプト化された繰り返し可能なワークフローを使用して作業を自動化することで、大幅な時間節約を実現できます。自動化スクリプトは、データのインポート、データのキュレーション、分析/レポート作成という3つの主要なセクションに分かれています。最初のセクションと3番目のセクションのタスクは、ポイントアンドクリックで目的の結果を達成し、結果のスクリプトをキャプチャするなど、比較的簡単ですが、データキュレーションはスクリプト作成を始めたばかりの人にとっては難しい場合があります。この講演では、一般的なデータ準備作業を概説し、プロセスの自動化に必要なJSLコードについて説明し、JMP 16の新機能であるアクション記録と強化されたログを使用してデータキュレーションスクリプトを作成する方法を紹介します。

自動生成されたトランスクリプト...

スピーカー	トランスクリプト
ミア・スティーブンス	JMP Discovery Summitへようこそ。JMPプロダクトマネージャーのミア・スティーブンスです。システムエンジニアのジョーダン・ヒラーも参加しています。本日は、データキュレーションワークフローの自動化についてお話します。
	これはあくまでも参考のための要約であり、これについて話すつもりはありません。
	この講演は2つのパートに分かれています。まず分析ワークフローについてお話しします。
	データの作成、そしてデータキュレーションとは何かについてお話しします。そして、データに潜む潜在的なデータ品質の問題を特定する方法についても見ていきます。
	次にジョーダンにバトンタッチします。ジョーダンは再現性の必要性についてお話しします。
	彼はデータキュレーションのチートシートを共有し、JMP でデータをキュレーションする方法を紹介します。
	アクションレコーダーと拡張ログ。
	それでは、分析ワークフローについてお話ししましょう。
	すべては、私たちが解決しようとしているビジネス上の問題から始まります。
	もちろん、データをコンパイルする必要がありますが、さまざまなソースからデータを収集し、そのデータを JMP に取り込むことができます。
	そして最後に、結果を共有し、発見したことを他の人と伝えられるようにする必要があります。これは単発のプロジェクトである場合もありますが、
	しかし、多くの場合、分析は繰り返し行うことになります。そこで、この講演で取り上げる中心的な問いは、「結果を簡単に再現できるか？」ということです。
	他の人はあなたの結果を再現できますか？あるいは、新しいデータや更新されたデータがある場合、分析、特にそれらの新しいデータに対するデータキュレーションの手順を簡単に繰り返すことができますか？これが、今回の講演で取り上げたいことです。
	しかし、データキュレーションとは一体何でしょうか?
	そして、なぜ私たちはそれを心配する必要があるのでしょうか?
	データキュレーションとは、分析による発見を促進する上でデータが有用であることを保証することです。根本的には、解決しようとしている問題を解決できなければなりません。
	それは主にデータの編成、データ構造、そしてデータのクリーンアップに関するものです。
	データに関して遭遇する可能性のある問題について考えてみると、それらは4つの一般的なカテゴリーに分けられる傾向がある。
	フォーマットが間違っている、データが不完全、データが欠落している、データが汚い、乱雑であるなどの可能性があります。
	これらの問題について議論するために、STIPSのコンテンツをいくつかお借りします。STIPSをご存知ない方のために説明すると、STIPSとは「産業問題解決のための統計的思考」という無料コースです。
	これは 7 つの独立したモジュールに基づいたコースで、 2 番目のモジュールは探索的データ分析です。
	探索的データ分析とデータキュレーションは反復的かつインタラクティブな性質を持っているため、このモジュールのこのモデルの最後のレッスンは「分析のためのデータ準備」と呼ばれ、この講演全体を通じてこのレッスンの内容を多く借用しています。
	これらの問題を一つずつ詳しく見ていきましょう。不適切なフォーマット。不適切なフォーマットとはどういう意味でしょうか？これは、データが分析に適した形式、あるいはフォーマットで保存されていない場合を指します。これはデータテーブル全体に当てはまります。例えば、以下のようなケースが考えられます。
	データは別々の列に格納されますが、実際には 1 つの列に格納されたデータが必要です。
	または、データが別々のデータ テーブルに保存されており、それらのデータ テーブルを連結、更新、または結合する必要がある場合もあります。
	これは個々の変数に関係する可能性があります。例えば、モデリングの種類が間違っている可能性があります。あるいは、データテーブルに日付が含まれている場合、日付の列が日としてフォーマットされていない可能性があります。そのため、分析ではこれらが日付データであると認識されない可能性があります。
	書式設定は見た目にも影響します。例えば、大きなデータテーブルを扱う場合、列数が多くなることがあります…
	名前、つまりあまり認識されない列名があり、それを変更したい場合があります。
	管理しやすくするために、グループ化したい列がたくさんある場合があります。
	回答列がデータテーブルの一番最後にある場合、上に移動したいと思うかもしれません。見た目の問題が必ずしも分析の妨げになるわけではありませんが、これらの問題のいくつかに対処できれば、分析が少し楽になります。
	不完全データとは、データが不足している状態を指します。重要な変数に関するデータが不足している場合もあります。例えば、問題解決に不可欠な変数に関するデータが不足している可能性があります。また、複数の変数の組み合わせに関するデータが不足している場合もあります。
	したがって、たとえば、相互作用を推定するのに十分な情報がない可能性があります。
	あるいは、興味のある目標変数が不均衡な場合、欠陥のような何かを調べることになるかもしれません。それは観測値の5%だけかもしれません。
	欠陥に関するデータがあり、十分なデータがない可能性があります。データのごく一部しか持っていない可能性があります。
	欠陥が存在する場所。欠陥の潜在的な原因を理解するのに十分なデータが揃っていない可能性があります。また、サンプルサイズが十分でないため、適切な推定値を得るのに十分なデータがない可能性もあります。
	欠損データとは、変数の値が欠損している状態であり、これにはいくつかの異なる形式があります。
	データが欠落していて、そのデータがランダムでない場合、深刻な問題が発生する可能性があり、推定値が偏っている可能性があります。
	完全にランダムにデータが欠落している場合、数個の観測値が欠落しているだけであれば問題にはならないかもしれませんが、大量のデータが欠落している場合は問題になる可能性があります。
	汚れた乱雑なデータとは、観測値や変数に問題があるデータのことです。つまり、値が間違っている場合もあれば、単に値が間違っている場合もあります。
	一貫性がない可能性があります。例えば、人によって入力方法が異なっている場合、タイプミスや誤植が発生する可能性があります。
	値が不正確である可能性があります。例えば、測定システムに問題がある可能性があります。エラーやタイプミス、データが古くなっている可能性があります。
	廃止されたデータとは、たとえば、もう使用されていない施設や機械に関するデータがある場合のことです。
	データは古くなっている可能性があり、2～3年前のデータがあるかもしれませんが、その期間のどこかでプロセスが変更されている可能性があります。
	つまり、これらの過去のデータは、現在のプロセスとは関連性がない可能性があります。データが検閲されたり、切り捨てられたりする可能性もあります。
	本質的に同じ情報を含む列、つまり冗長な列が存在する場合があります。あるいは、観測結果が重複している場合もあります。
	したがって、汚れたデータや乱雑なデータはさまざまな形をとる可能性があります。
	では、潜在的な問題をどのように特定するのでしょうか?
	良い出発点は、データを探索することです。実際、問題を特定すると、データの探索、そして分析へと進みます。そして、データを探索し始めると、分析において問題を引き起こす可能性のあるものを特定し始めます。
	したがって、データ テーブルをスキャンして明らかな問題を探すのがよい出発点となります。
	これからこの講演ではコンポーネントと呼ばれる例を使用します。これはSTIPSコースの例です。
	ある企業が小型部品を製造しており、歩留まりに問題を抱えています。そこで、369バッチ分のデータを収集しました。15の特性が捉えられており、これらのデータを活用して、歩留まり低下の潜在的な根本原因を解明したいと考えています。
	データテーブル自体を見てみると、どのようなデータ品質の問題があるかの手がかりがいくつか見つかります。これは非常に良い出発点です（これはJMP 15で追加されました）。
	ヘッダーグラフです。私はヘッダーグラフが大好きです。連続変数の場合、ヒストグラムを表示することで、分布の中心、形状、広がりを確認できます。
	値の範囲も表示されます。カテゴリデータの場合は、最も人口の多い棒グラフが表示されます。それではいくつか見てみましょう。まずはバッチ番号から見てみましょう。バッチ番号はヒストグラムで表示されており、形状は均一です。
	バッチ番号はおそらく識別子なので、すぐにこれらのデータがおそらく間違ってコード化されていることがわかります。
	この分布は非常に偏っていることがわかり、また最低値は -6 であることもわかります。これにより、スクラップ数がマイナスになる可能性について疑問が生じます。
	プロセスもその一つです。基本的に2本のバーがありますが、実際には2つの値だけを持つヒストグラムが表示されています。
	これらの列グラフ、ヘッダーグラフを見ると、列パネルを見ると、
	例えば、バッチ番号、部品番号、工程はすべて連続型としてコード化されていることが一目瞭然です。JMPにデータをインポートすると、JMPが数値を認識すると、これらの列は自動的に数値連続型としてコード化されます。そのため、これらの項目は変更が必要になる可能性があります。
	データ自体を見ることもできます。例えば湿度を見ると（データを見る際には文脈が非常に重要です）、湿度は連続データとして考えられます。
	しかし、ここには N/A となっているフィールドがいくつかあります。
	英数字データ、または数値列にテキストデータがある場合、JMPにデータを読み込むと、その列は名義尺度としてコード化されます。つまり、これはすぐに修正する必要があることがわかります。
	他の列も見ることができます。例えば、「仕入先」の列には、いくつかの値が欠けていることがわかります。JMPにデータを取り込むと、
	カテゴリデータのセルが空の場合、値が欠損していることがわかります。データの入力方法に一貫性がないエントリがいくつかあることがわかります。
	つまり、データに潜在する問題に関する重大な手がかりが得られつつあるということです。
	点がたくさんあるのに注意してください。温度は連続変数なので、点がある部分は値が欠落していることを示しています。つまり、温度は私の分析にとって非常に重要なので、これは問題になるかもしれません。
	これを自然に発展させると、変数を一つずつ調べてデータを探索し始めることができます。データを最初に見始めるときに私がよく使うツールの一つが列ビューアです。列ビューアでは、選択した変数の数値サマリーが表示されます。
	欠損値がある場合は、「N Missing」列が表示されます。ここで、温度の369個の値のうち265個が欠損していることがわかります。つまり、温度が分析において重要だと考える場合、これは深刻なギャップです。
	何かおかしな値が出ていないか確認することもできます。例えば、廃棄数や廃棄率の最小値と最大値を見ると、マイナスの値が出ています。もしこれが実現不可能であれば、データかデータ収集システムに問題があることになります。
	変数のコードミスも簡単に見つかります。例えば、施設番号とバッチ番号は、本来は名目値としてコードされるべきなのに、平均値と標準偏差として報告されています。
	これについて考える良い方法は、平均バッチ番号または（部品番号が他の変数である場合）部品番号を持つことが物理的に不可能である場合、これらを連続変数ではなく名目変数に変更する必要があるということです。
	最初にデータに慣れるときに次に参照するのは「Distributions」です。
	分布を使用すると、連続データがある場合、データの形状、中心、広がりを把握できるだけでなく、異常な値があるかどうかも確認できます。
	カテゴリデータの場合は、階層数も確認できます。例えば顧客番号の場合、顧客番号が重要な変数、あるいは潜在的に重要な変数であれば、
	顧客番号には多くのレベルや値があります。データを準備する際に、データがあまり多くない顧客については、別のカテゴリと合わせて4つか5つのバケットにまとめる必要があるかもしれません。
	湿度。列に「N/A」と表示されているのが問題です。ヒストグラムではなく棒グラフが表示されています。
	サプライヤーのデータを見れば、何を見ていたのか簡単に分かります。例えば、「Cox Inc」と「Cox, Anderson」は3通りの綴りがあり、「Hersh」も3通りの綴りがあります。
	速度については、60から140あたりまで山のような分布がありますが、一番下には1つか2つの値があります。
	それはほぼゼロに近いので、これはおそらく...データ入力エラーだったのかもしれませんが、間違いなく調査したいものです。
	これを拡張して、データを一度に2つの変数で見てみるのも良いでしょう。例えば、グラフビルダーや散布図などを使うのがよいでしょう。
	変数を 2 つずつ見ると、パターンが見えてきて、複数の変数にまたがる異常なパターンも簡単に見つけられるようになります。
	例えば、スクラップ率とスクラップ数を見ると、いくつかのバンドがあることがわかります。データテーブルの中に、このパターンを説明できる何かがあるかもしれません。
	この場合、バンドは異なるバッチ サイズに起因しており、この紫色のバンドはバッチ サイズが 5,000 の場所です。
	バッチサイズが大きい方が、小さい場合よりもスクラップが発生する可能性がはるかに高くなります。これはある程度理にかなっているかもしれませんが、一方で、腑に落ちない点もあります。ここの2つの値はマイナスの範囲にあります。
	したがって、データを 2 次元で見ると、これらを確認するのは非常に簡単です。
	列スイッチャーとデータ フィルターを使用して、グラフに追加の次元を追加できます。
	これは潜在的な分析にもつながりますので、重要な可能性があり、スクラップ率に関連する可能性のある x が何であるかを理解することに興味があるかもしれません。
	同時に、データ品質の問題や潜在的な問題にも目を向けてください。スクラップ率に関しては、圧力とスクラップ率の間には正の相関関係があるように見えます。
	あまり関係がないように見えます。スクラップ率と温度の関係はほぼ一定なので、あまり変化がないようです。
	しかし、速度に注目してください。負の相関関係がありますが、上部に2つの値があります。1つはヒストグラムで見た値ですが、もう1つは目立つ値があります。
	つまり、60付近のこの値は単なる外れ値かもしれませんが、妥当な値である可能性はあります。0付近のこの値が妥当かどうかは疑問です。
	ここまでデータテーブルを見てきました。変数ごとにデータを見てきました。変数ごとにデータを見てきました。そして、変数ごとにデータを見てきました。これらすべてがデータ探索に役立ち、分析へとつながります。
	このコースやこの講演の範囲外ですが、さらに高度なツール (外れ値の探索、欠損値の探索など) を使用することもできます。
	データの分析を始めると、新たな問題が見つかる可能性があります。例えば、カテゴリ変数のカテゴリが多数ある場合、
	回帰モデルに交互作用を当てはめようとすると、JMPは実際にはそれができないという警告を表示します。つまり、データの分析を始めると、このプロセス全体が反復的になり、プロセス全体を通して潜在的な問題が特定されることになります。
	重要なのは、データを見ているときに遭遇した問題をメモしておくことです。これらの問題のいくつかは、
	作業を進めながら修正していくので、値を非表示にしたり除外したり、データの形状を変更したり、データを再整理したりすることができます。しかし、新しいデータを収集する必要があると判断する場合もあります。データ自体の信頼性を高めるために、DOE（実験計画法）を実施するのも良いでしょう。
	この分析を繰り返す予定、または他の誰かがこの分析を繰り返す予定であることが分かっている場合は、
	再現性を確保するために、自分が行っている手順を記録しておく必要があります。他の人が結果を再現したり、後で分析を繰り返すこともできます。では、ここからはジョーダンにバトンタッチします。ジョーダンは
	再現可能なデータキュレーションについて話します。
ジョーダン・ヒラー	わかった。ありがとう、ミア。
	こんにちは、ジョーダン・ヒラーです。JMPのシステムエンジニアです。再現性についてもう少し詳しくお話ししましょう。
	データキュレーション用。
	ミアはこのアイデアをとてもうまく紹介してくれましたが、もう少し詳しく説明しましょう。ここでのアイディアは、簡単に再実行できるようにしたいということです。
	分析用にデータを準備するために使用するすべてのキュレーション手順を自動化しています。これには主に3つのメリットがあります。1つ目は効率性です。データが変更され、将来新しいデータに対してこれらのキュレーション手順を再度実行する必要がある場合、
	ポイントアンドクリック操作を何度も繰り返すよりも、ワンクリックスクリプトを使って一度実行する方がはるかに効率的です。正確性は2つ目のメリットです。ポイントアンドクリック操作はエラーが発生しやすいため、スクリプトにすることで正確な再現が可能になります。
	最後に、ドキュメント化ですが、これはあまり評価されていないかもしれません。スクリプトがあれば、手順が文書化されます。
	かかった時間。これは、後々必然的にこのプロジェクトを再び見直す必要が生じた際に、このデータを準備するために何をしたかを思い出すためのパンくずの道です。
	このスクリプトは大きな助けになります。そこで今日はケーススタディを行い、再現可能なデータキュレーションスクリプトを作成する方法をご紹介します。
	ポイントアンドクリックだけで操作できます。JMP 16では、これを可能にする技術が新たに追加されました。強化されたログ機能と、強化されたログ機能に含まれるアクション記録です。
	では、これからやることを説明します。いつものようにポイントアンドクリックでデータキュレーションを実行します。これを行うと、
	必要なスクリプト、コンピュータコード（JSLコード、JMPスクリプト言語のJSLと呼ばれます）は自動的にキャプチャされます。
	新しく強化されたログで。ポイントアンドクリックによるキュレーションが終わったら、そのコードを取得して保存するだけです。もう少し強化するために、微調整や修正を加える必要があるかもしれませんが、それはオプションです。
	これは使えるチートシートです。最も一般的なデータクリーニング作業の一部です
	JMP 16でパンくずリストを残せるように、JSLスクリプトを拡張ログに残せるように、これらの操作を行う方法を説明します。行の操作、列の操作、
	データ テーブルを変更する方法、すべてのデータ クリーニング操作、ポイント アンド クリックで実行する方法などについて説明します。
	したがって、これはデータ クリーニングに必要なすべてのことを網羅したリストではありませんし、拡張ログに記録されるすべてのことを網羅したリストでもありません。しかし、これがここで最も重要なことです。
	さて、Mia が紹介したコンポーネント ファイルを使用してケース スタディに進み、拡張ログを使用して JMP 16 でデータ キュレーション スクリプトを作成しましょう。
	JMP 16 がリリースされました。これは JMP 16 の早期導入プログラムの最終バージョンなので、プレリリース版であることをご承知おきください。ただし、JMP 16 の実際のリリース版と非常によく似たものになると思います。
	ログを取得するには、
	ここでお見せします。以前のバージョンのJMPのログに慣れている方にとっては見た目が異なります。2つのパネルに分かれています。
	上部にメッセージパネル、下部にコードパネルがあります。ここで少し時間を取って、これがどのようなものかお見せしますが、まずはファイルのインポートやこの列の削除といった簡単な操作を行った場合のプレビューだけお見せしましょう。
	私が実行した2つの手順（データのインポートと列の削除）が、このメッセージパネルにリストされているのがわかります。
	再現可能なデータキュレーションスクリプトに必要なJSLコードは、この下のパネルにあります。
	本当に素晴らしいことですが、このコードがあれば、ポイントしてクリックするだけで必要なときにいつでも取得できるというのは、JMP 16 の大きな利点です。
	JMP 16では、この新しい拡張ログビューがデフォルトでオンになっています。以前のバージョンのログ、つまりシンプルなテキストログに戻したい場合は、JMPの環境設定セクションで設定できます。新しい
	ログのセクションが表示され、必要に応じて以前のテキスト表示に戻すことができます。JMP 16をインストールすると、デフォルトで拡張ログが表示されます。これらの他の機能については、後ほどケーススタディの後半で詳しく説明します。
	よし、それでは片付けるよ
	とりあえず赤い三角のログからログを削除してください。ログをクリアして、ケーススタディを始めましょう。Miaが共有してくれたコンポーネントデータをインポートしましょう。このCSVファイルから始めます。
	それで
	ドラッグするだけで最も簡単なインポートを実行します。あ、すでに同じバージョンを開いていました。すみません、まず古いバージョンを閉じさせてください。
	もう一度ログをクリアします。
	わかりました、簡単なインポート
	JMPウィンドウにドラッグして移動します。これで、369個のバッチを含むコンポーネントAというファイルが作成されました。それでは、データクリーニング作業を進めましょう。
	ヘッダーグラフです。まず最初に、Facility列にはFabTechというエントリと値が1つだけあることがわかります。つまり、変化はなく、特に注目すべき点はありません。右クリックして列を削除しましょう。
	繰り返しになりますが、これは拡張ログに記録されます。
	では、他に何かありますか？表の最後の方にあるこのスクラップ率の列が私たちにとって非常に重要で、表の前の方に表示したいとします。これを4番目の位置に移動します。
	列パネルでそれを掴んで、顧客番号のすぐ後ろにドラッグします。これで完了です。
	ミアは、この湿度の列がインポート時に誤って表示されていると述べました。主な原因は、N/Aです。
	文字変数として入力される原因となっているアルファベット文字を修正しましょう。ここで右クリックして列情報を表示します。
	データ型を文字から数値に変更し、モデリングの種類を名義から連続に変更します。「OK」をクリックします。ログをクリックすると、4つのステップが記録されていることがわかります。このまま進めていきましょう。
	では、次は何をしましょうか？連続から公称値に変更する必要がある変数がいくつかあります。バッチ番号、部品番号、そしてプロセスです。これら3つを選択した状態で右クリックし、連続から公称値に変更します。
	そしてそれらはすべて修正されました。
	ここでも、これら 3 つのステップがログに記録されていることがわかります。
	では、他に何かありますか？少し見た目を変えたいのですが、「圧力」という列があります。エンジニアたちはこの列名を「PSI」と表示したいので、この列を選択して「PSI」と入力するだけで変更できます。Tabキーで別の場所に移動できます。これもログに記録されます。
	サプライヤーです。ミアが、いくつかスペルに一貫性がないことを指摘してくれました。おそらく値が多すぎるのでしょう。文字の値を修正する必要があります。列に不正確な、一貫性のない文字の値がある場合は、再コードツールをご検討ください。
	再コードツールは、この問題に対処するのに非常に効率的な方法です。サプライヤーを右クリックして、再コードに進みます。
	これらを適切にグループ化しましょう。まずは赤い三角のオプションから始めます。すべての値を先頭文字大文字に変換しましょう。
	空白もトリミングして、不均一な間隔を修正しましょう。これでいくつかの問題は解決しました。残りはすべて手動で修正しましょう。Andersons をグループ化します。Coxes をグループ化します。
	ハーシーズをグループ化しましょう。トゥルトナとウォーリーはすでに単一のカテゴリーで正しいです。そして最後に訂正しますが、空白または欠落としてリストされているものについては、明確な説明をします。
	ここでラベルがありません。
	再コードをクリックすると、
	これらの修正を「サプライヤー 2」という新しい列に追加しました。
	1、2、3、4、5、6 のカテゴリが修正され、折りたたまれました。
	良い。
	では計算してみましょう。バッチサイズと廃棄数を使って歩留まりを計算します。
	そうですね。確かに少し冗長かもしれませんが、スクラップ率は既に存在し、歩留まりはスクラップ率から1を引いた値ですが、議論のために、
	計算です。歩留まりの列を「廃棄数」のすぐ後に挿入したいので、「廃棄数」をハイライト表示し、「列」メニューに移動して「新しい列」を選択します。
	これをyieldと呼ぶことにします。
	選択した列の後に、廃棄された番号の後に新しい列を挿入し、収量を計算する数式を入力します。
	良品の数が必要です。それはバッチサイズから廃棄数を引いた数になります。
	これが良いユニットの数です。これを全部で割ると
	バッチサイズ。
	良品数をバッチサイズで割ったものが、歩留まり計算になります。
	そして「OK」をクリックします。
	これが私たちの新しい
	歩留まりの列です。スクラップ率が1マイナスになっているのが分かります。これは…良いことです。100%を超える歩留まりがいくつかあることは、今のところ無視しましょう。
	ほぼ完了です。あと少し変更するだけです。プロセスが2つあることに気づきました。今のところは、プロセス1とプロセス2というラベルが付けられています。
	これはあまり説明的ではなく、あまり役に立ちません。もっと説明的なラベルを付けましょう。プロセス1は「製造プロセス」、プロセス2は「実験プロセス」と呼びます。これは再コードではなく、値ラベルで行います。列情報を見てみましょう。
	そして、1 と 2 に値ラベルを割り当てます。
	この列の 1 つは生産を表します。
	それを追加してください。
	2 は実験を表します。
	それを追加してください。
	[OK]をクリックします。いいですね。ヘッダーグラフには1と2が表示されていますが、データテーブルには生産と実験が表示されています。
	さて、スクリプトを保存する前に最後のステップを一つ。議論のために、データだけに興味があるとしましょう…真空がオフの時のみ分析を進めたいとします。
	では、データをサブセット化して、真空がオフになっている行だけを含む新しいデータテーブルを作成します。真空がオフになっているセルの1つを右クリックします。
	一致するセルを選択します。
	これで、vacuumがオフになっている313行が選択されました。次に、テーブルサブセットに進みます。
	新しいデータ テーブルを作成し、vac_off という名前を付けます。
	「OK」をクリックします。
	はい、これが真空がオフになっているデータのみを表示する 313 行の新しいデータ テーブルです。
	これで終わりです。データのキュレーションはすべて完了しました。では、ログに戻ってもう一度確認し、データについてもう少し詳しく見ていきましょう。
	さて、これらすべての手順と、意図していなかったいくつかの手順が、ここにログに記録されました。
	ここを見てください。すべての行は、私たちが実行するステップの 1 つです。
	他にもいくつか余計な部分があります。例えば、ある時点で行の選択範囲をクリアしてしまいました。スクリプトにその部分を含める必要はなかったのですが…
	選択した行をクリアします。削除しましょう。右クリックして「クリア」を選択すると、その項目が削除されます。これで完了です。
	さて、メッセージは上に、JSLコードは下に書いてあります。オリジンと結果に注目してください。これはなかなか面白いですね。
	何かステップを実行するたびに、ポイント＆クリックでアクションを実行するたびに、そのアクションを実行する対象と結果が存在します。これが起点と結果です。例えば、施設の列を削除したとき…
	まあ、それは悪い例かもしれません…代わりに湿度の列情報を変更してみましょう。原点、つまり私たちがそれを実行した対象です
	コンポーネントAテーブルがありました。ここにデータテーブルとしてリストされています。マウスオーバーすると「コンポーネントAを最前面へ移動」と表示されるので、それをクリックすると、コンポーネントAテーブルが表示されます。いいですね。
	結果は、湿度列に対して行った操作です。湿度を変更し、データ型を数値、モデリングタイプを連続に変更しました。下をご覧ください。
	ここをクリックして湿度の列に移動すると、ハイライト表示されて選択されます。JMPが自動的に湿度の列を選択します。
	すべて緑色ですが、最後の1つの結果は青色です。これは、さまざまなデータテーブルでのアクティビティを追跡しやすくするためです。これらのアクティビティはすべて、Components Aデータテーブルで行いました。
	最後のアクティビティでは、Components Aデータテーブルのサブセット化を実行しました。その結果、「vac_off」という新しいデータテーブルが作成されました。「vac_off」は青色で表示されています。これらの色分けによって、状況を把握しやすくなります。
	さて、ここでログで紹介したい最後の機能は…
	非常に長い一連のステップがあり、そのうちの1つだけを見つけたい場合、このフィルターボックスを使うと便利です。例えば、サブセットを見つけたいとします。ここにあります。サブセットのデータテーブルが見つかったので、必要なコードに直接アクセスできます。
	はい、これで必要なものはすべて揃いました。データキュレーションの手順はキャプチャされました。再現可能なデータキュレーションスクリプトを作成するには、赤い三角をクリックして、スクリプトを新しいスクリプトウィンドウに保存するだけです。
	インポートステップ、列削除ステップ、スクラップ率変更ステップ。これらすべてのステップがスクリプトに含まれています。
	スクリプトの読みやすさを向上させるために、構文の色分け機能があります。また、各ステップで何をしていたかを正確に示す、役立つコメントも表示されます。
	はい、これですべてです。必要なものはこれだけです。これを保存します。デスクトップに「import and clean」という名前で保存します。「import and curate components」とでも呼びましょうか。
	はい、これが再現可能なデータキュレーションスクリプトです。JMPのホームウィンドウに戻り、新しいスクリプト以外のすべてを閉じます。
	データキュレーションの手順を再度実行する必要がある場合、次のようにします。スクリプトファイルを開いたので、「スクリプト実行」ボタンをクリックして実行します。データを開き、すべてのクリーニングとサブセット化を行い、313行の新しいデータファイルを作成します。
	ここで、これを新しいデータで再生する必要があると想像してみましょう。
	コンポーネントファイルの別のバージョンがあります。コンポーネントBです。行数が50行増えたので、369行ではなく419行になりました。このプロセスをさらに50バッチ実行して、データが増えたと想像してみてください。
	これはコンポーネントBという名前で、このスクリプトをコンポーネントBで実行したいのですが、スクリプト全体でコンポーネントAを複数回呼び出していることに気付くでしょう。そこで、コンポーネントAを検索して置換し、コンポーネントBに変更する必要があります。さあ、編集しましょう。
	検索。
	コンポーネント A を見つけて、コンポーネント B に置き換えます。すべてを置き換えます。15 個が置き換えられました。
	こちらとこちらでご覧いただけます。
	スクリプトを再実行すると、新しいバージョンのデータが表示されます。行数が増えているのがわかります。実際、行数が間違っていました。以前は313行でしたが、今は358行です。
	さて、新しいデータに対して実行できる再現可能なデータ キュレーション スクリプトです。
	さて、ここでもう一度チートシートをお見せします。これは講演資料に含まれていますので、ご自由にご覧いただけます。このチートシートでは、ポイントアンドクリック操作だけでデータキュレーションを行い、再現性の高いデータキュレーションスクリプトを作成する方法が説明されています。
	私たちが作ったスクリプトは、コーディングを全く必要としませんでしたが、使えるヒントをいくつか紹介します。
	スクリプトを少しだけ強化したい場合、まずはスクリプトの先頭にこの行を挿入してください。これはすべてのスクリプトで推奨される方法です。ここに、default to という行名を挿入するだけです。
	これは、スクリプトが他のスクリプトと干渉するのを防ぐためです。これは名前空間衝突と呼ばれ、何をするのかを理解する必要はなく、ただ実行するだけで済みます。これは良いことです。良いプログラミングの習慣です。
	2 番目のヒントは、JSL 式の間にセミコロンがあることを確認することです。
	拡張ログはこれを自動的に実行します。各ステップの間に必要なセミコロンを挿入します。ただし、自分で変更を加える場合は、セミコロンが正しく配置されていることを確認する必要があります。念のため、念のためご説明します。
	コメントを追加します。
	コメントはプログラムにメモを残す手段であり、プログラムを台無しにしないように残しておく手段です。
	プログラム内に、JSLインタプリタでは解釈されない何かを残さないでください。また、拡張ログに記録されたアクションに関するメモも用意されています。ただし、必要に応じて変更したり追加したりすることができます。コメントに関する主なポイントは次のとおりです。
	典型的なフォーマットは2つのスラッシュで、スラッシュに続くものはすべてコメントです。つまり、行頭でも行末でもコメントとして記述できます。インタープリタはこのX = 9というJSL式を実行しますが、スラッシュに続くものはすべて無視されます。
	より長いコメントがある場合は、先頭に/*、末尾に*/という形式を使うこともできます。これでコメントが囲まれます。コメントは自分用のメモとしてだけでなく、JSLスクリプトのデバッグにも役立ちます。
	コード行を削除して実行しないようにしたい場合は、行頭に2つのスラッシュを追加するだけで済みます。また、より長いコードブロックに対して同じ処理を行いたい場合は、この形式を使用できます。コメントの使い方を知っておくと便利です。
	最後にご紹介するヒントは、データテーブル参照を一般化することです。Components Bという新しいファイル名でスクリプトを実行するために、検索と置換が必要だったことを覚えていますか？
	スクリプト内のデータテーブルで15個のインスタンスを変更する必要がありました。15回も変更するのではなく、一度に変更するだけで済むとしたら、もっと良いと思いませんか？そうすれば、スクリプトをより堅牢にすることができます。
	データテーブル参照を一般化することで実現します。テーブル名を使用する代わりに、JSL変数を使用してテーブル名を保持します。ここで私が何を言っているのか、例を挙げて説明します。
	左側は、拡張ログのアクション記録によって生成されたコードです。
	Big Classデータテーブルを開いて、年齢列を操作し、連続モデリングタイプに変更して、新しい計算列を作成します。
	開いたときに、年齢列の変更を実行するために使用し、ここで使用します。
	これをより堅牢かつ一般化するために必要なことは非常にシンプルです。
	3つの変更を加える必要があります。
	こちらの最初の変更で、名前を割り当てています。私はBCを選択しましたが、お好きな名前を選んでください。DTはよく見かけると思います。
	BCは、スクリプトの残りの部分でBig Classデータテーブルを参照する名前です。年齢を変更したい場合、
	age は BC データ テーブルとそのデータ テーブル内の age 列を意味します。
	ここでは、Big Classデータテーブルにメッセージを送信しています。二重矢印構文はまさにこの意味です。つまり、これを一般化して、新しい名前を使ってメッセージを送信するようにしているのです。
	データテーブルに追加します。そして、このスクリプトをBig Class以外の名前の新しいデータテーブルで実行する必要がある場合、必要な変更はこれだけです。スクリプト内の1箇所を変更するだけで済みます。検索と置換を行う必要はありません。
	さて、これらの4つのヒントを終えて、キュレーションスクリプトを次のレベルに引き上げる準備ができたら、次のステップをいくつかご紹介します。ファイルピッカーを追加することもできます。コーディングはそれほど必要ありません。
	誰かがこのスクリプトを実行するときに、スクリプトを手動で編集するのではなく、スクリプトを実行したいファイルに移動するだけになるように変更します。
	これは良いアイデアですね。スクリプトを組織内の他のユーザーに配布したい場合は、JMPアドインに組み込むことができます。そうすれば、ユーザーはJMP内のメニューからスクリプトを選択するだけで実行できます。
	本当に便利です。最後に、ネットワーク上のどこかに保存されているマスターJMPデータテーブルを更新するために、このキュレーションスクリプトをスケジュールに従って実行する必要がある場合は、WindowsのタスクスケジューラまたはMac OSのAutomatorを使用してスケジュールに従って実行できます。
	まとめると、Mia は、データを探索し、反復して問題を特定することで、データ キュレーションを行う方法について話しました。
	これらの手順を自動化すると、再現性、つまり効率性、正確性、作業の文書化というメリットが得られます。
	JMP 16 でこれを行うには、通常どおりポイントしてクリックするだけで、拡張ログで実行されるアクション記録によってデータキュレーション手順がキャプチャされます。
	最後に、拡張ログからJSLコードをエクスポートして修正することで、再現可能なデータキュレーションスクリプトを作成できます。これで講演は終了です。お忙しい中、ありがとうございました。

高度な統計モデリング自動化とスクリプト基本的なデータ分析とモデリング消費者および市場調査コンテンツの編成データアクセスデータのブレンドとクリーンアップデータの探索と可視化実験計画法予測モデリングと機械学習品質およびプロセスエンジニアリング信頼性分析結果の共有と伝達