UA-115498173-1

2019年03月30日

オーギュメントコードと実験計画

先週お話ししたように,ブログ移行の作業中です.Bloggerへのインポートがうまくいかないので,手動で過去の投稿を移しているのですが,この機会に記事を読みなおして適宜修正を入れたりしてます.今だったらこう書かないなというのが結構目に付きますね.これから過去の記事を読まれる方がいらっしゃるならば,あちらで読んでいただく方少なくともがタイプミスは減ってます.

移設先はこちらです.統計的問題解決研究所 https://thinkstatistical.blogspot.com

もうしばらくはあちらでも記事を投稿する予定ですが,やはり面倒なので来週からは更新止めるかもしれません.少なくとも,こちらでは画像を入れたりリンクを貼ったりもしませんので,今後はあちらに行っていただけるとありがたいです.本日の記事でも画像が抜けているのでわかりにくいかもしれませんが,ご容赦ください.

このような事情で過去の記事を読みなおしたりしていますが,「統計的問題解決入門」執筆当時のことが思い出されます.わたしの場合,大学の先生とも違って,執筆には土日をさくしかないのですが,執筆中はいつも鶯の鳴き声が響いていた記憶があります.今も鶯の谷渡りが聞こえているので,ページ数の制限や,外国人の名前を呼び捨てにするかとか,データ引用の著作権のことなどで悩んだり,そもそも書籍を出版するなどというのは無謀だったかもと後悔したことなどがフラッシュバックしています.今になって振り返れば,大変だったけれどセミナーで同じことを繰り返さずに済むようになったのは,その甲斐がありました.先日も「温度は折れ線グラフで書いてはダメだよ」などと話していたら,比例尺度と間隔尺度との違いがわからないというので「p7のコラムを読んでね」と返事したりしてます.

一番の収穫はブラインドタイピングできるようになったことでしょうか.実は,性懲りも無く別の本を執筆しています.「統計的問題解決入門」の執筆ではようやくブラインドタイピングできるようになった頃に脱稿でしたから,今回は前回比およそ1.5倍で執筆中です.脱稿が見えてきたら,またこの場で報告いたします.

さて,「DOEを成功させるためのヒント」の続きですが,今週は前置きが長くなってしまったので,前回の「カスタム計画を使おう」を補足するにとどめます.わたしはカスタム計画一押しで,少なくともイノベーションを目指す技術者にはその他の計画は必要なしという過激派ですが,いくつかの例外はあります.三つあって,その一つが拡張計画です.といっても,特定の計画手法があるわけではなく,計画を拡張するというだけの意味に過ぎません.実験計画メニューの下にある「拡張計画」では,拡張選択として以下の手法が用意されています.


ここで拡張計画といっているのはこの拡張選択の右端にある「拡張計画」です.ちょっとややこしいのでSAS社には言葉を変えてもらいたいですね.そもそも英語では拡張計画はAugment Designなのですが,拡張という訳はJMP日本語版独自のものでしょうか.Augmentは拡張というよりは増強です.アメリカ滞在時にUnited States Marine Band(海兵隊の音楽隊)の奏者にサックスを習っていたので,少々Jazzのコードがわかるのですが,augと添字されるコードがあります.5thが半音上がって根音・長三度・増五度とノート間隔がすべて長3度になるちょっと独特な奇妙な感じがする特殊なコードで,オーギュメントコード(オーグメントとも)と言います.このaugはaugmentを意味するもので,明らかに増加する(半音上がる)ことからのネーミングです.ですので,augment designは拡張計画というよりは増大するというニュアンスを加味して増強計画と訳した方が良いと考えています.

そうでないと,日本語で拡張は範囲の拡大を意味しますから,後付けで設計因子が追加できるのかと思う人が出てきます.(実際にいらっしゃいました.)確かに元がカスタム計画であれば,実験空間の拡張もできますが,設計因子の追加は無理です.実験空間の拡張もせっかく取れているバランスが崩れるので,軽々しく拡張するのは考えものです.拡張計画は交互作用の追加のためと割り切った方が安全です.そういえば,以前「計画を拡張すると手薄になるのではないか」という質問を頂いたこともあります.「拡張とは書いてありますが,実際は増強です.」とこのときはお答えしました.

拡張計画では「実験回数の指定」にいつも悩むのですが,そこはうまく計画の評価を使ってください.実例を挙げて,拡張計画をうまく使って実験数を圧縮する事例なども紹介したいのですが,すいません,時間が来てしまいました.ブログ継続のコツは時間をかけすぎないことなので,ここで締めます.

カスタム計画以外に例外的に使う計画の残り二つについては書けなかったので,また今度お話しします.それではまた.
タグ:JMP
posted by Tad at 19:00| Comment(0) | TrackBack(0) | 講演コンテンツ

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) | 講演コンテンツ