<   2013年 12月 ( 5 )   > この月の画像一覧

「プロジェクト&プログラム・アナリシス研究部会」(2014/01/16) 開催のお知らせ


と、いうわけで(?)、PM教育について、研究部会でお話することにしました。一方的な講演というよりも、双方向的な討議の場にしたいと考えています。この問題に関心のある方のご参加をお待ちしております。

ちなみに「プロジェクト&プログラム・アナリシス研究部会」 は、小生が主査を務めるオープンな研究会です。スケジューリング学会の下に位置していますが、学会員でなくても、どなたでも自由に参加できます。

以下の要領にて2014年第1回会合を開催いたします。新年のご多忙な折とは思いますが、ぜひよろしくご参加ください。

<記>
日時:2014年1月16日(木)19:00-20:30

場所:慶應義塾大学 三田キャンパス・北館・会議室2
 http://www.keio.ac.jp/ja/access/mita.html
※キャンパスマップの【1】になります

テーマ:  「プロジェクト・マネジメントの教育について」

講師:佐藤知一 (日揮株式会社) 

内容:プロジェクト・マネジメントの教育はどうあるべきか。過去5年間にわたり、大学・大学院・自社・他企業などで試行し実践してきた教育カリキュラムの内容を概観するとともに、その課題について討議したい。 

参加費用:無料。
ちなみに本研究部会員がスケジューリング学会に新たに参加される場合、学会の入会金(¥1,000)は免除されます。

参加を希望される方は、確認のためできましたら当日までに佐藤までご連絡ください。

                         以上
by Tomoichi_Sato | 2013-12-24 12:54 | ビジネス | Comments(0)

クリスマス・メッセージ:折れない心をもつために

Merry Christmas!

5年前から、大学でプロジェクト・マネジメントを教えるようになった。今年の前期は東大の大学院で、また後期は法政の学部3年生に教えてきた。それ以外にも、単発的に依頼されて話した事もある。個別のエピソードについては、すでに何度か書いたと思う。しかし全体として、何をどんな風に教えるべきか、いつも悩ましい。

悩む最大の理由は、大学生・院生が実務の経験をほとんど持たない事だ。共同で事に当たることがなければ、プロジェクト・マネジメントの必要性がピンと来ない。また、授業で例題を考えるにしても、ビジネスに関わるケースを採り上げづらい。だからいきおい、「たとえば、あなたが同期30人の集まるパーティの幹事になったとしよう」といった例になってしまう。

それでも、講義を数回聴いた学生は、しだいにその意義が分かる者が出てくる。アンケート用紙にも、「もっと早くからこういう話が聞きたかった」「一年生の時にプロジェクト・マネジメントを勉強していたら、サークル活動であんなに苦労せずにすんだのに」といった感想が並ぶようになる。たしかに、大学ではマネジメント系の講義が(とくに理工系では)ほとんど無いので、新鮮に思えるのだろう。わたし自身、“自分も工学部出だが、みなさんに教えている内容は、すべて社会人になってから勉強したことばかりだ”と伝える事にしている。“だからこそ、こうした授業を大学のうちにしておくことが大切だと信じて、講師を引き受けているのです”とも。

それにしても、5年前につくった授業の資料と現在を比べてみると、自分でも気づく事がある。わたしは次第に、知識を教えなくなっているのだ。プロジェクト・マネジメントの分野では、必須の基本的概念や知識がある。スコープとかWBSとか、PERT/CPM、EVMSといった手法論である。今でも一通りは、教えている。だが、それに関連する詳しい知識、たとえばStart-to-startはどういうとき使うかとかCPIとは何かといった話は、講義資料から消えた。

かわりに、学生にはもっと基礎的なスキルを教えるべきと考えるようになった。コミュニケーションだとか、交渉だとか、To Doリストだとか、そういった事柄である。それも、なるべく演習(二人一組やグループ演習)を授業中にとりいれるようにした。演習を入れるのは、学生を寝かせない、余計な私語をさせない、といった消極的な理由もある(じっさい、「ゆとり教育世代」に属する学生達は、興味が無くなると授業中に平気でふつうの声でおしゃべりをはじめる)。だが一番の理由は、『自分で能動的に考える』ようにしてほしいからである。マネジメントの世界では、一般に普遍的「正解」は存在しない。自分の頭で考えるしかない。ところが、すべてを点数化し競争原理で駆り立てようとする現代においては、手っ取り早い「正解」に頼りたがる傾向が強い。それは学生だけでなく教師の側も同様である。正解のある問題を出す方が、試験の採点も楽で効率的だからだ。

