コンカレントエンジニアリングを促進するPLM活用のすゝめ

コンカレント開発がうまくいかない理由としては大きく、プロセス・ルール構築の難しさとそれを支える仕組み（システム）がうまく構築できていないというところにあります。

① プロセス・ルール構築の難しさ

コンカレント開発は設計完了前に生煮えの情報を「正式に公開」することが大きなポイントとなりますが、その“目的”と“公開する情報”およびそれを基に下流部門が“実施する業務”を定義しなければ、設計者にとっても下流部門にとってもただのリスクにしかなりません。
設計がいつ・何を・どの程度の完成度で公開すべきか？また、それを受けて下流部門は何をアウトプットするのか？を両者が納得のいく形で、部門横断・協力型で取り組むためのルール設計をしっかりと行うことが非常に重要です。具体的なプロセス改革のポイントについては、レイヤーズの他の記事でもご紹介しておりますので、参考にしてください。
（参考URL：設計頼みのコンカレント開発、やめにしませんか？）

② コンカレント開発を支える仕組み（システム）

次に、仕組み面の課題としてよくあるのが、「過去に発生した変化点の判断根拠や設計意図が残っていない」「変化点を追えない」という点です。例えば設計変更の過程でどの案が検討され、なぜ現在の仕様に至ったのかといった経緯が記録されていない、前回の公開からの変化点が分からない場合、下流部門では「変更の経緯が不明で、何を考慮して考えれば良いかわからない」「どこが変わったのか聞かないとわからない」といった状況に陥ります。その結果、設計部門への問い合わせや、すり合わせ回数が大幅に増えたり、下流部門の業務の手戻りが多くなり、“ただ負荷が増えただけ”のコンカレント開発が出来上がってしまいます。

また、設計から下流部門への情報共有に多大な労力がかかる点も課題です。3Dやデジタルデータを正とした共有やその仕組みがない状態だと、設計変更のたびに会議や資料作成を通じて説明が必要となり、設計部門の工数がとられることでタイムリーな連携が阻害されてしまいます。しかし、労力がかかるからといって共有した情報の位置づけを曖昧にすることや、下流部門への説明を疎かにしてしまうのもよくありません。設計部門は検討用の暫定データとして扱っている一方で、製造部門は確定前提で受け取り、詳細部分の工程設計まで進めてしまう等のケースがあります。情報の意味合いや成熟度に対する共通認識がないままでは、各部門が異なる前提で作業を進めることになり、結果として大きな手戻りや非効率を生み出すことになります。

コンカレント開発を円滑に進めるためには、変更来歴が管理・わかりやすく把握できることに加え、情報共有を手軽に実施できるような仕組み（システム）が必要となります。
今回はその仕組み面での解決として、Aras InnovatorというPLMパッケージシステムを活用した施策例を次章以降で説明します。

開発段階における設計変更履歴や、単なる変更結果の記録の管理ができることはもちろん、その変化点の結果を容易に把握できるようにすることは、コンカレント開発を促進するうえで肝となります。
さらには、過去の判断根拠や設計意図といった『コンテキスト（文脈）』を残していくことは、検討漏れのリスクを最小化するだけでなく、影響範囲を精緻に特定することにもつながります。これは下流部門がコンカレント開発の結果生み出すアウトプットにも大きく影響を与えるため、非常に重要な要素となります。
ここでは、それらを実現していくうえでの代表的なPLM機能例について紹介していきます。

1．DR等のチェックポイントと絡めたスナップショット機能の活用

仕掛段階の設計データを複数回公開し、徐々にQCDを作りこんでいくコンカレント開発にとっては、開発のある時点における設計の状態を再現できる環境の存在がコンカレント開発の成功に直結します。
PLMの変更通知等ワークフローを活用した、ある時点の構成をスナップショットとして記録に残す機能は、一般的なPLM機能として有効な手段といえます。
この方法であれば、例えばパーツ自体の版数を上げることなく、ある設計状態を必要なタイミングで呼び戻すことができます。
この機能は設計者にとっても、進行中の開発のなかでその時点の状態を振り返りたい場合や、次世代機種の開発時にナレッジとして活用することもできます。

2．スナップショット機能を有効に活用するための比較機能の活用

こうして蓄積された設計情報は、PLMの構成比較の機能とあわせて使うことで、コンカレント開発へ最大限有効活用することができます。
開発段階における新旧案や複数の設計案に対してBOM構成を横並びにして、構成のどこに違いがあるのかを一目で可視化することができるため、変更箇所を即座に特定することができます。
また、構成だけでなく、モデル形状や材質・コストといった属性値の差分についても、PLMに登録している属性情報をPLM内で比較・検証することも可能です。

