<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>設計の標準化 | 技術力向上カウンセリングオフィス</title>
	<atom:link href="https://rakuda0218blog.com/tag/design-standardization/feed/" rel="self" type="application/rss+xml" />
	<link>https://rakuda0218blog.com</link>
	<description></description>
	<lastBuildDate>Tue, 22 Nov 2022 19:25:00 +0000</lastBuildDate>
	<language>ja</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.8.3</generator>
	<item>
		<title>機械設計とプロセス開発の標準化の秘訣</title>
		<link>https://rakuda0218blog.com/3684/</link>
					<comments>https://rakuda0218blog.com/3684/#respond</comments>
		
		<dc:creator><![CDATA[布施　裕児]]></dc:creator>
		<pubDate>Tue, 09 Mar 2021 23:11:00 +0000</pubDate>
				<category><![CDATA[本格検証/設計審査]]></category>
		<category><![CDATA[設計の属人化]]></category>
		<category><![CDATA[設計の流用化]]></category>
		<category><![CDATA[設計の標準化]]></category>
		<guid isPermaLink="false">https://rakuda0218blog.com/?p=3684</guid>

					<description><![CDATA[設計や開発は独創的な発想が必要で標準化は向かない。と言われる方もいます。 確かに、そういった側面は有りますが、すべてに新たな発想が必要な訳ではありません。 過去の事例、図面などの成果物、仕事の進め方/システムなど、標準化 [&#8230;]]]></description>
										<content:encoded><![CDATA[
<p>設計や開発は独創的な発想が必要で標準化は向かない。と言われる方もいます。</p>



<p>確かに、そういった側面は有りますが、すべてに新たな発想が必要な訳ではありません。</p>



<p>過去の事例、図面などの成果物、仕事の進め方/システムなど、標準化出来る所は標準化すべきです。</p>



<p>具体的な設計にしても、流用設計を極力多くして、多くの製品で、極力共通する部品、あるいは技術を使う事を考え、新たな発想が必要な部分は極力少なくすることが大切になってくると思っています。</p>




  <div id="toc" class="toc tnt-number toc-center tnt-number border-element"><input type="checkbox" class="toc-checkbox" id="toc-checkbox-2" checked><label class="toc-title" for="toc-checkbox-2">目次</label>
    <div class="toc-content">
    <ol class="toc-list open"><li><a href="#toc1" tabindex="0">設計開発の標準化・流用設計の必要性について</a><ol><li><a href="#toc2" tabindex="0">効率化</a></li><li><a href="#toc3" tabindex="0">業務の属人化を防ぐ</a><ol><li><a href="#toc4" tabindex="0">業務が属人化する要因、メリット、デメリットは？</a></li><li><a href="#toc5" tabindex="0">業務の属人化を防ぐには？</a></li></ol></li></ol></li><li><a href="#toc6" tabindex="0">設計開発の標準化の秘訣</a><ol><li><a href="#toc7" tabindex="0">メンバーの意識合わせ</a></li><li><a href="#toc8" tabindex="0">情報の標準化</a></li><li><a href="#toc9" tabindex="0">標準化する物、しない物を決める</a></li><li><a href="#toc10" tabindex="0">一度ルール化したら使う、使わせて改善して行く</a></li></ol></li><li><a href="#toc11" tabindex="0">流用設計（機械設計）</a><ol><li><a href="#toc12" tabindex="0">流用設計の注意点</a></li></ol></li><li><a href="#toc13" tabindex="0">プロセス開発の標準化について</a></li><li><a href="#toc14" tabindex="0">まとめ</a></li></ol>
    </div>
  </div>

<h2 class="wp-block-heading" id="設計開発の流用化-標準化の必要性について"><span id="toc1">設計開発の標準化・流用設計の必要性について</span></h2>



<h3 class="wp-block-heading" id="効率化"><span id="toc2">効率化</span></h3>



<p>圧倒的に業務の効率化です。<strong>物を検索している時間、無駄な設計、および設計検証を省ける効果等を考えればやらない手はありません。</strong></p>



<p class="has-text-align-center"><strong><span class="fz-20px"><span class="marker-under-red">ムダを省くのはコストダウンの常とう手段でもあります。</span></span></strong></p>



<p>標準化を進めると、設計者の自由な発想を妨げる、技術的な発展につながらない。と主張される方も多いですが、考え方を逆にした方が良いと思っています。</p>



<div class="wp-block-cocoon-blocks-tab-caption-box-1 tab-caption-box block-box has-background has-border-color has-watery-yellow-background-color has-orange-border-color"><div class="tab-caption-box-label block-box-label box-label"><span class="tab-caption-box-label-text block-box-label-text box-label-text"><strong><span class="fz-20px">なぜ、標準化、流用設計が必要か？</span></strong></span></div><div class="tab-caption-box-content block-box-content box-content">
<p><strong>クリエイティブな業務に極力集中し、効率化を図り、設計/開発の質を向上するため。</strong></p>
</div></div>



<h3 class="wp-block-heading" id="業務の属人化を防ぐ"><span id="toc3">業務の属人化を防ぐ</span></h3>



<h4 class="wp-block-heading" id="業務が属人化する要因-メリット-デメリットは"><span id="toc4">業務が属人化する要因、メリット、デメリットは？</span></h4>



<p><strong>その業務で特定の人がいないと勧められない状態を属人化と言うようです。仕事が組織ではなく人についている状態です。</strong></p>



<p>私自身、梱包容器の仕事を開始した当初は、担当一人で社内でも誰も経験したことのない開発項目でしたのでまさしく業務が属人化してしまった経験が有ります。</p>



<p>業務が属人化するのは、短期的には効率的な面もありますが、長期的にはデメリットの方が大きいです。</p>



<p>一番のデメリットは、業務内容を周りは担当者と同じレベルで理解していないので、適切なコメントやアドバイスが出来なくなり、誰もフォロー出来なくなる。</p>



<p><strong>担当者は性格の問題もあるでしょうが、説明、共有化するのも無駄、あるいは時間が取れないと考えてしまい、ますます、自分がやらねば。と自分を追い込んでしまうといった、負のスパイラルに陥っていまう。という事が起こります。（私の場合はそうでした）</strong></p>



<p>自分の地位を守るために業務を抱え込むような場合も一般には有るかもしれません。</p>



<p>後、得られた知識が個人の物になりますので、会社の知識/知見として蓄積されません。後任が来ればまたゼロから始まることになります。</p>



<h4 class="wp-block-heading" id="業務の属人化を防ぐには"><span id="toc5">業務の属人化を防ぐには？</span></h4>



<p>色々な事が考えられますが、基本はマネージングの問題だと思います。誰もフォロー出来ない状態になるとそもそも、開発の進め方、システムが機能しません。</p>



<p>その為には、やはり、システムがしっかり確立されておりそのシステムに沿って進める事が大切です。<strong><span class="fz-20px"><span class="marker">システムが確立されて、しっかり運用することで属人化の問題点が明確に見えてきます。</span></span></strong></p>



<p>デザインレビューや本格検証が機能しないと思うのであれば、人員の補強を図るなど何らかの対応を取る必要が有ります。</p>



<p>ただし、単純に人員を増加すれば上手く行くとも限りません。本当に必要な対策は何か？良く考える事が大切になります。</p>



<p>知識を会社の知識としていくにはやはり標準化が必要となってきます。</p>



<h2 class="wp-block-heading"><span id="toc6">設計開発の標準化の秘訣</span></h2>



<div class="wp-block-cocoon-blocks-tab-caption-box-1 tab-caption-box block-box has-background has-border-color has-watery-blue-background-color has-cyan-border-color"><div class="tab-caption-box-label block-box-label box-label"><span class="tab-caption-box-label-text block-box-label-text box-label-text"><span class="fz-20px"><strong>４つ標準化の</strong></span><strong><span class="fz-20px">秘訣</span></strong></span></div><div class="tab-caption-box-content block-box-content box-content">
<ol class="wp-block-list">
<li><span class="fz-20px"><strong>メンバーの意識合わせ、</strong></span></li>



<li><span class="fz-20px"><strong>使える状態にするための情報の整備</strong></span></li>



<li><span class="fz-20px"><strong>標準化する物</strong>、<strong>しない物を決める</strong>。</span></li>



<li><span class="fz-20px"><strong>一度ルール化したら、使う、使わせ</strong></span><strong><span class="fz-20px">て改善して行く。</span></strong></li>
</ol>
</div></div>



<h3 class="wp-block-heading"><span id="toc7">メンバーの意識合わせ</span></h3>



<p>まずは、メンバーに標準化が必要だという事を良く説明し、意識を合わせる必要が有ります。</p>



<p>気が乗らない人がいるのは仕方がないとして、実施する事を承諾してもらう事は必要です。実際にやって効果が実感できれば、反対意見は自然と消滅します。</p>



<h3 class="wp-block-heading"><span id="toc8">情報の標準化</span></h3>



<p class="has-text-align-center"><strong><span class="fz-20px"><span class="fz-22px"><span class="marker">情報は、エンジニアにとって非常に大切な仕事道具です。</span></span></span></strong></p>



<p><strong>設計開発に使うすべての情報、例えば、過去のクレーム事例、部品表（ＢＯＭ）、競合他社情報、過去の開発情報などです。</strong></p>



<p><strong><span class="fz-20px">5S活動同様、<span class="marker-under-blue">必要な物が、必要な時に、必要な分だけ、誰でも使えるように維持管理する必要が有ります。</span></span></strong></p>



<p><strong><span class="fz-20px">従って、設計/開発の標準化を進めるにあたっては、<span class="marker-under-blue">情報の整理整頓を行う事が初めの一歩になります。</span></span></strong></p>



<p>注意点は以下のようになります。</p>



<div class="wp-block-cocoon-blocks-tab-caption-box-1 tab-caption-box block-box has-background has-border-color has-watery-yellow-background-color has-orange-border-color"><div class="tab-caption-box-label block-box-label box-label"><span class="tab-caption-box-label-text block-box-label-text box-label-text"><strong><span class="fz-20px">情報の標準化の注意点</span></strong></span></div><div class="tab-caption-box-content block-box-content box-content">
<ul class="wp-block-list">
<li><strong>共通認識、用語の統一を図る。</strong></li>



<li><strong>分類は最低限に、「その他」を作ると破綻する。</strong></li>



<li><strong>コード化できるものはコード化する。</strong></li>



<li><strong>標準化しない物、標準化する物を決める。（整理整頓）</strong></li>
</ul>
</div></div>



<p>具体的にどう進めるのが良いのかについては別に記事にしていますのでそちらを参照願います。</p>



<figure class="wp-block-embed is-type-wp-embed is-provider-ラクダブログ wp-block-embed-ラクダブログ"><div class="wp-block-embed__wrapper">

<a href="https://rakuda0218blog.com/7874/" title="設計・開発情報の共有化で大切な事。5選" class="blogcard-wrap internal-blogcard-wrap a-wrap cf"><div class="blogcard internal-blogcard ib-left cf"><div class="blogcard-label internal-blogcard-label"><span class="fa"></span></div><figure class="blogcard-thumbnail internal-blogcard-thumbnail"><img decoding="async" width="160" height="90" src="https://rakuda0218blog.com/wp-content/uploads/2021/11/22239576_s-160x90.jpg" class="blogcard-thumb-image internal-blogcard-thumb-image wp-post-image" alt="" srcset="https://rakuda0218blog.com/wp-content/uploads/2021/11/22239576_s-160x90.jpg 160w, https://rakuda0218blog.com/wp-content/uploads/2021/11/22239576_s-120x68.jpg 120w, https://rakuda0218blog.com/wp-content/uploads/2021/11/22239576_s-320x180.jpg 320w" sizes="(max-width: 160px) 100vw, 160px" /></figure><div class="blogcard-content internal-blogcard-content"><div class="blogcard-title internal-blogcard-title">設計・開発情報の共有化で大切な事。5選</div><div class="blogcard-snippet internal-blogcard-snippet">設計/開発において、技術情報は大切な商売道具ですので、いつでも使える状態にしておく事は非常に大切です。個人で使う分には頭に入っている事も多いので問題ない？ですが、情報は関係者で閲覧できるようになって初めて有効になります。その為に大切なことを...</div></div><div class="blogcard-footer internal-blogcard-footer cf"><div class="blogcard-site internal-blogcard-site"><div class="blogcard-favicon internal-blogcard-favicon"><img decoding="async" src="https://www.google.com/s2/favicons?domain=https://rakuda0218blog.com" alt="" class="blogcard-favicon-image internal-blogcard-favicon-image" width="16" height="16" /></div><div class="blogcard-domain internal-blogcard-domain">rakuda0218blog.com</div></div><div class="blogcard-date internal-blogcard-date"><div class="blogcard-post-date internal-blogcard-post-date">2021.11.08</div></div></div></div></a>
</div></figure>



<h3 class="wp-block-heading"><span id="toc9">標準化する物、しない物を決める</span></h3>



<p>活動のすべてを標準化しようとすると破綻をきたしますし、すべてを標準化する必要もありません。標準化するものと必要のないものをまずはっきりさせることが大切です。</p>



<ol class="wp-block-list">
<li><span class="fz-20px"><strong>標準化するには繰り返し使われるか？。</strong></span></li>



<li><span class="fz-20px"><strong>関係者で共有する価値があるか？</strong></span></li>
</ol>



<p><strong>の観点で決めて行く事が大切だと思います。<span class="marker-under">繰り返しの頻度だけで見れば1年に1度実施するかどうか、といった作業でも必ず実施されるものであれば標準化する必要が有るでしょう。</span></strong>たまに実施する物程、標準化した方が良いとも言えます。</p>



<p>特に初めは範囲を狭くして、まずは運用させて、問題点を洗い出してから広げて行くのが良いと思います。</p>



<p>例えば、実際に試作品に関しては標準化するが、アイデアを遂行している間は一切管理しないと決めるなどです。QMS（品質管理システム）は構築する必要が有るでしょう。</p>



<p class="has-text-align-center"><strong><span class="fz-20px">小さく初めて大きく育てる。の考えが大切だと思います。</span></strong></p>



<h3 class="wp-block-heading"><span id="toc10">一度ルール化したら使う、使わせて改善して行く</span></h3>



<p><span class="fz-18px">標準化は実際に進めると、非常に難しく、時間もかかります。準備期間の間は逆に効率が落ちますし、導入後も、皆が使えるようになるには時間がかかります。</span></p>



<p><strong>途中何度か心が折れかけることも多いですが、標準化については時間がかかっても必ず完成できます。一旦上手く行くと、それまで、否定的な事を言っていた人も便利さに気が付き協力者に代わります。</strong></p>



<p>その為には、<strong><span class="fz-20px"><span class="marker-under-red">遂行担当は自分だとリーダーが自覚するのが出発点になると思います。</span></span></strong></p>



<p>これを実施しないと何も変わりません。<strong><span class="marker-under-red"><span class="fz-20px">「成功の秘訣は成功するまで続ける事」</span>といった言葉があったかと思いますが、標準化においてはその考えが非常に大切だと思っています。</span></strong></p>



<h2 class="wp-block-heading"><span id="toc11">流用設計（機械設計）</span></h2>



<blockquote class="wp-block-quote has-text-align-left is-layout-flow wp-block-quote-is-layout-flow">
<p><strong>（設計の流用化を進める上で）最も重要なのは現在までの<span class="marker-under-red"><span class="fz-20px">設計成果物の２Sを用い</span></span>、専用の部品・ユニット・製品「カタログ」を完成させ、この「標準カタログ」を設計者同士で共有し、ネタ帳であるこのカタログから仕様を満足する部品、ユニットを検索して流用化を図る事です。</strong></p>
<cite><span class="fz-14px"><span class="fz-16px">BOMで実践、設計部門改革バイブル（株）大塚商会　谷口　潤氏（著）P111より</span></span></cite></blockquote>



<p>谷口氏は、標準カタログから、各部品、ユニットまで、たどり着ける情報の整理（階層化）が大切と言われています。</p>



<p><span class="fz-14px"><span class="fz-18px"><strong>BOMで実践、設計部門改革バイブル（株）大塚商会　谷口　潤氏（著）</strong></span></span>は機械設計の標準化に関して、色々なノウハウが記載されています。一読をお勧めいたします。</p>



<p>確かに、社内で何か新しいものを検討する場合、過去の社内情報をまずあたりに行くので、情報が整理されている事は大切だと思います。</p>



<h3 class="wp-block-heading"><span id="toc12">流用設計の注意点</span></h3>



<p>しかし、十分に実績がある部品、部材でも、別の製品に使う場合には、まったく同じ条件で使用できるとは限りません。出来ないと考えた方が良いでしょう。</p>



<p>従って、流用する場合には、実績が十分だから大丈夫ではなくて、今回の設計は何が違うか？を確認し、それに対して検証（シミュレーションや計算でも良い）することは必要になります。</p>



<p><strong><span class="marker">結局、デザインレビューで流用設計と新規設計を明確にすることが大切だと思います。</span></strong></p>



<h2 class="wp-block-heading" id="プロセス開発の流量化-標準化について"><span id="toc13">プロセス開発の標準化について</span></h2>



<div class="wp-block-cocoon-blocks-tab-caption-box-1 tab-caption-box block-box has-background has-border-color has-watery-green-background-color has-green-border-color"><div class="tab-caption-box-label block-box-label box-label"><span class="tab-caption-box-label-text block-box-label-text box-label-text"><span class="fz-20px">開発業務の標準化</span></span></div><div class="tab-caption-box-content block-box-content box-content">
<p class="has-text-align-center"><strong><span class="marker">ISOのQMS（品質マネージメントシステム）を構築する事を言っています。</span></strong></p>



<p><strong>標準化というには、これは共通の方法で使える設計、開発方法だというのが無いと共通化とはいえません。</strong>そういった目的で発達してきたのが<span class="bold-red"><strong><strong>ISO</strong></strong></span>などの規格だと思っています。<strong>ただ、この規格は具体的な方法は一切記載されていません。各職場での使いこなしが必要です。</strong>私のブログのメインテーマになっています。</p>
</div></div>



<div class="wp-block-cocoon-blocks-tab-caption-box-1 tab-caption-box block-box has-background has-border-color has-watery-green-background-color has-green-border-color"><div class="tab-caption-box-label block-box-label box-label"><span class="tab-caption-box-label-text block-box-label-text box-label-text"><span class="fz-20px">検証方法の標準化</span></span></div><div class="tab-caption-box-content block-box-content box-content">
<p><strong>「実験計画法」</strong>や<strong>「品質工学」</strong>と呼ばれる方法がありそのような考え方を社内に取り入れて適用できないか考えてみるのは大切だと思います。</p>



<p>ただ、<strong>具体的な対策や方策を捻る出すのは、<span class="marker-under-blue">「目の付け所」</span>を共有化することが大切</strong>と考えています。</p>



<p>例えば、加工の場合は<strong>均一性や異物混入、経時変化による劣化、寿命、</strong>個々の技術であれば更にノウハウはあるでしょう。いずれにしても具合に社内でノウハウを蓄積して行くことが大切と思います。</p>
</div></div>



<div class="wp-block-cocoon-blocks-tab-caption-box-1 tab-caption-box block-box has-background has-border-color has-watery-green-background-color has-green-border-color"><div class="tab-caption-box-label block-box-label box-label"><span class="tab-caption-box-label-text block-box-label-text box-label-text"><span class="fz-20px">過去の技術の見える化</span></span></div><div class="tab-caption-box-content block-box-content box-content">
<p><strong>過去の膨大な開発設計情報を見える化して見たい物がすぐに出てくるようなシステム作りです。</strong></p>



<p>対象人数が少なく、資料も少ない場合はまだ対応可能ですが、対象範囲が広がると極端に難しくなります。AI技術のさらなる発展に期待したいです。</p>
</div></div>



<h2 class="wp-block-heading" id="まとめ"><span id="toc14">まとめ</span></h2>



<div class="wp-block-cocoon-blocks-blank-box-1 blank-box block-box has-background has-border-color has-watery-yellow-background-color has-orange-border-color">
<ol class="wp-block-list">
<li><strong>設計開発の標準化の秘訣</strong>
<ul class="wp-block-list">
<li><strong>メンバーの意識合わせが前提条件</strong></li>



<li><strong>情報の整理整頓が最初の一歩</strong></li>



<li><strong>標準化する物、しない物を決める。</strong></li>



<li><strong>ルール化したら使わせる。使いながら改善。</strong></li>
</ul>
</li>



<li><strong>機械設計の流量設計</strong>
<ul class="wp-block-list">
<li><strong>実績（前例）と今回（新規設計）の相違点、その影響の検証</strong>、<strong>同じものは二つ無い</strong></li>
</ul>
</li>



<li><strong>プロセス開発の標準化</strong>
<ul class="wp-block-list">
<li><strong>業務の進め方（開発計画書　等）（QMSの構築）</strong></li>



<li><strong>専門知識の教育、目の付け所の共有</strong></li>



<li><strong>過去の技術の見える化（IT技術駆使）</strong></li>
</ul>
</li>
</ol>
</div>



<p></p>
]]></content:encoded>
					
					<wfw:commentRss>https://rakuda0218blog.com/3684/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
	</channel>
</rss>

<!--
Performance optimized by W3 Total Cache. Learn more: https://www.boldgrid.com/w3-total-cache/

Disk: Enhanced  を使用したページ キャッシュ

Served from: rakuda0218blog.com @ 2025-10-20 17:40:25 by W3 Total Cache
-->