UA-115498173-1

2019年03月23日

グラフビルダーの「区間」ゾーン

はじめにご報告しておきたいのですが,近いうちにこのブログを移設しようと思っています.当面はここにも同時掲載していきますが,よろしければ来週からは移設先に行っていただけるとありがたいです.費用をかけるほどのブログでもないので,とりあえず以前使っていて使い方を知っているというだけでBloggerにしました.移設の理由ですが,さくらネットのブログは使いにくいというだけでなく,記事のカテゴリーやタグを泥縄式につけていったので一度リセットしたかったからです.Bloggerにうまくエクスポートできないので,時間ある時に手動で今の記事は移動していきます.それが完了するまでは,こちらとあちらに同じ記事を書いていく予定です.

さて,ここのところ「「DOEを成功させるためのヒント」について書いているのですけれど,飽きてきました.そこで本日は違うことにしたいのですが,何にしようかと考えるに,最近気づいた些細なことを.

先週とあるJMPのセミナーで講師をしたのですが,私はJMP14で受講者はJMP13という環境でした.グラフビルダーのGUIを説明していてJMP14には新たにドロップゾーン(変数をドラッグしてドロップしようとすると色が変わる領域のことです)として「区間」というデータゾーンが右側の一番下(「サイズ」の下)に加わっていたことに気づきました.この役目は言わずもがなですが,何気に便利ですね.例えば,サンプル平均の棒グラフを描いて,そこに標準偏差「SD」のエラーバーを載せたいときは,「SD」をこの「区間」ゾーンにドロップします.

もちろん,グラフビルダーには,グラフ要素のオプション(グレーの開閉ボタンまたはグラフ上で右クリックで出します)に「誤差バー」というのがあるのでそこからSDやSEを選べばこと足ります.この「区間」ゾーンが便利なのは,たまにあるサンプルの統計量だけが与えられているデータのグラフを書く場合です.例えば,最近発表された「World Happiness Report 2019」に添付されているデータはテーブルには「Happiness score」と「Whisker-high」「Whisker-low」という統計量があるだけで,サンプル詳細は不明です.

そこで「Happiness score」を「Y」にドロップしてから,「Happiness score」と「Whisker-high」「Whisker-low」とを「区間」にドロップするとこのようになります.
DraggedImage.e79a7ed84d9d4b5391f00ec2b315a840.png
このとき,ドロップしようとすれば気づくはずですが「区間」ゾーンは例えば,こんなふうに三つのサブゾーンに分かれます.ちょっとわかりにくいですが,青い実線で囲われているのがサブゾーンです.
DraggedImage.ccd877e2b54748fa89af37cf9a027076.png
この図では左下のサブゾーンに「Whisker-high」をドロップしているところで,この操作によって「区間」に二つの変数を設定できます.真ん中のサブゾーンにドロップすると先に入れた変数を上書きしてしまいますので注意が必要です.

この仕様の良いところは,上下限を独立して指定できるので,例えば,下限に「Happiness score」を入れると,このような片側だけのエラーバーを入れることもできます.
DraggedImage.403dd0ce973c48b2b851b55c3b0febf0.png
この片側エラーバーはあまりお勧めはしませんが,医薬関連の論文にはなぜかよくでてきます.因みにこのグラフは参考までに載せましたが,こういうグラフは書いてはいけません.なぜだかはお分かりですね.注記さえしておけば,独自の定義によるエラーバーも載せることができます.例えば「Range」など面白いですかもしれません.あまり見かけないのでしっかり注記してください.

「World Happiness Report 2019」はちょっと気になる報道があったので今原著を読んでいるところです.何かわかったらブログで書こうと思っています.
それではまた.
posted by Tad at 19:00| Comment(0) | TrackBack(0) | JMP

2019年03月16日

カスタム計画を使おう

