« 2007年6月 | トップページ | 2007年8月 »

2007年7月30日 (月)

うどん

20070729_1 今日、初めてうどんを打ってみた。自分ではそばもうどんも同じように好きだと思っていたし、ボストンでは加ト吉の冷凍うどんでさえも日本の倍の値段とはいえ売っていて、生麺以外は大体そろうのだけれど、やはり関西人のソウルフードであるうどんは生麺を食べないことに我慢できなくなってきたようだ。
ちなみにボストンに来て8ヶ月近く(そう、もう8ヶ月なのだ)経つけれど、そばは一口も食べていない。一番食べているのはやっぱり野菜を含めて材料が安くて充実しているパスタ、次にインスタントラーメン、うどんと続く。

レシピは4月からジュネーブに住んでいる友人のハイジさん夫婦(日本人)に1ヶ月以上前に聞いていたのだけど、ようやく今日時間を見つけて作ることができた。

20070729_2 うどんを打つのには中力粉を使うのだけれど、手近には何故か売っていないので薄力粉と強力粉を半々で使うことに。冗談みたいな話しだが本当にそれでよいらしい。
とはいえ、こちらで売っているのはもちろんアメリカ産。日本でうどんに使われている小麦粉のほとんどは、うどん向きのオーストラリア産だし出来れば日清製粉のマル香ものがあれば言うこと無いけれども贅沢は言えない。

そして朝から取りかかった結果、お昼の食卓にはそれは見事なクリーム色に輝くつるっとした讃岐うどん張りの

・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

からはほど遠い、ややグレーの縮れ麺が出来た。ちょっとざらっと感も残ったし讃岐うどんへの道は遠い。

20070729_3 とはいえ味は讃岐うどんとしてこちらで売っている乾麺よりはおいしく出来たのでひとまず満足。
今回は葱、生姜、醤油でぶっかけにして、わしわしっと食べてしまった。

ボストンにいる間に、もう少し旨いうどんを打てるように頑張ってみたいと思う。
友人が送ってくれたビデオの中に映画「うどん」がたまたま入っていたので、これも見ねば(笑)。

2007年7月29日 (日)

アメリカ

20070728_1 昨日やっとアメリカのパスポートが郵便で送られてきた。もちろん自分のではなくて娘のパスポートだ。
4月下旬に申し込んだのでたっぷり3ヶ月以上かかったことになる。やっと日米両方のパスポートが揃った。
通常は3~4週間で発行手続きが終わるらしいけれど、現在10~12週間かかっているということが国務省のホームページにも出ていたのと、発行手続き中であることがWeb上で確認できていたし、ここはアメリカなのであまり焦ることもなく待っていた。
日本のように情報は全く出てこないけれど変動にも頑張って対応するシステムと、アメリカのように変動にはあまり頑張って対応しないけれど情報提供をきっちりするシステムの違いが見えてきて面白い。どちらがいいというわけでもないけれど、ところ変わればである。

しかし自分の娘がアメリカ国籍を持っているというのは当たり前のことなんだけど、娘がアメリカ人だ、というには感情的にはちょっと不思議なところがある。
二重国籍だからと言って何が変わるわけでもないし、責任は親にあるとしても本人の問題なのであと20年経ったときに好きにすればいいとは思っている。とはいえ、親としてはそのときにはどちらを選ぶにせよ複雑な気持ちになるんだろうな。
20070728_3 なんてことを本人は知るよしもなく今日も元気に遊んでは、変な寝相で昼寝をしている。まっすぐ置いたのに・・・。

 

 

さて、パスポート自体は日本もアメリカも最近流行?のICパスポートになっていて、プラスティックを含浸させた厚紙が挟まっていて少し堅い。ただ、アメリカのパスポートは日本のパスポートとちょっと雰囲気が違って面白い。何かというと各ページにアメリカの歴史や風景を彷彿させるイメージイラストが全面に薄く描かれていて結構派手なのだ。西部開拓時代、ネイティブアメリカンの生活、山河の自然風景、バッファローと鷲と草原、自由の女神など。それに加えて歴史上の人物が残した言葉が各ページに書かれているのも面白い。日本ではなかなか無い発想だと思うけれど僕は結構好きである。自分の日本のパスポートを開いて各ページを見たくなるなんて事はなかったし。

20070728_2 そうやってぱらぱらとページをめくっていくと、最後のICが埋め込まれているページのイラストは宇宙開発がテーマだ。アメリカにおける宇宙開発のステータスの高さにちょっと感動してしまった。でもよく見るとイラストは地球、月(1970年代のアポロのイメージ?)、そして飛んでいる探査機はアポロではなくパイオニア(1972年打ち上げ)だろう。そして著名人の言葉はEllison Shoji Onizuka(鬼塚承二)氏。1986年のスペースシャトル、チャレンジャー号の爆発事故で亡くなってしまった宇宙飛行士とどれをとっても古いものばかりで、1980年頃を境にアメリカの宇宙開発も人々の心に届いていないのかと、ちょっとうがった見方をしてしまった。

"Every generation has the obligation to free men's minds for a look at new worlds... to look out from a higher plateau than the last generation."
どの世代の人たちも自由な心を持っていなければならない、前の世代が到達できなかった高みから新しい世界を見渡すための心を。
-Ellison S. Onizuka-

もちろん、自分の子供達が自分たちを乗り越えていける土台を築いた上で・・・いい言葉なんだけどな。

2007年7月28日 (土)

System Dynamics(その7)~大事なこと~

20070727_sd7_1 All models are wrong, but some are useful.
「完璧なモデルはない、それでも役に立つモデルもある」

何かしらのプログラミングやシミュレーションをする人ならこの言葉を聞いたことはあるんじゃないだろうか。当然世の中で起こる事を完璧に数式化できる訳ではないので当たり前の事を言っているに過ぎない。なのにこの言葉が有名なのは、その当たり前のことが大切なのにもかかわらず忘れられ易いからではないだろうか。
逆説的に考えて、現象を完璧に再現するように頑張ったした結果、複雑で使いにくくて仕方がないモデルができあがってしまう、なんてことが無いようにとの警告だととらえてもいいと思う。

System Dynamicsのモデルを構築する場合にもこの心構えは非常に重要だ。
それでもMITの授業でも教授がモデルを組んで何かしらの状況を説明しようとしたときに必ずと言っていいほど「実際の世界ではこういう要素も関係してくると思うんですけど」とか「これってもう少し細かく分解できると思うんですけど」という質問が出る。大体の場合は間違ってはいないからやっかいなのだ。
大事なのは、

  • 何を考えるためのモデルなのか
  • 最終的に持って行きたい望ましい状況は何か
  • そのためにはどんなパラメータの振る舞いを知る必要があるのか
  • そのパラメータの振る舞いに大きな影響を与える重要な要因は何か

であって、誰からも揚げ足を取られない正確で精密なモデルを組むことが目的ではない。モデルはいくらでも複雑に出来るし細かいチューニングが可能だ。しかし細部にこだわるあまり全体像を見失ってしまっては意味がないし、そのチューニングにかかる時間と効果を考える必要もある。
どうしても細部へこだわる必要があるなら、まずは出来るだけシンプルなモデルで全体像をとらえ、そこから徐々に重要度の低い要素をくわえていくなり、ひとまとめにしていた要素を細かく分解していくことをお勧めする。局所的に作り込んでいくと全体のバランスを取るのに非常に苦労する。

