「デザインレビュー」カテゴリーアーカイブ

デザインレビューの方法などに関するブログ

製造業のデザインレビューには製品構造の横並び比較システムが必要である。

投稿日時: 投稿者:

製造業のデザインレビューで成功する為には

デザインレビューはどんな観点で問題意識を持つかということは個人によって違いがあることを否めない。個人が保有した経験差が顕著にあらわれるものである。問題点はなぜ、そのことが問題であるのかということを説明し合うと差が良く分かるものである。製品開発におけデザインレビューをより継続的な共通の判断に持ち込むためには、製品の構造比較を整備する必要がある。

　製品のデザインレビューを行う生産側の担当の頭には何が固定概念としてあるのかを知っていなければならない。それは、製品を生産する予定の生産ラインの条件が頭にあるはずである。確かにその製品検討は、その製品をそのライン投入する為の仕事であり、その仕事をするように命令を受けて参加しているのであり、仕方がないことである。

　しかし、仮に、他にも生産ラインがあり、違う製品もあるならば、自分が気づいた問題点は、企業の共通の問題なのか、それとも担当する生産ラインの固有の問題点であるかを意識しなければならない。複数の生産ラインを保有する企業では、このような生産ライン固有の問題点だけをデザインレビューで行う傾向がある。
　

製造業は部品種類抑制し、構造の種類によるデザインレビューでの判断を複雑化しないこと


　企業の中でもう一つの問題は部品の種類増加である。部品種類増加は、生産の複雑化だけではなく、製品の交換パーツのサービス維持など、長期にその加工のために型がどんどん増えていく。置き場に困りスタッカークレーンなどを設置するならば、これは何かおかしいなと思わなければならない。

　製品の構成部品に似て非なる部品がどんどん増えてしまうのは、1つには、設計者の共通化の意識の不足もあれば、2つには、生産側の問題点の認識が固有の生産ラインのことだけを考えていることにもよって、部品の種類が増加していることも承知すべきことである。

　設計は特定の製品を長期に担当することもあり、その製品については熟知することになる。しかし、他の製品はよく分からないということになる。

　生産側は、多品種生産が通例であれば、いくつもの製品の構造を理解する必要があり、製品構造に関する知識は設計者よりも種類については良く知り得る立場になる。

　このように知り得る知識の範囲が縦と横のようの大きく異なる組織が、共通の意識を持って製品の設計が行うことができなければ、企業内に無駄な部品種類を増加させることになってしまうという事を理解しなければならない。

製品構造の横並び比較システムで構造検討を正しく行う

　このことを解決するためには、製品の横並び比較表を整備することが良い。企業内の製品を、1つの製品タイプ内の全製品を主たる構成部品ごとに横並び比較が行えるようにビジュアルに整理することが大事である。横軸は製品のバリエーションであり,縦軸は主たる構成部品が並ぶ。このセルに部品の構造をビジュアルに登録するのである。そして、この表に対して、製品が追加されるたびに横並び列を増やしていけば良いのである。
　

このようにすることで過去の製品の構造知識から最新製品の構造知識を誰もが知ることのできる環境が整うことになるのである。製品開発における知識の記録方式には、以上のような比較が可能にならなければ、単にコンピュータにデータをためるだけのシステムになってしまうだろう。

製造業でのプロフェッショナルな人材育成にはデザインレビューが最適

投稿日時: 投稿者:

製品の外側から内部の構造を推察できればプロフェッショナル

ものごとについてプロフェッショナルと言われる人達は皆、外から中を知る能力を持っていると思う。ものについては、例えば、自動車の分解研究をしたことがあるが、インストルメントパネル周りの分解をするにあたり、どこから先に分解することができるのかを推定する。自動車の意匠で誰もが一番接することの多いのが、この場所である。したがって、どの企業のインパネもビスの頭も一切外部からは見ることがないように設計されている。一番最後に組まれた部品は何かを推定することで、その部品を取り外すと、その中に、内部の部品の締め付け部が見えるといったような思想である。複雑なインパネ内の構造もこの思想を基本にすることで、インパネのモジュール化が実現されてきた。単に、部品を見るだけではなく、どのような考え方の上で、その部品や周辺構造は設計されたのかや、どのような加工プロセスで作られたのかなどを見つけることができるようになると楽しいものだ。