先日の授業では、交渉について教えてみた。今年からのはじめての試みである。いうまでもなく、交渉はプロジェクト・マネージャーにとって最重要なスキルの一つだ。ネゴシエーションがうまくいくかどうかで、その後のプロジェクトの成否が左右される状況も珍しくない。いや、プロジェクトに限らず、現実の世の中では、大小様々な問題に関し、公私を問わず、つねに交渉が必要とされる。にもかかわらず、ネゴのやり方というのは、大学はおろか、中学高校でもまず教えない。まるで、わたし達の社会が、交渉上手な人材を求めていないかのようだ。だいたい、どの科目で教えるべきだというのか? 国語か、社会か、英語か、それともまさか道徳か? 大学でやるとして、それは理系の科目なのか文系なのか?

そういう訳なので、わたしはまず交渉の簡単な原則からはじめた。交渉論の本はそれなりに出版されているが、大きく次の3点は共通のようだ:

(1) 交渉の成否の半分以上は、その準備段階で決まる。何が事実か、どこに自分の論拠・武器を求めるか、そして落としどころはどこにするべきか、事前に作戦を熟考せよ。
(2) 交渉はゼロサム・ゲームではなく、相手と共同した問題解決のプロセスだととらえよ。相手が「勝った」と思える交渉こそ、良い交渉なのだ。
(3) 最後まであきらめてはいけない。あきらめた瞬間、そこでGame Overとなる。

これに付随して、交渉の場における戦術、ないし定石がいろいろある。最初に大きく要求して相手の譲歩を引き出すのもよし、逆に小さな要求からはじめて最後に相手の懐に飛び込むのもよし。どちらを使うかは、それこそ相手と状況によるので、「正解」はない。

そして、交渉能力というのは、トレーニングによって向上可能なスキルなのだ。この点を授業では強調した。たしかに生まれつきのセンスがあって、交渉上手な人間もいる。うらやましい限りである。しかし、そうでないわたし達だって、なんとか交渉をして世の中を渡っていかなければならない。そのためには、交渉の理屈も知っておくべし。だが、何より場数が必要である。そのための練習の機会を、授業で与える。

じつは、わたしの勤務先では、若手のプロマネ候補生に対して、交渉の教育を実施している。座学による講義もするが、中心となるのは演習である。ケース事例を与えて事前に準備させ、講師側が顧客役になって交渉の実技演習をするのである。わたしも昨年度までは講師の一員だった。それを簡略化して、大学の授業でもやってみたわけである。クラスを班に分けて、発注者・受注者役に分担させ、互いに交渉させてみた。周囲の学生は、交渉している当事者達をじっと観察させ、良かった点、まずかった点などを指摘させる。それを全部の班に順番にやらせてみた。限られた時間内に、交渉の妥協点にたどり着けた組も、そうでない組もあった。だが、アンケートを見ると、「はじめての体験だがとても勉強になった」「もっとこういう機会を設けて欲しい」などの声が多く、やって良かったと感じてホッとした。そして、交渉の勉強はニーズが高いと再認識した。

ところで、上記の3原則の中で、若い人たちにとって最も重要なのは(3)であろう。どのような事柄であれ、まずはあきらめずに勇気を持って交渉の場に乗ってみること。これは、日本のように高度なタテ社会の秩序の中で育つと、身につけるのがかえって難しい。「何を町人の分際で。控えおろう!」という問答無用の論理が、伝統の中に強く残っている。

しかし、ことが世界の他の国々で、グローバルに何かのビジネスをやろうとなると、まったく別の感覚にぶつかることが多い。それは、Everything is negotiable = “何ごとも交渉可能だ”、との論理である。このセリフは昔、フランス人のプロジェクト・マネージャーからきいた言葉である(彼はフランス社会では何事も交渉次第だ、とわたしに教えてくれた)。そして、それはフランスに限らない。欧米、あるいは地中海世界などを通して、人々が共通にもつ感覚なのだ。