本日も「DOEを成功させるためのヒント」の続きを書きます.今回のヒントは「カスタム計画を使おう」というとても簡単でものなので,あまり説明する必要はないかもしれません.わたしがこんなことを言うまでもなく,JMPの実験計画メニューはJMP12からだったかJMP13からかは忘れましたが,このようになりました.
112.png
これはJMP14のメニューですが,「カスタム計画」を先頭に,それを補うための「拡張計画」を従えています.区切りが入ったその下には決定的「スクリーニング計画」があり,「古典的な計画」がその下に続きます.下の三つのメニューは「特殊な目的」の「Space Filling計画」を除いては,あまり使うことはありません.「計画の診断」にある「計画の評価」はとても有効な機能ですが,普通にカスタム計画を作ると「計画の評価」はレポートに出力されるので,独立したコマンドとして使う機会はさほど多くないと思います.
ご存知の方も多いと思いますが,カスタム計画はJMPだけの用語であって,一般的には最適計画(Optimal Design)と呼ばれています.Nordström, Kenneth (1999), Statistical Science 14 (2): 174–196 によればGustav Elfvingという統計学者が極地観測において観測回数(実験回数)を最少にすべく考案した手法がもとになったようです.実験回数の圧縮に生命を賭した,まさに生き残るための実験計画だったわけです.わたしたちにとっても実験回数の圧縮は切実な問題ですから,これを使わない手はありません.
とは言っても,医薬系を除く日本の製造業のメーカーでは馴染みがないと思うので,上司や同僚にカスタム計画とは何かということを説明する必要がるかもしれません,そんなときは,数式を並べるのではなく,より具体的に従来の実験計画と異なっている特徴が求められます.それは何かと考える鍵が「古典的な計画」です.この下のサブメニューには「スクリーニング計画」「応答曲面計画」「完全実施要因計画」「配合計画」「タグチ配列」の5つがあります.この中で「配合計画」はちょっと異端で,なぜに「古典的な計画」に押し込まれているのか不思議です.計画の手法というよりは実験の制約に関する計画手法なので「特殊な目的」の下に入れたほうが良いような気もします.事実,配合計画では「最適計画」や「Space Filling」といった(古典的ではない)計画の種類が選べます.改めてその他の4つの計画を眺めると,それらは基本的に直交計画であることがわかります.カスタム計画の特徴を伝える際は,直交計画との比較を念頭に入れるといいです.
それでは,L12,L16,L18等に代表される直交計画とはどういうものかと長所短所を挙げてみると.
● 直交しているので安全な計画が組める
● ツールを必要としない
安全といっても予測に安全という意味ですが,これが最大の長所ですね.JMPユーザーにとってはソフトを必要としないというのは長所にはなりません.
● TAGUCHIのロバスト設計が適用できる(L18)
これは長所といって良いものか悩みますが,要因効果図が正確に描けるということは長所といっても良いかもしれません.
● 計画の選び方,割り付けに知識を要する
● 実験数が比較的多くなる
これらが短所です.これに対し非直交計画であるカスタム計画では,直交計画とは真逆の特徴になります.
● 既存の知見を生かすことで,実験数が圧縮できる
● 拡張計画による戦略的で粘り強い技術活動を支援する
少し飾った表現があざといかもしれませんが,これが長所です.一方,短所は以下のようなものでしょう.
● 直交していないためできた計画の評価が必要
● ツールが必須
● TAGUCHIのロバスト設計の適用不可
安全な計画と判断するには計画の評価が必要ですが,JMPならば(勝手に)実施してくれますし,安全性という意味では,そもそも最適化設計にはいかなる計画を採用しても再現性の確認が必要です.ですから,JMPユーザーであって,品質工学をやるのでもなければこれらは短所とは言えないでしょう.
結論としては,実験数の制約が厳しく,(そのことのデメリットを覚悟した上で)一実験でも減らしたいならばカスタム計画に限ります.更に.わたしがカスタム計画が技術者向けと思うもう一つ理由は,いろいろ覚える必要がないということです.実験計画を勉強することなしに,身軽に実験計画を使って最適化を実施して素早く問題解決に挑むことの意義は大きいと考えています.
カスタム計画以外にも,拡張計画とか決定的スクリーニング計画,あるいはSpace Filling等の有効な計画があり,これらとの使い分けについて,あるいはカスタム計画においても最適化の基準等知っていくべきことはありますので,これらについてはまたいつか書こうと思います.
それではまた.
タグ:問題解決 JMP
posted by Tad at 19:00| Comment(0) | TrackBack(0) | 講演コンテンツ

2019年03月09日

近江商人の商売十訓にみる最適化設計

本日は「DOEを成功させるための7つのヒント」その3の「動特性を評価しよう」ということについて書きます.

