空調開発で発生しやすい部門間の認識齟齬をMBSEで防ぐ方法

この記事で分かること

• 空調設計でMBSE/SysMLを使う目的
• 要求・構造・制御・検証をつなぐ考え方
• 設計レビューで最初に確認すべき論点

空調開発では、機械設計、制御設計、電気設計、品質保証、製造、保守、設備管理、営業技術がそれぞれ異なる言葉で同じシステムを見ています。機械設計者にとっては熱交換器や配管の問題でも、制御設計者にとってはセンサ値と保護条件の問題であり、品質保証にとっては故障モードと検証条件の問題です。この見方の違いが整理されないまま進むと、レビューで合意したつもりでも、後工程で認識齟齬が表面化します。

MBSEは、部門間の会話をなくすものではありません。むしろ、会話の前提をそろえるための共通モデルです。要求、構造、流れ、状態、制御、故障、検証をつなげることで、「何について合意したのか」「何が未決なのか」を明確にできます。

部門間の認識齟齬は、担当者の理解不足ではなく、同じ対象を別の粒度と言葉で見ていることから発生します。

目次

• 結論：MBSEは共通語ではなく翻訳表として使う
• 空調開発で起きやすい認識齟齬
• 部門ごとの関心をモデル要素へ対応させる
• 要求からレビュー論点をつなぐ
• 変更時の認識齟齬を防ぐ手順
• 会議運営での使い方
• よくある失敗
• 部門間合意を残すレビュー記録
• まとめ

結論：MBSEは共通語ではなく翻訳表として使う

MBSEを導入すると、すべての部門がSysMLを同じ深さで理解する必要があると思われがちです。しかし実務では、全員が図法の専門家になる必要はありません。重要なのは、部門ごとの関心をモデル上で対応づけることです。

MBSEは、全員を同じ言葉に統一するより、各部門の言葉を接続するために使う方が定着します。

空調開発で起きやすい認識齟齬

空調開発でよく起きる認識齟齬は、用語の違いだけではありません。前提条件、<u>責任範囲</u>、評価方法、異常時の扱いが部門ごとに違うことが原因です。

これらは会議で一度説明しても、仕様変更や担当者変更で再発します。だからこそ、モデルとして残す必要があります。

部門ごとの関心をモデル要素へ対応させる

認識齟齬を防ぐ第一歩は、部門ごとの関心をモデル要素に割り当てることです。たとえば、冷媒漏えいという論点を考えると、機械設計は配管接続や部品配置を見ます。制御設計は圧力・温度の異常検知を見ます。品質保証は故障モード、発生原因、検出方法を見ます。保守担当は点検記録と通知を見ます。

モデル上で対応づけると、会議で「それは誰の範囲か」を毎回議論せずに済みます。

要求からレビュー論点をつなぐ

部門間認識をそろえるには、レビュー論点を要求から始めます。要求が曖昧なまま部品や制御の議論をすると、部門ごとに違う前提で最適化してしまいます。たとえば「省エネ」を上位要求にするなら、COP、実使用効率、ピーク電力、快適性、AI制御の停止条件を分けます。

要求図で派生関係を作り、IBD、状態機械図、FMEAへ接続すると、部門別論点が同じ要求から出ていることを確認できます。

変更時の認識齟齬を防ぐ手順

設計変更は、認識齟齬が最も起きやすい場面です。配管経路の変更、センサ追加、制御仕様変更、冷媒変更、BEMS連携追加などは、複数部門へ波及します。

この順序で進めると、変更会議が部品単体の議論に閉じにくくなります。

会議運営での使い方

MBSEモデルを会議に持ち込むときは、すべての図を説明しようとしないことが重要です。会議の目的に応じて、確認する図を絞ります。部門間の認識合わせなら、要求図、IBD、状態機械図、FMEA連携表の4点で十分なことが多いです。

会議後は、議事録ではなくモデルへ反映する項目を明確にします。指摘がモデルに戻らない場合、次回以降も同じ認識齟齬が繰り返されます。

よくある失敗

部門間合意を残すレビュー記録

部門間の認識齟齬を防ぐには、会議で合意した内容を「誰が何をするか」だけで終わらせないことが重要です。合意内容を要求ID、構造要素、状態名、信号名、故障モード、試験項目へ紐づけて残します。そうしないと、次回レビューで同じ合意を別の言葉でやり直すことになります。

この形式で残すと、合意が議事録の文章に埋もれません。設計変更が入ったときも、どの部門のどの前提を再確認すべきか分かります。品質保証や保守担当が後から参加した場合でも、なぜその制御条件や点検要求が必要になったのかを追跡できます。

また、部門間合意には「未決」を残すことも大切です。全項目を無理に決めきると、曖昧なまま決定済みに見えてしまいます。データ取得周期、通信異常時の扱い、点検記録の保存期間、AI制御の説明ログなど、未決のまま残る項目は、責任部門と期限を付けてモデル上に残します。

部門横断レビューを定着させる初期段階では、合意記録を複雑にしすぎない方が続きます。最初は、変更対象、関係部門、影響する要求、確認する試験、未決事項の5項目だけでも十分です。重要なのは、会議後に誰かが議事録を読むことではなく、次の設計判断で<u>同じ前提</u>を再利用できることです。

この最小形式で記録を始め、必要に応じてFMEA番号、<u>ログ項目</u>、点検要求、法規制確認などを追加します。小さく始めることで、MBSEが会議の負担ではなく、認識齟齬を減らす運用として受け入れられやすくなります。

次に読むなら

次に読むなら、空調メーカーにおけるMBSE導入の第一歩 がおすすめです。このテーマの全体像を整理する柱記事です。

関連記事

• SysMLで空調システムを設計するとは何か？初心者向けに実務視点で解説: このテーマの全体像を整理する柱記事です。
• 空調設計にMBSEが必要になる理由：メカ設計だけでは解決できない時代へ: このテーマの全体像を整理する柱記事です。
• 空調室外機をSysMLでモデル化する基本手順: 前提を押さえると、この設計判断の位置づけがつかみやすくなります。
• CAD中心設計とSysML中心設計の違いを実務視点で比較する: 前提を押さえると、この設計判断の位置づけがつかみやすくなります。

まとめ

空調開発で発生する部門間の認識齟齬は、担当者の注意不足だけで起きるものではありません。機械、制御、品質、保守、設備が同じシステムを別の粒度と言葉で見ているために発生します。

MBSE/SysMLは、すべての部門を同じ言葉に統一する道具ではなく、各部門の関心を接続する翻訳表として使うと実務に馴染みます。要求、構造、流れ、状態、制御、故障、検証をモデル上でつなぎ、変更時には<u>影響範囲</u>を確認することで、レビューの合意を後工程まで残せます。