それにSystem Dynamicsの目的は全体のダイナミクスを自分が理解することであって、「モデルを組んでシミュレーションしたら、こんな結果が出ましたので問題ありません」だけでは全く意味がない。System Dynamicsのモデリング手法を使ってシミュレーションを行った結果を用いて意志決定を自動化しようというのはとんでもない間違いだ。
繰り返すけれどもSystem Dynamicsはシステム全体の振る舞いを包括的に把握することであって、数値シミュレーションは頭の中で行う感覚的、論理的なシミュレーションが合っているのか、それとも間違っているならどこに思い違いがあるのか発見することを助けてくれるものだと思った方が良いだろう。

論理を考え、それに基づいて善し悪しの判断を行うのはあくまで自分であって、System Dynamicsはそれを視覚的、論理的、数学的に補助してくれるツールだ。判断をツールに預けてしまってはならない。
System Dynamicsに限らず、シミュレーションは便利なもので自分で考えずとも結果を出してくれるので、つい頼ってしまうかもしれないけれども、それは本当に危険なことなので自戒の意味も込めて強調しておきたい。

いい加減長くなってきたので次回はSystem Dynamicsについてとりあえずの最終回。
どうすればいいモデルが組めるのか、信頼性の高いシミュレーションが出来るのかについて。

2007年7月27日 (金)

System Dynamics(その6)~ビア・ゲーム3~

20070727_sd6_beergame3_1 今日は本当に暑かった。さらに寝不足でふらふらだったにもかかわらず、朝一の授業が終わった後にクラスメート6人で炎天下の中でタッチフットのミニゲームをやってしまった。タッチフットと言えば僕にはタッチラグビーだったけれど、こちらではもちろんアメリカンフットボールだ。
結果は、相手の方がパスが正確で大敗してしまったけれど、へばりながら3人でチームの健闘を讃え合った。

残念ながらビア・ゲームではテーブルを囲むメンバー間で健闘を讃え合う光景はまず見られない。
全体のコストを最小限にするという共通の目的を持ち、各自が出来る限りの努力をするのだけれど、ゲームが進むにつれて周りから聞こえてくる声は
「ほわっつ?なんじゃこりゃ?何でこれだけしか来ないんだ?(もちろん英語)」
「へいへいへい奴らクレイジーだぜ。いきなり注文が10倍?ありえん!(しつこいけど英語)」

ゲームが終わって在庫量の変化グラフをつけてみると、一部のチームは笑うしかないほどの在庫を抱え、一部のチームは絶望的なBack log(予約待ち)に沈み、そして残りはそのどちらも体験していることになる。
教授はこのゲームを子供達から大企業の社長達までがプレイするのを数百回も目にしているらしいけれど大体の傾向は同じとのことだった。そしてみんな同じ言い訳をするらしい。

"That's not my fault! Others screwed me up!"
「俺が悪いんじゃない!周りが滅茶苦茶にしたんだ!」

全員が全員に向かって言い始めると本当に説得力が無い。

ちなみに今回の設定では、最小到達可能コストは約$550、過去の平均は約$2,200ほどになるそうだ。
僕らのクラスでは最大が約$4500、優勝した僕のチームが最小の約$1,600でありがたく商品を頂いてしまった。
それでも「勝ったのは俺が上手くコントロールしたからだ」と皆が思っていたので負けたチームとのメンタリティに大した違いはない。しかも最適コストの3倍もかかってしまっている。
(もちろん勝因はちゃんとある♪と僕は懲りずに思っている)

そしてもう一つ良くある言い訳は
"I do not fail in the second round, for sure."
「もう一回やったら絶対うまくいくはず。」

残念ながらこれも間違いだ。在庫や予約待ちの山が多少減るだけのようだ。
ちょっとした工夫は出来るけれど、全体のダイナミクスを把握することなくして到達できる範囲は限られている。例え50週に渡ってお客さんの注文がずっっと4ケースだったとしても似たような失敗をするらしい。
更には例え、このゲームを製造者がお客さんの注文を直接聞いて直接納入するケース(つまり一人でする)でも同じ失敗をしてしまう。
ここでは省略するけれど、これらは全てシステム・ダイナミクスのモデルを使って完全にシミュレートできてしまう。

話が非常に長くなってしまったけれど、このゲームから僕が学んだことは3つある。

  • 「他はどうあれ自分は自分の出来ることを精一杯やっていればいい」と言う考えは集団全体はもちろん自分にも回り回って悪影響を及ぼす可能性がある事に気づかない
  • 問題解決のために取った行動が、時間遅れを伴って忘れた頃に自分にどう戻ってくるかを考える必要がある
  • システムのダイナミクスをモデル化して見てしまうと、何のことはない当たり前の事に思えてくる

しかし、結果がわかっているからシステム・ダイナミクスが解るんじゃないか?
実際の世の中にある複雑なシステムはモデル化出来ないんじゃないか?
とかいう声も聞こえてきそうだ。
もちろん僕もまだまだ学び始めたところだけれど、次回はシステムダイナミクスの使い方について考えてみたい。

2007年7月25日 (水)

System Dynamics(その5)~ビア・ゲーム2~

20070724_sd5_beergame2_1 アメリカは意外とお酒に厳しい。買うときにはほとんどの場合に身分証明証で生年月日を確認されるし、公園や道ばたでアルコールを飲むことは禁じられている。さらには車の後部座席に空き瓶が転がっているだけでも飲酒運転をしたと見なされてしまう。飲むときも楽しい範囲で飲むのが基本なので、日本の感覚でいると問題を起こしかねないので注意が必要だ。

それでもアメリカ人はやっぱりお酒が好きなので、ゲームの名前はビア・ゲーム。
ルール説明に入ろう。
20070724_sd5_beergame2_2
ゲームの目的は、各会社が持つInventory(在庫)を最適化することにある。ビールをストックしておくことでかかる費用は各週の在庫量×$0.5で計算する。なので納入された量だけ売って在庫はなるべく少なくしておきたい。
しかし品切れを起こすと、その分売るチャンスを逃すことになって損失を被る。幸い全てのお客さんが納入を待ってくれるのでBacklog(予約待ち)を抱えることになるが、その費用は予約待ち量×$1.0で計算する。

そして一番重要な制約事項として、各社間でのコミュニケーションは一切取ってはいけない。次にどれだけのビールが納入されるかも、なるべく見てはいけない。

さて、ゲームを進める手順は以下の通りだ。

  1. 各自のInventoryの1マス左側にあるTransport delayのビールを下流側に納入すると同時にInventoryの1マス右側にあるTransport delayのビールを受け取ってInventoryに入れる
    1. 結果、自分の左側のTransport delayだけが空いているはずだ
  2. Incoming Ordersにある注文票に書かれた数と予約待ち分を合わせた数だけ、Inventoryから左側のTransport delayに送る。在庫が足りなければその分をBack logに足しておく。
    1. つまり予約待ちが4ケースあったのに、今週の納入分も合わせた在庫は2ケースしかなく、注文が8ケースだった場合は予約待ちが合計10ケースになる
    2. RetailerはCustomerに送り込む
    3. その週の在庫量、予約待ち量をメモしておく
  3. 使い終わったIncoming Ordersの紙を捨て、Outgoing Ordersに置いてあった先週の注文票を右隣の会社のIncoming Ordersに伏せたまま送り込む
    1. FactoryはOutgoing Ordersに置いてあった注文票に書いていた数だけ、無尽蔵のRaw Materialから隣のTransport delayに送り込む
    2. RetailerはCustomerの位置から購入数が書かれたカードを1枚伏せたまま取って自分のIncoming Ordersの位置に置く
  4. 自社のメンバーだけで相談して(もしくは自分だけで)今週の注文数を新しい注文票に記入してOutgoing ordersの位置伏せてに置く

