<?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/sekkei-sinnsa/feed/" rel="self" type="application/rss+xml" />
	<link>https://rakuda0218blog.com</link>
	<description></description>
	<lastBuildDate>Fri, 15 Apr 2022 20:30:45 +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/475/</link>
					<comments>https://rakuda0218blog.com/475/#respond</comments>
		
		<dc:creator><![CDATA[布施　裕児]]></dc:creator>
		<pubDate>Wed, 13 Jan 2021 06:29:00 +0000</pubDate>
				<category><![CDATA[本格検証/設計審査]]></category>
		<category><![CDATA[設計審査]]></category>
		<category><![CDATA[お客様要求事項]]></category>
		<category><![CDATA[妥当性の確認]]></category>
		<category><![CDATA[リスク評価]]></category>
		<guid isPermaLink="false">https://rakuda0218blog.com/?p=475</guid>

					<description><![CDATA[まさしく、独自の目的・目標をもった期限付きの「プロジェクト」ですので、世間一般で言われているプロジェクトマネージメントの手法を使う事になります。 設計審査の体制例を上記のようにまとめました。 全関連部署が参加し、情報共有 [&#8230;]]]></description>
										<content:encoded><![CDATA[
<p>まさしく、<strong>独自の目的・目標をもった期限付きの「プロジェクト」</strong>ですので、世間一般で言われているプロジェクトマネージメントの手法を使う事になります。</p>



<figure class="wp-block-image size-large"><img fetchpriority="high" decoding="async" width="939" height="710" src="https://rakuda0218blog.com/wp-content/uploads/2021/01/image-15.png" alt="" class="wp-image-509" srcset="https://rakuda0218blog.com/wp-content/uploads/2021/01/image-15.png 939w, https://rakuda0218blog.com/wp-content/uploads/2021/01/image-15-300x227.png 300w, https://rakuda0218blog.com/wp-content/uploads/2021/01/image-15-768x581.png 768w" sizes="(max-width: 939px) 100vw, 939px" /></figure>



<p>設計審査の体制例を上記のようにまとめました。</p>



<ul class="wp-block-list"><li><span class="fz-20px"><strong>全関連部署が参加し、情報共有を行い、アクションアイテムや決裁を行う全体会議</strong></span></li><li><span class="fz-20px"><strong>問題点を明確にした上で少人数で突っ込んだ議論を行う分科会</strong></span></li></ul>



<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></li><li><a href="#toc2" tabindex="0">会議進行時の注意事項</a></li><li><a href="#toc3" tabindex="0">設計審査(クロージング）</a></li></ol>
    </div>
  </div>

<h2 class="wp-block-heading" id="全体会議"><span id="toc1">全体会議</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-blue-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">
<ol class="wp-block-list"><li><strong>お客様要求事項の更新、優先順位に議論が必要であれば実施</strong></li><li><strong>開発進捗状況</strong></li><li><strong>開発体制(議論の必要があれば実施）</strong></li><li><strong>量産性評価（品質Q/コストC/デリバリーD）</strong></li><li><strong>リスク評価（FMEA等）</strong></li></ol>
</div></div>



<p><strong><span class="fz-20px">１-1)お客様要求事項の更新</span></strong></p>



<p><strong>♦社内の要求事項の更新</strong></p>



<p>　お客様要求事項のリストを事前にリバイスしてもらい、当日は変更点のみ共有。優先順位に関して議論が出ればその場で協議</p>



<p><strong>♦お客様の要求事項の更新</strong></p>



<p>　試作品の説明、あるいは、お客様の評価結果を聞く際に要求事項を改めて確認する。その際には設計者が同行するのが望ましい。お客様の関連部署の要求事項は営業にフォローしてもらう。</p>



<p><strong><span class="fz-20px">1-2)開発進捗状況</span></strong></p>



<p>　要素技術進捗は結果と、目標値とのGap、今後の対応案を簡潔に。設計部門で議論できることは事前に議論しておく。</p>



<p>　試作品流動状況は責任部署から状況を簡潔に報告</p>



<p>　特許関係は、議論すべきことがあれば報告</p>



<p><strong><span class="fz-20px">1-3)開発体制</span></strong></p>



<p>　議論があれば実施</p>



<p><strong><span class="fz-20px">1-4)量産性評価（品質:Q、コスト:C、納期：D)　</span></strong></p>



<p>品質、お客様評価結果、コストC：製造によるF.S.評価、納期D：リードタイム</p>



<p><span class="bold-red">　<strong>目標に達しない場合には対策を考える必要はがあるが、コスト/品質/デリバリーは連動するところがあるので新しい考え方を導入する必要が出てくる。</strong></span></p>



<p>　<strong><span class="bold-red">そこは開発責任者が関係者を招集して別途対応を協議し、全体会議で報告する。その際に、設計審査の決裁者に相談することも大切。</span></strong></p>



<p><strong><span class="fz-20px"><span class="marker-under-red">お客様の評価結果は、妥当性の確認も含むので、出荷、輸送、納入、引き渡し、すべての工程で問題点を明確にし、対応を分科会で協議する。</span></span></strong></p>



<h2 class="wp-block-heading" id="会議進行時の注意事項"><span id="toc2">会議進行時の注意事項</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></li><li><strong>詳細は分科会の少人数で徹底議論。全体会議では問題点と対応内容を簡潔に報告</strong></li><li><strong>詳細な議論は分科会で良いが、会議の席で打ち合わせ日を決める。</strong></li><li><strong>記録者は司会者とは別に確保する。(記録者は参加者の持ち回りでもOK）</strong></li><li><strong>会議終了時に、記録者に会議の議決内容を確認してもらう。（ホワイトボードの手書きでもOK)</strong></li><li><strong>レビュ-内容は文章（議事録）にして参加できなかった関係者にもメール発信。</strong></li></ol>
</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/10016/" title="会議の無駄を省き、円滑に本格検証を進める技術、ファシリテーションについて" 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/2022/02/5083603_s-160x90.jpg" class="blogcard-thumb-image internal-blogcard-thumb-image wp-post-image" alt="" srcset="https://rakuda0218blog.com/wp-content/uploads/2022/02/5083603_s-160x90.jpg 160w, https://rakuda0218blog.com/wp-content/uploads/2022/02/5083603_s-120x68.jpg 120w, https://rakuda0218blog.com/wp-content/uploads/2022/02/5083603_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">会議の無駄を省き、円滑に本格検証を進める技術、ファシリテーションについて</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">2022.02.05</div></div></div></div></a>
</div></figure>



<h2 class="wp-block-heading" id="設計審査-クロージング"><span id="toc3">設計審査(クロージング）</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-amber-border-color">
<ol class="wp-block-list" id="block-7f8a5b69-0475-469f-b9fd-7c6439ae84dc"><li><strong>通常は、100%の状態で終了とはならず、残課題が残る。</strong></li><li><strong>期限日の前に延長するか、中断するか、量産移管するか決裁者に判断を仰ぐ。</strong></li><li><strong>判断量産移管に進む場合には残課題の整理、役割分担を明確に。</strong></li></ol>
</div>



<p>開発を進めても必ず、残課題が残ります。そこを明確にしておかないと、開発がいつまでも抜けられない。製造部門で実施した方が良い物をいつまでも開発が抱えていたりしますので、クロージングはそういった意味でも非常に大切です。</p>
]]></content:encoded>
					
					<wfw:commentRss>https://rakuda0218blog.com/475/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>効果的なデザインレビューの進め方。大切なポイント。6選。</title>
		<link>https://rakuda0218blog.com/278/</link>
					<comments>https://rakuda0218blog.com/278/#respond</comments>
		
		<dc:creator><![CDATA[布施　裕児]]></dc:creator>
		<pubDate>Fri, 08 Jan 2021 03:36:00 +0000</pubDate>
				<category><![CDATA[デザインレビュー]]></category>
		<category><![CDATA[設計審査]]></category>
		<guid isPermaLink="false">https://rakuda0218blog.com/?p=278</guid>

					<description><![CDATA[目次 デザインレビューデザインレビューの目的参加メンバーデザインレビュー内容要求項目から要素技術/開発目標の進捗状況過去の不具合対策が反映されているか他社特許の抵触有無、特許戦略の明確化マージン評価量産性評価（品質/コス [&#8230;]]]></description>
										<content:encoded><![CDATA[

  <div id="toc" class="toc tnt-number toc-center tnt-number border-element"><input type="checkbox" class="toc-checkbox" id="toc-checkbox-4" checked><label class="toc-title" for="toc-checkbox-4">目次</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></li></ol></li><li><a href="#toc4" tabindex="0">デザインレビュー内容</a><ol><li><a href="#toc5" tabindex="0">要求項目から要素技術/開発目標の進捗状況</a></li><li><a href="#toc6" tabindex="0">過去の不具合対策が反映されているか</a></li><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">デザインレビューで心がけるべき大切な事、6選</a></li></ol>
    </div>
  </div>

<h2 class="wp-block-heading"><span id="toc1">デザインレビュー</span></h2>



<h3 class="wp-block-heading"><span id="toc2">デザインレビューの目的</span></h3>



<p class="has-text-align-center"><strong><span class="fz-20px"><span class="marker-red">技術的な何故を開発メンバーで協議しておく事が必要で、それが</span></span><span class="marker-red"><span class="fz-22px"><span class="fz-20px">一番大きな目的です。</span></span></span></strong></p>



<p><span class="fz-20px"><span class="fz-18px">　実務上はデザインレビューの結果を開発計画にまとめる事。開発計画を関連部署に説明し、合意を得て開発を進める事になります。</span></span></p>



<p>　　<strong><span class="fz-20px"><span class="marker-under-blue">関連部署に説明し、レビューを行い、進め方の合意を得るのをデザインレビューと呼ぶ方も多いと思いますが、その場合は、製造なり、品質保証なり、営業の観点の議論になり、技術的な深いレビューは出来ま</span></span><span class="fz-20px"><span class="marker-under-blue">せん。</span></span></strong></p>



<p><span class="fz-18px"><strong>　</strong>なので、まえもって、設計/開発のメンバーで徹底的に、その設計の根拠、技術的な内容を深く議論することが大切になります。</span></p>



<h3 class="wp-block-heading"><span id="toc3">参加メンバー</span></h3>



<p class="has-text-align-center"><strong><span class="fz-20px"><span class="marker-under">開発メンバ（少人数、最低2人、決裁者の出席は必須）で詳細なレビューを行う。</span></span></strong></p>



<p>　参加メンバーを絞り、少数で有効な議論をするのが大切です。他部署メンバーとプロト機／予察評価を共同で実施したような場合は当然、他部門のメンバーも参加してもらう必要があります。</p>



<h2 class="wp-block-heading"><span id="toc4">デザインレビュー内容</span></h2>



<div class="wp-block-cocoon-blocks-tab-caption-box-1 tab-caption-box block-box has-border-color has-red-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></div><div class="tab-caption-box-content block-box-content box-content">
<ul class="wp-block-list"><li><span class="fz-20px"><span class="bold-red"><strong>要求項目からの要素技術/開発目標の進捗状況</strong></span></span></li><li><span class="fz-20px"><span class="bold-red"><strong>過去の不具合対策が反映されているか？</strong></span></span></li><li><span class="fz-20px"><span class="bold-red"><strong>他社特許の抵触有無、特許戦略の明確化</strong></span></span></li><li><span class="fz-20px"><span class="bold-red"><strong>マージン評価</strong></span></span></li><li><span class="fz-20px"><span class="bold-red"><strong>量産性評価（品質/コスト/納期）</strong></span></span></li><li><span class="fz-20px"><span class="bold-red">リスク評価</span></span></li></ul>
</div></div>



<h3 class="wp-block-heading"><span id="toc5">要求項目から要素技術/開発目標の進捗状況</span></h3>



<ul class="wp-block-list"><li>要素技術の進捗状況確認。</li><li>開発目標の達成状況(達成/未達）</li><li>問題点の特定と修正。</li></ul>



<h3 class="wp-block-heading"><span id="toc6">過去の不具合対策が反映されているか</span></h3>



<p>　この場合、設計上のレビューですので、具体的に物理、化学的な事が原因で発生した不具合について、確実に対策が盛り込まれているかレビューすることになります。</p>



<div class="wp-block-cocoon-blocks-blank-box-1 blank-box block-box has-background has-border-color has-watery-yellow-background-color has-amber-border-color">
<p><strong>過去の不具合も、物理的な、あるいは化学的な現象と、人の行動と、仕事の進め方に分けて、原因を追究し、<span class="fz-20px"><span class="marker-under-red">一般的な、他の分野に応用できるような形でまとめておく必要があります。そうしないと、当該の問題にしか対応できず、応用範囲の狭い物になります。</span></span></strong></p>
</div>



<p> <span style="text-align: -webkit-match-parent;">詳しくは</span>以下の記事<span style="text-align: -webkit-match-parent;">を参照ください。</span> </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/1788/" title="未然防止/予防対策に必要な過去のトラブルの上位概念化。一般化。でもどうすれば良い？そのコツ、秘策を紹介します。" 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 loading="lazy" decoding="async" width="160" height="90" src="https://rakuda0218blog.com/wp-content/uploads/2021/02/1134969_s-1-160x90.jpg" class="blogcard-thumb-image internal-blogcard-thumb-image wp-post-image" alt="" srcset="https://rakuda0218blog.com/wp-content/uploads/2021/02/1134969_s-1-160x90.jpg 160w, https://rakuda0218blog.com/wp-content/uploads/2021/02/1134969_s-1-120x68.jpg 120w, https://rakuda0218blog.com/wp-content/uploads/2021/02/1134969_s-1-320x180.jpg 320w" sizes="(max-width: 160px) 100vw, 160px" /></figure><div class="blogcard-content internal-blogcard-content"><div class="blogcard-title internal-blogcard-title">未然防止/予防対策に必要な過去のトラブルの上位概念化。一般化。でもどうすれば良い？そのコツ、秘策を紹介します。</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 loading="lazy" 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.02.05</div></div></div></div></a>
</div></figure>



<h3 class="wp-block-heading"><span id="toc7">他社特許の抵触有無、特許戦略の明確化</span></h3>



<ul class="wp-block-list"><li>製品開発の場合は必須</li><li>プロセス開発の場合は侵害検証の可能性は少ないので必須ではない。</li></ul>



<h3 class="wp-block-heading"><span id="toc8">マージン評価</span></h3>



<p><strong><span class="fz-20px">●材料加工の場合</span></strong></p>



<p>　例えば、研磨の場合には加工圧力やスラリー濃度、PAD寿命、研削の場合は砥石の押し込量、砥石寿命等、量産時に管理幅を設定する必要がある項目のマージン評価結果、</p>



<p>　<strong><span class="fz-20px"><span class="marker-blue">また、特性がそのパラメーターに感度があるのは何故か？その原因まで深堀することが大切です。何故なら、パラメーターの感度は状況が変われば変わることは良くある話で、その時に深堀が出来ていないと、何を、どう考えればよいのか、手が出なくなるためです。</span></span></strong></p>



<p><strong><span class="fz-20px">●組み立て加工品の場合</span></strong></p>



<p>　過負荷評価（シミュレーション）やプロト機での評価（振動試験　etc）</p>



<h3 class="wp-block-heading"><span id="toc9">量産性評価（品質/コスト/納期）</span></h3>



<ul class="wp-block-list"><li>開発コンセプトに基づいて量産性の評価を行う。</li><li>他部署と協議をするための原案を作成する。</li><li>本格的な検証は他部署を巻き込んだ量産設計の所で検証していくことになる。</li></ul>



<p>　<strong><span class="marker-under">組み立て加工の場合、既存の製品と部品/技術の共有化が図れているかのチェックが必要。コストだけでなく、納期(デリバリー）に大きく影響します。</span></strong></p>



<h3 class="wp-block-heading"><span id="toc10">リスク評価</span></h3>



<div class="wp-block-cocoon-blocks-blank-box-1 blank-box block-box has-background has-border-color has-watery-yellow-background-color has-amber-border-color">
<p><strong><span class="fz-20px">デザインレビューの段階では、<span class="marker-under-red">新規に追加した項目（開発した項目）に関して</span>重点的に、<span class="marker-under-red">重大クレームにつながる原因をFTAやロジックツリーの考え方で協議し、レビューする事が大切</span>です。</span></strong></p>



<p><strong><span class="fz-20px"><span class="marker-under-red">また、過去の不具合を一般化、上位概念化し、未然防止に使える形にして置き、これが設計に反映されているかレビューすることが大切です。</span></span></strong></p>



<p><strong><span class="fz-20px">これをリスク評価と呼べば、このようなリスク評価は必要だと思います。</span></strong></p>
</div>



<p>　<strong><span class="marker-under"><span class="fz-22px"><span class="fz-18px">ISO上は、リスク評価を各ステージで実施するように要求されています。</span></span>ただ、デザインレビューの段階で細かなFEMAなどを実施しても、その後、細かな所は変わっていくのであまり意味が有りません。</span><span class="fz-22px"><span class="marker-under"><span class="fz-18px">制約事項、あるいは市場から退場をせざる負えないノックアウト要因があるのなら開発の前提条件、制約事項、要望事項として洗い出しておくべきで、リスク評価とは異なります。</span></span></span></strong></p>



<p>　<strong><span class="fz-20px"><span class="bold-red">デザインレビューの段階では、その設計そのものが、重大クレームや、制約事項に対して適切かのレビューを行う事が大切となります。</span></span></strong></p>



<p>一方、<strong><span class="fz-22px"><span class="marker">量産前にはFTAとFMEAを組み合わせたような詳細なリスク評価は絶対に必要です。</span></span></strong></p>



<p>その段階では、<strong><span class="fz-22px"><span class="marker-under-red"><span class="fz-18px">量産化を見据えた管理方法の検討段に入っているので、具体的に、管理方法にリスク評価の結果が反映でき</span></span></span><span class="marker-under-red">るので、非常に有効です。</span></strong></p>



<h2 class="wp-block-heading"><span id="toc11">デザインレビューで心がけるべき大切な事、6選</span></h2>



<p>　<strong><span class="fz-28px"><span class="marker"><span class="fz-18px"><span class="fz-20px">開発の目的を達成できると自信が持てる。行けそうだと思えることが大切</span></span></span></span><span class="fz-20px"><span class="marker"><span class="fz-18px">です</span>。</span></span></strong></p>



<p>　<strong><span class="fz-20px"><span class="marker">そうでなければ、人の意見に左右され、議論になりません。自信が持てなければ調査、実験に戻りましょう。</span></span></strong></p>



<p>本格検証は、このデザインの検証になりますのでこのデザインレビューで骨組みはほぼ決まります。その為、設計の問題点を想定範囲を広く、感度良く気が付けるようにしておく事が大切です。</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-amber-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 class="fz-20px">6選</span></span></div><div class="tab-caption-box-content block-box-content box-content">
<ol class="wp-block-list"><li><strong><span class="fz-20px">お客様の使用工程を良く知る。</span></strong><ul><li>どういった使われ方をしているのか、どういったことが想定されるのか？（社内であれば協議可能だか、お客様であれば協議は実質不可能）</li></ul></li><li><strong><span class="fz-20px">実績のある問題のない機種との相違点、共通点は何か？使用環境に変化はあるか？</span></strong><ul><li>相違点に関して、重点的にレビュー</li></ul></li><li><strong><span class="fz-20px">重大クレーム、品質トラブルを想定し、設計をレビューする</span></strong>。<strong>（リスク対応）</strong><ul><li>どうなれば、重大クレーム、あるいは品質トラブルにつながるか？</li><li>発生頻度や影響度を考えた時、現状の設計で十分か？</li></ul></li><li><strong><span class="fz-20px">過去の不具合を一般化、上位概念化して未然防止に使える形にしておく</span></strong></li><li><strong><span class="fz-20px">マージン評価、過負荷評価</span></strong><ul><li>プロセス開発の場合は技術的な深堀を行う。具体的には、マージン評価、安定性評価にとどまらず、特性がそのパラメーターに敏感なのは何故か？</li></ul></li><li><strong><span class="fz-20px"><span class="marker-under-red">量産できる。行ける。と自信が持てる事。</span>（QCDの未通しも含む）</span></strong></li></ol>
</div></div>



<p>また、デザインレビューは、改まって実施するのは一回で良いでしょうが、同僚や、上司とは非公式な打ち合わせはタイミングをみてどんどん実施する事も大切な事と思っています。</p>
]]></content:encoded>
					
					<wfw:commentRss>https://rakuda0218blog.com/278/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-17 17:39:19 by W3 Total Cache
-->