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