これを延々と繰り返す。
ただし、最初の5週まではずっと4ケース注文して、4ケース流すと言うことを強制的に行って、それ以降は自由に進める。

お客さんが毎週買いに来る数はあらかじめ設定されているが、途中で大きく増えたと思ったら大きく落ち込み、しばらくするとまた定常に近くもどるのが基本パターンのようだ。そしてゲームはプレイヤーの意表を突いて36週目で終わらせるのも基本のようだ。
終わったら各週の在庫量と予約待ち量から各社の総コストを計算して、全4社の合計コストをそのテーブルの総コストとする。

本当に簡単なゲームなのだけど、実際にやってみると誰もが驚くべき結果が待っていた・・・・・。

写真はSamuel Adamsのミックスパッケージ。6種類の味が楽しめてお得なのだ。
もちろんこの他にも季節限定ビールなどが店頭には並んでいる。

2007年7月24日 (火)

System Dynamics(その4)~ビア・ゲーム~

20070722_1beergame2 実際に自分でやってみることで学ぶ機会が授業中に何度もある。これは間違いなく僕がMITを気に入っている理由の1つだ。
System Dynamicsの授業においてもPeople Expressという航空会社のシミュレーションソフトウェア(非常に良くできていたが、残念ながら商用ソフトウェアなので試してもらうことが出来ない)でバーチャルに経営することで企業を取り巻く環境のダイナミクスを把握することにチャレンジしてみたりと、理論の基礎を学んでなんでも出来そうな気になっていた自分に、その浅さをガツンと思い知らせてくれるからだ。

グループでチャレンジしたビア・ゲームはまさにその典型だった。本来はサプライチェーンマネージメントの問題としてMBAの世界では有名らしいけれどもこのゲームが教えてくれることはその範囲に留まらない。
全体を把握せずに各自が精一杯頭を働かせて最大限の努力をした結果がシステムを破綻させてしまう事を身をもって経験できる。これは良い体験だった。
「うちの会社は優秀な人材が揃っているしみんな頑張ってるのに何故状況が良くならないんだろう?」と考えたことがある人、このゲームを一度試してみることをお勧めする。もっとも解決方法が得られるかどうかは別問題だが。

日本語のサイトでも色々と紹介されてはいるようで、ここでは読み物形式で、ここでは本格的に紹介されているので簡単に説明していこう。

20070722_1beergame_2_3

上の写真にあるボードのとおり、このゲームは4種類の会社が必要なので4人以上でボードを囲み、それぞれFactory(メーカー), Distributor(一次卸し)、Wholesaler(二次卸し)、Retailer(小売店)に分かれる。僕たちは基本8人で2人ずつに分かれたが適当でいい。

次にボードの準備をしよう。

  • Customer(お客さん)の欄には毎週お客さんが買いに来る量が書かれたカード50枚を伏せて置く
  • Incoming Orders(受注伝票)とOutgoing Orders(発注伝票)のマスには各自が取引先に出す注文と、受けた注文とが書いた伝票を置く。最初は全てに4ケースと書かれた紙を伏せて置く
  • Transport Delay(配達中)のマス全てにはビールを表すチップが4つずつ、Inventory(在庫)の三角には12個づつ置く
  • Raw Material(原材料)の箇所にはビールを表すチップを無数に置く
  • Incoming ordersとOutogoing ordersの間には新しい注文票が50枚置いてある。

これで準備完了だ。ルール説明が終わればいよいよ遊べるけれど、その前に一息入れよう。
写真はボストンの地ビールSamuel Adams。バリエーションはもちろんのこと味の種類も豊富なので日本のビールよりも好きかもしれない。

ちなみに「ビールはどこ?」と言って登録していないクラスメートも何人かは授業にやってきたけれど、もちろん授業でビールが振る舞われる事はなかった。

2007年7月22日 (日)

System Dynamics(その3)~Forrester氏が来る~

20070721_sd4 先日の授業に、なんとSystem Dynamicsという学問分野を50年前に確立した張本人、Jay Forrester氏がレクチャーをしに来てくれた。1つの分野を確立した張本人から直接話を聞けるなんて滅多にない機会なので本当に嬉しいことだ。
しかし50年前に分野を確立したと言うことは間違いなくかなりの高齢である。MITの航空宇宙学科には1969年に初めて人類を月に送ったアポロ計画で働いていたエンジニアが当時を振り返ってエンジニアリングとマネージメントを教えてくれる授業があるけれど、それを遙か20年も遡ることになるのだ。

実際、想像通り91歳という高齢だったけれど失礼と言えないほどに明らかに若々しく、120分の授業を立ってやり通した体力は圧巻だった。話の内容も深い洞察に富んだものでなかなか面白かった。後10年は達者で暮らされるであろうし、そう願うばかりだ。

さて、そんな彼がシステムダイナミクスについて語った内容は以下のような事だと自分は理解している。

  • 目の前の状況を改善するために良かれと思ってやったことが回り回って大きなダメージを生むことが往々にしてある。そんな事態を生まないために、取り巻く状況や因果関係の全体像を上手く把握し、どういうアクションを取るべきかを考えることを助けたい
  • 数式では表せない社会現象も論理的にモデル化できる
  • 論理だけでもモデル化できてしまうが故に、論理の飛躍や間違った論理展開を内在してしまう可能性がある
  • モデルのパラメータをチューニングするには実例からデータを集めてくる必要がある
  • コンピュータの発展により、想像だけじゃなく実際にモデルをシミュレーションすることが可能になった。早い段階でシミュレーションを繰り返すことは、安価にいくらでも失敗できる良い機会である。それによって後の失敗を防ぐことに寄与したい

一言で言ってしまえば、「システムダイナミクスという学問とテクニックを知っていればモデル化やシミュレーションが出来る。その一方で、何が正しくて有効かを判断するには実経験が必要である」と言うことになるかもしれない。

それでも物事の全体をとらえてシステマティックに考えるというトレーニングを日頃から積んでおけば、経験を効果的に生かす事もやりやすくなるだろうし、人にも伝え易くなるのではないだろうか。
僕も経験豊富で尊敬すべき人たちのうちに、自分の考えや仕事のやり方を全く説明出来ない人たちを沢山知っている。「どうするかは聞いてわかるもんじゃない、だまって一緒に仕事をすればそのうちわかる」と言う状況は、システムダイナミクスが普及すれば少しは減るかもしれない・・・・というのは期待しすぎ?

写真はForrester氏がシステムダイナミクスという学問を生み出すきっかけになったある企業の在庫管理のダイナミクス。

2007年7月20日 (金)

壁一面が使えるのは便利!

夏学期もようやく折り返しの時期を迎えているので本格的に宿題の内容が重くなってきたと同時に、中間試験の準備にも追われている。みんなからも「1月のブートキャンプのように忙しい~」と悲鳴が聞こえてくるけれど、そんな中で13ヶ月で卒業する数人(気がついたらたったの数人になっていた・・・)は研究も進めているのでかなりの正念場を迎えていると言ってもいいかもしれない。それでも研究は今頑張っておかないと後で辛くなるのであと一ヶ月と思って励まし合って(慰め合って?)何とかやっている。

