「実機レスによりデバッグ完了期間が1週間短縮」は大きいといえるのか：3D設計推進者の眼（23）（2/3 ページ）

　そこで「私がここを協力しよう」という人（支持者）が必要です（関連記事：フロントローディングすると工数が増える現実――抵抗勢力と現場の勘違い）。しかし、実際問題として、このように設計初期状態に負荷をかけることと、開発リードタイム短縮、総工数というものがどのような結果を得たのかという詳細データを私は持ってはいません。現職において、これを突き詰めていく必要を感じています。

　下図は、DMUによる制御シミュレーター導入有無における開発期間試算の例になります。

DMUによる制御シミュレーター導入有無における開発期間試算の例

　実機レスデバッグの実施により、デバッグ完了期間としては1週間を見込みました。完成期間の3.5カ月に対して1週間の短縮という試算が、果たして大きいとみるのか、小さいとみるのか。これだけでは、私自身は制御シミュレーターの導入効果が大きいとは言い切ることはできません。

　DMUによる制御シミュレーターですが、3Dデータに対して、以下のようなさまざまな設定を行う必要があります。

• I/Oマップの確認
• 3D CADアセンブリーデータ再構成：アセンブリーファイル名変更、パーツファイル名変更、機構名称・仮想部品名称の設定
• 制御シミュレーション用3Dデータ変換
• 機構設定：モータ駆動/エアシリンダ駆動/センサー/アナログ機器
• シミュレーション定義

　簡単にいえば、もともとの3D CADデータの構成に対して、可動部と固定部のサブアセンブリー化を行い、制御シミュレーター用の3Dデータに変換した後、ライブラリにある駆動機器の動作条件をその3Dモデル内のサブアセンブリーに設定していくという作業が必要になるわけです。

　制御ハードウェアと仮想検証を行うPCとの接続設定作業も必要になります。非常に制御軸数の多い、新規開発の装置においては、4000時間を超える機器設定時間を要したこともあります。流用設計やスキルアップによって、この工数は減少しますが、実機でしかできないデバッグを含む総ソフトウェア開発工数において、この制御シミュレーターの設定工数が占める割合が、約40％となることもあります。

　この工数を設計部門が負担することは実際に難しいでしょう。社内にこれを専門的に行うことができる部門を設置することが必要なことや、その工数を受注製番においてどのように処理をするかという課題も生じることでしょう。

　この一例だけを見ても、単に工数だけに注目してしまうと、受注製番における総工数は上昇することになって、原価管理を行う部門からクレームが発生することが予測されます。

　フロントローディングとは、いわば「初期設計段階に負荷をかけるリソースを投入すること」なので、当然のことながら、その追加投入された工数分は、総工数が上がるわけです。何だか悲観的な感じですが、その工数に見合うQCD向上を図ることが、このフロントローディングの目的にしなければならないのです。

　この制御シミュレーターの例においても、下記のような効果があります。

• 実機レスデバッグにより機械組立と制御担当による実装置の占有取り合いはない
• 仮想装置でのデバッグでは、干渉しても装置は壊れない
• 仮想装置でセンサー関係の故障を起こすことも可能
• 仮想検証での干渉など事前に問題を見つけることがあれば、実機組立に対策が間に合うことで、製作スケジュール遅延を防止することもできる
• 装置出荷後も仮想検証は可能

　実績とすれば、制御シミュレーターでのソフトウェアのバグ検出率が、実機を含めたデバッグにおいて、60%を超える実績もあります。

　これらの効果は更に分析する必要があるでしょう。FMEA、CAE、DRも工数を要することは当たり前ですが、これらを初期設計段階に集約することによって、QCDの向上が本当に図れるのか分析が必要だと私は考えています。そう考えるのは、それらが指標的に把握できていないからなのです。

• FMEAによるリスク分析件数と項目の対応時間に対する効果金額
• CAEの作業工数とその効果金額（削減可能な追加費用・作業時間）
• DRの回数と指摘事項点数、その指摘事項に対する作業工数と効果金額（削減可能な追加費用・作業時間）

　ここまでのお話で皆さんにも感じていただきたいのは、フロントローディングの目標を達成するのは、設計者だけではなく、会社全体の話であるということです。