第11回 開発プロセス運用の仕組み作り | DX時代の製品開発プロセスとCAEの重要性

前回（第10回）は、設計CAEの課題解決の進め方について以下のように紹介しました。

企画プロセスから始まったMBDの普及拡大と共にデジタル技術を駆使することで設計プロセスも進化しつつあり、将来の製品開発プロセスの姿が明らかになってきました。課題は残されていますが、新たな設計プロセスと支える設計CAEの確立に向けて着実に努力が重ねられています。

今回（第11回）は、MBD手法に基き再構築した開発プロセスを開発現場で確実に運用するための仕組み作りについて解説します。各回でも個別に紹介してきましたが、プロセスを定着させるためには大変重要ですので改めて設計プロセスに焦点を当てて整理しておきます。

貴重な資源と時間を投入して設計プロセスを再構築しても、残念なことに開発現場で十分に活用されていないケースが散見されます。現場での安定的な運用には仕組みが不可欠です。仕組み作りの重点はプロセスの標準化と情報基盤の構築と実装です。

一般的に設計者は多忙であり、日常業務に追われてプロセス標準化が十分でないことが少なくありません。設計プロセスが属人化（設計者によりプロセスが異なる）していると非効率で開発手戻りの原因にもなりますので、プロセスを標準化する必要があります。標準化により若手でもベテラン設計者と同様に高品質で高効率な設計が可能となり、設計プロセスにおける手戻りも防止できます。

標準化にあたり、まず設計者にヒアリングを行い基準となるプロセスを定める必要があります。ベテランは豊富な経験を踏まえてプロセスの一部を省略することもあり、各層（ベテラン、中堅、若手等）の設計者からバランス良くヒアリングすることが肝要です。

基本的な標準化手法はSIPOCとRFLPです。業務プロセスを構成する5要素である“SIPOC” （下記＊）という流れに沿って、他部門との仕様調整等も含めて設計タスクを体系的に配列し、時系列で連結します。本手法で整理すると抜け漏れ等の課題を浮彫りにすることができます。

＊SIPOC： S（Supplier）；供給者→ I（Input）；入力→ P（Process）；プロセス（R→F→L→P）→ O（Output）；出力→ C（Customer）；顧客

中核となるP（Process）；プロセスについては、設計根拠（トレーサビリティ）を明確にするためSE（システムズエンジニアリング）の基本である“RFLP” （下記＊）の流れで展開します。

＊RFLP： R（Requirement）；要求分析→ F（Function）；機能設計→ L（Logical）；論理設計→ P（Physical）；物理設計

次に、設計情報の共有や再利用のために設計関連情報（設計文書等）の一元管理が必須です。保管形態（書類や電子データ等）や保管場所が不統一で、若手設計者が設計にあたり情報収集に苦労しているケースも見受けられます。情報基盤PLM（Product Lifecycle Management）を構築し、標準化されたプロセスを実装します。情報基盤には開発関連情報PDM（Product Data Management）、CAE関連情報SPDM（Simulation Process & Data Management）等も含めて格納します。なお、実装時に定型作業（帳票作成等）の自動化も実施すると、さらなる効率向上が期待できます。

情報基盤専用ツールとして本格的なプラットフォームが市販されていますが、使いこなすためにはツールの理解や十分な習熟が必要です。はじめは簡易的なツール（Excel等）でスタートし、慣れてから本格ツールに移行すると良いでしょう。

プロセス標準化やシステム実装等にはノウハウや経験が求められ、自社だけで完成させるには時間がかかります。かつて筆者もエンジン部品の設計プロセス標準化に取り組んだ経験がありますが、主たる設計業務との兼務のため完成までには数年かかってしまいました。繰返しになりますが、コアである新技術創出や新製品開発に集中するためにも、外部の専門企業を活用することをお勧めします。

プロセスの確実な運用には仕組みが不可欠であり、SIPOCとRFLPに基づいた標準化、開発情報類を一元管理するための情報基盤の構築と実装が重点です。時代や他社の動向に遅れないようにするために、外部企業活用による仕組み作りの加速も検討する価値があります。
次回（第12回）は、最終回として本シリーズのまとめと変革の時代に求められるエンジニア像について私なりの見解を述べてみたいと思います。