このブログでもなかなか紹介する機会が持てない卒業研究だけど、少しずつは進んでいて今日はアドバイザー(指導教官)との定期ミーティング。おおよそ順調じゃないの?と言われてちょっと安心しつつもこれからが本番だしまだ明確に考えが纏まる兆しが無い・・・。

さて、下の写真はアドバイザーのオフィスとそこに隣接するミーティングスペース。なんと壁一面がホワイトボードになっていて書き込める。単に表面がコーティングされた壁紙のようなものなので安いだろうし、家には要らないけれど日本に帰ったら職場に欲しいと思ったのは僕だけだろうか?

20070719_kabe1_1

20070719_kabe2

2007年7月18日 (水)

求められる能力と経験

20070717_1 INCOSEのホームページにSEの求人情報が出ている。基本的に欧米の企業が求人情報を出すときには仕事の内容やポスト、職責、求められる資格や経験が細かく定義されているので、転職先を探していない人でもSEとして仕事をしている人や、欧米でSEと呼ばれる人たちの仕事がどういうものか興味がある人は覗いてみることをお勧めする。
僕も以前からJob, System Engineerなどのキーワードでインターネット検索しては読んだりしていたけれども、将来自分がどういう人になっていたいたいかを考えるのに多少は助けになってきたと思っている。もちろんSEだけじゃなくてその他多くの職業に当てはまるはず。

一例として、アメリカの航空宇宙軍事関連の巨大企業Northrop Grumman社の電気系システムのSystem Engineerの求人情報を見てみるとこんな感じだ。

ちょっと簡単に訳してみると・・・・

電波通信システムのコンセプト構築、設計、実装を行う際にチームメンバーに対して全体的なリーダーシップを発揮し、引っ張っていけるSEを募集しています。

その他の職責など

  • 時間とコストの制約に収まるようなシステム設計が可能かどうか、システム要求を分析する
  • システムの仕様を定めて、アーキテクチャーとハードウェア制約、インプット/アウトプットのプロセス、ハードウェア/ファームウェア/ソフトウェアの互換性に関するパラメータを評価する
  • 電波通信システムとモジュールの設計要求を作成し、割り当てる
  • システムとサブシステム設計全体システムの統合と試験をコーディネートする
  • システムレベルおよびモジュールレベルの設計レビューの段取りおよび実行する
  • 電気工学学士号を持ち、軍、宇宙、商用通信のハードウェアとプロトコルに関して9年以上のシステムエンジニアとしての職歴を有すること
  • SLATE(訳注:要求管理ツール)とMATLAB(訳注:汎用解析ツール)の経験があればなお良い

基本要求

  • 電気工学学士号
  • 軍、宇宙、もしくは商用通信分野におけるハードウェアとプロトコルに関して9年以上のシステムエンジニアとしての職歴を有すること
  • トップシークレットセキュリティ資格を有すること(訳注:少なくとも永住権は要るでしょうね)

とまぁシステムエンジニアやるのも簡単ではないことが明確にわかる。もちろん日本でも大変だけれど、このレベルになると給料は日本でエンジニアやるよりよっぽど良いはず。

2007年7月16日 (月)

人生最初の小さな世界

20070715_1 これまでは手に触れたものが何かを確かめるかのように握って遊んだり口に持っていったりしていたのに、ふと気がついたらいつの間にか周りにある見えるもの全てが気になってしょうがないらしく片っ端から手を伸ばしている。今日もお風呂に入れてあげると水面をばしゃばしゃたたいては不思議そうにしているし跳ね返ったお湯が顔にかかると驚いている。広い世界を知っていくその第一歩を踏み出しているのだ。

更に驚いたことに、これまで口に入れれば飲むだけだったほ乳瓶も自分で持って飲めるようになってしまっていた。もちろん気が向いたときしか持たないし、ちゃんと握れないので頻繁に落とすし、底を上げないと飲めない事がわかっていないので振り回したりしているけれど正直に言って唖然としてしまった。

当の本人もどうやら急に世界観が広まったことにまだしっくり来ないのか戸惑っているのか、夜の眠りが浅かったりちょっとしたことで泣き出したりと神経質になっているようだ。

この一週間は、朝から学校に行って夜8~10時過ぎに帰ってきては夜中まで宿題や勉強、という生活が続いていたので出来ても娘をお風呂に入れてあげるくら いだった。どうやらその間に1つ壁を越えてしまったようだ。不思議なもので何事も1つ1つ徐々に出来るようになるとはいえ、その成長が内に秘められてい る時期と一度に外に出てくる時期がある事に気づかされる。

「子供を持つとなぁ、生命ってものが何かを理解できるんだよ」と言っていたクラスメートの言葉は本当だと思うけれど、これがもう2ヶ月もするとそこら中をはい回って手当たり次第にあらゆるものを引っかき回すと考えると楽しみとはいえちょっと恐ろしくなる。

それも生命ってやつの定めか。

2007年7月15日 (日)

System Dynamics(その2) ~ミシシッピ川~

20070714_0 アメリカ最長を誇るミシシッピ川は度重なる洪水によって1700年代初めから流域住民を苦しめていた。当然の事ながら住民や地方自治体は「水が来る高さよりも高い堤防を各施設や河川敷に作る」ことで洪水に対応し始めていた。
もちろん各自治体は自分たちの領域しか整備しないので、片側の岸しか堤防が建設されないこともあったし、両岸に建設されたとしてもその州の範囲のみであることが当たり前だったようだ。
1840年代には平均的に2m近くの堤防が建てられたが、それでも洪水は度々起こったため連邦政府はミシシッピ流域対策の予算を組み各州に配分した。そのため各州は競って高い堤防を建設した。何故かというと川は堤防の一番低いところから溢れて堤防を決壊させる。どこも自分の住む地域が洪水の被害を被るのは嫌なのだ。

その結果、20世紀始めには堤防の高さは5mを超え、1950年代にはなんと9mに至り堤防の長さは万里の長城をしのぐ長さにまでなったらしい。そして洪水の規模はどんどん大きくなっていった。なぜなら堤防の高さが高くなり、川が沢山の水を蓄えられるようになったために、一度決壊してしまえばその分大量の水が流れ込むからだ。
川と堤防の整備が進むたびに政府は安全宣言を出してきたがその期待がことごとく裏切られたこともこの高さ競争に拍車をかけたのかもしれない。

これはもうすでに「洪水をどうやって防ぐか」ではなくて「どれだけ高い堤防を築いて自分のところで洪水を起こさないようにするか」という競争に他ならない。残念ながら1800年代の「洪水を防ぐためには堤防を作ればよい」という考えから脱却できなかった。やっと1993年の洪水を機に堤防建築競争はやめて、どこに水を逃がすかが考えられている。

20070714_1 この悲しい意志決定の歴史をシステムダイナミクスのモデルで極単純に表すとこうなる。システムダイナミクスは単に数学的なモデルを組むだけではなく、こういった社会現象もモデル化できる。

ちなみに使っているツールはVenSimという教育用であればフリーのツールだ。英語だけれど日本語入力は問題なくできるのでちょっと使ってみるにはちょうどいい。

2007年7月14日 (土)

System Dynamics(その1)