講演ではあえて動特性という品質工学の言葉を使いましたが,相応しい言葉とは思いません.そもそも品質工学では,制御工学分野から引っ張ってきている用語が多く,初学者には紛らわしいものです.SN比とかエネルギーとか似て非なるものを同じ言葉で表現することは極力避けるべきです.SN比の定義で対数を取ることは加法性を意識してのことでしょうけれど,パラメータ設計に持ち込むならば,無次元化した平均2乗損失の逆数という一般化した定義の方がわかりやすいです.

因みに,制御工学で動特性というときは,時間的に変化するシステムの応答関数を意味しますが,品質工学では設計因子と信号因子で二次元的に記述されたシステムの特性のことです.一方,このヒントでの動特性とは,設計因子と(目的)因子間の関係性を包含したシステムの統計モデルのことです.ですから動特性を評価しようということは,システムに目的因子を見出そうということと同義です.その上で,目的因子を取り込んだ実験をして統計モデルをつくり,更に目的因子の水準範囲で所望の特性を得る設計解を得ることを意味します.

一つ注意して欲しいのは,この目的因子という言葉はわたしが勝手に名付けた名称ということです.本書で説明しているように,目的因子とはユーザーが目的を達成するために調整する(可能性のある)因子のことです.例えば,炬燵の設定温度とか,自動車のエンジンの回転数とかがその一例です.エンジンの特性をトルクとパワーとで定義して,最適なエンジンを作ろうとした設計者は,回転数が重要な因子であることを知っているわけです.かといって,最適解として「5000rpmでお使いください」と取り説に書くわけにはいきません.ドライバーが速度(目的)に応じてアクセルを踏むことで回転数を調節することを前提としてエンジンというシステムを最適化しなければならないのです.回転数を例えば5000rpmに固定した場合を品質工学では静特性と呼んでいますが,何のことはない,目的因子を固定因子とした場合に過ぎません.

システムの目的因子が何かを考えることがポイントとなるわけですが,近江商人の商売十訓のその5にヒントがあります.松下幸之助が昭和11年の松下電器連盟店経営資料として書いたとされる「商売戦術30ヶ条」の第11条の出典としても有名です.「無理に売るな,客の好むものも売るな,客のためになるものを売れ」という言葉はどこかで聞かれた方も多いでしょう.客の好むものとは流行を追った商品であったり廉価商品であったりと様々ですが,そういう商品は売ってはいけないということです.そして,客のためになるもの,使って便利な商品を売りなさいと教えています.

マーケティング業界の言葉でマーケットインとプロダクトアウトはよく知られています.両者は対立した概念と説明されることも多いのですが,実は製造者の視点からユーザーを見ているという点で両者は同じものです.作るものが先にあってマーケットを探すのか,マーケット(消費者のニーズ)があって作るものを決定するのかの違いに過ぎません.

これら以外に,マーケットアウトという考えがあることはご存知でしょうか.マーケットアウトとは,ユーザーのニーズを踏まえて製品を作っていくというアプローチです.消費者の視点でマーケットから世の中が求めている製品を生み出すのがマーケットアウトであり,それを見据えて作るのがプロダクトインなのです.
上述した「客の好むものも売るな,客のためになるものを売れ」という言葉は,まさにマーケットインではなく,マーケットアウトたるべしということを言っているのです.これは私たち技術者にとっては,プロダクトアウトでなく,プロダクトインたるべしということと捉えるべきでしょう.

いささか脱線してしまいましたが,このプロダクトイン即ちユーザー目線での製造設計の肝が目的因子なのです.ですから,目的因子を考えるということはプロダクトインに繋がるはずです.ユーザーの求めるものがユーザー自身にもわからないことも多々あります.むしろユーザーは欲しいものは自覚できても,求めるるものは自覚できないと思った方が良いかもしれません.そこでわたしたち設計者が,顧客視点でそこに目的因子が潜んでいるはずだと深く考える必要があります.

