構想設計の見直し方：構想設計の基礎知識5
投稿日：- 2017年04月20日
- ｜
カテゴリ： - 基礎知識
- ｜
tags：
前回は、VEを使ったコスト見積もりを解説しました。最終回の今回は、構想設計を見直し、基本設計や詳細設計につなげる方法を説明します。
1. モジュール構想の後に全体を見直す
図1は第2回で紹介した製品設計の全体の流れです。システム構想を行った後、モジュールごとに構想設計を行います。手順はシステムの全体構想と同様で、対象とする範囲がそれぞれのモジュールに限定されています。モジュール構想で具体的な技術手段が決まります。
この段階で、いったんシステム全体を振り返ってみてください。各モジュールは要求される仕様を満足しても、全体を組み合わせるとうまく動作しない、あるいは思いがけない問題が起こる場合があります。思い当たる節がある人も多いでしょう。次の章で、具体的な見直しの方法を紹介します。
2. 構想見直しの手順
図2はシステム構想をモジュール構想に基づいて修正していくフローチャートです。まずシステム構想によりモジュールに対する要求仕様が決まり、それに基づいてモジュール構想が行われ、具体的な手段が決まります。次に、具体的になったモジュールを仮想的に統合し、システムが稼働した場合のシミュレーション（机上検討）を行います。
リスクの抽出と評価では、表1に示すようなリスク対策表を作成します。FMEAという手法を活用したものです。記載の手順は、5ステップあります。
1：各構成要素に対する故障パターンを列挙
「故障モード」とは、構成要素の変化のパターンです。実際に被害をもたらす故障（トラブル）とその原因の間にある概念です。故障にはさまざまな形態があり、網羅的に取り上げることは不可能です。故障モードという概念を導入すると、抜け漏れを防止することができます。図3にプリンタの紙搬送ローラの場合を示します。
2：故障モードを引き起こす要因を抽出
システムの外部から受ける要因と、内部に発生する要因に大別します。前者はシステム停止中と動作中で、要因が異なる場合があります。後者は、主にシステムの他の部分から受ける影響です。可能性のあるものは全て取り上げます。
3：不具合の推測
故障モードから引き起こされる不具合を推測し、記述します。
4：リスクの評価
故障が起きた場合の被害の程度、起きる頻度、事前に検知できるかどうかの3つを定量化します。基本的には相対評価ではなく絶対評価で、5段階程度でランク付けします。3値の積の立方根をリスクの評価値とし、値が大きいものへの対策を検討します。注意点は、評価値は一つの目安であり、それだけで対策の要否を決めないことです。頻度は小さくても、被害が甚大な事故につながる可能性があれば、必ず対策を打ちます。
5：システムとしての対応策の検討
故障に対する対応策を記述します。対策はシステムに組み込んでも、組み込まずに人が介在しても構いません。あらゆるものを取り上げます。対策を取った場合のリスク評価を再度行い、評価値が十分に低くなったことを確認します。
対応策を取る場合、元のシステム構想の変更が必要になる可能性もあります。フローの最初に戻り、改めてシステム構想の内容を確認し、必要な場合は修正を加えます。
続きは、保管用PDFに掲載中。ぜひ、下記よりダウンロードして、ご覧ください。
3. ロバスト設計
保管用PDFに掲載中。ぜひ、下記よりダウンロードして、ご覧ください。
4. 人材育成
保管用PDFに掲載中。ぜひ、下記よりダウンロードして、ご覧ください。
5. おわりに
保管用PDFに掲載中。ぜひ、下記よりダウンロードして、ご覧ください。