20070713_0 ある問題を解決しようとして取った行動が予期せぬ副作用を起こして全てを失敗させる事は珍しくない。その頻度は世の中が複雑になるにつれて増していると言えるだろう。それでもその失敗の原因は複雑なシステムの大局を見失い、一面的にしか物事を見なかった事に起因する事が少なくない。つまり、一見すると問題は細部に宿っているように見えて、一歩引いて大局的な目で見てみると全体のバランスやロジックを見失っていたためにおかしくなって一部で問題が顕在化しただけだったりするということだ。そういった場合にはいくら問題が起きた箇所を直したところで、また問題が大きくなって返ってきたり他のところに問題が起きることになる。

システムダイナミクスの狙いは、システムに含まれる現象の因果関係を明らかにしてモデル化することで、全体を俯瞰的に理解しようというものだ。そうるすことで、システムの全体構造を理解した上で意志決定ができると考えられている。もちろんモデルを組み立てた後は数値シミュレーションを実行することも可能だけれども、それにこだわらず、あくまで論理的にシステムの仕組みやダイナミクスを理解するために使える事が一番の魅力だと考えてもらっていいだろう。
なにせ起源はある企業が抱えていた、需要に対する生産体制の変更や在庫管理がうまくいかない問題を解決するために考えられたもので、MITではSloan ビジネススクールの授業として提供されている。写真にある教科書の題名もBusiness Dynamics -Systems Thinking and Modeling for a Complex World-なのだ。
そして一番驚いたのは、アメリカでは広い視野を持った人材を育てるために、The Creative Learning Exchangeという団体が設立されていて、なんと幼稚園や小学校からシステムダイナミクスを授業に取り入れているということだ。個人的にはすごく良いことだと思うので日本の教育現場でも取り入れてみてもいいんじゃないかと思う。
日本では全く知らなかった学問分野だけれど、産業への適用はともかく一定規模の研究は行われているようだ。

さて、そのシステムダイナミクスを説明する最も簡単な例の1つとして、人口の増減を考えてみよう。
最もシンプルに考えると人口が多くなれば生まれる人は増え、さらに人口は増える。逆に人口が減ると出生数も減り更に人口が減る。つまり物事の流れが強化される(Reinforcing)。
一方で、人口が増えると死ぬ人も増えて人口増加を抑える。人口が減ると死ぬ人が減って人口の減り方は穏やかになる。こちらはバランスが取られる(Balancing)。
20070713_1
これをシステムダイナミクスの基本”Causal Loop Diagram”と呼ばれるモデルで表したのが上の図だ。原因と結果は矢印で、その関係は+と-で表される。そして人口変化を加速させるループR(Reinforcing)と変化を抑えるB(Balancing)で表される。
20070713_2_1
さらにこれを”Stock & Flow Diagram”という図に変換すると上の図のようになる。人口が貯まる(Stock)のに反応して、出生数や死亡数が変化する。これは栓を抜いたバスタブにお湯を注ぐ状況を考えてもらえばいいだろう。

もちろん人口が増減する理由はそんなに単純ではない。国や地域、時代によって様々な要因が複雑に絡み合ってくる。それでも人口が増減する根本的な理由は人が生まれ、人が死ぬことだ。そこを押さえた上でその理由を順次論理的に発展させていく事が出来る。そういう意味でこのモデルからスタートすることは無意味どころか非常に大事だと思う。

2007年7月13日 (金)

ものづくり ~イノベーション~

20070712_1_1 イノベーションという言葉を日本でもよく聞くようになった。これはアメリカがものづくりでの競争力を弱くしてからは特許などの知的財産権で儲ける仕組みを世界中に広めることに成功したからだろうか、それともライフサイクルが極端に短くなっている製造業やサービス業で一番重要なのは「イノベーション」なのだと皆が思い始めたからなのだろうか。

日本語では技術革新と訳される言葉だけれどそれだけでは半分しか説明できない。もちろん技術革新は重要だし世の中の優れた製品が誕生することに貢献していることは間違いない。それでもそれが花開くためには、特に既存の技術を有効に組み合わせてシステムとしてバランスの取れたものが作り出せたかどうかが非常に重要だ。イノベーションと言う言葉はこの両者が合わさった状態を表しているのだというのが僕の考えだ。

そして、技術革新や新しいアイデアというものはどこから沸いてくるかというと、ものづくりの経験が重要な役目を果たしているんじゃないかと思う。アメリカは技術開発、設計、製造は分けられるものであって自分たちは技術開発や設計に注力して(設計も外注する事がある)製造はアジアの企業に外注して安く済ませればいいと考える傾向があって分業体制が進みつつある。だけど製品が複雑であればあるほど、それは真似しない方がいいんじゃないかと思うのだけれどどうなんだろうか。

もちろん日本でも人材流動が活発になって、研究から製造まで多くの人が渡り歩くというのなら別だけれども、研究、設計、製造の三者が密に交流すること無しに新しいことは生まれてこないと思う。

そしてどうやらアメリカではこれが典型的な日本人の考え方だと思われているらしいので、それをわかった上でのことなんだろうけれど。

さて、最後に面白い動画を見つけたので紹介しよう。古代に「本」が発明されてそれを始めて手にした人がどう使っていいかわからず戸惑うコメディなのだが、あまりに革新的なものが出回ったときには、いつの世でもこういう反応が繰り返されるのだろう。音声はノルウェー語、字幕は英語だけど、身振り手振りだけで大体わかるはず。リンクはこちら

2007年7月12日 (木)

ものづくり ~Pugh Matrix~

200705000_1pughmatrix 前回紹介したように、いくつかの設計案が出てきたときにはどうやって最も良い案を選べばよいのだろうか。
定量的に順位をつける、すなわち点数をつける方法がいくつかある。基本的にはどの手法も、評価基準を並べてそれぞれを重要度×評価点数の合計で評価すると言っていいだろう。
AHPと呼ばれる手法も有名だけど、比較的Web上の日本語情報が充実していそうなので、今回はPugh Matrix(ピュー・マトリックス)と言う手法を紹介する。英語であれば情報が充実しているので興味のある方はそちらも参考にして欲しい。

さて、Puth MatrixはStuart Pughという人が1980年代に考案した方法で実行手順は次の通りだ。

  1. 評価基準となる重要な要求やニーズを並べ出す。多くても30~40個に絞る。数値化できないものでも良いが各項目が同じ程度の重要度であればなお良い。
  2. 市場に競合製品や比較できる製品で最も重要な製品を比較対象として選び出す。市場に無ければ設計案のうちから1つ基準となるものを選ぶ。
  3. 各設計案に対して、それぞれの評価基準が比較対象と比べたときに、優れている(+)、同程度(0)、劣っている(-)の三段階で評価する。
  4. +,0,-の合計を各設計案で集計して、比較対象よりも悪いスコアのものを削除する。写真のようなマトリックスができあがることになる。このマトリックスは僕のチームが実際に授業中に作ったものだ。
  5. 残った案のうち、複数の案の要素を組み合わせることで良いスコアになると思われればそれに従って再度設計を行う。
  6. 候補案が出そろったら1~5を繰り返して絞り込んでいく

なぜどれだけ優れて(劣って)いるかを数値で表さずに+,0,-で表すのだろうか。それは人間が二つを比較して優劣をつけることには優れていても、絶対的にどれだけ優れているかを評価するのは苦手としているからだ。それに性能のように数値で示せるものでも、3倍になったら価値が単純に3倍になるとは限らない。

そして一番気をつけて欲しいことは、この手法を繰り返して使って候補を絞り込んでいくときには最終的に1つを選び出すのではなくて、その手前の3~4候補残ったところで終了させることが最適と考えられていることだ。