じっさい、旧約聖書の中には、悪徳のはびこるソドムとゴモラの町を滅ぼそうとする神様に対して、アブラハムが「わが主よ、あの町に50人の善人がいたとしても、他の悪人たちの故に町を滅ぼされるのですか?」と問う場面が出てくる。神が「50人いたなら、その彼らのために、町は許してやろう」と答える。するとアブラハムはさらに、「主よ、もし50人に5人足りず、45人しかいなかったら、それでも町を滅ぼされるのですか」と問いかけ、その調子でなんと40人、30人、20人と競り下げ、最後は10人まで神様を譲歩させるのである。

全能の審判主に対してさえ、交渉が可能である。そういう信念が、ここには表れている。そして、旧約はユダヤ教とキリスト教とイスラム教の共通の聖典である。ということは、この逸話を聞いて育った人間が、世界には10億人単位で存在するということだ。それが、わたし達日本人をとりまく世界なのである。

学生達が世の中に出ていったとき、将来は見知らぬ他者とも交渉をしなければならない。そのために『折れない心』をもつことが大事だ。ここで、「折れない」というのは、簡単に交渉で折り合わないとか、すぐ喧嘩別れする、という意味ではない。相手を認めつつ、自分も大切にする心をもつという事である。そのために、しなやかだけれども強い自分を育てなければならない。剛毅な、硬直した精神は、しばしば折れやすい。柔軟だが、折れない心--それを育てるには、どうしたらいいのか。世間がひととき静かで平和な時を迎えるこの季節、少しじっくりと考えてみることにしてみよう。


<関連エントリ>
 →「それは知識ですか、スキルですか、資質ですか?
by Tomoichi_Sato | 2013-12-23 17:27 | プロジェクト・マネジメント | Comments(1)

モジュラー型 vs. インテグラル型--設計のアーキテクチャ再論

3年前に書いたサイトの記事「モジュラーとインテグラル - 製品アーキテクチャーの二つの方法」に、最近、読者の方から質問が寄せられた。良い質問だと思うので、ここでとりあげ、あらためて自分の考え方をご説明したい。

ご質問は、つぎのとおりだ(やや長いが、全部引用させていただく):

「車がインテグラル型アーキテクチャということは多方面で言われていることなのですが、すんなり納得ができません。

確かに、ボディ形状は独自設計ではありますが、ヘッドライトは他車種でも移植可能なものもありますし、内部のランプ単体については明かな標準規格品です。

また、ハンドルの入れ替えも(日本国内法は別として)置き換え可能ですし、ワイパーやウィンカーレバーはメーカー内で汎用品になっていることが多いです。
タイヤは規格品ですし、ホイールやサスペンションも変更可能です。確かに社外メーカーが純正品規格に合わせて作っているからであるかもしれませんが、事実上ある一定の規格があるので、市場に製品を出せているのだと思います。
カーナビやカーステレオ、スピーカーについては、配線を通じて、社外品が十分に対応していると思います。

ですので、必ずしもメーカーに閉じたインテグラルクローズもしくは、モジューラークローズであるわけではないと思うので、、、いつもすんなりと納得できずにいます。

明確な規格が存在しないからというだけで、インテグラル型だと考えるべきでしょうか?
もしよろしければ、ご助言・ご教示頂けませんか?」

最初にわたしの答えを言ってしまうと、“両者の区分は設計思想によります”、ということなのだが、これだけだと分かりにくいので少し補足させていただこう。

世の中の製品は、単純なものから複雑なものまで、いろいろある。製品が単純で、ほぼ均一の材料からなり、部品で組み立てられていない製品(たとえばモノサシだとか、まな板だとかを想起されたい)では、誰も設計アーキテクチャーについて論じたりはしない。アーキテクチャーが問題になるのは、主に後者である。つまり、複数の部位・部材ないし部品から構成されるもので、想定される機能も複数持ちうるものだ。自動車はもちろん、その代表格である。

ちなみに機能とは、製品と使い手の意思との関係で決まる。だからモノサシのような単純な道具でさえ、長さを測る以外に、紙に直線を引く定規として使う、紙を直線的に千切るのに使う、背中をかく、人の尻を叩く、など様々な「用途」で使える。このうち、設計者が想定する機能は、たぶん最初の二つ程度であろう。それ以外の使用条件は、たぶん『想定外』となる(そのことの是非は別の議論なのでここでは論じない)。ここでは、機能というものが、何か客観的な実在ではなく、製品と使用者の間で相対的にしか決まらない、ということだけ頭に置いておこう。