Appleはユーザーが望んでも顧客のためにならないものは作らないという精神では徹底しているメーカーです.ある意味ではプロダクトアウトとも言えますが,それだけではここまで成功しなかったでしょう.そこにはプロダクトインがあったのは明白です.例えば,MicrosoftのSurfaceのようなタッチパネル搭載PCは作らないと明言しています.(タッチスクリーンのコンセプト製品もあるようですが)それはキーボードとの併用ではユーザーが疲れてしまうからだと説明しています.PCの最適化設計に,ユーザーの手の移動距離のような目的因子が想定できるのではないでしょうか.その他にもiPodの「所有している全ての音楽をポケットに入れて持ち運べる」というコンセプトや,シンプルかつスタイリッシュということを最優先したためにフロッピードライブを撤廃してユーザーにブーイングを買った初代iMac等々,これらは全てユーザー目線のプダクトインの製品であったことは今になって見ればわかります.昔のPCはフロッピーがあって良かったなどという人はいませんから.

あなたの製品の目的因子は何かをプロダクトインで考えてみてください.それではまた.
タグ:問題解決
posted by Tad at 19:00| Comment(0) | TrackBack(0) | 講演コンテンツ

2019年03月02日

MacBookが故障した話

先週の金曜日にJMPer’s Meetingで使ったMacBook Proですが,なんと翌日の土曜日に故障してしましました.先週のブログを書いているとき,なんか今日はタイプミスが多いなと思っていたんですよね.前の日の疲れからと思っていたんです.症状は「nキー」が二度打ちされてしまうというのもので,ローマ字入力なので,例えば「なんです」とタイプすると「nなんです」となってしまいます.調べたら,MacBook Pro (2016 以降) のキーボードには埃などが隙間に入って動作不良を起こすというトラブルがあるようです.MacBook や MacBook Pro のキーボードのお手入れ方法などという公式文書も公開されているくらいです.この本体を75度傾けるという指定がなんとも奇妙ですね.(分度器なしに正確に75度を知るにはどうすれば良いのかを考えること数分.正三角形を描いて60度を作り更にそれを4等分すれば良いことに気づきました.)面倒なので,おおよそ75度で書いてある通りに処置しても改善せず.最後の手段でAppleのサポートに連絡して持ち込み修理の予約をしました.

幸いなことにこのトラブルはApple側が認識していて無償修理の対象となっていました.そうでなければ,正確な額は忘れましたが,5万円以上かかるのだとか.この無償修理は購入から4年という制限がありますので,MacBook Proのユーザーの方はキーボードの調子がおかしいなと思ったら様子見をせずに動いた方が良いです.因みに,その後に知ったところでは,第三世代のバタフライキーボードでは対策されているという噂もあるようです.

サポートには最長1週間と言われたのですが,なんと中1日で修理品が輸送されてきました.それで本日はこれからバックアップデータをもとに戻すところです.言い訳が長くなりましたが,そういうわけで,本日のブログで書く予定だった「DOEを成功させるためのヒント」の最三回は来週に回します.三番目がなんだったか忘れてしまったので.そもそもあのヒントは「統計的問題解決入門」を執筆したときのドラフトがもとになっていて,全部で30以上もある中から今回の講演のために7つ(追加分を入れると8つ)を選んだものなのです.先日SAS社から参加者の皆様のアンケートをフィードバックしていただいたのですが,この7つのヒントが好評でした.そういうわけで気を良くしてこの企画は続けますが,今週は上記の事情により休載します.

これだけですと物足りないので,問い合わせを頂いている「事例検討会」について補足します.正式にはHOPE事例検討会と呼んでいて,高橋先生が主催されているHOPEアドインを使った事例検討を研究するという集いです.その場ではHOPEアドインのライセンスがもらえるだけでなく,使い方の指導もしています.JMPユーザーであれば,参加資格は唯一自分の事例を落ち込むことです.あの場ではデータが必要と言ったかもしれませんが,それは正確ではなくて,これからどのような実験計画を組めば良いかの相談であっても構いません.その場合に必要なのはデータではなくて事例の背景です.その際,細かい技術内容は不要です.正確である必要もありません.データは実験した後に持ってきていただき,HOPEを使った最適化を試みるという流れになります.この場合も,因子名や水準値はマスクして構いません.とは言っても,社外発表等の承認手続きが必要になる会社もあると思いますので,そこらへんはメリットとデメリットを秤にかけてご検討をお願いします.現在,隔月で実施している検討会ですが,今後は毎月実施する予定ですので,最短では一月で問題解決できるかもしれません.