実際にやってみるとわかることだけれど、この手法を使ってスコアを出したときに例えば+,0,-がそれぞれ8個,2個,3個の候補と6個,6個、1個の候補ではどちらが優れているか判断できるだろうか?よしんば7個,5個,1個だったとして果たしてその+1個の違いで優劣を決められるだろうか。そもそもスコアをつける基準とした要求はそれぞれ同じ重要度だろうか?

もちろんPugh Matrixの発展型として、それぞれの要求項目に0.0~1.0の範囲で重み付けをする手法もあるけれども、その重み付けは信頼できるだろうか?
クラスメートのほとんどがこれらの問いに対してNo!と言うに至ったことからもおおかた間違いではないと思う。

それではPugh Matrixを始めとした数値評価方法は何のためにあるかというと、僕は大きく分けて3つあると考えている。

  • 劣った案を切り捨て、選択肢を大幅に絞る
  • 何を重要視して何を無視するかの考え方、それぞれの案に対する認識を目に見える形でチーム内で共有する
  • 新しい組み合わせの発見を助ける

逆に危険な使い方として考えるのは次の通り

  • 意志決定を形式的に済ませる
    • 点数はあくまで参考なので算数で最適なシステムは決まらない
    • 点数付けや重み付けが本当に正しいか評価しにくい
  • 評価選択のプロセスを完全にコントロールする
    • 厳密な論理を持たないので、逆に感情的で非論理的な想像力を刺激する
  • トレードオフ
    • 単純に向いていない

ここまで読んでくれた人なら想像が付くと思うけれど、AHPなどの他の手法も大体同じようなものだと考えられている。点数による評価結果を意志決定の理由として使うことは欧米でも珍しくないけれども、クラスメートが所属する企業で使っているところの実態を聞くと(大体は航空宇宙防衛産業だ)あくまで表向きに都合良く説明できる形式的なものに過ぎないと認識しているようだ。

その代わりに、各自の考えを数字という比べられる形で表すことで議論を加速してより良い案を導き出すと共に、最終的には意志決定者がプロジェクトをどの方向に向けるか、何を重要視して何のリスクを背負う覚悟をするか、そうやって論理的に判断するしかないのが現状のようだ。

さて、皆さんの感想はどうだろうか。

2007年7月11日 (水)

ものづくり ~正解はありません~

20070710_1 世の中で起こる問題には複雑であればあるほど「誰にとってもこれこそが正解!」という唯一の解が存在しないことが多い。これは「こちらを立てればあちらが立たず」というトレードオフの関係にある要素が絡み合っているせいで、何をどれだけ重要視するかによって最適解が変わってくるからだ。

一見当たり前のように思えることだけど、受験勉強の弊害なのか日本で受ける講習やトレーニングでも「答えは何なんでしょうか?」とか「模範解答が知りたい」という声を良く耳にする。1つの基準値を最大にするためにパラメータを変えるだけで解決してしまう問題を解くことを続けるならばそれでもいいけれど、実際は世の中はどんどん未知のものが出てくるし、状況の変化に伴って初めて目にする問題に取り組まなくてはならない事ばかりだ。そういう中で本当に大事なのは、どういう解答が正解かを覚えるよりも、どういう理論と道筋をたどってその答えにたどり着いたか、それが上手く機能することがどう説明できるかといった能力、対応力ではないだろうか。
僕がMITでSEを学んでいる最大の目的は、システム開発においてエンジニアリングに関する様々な問題や課題が出てきたときにどうやってチームで解決に導くか、その考え方と進め方を少しでも身につけることだと思っている。更に言うと形式的だったり漠然としていてよくわからないと言われがちなSEの理論と実践をつなぐ事が少しでも出来ればと思っている。

さて、話をものづくりに戻そう。何かを設計していて最適解を探しているとどんどんトレードオフの対象が増えてきて、解決策の候補のバリエーションが無数に増える。ここで経験豊富なエンジニアであれば、知識や経験に基づいて何を変えればどこにどういう影響が出るか、今の時点ではどのポイントを押さえることが重要かを知っているので、見込みが無いと思われる候補をバシバシと切って最終候補を絞り込んでいく。
経験がなければどうするか。時間をかけて詳細に解析してみたりシミュレーションしてみるしかない。逆説的なようだけれども、経験がないエンジニアほど答えを出すのに詳細な解析を必要とする事が多いのだ。

こうして設計を進めていくと、いくつかの候補が形を成してくる。特にシステム設計とか概念設計と呼ばれるプロジェクトの極初期には様々なアイデアが浮かんでくるものだ。
それでもそれらの候補は最終的には1つの案に絞り込む必要がある。新型新幹線みたいに最後まで2,3残す事もあるけれど、普通は開発が進むと共に意志決定をしていかなければならない。

じゃぁその意志決定はどうすればいいのだろうか。経験?数値?カン?

写真は少し見にくいけどApollo宇宙船の代替案で没になったシリーズだ。

2007年7月 9日 (月)

ものづくり ~設計と才能~

20070708_1 要求や仕様が一意に決まったとしてもそれを実現するための方法は無限にある。そして設計、製造する側の能力よって性能や使い勝手などに大きく差が出てくることになる。

残念ながらSEや、設計論をどれだけ勉強しても良いシステムを設計する能力を身につけることはできない。ソフトウェアにせよハードウェアにせよ実際にものを作った経験がものをいうことは紛れもない事実なのだ。もちろん市販品と同じレベルで携帯電話やロケットを一人で作ってしまうのは不可能なので、小規模でもいいから実際に設計、製造、試験、運用してみれば良い。そのときにどういう事に気をつけなくてはならなくて、どういう問題がどの時点で起こるかをシステムを含めた各分野で少しでも感覚として理解していることが大きな助けとなる。

さらに面白いのは仕事上の物作りの経験だけでなく、幼少の頃からの物作りの経験もその人がどれだけ優れたシステムエンジニアになるかに大きく影響しているというMITによる調査結果もあって、個人的には少しは当たっているんじゃないかと思っている。

実はアメリカでもどうやったら良いシステムエンジニアを育てられるかと言うことはずっと議論の的になっているのだけど、まだまだ身をもって学ぶしかないと考えられているし、芸術と同じように、すばらしいシステムエンジニアには才能が備わっていただけだと考える人も多かったりする。

才能が寄与することは認めざるを得ないとしても、努力と経験によってかなりのレベルまでは到達できるんじゃないかと思う。問題は歳を取ると共に徐々に自分で手を動かしてものを作る経験がしづらくなる事だと最近実感し始めている。

 

余談だけれど、僕は物心付いたときからLEGOが大好きだ。それが最近のLEGOはハリポタやらスターウォーズやら最初から何ができあがるかわかっているシリーズが多くて面白くない。日本に帰って娘がもう少し大きくなったら僕が大昔に使っていた赤バケツをはじめとするベーシックなLEGOをプレゼントしようと思っている。
やはり自分で作りたいものを考えて、多少は不細工でも作りたいように作れる、あの無限の可能性を秘めたLEGOが好きだし、それでこそものを作る楽しみがわかるものだと思うのだけど、時代に合わなくなってきているのだろうか。

2007年7月 6日 (金)

iPhone

20070705_1 持ってみると見た目以上にずっしりと重かった。そして画質と操作感がすごくいいというのが触ってみた最初の印象だった。クラスメートのうち誰かは買うだろうなと思っていたら、ある授業でチームを組んでいる一人が初日に買ってきたのでさっそく触らせてもらったのだ。iPhoneがどんな電話かについては日本のメディアでもかなり詳しく報道されているので割愛するけれど、単にiPod+PDA+電話というものではなくて、はっきり言って触っているだけで楽しい。