さて、設計とは、すこぶる単純化すると、「機能を構造に落としこむ」作業である。たとえば椅子というものを考える。椅子は、人がその上に一時的に腰掛けるためのものだ。すなわち、一定の高さに座面を提供することが、その機能である。野良仕事に行った先の、木の切り株だって腰掛ける用には足りるが、その目的で設計されたものではない。椅子を設計するとなると、まず座面と、それを支持する脚部からなる「構造」を考える。次に、座面の広さ・高さ・材質を検討するだろう。それから、その座面を支える脚をどんな形で何本にするのか、地面とはどう接するのかを決めていく。こうして構造の大枠が決まっていく。

木の切り株には構造はない。ムクの木材が均質に詰まっているだけだ。構造とは、ある全体が、均質ではない部分から成り立っているときの、その成り立ち方を指している。目に見える個体製品の場合は、その部品群の相対的な位置と接合関係で記述される。

むろん、椅子は手で持ち上げられる重さでなければならないとか、耐荷重は100kg必要だとか、回転できるようにしたいとか、背もたれも必要だとか、さまざまな設計の『制約条件』がある。この条件を満たすように、要素の成り立ち、組合せを考える。そして、個々の要素が満たすべきサブ機能や仕様を決める。

ここまで来ると、座面と支持脚をどう接合(固定)するかという、インタフェースの問題が出てくる。一体型で同じ一つの素材から削り出すという設計方針もありえるし、接着・溶接する、金具や釘で固定する、取り外し可能にする、等々、インタフェースの実現方法は様々だ。

ここで、接合箇所の形状や固定方法を社内で標準化して、いろいろな座面と支持脚の組合せを可能にしよう、と考えると、その設計はモジュラー型アーキテクチャーだということになる。これに対して、個別の座面に最適な脚の接合方法を個別に設計しよう、というのがインテグラル(すり合わせ型)アーキテクチャーである。そのどちらを選ぶかは、複数の視点からの評価が必要である。

(1)強度(頑健性):一体型が一番、強度が高い。逆に取り外し可能にすると、どうしても強度が弱くなるため、それだけの余裕シロ(安全率)を設計にみなければならない。

(2)部品材料コスト:上記の理由で、インテグラルの方が最適設計となり、ムダがないため材料コストは抑えられる。

(3)製造コスト:組立加工の手間自体は、一概に甲乙は言えないが、モジュラー型の方が同じ作業の繰り返しとなるため、習熟度は上がりやすい。

(4)設計コスト:概して、モジュラー型の方が設計の工数は少なくてすむ。インタフェース回りは毎回流用できるし、なによりモジュラー型の方は、座面だけ、脚だけという風に、独立して設計をすすめることができる。インテグラル型だと、設計も相互調整が必要だ。

(5)技術進歩のスピード:モジュラー型の場合は、ある部品要素だけを設計上で入れ替えることがやりやすいため、技術進歩が早く、次々と取り替えて製品のバージョンアップを図ることが容易となる

(6)サプライヤーの選択肢:インテグラルの場合、自社で設計した詳細図面に基づき、外部調達することになる。モジュラー型の場合、インタフェースと基本仕様だけで引き合いが可能なため、(その業界がそういう仕組みになれていれば)幅広く調達先を探すことができる

(7)ビジネスモデルとの整合性:たとえば本体価格は安く抑え、周辺付属品や消耗品を売って儲けるという方式(ジレット社がカミソリの替え刃で最初に導入した方式なので「ジレット・モデル」と呼ばれる)の場合、その部分の付け外しは可能になっていなければならない。

以上のような複数の視点から、長短を比較しながら、どちらを選ぶべきかを選択することになる。なお、(4)で書いたように、インテグラル型かモジュラー型かは、設計作業の体制にもそのまま影響する。モジュラーの方が分業と平行作業がやりやすく、また設計の流用や標準化も進めやすいのは言うまでもない。

そして、ここまで書いたように、インタフェースを社内で標準化するかどうかと、それを社外にも公開・共有するかどうかは別問題である。前者はクローズド、後者はオープン戦略と言ってもいい。モジュラーだがクローズド、という戦略も当然あり得る(ジレット・モデルはその例である)。