さらには周辺ツールとの併用を行うことにより、3Dモデル形状そのものの比較も行うことができるので、併せて活用することで効果を最大化させることが期待できます。

このように、これまで担当者間の属人的な手法に頼っていた開発段階における変更経緯の管理や分析業務をデジタル上で行うことで、コンカレント開発を円滑に行うための基盤を確立することが可能となります。

コンカレント開発を推進するうえで、設計情報を下流部門といかに効果的かつ効率的に連携していくかも重要です。
下流部門と連携したい生煮えの情報の “どの状態（完成度）”の “どこ（見るべきポイント）”を“いつ”下流工程に確認してほしいのかという、公開ルールを定義したうえで、“どのように（効率的に）” 下流部門側と確認していくかがポイントとなります。
本章では、コンカレント開発の情報公開ルールをPLM活用によって、 “どの状態（完成度）”の“どこ（見るべきポイント）”といった情報をどのように定義できるかについて述べるとともに、 “どのように（効率的に）”下流部門側とコミュニケーションがとれるかについて紹介していきます。

1．公開時の設計状態の「完成度」を定義し、下流部門が確認すべき深さを可視化

後工程側へ設計データをレビュー依頼するにあたり、 “どの状態”であるかをいかにわかりやすく、属人化させない形で仕組み化していくことが重要です。
やり方の一つとして、例えばPLM上のパーツやアセンブリに、そのような完成度を示す属性を付与することで、下流工程を含めた担当者が、誰でも一目で設計データのその時点での状態を判別できるようにすることもあげられます。
例えば以下のようにそれぞれの状態を定義し、公開情報とともに共有されれば、後工程側はこのような確度情報に基づいた検討を先行して開始させることができます。

例：
確定：仕様変更の可能性は極めて低く、確定情報として扱ってほしい
流動的：外形寸法は固まっているが、内部寸法の微調整の可能性あり
検討中：構造自体が変わる可能性があり、参照のみに留めてほしい

2．ワークフローを用いた公開の工夫とバーチャル検証環境でのフレキシブルな設計レビュー

PLMを活用して“どこ（見るべきポイント）”を“どのように（効率的に）”下流部門へ伝達していくかについては、開発情報を公開するための専用ワークフローの使用やバーチャルレビュー環境の活用が考えられます。
専用のワークフローにより、コンカレント開発をするうえで特に連携したい特定の属性情報を保持することができ、その他ワークフローとの使い分けを明確に行うことができます。
前述の設計情報と合わせて“どこ（どのポイント）”を見てほしいのかといった情報を指定し、ワークフローとして流すことで下流側にやってほしいことを明確にすることができます。

また、3Dモデルや設計資料をレビューする場として、会議体を設けて検証や指摘出しを行うのも一般的ではありますが、設計者が参加者の調整を行うケースが多く、本来の業務に関係のないところで設計者の負担となっています。
そこで、PLMのバーチャル検証環境を活用して、下流部門における3Dモデルや設計資料の確認作業について、チャット機能などを使用して、時系列で残していくことで下流部門と時間制約の少ない円滑なコミュニケーションが実現可能となります。

コンカレント開発は、開発L/Tを削減するという高い目標を全部門で持ち、各部門の英知を集結させて、協力型で開発を行うことが重要です。
そのためには、それが「必ず」行われるためのプロセスやルールを整備することはもちろん、効率的に実現できる仕組みの支えを借りてやっていくことがポイントであることをご紹介しました。

ただし、コンカレント開発の最終ゴールはそこではありません。

コンカレント開発プロセスで行われる判断や検証、指摘・意見出しの結果は、その企業にとっての大きな「資産」（ナレッジ）となります。
そのため、デジタルデータとしてその結果を残し、蓄積・活用することで、誰かを頼らなくてもそのデータを頼りに、各々が情報を判別できる状態にすることを目指し、将来的にはそれをシステムに組み込み自動レビュー化、データの中から関連／該当ナレッジを抽出しプッシュ型で確認・注意を促す等、AI活用も視野に入れた取り組みへと昇華させていくことが必要です。

レイヤーズ・コンサルティングでは、開発設計プロセスに係る業務改革、それに伴うシステムやAI導入に係る事例を多数保有しています。もっと深く確認したい／事例を聞きたい／相談をしたい等のご要望がございましたら、どうぞお気軽にご連絡ください。