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

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

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

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

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

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

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

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

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

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

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

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