開発業務プロセス分析によるシミュレーション活用の明確化

商品開発業務において計画通りに業務を進められないという話を耳にすることがあります。商品の市場投入が遅れたり、納期を守るために人員や費用を投入したり、さらには最小限の確認と検証で開発を前に進めたりと苦労されている企業も多いのではないでしょうか。

現状の問題を解決するカギは、「開発業務の見える化」により改善のポイントを明確化し、適切な改善策を打つことにあります。

開発業務におけるプロセス分析（業務の見える化）の手法

製品開発業務は相互依存的な業務タスクが多く、試行錯誤しながら計画し、プロジェクトを進めていく必要があります。一般的な方法として「ガントチャート」や「PERT図」などがありますが、これらの記述方法はタスクが時間軸に沿って流れることを前提としていますので、繰り返しを含む業務プロセスを正確に表現することができないといった問題が生じます。DSMではこのような繰り返し業務を表現しつつ、プロジェクト計画を作成することができます。

DSM（Design Structure Matrix）とは？

「情報の流れ（＝依存の箇所）」と「タスクの繰り返し（＝マトリックス上における依存の位置）」に着目して、プロジェクトのプロセスを分析し、最適化するためのツールです。重要な繰り返しを計画的に行い、回避すべき繰り返し（やり直し）を未然に防ぐプランニングが可能となります。

DSM活用による3つのメリット

開発プロセスの可視化
- 業務タスク間の双方向の関連を、一枚のマトリクスに整理できる。
- 主要な業務タスクにおける関係者の役割・権限を明確にできる。
問題点の抽出
- 「フィードバック領域」に着目し、手戻り（繰り返し作業）を洗い出せる。
改善策の検討
- 手戻りに対する改善策や、協調作業による効率化を検討できる。
- 改善策の実施後の効果を分析できる。

DSMを用いて、立案した開発業務計画に対する手戻りを考慮した開発日程、工数の想定結果を把握することにより、計画に対するリスクを顕在化することができます。

開発業務における手戻り削減ポイントの確認

商品開発業務を計画通りに遂行するために商品開発業務においてデザインレビューや検討会などのゲートを設けている場合が大半ですが、それでも計画と実績に乖離が生じてしまいます。例えば、レビューアが当たり前と思っていることが担当者は認識しておらず後工程で問題が発覚したり、前機種同様の方式なので大丈夫と考えていたが今回の機種では成立しなかったりするケースが見受けられます。

そこで、商品開発業務を計画通りに遂行するために押さえるべきカギは、「ゲートを跨いだ手戻りを防止する」こととなります。上述のDSMを用いることでゲートを跨いだ手戻りの発生ポイントが示されるので、そのポイントに着目した業務改善を行うことが必要となります。なお、業務改善を進めるにあたり手戻りが生じる要因は複数ありますが、ここでは性能/機能の未達、品質不良に着目し、性能/機能の未達、品質不良以外の要因については、別の機会に改めてご紹介します。

性能/機能の未達、品質不良による主な手戻りの要因として事前検証が不十分と言われていますが、手戻りを削減するためのポイントは2つあります。

製品の要求/仕様の明確化、明文化
製品仕様のみが内部共有されていたり、設計方針、実現方法、設計案選定の理由などが部分的にしか共有できていなかったりすることはありませんか？暗黙知は人によって見落とすリスクがあります。
性能/機能の実現方法のシミュレーション
過去機種で性能/機能を実現できた理由や、勘、コツ、経験が標準化されていなかったり、物理現象における原理原則の仮説立案が不十分だったりしませんか？性能/機能を実現する方法が適切かどうか、また実現の見込がどの程度あるかの確認を属人的に判断するのではなく、ロジカルに説明しレビューすることが重要です。

それぞれのポイントについてもう少し詳しく説明します。

開発業務の試作後の手戻り防止方法

1.製品の要求/仕様の明確化、明文化

暗黙知を無くし商品開発に関わるメンバーが正しく認識するための方法としてQFD（品質機能展開）の活用が挙げられます。QFDの主な目的として次が挙げられます。

製品のねらいにあった仕様を設定し、QCDのバランスを十分考慮した開発を進める。
仕様の決定や変更、コストダウンなどにおいて複数部門が共通認識を持てるようにし、スムーズな意思決定を促進する。
製品開発における技術課題を洗い出す。
製造品質を管理するための指標を明らかにする。

ここでは、製品の要求/仕様の明確化、明文化により設計観点での抜け漏れを防止し、設計目標の社内合意形成を目的としますので、品質機能展開の一部である「品質表」に着目します。

「要求品質」（顧客の真の要求を言語で表現したもの）から「品質特性」（要求品質の達成度を評価可能とする代用特性）の導出に使われる二元表を品質表と呼び、基本的な作成手順は次の通りです。

品質表の作成は、要求品質から品質特性を段階的に抽出・整理することで暗黙知を無くし、商品開発に関わるメンバーが製品の要求/仕様を正しく認識できるようになります。

2.性能/機能の実現方法のシミュレーション

試作品による実機検証では性能/機能を評価する際にはOK/NGの結果だけでなく、その結果に至った理由を明らかにしておくことが重要です。その際には物理現象の原理原則に基づくメカニズム解明が必要となり、メカニズムが明らかになっていれば試作前のCAE（デジタル検証）により性能/機能の実現方法についてレビューを行うことが可能となります。性能/機能の実現方法を試作前に確認するアプローチは次の通りです。

メカニズムを書き下し、問題発生の理由を説明する仮説を構築する。
設計結果（壊れた/壊れなかった）ではなく、考え方（検討用モデル、仮説）の妥当性を検証する。
不明点の現象（実験結果）を観察し、説明するためのモデルを構築する。
設計で活用するための評価モデルを構築する。
3Dモデルが無い状態でも定量的な評価により製品要求・機能へ影響を与える特性と傾向を把握する。
試作直前の確認として形状ベースによる性能/機能の実現性を検証する。

CAEの活用は単なる実機試験の置き換えではなく、性能/機能の実現方法を関係者間で正しくレビューするために必要な手段となります。

まとめ

ここまでお読みいただいた方はお気づきの事かと思いますが、製品の要求/仕様の明確化、明文化し性能/機能の実現方法を事前に確認するアプローチはMBSEの手法そのものです。

商品開発業務において計画通りに業務を進められないという問題を解決するカギは、「開発業務の見える化」により改善のポイントを明確化し、適切な改善策を打つことにあります。モデルベースの考え方によりアプローチを効率化することで商品開発業務を計画通りに遂行できるようになり、開発リードタイムの短縮や開発工数削減につながる改革を推進できるようになります。