授業の合間の休み時間には他のクラスメートもよってたかって触っている。「お、お前iPhoneから電話受けてるやん、いいなあ。」と言われたけど、それは絶対興奮しすぎでiPhoneに呑まれている。受ける側には何のメリットもない事だけは断言できる。

さて、僕は以前からPDAを愛用していて、以前はiPhoneに似ているとも言えないこともないシャープのZaurus A300を利用していたところ、ネットワーク機能が欲しくなってiPhoneの隣に写っているSL-C760を会社の先輩から無期限で借りている。OSがLinuxと言うことでネット上で沢山フリーウェアが見つかるのでかなり気に入って使ってはいるけれど、発売から4年経っていることとPDA市場自体が携帯や小型PCに押されてもはや死に体なだけあって徐々に使い勝手が悪くなってきているので、iPhoneと比べると否が応でも時の流れを感じさせられる。

iPhoneのソフトウェアキーボードはバスケットボールが持てるくらい大きな僕の手でもタイプしやすいし、YouTubeもすごく綺麗な画質で見られるし、Google MapにGPSナビが付いているし、カメラも思った以上に良く写るし、インターネットもWiFi接続でさくさく使える。

思わず欲しくなってしまったけれど、電話回線の契約をしないと使えないし、日本語入力出来ないし、APIが公開されていないのでiTunesで買う以外ソフトウェアを増やせないし、バッテリがへたってきたら郵送しないと交換してくれないし冷静に考えるとやっぱり買わないなと思ったのでした。

日本では携帯キャリアとの交渉に手間取るはずなのでしばらく発売される見込みはないと思うけれど(とある授業では日本ほど”邪悪な”通信市場はないと酷評されていたし)シャープならA300とAQUOS携帯を元に多少ユーザーインターフェースはおおめに見ても、いいもの作れると思うんだけどなぁ・・・・無理か。

2007年7月 5日 (木)

Matsuzaka応援

20070704_1 昨日は久々に童心に返って楽しい時間を過ごすことが出来た。
仲の良いクラスメートに誘われて2人で松坂投手が登板した昨日(既に一昨日か)のRed Soxのゲームを観戦してきたのだ。既にブローカーや個人売買でもなければチケットを入手することは難しいのだけれど、アメリカ軍が立ち見席を毎試合100~200席くらい押さえているとのことで空軍所属の彼が持つ特権のご相伴にあずかったのだ。しかし立ち見席といえども$7は破格だ。収容人数が38,000人と非常に少ないこのFenway Parkは最も安い席でも$45するらしいし、なんと言ってもビール1杯と同じ値段なのだからうらやましい。

もちろん立ち見席券と言っても初めからおとなしく最後部に立っているわけもなく、いい席に座ってその席の観客が来るまで(なんと6回まで来なかった)ちゃっかりと2人で近くから観戦。ここの球場は観客席とグラウンドとの高さが非常に近いので臨場感があって非常に楽しい。周りと同じく2人でRed Soxの選手や日米の野球について語りながら本気になって応援してしまった。

日本の観客と雰囲気が違うと思ったのは老若男女を問わず選手のTシャツやユニフォームを着ている人が多いこと。Red Soxは阪神タイガースのように熱狂的なファンが多いことで有名な球団だけれど、それを差し引いてもおじいちゃんやおばあちゃんまで選手のTシャツを着て試合の最後まで声を出して応援している姿を見ると、本当に野球が好きでチームを応援しにきている感じが伝わってくる。松坂選手を見に来ている日本人も沢山いるのだけれど、18番のTシャツを着ている人たちの半分以上は日本人じゃないだろうという人たちで、特にちびっ子達が小さな18番シャツを着ていたりすると、彼もしっかりとRed Soxのファンから受け入れられているのだなと思って、訳もなく嬉しくなってしまった。

試合自体は、松坂投手は応援しがいが無いくらい調子が良くて8回を3塁さえ踏ませずに無失点で抑えてしまった。ピンチになったら甲子園の阪神戦の観客ばりに(笑)声でもかけようかと思っていたけれどそのチャンスさえ無し。相手チームが最下位のタンパベイだからとはいえさすが。唯一のピンチは岩村選手に2塁打を打たれたときくらい。
実は来月には家族でデイゲームを見に行く機会があるのだけれどそれも相手はタンパベイ。今度も松坂投手が見られる可能性は低いけれど、岡島投手が投げてチームが快勝してくれることを期待している。

2007年7月 3日 (火)

ものづくり ~ニーズ再考~

20070702 前回、前々回と、対象にしたマーケットセグメントにニーズがある事を前提として話を進めてきたけれど、以前First Mover Advantageの記事で紹介したように、製品が市場に出回って初めてニーズが生まれてくる場合もある。例えばコピー機やi-modeのように「そんなもん誰が使うんだ?」と言われながら大ヒットになった製品は枚挙にいとまがない。これは使う側の行動パターン自体を変えることが出来るだけのメリットがあってこそなので、そう簡単に出てくるケースではない。

また、これまでにマーケットになかった製品は必ず予想だにされなかった使い方をされるからニーズを明らかにするのは不可能だという話を聞くこともある。もちろんそれは正しい。しかしプロジェクトの主要な目的となるニーズを特定せずにスタートすることになると失敗の確率が非常に高い。何より開発する側が何をプロジェクトのゴールに設定して良いかわからなくなり、出来るだけ良くしたいとの思いから、幻を追いかけるがごとく、いつまで経っても開発が終わらないという可能性もある。そのリスクを負ってでもプロジェクトをまとめ上げて世の中に問うてみる価値があるというならばそれも良いだろう。ただし全く売れなかったり、ニーズが出てくるまで長期でじっと耐えなければならない覚悟が必要だ。

最後に、まったく世の中に存在しないサービスを新たに立ち上げようと言うとき、つまり競合他社がいない場合にはチャンスであると同時に非常に危険であることを覚えておかなくてはならない。今まで誰も本当に思いつかなかったのか、それとも既に誰かが失敗しているのか、とても成り立たないと放棄されている市場なのか、よくよく調べた方が身のためである。

と、さんざんニーズを知ることが大事であるかのように書いてきたけれども、ニーズに応えてばかりいると長期的に失敗する可能性もあることは確かだ。これはS-Curveの記事で紹介したのでそちらを参考にして欲しい。今まで顧客の欲しいと言っていたものを提供し続けていたはずなのに、新しい技術が台頭して、これまで顧客が満足していた製品のシェアを見事に奪っていくのが世の常だ。

要するに、顕在化しているニーズをがっちりとらえて素早くいいものを提供する活動と、過半数は失敗しても良いから将来を見据えてニーズを先取りするための活動の違いをしっかり認識して、自分たちが今何をどういう戦略の元にやっているのかを把握しておかなければならない。それによって何をいつまでにやらなくてはいけないか、どういう技術、どれくらいのコストとリソースがどのタイミングで必要になるかが変わってくる。

戦略、戦略、戦略、そしてタイミング、タイミング、タイミング。

2007年7月 2日 (月)

ものづくり ~ニーズ、要求、仕様~

20070701_1 ニーズ、要求、仕様、どれもビジネスの世界で良く聞く単語だけどそれぞれどういう意味を持っていてどう違うのだろうか。これには産業や対象製品によって独自の定義が沢山あるので万能の解は無いけれども、僕がシステムズ・エンジニアリングを学んで来た中で次のように理解している。

