ロバスト性向上のための開発目標管理 (重要ポイント6選)
製造品質不良による市場不具合は特定ロットに限定されていることが多いのに対して、設計仕様に関する市場不具合は規模が大きくなったり、あるレベルの不具合率が下がらないなど影響が大きくなることが多々あります。そのような市場不具合を防ぐには、設計仕様のロバスト性（頑健性）を高めることが有効です。
本コラムでは、ロバスト性を向上するための開発目標の管理の考え方について説明したいと思います。
目次
１．ロバスト性の高い仕様とは？
「ロバスト性（頑健性）が高い」とは、様々な負荷や外乱に対する耐性が高い、余裕率（安全率）が高いことを意味します。
製品コンポーネントで言えば、製造規格にわずかに外れることで特性が大きく変わったり、システムで言えば、コンポーネントのわずかな特性変化でシステムの特性が大きく変わるようなものは、ロバスト性が低いと言われます。
これを模式的に表すと図1のようになります。
（a）に示すように、全体の特性は、構成要素の特性が相互作用した結果として表れます。
（b）がロバスト性の低い仕様で、（c）がロバスト性の高い仕様です。
【図1 ロバスト性】
２．より上位の要素の目標特性を考える
品質機能展開という手法で分解していくのと同様で、目標品質や目標特性はそれを得るための特性を分解していった構成をもちます。分解された特性を達成することにより目標特性が得られます。
開発仕様の設定で言えば、図2に示すように、目標特性Aを得るための構成として、（a）のように分解して仕様の設定をしていきます。
一方、実験による評価の結果、目標特性Aを得るための構成は、（a）ではなく（b）の方がより適切ということが分かることがあります。
この場合、（a）における目標特性Ｃのかわりに、（ｂ）に示す目標特性Ｉを評価できるように、評価方法やポイントを変更するという進め方もありますが、上位の目標特性Aを得るための重要なキーとなる目標特性Ｉを得るために、有利となる仕様に変更するという進め方もあります。
【図2 目標特性を得るための構成】
重要な理解・認識は、下位の目標特性は、あくまで上位の目標特性を得るための手段ということです。下位の目標特性にとらわれることなく、上位の目標に対する定性的および定量的な影響を考えなければなりません。ロバスト性の向上についても、より上位の要素のロバスト性を向上するという目的意識が必要になります。
開発の時間には限りがあります、その制限の中で、ロバスト性が高く高品質な製品やシステムを開発していくためには、強化すべきポイントを見極め、評価も集中的に行わなければなりません。
目標特性の構成の図の上で言えば、図3に示すようなイメージです。
【図3 重要な目標特性の見極め】
目標特性DとKを強化することにより、目標特性Aのロバスト性を効果的に向上することが可能になります。
３．目標管理で重要な要素
これまで説明してきた考えを念頭におき、どのように開発目標を管理していくべきかを説明します。
目標管理においては、目標値と達成値をドキュメント化し更新していきます。
目標達成状況についてはプロジェクトメンバー間でのDR（デザインレビュー）で、あるいは顧客とのレビューで議論が行われます。
このような管理・運用プロセスにおいて重要な要素を図4に挙げます。
【図4 目標管理で重要な要素】
①～④は、開発目標管理のドキュメントにおいて、初期作成と更新にあたって注意しなければならない項目を示しています。
⑤～⑥は、目標値の内容の質を向上するための注意項目を示しています。
以下より各項目について説明します。
①目標の数値化 ②評価方法・条件の定義
目標は、人により解釈に差が出てしまうような言葉ではなく、できる限り数値にして管理しなければなりません。この数値に対して、達成値と達成状態をトラッキング（追跡管理）していきます。達成状況の管理に関しては、評価サンプル数は充分か、数増し確認が必要かなどもドキュメントに記します。
評価結果の数値は評価方法や条件で変わります。これらを定義してより正確にすることにより、数値の意味を明確にすることが必要です。例えば、劣化特性を評価するための耐久信頼性テストでは、複合テストの条件設定でも評価結果が変わります。
③数値化が難しい項目の区別と定性的な表現
開発初期に、目標の数値化が難しい項目については、それを区別・明確化することが必要です。
定性的な目標の場合には、後のレビューで達成レベルを評価・議論するために、どのような定性なのかをできるだけ詳細に記述しておくことが有効です。
不快感など、そもそも最終評価特性が感応の領域である項目であっても、レーティング値などを用いることにより、数値による目標値達成管理が可能になります。
④開発目標の共有化・見える化
開発目標を設定するのは、達成状況を議論したり、管理したりするためです。達成状況により、軌道修正や方針変更、あるいはバックアップ策定などのアクションが必要になる場合もあります。
情報共有のためにドキュメントも分かりやすくすることが必要です。エビデンス的な詳細版と、集約的なまとめ版の２本だてでドキュメント化するという方法もあります。前者は、次の開発のためにも役立ち、後者は、現行プロジェクトの進め方を議論しやすくします。
⑤開発中における新たな情報の反映
開発を行うにはある期間が必要です。その開発期間中に発生した新規情報を開発目標と評価方法・条件に反映することも重要です。
例えば、市場での最新情報や、上位システムの評価により得られた知見です。これらが目標値管理に反映されなかったばかりに、開発目標値を全て達成したにもかかわらず、市場で不具合を起こすというようなことを避けなければなりません。
⑥評価結果に対する感受性
定義した評価方法・条件でOK基準を満たしたサンプルであっても、サンプルをよく観察したり、測定を行うことは重要です。これにより開発が進んでから、あるいは市場投入してから発生する不具合の兆候を見つけられるかもしれません。
例えば、OK基準は満足しているが、劣化の進行が早い、想定していない場所に強い当たり跡があるなどは、要注意です。OK基準を満足している劣化部分を強化しておくことは、ロバスト性を向上し想定外の不具合を防止することに繋がります。
目標値管理をすると管理リストをOKで埋めていきたくなりますが、OK？を正しく認識して対処することは、後々に大きな苦労をすることを防止することに繋がります。
最初に、上位目標に対して下位目標はあくまで手段であることを説明しました。
同様に、開発目標管理についても管理を行う目的を考え、管理のための管理ではなく、目的の達成のためにより役立つための管理・運用をしていくことが重要です。
（アイアール技術者教育研究所 H・N）