結局、ある製品がモジュラー型かインテグラル型かは、その製品の中核的な機能と構造が、どのような設計思想で作られているかによって分類される訳である。モノコック構造の自動車の場合、エンジンやトランスミッション、ボディなどがそれにあたる。逆に、ヘッドライトやランプ、ホイール、AV機器などは、顧客要望を取り入れやすいように取替可能となっているが、これらは自動車の周辺要素である。その部分だけ取り出せばモジュラー型に見えるが、全体構造はインテグラルである。ある部分だけ、使い分けているわけだ。

e0058447_215741100.jpg


もちろん、言うまでもないが、以上は設計思想が明確にある場合の話である。設計思想とは、設計上の判断が必要になったとき(つまりトレードオフが生じたとき)に、決断するためのガイドラインのことだ。だが、残念ながら、少なからぬ企業では、その設計思想自体が不明確だったり、部署・部位により混沌としていたりするのが実情である。その結果、従来はこうだったとか、業界の慣習ではこうだ(概して言えば電機部品業界は標準化・モジュラー化に慣れている)、といった判断がまかり通る。そして何型ともいえぬ製品ができあがる。

モジュラー型とインテグラル型を意識して使い分けるなら、それはそれで(車の場合にみるように)メリットはある。もしそれが意図した結果でないのなら--今からでも遅くない、本来あるべき設計の姿を、あらためて考え直すべきなのだろう。


<関連エントリ>

→「モジュラーとインテグラル - 製品アーキテクチャーの二つの方法
→「設計思想(Design Philosophy)とは何か
by Tomoichi_Sato | 2013-12-16 22:03 | サプライチェーン | Comments(0)

問題症状を治してはいけない

学生の頃、友人の家に泊まった。深夜まで音楽談義にふけった翌朝、寝不足と二日酔い気味のまま起きだして、その家の洗面台の前に立つ。顔を洗おうとしたら、壁に小さな新聞記事の切り抜きが貼られているのに気がついた。なにかコラム記事のようだ。タイトルは「風邪を引かない方法」。筆者の名前は、医学博士 ○○○○とある。

文章の主旨はこうだった。「風邪を引いた患者の容態を調べると、ほぼ共通して、初期は鼻が通常より乾いた状態であることがわかった。本来、健康人の鼻の穴は適度に濡れている。鼻が乾いてしまうことが、風邪をひく原因だ。だから、風邪を予防したければ、朝夕、顔を洗うときに、指先を水道の水にひたし、それで鼻の穴を濡らすようにすると良い。自分はこの方法で、もう10年以上も、風邪ひとつ引いたことがない。」

たぶん、友人の母上はこの記事が気に入って、自分の健康のために洗面台に貼ることにしたのだろう。母上が実際に風邪ひとつ引かぬ体質になったかどうかは、知らない。しかし、この文章があまりにも奇妙だったため、わたしは今でも忘れられずにいる。

風邪はウィルス性の感染症で、主に空気感染によってうつる--こんな常識は、もちろん医学博士某先生も重々ご承知であったはずである。では、鼻の穴が乾くとなぜ風邪を引くのか? そこの理路はよく分からなかった。鼻腔壁が濡れていれば、外気と一緒に呼吸で吸い込んだウィルスなどもよく吸着でき、体内に入るのを防ぐことができる、ということだったのかもしれない。実際、わたし自身も、鼻が乾きやすいのは風邪の初期症状だと自覚し、気づいた時はなるべく大事をとるようにしている。そう思うようになったのは、この記事を読んで以降のことだったろうか。ただ、朝晩、水道水で鼻の穴を濡らすことはしていない。

というのは、わたしは別の見方をしたからだ。鼻が乾くことが、風邪の原因ではない。風邪を引いて、鼻腔が熱っぽくなるから、鼻が乾きやすくなるのだと考えたのである。なぜ熱っぽくなるのか? ここからは素人の想像だが、文字通り、身体の正常な反応のひとつであり、熱を出して温度を上げることによって、菌の生存率を下げようとしているのだ。発熱というのは基本的に、身体が外部から侵入したバイキンを弱らせる防御反応である(微生物には生存に適した温度範囲があり、感染菌はたいてい人間の通常体温に適応している)。