関心をもった文書の思考を理解するための関連文書をかき集める

　また、ことについても同じで、これまでの投稿してきた各分野の仕事においても、最終的な文書から、そのことが決められた背景、意図を見つけることができれば、その道のプロフェッショナルと言えよう。しかし、これはインパネの分解研究とは格段に難しい。それは、その文書には、それを分解できる文書が添付されていないからである。多くは、理解されて当然ということは省略されているのである。ここがものとことの外から見た大きな違いである。そこで、ことの理解を深めるには、その文書の関連文書を一通りかき集め、その文書の成り立ちについて、思考プロセスを自分の頭で行う必要が出てくる。そのプロセスにて、違う視点が見つかるかも知れない。その時には、目の前にある文書を修正する必要があると認識することになる。そこで目の前にある文書の作成者が、その文書を完成するまでに見たり、読んだりしたことを、全て、その感想や解釈と共に、記録していたならば、その文書を読む人の理解は圧倒的に早く進んでいくことになるはずだと考えている。

文書作成のプロセスを共有することから始めると人材は育つ

　自動車の部品のように、私達の文書も、その作成プロセスを共有することが必要だと考えている。完成した文書だけでは、人を動かせない。小説家や文書のプロである作家は、みなさん、このような、思考プロセスを記述してくれるので、良くわかるのである。このようになっている伝達の方法がストーリテリングであると思う。企業の内部において、なかなかベクトルが揃わない、意見がまとまらないという原因は、同じ情報と知識を持ち合わせていない集団であるからだ。人であるが故に、個人差があるのは当然だが、もう少し、企業においては基礎的情報と知識を共有する努力をすべきでは無いかと強く思っている。

デザインレビューをすることで考え方や知らなかったプロフェッショナルの人の知識を受け継ぐことができる。

　自動車のようにものづくりには、生産工程という物理的なプロセスが目に見える状態で存在している。それがゆえに、プロセス管理は容易である。各工程で完成したものを外から見て、おかしな点があれば、細部の生産工程を目で見て確認することができる。このようなことを繰り返し経験すると、ものの外部から見た時に気づく要因は、細部工程を見ることもなくかなりの確からしさで言い当てることができる。
　しかし、ことには物理的なプロセスが目に見える状態で存在していない。そのために、完成した文書だけでは、求めていた結果となっていない場合には、それまでの仕事のやり直しをすることになってしまう。言葉は賛成できないが、ダメ出しが必要なのである。ことの仕事にも、ものづくりと同じデザインレビューが必要なのである。このデザインレビューが定着されれば、組織としての考え方を整えることができるであろう。他者の仕事に注文をつけるのは避けたいことではあるが、そのことをお互いに受けいれ尊重し合うことは創造的なことが求められている現代においては本当に重要な意識である。そして、ことのプロセスを記録することがホワイトカラーの仕事の自動化につながるはずである。

デザインレビューに最適なCKWEB2に知りたいことはこちらから

製造業のデザインレビューの目的は潜在的問題点を顕在化し、関係組織にて解決し経営指標を高めることにある。

投稿日時: 投稿者:

サプライチェーンの中の潜在的問題点の顕在化

仕事は問題と対策の繰返しである。計画通りに進まないのが当たり前。しかし、同じ間違いを繰り返す事は避けたい。デザインレビューを例に問題点管理の重要性と知識の記録との関係を説明する。
　デザインレビューで気づいたことは、その対象である設計図面のイメージ図に特徴点記録方式によって記録する。例えば、部品と部品との隙間を設計者は1mm で図面を作成したとしよう。2つの部品は、板厚0.7mmのプレス品としよう。さて、生産側はこの隙間を適切な寸法と考えるかどうかという視点が必要だ。それには、設計として1mmの隙間をどの位の公差で製品化したいのかを確認する必要がある。仮に、1±0.5mmなら、生産側は、バラツキをこの公差内に抑えることができるかどうかという判断が必要になる。
　生産側はどのような加工法を現在行なっているのかを知っていないといけない。更に、その加工法における工程能力も把握していないといけない。知っているからこそ、問題だと言えるのである。
　このように、ものづくりのサプライチェーンの中には、膨大なものづくりの知識が存在している。その加工工程を知っているのかどうかはデザインレビューにおける気づきの有無に影響する。ものづくりの知識は現場での体験によって記憶に留められるものだ。座学では、感覚は身につかない。しかし、全ての人がサプライチェーンの中の全ての現場を体験できることなど不可能である。会社も組織も機能分担されているために、そのような体験ができる事はあり得ないことである。

