産業プロセスの中核では、ますます多くのデータが収集・保存されています。これらのデータはプロセスの動作を反映するものであり、その内容をリアルタイムで特定することが成功の鍵となります。
したがって、リアルタイム情報を取得するには、API Rest（データベースアクセス）の使用が不可欠です。このケースでは、HTTPリクエストを使用して、マンチェスターの今後7日間の天気予報を定期的にアップロードします。次に、JSON解析から仕様限界を定義するための自動データ準備が行われた後、JMP Liveレポートが自動的に生成されます。これらのレポートには、インタラクティブなビジュアルや管理図などの統計監視ツールを含めることができます。このSPC監視は、気象許容の設計空間にリンクされた一連の制約に従い、ドリフトが発生した場合にはアラームを発します。これらのアラームは電子メールを介して関係者全員にドリフトの存在を通知し、それに応じて対応できるようにします。このように、データアクセス、データ準備、レポート、管理図の更新、ライブコミュニケーションというSPCチェーン全体が、JMP Live内で完全に自動化されています。
皆さん、こんにちは。「マンチェスターに傘を持っていくべきか：プロセス監視のアナロジー」と題したプレゼンテーションへようこそ。私はフローレンス・クセナーです。JMPのプリンシパルシステムエンジニアで、12年前にフランスでJMPに入社しました。
このテーマの目的は、皆さんが日常業務で経験するプロセスモニタリングのあらゆるステップを再現するケーススタディを作成することです。問題の定義、データ収集、分析ステップ、情報の共有（これは非常に重要なので、時間をかけて説明します）、そしてこれらの様々なステップの更新すべてです。プロセスモニタリングにおいてもう一つ重要なことは改善です。この点について、私は全時間かけて説明します。これが今回のセッションの議題です。
次に、アクセスしやすく定期的に更新されるデータが必要でした。このプロセスでは、天気データを利用します。このセッションで私が持っている定義と状況評価データは、「旅行の準備をする際には、必要なものをすべて準備する必要があります」というものです。問題は、「傘は必要か、コートなど何か必要なものか」ということです。この質問に答えるには、天気を確認する必要があります。
今では、スマホやパソコンで天気予報を確認できるアプリが当たり前になっています。JMPでこれらの手順をすべて再現できるかどうか、まさに私がやりたいことなのですが、JMPで再現できるでしょうか？
以前、まず設計空間を定義する必要がありました。通常、日常業務で設計空間を定義するには、実験計画法（DOE）を用いるのが最善のアプローチです。実験計画法の種類は様々ですが、状況によっては、何らかのデータが存在するかもしれません。過去のデータから設計空間に関する知見が得られるかもしれません。もしデータが存在する場合、それが十分でなければ、過去のデータとDOEを組み合わせることができます。
最終的に重要なのは、製品の品質を達成するために、入力にある程度の変化を持たせられる場所を見つけることです。私の状況は少し異なります。データとこのプロセスは夏に作成したため、冬のデータはありません。気象データに関する設計空間を作成することはできません。不可能です。様々な指標を検討する必要があるため、私の状況に合わせて気温と降水量を選択しました。
私がやったのは、空間充填均一設計を作成し、データに事前情報を埋め込むことです。気温と降水量、そして1から10の間で気分を書き込んでいるのがわかります。2つの四角で緑色にハイライトされているのが、許容範囲であることがわかります。
まず1つ目はこれです。今日はこれに焦点を当てます。降水量はそれほど多くなく、気温は8度から30度の間です。気温が8度を下回ると、明らかに急激に寒くなってしまいます。30度以上なら大丈夫ですが、状況によって異なり、必ずしも許容できるとは限りません。
他の地域では、気温がゼロ付近で降水量が多い時間帯が多いのが分かります。私はスキーとスノーボードが好きなので、こういう状況になるととても幸せです。しかし、マンチェスターではそうではありません。ここはアルプス山脈ではありませんし、スキーやスノーボードもしません。私が注目しているのはこの地域なので、降水量は1.5以下、気温は8～30℃です。
その後、データが必要です。通常、定期的に日付が付けられたデータの場合はデータベースを使用します。UDBCデータベースは、月単位のコマンドを使用することが多いですが、他にも次のようなデータがあります。ExcelやCSVをデータベースとして使用している人もいます。
私の場合は、少し特殊な方法を使用します。APIを使用します。このAPIを使用すると、Visual Crossingのウェブサイトに接続でき、HTTPリクエストを使用してこのウェブサイトからいくつかのデータを抽出できます。
ウェブサイトを見て、どんな内容か確認してみてください… 私のウェブサイトを開いてください。今日はなぜこんなに長いのか分かりません。このウェブサイトについて簡単にまとめると、まだ公開段階ですが、このウェブサイトは非常に優れています。ウェブサイト内で様々なパラメータ設定を行えるからです。
まず、検索する都市を選択します。このセッションではマンチェスターを検索していますが、都市は自由に選択できます。期間も選択できます。15日間、日付範囲、動的な期間、2日間のみ、過去7日間など、お好みに合わせて選択できます。過去7日間、あるいは今後7日間を選択することも可能です。期間と指標も選択できます。私はフランス人なので摂氏を使用していますが、これは変更できます。
あなたにとって何が重要か、教えてください。日次情報ですか、それとも時間別情報ですか？必要な指標は何ですか？いくつか拾ってみましたが、全てではありません。湿度、降水量、降水確率、雪の有無など、様々な情報が得られます。実際の気温とは異なる気温の感覚も必要ですか？風速、日射量、その他あらゆる情報も得られます。
ここにデータテーブルがあります。このデータテーブルは他の形式でも利用できます。JSON形式でデータを取得できるのが私にとって興味深い点です。例えば、チャートもいくつか用意できています。しかし、このウェブサイトがAPIを作成してくれる点が興味深いです。これは、私が以前行ったすべてのパラメータ化に関連するURLです。
ここにURLがありますので、これを使えます。これを使うには、URLの中にAPIキーが必要です。サインアップしてAPIキーを作成する必要があります。これは私の側で行ったことです。APIキーを生成したのが分かりますね。これが私が付けた名前です。都市名には変数も指定しています。これは、私のスクリプトが非常に簡単に変更できるためです。パリで何が起こっているかを確認したい場合、非常に簡単に変更できます。
ここにURLが表示されています。これは先ほどのものより少し複雑です。私が求めているのは今後7日間の予測情報です。具体的にどのパラメータが必要なのかが分かります。全てを取得しているわけではありません。気温、降水量、風、そして日射量だけを取得しています。
曜日の情報が欲しいと言いましたが、時間情報も必要です。ここにAPIキーが配置されているのがわかります。最後に、JSONファイルでの出力を希望しています。JMPはJSONファイルで問題なく処理できるので、これが私のリクエストです。
ここに、ウェブサイトから情報を取得したいというHTTPリクエストがあります。あとはJSONファイルを渡すだけです。このJSONファイルには2つのレベルがあることがわかります。1つは曜日に関するもので、各曜日には時間の情報があります。そのため、3番目の要素には2番目のレベルがあります。ここでも、時間に関する情報があることがわかります。
最後にデータテーブルがあります。このスクリーンショットは12月に作成されたものです。7日間のデータが収集されており、実際の日付も表示されています。これは12月5日の収集データです。5日から12日までの7日間のデータです。さらに、昨日何が起こったかという実際の情報も収集しています。
最後に比較できるようになります。降水量の変動、つまり降水量と気温の変動に関する外れ値を見ることができます。12月の今週は、予定気温がマイナス2度から12度の間でした。
分析の部分では、いくつかツールを作成しました。いくつかはご存知かと思いますが、実測温度と黄色の充填量を示すグラフを作成しました。充填量と比較すると、実測温度から外れ値が出る場合があることがわかります。
こちらには、天候の変化に関する情報を示すヒートマップもあります。最初の3日間は気温が低く、その後は気温が上昇していることがわかります。これは気温です。こちらにはコロンスイッチャーが付いているので、他の項目を確認したい場合は切り替えることができます。また、管理図に相当するものも用意しています。
同じことが分かります。次の7日間の初めと、その後の数日間は、気温が非常に低くなっています。ここで注目すべき点は、管理限界として設定した仕様限界があり、それを外れた場合はすぐに確認でき、アラームもいくつか作動するということです。8度を下回るとすぐにアラームが作動し、それを上回るとすぐに30度を少し下回りますが、この冬の時期には問題ではありません。しかし、この部分では問題ないことがわかります。
SPC（プロセス・スクリーニング）を行う際に特に役立つレポートの一つが、プロセススクリーニングレポートです。このレポートでは、すべてのパラメータを1つのレポートで同時に把握できます。気温、風速、降水確率、風向、日射量、時間別降水量など、収集した様々な要素について、安定性、アラーム、そして様々なアラームの発生率を示すレポートを作成できます。私の場合、特にアラーム1が重要です。
CpkとPpkがわかります。明らかに、CPKは気温に対してマイナスになっています。今週は風速が良好で、素晴らしい状況です。ここではマンチェスターの風向については何も述べていません。マンチェスターの風向が天候や体感にどのような影響を与えるか全く分からないからです。しかし、このような状況では役に立つかもしれません。
例えば、南フランスでは、風向きによっては、数時間後や数日後に現れる天候とは異なる可能性があります。これは、データの分析と追跡のために私が作成した別のツールです。
分析が完了したら、その分析結果を共有する必要があります。JMPでは通常、分析結果を共有する方法が2つあります。1つ目は、より高度な方法で、データテーブルを使用する方法です。まず最初に、この方法を使用します。私はデータテーブルにスクリプトを添付して他のユーザーと共有し、何が起こったかを確認できるようにしています。
あるいは、JSLを使うこともできます。JSLを使えば、より自動化が進み、JSLを実行できるようになります。このJSLに満足したら、アドインに組み込むこともできます。JMP環境を独自のツールで強化し、他のユーザーと共有できるので、非常に簡単です。
唯一の難点は、状況によってはメンテナンスが難しくなることです。JSLやアドインを更新したら、それを他のユーザーと共有する必要があります。そのためにはJMPが必要です。分析を行っていない人とも管理図を共有する必要がある場合もあります。彼らには、何が起こっているのか、欠陥率はどれくらいなのか、そしてその欠陥率を考慮してどのような判断を下すべきなのかを、ただ目で見て確認してもらうだけで十分です。
このような状況で、JMPユーザー以外と共有する必要がある場合、共有しやすい静的なレポートを作成することになりますが、JMPの機能の使用は制限されます。そのため、すべてのインタラクションが失われます。静的なレポートとその処理方法があります。それを回避するには、何らかの処理方法を用意する必要があります。
私の場合は、JMP Live の Web レポートを使用しています。その大きな利点は、共有が簡単なことです。JMP の柔軟性とインタラクティブ性はそのままに、JMP ユーザーだけでなく、JMP ユーザー以外のユーザーとも共有できます。レポートへのアクセス権限を制限することもできます。セキュリティ対策も重要です。
重要なのは、すべてのワークフローを検証できるということです。この状況では、GSLのようにワークフローが検証されている場合を想定していますが、製薬会社の場合、すべてのステップの検証が重要です。すべてのワークフローがサーバー上で検証され、すべてを共有できるのは非常に便利です。
先ほど作成したレポートと同じレポートが表示されていますね。このレポートを開いて、中身を確認してみましょう。ここで自分のWebページを開いています。セキュリティを確認する必要があります。このレポートを確認する権限は私にありますか？私の名前はすでに保存されています。自分の名前も覚えています。大丈夫です。ご覧の通り、私はフローレンスです。このレポートの所有者です。別のレポートも作成しています。同じ内容を確認できます。
このレポートがいつ更新されたか確認できます。今日は1月19日ですが、私のレポートは1月15日に更新されたことがわかります。この点については後ほど詳しく説明します。例えば、何が起こっているかを確認すると、マンチェスターの気温について、今週はこの予測データが予定されていることがわかります。
今週は週末までかなり寒いと予想されていましたが、今週末にはイギリスの気温が一転するでしょう。降水量について見てみましょう。気温は改善するでしょうが、21日は雨の日、特に大雨の日が予想されます。日射量は逆になります。雨が降ると雲ができるので、日射量は少なくなります。風速についても見てみましょう。21日は雨と風が強くなるでしょう。
これは私ができる最初の相談です。プロセススクリーニングレポートなど、他のレポートももちろんあります。これらの様々な点を強調表示できます。このレポートでは最後に風向を省いているので、風向は良好ですが、気温が非常に低いことがわかります。PpkとCpkはマイナスなので、状況は良くありません。実際のプロセスでは、非常に悪い状況になるでしょう。
管理図を見てみると、少し特殊な構造になっていることがわかります。赤いフラグで強調表示されていますが、これはここにも表示されています。これは、何らかの警告が発生していることを示しています。これはどういう意味でしょうか？JMP環境で有効にした警告もここに表示されているということです。確かに、いくつかの警告が発生しています。今週の予測では、気温が8度を超えるのは数時間だけです。
いくつか警告が出ていますが、気温だけではありません。今週末は雨が降る予定なので、傘が必要です。週末は日射量が少なく、風が吹くことも分かります。
これはヒートマップの分析部分です。先ほどのヒートマップとは違いますが、こちらは管理図を使った分析をさらに詳しく表示しています。ここでも警告が表示されています。このサマリーを見ると、各管理図における警告の割合がわかります。警告の数が非常に多く、ポイントの94%が管理限界外にあることがわかります。先ほど言ったように、これは悪い状況です。降水量については、3つ、つまり6つしかありません。風速については、10%です。
この例では、意味のあるテスト1だけを有効にしましたが、他のテストも使用できます。例えば、気温が上昇しているか下降しているかなどです。私の場合、上昇と下降の両方を使用すると毎日警告が表示されますが、意味がありません。例えば、日中に気温が変化することがあるため、どちらも有効にしませんでしたが、必要に応じて任意の警告を有効にできます。
これは共同作業です。つまり、管理図やレポートなどで特定の状況があり、コメントを残したい場合、自分の観察結果を聞き、説明したり、他のユーザーにタグ付けしてアクションを促したりすることができます。
すべてのコメントはこの場所に保存されています。JMPで開くことができます。JMPユーザーで、根本原因分析など、より高度な作業が必要な場合は、JMPで開くことができます。データセットがJMPにダウンロードされるので、データ探索を行うことができます。このレポートに興味があれば、ブックマークすることができます。ここにブックマークレポートのセットがあります。同僚やユーザーが作成した非常に優れたレポートをブックマークしています。共有することもできます。
管理図に特化してお見せしたいのは、サブスクリプションを作成できることです。これについては後ほど詳しく説明しますが、サブスクリプション管理図を作成すると、警告が発生した際に通知が届くようになり、メールが届くようになります。その点については後ほど詳しく説明します。
ここに4つのレポートがあり、希望する人なら誰でも共有できます。スライドに戻ってください。このレポートの特長は、組織全体で共有とコラボレーションを実現することです。しかし、もう一つ非常に便利な点があります。それは、公開を自動化できることです。先ほどレポートを購読できると説明しましたが、実際に購読するとどうなるか、見てみましょう。
私はレポートの所有者なので、レポートが更新されるたびにこのようなメールが届きます。これは、データ投稿が正常に更新されたことを知らせるものです。これは私がレポートの所有者であるというだけで、全員がこのメールを受け取るわけではありません。
管理図の警告については、レポートを購読している方は受信できます。月曜日にデータが更新されると、管理図に警告があるというレポートが届きました。私のレポートと全く同じ情報です。警告率は94%で、先ほど確認した通りです。警告がいつ届くかは一目瞭然です。
今、それが起こることは分かっています。今はとても寒いので、まさに今です。例えば、もう一つのレポートを見れば、降水量を確認できます。レポートには降水量が記載されています。15日には、数日後に多少の降水があるだろうと言われました。
既に把握している危機なのか、それとも管理図に新たに現れた何かなのか、ある程度の洞察が得られます。そこに表示されているリンクをクリックすると、直接ウェブページにアクセスできます。今、私が開くのではなく…管理図を開いて、何かが起こっているかどうかを確認します。管理図が私に「ああ、何かが起こっている」と知らせてくれます。もし何も起こらなかったら、そのことに時間を費やす必要はありません。
どのように動作するのでしょうか？実は、そこに戻ると、管理図上で直接開きます。そこに戻ると、私の…に関連する別のファイル、別のレポート、そしてデータセットがあります。このデータセットには履歴があります。この履歴はここにあります。12月の初めまでは毎日情報を収集していましたが、毎日更新されていたことがわかります。
現時点では、スケジュールを変更して毎週のスケジュールを設定しました。ご覧の通り、毎週データが抽出されています。なぜでしょうか？ウェブサイトでは、一定数のデータにアクセスする権利があることに気づいたからです。現在は支払い手続きをその時に行うため、その作業は避けました。3月までマンチェスターには行かないので、毎日のメールでその情報を毎日受け取る必要はないと判断し、データの更新を毎週行うことにしました。
どうやって設定するのでしょうか？設定画面を開くと、毎週月曜日の午後10時、つまりイギリス時間の午後10時にメールを受け取るように設定しているのが分かります。私のタイムゾーンでは午後11時です。だから、私は午前11時にメールを受け取るように設定しています。これを繰り返し設定できるのが分かります。毎日ではなく、もっとリアルタイムな頻度で送信したい場合は、調整できます。5分ごと、1時間ごと、12時間ごとなど、お好みに合わせて設定できます。
例えば、勤務時間中のみ1時間ごとに情報を取得したい、つまり夜間は情報を取得したくない、といった設定も可能です。また、有効期限を設定することもできます。複数のスケジューラーを作成することも可能です。例えば、週ごとのスケジューラーと時間ごとのスケジューラーを作成することも可能です。週末、休暇、あるいは毎日の業務など、スケジュールに合わせてマッピングすることも可能です。
左側にスクリプトがあります。このスクリプトは、私が行ったすべてのデータアクセスとデータ準備を管理しています。APIキーを使ったアクセス、都市、設定したスペック制限、URLが表示されています。先ほどスライドで示したコードと全く同じで、プロパティのスペック制限など、私が設定したすべてのデータ準備が含まれています。
データセットとデータテーブルはすべて準備完了です。最後に、JMPにどのデータテーブルを使用するかを指定する必要があります。これは、いくつかの異なるデータテーブルを使用しているためです。そのため、実際のデータテーブルを念頭に置いて決定する必要があります。ここで使用されているのは、更新クリップです。ここにソーススクリプトを配置できます。スクリプトは異なる場合もあれば、そうでない場合もあります。ソーススクリプトはここに配置できます。割り当てられた認証情報は、実際のデータベースに接続する際に必要となるため、特定のユーザーに認証情報を入力する必要がある場合があります。
ご覧の通り、データを表示でき、データのグリッドが開きます。ここでお見せしたいのは、データの更新を実行できることです。更新スクリプトが現在実行されているのが分かります。データテーブルに戻ると、様々なレポートが再生成されているのが分かります。例えば、管理図ビルダーに戻ると、今日から翌日までの情報が表示されているのが分かります。
今、私のメールボックスには、データセットが更新されたというメールが届いています。もう一つのメールは、管理図に警告があることを知らせるものです。警告率が低下しているのが分かります。今は19日11時38分ですが、警告は弱まっています。気温も少し高くなっているようです。JMP Liveを使った自動化のおかげで、データの状況に応じて迅速かつリアルタイムに近い判断を下すことができ、非常に便利です。
改善を締めくくる前に最後に触れておきたいことがあります。プロセスモニタリングでは、設計空間を非常に適切に定義していても、危機的状況や様々な状況に直面する可能性があります。危機的状況に直面した時は、あなたは消防士モードですが、実際には継続的なプロセス改善の方向に向かっているかもしれません。
設備や原材料など、変更が必要になる場合もあります。問題がないか確認するために、分析や実験計画を行う必要があります。新たな制約も発生する可能性があります。例えば、多くの企業が製造工程で発生する酸素や炭素に関する生態学的制約の影響を受けています。
状況によっては、データ収集にコストがかかるため、どの指標が重要かを定義する必要があるかもしれません。相関性の高いデータや、それほど重要ではないデータを収集している場合もあります。そのため、どの指標が重要かを定義する必要があるかもしれません。私の場合は予測データを使用しているため、状況は少し異なります。根本原因分析はできませんが、データ収集量が多すぎるとコストが高くなることに注意してください。
毎日データを収集する必要があるのか、それとも毎週収集すれば十分なのか、考え始めました。実際のところ、予測の質はどの程度なのでしょうか。データを収集して、何が起こっているのか、実際のデータと現実の違いは何か、そして予測との違いは何かを確認します。
色が薄いほど、予測日数が多いことを示しています。この状況では、あまり結論を出すことができませんでした。そこで、日別予測距離変動を作成しました。これが私の目標値です。初日を見てみると、今日の予測はどうなるでしょうか？この濃い赤色の部分です。予測日数が増えるにつれて、色が薄くなり、距離が伸びていることがわかります。確かに、日当たりについては努力の余地があるかもしれませんが、やり過ぎは禁物です。そうでないと、気温差が大きくなってしまうからです。
ここでデータを収集しました。1か月分のデータですが、その日の気温情報がある日は気温に注目しています。中央値は1未満で、今日までこの状態が続いています。その後、平均値は6日間で2まで上昇し続けています。
しかし、私にとって重要なのは自分の感覚です。平均値も重要ですが、差異の最大値に注目したかったのです。差異の最大値を見てみると、前日、あるいは前々日はほぼ同等で、その後はそこに変化が見られます。ここに最大値があります。明らかに同等ですが、その後は実際に変化が見られます。最初の3日間は、3日に1回ずつ測定できるようです。
よく見ると、最初の3日間に外れ値があることがわかります。最初の3日間を見てみると、最初の2日間に外れ値があるにもかかわらず、何らかの差異が生じている日が1日あることがわかります。それぞれ11月25日です。11月のすべての月を収集しているので、11月30日です。その後、11月21日にも差異が現れていることがわかります。
11月25日を見てみると、明らかに予定とはかけ離れ、非常に寒くなっていることがわかります。すべての月のデータを見てみると（実際のデータ測定のみですが）、25日には確かに気温が大きく変化していることがわかります。ニュースでも報じられています。イギリスの大部分で初めて寒波が発生し、気温が氷点下まで下がりました。ご覧いただければ、11月25日です。予定にはなかった大きな変化があったようです。
最後に、この外れ値について間違いがないように、念のためこの外れ値を削除しました。削除してみると、今日の予測と明日の予測の間に若干の差があることがわかります。今日の予測はほぼ一致していますが、さらに1日経つと、少し差が出始めます。
1日おきに1日ずつ、つまり2日ごとに収集することにしました。2K検定を行うと、毎日収集した場合と2日ごとに収集した場合の平均値に差がないことがわかります。これは変更可能です。先ほどお見せしたウェブページで、「毎日ではなく、2日ごとに情報を収集したい」と指定できます。現時点では毎週収集していますが、変更は簡単に行えます。
この天気の例で締めくくりましょう。プロセス監視の全ステップを再現することができました。設計空間の定義から更新まで、このすべてのステップが更新されました。定義後は、データ収集、データ分析、共有といった更新作業を行い、これらは毎日自動化されています。
改善から、つまり通常、改善を行う際には、設計空間の定義に取り組んでいます。私の場合は、改善アプローチを用いてデータを探索し、データベースへの最適な接続方法を確認します。
製造現場での日々の業務とプロセス管理全般との関連性をご理解いただけたでしょうか。ご質問がございましたら、喜んでお答えいたします。良い一日をお過ごしください。