つまり、鼻が乾くことは、風邪の原因ではなく結果であり、初期症状なのである。それは、身体の正常な反応の一部だ。結果を除去したからといって、原因が治るわけではない。鼻の乾きにかぎらず、痛みや熱といった症状は、体のアラーム信号だ。アラーム信号それ自体を除去して、異変が治るだろうか。もちろん素人のわたしが、医学の専門家の意見を批評するのはおこがましいかもしれぬ。ただ、俗に“風邪を治す薬を発明できたらノーベル賞ものだ”と言われるが、この医学博士の先生が受賞したという話は聞かないし、学会での常識になったという風でもない。

話は、いきなり飛ぶ(いつもながらすみません)。10年ほど前だが、あるERPベンダーを、別の国のコングロマリットが買収した。ERP市場の中では、Second tierというか二番手集団だったが、あいにく赤字に陥って、買収の憂き目にあったわけだ。買い手の企業の方は、次々と買収劇を繰り返して急成長中であった。彼らは買収時のコメントとして、「これからは厳格なコスト管理を行って、経営を再建する」と発表した。Stringent cost controlという語を使っていた。これを読んだわたしは、“あ、これはダメだ”とがっかり感じたのを覚えている。

なぜダメか。ソリューション・ベンダーが赤字に陥る状態は、コスト管理の失敗から来ることは、じつは少ないからだ。豪華すぎる設備を買ったとか、外注先に払う人月単価が高すぎたといった理由で、赤字になるのなら、たしかにコスト屋の領分だろう。だが、多くの場合は、ちがう。新バージョンのリリースが遅れてシェアを競合他社に奪われたとか、追加交渉に失敗して売上が伸びなかったということが原因なのだ。さらに、どうしてそういう事態が生じるかというと、仕様が複雑化して開発工数が増大したとか、出来上がった製品の品質が悪くて顧客交渉に強く臨めない、といった事象が考えられる。そしてもっと原因をたどると、自社要員の人数・能力不足や、開発外注先の選定の失敗が浮かび上がる。それらの根本原因として、コミュニケーション不全や、リスク管理の不在など、マネジメント・スキル自体の問題が横たわっているはずだ。こうした問題を、数字に強いだけの財務屋さん達が解決できるだろうか?

赤字というのは、企業というシステムの表面に現れる症状である。その症状を、コストという「症状の次元」の中で解決できると思うのは、あさはかだ。原因は、もっと深いところにあるのに、買収で成長する企業では、往々にして頭脳優秀な財務マンたちが経営企画の中核にいて、自信満々にすべてを数字で割り切れると信じている。彼らが得意とするのは、厳格なコスト管理であり、不採算部門の売却であり、人のレイオフである。新技術が必要なら、自分でゆっくり開発するより外から買収してくるのが、一番てっとり早いと考える。

だが、ソリューション・ビジネスというのは複雑なシステムである。誤解しないでほしいが、ERPが複雑な情報システムだという話をしているのではない。ソリューションはベンダーと顧客とパートナーとハードメーカーと開発外注先の群からなる複雑なエコシステムの上に成り立つ商売であり、どこかの要素にインパクトを与えた場合、リアクションは思いもよらぬ別の場所に、後になってゆっくり現れたりする。それはちょうど、生物のからだ、あるいはヒトの身体のようなものだ。

あの医学博士が誤解した理由ははっきりしている。人間の身体というシステムで、鼻の乾きと風邪の発熱という二つの現象が、相前後してほぼ同時に現れる。だから前者が後者の原因だと考えてしまった。それは、複雑なシステムというものの見方ができない人の、早合点した論理だった。赤字を、コスト問題の次元でとらえるのも、同じように短絡した論理だ。納期遅れをスケジュールの次元だけで考え、在庫問題を物流だけの次元で対策しようというのも同様だ。結局、その企業は、数年後にERPベンダー部門を売却することになった。その間の本当の事情は、わたしには分からない。ただ、しだいに寡占化が進みつつあったERP市場で、その製品がトップ集団に踊り出ることもなかった。いいところもあったのに、残念なことだ。

症状を、症状の次元で治そうとする行為を「対症療法」と呼ぶ。対症療法では、病は根治できない。根治したければ、深い原因を探さなければならない。

そして、そのためには、システムというものに対する深い洞察が必要なのである。
by Tomoichi_Sato | 2013-12-10 23:59 | 考えるヒント | Comments(0)