ニーズはお客さんやユーザーが、製品やサービスに対して何を期待しているか、または何をして欲しいかを表現したものだ。非定量的で抽象的な表現が含まれるかもしれないし実現可能かどうかもわからない場合がある。

要求は要件と呼ばれる場合もあるけれども、そのプロジェクトや製品に対して求められる事であって、あらゆるステイクホルダーから出てくる。システムやサブシステム、コンポーネント、それらあらゆる階層に存在するものについての機能、性能、構成品、試験、運搬、運用、廃棄、法律、特許、安全、経営、コスト、他製品との共通性、・・・誰が何に求めるかで数限りなく分類される。このうちニーズを元にユーザーが製品に求めることとして定められるのがユーザー要求だ。航空宇宙の世界ではミッション要求と言われる事も多い。
ユーザー要求がニーズと大きく違うのは「検証可能でなければいけない」ことだ。なぜならニーズは「こういう事がしたい」という希望にすぎないのに対して要求は履行することが求められるからだ。従ってこういう例は要求と言えない。4つの文中に少なくとも5つの問題点があることがおわかりいただけるだろうか。

  • いかなる場合でも安全が確保されること
  • できるだけ最大加速度を低くすること
  • 十分に長い時間静止できること
  • 不快感を与えない外観であること

最後に仕様というのは、製品を開発して顧客に受け渡すときに満たしていなければならない条件だ。往々にして要求と重複する事が多く観点の違いだけだと考えられている事もあるし、そういう場合も多いと思う。

さて、前回の記事で把握したニーズを元に、どうやってユーザー要求に発展させていけばいいだろうか。1つの方法としては、まずニーズをどれだけ満足させられるかを評価するパラメータを見つける。そしてそのパラメータがどれくらいの値や程度であれば満足&許容されるかどうかをユーザーと交渉して取り決めることで定めることが出来る。

そしてくどいようだけれども、ユーザー要求は基本的に「こういう事を実現して欲しい」という書き方がされるものであって、開発する側が部品のサプライヤーでもない限り「こういう方式のこれが欲しい」といった手段を書くことは少ない。なぜならばユーザーからするとニーズを満たして欲しいわけであって、製品はそのための手段にすぎないからだ。最初にこれが最良の手段だと思いこんで決めてしまうことは、そのときに想像していなかったもっと良い手段をみすみす捨ててしまうことになる。

簡単なことのようだけれど、ユーザー要求として実現手段が書かれていることが意外と珍しくないことも事実なのだ。そういう場合には「なぜ?」という問うべきで、「自社製品使いたいから」という答えが返ってくるのはまだ良くて(制約条件として扱えるから)、全く答えられなかったり「これが一番いい方法でしょ?」という答えが返ってくるともう一度原点に戻って再考する余地があるといって間違いないだろう。

5ヶ月

20070701_2 今日から7月が始まった。ということで娘も生後満5ヶ月。4ヶ月検診の時に打った予防接種で少し熱が出たことと、一度血便が出た(この時期の乳児には良くあることらしく何とも無かった)以外は全くけがも病気もせずにすくすくと元気に育っている。体重8.0kg、身長67cm。

4ヶ月を1週間過ぎるか過ぎないかの頃に、右肩支点で仰向けから腹ばいへの寝返りを覚えてからは腹ばいで遊ぶのが好きなようで、寝かせるたびに寝返りを打っている。そのくせ仰向けに戻れないので昼夜を問わず飽きると泣いて妻を困らせている。最近は逆方向の寝返りを覚えるそぶりがないのに、腹ばいでおしりを上げてずりずりと前進しかねない動きを見せているので寝返りを完全にマスターする前にハイハイしそうな勢いだ。

おもちゃにもすごく興味を示していて、新しいおもちゃを買ってあげたときの嬉しそうな顔は忘れられない。そして両手でつかんでは手当たり次第に口に持って行く。

周りにある色々なものに対する認識能力もすごく上がっていて成長っぷりに目を見張ると共に、ごまかしにくくなっていて困ったものだ。

とまぁそんな風に周りの全てを一生懸命感じて泣いて笑って離乳食も頑張って食べて必死で寝返りしておもちゃと格闘するかのごとく果敢に口に運んでいる娘を見ていると、子供は楽でいいなぁと思っていた感覚が変わっていることに気づかされる。
あと半年、日本に帰るまでに娘に負けないよう自分も頑張らねば。

2007年7月 1日 (日)

ものづくり ~Customer Needs~

20070630_10_1

誰も欲しがらないものを作っても仕方がないので、多くの場合はまず選んだマーケットセグメントのお客さんが何を欲しがっているかを把握することから始まる。これはすごくおおざっぱに言って次の手順で進められる。

  1. 現在の顧客やターゲットとする仮想の顧客から生の意見を集める
  2. 集めた意見からニーズを汲み取る
  3. ニーズを主要なものと副次的なものに分け、必要に応じて分類する
  4. ニーズ間の相対的な重要度を決める(ランク付けする)
  5. 全体的に矛盾がないか、抜けや漏れがないかを確認する

まず初めの生の意見を集める方法としては、直接買ってくれそうな対象へのインタビュー、5~10人程度を集めてのディスカッション形式のフォーカスグループがある。企業によっては不特定の大衆に対して大規模に行う事になるだろう。さらには、ヘビーユーザーや参考になりそうなサービスが既に存在する他分野のユーザーを選んでインタビューやフォーカスグループの手法を使う「リードユーザー」と呼ばれる方法がある。
このときに大事なのは「どういう製品が欲しいか」つまりソリューションを聞き出すのが目的ではないと言うことだ。人のサガとしてすぐに具体的なモノに飛びついてしまう傾向があるけれど、この段階でそれが最善のソリューションであることを誰が保証できるだろうか。大事なのは、誰が何に困っているか、潜在的なことも含めてどこに問題があるのか、既存の製品の何に不満を持っているか、どういう事が実現できれば嬉しいか、そういった事を把握する事が必要なのだ。そのためにはユーザーがどういう仕事の進め方をしているか、既存の製品がどう使われていて、何が原因で売れている製品と売れていない製品が分かれているかなどを調べることでユーザーへ正しい質問が出来る可能性がぐっと上がる。

そうやって集めた声は貴重なデータだ。しかし、曖昧な表現や重複も多数含まれているはずだ。なのでそれを簡潔な表現に直し、整理する必要がある。そうすることで具体的にユーザーが何を求めているかがわかりやすくなる。ただしここでも上と同じように、「何をしたいと求めているか」を知りたいのであって「こういう解決策が欲しい」と言う表現はなるべく避けなければいけない。

そしてそれらのニーズを分類、ランク付けをする。分類するに当たっての方法は色々あるけれど、授業では名前こそ出なかったけれど、KJ法が便利だと教えられている。自分は仕事でも使っているのだが本当に便利だと思う。
ランク付けについては初めから完全に出来るわけはないけれど、不完全だとしても設計が進むにつれて繰り返し見直されるはずなのであまり気張らなくても良い。ただしどれだけ明確に分類やランク付けが出来ているかはプロジェクトの中で何が大事であるかがどれだけわかっているかを教えてくれる。つまり方向性がどれだけはっきりと見据えられているかを反映している。

この後はユーザー要求、製品への仕様制定へと続いていく。

« 2007年6月 | トップページ | 2007年8月 »