January 19, 2011
これまで、トップダウン・ボトムアップ設計手法、さらにProduct Model Languageに関して説明を加えてきました。結局、デジタルプロダクトモデル設計を成功させる為のキーは何でしょうか。
これを問われたとすれば、３次元メカ設計を例にお答えします。
まず、私共は３次元設計を導入する意義の一つを挙げたいと思います。それは、３次元設計の導入が、今までの２次元設計の世界で直面していた問題へのブレークスルーを発見するチャンスを与えることです。
３次元設計に対する投資は小さくありません。その３次元設計を成功させ効果を得たいと考えるのであれば、
当然、３次元設計の特徴１）を考え、トップダウン・ボトムアップ設計手法に基づき３次元をテコにした開発業務改革を実施すべきです。
この過程で、今までの２次元設計の世界で直面していた問題へのブレークスルーを発見することになります。
結果的に、この発見が、ＱＣＤ（品質・コスト・納期）に関わる課題へのブレークスルーや、より大きな外部環境の変化へ対応する為のブレークスルーにつながるのです。いずれにしても、これらのブレークスルーにより生み出される変革は、確実に企業進化レベルの階段を登ることにつながります。
しかし、実際の改革は簡単ではありません。一時的には３次元設計を実施する以前より工数負担が増える可能性も高く、慣れ親しんだ２次元設計から離れることへの現場からの抵抗も少なからず発生します。これらに対処する為に
私共が関与した様々なお客様の改革活動から、２つのポイントの重要性を指摘したいと考えます。
注１） ３次元設計は製品データそのものをデジタル化しバーチャルな世界で設計を進め、その品質を螺旋状に
徐々に向上させていく特性を持つ故に、ソフトウェア工学の中で進んでいる改革を参考にすることが出来きます。
近年のソフトウェアの複雑化と組み込み型ファームウェアの増加に伴い、ＵＭＬ※１による設計効率化と品質向上の取り組み、開発品質の企業単位での向上を促進する為のＣＭＭ※２による設計業務成熟度測定、などが進んできています。この様な取り組みの中でソフトウェア開発会社は自社の技量をグローバルに競い合っています。この様な側面からもProduct Model Languageなどを活用し３次元設計などのデジタルプロダクトモデル設計を捉える思考が必要となっているのです。
※１ ＵＭＬ：Unified Modeling Language
統一モデリング言語 オブジェクト指向ソフトウェア開発におけるモデリング方式
※２ ＣＭＭ ：Capability Maturity Model
能力成熟度モデル 組織（企業・チーム）のソフトウェアプロセスの成熟度を示すリファレンスモデル。
■指摘１ 経営者サイドの心構え■
ブレークスルーによる企業進化を望む経営トップの強い意志と支援がなければ、３次元設計などのデジタル
プロダクトモデル設計は成功しません。
例えば、３次元設計を既成の機構設計の枠だけで捉えるのでなく、バリューチェインを意識した要件を取り込むトップダウン、部品単位から設計を進めるボトムアップ、この両方の設計手法から十分検討することにより、はじめて、確実に開発業務改革につなげることが出来るのです。
この為には、近い将来必ず効果を獲得できるという経営者の強い信念とリーダーシップが必要です。
そして、その信念を「忙しい現場」に徹底させる必要があります。デジタルプロダクトモデルを成功させる為の重要なキーの１つは、経営層にかかっているのです。
■指摘２」現場サイドの心構え■
もう１つのキーは「現場」にあります。
それは小さな成功体験を積むことにより、現場でデジタルプロダクトモデル設計を徹底させるダイナミックな波動を生み出すことが必要です。
例えば、次元設計ツールを活用して、現場に山積した課題を解決する為の施策ロードマップを作り、意識的に、
小さな成功体験を積み重ねることできるマイルストーンを準備することが重要です。
そして、その積み重ねが、真のブレークスルーの実現に向かっていることを現場全体に実感・共感させる。これが、多忙を極める日常業務の中で、現場が喜びを見出すことになり、更に、困難な改革に拍車をかけることになります。（事実、我々はそうした姿を見てきました）
製造業ブログランキングに参加しております。以下のタグをクリック頂ければファソテックコンサルティングのブログランキングをご確認いただけます。よろしくお願い申し上げます。
ftc_corp
『コア』（原型）については、企業進化レベルが高まるにつれて、やがては、ひとつの製品に関わる全ての情報を内包した『球根（Ｃｏｒｅ Ｖａｌｖｅ）』として企業間のコア連携の為に活用されることとなります。（企業進化レベル４で紹介）
そして、このコアの考え方は、現存するMALTABなどのモデルベース指向のソフトウェア開発・論理シミュレーションツール、電気系・３次元メカＣＡＤ、論理モデルなどにもあてはまります。
但し、Product Model Languageを使ってコアを生み出すという取り組みは、一回だけで全てが完結する訳ではありません。
自社内の設計関連部門はもちろん、サプライヤや顧客も巻き込んだ形でコアを活用した開発プロジェクトを繰り返すことにより、次第に、設計部門以外の生産技術部門などで『どのようにデジタルデータを活用するか』というデジタル習熟度が上がり、デジタル設計支援ツールの活用レベルも高まることとなります。
また、このデジタル習熟度が上昇する過程でのＩＴ技術などの進歩とも相まって、当初に想定した『あるべき姿（Ｔｏ－Ｂｅ）』も、より完成度の高いものに成長を遂げると考えられます。
よって、コアは継続的に見直されることが必要であり、そのことが商品開発における上流品質１）や設計データとしての源流品質を
向上させ、コアに含まれる製品の原型、バリューチェイン要請を反
映した設計業務プロセス、及びそのノウハウが共にスパイラル上に習熟することになります。
これが企業において「デジタル習熟スパイラル」を生み、次第にデジタル活用習熟度をより高め、比類なき競争力の獲得に繋がると確信します。一回の取り組みだけでなく、粘り強い反復した取り組みが、より自社の潜在能力を高め、より高い目標を達成することが可能となるデジタル活用業務プロセスが構築できるのです。
注１）
上流品質については、サプライヤを含んだ品質管理体制を指す場合があります。私共は、サプライヤからの購入品に関わる製品情報のやり取りを含む「サプライヤ管理プロセス」をバリューチェイン検討の中に含むべきであると考えます。
January 04, 2011
■Ｐｒｏｄｕｃｔ Ｍｏｄｅｌ Ｌａｎｇｕａｇｅとトップダウン・ボトムアップ手法の関わり■
Product Model Languageの考え方には前項の『トップダウン設計』 『ボトムアップ設計』がベースにあります。
さらに、その両面からどのように設計を行うか？という『コントロール（制約）』があり、そのコントロールにはトップダウン設計とボトムアップ設計の各要件が置かれています。
トップダウン設計要件は、ビジネスモデルに直結するバリューチェイン要請を受けて作成される「設計ルール」（環境・製造・保守からの要請も含む）などです。これには、設計業務の上流段階で、設計品質を上げる為のコンカレント的なアプローチが内在しています。
また、ボトムアップ設計要件には、設計情報としてのデジタル製品情報（デジタルプロダクトモデル情報）の品質をどのように高めるかに焦点が当てられます。
デジタル製品情報は、デジタル設計支援ツールにより作成されることから、データ構造・様式・識別やメタデータと実体データの取り扱い関係などを明確に定義することよって、その品質を高め、バリューチェインを横断して共有・活用されなければなりません。ボトムアップの設計要件は源流品質のプロダクトモデルへの品質作りこみルールとも言えます。
■コア（原型）の定義と、Product Model Languageの２つの用途■
設計開発は、新規に設計する場合と、一度設計したものを再利用する再設計があります。再設計を行う際、元となるデータは、一般的には「雛形」と呼ばれますが、設計品質を高めるためには、雛形よりさらに厳密に生み出された「原型」に近いものが必要だと言えます。
その『コア』（原型）は、潜在ニーズを具体化し競争の核を具現化する要素技術開発プロセスの中で、新規に生み出されます。この『コア』（原型）の中には、ＣＡＥやシミュレーションによりコスト・品質・性能が最適化されたモデルデータ（限界設計）、さらに、様々な設計業務プロセスやノウハウが反映されたテンプレート、この２つで構成されます。
この原型が、再設計（派生・流用設計）の核のようになるという意味で、『コア』（原型）という名称を定義しました。
Product Model Languageの用途は、このコアの新規設計、コアを使っての再設計、２つのパターンが存在します。
①プロダクトモデルにおける「あるべき姿（To-Be）」としてのコアを検討する場合 ⇒ 新規設計
②プロダクトモデルにおけるコアをベースとした再設計（派生・流用設計）を検討する場合 ⇒ 再設計
※ ファソテックコンサルティングは、「コア」（原型）を生み出す手法として、データ・ホモロゲーションを提案しています。
その中で、ＣＡＥやＭＡＴＬＡＢを活用した論理シミュレーションにより最適化されたモデルデータ（限界設計）、さらに、様々な設計業務プロセスやノウハウがテンプレート化される概要をご紹介しています。別途、Product Model Language（ＰＭＬ）の最新資料をお読みください。
■プロダクトモデルにおける「あるべき姿（To-Be）」としての『コア』（原型）を検討する場合■
Product Model Languageを使用して設計業務を可視化する場合、最も重要なポイントは、現状の各業務内容を把握した後、『あるべき姿』を検討するプロセスを必ず実行することです。その際、「現状の姿（As-Is）」から「あるべき姿（To-Be）」を検討する為には、開発業務における「将来への目標」が明確になっていなければなりません。
何故なら、将来への目標と「現状の姿（As-Is）」との間にある課題を解決しなければ、「あるべき姿（To-Be）」へとは到達できないからです。
これは、米国連邦政府やインテル社などがその業務改革を推し進めた際に活用した「エンタープライズ・アーキテクチャ（ＥＡ）」の基本的な考えに基づくものです。ここでは、それを設計業務に適応しています。
また、ここで言う「あるべき姿（To-Be）」を検討するためには、デジタル設計支援ツールとは何か？ どう活用すべきか？ をしっかり認識した上で、設計業務プロセス上の課題解決策を見極めなければなりません。