オプションが多数ある製品のBOMは、どう構成すべきか

今からおよそ100年前、ヘンリー・フォードは世界で初めて自動車の量産をはじめた。それまで、自動車は富裕階級向けの特別な商品であり、ほとんどが注文生産だった。顧客は大きさや色をはじめ、様々な自分の好みをつけて注文する。メーカーはそれを受けて、個別に設計して製造する。当然ひどく高くつく。それでも買える人だけが顧客だった。ほとんど今の注文住宅のようなものである。

そのようなマーケットの常識を、フォードは完全にくつがえした。彼は黒色のT型フォードという、ただ一つの標準モデルを売ることに決め、そのための専用量産ラインを、当時としては画期的だった工程別分業体制とベルトコンベア方式によって実現した。この時に彼が言った、

 「顧客の望む色はどんな色でも売ります--それが黒色である限り」

という、有名な文句は一種の標語となった。モデルを一種類にしぼり標準化をはかることで大量見込生産を可能とし、安価な製品で大きなマーケットを獲得したのである。かくしてフォード・システムはアメリカ的経営の成功モデルとなった。

しかし、時代が下り、自動車が大衆社会におけるコモディティ商品となっていくにつれ、単一モデル販売ではもはや競争に勝つことができなくなっていった。外装の色やエンジンの排気量など、標準モデルにさまざまなバリエーションをつけることによって、次第に消費者の細かな好みに合わせる方向に、販売競争が進んでいった。その結果、インテリアの仕上げ、変速がマニュアルシフトかATか、エアバッグの装備、搭載カーナビ機器のグレードなどなど、かなりの種類のオプションを購入者が選べる状態が、現代では常識となっている。つまり、

 初期の個別受注生産 →普及期の大量見込生産 →成熟期の個別オプション生産

という風にマーケットの形(生産・販売形態)が変遷していったのである。

同じことはコンピュータ産業でも起きた。初期の汎用機は非常に高価で、注文生産だった。顧客はそれを買える大企業や国立の研究機関だけだった。しかし、やがてミニコンやオフコンといわれるクラスの普及型製品が出される。さらに「Apple II」や「IBM PC」といった、大衆向けの安価な単一モデルが消費者市場を席巻した。フォード・システムの再来である。そして今日では、多くの消費者はショップに行き、CPU速度やディスク容量・メモリ容量など、多数のオプションを選ぶようになってきている。

このようにオプションが導入されたのは、多様な消費者ニーズに柔軟に対応して、販売しやすくするためである。こうして、消費者の手元に届く商品はバラエティが増え、同じモデル名でも一つ一つが異なる別のものになってくる。こうした生産形態を、大量生産(マス・プロダクション)に対比して、マス・カスタマイゼーションと呼ぶこともある。

ところが、BOM(部品表)の観点から見ると、ここで一つの難問が生じる。BOMというのは、最終製品(英語でEnd productないしEnd itemと呼ぶ)を頂点とした、部品群からなるツリー構造になっている。一種類の最終製品に、一つのBOMが付随する、1:1の関係だ。たとえ同じモデル名でも、もし、トランスミッションの種類が違ったり、エアバッグの装備などが違ったりすれば、当然ながら部品の構成は変わるわけだから、別のBOMが必要になる。

たとえば、自動車のオプションが次のようにあったとしよう。

 ・外装の色 5色
 ・内装の種類 3種類
 ・変速方式 マニュアルまたはAT
 ・エアバッグ装備 3種類
 ・搭載カーナビ機器 4機種

すると、可能な組合せの数は5×3×2×3×4=360種類にものぼることになる。この場合、360種類ものBOMを作成し、マスタに登録して用意しなければならないのだろうか? 

それはとてもばかげた手間に思える。じゃあ、個別の注文を受けた際に、その時毎回、必要なBOMだけを登録することにしてはどうか。いうまでもなく、BOMは製造工程で必要とする部品の出荷指示の基準情報である。だから、工場倉庫からの部品在庫の払い出しは、その個別BOMに従う、とすればいいはずだ・・。

ところが、そうは問屋が卸さないのだ。BOMは材料の購買手配の基準情報でもあることを、忘れてはいけない。部品サプライヤーたちに、先々の数量を先行内示で与えるのが、自動車業界の慣習だ。このとき、すでに登録されている(つまりたまたま過去に注文のあったオプション組合せの)BOMだけで購買手配をかけたら、これまでなかった新しい組合せの注文が顧客から来ても、応えられなくなってしまうだろう。