デザインレビューを通じて周知を結集し、経験を共有することができる


　そこでどのように擬似体験を行うことができるかを考える必要がでてくる。人は成長してながら、後任にバトンを渡さないと社会は成長していかない。これまでバトンを渡さない企業を何社も見てきたが、すべからく進歩の無い硬直化した組織であった。
　人は突然と何かを思い出して生きているように思う。それは新聞を読んでいたり、小説を読んでいる時や、絵画を眺めているとき、遠くを見ているとき、人にあった時、などいろいろな場面で起こりうる。その時には、目に見えた絵と結合しているように思う。だから、嗚呼、どこかで見たなあ、あの人とそうだ鈴木さんと、渋谷の駅でばったりと会って、懐かしい学生時代の部活の話をしたなあ、嗚呼、そうだ今、中村くんはどうしているかな？など、芋づるのように思い出が湧き上がってくることがある。この状態を知識の繭の糸を紡ぐと表現している。
　製品の図面を見ても、嗚呼、あんな失敗をして生産が品質不安定で苦労したなあ、、と問題点と対策が繭の糸を紡ぐように脳裏に浮かび上ってきて欲しいのである。

問題点は膨張するビックデータである。真っ先にDXで取り組むべきシステム化。


　このようにするには、図面と一体に問題点を記録するビジュアルな方法が周辺の部品の関係などからも、過去の記憶を呼び出せる。そして、そのような失敗を問題点として皆が記録すれば、他者の失敗にも具体的なこととして、理解でき記憶に留めることができようになる。失敗を個人の記録として解決できたら一件落着とするのではなく、未来のバトン渡しのために、発生した問題点をその失敗事例のイメージ図の中に記録させるckweb2 による問題点管理はマネジャーの役割だと考える。

製造業のデザインレビュー業務を効率化するツール：CKWEB2

投稿日時: 投稿者:

デザインレビューは企業の技術判断のレベルを顕在化させる

デザインレビューはものづくり企業では一般的な取組みである。製品を開発する場面で用いられることが多いが、それ以外でも、設計とで製造着手の前に行われることも多い。今回は、製品設計の場面での知識の記録方式について記述する。

　製品設計図をデザインレビューする目的は、機能、品質、原価、デザイン、販売、サービスなど企業の多くの組織に存在する。その中でも、やはり生産側のニーズが大きい。どんな図面を描いても製造することができないようではどうにもならない。したがって、設計構想などの手戻りの少ない段階でのデザインレビューが有効である。図面が完成した段階ではデザインレビューの意味が無い。試作図という段階を持つ製品の場合は、当然、試作図が完成する前で行う必要がある。デザインレビューの失敗は、設計側の情報の出し惜しみと生産側の作る技術の曖昧さ、設計と生産との組織的信頼関係の無さによることが多い。

設計と生産部門の技術知識の相互理解がデザインレビューを成功に導く

生産側の立場では、デザインレビューをし初めて直面することがある。それは設計図を見て何を発言すべきか、その意見は正しいのであろうか、設計者に折角の図面を修正してもらう意味のある提案なのだろうかということに不安を持つはずだ。この仕事はベテランでなければ務まらないもので、生産の知識が不足している年上の管理者では遂行できない業務だと思う。
設計者は創造性を発揮して、製品機能を中心に検討し図面を描く。出図日程も原価目標も決まっている。時間との戦いの中にいる。一方、生産側は鋳造、鍛造、機械加工、塗装、溶接、組立などものづくりを素材から完成までのエンジニアリングを少なくともその製品について短期間に広い範囲で検討しなければならない。
まず、限られた期間の中で、生産側の安全、品質、コストに関する確認を終え、更に、その対策案を具体的に提示しなければいけない。従来は、そのやり方はチーム内でそれぞれが紙にリスト化したものを、重複、提案、却下、保留などに分ける。保留とはチーム内で合意できなかった事で、事実の確認などを生産現場で行うものである。これらを、整理した上で設計者と打ち合わせを行うのである。このようにデザインレビューは、意見調整、事例の調査、日程調整、対立意見の調整など、人のコミュニケーションを必要とする多くの工数がかかる方法であった。

