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