このような矛盾をはらむ問題の解決法には、じつは定石がある。ここでの問題の根幹には、BOMが「部品購買手配の基準データ」と「製造の部品払出指示の基準データ」という二つの機能を併せ持っていて、その二つが両立しがたいことにある。こういう場合は、二つの機能を受けもつ要素を別にするのである。ちょうど、機械設計のとき、異なる機能を受けもつ部品には違う材質を用いるように。つまり、「部品購買手配の基準」であるマスタとしてのBOMと、「製造の部品払出指示の基準」としての個別BOMを、別のデータとしてシステムに持つのである。前者はマスタデータであり、後者はITの用語で言えばトランザクション・データである。

まず、前者のマスタとしてのBOMから説明しよう。こういうケースでは、BOMの親製品と子部品の間の数量関係(員数)を、整数ではなく、使用比率に応じた小数つきの値で持つ。こうしたBOMデータの形式を、「モジュラーBOM」(あるいは「縮約BOM」)と呼ぶ。モジュラー化したBOMでは、まず最上位の仮想的な最終製品として、製品ファミリーを定義する。その下に、基本モデル製品と、各オプションに対応するモジュールのサブ・アセンブリーに関するBOMを、登録する。

この際、親子関係の員数として、オプション選択の比率を使う。もしユーザが平均してマニュアルを30%、ATを70%選ぶことが過去の経験から知られていたら、製品ファミリーから変速装置への員数をそれぞれ0.3と0.7に設定するのでである。むろん、この員数は定期的に見直す。

e0058447_22361318.png

図:オプション構成とモジュラー化されたBOM (「BOM/部品表入門」第8章より引用)

このようなBOMを定義すれば、マスタ情報のメンテナンスが楽になるばかりではなく、MRPを利用する際にも、販売予測を360種類の最終製品に対して行なうかわりに、製品ファミリーに対して1種類行なえばすむようになる。

むろん、ユーザによるオプションの選択比率は、つねに定期的に見なおしていく必要がある。とはいえ、そ比率の見直し作業は、5+3+2+3+4=17種類のモジュールに対して行なえばすむ訳である。

そして、製造の部品払出指示に対しては、受注した個別オーダーのオプションから導出されるBOMを用いる。生産管理パッケージの中には、製造指図にBOMを添付する機能を持っているものもある(わたしの記憶では、SAPの生産管理モジュールもその機能を持っていたはずである)。ここで、添付するBOMは、元のマスタデータからコピーするが、顧客の指定したオプションに従って個別に修正したものを添付する。これが、製造BOMのトランザクション・データになる。

つまり、ただ一つのBOMデータでいろいろな業務機能をまかなおうとするから問題にぶつかるのである。BOMには、最低でもマスタとトランザクションの二種類が必要である。これは、わたしが拙著BOM/部品表入門で提案したことだ。より正確に言えば、トランザクションは「これで作れ」という指示系履歴データと、「これで作りました」という実績系履歴データに分かれるべきだから、BOMは合計、3種類必要だ、というのが、わたしのかねてからの主張である。

顧客の要望する機能や仕様は多様化しており、作り手がその流れを止めることはほとんど不可能である。そこで、いろいろなオプションや付属品をご提供することによって、なんとかニーズを満たしてもらう訳である。その無数に増え続ける組合せを、パターン化するための方法が、仕様に対応する「モジュラー化」の考え方なのである。モジュラー化とは、標準的なモジュールの組合せによって、選択のバリエーションを作りだす方法で、いわば注文住宅とプレファブ住宅の違いと言ってもいい。モジュラー化設計によって、必要な部品やサブ・アセンブリーのバラエティを減らし、ある程度見込をつけて生産しておくことができるようになる。そして、BTO生産方式(「ATO」とも)に近づくことができ、注文から納品までのリードタイムを劇的に短縮できるようになる。そのような生産革新のキーが、モジュラー化BOMなのである。


<関連エントリ>
 →「生産革新のためのBOM(部品表)再構築入門(1)
 →「工場計画論(5) BTOと製品アーキテクチャー
by Tomoichi_Sato | 2013-12-02 22:39 | ビジネス | Comments(0)