デザインレビューと技術知識の共有は車の両輪である


この仕事はckweb2 に最適で、チームが同じ図(イメージ図)に特徴点を書き込むだけである。これにより重複は未然に防止できる。また、他者の意見も画面に見えるために、その場で調整が可能となる。チームで合意したデータは設計者に開放し、打ち合わせの前に図を見ながら理解してもらう。その結果をckweb2 にイメージ図の中に特徴点記録する。すると、個人が保有していた知識が記録され、他者の知識を共有できるようになるのである。テレワーク、海外とのデザインレビューにも最適だ。

製品開発でのデザインレビューにおけるQPPモデルの活用方法

投稿日時: 投稿者:

製品開発の企画書をQのモデルとして利用すること

製品開発の実務適用についての特徴点とQPPモデルの使い方を紹介をします。製品開発の企画段階では、製品を市場に出す狙いは何かが議論され方針が決定します。この段階では例えば製品企画書という文書が作成されることでしょう。この文書を作成する人は、まず、過去に作成された書式の企画書を読むことになる。参考にすることは漏れの無い仕事の基本だからだ。これの過去の企画書を対象と呼ぶ。この対象とした文書に変更すべき点に引出し線を引く。その引き出し線の頭に、変更したいの内容を記述する。これらを対象の文書に書き込んでいくのである。これで、1つの企画書のアイデアが生まれたことになる。ここで大事なことは、帳票の記入エリアの大きさ制限を気にしなく自由に書くことができることである。常に内容が重要である。見た目を意識すると自分にも他者にも理解しにくい不十分な説明になる。頭の使い方を見た目のことから離れて、考えることだけに集中するのである。

設計、生産、販売など多面的な意見を企画書に記入する

次に、既に過去の帳票にも表現されている区分を付与する。全体として企画書はQの区分である。そして帳票の中にはには、例えば記入欄ごとに、テーマ、背景、課題、市場動向、必要な機能、販売予測、価格設定、発売時期、などの書く欄がある。これらの項目にもQPPの区分を付与する。区分する時は目的、設計、実行段階のどこで守ることかで分けること。全て企画書を書いた部署の責任ではないという意識で行うこと。
この企画書のアイデアに対して、社内で議論されることになる。その議論は、テーマはもとより、記入欄の内容=つまり引き出し線の頭に記載された内容についての意見である。それらは、１つひとつの引き出し線の頭に、複数の意見があり、その意見に対して、更に複数の意見が出される。つまり１枚の過去の企画書に追記する形で、その後の議論は全てこの文書に記載することができるのである。今日、これらはIT技術を用いて、クラウド上にある、弊社株式会社デジタルコラボレーションズのckweb2 サーバに保存することができる。

自部署のアウトプット文書をモデルとして、設計の企画書と紐付けする


企画書の次にそれぞれの組織が業務を行うことになる。その時に、それぞれの組織の業務においてアウトプットする文書がある。今度はそれぞれの組織での過去の文書を対象とする。自組織の文書に新しい企画書の変更内容についての意見や注意点を引き出し線を書き、その頭に、内容を記述する。この時、企画書のアイデアに書かれている特徴点と自部書の記載した特徴点との間には参照関係を登録することを行う。

QPPモデルのベネフィット

これにより関係組織の考えに対して自部署の考えを関係づけて記録することができる。これらのことを繰り返すことで、文書が決定されていくプロセスにての考え方を記録することができる。最終決定したそれぞれの文書をサーバーに保管すればよく、その際に、過去の企画書と最終の企画書との関係に参照関係を登録する。このようにして、企画から設計、生産に関する自部署のアウトプット文書を作成しながら、考えたことを記録することができる。これにより、キーワード検索や文書のイメージをキーワードから検索表示し、同時に、文書作成途中の議論を繭の糸の如く、引き出すことができるのである。