因みに,MCDAアドインはこの検討会では対象外です.MCDAアドインは「統計的問題解決入門」の読者に多目的最適化の醍醐味を味わっていただけるように企画したものなので,SAS社でも事例検討会でもサポートしていません.HOPEアドインと違って,MCDAアドインはJMPネイティブのモデリング(モデルのあてはめ)を使いますので,そのぶん機能はシンプルですがHOPEアドインとはアプローチが異なるので注意が必要です.先週のJMPer’s Meetingの後に,早速本書を購入してMCDAアドインをダウンロードしてくださった方もいるとSAS社の営業の方に聞きました.その方がこのブログをご覧になっているかわかりませんが,不明な点あれば直接このブログのコメント蘭でお問い合わせください.事例相談等についても,できる範囲で協力します.東京近辺の方であれば,SAS社の会議室を借りて,直接お話しすることもできるかもしれません.

本日は雑記でした.これからバックアップを復元します.それではまた.
posted by Tad at 19:00| Comment(0) | TrackBack(0) | 雑記

2019年02月23日

システムを意識しよう

昨日のJMPer’s Meetingさ参加してくださった皆様.どうもありがとうございました.当日は花粉症の影響で喉の調子がよろしくなく,体調的にも今ひとつでしたが,多くの方にお会いできてとても有意義でした.
さて,昨日もお話しした「DOEを成功させるためのヒント」について続けます.今週はその2として「システムを意識しよう」ということについて書きます.システムという言葉は,日本語ですとSEに代表されるようにコンピュータ関連の特にソフトウェアに限定して使われることが多いのですが,そもそもは系という訳が与えられている広範囲な概念をも意味します.例えば太陽系はソーラー・システムです.一企業の囲い込みを「エコシステム」などときれいごとで表現することもあります.

DOEによる問題解決の場合,最適化する対象をシステムと見做すことが大切です.この場合のシステムは,個々の構成要素が全体として機能していると考えます.ですから,ほとんどのモノはシステムです.例えば,自動車,PCと言った工業製品はもちろん,カレーライスやおでんなどの料理もシステムと考えることができます.そうだからこそ,こう言ったモノは最適化即ちその機能を最大化することができるのです.最適化設計ではDOEによるデータでシステムを数式化するわけですが,そのDOEがカスタム計画であるときは,システムの構成を仮定する必要があります.鶏と卵のようではありますが,物理学で理論構築の際にモデルを立てるのと似ています.このシステムモデルを元に統計モデルという別のモデルを立てるのがややこしいところです.

システムのモデルをもとにDOEを構築する場合,設計因子と特性はシステムの縦糸と横糸であると意識します.こういうときに,よくフィッシュボーン・チャートを使うように書いてある本もあります.JMPではishikawaダイアグラムとして実装されていますが,わたしはそれよりもマインドマップ的なものを紙に書くことをお勧めしています.マインドマップはフリーも含めていろいろソフトやアプリがリリースされていますが,紙に書いた方が絶対いいです.A4のコピー用紙を横にして使うのがお勧めです.ノートに書くならば無地に限ります.どう書いていくかというと,ステークホルダーでシステムを把握することがコツです.

例えば,「おでん」というシステムには作る人と食べる人というステークホルダーがいます.作る人は,レシピ(材料の種類と量)や調理方法・手順などで「おでん」に関わります.食べる人は代金を支払って味や食感などを得ることで「おでん」に関わります.これで一通りの縦糸と横糸が導かれたわけですが,実践的なDOEではもう一人の重要なステークホルダーがいらっしゃいます.それは誤解されることを恐れず言ってしまえば,神様です.神様は「おでん」に気温などの環境として影響します.関東か関西かという場の違いを考慮するならば,固定因子とすべきかノイズ因子とすべきかで悩むこともあるかもしれません.然しながら,この段階では作る人(お店)または食べる人が関東にあるか関西にあるかという関わり方で捉えるに留めておきます.

今日は昨日無理したせいで喉の調子がいまいちなのでここまでとしますが,ここらへんの説明は本書P173をご参考にしてくださるとわかりやすいかと思います.

それではまた.
posted by Tad at 19:00| Comment(0) | TrackBack(0) | 講演コンテンツ